Now that I decided to work on r128 (ATI Technologies RAGE 128) graphics stack, here is my assessment of the state of the graphics stack.

• Standby resume does not work

Not surprising considering that FOSS (Free and Open Source Software) graphics developers back in early Year 2000 did not really care much about hardware state recovery from ACPI S3 State (Suspend to RAM). Since I do not really like keeping the computer on when I am not using it (even with a desktop computer), this is probably the first item I hope to fix. More analysis on this matter in a separate post.

• EXA based 2D acceleration is fairly buggy

There was a developer who added this functionality in Year 2012. Unfortunately, he did not fully debug the code before committing the new code, so it creates all kinds of rending problems on one’s desktop.

• Contains FBDEV and VBE mode setting code paths

In general, I am not a fan of complex, non-preemptive, multitasking OSes (yes, that was a big deal in the early Year 2000s) calling VBE (VESA BIOS Extension) for mode setting. I will like to get rid of it. That being said, some hardware specific information like PLL reference frequency appears to come only from the Video BIOS (there is a table entry that tells the graphics device driver about the PLL reference frequency) according to RAGE 128 technical documentation. This means that it is basically impossible to wean 100% off of Video BIOS. Probably what is going to happen is that r128 graphics stack will continue to use the hardware information that comes from the Video BIOS, and handle mode setting based on the information provided, but likely get rid of FBDEV and VBE mode setting code paths. Considering the age of r128 graphics stack, it is likely going to end up as a UMS / KMS dual mode setting graphics stack similar to what I am trying to do with OpenChrome graphics stack.

• Lacks clear separation of display controllers (CRTC) and output devices

OpenChrome graphics stack has clean separation of display controller (people used to call this CRTC or Cathode Ray Tube Controller starting around ’70s until fairly recently since no one makes real CRTs for new displays anymore) and output devices. I will likely try to separate VGA, FP, DVI, and TV after I gain some programming experience with the hardware and after I obtain a laptop containing RAGE 128 (I think they were called RAGE Mobility 128, RAGE Mobility M3, and RAGE Mobility M4 back around Year 2000).

One more interesting thing I have observed after doing some digging is that RAGE 128 and early Radeon hardware (i.e., R100) appear to share practically the same display controller. This is a pretty good example of ASIC reuse (i.e., reusing the portions of the ASIC design) from a hardware design perspective. Of course, it helps reduce the burden of having to rewrite and test the software code as well. What this means is that I can use Radeon DRM code as a reference at least for the FP and DVI portion of the code if I get stuck with the development.