Keypad numbers not being regocnized correctly

[Kimmo]

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

[DRC]

I can't reproduce the issue, even with a Finnish keyboard layout on the client.  Weird.

[Kimmo]

Actually I'm not suprised as you weren't able to reproduce https://sourceforge.net/p/virtualgl/feature-requests/13/ issue either.

It somehow seems to be so that only after some KP_X (where X is numerical) key is received at the server side, the server starts to receive them correctly.

KP_END, KP_INSERT, etc. keys were recognized correctly with num lock off even before the fix.

[DRC]

I can reproduce it now.  Investigating.

[Torsten Kupke]

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

--
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 turbovnc-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/turbovnc-users/e42d7c34-ed07-2cdb-1510-7a77c08bcd43%40virtualgl.org.

[DRC]

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.

To view this discussion on the web visit https://groups.google.com/d/msgid/turbovnc-users/2ea7d4a3-48ff-b94d-5878-ba249b697c7f%40hacon.de.

[DRC]

The keypad decimal issue has been fixed, and a new pre-release build with the fix should be available shortly.  Both flavors of the TurboVNC Viewer now read the preferred decimal symbol from the client's input locale and transmit XK_KP_Separator rather than XK_KP_Decimal if the decimal symbol is a comma.  However, since the TurboVNC Server has to translate key symbols back to key codes, XK_KP_Separator will be translated into a regular comma on the server unless the server's locale also uses comma as a decimal symbol.  In short, to make it fully work, you will need to use a German keyboard layout both on the client and in the TurboVNC session.  If the client uses a German keyboard layout but the server uses a U.S. keyboard layout, then pressing the keypad decimal key on the client will produce a regular comma (not a keypad separator comma) on the server.  Again,
https://github.com/TurboVNC/turbovnc/issues/108 will eliminate that issue, since it will send only raw key codes from the client (the server's keyboard layout will control everything.)