Hi On Wed, Sep 10, 2014 at 1:13 PM, Fredrik Hallenberg <megahallon@xxxxxxxxx> wrote: > 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 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. Thanks David -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
