[forum] XFree86 5.0 TODO

[Alan Hourihane]

On Thu, Mar 20, 2003 at 12:41:46 +0100, Sven Luther wrote:
> On Thu, Mar 20, 2003 at 09:57:25AM +0000, Alan Hourihane wrote:
> > Well,
> > 
> > As this forum is for discussing all X stuff, here goes with a few notes
> > from an XFree86 Core Team meeting from a little while back. So in the
> > spirit of openness I thought I should discuss it here.
> > 
> > This is stuff that we can think of that needs doing for XFree86 5.0, but
> > by no means is it limited to this list or even guarantee'ing anything
> > on the list will make it for 5.0.
> > 
> > So, to spark discussions, here it is....
> > 
> > 1. Redesign of XAA, so that multiple depth pixmaps can be stored in offscreen
> > memory and the creation of a new directive - called the XAASurface. There
> > will undoubtably be driver work involved to port to the new interface. The
> > techinical lead on this is Mark Vojkovich. I believe Mark has a substantial
> > portion of this done, if not all.
> 
> Mmm, what would be the benefit of this one ? And how is the hardware
> side taken care of ? For example with graphic cards that don't have
> linear framebuffer, and where the pixmaps need to be converted (either
> in software or in hardware) before they are uploaded to the offscreen
> cache. Such non-linear memory organisation is sensitive to depth
> changes.
 
I'll leave Mark to answer this one.

> > 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.

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.

> > 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. 

> > 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.

> 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.

Alan.