> On Dec. 16, 2015, 10: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? > > Sebastian Kügler wrote: > 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.
WaylandBackend inherits KScreen::AbstractBackend which does have a virtual destructor that should get called automagically when we unload the backend - so you could just delete the WaylandConfig there and reset s_internalConfig to nullptr. > On Dec. 16, 2015, 10: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? > > Sebastian Kügler wrote: > 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. You could keep a copy of KScreen::OutputPtr in each WaylandOutput and keep it updated, then a call to toKScreenOutput() would just return the copy. The reason I did not do it in the XRandR backend originally was mostly my laziness to deal with keeping modes and clones in sync constantly. - Daniel ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/126381/#review89584 ----------------------------------------------------------- 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 > >
_______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
