[forum] XFree86 5.0 TODO

[Sven Luther]

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

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

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

Friendly,

Sven Luther