numpad dot issue

[jouven]

I know this was a change from 2.2.4, but the situation here is: On the viewer side: Spanish keyboard, Spanish locale, language English, windows 10 On the server side: Debian 10 bullseye, doesn't matter the locale or language, the end result is a comma printed when hitting the numpad dot (I went crazy trying stuff until I though it might be a turbovnc issue) Since 2.2.4 the numpad dot character is rebinded to a comma, but in regular use, no vnc involved, in a Spanish keyboard the numpad dot is symbolized with a dot and pressing it writes a dot even with the Spanish locale (in windows or Linux), the comma is only used to display numbers What I mean is: it's a locale display characteristic not a keyboard one, in windows or Linux these two things are independent and locale doesn't define how the keyboard behaves I don't know if Spanish is the only case but it might happen to other languages Also changing the number decimal symbol in windows doesn't change this behavior, then again it's possible that the configuration is not pulled from the windows settings

[dcommander]

I think I see the problem. Stand by.

[dcommander]

You are correct that the decimal separator can be configured independently of the keyboard layout, but that decimal separator setting only affects the display of numbers in dialogs and such. The key symbol that is generated when you press the numeric keypad decimal separator key is purely a function of the keyboard layout. Thus, I believe that it is correct for the TurboVNC Viewer to use the current keyboard layout to base its decision regarding whether to send XK_KP_Separator or XK_KP_Decimal. Ultimately, we are trying to emulate the behavior of Linux, which generates XK_KP_Separator or XK_KP_Decimal for the keypad decimal separator key depending on the keyboard layout.

Let's take three example keyboard layouts that demonstrate the issue: U.S., German, Spanish. On Linux, both U.S. and Spanish keyboard layouts generate XK_KP_Decimal for the keypad separator key, and the German keyboard layout generates XK_KP_Separator, so that's the target behavior. On Windows, the three keyboard layouts generate the same key symbol for the keypad decimal separator key as on Linux. On Mac, the Spanish keyboard layout generates , for the keypad decimal separator key, so there is one problem. The second problem is that, on Windows, GetLocaleInfo(..., LOCALE_SDECIMAL, ...) returns an incorrect value for the keyboard locale if using a Spanish keyboard. Even though the Spanish keyboard layout generates . when the keypad decimal separator key is pressed, GetLocaleInfo(..., LOCALE_SDECIMAL, ...) returns ,. So the root of the issue isn't that TurboVNC is using the keyboard layout to determine whether or not to send XK_KP_Separator or XK_KP_Decimal. The root of the issue is that Windows is behaving incorrectly. Now I just have to figure out how to work around the incorrect behavior. :|

[jouven]

I don't know what's the "linux behavior" is but my specific issue was having a key mapping that wasn't 1:1, e.g., I press something but it's remap to something else, plus there is no workaround except using 2.2.3 or older

I'm no expert and I don't want to impose but it seems it's not a good idea to check for this information in the locale configuration since as we discussed locale != keyboard layout, but maybe there is more to it. It seems locale and keyboard layout can coincide in some languages but that might not be always the case

Searching a bit there are libraries to deal with this at keyboard level see this answer https://stackoverflow.com/a/8737733/4224866 also https://blog.molecular-matters.com/2011/09/05/properly-handling-keyboard-input/

[dcommander]

Should be fixed now. Please test using the latest 2.2.x Windows pre-release build.

[dcommander]

Note: on Windows, the keyboard locale and the system locale are not the same thing. I was probing LOCALE_SDECIMAL from the keyboard locale, and this should have correctly reflected the fact that the Spanish keyboard layout generated . for the keypad decimal key. It did not, which I posit is a Windows bug. See the commit log for information regarding how I worked around it.

[jouven]

Tested the pre-release build for windows, it's fixed with the "TurboVNC Viewer" but the "Java TurboVNC Viewer" still exhibits the old behavior

[dcommander]

Should now be fixed in the Java viewer as well. Pre-release builds will be available in a few minutes.

[jouven]

Tried the new build for windows, it's fixed in both the "TurboVNC Viewer" and the "Java TurboVNC Viewer" now Thanks for fixing this issue