Re: Native mode handling

> Maybe, but it's starting to get a little complex.  If anyone really cares 
> about full support for broken/obsolete hardware, they can put some effort into 
> such a design at a later date.  But understand you are talking about a 
> vanishing class of hardware.
> 
> I'd expect the non-open vendors to provide drivers for this infrastructure, 
> assuming it takes off.

Well... The main problem with supporting different sets of acceleration
APIs (typically 2D and 3D in this discussion) is the necessary
arbitration between those for accessing the chip & engine(s).

However, since we want to get in some mode setting & monitor probing,
possibly fully dynamic (hotswap), we need that kind of arbitration
anyway, at least for beeing able to pause the 3D pipe and any other
direct HW access while the mode is beeing changed, which in some cases
cases imply resetting the engine, tweaking PLLs & memory FIFOs etc...

As long as we have some working arbitration on this kind, it seems to me
like having a 2D API is as well is not that much of a problem.
Especially since we could probably just use the existing kdrive API
slightly tweaked and be done with it.

A driver may be exclusive in this regard, that is if it provides a GL
API, it doesn't do 2D and 2D is expected to be layered on top of 3D,
that's an option simplifying arbitration at the HW level, but that's
just driver choice.


Ben.