Keyboard events and Direct Draw

[Alan Chandler]

Actually this is NOW the third attempt the other attempts were
yesterday.

Apologies to everyone if they have already seen the following.  I
posted it several hours ago, but I would have expected it to have
bounced back to me from the list by now, but it hasn't...

... and I also wanted to add, that I have been desperately trying to
find a way to put a breakpoint on any events coming from the keyboard
to try and track where they go - but nothing.  I cannot find any
evidence of any keyboard events being received within wine at all.

With --debugmsg traces on channels "key", "keyboard" or "event", I can
find nothing registered as I press a key.  Perhaps more problematic
since its also using the keyboard, but winedbg is not breaking on a
breakpoint set on X11DRV_KEYBOARD_HandleEvent

The following ...

I am trying to understand the behaviour of wine when running Grand
Prix Legends (a racing car simulator) - called GPL below.  I posted
here last week, and since then some updates have occurred to wine that
improve things.  Namely the colours now all come out correct.

However, I am still trying to find out why key presses don't get fed
into the program.  This has the unfortunate affect, that once you have
told the program to exit, you have to wait several minutes for the
credits to scroll by since in the program under Windows, hitting
return is the only way to kill these off.  This is made worse by the
fact that the DirectDraw window created by the program forceses itself
on top of all the others so that whilst is there most ofther windows
are fully or partially obscured (on any virtual desktop).  This makes
further debugging extremely difficuly.

I am pretty sure the program (GPL) is not trying to use direct input
for the keyboard, which implies it is expecting keypress messages on
its winproc queue.  However I don't know which one.  With use of
--debugmsg I think it creates one window, and then uses a Direct Draw
call SetCooperativeLevel to set this window to full screen and
exclusive mode.  This window is then made active.

Inside wine, dlls/ddraw/dsurface/user.c - there is a routine called
when a direct draw surface is to be created.  Last week Gavriel State
suggested that I look at the #define OWN_WINDOW and comment it out.

I tried that, and if I do, the game produces no output.

However, when this #define is defined I do get the proper output (I
have set the game and wine to only assume a 640x480 screen so its a
window created in the upper left of my screen).  Mouse events are
captured properly, but keyboard events do not seem to be.  Instead
they seem to be directed at the underlying window from which wine was
started (or if running winedbg the debug window).

Looking at the code within the dsurface/user.c file, it appears to me
that keyboard events received are passed to the orginal DirectDraw
window.  Therefore I don't understand why its not working.

I guess the question I am asking is what are the differences between
windows and wine here - I have very little knowledge of windows or x
windows operation (other than what a learned about windows 5 years ago
by reading manuals - but never actually writing code) so forgive me -
and what could GPL doing to actually get keypresses.

Some thoughts

a)  There is a call in the trace "CreateDesktopWindow" a little before
the other windows calls.  Is this Wine or GPL creating this window

b)  When I run the game under Windows you can ALT-TAB between two
tasks.  Maybe this other task has a dummy window taking keypresses and
that somehow wine is not emulating windows behaviour correctly when
automatically linking keypresses to the DirectDraw window

Any comments?

Alan

[e-mail]
http://www.chandler.u-net.com