Closed mardukbp closed 3 years ago
wez
commented
3 years ago I can't reproduce this with either the current release or the nightly.
Please try the nightly release. It has a new option:
return {
debug_key_events = true,
}that will cause wezterm to log information about the keys that you are pressing.
Then start wezterm -n from a terminal so that you can see the logs, then try pressing the keys that are not behaving for you and report what is being logged in the terminal.
mardukbp
commented
3 years ago I downloaded wezterm 20201101-103216-403d002d-147-g2356be0c, created the wezterm.lua you suggested in the wezterm directory, executed wezterm -n
and no key presses were logged. I only got this:
2020-12-22T20:14:52.293Z ERROR window::os::windows::window > Initialized EGL!
2020-12-22T20:14:52.365Z INFO wezterm_gui::gui::termwindow > OpenGL initialized! ANGLE (Intel(R) UHD Grapct3D11 vs_5_0 ps_5_0) OpenGL ES 3.0.0 (ANGLE 2.1.1 git hash: 07ea804e6201) is_context_loss_possible=true Sorry, wezterm -n doesn't load the configuration file; just run wezterm
mardukbp
commented
3 years ago After pressing [ I got:
2020-12-23T10:13:45.661Z ERROR wezterm_gui::gui::termwindow > key_event KeyEvent { key: Control, modifiers: CTRL, raw_key: None, raw_modifiers: CTRL, raw_code: Some(17), repeat_count: 1, key_is_down: true }
2020-12-23T10:13:45.661Z ERROR wezterm_gui::gui::termwindow > key_event KeyEvent { key: Alt, modifiers: ALT | CTRL, raw_key: None, raw_modifiers: ALT | CTRL, raw_code: Some(18), repeat_count: 1, key_is_down: true }
2020-12-23T10:13:45.662Z ERROR wezterm_gui::gui::termwindow > key_event KeyEvent { key: Char('8'), modifiers: ALT | CTRL, raw_key: None, raw_modifiers: ALT | CTRL, raw_code: Some(56), repeat_count: 1, key_is_down: true } After pressing \ I got:
2020-12-23T10:18:56.913Z ERROR wezterm_gui::gui::termwindow > key_event KeyEvent { key: Control, modifiers: CTRL, raw_key: None, raw_modifiers: CTRL, raw_code: Some(17), repeat_count: 1, key_is_down: true }
2020-12-23T10:18:56.914Z ERROR wezterm_gui::gui::termwindow > key_event KeyEvent { key: Alt, modifiers: ALT | CTRL, raw_key: None, raw_modifiers: ALT | CTRL, raw_code: Some(18), repeat_count: 1, key_is_down: true }
2020-12-23T10:18:56.914Z ERROR wezterm_gui::gui::termwindow > key_event KeyEvent { key: Char('ß'), modifiers: ALT | CTRL, raw_key: None, raw_modifiers: ALT | CTRL, raw_code: Some(219), repeat_count: 1, key_is_down: true } That really doesn't look like a US keyboard layout. Neither of those keys require CTRL or ALT to press on a US keyboard. Is there some information missing about your configuration?
wez
commented
3 years ago You can set RUST_LOG=trace before starting wezterm to cause extra trace logging to be gathered.
Some of that will include information about the keyboard layout, and some about lower level key events.
It may be helpful, but may not.
My suspicion is that the VNC client may be doing something surprising with the keyboard input before it gets to wezterm.
mardukbp
commented
3 years ago It did not provide any extra information.
My suspicion is that the VNC client may be doing something surprising with the keyboard input before it gets to wezterm.
I ran the micro editor in Alacritty. It has a raw command that shows the key events. Pressing [ the key event is Alt-Ctrl-[. All the other keys I mentioned in this issue have the same modifiers and the characters are printed correctly.
I then ran micro in wezterm. Pressing [ the key event is Alt-Ctrl-x, ] corresponds to Alt-Ctrl-y and \ to Shift-Alt-Ctrl-_.
wez
commented
3 years ago The issue that needs to be understood is why [ shows up to Windows and thus to wezterm as you pressing the 8 key with ALT and CTRL pressed if you are using a US keyboard layout.
What are you pressing on your keyboard in this case?
When you are physically using the Windows machine (no VNC) is the behavior correct?
mardukbp
commented
3 years ago It turns out that I set the US layout in the Linux host, but not in the Windows machine. Somehow, that does not matter to any other app. For wezterm I need to set the US layout also in Windows. Using https://unixpapa.com/js/testkey.html I observed the following while pressing [ with the German keyboard layout set in Windows:
keydown keyCode=17 which=17 charCode=0
keydown keyCode=18 which=18 charCode=0
keydown keyCode=56 (8) which=56 (8) charCode=0
keypress keyCode=91 ([) which=91 ([) charCode=91 ([)
keyup keyCode=18 which=18 charCode=0
keyup keyCode=17 which=17 charCode=0
keyup keyCode=56 (8) which=56 (8) charCode=0 So it seems that wezterm uses the keydown keycode, whereas other apps use the keypress keycode.
Thank you for your help and patience @wez!
wez
commented
3 years ago FWIW, Windows doesn't have a keypress event; that's a web browser thing. Only down and up events are reported.
Which keyboard layout is active on the Windows system? If you press the same keys on the Windows system itself (no VNC) with that layout active, is the behavior correct?
mardukbp
commented
3 years ago If you press the same keys on the Windows system itself (no VNC) with that layout active, is the behavior correct?
Yes, with the US layout active on Windows the behavior is correct.
I managed to understand the difference in behavior between wezterm and the other apps. The explanation is this table for the German layout:
My guess is that the VNC Server running on Windows receives the character [, it or Windows looks it up in the table of VK codes of the active keyboard layout and generates the corresponding key event. Wezterm receives the keys Ctrl, Alt, 8, but does not interpret them as a chord (in musical terms), which would insert [.
I think it would be a good idea to add support for these key chords, since that is how other apps behave and is therefore what users expect.
wez
commented
3 years ago So, the keyboard layout is German when running under VNC? If you're using that layout without VNC, is the behavior correct? What VNC client and server software are you using? Does it offer guidance on using mismatched keyboard layouts between the client and the server?
mardukbp
commented
3 years ago If you're using that layout without VNC, is the behavior correct?
Without VNC wezterm works as expected for any given layout I have used.
What VNC client and server software are you using?
Client: Remmina Server: TightVNC
Does it offer guidance on using mismatched keyboard layouts between the client and the server?
TightVNC states the following:
The server should simulate pressing AltGr (Alt and Ctrl) to produce characters that would be entered with AltGr in current keyboard layout.
The RFC for the Remote Framebuffer Protocol states the following:
On a client where modifiers like Control and Alt can also be used to generate character-based keysyms, the client may need to send extra "release" events in order that the keysym is interpreted correctly. For example, on a German PC keyboard, Ctrl-Alt-Q generates the '@' character. In this case, the client needs to send simulated release events for Control and Alt in order that the '@' character is interpreted correctly, since Ctrl-Alt-@ may mean something completely different to the server.
I did some experiments using whichkeybind running on Alacritty and on wezterm. The keyboard layout of the Linux client is US.
Windows layout: US
The output in Alacritty corresponds with the keys I pressed. In wezterm it does not. However, the same characters are printed in the terminal.
Windows layout: Spanish Latin America
Here wezterm got a completely different event when I pressed \.
Windows layout: German
Here wezterm got two wrong key events, whereas Alacritty received the correct key events.
I do not think there is any problem with the behavior of the VNC client and server. I think it is clear that wezterm is not behaving as expected.
wez
commented
3 years ago I've pushed a commit that may help with this. Give the nightly build a try in the next hour or so.
mardukbp
commented
3 years ago It works!! Thank you so much @wez! Merry Xmas!
bew
commented
3 years ago Hello @mardukbp,
If you're still using the setup you described, you should be warned that in the next release of wezterm, the default behavior has been reverted, and you need to set treat_left_ctrlalt_as_altgr = true in your configuration to ensure your VNC session works like you want.
See #512.
mardukbp
commented
3 years ago Thanks for the info @bew!
github-actions[bot]
commented
1 year ago I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.
Describe the bug
With the US keyboard layout, I cannot insert ~,@,\,|,[,],{,} in any version of WezTerm for Windows. I tried almost all the releases.
Environment (please complete the following information):
To Reproduce
Launch WezTerm and try to enter any of those characters.
Configuration
No config file.
Expected behavior
The characters should be inserted.
Screenshots
None
Session Recording
None
Additional context
I connect to my Windows machine over VNC from a Linux host which is configured with the US keyboard layout. The keyboard works as expected in cmd.exe and GUI apps.