Re: new device driver features

Alex Deucher wrote:
> I hate to reply to my own email, but I thought of one more:
> Dealing with things like DPI and gamma properly per-head on single
> logical screen (xinerama style) multi-head.

I think several of your ideas fall outside the scope of the graphics 
h/w device driver...


> Alex
> 
> --------------------------
> We should also design it with "hot" reconfiguration in mind. 


> Things like enabling/disabling output ports,

got that.


> changing crtc and virtual resolutions, color depths

got that.


> screen orientation,

window system issue.


> overlay changes,

huh?


> swapping input devices,

Not a graphics driver issue.


 > per-context 3D allocations,

The device driver probably won't know anything about multiple 
rendering contexts.  I think it's up to higher-level software to 
virtualize the graphics hardware.


> PCI(E)/AGP hot-swap of video cards,

OK.


> adding Xservers on other PCs.

Not a graphics driver issue.


> Some other things to think about:
> - power management

OK.


> - multiple users on one PC/video card

What do you mean by that?


> - idea of multiple focus - 2+ users can share a single desktop, eg.
> collaborating on a single project, etc.  this concept of a "user" can
> be tied to a particular set of input devices.  the "user" would also
> have their own clipboard, etc. Each "user" could have a window in focus
> and actively be working on it independantly, or share a window and both
> actively edit a single document.

That's clearly a window system issue, not a device driver thing.

> - multi-head/xinerama/mergedfb - how can we mix HW accel between heads
> (one chip, multiple chips, PCs, etc)?  Chromium?

Some/most of this is above the device driver.


> - X server spread across multiple physical PCs - DMX?

Definitely not a device driver issue.


> We may not be able to support these all off the bat, but if we could
> design with them in mind, it would ease the process of adding that
> functionality later.

These are all fine ideas, but the point of this thread is to talk 
about a device driver interface.


-Brian


> --- 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?
>>
>>Query card capabilities:
>>	- amount of VRAM
>>	- number of screens
>>	- make/model info
>>	- 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
>>	- more?
>>
>>Monitor:
>>	- query monitor's parameters/limits (DDC / EDID?)
>>	- 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 separate?
>>	- simple, built-in rendering (like blits)?
>>	- more?
>>
>>
>>SciTech's SNAP interface provides this sort of stuff, plus lots of 
>>rendering and utility functions.  Is that sort of what people are 
>>looking for?
>>
>>-Brian
>>
>>
> 
> 
> 
> __________________________________
> Do you Yahoo!?
> Protect your identity with Yahoo! Mail AddressGuard
> http://antispam.yahoo.com/whatsnewfree
> 
>