Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Keyboard layout changes don't propagate from dom0 #1396

Open
hdevalence opened this issue Nov 9, 2015 · 60 comments
Open

Keyboard layout changes don't propagate from dom0 #1396

hdevalence opened this issue Nov 9, 2015 · 60 comments
Labels
affects-4.1 This issue affects Qubes OS 4.1. C: core C: doc C: gui-virtualization help wanted This issue will probably not get done in a timely fashion without help from community contributors. localization This issue concerns translating things into different languages or adapting them to other regions. P: minor Priority: minor. The lowest priority, below "default." r4.1-bullseye-stable r4.1-buster-stable r4.1-centos8-stable r4.1-dom0-stable r4.1-fc29-stable r4.1-fc30-stable r4.1-fc31-stable r4.1-fc32-stable r4.1-stretch-stable T: bug Type: bug report. A problem or defect resulting in unintended behavior in something that exists. ux User experience

Comments

@hdevalence
Copy link

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.

@marmarek
Copy link
Member

marmarek commented Nov 9, 2015

Does that affect also VM started after layout change?

Currently keyboard layout is set in the VM only at VM startup time. Yes,
somehow suboptimal solution...

Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

@hdevalence
Copy link
Author

Yes, VMs started after the layout change also don't inherit the (X11) keyboard layout from dom0.

@marmarek
Copy link
Member

marmarek commented Nov 9, 2015

Did you used per-VM layout setting in those VMs? It overrides layout
retrieved from dom0.

Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

@bnvk
Copy link

bnvk commented Nov 21, 2015

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 Alt or Opt key and then typing certain keys!

@marmarek marmarek added T: bug Type: bug report. A problem or defect resulting in unintended behavior in something that exists. C: core C: gui-virtualization P: minor Priority: minor. The lowest priority, below "default." ux User experience labels Jan 7, 2016
@marmarek marmarek added this to the Release 3.0 updates milestone Jan 7, 2016
@ghost
Copy link

ghost commented Jun 8, 2016

What's the status for the fix? It's one of the biggest problems I've with Qubes.

@marmarek marmarek added the help wanted This issue will probably not get done in a timely fashion without help from community contributors. label Jun 8, 2016
@marmarek
Copy link
Member

marmarek commented Jun 8, 2016

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.

@ghost
Copy link

ghost commented Jun 9, 2016

Marek Marczykowski-Górecki:

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.

Yes it works, but it's really frustrating to switch layout (that takes
one to one and a half minute) just for writing "å", "ä", and "ö". And
then switch back to US layout then I'm finished. This happens quite
often because I write in Swedish (or simply write my name) quite often.

@marmarek
Copy link
Member

marmarek commented Jun 9, 2016

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.

@ghost
Copy link

ghost commented Jun 12, 2016

Marek Marczykowski-Górecki:

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.

No, I don't know how to do that. I'm guessing that it exist a solution,
but I have to do it myself?

@marmarek
Copy link
Member

Just looking how to trigger keyboard layout change in the VM to properly fix this issue.

@tlaurion
Copy link
Contributor

I Also have the same problem with "ca" keyboard.
As an example,pressing AltCar+2 is supposed to give an arobas. For some reason, that AlCar key is not working, that altcar key having the same behavior as the standard alt key.

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.
https://www.qubes-os.org/doc/user-faq/#my-keyboard-layout-settings-are-not-behaving-correctly-what-should-i-do

@tlaurion
Copy link
Contributor

tlaurion commented Jun 12, 2016

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:

KeyPress event, serial 31, synthetic NO, window 0x1600001,
    root 0x266, subw 0x0, time 5866343, (-681,13), root:(64,417),
    state 0x0, keycode 108 (keysym 0xfe03, ISO_Level3_Shift), same_screen YES,
    XKeysymToKeycode returns keycode: 92
    XLookupString gives 0 bytes: 
    XmbLookupString gives 0 bytes: 
    XFilterEvent returns: False

KeyPress event, serial 31, synthetic NO, window 0x1600001,
    root 0x266, subw 0x0, time 5867038, (-681,13), root:(64,417),
    state 0x80, keycode 64 (keysym 0xffe9, Alt_L), same_screen YES,
    XLookupString gives 0 bytes: 
    XmbLookupString gives 0 bytes: 
    XFilterEvent returns: False

KeyPress event, serial 31, synthetic NO, window 0x1600001,
    root 0x266, subw 0x0, time 5867039, (-681,13), root:(64,417),
    state 0x88, keycode 11 (keysym 0x40, at), same_screen YES,
    XLookupString gives 1 bytes: (40) "@"
    XmbLookupString gives 1 bytes: (40) "@"
    XFilterEvent returns: False

KeyRelease event, serial 31, synthetic NO, window 0x1600001,
    root 0x266, subw 0x0, time 5867333, (-681,13), root:(64,417),
    state 0x88, keycode 11 (keysym 0x40, at), same_screen YES,
    XLookupString gives 1 bytes: (40) "@"
    XFilterEvent returns: False

KeyRelease event, serial 31, synthetic NO, window 0x1600001,
    root 0x266, subw 0x0, time 5868574, (-681,13), root:(64,417),
    state 0x88, keycode 108 (keysym 0xfe03, ISO_Level3_Shift), same_screen YES,
    XKeysymToKeycode returns keycode: 92
    XLookupString gives 0 bytes: 
    XFilterEvent returns: False

FocusOut event, serial 31, synthetic NO, window 0x1600001,
    mode NotifyNormal, detail NotifyNonlinear

@tlaurion
Copy link
Contributor

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.

@marmarek
Copy link
Member

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.

@marmarek
Copy link
Member

An idea: watch _XKB_RULES_NAMES property on root window. But first requires a verification if that's part of official API, not an implementation detail (which may work with some tools but not others).

@ghost
Copy link

ghost commented Aug 29, 2016

(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:

  • no layout notification; not a problem for me, if you don't remember which layout you've enabled, in the worst case you'll type a letter, see that you're in the wrong layout, press both shift keys, and continue. It takes 1 second.
  • my biggest gripe: when the screensaver kicks in (xscreensaver here), there's no way to know in which layout you're typing your password. Typing your English password with - say - Cyrillic letters will obviously fail, so you'll have to press both shift keys and try again.

@mfc mfc added the localization This issue concerns translating things into different languages or adapting them to other regions. label Aug 29, 2016
@modulistic
Copy link

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 QSystem ToolsKeyboardLayout, 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. You can use localectl --help as a starting point.

Example: localectl set-x11-keymap us dell ,qwerty compose:caps.

This generates the appropriate configuration in /etc/X11/xorg.conf.d/00-keyboard.conf.

Restarting xorg is required. The easy way is to reboot the system.

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.

@rwiesbach
Copy link

Today I installed Qubes 4.1 RC1 from scratch. During the setup I choose to install only German keyboard layout (removed the Englisch one). Nevertheless all templates (debian-11, fedora-34, both whonix) and thereby all VMs still have the English layout active. Dom0 has German layout, as expected.

@fepitre
Copy link
Member

fepitre commented Oct 22, 2021

Go to dom0/System Tools/Keyboard. Then "Layout" tab and uncheck "Use system defaults". That's all.

@rwiesbach
Copy link

@fepitre thank you, that worked out. I expected "system default" to be the layout that I defined during setup phase. I suggest to uncheck this option in 4.1 final, as I think that is what people would expect, isn't it?

@fepitre
Copy link
Member

fepitre commented Oct 22, 2021

Yes we would need to adjust default XFCE conf.

@Rudd-O
Copy link

Rudd-O commented Oct 26, 2021

The workaround for the keyboard layout does not work for me. It's already unchecked.

@marmarek
Copy link
Member

This should be already fixed by QubesOS/qubes-core-admin-client#193, that is included in QubesOS/updates-status#2721 (already in stable). If anybody still see this issue even with that update installed, please leave a comment.

@loztcf
Copy link

loztcf commented Dec 8, 2021

I set keyboard layout in dom0 with "localectl set-x11-keymap us,de 104,105 altgr-intl,nodeadkeys grp:l_alt_lshift_toggle"
If I use XFCE the keyboard layout propagates fine to any vm (and dom0) if I switch it via l_alt_shift_toggle. The keyboard layout is set correctly then without problems, I'm able to query and verify it via qvm-prefs.
If using i3wm the keyboard layout only switches in dom0 and doesn't propagate to any vm if - I query any via qvm-prefs the default one is still set.

@marmarek
Copy link
Member

marmarek commented Dec 9, 2021

When using i3wm, is qvm-start-daemon --all --watch process running?

@loztcf
Copy link

loztcf commented Dec 9, 2021

Yes, it is running according to ps -ef. If I could provide more useful details somehow please let me know.

@bashlund
Copy link

One more weird issue, not sure if it belongs here or if I should open a separate entry on github.

After a while, arrow keys and pgup/pgdn in VMs stop working. VM restart helps, but then the issue re-appear. Xev shows that keycodes are correct but mapping is all off. I checked the setting thoroughly and found out that xkbmap keycodes are slipped to "xfree86+aliases(qwerty) instead of normal "evdev+aliases(qwerty)". resetting it with setxkbmap -keycodes "evdev+aliases(qwerty)" restores normal behavior.

Thanks @arkenoi, your tip of resetting using setxkbmap -keycodes "evdev+aliases(qwerty) really saved my setup!

Whenever the arrow keys stop working I run that snippet and it all works again as expected.

@holiman
Copy link

holiman commented Aug 15, 2022

I am also having this problem, it appeared pretty recently (after upgrade to 4.1). Am on 4.1. 5.8.9-1 kernel. Use En and SE layouts, and double-shift to switch, but it does not propagate from dom0.
Also on i3, and qvm-start-daemon --all --watch is running.

@bashlund
Copy link

I noticed you poppin by @holiman, so I though it's time to share a snippet which works good as a workaround on this issue :)
The ideas to the snippet come from this thread.
It solves the problems by the user hitting a keyboard shortcut and the script then sets the keyboard layout in all VMs.

Whenever my layout totally breaks I just hit the shortcut two times to get back to the layout I was using, so it solves the issue of layout which stop working and also propagating layouts from dom0.

See the script header for details on how to set it up. The script must be copied to dom0, but no install are necessary.

https://gist.github.com/bashlund/90f097d5ffea3c5a8c7ffd13867b5cb3

@marmarek
Copy link
Member

The layout switching involves several parts:

  1. qvm-start-daemon monitors _XKB_RULES_NAMES and XKLAVIER_ALLOW_SECONDARY properties on the root window ( you can check with xev -root -event property if they change)
  2. Then, it adjusts keyboard_layout property on dom0 (check with qvm-prefs dom0 keyboard_layout)
  3. Then, it's transferred using qubesdb to relevant VMs, where qubes-keymap.sh script should monitor it and apply the change (check process list in the VM to see if it runs)

@holiman
Copy link

holiman commented Aug 16, 2022

Interesting!

As far as I can tell, it's 1) which is failing. If I switch layout, then indeed it works in dom0, but the qvm-prefs dom0 keyboard_layout does not change. The xev -root -event property only reacts when the cursor moves from one application screen to another.

At this point, I exited i3, and started an xfce session instead. In xcfe, the xev -root -event property did emit XKLAVIER_ALLOW_SECONDARY events, which updated the qvm-prefs, and the whole chain worked.

@jamke
Copy link

jamke commented May 7, 2023

The layout switching involves several parts:

1. `qvm-start-daemon` monitors `_XKB_RULES_NAMES` and `XKLAVIER_ALLOW_SECONDARY` properties on the root window ( you can check with `xev -root -event property` if they change)

2. Then, it adjusts `keyboard_layout` property on dom0 (check with `qvm-prefs dom0 keyboard_layout`)

3. Then, it's transferred using qubesdb to relevant VMs, where `qubes-keymap.sh` script should monitor it and apply the change (check process list in the VM to see if it runs)

@marmarek
Thank you for this valuable piece of information!
Is it documentation somewhere? I want to investigate and fix #8035, but could not find documentation how layout switching works in R4.1. I mean your reply explains a lot, but maybe it is explained somewhere else too?

And why XKLAVIER_ALLOW_SECONDARY exactly? I tried to search for it and it seems that Qubes OS is almost the only somewhat popular project that relies on XKLAVIER_ALLOW_SECONDARY (I can easily be wrong about this).

@gangamstyle
Copy link

Debugging:

  1. qubesdb-watch /keyboard-layout in guests returns nothing, and this prevents layout update in guests
  2. qvm-prefs dom0 keyboard_loyout in dom0 returns nothing

Script that tracks layout changes in dom0 and updates keyboard_layout for qvm-prefs:
/usr/lib/python3.8/site-packages/qubesadmin/tools/qvm_start_daemon.py
It listens to X events using xcffib library https://github.com/tych0/xcffib and that library may be bugged.

@gangamstyle
Copy link

@marmarek can you please check if this pull request QubesOS/qubes-core-admin-client@b99e45f can be affected by suspend/resume (this starts the bug)

@sysfu
Copy link

sysfu commented Mar 7, 2024

I'm troubleshooting an issue whereby dom0 keyboard layout and setxkbmap options are being ignored by a Windows 7 Qube. All linux Qubes do not have this issue and respect both dom0 keyboard layout and setxbkmap -options ctrl:nocaps setting.

Forum thread with the troubleshooting steps I've taken so far, maybe it's due to this same bug?

@jamke
Copy link

jamke commented Mar 8, 2024

I'm troubleshooting an issue whereby dom0 keyboard layout and setxkbmap options are being ignored by a Windows 7 Qube.

I have Windows 10 for a while that does not care about keyboard layout of other qubes, including dom0. Is the propagation expected to work with Windows qubes at all?

@sysfu
Copy link

sysfu commented Mar 9, 2024

I'm troubleshooting an issue whereby dom0 keyboard layout and setxkbmap options are being ignored by a Windows 7 Qube.

I have Windows 10 for a while that does not care about keyboard layout of other qubes, including dom0. Is the propagation expected to work with Windows qubes at all?

I did some more research and believe this is due to missing Qubes Windows Tools. They were replaced with a dummy file around August 2023 on account of a Xen driver CVE.

You can manually downgrade to qubes-windows-tools-4.1.69 (for Qubes OS v4.2) but the updater will replace it with the dummy file again if you're not careful.

@jamke
Copy link

jamke commented Mar 10, 2024

Without QWT it will not propagate for sure. I have QWT and it still never propagated on Win10 for me, so, I am not sure it should.

@marmarek
Copy link
Member

marmarek commented Mar 10, 2024 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
affects-4.1 This issue affects Qubes OS 4.1. C: core C: doc C: gui-virtualization help wanted This issue will probably not get done in a timely fashion without help from community contributors. localization This issue concerns translating things into different languages or adapting them to other regions. P: minor Priority: minor. The lowest priority, below "default." r4.1-bullseye-stable r4.1-buster-stable r4.1-centos8-stable r4.1-dom0-stable r4.1-fc29-stable r4.1-fc30-stable r4.1-fc31-stable r4.1-fc32-stable r4.1-stretch-stable T: bug Type: bug report. A problem or defect resulting in unintended behavior in something that exists. ux User experience
Development

No branches or pull requests