On Wed, 21.11.12 22:04, Олег Самарин ([email protected]) wrote:
> Hi! > > I have a Fedora 17 system with two nvidia videocards, two screens, two > keyboards and two mouses. I've tried to setup multi-seat on it following > this article: > http://code.lexarcana.com/blog/2012/06/17/simple-multiseat-setup-on-fedora-17/. > But > without success. I wasn#t aware of that blog story. I think the second part of it one can just ignore entirely, though. The rules logind write out should be entirely sufficient to put together multi-seat setups. > The article propose to create a new seat by attaching a framebuffer device to > the it: > > Unfortunally, there are no any devices whose path end with /drm/card1 or > /graphics/fb1 in my system ('loginctl seat-status seat0' does not show any). > These paths arrive only after loading the open-source driver > (nouveau), but not with Nvidia proprietary driver. Ahum, we wrote this with modern in-kernel drivers in mind, really. I understand that people want to run this stuff with the closed-source binary drivers, but due to the closed-source-ness this is really not that high on my TODO list and is not as easy to implement as it sounds. > Furthermore, the right way of loading graphic driver is after starting > X-server, not before it. So logind should inform gdm about new seats > before gdm starts X-servers that loads nvidia driver. > > My idea is > 1. make static configuration of videocards and monitors in xorg.conf Actually we have been working on eliminating this entirely. In F18 the xorg.conf files we write are already much shorter, and we actually intended to have them go away entirely already, which will probably happen in F19. > 2. dynamically add inputdevices according to the site udev rules > 3. learn Xorg to select proper ServerLayout section according the -seat > parameter > > I created two patches (one for systemd-44-21) and another for > xorg-x11-server-1.12.3-2) that implemented this idea. These patches really work in the opposite direction we want things to go. We want that X is capable of determine the hw to use from -seat, and from -seat alone with no further configuration. > The first patch - systemd-logind-site-without-graphics - introduces > the new systemd-logind.conf option: SeatWithoutGraphics with default > value "no". But the value "yes" allows logind to create a new seat by > attaching any device for it, not only graphics. Well, but this is dangerous: how do you know when it is the right time to send out the NewSeat bus signal? Note that our start-up is much faster now than it used to be. In fact we will now end up starting gdm at a time where the kernel drivers are not fully initialized yet, so that graphics devices might not have shown up yet. Now, the kernel graphics drivers generally guarantee us that the fb device is the last one that shows up for each graphics card, hence we use he fb device as indication that things are ready now. But if you disable this logic, what do you use instead? Just because a USB mouse happened to have been discovered before any graphics card this really shouldn't mean that we immediately start an X server for it, which will subsequently fail because it couldn't find the graphics card. So, I am really not convinced that this all is desirable. I mean, I understand why you are doing this, but this necessarily introduces races, and is basically just a work-around for a closed-source binary driver from a company that's a big dick towards Open Source. I mean, I am not generally opposed to making changes when we notify the DM that a new seat is available, but I am pretty sure that this global switch is really not what we should be doing. I think there are other ways thinkable, where we don't have to add explicit nvidia-compatibility switches. For example, instead of explicitly watching for fb devices to show up before we consider a seat to be around, we could instead look for devices that are tagged with a special tag ("tag" as in udev's TAG= construct) -- we'd then tag all fb devices out-of-the-box this way, and people who want to use the nvidia binary driver can attach that tag to some kernel device the nvidia driver exposes, but I wouldn't have to care about that, and systemd upstream wouldn't need to know what people do locally. And maybe you could even convince Nvidia to ship the udev rule that attaches this tag in their drivers. By doing things this way we'd not introduce the race that your patch would introduce, but we'd not hardcode anything directly to fb devices. Note that in systemd we generally try to fix this things properly, and not work-around things. Now, your global swicth didn't appear as a "proper fix" to me, due to the race issues. But the solution with a udev tag otoh sounds like a worthwile fix that makes logind cleaner -- and which as a side-effect allows you to integrate things with your nvidia driver. Does that make some sense? Lennart -- Lennart Poettering - Red Hat, Inc. _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
