[RFC wayland] System compositor protocol

[David Herrmann]

Hi

On Tue, Aug 27, 2013 at 9:16 PM, microcai <microcai at fedoraproject.org> wrote:
> 2013/8/25 David Herrmann <dh.herrmann at gmail.com>:
[...]
>> The idea behind a system-compositor was to provide a system daemon
>> that runs _outside_ a session. Its sole responsibility is to control
>> access to graphics and input hardware. So session-compositors no
>> longer access hardware directly, but instead tunnel it through the
>> system-compositor. But this means, the system-compositor must know of
>> session-switches and correctly display only the session-compositor of
>> the active session. However, session-switching is controlled by
>> logind, so the system-compositor gets the session-switch notification
>> _after_ the session was actually switched, making this kind of racy
>> (but still ok!).
>
> when the user wants to switch, logind should be notified by system-compositor.
> system-compositer controls the screen and the input, not logind, so
> there should be no race.

Yeah, this is *not* how it works. Currently a session-switch is
controlled by either the kernel (for VTs) or by logind. I don't see
any reason why this should change. Please explain yourself if you
disagree.

>> The bigger problem is, the system-compositor is not part of a session
>> so it has to be active *all the time*. You cannot have some sessions
>> using the system-compositor and other sessions doing it the old way.
>> You cannot do device-access handover from the system-compositor to a
>> self-hosting or legacy session. This would require ugly racy hacks and
>> conflict with VT!
>> But if the system-compositor is always active, you cannot use VTs in
>> text-mode. Because VTs in text-mode access graphics hardware
>> *directly*.
>
> if we want to kill VT, then better we have system-compositor. I see no reason
> to support kernel VTs when you could have system-compositor.

I don't see any reason to support VTs at all. But it's not me to
decide, so we will always support VTs for backwards compatibility.

> system-compositor is not always active. In fact, it only got wake up when you
> do session switch. the session compositor directly render to the screen. there
> is no need to wake up system-compositor here.

In this scenario, how does the system-compositor know whether the
session that you switch to renders directly or requires the
system-compositor?

> sessions that does not use system-compositor is a dead end.
> All sessions should and must output to system-compositor.
> system-compositor should be socket activated, and guaranteed to be there.

Please elaborate. You are just claiming stuff without explaining why..
Or is this just your opinion?

[...]
>>
>> Yepp, that's all we need. Just rename it from "system_compositor" to
>> "wl_fullscreen_shell" (I bet you can come up with some fancier name).
>> No other criticism on this proposal from my side.
>>
>> Feel free to disagree ;) I am open for suggestions or criticism.
>> Cheers
>> David
>
>
> with system-compositor, we can do cross-session visual effects
> that's hard to be done without a system-compositor.

And "hard to be done" is bad?
Choosing the convenient way here means adding latency (by routing
everything through the system-compositor). We don't want that.
And "cross-session visual effects" are still possible. I will present
that at XDC in 1 month.

> with system-compositor, we provide unified input handing,
> multi-GPU handing, multi-monitor handing, and integrate that well with logind.

Please show to me how this integrates well with logind?

"Multi-GPU", "multi-monitor", "unified input",.. that has nothing to
do with a system-compositor. You can have that with
session-compositors, too. In fact, we already have all that..

> with system-compositor, we killed kernel VTs. we can still provide
> text terminal as clients of system-compositor.

Has nothing to do with system-compositors..

> with system-compositor, we secured our GPUs.

What? In your claim above you said system-compositors *don't* always
have to be active. How do you protect your GPU during such switches?

> with system-compositor, we can make system-compositor to load old Xorg drivers
> to bring up OGL and do user-mode setting while native KMS drivers absent.

Again, this has nothing to do with system-compositors. You can
implement that in any compositor.

Regards
David