Callbacks while app is looping

[Mark Westcott]

Hi all,
I've been working on fixing the crash in 'Gens' when trying to reassign keys.

The app basically does a:

while (1)
{
 IDIRECTINPUTINTERFACE::GetDeviceState();
}

Until it notices a key has been pressed.  DirectInput hooks onto system 
keyboard events with SetWindowsHookEx(WH_KEYBOARD_LL........), but while the 
app is doing its nasty while(1) loop, DirectInput's callback procedure never 
gets called.

This is as far as I can get  (new to wine) - any ideas anyone? I threw a test  
case app that illustrates the problem

(btw, the WH_KEYBOARD_LL hook has the note 'should use SendMessage instead', 
but I don't get what this means or know if using SendMessage instead would 
have anything to do with fixing this problem)

--------
Mark Westcott

[Mike Hearn]

> This is as far as I can get  (new to wine) - any ideas anyone? I threw a test  
> case app that illustrates the problem

Could you make that available? either C source with Makefile or compiled
EXE is fine.
> (btw, the WH_KEYBOARD_LL hook has the note 'should use SendMessage instead', 
> but I don't get what this means or know if using SendMessage instead would 
> have anything to do with fixing this problem)

It might do, poking around in the windows/input.c file reveals the hook
is called using HOOK_CallHooks() rather than sending a message. MSDN
says Windows internally uses messages to implement this one for some
reason, but on the other hand presumably DirectInput knows how Wine does
it.

Being able to play with the test app would make it easier to debug this
problem. 

Also, if any Wine/Win32 gurus could point to some docs on how callback
routines are invoked, that'd be useful.

One other possibility is that DirectInput should not be using keyboard
event hooks in this way. GetDeviceState() implies reading the keyboard
device directly, or reading an internal map of key states - NOT waiting
for keyboard events. But, I haven't seen that code and didn't implement
it, so I might be talking rubbish.

thanks -mike (TD on irc)

-- 
Mike Hearn <m.hearn(a)signal.qinetiq.com>
QinetiQ - Malvern Technology Center

[Mark Westcott]

On Thursday 01 May 2003 10:42 am, Mike Hearn wrote:
> > This is as far as I can get  (new to wine) - any ideas anyone? I threw a
> > test case app that illustrates the problem
>
> Could you make that available? either C source with Makefile or compiled
> EXE is fine.

Sure, exe is here:
http://www.befishy.co.uk/files/GetDeviceStateTest.exe
> > (btw, the WH_KEYBOARD_LL hook has the note 'should use SendMessage
> > instead', but I don't get what this means or know if using SendMessage
> > instead would have anything to do with fixing this problem)
>
> It might do, poking around in the windows/input.c file reveals the hook
> is called using HOOK_CallHooks() rather than sending a message. MSDN
> says Windows internally uses messages to implement this one for some
> reason, but on the other hand presumably DirectInput knows how Wine does
> it.

Ok, but I just did a little bit more poking and it turns out that 
windows/input.c:queue_kbd_event isn't getting called at all, and back 
further, nor is SendInput() or kbd_event(). (Btw, mouse events don't get 
through either during the while (1) loop.), so the fact its calling the hooks 
this way isn't the problem.
> Being able to play with the test app would make it easier to debug this
> problem.
>
> Also, if any Wine/Win32 gurus could point to some docs on how callback
> routines are invoked, that'd be useful.
> One other possibility is that DirectInput should not be using keyboard
> event hooks in this way. GetDeviceState() implies reading the keyboard
> device directly, or reading an internal map of key states - NOT waiting
> for keyboard events. But, I haven't seen that code and didn't implement
> it, so I might be talking rubbish.

Well, the wine DInput implentation keeps an internal map of key states and 
updates these when an event happens.  Its just this badly written bit of code 
thats using it to wait for a keyboard event :)
> thanks -mike (TD on irc)

Thanks for the response Mike,

Mark

[Mike Hearn]

> Well, the wine DInput implentation keeps an internal map of key states and 
> updates these when an event happens.  Its just this badly written bit of code 
> thats using it to wait for a keyboard event :)

I suspect the actual problem is that keyboard hooks require the app to
be processing messages in order to function. In fact, run that test app
in desktop mode - you'll see that it works fine, presumably because the
desktop continues processing messages even when the app within it is
not.

I'm not sure what to do about this, it'd seem sensible to have X11
events processed by the service thread, but I suspect there are reasons
why this isn't the case. CCing Alexandre, he'll know more about
hooks/callbacks.

thanks -mike

[Ove Kaaven]

fre, 02.05.2003 kl. 21.03 skrev Mike Hearn:
> > Well, the wine DInput implentation keeps an internal map of key states and 
> > updates these when an event happens.  Its just this badly written bit of code 
> > thats using it to wait for a keyboard event :)
>
> I suspect the actual problem is that keyboard hooks require the app to
> be processing messages in order to function. In fact, run that test app
> in desktop mode - you'll see that it works fine, presumably because the
> desktop continues processing messages even when the app within it is
> not.
>
> I'm not sure what to do about this, it'd seem sensible to have X11
> events processed by the service thread, but I suspect there are reasons
> why this isn't the case.

Even so, the current thread can and should still process its incoming
X11 events whenever it needs to. Adding an event-checking (but otherwise
no-op) construct like MsgWaitForMultipleObjectsEx(0, NULL, 0, 0, 0); to
GetDeviceState and GetDeviceData should be able to make this happen.