A bug made itself present in VkKeyScan's handling of the less-than character on US (and other) keyboard layouts. VkKeyScan('<') in Windows returns 0x1bc, which is VK_OEM_COMMA with the shift key flag set. In Wine, VkKeyScan('<') returns 0xe2, which is VK_OEM_102, or the VK for the "infamous phantom key".
The root cause of this is X's XKeysymToKeycode returning the keycode for the phantom key instead of the keycode for the comma key when passed the keysym for '<' (XK_less). This isn't incorrect on X's part, but inconvenient for Wine as most US keyboards don't have the <> key, but rather use the shifted comma key.
The attached patch adds a new field in the main_key_tab structure. The new field indicates which keysym, if any, should be passed to XKeysymToKeycode instead of '<'. I've filled this field in for every keyboard type already defined in keyboard.c.
Since winex11.drv is a pretty touchy part of Wine, I'm sending this patch to wine-devel for review. I don't have the hardware or software setup to test other language inputs, and LoadKeyboardLayout is not implemented so I can't just test with VkKeyScanEx. If you're using a foreign keyboard, especially one with a <> key, please test VkKeyScan's handling of the '<' character with this patch applied.
Thanks Andrew
Andrew Eikum wrote:
A bug made itself present in VkKeyScan's handling of the less-than character on US (and other) keyboard layouts. VkKeyScan('<') in Windows returns 0x1bc, which is VK_OEM_COMMA with the shift key flag set. In Wine, VkKeyScan('<') returns 0xe2, which is VK_OEM_102, or the VK for the "infamous phantom key".
The root cause of this is X's XKeysymToKeycode returning the keycode for the phantom key instead of the keycode for the comma key when passed the keysym for '<' (XK_less). This isn't incorrect on X's part, but inconvenient for Wine as most US keyboards don't have the <> key, but rather use the shifted comma key.
The attached patch adds a new field in the main_key_tab structure. The new field indicates which keysym, if any, should be passed to XKeysymToKeycode instead of '<'. I've filled this field in for every keyboard type already defined in keyboard.c.
Since winex11.drv is a pretty touchy part of Wine, I'm sending this patch to wine-devel for review. I don't have the hardware or software setup to test other language inputs, and LoadKeyboardLayout is not implemented so I can't just test with VkKeyScanEx. If you're using a foreign keyboard, especially one with a <> key, please test VkKeyScan's handling of the '<' character with this patch applied.
Thanks Andrew
Here also are some test cases to test with. They are set up for my keyboard. Your setup might expect VK_OEM_102 to be returned instead of VK_OEM_COMMA. Modify as appropriate.
"Andrew Eikum" aeikum@codeweavers.com wrote:
The root cause of this is X's XKeysymToKeycode returning the keycode for the phantom key instead of the keycode for the comma key when passed the keysym for '<' (XK_less). This isn't incorrect on X's part, but inconvenient for Wine as most US keyboards don't have the <> key, but rather use the shifted comma key.
Why do you think that it's OK for X11 to return the phantom key for '<' from XKeysymToKeycode? That's clearly a problem with X11 keyboard layout. Are you going to introduce another hack if/once X11 starts to return something else?
It seems to be 'OK' for X11 to return that because everyone in the X11 universe seems to just accept that as how X works. Not fixing it wine would mean require all wine users to use something like xmodmap to modify their own xservers to get the correct behavior.
That doesn't seem like an acceptable solution. -aric
Dmitry Timoshkov wrote:
"Andrew Eikum" aeikum@codeweavers.com wrote:
The root cause of this is X's XKeysymToKeycode returning the keycode for the phantom key instead of the keycode for the comma key when passed the keysym for '<' (XK_less). This isn't incorrect on X's part, but inconvenient for Wine as most US keyboards don't have the <> key, but rather use the shifted comma key.
Why do you think that it's OK for X11 to return the phantom key for '<' from XKeysymToKeycode? That's clearly a problem with X11 keyboard layout. Are you going to introduce another hack if/once X11 starts to return something else?
"Aric Stewart" aric@codeweavers.com wrote:
It seems to be 'OK' for X11 to return that because everyone in the X11 universe seems to just accept that as how X works.
Could you please provide an example of this? How other projetcs cope with that?
Having an appropriate X11 keyboard layout activated is exactly the same kind of thing as having an appropriate X11 locale, or a sensible font set. Just because Wine depends on this.
Many users don't have it set correctly, and both KDE and Gnome have workarounds/hacks for that. But it doesn't mean that Wine has to workaround or hack every user misconfiguration.
It was always a Wine policy to ask users to properly configure their system, and report the bugs to other projects. That's not different from gcc/binutils/kernel/WM/pulseaudio/video drivers/etc. bugs.
Not fixing it wine would mean require all wine users to use something like xmodmap to modify their own xservers to get the correct behavior.
Using the keyboard layout selector in Gnome/KDE or any other environment should be enough. Besides it's hard to call this hack a "fix".
Dmitry Timoshkov wrote:
"Aric Stewart" aric@codeweavers.com wrote:
It seems to be 'OK' for X11 to return that because everyone in the X11 universe seems to just accept that as how X works.
Could you please provide an example of this? How other projetcs cope with that?
Having an appropriate X11 keyboard layout activated is exactly the same kind of thing as having an appropriate X11 locale, or a sensible font set. Just because Wine depends on this.
Many users don't have it set correctly, and both KDE and Gnome have workarounds/hacks for that. But it doesn't mean that Wine has to workaround or hack every user misconfiguration.
It was always a Wine policy to ask users to properly configure their system, and report the bugs to other projects. That's not different from gcc/binutils/kernel/WM/pulseaudio/video drivers/etc. bugs.
Not fixing it wine would mean require all wine users to use something like xmodmap to modify their own xservers to get the correct behavior.
Using the keyboard layout selector in Gnome/KDE or any other environment should be enough. Besides it's hard to call this hack a "fix".
You're right, it's a keyboard layout problem. I thought it was a deeper problem than that. Unfortunately there doesn't seem to be a US keyboard layout, at least in my Ubuntu selector, which does not have this key. This looks to be a problem with whoever provides the keyboard layouts.
I'll do some more research and try to report this upstream.
-
Andrew Eikum -
Aric Stewart -
Dmitry Timoshkov