Some musings about DGA2 support in Wine...

[Lionel Ulmer]

Hi all,

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

-- 
		 Lionel Ulmer - http://www.bbrox.org/