I’m adding a second language to layout, but it disappears after restarting qube - only one language (English) remains in layout. I tried it in both AppVM and TemplateVM/dvm (Kicksecure/Whonix), but second language always disappear. Is this a bug, or a private-function that only English to be used? Or am I doing something wrong? (First time using LXQt)
Reproducible with Debian based Qube?
Are you talking about keyboard layout? Those are normally managed at dom0 level (when set in dom0, the setting is automatically propagated to relevant qubes).
2 Likes
oh sorry. I forgot to say that I have KDE desktop installed. but this does not affect other appVMs (fedora, debian, kali, arch) - I have successfully added a second keyboard layout to all AppVMs except Whonix and Kicksecure. I have to add a second layout every time after starting Kicksecure/Whonix - layout disappears after shutdown of the vm.
Hello. This problem on KDE desktop. Debian and Fedora AppVMs work well with 2 layouts. Sorry I forgot to say about KDE
Are you using Qubes OS?
How did you install KDE desktop?
Are you using an HVM?
Is this reproducible in a similar environment Debian + KDE desktop?
Yes Qubes OS 4.3 with Kicksecure/Whonix templates. Kde installed from this guide KDE (desktop environment) — Qubes OS Documentation
Problem occurs only in Kicksecure/Whonix templates/appVM. Other VMs don’t have this issue (Debian 13, Fedora 42) - 2 layouts persist after restarting qube.
I am understanding the conditions better now.
- Qubes OS 4.3.
- Qubes with KDE installed in dom0.
- Not using HVM.
- Not installing KDE inside Kicksecure template.
What is the output of the following command - you don’t need to specifically reply and reveal the value - but does it differ from the output in unaffected VMs such as Debian VMs?
qubesdb-read /keyboard-layout
Can you confirm that file /etc/X11/xinit/xinitrc.d/qubes-keymap.sh does not exist on your system?
(That was a previous location. I do not recommend to simply delete the file if it exists. I am just trying to figure out if the upgrade path had a leftover. And if so, that would be a Qubes bug.)
Can you confirm that file /etc/xdg/autostart/qubes-keymap.desktop does exist?
Can you run sh -x /usr/lib/qubes/qubes-keymap.sh in verbose mode please and post the output here?
You can remove your actual keyboard layout from the output. I recommend using a file editor and its search function to catch all mentions.
sh -x /usr/lib/qubes/qubes-keymap.sh
Here’s the output for me (no redaction required, since well known in my case):
+ /usr/bin/qubesdb-read /keyboard-layout
+ QUBES_KEYMAP=de++
+ [ -n de++ ]
+ set_keyboard_layout de++
+ KEYMAP=de++
+ [ -z de++ ]
+ echo de+++
+ cut -f 1 -d +
+ KEYMAP_LAYOUT=de
+ echo de+++
+ cut -f 2 -d +
+ KEYMAP_VARIANT=
+ echo de+++
+ cut -f 3 -d +
+ KEYMAP_OPTIONS=
+ [ de != us -a de != si ]
+ KEYMAP_LAYOUT=de,us
+ KEYMAP_VARIANT=,
+ [ -n , ]
+ KEYMAP_VARIANT=-variant ,
+ [ -n ]
+ basename /tmp/.X11-unix/X0
+ display=X0
+ setxkbmap -display :0 -layout de,us -variant ,
+ qubesdb-watch /keyboard-layout
@marmarek The while qubesdb-watch /keyboard-layout ; do in the script might be a bit brittle? Maybe there is a race condition here?
I guess if /usr/lib/qubes/qubes-keymap.sh runs after /keyboard-layout was already written into qubesdb, it will wait forever. In other words, this script is not idempotent. Attempting to re-execute it on my system results in the script waiting forever as the qubesdb entry already exists.
qubesdb-read /keyboard-layout
Failed to read /keyboard-layout
not exis
ls /usr/lib/qubes/
cleanup-dispvms qrexec-client udev-block-remove
create-snapshot qrexec-policy-agent-autostart udev-usb-add-change
destroy-snapshot qubes-device-agent-autostart udev-usb-remove
fix-dir-perms.sh qubes-rpc uki-generate
icon-receiver qubes-rpc-multiplexer update-xfce-config
input-proxy-arg startup-misc.sh vm-modules-genfs
preload-dispvm tests
qfile-dom0-agent udev-block-add-change
file not found
1 Like
Are you using Kicksecure version 18? To test, see:
Kicksecure, systemcheck, Check Version
Was this a newly installed Kicksecure Template or a Release Upgrade?
Are you using R4,3 Qubes repositories, do you have file /etc/apt/sources.list.d/qubes-r4.list?
To check your qubes-gui-agent version:
dpkg -l | grep "qubes-gui-agent "
Output should include:
ii qubes-gui-agent 4.3.[…]
yes Qubes R4.3 last stable release, Kicksecure/Whonix 18
dpkg -l | grep "qubes-gui-agent "
ii qubes-gui-agent 4.3.15-1+deb13u1 amd64
I noticed something else – I enabled keyboard layout editing in the KDE dom0 settings and changed the order, making English the second language. Then I rebooted Qubes. After startup, Kicksecure appVM had second layout, but I couldn’t switch to it – now only layout‑switching keys no longer persist after reboot Kicksecure/Whonix appVMs.
Then I changed keyboard‑layout order again in KDE dom0 settings, putting English in the first position. After that, second layout stopped longer persist in the Kicksecure/Whonix VM again after reboot AppVMs
Perhaps this issue is related to the known problem with keyboard‑layout switching in Qubes KDE https://forum.qubes-os.org/t/cant-change-keyboard-layout-in-kde/3002
However, I somehow avoided that problem in debian/fedora VMs. My problem is only with the Kicksecure/Whonix VMs: adding second layout and keys to change layout, and persist it after reboot
It is supposed to wait forever, to apply later layout changes dynamically. The initial layout is set based on qubesdb-read you can see earlier in the output.
1 Like
Is it Wayland-based KDE or X11 one? Default instructions should install X11 one. Wayland one isn’t fully supported yet, and the layout switching is one of the missing part. Tracked here: [Build 2024101803-4.3] openQA test fails in gui_keyboard_layout under Wayland Plasma session · Issue #9517 · QubesOS/qubes-issues · GitHub
1 Like
X11 default session
1 Like
I don’t know why you’re missing file /usr/lib/qubes/qubes-keymap.sh (part of package qubes-gui-agent [1]). To investigate…
Try to check your system using debsums.
sudo debsums --silent --all
You can ignore most modified files in /etc and missing files in /boot.
Try to re-install qubes-gui-agent.
sudo apt install --reinstall qubes-gui-agent
Then see if that restores the file.
[1] Not important. Just letting you know how I was looking that up.
dpkg -S /usr/lib/qubes/qubes-keymap.sh
qubes-gui-agent: /usr/lib/qubes/qubes-keymap.sh
I reinstalled it. Yes, file is there now, but the keyboard layout issue remains after reinstalling
sh -x /usr/lib/qubes/qubes-keymap.sh
-
/usr/bin/qubesdb-read /keyboard-layout -
QUBES_KEYMAP=ru++ -
[ -n ru++ ] -
set_keyboard_layout ru++ -
KEYMAP=ru++ -
[ -z ru++ ] -
echo ru+++ -
cut -f 1 -d + -
KEYMAP_LAYOUT=ru -
echo ru+++ -
cut -f 2 -d + -
KEYMAP_VARIANT= -
echo ru+++ -
cut -f 3 -d + -
KEYMAP_OPTIONS= -
[ ru != us -a ru != si ] -
KEYMAP_LAYOUT=ru,us -
KEYMAP_VARIANT=, -
[ -n , ] -
KEYMAP_VARIANT=-variant , -
[ -n ] -
basename /tmp/.X11-unix/X0 -
display=X0 -
setxkbmap -display :0 -layout ru,us -variant , -
qubesdb-watch /keyboard-layout
It after adding second layout.
But it after restart Kicksecure appVM
sh -x /usr/lib/qubes/qubes-keymap.sh
-
/usr/bin/qubesdb-read /keyboard-layout -
QUBES_KEYMAP=us++ -
[ -n us++ ] -
set_keyboard_layout us++ -
KEYMAP=us++ -
[ -z us++ ] -
echo us+++ -
cut -f 1 -d + -
KEYMAP_LAYOUT=us -
echo us+++ -
cut -f 2 -d + -
KEYMAP_VARIANT= -
echo us+++ -
cut -f 3 -d + -
KEYMAP_OPTIONS= -
[ us != us -a us != si ] -
[ -n ] -
[ -n ] -
basename /tmp/.X11-unix/X0 -
display=X0 -
setxkbmap -display :0 -layout us -
qubesdb-watch /keyboard-layout
In this scenario command sh -x /usr/lib/qubes/qubes-keymap.sh output is repeated with two keyboard layouts, but keys for switching layouts are not persist after a reboot.
I’m not sure yet why specifically it happens, but it does look like an issue on qubes side, not kicksecure.
Just to confirm - have you done it in the template or the app qube?
1 Like
template and appVM
It seems KDE settings in dom0 affect it. Problems with layout switching appearing in other qubes, but all qubes always keep two layouts except for Kicksecure/Whonix. I notice that changing language order in KDE’s layouts begins to affect layout switching in all qubes. Restoring KDE settings re‑enables layout switching in all qubes except Kicksecure/Whonix - second layout disappears.
I see two scenarios:
- All qubes switch layouts, but Kicksecure/Whonix loses second layout after a reboot;
- Or all qubes have a second layout (including Kicksecure/Whonix), but none of the qubes can switch layouts.
1 Like