On Mon, Aug 1, 2011 at 3:41 PM, Prof. Dr. Klaus Kusche <klaus.kusche@xxxxxxxxxxxxxxx> wrote: > 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. You almost always have more connectors than display controllers (e.g., you might have displayport, svideo, DVI-I and VGA, but only two display controllers so you can only use two of the connectors at any time). Also certain combinations of connectors are not possible depending on the hw (e.g., the svideo and the VGA port may share the same DAC, so you can only use one or the other at the same time). Alex _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
