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
Tomas Carnecky wrote:
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?
The patch in the attachment removes update_key_state() from mouse.c - the decision whether this is the right approach or not is left to someone else. If you think it's worth a try to send this patch to wine-patches, please do so, I'll have to continue using a custom patchset anyway since the app I want to run doesn't work on vanilla wine, so I don't heave really a strong interest in getting this patch accepted.
Getting patches accepted was quite hard for me, and that was because lack of feedback. It leads to nowhere if I submit the very same patch more than twice, and without feedback I can't improve it. So, my two patches (one for alsa/dsound and this for the stuck keys) will remain public domain and free for everyone to use, and if you feel like it, to improve and send back to wine for inclusion.
I'll (more or less) retire from writing patches. But of course if I come up with a fix for something that I think is worth sharing, I'll let you guys know ;)
tom
-
Tomas Carnecky