For a very long time now, enabling DGA causes mouse/keyboard events to be ignored. There have been a few threads on this issue in the past, and it seems nobody is willing to actually fix this problem (even though some have submitted patches to fix it, nothing has ever made it into CVS). Why is this? Overall, the problem seems to be related to the use of separate per-thread X display handles, along with a global (separate) "GDI" display. At first I tried just making the first thread's display the "global" display, but since that didn't work, and I don't have the patience to figure out why this dichotomy exists, here's a simple patch which at least works for a few games I tried (but still has mouse problems with a few other games I've tried - there was a mouse fix on an earlier thread(1) on this subject, but it doesn't work -- perhaps it has something to do with the fact that DGA only returns relative mouse movement, and non-DGA returns absolute movement). On the other hand, you could just at least make your default behavior and sample config not enable DGA.
Note that this patch is against wine-20030813, but I did check CVS first and it still applies. Also, I wasn't sure about the wine-patches message policy, so I'm just sending this to wine-devel.
(1) http://www.winehq.com/hypermail/wine-devel/2002/06/0427.html
---------------------------------------------------------------------------- Thomas J. Moore, Hacker/SysAdmin | TV & video games have destroyed my mind inet: dark@mama.indstate.edu | unix ada asm c/c++ mcu ee amiga tired
----------------------------------------------------------------------------
fre, 05.09.2003 kl. 22.02 skrev Thomas J. Moore:
For a very long time now, enabling DGA causes mouse/keyboard events to be ignored. There have been a few threads on this issue in the past, and it seems nobody is willing to actually fix this problem (even though some have submitted patches to fix it, nothing has ever made it into CVS). Why is this?
Probably because all those patches are based on having gdi_display receive events. It should not. Consequently, DGA should be initialized using a per-thread display so that events arrive on a per-thread display. Originally I had thought that the DGA driver could create a separate thread and use its thread display, but it may not be strictly necessary, given that DirectDraw needs a cooperative window, and windows are per-thread objects, so the thread that owns the cooperative window could also own the DGA display. If we also assume that this thread calls SetMode, it's probably okay to just use the current thread_display() instead of gdi_display. But I suppose it's probably still safer to let DGA create its own thread, though somewhat more involved (you may have to use XSendEvent or some kind of wineserver stuff to forward keyboard and mouse events to the thread that owns the cooperative window). Besides, a separate thread would allow the DGA code to handle its own events, instead of scattering DGA special cases around the rest of the x11drv event-handling code.
-
Ove Kaaven -
Thomas J. Moore