Hi I've spent some more time reading systemd/src/login/logind* and could solve few questions myself, but the multi-session question still remains:
On Wed, May 16, 2012 at 4:01 PM, David Herrmann <[email protected]> wrote: > Hi > > I am currently working on kmscon, a user-space VT replacement. In it's > current state, it simply runs a console emulator on a VT but in the > end we want it to fully replace CONFIG_VT. To make it multi-seat > capable I used sd-login.h and it correctly assigns drm-connectors and > input devices to all available seats. However, I have several > questions regarding session management (see below). > > The idea is to have a single process run all the terminals for all > available seats. We listen for new and going seats and correctly > reassign available devices. The user can now use chvt to change > between their xserver, wayland, kmscon or some other VT. That is, if > kmscon is not active on seat0, we drop drmMaster (and other devices) > for seat0 and reqacuire them only when the user switches to kmscon > again. However, all seats are supposed to be independent in respect to > VT management (we eventually want to drop it entirely)! > > 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. > 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. > 3) The idea behind kmscon is to set CONFIG_VT=n (for several different > reasons but mainly to avoid having UI code in the kernel). Does > systemd provide a simple way to replace the VT-switching logic? My > idea was using sd_login_monitor to watch for session changes. If it > changes, I check with sd_session_is_active() whether my session is > still active. If not, I stop using the drm, input, etc. devices and > for instance an xserver can show up. If the user switches to kmscon > again, I am notified via the sd_login_monitor and > sd_session_is_active() will be true again and I can start showing up > again. The interface for switching "VTs"/sessions would then be some > kind of "sd_activate_session" dbus/library call. > However, looking at logind sources it seems the "active" logic is > tightly bound to VTs. I would start working on implementing this, > however, I'd like to get some review on the idea before I spend too > much time in it. 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). Switching between sessions can then be done via dbus calls instead of VT_ACTIVATE on /dev/ttyX. > 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. > I think that's it for the moment. I would be glad if you can help me > out with it. > Regards > David Thanks David _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
