[Wayland-bugs] [Bug 107757] [Regression] Xwayland/Present: Black window with "World of Warcraft" under Wine

[b***@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=107757

Bug ID: 107757
Summary: [Regression] Xwayland/Present: Black window with
"World of Warcraft" under Wine
Product: Wayland
Version: unspecified
Hardware: Other
OS: All
Status: NEW
Severity: normal
Priority: medium
Component: XWayland
Assignee: wayland-***@lists.freedesktop.org
Reporter: ***@xfce.org
QA Contact: xorg-***@lists.x.org
CC: ***@gmail.com

Created attachment 141381
--> https://bugs.freedesktop.org/attachment.cgi?id=141381&action=edit
PresentDebug logs

Description:

WoW with Wine shows a black output window when run on Xwayland 1.20-rc2 and
later (including 1.20.1 and master).

Xwayland 1.20-rc1 worked fine.

The issue first occured with the introduction of Present support in Xwayland
(commit be087778).

Steps to reproduce:

1. Download Wow for free
(trial version
https://battle.net/account/creation/tos.html?theme=wow&style=wow-trial)
2. Configure Wine to emulate Windows 7 (otherwise WoW won't install ...)
3. Run "wine World-of-Warcraft-Setup.exe"
4. Play the game

Actual result:

A black window shows up, while sounds plays.

Expected result:

The output window shows some content

Additional data:

xserver-1.20rc1 worked, xserver-1.20rc2 fails and first bad commit seems to be
the enabling of Present support in Xwayland:

commit be087778a0eae3093ffdbba3ff7c9f3863d8e1d4
Author: Roman Gilg <***@gmail.com>
Date: Tue Mar 13 16:00:57 2018 +0100

xwayland: Activate Present flips in rootless mode with Glamor

Link the newly introduced support for Present flips. For now flips can only
be used in rootless mode together with Glamor.


Running Xwayland with PresentDebug enabled while the issue occurs gives (see
attachment)

[b***@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=107757

--- Comment #1 from Olivier Fourdan <***@xfce.org> ---
Oh, and a bt of the client side gives:

#0 0x00007f8e7dbf3ae9 in syscall () from /lib64/libc.so.6
#1 0x00007f8e400ffc12 in sys_futex (val3=0, addr2=0x0, timeout=0x0, val1=-1,
op=0, addr1=0x7f8e6808f000) at xshmfence_futex.h:66
#2 futex_wait (value=-1, addr=0x7f8e6808f000) at xshmfence_futex.h:66
#3 xshmfence_await (f=0x7f8e6808f000) at xshmfence_futex.c:63
#4 0x00007f8e40b6aa1b in dri3_get_buffer.isra () from /lib64/libGLX_mesa.so.0
#5 0x00007f8e40b6b84e in loader_dri3_get_buffers ()
from /lib64/libGLX_mesa.so.0
#6 0x00007f8e3ef15805 in intel_update_renderbuffers ()
from /usr/lib64/dri/i965_dri.so
#7 0x00007f8e3ef15e95 in intel_prepare_render ()
from /usr/lib64/dri/i965_dri.so
#8 0x00007f8e3ef11315 in brw_clear () from /usr/lib64/dri/i965_dri.so
#9 0x00007f8e6b2f62ba in device_clear_render_targets ()
from /usr/bin/../lib64/wine/wined3d.dll.so
#10 0x00007f8e6b2efc05 in wined3d_cs_exec_clear ()
from /usr/bin/../lib64/wine/wined3d.dll.so
#11 0x00007f8e6b2f169b in wined3d_cs_st_submit ()
from /usr/bin/../lib64/wine/wined3d.dll.so
#12 0x00007f8e6b3060ba in wined3d_device_clear_rendertarget_view ()
from /usr/bin/../lib64/wine/wined3d.dll.so
#13 0x00007f8e681883af in d3d11_immediate_context_ClearRenderTargetView ()
from /usr/bin/../lib64/wine/d3d11.dll.so
#14 0x0000000140395718 in ?? ()
#15 0x000000000023f810 in ?? ()
#16 0x0000000000000000 in ?? ()

(courtesy of Carlos Garnacho ^_~)

[b***@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=107757

--- Comment #2 from Olivier Fourdan <***@xfce.org> ---
The logs from attachment 141381 are useless, WoW uses multiple windows and
those are from a working case (where the window is decorated/reparented
anyway).

But in the case of the actual game output window (the one which stays black),
we get instead:

q 1 0x1eb93a0 1: 016000bf -> 016000b9 (crtc 0x126f450) flip 1 vsync 0
serial 1
f 1 0x1eb93a0 1: 016000bf -> 016000b9
e 1 ust 235274993625 msc 1
n 1 0x1eb93a0 1: 016000bf -> 016000b9


And that's it!

So present_wmnd does notify and send an event to the client.

On the client side, the backtrace shows it's stuck in `xshmfence_await()`
called from `dri3_get_buffer()` (through `dri3_fence_await()`) but I still
don't understand what prevents that fence from being triggered.

[b***@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=107757

Olivier Fourdan <***@xfce.org> changed:

What |Removed |Added
----------------------------------------------------------------------------
Attachment #141381|0 |1
is obsolete| |

[b***@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=107757

--- Comment #3 from Michel DÀnzer <***@daenzer.net> ---
Created attachment 141439
--> https://bugs.freedesktop.org/attachment.cgi?id=141439&action=edit
loader/dri3: Only wait for fence when necessary in dri3_get_buffer

Does this Mesa patch fix the problem?

[b***@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=107757

--- Comment #4 from Olivier Fourdan <***@xfce.org> ---
(In reply to Michel DÀnzer from comment #3)

Post by b***@freedesktop.org
Does this Mesa patch fix the problem?

Unfortunately, no, it doesn't.

But I managed to get a better stacktrace with symbols of the hung thread
(that's with mesa 18.2.0-rc5 _without_ attachment 141439 applied):

#1 0x00007f7ff5258c12 in sys_futex (val3=0, addr2=0x0, timeout=0x0, val1=-1,
op=0, addr1=0x7f8005cf2000) at xshmfence_futex.h:66
#2 futex_wait (value=-1, addr=0x7f8005cf2000) at xshmfence_futex.h:66
#3 xshmfence_await (f=0x7f8005cf2000) at xshmfence_futex.c:63
#4 0x00007f7ff5cc5c5f in dri3_fence_await (buffer=0x7f7fcc0a4150,
draw=0x7f7fcc03f4f8, c=<optimized out>) at loader_dri3_helper.c:239
#5 dri3_get_buffer (format=***@entry=4107,
buffer_type=***@entry=loader_dri3_buffer_front,
draw=***@entry=0x7f7fcc03f4f8,
driDrawable=0x7f7fcc041a50) at loader_dri3_helper.c:1822
#6 0x00007f7ff5cc6b4a in loader_dri3_get_buffers
(driDrawable=***@entry=0x7f7fcc041a50, format=4107,
stamp=***@entry=0x7f7fcc041a80,
loaderPrivate=***@entry=0x7f7fcc03f4f8,
buffer_mask=***@entry=3, buffers=***@entry=0x563fa60)
at loader_dri3_helper.c:1948
#7 0x00007f7fdb83d4a5 in intel_update_image_buffers (drawable=0x7f7fcc041a50,
brw=0x7f7fcc068980) at brw_context.c:1757
#8 intel_update_renderbuffers (context=***@entry=0x7f7fcc041810,
drawable=***@entry=0x7f7fcc041a50) at brw_context.c:1424
#9 0x00007f7fdb83db35 in intel_prepare_render (brw=***@entry=0x7f7fcc068980)
at brw_context.c:1445
#10 0x00007f7fdb838f63 in brw_clear () at brw_clear.c:254
#11 0x00007f80080627ea in device_clear_render_targets (device=<optimized out>,
rt_count=<optimized out>, fb=<optimized out>, rect_count=1,
clear_rect=0x1301c090, draw_rect=0x1301c064, flags=1, color=<optimized
out>, depth=0, stencil=0) at device.c:449
#12 0x00007f800805bd55 in wined3d_cs_exec_clear (cs=<optimized out>,
data=0x1301c04c) at cs.c:574
#13 0x00007f800805e7b4 in wined3d_cs_run (ctx=<optimized out>) at cs.c:2856
#14 0x000000007bcb812a in call_thread_func (entry=0x7f800805e660
<wined3d_cs_run>, arg=0x12fba030) at signal_x86_64.c:4378
#15 0x0000000000000000 in ?? ()

(gdb) f 5
#5 dri3_get_buffer (format=***@entry=4107,
buffer_type=***@entry=loader_dri3_buffer_front,
draw=***@entry=0x7f7fcc03f4f8,
driDrawable=0x7f7fcc041a50) at loader_dri3_helper.c:1822
1822 dri3_fence_await(draw->conn, draw, buffer);
(gdb) list
1817 }
1818 }
1819 buffer = new_buffer;
1820 draw->buffers[buf_id] = buffer;
1821 }
1822 dri3_fence_await(draw->conn, draw, buffer);
1823
1824 /*
1825 * Do we need to preserve the content of a previous buffer?
1826 *

[b***@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=107757

--- Comment #5 from Olivier Fourdan <***@xfce.org> ---
Sorry, I take that back, attachment 141439 works!

[b***@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=107757

Olivier Fourdan <***@xfce.org> changed:

What |Removed |Added
----------------------------------------------------------------------------
Assignee|wayland-***@lists.freedesk |mesa-***@lists.freedesktop.
|top.org |org
QA Contact|xorg-***@lists.x.org |mesa-***@lists.freedesktop.
| |org
Component|XWayland |GLX
Product|Wayland |Mesa