Hi Colin, I realise this thread may be out-of-date by now, so please excuse me if I'm commenting on something which has later changed.
On Sun, Aug 4, 2013 at 4:46 PM, Colin Walters <[email protected]> wrote: > On Tue, 2013-07-30 at 01:02 +0200, Lennart Poettering wrote: > >> We are working on this bit by bit. If you want this to go faster, then >> please work with us, and write patches for libX11 and D-Bus. > > Ok, some hacking on the plane on the way to GUADEC got me really far on > this; then we had a quick face to face to work through some conceptual > issues. > > In the new user@ model, it's very important to note there is only one > "stub" process per session (at least graphical ones - whether we change > getty is a whole other topic). So for graphical, everything is launched > from [email protected]. The side effect of this is twofold: > > 1) Pretty much all the user processes are no longer inside a session > at all. > 2) It is now much harder to log in multiple times graphically; this > is kind of a crazy thing to do, but it's still *possible*. To do > so, you wire up your userspace code to set > the pile of usual environment variables to override (DISPLAY, > DBUS_SESSION_BUS_ADDRESS, etc.) I can say though at least for > GNOME we haven't supported this for years, so it's really not > a change. > > For for adapting to 1), we agreed on adding the concept of a "primary" > session, which is basically the first non-tty login. I've added a small > API to systemd to look this up, and the patched GNOME to use it > (although we partially still respect XDG_SESSION_ID). Hm, I'm not really happy with the notion of a "primary" session, particularly as it relies on distinguishing between graphical and non-graphical sessions (where does the line go between a traditional VT, systemd-consoled, kmscon, wayland, X,...). And also relying on something being the "first" sounds like it may become confusing for the user. Have you considered taking things one step further, and simply force at most one logind session per user? This would mean that logging in as the same user the second time means the new login will join the already existing session. We then get: * If at most one of the logins is associated with a seat (and the rest are remote), things will work just as now. * If two logins (of the same user) are associated with different seats, this is not really supported at the moment, so we could ban it, or we could simply allow it and temporarily merge the two seats and let the session controller (window manager) deal with how that should be presented to the user. This would probably mean that we want logind's interfaces for getting hardware devices should be per-user, and not per-session. * If two logins (of the same user) are both associated with the same seat, we'll have to allow switching between the two apps being the session controller within the same session (this is a common use-case for when you login once with consoled and once with mutter, or something like that). Cheers, Tom _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
