> 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 > >
_______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel