Re: new device driver features

Alex Deucher wrote:
> another thing to think about regarding multiple output ports is how to
> handle them.  right now the radeon driver has screen based dualhead
> (separate pScrns, independant framebuffers, etc.) and mergedfb (shared
> frambuffer).  setting up the CRTCs is the same either way, but the
> handling of the frame, overlay, and cursor is different depending on
> what type of multi-head you are running.  I suppose the multi-head type
> could be abstracted independantly of how the hardware is set up. e.g.,
> just set up buffers of some bit depth (in the big framebuffer) that
> each crtc points to; then they can be independant or act as a single
> logical screen depending on how you "configure" it and you would get HW
> accel on both heads.

All this should be possible if the right set of primitive operations 
are offered by the driver interface.


> actually you could even extend this idea beyond the device driver. 
> this is getting a bit off topic, but why not set up a virtual
> framebuffer that maps to buffers allocated from the framebuffer or
> AGP/PCI space of each physical device.  then for higher level stuff it
> would look like a single framebuffer, but you would be able to get
> accel on the whole thing because the underlying hardware would handle
> it's portion of the virtual frambuffer.  I realize there are some
> gotchas regarding synchonization and such...

Have you seen DMX?  dmx.sf.net  The cards don't all have to be in the 
same machine.

The notion of distributed frame buffers is also a part of Chromium 
(chromium.sf.net).  Chromium is to OpenGL as DMX is to X.

-Brian