Bug 9842

Summary:	key 49 and 94 send both 49 and 94 events on macbooks REGRESSION
Product:	Drivers	Reporter:	Emil Karlson (jekarlson)
Component:	Input Devices	Assignee:	Jiri Kosina (jikos)
Status:	CLOSED CODE_FIX
Severity:	normal	CC:	bunk, jikos
Priority:	P1
Hardware:	All
OS:	Linux
Kernel Version:	2.6.24-git5	Subsystem:
Regression:	Yes	Bisected commit-id:
Bug Depends on:
Bug Blocks:	9832
Attachments:	revert quirk code movement fix hid-input quirk processing

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
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 §<

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)

Thanks

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
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.

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.
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.

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

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

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.

Thanks.

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.