Re: new device driver features

Jon Smirl wrote:
> 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. 

I know exactly what you're talking about.


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

Good idea.


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

I didn't know that, but certainly can understand that.

Modularity is of the utmost importance.  I think we'd like to 
encapsulate as much of the device-dependent graphics code within an 
API that's fairly simple and understandable so that vendors/people can 
write drivers without a lot of hassle.

By identifying what's needed by the graphics hardware driver, I'd hope 
that a nice API would follow.

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

This all sounds good to me.

I'll update my outline with your suggestions (and Alex's).

-Brian