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. >> 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 _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
