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

[David Herrmann]

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.

I don't think this is currently possible with the weston codebase, as
we require each compositor-backend to allow multiple surfaces.

Regards
David