[forum] XFree86 5.0 TODO

[Alan Hourihane]

On Thu, Mar 20, 2003 at 01:53:51 +0100, Sven Luther wrote:
> On Thu, Mar 20, 2003 at 12:36:28PM +0000, Alan Hourihane wrote:
> > > > 2. FBManager extensions. This still needs furthur thought to encompass
> > > > the requirements of all bases, but, the DRI is one that needs much more
> > > > flexible memory management of the framebuffer. Secondly, it's been 
> > > > requested before for linear allocation, rather than the current area 
> > > > allocation code for some Xv implementations.
> > > 
> > > Will this be X centric, or will we be able to share this framework with
> > > the fbdev or other graphic hardware accessing stuff ? If i understood it
> > > right, the DRI wanted to move most of this in the drm kernel module, no ?
> >  
> > We're in the X development forums, so I can see it being X centric.
> 
> Well, the discution yes, but the solution may be more generic, no ?
 
Potentially.

> > As for the DRI team wanting to move framebuffer allocation into the kernel -
> > they have a document about it which probably should be repeated here.
> 
> Yes, ...
> 
> > > > 5. RandR. We now have rotation support, but not depth switching yet. This
> > > > still needs to be done.
> > > 
> > > I personally am interested in dual/multi-head, and flexible
> > > configuration of viewports into a common framebuffer. I am not familiar
> > > with RandR, but i think it could be extended to allow dynamical head
> > > configuration or windows-zooming or other such functionality.
> > 
> > I think multihead in a common framebuffer is doable in the current
> > infrastructure. 
> 
> You are saying that it should be possible to use RandR to switch the
> viewport of both heads dynamically, like we change resolutions today ?
 
I'm not thinking RandR here. More a static approach by splitting the framebuffer
up into two portions, one for use as though it's an independent card.
Then XAA can share the graphics accelerator to write to both regions. I
understand this is the way of the mga driver that does it now. There'd
be a need for better framebuffer management to support depth switching for RandR
in this environment, which comes back to point 2.

> > > > 7. Hot Plugging of devices. Displays, Keyboards, Mice. This is obviously
> > > > tricky when running multiple Xservers on the same machine. How do you
> > > > correlate which device is plugged in, to which Xserver etc. 
> > > 
> > > The display part at least is related to what i mention above.
> > > 
> > > > 8. Multiseat capability. Allowing multiple Xservers to run with independent
> > > > graphics cards, keyboards and mice on the same machine.
> > > 
> > > What about running multiple seats on the different heads of a same video
> > > chip ? You exclude that here, but with a common low level hw access and
> > > management layer (like the dma buffers of the DRI) i think it can be
> > > done. It may cause security concerns and such though.
> >  
> > I'm not excluding anything. This is just to open up discussions. The above
> > seems to relate to a question you had furthur back in the message regarding
> > multihead in a common framebuffer. As I've said, multihead in a common
> > framebuffer should be doable in the current infrastructure, but multiseat
> > in that environment suffers the same problems as with multiple graphics
> > cards. The current issue, is the OS. As for Linux, we know the 2.5 kernel
> > will be able to support concurrent VT's, so we'll need to take advantage
> > of that. As for other OS'es, we'll need to figure out details. If there
> > are others out there with knowledge on the other OS'es I'd welcome their
> > thoughts here.
> 
> Ok, ...
> 
> BTW, when the X server dies for whatever reason, it would take both
> seats with him, right ?
 
Right.

> > > Anyway, for dual/multi-head on single graphic cards that support it, i
> > > would like to have us separate more the part related to the graphic chip
> > > from the part related to the output heads. Current multi-headed
> > > solutions (on the same chip) use a chip sharing trick, and the pEnt to
> > > store common information, but we could make this more formal, at least
> > > at the device driver level, and have things like preinit and part of the
> > > screeninit be done one time only for the entity, and then have multiple
> > > calls to modeinit for setting the viewports, the zooming, the
> > > outgoing resolution, the ddc info on the attached monitor and so on done
> > > per head.
> > 
> > multihead on a common framebuffer is obviously chip specific, so a lot
> > of the details are specific to a driver. Again, for this, it should be
> > doable now.
> 
> Yes, but not easily. The way i would do it currently is to set a virtual
> size that is the sum of both heads and inform the driver that the
> framebuffer is shared somehow. This would need the user to setup things.
> Another way of doing this is, in the driver, to wait that the
> information about both heads mode are given to the driver, and then sum
> them up and do a the framebuffer allocation then. This could be done in
> preinit, i think, but again, you would need to get access to the other
> head's framebuffer layout information and modify it, which is not the
> cleanest thing to do. If we are going to rework things, we could as well
> clean this up, no ?

Take a closer look at the mga driver.

Alan.