MacBookAir 4,1 trackpad does not work with evdev/multitouch driver

To provide the sequence of what I think is relevant log files, I did this:

boot cold in to 3.2.0-17 -- trackpad not working (precise-kernel-coldboot)
warm reboot into 3.2.0-17 again -- trackpad not working (precise-kernel-reboot)
warm reboot into 3.2.1-030201 -- trackpad works (upstream-kernel-reboot)
warm reboot into 3.2.0-17 -- trackpad works (precise-kernel-afterupstream)

I saved Xorg.0.log and dmesg after each boot. After stripping off the timestamps, I notice that the main difference is that the apple trackpad is initialized *much* later with the 'afterupstream'. Also I notice that this message is no longer in dmesg after the upstream 3.2.1 kernel is booted:

bdi 1:0: hash matches
acpi device:19: hash matches

I have attached the results of this debugging sequence, the tags in parenthesis above correspond to the log file names.

@Clint -- does the touchpad work with the later mainline kernels, which ever the latest v3.2.x specifically (v3.2.1 is pretty old now) we are based on v3.2.6 (at the time of this comment). So it would be good to confirm/deny whether the v3.2.6 mainline kernel works too. That should be in teh same place you got the previous one.

@Clint

A new patch for the bcm5974 driver was merged from upstream in 3.2.0-17. Please try the previous Ubuntu linux kernel to see if it works.

Thanks!

nm, I see in the original description that this occurred in previous kernels too.

@apw yes I just tried 3.2.6, identical behavior to 3.2.1

I'm really puzzled by this. I'm using the same machine, with the exact same touchpad based on the USB id, and I don't see anything like this. The bcm5974 driver in precise is identical to the one in 3.2, aside from the patch that Chase mentioned that wasn't present prior to 3.2.0-17.26. It's hard to imagine what might be causing the difference in behavior.

The logs show that even when the touchpad isn't fully functioning that it's being correctly detected, that the driver is being loaded, and that X is using the synaptics driver to support it. The driver never sends relative motion events, so the fact that it works at all suggests that the absolute coordinate events are being sent from the kernel driver.

Chase, given the above, can you provide any insight on what the driver could be doing that could be resulting in the behavior that Clint is seeing? On the surface everything looks okay, yet there's obviously some problem here that I'm at a loss to explain.

FYI, further testing has actually revealed that 3.2.6 *does not* in fact fix this reliably. I can't say whether its "sometimes" or "always" with 3.2.6, as I think it worked at least once.. but the last few times, 3.2.6 is just like the precise kernel. 3.2.1 does *always* result in a trackpad that works.

More facts, I am booting into Ubuntu from rEFIt .. could it be part of it?

Thank you for taking the time to file a bug report on this issue.

However, given the number of bugs that the Kernel Team receives during any development cycle it is impossible for us to review them all. Therefore, we occasionally resort to using automated bots to request further testing. This is such a request.

We have noted that there is a newer version of the development kernel than the one you last tested when this issue was found. Please test again with the newer kernel and indicate in the bug if this issue still exists or not.

You can update to the latest development kernel by simply running the following commands in a terminal window:

    sudo apt-get update
    sudo apt-get upgrade

If the bug still exists, change the bug status from Incomplete to Confirmed. If the bug no longer exists, change the bug status from Incomplete to Fix Released.

If you want this bot to quit automatically requesting kernel tests, add a tag named: bot-stop-nagging.

 Thank you for your help, we really do appreciate it.

Just tried 3.2.0-17.27 .. still the same problem.

I'm starting to think there is a user space component to this. Since some time in the last 7-10 days, the 3.2.6 and 3.2.1 mainline kernels have no effect on things, I can't get any 3.2 kernel to work. At this point I have to use the Oneiric kernel.

Update.. so now everything works fine with the synaptics driver, no boot to 3.2.1 or 3.2.6 required. I suspect this was an xorg problem all along.

If I remove xserver-xorg-input-synaptics then the trackpad stops working (and oddly enough, the keyboard becomes really hard to use if X is running.. very hard to describe, but keypresses are lost). In my experience, the synaptics driver is really bad at palm detection, so I am not really happy about having to use it, but at this point, its my only option.

Redirecting to xorg. Thanks everyone for the help thus far.

More testing has revealed this to be some kind of race condition I think. I can now fix the problem by switching to tty1 and restarting lightdm.

Diffing the two log files reveals a massive difference between first-boot Xorg.0.log and Xorg.0.log.old. I will attach both files. The interesting part, to me, is here (old is the failed file):

--- Xorg.0.log.old.awked 2012-03-03 07:04:21.134327363 -0800
+++ Xorg.0.log.awked 2012-03-03 07:04:11.570327281 -0800
@@ -13,7 +13,7 @@
 Markers: (--) probed, (**) from config file, (==) default setting,

-(==) Log file: "/var/log/Xorg.0.log", Time: Sat Mar 3 06:59:22 2012
+(==) Log file: "/var/log/Xorg.0.log", Time: Sat Mar 3 07:01:36 2012
 (==) Using system config directory "/usr/share/X11/xorg.conf.d"
 (==) No Layout section. Using the first Screen section.
 (==) No screen section available. Using defaults.
@@ -41,7 +41,7 @@
 (==) ModulePath set to "/usr/lib/x86_64-linux-gnu/xorg/extra-modules,/usr/lib/xorg/extra-modules,/usr/lib/xorg/modules"
 (II) The server relies on udev to provide the list of input devices.

-(II) Loader magic: 0x7f2eb9d84b00
+(II) Loader magic: 0x7f3587664b00
 (II) Module ABI versions:
    X.Org ANSI C Emulation: 0.4
    X.Org Video Driver: 11.0
@@ -392,7 +392,7 @@
 (--) evdev: Apple Inc. Apple Internal Keyboard / Trackpad: Vendor 0x5ac Product 0x249
 (--) evdev: Apple Inc. Apple Internal Keyboard / Trackpad: Found keys
 (II) evdev: Apple Inc. Apple Internal Keyboard / Trackpad: Configuring as keyboard
-(**) Option "config_info" "udev:/sys/devices/pci0000:00/0000:00:1a.7/usb1/1-1/1-1.2/1-1.2:1.0/input/input6/event6"
+(**) Option "config_info" "udev:/sys/devices/pci0000:00/0000:00:1a.7/usb1/1-1/1-1.2/1-1.2:1.0/input/input14/event6"
 (II) XINPUT: Adding extended input device "Apple Inc. Apple Internal Keyboard / Trackpad" (type: KEYBOARD, id 10)
 (**) Option "xkb_rules" "evdev"
 (**) Option "xkb_model" "pc105"
@@ -460,24 +460,6 @@
 (II) intel(0): EDID vendor "APP", prod id 40178
 (II) intel(0): Printing DDC gathered Modelines:
 (II) intel(0): Modeline "1366x768"x0.0 72.00 1366 1380 1436 1500 768 769 772 800 -hsync -vsync (48.0 kHz)
-(II) config/udev: removing device Apple Inc. Apple Internal Keyboard / Trackpad
-(II) evdev: Apple Inc. Apple Internal Keyboard / Trackpad: Close
-(II) UnloadModule: "evdev"
-(II) Unloading evdev
-(II) config/udev: Adding input device Apple Inc. Apple Internal Keyboard / Trackpad (/dev/input/event6)
-(**) Apple Inc. Apple Internal Keyboard / Trackpad: Applying InputClass "evdev keyboard catchall"
-(II) Using input driver 'evdev' for 'Apple Inc. Apple Internal Keyboard / Trackpad'
-(II) Loading /usr/lib/xorg/modules/input/evdev_drv.so
-(**) Apple Inc. Apple Internal Keyboard / Trackpad: always reports core events
-(**) evdev: Apple Inc. Apple Internal Keyboard / Trackpad: Device: "/dev/input/event6"
-(--) evdev: Apple Inc. Apple Internal Keyboard / Trackpad: Vendor 0x5ac Product 0x249
-(--) evdev: Apple Inc. Apple Internal Keyboard / Trackpad: Found keys
-(II) evdev: Apple Inc. Apple Internal Keyboard / Trackpad: Configuring as keyboard
-(**) Option "config_info" "udev:/sys/devices/pci0000:00/0000:00:1a.7/usb1/1-1/1-1.2/1-1.2:1.0/input/input14...

Well I've at least found a workaround. I added 'udevadm settle' right before the 'exec lightdm' in /etc/init/lightdm.conf. As long as that is in place, I do not experience this issue.

So, I think this is an issue with boot speed. My machine has almost nothing installed beyond the default, and boots from grub -> lightdm in about 5 - 8 seconds. That might explain why you don't see it Seth if you have more things starting at bootup, as that may be enough to delay X long enough for udev to be available.

cnd, mind having a look at Clint's problem? Some sort of race condition loading synaptics.

New data point.. it failed again even with the udevadm settle... though its happening far less often now at least.

Hi Bryce,

This seems to be a udev layer issue, which I have no idea about. I'm removing my assignment because I don't know what to try, and I don't have the resources to look into it right now :(.

Adding 'and stopped udevtrigger' to the start on conditions seems to have solved the problem without any sleeps. This might also be the fix for bug # 969489, which might suggest that the whole thing is related.

Spoke too soon. I just did a reboot and had no trackpad.

Still looks like lightdm just starts a tiny bit too soon, before some bits of the hardware are initialized. Its likely a specific set of udev events needs to be looked for that represents the sum total of input devices being initialized.

X is supposed to support hot-adding of input devices.

Here are the relevant lines that show up during a failed boot but not a successful one:

-(II) config/udev: removing device Apple Inc. Apple Internal Keyboard / Trackpad
-(II) evdev: Apple Inc. Apple Internal Keyboard / Trackpad: Close
-(II) UnloadModule: "evdev"
-(II) Unloading evdev
-(II) config/udev: Adding input device Apple Inc. Apple Internal Keyboard / Trackpad (/dev/input/event6)
-(**) Apple Inc. Apple Internal Keyboard / Trackpad: Applying InputClass "evdev keyboard catchall"
-(II) Using input driver 'evdev' for 'Apple Inc. Apple Internal Keyboard / Trackpad'
-(II) Loading /usr/lib/xorg/modules/input/evdev_drv.so
-(**) Apple Inc. Apple Internal Keyboard / Trackpad: always reports core events
-(**) evdev: Apple Inc. Apple Internal Keyboard / Trackpad: Device: "/dev/input/event6"
-(--) evdev: Apple Inc. Apple Internal Keyboard / Trackpad: Vendor 0x5ac Product 0x249
-(--) evdev: Apple Inc. Apple Internal Keyboard / Trackpad: Found keys
-(II) evdev: Apple Inc. Apple Internal Keyboard / Trackpad: Configuring as keyboard
-(**) Option "config_info" "udev:/sys/devices/pci0000:00/0000:00:1a.7/usb1/1-1/1-1.2/1-1.2:1.0/input/input14/event6"
-(II) XINPUT: Adding extended input device "Apple Inc. Apple Internal Keyboard / Trackpad" (type: KEYBOARD, id 10)
-(**) Option "xkb_rules" "evdev"
-(**) Option "xkb_model" "pc105"
-(**) Option "xkb_layout" "us"

I don't agree that this is an issue in the udev layer; that looks like a plain evdev issue to me, since when the device is reopened it comes up with different features.

However, it may be enlightening to see a /var/log/udev and matching Xorg.0.log from the same boot capturing this issue. If nothing else it may point to a workaround. Clint, could you provide such logs?

The other thing I notice is that there's a separate touchpad device that's registered between the first and second detections of the keyboard:

[ 11.182] (II) config/udev: Adding input device bcm5974 (/dev/input/event8)
[ 11.182] (**) bcm5974: Applying InputClass "evdev touchpad catchall"
[ 11.182] (**) bcm5974: Applying InputClass "touchpad catchall"
[ 11.182] (II) LoadModule: "synaptics"
[ 11.182] (II) Loading /usr/lib/xorg/modules/input/synaptics_drv.so
[ 11.238] (II) Module synaptics: vendor="X.Org Foundation"
[ 11.238] compiled for 1.11.3, module version = 1.5.99
[ 11.238] Module class: X.Org XInput Driver
[ 11.238] ABI class: X.Org XInput driver, version 16.0
[ 11.238] (II) Using input driver 'synaptics' for 'bcm5974'
[ 11.238] (II) Loading /usr/lib/xorg/modules/input/synaptics_drv.so
[ 11.238] (**) bcm5974: always reports core events
[ 11.238] (**) Option "Device" "/dev/input/event8"
[ 11.357] (--) synaptics: bcm5974: x-axis range 0 - 1280
[ 11.357] (--) synaptics: bcm5974: y-axis range 0 - 800
[ 11.357] (--) synaptics: bcm5974: pressure range 0 - 256
[ 11.357] (--) synaptics: bcm5974: finger width range 0 - 16
[ 11.357] (--) synaptics: bcm5974: buttons: left double triple
[ 11.357] (--) synaptics: bcm5974: Vendor 0x5ac Product 0x249
[ 11.357] (--) synaptics: bcm5974: touchpad found
[ 11.357] (**) bcm5974: always reports core events
[ 11.364] (**) Option "config_info" "udev:/sys/devices/pci0000:00/0000:00:1a.7/usb1/1-1/1-1.2/1-1.2:1.2/input/input8/event8"
[ 11.364] (II) XINPUT: Adding extended input device "bcm5974" (type: TOUCHPAD, id 11)
[ 11.364] (**) synaptics: bcm5974: (accel) MinSpeed is now constant deceleration 2.5
[ 11.364] (**) synaptics: bcm5974: MaxSpeed is now 1.75
[ 11.364] (**) synaptics: bcm5974: AccelFactor is now 0.133
[ 11.364] (**) bcm5974: (accel) keeping acceleration scheme 1
[ 11.364] (**) bcm5974: (accel) acceleration profile 1
[ 11.364] (**) bcm5974: (accel) acceleration factor: 2.000
[ 11.364] (**) bcm5974: (accel) acceleration threshold: 4
[ 11.365] (--) synaptics: bcm5974: touchpad found
[ 11.365] (II) config/udev: Adding input device bcm5974 (/dev/input/mouse1)
[ 11.365] (**) bcm5974: Ignoring device from InputClass "touchpad ignore duplicates"

Here it's shown using the evdev driver rather than multitouch. But I guess something about the remove/re-add of the keyboard leaves the touchpad in an inconsistent state.

So it's either a kernel driver or an X driver issue... udev is just the messenger here, passing through the add/remove shown it by the kernel.

It's not really a separate touchpad, it's a /dev/input/mouseX device registered by the mousedev driver for the same touchpad, kind of a legacy mouse device for applications that need that sort of thing. It's there in the good and bad case, and X seems to be (correctly) ignoring it.

I think you may be onto something with the keyboard remove being related. I don't know what's going on, and I don't see it on my MBA 4,1, but dmesg does show usbhid devices disappearing and reappearing about 18 seconds after boot. Actually it looks like the usbhid module is unloaded and reloaded. If I rmmod then insmod usbhid on my machine my touchpad stops working until I restart X.

Status changed to 'Confirmed' because the bug affects multiple users.

Whatever the issue was it has been corrected in raring, my touchpad works properly now.

Clint Byrum, this bug report is being closed due to your last comment https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-synaptics/+bug/936552/comments/25 regarding this being fixed with an update. For future reference you can manage the status of your own bugs by clicking on the current status in the yellow line and then choosing a new status in the revealed drop down box. You can learn more about bug statuses at https://wiki.ubuntu.com/Bugs/Status. Thank you again for taking the time to report this bug and helping to make Ubuntu better. Please submit any future bugs you may find.