Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

scan_code and virtual_key_code are swapped #2092

Closed
Woyten opened this issue Dec 9, 2021 · 5 comments
Closed

scan_code and virtual_key_code are swapped #2092

Woyten opened this issue Dec 9, 2021 · 5 comments
Labels

Comments

@Woyten
Copy link

Woyten commented Dec 9, 2021

https://github.com/rust-windowing/winit/blob/master/src/platform_impl/web/web_sys/event.rs considers event.key_code()/event.char_code() to be the scan_code of the KeyboardInput event and event.code() to be the virtual_key_code of the KeyboardInput event while it should be the other way around.

How to verify yourself: Use the links given below and a German keyboard layout and press the German z key

Demonstration of workaround in my personal project: Woyten/tune@38b7ecd and Woyten/tune@fcec2d3

@Woyten
Copy link
Author

Woyten commented Dec 19, 2021

@madsmtm I would like to contribute to winit by fixing this problem. Is that okay or is there some impediment like s.o. already working on it or an opposite opinion / vision regarding this topic?

@madsmtm
Copy link
Member

madsmtm commented Dec 19, 2021

I've no idea, the keyboard model is not something I've looked at at all.

See this meta issue: #1806, the fix may be present somewhere in those PRs already. Though if the fix is as simple as it sounds, your could try making a PR to fix it, though a big issue right now is that we don't have a WASM maintainer to approve it at the moment (see Testers and Contributors table), so not sure that would get you anywhere either.

@maroider
Copy link
Member

The only sane keyboard input API on the web is fundamentally incompatible with winit's current keyboard API.

I unfortunately cannot give you an ETA on when #1888 (and thus a reasonable way of doing what you want to do) will get merged into the new-keyboard branch.

@Woyten
Copy link
Author

Woyten commented Dec 22, 2021

@maroider What about an imperfect but less broken WASM implementation? I could do the following:

  • event.code() is mapped to the scan code that was originally emitted by the keyboard. E.g. "KeyA" is mapped to scan code 30, KeyS to 31 and so on. As far as I can tell the scan codes are the same for all standardized physical keyboards under each platform.
  • event.key_code() is mapped to the corresponding VirtualKeyCode via its ASCII number s.t. 65 becomes VirtualKeyCode::A, 66 becomes VirtualKeyCode::B and so on. We could even map the modifier keys on a best-effort basis, e.g. 17 is mapped to VirtualKeyCode::LControl (or VirtualKeyCode::RControl, they are indistinguishable which should be reflected in the VirualKeyCode enum in my opinion) .

I know this is not a bullet-proof solution but the current implementation is broken in a way which prevents projects like Nannou from delivering a first-class WASM experience. The biggest impediment probably is the modifiers state not being handled correctly. As I said: I would invest some time to help making the implementation less broken.

@kchibisov
Copy link
Member

Fixed on master.

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
Development

No branches or pull requests

4 participants