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?

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.

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.

why do we do this on every lock?

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

then we get rid of all these connects and disconnects

who deletes m_screenLockerClientConnection in this case?

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.

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

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. :)