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.
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.
Server log
Output from the bug report tool for the keyboard info
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
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.
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?
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)
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.
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)
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:
--keyboard-layout=es
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).
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
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.
Finally fixed in #2983.
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/1282