[systemd-devel] logind: multiseat without framebuffer graphic cards

[Lennart Poettering]

On Wed, 21.11.12 22:04, Олег Самарин (osamarin68 at gmail.com) 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.