Skip to content
New issue

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

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

Already on GitHub? Sign in 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.

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

No branches or pull requests

4 participants