alt+g not working with the QEMU Extended Key Event extension

[TobiaszCudnik]

Useful information:

When using TurboVNC with QEMU Extended Key Event extension enabled, some key combos like alt+g stop working. Source issue with more context: TurboVNC/turbovnc#377. When forcefully disabling QEMU Extended Key Event, alt+g works fine.

Default us layout on both client and server, macos client.

• Version:

TurboVNC Viewer v3.0.91 (build 20230818) [JVM: x86_64]
wayvnc: v0.6.2-0-gfd652e7 (makepkg)
neatvnc: v0.6.0-0-g8b3dc1a (makepkg)
aml: v0.3.0-0-gb83f357 (makepkg)

• Try to reproduce while capturing a trace log:

wayvnc for alt+g with Extended Key Event

ERROR: ../wayvnc/src/keyboard.c: 400: Failed to look up keyboard symbol: copyright
ERROR: ../wayvnc/src/keyboard.c: 400: Failed to look up keyboard symbol: copyright

xkbcli for alt+g with Extended Key Event

$ xkbcli interactive-wayland
seat0: keysyms [ g                ] unicode [ g ] layout [ English (US) (0) ] level [ 0 ] mods [ ] leds [ ] 
seat0: keysyms [ Alt_L            ] unicode [  ] layout [ English (US) (0) ] level [ 0 ] mods [ Mod1 ] leds [ ] 

xkbcli for alt+g WITHOUT Extended Key Event

$ xkbcli interactive-wayland
seat0: keysyms [ g                ] unicode [ g ] layout [ English (US) (0) ] level [ 0 ] mods [ ] leds [ ] 
seat0: keysyms [ Alt_L            ] unicode [  ] layout [ English (US) (0) ] level [ 0 ] mods [ Mod1 ] leds [ ] 
seat0: keysyms [ g                ] unicode [ g ] layout [ English (US) (0) ] level [ 0 ] mods [ Mod1 ] leds [ ] 

• Describe how to reproduce the problem
  1. Use the latest TurboVNC beta on macos
  2. Connect to wayvnc with a default layout
  3. Run xkbcli interactive-wayland or any other keypress viewer

Workaround: disable the extension via -serverkeymap=0

[any1]

I tested git master against wlvncc and Tiger VNC and it works fine.

Based on your trace log, it looks like Turbo VNC is still sending symbol events.

[dcommander]

@any1 You are correct. The TurboVNC Viewer was falling back to regular RFB key events if the VNC server didn't support either the QEMU or VMware LED State extension. I fixed that issue in TurboVNC/turbovnc@b4fd6ae. However, I would suggest that support for one of those LED State extensions be added to neatvnc. Otherwise, the lock key states will become decoupled between the client and the VNC server if one of the lock keys is pressed outside of the VNC viewer window. (In fact, that is exactly what happens when using the TigerVNC Viewer, or the TurboVNC Viewer with the aforementioned fix, with wayvnc.)

[any1]

@dcommander Can't the client remember the state and re-apply it when it receives focus? Or maybe just send key events to the server?

[dcommander]

@any1 Not without one of the LED State extensions. The problem is two-fold:

1. Most VNC servers, including TurboVNC and TigerVNC, allow multiple simultaneous viewer connections for collaboration purposes. Thus, when the viewer window receives focus again, the viewer actually doesn't know what the lock key states are on the server anymore, because another connected viewer may have modified them.
2. Even if the VNC server doesn't allow multiple simultaneous connections, consider the case of pressing one of the lock keys in the VNC viewer window (which would synchronize the lock key state with the VNC server), quitting the VNC viewer, pressing the lock key again, then reconnecting to the same VNC server. In that case, the lock key state would also become decoupled between client and server, and there is no way that the viewer could remember it (because the viewer was restarted.)

[dcommander]

@any1 Upon further reflection, it isn't even necessary for the VNC server to allow multiple simultaneous connected viewers in order to experience Problem 1 above. The lock key state for an X11 or Wayland display can be modified from a command line program, and such a program could be run in an SSH shell with either DISPLAY or WAYLAND_DISPLAY pointed to the VNC server. Or, if the VNC server is a screen scraper connected to the host's primary display, then someone sitting in front of the host could simply press one of the lock keys.

[any1]

@dcommander I'd say problem "3" is pretty much the same thing as problem 1. They can both be solved by enabling multi-seat in wayvnc, but that's not enabled by default.

Problem 2 wasn't entirely clear to me, but I think I understand it now: The client doesn't know the server's state when it connects, so it doesn't know which lock keys to toggle if it wants to synchronise the state.

Thanks for explaining!

[dcommander]

Out of curiosity, what does multi-seat do?

[any1]

Out of curiosity, what does multi-seat do?

Each user has their own separate input state and window focus.