* Re: hid_apple bug: arrow keys interpreted as Fn [not found] ` <C3870FA0-209F-4D40-8923-34D594B75EB1@freedesktop.org> @ 2009-05-19 20:57 ` Jiri Slaby 2009-05-19 21:10 ` Jiri Slaby 2009-05-19 22:31 ` Jeremy Huddleston [not found] ` <4A132540.7070409@gmail.com> 1 sibling, 2 replies; 9+ messages in thread From: Jiri Slaby @ 2009-05-19 20:57 UTC (permalink / raw) To: Jeremy Huddleston; +Cc: Jiri Kosina, linux-input On 05/19/2009 07:13 AM, Jeremy Huddleston wrote: > I'm sending this to you since you're the most recent maintainer listed > in hid_apple.c ... please let me know if I should look somewhere else... > > I've found a weird issue using hid_apple in a recent linux-2.6 git. > Pressing 3 arrow keys at once causes a problem whereby the third press > and the first release are interpreted as Fn instead of the actual key. > > From evtest.c (http://people.freedesktop.org/~whot/evtest.c): > > # press right > Event: time 1242708001.840682, type 4 (Misc), code 4 (ScanCode), value > 7004f > Event: time 1242708001.840700, type 1 (Key), code 106 (Right), value 1 > Event: time 1242708001.840704, -------------- Report Sync ------------ > Event: time 1242708002.089283, type 1 (Key), code 106 (Right), value 2 > ... REPEAT ... > Event: time 1242708002.489293, type 1 (Key), code 106 (Right), value 2 > Event: time 1242708002.489302, -------------- Report Sync ------------ > > press down > Event: time 1242708002.496684, type 4 (Misc), code 4 (ScanCode), value > 70051 > Event: time 1242708002.496699, type 1 (Key), code 108 (Down), value 1 > Event: time 1242708002.496704, -------------- Report Sync ------------ > Event: time 1242708002.745939, type 1 (Key), code 108 (Down), value 2 > ... REPEAT > Event: time 1242708003.545937, type 1 (Key), code 108 (Down), value 2 > Event: time 1242708003.545945, -------------- Report Sync ------------ > > press left > Event: time 1242708003.568680, type 1 (Key), code 464 (?), value 1 > Event: time 1242708003.568690, -------------- Report Sync ------------ > Event: time 1242708003.815938, type 1 (Key), code 464 (?), value 2 > ... REPEAT > Event: time 1242708004.582630, type 1 (Key), code 464 (?), value 2 > Event: time 1242708004.582639, -------------- Report Sync ------------ > > release right (somehow this release is causing the Fn release and right > never releases) > Event: time 1242708004.592685, type 1 (Key), code 102 (Home), value 1 > Event: time 1242708004.592697, type 1 (Key), code 464 (?), value 0 > Event: time 1242708004.592699, -------------- Report Sync ------------ > > release down > Event: time 1242708009.040671, type 4 (Misc), code 4 (ScanCode), value > 70051 > Event: time 1242708009.040685, type 1 (Key), code 108 (Down), value 0 > Event: time 1242708009.040689, -------------- Report Sync ------------ > > release left > Event: time 1242708013.568663, type 1 (Key), code 102 (Home), value 0 > Event: time 1242708013.568671, -------------- Report Sync ------------ Didn't you crop some 'type 4 (Misc)' lines from that output? It looks like the kbd controller doesn't emit hid events for the releases. It all looks like the controller got pretty crazy after pressing those 3 buttons at a time. Jiri, any ideas here? I don't understand 'code 464' lines as well, how they did get there? I would have suspected the autorepeat code if there hadn't been a 'value 1' entry. But this look like we get a mess from the keyboard. What it is expected to output when you press fn+arrow? > --- > > Bus 002 Device 003: ID 05ac:020e Apple, Inc. Internal Keyboard/Trackpad > Device Descriptor: > bLength 18 > bDescriptorType 1 > bcdUSB 2.00 > bDeviceClass 0 (Defined at Interface level) > bDeviceSubClass 0 > bDeviceProtocol 0 > bMaxPacketSize0 8 > idVendor 0x05ac Apple, Inc. > idProduct 0x020e Internal Keyboard/Trackpad > bcdDevice 0.28 > iManufacturer 1 Apple Computer > iProduct 2 Apple Internal Keyboard/Trackpad > iSerial 0 > bNumConfigurations 1 > Configuration Descriptor: > bLength 9 > bDescriptorType 2 > wTotalLength 21504 > bNumInterfaces 3 > bConfigurationValue 1 > iConfiguration 0 > bmAttributes 0xa0 > (Bus Powered) > Remote Wakeup > MaxPower 40mA > Interface Descriptor: > bLength 9 > bDescriptorType 4 > bInterfaceNumber 0 > bAlternateSetting 0 > bNumEndpoints 1 > bInterfaceClass 3 Human Interface Device > bInterfaceSubClass 1 Boot Interface Subclass > bInterfaceProtocol 1 Keyboard > iInterface 5 Keyboard > HID Device Descriptor: > bLength 9 > bDescriptorType 33 > bcdHID 1.10 > bCountryCode 0 Not supported > bNumDescriptors 1 > bDescriptorType 34 Report > wDescriptorLength 73 > Report Descriptors: > ** UNAVAILABLE ** > Endpoint Descriptor: > bLength 7 > bDescriptorType 5 > bEndpointAddress 0x83 EP 3 IN > bmAttributes 3 > Transfer Type Interrupt > Synch Type None > Usage Type Data > wMaxPacketSize 0x0800 2x 0 bytes > bInterval 10 > Interface Descriptor: > bLength 9 > bDescriptorType 4 > bInterfaceNumber 1 > bAlternateSetting 0 > bNumEndpoints 1 > bInterfaceClass 3 Human Interface Device > bInterfaceSubClass 1 Boot Interface Subclass > bInterfaceProtocol 2 Mouse > iInterface 6 Touchpad > HID Device Descriptor: > bLength 9 > bDescriptorType 33 > bcdHID 1.10 > bCountryCode 0 Not supported > bNumDescriptors 1 > bDescriptorType 34 Report > wDescriptorLength 35 > Report Descriptors: > ** UNAVAILABLE ** > Endpoint Descriptor: > bLength 7 > bDescriptorType 5 > bEndpointAddress 0x81 EP 1 IN > bmAttributes 3 > Transfer Type Interrupt > Synch Type None > Usage Type Data > wMaxPacketSize 0x2000 1x 0 bytes > bInterval 1 > Interface Descriptor: > bLength 9 > bDescriptorType 4 > bInterfaceNumber 2 > bAlternateSetting 0 > bNumEndpoints 1 > bInterfaceClass 3 Human Interface Device > bInterfaceSubClass 0 No Subclass > bInterfaceProtocol 0 None > iInterface 7 Consumer > HID Device Descriptor: > bLength 9 > bDescriptorType 33 > bcdHID 1.10 > bCountryCode 0 Not supported > bNumDescriptors 1 > bDescriptorType 34 Report > wDescriptorLength 20 > Report Descriptors: > ** UNAVAILABLE ** > Endpoint Descriptor: > bLength 7 > bDescriptorType 5 > bEndpointAddress 0x84 EP 4 IN > bmAttributes 3 > Transfer Type Interrupt > Synch Type None > Usage Type Data > wMaxPacketSize 0x0100 1x 256 bytes > bInterval 10 > Device Status: 0x0000 > (Bus Powered) > ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: hid_apple bug: arrow keys interpreted as Fn 2009-05-19 20:57 ` hid_apple bug: arrow keys interpreted as Fn Jiri Slaby @ 2009-05-19 21:10 ` Jiri Slaby 2009-05-19 22:31 ` Jeremy Huddleston 1 sibling, 0 replies; 9+ messages in thread From: Jiri Slaby @ 2009-05-19 21:10 UTC (permalink / raw) To: Jeremy Huddleston; +Cc: Jiri Kosina, linux-input On 05/19/2009 10:57 PM, Jiri Slaby wrote: > I don't understand 'code 464' lines as well, how they did get there? Ah, that's the fn key and there can be no misc for those, since they are handled in the apple driver. Ignore me, I need to dig through the code more carefully. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: hid_apple bug: arrow keys interpreted as Fn 2009-05-19 20:57 ` hid_apple bug: arrow keys interpreted as Fn Jiri Slaby 2009-05-19 21:10 ` Jiri Slaby @ 2009-05-19 22:31 ` Jeremy Huddleston 1 sibling, 0 replies; 9+ messages in thread From: Jeremy Huddleston @ 2009-05-19 22:31 UTC (permalink / raw) To: Jiri Slaby; +Cc: Jiri Kosina, linux-input > Didn't you crop some 'type 4 (Misc)' lines from that output? No, I just cropped value:2 lines identical to the lines above/below and sync lines. > It looks > like the kbd controller doesn't emit hid events for the releases. It > all > looks like the controller got pretty crazy after pressing those 3 > buttons at a time. Jiri, any ideas here? > > I don't understand 'code 464' lines as well, how they did get there? I > would have suspected the autorepeat code if there hadn't been a 'value > 1' entry. There was a value:1 entry for code 464. That occurred when I pressed left. code 464 corresponds to Fn. > But this look like we get a mess from the keyboard. > > What it is expected to output when you press fn+arrow? Just to be clear, I'm NOT pressing Fn. Pressing Fn+Left should result in Home... which I suspect is related to why we see the Home release when I eventually release left. ^ permalink raw reply [flat|nested] 9+ messages in thread
[parent not found: <4A132540.7070409@gmail.com>]
* Re: hid_apple bug: arrow keys interpreted as Fn [not found] ` <4A132540.7070409@gmail.com> @ 2009-05-20 1:04 ` Jeremy Huddleston 2009-05-20 14:19 ` Jiri Kosina 0 siblings, 1 reply; 9+ messages in thread From: Jeremy Huddleston @ 2009-05-20 1:04 UTC (permalink / raw) To: Jiri Slaby; +Cc: linux-input, Jiri Kosina On May 19, 2009, at 14:31, Jiri Slaby wrote: > On 05/19/2009 07:13 AM, Jeremy Huddleston wrote: >> I'm sending this to you since you're the most recent maintainer >> listed >> in hid_apple.c ... please let me know if I should look somewhere >> else... >> >> I've found a weird issue using hid_apple in a recent linux-2.6 git. >> Pressing 3 arrow keys at once causes a problem whereby the third >> press >> and the first release are interpreted as Fn instead of the actual >> key. >> >> From evtest.c (http://people.freedesktop.org/~whot/evtest.c): > > Could you rebuild your kernel with HID_DEBUG enabled, modprobe hid > module with hid_debug=2, retry and send the resulting dmesg output? > > To me it now looks like the FN is sent from the kbd, but I might be > wrong again. I used debug=2 since hid doesn't know about hid_debug on my kernel (linux-2.6 git master as of a few hours ago) starting, no keys pressed press right: May 19 18:01:14 aeris kernel: [ 256.453247] drivers/hid/hid-core.c: report (size 8) (unnumbered) May 19 18:01:14 aeris kernel: [ 256.453259] drivers/hid/hid-core.c: report 0 (size 8) = 00 00 4f 00 00 00 00 00 May 19 18:01:14 aeris kernel: [ 256.453278] hid-debug: input Keyboard. 00e0 = 0 May 19 18:01:14 aeris kernel: [ 256.453295] hid-debug: input Keyboard. 00e1 = 0 May 19 18:01:14 aeris kernel: [ 256.453304] hid-debug: input Keyboard. 00e2 = 0 May 19 18:01:14 aeris kernel: [ 256.453313] hid-debug: input Keyboard. 00e3 = 0 May 19 18:01:14 aeris kernel: [ 256.453322] hid-debug: input Keyboard. 00e4 = 0 May 19 18:01:14 aeris kernel: [ 256.453331] hid-debug: input Keyboard. 00e5 = 0 May 19 18:01:14 aeris kernel: [ 256.453340] hid-debug: input Keyboard. 00e6 = 0 May 19 18:01:14 aeris kernel: [ 256.453349] hid-debug: input Keyboard. 00e7 = 0 May 19 18:01:14 aeris kernel: [ 256.453359] hid-debug: input Keyboard. 004f = 1 May 19 18:01:14 aeris kernel: [ 256.453373] hid-debug: input 00ff. 0003 = 0 press down: May 19 18:01:17 aeris kernel: [ 259.429256] drivers/hid/hid-core.c: report (size 8) (unnumbered) May 19 18:01:17 aeris kernel: [ 259.429268] drivers/hid/hid-core.c: report 0 (size 8) = 00 00 4f 51 00 00 00 00 May 19 18:01:17 aeris kernel: [ 259.429288] hid-debug: input Keyboard. 00e0 = 0 May 19 18:01:17 aeris kernel: [ 259.429305] hid-debug: input Keyboard. 00e1 = 0 May 19 18:01:17 aeris kernel: [ 259.429315] hid-debug: input Keyboard. 00e2 = 0 May 19 18:01:17 aeris kernel: [ 259.429324] hid-debug: input Keyboard. 00e3 = 0 May 19 18:01:17 aeris kernel: [ 259.429333] hid-debug: input Keyboard. 00e4 = 0 May 19 18:01:17 aeris kernel: [ 259.429341] hid-debug: input Keyboard. 00e5 = 0 May 19 18:01:17 aeris kernel: [ 259.429350] hid-debug: input Keyboard. 00e6 = 0 May 19 18:01:17 aeris kernel: [ 259.429359] hid-debug: input Keyboard. 00e7 = 0 May 19 18:01:17 aeris kernel: [ 259.429370] hid-debug: input Keyboard. 0051 = 1 May 19 18:01:17 aeris kernel: [ 259.429423] hid-debug: input 00ff. 0003 = 0 press left: May 19 18:01:20 aeris kernel: [ 262.469256] drivers/hid/hid-core.c: report (size 8) (unnumbered) May 19 18:01:20 aeris kernel: [ 262.469269] drivers/hid/hid-core.c: report 0 (size 8) = 00 00 01 01 01 01 01 01 May 19 18:01:20 aeris kernel: [ 262.469289] hid-debug: input Keyboard. 00e0 = 0 May 19 18:01:20 aeris kernel: [ 262.469307] hid-debug: input Keyboard. 00e1 = 0 May 19 18:01:20 aeris kernel: [ 262.469316] hid-debug: input Keyboard. 00e2 = 0 May 19 18:01:20 aeris kernel: [ 262.469326] hid-debug: input Keyboard. 00e3 = 0 May 19 18:01:20 aeris kernel: [ 262.469334] hid-debug: input Keyboard. 00e4 = 0 May 19 18:01:20 aeris kernel: [ 262.469343] hid-debug: input Keyboard. 00e5 = 0 May 19 18:01:20 aeris kernel: [ 262.469352] hid-debug: input Keyboard. 00e6 = 0 May 19 18:01:20 aeris kernel: [ 262.469361] hid-debug: input Keyboard. 00e7 = 0 May 19 18:01:20 aeris kernel: [ 262.469372] hid-debug: input 00ff. 0003 = 1 release right: May 19 18:01:22 aeris kernel: [ 264.981247] drivers/hid/hid-core.c: report (size 8) (unnumbered) May 19 18:01:22 aeris kernel: [ 264.981258] drivers/hid/hid-core.c: report 0 (size 8) = 00 00 51 50 00 00 00 00 May 19 18:01:22 aeris kernel: [ 264.981278] hid-debug: input Keyboard. 00e0 = 0 May 19 18:01:22 aeris kernel: [ 264.981295] hid-debug: input Keyboard. 00e1 = 0 May 19 18:01:22 aeris kernel: [ 264.981304] hid-debug: input Keyboard. 00e2 = 0 May 19 18:01:22 aeris kernel: [ 264.981313] hid-debug: input Keyboard. 00e3 = 0 May 19 18:01:22 aeris kernel: [ 264.981322] hid-debug: input Keyboard. 00e4 = 0 May 19 18:01:22 aeris kernel: [ 264.981331] hid-debug: input Keyboard. 00e5 = 0 May 19 18:01:22 aeris kernel: [ 264.981340] hid-debug: input Keyboard. 00e6 = 0 May 19 18:01:22 aeris kernel: [ 264.981349] hid-debug: input Keyboard. 00e7 = 0 May 19 18:01:22 aeris kernel: [ 264.981359] hid-debug: input Keyboard. 004f = 0 May 19 18:01:22 aeris kernel: [ 264.981369] hid-debug: input Keyboard. 0050 = 1 May 19 18:01:22 aeris kernel: [ 264.981411] hid-debug: input 00ff. 0003 = 0 release down: May 19 18:01:25 aeris kernel: [ 267.405254] drivers/hid/hid-core.c: report (size 8) (unnumbered) May 19 18:01:25 aeris kernel: [ 267.405267] drivers/hid/hid-core.c: report 0 (size 8) = 00 00 50 00 00 00 00 00 May 19 18:01:25 aeris kernel: [ 267.405288] hid-debug: input Keyboard. 00e0 = 0 May 19 18:01:25 aeris kernel: [ 267.405304] hid-debug: input Keyboard. 00e1 = 0 May 19 18:01:25 aeris kernel: [ 267.405314] hid-debug: input Keyboard. 00e2 = 0 May 19 18:01:25 aeris kernel: [ 267.405323] hid-debug: input Keyboard. 00e3 = 0 May 19 18:01:25 aeris kernel: [ 267.405332] hid-debug: input Keyboard. 00e4 = 0 May 19 18:01:25 aeris kernel: [ 267.405340] hid-debug: input Keyboard. 00e5 = 0 May 19 18:01:25 aeris kernel: [ 267.405349] hid-debug: input Keyboard. 00e6 = 0 May 19 18:01:25 aeris kernel: [ 267.405359] hid-debug: input Keyboard. 00e7 = 0 May 19 18:01:25 aeris kernel: [ 267.405369] hid-debug: input Keyboard. 0051 = 0 May 19 18:01:25 aeris kernel: [ 267.405424] hid-debug: input 00ff. 0003 = 0 release left: May 19 18:01:26 aeris kernel: [ 269.277246] drivers/hid/hid-core.c: report (size 8) (unnumbered) May 19 18:01:26 aeris kernel: [ 269.277258] drivers/hid/hid-core.c: report 0 (size 8) = 00 00 00 00 00 00 00 00 May 19 18:01:26 aeris kernel: [ 269.277278] hid-debug: input Keyboard. 00e0 = 0 May 19 18:01:26 aeris kernel: [ 269.277295] hid-debug: input Keyboard. 00e1 = 0 May 19 18:01:26 aeris kernel: [ 269.277304] hid-debug: input Keyboard. 00e2 = 0 May 19 18:01:26 aeris kernel: [ 269.277313] hid-debug: input Keyboard. 00e3 = 0 May 19 18:01:26 aeris kernel: [ 269.277322] hid-debug: input Keyboard. 00e4 = 0 May 19 18:01:26 aeris kernel: [ 269.277331] hid-debug: input Keyboard. 00e5 = 0 May 19 18:01:26 aeris kernel: [ 269.277340] hid-debug: input Keyboard. 00e6 = 0 May 19 18:01:26 aeris kernel: [ 269.277349] hid-debug: input Keyboard. 00e7 = 0 May 19 18:01:26 aeris kernel: [ 269.277359] hid-debug: input Keyboard. 0050 = 0 May 19 18:01:26 aeris kernel: [ 269.277401] hid-debug: input 00ff. 0003 = 0 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: hid_apple bug: arrow keys interpreted as Fn 2009-05-20 1:04 ` Jeremy Huddleston @ 2009-05-20 14:19 ` Jiri Kosina 2009-05-20 17:41 ` Jeremy Huddleston 2009-05-21 0:39 ` Jeremy Huddleston 0 siblings, 2 replies; 9+ messages in thread From: Jiri Kosina @ 2009-05-20 14:19 UTC (permalink / raw) To: Jeremy Huddleston; +Cc: Jiri Slaby, linux-input On Tue, 19 May 2009, Jeremy Huddleston wrote: > press right: > May 19 18:01:14 aeris kernel: [ 256.453247] drivers/hid/hid-core.c: report (size 8) (unnumbered) > May 19 18:01:14 aeris kernel: [ 256.453259] drivers/hid/hid-core.c: report 0 (size 8) = 00 00 4f 00 00 00 00 00 [ ... ] > press down: > May 19 18:01:17 aeris kernel: [ 259.429256] drivers/hid/hid-core.c: report (size 8) (unnumbered) > May 19 18:01:17 aeris kernel: [ 259.429268] drivers/hid/hid-core.c: report 0 (size 8) = 00 00 4f 51 00 00 00 00 [ ... ] > press left: > May 19 18:01:20 aeris kernel: [ 262.469256] drivers/hid/hid-core.c: report (size 8) (unnumbered) > May 19 18:01:20 aeris kernel: [ 262.469269] drivers/hid/hid-core.c: report 0 (size 8) = 00 00 01 01 01 01 01 01 [ ... ] > release right: > May 19 18:01:22 aeris kernel: [ 264.981247] drivers/hid/hid-core.c: report (size 8) (unnumbered) > May 19 18:01:22 aeris kernel: [ 264.981258] drivers/hid/hid-core.c: report 0 (size 8) = 00 00 51 50 00 00 00 00 [ ... ] > release down: > May 19 18:01:25 aeris kernel: [ 267.405254] drivers/hid/hid-core.c: report (size 8) (unnumbered) > May 19 18:01:25 aeris kernel: [ 267.405267] drivers/hid/hid-core.c: report 0 (size 8) = 00 00 50 00 00 00 00 00 [ ... ] > release left: > May 19 18:01:26 aeris kernel: [ 269.277246] drivers/hid/hid-core.c: report (size 8) (unnumbered) > May 19 18:01:26 aeris kernel: [ 269.277258] drivers/hid/hid-core.c: report 0 (size 8) = 00 00 00 00 00 00 00 00 Looks like the state machine inside the keyboard gets a little bit crazy when you press the third button. The data that HID core sees coming on USB bus really don't represent [right,down,left] being pressed. Do you have any chance to verify whether this works properly in a different operating system? It would require very specific handling violating the standard. Thanks, -- Jiri Kosina SUSE Labs ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: hid_apple bug: arrow keys interpreted as Fn 2009-05-20 14:19 ` Jiri Kosina @ 2009-05-20 17:41 ` Jeremy Huddleston 2009-05-21 0:39 ` Jeremy Huddleston 1 sibling, 0 replies; 9+ messages in thread From: Jeremy Huddleston @ 2009-05-20 17:41 UTC (permalink / raw) To: Jiri Kosina; +Cc: Jiri Slaby, linux-input -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jiri Kosina wrote: > Looks like the state machine inside the keyboard gets a little bit crazy > when you press the third button. The data that HID core sees coming on USB > bus really don't represent [right,down,left] being pressed. > > Do you have any chance to verify whether this works properly in a > different operating system? It would require very specific handling > violating the standard. I *belive* it worked fine on OSX. I don't have it installed on this machine at the moment, so I can't verify right now. I'll install it on a firewire drive soon and get back to you. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFKFECvjC1Anjf1NmMRAuFOAJ4wwHJi2B27r82e6yB5gfwiG2h/EgCfZ79g shiwKCxclIpjz1NXodZ0/No= =Owmi -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: hid_apple bug: arrow keys interpreted as Fn 2009-05-20 14:19 ` Jiri Kosina 2009-05-20 17:41 ` Jeremy Huddleston @ 2009-05-21 0:39 ` Jeremy Huddleston 2009-06-23 13:07 ` Jiri Kosina 1 sibling, 1 reply; 9+ messages in thread From: Jeremy Huddleston @ 2009-05-21 0:39 UTC (permalink / raw) To: Jiri Kosina; +Cc: Jiri Slaby, linux-input On May 20, 2009, at 07:19, Jiri Kosina wrote: > On Tue, 19 May 2009, Jeremy Huddleston wrote: > >> press right: >> May 19 18:01:14 aeris kernel: [ 256.453247] drivers/hid/hid- >> core.c: report (size 8) (unnumbered) >> May 19 18:01:14 aeris kernel: [ 256.453259] drivers/hid/hid- >> core.c: report 0 (size 8) = 00 00 4f 00 00 00 00 00 > [ ... ] >> press down: >> May 19 18:01:17 aeris kernel: [ 259.429256] drivers/hid/hid- >> core.c: report (size 8) (unnumbered) >> May 19 18:01:17 aeris kernel: [ 259.429268] drivers/hid/hid- >> core.c: report 0 (size 8) = 00 00 4f 51 00 00 00 00 > [ ... ] >> press left: >> May 19 18:01:20 aeris kernel: [ 262.469256] drivers/hid/hid- >> core.c: report (size 8) (unnumbered) >> May 19 18:01:20 aeris kernel: [ 262.469269] drivers/hid/hid- >> core.c: report 0 (size 8) = 00 00 01 01 01 01 01 01 > [ ... ] >> release right: >> May 19 18:01:22 aeris kernel: [ 264.981247] drivers/hid/hid- >> core.c: report (size 8) (unnumbered) >> May 19 18:01:22 aeris kernel: [ 264.981258] drivers/hid/hid- >> core.c: report 0 (size 8) = 00 00 51 50 00 00 00 00 > [ ... ] >> release down: >> May 19 18:01:25 aeris kernel: [ 267.405254] drivers/hid/hid- >> core.c: report (size 8) (unnumbered) >> May 19 18:01:25 aeris kernel: [ 267.405267] drivers/hid/hid- >> core.c: report 0 (size 8) = 00 00 50 00 00 00 00 00 > [ ... ] >> release left: >> May 19 18:01:26 aeris kernel: [ 269.277246] drivers/hid/hid- >> core.c: report (size 8) (unnumbered) >> May 19 18:01:26 aeris kernel: [ 269.277258] drivers/hid/hid- >> core.c: report 0 (size 8) = 00 00 00 00 00 00 00 00 > > Looks like the state machine inside the keyboard gets a little bit > crazy > when you press the third button. The data that HID core sees coming > on USB > bus really don't represent [right,down,left] being pressed. > > Do you have any chance to verify whether this works properly in a > different operating system? It would require very specific handling > violating the standard. So in OSX, I certainly don't see the Fn misinterpretation. There is another odd behavior in OSX that is probably related to an underlying hardware quirk that OSX just deals with more elegantly. In OSX, I see this behavior: press right: event received that right arrow pressed press down: event received that down arrow pressed press left: no event release right: event received that right arrow released event received that left arrow pressed release down: event received that down arrow released release left: event received that left arrow released So there seems to be an underlying problem that needs to be worked around. Perhaps we can figure out a way to handle it in a way results in similar behavior to the OSX... ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: hid_apple bug: arrow keys interpreted as Fn 2009-05-21 0:39 ` Jeremy Huddleston @ 2009-06-23 13:07 ` Jiri Kosina 2009-06-23 15:10 ` Jeremy Huddleston 0 siblings, 1 reply; 9+ messages in thread From: Jiri Kosina @ 2009-06-23 13:07 UTC (permalink / raw) To: Jeremy Huddleston; +Cc: Jiri Slaby, linux-input On Wed, 20 May 2009, Jeremy Huddleston wrote: > > >press right: > > >May 19 18:01:14 aeris kernel: [ 256.453247] drivers/hid/hid-core.c: report > > >(size 8) (unnumbered) > > >May 19 18:01:14 aeris kernel: [ 256.453259] drivers/hid/hid-core.c: report > > >0 (size 8) = 00 00 4f 00 00 00 00 00 > >[ ... ] > > >press down: > > >May 19 18:01:17 aeris kernel: [ 259.429256] drivers/hid/hid-core.c: report > > >(size 8) (unnumbered) > > >May 19 18:01:17 aeris kernel: [ 259.429268] drivers/hid/hid-core.c: report > > >0 (size 8) = 00 00 4f 51 00 00 00 00 > >[ ... ] > > >press left: > > >May 19 18:01:20 aeris kernel: [ 262.469256] drivers/hid/hid-core.c: report > > >(size 8) (unnumbered) > > >May 19 18:01:20 aeris kernel: [ 262.469269] drivers/hid/hid-core.c: report > > >0 (size 8) = 00 00 01 01 01 01 01 01 > >[ ... ] > > >release right: > > >May 19 18:01:22 aeris kernel: [ 264.981247] drivers/hid/hid-core.c: report > > >(size 8) (unnumbered) > > >May 19 18:01:22 aeris kernel: [ 264.981258] drivers/hid/hid-core.c: report > > >0 (size 8) = 00 00 51 50 00 00 00 00 > >[ ... ] > > >release down: > > >May 19 18:01:25 aeris kernel: [ 267.405254] drivers/hid/hid-core.c: report > > >(size 8) (unnumbered) > > >May 19 18:01:25 aeris kernel: [ 267.405267] drivers/hid/hid-core.c: report > > >0 (size 8) = 00 00 50 00 00 00 00 00 > >[ ... ] > > >release left: > > >May 19 18:01:26 aeris kernel: [ 269.277246] drivers/hid/hid-core.c: report > > >(size 8) (unnumbered) > > >May 19 18:01:26 aeris kernel: [ 269.277258] drivers/hid/hid-core.c: report > > >0 (size 8) = 00 00 00 00 00 00 00 00 > >Do you have any chance to verify whether this works properly in a > >different operating system? It would require very specific handling > >violating the standard. > So in OSX, I certainly don't see the Fn misinterpretation. There is another > odd behavior in OSX that is probably related to an underlying hardware quirk > that OSX just deals with more elegantly. > > In OSX, I see this behavior: > > press right: > event received that right arrow pressed > press down: > event received that down arrow pressed > press left: > no event > release right: > event received that right arrow released > event received that left arrow pressed > release down: > event received that down arrow released > release left: > event received that left arrow released In fact, in your "press left" report, there is drivers/hid/hid-core.c: report (size 8) (unnumbered) drivers/hid/hid-core.c: report 0 (size 8) = 00 00 01 01 01 01 01 01 hid-debug: input Keyboard.00e0 = 0 hid-debug: input Keyboard.00e1 = 0 hid-debug: input Keyboard.00e2 = 0 hid-debug: input Keyboard.00e3 = 0 hid-debug: input Keyboard.00e4 = 0 hid-debug: input Keyboard.00e5 = 0 hid-debug: input Keyboard.00e6 = 0 hid-debug: input Keyboard.00e7 = 0 hid-debug: input 00ff.0003 = 1 Which signalizes that the keyboard thinks that "Fn" key has been pressed. Can you please verify that pressing right-down-left-<something> works in a same way as fn-<something>? Preferably both in linux and other operating system. Thanks, -- Jiri Kosina SUSE Labs ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: hid_apple bug: arrow keys interpreted as Fn 2009-06-23 13:07 ` Jiri Kosina @ 2009-06-23 15:10 ` Jeremy Huddleston 0 siblings, 0 replies; 9+ messages in thread From: Jeremy Huddleston @ 2009-06-23 15:10 UTC (permalink / raw) To: Jiri Kosina; +Cc: Jiri Slaby, linux-input On Jun 23, 2009, at 06:07, Jiri Kosina wrote: > On Wed, 20 May 2009, Jeremy Huddleston wrote: > >>>> press right: >>>> May 19 18:01:14 aeris kernel: [ 256.453247] drivers/hid/hid- >>>> core.c: report >>>> (size 8) (unnumbered) >>>> May 19 18:01:14 aeris kernel: [ 256.453259] drivers/hid/hid- >>>> core.c: report >>>> 0 (size 8) = 00 00 4f 00 00 00 00 00 >>> [ ... ] >>>> press down: >>>> May 19 18:01:17 aeris kernel: [ 259.429256] drivers/hid/hid- >>>> core.c: report >>>> (size 8) (unnumbered) >>>> May 19 18:01:17 aeris kernel: [ 259.429268] drivers/hid/hid- >>>> core.c: report >>>> 0 (size 8) = 00 00 4f 51 00 00 00 00 >>> [ ... ] >>>> press left: >>>> May 19 18:01:20 aeris kernel: [ 262.469256] drivers/hid/hid- >>>> core.c: report >>>> (size 8) (unnumbered) >>>> May 19 18:01:20 aeris kernel: [ 262.469269] drivers/hid/hid- >>>> core.c: report >>>> 0 (size 8) = 00 00 01 01 01 01 01 01 >>> [ ... ] >>>> release right: >>>> May 19 18:01:22 aeris kernel: [ 264.981247] drivers/hid/hid- >>>> core.c: report >>>> (size 8) (unnumbered) >>>> May 19 18:01:22 aeris kernel: [ 264.981258] drivers/hid/hid- >>>> core.c: report >>>> 0 (size 8) = 00 00 51 50 00 00 00 00 >>> [ ... ] >>>> release down: >>>> May 19 18:01:25 aeris kernel: [ 267.405254] drivers/hid/hid- >>>> core.c: report >>>> (size 8) (unnumbered) >>>> May 19 18:01:25 aeris kernel: [ 267.405267] drivers/hid/hid- >>>> core.c: report >>>> 0 (size 8) = 00 00 50 00 00 00 00 00 >>> [ ... ] >>>> release left: >>>> May 19 18:01:26 aeris kernel: [ 269.277246] drivers/hid/hid- >>>> core.c: report >>>> (size 8) (unnumbered) >>>> May 19 18:01:26 aeris kernel: [ 269.277258] drivers/hid/hid- >>>> core.c: report >>>> 0 (size 8) = 00 00 00 00 00 00 00 00 >>> Do you have any chance to verify whether this works properly in a >>> different operating system? It would require very specific handling >>> violating the standard. >> So in OSX, I certainly don't see the Fn misinterpretation. There >> is another >> odd behavior in OSX that is probably related to an underlying >> hardware quirk >> that OSX just deals with more elegantly. >> >> In OSX, I see this behavior: >> >> press right: >> event received that right arrow pressed >> press down: >> event received that down arrow pressed >> press left: >> no event >> release right: >> event received that right arrow released >> event received that left arrow pressed >> release down: >> event received that down arrow released >> release left: >> event received that left arrow released > > In fact, in your "press left" report, there is > > drivers/hid/hid-core.c: report (size 8) (unnumbered) > drivers/hid/hid-core.c: report 0 (size 8) = 00 00 01 01 01 01 01 01 > hid-debug: input Keyboard.00e0 = 0 > hid-debug: input Keyboard.00e1 = 0 > hid-debug: input Keyboard.00e2 = 0 > hid-debug: input Keyboard.00e3 = 0 > hid-debug: input Keyboard.00e4 = 0 > hid-debug: input Keyboard.00e5 = 0 > hid-debug: input Keyboard.00e6 = 0 > hid-debug: input Keyboard.00e7 = 0 > hid-debug: input 00ff.0003 = 1 > > Which signalizes that the keyboard thinks that "Fn" key has been > pressed. > Can you please verify that pressing right-down-left-<something> > works in a > same way as fn-<something>? When I have right-down-left pressed, no other keys pressed generate any event that I can see by running evtest. However, the Yes. I'm sorry that hasn't been clear in my description, but on OSX I do not see the misbehavior of the third arrow being seen as "Fn". I see exactly the (expected) behavior listed in my quoted text and copied here. So in short: ===OSX (correct, based on HW limitations)=== press right: event received that right arrow pressed press down: event received that down arrow pressed press left: no event (atleast as far as applications are told) release right: event received that right arrow released event received that left arrow pressed release down: event received that down arrow released release left: event received that left arrow released ===Linux (wrong)=== press right: event received that right arrow pressed press down: event received that down arrow pressed press left: ### ERROR ### event received that Fn pressed release right: event received that home pressed ## NOTE: Fn+left is home ### ERROR ### event that Fn released (so "right arrow" is still seen in a pressed state) release down: event received that down arrow released release left: event received that home released ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2009-06-23 15:10 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <3E66E0E0-3B2B-4F78-9A62-87015A842A47@freedesktop.org>
[not found] ` <C3870FA0-209F-4D40-8923-34D594B75EB1@freedesktop.org>
2009-05-19 20:57 ` hid_apple bug: arrow keys interpreted as Fn Jiri Slaby
2009-05-19 21:10 ` Jiri Slaby
2009-05-19 22:31 ` Jeremy Huddleston
[not found] ` <4A132540.7070409@gmail.com>
2009-05-20 1:04 ` Jeremy Huddleston
2009-05-20 14:19 ` Jiri Kosina
2009-05-20 17:41 ` Jeremy Huddleston
2009-05-21 0:39 ` Jeremy Huddleston
2009-06-23 13:07 ` Jiri Kosina
2009-06-23 15:10 ` Jeremy Huddleston
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).