[systemd-devel] [RFC] VTs for multiple seats

[Christopher James Halse Rogers]

On Tue, 2012-07-10 at 21:29 +0200, David Herrmann wrote:
> Hi Kristian
> 
> On Tue, Jul 10, 2012 at 8:15 PM, Kristian Høgsberg <hoegsberg at gmail.com> wrote:
> > On Tue, Jul 10, 2012 at 12:22:13PM -0400, Casey Dahlin wrote:
> >> On Mon, Jul 09, 2012 at 06:17:13PM -0400, Kristian Høgsberg wrote:
> >> > No, wayland is the protocol, weston is the compositor building
> >> > toolkit.  If you want an EGL compositor on KMS with evdev input, you
> >>
> >> But we don't want an EGL compositor. We want bare-bones KMS support.
> >>
> >> One of the things he mentioned was replacing plymouth with the system
> >> compositor. Do you really want to pack mesa into the initrd?
> >>
> >> The system compositor needs to provide a lightweight SHM-only graphics
> >> stack. It also needs to be able to provide the EGL stack /dynamically/
> >> when the rest of userspace becomes available.
> >
> > Yes, so what you want is an EGL/KMS/evdev compositor that can start
> > out only using sw compositing.  How is that *smaller* than weston
> > again?
> 
> I don't think that is what Lennart has in mind. Or at least I think of
> something simpler. Correct me if I am wrong but I thought it is
> possible to have a compositor that is only linked with libdrm (and
> using only the generic ioctls, no 3D driver dependent stuff). That is,
> the clients, whatever they use for rendering, just pass the DRM
> framebuffer ID to the system-compositor which simply uses this buffer
> as scanout buffer for the connectors. This automatically forces the
> compositor to always make clients full-screen as it has no own
> buffers. This would be a zero copy mechanism that is as fast as the
> client-renderer but doesn't require heavy dependencies in the
> system-compositor. Then, if clients are not DRM compatible, the
> compositor can still create a dumb-buffer and blit the raw buffers
> into the dumb-buffer. This would be a single-copy mechanism but I
> think this is even needed when using full EGL/GL stuff but the client
> does only pass in shm buffers. Overall, this wouldn't require any
> EGL/GL/mesa dependency.
> As a fallback, we could even make the compositor use fbdev instead of
> dumb-buffers for compatibility reasons (even though I think this is a
> bad idea as we probably want to drop fbdev entirely and this is best
> achieved by not supporting it).
> 
> What we gain by this is a system-compositor that is very simply, very
> lean and still very fast. Although, it wouldn't allow any eye-candy
> transitions etc.
> 

But I fully expect that some form of eye-candy transitions - and note
that ‘eye candy’ in this case includes everything down to and including
simple fade-to-black transitions - will be one of the requirements. I
also expect that people will want the system compositor to do more
complicated things, like having an authentication surface for PolicyKit
dialogs.

If you need something in the initramfs (and we do), you can either (a)
scale weston down to a SHM-only compositor which then loads dynamically
loads an EGL backend once userspace is up, or (b) use something like
plymouth's existing KMS framebuffer stuff, and have code in the
system-compositor to seamlessly switch.

But your main system-compositor is going to want to have features that
EGL provides, and it doesn't make much sense to run that compositor on
top of an even more bare-bones compositor underneath.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.freedesktop.org/archives/systemd-devel/attachments/20120711/717c79b5/attachment.pgp>