[RFC wayland] System compositor protocol

[microcai]

2013/8/28 David Herrmann <dh.herrmann at gmail.com>:
> 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.

system-compositor decide to do session-switch, just as today Xorg
decide to do VT switch.

kernel should not be involved here. when system-compositor decide to
do session-switch, it notifies logind.

>
>>> 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 can still support VTs for backwards compatibility.
But disabled by default. or disabled at all.

>
>> 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?

The process is there, but wait stage, not consuming any CPU time. When
the user wants session-switch,
the session-compositor grabs the key press, then notifies
system-compositor. Only by that time, this process is wake.

>
>> 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.

Standard is a good thing.

>
> Regards
> David