On Tuesday 20 January 2004 5:23 am, Dmitry Timoshkov wrote:
X11 team tends to remove more than 2 characters per keysym. See /etc/X11/xkb/symbols/tr. Turkish keyboard layout in Wine has more than 2 for some of them. Just do 'setxkbmap tr' and run Wine with +key,keyboard,+x11drv and look for mismatches.
I have done that and piped the output to a logfile. Attached is an abbreviated version with just the icelandic and turkish detection included. It seems to be mismatching on detecting the third keysym where the key is defined in /etc/X11/xkb/symbols/tr this could be a clue :)
That shouldn't happen. Keyboard detection code always does a full round of comparisons with every keyboard table in x11drv.
I took another look at the code and with the trace I have to say that I was wrong :-(
The trace only shows 0x0000 for the third(?) keysymb so I dont know what was returned. I believe (gingerly) that is due to the trace having a precision of 4. TRACE_(key)("mismatch for keysym 0x%04lX, keycode %d,
in function X11DRV_KEYBOARD_DetectLayout where it should be
TRACE_(key)("mismatch for keysym 0x%08lX, keycode %d,
or my version of X11 is returning a larger value than it should. I suspect this because of the large amount of calls to the function KEYBOARD_MapDeadKeysym. Maybe the X11 guys have changed a short to a long somewhere in my version of X11 (cvs 2003-11-24) or my gcc (3.2.2) has defined them differently. If that is the case then the line
ckey[i] = keysym & 0xFF;
in function X11DRV_KEYBOARD_DetectLayout would change the keysym and cause a mismatch. Another thought popped up is maybe the X11 guys extended the keysymb codes to allow for 6 instead of four combinations. I will have to check the changelogs to be sure.
Other programs have no constrains implied by implementing Win32 APIs on the top of X11.
LOL