Review Request 126381: kwayland backend for libkscreen

[Sebastian Kügler]

> On Dec. 20, 2015, 6:14 p.m., Kai Uwe Broulik wrote:
> > backends/kwayland/waylandconfig.cpp, line 222
> > <https://git.reviewboard.kde.org/r/126381/diff/6/?file=424618#file424618line222>
> >
> >     Out of curiosity, why do you always check explicitly for nullptr and false?

We don't assume ownership of the kscreen config, and I've seen it crash there a few times. I'm not sure if it's still the case, but then, these are no hot paths, the impact is negligible, and a crasher here is really really bad.


> On Dec. 20, 2015, 6:14 p.m., Kai Uwe Broulik wrote:
> > backends/kwayland/waylandconfig.cpp, lines 250-251
> > <https://git.reviewboard.kde.org/r/126381/diff/6/?file=424618#file424618line250>
> >
> >     Btw if you made outputs const you could use a range-for, range-for is only evil on Qt containers if not const. :)

and then I get asked to use either for or FOREACH. (Been there, done that.) Matter of consistency here.

I've made outputs const nevertheless.


> On Dec. 20, 2015, 6:14 p.m., Kai Uwe Broulik wrote:
> > backends/kwayland/waylandoutput.cpp, lines 184-185
> > <https://git.reviewboard.kde.org/r/126381/diff/6/?file=424620#file424620line184>
> >
> >     could just use output->name()

I'd rather see the data from kwayland in here.


> On Dec. 20, 2015, 6:14 p.m., Kai Uwe Broulik wrote:
> > tests/kwayland/waylandconfigreader.cpp, line 33
> > <https://git.reviewboard.kde.org/r/126381/diff/6/?file=424630#file424630line33>
> >
> >     QVector

Qt docs suggest, see QVector docs.


- Sebastian


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


On Dec. 18, 2015, 3:16 p.m., Sebastian Kügler wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126381/
> -----------------------------------------------------------
> 
> (Updated Dec. 18, 2015, 3:16 p.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/20151221/81f2c69f/attachment.html>