Xpra: Ticket #1282: Xpra in windows detects wrong keyboard

In windows 10 I can select from about 4 latam keyboard layouts But even when I'm in Mexico and my regional settings are set for this country, I have an Spanish - Spain Keyboard not a Spanish - Latinamerica one. And those latam keyboards are not easy to found. I think the detection should be based in the keyboard settings from windows.



Fri, 12 Aug 2016 05:21:03 GMT - Antoine Martin: owner changed

I think the detection should be based in the keyboard settings from windows.


What makes you think that it isn't? What exact values are you seeing in the system tray, what does your server log show? Can you provide the keyboard information from the bug report tool?

As of r13306, we include a tool called "Keyboard_info" which will dump the values we detect using the native win32 API GetKeyboardLayout. As of r13308, the raw value from this API will also be logged when you run Keyboard_info.exe -v.

What do you see when you run this tool? This is available in the latest beta: http://xpra.org/beta/windows.


Fri, 12 Aug 2016 20:43:28 GMT - observer: attachment set

Server log


Fri, 12 Aug 2016 20:44:51 GMT - observer: attachment set

Output from the bug report tool for the keyboard info


Fri, 12 Aug 2016 20:52:50 GMT - observer:

Because I think its guessing my keyboard from my location, as a note also when I install windows it too adds a latam keyboard which I always remove.

These are the options in the keyboard menu:

latam - Default
latam - nodeadkey
latam - deadtilde
latam - sundeadkeys

And none of these works 100% with my keyboard

this is the output from the keyboard info tool

Keyboard_info.exe
Modifiers:
Server Managed                    : None
Missing from pointer events       : lock
Layout:     'latam'
Layouts:    ['latam']
Variant:    'None'
Variants:   ['nodeadkeys', 'deadtilde', 'sundeadkeys']
Repeat:     500, 33

I have attached the server log and the info from the bug reporting tool


Sat, 13 Aug 2016 03:26:34 GMT - Antoine Martin:

As per comment:1, please run with the Keyboard_info.exe -v with the "-v" flag, which will show use more details. It looks to me like windows is telling us that your keyboard layout is "latam"... so that's what we use.


Sat, 13 Aug 2016 03:29:45 GMT - observer:

This is the output

Keyboard_info.exe -v
Modifiers:
Server Managed                    : None
Missing from pointer events       : lock
win32api.GetKeyboardLayout(0)=0x40a080a
found keyboard layout 'latam' with variants=['nodeadkeys', 'deadtilde', 'sundeadkeys'], code 'ESM' for kbid=2058
Layout:     'latam'
Layouts:    ['latam']
Variant:    'None'
Variants:   ['nodeadkeys', 'deadtilde', 'sundeadkeys']
keyboard repeat speed(31)=33, delay(1)=500
Repeat:     500, 33

Just to be sure, latam is latin america isn't it?


Sat, 13 Aug 2016 04:07:58 GMT - Antoine Martin:

Yes "latam" is "latin america" in X11.

Your win32 keyboard id is 0x080a (the low half part of the GetKeyboardLayout value) and according to this Table of Language Culture Names, Codes, and ISO Values Method, this corresponds to es-MX Spanish - Mexico 0x080A ESM.

So I've changed our lookup table to do the right thing and use "es" (Spanish) for this particular value. There may well be other errors in that table... So maybe we should:

@observer: does that work better for you? (new beta posted)


Sat, 13 Aug 2016 06:07:53 GMT - observer:

It solved the problem with my desktop but I remembered that my laptop has a builtin latam keyboard which I almost never use, I use an usb spain keyboard most of the time, I tried the new beta on it to see what happens and again it detected the wrong keyboard this time the opposite way. I look at the windows docs for the function used but I didn't get clear what it really does. I think it is probably being used the wrong way or there may be some other function more appropiate to the isue. I'm not trying to make a problem of this but I can imagine people with keyboards that doesn't match the locale of the ui. Maybe a workaround could be a window to select the keyboard from every layout available like when fedora is installed, and that this value gets saved to the .xpra file so there is no need to repeat the process all the time.


Sat, 13 Aug 2016 06:42:29 GMT - Antoine Martin:

again it detected the wrong keyboard this time the opposite way.


Details please. I really do not understand what this means and will need data. If you have multiple keyboards, I am not sure this will work.


I think it is probably being used the wrong way or there may be some other function more appropiate to the isue.


It is the right function to call. Is your desired keyboard layout not "mexico" "spanish"?


Maybe a workaround could be a window to select the keyboard from every layout available like when fedora is installed, and that this value gets saved to the .xpra file so there is no need to repeat the process all the time.


I am planning on adding a layout option to the config file so that users can override the detection code. (without GUI at first)


Sat, 13 Aug 2016 10:36:45 GMT - Antoine Martin:


Because I think its guessing my keyboard from my location


No, the GetKeyboardLayout is for keyboard layouts, not locale or location.


As of r13332, you can:

Note: you can also change the "keyboard-variant", "keyboard-options", etc.. This ticket looks done to me. At the very least you should now have a viable workaround.

There may be other issues with the default keyboard translation table (win32 constants to X11 names - which is always going to be imperfect, and I don't have time to go through all of them).


Tue, 16 Aug 2016 23:32:45 GMT - observer:

It works for me now, but I want to add this since I think is relevant anyway

In the laptop as I said there are 2 keyboards installed, both are resolving to "es" now, one should resolve to "latam":

es:

./Keyboard_info.exe -v
Modifiers:
Server Managed                    : None
Missing from pointer events       : lock
win32api.GetKeyboardLayout(0)=0x40a080a
found keyboard layout 'es' with variants=['nodeadkeys', 'deadtilde', 'sundeadkeys', 'dvorak', 'est', 'cat', 'mac'], code 'ESM' for kbid=0x80a
Layout:     'es'
Layouts:    ['es']
Variant:    'None'
Variants:   ['nodeadkeys', 'deadtilde', 'sundeadkeys', 'dvorak', 'est', 'cat', 'mac']
keyboard repeat speed(31)=33, delay(1)=500
Repeat:     500, 33

latam:

./Keyboard_info.exe -v
Modifiers:
Server Managed                    : None
Missing from pointer events       : lock
win32api.GetKeyboardLayout(0)=0x80a080a
found keyboard layout 'es' with variants=['nodeadkeys', 'deadtilde', 'sundeadkeys', 'dvorak', 'est', 'cat', 'mac'], code 'ESM' for kbid=0x80a
Layout:     'es'
Layouts:    ['es']
Variant:    'None'
Variants:   ['nodeadkeys', 'deadtilde', 'sundeadkeys', 'dvorak', 'est', 'cat', 'mac']
keyboard repeat speed(31)=33, delay(1)=500
Repeat:     500, 33

Sun, 21 Aug 2016 10:03:59 GMT - Antoine Martin: status changed; resolution set

The windows API only has a single keyboard, all the input goes there, no matter how many keyboards are attached. Nothing we can do about this.


Wed, 30 Dec 2020 06:22:32 GMT - Antoine Martin:

Finally fixed in #2983.


Sat, 23 Jan 2021 05:20:01 GMT - migration script:

this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/1282