Hi On Wed, Dec 4, 2013 at 2:32 PM, Hans de Goede <[email protected]> wrote: > Hi All, > > I've been looking into using systemd-logind Session.TakeControl() > and friends from the xserver, so that the xserver can let > logind open/close the device nodes for it, and then hopefully > will no longer need root rights. > > Sofar I've mainly been finding investigating / finding my way around > the xserver. > > So today I was ready to start adding some initial code for this to > the Xserver, only to immediately hit a roadblock :| > > Hence this mail I'm looking for input on how to solve the problems > I've found sofar. Below I try to explain the 2 problems I see and > I ask a few initial questions about them. Your input on this is > very much appreciated. > > Problem 1: > 1) TakeControl() works on a session, so the xserver will need to find > the session it is to serve and then TakeControl of that session. > > Questions about problem 1: > * Does gdm create the session before starting X ?
No. gdm uses a single Xserver for the login-screen and for the session. But once you log in multiple times, I think it starts a new Xserver for each. But I am not that familiar with gdm.. > * Can gdm pass in the session id, or the pid of the session leader > to X when starting X ? Just use sd_pid_get_session(). It's in systemd/sd-login.h. It returns the session ID of a given process. Don't pass session-ids around. > Problem 2: > 2) When switching from the "gdm" session to the user login session > a new session gets created. For this to work we either need to > start a new X, or X needs to deal with the session going away, > and another one showing up. Dealing with this means releasing > all devices including the drm node and then re-opening it when > X gets the new session. 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 have some ideas how to do transition effects between compositors, but haven't come around to implement it. I'd recommend just not doing any effects for now. > Questions about problem 2: > * I know starting a new X for the user-session is undesirable, > but is it a blocker ? Why undesirable? That's the way to go. > * How feasible is it to make X deal with the drm node going away, > without fully invoking the entire switch vt logic ? I don't see why that's needed. We should just stop sharing Xservers. I am currently working on systemd to provide basic fallbacks for all this. See here: http://cgit.freedesktop.org/~dvdhrm/systemd/log/?h=console Especially the commit "gfx: add monitor". I rebase that branch quite often so commit-ids are useless.. 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. systemd-welcomed is still under development, but systemd-consoled already works. You might also want to look at weston-git/src/logind-util.c which implements this for weston. It differs from systemd-consoled as it doesn't support multiple GPUs (which consoled/welcomed do!). Thanks David _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
