Subject: Re: rasops vs. splash
To: Garrett D'Amore <email@example.com>
From: Jared D. McNeill <firstname.lastname@example.org>
Date: 05/22/2006 17:14:39
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
> 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
> 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).