Xpra in windows detects wrong keyboard

[totaam]

Issue migrated from trac ticket # 1282

component: keyboard | priority: major | resolution: fixed | keywords: keyboard layout

2016-08-11 23:48:23: observer created the issue

---

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.

[totaam]

2016-08-12 06:21:04: antoine changed owner from antoine to observer

[totaam]

2016-08-12 06:21:04: antoine commented

---

I think the detection should be based in the keyboard settings from windows.
[[BR]]
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].

[totaam]

2016-08-12 21:43:29: observer uploaded file kbd.log (4.8 KiB)

Server log

[totaam]

2016-08-12 21:44:51: observer uploaded file kbd.txt (10.8 KiB)

Output from the bug report tool for the keyboard info

[totaam]

2016-08-12 21:52:50: observer commented

---

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

[totaam]

2016-08-13 04:26:35: antoine commented

---

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.

[totaam]

2016-08-13 04:29:45: observer commented

---

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?

[totaam]

2016-08-13 05:07:58: antoine commented

---

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:

• update it from the microsoft reference table
• provide a command line option to override the layout detection code (so that if we still get it wrong or if the user wants to use something else, we can do that)

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

[totaam]

2016-08-13 07:07:53: observer commented

---

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.

[totaam]

2016-08-13 07:42:30: antoine commented

---

again it detected the wrong keyboard this time the opposite way.
[[BR]]
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.

[[BR]]

I think it is probably being used the wrong way or there may be some other function more appropiate to the isue.
[[BR]]
It is the right function to call.
Is your desired keyboard layout not "mexico" "spanish"?

[[BR]]

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.
[[BR]]
I am planning on adding a layout option to the config file so that users can override the detection code. (without GUI at first)

[totaam]

2016-08-13 11:36:46: antoine commented

---

[[BR]]

Because I think its guessing my keyboard from my location
[[BR]]
No, the GetKeyboardLayout is for keyboard layouts, not locale or location.

---

As of 13332, you can:

• use the command line argument --keyboard-layout=es
• set this option in xpra.conf

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).

[totaam]

2016-08-17 00:32:46: observer commented

---

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

[totaam]

2016-08-21 11:03:59: antoine changed status from new to closed

[totaam]

2016-08-21 11:03:59: antoine set resolution to fixed

[totaam]

2016-08-21 11:03:59: antoine commented

---

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.

[totaam]

2020-12-30 06:22:33: antoine commented

---

Finally fixed in #2983.