On 22-May-06, at 4:19 PM, Garrett D'Amore wrote:

> I'm looking at rasops and splash a bit more lately, and I find that
> there is a lot of sharing/duplication of effort.
>
> For example, I need to make splash support drawing on a BGR display  
> (it
> only supports RGB at the moment).  Not terribly hard to do, but we
> already have all this support in rasops.
>
> It strikes me that we really need a common framework for display
> adapters (pixel oriented at least) to expose themselves, and implement
> just a single set of operations, from which either text or graphic
> drawing can be done.
>
> I'd like to suggest that we consider merging the splash and progress
> features with rasops a bit more, so that raster-oriented (or pixel
> oriented) displays can have a single API they have to implement in  
> order
> to get reasonably complete support.  And so that logic that needs  
> to be
> added to splash etc. can be simplified, removed, and just use the same
> logic where it exists in rasops.

Both rasops and splash need to become consumers of a common, for lack  
of better term, "DDI". As we discussed earlier, have a look at the  
Windows CE DDI API for what ops that hw drivers should export to both  
userland and to these subsystems. We will of course need to do  
software implementations of these functions for linear framebuffers  
to assist in developing new drivers (or using existing hardware that  
lacks hw accelops).

Having a DDI lets us build both "applications" in the kernel that can  
use the display, as well as providing a reasonable accelerated 2D API  
for userspace to use (X, SDL, Qtopia, etc).

Cheers,
Jared