Winit: Windows not sending characters with alt/control held

[chrisduerr]

It appears that when pressing characters while holding alt or ctrl on windows, the ReceivedCharacter is not triggered for that specific character. However all other platforms seem to emit the pressed character.

For Alacritty this distinction is quite important, since alt can be sent to send escapes directly to the terminal.

This has been reported to Alacritty in https://github.com/jwilm/alacritty/issues/1939.

[chelmich]

I tested this with the window example on both v0.20 and v0.19. It looks like the correct key is reported with alt: true in the ModifiersState struct. This makes me think the issue is downstream unless I'm missing something.

[chrisduerr]

KeyboardInput and ReceiveCharacter are two different things. The problem is with ReceiveCharacter, which will never have any mods attached to it.

[chelmich]

My bad. I'm still learning how to use winit. I was also confused because I couldn't find ReceiveCharacter anywhere. It's apparently actually ReceivedCharacter. I was able to recreate the bug on Windows. I also tested on X11 and the bug was not present as suggested in the original post.

[chelmich]

Okay, I did a little digging and it looks like alt key characters are handled as winuser::WM_SYSCHAR. It shouldn't be too hard to handle those along with WM_CHAR, although I'm not exactly sure what the details should be. Replacing

winuser::WM_CHAR => {

with

winuser::WM_CHAR | winuser::WM_SYSCHAR => {

seems to work, but that may cause other unwanted behavior.

[Osspial]

@chelmich Thank you so much for investigating this!

As far as I can tell, that wouldn't cause any issues. Since you figured out the solution, would you like to submit a PR implementing that change?

[chrisduerr]

According to https://github.com/jwilm/alacritty/issues/2908, it seems like not only Alt, but Control is having the same issue.

Since alt can be used for alternative characters, that might not necessarily be the same issue, but I thought we can try to fix either one and see if it resolves the other. If that doesn't do the trick I can still open a separate issue.

[Osspial]

@chrisduerr I don't think the control key issue is a problem in Winit. Even on master, pressing ctrl+key outputs a character value - albeit a different character value. It seems like Windows does some additional character filtering when control keys are pressed.

[chrisduerr]

Well in theory, only because master doesn't work, doesn't mean it's not a bug in winit, right?

I have obviously no clue about ReceivedCharacter handling on Windows, but I don't see why applications wouldn't be able to get the keycode of a character plus control? Saying "it's not possible" seems a bit strange to me in this scenario.

[Osspial]

@chrisduerr because the OS only reports the control character. Keycode->character processing is a complex issue that changes based on user configuration and it's not Winit's place to step in and do additional processing on top of the OS.

Anyway, I did some investigation and it looks like this may be a keyboard layout problem.