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 · 17 comments

Comments

Projects
None yet
8 participants
@hdevalence

hdevalence commented Nov 9, 2015

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

This comment has been minimized.

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

This comment has been minimized.

hdevalence commented Nov 9, 2015

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

@marmarek

This comment has been minimized.

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

This comment has been minimized.

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!

@ghost

This comment has been minimized.

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 label Jun 8, 2016

@marmarek

This comment has been minimized.

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

This comment has been minimized.

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

This comment has been minimized.

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

This comment has been minimized.

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

This comment has been minimized.

Member

marmarek commented Jun 12, 2016

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

@tlaurion

This comment has been minimized.

Contributor

tlaurion commented Jun 12, 2016

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

This comment has been minimized.

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

This comment has been minimized.

Contributor

tlaurion commented Jun 14, 2016

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

This comment has been minimized.

Member

marmarek commented Jun 14, 2016

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

This comment has been minimized.

Member

marmarek commented Jun 14, 2016

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).

@taradiddles

This comment has been minimized.

taradiddles 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.
@modulistic

This comment has been minimized.

modulistic commented Apr 4, 2017

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment