This service will be undergoing maintenance at 00:00 UTC, 2016-09-28. It is expected to last about 1 hours
Bug 908604 - Apple Bluetooth "Magic" Trackpad - bad tap and scroll behavior
Apple Bluetooth "Magic" Trackpad - bad tap and scroll behavior
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
18
x86_64 Linux
unspecified Severity unspecified
: ---
: ---
Assigned To: Benjamin Tissoires
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-02-07 01:31 EST by Clarke Wixon
Modified: 2013-04-11 19:33 EDT (History)
13 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-04-11 19:33:28 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
Gnome Shell screencast showing bad scrolling behavior (4.10 MB, video/webm)
2013-02-07 01:31 EST, Clarke Wixon
no flags Details
evemu device description under 3.6.11-3.fc18.x86_64 (887 bytes, text/plain)
2013-03-27 06:25 EDT, Benjamin Tissoires
no flags Details
evemu events under 3.6.11-3.fc18.x86_64 (71.33 KB, text/plain)
2013-03-27 06:25 EDT, Benjamin Tissoires
no flags Details
same events but human readable under 3.6.11-3.fc18.x86_64 (157.63 KB, text/plain)
2013-03-27 06:27 EDT, Benjamin Tissoires
no flags Details
evemu device description under 3.7.9-201.fc18.x86_64 (887 bytes, text/plain)
2013-03-27 06:28 EDT, Benjamin Tissoires
no flags Details
evemu events under 3.7.9-201.fc18.x86_64 (75.49 KB, text/plain)
2013-03-27 06:28 EDT, Benjamin Tissoires
no flags Details
same events but human readable under 3.7.9-201.fc18.x86_64 (167.80 KB, text/plain)
2013-03-27 06:29 EDT, Benjamin Tissoires
no flags Details
attempted fix (2.51 KB, patch)
2013-03-27 13:58 EDT, Benjamin Tissoires
no flags Details | Diff
evemu-describe on Magic Trackpad, kernel 3.6.11 (875 bytes, application/octet-stream)
2013-03-28 01:05 EDT, Clarke Wixon
no flags Details
evemu-describe on Magic Trackpad, kernel 3.8.4 (875 bytes, application/octet-stream)
2013-03-28 01:05 EDT, Clarke Wixon
no flags Details
evemu-record on Magic Trackpad, kernel 3.6.11 (344.04 KB, application/octet-stream)
2013-03-28 01:07 EDT, Clarke Wixon
no flags Details
evemu-record on Magic Trackpad, kernel 3.8.4 (418.59 KB, application/octet-stream)
2013-03-28 01:07 EDT, Clarke Wixon
no flags Details

  None (edit)
Description Clarke Wixon 2013-02-07 01:31:28 EST
Created attachment 694253 [details]
Gnome Shell screencast showing bad scrolling behavior

Description of problem:

Under kernel 3.7 ONLY, the Apple Magic Trackpad seems to "miss" taps frequently and jumps around during scrolling.

Single-finger and two-finger tap gestures are often missed.  Such taps sometimes, maybe 10-30% of the time, do not trigger the desired action.  True button presses are caught, but taps are often not.

When two-finger scrolling, the scroll position jumps around. The jumping during scrolling looks as if it "misses" finger lifts between swipes. So if I scroll down with a two-finger swipe, then pick up my fingers and scroll down again, the cumulative result will be as if I only scrolled once. As soon as I put my fingers down the second time, the scroll position reverts back to where I started the first scroll -- it jumps right back to that spot, as though I instantaneously dragged my two fingers back to that spot, rather than lifting them and repositioning them for a second swipe.



Version-Release number of selected component (if applicable):

The problem only seems to occur with kernel 3.7.x -- I have tested 3.7.2, 3.7.4, and 3.7.5.  All of these exhibit the problem.

Downgrading the F18 kernel to 3.6.11-3 -- with no other changes -- causes the tapping and scrolling behavior to revert back to normal, with no problems.


Additional info:

There's nothing unusual in dmesg or Xorg.0.log suggesting a problem.

The trackpad pairs normally (using blueman, because pairing using the standard Gnome Shell Bluetooth applet is still problematic.)

Pointer motion works fine.  Perfectly smooth.  Actual button-presses (press-to-click on the trackpad) are captured accurately.

Observing trackpad events via synclient -m works fine -- the trackpad and synaptics driver ARE capturing all touch and lift events, as expected.  Some of them just aren't acted upon.

I started a thread on fedoraforum.org, and this bug is being experienced by others.  It is also apparently present in Arch Linux using the 3.7.4 kernel, so it may be an upstream issue.

Here's the thread: http://forums.fedoraforum.org/showthread.php?p=1628185

I personally have tested in Gnome Shell and LXDE, and the problem is evident in both desktop environments.  The Arch Linux user in the referenced fedoraforum.org thread uses KDE, and the problem exists there as well.
Comment 1 info@kobaltwit.be 2013-02-17 11:48:48 EST
I can confirm this erratic behaviour on KDE as well.
kernel 3.7.7-201.fc18

I have a worse experience on kde even than what the original poster describes. Other than all that is already described, I have experienced the complete desktop environment crashing by two-finger-clicking. A two-finger click is the magic pad's equivalent of clicking the right mouse button on an ordinary mouse. On such an ordinary mouse, I haven't been able to trigger this crash. With the magic trackpad, I managed to crash kde 3 times in 2 hours.

And just for clarity, with crash, I mean this: the screens goes black immediately after a two-finger click. After a couple of seconds gdm appears again, showing the login screen. I have checked all other virtual terminals, but there's no active session left. The old one is effectively gone.

I had to switch back to kernel 3.5.5 (fc17) for another bug, and noticed the problems with the magic trackpad are gone.
Comment 2 info@kobaltwit.be 2013-02-19 14:41:47 EST
There was an update to kernel 3.7.8-202. With this kernel it gets even worse. Any two-finger click immediately results in a kernel oops.

If desired I can attach a picture of the last lines still on screen.
Comment 3 Marciano Siniscalchi 2013-03-20 10:22:30 EDT
I can confirm this erratic behavior on FC18/Gnome Shell and kernel 3.8.3-203 (updated today, 3/20/13). Tap-to-click sometimes doesn't work, and most importantly scrolling behavior is as described in the OP.
Comment 4 Benjamin Tissoires 2013-03-25 05:30:18 EDT
There has been updates in the input subsystem between 3.6 and 3.7. They should not impact drivers like hid-magicmouse.

I'll need the output of evemu-record both in 3.6 and 3.7 (or 3.8). Please record each gesture in a separate file. I need to replay those locally to check what is broken.
I also need the evemu-describe output. Thanks
Comment 5 Clarke Wixon 2013-03-27 01:10:13 EDT
Benjamin, thanks.  I have some files to upload, but bugzilla is giving me some mysql errors when I try to attach them.  I'll try again later or tomorrow.

The evemu-describe files were no problem to generate, of course.

With regard to evemu-record, I don't think I can very easily give you "each gesture in a separate file" per your request, unless I make a lot of files, only a few of which might exhibit the problem.

The bad behavior is intermittent, and only SOME scroll-lifts and SOME taps are missed.  Because I have to run evemu-record in a text VT, I won't know whether the bad behavior is occurring or not if I record a single gesture.

What I HAVE done so far is make two evemu-record files, one under 3.6.11 (where the trackpad works as expected) and one under 3.8.4 (which exhibits the problem described in my original post).  Each one includes ten two-finger swipes down (as if scrolling), followed by ten single-finger taps in various locations around the pad, followed by ten two-finger swipes up (scrolling again).

For the record, the two kernel versions I have installed on my system are 3.6.11-3.fc18.x86_64 and 3.8.4-202.fc18.x86_64.

Will the files I have generated be helpful, or would you prefer a different approach?  I can make a bunch of separate files if that would be better.
Comment 6 Benjamin Tissoires 2013-03-27 04:14:07 EDT
Clarke, I think providing the 2 files in their current state is good. As long as I know which events sequence you did during the recording. 
On my side, I'll try to figure out the bogus taps and scrolls.

Anyway, for the scrolls, I managed to get my hand on a magic trackpad yesterday and to reproduce your bug. I also managed to get low level traces (before the kernel processing) so I'll be able to test the very same events under 3.6 and 3.7.

Your files will confirm the tests I'm going to conduct, so please upload them too.
Comment 7 Benjamin Tissoires 2013-03-27 06:25:07 EDT
Created attachment 716996 [details]
evemu device description under 3.6.11-3.fc18.x86_64
Comment 8 Benjamin Tissoires 2013-03-27 06:25:42 EDT
Created attachment 716997 [details]
evemu events under 3.6.11-3.fc18.x86_64
Comment 9 Benjamin Tissoires 2013-03-27 06:27:19 EDT
Created attachment 716998 [details]
same events but human readable under 3.6.11-3.fc18.x86_64
Comment 10 Benjamin Tissoires 2013-03-27 06:28:19 EDT
Created attachment 716999 [details]
evemu device description under 3.7.9-201.fc18.x86_64

same as under 3.6.11-3
Comment 11 Benjamin Tissoires 2013-03-27 06:28:54 EDT
Created attachment 717000 [details]
evemu events under 3.7.9-201.fc18.x86_64
Comment 12 Benjamin Tissoires 2013-03-27 06:29:43 EDT
Created attachment 717001 [details]
same events but human readable under 3.7.9-201.fc18.x86_64
Comment 13 Benjamin Tissoires 2013-03-27 06:32:40 EDT
For the records, I put the outputs I get from the 3.6 and 3.7.
There is obviously a problem when scrolling with two fingers. The BTN_TOUCH events are sometimes missing, leading to an unknown state in xf86-input-synaptics.
Comment 14 Benjamin Tissoires 2013-03-27 13:58:43 EDT
Created attachment 717194 [details]
attempted fix

I figure out that the problem was from a race between input_register() and
probe().
My previous analysis was wrong: my own scripts masked the fact that I did not received the correct sync event.

I've started a scratch build here for you to test:
http://koji.fedoraproject.org/koji/taskinfo?taskID=5181953
Comment 15 Clarke Wixon 2013-03-28 01:05:01 EDT
Created attachment 717426 [details]
evemu-describe on Magic Trackpad, kernel 3.6.11
Comment 16 Clarke Wixon 2013-03-28 01:05:41 EDT
Created attachment 717427 [details]
evemu-describe on Magic Trackpad, kernel 3.8.4
Comment 17 Clarke Wixon 2013-03-28 01:07:00 EDT
Created attachment 717428 [details]
evemu-record on Magic Trackpad, kernel 3.6.11

Sequence of gestures described in comment 5
Comment 18 Clarke Wixon 2013-03-28 01:07:43 EDT
Created attachment 717429 [details]
evemu-record on Magic Trackpad, kernel 3.8.4

Sequence of gestures described in comment 5
Comment 19 Clarke Wixon 2013-03-28 02:21:06 EDT
I uploaded my files, as described in comment 5 -- but if you think you have a fix, they're primarily for confirmation and for historical interest at this point, I suppose.

Unfortunately, I can't currently test the proposed fix because the kernel from the koji link in comment 14 won't boot all the way to the desktop.  I get the plymouth animation, with the white fedora logo filling up then changing to the "f", but that's all I get.  No gdm.

In /var/log/messages I see a bunch of gdm errors.

If I boot with the splash disabled (without "rhgb quiet"), I can switch to another VT and login, but not with plymouth in the way.
Comment 20 Benjamin Tissoires 2013-03-28 05:12:11 EDT
Thanks for the logs, they confirm my theory, and sorry for the kernel that doesn't boot.

I set up a repo on github for you to test the patch.
just run:
$ git clone https://github.com/bentiss/hid-magicmouse.git
$ cd hid-magicmouse
$ make
$ sudo make test

if it's working, then you can do a permanent install for your current kernel with
$ sudo make install

thanks for the feedbacks
Comment 21 Clarke Wixon 2013-03-29 15:50:46 EDT
Ah, much better, thanks!

The driver built without a hitch, and I am seeing a GREAT improvement.  No missed taps or gestures at all so far, on the standard 3.8.4 x86_64 kernel from the F18 repository with this module loaded.

I would call this a good fix.

Thanks again for your work on this.
Comment 22 Daniel Sjoholm 2013-03-31 10:58:44 EDT
Pitching in to say that this seems to solve it for me too, thanks!
Comment 23 Benjamin Tissoires 2013-04-04 11:41:26 EDT
Quick update:

the patch has been accepted upstream and should be scheduled for 3.9 (the pull request has been done):
https://git.kernel.org/cgit/linux/kernel/git/jikos/hid.git/commit/?h=for-3.9/upstream-fixes&id=f1a9a149abc86903e81dd1b2e720f3f89874384b
Comment 24 Josh Boyer 2013-04-08 09:28:02 EDT
Added the patch today.  Will be in the next update.  Thanks Benjamin!
Comment 25 Fedora Update System 2013-04-09 18:16:23 EDT
kernel-3.8.6-203.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/kernel-3.8.6-203.fc18
Comment 26 Fedora Update System 2013-04-11 06:10:57 EDT
Package kernel-3.8.6-203.fc18:
* should fix your issue,
* was pushed to the Fedora 18 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing kernel-3.8.6-203.fc18'
as soon as you are able to, then reboot.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-5368/kernel-3.8.6-203.fc18
then log in and leave karma (feedback).
Comment 27 Fedora Update System 2013-04-11 19:33:30 EDT
kernel-3.8.6-203.fc18 has been pushed to the Fedora 18 stable repository.  If problems still persist, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.