Will keyboard layouts horror be ever resolved

If I’m not the only one to have massive issues with switching keyboard layouts in dom0, of which the most horrifying are: it doesn’t work always, it works after tens of times switching cycles and the worst one that it causes massive lag response of a whole dom0 (not inside already opened qubes) nevertheless if it works or not but just on a switch attempt, may I then ask will this basic funcitonality be ever resolved after more than 10 years of Qubes?

Whenever I need to switch it I hesitate to do it, because very soon after that I’m getting pissed off of the lag response of dom0 measured in tens of seconds after any action taken, and the only solution is to reboot Qubes, which also takes time and I have a lot of opened qubes opened by default, so I need like 15-30 minutes to get where I was before the lag.

Jesus…

First of all I understand your frustration, I would also consider this issue to be a blocker and release nothing new until this basic functionality issue is completely solved.

About 10 years: no, it was working properly in R4.0, at least for me. So, it is a major regression (probably the biggest of all time Qubes OS exists). And the problem was not address for a long time. Layout switching was broken in R4.1 due to the new layout propagation approach and this dramatic change was not even mentioned in the R4.1 changelog.

On R4.1 there were at least 4 separate bugs in managing keyboard layout. Most of them has been fixed recently, not sure if they are already updated with dom0 updates, though. But the delay when switching is still not fixed, as I understand. I diagnosed the issue and reported, but it has not been not addressed yet.

You can post your concerns on github in the linked issues, because it seems that devs are not reading forum actively nowadays, or at least do not reply.

Read more about layout switching issues of R4.2 and the progress of solving them here:

2 Likes

I meant with this that after 10 years of developing a product the one mustn’t allow basic functionalities not to function for more than couple of (basic) time units. Like flying to the Moon, then gong back to the ship for every breath take.

Step aside it’s about basic functionality, if this forum serves as a stop-by for a github redirection, then it is a regression per se, because, then it can’t be considered as a “knowledge base” founded by the team.

Although aware of the github, grateful for the links, though

[quote=“Welcome to the Qubes OS forum!, post:1, topic:7”]

Report issues and submit changes in the right places

The forum (and mailing lists) a good place to ask questions and discuss bugs and feature requests.
[/quote]

Just to be clear, I was not sending you to github as “you should not complain on forum”.
No, it was a polite saying that the solution for this issue can be archived more effectively there, that’s all.

You are welcome.
I am also concerned about these layout switching issues and even was helping to fix them.

1 Like

Of course, of course. It’s the lack of live face to face communication that brought this possible misunderstanding when there was no room for it.

So, I left the computer without restart and it became absolutely unresponsive after a day. To me, it looks as an obvious memory leak in dom0 caused by keyboard layout switch.

Best regards

It is definitely a problem that can be reported, especially in case it is reproducible.

But why do you think it is caused by keyboard layout switch? The code processing layout change is invoked mostly only when XKLAVIER_ALLOW_SECONDARY event is fired (on layout change).

Main devs and contributors use only 1 layout I think, because of this we have this problem

1 Like

The horror continues. Is this a horror or am I exaggerating?

Look, I don’t want to be personal. I don’t care. It’s basic functionality. You know what I mean? It’s not about sys-gpu, or complex things like that.

It’s horror over basic functionality.