No X11 input events in DGA2 mode

Andy MacLean andy-wine1 at themacleans.org.uk
Tue Jul 9 23:16:50 CDT 2002


Lionel Ulmer wrote:

>
>You can see that this topic was already debated in the following threads :
>
>   http://www.winehq.com/hypermail/wine-devel/2002/06/0396.html
>
>And even earlier here :
>
>   http://www.winehq.com/hypermail/wine-devel/2002/01/0392.html
>  
>
Thanks, I probably should have searched the archive first before jumping 
in and posting.  Had a read of the previous threads and I'm still trying 
to understand exactly what's wrong with the fix, here are some questions:

-> if gdi_display gets replaced with the thread specific display, won't 
this cause more problems than it fixes?  Would a windows program not 
expect to be able to switch on directX in one thread then operate on the 
raw display from any thread?  Using the thread specific display would 
require the thread which switched DGA2 on to perform all operations 
because most DGA2 calls throw errors if a display is not in DGA2 mode 
and only one display can be in this mode at any one time.

-> In a multi-threaded program, does it matter which 
WaitForMultipleObjects is used to collect the events?  The event gets 
dispatched to the wineserver with the DGA window's hWnd attached in the 
same way as it would if 'emulated' direct access were used (i.e. drawing 
with normal X11 calls).  This then sends the event on to the windows 
program.  If this is a problem then wouldn't it also affect non-DGA2 
modes and therefore be a separate problem?  It's been ages since I did 
any windows programming (win 3.1), what would a multi-threaded windows 
app expect to happen if it starts multiple threads and runs more than 
one event loop?

Perhaps a better fix might be to have a thread 'own' the gdi_display if 
it switches DGA2 mode on.  The X11drv_thread_data structure for each 
thread could get a new 'gdi_display' field which would default to NULL. 
 This could get set to the global gdi_display field for the thread which 
switches on DGA2 and process_events could be changed to poll 
data->gdi_display in addition to data->display if this was non-null.  I 
think this would produce input event behaviour identical to the 
'emulated' DGA2 mode since DGA2 events would only be handled when the 
thread which entered DGA2 mode was polled for events.


A.




More information about the wine-devel mailing list