Created attachment 747787 [details] Custom xorg.conf for SM501 PCI graphics card Description of problem: My multiseat setup consists of an on-board Intel graphics chip, a Silicon Motion SM501 PCI graphics card (no framebuffer device available; configurable via DDX driver only), and a pair of USB hubs with audio (declared as seat master devices in /etc/udev/rules.d). I'm trying to setup multiseat in Fedora 18 (KDE spin) so that my Intel chip is my primary graphics device (i.e., assigned to seat0) and my SM501 graphics card is assigned to another seat via custom xorg.conf/kdmrc (e.g. seat1). However, every time I configure my system to assign my SM501 card with seat1, my X server fails to start, returning a "No devices detected" error. Nevertheless, when I assign my SM501 card with seat0 and attach my Intel graphics device to seat1 (via loginctl), both seats load successfully. Version-Release number of selected component (if applicable): systemd: 197-1.fc18.2 kdm: 4.10.2-8.fc18 xorg-X11-server-Xorg: 1.13.3-3.fc18 How reproducible: Completely reproducible Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Created attachment 747799 [details] Custom kdmrc (success case)
Created attachment 747800 [details] Custom kdmrc (fail case)
Created attachment 747801 [details] Xorg log for SM501 (success case)
Created attachment 747802 [details] Xorg log for SM501 (fail case)
Created attachment 747803 [details] Output of "loginctl seat-status seat0" (success case)
Created attachment 747804 [details] Output of "loginctl seat-status seat0" (fail case)
Created attachment 747805 [details] Output of "loginctl seat-status seat1" (success case)
Created attachment 747806 [details] Output of "loginctl seat-status seat1" (fail case)
Not sure if this is a X server bug, a system bug, or even a siliconmotion DDX bug.
As you can see in my custom kdmrc, I'm not using systemd-multiseat-x wrapper.
I've finally solved my problem. It's all about "platform bus" support in latest Xorg server. I don't know what is it, but whatever it means, the current siliconmotion DDX doesn't implement it. In the current Xorg packages for Fedora 18, for non-seat0 devices, the X server only probes platform bus devices, so I've patched it to go further with "lecagy" PCI devices probe when no platform bus device is found.
Created attachment 751266 [details] Xorg patch to go further with PCI probe for when seat is other than seat0, and no platform bus device is found.
Might this be related? https://bugzilla.redhat.com/show_bug.cgi?id=878605
Oli, Sort of. In fact, my SM501 graphics card exposes no kernel device interface to loginctl (I'm not using kernel module sm501fb), so it can't be set as a seat master device. This was the same problem Oleg Samarin has described in https://bugzilla.redhat.com/show_bug.cgi?id=878605. The discussion about that bug has evolved in systemd-devel mailing list, culminating in the introduction of "seat-master" udev tag in upstream v197 (and replaced with "master-of-seat" in v198 and later). With this new feature, I can tag my USB hub as the master device of my secondary seat, and assign my SM501 card to it via custom xorg.conf file. However, the problem I describe here is not related to systemd-logind, but with X.Org itself. Currently, X.Org only probes graphics devices that implement "platform bus" for non-seat0 seats (seat0, by default, also probes "legacy" PCI bus). I don't know what "platform bus" really means, but I guess it may be related to DRM/KMS. My card, with siliconmotion DDX, implements no "platform bus" interface, so it can't be reached by X.Org in its current form, unless it's assigned to seat0. With the patch I propose here, X.Org can go further with "legacy" PCI bus probe also for non-seat0 seats, so it can find my SM501 card assigned to my secondary seat.
Thanks for your reply! I seem to be missing some step that is not immediately obvious; having tagged my graphics card (or hub) as master, the secondary Xorg never manages to start with the same error as you describe - "(EE) No devices detected. / Fatal server error: no screens found". I made up some xorg.conf assignment into a file in the xorg.conf.d folder, but it is not clear that it is being read, since the automatic multiseat seems to use a config file in /var/run. The Xorg.log file suggests that it always tries to activate screen0 and never screen1 (the latter being assigned to seat1). I managed to see output on screen1 (but not screen0), if I swapped the order of those sections in the config file; it seems that in the absence of any seat directive then it will load the first one it finds. I think I was also able to run an X server manually with the "-layout" parameter. Do you know if there is some assumed naming convention for the xorg config file, or else if it is better to use a custom gdm config instead of the automatic multiseat?
Created attachment 764676 [details] Append custom xorg.conf to /run/systemd/multi-session-x/seatXXXX Allows to append custom xorg.conf to /run/systemd/multi-session-x/seatXXXX If the display manager allows X server command line customization, the custom xorg.conf can be passed to systemd-multi-seat-x "-config" option. Otherwise (as with GDM), rename your custom xorg.conf to /etc/X11/xorg.conf.__seatXXXX__, where seatXXXX must be replaced with your seat id, and systemd-multi-seat-x wrapper will find it.
Oli, In fact, systemd-multi-seat-x wrapper loads an automatically generated xorg.conf file named /run/systemd/multi-session-x/seatXXXX, where seatXXXX is your seat id. Every file you put in directory xorg.conf.d is read after /run/systemd/multi-session-x/seatXXXX, but it's applied for all seats, which can be an inconvenient. My last patch to systemd-multi-seat-x wrapper (see above) allows you to append your custom xorg.conf file to /run/systemd/multi-session-x/seatXXXX, so your custom changes will only be applied to that seat.
Thanks for your input! If I append lines to /run/systemd/multi-session-x/seat1 then they simply disappear after init3/init5. If I put config in xorg.conf.d then both seat0 and seat1 go for the same screen/layout and one fails. I feel that I am so close and according to the other ticket it should work, but without your patch above it is not clear how/where I can specify the config in a way that will be read by the Xorg.
Well... multiseat support in Fedora/GNOME/Systemd was originally intended for Plugable devices and other modern video cards with open source drivers that implement DRM/KMS interface, which don't need any extra xorg.conf. That's why is so tricky to add support to other video cards with old drivers or proprietary drivers only, which need custom xorg.conf. The only way to configure your system without any patched package is to pass an option -layout, with the value corresponding to the "ServerLayout" section of your custom xorg.conf, to your X server command line from your display manager. Unfortunately, the only fully multiseat-compliant display manager in the market, GDM, does not support X server command line customization. There is some work in progress to improve multiseat support in KDM, which you can follow in these threads: https://bugzilla.redhat.com/show_bug.cgi?id=884271 https://bugzilla.redhat.com/show_bug.cgi?id=975079 https://bugzilla.novell.com/show_bug.cgi?id=809806
(In reply to Laercio de Sousa from comment #11) > I've finally solved my problem. It's all about "platform bus" support in > latest Xorg server. I don't know what is it, but whatever it means, the > current siliconmotion DDX doesn't implement it. In the current Xorg packages > for Fedora 18, for non-seat0 devices, the X server only probes platform bus > devices, so I've patched it to go further with "lecagy" PCI devices probe > when no platform bus device is found. Laercio, you are a genius! I've been struggling with MultiSeat using the proprietary drivers for days and could only ever manage to get Seat0 working. The platform bus patch you posted works great and immediately got everything working. I also used your systemd-multiseat-x patch to allow the xorg.conf.__seat1__ etc. files to load to make things much easier. Thank you very much! I didn't spend much time looking over the code but it seems the offending code is actually below. Looking at the comment, it seems they always match the first device in non-seat0 scenarios. For the binary nvidia driver, this definitely isn't the case. I didn't look entirely through the code, but it seems like the devices aren't marked as "claimed" in the xf86MatchDevice function, so all nvidia devices are returned and only the first is ever checked. I haven't tested it, but its possible if we just eliminate the "if (ServerIsNotSeat0()) break; lines your other patch wouldn't be needed. It would be nice to know if that "assumption" was there for a good reason other than speeding up device enumeration. /hw/xfree86/common/xf86platformBus.c xf86platformProbeDev(DriverPtr drvp) { Bool foundScreen = FALSE; GDevPtr *devList; const unsigned numDevs = xf86MatchDevice(drvp->driverName, &devList); int i, j; /* find the main device or any device specificed in xorg.conf */ for (i = 0; i < numDevs; i++) { for (j = 0; j < xf86_num_platform_devices; j++) { if (devList[i]->busID && *devList[i]->busID) { if (xf86PlatformDeviceCheckBusID(&xf86_platform_devices[j], devList[i]->busID)) break; } else { /* for non-seat0 servers assume first device is the master */ if (ServerIsNotSeat0()) break;
I've openened the same bug in upstream: https://bugs.freedesktop.org/show_bug.cgi?id=66851
Thanks for the detailed information Laercio! For now I have given up and switched to ATI graphics.
This message is a reminder that Fedora 18 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 18. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '18'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 18's end of life. Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 18 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior to Fedora 18's end of life. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 18 changed to end-of-life (EOL) status on 2014-01-14. Fedora 18 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.
I'm reopening this bug, with some updates. As you may know, since version 198, systemd-logind no longer requires a framebuffer device to create a new seat (it's sufficient to assing at least one suitable device tagged as "master-of-seat" in udev to a new seat in order to create it). It opens the possibility to configure multiseat properly using multiple graphics cards with non-KMS drivers (like NVIDIA proprietary ones). However, some fixes in Xorg server are still needed to make it start properly with a non-KMS video driver if an option "-seat seatXXXX", where "seatXXXX" is not "seat0", is passed. Oleg Samarin and I are proposing the following patches for Xorg uptream: xfree86: allow fallback to PCI bus probe for graphics devices on non-seat0 X servers (the same patch attached above) http://lists.x.org/archives/xorg-devel/2014-April/041691.html NOTE: Hans de Goede and Dave Airlie already have given some feedback about this patch, but it's not included in any pull-req to Keith Packard, yet. xfree86: add new key MatchSeat to xorg.conf sections "Device", "Screen", and "ServerLayout" http://lists.x.org/archives/xorg-devel/2014-April/041692.html NOTE: This patch is needed if you want to provide a completely DM-independent solution. Without it, you need to write a separate xorg.conf.custom file and pass it to X server via "-config" option, if you want that these settings only apply for the right seat. However, in some cases, this solution is undesirable or even impossible (e.g. when using GDM, which doesn't allow X server command line customization). xfree86: add short description about MatchSeat key in xorg.conf man page http://lists.x.org/archives/xorg-devel/2014-April/041693.html
Fixed in upstream: http://cgit.freedesktop.org/xorg/xserver/commit/?id=29b1484bb9555e45067669cbfe68a3c40596f4ff http://cgit.freedesktop.org/xorg/xserver/commit/?id=7070ebeebaca1b51f8a2801989120784a1c374ae http://cgit.freedesktop.org/xorg/xserver/commit/?id=a6f5ffd5879e7fb052d343592951cc476b699bb4 http://cgit.freedesktop.org/xorg/xserver/commit/?id=fb24ac0a2c317099bdf7d1d8e4b7c443e3ee644f
This bug appears to have been reported against 'rawhide' during the Fedora 22 development cycle. Changing version to '22'. More information and reason for this action is here: https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora22
Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.