Bug 7281 - Shift+Alt doesn't work with VMware and Windows client
Summary: Shift+Alt doesn't work with VMware and Windows client
Status: RESOLVED FIXED
Alias: None
Product: ThinLinc
Classification: Unclassified
Component: VNC (show other bugs)
Version: 1.3.1
Hardware: PC Unknown
: P2 Normal
Target Milestone: LowPrio
Assignee: Alex Tanskanen
URL:
Keywords: prosaic, upstream
Depends on: 7373
Blocks: 3523
  Show dependency treegraph
 
Reported: 2018-11-23 10:20 CET by Pierre Ossman
Modified: 2020-01-21 15:50 CET (History)
2 users (show)

See Also:
Acceptance Criteria:


Attachments

Description Pierre Ossman cendio 2018-11-23 10:20:01 CET
I have Ctrl+Shift+Alt configured as the key combination to release the keyboard grab in VMware. However this does not work reliably when I'm using the Windows client. Sometimes it breaks the grab, sometimes it doesn't.

It turns out after some experimenting that the problem is Shift+Alt. If I press the Alt before shift, then it works. But Shift before Alt breaks.
Comment 1 Pierre Ossman cendio 2018-11-23 10:24:51 CET
I had a look at this and the issue is that VMware looks at physical keys rather than symbols. On Linux Shift+Alt generally generates Meta, but not on Windows.
So Xvnc will find a different key when it sees the client sending Alt with Shift already pressed.

I've implemented a heuristic upstream to handle this:

https://github.com/TigerVNC/tigervnc/commit/3b532f87b26d791b0b64b87aa39141d1a81098e8

The basic principle is that if Shift+Alt in the server keyboard map generates Meta, then we'll use that key and send a Meta when we see the symbols Alt_* from a client and Shift is currently pressed.
Comment 2 Pierre Ossman cendio 2018-11-23 10:25:52 CET
Also note bug 5258 which is indirectly affected by this heuristic.
Comment 3 Alex Tanskanen cendio 2020-01-21 15:50:24 CET
Tested on a Windows 10 client against a RHEL 8 server with build 6364. Tested by pressing Shift+Alt and verified that it sends Meta with keycode 64 instead of 204 as previously. Also tested that Linux clients still have the correct behavior.

Note You need to log in before you can comment on or make changes to this bug.