On 18/02/13 20:13, Simon McVittie wrote: >>> Is there any plan for how GUI processes started via session D-Bus >>> activation should pick up the right value for $DISPLAY? > > 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.
It turns out that this shouldn't be needed, because modern versionx of Xorg support something like "DISPLAY=unix:/run/user/1000/X11-display" - so it should be possible to impose this on all processes within the login1.User. (logind already sets up that path as a symlink or hardlink.) That isn't going to be particularly graceful if a login1.User has more than one X11 display. GUI applications that are D-Bus/systemd-activated *and* want to cope gracefully with this situation will have to do it themselves, perhaps by accepting a display number from the requester when it asks them to make a window, and potentially opening windows on more than one display. logind's choice of what to link to X11-display is perhaps not perfect (it will tend to prefer the first X11 display seen, even if that one is idle), but that can be improved on if/when it becomes a practical problem. >>> If there is not currently a plan for how to deal with DISPLAY and >>> XAUTHORITY XAUTHORITY is not relevant on Linux (i.e. not relevant if systemd works), because it can be superseded by something like "xhost +si:localuser:smcv" or the equivalent Xlib calls. GDM already knows how to do that: for the greeter session, it uses Xlib. For the login session it certainly runs xhost(1) in the Xsession script, but it might also do the equivalent Xlib calls internally. S _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel