> On Dec. 24, 2015, 9:23 p.m., Hrvoje Senjan wrote: > > backends/CMakeLists.txt, line 3 > > <https://git.reviewboard.kde.org/r/126381/diff/7/?file=424946#file424946line3> > > > > Either this should be guarded by KF5Wayland_FOUND, or KF5Wayland should > > be marked as required in top CMakeLists.tyt > > Sebastian Kügler wrote: > KF5Wayland is required in top-level CMakeLists.txt. Where did you see > that it isn't? > > Hrvoje Senjan wrote: > >find_package(KF5Wayland CONFIG) > > There's no REQUIRED keyword here AFAICS > > Sebastian Kügler wrote: > There's no OPTIONAL keyword there, either. My understanding is that > find_package() defaults to REQUIRED. (XCB for example is explicitely marked > as OPTIONAL.) Please correct me if I'm wrong.
Nope; omitted REQUIRED implies OPTIONAL by default for some time now. Also see * https://cmake.org/cmake/help/v3.0/command/find_package.html - "If REQUIRED is specified and the package is not found a fatal error is generated" * https://cmake.org/cmake/help/v3.0/module/FeatureSummary.html - "TYPE: What type of dependency has the using project on that package. Default is OPTIONAL." (as a side note, the XCB got marked as OPTIONAL in this patch, actually) - Martin ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/126381/#review90076 ----------------------------------------------------------- On Dec. 22, 2015, 12:46 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. 22, 2015, 12:46 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.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 > >
_______________________________________________ Kde-hardware-devel mailing list Kde-hardware-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-hardware-devel
