2013/8/28 David Herrmann <dh.herrm...@gmail.com>: > Hi > > On Tue, Aug 27, 2013 at 9:16 PM, microcai <micro...@fedoraproject.org> wrote: >> 2013/8/25 David Herrmann <dh.herrm...@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 _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
