Some musings about DGA2 support in Wine...
lionel.ulmer at free.fr
Sun Jan 20 04:28:52 CST 2002
After being prodded by people on #WineHQ to look at the current DGA2 problem
in Wine (it it works fine for graphics, but does not accept any user input
at all and needs to either kill Wine remotely or do the three finger salute
to the X server), I found the following things :
- the DGA2 code (in dlls/x11drv/dga2.c) used the gdi_display connection to
open the framebuffer and setting-up all the input handling. But it was
the thread->display connection that was used to process the events. This
is a no-go as when DGA2 is entered, there is only one connection that
receives the event, the one which has grabbed the frame buffer (thanks to
Ove to remind me of the 'one connection per thread' thingy).
- so I removed all the mentions to 'gdi_display' in dga2.c and replaced
them by the current thread display and still no go (although I checked
that the event processing in WaitForMultipleEvents and subsequent
process_events was done on the correct display). Still no go. So I
investigated a bit with a little test program :
= I did first try setting up DGA2 in a separate display and then doing
all the 'standard' processing on another display (that is Wine does
with DGA2 set-up in the init function to test if DGA2 is available and
then really use it in another thread). As my test application still
was working fine, this was not the problem...
= then, I saw in the logs some calls to X11DRV functions after we have
entered DGA2 (some due to the DDraw stuff creating DIB sections and so
on, some due to the application I think). After adding the same stuff
in my test program (ie I created a window just after entering DGA2), I
found that it perturbed the event processing (I still had motion
events, but neither key presses nor button presses).
- so, finally, just to try, I backed off my changes in dga2.c (ie I used
again the gdi_display for all the set-up) and had the process_events
function in windows/x11drv/event.c use gdi_display instead of
data->display when DGA was used (by testing the DGAUsed variable). And
now it seems to work just fine....
All this leads now to the 10 ¤ (an Euro sign for all the people not having
an iso8859-15 font :-) ) question : how to fix this 'properly' and not with
the hack I just did ?
The only somewhat 'clean' solution I found would be to create a display
connection specifically used for DGA2 (thus we would be sure that no X calls
would 'pollute' the link). And in process_events, if DGA2 is used, use this
connection instead of the thread connection (we already have some DGA
specific variables there, what would be one more :-)) ). After, the question
would be how we are sure that it's the 'good' WaitForMultipleEvents that
receives the events (if the application is multi-threaded and has multiple
threads calling this function).
Anyway, if people want just to play some games using DGA2, they can always
use my hacky solutions I just described up there :-)
Lionel Ulmer - http://www.bbrox.org/
More information about the wine-devel