Latest working kernel version:2.6.25-git4 Earliest failing kernel version:2.6.25-git5 Distribution:gentoo 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 §<
Is this with HIB oe ADB driver? Do you see duplicate events in console if you run evtest utility?
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.
kbd was the driver for xorg...
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) Thanks
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 and 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.
Does reverting commit a45d82d19a6c2 commit fix the problem for you please?
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. http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=a45d82d19a6c2;hp=81e1a875505f2963f4d22f7e7ade39d764755f9b I can test on git once I'll get a revision that actually boots.
Since this doesnt seem to happen, where can I get git revisions of git snapshots 4,5,7,8?
http://ftp.kernel.org/pub/linux/kernel/v2.6/snapshots/patch-2.6.24-git4.id is the -git4 one, similar naming for the other ones
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
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. Thanks.
Applying the patch (on 2.6.24-git14) fixes the bug as far I can tell, now I get just '<' or '§'.
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.
Attached patch (id=14731) seems to fix the issue (tested on 2.6.24-git16).
Thanks for your testing. I have queued the patch in the 'upstream-fixes' branch of my tree to be pushed to Linus.
FYI, I had the same problem but it went away when I disabled CONFIG_MAC_EMUMOUSEBTN. I haven't tested Jiri's patch though.