Bug 9842 - key 49 and 94 send both 49 and 94 events on macbooks REGRESSION
Summary: key 49 and 94 send both 49 and 94 events on macbooks REGRESSION
Alias: None
Product: Drivers
Classification: Unclassified
Component: Input Devices (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: Jiri Kosina
Depends on:
Blocks: 9832
  Show dependency tree
Reported: 2008-01-29 08:15 UTC by Emil Karlson
Modified: 2008-02-17 22:24 UTC (History)
2 users (show)

See Also:
Kernel Version: 2.6.24-git5
Regression: Yes
Bisected commit-id:

revert quirk code movement (7.08 KB, patch)
2008-02-05 13:21 UTC, Jiri Kosina
Details | Diff
fix hid-input quirk processing (3.51 KB, patch)
2008-02-07 04:28 UTC, Jiri Kosina
Details | Diff

Description Emil Karlson 2008-01-29 08:15:23 UTC
Latest working kernel version:2.6.25-git4
Earliest failing kernel version:2.6.25-git5
Hardware Environment:macbook
Problem Description:
both keys 49 and 94 (keycode by xev) send two events on X corresponding to 49 & 94 or 94 & 49

It might be useful two note in some earlier kernels the keys were reversed(49 gave 94 and 94 gave 49) which was fixed in some later kernel update.

This bug has been present in mm-tree earlier.

Steps to reproduce:
press key 49 or 94 on macbook (keycode by xev)
on my keymap this gives
<§ or §<
Comment 1 Dmitry Torokhov 2008-01-29 10:09:09 UTC
Is this with HIB oe ADB driver? Do you see duplicate events in console if you run evtest utility?
Comment 2 Emil Karlson 2008-01-29 10:52:07 UTC
Yes evtest /dev/input/event1 and pressing 49 gives the '<§' on console.

On console without evtest key 49 also gives '<§'.

Still there is no keyboard repeat for the first event when continuoysly pressing a key affected by some apple quirk (fn+something, 49, 94). This happens in evtest, console and Xorg. Don't know if it correlates in any way with this bug. (with fn something the fn is in effect just for the first repeat)

I am not quite certain though how one should use evtest.

I should be using xkb driver on Xorg anyways, unless this is some weird Xorg-server-1.4 input hotplug feature.
Comment 3 Emil Karlson 2008-01-29 10:58:22 UTC
kbd was the driver for xorg...
Comment 4 Jiri Kosina 2008-01-30 03:07:02 UTC
Does this happen with usbhid kernel driver?

Could you please send me vendor/product identifiers of the keyboard (you can see them for example in the output of 'lsusb' command)

Comment 5 Emil Karlson 2008-01-30 04:11:46 UTC
lsusb gives
Bus 005 Device 002: ID 05ac:1000 Apple Computer, Inc. 
      bInterfaceClass         3 Human Interface Devices
      bInterfaceSubClass      1 Boot Interface Subclass
      bInterfaceProtocol      1 Keyboard
Bus 002 Device 002: ID 05ac:021b Apple Computer, Inc. 
  iManufacturer           1 Apple Computer
  iProduct                2 Apple Internal Keyboard / Trackpad
      bInterfaceClass         3 Human Interface Devices
      bInterfaceSubClass      1 Boot Interface Subclass
      bInterfaceProtocol      1 Keyboard
      iInterface              3 Apple Internal Keyboard

and dmesg gives
input: HID 05ac:1000 as /devices/pci0000:00/0000:00:1d.3/usb5/5-1/5-1:1.0/input/input8
input: USB HID v1.11 Keyboard [HID 05ac:1000] on usb-0000:00:1d.3-1
input: HID 05ac:1000 as /devices/pci0000:00/0000:00:1d.3/usb5/5-1/5-1:1.1/input/input9
input: USB HID v1.11 Mouse [HID 05ac:1000] on usb-0000:00:1d.3-1

So the first one is probably the relevant one - yes I use usbhid afaik.
Comment 6 Jiri Kosina 2008-01-30 04:35:05 UTC
Does reverting commit a45d82d19a6c2 commit fix the problem for you please?
Comment 7 Emil Karlson 2008-01-30 10:16:37 UTC
apparently I don't have enough skills to use git (or patch -R), manually reverting the patch on 2.6.24-git7 did not seem to help.

I can test on git once I'll get a revision that actually boots.
Comment 8 Emil Karlson 2008-02-03 01:27:51 UTC
Since this doesnt seem to happen, where can I get git revisions of git snapshots 4,5,7,8? 
Comment 9 Adrian Bunk 2008-02-03 01:48:19 UTC
is the -git4 one, similar naming for the other ones
Comment 10 Emil Karlson 2008-02-03 03:16:49 UTC
Here you go

87bc2aa9933afc032a93490e1642918121e7470b is first bad commit
commit 87bc2aa9933afc032a93490e1642918121e7470b
Author: Jiri Kosina <jkosina@suse.cz>
Date:   Fri Nov 23 13:16:02 2007 +0100

    HID: separate hid-input event quirks from generic code
    This patch separates also the hid-input quirks that have to be
    applied at the time the event occurs, so that the generic code
    handling HUT-compliant devices is not messed up by them too much.
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>

:040000 040000 b7cc103e79b047a5d0a1cce04835e9107efa2745 b33a2564773ce179902315a5bfdce47fea164f7a M	drivers
:040000 040000 f1108c536cdfdc48b84a3f40f136050be0697d52 32d5871f23f30d2a1480e2800d59aae7982af1c1 M	include
Comment 11 Jiri Kosina 2008-02-05 13:21:08 UTC
Created attachment 14713 [details]
revert quirk code movement

Hmm, I don't immediately see how this patch could be causing what you are seeing.

Could you please try to apply the attached patch, if it fixes the bug? It should be basically just revert of the patch you bisected, with rejects fixed.

Comment 12 Emil Karlson 2008-02-05 14:37:24 UTC
Applying the patch (on 2.6.24-git14) fixes the bug as far I can tell, now I get just '<' or '§'.
Comment 13 Jiri Kosina 2008-02-07 04:28:02 UTC
Created attachment 14731 [details]
fix hid-input quirk processing

Could you please try the attached patch and let me know? It should fix your issues. Thanks.
Comment 14 Emil Karlson 2008-02-07 06:25:39 UTC
Attached patch (id=14731) seems to fix the issue (tested on 2.6.24-git16). 
Comment 15 Jiri Kosina 2008-02-07 07:47:19 UTC
Thanks for your testing. I have queued the patch in the 'upstream-fixes' branch of my tree to be pushed to Linus.
Comment 16 Pekka Enberg 2008-02-17 22:24:38 UTC
FYI, I had the same problem but it went away when I disabled CONFIG_MAC_EMUMOUSEBTN. I haven't tested Jiri's patch though.

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