Ubuntu

bcm5974 touchpad doesn't work after S3 on MacBookAir

Reported by Seth Forshee on 2012-03-30
200
This bug affects 40 people
Affects Status Importance Assigned to Milestone
Xserver Xorg Input Synaptics
Fix Released
Medium
xorg-server (Ubuntu)
Medium
Unassigned
Quantal
Medium
Unassigned
xserver-xorg-input-synaptics (Ubuntu)
Medium
Unassigned

Bug Description

xorg-server SRU Justification
=============================
[Impact]
When a laptop is suspended, X disables the input devices. If X believes the hardware has a button press when the device is disabled, it will not release the button on resume and device enabling. With tap to click turned out, the volatile mix of the touchpad and the LCD screen on lid closure can cause this problem on suspend/resume.

[Development Fix]
A one-line patch from upstream has been added to xorg-server 1.11.4-0ubuntu11. The patch can be seen in the SRU debdiff. It simply releases the buttons when an input device is disabled.

[Stable Fix]
The same one-line patch for the development fix has been made to xorg-server 1.11.4-0ubuntu10.2. Please see the attached xorg-server SRU debdiff.

[Test Case]
Close and open the lid to perform a suspend resume cycle on a MacBook Air. Repeat multiple times. Note that there will be issues until an SRU for xserver-xorg-input-synaptics is available too.

[Regression Potential]
Very minimal. The one-line change releases the buttons when an input device is disabled. It is a trivial fix.

xserver-xorg-input-synaptics SRU Justification
==============================================
[Impact]
When a laptop is suspended, X disables the input devices. The entire state of the device needs to be reset when the device is disabled so that it works properly when re-enabled. Without this fix, the trackpad may do odd things like behave as though there are active touches that no longer exist. This can manifest as scrolling with one finger, no cursor motion, and right clicking instead of left clicking.

[Development Fix]
Upstream 1.6.0 has two patches that fix this specific issue, among other bug fixes. This has been uploaded to Quantal.

[Stable Fix]
The Quantal 1.6.0 update has been uploaded for Precise and is identical to the Quantal package other than the Precise SRU version. The only changes from the previous package to the 1.6.0 package are various bug fixes.

[Test Case]
Close and open the lid to perform a suspend resume cycle on a MacBook Air. Repeat multiple times. Ensure the trackpad continues to function properly.`

[Regression Potential]
Minimal. The fixes for this patch are small and well-contained. The fixes for other issues in the upstream 1.6.0 release are also small and well-contained.

Original Bug Report
===================
I started seeing this immediately after installing updates that included xserver-xorg-input-synaptics from 1.5.99.901-0ubuntu2 to 1.5.99.902-0ubuntu1 and rebooting.

When I initiate a suspend by closing the lid, after resuming the touchpad no longer works at all. I can see a stream of events by switching to a vt and running input events, and if I restart the display manager the touchpad starts working again. I do not see this issue if I initiate suspend from the menu, only when closing the lid.

ProblemType: Bug
DistroRelease: Ubuntu 12.04
Package: xserver-xorg-input-synaptics 1.5.99.902-0ubuntu1
ProcVersionSignature: Ubuntu 3.2.0-20.33-generic 3.2.12
Uname: Linux 3.2.0-20-generic x86_64
ApportVersion: 1.95-0ubuntu1
Architecture: amd64
Date: Thu Mar 29 23:01:23 2012
DistUpgraded: Fresh install
DistroCodename: precise
DistroVariant: ubuntu
EcryptfsInUse: Yes
InstallationMedia: Ubuntu 12.04 LTS "Precise Pangolin" - Alpha amd64+mac (20111208)
MachineType: Apple Inc. MacBookAir4,1
ProcEnviron:
 TERM=xterm
 SHELL=/bin/bash
 PATH=(custom, user)
 LANG=en_US.UTF-8
ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz root=UUID=f4af0efe-df4b-4d74-8995-7081cf79889c ro
SourcePackage: xserver-xorg-input-synaptics
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 10/14/2011
dmi.bios.vendor: Apple Inc.
dmi.bios.version: MBA41.88Z.0077.B0E.1110141154
dmi.board.asset.tag: Base Board Asset Tag#
dmi.board.name: Mac-C08A6BB70A942AC2
dmi.board.vendor: Apple Inc.
dmi.board.version: MacBookAir4,1
dmi.chassis.type: 10
dmi.chassis.vendor: Apple Inc.
dmi.chassis.version: Mac-C08A6BB70A942AC2
dmi.modalias: dmi:bvnAppleInc.:bvrMBA41.88Z.0077.B0E.1110141154:bd10/14/2011:svnAppleInc.:pnMacBookAir4,1:pvr1.0:rvnAppleInc.:rnMac-C08A6BB70A942AC2:rvrMacBookAir4,1:cvnAppleInc.:ct10:cvrMac-C08A6BB70A942AC2:
dmi.product.name: MacBookAir4,1
dmi.product.version: 1.0
dmi.sys.vendor: Apple Inc.
version.compiz: compiz 1:0.9.7.2-0ubuntu4
version.ia32-libs: ia32-libs N/A
version.libdrm2: libdrm2 2.4.32-1ubuntu1
version.libgl1-mesa-dri: libgl1-mesa-dri 8.0.2-0ubuntu2
version.libgl1-mesa-dri-experimental: libgl1-mesa-dri-experimental N/A
version.libgl1-mesa-glx: libgl1-mesa-glx 8.0.2-0ubuntu2
version.xserver-xorg-core: xserver-xorg-core 2:1.11.4-0ubuntu7
version.xserver-xorg-input-evdev: xserver-xorg-input-evdev 1:2.7.0-0ubuntu1
version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:6.14.99~git20111219.aacbd629-0ubuntu2
version.xserver-xorg-video-intel: xserver-xorg-video-intel 2:2.17.0-1ubuntu4
version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:0.0.16+git20111201+b5534a1-1build2

Seth Forshee (sforshee) wrote :
Seth Forshee (sforshee) wrote :

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

Launchpad Janitor (janitor) wrote :

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

Changed in xserver-xorg-input-synaptics (Ubuntu):
status: New → Confirmed
Sean McIntyre (s-mcintyre0) wrote :

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

Seth Forshee (sforshee) wrote :

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?

Chase Douglas (chasedouglas) wrote :

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.

Bryce Harrington (bryce) on 2012-04-05
summary: - bcm5974 touchpad doesn't work after S3
+ bcm5974 touchpad doesn't work after S3 on MacBookAir4,1
Bryce Harrington (bryce) on 2012-04-05
Changed in xserver-xorg-input-synaptics (Ubuntu):
importance: Undecided → High
status: Confirmed → Triaged
assignee: nobody → Chase Douglas (chasedouglas)

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.

Chase Douglas (chasedouglas) wrote :

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.

Changed in xserver-xorg-input-synaptics (Ubuntu):
assignee: Chase Douglas (chasedouglas) → nobody
Calum MacRae (phyrne) wrote :

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 :)

Luke Hoersten (lukehoersten) wrote :

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.

Eugene San (eugenesan) wrote :

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.

Reuben Thomas (rrt) wrote :

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?

Bryce Harrington (bryce) on 2012-04-11
summary: - bcm5974 touchpad doesn't work after S3 on MacBookAir4,1
+ bcm5974 touchpad doesn't work after S3 on MacBookAirX,X
summary: - bcm5974 touchpad doesn't work after S3 on MacBookAirX,X
+ bcm5974 touchpad doesn't work after S3 on MacBookAir
Gorka Navarrete (emrys) wrote :

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.

Daniel Nyström (speakman) wrote :

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

Chase Douglas (chasedouglas) wrote :

Hi Gorka,

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

Thanks!

Iain Lane (laney) wrote :

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.

tags: added: rls-p-tracking
Chase Douglas (chasedouglas) wrote :

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.

Martin Pitt (pitti) wrote :

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.

affects: xserver-xorg-input-synaptics (Ubuntu Precise) → pm-utils (Ubuntu Precise)
no longer affects: linux (Ubuntu Precise)

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.

Changed in linux (Ubuntu):
status: New → Confirmed
status: Confirmed → Incomplete
tags: added: kernel-request-3.2.0-23.36
Daniel Nyström (speakman) wrote :

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.

Seth Forshee (sforshee) wrote :

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.

tags: added: bot-stop-nagging
Changed in linux (Ubuntu):
status: Incomplete → Confirmed

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)

Seth Forshee (sforshee) wrote :

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.

Martin Pitt (pitti) wrote :

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

affects: linux (Ubuntu) → xserver-xorg-input-synaptics (Ubuntu)
Martin Pitt (pitti) wrote :

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.

no longer affects: pm-utils (Ubuntu)
no longer affects: pm-utils (Ubuntu Precise)

Same problem here on thinkpad edge 13

tsj (ts3141592) wrote :

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.

Daniel Nyström (speakman) wrote :

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!

tags: added: verification-needed
Changed in xserver-xorg-input-synaptics (Ubuntu):
status: Confirmed → Fix Committed
Daniel Nyström (speakman) wrote :

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.

tags: added: verification-failed
removed: verification-needed
Daniel Nyström (speakman) wrote :

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

Chase Douglas (chasedouglas) wrote :

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.

Daniel Nyström (speakman) wrote :

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

Daniel Nyström (speakman) wrote :

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

tags: added: verification-needed
removed: verification-failed
Iain Lane (laney) wrote :

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

Thanks very much for the proper fix!

tags: added: verification-done
removed: verification-needed
Seth Forshee (sforshee) wrote :

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

Robert Hooker (sarvatt) wrote :

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.

Chase Douglas (chasedouglas) wrote :

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.

tsj (ts3141592) wrote :

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

The MacBook hardware seems to trigger some input on the touchpad on lid close, before the suspend process has kicked in. This leaves the driver in an inconsistent state on resume, causing funky touchpad behaviour.

http://patchwork.freedesktop.org/patch/10055/ seems to mostly fix this, but apparently there's still some problem. Testers on the Launchpad bug report that the touchpad treats single-clicks as double-clicks after 3 of 20 resumes.

cf: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-synaptics/+bug/968845
cf: https://bugzilla.redhat.com/show_bug.cgi?id=814972

Iain Lane (laney) wrote :

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?

Seth Forshee (sforshee) wrote :

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.

Bradley Jones (bradjones) wrote :

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

Changed in xserver-xorg-input-synaptics:
importance: Unknown → Medium
status: Unknown → In Progress
Launchpad Janitor (janitor) wrote :

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

Changed in xserver-xorg-input-synaptics (Ubuntu):
status: Fix Committed → Fix Released
Changed in xserver-xorg-input-synaptics (Ubuntu):
importance: Undecided → Medium
Chase Douglas (chasedouglas) wrote :

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.

Changed in xserver-xorg-input-synaptics (Ubuntu):
status: Fix Released → In Progress
Changed in xorg-server (Ubuntu):
status: New → Triaged
Changed in xorg-server (Ubuntu Precise):
status: New → Triaged
Changed in xorg-server (Ubuntu):
importance: Undecided → Medium
Changed in xorg-server (Ubuntu Precise):
importance: Undecided → Medium
Launchpad Janitor (janitor) wrote :

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

Changed in xorg-server (Ubuntu):
status: Triaged → Fix Released
Chase Douglas (chasedouglas) wrote :
description: updated
Launchpad Janitor (janitor) wrote :

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

Changed in xserver-xorg-input-synaptics (Ubuntu):
status: In Progress → Fix Released
Steve Langasek (vorlon) on 2012-05-07
no longer affects: xorg-server (Ubuntu Precise)
description: updated

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!

tags: removed: verification-done
tags: added: verification-needed
Chris Halse Rogers (raof) wrote :

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!

Chris Halse Rogers (raof) wrote :

(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!)

Luke Hoersten (lukehoersten) wrote :

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?

Chase Douglas (chasedouglas) wrote :

Hi Luke,

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

Luke Hoersten (lukehoersten) wrote :

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.

Luke Hoersten (lukehoersten) wrote :

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.

Seth Forshee (sforshee) wrote :

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.

Chase Douglas (chasedouglas) wrote :

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.

Seth Forshee (sforshee) wrote :

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.

David Ryder (davidryderuk) wrote :

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

Steve Langasek (vorlon) wrote :

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.

tags: added: verification-failed
removed: verification-needed
Chase Douglas (chasedouglas) wrote :

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.

tags: added: verification-done
removed: verification-failed
Daniel Nyström (speakman) wrote :

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?

Daniel Nyström (speakman) wrote :

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.

(In reply to comment #2)
> Patches required:
>
> xserver:
> http://patchwork.freedesktop.org/patch/10116/

xorg-server-1.12.0-125-gf3410b9, though with some side-effects that need to be resolved separately

> synaptics:
> http://patchwork.freedesktop.org/patch/10117/
> http://patchwork.freedesktop.org/patch/10118/

in synaptics 1.6.0

Changed in xserver-xorg-input-synaptics:
status: In Progress → Fix Released
Luke Hoersten (lukehoersten) wrote :

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.

Eric Zig (zuric) wrote :

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

Bryce Harrington (bryce) on 2012-07-16
Changed in xserver-xorg-input-synaptics (Ubuntu Quantal):
status: Fix Released → In Progress
status: In Progress → Fix Released
Bryce Harrington (bryce) on 2012-07-16
no longer affects: xserver-xorg-input-synaptics (Ubuntu Quantal)
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.