On 2011-08-03 19:51, Alex Deucher wrote:
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.
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.
From the user's / administrator's point of view,
I'm still not convinced that we need to isolate kms objects into groups
explicitely and that we need another visible configuration interface
at the kernel level (like a configfs interface) for that.
Multiseat already has too many places to configure:
* xorg.conf (for defining x servers and assigning input devices to them)
* xdm / gdm / kdm / consolekit config (to get things running)
* udev rules (for assigning nice input device names to specific USB ids)
Please don't add another configuration step or interface
if it can be avoided.
All the device and output assignment can easily be expressed
in xorg.conf (as it is already done e.g. for zaphod),
and that's also the place where it belongs:
The information which input devices, which PCI id (or card device)
and output, and which X server number belong to each seat
should be kept together in *one* place.
Based on that information, each X server could allocate
the ressources it was configured for - no need to do that separately.
Of course the kernel has to do some bookkeeping which server
has allocated which outputs: It must prevent that some server
allocats a card or output already taken, and it must take care that
each server only accesses the ressources it has allocated.
But from the user's point of view, there is no need
to explicitely isolate outputs or create separate device nodes
for each output *before* starting the X servers:
I think it's no problem that a server "sees" all outputs
of its card (including those not belonging to him),
only using or reconfiguring them must result in an error
if they have already been taken by some other server.
Klaus.
--
Prof. Dr. Klaus Kusche
Private address: Rainstraße 9/1, 88316 Isny, Germany
+49 7562 6211377 Klaus.Kusche@xxxxxxxxxxxxxxx http://www.computerix.info
Office address: NTA Isny gGmbH, Seidenstraße 12-35, 88316 Isny, Germany
+49 7562 9707 36 kusche@xxxxxxxxxxx http://www.nta-isny.de
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
