Keyboard layout changes don't propagate from dom0 #1396
Comments
Does that affect also VM started after layout change? Currently keyboard layout is set in the VM only at VM startup time. Yes, Best Regards, |
Yes, VMs started after the layout change also don't inherit the (X11) keyboard layout from dom0. |
Did you used per-VM layout setting in those VMs? It overrides layout Best Regards, |
I've noticed weird behavior with International keyboards (I have 3 installed), most of the time when I switch to one (via clicking an icon in the main KDE navbar, it seems to do nothing. However, once in awhile, I'm able to access Int. characters by holding the |
What's the status for the fix? It's one of the biggest problems I've with Qubes. |
For now the workaround is to use per-VM keyboard layout change feature. It should work regardless of dom0 layout, and in fact dom0 layout will no longer be propagated there. |
Marek Marczykowski-Górecki:
Yes it works, but it's really frustrating to switch layout (that takes |
Do you know how to install some hook on dom0 keyboard layout change? It can be anything - from registering a script somewhere, to having a tool listening on some events. |
Marek Marczykowski-Górecki:
No, I don't know how to do that. I'm guessing that it exist a solution, |
Just looking how to trigger keyboard layout change in the VM to properly fix this issue. |
I Also have the same problem with "ca" keyboard. Dom0 is set to use english keyboard. From Qubes-manager i've selected ca keyboard. No change.I also have tried changing settings through gnome-control-center without any success from inside the VM. A writeup on how to fix that would be nice, since the FAQ is not helping the intl user in any way. |
What is weird is that the key sequence is seen and the key are mapped ok inside xev under a qubes-manager configured keymap appvm. I do not understand why it is impossible to type the good character directly into an application. xev output:
|
To truely have an intl keyboard, both Dom0 and Appvm need to have the same keyboard layout applied. Else, a "can" keyboard configured only through Qubes Vm manager alone will not result in the right desired behavior, eg: pressing altcar+2 won't result in "@"character that appear when both dom0 and domu are configured to use the same layout. It seems that dom0 selected layout needs to propagate to domu. |
Exactly why I'm looking for a way of getting a notification when dom0 keyboard layout is changed. |
An idea: watch |
(copy/paste from a reply in the dev ML) the following workaround has been working well for me for many years, in stock fedora and now in Qubes: in a terminal in dom0, type the following (obviously replace the bg(phonetic) version with whatever layout you're using) setxkbmap -layout "us,bg(phonetic)" -option "grp:shifts_toggle" then you'll be able to press both shift keys to switch the layout in specific VMs. you can automate this by putting this line in a script called by the window manager during startup. caveats:
|
After some frustration with a fresh qubes R3.2 install with stock XFCE, I found the "right" way to set the (xorg) system-wide keyboard layout (and options); This feels like a work-around for me, but anyway: In Set the system-wide layout and options for Example: This generates the appropriate configuration in Restarting I just opened a PR that adds this explanation to the FAQ. BTW, I've been unable to figure how the current layout is propagated from dom0's xorg to the other VMs, along with others such as the display geometry. It would be nice to have this explained somewhere in the documentation, even if it is in the developer documentation. |
Automated announcement from builder-github The package
|
@marmarta @marmarek : https://www.qubes-os.org/faq/#my-keyboard-layout-settings-are-not-behaving-correctly-what-should-i-do refers here, while packages seems to be updates for 4.1. What is the current situation? Is the FAQ up to date? Canadian French here, so need to have US keyboard by default but have '@' set as canadian-fr keyboad in some VMs, still not attainable. (key is not accessible with alt+2 as expected.) Repro: Better issue then this one? Open a new issue? Please tag me here or elsewhere. So I can test/reproduce/create new issue) |
@andrewdavidwong @marmarek @marmarta : Without success either. What are supposed to be the working instructions relative to current pushed changes? |
In R4.0 the keyboard layout is loaded by an AppVM only at its start time. This means, if you want to switch keyboard layout when the VM is running, you either need to restart it, or change it manually in both dom0 and the VM. |
Will do other recommendations and activate multiple keyboard on dom0 prior of launching AppVMs and report back. |
@fepitre set in dom0: Then remove past customization under QubesOS Manager for running VM: Testing:
|
You can see in the blame view that the most recent update to that FAQ entry was 8 months ago, so it's certainly not describing 4.1. Historically, our documentation has always described the latest stable release, so it wouldn't describe 4.1 until 4.1 is actually a stable release. (However, I'm working on versions-specific docs.) It's unclear to me whether this issue needs to be reopened. |
@andrewdavidwong : The documentation needs to be updated. My tests #1396 (comment) show 4.0 testing, where if followed, permits mitigation of keyboard issues of multi-language support. From my quick verification of 4.1, the difference there is that it doesn't require shutting down active VM since propagation is live, not only done at startup of the AppVM, and where links to discussion (last update on google group, on which you replied) is a temporary solution, where #1396 (comment) is preferred. |
When the keyboard layout is changed in dom0 (e.g., using the KDE layout switcher in the icon tray) the change doesn't propagate to other VMs, in particular any VM you would actually be using.
This makes it basically impossible to (e.g., temporarily) change keyboard layouts from your default, since you have to go to every VM and manually reconfigure their input methods, and then do it all over again to change back.
The text was updated successfully, but these errors were encountered: