Summary:
The pointer constraints protocol is an unstable protocol and thus
the implementation follows the semantics of unstable protocols.
The protocol allows to create a constraint on the pointer - either a
lock or a confinement on a surface. Those are not activated at once, but
when the compositor actively grants it.
During lock no further pointer motion is emitted, during confinement the
pointer is kept in a certain area.
This implements T4451.
Reviewers: #plasma_on_wayland
Subscribers: plasma-devel
Tags: #plasma_on_wayland
Differential Revision: https://phabricator.kde.org/D3466
Summary:
Pointer gestures are created for a pointer and there are two types of
gestures: swipe and pinch.
At a given time there can only be one active gesture. The implementation
in SeatInterface ensures that there can only be one active gesture.
Each gesture consists of a start event, 0 to multiple update events and
an end event. The end can also be a cancel. To better support this the
implementation doesn't follow the protocol and splits end and cancel
into dedicated methods in the server side and into dedicated signals in
the client side.
Reviewers: #plasma_on_wayland
Subscribers: plasma-devel
Tags: #plasma_on_wayland
Differential Revision: https://phabricator.kde.org/D3169
This is ancient code that is outright wrong most of the time and at best
just incredibly unnecessary.
It is also not present in the great majority of frameworks due to this.
Its wrongness comes from the fact that it hardcodes the installation path,
which breaks relocatability of the KF5 tree as it will always attempt to
find the include dir $PREFIX/KF5 (e.g. /usr/include/KF5), which may or may
not exist given that the tree was relocated.
Worse yet, in a cross-building scenario we maybe for example
build on ARM and install to /usr but for cross building take the entire ARM
tree and shift it into /arm/usr/. If we then crossbuild on that tree the
bogus include list in this framework will make sure that we always search
in /usr/include/KF5 and thus potentially load a !ARM header simply because
the relevant ARM header was not installed etc.. Similarly of course a
build in $HOME can pick up /usr/include/KF5 headers because the home ones
are missing, causing unexpected results.
This happens whenever the KDE_INSTALL_INCLUDEDIR_KF5 var is absolute, which
it usually is.
On top of all that the premise of the code in question is flawed. It seeks
to add $PREFIX/$KF5INCLUDES to the search paths (e.g. /usr/include/KF5).
This is unnecessary because the target itself is properly installed via
cmake's install(TARGETS ... EXPORT ...) function [1]. This function has
smart functionality built in which will add the passed INCLUDES destination
to the INTERFACE_INCLUDE_DIRECTORIES property of the targets (i.e. what
the useless code wants to do) [2].
So what happens is that we install the target to the
KF5 locations, which has "include/KF5" as INCLUDES location,
thus causing the correct path to be added to the includes list of the
Targets.cmake file.
In particular thanks to more internal magic in cmake it will do so with
automatically resolved root paths such that the installed tree is
relocatable and able to relatively find the other KF5/* headers. So it
does what the code in question wants to do, just correctly.
Since cmake automatically takes care of injecting $prefix/include/KF5 we
can simply get rid of the wrong custom inejection code. This makes the
generated cmake file find the correct include/KF5/ directory and stops it
from always expecting a /usr/include/KF5/ directory to be present.
[1] https://cmake.org/cmake/help/v3.0/command/install.html
[2] https://cmake.org/cmake/help/v3.0/command/install.html
> The INCLUDES DESTINATION specifies a list of directories which will be
> added to the INTERFACE_INCLUDE_DIRECTORIES target property of the
> <targets> when exported by the install(EXPORT) command.
REVIEW: 129273
CHANGELOG: Improved relocatability of CMake export
Summary:
Especially for Xwayland windows the compositor might not have a themed
icon name. Resulting in a task manager not having dedicated icons for
Xwayland windows.
This change deprecates the way how a compositor is supposed to set the
window icon. Instead of passing the themed icon name, it is now supposed to
pass the QIcon. In case it's a themed icon the existing way to pass to
the client is used.
Otherwise a new event is used to inform the client that there is an icon
- no data is transmitted at this point. The client can then create a
file descriptor and pass it to the compositor. The compositor serializes
the icon into the file descriptor and the client can read from it. This
all happens transparently on client side there is no api change at all.
The writing and reading of the icon is done in a thread. Due to that
Qt5::Concurrent is now a required dependency instead of an optional
dependency.
Reviewers: #plasma_on_wayland, hein
Subscribers: plasma-devel
Tags: #plasma_on_wayland
Differential Revision: https://phabricator.kde.org/D3049
Summary:
This change implements the zwp_relative_pointer_v1 protocol which allows
to send relative motion events.
The (unstable) protocol consists of a RelativePointerManager which
creates RelativePointers for a given Pointer. This interface currently
only has one event to report the relative motion. It carries the delta,
the non-accelerated-delta and a timestamp in microsends granularity.
On the server side the implementation is mostly internal. Once a
RelativePointerManagerInterface is created one can send relative motion
events through the SeatInterface. The SeatInterface takes care of
sending it to the responding RelativePointerInterface. The protocol does
not restrict the sending of "normal" and relative motion events. Thus it
can be combined in any way one wants. This allows to have a rather
simple implementation. A user of the SeatInterface can just start to
feed the relative motion events (if the information is available) to the
SeatInterface together with the pointer events.
On client side a new RelativePointerManager and RelativePointer class
are added. The RelativePointerManager creates the RelativePointer for a
given Pointer. The event sent to RelativePointer is transformed in a
normal signal.
Reviewers: #plasma
Subscribers: plasma-devel
Tags: #plasma_on_wayland
Differential Revision: https://phabricator.kde.org/D2978
Summary:
This change introduces support for the unstable xdg-shell interface in
the server. The implementation is based on version 5 of the unstable
interface. This is the version used by toolkits like e.g. GTK.
There is also a version 6 of the protocol under development which is
incompatible. This makes it difficult to implement it in a backward
compatible way.
Because of that the implementation is a little bit different to other
interfaces and inspired by the TextInput interfaces:
On client side an XdgShell class is exposed which does not represent
it directly. Instead it delegates everything to an XdgShellUnstableV5
implementation. For the Surface/Popup the same is done.
In the Registry it's possible to create an XdgShell and it accepts
the XdgShellUnstableV5 and in future will accept XdgUnstableV6, etc.
On server side it also follows the approach from TextInput. That is
there is a version enum which gets passed to the factory method in
Display. It currently supports only V5, but in future can be extended
for V6. As there is lots of similar code between wl_shell, xdg_shell
and in future xdg_shell_unstable_v6 a templated GenericShellInterface
class is added which combines the common parts.
Reviewers: #plasma_on_wayland
Subscribers: plasma-devel
Tags: #plasma_on_wayland
Differential Revision: https://phabricator.kde.org/D2102
Summary:
This change introduces support for text input. Text input allows to
compose text on the server (e.g. through a virtual keyboard) and sent
the composed text to the client.
There are multiple interfaces for text input. QtWayland 5.6 uses
wl_text_input, QtWayland 5.7 uses zwp_text_input_v2.
wl_text_input is from pre Wayland-Protocols times and considered as
UnstableV0 in this implementation. The other interface is UnstableV2.
Unfortunately the V2 variant is not yet part of Wayland-Protocols, but
used in Qt.
The implementation hides the different interfaces as good as possible.
The general idea is the same, the differences are rather minor.
This means changes to how interfaces are wrapped normally. On client
side in the Registry a manager is factored which represent either of
the two interfaces. Similar on the server side Display's factory method
takes an argument to decide which interface should be factored. This
way a user of the library can expose both interfaces and thus be
compatible with Qt 5.6 and Qt 5.7 onwards.
Reviewers: #plasma
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D1631
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
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.
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
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.
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.
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.
The ClientConnection is managed by Display. Whenever one tries to
get a ClientConnection for a wl_client* and it doesn't exist yet a
new one will be created and a clientConnected signal will be emitted.
Also there is a clientDisconnected signal.
ClientConnection provides access to pid, uid and gid. The idea is
to extend it to provide access to all the resources created for the
client.
The Resource base class is supposed to be used by all interface
classes which get created for a wl_resource.
Most interface classes are adjusted, but there are some exceptions:
* BufferInterface: is different as the wl_resource is already created
* PointerInterface and KeyboardInterface: those two need changes, the
implementation differs from all other interface implementations.
New base class KWayland::Server::Global which all Interface classes
for a wl_global inherit. Furthermore there is a shared base class
for all the Private classes of that type.
Only selection part is implemented, drag'n'drop still needs to be
implemented.
Unit test is not properly testing whether the data can be transferred.
This needs some better architecture to have multiple processes which
perform the source and target part.
This implements the subcompositor and subsurface protocol on both
Client and Server side.
Client:
New classes SubCompositor and SubSurface. The SubCompositor can be
created through the Registry and creates the SubSurface which is
bound to a Surface and has a parent Surface. The SubSurface class
provides convenient wrappers for all calls exposed in the
wl_subsurface interface.
Server:
New classes SubCompositorInterface and SubSurfaceInterface. Support
for all commands is added, though the API probably still can need
some fine tuning. The synchronized vs. desynchronized behavior is
not yet exposed in the API. This could also be delegated towards
the user of the library.
This makes it possible to install and then use it. Installation is still
commented since we can't give enough stability guarantees for now.
In detail:
- do not actually install headers
- generate the export header into Wayland/Server
- include it from there
REVIEW:120579
Framework style build system which generates two libraries:
* KF5WaylandClient
* KF5WaylandServer
autotests are adjusted to compile again. They need to be changed to
use the libraries once the export header gets generated.
