Re: new device driver features

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.

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

Just something to think about.  

Alex

--- Brian Paul <brian-CdwZJljFklH+2FeEXyspIVaTQe2KTcn/@public.gmane.org> wrote:
> Updated outline follows.
> 
> -Brian
> 
> 
> 
> Initialization:
> 	- ability to resent a secondary card; only primary cards
> 	  are reset at boot by the BIOS.  (Jon Smirl)
> 	- more?
> 
> Query card capabilities:
> 	- amount of VRAM
> 	- number of screens
> 	- make/model info
> 	- interupt #  (Jon Smirl)
> 	- more?
> 
> Display:
> 	- query supported display modes (for each screen)
> 	- set display mode (for each screen)
> 	- set start address/stride for scanning out the framebuffer
> 	- set hardware colormap
> 	- enable/disable each screen
> 	- stereo mode
> 	- setup hardware video overlays
> 	- enable shadow display / TV-out  (Jon Smirl)
> 	- enable ROM to get PLL values  (Jon Smirl)
> 	- more?
> 
> Monitor:
> 	- query monitor's parameters/limits (DDC / EDID?)
> 	- fall back to a config file for monitors without DDC/EDID  (Jon
> Smirl)
> 	- more?
> 
> Cursor:
> 	- show/hide
> 	- get/set position
> 	- get/set cursor image
> 	- more?
> 
> Memory:
> 	- allocate/free VRAM
> 	- AGP allocation?
> 	- map VRAM into process address space
> 
> Rendering:
> 	- negotiate DMA based rendering?
> 	- OpenGL renderer as an intrinsic piece, or layered?
> 	- simple, built-in rendering (like blits)?
> 	- more?
> 
> Utility library:
> 	- write a utility library of routines generally useful to most
> drivers
> 		- EDID parsing
> 		- frame buffer memory allocation
> 		- I2C
> 		- mode line files, etc.
> 
> Misc:
> 	- hot-swap ability (change monitors)  (Alex Deucher)
> 	- power management  (Alex Deucher)
> 
> 
> 
> Other Notes:
> 
> Jon Smirl
> ------------------------------------------------------------
> 
> "PCI probing and resource allocation needs to be done by the OS.
> 
> It shouldn't be very hard to write a minimal driver that used the OS
> for probing and then exposed the frame buffer. That would allow
> software mesa/xserver to run on a lot of different hardware to begin
> with. We can then come around later and fix the acceleration.
> 
> I'm also against having multiple device drivers trying to share the
> same piece of hardware. There is an awful lot of code in the XFree
> drivers trying to support multitasking of two device drivers on the
> same piece of hardware. You can easliy fool this code and lock up
> your
> system once you know where the holes are. There is also the issue of
> saving/restore of complete hardware state between the drivers.
> 
> Coexistance with framebuffer can be achieved by booting on
> framebuffer, but as soon as the new driver loads, deactivate the
> framebuffer driver. Systems that don't run xserver would continue on
> with framebuffer. Also note that most PCs, Mac, Sun boxes don't need
> framebufer installed to boot since they have BIOS based video
> support.
> 
> Under the new scheme each VT would have it own buffer. A VT switch
> would just tell the compositing engine to make one of these buffers
> full screen."
> 
>
----------------------------------------------------------------------
> 
> 
> _______________________________________________
> Xserver mailing list
> Xserver-u7BhqnqprCWvj1b/[email protected]
> http://pdx.freedesktop.org/cgi-bin/mailman/listinfo/xserver


__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree