Re: new device driver features

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

----------------------------------------------------------------------