Hi

On Thu, Sep 11, 2014 at 10:50 AM, Fredrik Hallenberg
[off-list ref] wrote:

quoted

quoted

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

The HID mapping is hardcoded, so only key code 43 will have this
problem regardless of user keymaps.

I think Dmitry is talking about setkeycode() which can change the
keycode a scancode is mapped to. This is indeed a problem, but I
thought we implicitly tell people to not map two scancodes to the same
keycode.. we simply don't support it (as we only have 1bit state per
keycode, and 0bit per scancode).

But this reminds me: we can use udev hwdb and setkeycode() to fix your
keyboard. Simply add this to /lib/udev/hwdb.d/60-keyboard.hwdb:
    keyboard:name:*Corsair*:dmi:bvn*:bvr*:bd*:svn*:pn*:pvr*
        KEYBOARD_KEY_32=0

this will run setkeycode(0x32, KEY_RESERVED) and thus disable the key
0x32 entirely.
Adding properly crafted match-rules to udev should solve this mess, I
guess. Imho, this is the cleanest solution, but depends on udev, of
course.

Thanks
David