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