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