http://bugs.winehq.org/show_bug.cgi?id=28168
Summary: VK_OEM_3 (0xC0) not converted into (0xC0) if US keyboard requested Product: Wine Version: 1.3.26 Platform: x86 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: winex11.drv AssignedTo: wine-bugs@winehq.org ReportedBy: Sebastian.Riemer@gmx.de
E.g.: Carmageddon TDR 2000 requests an US keyboard layout no matter for which language version of the game. It also gets this for most keys.
But for the cheating console the VK_OEM_3 (0xC0) is needed and MapVirtualKeyExW() in dlls/user32/input.c has to return 0xC0, too.
But instead it returns 0x5E (^) on my German KDE4 openSUSE 11.3 amd64 system - so this key isn't converted to US keyboard layout. On my German Windows XP it works as expected (0xC0 is returned).
I've also tried to enable the KDE4 keyboard layouts and to switch to US layout with that, but this didn't help.
Here is my dirty fix with which I've tested it:
UINT WINAPI MapVirtualKeyExW(UINT code, UINT maptype, HKL hkl) { TRACE_(keyboard)("(%X, %d, %p)\n", code, maptype, hkl);
/* dirty fix for testing VK_OEM_3 */ if (code == 0xC0) return 0xC0;
return USER_Driver->pMapVirtualKeyEx(code, maptype, hkl); }
http://bugs.winehq.org/show_bug.cgi?id=28168
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |patch Severity|normal |minor
http://bugs.winehq.org/show_bug.cgi?id=28168
--- Comment #1 from Sebastian Riemer Sebastian.Riemer@gmx.de 2011-08-25 02:08:57 CDT --- Created an attachment (id=36096) --> (http://bugs.winehq.org/attachment.cgi?id=36096) This fixes VK_OEM_3 in MAPVK_VK_TO_CHAR converting
VK_OEM_3 (0xC0) has to remain 0xC0 for MAPVK_VK_TO_CHAR instead of asking the X11 server. This patches X11DRV_MapVirtualKeyEx() in dlls/winex11.drv/keyboard.c for wine 1.3.26.
http://bugs.winehq.org/show_bug.cgi?id=28168
Sebastian Riemer Sebastian.Riemer@gmx.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|VK_OEM_3 (0xC0) not |VK_OEM_3 (0xC0) not |converted into (0xC0) if US |converted into 0xC0 if |keyboard requested |MAPVK_VK_TO_CHAR requested
http://bugs.winehq.org/show_bug.cgi?id=28168
--- Comment #2 from Austin English austinenglish@gmail.com 2011-08-25 05:43:30 CDT --- Patches should be sent to wine-patches@winehq.org. They aren't picked up here.
http://bugs.winehq.org/show_bug.cgi?id=28168
--- Comment #3 from Dmitry Timoshkov dmitry@baikal.ru 2011-08-25 06:19:38 CDT --- A test case for MapVirtualKeyExW() should be written first to confirm that 0xc0 is correct value for all keyboard layouts and locales.
http://bugs.winehq.org/show_bug.cgi?id=28168
--- Comment #4 from Sebastian Riemer Sebastian.Riemer@gmx.de 2011-08-25 10:58:27 CDT --- (In reply to comment #3)
A test case for MapVirtualKeyExW() should be written first to confirm that 0xc0 is correct value for all keyboard layouts and locales.
This is the next step, yes. I'll attach my test tool, will run it on my German Windows and on my German KDE4 with wine 1.3.26.
The point is that MAPVK_VK_TO_CHAR is used to be independent from locales and keyboard layouts. Don't know why Wine is asking the X11 server for this.
And, yes I know - no one will find and use an unfinished patch I submit here. But it helps in the AppDB to have a quick fix (and to track what was tested).
http://bugs.winehq.org/show_bug.cgi?id=28168
--- Comment #5 from Sebastian Riemer Sebastian.Riemer@gmx.de 2011-08-25 11:06:03 CDT --- Created an attachment (id=36100) --> (http://bugs.winehq.org/attachment.cgi?id=36100) vkey to key test tool
This is a simple vkey to key iteration which uses MAPVK_VK_TO_CHAR. It cross compiles with "i586-mingw32msvc-gcc keycheck.c -o keycheck.exe" and runs with wine. Test results will be submitted shortly.
http://bugs.winehq.org/show_bug.cgi?id=28168
--- Comment #6 from Dmitry Timoshkov dmitry@baikal.ru 2011-08-25 12:06:29 CDT --- (In reply to comment #5)
Created an attachment (id=36100)
--> (http://bugs.winehq.org/attachment.cgi?id=36100) [details]
vkey to key test tool
That's not testing what I asked for. You need to enumerate all available keyboard layouts and activate them. Same for locales.
http://bugs.winehq.org/show_bug.cgi?id=28168
Sebastian Riemer Sebastian.Riemer@gmx.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|VK_OEM_3 (0xC0) not |VK_OEM_3 (0xC0) not |converted into 0xC0 if |converted correctly if |MAPVK_VK_TO_CHAR requested |MAPVK_VK_TO_CHAR requested
http://bugs.winehq.org/show_bug.cgi?id=28168
--- Comment #7 from Sebastian Riemer Sebastian.Riemer@gmx.de 2011-08-25 14:53:17 CDT --- (In reply to comment #6)
That's not testing what I asked for. You need to enumerate all available keyboard layouts and activate them. Same for locales.
You're right. I'm sorry, this really seems to be keyboard layout (and locale) specific. VK_OEM_3 is converted to 0xF6 on the German WinXP instead of 0xC0 and there are more keys different.
As you're the more experienced wine developer could you give me a hint which WINAPI calls to use in order to iterate through the keyboard layouts and locales? Perhaps you already have a little template?
That little test tool just needs to be extended then in order to obtain the correct mappings.
http://bugs.winehq.org/show_bug.cgi?id=28168
Dmitry Timoshkov dmitry@baikal.ru changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords|patch | Status|UNCONFIRMED |NEW Ever Confirmed|0 |1
--- Comment #8 from Dmitry Timoshkov dmitry@baikal.ru 2011-08-26 00:45:05 CDT --- I'd try something like GetKeyboardLayoutList + ActivateKeyboardLayout without locale change first. Notice, that keyboard layout APIs in Wine don't do much.
http://bugs.winehq.org/show_bug.cgi?id=28168
--- Comment #9 from Sebastian Riemer Sebastian.Riemer@gmx.de 2011-08-26 15:29:20 CDT --- Created an attachment (id=36115) --> (http://bugs.winehq.org/attachment.cgi?id=36115) improved HKL iterator and vkey to key test tool
I think this is what you wanted Dmitry. WinXP doesn't care about locales there - just the HKLs. The wine output isn't tested as easy as this - so this is Windows only.
For wine the regular "vkey to key test tool" is better.
http://bugs.winehq.org/show_bug.cgi?id=28168
--- Comment #10 from Sebastian Riemer Sebastian.Riemer@gmx.de 2011-08-26 15:47:02 CDT --- Created an attachment (id=36116) --> (http://bugs.winehq.org/attachment.cgi?id=36116) WinXP test results with 129 keymaps
So these are my results from WinXP. I've installed all installable keymaps (129) including Chinese, Japanese,... .
I also wrote a script which takes the first keymap as reference and counts the matches with the others.
So I've found 6 areas which are completely identical in every keymap: 0x00 .. 0x2F 0x3A .. 0x6D 0x6F .. 0xB9 0xC3 .. 0xDA 0xE0 .. 0xE1 0xE3 .. 0xFE
wine could put the HKLs e.g. into a red-black search tree and retrieve from there the correct mappings. 129 * 256 Byte = approx. 33 KB needed for complete maps.
http://bugs.winehq.org/show_bug.cgi?id=28168
--- Comment #11 from Dmitry Timoshkov dmitry@baikal.ru 2011-08-26 23:25:09 CDT --- So, the VK_OEM_3 mapping should be fixed only for some keyboard layouts. Did you try to edit the keyboard layout table you are interested in at dlls/winex11.drv/keyboard.c ? Or try to run 'setxkbmap us' before running your application.
http://bugs.winehq.org/show_bug.cgi?id=28168
Dmitry Timoshkov dmitry@baikal.ru changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #36100|text/x-csrc |text/plain mime type| |
http://bugs.winehq.org/show_bug.cgi?id=28168
Dmitry Timoshkov dmitry@baikal.ru changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #36115|text/x-csrc |text/plain mime type| |
http://bugs.winehq.org/show_bug.cgi?id=28168
--- Comment #12 from Sebastian Riemer Sebastian.Riemer@gmx.de 2011-08-27 04:35:22 CDT --- (In reply to comment #11)
Did you try to edit the keyboard layout table you are interested in at dlls/winex11.drv/keyboard.c ? Or try to run 'setxkbmap us' before running your application.
1. If I would edit this other maps than MAPVK_VK_TO_CHAR would be broken. So there should be multiple maps for the same HKL.
2. Yes, this works, but I'd prefer qwertz rather than qwerty when typing on a console.
http://bugs.winehq.org/show_bug.cgi?id=28168
--- Comment #13 from Dmitry Timoshkov dmitry@baikal.ru 2011-08-28 00:01:42 CDT --- (In reply to comment #12)
Did you try to edit the keyboard layout table you are interested in at dlls/winex11.drv/keyboard.c ? Or try to run 'setxkbmap us' before running your application.
- If I would edit this other maps than MAPVK_VK_TO_CHAR would be broken. So
there should be multiple maps for the same HKL.
- Yes, this works, but I'd prefer qwertz rather than qwerty when typing on a
console.
That's a clear indication that fixing a keyboard layout in Wine should help. But first you need to figure out which one is actually detected/used.
http://bugs.winehq.org/show_bug.cgi?id=28168
Sebastian Riemer Sebastian.Riemer@gmx.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #36096|0 |1 is obsolete| |
--- Comment #14 from Sebastian Riemer Sebastian.Riemer@gmx.de 2011-08-28 05:58:24 CDT --- Created an attachment (id=36129) --> (http://bugs.winehq.org/attachment.cgi?id=36129) VK_OEM_3 fix for "de nodeadkeys" only
Dmitry, let me make this perfectly clear: The US layout is special, because VK_OEM_3 returns always 0x60 (`) if this key was pressed no matter which map.
The German layout is different. 0x5E (^) is on that key. This is a dead key by default, so I need "de nodeadkeys" for this to work. And on the other hand on the map MAPVK_VK_TO_CHAR 0xF6 (ö or XK_odiaeresis) has to be returned. If you ask the X server for the key there is always only a single map per keyboard layout. But conversely Windows has multiple maps for this.
Conclusion: MAPVK_VK_TO_CHAR processing may not ask the X server for any keys but instead compare with own maps.
http://bugs.winehq.org/show_bug.cgi?id=28168
Sebastian Riemer Sebastian.Riemer@gmx.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #36100|0 |1 is obsolete| |
--- Comment #15 from Sebastian Riemer Sebastian.Riemer@gmx.de 2011-10-10 01:59:53 CDT --- Created attachment 36798 --> http://bugs.winehq.org/attachment.cgi?id=36798 vkey to key test tool
new vkey to key test tool to be comparable to the WindowsXP HKL iterator
http://bugs.winehq.org/show_bug.cgi?id=28168
Sebastian Riemer Sebastian.Riemer@gmx.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #36129|0 |1 is obsolete| |
--- Comment #16 from Sebastian Riemer Sebastian.Riemer@gmx.de 2011-10-10 02:06:35 CDT --- Created attachment 36799 --> http://bugs.winehq.org/attachment.cgi?id=36799 MAPVK_VK_TO_CHAR wine-1.3.29 fix for all HKLs
It took some time but I could proof that direct mapping with this patch solves the problem for all HKLs.
http://bugs.winehq.org/show_bug.cgi?id=28168
Sebastian Riemer Sebastian.Riemer@gmx.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #36116|0 |1 is obsolete| |
--- Comment #17 from Sebastian Riemer Sebastian.Riemer@gmx.de 2011-10-10 02:23:14 CDT --- Created attachment 36800 --> http://bugs.winehq.org/attachment.cgi?id=36800 MAPVK_VK_TO_CHAR wine-1.3.29 patch verification data
I could verify that my patch is correct.
1. I've installed and collected all (127) HKLs from WindowsXP 2. I've compared them with each other to find common keys and common maps 3. I've added a test which iterates the members of "main_key_tab" and writes their maps to HKL files 4. I've compared the data from testing wine 1.3.29 with the files from WindowsXP - each file matches 5. I've compared unpatched with patched wine 1.3.29 DE HKL and both again with WindowsXP - only the patched one matches completely. The vanilla 1.3.29 has only 231/256 key matches.
http://bugs.winehq.org/show_bug.cgi?id=28168
--- Comment #18 from Saulius K. saulius2@gmail.com 2011-10-11 02:40:21 CDT --- I am not into this topic, but does that mean no useful test can be produced on this issue?
http://bugs.winehq.org/show_bug.cgi?id=28168
--- Comment #19 from Sebastian Riemer Sebastian.Riemer@gmx.de 2011-10-12 02:29:44 CDT --- (In reply to comment #18)
I am not into this topic, but does that mean no useful test can be produced on this issue?
That's true at the moment, because I can't determine for sure which keyboard layout is really selected in tests because of this bug: http://bugs.winehq.org/show_bug.cgi?id=28670
So, I guess, I have to fix lots of other stuff as well as the tests first.
http://bugs.winehq.org/show_bug.cgi?id=28168
--- Comment #20 from Austin English austinenglish@gmail.com 2013-11-13 16:48:53 CST --- This is your friendly reminder that there has been no bug activity for 2 years. Is this still an issue in current (1.7.6 or newer) wine? If so, please attach the terminal output in 1.7.6 (see http://wiki.winehq.org/FAQ#get_log).
https://bugs.winehq.org/show_bug.cgi?id=28168
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |ABANDONED
--- Comment #21 from Austin English austinenglish@gmail.com --- Abandoned.
https://bugs.winehq.org/show_bug.cgi?id=28168
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #22 from Austin English austinenglish@gmail.com --- Closing.