Fixing conflicts between WineD3D and WGL

[Jerome Leclanche]

Hi Ken

Your patchset causes X11 errors with the Battle.net client. 100%
reproducible, and also crashes within explorer.exe with +synchronous.

I thought it was something else at first due to a bad revert and filed
the details here: https://bugs.winehq.org/show_bug.cgi?id=36141

You can download the Battle.net Client here:
https://us.battle.net/account/download/
J. Leclanche


On Thu, Apr 24, 2014 at 4:29 PM, Ken Thomases <ken at codeweavers.com> wrote:
> Hi,
>
> On Apr 23, 2014, at 4:13 PM, Stefan Dösinger wrote:
>
>> I tested this a little bit sooner than expected, thanks to a
>> regression in Starcraft and Age of Empires 2. (Looks like bugs 35950
>> and 35655).
>
> Thanks for testing!
>
>> The good news is that your patches fix the regressions in those games.
>
> Nice.
>
>> Am 2014-04-21 17:49, schrieb Ken Thomases:
>>> * Full-screen games are actually full-screen, appearing in front
>>> of other apps, docks, panels, menus, taskbars, etc.
>> Kde 4.11.5 here. The fullscreen apps indeed appear fullscreen. But
>> once Starcraft was shifted down and only showing the top ~50 pixels at
>> the bottom of the screen.
>
> Strange.  The only positioning of the full-screen windows that the code ever does is moving it to get_primary_rect() converted from Win32 virtual screen coordinates to root coordinates.
>
>> Inside a virtual desktop Age of Empires 2 seemed to snap into place
>> after a resolution change. It first rendered at the bottom of the
>> screen and after ~0.5 seconds the rendering was correct.
>
> Yes, the code watches for root window configuration changes and repositions itself when that happens.  It tries to keep itself filling the screen.  The delay was probably because the app didn't return to processing events for a bit.  I think I can improve that by hooking into X11DRV_resize_desktop().
>
> When it's managed (not in a virtual desktop window), it also sets _NET_WM_STATE_FULLSCREEN which should lead the window manager to keep it in position.
>
>
>>> * But you can switch to another app as well/easily as you could
>>> without these patches.  Full-screen games don't take over your
>>> whole display such that you can't escape without drastic measures.
>> Alt-Tab does not work. The game loses focus and stops redrawing, but
>> my other apps don't show up. Switching to a different virtual desktop
>> works. I don't know if this worked in the past with those two games,
>> probably not. I'll retest with plain Wine, as far as the regressions
>> allow.
>
> My understanding is that most window managers only keep _NET_WM_STATE_FULLSCREEN windows over everything else as long as they have focus.  Did the desktop environment's panels, docks, taskbars, etc. show up when the game lost focus?
>
> The problem may be that I also set _NET_WM_STATE_ABOVE.  That's what happens for a WS_EX_TOPMOST window, which wined3d used to use prior to my patches, so I emulated that.
>
>
>>> * After switching away, you can switch back successfully.
>> I have to select the Wine window. If I select the game window, Wine's
>> rendering window does not take over.
>
> I have an additional patch that may fix that.  Please try applying <http://www.codeweavers.com/xfer/ken/wgl_wine_surface/wgl_surface_fixes_and_diag.patch> on top of the other patches.
>
> The main thing it does for this issue is set WM_HINTS.window_group to be the device window.  That should convince KDE to allow it to "steal" focus from the device window.  (I think what you were encountering is KDE's focus stealing prevention feature.)
>
> I've also reordered setting focus vs. raising the window.  And I'm trying a _NET_ACTIVATE_WINDOW request on top of all that.
>
> It also adds a bunch of additional logging for diagnosing other issues.
>
> -Ken
>
>
>