On 3/23/21 6:27 PM, Aleix Pol wrote:
I don't feel like there's a use-case for it.
I also don't have the feeling that having 2 separate repositories help
with anything. Moving code from one side to another is cumbersome and
makes history tracking more complex.
I think it would be even cool if we didn't have kwayland-server
altogether. From my perspective, its only reason to be is
kscreenlocker which needs some classes from it:
KWayland::Server::Display and KWayland::Server::ClientConnection.
That's a fair argument. My main gripe with the current architecture is
that the split between kwayland-server and kwin makes it more difficult
to implement some protocols.
For example, client buffers can't be implemented entirely inside
kwayland-server because at some point we need to ask the renderer to
provide us a texture or additional info about the buffer. At the moment,
we work around that by adding EGLDisplay info to the Display so we can
call eglQueryWaylandBuffer in BufferInterface or taking an additional
Impl object as in LinuxDmabufUnstableV1Interface.
I think that the wayland machinery and the rest of the compositor
(backends, renderer, etc) need to live in the same repo, either
kwayland-server or kwin.
I do agree that things will be better off without a separate repo for
wayland wrappers. I guess if the need for a library to write compositors
arises, we can just refactor libkwin and make it more general purpose.
My question is: why does kscreenlocker need KWayland::Server::Display?
Can we port it to QLocalServer/QLocalSocket?
Cheers,
Vlad
That's it.
And as it is, I just realised that it was never ported to kwayland-server...
Aleix
