Hi On Wed, Dec 4, 2013 at 7:54 PM, Ray Strode <[email protected]> wrote: >> Start one Xserver for each session. Yes, blending and other transition >> effects will get very hard to implement then, but still better than >> sharing an xserver between sessions.. > I think it might be better to wait on that until we have wayland and a system > compositor.
No-one is working on a system-compositor and it is an orthogonal idea to Session.TakeControl(). Both don't work together. Ubuntu tries to introduce a system-compositor with Mir, but no-one tries to do that with Wayland. The idea was dropped by all parties and is actually the reason why we introduced Session.TakeControl() as replacement. I don't want to discuss the pros/cons of system-compositors here. Imho, there is no sane way to implement it and looking at Ubuntu and the problems they're facing, I really think we're better off without it. >> Why undesirable? That's the way to go. > 1) It will cause flicker No it ain't. If you use DRM, you can run a smooth handover without tearing, flicker or other artifacts. It's not obvious and not documented at all (sadly), but it's possible. You simply avoid doing a full/deep modeset on session activation but instead take-over where it was left. Schedule your framebuffer for the next vblank and you will see no artifacts. Obviously, if you need to change (pixel-)modes or clock parameters, a full modeset is required. But that's always the case, whether you use a system-compositor or not. I'm actually working on some improved DRM ioctls to speed up getting mode-information on activation. Currently it can take up to 200ms to do that, which is awfully slow. Note that you can even do blending on handover! FB handles are global resources on DRM so the active Master can access previous buffers and blend over. > 2) It will mean there's always an X server with a login screen running in the > background, even on single user systems. You can shut down the greeter-session after login and re-create it when required again. > I mean it's something we can consider, we even used to have code to do it > (called "factory mode"), but I don't it's a > absolute given that we should do it at this point. I'm lost, sorry. So you are saying we should try it or not? >> systemd-consoled is an example how graphics applications work with >> TakeControl()/TakeDevice(). It expects to be run inside a session, so >> the session has to be setup by the parent beforehand. >> systemd-welcomed is an example how login-screens can work. It spawns a >> separate process for the greeter and one for each session. Note that >> the greeter runs as user "nobody" *inside* of a systemd-logind >> session. So it's the same as any other session. Not like gdm which >> treats the greeter special. > gdm runs the greeter inside a logind session as a "gdm" user, too. It does > this by invoking a minimal pam stack to open the session which runs > pam_systemd. > > The X server doesn't run inside the session at the moment though. I skimmed through the gdm code but didn't find the pam-transaction for the gdm user, only the one for the new sessions. Thanks for clarifying that! It's the right thing to do, imho. Thanks David _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
