Re: [gdm-list] RFC: user session lifetimes vs. $DISPLAY

[Simon McVittie <simon mcvittie collabora co uk>]

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