support customized keyboard layout (with KLC file)

[hwdef]

Is your feature request related to a problem? Please describe.

I use dvorak keyboard layout, and I can not find a way to change the wslg keyboard from qwerty to dvorak

Describe the solution you'd like

Describe alternatives you've considered

Additional context

[susannemoog]

You could try calling setxkbmap us dvorak-alt-intl -model pc102 - that worked for me (see https://susi.dev/dev-env-2020 at the bottom for my solution from last year, seems to continue working with wslg).

[hwdef]

@susannemoog
ok, thank you!😃

[viniavila]

You could try calling setxkbmap us dvorak-alt-intl -model pc102 - that worked for me (see https://susi.dev/dev-env-2020 at the bottom for my solution from last year, seems to continue working with wslg).

This just worked for Qt programs, Gnome programs requires layout change in weston.ini, but when changing /mnt/wslg/.config/weston.ini (which is the file weston.log says is consulted) nothing happens

[cpbotha]

Indeed, some applications work through xwayland and then weston (the wayland compositor), and therefore the setxkbmap invocation works, but other (wayland-compatible) applications go directly through weston.

If anyone has any tips as to changing weston's keyboard layout (via the weston.ini suggested by @viniavila for example) I would be grateful.

[cpbotha]

I have figured out a hacky way of changing the Wayland (weston) keyboard layout.

In short, you can edit weston.ini in the hidden wslg system instance and then send the weston process a HUP signal so it reloads this new config.

Step by step:

1. enter the WSLg system instance by doing wsl..exe --system

2. cat /home/wslg/.config/weston.ini to see the current config, it should look like this:

[xwayland]
disable_access_control=true

[input-method]
path=

3. Add the relevant keyboard layout variables. In my case I want dvorak: echo -e "\n[keyboard]\nkeymap_layout=us\nkeymap_variant=dvorak\n" >> /home/wslg/.config/weston.ini

4. Confirm that the weston.ini now looks something like this:

[xwayland]
disable_access_control=true

[input-method]
path=

[keyboard]
keymap_layout=us
keymap_variant=dvorak

5. Tell the weston process to restart by sending it the HUP signal: pkill -HUP weston (this will restart it, so any gui apps of yours will be killed)

Wayland apps you start during this session will use the new keymap. If I understand the docs correctly, the WSLg system instance is ephemeral, so the next time you restart wsl (with --shutdown) or reboot your machine, you'll have to do it again.

For extra credit, build your own WSLg system distro and use that. ;)

[hideyukn88]

@cpbotha , thanks for write up! actually weston should be trying to "sync" the keyboard layout based on what Windows client software (RDP client) reports.

For example, when I use with Japanese keyboard, Windows reports like below (logged in weston.log).

     [12:08:56.935] kbd_layout:0xe0010411 kbd_type:0x7 kbd_subType:0x2 kbd_functionKeys:0xc

And RDP backend in weston will try to match above to rules in Xkb.

      [12:08:56.935] convert_rdp_keyboard_to_xkb_rule_names: matching layout=jp variant=(null)

And Xkb will compile matching layout (below is debug output from Xkb if enabled).

    xkbcommon: DEBUG: Compiling from RMLVO: rules 'evdev', model 'jp106', layout 'jp', variant '(null)', options '(null)'
    xkbcommon: DEBUG: Compiling from KcCGST: keycodes 'evdev+aliases(qwerty)', types 'complete', compat 'complete+japan', symbols 'pc+jp+inet(evdev)'

And for US-dvorak case, it should be like below.

    [12:29:59.328] kbd_layout:0x10409 kbd_type:0x4 kbd_subType:0x0 kbd_functionKeys:0xc
    [12:29:59.328] convert_rdp_keyboard_to_xkb_rule_names: matching layout=us variant=dvorak

    xkbcommon: DEBUG: Compiling from RMLVO: rules 'evdev', model 'pc102', layout 'us', variant 'dvorak', options '(null)'
    xkbcommon: DEBUG: Compiling from KcCGST: keycodes 'evdev+aliases(qwerty)', types 'complete', compat 'complete', symbols 'pc+us(dvorak)+inet(evdev)'

And above should have same effect as configuring at weston.ini. Thus, when "auto-sync" doesn't work, there is 3 possibilities, I think.

1: The layout Windows Client software reported doesn't match your settings in Windows (but this is very unlikely, I think).
2: RDP-backend failed to convert or convert to wrong Xkb settings.
3: The corresponding Xkb rules (and etc) is not installed in system-distro. (but this doesn't apply to your case since configuring weston.ini does fix it).

Would you please take a look your weston.log to see what Windows client reports and what Xkb rules RDP-backend covert to ?

Thank you very much for trying out WSLg and helping us!

[cpbotha]

Would you please take a look your weston.log to see what Windows client reports and what Xkb rules RDP-backend covert to ?

Thank you very much @hideyukn88 for spending your time on this, and explaining this mechanism.

I just checked my weston.log and see this:

[07:27:59.623] kbd_layout:0xa0010409 kbd_type:0x2110110 kbd_subType:0x2 kbd_functionKeys:0xc

The text convert_rdp_keyboard_ is nowhere to be found in the weston.log.

This is very possibly because I use the dvaltint keyboard layout from [1], a special Dvorak layout with no dead keys that supports AltGr as a compose key, so I can also type the diacritics I need in Afrikaans ad Dutch (ô, ï, ë, for example).

Is there any way for me to modify that keymap (I have the KLC file) so that WSLg does recognize it as layout US variant Dvorak, or maybe some other approach?

[1] http://keyboards.jargon-file.org/ see "United States-Dvorak International Alternate"

[hideyukn88]

@cpbotha , thanks for checking out and explaining your issues, so in summary...

1: Since you are using customized keyboard layout (using KLC file), the kbd_layout and kbd_type (which Windows reports to WSLg) are not standard one defined in Remote desktop protocol (below link), thus those can't be recognized by RDP-backend, and it ends up not changing anything, left as default English layout, or as you do, configured with the override from weston.ini.

https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-rdpbcgr/00f1da4a-ee9c-421a-852f-c19f92343d73

2: Since you are using customized keyboard layout, does override by weston.ini give you exactly what you have in Windows side? I image it is not since that weston config sets Xkb to standard English Dvorak layout, not which might not match perfectly with your customized one, am I right?

Thus the possible solutions are...

a: Offer a way to override keyboard layout which can remain across WSL restarts, which eliminate the needs to update weston.ini every time. This sounds workaround, but it helps a lot, I guess. This also helps when the match done by RDP-backend is not exactly what user want.

b: Offer a way to configure Xkb with custom Xkb configuration files, thus if user has non-standard layout, which is not available at system-distro by default, they have an option to configure it and apply using solution a:

c: (very unlikely to be done, but ideally better) When custom keyboard layout file are being used in Windows side, auto generate Xkb configuration from KLC (or any other source) if necessary, and auto apply it.

We will continue to explore more options for solution, please feel free to send us feedbacks!

[hideyukn88]

@hwdef, as I commented above (#173 (comment)), would you please check weston.log and see what layout is reported from Windows and being converted for Xkb? thanks!

[hwdef]

@hideyukn88

Sorry, I don't have a wslg environment anymore and can't test it for you

[cpbotha]

2: Since you are using customized keyboard layout, does override by weston.ini give you exactly what you have in Windows side? I image it is not since that weston config sets Xkb to standard English Dvorak layout, not which might not match perfectly with your customized one, am I right?

You are right, it does not match perfectly, but for my purposes it's good enough. In any case, I can customise XKB as I usually have to do on my Linux setups in any case.

Thus the possible solutions are...
a: Offer a way to override keyboard layout which can remain across WSL restarts, which eliminate the needs to update
b: Offer a way to configure Xkb with custom Xkb configuration files, thus if user has non-standard layout, which is not
c: (very unlikely to be done, but ideally better) When custom keyboard layout file are being used in Windows side, auto generate Xkb configuration from KLC (or any other source) if necessary, and auto apply it.

I would personally be happy with any of these!

Thank you again!