Re: new device driver features

We might also want to try building a model where the server doesn't need to run
with root priv. What would be the issues with removing the need for root?

Here is a first pass at a split....

Device driver:
> Query card capabilities:
> 	- amount of VRAM
> 	- number of screens
> 	- make/model info
> 	- interrupt #  (Jon Smirl)
> 	- more?
OS probing
OS events - interrupt, power management
Current DRM functions

Device specific library:
> Cursor:
> 	- show/hide
> 	- get/set position
> 	- get/set cursor image
> 	- 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?

Common code library:
> Memory:
> 	- allocate/free VRAM
> 	- AGP allocation?
> 	- map VRAM into process address space
> Initialization:
vm86 support so we can make BIOS calls when there is no other choice.
> 	- ability to resent a secondary card; only primary cards
> 	  are reset at boot by the BIOS.  (Jon Smirl)
> 	- more?
> 	- write a utility library of routines generally useful to most drivers
> 		- EDID parsing
> 		- frame buffer memory allocation
> 		- I2C
> 		- mode line files, etc.
> Monitor:
> 	- query monitor's parameters/limits (DDC / EDID?)
> 	- fall back to a config file for monitors without DDC/EDID  (Jon Smirl)
> 	- more?
> Misc:
> 	- hot-swap ability (change monitors)  (Alex Deucher)
> 	- power management  (Alex Deucher)
> Rendering:
> 	- negotiate DMA based rendering?
> 	- OpenGL renderer as an intrinsic piece, or layered?
> 	- simple, built-in rendering (like blits)?
> 	- more?
> 
> 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 easily 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.
> 
> Coexistence 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

=====
Jon Smirl
jonsmirl-/[email protected]

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