This change addresses the sometimes cumbersome to use API of Registry.
So far to bind an interface one needed to connect to the signals when
setting up the registry. There was no other way to get the name and
version at a later point. This made it difficult to use one Registry
in different parts of an Wayland application.
This change adds a convenient:
struct AnnouncedInterface { quint32 name; quint32 version;};
AnnouncedInterface interface(Interface) const
QVector<AnnouncedInterface> interfaces(Interface) const
The first one is meant for interfaces like wl_shm which is normally only
announced once. The latter one is meant for interfaces like wl_output
for which normally multiple interfaces can get announced.
Those methods can be used without having to connect to the announced
spy.
REVIEW: 124734
The shadow protocol is inspired by the KWin's X11 protocol and the
DecorationShadow in KDecoration2.
A shadow is attached to a surface (after a commit on surface) and
consists of several image parts (represented through a buffer):
* top-left
* top
* top-right
* right
* bottom-right
* bottom
* bottom-left
* left
In addition there is an offset on each side.
For more information see also the X11 protocol described at [1].
Note: the protocol is currently missing documentation and changing
the shadow is not yet properly delegated to the server API.
[1] https://community.kde.org/KWin/Shadow
This interface allows a client to fake input events and the server
might use them. There is an authentication mechanismn in place which
requires the server to mark the client as authenticated in order for
any events to be emitted at all.
This interface is intended for use cases like kdeconnect which allows
to remote control a device.
The idle time interface is modelled for the use cases of the KIdleTime
framework to allow providing a Wayland specific implementation.
It supports registering idle timeouts which are triggered on server
side if there has not been any user activity on the seat for the
requested amount of time. Once user activity resumes a resume from idle
signal is emitted.
In additon there is the possibility to simulate user activity which
simulates the resume from idle.
Sending a new PlasmaWindow as an event is quite problematic. The main
problem here is that it sends an id of 0 and this doesn't make sense
when the interface gets bound and all existing windows are send to the
client.
This changes the interaction to have the client create the resource for
the PlasmaWindow instead of the server creating it. The server generates
"window ids" and sends those to the client. The client now binds a
PlasmaWindow with the "window id" in the normal way.
In case the server doesn't know the id any more, it directly sends an
unmapped and destroyes the newly created resource again. It is not a
protocol error as that can happen (common example: file open dialog of
Qt 5 applications on Xwayland).
on xwayland clients, send mouse press, move and release
corresponding to touchDown, move and release
this gives a very basic touchscreen support on
xwayland clients
reviewed-by: Martin Graesslin <mgraesslin@kde.org>
Server can set a themed icon name, client gets it directly turned into a
QIcon. That only works with QGuiApplications as can be seen in the
adjusted paneltest.
Sends an umap to the client and destroys the resource afterwards.
The PlasmaWindowInterface gets automatically destroyed once there
are no more resources bound to it.
Check whether the resource for the Keyboard/Pointer/TouchInterface
is still valid before trying to use it.
This was hitting crashes in wayland during the wl_foo_send_enter
calls.
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.
