Correction from my end: I did not reproduce the issue. I was just misreading the output of xev. Sorry about that.
I tried the following sequence several times to ensure that no keystrokes were sent to the server prior to the keypad keystrokes: - (in an SSH session) Start a new TurboVNC session (TurboVNC Server v2.2.3.) - (in the SSH session) Start xev on the TurboVNC display. - (on the Windows client) Connect to the session using the native TurboVNC Viewer (also v2.2.3.) - (on the Windows client) With the TurboVNC Viewer window active, switch to the Finnish keyboard layout. - Press several keypad number keys in sequence. - Observe the output of xev in the SSH session (it always says "KP_X" for the keystrokes, which is correct.) As far as the German keypad comma vs. period issue, Windows doesn't distinguish between the two at the low level. It always generates a WM_KEYDOWN or WM_KEYUP message with a virtual key code of VK_DECIMAL, which TurboVNC transmits as XK_KP_Decimal. I'm guessing that Windows applications call some sort of higher-level API function to determine which symbol should be rendered for the decimal symbol, but such is not a function of the key map. It's determined by the other region and language settings. On Linux, it is a function of the keymap, and the keypad decimal key produces a keysym of XK_KP_Separator with a German layout and a keysym of XK_KP_Decimal with a U.S. layout. I'll see if it's possible to emulate this behavior. I'll say again that this feature: https://github.com/TurboVNC/turbovnc/issues/108 would render a lot of these issues academic. I have made some progress on it using the general fund but will need specific project funding in order to finish it. On 10/24/19 3:45 PM, Torsten Kupke wrote: > > Hi, > > I just tested it with a german keyboard. All the number keys on the > keypad produce the correct numbers. I'm using the native Windows > viewer and the server version 2.2.3 like Kimmo too. I see only one > little difference: The del key on the keypad labeled with a comma for > num lock on produces a comma under the local Windows OS and a period > point on the remote host with the TurboVNC server. For your info: In > german language the period point is a comma. All other keypad keys do > what they should do. And the cursor control functions with num lock > off also work fine. > > Best regards > > Torsten > > Am 24.10.2019 um 21:32 schrieb DRC: >> >> I can't reproduce the issue, even with a Finnish keyboard layout on >> the client. Weird. >> >> >> On 10/24/19 2:24 PM, Kimmo wrote: >>> Hello, >>> >>> I didn't find any post on this issue so I thought this might be useful for >>> somebody strugling with the keypad numbers not being recognized correctly >>> on the server side. >>> >>> I noticed the keypad numbers (with num lock on) were recognized as regular >>> numerical keys (on the top row of the keyboard) on the server side. I >>> checked this with 'xev'. This is not an issue in most cases but for example >>> with Blender there is a difference between the numerical keys and numpad >>> keys. >>> >>> I was able to fix this issue by opening 'Onboard' (on-screen-keyboard) in >>> VNC session on Mate desktop. By first inserting some keypad number with the >>> 'Onboard' (with num lock on) the keypad keys entered from the client side >>> physical keyboard were recognized correctly as KP_X keys. The keypad keys >>> were recognized correctly even after server side reboot. >>> >>> The same behaviour was observed with four different systems with Ubuntu >>> 16.04 and 18.04. The Mate desktop environment and lightdm was used in all >>> cases. All the keyboards used in the testing had Finnish layout but I'm not >>> sure if that has anything to do with this issue. The viewer was the >>> non-Java Windows version and the TurboVNC server version was 2.2.3. >>> >>> Great software regardless of this issue. >>> >>> -Kimmo >>> >> >> -- >> You received this message because you are subscribed to the Google >> Groups "TurboVNC User Discussion/Support" group. >> To unsubscribe from this group and stop receiving emails from it, >> send an email to [email protected] >> <mailto:[email protected]>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/turbovnc-users/e42d7c34-ed07-2cdb-1510-7a77c08bcd43%40virtualgl.org >> <https://groups.google.com/d/msgid/turbovnc-users/e42d7c34-ed07-2cdb-1510-7a77c08bcd43%40virtualgl.org?utm_medium=email&utm_source=footer>. > -- > You received this message because you are subscribed to the Google > Groups "TurboVNC User Discussion/Support" group. > To unsubscribe from this group and stop receiving emails from it, send > an email to [email protected] > <mailto:[email protected]>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/turbovnc-users/2ea7d4a3-48ff-b94d-5878-ba249b697c7f%40hacon.de > <https://groups.google.com/d/msgid/turbovnc-users/2ea7d4a3-48ff-b94d-5878-ba249b697c7f%40hacon.de?utm_medium=email&utm_source=footer>. -- You received this message because you are subscribed to the Google Groups "TurboVNC User Discussion/Support" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/turbovnc-users/e8bd833d-e7df-8d2a-26fd-1384180eca62%40virtualgl.org.
