Change of keyboard layouts with Capslock/Shift+Capslock (shift_caps_switch in setxkbmap) breaks all the time

[jamke]

Qubes OS release

R4.1.1.

Brief summary

Switching 2 keyboard layouts with Capslock for the first layout and Shift+Capslock for the second one (shift_caps_switch group in setxkbmap) is not working properly and breaks many times a day.

Steps to reproduce

• During system installation add a second layout and set layout switch hotkey to Capslock for first layout and Shift+Capslock for the second one (shift_caps_switch group in setxkbmap)
• Use the system normally.

Note: Also settings this mode after installation with a single English layout has the same results.

Expected behavior

Layout switch works.

Actual behavior

After some time layout switch stops working completely. Very often and very annoying.
The way to temporary fix the issue is to press capslock and shift+capslock several times in some order, to exit some kind of wrong state of Qubes OS keyboard layout scripts. But soon the layout switching gets broken again.

More

R4.0 worked fine, so this bug is a 100% regression.

[andrewdavidwong]

#6517 wasn't mentioned here, but it appears to be related.

[jamke]

#6517 wasn't mentioned here, but it appears to be related.

I provided feedback there before, it can be related, thank you.
On the other hand, it seems to be a different bug, because the combination is not one-button one, so I made a separate issue.

[jamke]

Not only do I have not working layout change but also sometimes the layouts change places: shift+capslock changes to the first one and capslock to the secocnd. But most of the time layout changes are not working completely.

Something very wrong happens with layout change in R4.1 compared to R4.0 in the case of shift_caps_switch mode. I think, after some time of using Qubes OS the layouts of dom0, qubes scripts and running qubes are un-synchronized and I get like 6-12 virtual layouts (but only 2 languages of course) that are changed in complicated way (not toggling between 2 as expected). Maybe it's somehow connected with the fact that shift_caps_switch is not toggling, but going to the end (last) and to the start (first) of layouts. @marmarek can it be the case? Can I somehow diagnose and fix it?

[unman]

On Tue, Feb 21, 2023 at 05:57:35AM -0800, jamke wrote: Not only do I have not working layout change but also sometimes the layouts change places: shift+capslock changes to the first one and capslock to the secocnd. But most of the time layout changes are not working completely. Something very wrong happens with layout change in R4.1 compared to R4.0 in the case of `shift_caps_switch` mode. I think, after some time of using Qubes OS the layouts of `dom0`, qubes scripts and running qubes are un-synchronized and I get like 6-12 virtual layouts (but only 2 languages of course) that are changed in complicated way (not toggling between 2 as expected). Maybe it's somehow connected with the fact that `shift_caps_switch` is not toggling, but going to the end (last) and to the start (first) of layouts. @marmarek can it be the case? Can I somehow diagnose and fix it?

Not an Xfce user, but I recall that there are bugs in using setxkbmap of late. Have you checked to see if this is Xfce version, rather than Qubes?

[jamke]

Not an Xfce user, but I recall that there are bugs in using setxkbmap of late. Have you checked to see if this is Xfce version, rather than Qubes?

Thanks for reply. I am using the layout switching settings installed by the installation process of the system, as I expected it to be the proper or at least the most expected way. Managing of layouts by XFCE is disabled in XFCE settings (Use system defaults is checked).
On previous Qubes OS instances I also had the same issue, and I tried:

• using XFCE layouts (not recommended approach, I think),
• use localectl to regenerate xorg config (saw it being recommended in docs or on github somewhere)
  and nothing helped.

While shift_caps_switch worked properly on R4.0, on R4.1 it is such a daily pain, that it should be considered unusable...

[jamke]

Have you checked to see if this is Xfce version, rather than Qubes?

If there is a way to make checks you mentioned - please tell, I will try them.

[jamke]

• use localectl to regenerate xorg config (saw it being recommended in docs or on github somewhere)

This is what I was talking about: https://www.qubes-os.org/doc/hardware-troubleshooting/#keyboard-layout-settings-not-behaving-correctly

[kalkin]

I have a similar issue. I'm using localetctl to setup switching between us/ru when pressing both Shift keys. Sometimes it works sometimes the switch between layouts is not forwarded to all VMs. Also a big issue is that Xscreensaver doesn't show the layout currently used.

[jamke]

Also a big issue is that Xscreensaver doesn't show the layout currently used.

You can use this script to overcome this limitation of xscreensaver: https://forum.qubes-os.org/t/force-xscreensaver-to-show-itself-on-specific-display/18200/13

Have you somehow fixed the issue this layout toggle?
I still have the issue and dream to fix it somehow.

[jamke]

I will try to modify qvm_start_daemon.py locally in dom0 to get more information about what is happening and what is wrong, because I have layout switch problem every day.

[jamke]

I found out that in my situation, when I use 2 layouts (lets call them us and AA) and a shift_caps_switch for switching the problem is that XKLAVIER_ALLOW_SECONDARY is not fired when it should be.

The situation during the problem happening:

1. In some qube I have active layout AA, I press capslock once, or multiple times to switch to us but it does nothing. And /usr/bin/qubesdb-read /keyboard-layout always shows: AA++grp:shift_caps_switch and actually types chars from AA. So, qubes-keymap.sh works properly, it's just that qubesdb does not have changed layout.
2. In dom0 it also type AA chars, and not us chars, so the effective layout it AA.
3. I checked xev -root -event property in dom0 and NOTHING is fired when I press capslock. That's the reason!
4. hen I pressed shift+capslock I see finally XKLAVIER_ALLOW_SECONDARY event.

So, why XKLAVIER_ALLOW_SECONDARY?
So, I think the problem is that XKLAVIER_ALLOW_SECONDARY it supposed to be fired only on change of layout and something (libxklavier?) in dom0 mistakenly thinks that I am trying to set layout to the same one (and not change it).
Is it possible to replace this event with something better, maybe something that is reliably called on any layout shortcut change event (even if the layout stays the same like us -> us)?

[jamke]

As a temporary work-around - I can bind capslock and shift+capslock to global shortcuts and change the layout manually using xbk-switch, but in this case I need to somehow fire XKLAVIER_ALLOW_SECONDARY event, so the Qubes OS script will propagate layout inside qubes.

Is there a way to fire XKLAVIER_ALLOW_SECONDARY manually?

I tried it without manual fire (and rely on automatic firing), it works but also breaks at some moment. Because the problem is with this event firing mechanism gets confused all the time and does not work reliably and properly.

[kalkin]

Also a big issue is that Xscreensaver doesn't show the layout currently used.

You can use this script to overcome this limitation of xscreensaver: forum.qubes-os.org/t/force-xscreensaver-to-show-itself-on-specific-display/18200/13

I just glanced over it, it looks like you suggest having a script switching the layout when xscreensaver is locked? This might work. Thanks.

Have you somehow fixed the issue this layout toggle?
Nop. I also have not debugged this topic any further (too little time, too much code to write...)

So, I think the problem is that XKLAVIER_ALLOW_SECONDARY it supposed to be fired only on change of layout and something (libxklavier?) in dom0 mistakenly thinks that I am trying to set layout to the same one (and not change it).

Nice work debugging this issue! Have you already discovered https://github.com/QubesOS/qubes-core-admin-client/blob/v4.1.30/qubesadmin/tools/qvm_start_daemon.py ? May be this can help you on your quest.

[jamke]

I just glanced over it, it looks like you suggest having a script switching the layout when xscreensaver is locked? This might work. Thanks.

Yes, and it does work, I am using it.
Trick with mouse movement for unlock desktop selection also works.

Nice work debugging this issue! Have you already discovered qvm_start_daemon.py?

Yes, we all have this file in dom0, here:
/usr/lib/python3.8/site-packages/qubesadmin/tools/qvm_start_daemon.py
I mentioned this file above (#8035 (comment)). Or maybe you mean something different, do you?

Anyway, problems with switching keyboard layouts in R4.1 are still not fixed, it's just now I know a bit more about how it's supposed to work (and quite often works).

[jamke]

OK, now I can 100% reproduce 2 different bugs related to this issue.

Good news is that I managed to workaround the issue by modification of /usr/lib/python3.8/site-packages/qubesadmin/tools/qvm_start_daemon.py in my system.

@marmarek @strugee @DemiMarie maybe you can help me to understand, why Qubes OS R4.1 is propagating ALL xkb options inside the target qubes? Including shortcuts for switching keyboard layout. I mean the whole point is that xkb inside the qube IS NOT changing keyboard layout itself, isn't it?
Because currently it breaks keyboard layout switch all the time. But if I block propagation of options (making layout unchangeable inside the qube by itself) everything works for me quite well.

So, maybe stripping options that are related to the shortcuts of layout switching should be added to qvm_start_daemon.py out of the box.

[marmarek]

I mean the whole point is that xkb inside the qube IS NOT changing keyboard layout itself, isn't it?

Right!

So, maybe stripping options that are related to the shortcuts of layout switching should be added to qvm_start_daemon.py out of the box.

Yes, I think this is the right way to go.

[qubesos-bot]

Automated announcement from builder-github

The component core-admin-client (including package core-admin-client) has been pushed to the r4.2 testing repository for the Fedora template.
To test this update, please install it with the following command:

sudo dnf update --enablerepo=qubes-vm-r4.2-current-testing

Changes included in this update

[qubesos-bot]

Automated announcement from builder-github

The component core-admin-client (including package core-admin-client) has been pushed to the r4.2 testing repository for the Fedora template.
To test this update, please install it with the following command:

sudo dnf update --enablerepo=qubes-vm-r4.2-current-testing

Changes included in this update

[andrewdavidwong]

Closing as resolved. If anyone believes this issue is not yet resolved, or if anyone is still affected by this issue, please leave a comment, and we'll be happy to reopen it. Thank you.

[qubesos-bot]

Automated announcement from builder-github

The package core-admin-client has been pushed to the r4.2 stable repository for the CentOS centos-stream8 template.
To install this update, please use the standard update command:

sudo yum update

Changes included in this update

[qubesos-bot]

Automated announcement from builder-github

The package core-admin-client has been pushed to the r4.2 stable repository for the Debian template.
To install this update, please use the standard update command:

sudo apt-get update && sudo apt-get dist-upgrade

Changes included in this update

[qubesos-bot]

Automated announcement from builder-github

The package core-admin-client has been pushed to the r4.2 stable repository for the Debian template.
To install this update, please use the standard update command:

sudo apt-get update && sudo apt-get dist-upgrade

Changes included in this update

[qubesos-bot]

Automated announcement from builder-github

The component core-admin-client (including package core-admin-client) has been pushed to the r4.2 stable repository for the Fedora template.
To install this update, please use the standard update command:

sudo dnf update

Changes included in this update

[qubesos-bot]

Automated announcement from builder-github

The component core-admin-client (including package core-admin-client) has been pushed to the r4.2 stable repository for the Fedora template.
To install this update, please use the standard update command:

sudo dnf update

Changes included in this update

[qubesos-bot]

Automated announcement from builder-github

The package core-admin-client has been pushed to the r4.2 testing repository for the CentOS centos-stream8 template.
To test this update, please install it with the following command:

sudo yum update --enablerepo=qubes-vm-r4.2-current-testing

Changes included in this update