Re: XFree86 5.0 TODO

On Thu, Mar 20, 2003 at 03:21:24 +0100, Sven Luther wrote:
> On Thu, Mar 20, 2003 at 01:12:41PM +0000, Alan Hourihane wrote:
> > > > > > 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.
> 
> This is the static approach, we can already do this, i think, but what

That's what I've already said that we can do this.

> about being able to do dynamic changes ? The idea is to have a
> framebuffer zone we render to (with one XAA, one DRI and so on) and one,
> two or three independenct viewport into this. If you are not able to
> modify these viewports dynamically, you bar the door to features like
> screen mirroring (optionally with scaling) or windows zooming, which the
> matrox windows driver does already for example, and which are usefull,
> for people with sight problems or for doing presentations with a video
> projector for example. But then, you already read my arguments on the
> DRI mailing list, didn't you ?
 
Nope, I must have missed that, but it comes down to framebuffer management
as I've already said. I think I'll contact Ian Romanick to forward his
current document here, regarding framebuffer management though.

> > 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.
> 
> I am not so much interested by different depth, but by having one
> framebuffer of common depth, and be able to have two viewports looking
> into it freely, even overlapping or something such.

It's still framebuffer management.

> > > > > > 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 ? 
> > > 
> > > 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.
> 
> Mmm, i did have a look, and, yes, it use the same kind of trick as you
> implemented in the glint driver for sharing the gamma between both pm3,
> does it not ? There are lot of places where there are checks for
> single/dual head (it doesn't support the parhelia triple head setup, i
> guess), and a refcount thingy to be able to do it only the first time. It
> is the same i have been doing in my new driver, but this is a hack, not
> a clean solution.
> 
> If you look at these drivers, there are 3 phases :
> 
>   probe : you detect the hardware, share the entity, and allocate a pEnt
>   if needed.
> 
>   preinit (a) : you parse the options, do some further chip and memory
>   detection, and load modules. These are all things that can be common
>   on both heads, after all, there is really no reason to detect the
>   memory twice. Mostly this is done by checking the refcount, or using
>   Isprimary or something such.
> 
>   preinit (b) : do some pixclock/mode/dpi settings.
> 
>   screeninit : set the actual video mode (first time we really write to
>   the chip), save the previous state, and do some further
>   initialization.
> 
> It would be neater if we could do :
> 
>   probe : detect the hardware, count the heads.
> 
>   entityinit : the entity is shared by default, we do part (a) of
>   preinit and the rest of the pEnt allocation done in probe currently.
>   We also parse entity level option (from the device section, which is
>   no more shared). We also reserve framebuffer memory for both upcoming
>   heads.
>   Called only one time per entity.
> 
>   preinit (or headinit) : we do part (b) of preinit, all things that are
>   head specific. Here we detect the monitor, do per head
>   clock/modes/whatever stuff, including parsing head specific options.
>   Called once per head.
> 
>   ScreenInit : as usuel, called once per head, viewport information are
>   separated between ingoing size (the framebuffer read) and outgoing
>   size (the real mode), so we can do automatic zooming if the hardware
>   supports it.
> 
> This would allow for cleaner writing of drivers. Sure many of this is
> already possible, but in a hacky way. If we are planing about 5.0, let's
> do this cleanly, and think about it this way.

There's undoubtably some work to be done to clean up the driver interface.

I'm not quite sure I completely understand what your splitting out above,
but if you can base what your thinking on the DESIGN document in
xc/programs/Xserver/hw/xfree86/doc/DESIGN and expand to the level of
detail that exists in this document I could make more comments.

Thanks Sven,

Alan.