bcm5974 touchpad doesn't work after S3 on MacBookAir

Attaching xsession-errors from from a session with a non-functioning touchpad. There are a lot of warnings and some errors.

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

Confirmed on 11" Macbook Air after Beta 2 update a few hours ago. Tried it several times, inspecting xsession-errors each time. Frequently I received "GRAIL WARNING (v3/slice.cpp:GetValues:230): failed to get touch from frame" messages as described in Seth's xsession-errors. On certain occassions, the touchpad would partially function after resume (i.e. able to move the cursor, but only while depressing the mousepad). I have attached my xsession-errors for this second case (partial functionality).

This issue was discussed on irc the other day, and I'm going to attempt to summarize the findings here.

The MBA has a magnet near the camera, and as the lid is closed this magnet induces touchpad activity. The resulting stream of input events from the driver show the start of a multitouch sequence that never completes. xf86-input-synaptics is left in a bad state, waiting for the completion of the multitouch sequence. There's also a possibility that the events will result in unintended actions being performed on the destkop (I've noticed from time to time that the dash is exposed after resume when it wasn't at the time the lid was closed, which may be evidence of this).

The proposed fix is for xf86-input-synaptics to listen for the input event that indicates the lid has been closed and to stop listening to internal input devices at that time. There's still a chance that events caused by the magnet will be received before the lid-close event when the lid is closed very quickly, but that seems to be unavoidable.

xf86-input-synaptics may also need to reset its internal state after the lid is opened to ensure that it's not left waiting for events it's never going to receive.

Chase, does this correspond to your takeaway from the discussion?

I don't think asking xf86-input-synaptics to listen to unrelated events is a good idea. However, there is functionality already present in synaptics that we may be able to use: the "Synaptics Off" option. Syndaemon already uses this to disable the trackpad when the user is typing on the keyboard. We could add functionality to syndaemon to listen for lid closure as well.

This affects me as well. MacBookPro 5,2.

The mouse cursor is still visible, and I can right-click and get a
context menu, but I am unable to move the mouse cursor around my screen.

This is something that requires some physical testing to ensure it gets done right. Unfortunately, my Macbook 5,1 laptop won't resume from suspend, so I can't really develop a fix for this. I'm unassigning myself.

A workaround is to unload and reload the bcm5974 kernel module:

$ sudo rmmod bcm5974
$ sudo modprobe bcm5974

This will reset the state of synaptics.

As Chase Douglas said, reloading the usbhid module will get it working.

You can put this into a script to be called by pm-utils. I've provided the instructions on how to do so in this Ubuntu Forums thread:

http://ubuntuforums.org/showthread.php?t=1952532

You'll just need to edit the script so it reloads the right module, so; replace 'usbhid' with 'bcm5974' or whatever module you're using for the trackpad :)

I have this same problem on my Macbook Air 3,1 and would be more than willing to help with testing/debugging. Probably the easiest way is to apply patches to a PPA and let the community test.

As temporary workaround I recommend using next:
$ echo 'SUSPEND_MODULES="bcm5974"' | sudo tee /etc/pm/config.d/mba4,x-touchpad

Also randomly happens on my Thinkpad.

The workaround works nicely to ensure that the touchpad always functions, but it seems to result in the touchpad being reset so that, for example, gestures don't emulate mouse clicks, even though I have them set to; I have to unset and reset the preference in System Settings to recover the functionality.

Is there some way to reapply settings on resume to fix this?

Same here, but with a particularity I have not seen above. If you click (not tapping but pressing) and while holding, move the finger, the cursor moves.

If you change session (to a different user), the cursor works fine again. If you come back to the original user, the problem reappears.

@Gorka: That's the exact behavior here as well. Just forgot to mention.

Hi Gorka,

The cursor moving while the trackpad "button" is pressed is expected behavior. It allows for operations like click + drag.

Thanks!

Do we have any chance of seeing this fixed in Precise? It's not really great to break suspend for these users. Can the package (what package is it?) ship a pm-config.d snippet for the SUSPEND_MODULES workaround to at least make the situation tenable? We could release note the fact that it's just an imperfect workaround in that options are reset.

The root cause is the hardware itself. The work around of adding a SUSPEND_MODULES config file to /etc/pm/config.d should fix the issue for broken input after resume.

The next question is: what package should this go into? I would suggest pm-utils since it already has video quirks.

Yes, I think a pm-utils snippet is a good enough hack for precise and an SRU, provided that (1) it has been verified that un/reloading the module does not introduce more problems than it solves (there were modules which caused kernel oopses on unloading, or freezes of X or other processe), and (2) there is an upstream kernel bug so that this can eventually be fixed properly.

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 dist-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.

I will as well test as soon as I get home to my MBA. But could this be a kernel bug really? IIRC it work correctly if you log out and then in as another user. I will confirm this also as soon as I get home.

Martin: I'm not sure the workaround belongs in the kernel. I'll shoot an email to the upstream developers, but a "disable touchpad when the lid is closed" policy sounds more like the type of thing that would normally be implemented in userspace.

Hello Seth,

Seth Forshee [2012-04-19 19:01 -0000]:
> Martin: I'm not sure the workaround belongs in the kernel.

Indeed not, sorry if I said that in a confusing way. The workaround
(unload the module during suspend) belongs into pm-utils.

The kernel part is that the module should be fixed to deal properly
with suspend, as pretty much all drivers do. I. e. to make the
workaround unnecessary again some day.

Martin
--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)

Hi Martin,

I think you misunderstand the problem. The driver does suspend/resume properly. The issue is that some component in the lid is inducing touchpad activity as it closes. This causes events to be sent to userspace, which result in stray click and also confuse xf86-input-synaptics. These happen *before* the kernel starts freezing tasks and suspending devices.

To emphasize: the touchpad and driver themselves do work after S3. If you restart X without reloading the driver everything works just fine.

As I understand it, the pm-utils workaround is really just a short-term band-aid solution. The better solution that's been proposed is to somehow tell xf86-input-synaptics to stop listening to the touchpad when the lid is closed.

Seth, thanks for the explanation. Reassigning back to x-x-i-s then.

As there was a question on IRC: I really meant to say that for precise it is okay to have a pm-utils *script* workaround, not that it actually needs to live in the pm-utils package. It is equally fine to ship it in x-x-i-s if people prefer. On second thought that actually makes more sense, as the workaround can be removed at the same time when the real fix comes in.

Same problem here on thinkpad edge 13

Same issue on 4,1 macbook air (11'' 2011) with up-to-date 12.04 installed from one of the daily builds. I haven't installed any touchpad-related packages so the issue occurs with whatever module comes by default.

Are someone up to a patch for this? Or should I create one using the script from Ubuntu Forums?

Hello Seth, or anyone else affected,

Accepted xserver-xorg-input-synaptics into precise-proposed. The package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

Just tried the new proposed update. The cursor now moves after S3 but it's also trying to scroll while moving the cursor. The rmmod/modprobe trick get rid of that problem. I've got two-finger-scroll enabled.

Did a few tests again and now it works. Not sure how to interpret this. I guess I just keep testing for a while and if it keep working I'll just forget about those first tests...

Hi Daniel,

After you upgraded, did you log out and back in, or restart your computer? The changes would not take effect until you restarted the X server. That would explain why it didn't fix things at first, and now it is fixed.

Yes, I did a full reboot just to be sure. Very weird. I'll keep testing...

Ok, yet another suspend and touchpad works perfectly. Changed back to verification-needed and hope for other folks to test it out.

Removed SUSPEND_MODULES hack, installed, rebooted and verified that it all works correctly.

Thanks very much for the proper fix!

I've been having good luck with the proposed fix as well.

3 out of 20 S3's failed here, it was stuck double clicking with a single click until removing/reloading bcm5974 when it fails. definitely better than it was.

For those of us who hit this issue and are proficient programmers (sarvatt, sforshee, laney, hint hint :), I suggest adding some debug statements inside the src/eventcomm.c touch handling functions to see exactly what is going on. The patch that RAOF added for this bug resets the touch state when the device is re-enabled, which I think happens on resume, so something is likely going wrong after that. Logging touch count changes would be a good first start, since the touch count determines whether the left or right clicks are emitted, and whether the cursor is moved or two-touch scrolling occurs.

Trying to install using with "sudo apt-get install xserver-xorg-input-synaptics/precise-proposed" but am getting error "E: Release 'precise-proposed' for 'xserver-xorg-input-synaptics' was not found."

I'd be happy to test the fix so any advice on how to actually install it from precise-proposed will be welcome. As you can probably tell I'm fairly new to this so more detail rather than less will be appreciated. Cheers

I've indeed now seen this failure mode too. I'll try and get some time over the next days to do some debugging.

My first thought is that the patch resets the state on suspend (when the device is disabled). Perhaps there is a similar interaction when the lid is opened and the device reenabled.

Is there an upstream bug for this?

Chase: I added the debug statements as you suggested. When I'm getting the incorrect behavior the number of touches seen by x-x-i-s is still correct.

Whether I get a left- or right-click behavior when I push down on the clickpad definitely seems to correspond to where my finger is on the touchpad. When it's near the bottom I get a left click, near the middle or top a right click. Horizontal position doesn't seem to matter.

I also have this problem though when it wakes from sleep all of the multitouch gestures still work fine. It is almost as if when awaking from sleep the touchpad is in a constant state of being pressed

This bug was fixed in the package xserver-xorg-input-synaptics - 1.5.99.902-0ubuntu5.1

---------------
xserver-xorg-input-synaptics (1.5.99.902-0ubuntu5.1) precise-proposed; urgency=low

  * debian/patches/204_monotonicise_hw_timestamp.patch:
    - Cherry-pick patch from upstream to ensure the timestamps used when
      determining velocities are monotonic. In certain circumstances the
      timestamps from hardware events can be less than the timestamps
      from the preceeding artificially-generated events.
      + Fixes occasional huge jumps in pointer position.
      + Fixes two-finger scrolling in GTK+3 windows (such as Nautilus and
        Evolution) failing some time after login. (LP: #982771)
  * debian/patches/205_end_touches_on_disable.patch:
    - Upstream patch to reset touch state on device disable.
      + Fixes touchpad not working after suspend on some MacBook models
        (LP: #968845)
 -- Christopher James Halse Rogers <email address hidden> Tue, 24 Apr 2012 14:32:49 +1000

This bug was partially fixed in xserver-xorg-input-synaptics 1.5.99.902-0ubuntu5.1. Most suspend/resume cycles will complete successfully now. However, about 10-20% of the time the trackpad will stop working properly. There are two more patches for xserver-xorg-input-synaptics and one for xorg-server to fully resolve this issue. These are noted in comment #46.

This bug was fixed in the package xorg-server - 2:1.11.4-0ubuntu11

---------------
xorg-server (2:1.11.4-0ubuntu11) quantal; urgency=low

  * Release buttons when device is disabled on suspend (LP: #968845)
    - Add temporary patch 508_device_off_release_buttons.patch from upstream
 -- Chase Douglas <email address hidden> Sat, 05 May 2012 13:17:34 -0700

This bug was fixed in the package xserver-xorg-input-synaptics - 1.6.0-0ubuntu1

---------------
xserver-xorg-input-synaptics (1.6.0-0ubuntu1) quantal; urgency=low

  * Update to upstream version 1.6.0
    - Bug fixes only
    - Fully fixes touchpad bugs on suspend/resume (LP: #968845)
  * Drop patches merged upstream
    - 200_fix_four_tap.patch
    - 201_fix_touch_count.patch
    - 202_touch_record_bounds_check.patch
    - 203_fix_coasting_speed.patch
    - 204_monotonicise_hw_timestamp.patch
    - 205_end_touches_on_disable.patch
  * Refreshed 130_dont_enable_rightbutton_area.patch
 -- Chase Douglas <email address hidden> Mon, 07 May 2012 12:22:23 -0700

Hello Seth, or anyone else affected,

Accepted xorg-server into precise-proposed. The package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

Hello Seth, or anyone else affected,

Accepted xserver-xorg-input-synaptics into precise-proposed. The package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

(SRU Note: due to a launchpad bug it's not possible to add a Precise task to -synaptics. The current state would be fix-committed!)

I updated to the latest proposed xserver-xorg-input-synaptics and still have the "single-click interpreted as double-click" problem. So this does not work for me. Is it working for anyone else?

Hi Luke,

Did you log out or restart after installing the updates? The updates do not take effect until the X server is restarted.

Chase, I did both to confirm. The test I use is the network manager's "connect to hidden network" and then the dropdown to select previously connected to hidden networks. First boot it works just fine with clicking the trackpad as well as tapping. After suspend, clicking always acts as a double click (effectively opening and closing the dropdown very quickly) and tapping works just fine. So at least for me, the problem seems to be isolated to clicking on the trackpad.

I'm sorry I had that backwards: I "connect to hidden wireless networks" after suspend and clicking works but tapping on the trackpad is like double-clicking. Sorry for the confusion.

The latest precise-propsed packages are an improvement. I'm no longer seeing single clicks behaving like double-clicks after initiating S3 by closing the lid. I am however seeing the following behavior: If I depress the clickpad with one finger and tap a second finger at other various locations on the touchpad, the pointer will jump large distances. I'm only getting this after an S3 initiated by closing the lid, not 100% of the time but most of the time.

I'm not normally a user of tap-to-click on this machine, but I've confirmed that I can reproduce the behavior described by Luke, whereby a single tap behaves like a double tap.

Hi Seth, Luke,

I have another fix for when a touch is active and the device is disabled. I have uploaded it to ppa:chasedouglas/jupiter. Please install it and retest to see if it fixes your issues.

Chase: I no longer see the double clicks when using tap-to-click, but I can still reproduce the pointer jumps as described in comment #59.

Hi,
I have a Macbook 7,1 with a similar trackpad to the above mentioned Macbook Air.

My trackpad uses the bcm5974 module, and in the original release of Ubuntu 12.04, my trackpad stopped working after suspending my computer.

I've recently been looking at the Xorg.conf file and noticed that after waking up my computer, Xorg.conf is full of error messages, so much so that after running my computer for 7 hours I have a 48 MB Xorg log file. I would be greatful if someone could tell me what these logs mean, since they seem to be due to the same bug.

In particular:

[ 16185.772] [dix] bcm5974: unable to find touch point 0
[ 16186.895] [dix] bcm5974: unable to find touch point 0
[ 16211.099] BUG: triggered 'if (!(event->device_event.flags & (1 << 5)))'
BUG: ../../dix/touch.c:642 in TouchConvertToPointerEvent()
[ 16211.100] Non-emulating touch event
[ 16211.100]
Backtrace:
[ 16211.116] 0: /usr/bin/X (xorg_backtrace+0x26) [0x7f349cc25866]
[ 16211.116] 1: /usr/bin/X (0x7f349ca9d000+0x76671) [0x7f349cb13671]
[ 16211.116] 2: /usr/bin/X (0x7f349ca9d000+0x11c29b) [0x7f349cbb929b]
[ 16211.116] 3: /usr/bin/X (0x7f349ca9d000+0x11bc35) [0x7f349cbb8c35]
[ 16211.116] 4: /usr/bin/X (0x7f349ca9d000+0x11efb3) [0x7f349cbbbfb3]
[ 16211.116] 5: /usr/bin/X (0x7f349ca9d000+0x14256a) [0x7f349cbdf56a]
[ 16211.116] 6: /usr/bin/X (mieqProcessDeviceEvent+0x204) [0x7f349cc063b4]
[ 16211.116] 7: /usr/bin/X (mieqProcessInputEvents+0x84) [0x7f349cc06444]
[ 16211.116] 8: /usr/bin/X (ProcessInputEvents+0x9) [0x7f349cb27e89]
[ 16211.116] 9: /usr/bin/X (0x7f349ca9d000+0x4e4e3) [0x7f349caeb4e3]
[ 16211.116] 10: /usr/bin/X (0x7f349ca9d000+0x3d6aa) [0x7f349cada6aa]
[ 16211.116] 11: /lib/x86_64-linux-gnu/libc.so.6 (__libc_start_main+0xed) [0x7f349ac5876d]
[ 16211.116] 12: /usr/bin/X (0x7f349ca9d000+0x3d99d) [0x7f349cada99d]
[ 16211.116] BUG: triggered 'if (!(event->device_event.flags & (1 << 5)))'
BUG: ../../dix/touch.c:642 in TouchConvertToPointerEvent()
[ 16211.116] Non-emulating touch event

Based on comment #59, I'm marking this SRU verification-failed. Chase, if you think this is worth publishing as-is, feel free to change it from verification-failed to verification-done instead.

Hi Steve,

There's actually a couple more fixes for the remainder of the issues. Since this package resolves some of the issues, I think we should accept it into precise-updates. Then we can create a new bug to track the remaining issues.

Yesterday I finally had time to test what's currently in precise-proposed, but now the two-finger-scroll is almost unusable. The same gesture both scroll up and down in Google Chrome. Sometimes it's extremely sensitive too, which makes it hard just figuring whether it's scrolling up or down.

I remember installing stuff during the Precise Beta period to enable touch gestures - are there any packages to look out for which might be causing this irregular behaviour?

Today scrolling works better (I havn't touched apt/dpkg since yesterday). But sometimes it triggers a press on the Alt button and shows the HUD. Quickly scrolling up and down continuously confirms the bug. It shows and hide the HUD and sometimes enter the menus. You can see the underlines indicating the menu item shortcut flicker while scrolling.

Note that this doesn't happen all the time. It's as intermittent as the bug described in #65.

I'm still having issues where after opening my screen, the touch pad detects single clicks as some kind of "move window with handles" event. This is certainly not fixed.

For me, now the touchpad work after S3 made by menu but it doesn't still work when I close my MBA.