StarCraft, HMM4

Собрать другой wine.

Вот что я нарыл по этому поводу в Инете... Но к сожалению я начинающий линуксоид и не могу сам поправить исходник. Может кто сделает это и выложит куда-нить пропатченый?

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