On Thu, 18 Apr 2013 17:39:33 +0900 Dmitry Timoshkov dmitry@baikal.ru wrote:
[please don't omit wine-devel when replying]
Stevie Trujillo stevie.trujillo@gmail.com wrote:
Stevie Trujillo stevie.trujillo@gmail.com wrote:
Another (minor) problem raised in the bugzilla entry is that, if a key is pressed when changing window, and released before returning, GetKeyboardState() will claim the key is still pressed (0x80). But this is easy to workaround, just hit the key again inside the game and it will stop scrolling.
dlls/winex11.drv/keyboard.c,X11DRV_KeymapNotify() should take care of that, if it doesn't - please debug why (probably a bug in your WM).
I think this function only applies to "modifier keys". It was tested with arrow keys.
It should work for all keys.
Anyway I don't think it's a big issue, since it doesn't cause any big problem, and it doesn't happen very often. It was just a situation where Windows and Wine exhibited slightly different behavior.
The first bug is much more annoying since one has to completely exit the game each time.
My comment was targeting both problems that you mentioned.
Ok, I didn't understand what this function does with the arrow keys yet, but I think I found out where the 0x40 comes from now:
In server/queue.c::update_input_key_state, down = (keystate == desktop->keystate) ? 0xc0 : 0x80;
When server/queue.c::set_input_key_state() is called with down=0, 0xc0 & ~0x80 = 0x40, keystate[key] &= ~0x80;
From dlls/winex11.drv/keyboard.c::X11DRV_KeymapNotify, get_async_key_state does SERVER_START_REQ( get_key_state ) with req->tid = 0. This retrieves the desktop->keystate.
When writing back changes, set_async_key_state calls SERVER_START_REQ( set_key_state ) with req->tid = GetCurrentThreadId(). This should copy the 0x40 bits from the desktop's keystate to the thread's keystate.