@Patrick Is it possible to temporarily add a command to /rw/config/rc.local to add a second keyboard layout and set layout‑switching keys (Alt + Shift)?
The paste is hard to read. Next time, please use Code Tags.
You didn’t provide this. So I don’t know how broken your Template is. This is highly unexpected. I don’t know how you could end up without file /usr/lib/qubes/qubes-keymap.sh unless you manually deleted it?
(No. Not a indicator of compromise. Valid Compromise Indicators versus Invalid Compromise Indicators)
The way to fix this is by investigating why the Template was broken in this way or re-installing the Template. Because if this strange missing file issue can happen, then you can also have lots of other strange follow-up issues.
I reinstalled template yesterday. This file is present, but problem remains. I also think that in the rush yesterday I might have mixed up terminals and entered command in wrong window (I have many qubes). Or I tried to fix problem myself and deleted something files (I was using AI for assistance - I’ve never worked with LXQt). Right now all of my appVMs switch keyboard layouts correctly and have two languages, except for Kicksecure/Whonix. I tried to find a temporary workaround for this problem – could you help me?
I also checked whonix‑workstation template - file is present. So problem with file must have been some mistake on my part. I didn’t reinstall whonix‑workstation and qubes-gui-agent in whonix
Yes, I added Spanish layout to Kicksecure AppVM, but it was removed after a restart
How?
Run appVM, open LXQT Config Center - Keyboard and mouse - Keyboard Layout, add layout and keys to change layout, Apply
In case it’s useful, I was able to successfully reproduce this on an entirely clean installation of Qubes R4.3.0 with the Xfce desktop:
Using keyboard layout settings in dom0 Xfce:
- Set English and German as keyboard layout languages in dom0
- Set switching key to Alt+Shift in dom0
- Set Compose key to right Ctrl in dom0
- Started AppVM
personal(based onfedora-42-xfce)- I can switch between English and German in this AppVM using Alt+Shift
- Both languages seem to work right initially
- Compose key works
- Started AppVM
anon-whonix(based onwhonix-workstation-18)- I can switch between English and German in this AppVM using Alt+Shift
- Both languages seem to work right initially
- Compose key works
Using keyboard layout settings in individual AppVMs, dom0 still using Xfce:
- Reverted all keyboard layout changes in dom0, logged out of dom0 and then logged back in
- Started AppVM
personal(based onfedora-42-xfce)
Despite
- Confirmed that the keyboard layout is now stuck on US, as expected
- In the AppVM itself, set English and German as keyboard layout languages, set switching key to Alt+Shift, set Compose key to right Ctrl
- I can switch between English and German in this AppVM using Alt+Shift
- Both languages seem to work right initially
- Compose key works
- Started AppVM
anon-whonix(based onwhonix-workstation-18)- Confirmed that the keyboard layout is stuck on US, as expected
- Confirmed that I could have the keyboard layout language in
personalset to German and the keyboard layout language inanon-whonixset to English at the same time, both languages seem to work - In the AppVM itself, set English and German as keyboard layout languages, set switching key to Alt+Shift (LXQt settings didn’t allow configuring the compose key)
- I can switch between English and German in this AppVM using Alt+Shift
- Both languages seem to work right initially
- Shut down both
anon-whonixandpersonal - Started both
anon-whonixandpersonal - Tested keyboard layouts in
personal- Can still switch keyboard layout languages between English and German in this AppVM
- Both languages seem to work right initially
- Tested keyboard layouts in
anon-whonix- Cannot switch keyboard layout languages between English and German in this AppVM
(I was going to test KDE next, but this was able to be reproduced before getting to that.)
@marmarek I don’t think this is a Qubes problem (at least not all of it; the KDE weirdness might be, but the failure to preserve VM-specific keyboard layouts I think is a Kicksecure thing). Adjusting the keyboard layout settings in LXQt adjusts the configuration in ~/.config/lxqt/session.conf, which is supposed to be read by lxqt-session. lxqt-session isn’t even installed in a Qubes environment, so the component of LXQt that would restore the keyboard layout settings in this way is missing entirely.
lxqt-session was intentionally left out because it doesn’t manage the session in a Qubes environment, qubes-session does. Unsurprisingly and reasonably, qubes-session does not know how to interpret LXQt’s session.conf (or anyone else’s session config for that matter; why this works with Xfce is unclear, though I suspect xfconfd is what’s making things work). Thus something else has to do that job.
The best solution would probably be to figure out how to get lxqt-session to do only those things that are “reasonable” under Qubes OS, like loading keyboard layouts, and ignore everything else. I haven’t had much luck with this; I can start lxqt-session inside an anon-whonix AppVM, but it doesn’t seem to do anything to the keyboard layouts when launched, and its configuration options aren’t really working the way I would expect, so I don’t know how practical this is. (It’s not looking very hopeful initially :P)
As a fallback, we could write some code that could read the LXQt keyboard layout configuration and load it into X11 at startup. This is non-ideal and would be Qubes-specific since Kicksecure uses Wayland on non-Qubes platforms now, but it would work.
1 Like
Shouldn’t this be reproducible inside a Debian minimal VM too?
Why this cannot be left to /usr/lib/qubes/qubes-keymap.sh?
Yes, almost without question (I’m testing it now). Edit: Just tested, this is reproducible in debian-13-minimal after installing lxqt-config and using it to add a second keyboard layout.
Because the original poster is trying to do something fundamentally different than what qubes-keymap.sh does. qubes-keymap.sh takes the keyboard layout settings from dom0 and loads those settings into each individual qube. What the poster is trying to do is configure keyboard layouts at the AppVM level, separate from dom0. Why is somewhat unclear (maybe they want to use different keyboard layout settings in different VMs, or maybe they’re trying to work around a limitation of the KDE session, or both), but that’s what they’re doing, as I understand it. This is why they mention settings things up in LXQt’s configuration, even though dom0 doesn’t have LXQt components installed most likely.
1 Like
I can additionally confirm that even when setting keyboard layout settings in dom0, layout switching is broken when using KDE in dom0. Pressing the keyboard layout switch shortcut (Meta+Alt+K by default) results in a popup appearing in dom0 that says the keyboard layout has been changed, but the keyboard layout does not actually change within a debian-13-minimal AppVM. If I run sh -x /usr/lib/qubes/qubes-keymap.sh in a terminal window, I don’t see anything printed to the terminal when pressing Meta+Alt+K in the KDE session, so it looks like the keyboard layout change notification isn’t reaching the AppVM at all. In contrast, if I log into the Xfce session in dom0, configure a second keyboard layout, run sh -x /usr/lib/qubes/qubes-keymap.sh in a debian-13-minimal AppVM, and then press the keyboard layout change shortcut, I see some text scroll down in the AppVM terminal upon pressing the shortcut. The keyboard layout within the VM also changes, so things seem to be working properly there.
1 Like
I don’t think this is supported configuration in any way. While theoretically mismatching keyboard layouts between dom0 and VM may work in some (many) cases, it does lead to various corner cases (for example if one of those layouts assign different meaning for some modifiers, they won’t synchronize properly anymore). Keyboard layout should be modified at dom0 level.
If one wants to use different layouts in different VMs, there are dom0 applications that can switch layouts based on active window - I believe KDE has this built in, but also I get similar behavior with Xfce built-in layout switcher, if I switch layout with some window active, by clicking on the widget, not key combo.
2 Likes
- As per above discussion…
- This is not a Kicksecure issue. This issue is unspecific to Kicksecure.
- Instead, this is a bug or missing feature in Qubes.
- If you wish to pursue this further, then it must be as per Self Support First Policy by reporting this against Qubes directly.
Hi. I added various keyboard layouts to appVMs for an experiment – I tried to fix this bug in different ways.
Please check: in debian‑minimal, second keyboard layout is preserved after rebooting VM, and issue occurs only when changing layouts, or does layout disappear just like in Kicksecure/Whonix? If second layout is preserved, then Kicksecure/Whonix also have problem. If not, it’s issue specific to Qubes only.
Not a Kicksecure issue. No further action planned.