Adapt to new KScreenLocker API
ClosedPublic

Authored by romangg on Mon, Mar 16, 10:02 PM.

Details

Summary

KScreenLocker only anymore takes an FD when it tries to lock. The connection
is created and kept internally in KWin.

At the moment we do not do any further checks on the lock but directly hand
over an FD whenever KScreenLocker is about to lock.

Diff Detail

Repository
R108 KWin
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.
romangg created this revision.Mon, Mar 16, 10:02 PM
Restricted Application added a project: KWin. · View Herald TranscriptMon, Mar 16, 10:02 PM
Restricted Application added a subscriber: kwin. · View Herald Transcript
romangg requested review of this revision.Mon, Mar 16, 10:02 PM
apol added a subscriber: apol.Tue, Mar 17, 12:40 AM

+1 overall

wayland_server.cpp
508–509

Sounds like if KSldApp wasn't a singleton much of the cleanup code would be much simpler. It could maybe make sense to revisit this?

romangg added inline comments.Tue, Mar 17, 12:48 AM
wayland_server.cpp
508–509

Oh yea. I guess it would also make the autotest easier to maintain since you could just reset the screen locker.

(In regards to the autotest see also: https://bugreports.qt.io/browse/QTBUG-82911)

And actually I tried to make it a member of WaylandServer (and already replaced all the KSldApp::self() getters in the code base with some waylandServer()->screenLocker() getter). But crudely enough the screen locker is already queried before the WaylandServer singleton is created by classes like PointerInputRedirection.

What sounds kind of wrong. But to tackle this there would be a larger refactoring needed for the startup order or with which class the screen locker interfaces.

davidedmundson added inline comments.
wayland_server.cpp
508–509

not sure that's the right.

KSLDApp is the process that launches the screenlocker when needed, it has to have the lifespan of the session.

523

why do we do this on every lock?

526

Can this be done the other way round in the seat constructor

then we get rid of all these connects and disconnects

575

who deletes m_screenLockerClientConnection in this case?

romangg added inline comments.Wed, Mar 18, 11:10 PM
wayland_server.cpp
523

Because the client connection is reset after every lock/unlock and I'm not sure it's possible to reuse the same socket for a new client. The connection is accessed by the greeter. And if the greeter exits the client connection is destroyed by callback.

526

Yea, when the KSldApp is a undestroyed singleton sure. Having it here improves locality imo but I can also put it in the constructors.

575

When the client goes down libwayland calls into the client connection destroy callback and that deletes the client here:
https://cgit.kde.org/kwayland.git/tree/src/server/clientconnection.cpp#n61

At this point trying to delete the connection from KWin's side would be a double-free.

If you think this API is not so intuitive don't look in the Client lib. :)

romangg added a comment.EditedMon, Mar 23, 1:25 PM

Shall I put the connects in the constructor to move this forward?

davidedmundson accepted this revision.Mon, Mar 23, 1:40 PM

Shall I put the connects in the constructor to move this forward?

You choose.

wayland_server.cpp
575

I don't like that client API :/

But this code makes sense then.

This revision is now accepted and ready to land.Mon, Mar 23, 1:40 PM
This revision was automatically updated to reflect the committed changes.