Re-purposing KWaylandServer

[Vlad Zahorodnii]

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
>