[Kde-hardware-devel] Review Request 126381: kwayland backend for libkscreen

Wed Dec 16 09:08:10 UTC 2015

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

good work! I omitted the tests/kwayland from review as I need a break after reading through all the unknown code.

autotests/testkwaylandbackend.cpp (lines 84 - 86)
<https://git.reviewboard.kde.org/r/126381/#comment61293>

    Just as an fyi: you could also make the WaylandTestServer operate on anonymous sockets (through the Display::createClient) and pass it in WAYLAND_SOCKET env variable.

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

    nothing is done with ids

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

    QVERIFY(mode->size().isValid()) or !.isEmpty()

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

    nothing is done with ids

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

    ?

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

    as you define a logging category: qCDebug?

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

    add a `_data` variant and test all possible rotation values?

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

    why 2 sec? Is there a reason to go away from the default wait timeout?

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

    and why 200 here?

backends/CMakeLists.txt (lines 5 - 6)
<https://git.reviewboard.kde.org/r/126381/#comment61302>

    there should be a variable for XCB_RANDR. Is KScreen using the find xcb from ECM?

backends/kwayland/README.txt (line 1)
<https://git.reviewboard.kde.org/r/126381/#comment61304>

    change it to README.md and use markdown syntax to encapsulate the structure?

backends/kwayland/README.txt (line 4)
<https://git.reviewboard.kde.org/r/126381/#comment61303>

    enlisting sounds wrong

backends/kwayland/waylandbackend.h (line 37)
<https://git.reviewboard.kde.org/r/126381/#comment61305>

    should the plugin name be .wayland or .kwayland?

backends/kwayland/waylandbackend.h (lines 45 - 51)
<https://git.reviewboard.kde.org/r/126381/#comment61306>

    virtual or override?

backends/kwayland/waylandbackend.h (line 55)
<https://git.reviewboard.kde.org/r/126381/#comment61309>

    why a static variable? Wouldn't it be better to design the WaylandConfig as a singleton?

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

    please use nullptr or Q_NULLPTR for pointers

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

    same here

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

    where does it get deleted?

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

    QStringLiteral

backends/kwayland/waylandconfig.cpp (lines 57 - 64)
<https://git.reviewboard.kde.org/r/126381/#comment61312>

    do you need that? there is also a connection failed signal in ConnectionThread

backends/kwayland/waylandconfig.cpp (lines 87 - 97)
<https://git.reviewboard.kde.org/r/126381/#comment61313>

    Important: connect before calling initConnection. Currently this is racing. InitConnection triggers another thread and it might have finished connecting before the connect is executed.

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

    nitpicky: indentation

backends/kwayland/waylandconfig.cpp (lines 114 - 115)
<https://git.reviewboard.kde.org/r/126381/#comment61315>

    I think you need to delete the connection before deleting the thread. Also you need to use deleteLater as m_connection lives in another thread.

backends/kwayland/waylandconfig.cpp (lines 118 - 121)
<https://git.reviewboard.kde.org/r/126381/#comment61316>

    do these manage a KWayland object? If yes: delete before destroying the connection.

backends/kwayland/waylandconfig.cpp (lines 134 - 137)
<https://git.reviewboard.kde.org/r/126381/#comment61317>

    why DirectConnection? It looks like all being in the main thread anyway.

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

    always add a context (e.g. this) to your lambda connects. Otherwise it might get invoked after the this object is deleted.

    Why capture everything? You seem to only use this in the lambda

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

    same here: only this is used in lambda

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

    don't call into low level wayland code. There is no need for this. What do you want to achieve? I can provide you the correct KWayland method to call.

backends/kwayland/waylandoutput.h (line 83)
<https://git.reviewboard.kde.org/r/126381/#comment61321>

    a mutuable shared pointer? Are you sure about that?

backends/kwayland/waylandoutput.cpp (lines 40 - 47)
<https://git.reviewboard.kde.org/r/126381/#comment61322>

    please use initialiser list for this:

        m_rotationMap = { {Normal, None}, {...}
        }

backends/kwayland/waylandoutput.cpp (line 52)
<https://git.reviewboard.kde.org/r/126381/#comment61323>

    be aware that the operator [] has unexpected behavior if invoked in a non-const condition as it adds a dummy entry if the element is missing.

    Given that I advise to never use the operator []. Instead I would use constFind.

    Especially this code fragment doesn't consider the case that transform doesn't exist in the map. If that is an impossible condition I advise to add a Q_ASSERT for it.

backends/kwayland/waylandoutput.cpp (line 62)
<https://git.reviewboard.kde.org/r/126381/#comment61324>

    what if the mode doesn't exist as a key?

backends/kwayland/waylandoutput.cpp (line 67)
<https://git.reviewboard.kde.org/r/126381/#comment61325>

    what if mode doesn't exist? This would return a default constructed int.

backends/kwayland/waylandoutput.cpp (lines 107 - 113)
<https://git.reviewboard.kde.org/r/126381/#comment61326>

    shouldn't it cache the OutputPtr in case it gets invoked again?

backends/kwayland/waylandoutput.cpp (line 166)
<https://git.reviewboard.kde.org/r/126381/#comment61327>

    do you intend to cut precision here? I mean very often a refresh rate is 59998, this would represented as 59 here, but in fact it's more like the expected 60.

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

    QStringLiteral

backends/kwayland/waylandoutput.cpp (line 178)
<https://git.reviewboard.kde.org/r/126381/#comment61329>

    QStringLiteral

src/backendmanager.cpp (line 205)
<https://git.reviewboard.kde.org/r/126381/#comment61330>

    hmm?

src/backendmanager.cpp (line 353)
<https://git.reviewboard.kde.org/r/126381/#comment61331>

    also hmm?

- Martin Gräßlin

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/kde-hardware-devel/attachments/20151216/7570b017/attachment-0001.html>