Summary:
This patch makes use of wlroot's DataControl interface to support
clipboard management.
Unlike wl_data_device clipboards are sent on every change to all
watchers.
If the data device has a selection set it updates immediately.
Because it was started a year ago it uses the existing style of
wrapping objects. The unit test uses the new approach.
Test Plan:
Updated kwin
used wlroot's wl-copy, wl-paste which are xclip replacements to
show that the clipboard updated correctly
Reviewers: #kwin
Differential Revision: https://phabricator.kde.org/D29330
Summary:
Clipboard managers and middle click paste are new protocols.
We want to be able to copy from a clipboard manager to a regular
clipboard and vice versa without duplicating loads of code.
If we support kliper's "syncronise contents of the clipboard and
selection" inside the compositor that would become an unmanageable amount
of combinations.
It also potentially allows the idea of our XWayland bridge not being a
wayland client and simplifying that code.
Test Plan: Unit test passes
Reviewers: #kwin
Subscribers: zzag
Differential Revision: https://phabricator.kde.org/D29329
BlurInterface always used to be my go-to template when starting a new
protocol, we may as well make it up-to-date with the generation.
Code is reduced by a third.
wl_shell_surface has been deprecated for quite a long time. Nowadays
most clients use the xdg-shell protocol to create desktop-style user
interface elements.
Summary:
Implements the necessary classes to have proper support for the tablet and pen.
Doesn't implement yet the ring/slider/totem bits.
Test Plan:
Used it with Plasma and GTK clients, together with the kwin patch I'll submit soon.
https://youtu.be/GGx0TlNJlzs
Also I added a test.
Reviewers: #kwin, #frameworks, zzag, davidedmundson
Reviewed By: #kwin, zzag, davidedmundson
Subscribers: davidedmundson, zzag, kde-frameworks-devel
Tags: #frameworks
Differential Revision: https://phabricator.kde.org/D26858
Summary:
To better isolate the clients from each other eachh KeyboardInterface
creates it's own dedicated temporary file and sends the fd for this
temporary file to the client. This means the memory for the keymap is no
longer shared between all clients, every client has an own copy.
To support this the existing API to set the keymap is deprecated and
replaced by a new method setKeymapData which takes the content of the
keymap as a byte array. The now deprecated method which takes a file
descriptor is changed to use the new setKeymapData method. For that it
reads the content of the file.
The implementation in KeyboardInterface to create the file descriptor is
based on the implementation of KWin. As I implemented the change in KWin
(see 3b4c508ee3) it is not a problem from
GPL vs LGPL perspective.
The change includes test cases to verify that the content of the keymap
is properly passed to the client and that the memory is no longer shared.
BUG: 381674
Reviewers: #kwin, #frameworks, davidedmundson, zzag
Reviewed By: #kwin, zzag
Subscribers: plasma-devel, kde-frameworks-devel
Tags: #frameworks
Differential Revision: https://phabricator.kde.org/D14910
Summary:
So far all double-buffered properties in our implementation of xdg-shell
weren't actually double-buffered. When a property setter is invoked, we
pray to the God hoping that the client committed associated surface.
This change introduces private SurfaceRole class. The new class provides
a way for SurfaceInterface to commit pending state of associated shell
surface.
The chosen architecture allows us to do more in the future. For example,
we could use SurfaceRole to prevent associating several roles to a single
wl_surface object, e.g. xdg-toplevel to a pointer surface, etc.
Test Plan: This change breaks support for client-side decorated clients in KWin.
Reviewers: #kwin
Subscribers: kde-frameworks-devel
Tags: #frameworks
Differential Revision: https://phabricator.kde.org/D23745
Summary:
Allows
* projects linking to KWayland to hide deprecated API up to a
given version or silence deprecation warnings after a given version,
using
* -DKWAYLAND_DISABLE_DEPRECATED_BEFORE_AND_AT
* -DKWAYLAND_NO_DEPRECATED
* -DKWAYLAND_DEPRECATED_WARNINGS_SINCE
* -DKWAYLAND_NO_DEPRECATED_WARNINGS
or
* -DKF_DISABLE_DEPRECATED_BEFORE_AND_AT
* -DKF_NO_DEPRECATED
* -DKF_DEPRECATED_WARNINGS_SINCE
* -DKF_NO_DEPRECATED_WARNINGS
No support for "EXCLUDE_DEPRECATED_BEFORE_AND_AT", needs to be done by
someone with detailed knowledge about disabling implementation, if wanted.
Reviewers: #kwin
Subscribers: zzag, kde-frameworks-devel
Tags: #frameworks
Differential Revision: https://phabricator.kde.org/D24663
Summary: Adding further files is confusing, since the list is almost alphabetical.
Reviewers: #kwin, zzag
Reviewed By: #kwin, zzag
Subscribers: zzag, kde-frameworks-devel
Tags: #frameworks
Differential Revision: https://phabricator.kde.org/D24002
Summary: This interface provides a way for clients to create generic dmabuf-based wl_buffers.
Test Plan: Works with weston-simple-dmabuf-drm and weston-simple-dmabuf-egl in KWin.
Reviewers: #kwin, #plasma, graesslin, davidedmundson, mart, fredrik
Subscribers: zzag, kde-frameworks-devel, romangg, plasma-devel
Tags: #frameworks, #plasma_on_wayland
Maniphest Tasks: T8067
Differential Revision: https://phabricator.kde.org/D10747
Summary:
So far we've been copying protocol specifications from wayland-protocols
repo to kwayland repo. The main issue with copying is that we have to
keep xml files in sync manually. A better approach would be to use xml
specs straight from wayland-protocols package.
Test Plan: Compiles.
Reviewers: #kwin, #frameworks, romangg, davidedmundson
Reviewed By: #kwin, romangg, davidedmundson
Subscribers: davidedmundson, apol, romangg, asturmlechner, kde-frameworks-devel
Tags: #frameworks
Differential Revision: https://phabricator.kde.org/D22216
Test Plan: Tested with both the lock screen and the keyboard indicator plasmoid
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: davidedmundson, kde-frameworks-devel
Tags: #frameworks
Differential Revision: https://phabricator.kde.org/D20191
Summary:
This implements a wrapper class for the wl_eglstream_controller Wayland
interface. It allows clients to inform the compositor when a new EGL Stream has
been created with an Wayland surface attached as its producer. The compositor
can then bind a GL texture as the stream's consumer allowing it access to the
surface's buffer contents for presentation. The only client currently expected
to make use of this interface is the NVIDIA EGL driver when running alongside a
compositor supporting EGLStream-based buffer sharing.
Reviewers: #kwin, romangg, davidedmundson
Reviewed By: #kwin, romangg, davidedmundson
Subscribers: kde-frameworks-devel
Tage: #frameworks
Differential Revision: https://phabricator.kde.org/D18824
Summary:
Usual massive boilerplate.
Should allow us to remove the injection in our QPT, as Qt 5.12 implements
this protocol directly. Will probably be relevant for other toolkits as
it's more standardised than our custom one.
Client is mostly 1:1 with the protocol, server side has some tweaking to
fit with kwayland turning an event based API into a state based one.
Test Plan:
Relevant unit test
Tried in modified kwin with our QPT disabled
Reviewers: #kwin, zzag
Reviewed By: #kwin, zzag
Subscribers: zzag, kde-frameworks-devel
Tags: #frameworks
Differential Revision: https://phabricator.kde.org/D17498
Summary:
Implement the virtual desktop protocol discussed in
T4457 xml protocol, client and server part.
The PlasmaVirtualDesktopManagement interface manages the desktops
instantiation and layout, each desktop is a PlasmaVirtualDesktop
instance which contains unique id, name and position.
PlasmaWindow has new events: plasmaVirtualDesktopEntered
and plasmaVirtualDesktopLeft when a window enters or leaves a desktop,
and desktops as the list of desktops is in. A window can be on
any subset of desktops, if the list is empty, it's considered on all desktops.
Test Plan: Autotest
Reviewers: #kwin, #plasma, graesslin, hein, davidedmundson
Reviewed By: #kwin, #plasma, davidedmundson
Subscribers: davidedmundson, zzag, bshah, romangg, kde-frameworks-devel
Tags: #frameworks
Maniphest Tasks: T4457
Differential Revision: https://phabricator.kde.org/D12820
Summary:
This adds XDG WM Base (essentially XDG Shell v7/stable edition) into our
existing XDGShell classes which wrap v5, v6 and now this.
It's mostly copy and paste from V6 except for the enum types for gravity
and anchor edges on positioners.
There's been no attempt to share code with V6 as realistically that
won't get updates whereas XDGWMBase will; and at some point we will
want to drop V6 without things being too tangled.
Test Plan:
Same test suite as V6 has
Compiled GTK master and ran against suitably modified kwin
running WAYLAND_DEBUG=1 gtk-demo showed we were using this interface
Everything worked as well as V6 does.
Reviewers: #kwin, romangg
Reviewed By: #kwin, romangg
Subscribers: romangg, zzag, kde-frameworks-devel
Tags: #frameworks
Differential Revision: https://phabricator.kde.org/D13510
Summary:
When we add WMBase (the new name stable XdgShell) we get a clash with
XDGShellV5. This clash consists of all functions in the generated C file
which clashes at linker time, as well as multiple xdg_blah_interface
structs which would get redefined.
XDGShellV5 in practice is used by literally no-one (Qt never defaulted
to it if wl-shell was available) and has been dropped from GTK when
they added v6. But it's used by some kwin unit tests so breaking
would cause issues for stable kwin release tests... so it's a pain.
We can't mod the XML as we need the strings sent down the wire to remain
the same and we need the same names for our forward declared structs
that the client code can cast to.
This patch copies the generated files and modifies them manually.
Hacky, but we know this code will never change again - and IMHO this
task isn't one worth investing too much time into.
Test Plan:
Finished my XDG WM Base patch (see next phab) and things compile \o/
Unit test still passes
Ran: QT_WAYLAND_SHELL_INTEGRATION=xdg-shell-v5 dolphin --platform wayland and verified it worked
Reviewers: #plasma, romangg
Reviewed By: #plasma, romangg
Subscribers: romangg, kde-frameworks-devel
Tags: #frameworks
Differential Revision: https://phabricator.kde.org/D13488
Summary:
Done primarily for XWayland which for legacy reasons doesn't assume the
logical size of a display is pixelSize / outputScale. Meaning xwayland
windows that position themselves are wrong in a scaled environment.
It also allows the possibility for us to support fractional scaling
whilst keeping wl_output::scale as an integer.
The protocol is a bit odd as it operates via the FooManager + Foo
pattern rather than using globals like Output so I've wrapped it so it
behaves more like globals.
Test Plan: #plasma
Reviewers: romangg
Subscribers: #frameworks
Tags: #frameworks
Maniphest Tasks: T8501
Differential Revision: https://phabricator.kde.org/D12235
Summary:
It's kept separate in case we ever merge the server decoration manager
interface upstream, and this is too kwin specific to have in a
potentially shared spec.
Code is a copy+paste of existing boilerplate.
Replaces use of the deprecated qt extended surface.
I'd like to target 5.42 as otherwise we'll have a regression when we
release Plasma 5.12 as Qt's XDGv6 doesn't have a working qt extended
surface.
Test Plan: Attached unit test
Reviewers: #plasma, graesslin
Reviewed By: #plasma, graesslin
Subscribers: plasma-devel, #frameworks
Tags: #frameworks, #plasma
Differential Revision: https://phabricator.kde.org/D9599
Summary:
A protocol that attaches to a surface and contains two strings which can
change.
The intended use is for clients to link a DBus Appmenu object with a
surface.
This is in preparation for the Qt Extended Surface deprecation which
currently handles this in Kwin.
Test Plan: Attached unit test
Reviewers: #plasma, graesslin
Reviewed By: #plasma, graesslin
Subscribers: broulik, graesslin, plasma-devel, #frameworks
Tags: #frameworks, #plasma_on_wayland
Differential Revision: https://phabricator.kde.org/D8919
Summary:
This allows a server to filter which globals are visible and bindable by
clients.
Design rationale:
Could be it's own class with Display as an arg, but we need the lifespan
to exactly match Display, and the cardinality to match Display and it
needs to be set after we're started but before clients connect.
Better to enfore rules with code than with documentation.
I'm filtering by interface name as there isn't any other good
identifier of what a wl_global refers to, even if you could assume
you can cast the userdata to a Server::Global.
Test Plan: Attached unit test
Reviewers: #plasma, graesslin, bcooksley
Reviewed By: #plasma, graesslin
Subscribers: bcooksley, graesslin, plasma-devel, #frameworks
Tags: #frameworks, #plasma
Differential Revision: https://phabricator.kde.org/D8050
Summary:
This protocol allows to indicate that a wl_surface should inhibit idle
actions such as DPMS, screen locking if the surface is visible.
The protocol is quite simple: it just creates an IdleInhibitor for a
Surface. If such an IdleInhibitor exists the Surface is considered to
inhibit idle.
On the server side it is also exposed like that through the API. The
IdleInhibitorInterface is private to the library and only
SurfaceInterface is extended to expose whether it currently inhibits
idle.
CCBUG: 385956
Test Plan: New test case added
Reviewers: #frameworks, #kwin, #plasma_on_wayland
Subscribers: plasma-devel
Tags: #plasma_on_wayland, #frameworks
Differential Revision: https://phabricator.kde.org/D8396
Summary:
Implement the "foreign" wayland protocol.
A client can export a surface with an unique string as handle,
then another client can refer to that surface and set an own surface as
child of that surface.
Potential use cases are out-of-process dialogs, such as file dialogs,
meant to be used by sandboxed processes that may not have the access
it needs to implement such dialogs.
The handle needs to be shared between the processes with other means,
such as dbus or command line paramenters.
The public api of the server side only tracks parent/child relationships as this is the only data kwin would need it for, the rest of the api is not exported so should be safer from eventual protocol changes
Test Plan:
the autotest works, but has a lot of random crashes when deleting surfaces,
unfortunately backtraces don't tell much and the crashes never occur when running into valgrind
behavior may still be wrong, depending on how the protocol is supposed
to work if more clients try to set the same exported surface as parent
Reviewers: #plasma, #kwin, davidedmundson, graesslin
Reviewed By: #plasma, #kwin, graesslin
Subscribers: davidedmundson, graesslin, plasma-devel, #frameworks
Tags: #frameworks, #plasma_on_wayland
Differential Revision: https://phabricator.kde.org/D7369
Summary:
This allows a server to filter which globals are visible and bindable by
clients.
Design rationale:
Could be it's own class with Display as an arg, but we need the lifespan
to exactly match Display, and the cardinality to match Display and it
needs to be set after we're started but before clients connect.
Better to enfore rules with code than with documentation.
I'm filtering by interface name as there isn't any other good
identifier of what a wl_global refers to, even if you could assume
you can cast the userdata to a Server::Global.
Test Plan: Attached unit test
Reviewers: #plasma, graesslin
Reviewed By: #plasma, graesslin
Subscribers: graesslin, plasma-devel, #frameworks
Tags: #frameworks, #plasma
Differential Revision: https://phabricator.kde.org/D8050
Summary:
The main clever part that's not just boring boiler plate is how we
handle the structure change
A surface now has an XDGSurface which then has a an Xdg TopLevel or a
Xdg Popup
We need to fit this into the public API which assumes a surface has a
Surface or a Popup.
The old Surface is similar to the new TopLevel.
The shoehorning works by relying on the fact that a surface without a
role is pretty useless.
Clients create the surface implicitly with the toplevel or implicitly
with the popup.
The server only announced it has a new "XdgSurface" when it gets a new
zxdg_surface_get_toplevel.
----
Popup decisions:
- On popup creation the server should copy the current info from the
positioner and then it gets deleted. Given kwaylands job is to keep
state, we expose all these parameter via popup.
- Due to this positioner is not exposed as a resource anywhere.
- Server API is 100% backwards compatiable.
i.e new code will work identically with v5 clients.
- Client API is not. Grabs are called separately from the constructor,
and the parent surface changed to an xdgsurface, not a raw surface.
V5 code still works as-is, just not with the new constructors.
It seemed better to match the v6 (and what will be the stable v7) than
to try and do hacks and lose functionality.
Given the client needs to change the code to opt into V6 anyway. I don't
think this is a huge problem.
Test Plan: Current test still passes.
Reviewers: #plasma, graesslin
Reviewed By: #plasma, graesslin
Subscribers: graesslin, mart, plasma-devel, #frameworks
Tags: #frameworks, #plasma_on_wayland
Differential Revision: https://phabricator.kde.org/D6047
Using the new extra-cmake-modules module ECMAddQch (since 5.36.0)
this adds the option to automatically build and install a file
in QCH format with the docs about the public API, which then can be
used e.g. in Qt Assistant, Qt Creator or KDevelop.
Additionally the installed cmake config files will be extended
with a target KF5Wayland_QCH containing information about how to "link"
into the generated QCH file, which then can be used in the cmake build
system of other libraries building on this library, by
simply listing this target in "LINK_QCHS" of their ecm_add_qch() usage.
And a respective doxygen tag file with all the metadata about the
generated QCH file and used for the "linking" will be created and
installed.
Pass -DBUILD_QCH=ON to cmake to enable this.
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.
