On 2011-07-31 22:09, Dave Airlie wrote:
There once was a patch to allow one X server per graphics card
output:
http://www.facebook.com/note.php?note_id=110388492307351
http://people.freedesktop.org/~airlied/multiseat/
However, this patch never made it to mainline
and no longer applies cleanly.
Now the question is:
* Are there any plans or activities to port these patches
to recent kernels? To include these patches or something similar
in the official linux kernel any time soon?
Nothing in my plans, I did a proof of concept to show how someone
should do things, I'd sort of hoped some of the people who dedicate
time to fixing multiseat and cared about it would pick things up and
run with them, it really does need a proper ioctl or configfs
configuration interface since any static setup will invariable be
wrong for 50% of people, and any kernel commandline interface will
invariably be ugly and complex in order to solve the problem.
I could envisage some sort of configfs where you echo 5> num_seats
then echo VGA-1> seat1, etc.
Then you could just write some scripts per machine if you don't want
gdm/consolekit support.
Hmmm, what's about the opposite approach?
To me, it sounds simpler and more logical when the kernel always creates
one device node per output (or maybe dynamically per connected output),
without any need for configuration or device assignment.
If a single X server wants to control several outputs,
libdrm should open the corresponding number of devices in parallel.
We already have both static X configuration and xrandr for configuring
that, and if the devices allow only a single open,
this would also arbitrate outputs between servers
(a server can't open an output which is already taken).
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
