On Wed, Sep 10, 2014 at 04:22:13PM +0200, David Herrmann wrote:

Hi

On Wed, Sep 10, 2014 at 1:13 PM, Fredrik Hallenberg
[off-list ref] wrote:

quoted

The keyboards in question have n-key rollover, this seems to be
implemented by sending every single key id every time the keyboard is
polled, this includes several keys that does not exist physically for
example 0x31. This may be a bit excessive but not broken. If I press
a-key and '-key in rapid succession, I get the following events
(omitting all other keys):

VALUE 1 CODE 30 HID 0x4
VALUE 0 CODE 43 HID 0x31
VALUE 0 CODE 43 HID 0x32
Output: a

VALUE 1 CODE 30 HID 0x4
VALUE 0 CODE 43 HID 0x31  - 43 is up
VALUE 1 CODE 43 HID 0x32  - 43 is down
Output: '

VALUE 0 CODE 30 HID 0x4
VALUE 0 CODE 43 HID 0x31  - 43 is up
VALUE 1 CODE 43 HID 0x32  - 43 is down
Output: '

VALUE 0 CODE 30 HID 0x4
VALUE 0 CODE 43 HID 0x31  - 43 is up
VALUE 1 CODE 43 HID 0x32  - 43 is down
Output: '

So even though the keyboard is behaving a bit weird the problem is in
the kernel as it will interpret 0x31 and 0x32 as the same key.

Thanks for the information! Please include that in follow-up
commit-messages so others can see it as well. I don't think a report
descriptor is needed, anymore.

This indeed explains the problem. We only track keys on the keycode
level, not scancode level. Therefore, you get weird key-up or
key-repeat events depending on the scan-order.

The nicest fix, obviously, is to blacklist keys that are not
physically present on the keyboard. But I assume the keyboard reports

Hmm, somebody could still load keymap with duplicate keycodes though...

either key depending on the model (standard vs. European). Given that
this key is indeed special as we only have a single keycode for it, we
probably need some quirk like yours. I'd like to hear Dmitry's
comments on this, maybe he has had similar problems with non-HID
keyboards.

Hmm, I do not think we have a good story for duplicate keycodes for
drivers that send entire state as opposed to just changed bits.

Thanks.

-- 
Dmitry