Description of problem: Multiseat system with kdm, hardware assigned to seat0 and seat1 using loginctl. user1 logs into seat0 and user2 logs into seat1 executing loginctl gives: # loginctl SESSION UID USER SEAT 1 500 user1 seat0 2 503 user2 seat0 2 sessions listed. Note: both users show up on seat0 according to loginctl. Expected: user2/session 2 should show seat1. # loginctl show-session 1 Id=1 Timestamp=Sat, 01 Dec 2012 22:38:43 +0000 TimestampMonotonic=41138110 DefaultControlGroup=name=systemd:/user/user1/1 VTNr=1 Display=:0 Remote=no Service=kdm-np Leader=1474 Audit=1 Type=x11 Class=user Active=yes State=active KillProcesses=no IdleHint=no IdleSinceHint=1354714190785587 IdleSinceHintMonotonic=312708073970 Name=user1 # loginctl show-session 2 Id=2 Timestamp=Sat, 01 Dec 2012 22:40:03 +0000 TimestampMonotonic=121036199 DefaultControlGroup=name=systemd:/user/user2/2 VTNr=2 Display=:1 Remote=no Service=kdm Leader=1457 Audit=2 Type=x11 Class=user Active=no State=online KillProcesses=no IdleHint=no IdleSinceHint=1354732023233043 IdleSinceHintMonotonic=330540521427 Name=user2 Note: user2 on seat1 shows up as inactive. Expected: session should show active Version-Release number of selected component (if applicable): Fedora 17 systemd: 44 kdm: 4.9.3 Additional info: xdmrc relevant sections: [X-:0-Core] ServerArgsLocal=-nolisten tcp -seat seat0 -novtswitch -isolateDevice PCI:0:2:0 [X-:1-Core] ServerArgsLocal=-nolisten tcp -seat seat1 -sharevts -isolateDevice PCI:1:0:0 -config xorg.seat1.conf contents of xorg.seat1.conf: Section "Device" Identifier "ATI" Driver "radeon" BusID "PCI:1:0:0" EndSection Section "ServerFlags" Option "AutoAddDevices" "True" Option "AllowEmptyInput" "True" Option "DontVTSwitch" "True" EndSection Section "InputClass" Identifier "Force Input Devices to Seat" Option "GrabDevice" "True" EndSection Let me know if you'd like to see the hardware configuration or loginctl seat-status, I'm not sure if they're relevant. Additional info: Sound doesn't work for user logged into seat1 and I suspect that it's related to the above discrepancies reported by loginctl. (I apologize for any mistakes I made here, this is my first bug report.)
kdm is not multi-seat aware using logind's/systemd's automatic multi-seat scheme: http://www.freedesktop.org/wiki/Software/systemd/multiseat Please use gdm if you want multi-seat work properly and automatically and consistently with logind/loginctl. Will reassign this to kdm now. (However, talking to KDE folks it appears that they think lightdm is more likely the future of DMs for KDE than KDM. However, neither supports automatic multi-seat afaik.)
Hi, I think you should specify the systemd wrapper for X in the config, too - add this line to the [X-*-Core] or both the sections you listed: ServerCmd=/usr/lib/systemd/systemd-multi-seat-x Reason to do this is here: http://www.freedesktop.org/wiki/Software/systemd/writing-display-managers in step 5 of the complete porting section. Please let me know if it helps. I'm currently playing with multiseat in KDM and trying to implement the automatic detection of new seats added/removed but this should theoretically work even without it. Thank you
Oh, I'm sorry, I just realized you're not using a USB graphics card. Then it seems bugged in this way, too.
The problem you're describing lies in your configuration. Loginctl sees only its own sessions and what you are using is defined by yourself regardless of seats in it. You can create a new seat using loginctl and assigning the hardware to it. It won't make multi-seat possible yet, but it will soon. I worked on a patch making automatic multi-seat possible in KDM. Now I'm able to spawn new greeters with it. For some reason, it takes forever to log in with the changes so I'm hunting the bug now but when I'm done, I'll post the patch.
I've just pushed support for systemd automatic multi-seat into rawhide: http://lists.fedoraproject.org/pipermail/scm-commits/Week-of-Mon-20130408/997808.html http://lists.fedoraproject.org/pipermail/scm-commits/Week-of-Mon-20130408/997836.html The packages are currently being built: http://koji.fedoraproject.org/koji/taskinfo?taskID=5242589 http://koji.fedoraproject.org/koji/taskinfo?taskID=5242705 We'll submit it to the previous Fedora releases eventually if there are no problems with it. However, this doesn't solve your problem. You have to create the seats first to be able to use them by the loginctl command. Then, KDM should detect them on startup. I'm closing the bug as fixed in rawhide. If you'll still find the support as problematic or find other issues, please feel free to reopen the bug or open a new one. Thank you.
Does kdm handle correctly the environment variables XDG_SEAT and XDG_VTNR at this point, or another patch is still needed? In this last case, is there any workaround for setting XDG_SEAT/XDG_VTNR while kdm doesn't get proper support?
Hi Laercio, KDM doesn't handle these variables correctly at this time. However, they are set on login automatically anyway. The problem here is, KDM doesn't provide a very convenient backend environment for writing such functionality, so it's using Reserve VTs those have to be allocated in the configuration file before even starting KDM. And it's sort of a opt-in currently, as I had to remove the systemd X wrapper from the ServerCmd option in /etc/kde/kdm/kdmrc to avoid potential errors. I have a patch with this added into the C source, which I'll push this week. If you don't want to wait for it, please set ServerCmd=/usr/lib/systemd/systemd-multi-seat-x in the [X-:*-Core] section of the KDM configuration file, then after restarting KDM, you should be able to use the automatic multi-seat functionality.
Hi Martin, I already use ServerCmd=/usr/lib/systemd/systemd-multi-seat-x in my kdmrc. My multiseat setup is that of https://bugzilla.redhat.com/show_bug.cgi?id=962907, and it works minimally, as long as I pass explicitly the -seat option in kdmrc, e.g. [X-:0-Core] ServerArgsLocal=-seat seat0 ... [X-:1-Core] ServerArgsLocal=-seat seat1 ... However, the output of loginctl command in my system looks strange: # loginctl SESSION UID USER SEAT 2 1001 user1 <-- Should be seat0 1 1002 user2 seat0 <-- Should be seat1 In fact, in session 2 (user1 logged in seat0), the variables XDG_SEAT and XDG_VTNR are not set at all, while in session 1 (user2 logged in seat1), these variables are set with the wrong values. This strange behavior has implications in audio output and pendrive input for each seat. Should I open another bug for that? BTW, are you following the logind support development in LightDM? It seems that minimal (no multiseat) support is already commited by upstream.
Well, I'm not entirely sure what the problem on your machine is. I'm pretty sure the XDG_SEAT and XDG_VTNR environment variables aren't that much important. You can in fact start another seat in KDM even without my patch, using the way you're describing in Bug 962907. This is of course valid assuming there are no issues elsewhere - I'm speaking about how it works with the Plugable terminal, as it seems you're using a system with multiple graphics cards which is a bit different case. In all cases, you have to use the wrapper provided by systemd, of course. Using something simple like: /usr/lib/systemd/systemd-multi-seat-x :8 -seat seat1 should create a new screen on the second seat. If this works with clean system (I'm afraid I can't help you if you have patched your X server), we can debug KDM further. From what I've seen in the other report, it seems the SM card isn't detected by udev and isn't assigned to any of the seats. This could be cause of the missing seat name, too. And yes, I know of the work being in progress in LightDM, it's all because Ubuntu will be switching to systemd-logind in one of the upcoming releases. However, personally I like SDDM ( https://github.com/sddm/sddm ) as a KDM substitution much better. I'm trying to add some missing (not really popular, such as XDMCP) features in my free time to it, too, but it's progressing really slow as free time is a rare commodity these days. :) Disregard that, adding multiseat support to it should be much easier than in the KDM case.
Martin, Yes, my SM501 card exposes no framebuffer device interface to logind, since I failed to use the sm501fb kernel module with X.Org fbdev driver, so it can't be attached directly by loginctl. This is the same situation one would have with a NVIDIA card with proprietary drivers, which motivated Oleg Samarin to start a discussion in systemd-devel mailing list culminating in "seat-master" udev-tag concept being introduced in systemd 197 (replaced with "master-of-seat" in v198). Since my SM501 card can't be attached by logind, I have tagged my USB hub as "master-of-seat" in order to create seat1. In my case, the main problem with systemd-multi-seat-x wrapper is that I can't pass a custom xorg.conf file (with my SM501 config) to it via -config option. As a workaround, I need to patch X.Org with Samarin's patch that adds Option "Seat" in xorg.conf's "ServerLayout" Section, and then put my SM501 config in /etc/X11/xorg.conf.d/ directory. Maybe I could patch systemd-multi-seat-x wrapper so it can receive my custom xorg.conf file and append it to its automatically generated config file /run/systemd/multi-session-x/seat1. I could set up my multiseat system in a clean environment, provided that: 1. I attach my Intel video device to seat1 via loginctl and use my SM501 card with seat0. 2. I set TerminateServer=false in kdmrc. 3. I DON'T use systemd-multi-seat-x wrapper 4. I explicitly pass my xorg.conf.sm501 file to X via -config option. Example: [X-:0-Core] ServerArgsLocal=-background none -nolisten tcp -seat seat1 [X-:1-Core] ServerArgsLocal=-background none -nolisten tcp -seat seat0 -config xorg.conf.sm501 -sharevts -novtswitch I've already did it, and got the same frustrating result in loginctl command output. Just for comparison, in a Fedora GNOME installation (and patched X.Org with Samarin's patch), I don't have that strange behaviour in loginctl command output: # loginctl SESSION UID USER SEAT 1 1001 user1 seat0 2 1002 user2 seat1 but sometimes I've got an inactive session for user logged in seat0 (not reproducible). However, when I swap the video devices (Intel goes with seat1, SM501 goes with seat0), this problem disappears, and I get active sessions for both seats, as expected. Unfortunately, my SM501 card is too weak to load GNOME Shell properly, so I'm working with KDE.
Thank you for the detailed description of the situation. Now I see why it's not set on your installation. Unfortunately, I'm not really inclined to fixing KDM any further, nor add new features to it. However, if we won't be able to find another solution, I'll try to fix it for you. Now, please, try using GDM to log into your sessions instead of KDM. You can achieve this by installing gdm package and running "systemctl disable kdm.service; systemctl enable gdm.service". The display manager itself isn't bound to any particular desktop environment or window manager so it should work just fine.
Thank you Martin. I'm switching to GDM for now. Unfortunately, per-seat auto/timed login doesn't seem to work on GDM 3.6 (it only works for the first seat). I'm still getting a strange behaviour in GDM with my multiseat setup: my seat0 randomly gives inactive sessions, while my seat1 always give active ones. A "loginctl show-session <id-of-session-for-seat0>" returns "VTNr=0" and "Active=no", while the same command for seat1 returns "VTNr=0" and "Active=yes". If I unplug my USB hub (master of seat1), reboot the computer, and replug my hub after GDM is running, I get "VTNr=1" and "Active=yes" for seat0, and "VTNr=0" and "Active=1" for seat1. It seems that VTNr=0 for seat0 is bad, right? I suspect that, due to some "race condition" between both seats at boot, I get a bad VTNr for seat0. P.S.: Sorry for going away from the scope of this bug report. Should I open another one?
Hi Laercio, this indeed does seem like a bug somewhere else and yes, you should open a new report for this. Even if it's not a bug, you'll get information from people who understand the topic more than I do. By the way, as per Bug 975079, I'll add the missing variables you mentioned earlier and fix some other issues which Stefan found to KDM so it should be a bit more usable soon.