Key codes vs Scan codes

[macbrayne]

This project currently supports a subset of ASCII and most of the modifier keys like CTRL and SHIFT. But on other keyboard layouts it provides incorrect mappings, e.g. QWERTZ ö translates to Grave instead of the umlaut (this is mentioned in the project
files). This is to be expected as i.e. the Win32 API only labels them as "OEM keys", the linux kernel on the other hand labels this key as GRAVE instead.
However if the mappings are US-QWERTY only they are currently inconsistent as the crate/Windows does translate the ASCII keys (like z vs y in QWERTZ) between locales (at least on windows) due to windows probably pre-processing the keys (I couldn't find any information online on this).
I have not researched the APIs as to why they label it differently but this problem on begs the question:

How "high-level" is this crate? Should this crate reporting the key position or the user facing value of the key? If yes, should or can they be localized?

[macbrayne]

I don't actually know if this can be fixed, because the problem is inherently linked with using (virtual) keycodes instead of scan codes, however both have their own set of problems: With scan codes numlock state is not being considered when providing the code whereas keycodes are half-localised and keyboard layout dependent.

[ostrosco]

My thought was always that the library should report the user facing value of the key. I'm pretty confident that's how what most users are expecting the library to do. I would love to localize to support other languages besides English but I haven't given any thought on the best way to do that.