Mir

XWayland clients updates not causing redraw

Bug #1720223 reported by Gerry Boland on 2017-09-28
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Mir
Fix Released
High
Alan Griffiths

Bug Description

Using the staging PPA

miral-shell
Xwayland :2
DISPLAY=:2 /usr/lib/x86_64-linux-gnu/qt5/examples/opengl/hellowindow/hellowindow

This should animate continually, but actually only updates when I move the mouse.

Related branches

The will only work when you have --cursor software enabled for the server. As when new buffers are swapped allows for the xwayland clients to render. Not sure what ends up causing this bug in mir.

Changed in mir:
milestone: none → 0.28.1
Alan Griffiths (alan-griffiths) wrote :

I've tried this as follows:

$ cmake-build-debug/bin/miral-app --cursor software

[In the app session]

QT_QPA_PLATFORM=wayland /usr/lib/x86_64-linux-gnu/qt5/examples/opengl/hellowindow/hellowindow&

works (as expected)

miral-xrun -Xwayland /usr/lib/x86_64-linux-gnu/qt5/examples/opengl/hellowindow/hellowindow&

Appears to work (eventually, it needs a dbus timeout before anything happens)...
...until the first session is closed. Then, only updates on mouse movement as described.

Changed in mir:
status: New → Triaged
importance: Undecided → High
Changed in mir:
assignee: nobody → Alan Griffiths (alan-griffiths)
Alan Griffiths (alan-griffiths) wrote :

Well, the clear difference is that QT_QPA_PLATFORM=wayland invokes the Surface::commit_thunk() while I cannot identify any notification by Xwayland that an update is pending.

However, my understanding of how this *should* work doesn't go any deeper than that.

Alan Griffiths (alan-griffiths) wrote :

Hmm "the mechanism by which a client provides and updates the contents is defined by the buffer factory interface". Helpfully vague.

Changed in mir:
assignee: Alan Griffiths (alan-griffiths) → nobody
Chris Halse Rogers (raof) wrote :

Oh, hello!

The problem is Xwayland is single-buffered; it only ever allocates a single wl_buffer and repeatedly wl_surface.attach()es it.

The problem here is that we tie the frame callback to the MirBuffer, and only submit the frame callbacks when we first construct the MirBuffer. Since the compositor never releases the MirBuffer we never construct a new one, and so all subsequent frame callback requests are ignored.

Bah.

Daniel van Vugt (vanvugt) wrote :

Merge with bug 1194333? :)

Alan Griffiths (alan-griffiths) wrote :

> Merge with bug 1194333? :)

I think this is sufficiently distinct, fixing it for Wayland won't solve the general case.

Daniel van Vugt (vanvugt) wrote :

Fair enough. On a related note, when working on Xmir I found the same problem -- Xmir needed support for single buffering (in theory) to render most cases correctly. While Xmir does contain workarounds for this, they are visibly buggy. In theory a simpler and more performant solution would be single buffering support in Mir itself.

Changed in mir:
assignee: nobody → Alan Griffiths (alan-griffiths)
Changed in mir:
status: Triaged → In Progress
Mir CI Bot (mir-ci-bot) wrote :

Fix committed into lp:mir at revision None, scheduled for release in mir, milestone Unknown

Changed in mir:
status: In Progress → Fix Committed

The branch that landed, seems to only fix when running on mesa-x11, mesa-drm still exhibits the problem.

Changed in mir:
status: Fix Committed → In Progress

OK, the problem I'm seeing is different. Xwayland isn't starting up. I've logged as lp:1728574

Changed in mir:
status: In Progress → Fix Committed
Changed in mir:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers