On Wed, Feb 26, 2003 at 10:47:39PM +0000, Andrew C Aitchison wrote: > > 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
Well, it is more like multiple OpenGL X clients and the X drivers themselves. I don't hear of anyone running DRI on fbdev and X alongside each other, and all the stuff is initialized inside the X driver anyway. > can share the hardware, adding another X server should be possible. It is not as simple, since for one chip driving two screens, there are some things that can only be done chip wide, and others that can be done separatedly on each head. Also, i think the DRI only bothers about the 3D engine, not really about things like mode setup and so. And even (onchip) memory management is not (yet) well separated. There is a proposal for DRI about that from Ian Romanick, but it does only concern the DRI, and it is not clear if the OS memory manager can be made to work with it also, or how. > 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, Mmm, there is another discution in the DRI mailing list about dual head with a single framebuffer, where i think RandR could be used to do one the fly head re-organization. But again, i don't really believe that this would help out if we plan to have two separate users, one on each head/seat/whatever. > and I think we would want something (probably fbdev) to share out the > frame-buffer. The fbdev and the drm would work, i think. You would use the fbdev for mode setting and such, and the drm for acceleration, the fbdev has not enough logic for it right now. but again, the fbdev and the drm don't cooperate very well, especially since the drm is initialized from the X driver. > I suppose we could go the other way, and do two seats > within one X server. Is this possible ? Not currently i guess, but it is a feature asked for since some time, for doing cheap terminals, instead of having one cheap box driving one terminal, you would driver two with it, thus almost halving the cost. That said, if one head crashes, the other goes too. > 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. Lot of good questions ... BTW, Dawes, what are the plans for post 4.3.0 XFree86 ? This kind of thing would most assuredly go into the thinking about 5.x, but some of the stuff here, and about the dual-head/one FB (which would allow DRI on dual head cards) could also be implemented in the current setting. Friendly, Sven Luther _______________________________________________ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
