[Feature request] Multiple X servers on one graphics card?

[Alex Deucher]

On Tue, Aug 2, 2011 at 3:11 PM, Prof. Dr. Klaus Kusche
<klaus.kusche at computerix.info> wrote:
>>
>> Some drivers can already do this (the radeon driver at least).  google
>> for zaphod mode.  You basically start one instance of the driver for
>> each display controller and then assign which randr outputs are used
>> by each instance of the driver.  It already works and supports
>> acceleration.  The problem is, each instance shows up as an X protocol
>> screen rather than a separate X server so, you'd have to fix the input
>> side.
>
> Hmmmm...
> * Zaphod seems to have even fewer active users and less future/support
> than Xephyr, so putting work into it doesn't seem to be a future-proof
> investment.
> * It would be of interest only if it were possible to configure two
> zaphod drivers assigned to two different outputs (but the same PCI Id!)
> in two *different* X servers, but I'm quite sure that's not supported...
>
>>> I also believe and accept that there will be no solution
>>> supporting all graphics cards existing today and 10 years back.
>>> Only some cards offer KMS, only some cards offer 3D acceleration,
>>> some older cards don't even offer dual-screen support for one X server,
>>> only some cards will offer multi-seat support in future.
>>> If somebody wants to build a high-density shared-card multiseat system,
>>> he has to choose suitable hardware.
>>
>> Even if you only support KMS supported hardware which seems reasonable
>> to me, you still have a lot of cards out there with interesting
>> display configurations.  We still make cards with DVI and VGA ports on
>> them or more connectors than display controllers.  You don't really
>> want to go through the whole effort if it only works on a handful of
>> special cards.  It wouldn't take that much more work to come up with
>> something suitable for the majority of hardware that is out there.  In
>> most cases, it will probably be a custom configuration for each
>> person, so as long as the right knobs are there, you can configure
>> something that works for your particular system.
>
> Any idea what "something suitable" could be?
> What the missing "right knobs" are?

Some way to assign a certain set of KMS objects (crtcs and
encoders/connectors) to a particular client.

>
> Back to the beginning of the discussion:
> The primary interest is not how to configure outputs.
> xrandr already does that, and that should be used, not duplicated.
> We only want what xrandr is able to do today (at most), not more.
> However, we want it for more than one X server.

You don't really want xrandr.  You want some way to isolate a group of
KMS objects.  You can write a client that uses the KMS ioctls to
configure the the display hardware.  That's what the ddx does right
now with kms drivers.  I think you'd want to add some knobs (in sysfs
or configfs maybe) that lets you limit which KMS objects are exposed
to a particular client.

>
> The central question is:
> How do two or more X servers share access to a single graphics engine?

This is already possible.  For rendering the client only needs to
allocate buffers via the drm memory management ioctls and then submit
command buffers that act on those buffers.  For things like direct
rendering, the dri2 protocol provides the way for the ddx and 3d
driver to share buffers via the drm.

> The second question is:
> How do xrandr outputs get assigned to X servers such that each server
> gets exclusive access to its outputs?

Right now it queries the ddx queries the drm using the kms modesetting
ioctls and gets a list of all the KMS display objects.  The DDX then
parses that list and provides a translation layer for xrandr.

> And the third item on the todo list is perhaps tightening security
> and server/user separation...

The drm already provides this for the most part.  Things could get
tricky if we ever add support for sharing buffers between drms.

>
> Airlied's prototype implementation was a working demonstration
> for the first item (just for radeon).
> His suggestion for the second question was purely kernel-based
> (using configfs). If I understood it correctly:
> * For each card, first configure the number of DRM devices
> you want to have (one per X server).
> * Then, assign xrandr outputs to these devices.
>
> This way, each X server opening its render device should only "see"
> the outputs assigned to this device.
>
> Is this agreed?

Seems like the best approach to me.

> Any alternatives?
>
> Basically, I think multiseat configurations will be static in most
> cases - after all, a multiseat configuration usually has
> quite a cabling mess, with a fixed number of monitors,
> each having a keyboard and mouse, which are statically mapped
> to fixed evdev devices using udev. Re-cabling is an effort anyway,
> so editing a config file in this case would be acceptable (after all,
> most existing multi-Xephyr solutions are also statically configured).
> Hence several xorg.conf selected with -config or one large xorg.conf
> with several layouts selected by -layout will suffice,
> each specifying input devices, a graphics card and an xrandr output
> similar to zaphod mode.
>
> So what would be needed to make that work?

Some way to associate a limited set of KMS display objects with a
particular drm device.

>
> If someone wants dynamic configuration without xorg.conf,
> I think the only thing needed is some bookkeeping in the kernel
> which server is using which xrandr output:
> * If a server is started without specific configuration,
> it just grabs the next available output
> (or all unused outputs on that card?).
> * If a server activates an unused output, this output should
> be assigned to him exclusively until disabled.
> * If a server tries to activate an output already in use by
> another server, it should get an error.
> * If a server disables an output, this output becomes available
> to other servers.
>
> What would be needed for that? Is the information about enabled
> and disabled outputs currently stored in the kernel or in userland?

All of that information is stored in the kernel.  You don't need X at
all.  The ddx basically just provides a translation layer between KMS
and xrandr, provides acceleration for render and core X and sets up
shared buffers for 3D rendering.

Alex