search

QubesOS / qubes-issues

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

"Change layout option" keyboard shortcut not always consumed by dom0 if it includes `Space` #8758

Open UndeadDevel opened 11 months ago

UndeadDevel commented 11 months ago

Qubes OS release

4.2rc5

Brief summary

When setting a keyboard shortcut for keyboard layout switching that includes a Space key (e.g. in the case of Super+Space) the layout will switch but the domU in focus will sometimes receive a Space input, i.e. if a text editor is open then a white space char will be printed. This happens both for manual settings in the Keyboard app as well as if Super+Space is the system default and the app is set to use the default. I only tested and confirmed this for Super+Space; testing Caps-lock as layout switching shortcut works and does not propagate a Caps-lock event to the domU. Setting it to something like "both Alts" or "both Shifts" also works and avoids the problem. This seems to happen only for certain apps, e.g. in this Firefox text field I'm typing the issue description in or in the address bar it doesn't occur, but in a terminal of the same qube it does; also occurs in e.g. LibreOffice Writer.

Dom0 seems unaffected.

Steps to reproduce

  1. Set up Super+Space as layout switching keyboard shortcut
  2. Open a terminal or LibreOffice Writer in a domU and put it in focus
  3. Switch layouts

Expected behavior

No propagation of Space key.

Actual behavior

In certain apps the Space key is printed.

DemiMarie commented 11 months ago

I’m pretty sure this is an XFCE bug.

jamke commented 11 months ago

Any information what stops key stroke from passing to the active qube in case of layout switch shortcut? Something in dom0 that should pick up the shortcut and mark it as processed?

UndeadDevel commented 11 months ago

I’m pretty sure this is an XFCE bug.

But dom0 seems unaffected (at least the dom0 xfce4-terminal is not receiving Space, while xfce4-terminal in domUs are)...are you suggesting I report it to Xfce on Gitlab?

k4z4n0v4 commented 10 months ago

Would it still be considered an XFCE bug if you set the keyboard layout with an xorg.conf and tell XFCE to use the system defaults? XFCE then should ignore keyboard events and X running in dom0 should handle those iiuc. Yet the bug happens whether or not the keyboard switching is configured using Xorg or XFCE.

k4z4n0v4 commented 4 months ago

The issue still exists, how can we try and diagnose it?

DemiMarie commented 3 months ago

I would run the GUI daemon under gdb. It’s best to do this with a trusted qube, though in theory it should not matter.

marmarek commented 3 months ago

I would run the GUI daemon under gdb

That's rather heavy hammer for issue like this...

xev is likely a better start.

Like xev -id (id of some qube's window) in dom0, and just xev in a qube.

xev output with Super+Space

``` KeyRelease event, serial 22, synthetic NO, window 0x5600337, root 0x7bf, subw 0x0, time 445853708, (393,180), root:(446,1404), state 0x0, keycode 133 (keysym 0xffeb, Super_L), same_screen YES, XLookupString gives 0 bytes: XFilterEvent returns: False KeyPress event, serial 22, synthetic NO, window 0x5600337, root 0x7bf, subw 0x0, time 445853708, (393,180), root:(446,1404), state 0x0, keycode 133 (keysym 0xffeb, Super_L), same_screen YES, XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False KeyRelease event, serial 22, synthetic NO, window 0x5600337, root 0x7bf, subw 0x0, time 445854114, (393,180), root:(446,1404), state 0x40, keycode 65 (keysym 0xfe08, ISO_Next_Group), same_screen YES, XLookupString gives 0 bytes: XFilterEvent returns: False KeyPress event, serial 22, synthetic NO, window 0x5600337, root 0x7bf, subw 0x0, time 445854114, (393,180), root:(446,1404), state 0x40, keycode 65 (keysym 0xfe08, ISO_Next_Group), same_screen YES, XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False KeyRelease event, serial 22, synthetic NO, window 0x5600337, root 0x7bf, subw 0x0, time 445854273, (393,180), root:(446,1404), state 0x2040, keycode 65 (keysym 0xfe08, ISO_Next_Group), same_screen YES, XLookupString gives 0 bytes: XFilterEvent returns: False KeyRelease event, serial 22, synthetic NO, window 0x5600337, root 0x7bf, subw 0x0, time 445854464, (393,180), root:(446,1404), state 0x2040, keycode 133 (keysym 0xffeb, Super_L), same_screen YES, XLookupString gives 0 bytes: XFilterEvent returns: False ``` and on the qube side: ``` KeyPress event, serial 38, synthetic NO, window 0x1600001, root 0x52f, subw 0x0, time 397271034, (93,55), root:(1308,1896), state 0x0, keycode 133 (keysym 0xffeb, Super_L), same_screen YES, XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False KeyPress event, serial 38, synthetic NO, window 0x1600001, root 0x52f, subw 0x0, time 397271185, (93,55), root:(1308,1896), state 0x40, keycode 65 (keysym 0x20, space), same_screen YES, XLookupString gives 1 bytes: (20) " " XmbLookupString gives 1 bytes: (20) " " XFilterEvent returns: False KeyRelease event, serial 38, synthetic NO, window 0x1600001, root 0x52f, subw 0x0, time 397271289, (93,55), root:(1308,1896), state 0x40, keycode 65 (keysym 0x20, space), same_screen YES, XLookupString gives 1 bytes: (20) " " XFilterEvent returns: False MappingNotify event, serial 38, synthetic NO, window 0x0, request MappingKeyboard, first_keycode 8, count 248 MappingNotify event, serial 38, synthetic NO, window 0x0, request MappingKeyboard, first_keycode 8, count 248 MappingNotify event, serial 38, synthetic NO, window 0x0, request MappingKeyboard, first_keycode 8, count 248 KeyRelease event, serial 41, synthetic NO, window 0x1600001, root 0x52f, subw 0x0, time 397271588, (93,55), root:(1308,1896), state 0x40, keycode 133 (keysym 0xffeb, Super_L), same_screen YES, XLookupString gives 0 bytes: XFilterEvent returns: False ``` (MappingNotify is likely caused by actually layout change)

xev output with "both ctrls together"

``` KeyRelease event, serial 39, synthetic NO, window 0x5600337, root 0x7bf, subw 0x0, time 446080174, (276,52), root:(329,1276), state 0x0, keycode 37 (keysym 0xffe3, Control_L), same_screen YES, XLookupString gives 0 bytes: XFilterEvent returns: False KeyPress event, serial 39, synthetic NO, window 0x5600337, root 0x7bf, subw 0x0, time 446080174, (276,52), root:(329,1276), state 0x0, keycode 37 (keysym 0xffe3, Control_L), same_screen YES, XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False KeyRelease event, serial 39, synthetic NO, window 0x5600337, root 0x7bf, subw 0x0, time 446080542, (276,52), root:(329,1276), state 0x4, keycode 105 (keysym 0xfe08, ISO_Next_Group), same_screen YES, XLookupString gives 0 bytes: XFilterEvent returns: False KeyPress event, serial 39, synthetic NO, window 0x5600337, root 0x7bf, subw 0x0, time 446080542, (276,52), root:(329,1276), state 0x4, keycode 105 (keysym 0xfe08, ISO_Next_Group), same_screen YES, XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False KeyRelease event, serial 39, synthetic NO, window 0x5600337, root 0x7bf, subw 0x0, time 446080716, (276,52), root:(329,1276), state 0x2004, keycode 105 (keysym 0xfe08, ISO_Next_Group), same_screen YES, XLookupString gives 0 bytes: XFilterEvent returns: False KeyRelease event, serial 39, synthetic NO, window 0x5600337, root 0x7bf, subw 0x0, time 446081133, (276,52), root:(329,1276), state 0x2004, keycode 37 (keysym 0xfe0a, ISO_Prev_Group), same_screen YES, XLookupString gives 0 bytes: XFilterEvent returns: False ``` And on the qube side: ``` KeyPress event, serial 29, synthetic NO, window 0x1600001, root 0x52f, subw 0x0, time 397166617, (-206,-361), root:(1009,1480), state 0x0, keycode 37 (keysym 0xffe3, Control_L), same_screen YES, XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False KeyPress event, serial 32, synthetic NO, window 0x1600001, root 0x52f, subw 0x0, time 397166869, (-206,-361), root:(1009,1480), state 0x4, keycode 105 (keysym 0xffe4, Control_R), same_screen YES, XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False KeyRelease event, serial 32, synthetic NO, window 0x1600001, root 0x52f, subw 0x0, time 397167014, (-206,-361), root:(1009,1480), state 0x4, keycode 105 (keysym 0xffe4, Control_R), same_screen YES, XLookupString gives 0 bytes: XFilterEvent returns: False MappingNotify event, serial 32, synthetic NO, window 0x0, request MappingKeyboard, first_keycode 8, count 248 MappingNotify event, serial 32, synthetic NO, window 0x0, request MappingKeyboard, first_keycode 8, count 248 MappingNotify event, serial 32, synthetic NO, window 0x0, request MappingKeyboard, first_keycode 8, count 248 KeyRelease event, serial 35, synthetic NO, window 0x1600001, root 0x52f, subw 0x0, time 397167316, (-206,-361), root:(1009,1480), state 0x4, keycode 37 (keysym 0xffe3, Control_L), same_screen YES, XLookupString gives 0 bytes: XFilterEvent returns: False ``` (MappingNotify is likely caused by actually layout change)

I'm a bit confused why it starts with KeyRelease, as well as what ISO_Prev_Group is doing there. But it looks like indeed the application does get those key events normally. If you look closely, in both cases the final key for the combo has keysym set to ISO_Next_Group (on dom0 side), but depending on settings, it has different keycode. On the other hand, there is no such mapping on the qube side. And this is correct, as qube doesn't know what key is set to switch keyboard layout. And if it would know, that would have an undesirable side effect - layout switching twice, and quickly desynchronize with dom0. I guess the solution is to simply filter out ISO_Next_group/ISO_Prev_Group on the GUI daemon side.