Re: new device driver features

We need a new driver model. I've been trying to pull the Radeon driver out of X
and make it work standalone. I have been working on it three weeks and I'm no
where near being finished.

The Radeon driver makes about 150 calls back into X. So I go into the X source
and pull out those 150 routines. But those 150 routines call another 100
routines and so on. Now I have to rewrite a bunch of these routines to break the
chain. 

To make the drivers more useful we need to a standalone support library that is
separately compilable. Things like EDID parsing, frame buffer memory allocation,
I2C, mode line files, etc can go into the common library.

I previously worked on the Mozilla project. Mozilla just about collapsed because
of the inseparability of their modules. The project came to a halt for almost
six months while things were refactored into independent pieces.

--- Brian Paul <brian-CdwZJljFklH+2FeEXyspIVaTQe2KTcn/@public.gmane.org> wrote:
> 
> So, it sounds like people want a new device driver model upon which 
> the X server (or other things) can be layered.  Has anyone outlined 
> the feature set for such a driver?
> 
> I'll go out on a limb and list what first occurs to me:
> 
> 
> Initialization:
> 	- what does this really involve?
ability to reset a secondary card (X does this) 
Only primary cards are reset at boot by the BIOS
> 
> Query card capabilities:
> 	- amount of VRAM
> 	- number of screens
> 	- make/model info
> 	- more?
interrupt #
> 
> Display:
> 	- query supported display modes (for each screen)
merged fb 
enable shadow display - TV out
> 	- set display mode (for each screen)
enable the ROM to get PLL values
> 	- set start address/stride for scanning out the framebuffer
> 	- set hardware colormap
> 	- enable/disable each screen
> 	- stereo mode
> 	- setup hardware video overlays
> 	- more?
> 
> Monitor:
> 	- query monitor's parameters/limits (DDC / EDID?)
> 	- more?
fall back to config file for monitors without DDC/EDID
> 
> 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 separate?
> 	- simple, built-in rendering (like blits)?
> 	- more?
> 

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.

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

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