When confined (in mir-test-tools) GLMark2Xwayland.* "succeeds" without displaying anything #1722
Comments
|
I don't yet know the reasons, but nothing appears because Xwayland doesn't draw any surfaces. The odd thing is that occasionally things do get drawn. |
|
OK, so Mir creates the endpoint in the spoof /tmp and glmark2 connects: (I think that arrangement was working a few weeks ago, but I no longer have working code to compare with.) |
|
The one difference I'm seeing with working runs outside confinement is: That's from the Xwayland process... However, this is probably unrelated: running |
|
Test scenario:
Most of the time, nothing will be displayed on the server. But sometimes it will be. Repeatedly running the client (without restarting the server) will either not display or display the same as the first run. Most of the time after restarting the server nothing will be displayed, but sometimes it will be. (And repeated runs of the client are consistent.) (Actually been testing with a local "core20" build.) |
|
Note of a utility script and incantation: $ cat ./glmark2-es2
#!/bin/bash
DISPLAY=:5
socket=${DISPLAY/://tmp/.X11-unix/X}
while [ ! -e "${socket}" ]
do inotifywait "$(dirname $socket)" &> /dev/null
done
exec glmark2-es2 -b build
$ mir_demo_server --enable-x11 --test-client ./glmark2-es2 --test-timeout 5Running this 10 times showed the glmark2 output twice. |
It looks very much as though the glmark2 <-> Xwayland communications are fine. As noted above, Mir doesn't see anything being drawn by Xwayland, the relevant part of the server output: I.e. there is nothing there: no X11 WM message, no Wayland messages and no windows created. |
|
Another data point: starting a separate Xwayland server (in a third terminal window) works reliably. This looks increasingly like something in the X11 WM/X server setup is racy. [edit] In support of the "racy" theory: it seems impossible to get an "strace" of a run where output occurs. |
|
Tracing through the BUT in the failure mode we never get into the |
Not impossible, I left this running in the background: it took 193 iterations. miral-system-compositor&
count=0
while ! grep mir::frontend::XWaylandWM::handle_events mir-test-tools.performance-test.strace
do
snap run --strace mir-test-tools.performance-test --wayland-host wayland-0 --gtest_filter=GLMark2Xwayland.windowed &> mir-test-tools.performance-test.strace
let count=count+1
echo $count
done |
AlanGriffiths
changed the title
1726: Create event dispatcher before running server r=AlanGriffiths a=wmww Related to #1722 and #1723. In combination with #1725, I think this fixes the race condition (though I haven't tested in a confined snap yet). This moves socket pair creation out of the `XWaylandServer` constructor, and creates the event dispatcher before creating the window manager or spawning the server. Because `XWaylandConnector`'s mutex is locked, any events will be blocked on the window manager being created and wont be dropped. Co-authored-by: William Wold <wm@wmww.sh>
1725: Manage X11 windows that existed before window manager started r=AlanGriffiths a=wmww Related to #1722 and #1723. It's a lot of code because XCB is messy, but all it's doing is going through the list of windows, getting their properties and setting up a `XWaylandSurface` for them the same way we do on newly created windows. This alone is not enough to fix the race condition because we don't get the `WL_SURFACE_ID` client message. See next PR for fixing that. Co-authored-by: William Wold <wm@wmww.sh> Co-authored-by: Alan Griffiths <alan@octopull.co.uk>
[Mir 2.0] We just get the black
mir_demo_serverwindow while each of the tests run...The non-snap version [
mir_performance_tests --gtest_filter=GLMark2Xwayland.* --logging on] works fine.The text was updated successfully, but these errors were encountered: