How strictly does W3C incomleteness limit this crate's functionality?

[eugenesvk]

For example, there are 3 modifiers Kana (toggle like Caps), Loya, Roya (non-toggle like Shift) that aren't part of the W3C spec (interestingly enough, it has virtual Symbol modifier, but not these physical ones)

Could those be added?

Similarly, all modifiers are currently side-agnostic so you can't differentiate between a Shift state toggled by a Left Shift key vs one toggled by a Right Shift key.

Could that be fixed here?

Or do you plan to maintain the web limits even in non-web apps that would rely on this crate?

[waywardmonkeys]

I'm just getting back from some travel (for RustWeek) and am discussing this with @xorgy and others. Our keyboard stuff currently comes from the keyboard-types crate, so it might be good to bring this up there as well.

[eugenesvk]

I already have a while back rust-windowing/keyboard-types#19 (comment) for mod side awareness, and unfortunately keyboard-types wanted to maintaing Web compat and didn't plan to change any APIs.
But of course would be nice if that crate also were richer and not limit all the libs that rely on it, including this one

[xorgy]

Regarding the oyayubi shift keys... did you include those in this list because you have a personal interest in them? I am having trouble finding any commercially available keyboard with 親指シフト; closest I've found is standalone Fujitsu word processor machines released 14 months after I was born.
Are there even standard scancodes for these? (I see random mentions that they are 0x95 「親指左」 and 0x96 「親指右」, and that would make sense since those are right after 変換・無変換 keys).
And kinda following on from that.. is there any real use for these outside of (obscure) input methods?

[eugenesvk]

I've included them in the list because they are possible to use and are used in actual keyboard layouts on Windows.

The links I've pasted explain the real use for this keys - they help fix the second issue of almost everything being side agnostic when it comes to modifiers. So you can't bind to Right Alt separately from Left Alt.

And Right Alt is located in the most convenient location on the keyboard - right thumb key, so it's a major ergonomic waste.

So one alternative is to rebind right alt as a roya modifier. But then those keys are invisible in many apps since they rely on incomplete foundational frameworks, leading us to... this issue

When it comes to hardware, I don't know, I've only seen pics of various Asian keyboards with many more keys vs the Western ones, and wouldn't be surprised if some ancient models were still used by someone

Are there even standard scancodes for these?

The 95, 96 are VK codes, not scan codes, when I test loya/roya/kana on Windows, so yes, those exist on Windows, VK_OEM_FJ_ROYA and VK_OEM_FJ_LOYA constants in the Windows API spec, so that's a standard?

The scan codes are 11d, l15d, 036
(vks are 95, 96, 15)

You can try the kbdedit app to play with them (it's free version allows temporary rebinding and activation of that binding while the app running)

[eugenesvk]

https://docs.rs/winapi/latest/i686-pc-windows-msvc/winapi/um/winuser/constant.VK_OEM_FJ_LOYA.html
https://docs.rs/winapi/latest/i686-pc-windows-msvc/winapi/um/winuser/constant.VK_OEM_FJ_ROYA.html

are 0x95 and 0x96

https://docs.rs/winapi/latest/i686-pc-windows-msvc/winapi/um/winuser/constant.VK_KANA.html

is 0x15

[eugenesvk]

FYI you can check a working Winit prototype example kbd_ev_print from this PR
And the types including side-awareness and kana/roya/loya mods