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

Sebastian Kügler sebas at kde.org
Wed Dec 16 13:42:20 UTC 2015 


> On Dec. 16, 2015, 9:08 a.m., Martin Gräßlin wrote:
> > good work! I omitted the tests/kwayland from review as I need a break after reading through all the unknown code.

Hi Martin,

No problem, that's not the critical part, anyway.

I've gone over the list of issues and dropped a few (commented on those). Some of them have to do with libkscreen's behaviour, and if they're to be changed, that needs to be done across all backends.)

I hope Dan is going to have another look if I've done these things correctly though, but at least they're in line with other backends.

I'll address the remaining issues next. Thanks a lot for the review already!


> On Dec. 16, 2015, 9:08 a.m., Martin Gräßlin wrote:
> > backends/kwayland/waylandconfig.cpp, lines 57-64
> > <https://git.reviewboard.kde.org/r/126381/diff/2/?file=423835#file423835line57>
> >
> >     do you need that? there is also a connection failed signal in ConnectionThread

Starting a event loop and not catching a timeout seems brittle to me, especially since this would freeze the application. I'd rather have it fail in this way, then. Perhaps overly careful, but better safe than sorry here.


> On Dec. 16, 2015, 9:08 a.m., Martin Gräßlin wrote:
> > backends/kwayland/waylandoutput.cpp, lines 107-113
> > <https://git.reviewboard.kde.org/r/126381/diff/2/?file=423837#file423837line107>
> >
> >     shouldn't it cache the OutputPtr in case it gets invoked again?

No, that's a kscreen idiosyncracy again.

Can't say I'm overly happy with this design, but it's in line with what the library expects, and with other backends.


> On Dec. 16, 2015, 9:08 a.m., Martin Gräßlin wrote:
> > src/backendmanager.cpp, line 205
> > <https://git.reviewboard.kde.org/r/126381/diff/2/?file=423840#file423840line205>
> >
> >     hmm?

This and the next one are left-overs from the inprocess work. They're really not needed, but are in my branch, so in they will go. (It's separate commits in my branch, anyway.)


> On Dec. 16, 2015, 9:08 a.m., Martin Gräßlin wrote:
> > backends/kwayland/waylandbackend.cpp, line 46
> > <https://git.reviewboard.kde.org/r/126381/diff/2/?file=423833#file423833line46>
> >
> >     where does it get deleted?

Nowhere. :/

This is in line with other backends, though. If it's to be fixed (Dan?), this would need to be done globally. For this backend, it's one of the idiosyncracies of libkscreen we have to live with.


> On Dec. 16, 2015, 9:08 a.m., Martin Gräßlin wrote:
> > backends/kwayland/waylandconfig.cpp, line 153
> > <https://git.reviewboard.kde.org/r/126381/diff/2/?file=423835#file423835line153>
> >
> >     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.

It hung and never arrived on the other side. I'll check again if it's needed, and if so, will get back to you.


- Sebastian


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


On Dec. 16, 2015, 2: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, 2: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/5ebe3549/attachment-0001.html>

More information about the Kde-hardware-devel mailing list