Re: new device driver features

Ideally, the hot swap facilities are true for
both monitors/displays and for the graphics interfaces themselves.

We already have the problem of hot swap of monitors, widespread.

And hot plug of displays also already occurs: we have PCMCIA/CF
displays in handhelds that are hotplug, and there his hotswap
versions of PCI.

We'll have to do work at the window system as well, but between
composite and randr, much of the protocol framework is present.

I'm advocating this be kept in mind in the interface design
more than initial implementation.....
                               - Jim

On Fri, 2003-11-14 at 16:09, Brian Paul 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
-- 
Jim Gettys <[email protected]>
HP Labs, Cambridge Research Laboratory