Feature request: add key names from web tool

[jtroo]

Is your feature request related to a problem? Please describe.

https://github.com/houmain/keymapper?tab=readme-ov-file#key-names

Apparently there's a website to allow easy discovery of keycodes. Not having tested yet, I would assume this works well for LLHOOK but I am less certain about Linux evdev and Interception.

But it would be able to use/suggest in docs if it works

Describe the solution you'd like.

Investigate and see if it works

Describe alternatives you've considered.

Not adding them because it doesn't work as intended

Additional context

No response

[rszyma]

Not having tested yet, I would assume this works well for LLHOOK but I am less certain about Linux evdev and Interception.

on Linux (wayland) and US layout detects all keyboard keys, but no mouse keys/events

[rszyma]

Though what would it the codes be used for? arbitrary-code? Then it shows different values on Linux e.g. the tool shows 65 for 'a' key, but evtest shows 30.

[jtroo]

It would be used for str_to_oscode

[jtroo]

Interesting, so the event.code field represents the underlying code that was pressed before OS desktop-level remapping. E.g. changing OS layout to dvorak does not change the code field, but does change the key field. This is consistent between Windows and Linux.

But what kanata Win-LLHOOK does today is use the equivalent of event.key in the hook function. So changing to use the equivalent of event.code by default would be a breaking change. It does seem more correct to change to that behaviour though, which is what keymapper appears to do.

[jtroo]

I would guess switching to use scancodes should also fix this long-standing issue that I hadn't considered before.

#152

Probably worth doing! 🙂

[jtroo]

As it turns out, unsafe { dbg!(MapVirtualKeyA(lparam.scanCode, 1)) } maps to the VK of the current layout. Not working just yet.. instead of calling this function, need to convert to the US layout.

[wis]

Do you still need the key names? I looked up the w3c spec for KeyboardEvent which is the object type in the browser for all the keyboard events, and found a list of them.

quote from the UIEvents w3c spec document:

the complete set of key and code values defined in [UIEvents-Key] and [UIEvents-Code] (subject to platform availability)

The UIEvents-Code link in the quote links to a footnote reference at the bottom, which contains a link to another spec document: UI Events KeyboardEvent code Values, which contains tables that list all the key names.

More on event.code: KeyboardEvent.code - MDN

[jtroo]

As it turns out, unsafe { dbg!(MapVirtualKeyA(lparam.scanCode, 1)) } maps to the VK of the current layout. Not working just yet.. instead of calling this function, need to convert to the US layout.

Fixed in #871

Now still need to add the proper docs and add to str_to_oscode

[gerhard-h]

BREAKING CHANGE: Add web event.code names as usable configuration key names, making them no longer usable in deflocalkeys.

I tested the feature and used successfully Numpad9, F1 (upper case) in my config - great.

Then I tried to break it
(deflocalkeys-wintercept ^ 192
(deflocalkeys-wintercept £ 186
(deflocalkeys-wintercept Lang1 186

But they all worked. :)

(deflocalkeys-wintercept ⇞ finally didn't work, but I think it is not related to this feature.