That is _really_ annoying, but nobody seems to know what it causes. So,
I once again started to investigate it. The culprit is the
'update_key_state' function in mouse.c, which modifies the global
'key_state_table' without telling the application that the keystate has
changed. A patch that was submitted long ago to the wine-patches mailing
list changed the code in the above mentioned function to call
'KEYBOARD_ChangeOneState', which takes care of informing the application
of the keystate change (but only if the keystate has actually changed).
AJ rejected the patch, don't know the exact reason but it was more or
less because it didn't seem the proper fix for him.
I watched how/when 'update_key_state' is called and one place is in
'X11DRV_EnterNotify' (which for some reason is also in mouse.c). The
problems is that KeymapNotify is sent after EnterNotify and because
'update_key_state' modifies the global keystate table (at EnterNotify),
'KEYBOARD_ChangeOneState' (called by 'X11DRV_KeymapNotify') doesn't
inform the application about the changed keystate.
The question now is, is the WM allowed to dispatch EnterNotify before
KeymapNotify? I couldn't find any definitive answer, but I've found one
book where this order is explicitly mentioned and one PDF where it's
less clear, but from my understanding also leads to this conclusion.
Webpage: http://www.sbin.org/doc/Xlib/chapt_08.html
This event type (KeymapNotify), if it is selected, always follows
immediately after an EnterNotify or FocusIn event.
PDF: www.hpl.hp.com/techreports/Compaq-DEC/CRL-90-8.pdf
page 18: KeymapNotify - Keyboard state at EnterNotify, FocusIn events
(less clear, but if this is true it would be quite useless if
KeymapNotify was dispatched after EnterNotify)
So.. now that the cause is known, what would be the right solution? Do
you still think it's the WMs fault? Or should wine be changed?
tom
