Hi,
I've a small problem with wine (cvs from today) when trying to play a game that uses dinput.dll. The game starts fine, keyboard inputs works but the mouse cursor didn't move. I had a look at the source code of dinput/mouse.c and the trace messages of dinput. But there is one thing I don't understand. The callback function for the mouse (dinput_mouse_hook) is never called. The initialising look good:
trace:dinput:SysMouseAImpl_Acquire (this=0x40269480) trace:hook:set_windows_hook WH_MOUSE_LL 0x40dd64e0 0 -> 0x20028 trace:dinput:SysMouseAImpl_Acquire Warping mouse to 512 - 384 trace:dinput:SysKeyboardAImpl_Unacquire (this=0x40269db8) trace:dinput:SysKeyboardAImpl_SetEventNotification (this=0x40269db8,0x00000124) trace:dinput:SysKeyboardAImpl_Acquire (this=0x40269db8) trace:dinput:SysKeyboardAImpl_Acquire (this=0x40269db8) trace:dinput:SysMouseAImpl_Acquire (this=0x40269480) ...
And later when pressing a mouse button:
trace:hook:HOOK_CallHooks calling hook in thread 0013 WH_MOUSE_LL code 0 wp 200 lp 4071d074
But then there is no other dinput message. Shouldn't there be a call of the mouse callback function?
Bye, Michael
Hi,
On Thu, Jul 22, 2004 at 07:38:26PM +0200, Michael Schlüter wrote:
Hi,
I've a small problem with wine (cvs from today) when trying to play a game that uses dinput.dll. The game starts fine, keyboard inputs works but the mouse cursor didn't move. I had a look at the source code of dinput/mouse.c and the trace messages of dinput. But there is one thing I don't understand. The callback function for the mouse (dinput_mouse_hook) is never called. The initialising look good:
The question is: Did it work right before?
Someone recently did some dinput mouse changes; these might be responsible here.
But then there is no other dinput message. Shouldn't there be a call of the mouse callback function?
No idea, sorry. Please keep investigating that, and keep reading dinput docs. Would be very nice to see that fixed!
Andreas Mohr
And later when pressing a mouse button:
trace:hook:HOOK_CallHooks calling hook in thread 0013 WH_MOUSE_LL code 0 wp 200 lp 4071d074
But then there is no other dinput message. Shouldn't there be a call of the mouse callback function?
There should, yeah.... But the way this works is that the event code is sending a message (via the server) to the thread which registered the hook via the DInput code. Now if that thread does not do any wait on any message, the message will time-out and the event will be lost (I had this issue with a game).
You could check by pressing a key to see if the keyboard low level hook is actually called or not.
By the way, could I know which game exhibits this problem and if I could download it to be able to debug on my box ?
Lionel
PS: this is the kind of stuff that Bugzilla should be used for (and would even work as we have a knowledgeable bug reporter who knows what he is doing :-) )
Am Samstag, den 24.07.2004, 22:50 +0200 schrieb Lionel Ulmer:
And later when pressing a mouse button:
trace:hook:HOOK_CallHooks calling hook in thread 0013 WH_MOUSE_LL code 0 wp 200 lp 4071d074
But then there is no other dinput message. Shouldn't there be a call of the mouse callback function?
There should, yeah.... But the way this works is that the event code is sending a message (via the server) to the thread which registered the hook via the DInput code. Now if that thread does not do any wait on any message, the message will time-out and the event will be lost (I had this issue with a game).
Are keyboard and mouse handled within the same thread?
You could check by pressing a key to see if the keyboard low level hook is actually called or not.
Yes, KeyboardCallback is called with every key stroke.
By the way, could I know which game exhibits this problem and if I could download it to be able to debug on my box ?
The games are called "Robin Hood – The Legend of Sherwood" and "Desperados - Wanted Death or Alive". Demos are available but I don't have the links handy.
Bye, Michael
On Sun, Jul 25, 2004 at 04:10:04PM +0200, Michael Schlüter wrote:
Are keyboard and mouse handled within the same thread?
Well, depends of the game... I think that it could well use a Keyboard device in one thread and a mouse device in another (for that, a +tid trace is nice because it prefixes all non-relay traces with the thread id).
Yes, KeyboardCallback is called with every key stroke.
So, if both are in the same thread (see up there how to check it), we must have a problem somewhere. I once spent a lot of time looking at this code to hunt for the bug in the 'no waitforevent' game, and from what I remembered, I used the '+server,+hook' debug channels to see exactly how the 'hook' event was propagated via the server. I would need to re-follow the code path to refresh on this though :-)
The games are called "Robin Hood The Legend of Sherwood" and "Desperados - Wanted Death or Alive". Demos are available but I don't have the links handy.
No need, I have both Demos installed (and even have the actual Desperados game itself). I will see if I can reproduce the bug here.
By the way, how did you manage to actually play Desperados ? On my version of Wine, when I start either the demo or the game installer, it creates a zero-size window on the screen ... which prevents me to actually start the game or the installation. It works fine in Windows (it's one of those funky non-square windows).
Lionel
Am Sonntag, den 25.07.2004, 18:18 +0200 schrieb Lionel Ulmer:
On Sun, Jul 25, 2004 at 04:10:04PM +0200, Michael Schlüter wrote:
Are keyboard and mouse handled within the same thread?
Well, depends of the game... I think that it could well use a Keyboard device in one thread and a mouse device in another (for that, a +tid trace is nice because it prefixes all non-relay traces with the thread id).
Yes, KeyboardCallback is called with every key stroke.
So, if both are in the same thread (see up there how to check it), we must have a problem somewhere. I once spent a lot of time looking at this code to hunt for the bug in the 'no waitforevent' game, and from what I remembered, I used the '+server,+hook' debug channels to see exactly how the 'hook' event was propagated via the server. I would need to re-follow the code path to refresh on this though :-)
I'm not sure but I think the problem occurred because a new thread (0015) is created, that than called SysKeyboardAImpl_Unacquire and after that SysMouseAImpl_Acquire. So all mouse events will be sent to thread (0015) and they never get there. Wouldn't it be better to send the event to the thread that is calling start_hook_chain because mouse and keyboard events are global.
The keyboard hasn't that problem because it calls SetWindowsHookExW and UnhookWindowsHookEx from keyboarddev_create_deviceA/W and SysKeyboardAImpl_Release and are only called once in a program. Maybe this could be done for the mouse too. I'll will try this later.
Here is short trace:
0009:trace:dinput:SysMouseAImpl_Acquire (this=0x4026a698) 0009: set_hook( id=14, tid=0000, proc=0x40ec64a0, unicode=0, odule=L"" ) 0009: set_hook() = 0 { handle=0x10028 } 0009:trace:hook:set_windows_hook WH_MOUSE_LL 0x40ec64a0 0 -> 0x10028 0009:trace:dinput:SysMouseAImpl_Acquire Warping mouse to 320 - 240 ... 0015: init_thread( unix_pid=4134, unix_tid=4151, teb=0x6c3c4000, entry=0x403892e0, reply_fd=49, wait_fd=51 ) 0015: init_thread() = 0 { pid=0008, tid=0015, boot=0, version=147 } 0015: create_event( manual_reset=0, initial_state=0, inherit=0, name=L"Mouse Event" ) 0015: create_event() = 0 { handle=0xf0 } 0015: create_event( manual_reset=0, initial_state=0, inherit=0, name=L"Keyboard Event" ) 0015: create_event() = 0 { handle=0xf4 } 0015:trace:dinput:SysKeyboardAImpl_Acquire (this=0x4026a640) 0015:trace:dinput:SysMouseAImpl_Acquire (this=0x4026a698) 0015:trace:dinput:SysKeyboardAImpl_Unacquire (this=0x4026a640) 0015:trace:dinput:SysMouseAImpl_Unacquire (this=0x4026a698) 0015:trace:hook:UnhookWindowsHookEx 0x10028 0015: remove_hook( handle=0x10028, id=0, proc=(nil) ) 0015: remove_hook() = 0 0015:trace:dinput:SysMouseAImpl_Unacquire warping mouse back to (16 , 170) ... 0015:trace:dinput:SysMouseAImpl_SetEventNotification (this=0x4026a698,0x000000f0) 0015:trace:dinput:SysKeyboardAImpl_Acquire (this=0x4026a640) 0015:trace:dinput:SysMouseAImpl_Acquire (this=0x4026a698) 0015: set_hook( id=14, tid=0000, proc=0x40ec64a0, unicode=0, module=L"" ) 0015: set_hook() = 0 { handle=0x20028 } 0015:trace:hook:set_windows_hook WH_MOUSE_LL 0x40ec64a0 0 -> 0x20028 0015:trace:dinput:SysMouseAImpl_Acquire Warping mouse to 320 - 240 0015:trace:dinput:SysKeyboardAImpl_Unacquire (this=0x4026a640) 0015:trace:dinput:SysKeyboardAImpl_SetEventNotification (this=0x4026a640,0x000000f4) 0015:trace:dinput:SysKeyboardAImpl_Acquire (this=0x4026a640) 0015:trace:dinput:SysKeyboardAImpl_Acquire (this=0x4026a640) 0015:trace:dinput:SysMouseAImpl_Acquire (this=0x4026a698) ... 0009: start_hook_chain( id=14 ) 0009: start_hook_chain() = 0 { handle=0x20028, pid=0008, tid=0015, proc=(nil), unicode=0, module=L"" } 0009:trace:hook:HOOK_CallHooks calling hook in thread 0015 WH_MOUSE_LL code 0 wp 200 lp 4071d074 0009: send_message( id=0015, type=1, flags=1, win=(nil), msg=80000008, wparam=00000200, lparam=4071d074, x=0, y=0, time=00006792, info=00000000, timeout=2000, callback=(nil), data={} ) 0009: send_message() = 0 0009: set_queue_mask( wake_mask=00008040, changed_mask=00008040, skip_wait=1 ) 0009: set_queue_mask() = 0 { wake_bits=00000023, changed_bits=00000023 } 0009: select( flags=4, cookie=0x4071c89c, timeout=0, handles={0x4c} ) 0009: select() = PENDING
Bye, Michael
Am Dienstag, den 27.07.2004, 00:18 +0200 schrieb Michael Schlüter:
The keyboard hasn't that problem because it calls SetWindowsHookExW and UnhookWindowsHookEx from keyboarddev_create_deviceA/W and SysKeyboardAImpl_Release and are only called once in a program. Maybe this could be done for the mouse too. I'll will try this later.
Ok, here is a first patch but I don't know where to put the /* Warp the mouse to the center of the window */ stuff. Lionel can you please have a look at the patch.
Bye, Michael
-
Andreas Mohr -
Lionel Ulmer -
Michael Schlüter