Review Request 126381: kwayland backend for libkscreen

[Martin Klapetek]

> On Dec. 24, 2015, 9:23 p.m., Hrvoje Senjan wrote:
> > backends/CMakeLists.txt, line 3
> > <https://git.reviewboard.kde.org/r/126381/diff/7/?file=424946#file424946line3>
> >
> >     Either this should be guarded by KF5Wayland_FOUND, or KF5Wayland should be marked as required in top CMakeLists.tyt
> 
> Sebastian Kügler wrote:
>     KF5Wayland is required in top-level CMakeLists.txt. Where did you see that it isn't?
> 
> Hrvoje Senjan wrote:
>     >find_package(KF5Wayland CONFIG)
>     
>     There's no REQUIRED keyword here AFAICS
> 
> Sebastian Kügler wrote:
>     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.

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)


- Martin


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126381/#review90076
-----------------------------------------------------------


On Dec. 22, 2015, 12:46 a.m., Sebastian Kügler wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126381/
> -----------------------------------------------------------
> 
> (Updated Dec. 22, 2015, 12:46 a.m.)
> 
> 
> Review request for Plasma, Solid, Daniel Vrátil, and Martin Gräßlin.
> 
> 
> 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
> -----
> 
>   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/20160104/f86c0a2c/attachment.html>