Thanks I had no idea about the hwdb but I have tried it now, it works if I use

KEYBOARD_KEY_70031=reserved

on my nordic keyboard, but a US keyboard user would have to use
scancode 70032 instead. If you chose the wrong one the backslash key
will be disabled.

I don't think this is good solution as long as there is no way to
detect which version is used with the hardware matcher string.

However I suppose udev should make it possible to do some kind of
script that does something similar to my original patch, that is,
detects which of the two keys in actually used and disables the other
one.

On Thu, Sep 11, 2014 at 2:41 PM, David Herrmann <[email protected]> wrote:
> Hi
>
> On Thu, Sep 11, 2014 at 10:50 AM, Fredrik Hallenberg
> <[email protected]> wrote:
>>>> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to