VK_PACKET ignored by VNC viewer for Windows #1847
Comments
|
VK_PACKET is a bit problematic in that it doesn't give any physical key information. But I suppose we could try a best effort approach. Could you see if you could generate a debug log so we get some more details about the events? |
IIUC,
So I don't really see how lack of physical key information would provide any obstacle for supporting VK_PACKET on the client side.
I have tried for a very long time to build vncviewer.exe, to no avail. What I can do, is provide you with an event log from The test string is Here is the As you can see, Printing the test string on Linux using As you can see, It appears to me the only challenge on the [1] |
We need to track which keys are pressed to maintain a sane state for the server. We can't track symbols since a single key can generate different symbols. I wonder if
We already have debug output, you just need to enable it. No need to rebuild TigerVNC: https://github.com/TigerVNC/tigervnc/wiki/Debug-Logs#client-1 That said, the build instructions should be current. Where did you get stuck?
Yeah, that looks like it would require some more state management. I wonder if it is worth the hassle. |
|
Hmm... To make things more confusing, WM_KEYUP only has 8 bits available for "scan code", which is quite insufficient for the 16 bits VK_PACKET needs. Looking at the Wine code, it suggest that VK_PACKET overwrites a few other fields as well. But that would need to be tested. |
|
If you manage to get a build going, please see how this patch works: diff --git a/vncviewer/Viewport.cxx b/vncviewer/Viewport.cxx
index e29c877cf..f66ef81a5 100644
--- a/vncviewer/Viewport.cxx
+++ b/vncviewer/Viewport.cxx
@@ -971,6 +971,15 @@ int Viewport::handleSystemEvent(void *event, void *data)
keyCode = 0x38;
}
+ // Windows will send VK_PACKET if it doesn't have a physical key
+ // associated with the event (e.g. from a mobile device virtual
+ // keyboard). In such cases, the "scan code" is actually a UTF-16
+ // code point.
+ if (vKey == VK_PACKET) {
+ isExtended = false;
+ keyCode = 0;
+ }
+
// Windows doesn't have a proper AltGr, but handles it using fake
// Ctrl+Alt. However the remote end might not be Windows, so we need
// to merge those in to a single AltGr event. We detect this case
@@ -1030,7 +1039,10 @@ int Viewport::handleSystemEvent(void *event, void *data)
if (keyCode == 0xb7)
keyCode = 0x54;
- keySym = win32_vkey_to_keysym(vKey, isExtended);
+ if (vKey == VK_PACKET)
+ keySym = ucs2keysym(msg->lParam >> 16);
+ else
+ keySym = win32_vkey_to_keysym(vKey, isExtended);
if (keySym == NoSymbol) {
if (isExtended)
vlog.error(_("No symbol for extended virtual key 0x%02x"), (int)vKey); |
You're talking about the server, while this ticket is only about the client.
Thank you. See vncviewer.log for an example when auto-typing the same example string I mentioned earlier.
See Dockerfile-debian.txt which you can run as
I'm willing to submit a PR if I can build and test. Keepass and vncviewer are pretty much the only windows programs I use, so it'd be nice if they can talk as intended :-)
My test above using
Would be happy to! I'd need help as explained above. |
I have a Windows build working now, using nix. This patch seems to change no behaviour. I'll look into the code eventually if you don't beat me to it. |
|
Could you share a debug log with the patch applied? There should hopefully be some more details. |
Fixes TigerVNC#1847 Co-authored-by: Pierre Ossman <[email protected]>
|
@CendioOssman Managed to fix it and opened a PR with a patch that works for me. |
Fixes TigerVNC#1847 Co-authored-by: Pierre Ossman <[email protected]>
Fixes TigerVNC#1847 Co-authored-by: Pierre Ossman <[email protected]>
Describe the bug
MS Windows has a special virtual keycode (VK) called
VK_PACKETthat indicates that the scan code is to be interpreted as a character code instead. This keycode is frequently used by applications that inject key events. It appears that VNC viewer ignores this keycode and sends no key events to the server. This bug likely also caused #1818.To Reproduce
Steps to reproduce the behavior:
"a'a^a`a~a.aaaaaappearing in the remote server's text editor.Expected behavior
The text
"a'a^a`a~ashould appear.Client (please complete the following information):
Server (please complete the following information):
x11vnc -N -forever -loop100 -usepw -nevershared -clear_keys -vAdditional context
-pipeinput "reopen:cat - > /tmp/keys.in.fifo"to thex11vncarguments to get a text stream of the key events received by the server.The text was updated successfully, but these errors were encountered: