-
Roman Gilg authored
Summary: The current KScreenLocker expects the Compositor to hand over the KWayland::Server::Display pointer. This has several disadvantages: * In KScreenLocker functionality is duplicated which the compositor probably has setup already (creating client connections manually). * The Display object has a way larger scope than what KScreenLocker actually needs. * Ownership of the Display is unclear in regards to memory but also what the compositor is still allowed to do in comparision to KScreenLocker with the Display. * KScreenLocker can only be integrated in compositors using KWayland for managing their wl_display protocol object. Instead it is now enough to hand over a single file descriptor KScreenLocker can use as its client endpoint to talk to the compositor. Test Plan: Manually in Wayland session, autotest. Reviewers: #plasma, davidedmundson Reviewed By: #plasma, davidedmundson Subscribers: apol Differential Revision: https://phabricator.kde.org/D28082
decf7c9d