DataDevice exposes new methods to get the DataOffer provided through
drag'n'drop and also signals to indicate the various changes on the
DataDevice during drag'n'drop.
This allows to add a first basic auto test for the drag'n'drop
functionality covering both server and client side.
Summary:
How drag'n'drop works on Wayland:
When a surface has a pointer grab and a button pressed on the surface
(implicit grab) the client can initiate a drag'n'drop operation on the
data device. For this the client needs to provide a data source
describing the data to be transmitted with the drag'n'drop operation.
When a drag'n'drop operation is active all pointer events are interpreted
as part of the drag'n'drop operation, the pointer device is grabbed.
Pointer events are no longer sent to the focused pointer but to the
focused data device. When the pointer moves to another surface an
enter event is sent to a data device for that surface and a leave
event is sent to the data device previously focused. An enter event
carries a data offer which is created from the data source for the
operation.
During pointer motion there is a feedback mechanism. The data offer
can signal to the data source that it can or cannot accept the data
at the current pointer position. This can be used by the client being
dragged from to update the cursor.
The drag'n'drop operation ends with the implicit grab being removed,
that is the pressed pointer button which triggered the operation gets
released. The server sends a drop event to the focused data device.
The data transfer can now be started. For that the receiving client
creates a pipe and passes the file descriptor through the data offer
to the sending data source. The sending client will write into the
file descriptor and close it to finish the transfer.
Drag'n'drop could also be initiated through a touch device grab, but
this is not yet implemented.
The implementation in this change focuses on the adjustments for pointer.
For the user of the library drag'n'drop is implemented in the
SeatInterface. Signals are emitted whenever drag is started or ended.
The interaction for pointer events hardly changes. Motion, button press
and button release can still be indicated in the same way. If a button
release removes the implicit grab the drop is automatically performed,
without the user of the library having to do anything.
The only change during drag and drop for the library user is that
setFocusedPointerSurface is blocked. To update the current drag target
the library user should use setDragTarget. Sending the enter/leave to the
data device gets performed automatically.
The data device which triggered the drag and drop operation is exposed
in the SeatInterface. The user of the library should make sure to render
the additional drag icon provided on the data device. At least QtWayland
based applications will freeze during drag and drop if the icon doesn't
get rendered.
The implementation is currently still lacking the client side and due to
that also auto test. It's currently only tested with QtWayland clients.
Reviewers: #plasma, sebas
Subscribers: plasma-devel
Projects: #plasma
Differential Revision: https://phabricator.kde.org/D1046
Summary:
The Cursor wasn't properly initialized. E.g. the damage signal didn't
get connected resulting in the server not noticing when the cursor
changes. The damage only got connected if a new cursor got instelled by
the client on the same pointer.
This change ensures that the Cursor is properly initialized by calling
into the same method as when the cursor changed.
The tests are extended by a new test case for damaging the surface.
Reviewers: #plasma
Subscribers: plasma-devel
Projects: #plasma
Differential Revision: https://phabricator.kde.org/D1022
Summary:
The signal gets emitted whenever the focused PointerInterfaces gets
newly set or reset to nullptr. This is needed to better track the
current cursor image in the compositor.
Reviewers: #plasma, sebas
Subscribers: plasma-devel
Projects: #plasma
Differential Revision: https://phabricator.kde.org/D1007
Summary: Convenient API to get the absolute executable path for the pid.
Reviewers: sebas, mart
Subscribers: plasma-devel
Differential Revision: https://phabricator.kde.org/D858
This patch transports the EDID data base64-encoded over the wire.
Apparently, we can't just send random QByteArrays as "strings" over, it
has to be encoded and decoded. So...
* base64-encode the data before sending to the client
* base64-decode it on the client side
* document the above, fix documentation woes in the xml definition
* change test accordingly
The test data used was actually invalid, it's a base64 string of the
actual data, so fix the tests (which actually breaks it), and encode on
the server-side and decode on the client side.
REVIEW:126380
So far we only supported mapping global to surface-local coordinates
using a 2D-offset. With this change it's possible to register a
QMatrix4x4 to describe the transformation for going from global to
surface-local coordinates in a full 3D space.
The existing 2D-offset is transformed to use the new matrix based
variant describing a translation.
REVIEW: 126271
A system isn't idle by definition below 5 sec. Before it's not possible
to properly determine whether the user is still interacting with the
system or not. Thus such a short timeout is not sufficient to determine
whether the system is idle.
Furthermore allowing short timeouts like 1 msec can be used to gather
information from the system. It would allow to reconstruct the timestamp
changes on the seat very reliable, which we do not want a Client to know.
And also this can be used to get events on each key press and key release
and the time between each of the events. This can be used to gather
statistics which would in worst case allow to reconstruct what the user
is typing. Determining where a word starts and ends should be relatively
straight forward if you know the timing. With the length of the word and
the statistics of alphabetic distribution it becomes possible to
reconstruct some words. And also individual letters. With enough
statistic and some known words one can determine how long it takes to
press a certain letter. At that point the idle interface would be a
keylogger.
To prevent such attacks the timestamp is now modified to be at least
5 sec. Why 5 sec? Because it's the smallest timestamp used in the
KIdleTime example application which I do not want to break.
5 sec are long enough to destroy this possible attack.
REVIEW: 126220
After deleting an OutputInterface the resources are not necessarily
destroyed, so unbind might still be called. The existing code just
casted the resource's user data which could then point to invalidated
memory.
This change verifies that we still have a Private* for the resource.
If not, it doesn't have to do any cleanup anyway.
REVIEW: 126097
Wrapper around wl_client_destroy. In case the ClientConnection got
created through Display::createClient we need to destroy the
ClientConnection again. The exiting client will not cause it to be
destroyed.
Reviewed-By: Bhushan Shah
This implements the server part of the screen management protocol. The
protocol is implemented as a wayland protocol.
It provides the following mechanisms:
- a list of outputs, close to wl_output, with additional properties for
enabled, uuid, edid, etc.. These OutputDevices correspond to a
connected output that can be enabled by the compositor, but is not
necessarily currently used for rendering.
- a global OutputManagement, which allows creating config objects, one
per client. The client can make changes to the outputs through
setScale(outputdevice*, scale) for example.
- an OutputConfiguration resource, that can be handed to a client and
used for configuration. Changes are double buffered here. Only after
OutputConfiguration.apply() has been called, the changes are relayed
over the global OutputManagement.
The compositor is responsible to handle changes.
For a more detailed description, see the API docs in especially
outputconfiguration.h.
REVIEW:125942
this exposes the geometry of taskbar entries in
plasma-windowmanagement, in order to make the
minimize effects possible.
unlike on X11, it takes relative positions and
it has one geometry per panel, making possible
to have multiple taskbars working.
REVIEW:125871
A transient surface can indicate through the flags that it does not
want to accept keyboard focus. This is now exposed through a dedicated
method.
REVIEW: 125552
So far transient was a mutual exclusive mode causing a transient window
to not be able to be fullscreen. This seems wrong. Let's have transient
still as a dedicated mode allowing the window to be maximized and/or
fullscreen. Only popup stays a dedicated mode.
REVIEW: 125468
On client side a setTransient method is added which wraps the semantic
of wl_shell_surface_set_transient.
On server side both set_transient and set_popup are implemented, though
for popup only the transient part is implemented. In particular the grab
is not yet handled and also no popup done is provided.
For the transient on server side the flags are ignored. Main reason is
that Qt does not use the flag, so testing whether it works is tricky
(needs a test application).
REVIEW: 125223
* wl_data_device_manager -> version 2
* wl_data_device -> version 2
* Wayland -> version 1.7
Unfortunately the client side is not yet completely correct. We
need to call wl_data_device_release only if we have a data device
of version 2. But there is no easy way to test this. To change we
will need to introduce a client side version tracking.
BUG: 352663
Follows a useful change added in the kwaylandScanner tool the
s_version becomes part of the Private class.
Also fixes the related generation in the tool.
* fix initializer type -- was hardcoded, seems like an oversight
* add semicolons after class declarations -- one less thing to fix in the
resulting code
REVIEW:125110
Uses QWidgets to render a very small UI.
* lists each Output
* for each output shows whether dpms is supported
* and which dpms mode it's in
* and provides a button to change the mode
Adding support for a org_kde_kwin_dpms interface. On server side
Dpms is mostly bound to the OutputInterface exposing just a very
small manager. Whether Dpms is supported and which mode is used is
tracked directly on the OutputInterface.
In the header for each request a method is created, with following
features:
* ignores requests working as destructor
* adjusts return type for requests containing newId
* adds QObject *parent = nullptr for requests containing newId
* adds the arguements
* turns arguments from wayland into Qt types
In the cpp the same logic is applied. Methods are not properly
implemented and won't compile in the case of returning.
* parses the protocol
* can derive file name to generate from protocol name
* detects which interface is a global and which one is referenced
* generates client code for global and for resource
* comes with a mapping.txt file to translate wl -> KWayland
The small tool added here allows to automate the process of generating
the boiler plate for an interface. Currently it's able to generate the
Client side code representing a wl_global.
The tool does not get installed, so run it from build directory:
Example usage:
./kwaylandScanner -c Foo -f foo -g wl_foo
This will generate a wrapper for the wl_foo interface in files:
foo.h and foo.cpp
The class is called KWayland::Client::Foo.
The tool will be extended. Following things are on the TODO list:
* parse xml to get the Wayland names
* add listener (if needed)
* generate code for Wayland interfaces representing Resources
* generate the Server boiler plate
CCMAIL: mart@kde.org
CCMAIL: sebas@kde.org
* Raises wl_seat supported version to 4 in both server and client
* Raises wl_keyboard supported version to 4 in wl_keyboard
* wl_pointer and wl_touch are still on version 3
* Raises minimum Wayland version to 1.6
a protocol to activate the blur behind windows and to
optionally set a sub region of the window where to apply
the blur to, in case the window is shaped
REVIEW:125015
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.
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.
