Keyboard layout switching is too slow

[quboid]

Hi,

Im using qubes for some time already.
And I have to say that since 4.x version of qubes os keyboard layout switching is working slower.
In comparison to 3.x.

I have around 20 running qubes and in my environment layout switching in a cube can take 30-60 sec if even take place at all.

Im curious if other users experience same problem.
May be there are some guides or recommendations on how address this issue?

[alimirjamali]

Unfortunately this bug exists and is a known bug. It has been reported by forum users as well as on Github issues.

It has improved a lot in r4.3 a lot. But the main issue still exists.

[alimirjamali]

Fix for this is submitted:

Cache GUIVM keyboard layout in `qvm-start-daemon`

[Max123]

Hi,

I’m not sure whether my issue has the same root, but if I press CapsLock (my key to change language) and then continue typing in the AppVM, it cancels the language change in the AppVM. So I need to press CapsLock twice to switch the language back and forth.

Propagation takes about 0.5-1.0 seconds, but the issue wouldn’t be such a big problem if the keyboard events didn’t reach the AppVM until the language switch has been completed.

I’m using Qubes 4.2 and have about 15 VMs loaded at one time (their count will be increased up to 50 quickly).

Just an idea for the loop - I guess it could improve the user experience if Qubes sent the layout change event in this order:

1. to the active window first
2. then to qubes with at least one open window
3. and then to all the others

P.S.: I’m also unable to use shortcuts like Ctrl+F in a non-English layout. I’m not sure if it’s related to the current issue, but maybe you have some advice. “Use system settings” is turned on in Settings → Keyboard, as the Internet instructs.

[alimirjamali]

@Max123

I’m using Qubes 4.2

The fixes I submitted is only merged to r4.3 branch (for the time). I will keep this thread updated if it is backported to r4.2. However, sometimes it might take weeks or even months for such fixes to be backported to the stable branch

@Max123

Just an idea for the loop - I guess it could improve the user experience if Qubes sent the layout change event in this order:

1. to the active window first
2. then to qubes with at least one open window
3. and then to all the others

Having said that, even with that improvement, more issues persist on r4.3. We have a race condition here. It is between the qvm-start-daemon agent which listens to the keyboard layout changes events and propagates the layout change to the child qubes. And the GUI daemon which send key press events via another path. Unfortunately it is not that easy.

[Max123]

Would it be easier to implement this if the layout-change feature were moved directly to the process that handles raw key presses?

In that case, you could have a dedicated Qubes OS configuration option for the “keyboard shortcut” and maybe a separate keyboard indicator in Dom0.

It’s just a guess - please ignore it if it’s not useful.

[alimirjamali]

@Max123

Would it be easier to implement this if the layout-change feature were moved directly to the process that handles raw key presses?

This was indeed suggested by one of the former members of the core development team here:

Keyboard layout switching unreliable

I just made a reply and the end of the thread

[marcos-morar]

Will keyboard layouts horror be ever resolved

A billion thanks to @alimirjamali or anyone who worked on this issue, the multiple keyboard layout switching horror has finally ended in 4.3! I’ve been testing it by adding four layouts and rapidly switching between them, and the system hasn’t picked the wrong one even once. Great work!