How Qubes installation manages keyboard layout?

Thanks for that.

So how do you use multi-language keyboard layouts at the moment, what’s the workaround?

I tried multiple ways, none of them worked for me, sadly.

I also just tried to re-install the system with pre-installed languages.

I updated all the templates through through the qubes-manager.

I installed KDE as it says in the docs: KDE (desktop environment) | Qubes OS

Launched Personal qube and keyboard layout doesn’t work.
It does work in the dom0 however.

I have added additional keyboard layout after installation (Q->System Tools-> Keyboard->Layout → “Add” button) and using them for quite a while (more that a year). Switching between layouts with Left Alt + Left Shift and do not experience any issues. The only problem is that Qubes does not show anywhere what layout is currently active, but as I have only two layouts, it is not a problem for me.

P.S. Now when I think more I’m not sure if I have added it during the installation or after installation…

The installer (anaconda from fedora) modify this file:
/etc/X11/xorg.conf.d/00-keyboard.conf
e.g. from https://wiki.archlinux.org/title/Xorg/Keyboard_configuration#Using_X_configuration_files

Section "InputClass"
        Identifier "system-keyboard"
        MatchIsKeyboard "on"
        Option "XkbLayout" "cz,us"
        Option "XkbModel" "pc104"
        Option "XkbVariant" ",dvorak"
        Option "XkbOptions" "grp:win_space_toggle"
EndSection

The documentation that Balko reffer to is keyboard-layout-settings-not-behaving-correctly.
And as he said, there are sometimes some issues (see the links he posted for more details).

You can add an new item in the panel.
Right click on the panel > Panel > Add New Item > Keyboard Layouts

As the doc recommend:

leave the checkbox “Use system defaults” checked. Do not customize the keyboard layout here.
Set the system-wide layout and options for xorg with the localectl command in dom0.

See the archlinux wiki link I posted just above.

4 Likes

I switched to XFCE just to make sure.
Fun fact: I can use second language in AppVM, but I can’t use any other(5 out of 7).

I use KDE and it’s my preferable DE, but I tried gnome as well and it’s the same as KDE - keyboard layout doesn’t work at all in AppVMs.

That’s just crazy, if indeed this is the behavior, very disappointing. Didn’t expect this kind of bugs for a released version that is available for over a year and a half.

sometimes is not the case, it just doesn’t work as intended for me all the time.

I tried many things already, but none of them worked.

From a fresh install with 7 selected keyboard layout languages, what exactly I should do for this to work in AppVMs?

With only 2 layouts, it does not always fail, just sometimes.
With many, indeed it always failed when using the keymap to switch layouts.
(I’ve used only one keymap to switch between all layouts).

I tried with 4 layouts and the keymap failed (it always block on the third and get stuck).
When using the ‘keyboard layouts’ item from the panel, it did works.
I haven’t tested this extensively, but you could give it a try.

Thank you and other members for trying to help, but I think I’m not gonna use Qubes. The idea is amazing, but it’s buggy and limiting, even with simple things like this one with the layout.

KDE 4.0 (aka not KDE 4) also had keyboard layout switch broken for a year or so, if I am not mistaken.

But yes, I agree that issues like that should be blockers for new releases.

I think that should works with the panel item.

Also, from this comment: https://github.com/QubesOS/qubes-issues/issues/8035#issuecomment-1682418329,
the issue with a toggle keymap (e.g. grp:win_space_toggle) should be fixed.
But not yet with some other shorcuts like shift_caps_switch.

You can already do the fix by looking the commit (or wait an update).
You can also thanks Balko, as he’s the one (with others too) who are debugging this issue.

Notice that the Qubes OS team is small and there is a lot of work to do.

1 Like

Thank you, that’s appreciated.

Indeed, it is a serious issue, which I’m also suffering from. @adw shouldn’t it be a blocker for 4.2?

1 Like

Well, that’s a decision for @marmarek. What issue are you referring to, exactly? Please provide the qubes-issues link or issue number. Several different ones have been mentioned/linked in this thread, so I’m not sure which one we’re talking about.

Maybe some meta-issue should be created, like “Make layout switching work correctly with propagation approach” (affects-4.1 and -4.2). Because there are at least 3 independent problems as I mentioned above. One is probably fixed, second half-fixed and one not even reported as a separate issue (about double events that have ~1s distance and break layout if user changes active qube during ~ 1s after keyboard layout switch). If you want, I can combine a meta-issue and report the 3rd problem, currently it is only mentioned in comment to other keyboard layout issues.

1 Like

We currently don’t allow meta-issues in the issue tracker. We use projects instead. However, only qubes-issues editors can create projects, and they’re only created when they’ll assist the developers in their work.

Please do create the missing separate issue.

Also, no one has provided an issue number or link for the issue(s) that should be considered 4.2 blockers. If you’d like the priority of such issues to be reconsidered prior to the 4.2 stable release, please do so now.

Meta issues are good stuff to track such multi-bug problems, maybe reconsider one day :slight_smile:

OK, I will report it today.

I will make several comments on github to organize keyboard layout issues better.

Currently I see independent problems:

  1. Issue #8230 - Layout switching eventually breaks key mapping
    Fixed by PR by github user solardiz. They also fixed another layout issue.

  2. Issue #8035 - Change of keyboard layouts with Capslock/Shift+Capslock (shift_caps_switch in setxkbmap) breaks all the time
    Probably fixed by @marmarek’s this commit and my PR (accepted today).

  3. The new issue I will have to report today about double delayed events.

1 Like

I do not insist about blocker status, only if you and the Team think it should be. I personally agree that broken layout switching is unacceptable for majority of non-US users and should be addressed as top priority.
It is also proven to be so by poll/post about what people want in R4.2.

And if you do decide to use blocker for R4.2 than this issue can be used as one that describes the problem in general. Of course, this issue affects-4.2 at the moment, I believe.

2 Likes

Thanks, @balko! This is all very helpful! :slight_smile:

We’re always open to considering better ways of doing things. The main problem with meta-issues is that they don’t seem to do anything that projects don’t do better, and they clutter up the issue tracker with issues that aren’t actionable until each of their sub-issues is closed. Projects seem specifically designed to do the job of meta-issues but better. If there are good arguments in favor of meta-issues, I’d like to hear them.

1 Like

Maybe projects are even better! I was not using them.

About current situation: I think, there is no need to create meta or project for that. We have one general issue that combines possible bugs about layout and that can be used. I also think that most of layout switching issues are fixed (hopefully) by now. One or two steps left to make people enjoy their layouts as it was on R4.0 but now with more universal propagation approach.

Done:

2 Likes