xpra icon
Bug tracker and wiki

Opened 3 years ago

Closed 3 years ago

#1282 closed defect (fixed)

Xpra in windows detects wrong keyboard

Reported by: observer Owned by: observer
Priority: major Milestone: 1.0
Component: keyboard Version: 0.17.x
Keywords: keyboard layout Cc:

Description

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.

Attachments (2)

kbd.log (4.8 KB) - added by observer 3 years ago.
Server log
kbd.txt (10.8 KB) - added by observer 3 years ago.
Output from the bug report tool for the keyboard info

Download all attachments as: .zip

Change History (12)

comment:1 Changed 3 years ago by Antoine Martin

Owner: changed from Antoine Martin to observer

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.

Changed 3 years ago by observer

Attachment: kbd.log added

Server log

Changed 3 years ago by observer

Attachment: kbd.txt added

Output from the bug report tool for the keyboard info

comment:2 Changed 3 years ago by 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

Last edited 3 years ago by Antoine Martin (previous) (diff)

comment:3 Changed 3 years ago by 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.

comment:4 Changed 3 years ago by 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?

Last edited 3 years ago by Antoine Martin (previous) (diff)

comment:5 Changed 3 years ago by 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:

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

comment:6 Changed 3 years ago by 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.

comment:7 Changed 3 years ago by 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)

Last edited 3 years ago by Antoine Martin (previous) (diff)

comment:8 Changed 3 years ago by 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:

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

comment:9 Changed 3 years ago by 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
Last edited 3 years ago by Antoine Martin (previous) (diff)

comment:10 Changed 3 years ago by Antoine Martin

Resolution: fixed
Status: newclosed

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.

Note: See TracTickets for help on using tickets.