kwayland backend for libkscreen

Review Request #126381 - Created Dec. 16, 2015 and submitted

Information
Sebastian Kügler
libkscreen
master
126380
Reviewers
plasma, solid
dvratil, graesslin

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.

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.

Issues

  • 0
  • 86
  • 14
  • 100
Description From Last Updated
Martin Flöser
Daniel Vrátil
Johan Ouwerkerk
Martin Flöser
Kai Uwe Broulik
Martin Flöser
Daniel Vrátil
Kai Uwe Broulik
Kai Uwe Broulik
Kai Uwe Broulik
Daniel Vrátil
Sebastian Kügler
Review request changed

Status: Closed (submitted)

Change Summary:

Submitted with commit cc4de29cf24f06e51dbc7e221ccb89162be525d4 by Sebastian Kügler to branch master.
Hrvoje Senjan

   
backends/CMakeLists.txt (Diff revision 7)
 
 

Either this should be guarded by KF5Wayland_FOUND, or KF5Wayland should be marked as required in top CMakeLists.tyt

  1. KF5Wayland is required in top-level CMakeLists.txt. Where did you see that it isn't?

  2. find_package(KF5Wayland CONFIG)

    There's no REQUIRED keyword here AFAICS

  3. There's no OPTIONAL keyword there, either. My understanding is that find_package() defaults to REQUIRED. (XCB for example is explicitely marked as OPTIONAL.) Please correct me if I'm wrong.

  4. Nope; omitted REQUIRED implies OPTIONAL by default for some time now.

    Also see
    https://cmake.org/cmake/help/v3.0/command/find_package.html - "If REQUIRED is specified and the package is not found a fatal error is generated"
    https://cmake.org/cmake/help/v3.0/module/FeatureSummary.html - "TYPE: What type of dependency has the using project on that package. Default is OPTIONAL."

    (as a side note, the XCB got marked as OPTIONAL in this patch, actually)

  5. Hah, thanks. I'll change accordingly.

Loading...