On Thu, 23 May 2002 [EMAIL PROTECTED] wrote: > I think a better way would be to use only one instance of XFree, have > it handle multiple monitors (that already works just fine!) WITHOUT > Xinerama, and add more event queues, each for one screen/user. And of > course, add support for multiple (USB) keyboards (at least two > solutions exist) and multiple mice with one cursor each. > > > 2) You could not go through the kernel and instead attempt to access the video > > card manually or through the frame buffer or something smart - and some has > > done this, and posted various patches.. although that still only allows a > > max of two heads. > > I don't quite understand what you mean by this, but again - I don't > think this is the problem, multi-head support is already working. > (Maybe not for all cards, though.) > > > 3) You could use something like Xinerama (sp?) to have one desktop but over > > multiple monitors. > > That's not what I want - I want multiple independent desktops. > > > 4) You can have more than one mouse, but currently you can't have more than > > one cursor on a particular X server. > > Right - this would have to be changed. > > > I think this is because of a limitation > > in the actual X protocol - if so, don't expect this to be fixed any time soon > > either. > > I don't think the X protocol has anything to do with it. Isn't the > multi-screen support much like two independent X servers already? How > closely coupled are screens :0.0 and :0.1?
For events, they are very closely coupled. As I understand it the point is that :0.0 and :0.1 are intended to be used by one user, however many keyboards and mice they may be using. :0 and :1 are intended to indicate separate user stations, and the most obvious way of doing that is separate X server processes. > The protocol is the interface between the client and the server, and > in that respect, I don't propose any change: the client would still > be seeing only one cursor, but depending on which screen it is > attached to, it would be one of the existing cursors. With one server instance (process) running 2 user stations, we would need chinese walls to ensure that my cursor could never wander onto your screen. If it could I could cut and paste your text, type in your windows, and all security would be gone. It seems the 2 X instances/processes is the right answer here. While I admit that it *might* turn out to be easier to build the chinese walls than fix the crashes when two processes are trying to talk to hardware at the same time, both DRI and the kernel framebuffers appear to be sensible approaches to solving that problem. -- Dr. Andrew C. Aitchison Computer Officer, DPMMS, Cambridge [EMAIL PROTECTED] http://www.dpmms.cam.ac.uk/~werdna _______________________________________________ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
