On 30/01/15 09:30, Simon McVittie wrote: > user-session > ------------ > > I don't think there is a standard term for this so I'm making one up.
Notes from the hackfest: A few people called these "super-sessions" when we discussed them. I preferred user-session tbh, but if people want to standardize on calling them super-sessions that's fine. > If people want to put work into this model, we could do a lot better > than we do now; for instance, the bus socket could be > unix:path=${XDG_RUNTIME_DIR}/sessions/${XDG_SESSION_ID}/bus (but with > the necessary escaping) on systems where those variables are set, rather > than messing about with $TMPDIR. Please open an "enhancement"-severity bug against dbus if you want this, and I can talk you through the right places to patch; it would not be rocket science, and if people have use-cases for it, I would be OK with merging it even though I personally prefer the user-session model. > Similarly, if you leave a screen/tmux session detached and running > in the background, systemd is fine with that: its view of the world > is that there are processes left over from your previous login session, > keeping the login session alive in "closing" state, with the consequence > that the user-session remains alive too Notes from the hackfest: Everyone seems to think screen/tmux/... should use PAM to register themselves as first-class login sessions in their own right, if allowed by the sysadmin. That would also work fine. > Under X11, that might well be the best we can do, because typical > X11 applications can't cope with being asked to put windows on more > than one $DISPLAY (although I've heard rumours that Emacs can, which > would make Emacs an ideal candidate to be a user-session service). > Under Wayland or similar future cleverness, hopefully there'll be > some way for a new login on a new seat to "steal" all the windows > from the inactive seat, or some way to merge both seats into > one big virtual display if the same person is using both (AIUI this > is what GNOME designers want to do), or some other clever solution. Notes from the hackfest: Lennart's long-term idea is to have a singleton X server (or Wayland equivalent) per uid, and "hotplug" output devices to it as the user logs in/out on different seats (or remotely via RFB or whatever), with the ability to clone the same window layout onto all displays, or have distinct displays and move windows between them, a lot like the way we currently deal with multiple monitors per seat. This also solves the $DISPLAY problem rather nicely. Regards, S _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel