win32: Add keycode_to_key method for getting logical keys from physical

[Aceeri]

#2678

Looking for thoughts on this, maybe it makes more sense to have a KeyboardLayout struct that you can query, but the main usecase I (and other game devs) have for this is giving correct mappings in games.

• Tested on all platforms changed
• Added an entry to the changelog module if knowledge of this change could be valuable to users
• Updated documentation to reflect any user-facing changes, including notes of platform-specific behavior
• Created or updated an example program if it would help users understand this functionality

[kchibisov]

The problem is that on platforms like linux we'd need to have a running event loop. I'm also not sure if the function is MT safe, so implementing via global state like that won't generally work, and the function should be a method on a theoretical Keymap struct.

[Aceeri]

The problem is that on platforms like linux we'd need to have a running event loop. I'm also not sure if the function is MT safe, so implementing via global state like that won't generally work, and the function should be a method on a theoretical Keymap struct.

Gotcha, makes sense. Is the LayoutCache still usable if we were able to move this into the event loop + copy mappings over to a separate Keymap struct (stored on the Window?)? I'm not super familiar with how the main thread safeness works here tbh.

Also do you know if that applies to the appkit/macos version too (#4455)? Just trying to figure out which parts to try to salvage if I try to get this into the event loop.

[kchibisov]

Can not speak for windows here, for linux caching is useless.

[Aceeri]

Can not speak for windows here, for linux caching is useless.

As in you can't cache across frames at all? I'll take a bit of a look into the linux code, I haven't really touched it before so I'm pretty blind.

[kchibisov]

In a sense that there's no point to cache anything, you have access to the entire keymap and thus you get things from it. It could have cache internally...