On Tue, Mar 23, 2021 at 9:44 AM Vlad Zahorodnii <vlad.zahorod...@kde.org> wrote: > > Hi, > > Currently, KWaylandServer library is a collection of convenience Qt > wrappers around Wayland protocols. The issue with such a design is that > the bulk of work needs to be still done in the compositor, for example > it still needs to deal with importing client buffers, setting up the > session, handling of input and drm devices, launching xwayland, etc. > > I believe that a better design will involve offloading all non-kwin > features from kwin to kwaylandserver: > > * kwin code base will be leaner. All window management features will be > in kwin, while low level specific bits will be well contained in > kwaylandserver > > * it's a more reusable design in general; this allows writing domain > specific wayland compositors easier, for example for tv, mobile, etc > > * the implementation of some wayland protocols will become a bit more > straightforward. At the moment, due to odd split of functionality > between kwin and kwaylandserver, it's not clear what the best way to > implement some protocols or features is, e.g. presentation feedback, > linux dma-buf, popup grabs, etc > > * it's a safer design choice in long term. Currently, things go quite > well in kwin, but just in case something goes wrong and we decide to > start a new Wayland compositor, we won't have to write low level > components such as the DRM backend, input device handling, and so on > from scratch.
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 it. And as it is, I just realised that it was never ported to kwayland-server... Aleix
