On 19/02/13 18:59, Kok, Auke-jan H wrote: > We may have to redefine systemd --user to start with a instance that > defines a "user - seat" pair instead. That would leave multiple > `systemd --user` pairs around, each serving the appropriate desktop. > They could use a central DBus location if needed, share agents and > such. Each would however run with DISPLAY hard set to the right > display number, would that be an improvement?
I don't think it's useful to have multiple `systemd --user` instances sharing one D-Bus session (dbus-daemon --session instance). That just produces the same problem, but instead of "when /usr/bin/gnome-terminal activates org.gnome.Terminal.Server, which DISPLAY should I put it on?" it's "which systemd --user should I start it on?". >> I've started prototyping what would be needed for `systemd --user` to >> track logind sessions, pick up the new $DISPLAY every time the user's >> set of sessions changes, and use that for all new activations. > > this implies that services re-connect to the new display in case it > changes, or better, services hangup when no longer in use in order to > prevent to a nonexistant display. X applications typically terminate when their DISPLAY goes away (indeed, if using Xlib it's difficult *not* to!), so we get that "free". xcb applications don't necessarily *have* to do that, and I can see that there's potentially value in having more service-like applications (gnome-terminal-server again) connect to multiple displays to put the window on the right display, and only terminate when they have no displays at all. I think doing that nicely would imply either better D-Bus API in logind (PropertiesChanged for the DISPLAY property), or making `systemd --user` proxy this information onto the session^Wuser bus. S _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel