Hi On Mon, Aug 26, 2013 at 10:48 AM, Cedric BAIL <moa.blueb...@gmail.com> wrote: > Hello, > > Cedric Bail > > > On Aug 26, 2013 2:11 AM, "David Herrmann" <dh.herrm...@gmail.com> wrote: >> >> Hi >> >> On Fri, Aug 23, 2013 at 11:55 PM, Jason Ekstrand <ja...@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 _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
