search

QubesOS / qubes-issues

The Qubes OS Project issue tracker
https://www.qubes-os.org/doc/issue-tracking/
536 stars 47 forks source link

Keyboard layout changes don't propagate from dom0 #1396

Open hdevalence opened 8 years ago

hdevalence commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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

marmarek commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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

marmarek commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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

tlaurion commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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

modulistic commented 7 years ago

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 Q → System Tools → Keyboard → Layout, 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.

andrewdavidwong commented 5 years ago

This issue is being closed because:

If anyone believes that this issue should be reopened, please let us know in a comment here.

hexagonrecursion commented 4 years ago

I can confirm that this issue affects Qubes 4.0. To reproduce:

  1. Configure multiple keyboard layouts in dom0 keyboard settings
  2. Try switching between them

Expected: Keyboard layout changes affect all qubes Actual: Only dom0 keyboard layout is set

marmarek commented 4 years ago

The currently implemented behavior is to propagate keyboard layout only at qube start. Right now, there is no propagation while qubes are running. But indeed that would be a useful thing.

GWeck commented 4 years ago

In the latest version of R4.1 (20200113 fully patched), dom0 keyboard layout (in my case German) does no longer propagate to fedora-30 VMs (template and AppVMs) - they use the US keyboard. It is also now impossible to set their keyboard layout; neither gnome-control-center nor the command localectl have any effect. localectl status shows the German locale and keyboard, but still the US layout is used.

dom0, debian and Whonix use the German keyboard as expected, only Fedora is affected.

qubesos-bot commented 4 years ago

Automated announcement from builder-github

The package python3-qubesadmin-4.1.7-1.fc32 has been pushed to the r4.1 testing repository for dom0. To test this update, please install it with the following command:

sudo qubes-dom0-update --enablerepo=qubes-dom0-current-testing

Changes included in this update

qubesos-bot commented 4 years ago

Automated announcement from builder-github

The package qubes-core-admin-client_4.1.7-1 has been pushed to the r4.1 testing repository for the Debian template. To test this update, first enable the testing repository in /etc/apt/sources.list.d/qubes-*.list by uncommenting the line containing stretch-testing (or appropriate equivalent for your template version), then use the standard update command:

sudo apt-get update && sudo apt-get dist-upgrade

Changes included in this update

qubesos-bot commented 4 years ago

Automated announcement from builder-github

The package python3-qubesadmin-4.1.9-1.fc32 has been pushed to the r4.1 stable repository for dom0. To install this update, please use the standard update command:

sudo qubes-dom0-update

Or update dom0 via Qubes Manager.

Changes included in this update

qubesos-bot commented 4 years ago

Automated announcement from builder-github

The package qubes-core-admin-client_4.1.9-1+deb9u1 has been pushed to the r4.1 stable repository for the Debian template. To install this update, please use the standard update command:

sudo apt-get update && sudo apt-get dist-upgrade

Changes included in this update

tlaurion commented 4 years ago

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

tlaurion commented 4 years ago

@andrewdavidwong @marmarek @marmarta : followed guidance setxkbmap -layout "us,ca" -option "grp:shifts_toggle"

Without success either.

What are supposed to be the working instructions relative to current pushed changes?

fepitre commented 4 years ago

@tlaurion Try to set the keyboard layout in XFCE settings by unselecting Use system defaults. It should propagate to AppVM. (https://github.com/QubesOS/qubes-issues/issues/6030)

marmarek commented 4 years ago

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.

tlaurion commented 4 years ago

@andrewdavidwong @marmarek @marmarta : followed guidance setxkbmap -layout "us,ca" -option "grp:shifts_toggle"

Without success either.

What are supposed to be the working instructions relative to current pushed changes? This works after restarting personal. But again, alt-2 (for @) is not available. But, switching between US and CA works by hitting both shift keys. So we have mitigation since having '@' can be obtained by switching to US keybaord and shift+2.

Will do other recommendations and activate multiple keyboard on dom0 prior of launching AppVMs and report back.

tlaurion commented 4 years ago

@fepitre set in dom0: xfce

Then remove past customization under QubesOS Manager for running VM: None

Testing:

andrewdavidwong commented 4 years ago

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?

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.

tlaurion commented 4 years ago

@andrewdavidwong : The documentation needs to be updated. My tests https://github.com/QubesOS/qubes-issues/issues/1396#issuecomment-705182253 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 https://github.com/QubesOS/qubes-issues/issues/1396#issuecomment-705182253 is preferred.

arkenoi commented 3 years ago

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.

arkenoi commented 3 years ago

apparently every layout switch forces it back from "evdev" to "xfree86"!

palainp commented 3 years ago

Not sure if this comment is relevant here, if it's a different issue or if I just have a buggy configuration.

I am with the same settings as in https://github.com/QubesOS/qubes-issues/issues/1396#issuecomment-705182253 but with only one layout (French alternative), when I start a vm, I can run :

$ setxkbmap -v -print
Trying to build keymap using the following components:
keycodes: evdev + aliases (qwerty)
types: complete
compat: complete
symbols: pc + us + inet (evdev)
geometry: pc (pc105)
xkb_keymap {
xkb_keycodes {include "evdev + aliases (qwerty)"};
xkb_types {include "complete"};
xkb_compat {include "complete"};
xkb_symbols {include "pc + us + inet (evdev)"};
xkb_geometry {include "pc (pc105)"};
};

but as I can type in FR (azerty) I may have a missconfiguration or something ?

The interesting part is when I attach a Sennheiser SP 20 USB to the VM, the layout changes to US (qwerty, in accordance with what setxkbmap says). This appears no matter if the VM is templated or standalone. The kernel logs shows :

[ 9021.779635] vhci_hcd vhci_hcd.0: USB/IP Virtual Host Controller
[ 9021.779690] vhci_hcd vhci_hcd.0: new USB bus registered, assigned bus number 2
[ 9021.780062] vhci_hcd: created sysfs vhci_hcd.0
[ 9021.780103] usb usb2: New USB device found, idVendor=1d6b, idProduct=0002, bcdDevice= 5.04
[ 9021.780127] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[ 9021.780150] usb usb2: Product: USB/IP Virtual Host Controller
[ 9021.780168] usb usb2: Manufacturer: Linux 5.4.125-1.fc25.qubes.x86_64 vhci_hcd
[ 9021.780189] usb usb2: SerialNumber: vhci_hcd.0
[ 9021.780269] hub 2-0:1.0: USB hub found
[ 9021.780286] hub 2-0:1.0: 8 ports detected
[ 9021.780522] vhci_hcd vhci_hcd.0: USB/IP Virtual Host Controller
[ 9021.780566] vhci_hcd vhci_hcd.0: new USB bus registered, assigned bus number 3
[ 9021.780597] usb usb3: We don't know the algorithms for LPM for this host, disabling LPM.
[ 9021.780633] usb usb3: New USB device found, idVendor=1d6b, idProduct=0003, bcdDevice= 5.04
[ 9021.780655] usb usb3: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[ 9021.780677] usb usb3: Product: USB/IP Virtual Host Controller
[ 9021.780696] usb usb3: Manufacturer: Linux 5.4.125-1.fc25.qubes.x86_64 vhci_hcd
[ 9021.780726] usb usb3: SerialNumber: vhci_hcd.0
[ 9021.781080] hub 3-0:1.0: USB hub found
[ 9021.781097] hub 3-0:1.0: 8 ports detected
[ 9021.940684] vhci_hcd vhci_hcd.0: pdev(0) rhport(0) sockfd(0)
[ 9021.940708] vhci_hcd vhci_hcd.0: devid(131076) speed(2) speed_str(full-speed)
[ 9021.940733] vhci_hcd vhci_hcd.0: Device attached
[ 9022.110974] vhci_hcd: vhci_device speed not set
[ 9022.162824] usb 2-1: new full-speed USB device number 2 using vhci_hcd
[ 9022.225904] vhci_hcd: vhci_device speed not set
[ 9022.277892] usb 2-1: SetAddress Request (2) to port 0
[ 9022.299082] usb 2-1: New USB device found, idVendor=1395, idProduct=0041, bcdDevice=95.90
[ 9022.299107] usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 9022.299129] usb 2-1: Product: Sennheiser SP 20 for Lync
[ 9022.299153] usb 2-1: SerialNumber: A0004...
[ 9022.312083] input: Sennheiser SP 20 for Lync as /devices/platform/vhci_hcd.0/usb2/2-1/2-1:1.3/0003:1395:0041.0002/input/input7
[ 9022.312328] input: Sennheiser SP 20 for Lync as /devices/platform/vhci_hcd.0/usb2/2-1/2-1:1.3/0003:1395:0041.0002/input/input8
[ 9022.364007] input: Sennheiser SP 20 for Lync Consumer Control as /devices/platform/vhci_hcd.0/usb2/2-1/2-1:1.3/0003:1395:0041.0002/input/input9
[ 9022.364949] hid-generic 0003:1395:0041.0002: input,hiddev96,hidraw1: USB HID v1.11 Device [Sennheiser SP 20 for Lync] on usb-vhci_hcd.0-1/input3
[ 9022.412981] mc: Linux media interface: v0.10
[ 9022.541172] usbcore: registered new interface driver snd-usb-audio
[ 9022.557379] audit: type=1130 audit(1626873890.761:136): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=alsa-state comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
[ 9023.647246] vhci_hcd: unlink->seqnum 75
[ 9023.647262] vhci_hcd: urb->status -104
[ 9023.647274] vhci_hcd: unlink->seqnum 76
[ 9023.647285] vhci_hcd: urb->status -104
[ 9023.647299] vhci_hcd: unlink->seqnum 77
...
anadahz commented 3 years ago

apparently every layout switch forces it back from "evdev" to "xfree86"!

I have the same issue as in https://github.com/QubesOS/qubes-issues/issues/1396#issuecomment-835199512 . This wasn't the case a week ago.

Not sure if it's related, I have a custom keymap set by a setxkbmap command on /etc/profile.d.

tlaurion commented 3 years ago

I confirm that on my side following https://github.com/QubesOS/qubes-issues/issues/1396#issuecomment-705182253 and not having changed anything else it works as intended on 4.0, but needs reboot as opposed to 4.1.

dual shift and then shift 2: @ dual shift and then shift 2: "

No layout configured under Qubes Manager for currently used AppVM.

rwiesbach commented 2 years ago

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 commented 2 years ago

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

rwiesbach commented 2 years ago

@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 commented 2 years ago

Yes we would need to adjust default XFCE conf.

Rudd-O commented 2 years ago

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

marmarek commented 2 years ago

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

loztcf commented 2 years ago

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 commented 2 years ago

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

loztcf commented 2 years ago

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

bashlund commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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