> > On Wed, 26 Feb 2003, Yitzhak Bar Geva wrote:
> > > What is the status of simultaneous multiple video console operation for
> > > full multiuser X on one machine?

> Dr Andrew C Aitchison wrote:
> > Someone reported that X works with the multi-head console  support
> > in Linux 2.5 kernels.
> > 
> > As far as I am concerned, that is the right way to go:
> > get multi-heads working on the console, then run X on top of that.
 
On Wed, 26 Feb 2003, Sven Luther wrote:
> Does it really work ? With 2.4 multi-headed console, X blanks the second
> head when it launches, even if i don't display anything on the second
> head. I tried tailing the /var/log/XFree86.0.log on it, but to no avail.

I don't know; I'm mostly still running 2.2 kernels !
 
> BTW, i suppose you mean dual head as in one X on one head, and another X
> (with another user, keyboard and mouse) on the second head.

Yes. Perhaps we should can it one "seat".

> How do you imagine this would work when both head are using a
> shared accel (XAA or DRI) engine ?

I thought that the whole point of the kernel DRI was to stop multiple apps
from fighting over the hardware. If the X server and several libGL apps
can share the hardware, adding another X server should be possible.
For it to work nicely the proposed extension to RandR which allows the 
frame-buffer to be re-arranged (remember that we have dropped on the fly
trade off between depth and number of pixels from 4.3) would help,
and I think we would want something (probably fbdev) to share out the 
frame-buffer.

I suppose we could go the other way, and do two seats
within one X server.
I'd want one seat to be called say <machine>:0 and the other <machine>:1
ie listen on two sockets/ports.
This would definitely be a case for two pointers and two sets of focus
(which people seem to want for other reasons).
Would the window scheduling be good enough to ensure that one seat
can't consume all the cycles ?
I'd be particularly worried that information could leak between seat.
Do we use separate threads (or processes) for each seat;
someone recently mentioned that the server isn't thread-safe.
Conceptually I feel that all this should be left to the kernel,
and we should run a separate X server for each seat.

However, I can't do the work, so I'm not going to make rules that
stop anyone doing it the way they find best.

-- 
Dr. Andrew C. Aitchison         Computer Officer, DPMMS, Cambridge
[EMAIL PROTECTED]       http://www.dpmms.cam.ac.uk/~werdna

_______________________________________________
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel

Reply via email to