Review Request 126381: kwayland backend for libkscreen
Sebastian Kügler
sebas at kde.org
Thu Dec 17 18:53:35 UTC 2015
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126381/
-----------------------------------------------------------
(Updated Dec. 17, 2015, 6:53 p.m.)
Review request for Plasma, Solid, Daniel Vrátil, and Martin Gräßlin.
Changes
-------
fix patch ;)
Repository: libkscreen
Description
-------
This adds a kwayland backend to libkscreen.
This backend uses KWayland's OutputManagement protocol for enlisting and
configuring devices.
Enlisting outputs
KScreen's outputs are created from KWayland::Client::OutputDevice objects,
they copy the data into kscreen's Outputs, and update these objects. A list
of outputs is requested from the client Registry object.
Configuring outputs
The backend asks the global OutputManagement interface for an OutputConfiguration
object, then sets the changes per outputdevice on this object, and asks the
compositor to apply() this configuration.
For this to work, the compositor should support the Wayland org_kde_kwin_outputdevice
and org_kde_kwin_outputmanagement protocols, for example through
KWayland::Server classes OutputDevice, OutputManagmenent and OuputConfiguration.
General working
WaylandBackend creates a global static internal config, available through
WaylandBackend::internalConfig(). WaylandConfig binds to the wl_registry
callbacks and catches org_kde_kwin_outputdevice creation and destruction.
It passes org_kde_kwin_outputdevice creation and removal on to
WB::internalConfig() to handle its internal data representation as WaylandOutput.
WaylandOutput binds to org_kde_kwin_outputdevice's callback, and gets notified
of geometry and modes, including changes. WaylandOutput administrates the
internal representation of these objects, and invokes the global notifier,
which then runs the pointers it holds through the updateK* methods in
Wayland{Screen,Output,...}.
KScreen:{Screen,Output,Edid,Mode} objects are created from the internal
representation as requested (usually triggered by the creation of a
KScreen::Config object through KScreen::Config::current()). As with other
backends, the objects which are handed out to the lib's user are expected
to be deleted by the user, the backend only takes ownership of its internal
data representation objects.
Diffs (updated)
-----
CMakeLists.txt efac5ce
autotests/CMakeLists.txt 07b7bbc
autotests/configs/default.json 3ac3e19
autotests/testconfigserializer.cpp 1af3069
autotests/testkwaylandbackend.cpp PRE-CREATION
autotests/testkwaylandconfig.cpp PRE-CREATION
backends/CMakeLists.txt ff5d751
backends/kwayland/CMakeLists.txt PRE-CREATION
backends/kwayland/README.md PRE-CREATION
backends/kwayland/waylandbackend.h PRE-CREATION
backends/kwayland/waylandbackend.cpp PRE-CREATION
backends/kwayland/waylandconfig.h PRE-CREATION
backends/kwayland/waylandconfig.cpp PRE-CREATION
backends/kwayland/waylandoutput.h PRE-CREATION
backends/kwayland/waylandoutput.cpp PRE-CREATION
backends/kwayland/waylandscreen.h PRE-CREATION
backends/kwayland/waylandscreen.cpp PRE-CREATION
src/backendmanager.cpp 89ae31e
src/config.cpp e8b8a8f
src/screen.h 4cd1e82
tests/CMakeLists.txt d5e41d5
tests/kwayland/CMakeLists.txt PRE-CREATION
tests/kwayland/main.cpp PRE-CREATION
tests/kwayland/waylandconfigreader.h PRE-CREATION
tests/kwayland/waylandconfigreader.cpp PRE-CREATION
tests/kwayland/waylandtestserver.h PRE-CREATION
tests/kwayland/waylandtestserver.cpp PRE-CREATION
Diff: https://git.reviewboard.kde.org/r/126381/diff/
Testing
-------
The patch contains a test server, which is used for the autotests.
The test server uses KWayland's server classes and is set up from the json config data we use for the other tests. That means that the backends runs against a real server to test everything.
I also tested the kscreen UI, which also works as expected.
Thanks,
Sebastian Kügler
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20151217/15cebf2d/attachment.html>
More information about the Plasma-devel
mailing list