Review Request 126381: kwayland backend for libkscreen

Wed Dec 16 19:29:47 UTC 2015

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

Great job! 

I can't really comment on the actual Wayland functionality, I leave that to Martin ;) but the code looks pretty good overall.

As I mentioned in one of the comments, there is absolutely no requirement to follow the design of other backends, so if you think you would be better off with another approach in some places, just go ahead.

Below are mostly nitpicks.

autotests/testkwaylandbackend.cpp (line 144)
<https://git.reviewboard.kde.org/r/126381/#comment61364>

    const&

autotests/testkwaylandbackend.cpp (line 240)
<https://git.reviewboard.kde.org/r/126381/#comment61370>

    Use QTRY_COMPARE(configSpy.count(), 1). Hardcoding random timeouts tends to randomly fail on our overcrowded CI.

autotests/testkwaylandbackend.cpp (line 259)
<https://git.reviewboard.kde.org/r/126381/#comment61371>

    QTRY_COMPARE here as well

autotests/testkwaylandconfig.cpp (line 102)
<https://git.reviewboard.kde.org/r/126381/#comment61373>

    IMO you should QVERIFY() if your test invariants that you are testing actually have the expected value.

autotests/testkwaylandconfig.cpp (line 113)
<https://git.reviewboard.kde.org/r/126381/#comment61375>

    QTRY_VERIFY/QTRY_COMPARE

autotests/testkwaylandconfig.cpp (line 117)
<https://git.reviewboard.kde.org/r/126381/#comment61378>

    Why > 3? You do 2 changes, should not that emit exactly 2 change notifications?

autotests/testkwaylandconfig.cpp (line 143)
<https://git.reviewboard.kde.org/r/126381/#comment61376>

    QTRY_VERIFY

autotests/testkwaylandconfig.cpp (line 147)
<https://git.reviewboard.kde.org/r/126381/#comment61377>

    Shouldn't this always be equal to 1? I mean if you perform exactly one change on a single output, you should not get more than one configurationChanged notifications from ConfigMonitor...

autotests/testkwaylandconfig.cpp (line 169)
<https://git.reviewboard.kde.org/r/126381/#comment61379>

    QTRY_VERIFY/QTRY_COMPARE

autotests/testkwaylandconfig.cpp (line 173)
<https://git.reviewboard.kde.org/r/126381/#comment61380>

    Exact change count?

autotests/testkwaylandconfig.cpp (line 197)
<https://git.reviewboard.kde.org/r/126381/#comment61381>

    QTRY_VERIFY

autotests/testkwaylandconfig.cpp (line 201)
<https://git.reviewboard.kde.org/r/126381/#comment61382>

    More precise change count

backends/kwayland/waylandbackend.cpp (line 90)
<https://git.reviewboard.kde.org/r/126381/#comment61358>

    Why not use the `cfg` here? WaylandConfig seems to keep a reasonably up-to-date copy of KScreen::ConfigPtr

backends/kwayland/waylandconfig.cpp (line 110)
<https://git.reviewboard.kde.org/r/126381/#comment61359>

    if (!m_thread->wait(3000)) {
       m_thread->terminate();
       m_thread()->wait();
    }

backends/kwayland/waylandconfig.cpp (line 172)
<https://git.reviewboard.kde.org/r/126381/#comment61361>

    Not that I would not like lambda slots, but there should be limit on how much code you can stuff into them :)

    IMO if it's not possible to deduce what the code is doing from a quick glance at it, it should not be an anonymous lambda, but a normal method with a descriptive name.

backends/kwayland/waylandconfig.cpp (line 228)
<https://git.reviewboard.kde.org/r/126381/#comment61360>

    const&

tests/kwayland/waylandconfigreader.cpp (lines 98 - 102)
<https://git.reviewboard.kde.org/r/126381/#comment61362>

    Use initializer list

- Daniel Vrátil

On Dec. 16, 2015, 3:05 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. 16, 2015, 3:05 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.txt 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/20151216/e25cda4c/attachment-0001.html>