Keyboard layout changes don't propagate from dom0

[hdevalence]

When the keyboard layout is changed in dom0 (e.g., using the KDE layout switcher in the icon tray) the change doesn't propagate to other VMs, in particular any VM you would actually be using.

This makes it basically impossible to (e.g., temporarily) change keyboard layouts from your default, since you have to go to every VM and manually reconfigure their input methods, and then do it all over again to change back.

[marmarek]

Does that affect also VM started after layout change?

Currently keyboard layout is set in the VM only at VM startup time. Yes,
somehow suboptimal solution...

Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[hdevalence]

Yes, VMs started after the layout change also don't inherit the (X11) keyboard layout from dom0.

[marmarek]

Did you used per-VM layout setting in those VMs? It overrides layout
retrieved from dom0.

Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[bnvk]

I've noticed weird behavior with International keyboards (I have 3 installed), most of the time when I switch to one (via clicking an icon in the main KDE navbar, it seems to do nothing. However, once in awhile, I'm able to access Int. characters by holding the Alt or Opt key and then typing certain keys!

[ghost]

What's the status for the fix? It's one of the biggest problems I've with Qubes.

[marmarek]

For now the workaround is to use per-VM keyboard layout change feature. It should work regardless of dom0 layout, and in fact dom0 layout will no longer be propagated there.

[ghost]

Marek Marczykowski-Górecki:

For now the workaround is to use per-VM keyboard layout change feature. It should work regardless of dom0 layout, and in fact dom0 layout will no longer be propagated there.

Yes it works, but it's really frustrating to switch layout (that takes
one to one and a half minute) just for writing "å", "ä", and "ö". And
then switch back to US layout then I'm finished. This happens quite
often because I write in Swedish (or simply write my name) quite often.

[marmarek]

Do you know how to install some hook on dom0 keyboard layout change? It can be anything - from registering a script somewhere, to having a tool listening on some events.

[ghost]

Marek Marczykowski-Górecki:

Do you know how to install some hook on dom0 keyboard layout change? It can be anything - from registering a script somewhere, to having a tool listening on some events.

No, I don't know how to do that. I'm guessing that it exist a solution,
but I have to do it myself?

[marmarek]

Just looking how to trigger keyboard layout change in the VM to properly fix this issue.

[tlaurion]

I Also have the same problem with "ca" keyboard.
As an example,pressing AltCar+2 is supposed to give an arobas. For some reason, that AlCar key is not working, that altcar key having the same behavior as the standard alt key.

Dom0 is set to use english keyboard. From Qubes-manager i've selected ca keyboard. No change.I also have tried changing settings through gnome-control-center without any success from inside the VM.

A writeup on how to fix that would be nice, since the FAQ is not helping the intl user in any way.
https://www.qubes-os.org/doc/user-faq/#my-keyboard-layout-settings-are-not-behaving-correctly-what-should-i-do

[tlaurion]

What is weird is that the key sequence is seen and the key are mapped ok inside xev under a qubes-manager configured keymap appvm. I do not understand why it is impossible to type the good character directly into an application.

xev output:

KeyPress event, serial 31, synthetic NO, window 0x1600001,
    root 0x266, subw 0x0, time 5866343, (-681,13), root:(64,417),
    state 0x0, keycode 108 (keysym 0xfe03, ISO_Level3_Shift), same_screen YES,
    XKeysymToKeycode returns keycode: 92
    XLookupString gives 0 bytes: 
    XmbLookupString gives 0 bytes: 
    XFilterEvent returns: False

KeyPress event, serial 31, synthetic NO, window 0x1600001,
    root 0x266, subw 0x0, time 5867038, (-681,13), root:(64,417),
    state 0x80, keycode 64 (keysym 0xffe9, Alt_L), same_screen YES,
    XLookupString gives 0 bytes: 
    XmbLookupString gives 0 bytes: 
    XFilterEvent returns: False

KeyPress event, serial 31, synthetic NO, window 0x1600001,
    root 0x266, subw 0x0, time 5867039, (-681,13), root:(64,417),
    state 0x88, keycode 11 (keysym 0x40, at), same_screen YES,
    XLookupString gives 1 bytes: (40) "@"
    XmbLookupString gives 1 bytes: (40) "@"
    XFilterEvent returns: False

KeyRelease event, serial 31, synthetic NO, window 0x1600001,
    root 0x266, subw 0x0, time 5867333, (-681,13), root:(64,417),
    state 0x88, keycode 11 (keysym 0x40, at), same_screen YES,
    XLookupString gives 1 bytes: (40) "@"
    XFilterEvent returns: False

KeyRelease event, serial 31, synthetic NO, window 0x1600001,
    root 0x266, subw 0x0, time 5868574, (-681,13), root:(64,417),
    state 0x88, keycode 108 (keysym 0xfe03, ISO_Level3_Shift), same_screen YES,
    XKeysymToKeycode returns keycode: 92
    XLookupString gives 0 bytes: 
    XFilterEvent returns: False

FocusOut event, serial 31, synthetic NO, window 0x1600001,
    mode NotifyNormal, detail NotifyNonlinear

[tlaurion]

To truely have an intl keyboard, both Dom0 and Appvm need to have the same keyboard layout applied. Else, a "can" keyboard configured only through Qubes Vm manager alone will not result in the right desired behavior, eg: pressing altcar+2 won't result in "@"character that appear when both dom0 and domu are configured to use the same layout.

It seems that dom0 selected layout needs to propagate to domu.

[marmarek]

It seems that dom0 selected layout needs to propagate to domu.

Exactly why I'm looking for a way of getting a notification when dom0 keyboard layout is changed.

[marmarek]

An idea: watch _XKB_RULES_NAMES property on root window. But first requires a verification if that's part of official API, not an implementation detail (which may work with some tools but not others).

[ghost]

(copy/paste from a reply in the dev ML)

the following workaround has been working well for me for many years, in stock fedora and now in Qubes: in a terminal in dom0, type the following (obviously replace the bg(phonetic) version with whatever layout you're using)

setxkbmap -layout "us,bg(phonetic)" -option "grp:shifts_toggle"

then you'll be able to press both shift keys to switch the layout in specific VMs.

you can automate this by putting this line in a script called by the window manager during startup.

caveats:

• no layout notification; not a problem for me, if you don't remember which layout you've enabled, in the worst case you'll type a letter, see that you're in the wrong layout, press both shift keys, and continue. It takes 1 second.
• my biggest gripe: when the screensaver kicks in (xscreensaver here), there's no way to know in which layout you're typing your password. Typing your English password with - say - Cyrillic letters will obviously fail, so you'll have to press both shift keys and try again.

[modulistic]

After some frustration with a fresh qubes R3.2 install with stock XFCE, I found the "right" way to set the (xorg) system-wide keyboard layout (and options); This feels like a work-around for me, but anyway:

In Q → System Tools → Keyboard → Layout, leave the checkbox Use system defaults checked. Do not customize the keyboard layout here.

Set the system-wide layout and options for xorg with the localectl command in dom0. You can use localectl --help as a starting point.

Example: localectl set-x11-keymap us dell ,qwerty compose:caps.

This generates the appropriate configuration in /etc/X11/xorg.conf.d/00-keyboard.conf.

Restarting xorg is required. The easy way is to reboot the system.

I just opened a PR that adds this explanation to the FAQ.

BTW, I've been unable to figure how the current layout is propagated from dom0's xorg to the other VMs, along with others such as the display geometry. It would be nice to have this explained somewhere in the documentation, even if it is in the developer documentation.

[bashlund]

I noticed you poppin by @holiman, so I though it's time to share a snippet which works good as a workaround on this issue :)
The ideas to the snippet come from this thread.
It solves the problems by the user hitting a keyboard shortcut and the script then sets the keyboard layout in all VMs.

Whenever my layout totally breaks I just hit the shortcut two times to get back to the layout I was using, so it solves the issue of layout which stop working and also propagating layouts from dom0.

See the script header for details on how to set it up. The script must be copied to dom0, but no install are necessary.

https://gist.github.com/bashlund/90f097d5ffea3c5a8c7ffd13867b5cb3

[marmarek]

The layout switching involves several parts:

1. qvm-start-daemon monitors _XKB_RULES_NAMES and XKLAVIER_ALLOW_SECONDARY properties on the root window ( you can check with xev -root -event property if they change)
2. Then, it adjusts keyboard_layout property on dom0 (check with qvm-prefs dom0 keyboard_layout)
3. Then, it's transferred using qubesdb to relevant VMs, where qubes-keymap.sh script should monitor it and apply the change (check process list in the VM to see if it runs)

[holiman]

Interesting!

As far as I can tell, it's 1) which is failing. If I switch layout, then indeed it works in dom0, but the qvm-prefs dom0 keyboard_layout does not change. The xev -root -event property only reacts when the cursor moves from one application screen to another.

At this point, I exited i3, and started an xfce session instead. In xcfe, the xev -root -event property did emit XKLAVIER_ALLOW_SECONDARY events, which updated the qvm-prefs, and the whole chain worked.

[jamke]

The layout switching involves several parts:

1. `qvm-start-daemon` monitors `_XKB_RULES_NAMES` and `XKLAVIER_ALLOW_SECONDARY` properties on the root window ( you can check with `xev -root -event property` if they change)

2. Then, it adjusts `keyboard_layout` property on dom0 (check with `qvm-prefs dom0 keyboard_layout`)

3. Then, it's transferred using qubesdb to relevant VMs, where `qubes-keymap.sh` script should monitor it and apply the change (check process list in the VM to see if it runs)

@marmarek
Thank you for this valuable piece of information!
Is it documentation somewhere? I want to investigate and fix #8035, but could not find documentation how layout switching works in R4.1. I mean your reply explains a lot, but maybe it is explained somewhere else too?

And why XKLAVIER_ALLOW_SECONDARY exactly? I tried to search for it and it seems that Qubes OS is almost the only somewhat popular project that relies on XKLAVIER_ALLOW_SECONDARY (I can easily be wrong about this).

[gangamstyle]

Debugging:

1. qubesdb-watch /keyboard-layout in guests returns nothing, and this prevents layout update in guests
2. qvm-prefs dom0 keyboard_loyout in dom0 returns nothing

Script that tracks layout changes in dom0 and updates keyboard_layout for qvm-prefs:
/usr/lib/python3.8/site-packages/qubesadmin/tools/qvm_start_daemon.py
It listens to X events using xcffib library https://github.com/tych0/xcffib and that library may be bugged.

[gangamstyle]

@marmarek can you please check if this pull request QubesOS/qubes-core-admin-client@b99e45f can be affected by suspend/resume (this starts the bug)

[sysfu]

I'm troubleshooting an issue whereby dom0 keyboard layout and setxkbmap options are being ignored by a Windows 7 Qube. All linux Qubes do not have this issue and respect both dom0 keyboard layout and setxbkmap -options ctrl:nocaps setting.

Forum thread with the troubleshooting steps I've taken so far, maybe it's due to this same bug?

[jamke]

I'm troubleshooting an issue whereby dom0 keyboard layout and setxkbmap options are being ignored by a Windows 7 Qube.

I have Windows 10 for a while that does not care about keyboard layout of other qubes, including dom0. Is the propagation expected to work with Windows qubes at all?

[sysfu]

I'm troubleshooting an issue whereby dom0 keyboard layout and setxkbmap options are being ignored by a Windows 7 Qube.

I have Windows 10 for a while that does not care about keyboard layout of other qubes, including dom0. Is the propagation expected to work with Windows qubes at all?

I did some more research and believe this is due to missing Qubes Windows Tools. They were replaced with a dummy file around August 2023 on account of a Xen driver CVE.

You can manually downgrade to qubes-windows-tools-4.1.69 (for Qubes OS v4.2) but the updater will replace it with the dummy file again if you're not careful.

[jamke]

Without QWT it will not propagate for sure. I have QWT and it still never propagated on Win10 for me, so, I am not sure it should.

[marmarek]

I don't think keyboard layout switching is implemented in QWT yet.

…

-- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab

[tlaurion]

@andrewdavidwong is this fixed in 4.2?

[andrewdavidwong]

@andrewdavidwong is this fixed in 4.2?

No idea. All I know is that no one has reported that it affects 4.2 so far.

If anyone can confirm that it still affects 4.2, please leave a comment here saying so.

[alimirjamali]

@andrewdavidwong is this fixed in 4.2?

It is currently broken on my r4.3 system (X11, dom0 as GUIVM, Dedicated audiovm) on Fedora 41 XFCE guests. There has been a noticeable delay which made the qvm-start-daemon layout change detection and propagation mechanism almost useless.

This issue is already very long and confusing. I believe it would be better to pin-point other bugs and file new issues.

Some related issues: #9517, #8109

[andrewdavidwong]

It is currently broken on my r4.3 system (X11, dom0 as GUIVM, Dedicated audiovm) on Fedora 41 XFCE guests.

Okay, thanks for the report. I'll assume it still affects both 4.2 and 4.3, then.

This issue is already very long and confusing. I believe it would be better to pin-point other bugs and file new issues.

Some related issues: #9517, #8109

Good point. Let's do that.

[github-actions]

This issue has been closed as "not applicable." Here are some common examples of cases in which issues are closed as not applicable:

• Help and support requests (please see Help, support, mailing lists, and forum)
• Questions (please see Help, support, mailing lists, and forum)
• Discussion issues (please see Help, support, mailing lists, and forum)
• Bug reports for behavior that is already working as intended
• Enhancement requests to improve things that are already working as intended
• Issues that rest on mistaken assumptions or misunderstandings
• Issues that do not provide enough information
• Issues that are not actionable

We respect the time and effort you have taken to file this issue, and we understand that this outcome may be unsatisfying. Please accept our sincere apologies and know that we greatly value your participation and membership in the Qubes community.

Regarding help and support requests, please note that this issue tracker (qubes-issues) is not intended to serve as a help desk or tech support center. Instead, we've set up other venues where you can ask for help and support, ask questions, and have discussions. By contrast, the issue tracker is more of a technical tool intended to support our developers in their work. We thank you for your understanding.

If anyone reading this believes that this issue was closed in error or that the resolution of "not applicable" is not accurate, please leave a comment below saying so, and we will review this issue again. For more information, see How issues get closed.

[tlaurion]

Someone having an understanding of the current issue could start a new issue then @andrewdavidwong @alimirjamali ?

I just gave up with ca-fr keyboard, never was able to make it work. I guess nobody can make it work either.

@marmarek I guess a pointer to an already existing and more pertinent issue then this one being 9yo would be beneficial to last comment of this thread then, and then lock it.

[holiman]

This is still an issue for me, Qubes R4.2.3, Kernel 6.6.63-1, with i3wm` window manager.

The investigation I posted here is, afaik, still correct.

---

Using two workarounds like this instead:

$ cat ~/bin/english 
setxkbmap -keycodes "evdev+aliases(qwerty)" -layout "us" -model pc105