On Sat, 19.05.12 14:55, David Herrmann ([email protected]) wrote: > > 1) Is there any documentation of the logind DBus API? When kmscon is > > started on a seat, the user can open multiple terminals (similar to > > tabbed windows in terminal emulators). Should I register a session > > with logind for each terminal that is opened? > > There seems to be no documentation. However, as far as I can see I > should register a single session for kmscon regardless how many > terminals the user opens. The whole kmscon application is then > considered one session.
The getty should register the session, not kmscon. (I assume that kmscon does not actually do any authentication on its own, does it?) > > 2) How does multi-seat handle VT switches? If two seats are active, I > > guess the xservers share a single VT (lets say vt-7). If one user > > performs a "chvt 1", does that switch to vt-1 for all users? In other > > words, if one user switches to kmscon, then all users are switched to > > kmscon as kmscon and an xserver cannot technically run on the same VT, > > right? > > After seeing seat_can_multi_session() I can now see that only seat0 is > considered multi_session capable (as it is registered as > m->vtconsole). All other seats do not open VTs and do not care for VT > switches. Hence, only one session can run on these seats. Yes, this is the current implementation, but this is not exposed in the bus API so that we can add multi-seat support for non-seat0 later on. > Knowing that multi-session is not supported on seats != vtconsole, you > probably don't have such an API. Therefore, I will have a deeper look > into this and propose one so every seat can be multi-session capable > (unless you explicitely reject such a feature). Yes, this is definitely our intention. > Switching between sessions can then be done via dbus calls instead of > VT_ACTIVATE on /dev/ttyX. This might be more complex than it appears at first, since you need to avoid deadlocks when ksmcon calls into logind, and logind calls into kmscon.... > > 4) Does systemd implement some internal timeouts for device > > reassignments? Imagine drm-card0 is assigned to seat5 and the user > > reassigns it to seat6. If the xserver starts directly up on seat6, it > > might not be able to get drmMaster for the card (xserver crashes in > > this case) because the process on seat5 did not release the drmMaster > > fast enough. The VT-switching logic uses roundtrips to acknowledge > > release/acquire, however, I cannot see something like this for logind > > session/device switching. > > That problem still exists but is probably not triggered in real-world > examples. Anyway, comments are still welcome. It is a real-life problem I would say, and currently there is no nice solution for this. It is not such a burning problem so far, since input devices are multi-open, and hence the race never is visible, but this is something that needs to be fixed properly eventually. Lennart -- Lennart Poettering - Red Hat, Inc. _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
