Bug 1437569

Created attachment 1268319 [details]
xev trace from linux client where Pipe is working

Created attachment 1268320 [details]
xev trace from windows client where Pipe is not working

Hi,

I managed to reproduce this issue with TigerVNC client (viewer) running on windows and TigerVNC server running on Linux. I did some investigation and it appears that this is not actually a bug, but it's by designed to work this way. here is a snip of documentation about keyboard keys from TigerVNC:

- Modifiers:

  X11: You can usually toggle Hyper/Super and Compose/Scroll_Lock using
       XKB options.

  - CapsLock, NumLock (sent but ignored by server)
  - Shift, Ctrl
  - Alt, AltGr, Super [Win, X11] (FIXME: AltGr broken on Win)
  - Meta [X11]
  - Left/right identification (FIXME: broken for Shift on Win)
  - CmdL => AltL, CmdR => SuperL, AltL => ModeSwitch, AltR => Level3Shift [OS X]
  - Hyper sends Super [X11]

  - CapsLock, Shift and AltGr affect symbol lookup
  - Ctrl does not affect symbol lookup
  - CtrlL+AltR is fake released to compensate for Windows' AltGr magic [Win]
  - Ctrl+Alt+<ANY> sends the same symbol as <ANY> (note behaviour above though)
  - Ctrl+AltGr+<ANY> sends the same symbol as AltGr+<ANY> (FIXME: broken on Win)
  - "Shift press, A press, Shift release, A release" should not send "a release"

So as you can see, using Ctrl + Alt + ANY_KEY results into pressing just ANY_KEY. I don't think I can do anything about this at this moment. I also tested this with TightVNC (another vnc client) and this one is configured differently and sending Ctrl + Alt + ANY_KEY worked just fine.

Source code for reference:
https://github.com/TigerVNC/tigervnc/blob/master/vncviewer/Viewport.cxx#L447

I tested following:

1) Install RHEL Workstation 9 (with RHEL 8 it should be same) into GNOME Boxes
2) Disable GDM with "systemctl disable gdm.service"
3) Reboot → Login → run "startx" 
4) GNOME starts → open GNOME terminal
5) Run "vncpasswd" to setup password for VNC
6) Run "x0vncserver -Display :0 -PasswordFile=/home/jgrulich/.vnc/passwd -AlwaysShared=1"
7) Set German keyboard layout on the client
8) Run "vncviewer" for Windows using Wine and connect to the server
9) Try to type e.g. "|" with AltGr + "|" on the keyboard button next to the shift on the left side
10) Observe it doesn't type anything

Workaround:
1) Set German keyboard layout on the server
2) Run "x0vncserver -Display :0 -PasswordFile=/home/jgrulich/.vnc/passwd -AlwaysShared=1 -RawKeyboard" 
- from documentation: send keyboard events straight through and avoids mapping them to the current keyboard layout. This effectively makes the keyboard behave according to the layout configured on the server instead of the layout configured on the client.
3) Run "vncviewer" for Windows using Wine and connect to the server
4) Try to type e.g. "|" with AltGr + "|" on the keyboard button next to the shift on the left side
5) Observe it types "|" as expected

Can you try to use "-RawKeyboard" option and verify it works for you as expected?

I have a fix pending upstream: https://github.com/TigerVNC/tigervnc/pull/1510

It was confirmed by the customer that this fixes the issue, I'm just waiting on feedback from upstream whether we should do it this way or whether we should hide it under an option so we don't break default behavior for other users.

Reproduced with old tigervnc-1.12.0-7 - cannot type '|' to vnc server

installed new tigervnc-1.12.0-8 - I can now type the '|' from Win10 client to RHEL8 vnc server

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (Moderate: tigervnc security and bug fix update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2023:2830