[forum] XFree86 5.0 TODO

[Sven Luther]

On Thu, Mar 20, 2003 at 03:04:03PM +0000, Alan Hourihane wrote:
> 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.

Here goes a first draft, i hope that is what you have in mind.

...

5.8 Video Driver Probe

  Here we restrict ourself to doing an hardware probe, like is said in the
  DESIGN document. There will be only one device section corresponding to the
  chip and it will be shared by default. xf86MatchDevice use the device
  section, right, not the screen one ?

  The current DESIGN document also allocates a screeninforec for each device,
  and partially fills it. This is needed so we know which PreInit to call. I
  am not sure about how this work, but i guess that we examine the Screen
  section of the config file here. We can still do this, but each screen which
  represents a viewport into a common framebuffer would use the same device
  id, so there is no more need of the Screen option in the device section.

  Claim the entities.

...

5.11 Sort the Screens and dpre-check the Monitor information

  Not sure about this, but i suppose it is just consistency check of the
  monitor modes, we can't do DDC things and such here.

5.12.a Entity Init

  We call this one for each entity in the chip, and do the stuff that is
  common to all heads of this entity, like video memory and other such stuff.
  We load modules that are needed, and in general handle all the information
  regarding the framebuffer (depth, bpp, virtualX/Y, dispalyWidth, videoRam,
  FBBase, MMIOBase and other such).
  
  We parse the entity-related options (the one of the device section).

  We also allocate a pEnt and store all the above information in it, and not
  in the screeninforec or driverprivate info. we put a pointer to the pEnt in
  the corresponding structures though.

  We can also call a HW accesing fb-init function, or do the necessary stuff
  directly to prepare the framebuffer information of the chip, like the
  framebuffer base address and stride.

5.12.b Head Init

  We call this one for each head (of each entity) and use it to allocate
  things related to each head. We initialize the clocks, the ramdacs, we query
  the supported modes trough DDC if possible, trought the builtin or
  configuration file provided data. Here we parse the screen (and monitor)
  related options and set variables such as frameX/Y0/1, modePool, modes,
  currentMode, ...

...

5.16 Screen Init

  Mostly as we do now, except maybe that we use, in addition to the
  currentMode, also information found in the currentSource or something such
  to be able to set do zooming if we can.
  
...

5.19 Mode switching
5.20 Changing Viewport

  I am not entirely sure of these two, and what would be the expected behavior
  with regard to the separate source/mode of the viewport. Adjustframe could
  be made to change not only the position of the viewport, but also its source
  size, while mode switching would be made to handle the outgoing video mode
  (to the monitor), but like Dawes said, this is rather counter intuitive to
  what is done now (where we only have modes), and may cause breakage in
  things like DGA apps and such.

5.21 VT switching

  This is a difficult one, since it would depend if we do multi-seat on the
  same entity or not. In the case we don't do same-entity multi-seat, it goes
  like this :

  on ENTER :
  
    ChipEntityEnter is called for each entity, and saves entity related
    information.

    ChipHeadEnter is called for each head (of each entity) and saves head specific
    information, which is proabably restricted to viewport information and
    outgoing video modes.

  on LEAVE :

    The same, but the other way around.

  Now, if we support same-entity multi-seat, thing become more problematic,
  since one seat could stay within X, while the other switches away or
  something such. I don't know if this is practical or can be solved without
  cooperation with the kernel console driver, or even if the chips support
  this (imagine one head being in text mode and driven by the kernel console
  code using the vga registers and the other continuing to be used by the X
  driver.

...

Other issues :

  Both the Xv overlay and the hardware cursor are handled per head, since they
  are related to the viewport and outgoing mode. They take as source a
  separate part of the onboard memory anyway.

  XAA and DRI needs to be shared per both heads, i suppose we can already do
  this, but there are further problems, like the Radeon limit on 2K
  coordinates for the graphic core (2D and 3D ? i don't really know, i don't
  have the docs). We need to call a rendering window adjustment function that
  modifies the framebuffer base per head or something such to work around
  this. This is what is done for the xinerama+DRI on dualhead experiment
  Jonathan Thambidurai did on Jens Owen advice.

What else, there are assuredly some other issues i did miss, like said, i am
mostly familiar by the device specific driver stuff and not much else, but i
think this is already a start and that we can do some discution based on this.

Friendly,

Sven Luther