Atlas OS

OK, so the ATI miniport driver thing ended when I started reading about windows display driver architecture. Modern video card programming is probably my biggest weak point, which is why I chose to hit that first. Anyway, it turns out that Windoze uses a layered driver approach with GDI, a display driver, a miniport driver, and a port driver. I've been vaguely aware of this, but didn't realize the details until trying to reverse the ATI driver. GDI is responsible for abstracting the details for user applications; it issues commands to the display driver and the miniport driver. The display driver has the job of actually rendering graphics, while the miniport driver handles configuration and mode setting type IO requests. The port driver is provided by Windoze and handles the bus interface (PCI, ISA, AGP, etc.). I'm happy to ignore the bus interface for now, but instead of simply copying Microsoft, I need to define my driver model. They have a pretty good reason for layering it the way they do, but this needs to look a little different within the Java framework.

Java already has a few GDI-esque libraries: Graphics2D being the most obvious. However, it is not derived from the device hierarchy and is not exactly what I'm looking for. So, I think the appropriate approach would be to design an AbstractDisplay class which offers functions like path stroking and filling, bit-blitting, color settings, etc. Then I can extend the abstract class to the equivalent of a MS display driver. Most display cards transfer data by mapping video memory onto system memory in a "linear frame buffer". All rendering operations will be alike for cards that support a LFB, so maybe one extension would be a LFBDisplay. Other cards have hardware accelerators, so maybe an AcceleratedDisplay. Then for specific card families, these devices can be further extended to support the nitty-gritty configuration details. Perhaps my ATI card would be an AtiRageMobiliyDisplay, which extends LFBDisplay, which extends AbstractDisplay. Then packages like Graphics2D can lookup the default AbstractDisplay, and perform all rendering functions to it. This is my idea given what I know so far-- it is likely to change as I go, and I'm learning to accept that.

So in the interest of both simplicity and genericism, I'm dropping the ATI project in favor of first implementing a generic VGA driver, after I define the abstract display class, of course. Mmmm, tasty details.