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