http://bugs.winehq.org/show_bug.cgi?id=8683
--- Comment #17 from Fábio Capela fabio.capela@yahoo.com 2008-01-21 07:26:15 --- Created an attachment (id=10390) --> (http://bugs.winehq.org/attachment.cgi?id=10390) Another hack, works for some keys but I'm not sure it's the correct approach.
Just changing s[2] to s[10] (and the corresponding size field in XLookupString) don't help. I went on and tried to convert the result of XLookupString to wide chars, and it solves the problem for all problematic keys except ß. The changes I used are attached.
The only key that is returning a value that needs more than 1 byte is ß, which is exactly the one key that is not working with this newest hack. Not sure why it's not working, it's returning 0x1e9e as the unicode char, but the unicode for ß is 0xdf.
BTW, just found another bug in this same function. Under the DE layout with numlock pressed the keypad <.> key generates the VK_SEPARATOR virtualkey, but this virtualkey is not correctly handled in the function. Seems like it would need another special numlock case to translate VK_SEPARATOR to KP_Separator, similar to the cases that already exists for VK_DECIMAL and VK_NUMPAD0 to VK_NUMPAD9