Re-purposing KWaylandServer

[Aleix Pol]

On Wed, Apr 28, 2021 at 10:27 AM Vlad Zahorodnii
<vlad.zahorodnii at kde.org> wrote:
>
> 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?

When I moved KWayland Server I took the kscreenlocker dependency for
granted, it's something I didn't question. I can't say I understand
why it needs to have a wayland server there.

+1 for unifying them and refactoring all within a product. It must
stay properly separate but it would allow us to organise the
components in ways that make sense beyond the frameworks splitting
much like you are finding right now.

Aleix