support win32-input-mode on Linux

[unxed]

What Operating System(s) are you seeing this problem on?

Linux X11

Which Wayland compositor or X11 Window manager(s) are you using?

Muffin

WezTerm version

20230330-214948-d1c2257b

Did you try the latest nightly build to see if the issue is better (or worse!) than your current version?

Yes, and I updated the version box above to show the version of the nightly that I tried

Describe the bug

echo -e "\x1B[?9001h"; read should enable win32-input-mode so key events are reported like this: ^[[83;0;115;1;32;1_
But this does not happen in Linux version, keys are still reported as in all classic *nix terminals.

To Reproduce

1. Run wezterm --config allow_win32_input_mode=true on X11 Linux
2. Paste string echo -e "\x1B[?9001h"; read
3. Press Enter
4. Press any key

Configuration

no config

Expected Behavior

win32-input-mode should be enabled after \x1B[?9001h

Logs

No response

Anything else?

No response

[wez]

win32_input_mode only works on Windows, because it requires passing through Windows-specific numbers generated by Windows input events

[unxed]

I wrote a small library that uses publicly available data to translate X11/Wayland XKB keycodes into Windows keycodes. There is also a sample application that demonstrates how to use that library to generate correct win32-input-mode escape sequences based on X11 keyboard events. I hope this will help implement support for the win32-input-mode on any platform that has X11 or Wayland available.

https://github.com/unxed/xkb2win

[wez]

Thanks! I'm a bit of a skeptic though because even on Windows, generating the correct events has proven difficult.
In addition, Wayland is similar but slightly different from X11, and the input method editor configured by the user can be a source of problems. And lastly, this doesn't cover macOS.

I'm not sure that the code you've shared is sufficient to cover all the cases expected on windows; it feels too short and simple compared to the weird issues I've already have to debug on windows! :-)

It might be interesting for you to verify that by ssh'ing into a Windows host and running traditional win32 console programs like Far Manager and see if all the key combinations are supported correctly.

[unxed]

It might be interesting for you to verify that by ssh'ing into a Windows host and running traditional win32 console programs like Far Manager and see if all the key combinations are supported correctly.

Already did it. I asked my friend who uses Windows Terminal to test Linux port of Far Manager (it has recently added the support for win32-input-mode) running in Windows Terminal under WSL. Everything works as it should, with the exception of a mouse input bug on Windows Terminal side, issue has been submitted.

As for Wayland's possible oddities, I'd be happy to accept PR to the xkb2win library if anyone can test it under Wayland and fix any bugs found under it. As you can see, xkb2win uses xkbcommon library for getting keysyms, so it should be compatible with Wayland which use xkbcommon also. The very close keycode translation was recently added to the wxWidgets cross-platform UI framework, and if there are any problems with it under Wayland, we will probably find it out soon.

As for MacOS, I suspect we will have to write separate code if wezterm works there not through x11, but through the native API. Unfortunately, I don't have a Mac at hands to explore its API and come up with a solution, but again, I'll gladly accept help from people who have one.

Can we leave this issue open for now so other people who are also interested in the solution can see it?

[wez]

Sure, we can track this as an enhancement request. The library doesn't help me as-is, and I don't see myself having time to port it into wezterm any time soon.

[unxed]

For others who are interested in the same feature: almost equivalent UX can be achieved using kitty's enhanced keyboard mode which WezTerm fortunately supports on non-Windows platforms. Converting from kitty's esc sequences to Windows-like KEY_EVENT_RECORD is also not a hard task.