Bug 14345 - 2.6.31.2 regression from 2.6.31, appletouch input, mouse doesn't move
2.6.31.2 regression from 2.6.31, appletouch input, mouse doesn't move
Status: CLOSED UNREPRODUCIBLE
Product: Drivers
Classification: Unclassified
Component: Input Devices
All Linux
: P1 normal
Assigned To: drivers_input-devices
:
Depends on:
Blocks: 14230
  Show dependency treegraph
 
Reported: 2009-10-07 21:32 UTC by Jeremy Huddleston
Modified: 2009-10-08 20:03 UTC (History)
2 users (show)

See Also:
Kernel Version: 2.6.31.2
Tree: Mainline
Regression: Yes


Attachments

Description Jeremy Huddleston 2009-10-07 21:32:45 UTC
Using gpm and X11, the mouse cursor remains in the same location as I scrub across the trackpad.  Connecting an external mouse works fine.

I don't see much activity in the input drivers from 2.6.31 to 2.6.31.2, so I'm at a bit of a loss where to start debugging.
Comment 1 Andrew Morton 2009-10-07 21:48:48 UTC
(switched to email.  Please respond via emailed reply-to-all, not via the
bugzilla web interface).

On Wed, 7 Oct 2009 21:32:46 GMT
bugzilla-daemon@bugzilla.kernel.org wrote:

> http://bugzilla.kernel.org/show_bug.cgi?id=14345
> 
>            Summary: 2.6.31.2 regression from 2.6.31, appletouch input,
>                     mouse doesn't move
>            Product: Drivers
>            Version: 2.5
>     Kernel Version: 2.6.31.2
>           Platform: All
>         OS/Version: Linux
>               Tree: Mainline
>             Status: NEW
>           Severity: normal
>           Priority: P1
>          Component: Input Devices
>         AssignedTo: drivers_input-devices@kernel-bugs.osdl.org
>         ReportedBy: jeremyhu@freedesktop.org
>         Regression: Yes
> 
> 
> Using gpm and X11, the mouse cursor remains in the same location as I scrub
> across the trackpad.  Connecting an external mouse works fine.
> 
> I don't see much activity in the input drivers from 2.6.31 to 2.6.31.2, so I'm
> at a bit of a loss where to start debugging.
> 

hm, that's bad: a 2.6.31 -> 2.6.31.2 regression.

Does this:

commit 1dbd009c9078b3491299722a9c0f1313fad0fc1b
Author: Jan Scholz <Scholz@fias.uni-frankfurt.de>
Date:   Wed Aug 26 13:18:51 2009 +0200

    HID: completely remove apple mightymouse from blacklist
    
    commit 42960a13001aa6df52ca9952ce996f94a744ea65 upstream.
    
    Commit fa047e4f6fa63a6e9d0ae4d7749538830d14a343 "HID: fix inverted
    wheel for bluetooth version of apple mighty mouse" is incomplete. If
    we remove Apple MightyMouse (bluetooth version) from the list of
    apple_devices in drivers/hid/hid-apple.c we have to remove it from
    hid_blacklist in drivers/hid/hid-core.c as well.

affect appletouch?
Comment 2 Dmitry Torokhov 2009-10-07 21:58:16 UTC
Shouldn't... Is appletouch detected at all (dmesg, /proc/bus/input/devices)? Did we touch USB in 2.6.31.2 at all?
Comment 3 Dmitry Torokhov 2009-10-07 22:16:32 UTC
On Wed, Oct 07, 2009 at 02:48:45PM -0700, Andrew Morton wrote:
> 
> (switched to email.  Please respond via emailed reply-to-all, not via the
> bugzilla web interface).
> 
> On Wed, 7 Oct 2009 21:32:46 GMT
> bugzilla-daemon@bugzilla.kernel.org wrote:
> 
> > http://bugzilla.kernel.org/show_bug.cgi?id=14345
> > 
> >            Summary: 2.6.31.2 regression from 2.6.31, appletouch input,
> >                     mouse doesn't move
> >            Product: Drivers
> >            Version: 2.5
> >     Kernel Version: 2.6.31.2
> >           Platform: All
> >         OS/Version: Linux
> >               Tree: Mainline
> >             Status: NEW
> >           Severity: normal
> >           Priority: P1
> >          Component: Input Devices
> >         AssignedTo: drivers_input-devices@kernel-bugs.osdl.org
> >         ReportedBy: jeremyhu@freedesktop.org
> >         Regression: Yes
> > 
> > 
> > Using gpm and X11, the mouse cursor remains in the same location as I scrub
> > across the trackpad.  Connecting an external mouse works fine.
> > 
> > I don't see much activity in the input drivers from 2.6.31 to 2.6.31.2, so I'm
> > at a bit of a loss where to start debugging.
> > 
> 
> hm, that's bad: a 2.6.31 -> 2.6.31.2 regression.
> 
> Does this:
> 
> commit 1dbd009c9078b3491299722a9c0f1313fad0fc1b
> Author: Jan Scholz <Scholz@fias.uni-frankfurt.de>
> Date:   Wed Aug 26 13:18:51 2009 +0200
> 
>     HID: completely remove apple mightymouse from blacklist
>     
>     commit 42960a13001aa6df52ca9952ce996f94a744ea65 upstream.
>     
>     Commit fa047e4f6fa63a6e9d0ae4d7749538830d14a343 "HID: fix inverted
>     wheel for bluetooth version of apple mighty mouse" is incomplete. If
>     we remove Apple MightyMouse (bluetooth version) from the list of
>     apple_devices in drivers/hid/hid-apple.c we have to remove it from
>     hid_blacklist in drivers/hid/hid-core.c as well.
> 
> affect appletouch?
> 

It shouldn't... Is appletouch detected at all (dmesg,
/proc/bus/input/devices)? It looks like there was a change affecting USB
core, could you try reverting 59664c0bdadb460086399375a3203fd08feb6abf ?
Comment 4 Jeremy Huddleston 2009-10-07 22:52:43 UTC
$ cat /proc/bus/input/devices
I: Bus=0017 Vendor=0001 Product=0001 Version=0100
N: Name="Macintosh mouse button emulation"
P: Phys=
S: Sysfs=/devices/virtual/input/input0
U: Uniq=
H: Handlers=mouse0 event0 
B: EV=7
B: KEY=70000 0 0 0 0 0 0 0 0
B: REL=3

I: Bus=0019 Vendor=0001 Product=0001 Version=0100
N: Name="PMU"
P: Phys=
S: Sysfs=/devices/virtual/input/input1
U: Uniq=
H: Handlers=kbd event1 
B: EV=23
B: KEY=100000 0 0 0
B: SW=1

I: Bus=0003 Vendor=05ac Product=020e Version=0110
N: Name="Apple Computer Apple Internal Keyboard/Trackpad"
P: Phys=usb-0001:10:1a.0-2/input0
S: Sysfs=/devices/pci0001:10/0001:10:1a.0/usb2/2-2/2-2:1.0/input/input4
U: Uniq=
H: Handlers=kbd event2 
B: EV=120013
B: KEY=10000 0 0 0 0 0 0 7b 1000 38 0 e1aeffdf 1cfffff ffffffff fffffffe
B: MSC=10
B: LED=1f

I: Bus=0003 Vendor=05ac Product=020e Version=0110
N: Name="Apple Computer Apple Internal Keyboard/Trackpad"
P: Phys=usb-0001:10:1a.0-2/input2
S: Sysfs=/devices/pci0001:10/0001:10:1a.0/usb2/2-2/2-2:1.2/input/input5
U: Uniq=
H: Handlers=kbd event3 
B: EV=13
B: KEY=2 0 0 0 0 0
B: MSC=10

I: Bus=0003 Vendor=05ac Product=020e Version=0028
N: Name="appletouch"
P: Phys=usb-0001:10:1a.0-2/input0
S: Sysfs=/devices/pci0001:10/0001:10:1a.0/usb2/2-2/2-2:1.1/input/input6
U: Uniq=
H: Handlers=mouse1 event4 
B: EV=b
B: KEY=6420 0 10000 0 0 0 0 0 0 0 0
B: ABS=1000003

event4 is appletouch

---

Yes, it's detected and mouse clicks are working.

Spew is coming through over event4 which I tested with evtest.c:

udo ./evtest /dev/input/event4 
[sudo] password for jeremy: 
Input driver version is 1.0.0
Input device ID: bus 0x3 vendor 0x5ac product 0x20e version 0x28
Input device name: "appletouch"
Supported events:
  Event type 0 (Sync)
  Event type 1 (Key)
    Event code 272 (LeftBtn)
    Event code 325 (ToolFinger)
    Event code 330 (Touch)
    Event code 333 (Tool Doubletap)
    Event code 334 (Tool Tripletap)
  Event type 3 (Absolute)
    Event code 0 (X)
      Value    479
      Min        0
      Max      959
      Fuzz      16
    Event code 1 (Y)
      Value    352
      Min        0
      Max      644
      Fuzz      16
    Event code 24 (Pressure)
      Value    300
      Min        0
      Max      300
Grab succeeded, ungrabbing.
Testing ... (interrupt to exit)
Event: time 1254955909.525686, type 3 (Absolute), code 0 (X), value 481
Event: time 1254955909.525692, -------------- Report Sync ------------
Event: time 1254955909.535686, type 3 (Absolute), code 0 (X), value 484
Event: time 1254955909.535690, -------------- Report Sync ------------
Event: time 1254955909.545687, type 3 (Absolute), code 0 (X), value 487
Event: time 1254955909.545690, -------------- Report Sync ------------
Event: time 1254955909.556684, type 3 (Absolute), code 0 (X), value 490
Event: time 1254955909.556687, -------------- Report Sync ------------
Event: time 1254955909.565685, type 3 (Absolute), code 0 (X), value 493
Event: time 1254955909.565688, -------------- Report Sync ------------
Event: time 1254955909.574684, type 3 (Absolute), code 0 (X), value 496
Event: time 1254955909.574686, -------------- Report Sync ------------
Event: time 1254955909.585684, type 3 (Absolute), code 0 (X), value 499
Event: time 1254955909.585687, -------------- Report Sync ------------
Event: time 1254955909.594685, type 3 (Absolute), code 0 (X), value 502
Event: time 1254955909.594687, -------------- Report Sync ------------
Event: time 1254955909.602683, type 3 (Absolute), code 0 (X), value 504
Event: time 1254955909.602686, -------------- Report Sync ------------
Event: time 1254955909.611683, type 3 (Absolute), code 1 (Y), value 350
Event: time 1254955909.611686, -------------- Report Sync ------------
Event: time 1254955909.707685, type 3 (Absolute), code 0 (X), value 501
Event: time 1254955909.707688, -------------- Report Sync ------------
Event: time 1254955909.717686, type 3 (Absolute), code 0 (X), value 499
Event: time 1254955909.717689, -------------- Report Sync ------------
Event: time 1254955909.728685, type 3 (Absolute), code 0 (X), value 497
Event: time 1254955909.728687, -------------- Report Sync ------------
Event: time 1254955909.737684, type 3 (Absolute), code 0 (X), value 495
Event: time 1254955909.737686, -------------- Report Sync ------------

I'll try reverting 59664c0bdadb460086399375a3203fd08feb6abf and giving that a try.
Comment 5 Dmitry Torokhov 2009-10-07 23:22:21 UTC
That suggest that the driver and input core works. Strangely mousedev did not attach to the appletouch device and thus GPM would not see anything. Is your X still uses legacy mouse driver?
Comment 6 Dmitry Torokhov 2009-10-07 23:23:19 UTC
Doh! Looked at the wrong entry... mousedev is active on event4.
Comment 7 Jeremy Huddleston 2009-10-07 23:31:01 UTC
No, X uses evdev.

gpm is reacting to the trackpad clicks.
Comment 8 Jeremy Huddleston 2009-10-07 23:31:31 UTC
And evdev in X is binding to /dev/input/event4 (since I need to kill X in order to bind to it for evtest).
Comment 9 Dmitry Torokhov 2009-10-07 23:42:18 UTC
I really don't see anything touching input in 2.6.31.1 and 2.6.31.2... Did you happen to update any other components beside the kernel?

At this point I am afraid you'll have to start bisecting to find the offending commit...
Comment 10 Jeremy Huddleston 2009-10-08 19:56:35 UTC
Ok, I'm going to chalk this up to some random hardware fluke.  I built 2.6.31.1 which worked fine, then went back to 2.6.31.2, and it was working fine... so /shrug ...

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