The Qt surface extension is a small protocol to allow exchanging
additional data between QWindows and the compositor. What we are
currently only interested in is the possibility to close a surface
from the Compositor.
Protocol description is copied from QtWayland 5.4.2 branch.
Before emitting the new damage we need to restrict it to the geometry
of the surface. That's required by the documentation and at least
QtWayland/OpenGL emits non-sense damage events.
If a resource is null, because e.g. the surface got already destroyed,
wayland will create an error while marshalling arguments causing
the connected client to in worst case abort.
Apparently we need to add a small delay after starting weston otherwise
it fails to connect on the CI system.
Additionally we switch to using headless-backend.so which should also
make the setup more robust.
Running real world applications (Xwayland) showed that it doesn't like
at all that we do a dispatch when we are going to flush. This caused
in a very reliable manner a "Connection closed" error in XWayland, taking
down the client and in return the (xwayland-enabled) server.
BufferInterface used to have a SurfaceInterface as parent. This could
result in easily hitting the abort condition that the BufferInterface
was still referenced when it gets deleted by just having one other
user referencing the BufferInterface.
There is no need to have the BufferInterface deleted when the
SurfaceInterface to which it belongs gets deleted. The BufferInterface
will get deleted once it's completely unreferenced and also has a
destroy listener.
Basically just wraps the size of the attached buffer. Convenience to
not have to go down to the Buffer to read the size.
TODO: apply buffer scale and transform.
Uses eglQueryWaylandBufferWL (if available) to determine the size of the
buffer. In order to do so, the server library links against egl (1) and
one needs to register the EGLDisplay in Server::Display by the user of
the library. For this a new method Display::setEglDisplay is added.
1: not using epoxy as it doesn't wrap the Wayland interfaces yet.
This change demonstrates how one can install a custom event dispatcher
before creating the QGuiApplication and how to process Wayland events
using the event dispatcher to e.g. start an Xwayland server prior to
creating the application.
It also allows to use
--platform wayland
on the test application. The wayland QPA plugin will connect to the
KWayland server started prior to creating the application.
Please note that such a setup will freeze unless QtWayland has commit
1e32e71 [1].
[1] 1e32e71403
This allows to start the Wayland server before the QCoreApplication is
created with an eventDispatcher being installed through
QCoreApplication::setEventDispatcher.
Instead of performing dispatchEvents for a hard coded number of
expected events from Xwayland, we use select on the pipe to figure
out whether Xwayland has started writing the display number. As long
as select does not indicate that the pipe is ready we need to dispatch
further events.
