[RFC wayland] System compositor protocol

[David Herrmann]

Hi

On Mon, Aug 26, 2013 at 10:48 AM, Cedric BAIL <moa.bluebugs at gmail.com> wrote:
> Hello,
>
> Cedric Bail
>
>
> On Aug 26, 2013 2:11 AM, "David Herrmann" <dh.herrmann at gmail.com> wrote:
>>
>> Hi
>>
>> On Fri, Aug 23, 2013 at 11:55 PM, Jason Ekstrand <jason at jlekstrand.net>
>> wrote:
>> > Hello All,
>> > I am in the process of picking back up the old idea of system
>> > compositors.
>> > I am not, at the moment, looking for a review of the code; simply a
>> > review
>> > of the concept and the proposed protocol.  If you would like to look at
>> > my
>> > implementation or try it out, it can be found in the system-compositor
>> > branch of my personal [weston fork on github][1].
>> >
>> > What follows is what I envision for system compositors. (Others may have
>> > a
>> > different idea which is why I'm writing this RFC email.) The basic idea
>> > behind a system compositor is to provide an interface for compositors
>> > whose
>> > only job it is to display other compositors or other stand-alone
>> > full-screen interfaces.  I image three primary purposes for system
>> > compositors:
>> >
>> > 1. As an abstraction layer.  Every time someone wants to write a RDP
>> >    server, VNC server, android backend, or the like the standard answer
>> > is
>> >    "write it as a weston plugin".  The problem with this is that, to my
>> >    knowledge, none of the major desktop environments (GNOME, KDE, EFL,
>> >    etc.) plan to run their compositor as a weston shell plugin.  This
>> > makes
>> >    a weston plugin a poor solution in the long term.  On the other hand,
>> > a
>> >    system compositor is fairly simple to implement and provides a
>> > backend
>> >    to any compositor that can run on top of a system compositor.
>>
>> KDE planned on using weston as underlying compositor. But I doubt
>> GNOME or EFL want to use something like that..
>
> Indeed, Enlightenment is not planning to use Weston. But if a common library
> dealing with all those drm / kms, android, rpi,... did exist, I am sure we
> would use it and contribute to it. I am not a big fan of adding a system
> compositor as it will impact speed and power consumption. As long as we can
> avoid it, and work on systemd / logind seems to go this way, I think it
> would be better.

I did try this with kmscon, but I never moved the library out of the
kmscon-repo as it is a quite fast moving target. So it will probably
take a while until we figure out some proper API. And interest seems
pretty low..

[...]
>> So back to your proposal. I'd like to see something like you did but
>> as a session-compositor (call it whatever you want ;)). So a session
>> that doesn't want to deal with DRM directly (like for instance
>> gdm/xdm/kdm) could avoid starting an xserver or weston and start your
>> session-compositor instead. It then displays it's content via the
>> standard wayland client APIs on this compositor. But this compositor
>> imho should run in a session. So it does *not* allow clients from
>> different sessions to connect. It is *no* system compositor. It's just
>> a daemon which provides graphics-access to the session. It may even
>> allow switching between multiple surfaces. And if you continue this
>> thought, you will notice that it is nothing more than weston but with
>> a *very* reduced wl_shell. Precisely a wl_shell that displays only one
>> surface at a time.
>
> What would be the benefit over a library that does the job in the
> compositor/single application ?

A library would work as long as you have only a single client. But
imagine your login-session also wants a screensaver. You could make
this compositor support a shell which allows a full-screen client
(login-screen) and additionally a screen-saver client.

So as long as your wl_whatever_shell in this compositor is limited to
a single client, I agree, a library would be better. But if you make
it just a little more complex, you should rather use a compositor.

Regards
David