Re: [Dri-devel] Dual-head (also S3 savage Duoview)

[Sven L. <lu...@dp...>]

On Mon, Feb 24, 2003 at 01:28:15PM -0800, Alex Deucher wrote:
> right now for these chips you set up the entity as shareable and then
> divide your framebuffer into two or more frambuffers, one for each
> CRTC.  Each instance of the driver then works using its framebuffer. 
> each head is distinguished using the "screen 0/1/etc." flag in the
> XF86Config file.  (entity functions and operations for this sort of
> thing are not so well documented, at least not that I could find). 
> Each pscrn gets it's framebuffer size and address mapped to the part of
> video ram you allocated for each frambuffer.

Yes, and you have to divide the fb memory in two, one for each head, or
something such, and each head will have its separate offscreen memory
manager, possibly using different screen strides.

It should be possible to allocate memory for both framebuffers and have
the offscreen memory manager be part of the EntRec, or something such,
that is common for both heads. I haven't looked at it much yet.

Also, this would need to be coordinated with ian's work on the texmem
memory manager, in particular the open point on XAA memory integration.

How is it done right now ? Is a part of the onchip memory reserved for
framebuffer and XAA, and another part free for 3D use ?

> For chips with dual crtcs you could do just what the diagram below
> shows and create a single frame buffer with two sort of virtual
> framebuffers.  I'm not sure how this would work with the existing
> entity code.  I guess as far as XF86Config goes you have to create a
> custom flag.  As Sven said, this is I think what the matrox and Nvidia
> drivers do.  They can also announce xinerama for the benefit of window
> managers and such (even though it's technically not two pscrns).

> You could add the stuff from the device specific EntRec's to device
> specific Rec's.  then each pscrn would be responsible for not only
> frambuffer base and address but also primary and secondary virtual
> frame buffers and address.  The main framebuffer would hold the whole
> contents of the screen and each virtual framebuffer would basically be
> a viewport into the total "screen."  I haven't had time to think this
> through throughly and I'm already starting to have questions... I
> dunno...food for thought I guess.

Notice that the current entity sharing stuff does distinguish between
primary head and secondary head, so you could just test if you are on
the primary head, and do the offscreen memory allocation and (double)
framebuffer reservation on the secondary head (the one that gets
initialized second), so we know the size of both framebuffers.
Naturally, this info should be shareable, but since i think it will not
change, it is also ok to have it in the device specific Rec.

Now, then the only thing that would differ would be the viewport, which
should not cause problem. Note that we need to maybe separate the
modeinit stuff, into one part which will be responsible for setting up
the framebuffers, and another part for setting up the viewport (the
video mode one both heads, that is).

This way, you would still have two screen sections in the config file,
the only difference from traditional dual head, would be that we specify
some flag to have it handled like that.

Now, lets see what configuration option we would like for such a setup.
The following things come to mind (i don't know if all the cards, or
even mine support all of these, but assuredly future board will).

  o Traditional dual head.
    => No additional flag is used.

  o Double buffer dual head (what i did just describe)
    => We use the "Double" or whatever flag, we can also use an
       additional (optional) flag or argument to give the head mapping,
       after all, there is no reason why head 0 should be the primary
       head and vice-versa).

  o Mirrored viewports.
    => We use a mirror flag, both heads will be set to the same
       viewport.

  o Zoomed window.
    => One of the heads will have a viewport corresponding to a subpart
       of the other. with optional zooming if the size don't correspond.

Maybe the two later could be merged, with some clever option handling or
such. Are there other things i am missing here ?

Also, as a later point, it would be nice if these things could be
changed dynamically, maybe as a response to some special key stroke or
such like they have on laptops (or do these keystroke work even if there
is no driver support for those ?).

Notice that this should work fine for most boards, even those having an
offchip second ramdac or a third like the matrox parhelia. There may be
some issues though with the accel engine of some chips which can only do
2048 width, but i guess these sizes will increase in the future, and
anyway, we could staple the screen vertically, thus not reaching too big
screen stride, and have the function which setup for each screen move
the base address or something such. This would be a problem if you want
to see both screens side by side though.

Now, this was the easy part, what are the problems we are facing ?

  o We need to make Xinerama aware of this.

  o Xv support (and possibly HW cursor). Well this works fine for most
    2D drawing and probably 3D drawing, but the video or cursor overlays
    will not know about it. We will still need to do those per screen,
    which may not be possible on all dual head boards.

  o 3D memory management. Ideally we would use Ian's new memeory manager
    for all memory allocation, including the framebuffer, XAA and Xv. I
    will have to look again at Ian's proposal, but i suppose you can
    declare the framebuffer as pinned to the onboard memory or something
    such. If i understood this correctly, this would _not_ work when the
    drm is not supported, because all the memory management is to be
    done in the drm kernel module, right ? Also this would need the
    offscreen memory manager to be adapted.

Well, i hope this covers it, i will no go to reread ian's proposal and
see how the XAA interaction will work out.

Are there things i have missed or additional ideas ?

Friendly,

Sven Luther