Red Hat Bugzilla – Bug 908604
Apple Bluetooth "Magic" Trackpad - bad tap and scroll behavior
Last modified: 2013-04-11 19:33:30 EDT
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.
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.
I can confirm this erratic behaviour on KDE as well.
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.
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.
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.
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
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.
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.
Created attachment 716996 [details]
evemu device description under 3.6.11-3.fc18.x86_64
Created attachment 716997 [details]
evemu events under 3.6.11-3.fc18.x86_64
Created attachment 716998 [details]
same events but human readable under 3.6.11-3.fc18.x86_64
Created attachment 716999 [details]
evemu device description under 3.7.9-201.fc18.x86_64
same as under 3.6.11-3
Created attachment 717000 [details]
evemu events under 3.7.9-201.fc18.x86_64
Created attachment 717001 [details]
same events but human readable under 3.7.9-201.fc18.x86_64
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.
Created attachment 717194 [details]
I figure out that the problem was from a race between input_register() and
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:
Created attachment 717426 [details]
evemu-describe on Magic Trackpad, kernel 3.6.11
Created attachment 717427 [details]
evemu-describe on Magic Trackpad, kernel 3.8.4
Created attachment 717428 [details]
evemu-record on Magic Trackpad, kernel 3.6.11
Sequence of gestures described in comment 5
Created attachment 717429 [details]
evemu-record on Magic Trackpad, kernel 3.8.4
Sequence of gestures described in comment 5
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.
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.
$ git clone https://github.com/bentiss/hid-magicmouse.git
$ cd hid-magicmouse
$ 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
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.
Pitching in to say that this seems to solve it for me too, thanks!
the patch has been accepted upstream and should be scheduled for 3.9 (the pull request has been done):
Added the patch today. Will be in the next update. Thanks Benjamin!
kernel-3.8.6-203.fc18 has been submitted as an update for Fedora 18.
* 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:
then log in and leave karma (feedback).
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.