Since my initial focus of my foray into developing r128 graphics stack is to first fix its broken standby resume behavior (Again, I really hate having to leave a room with an idling desktop computer.), I wanted to analyze the issue using the same development strategy I used successfully with OpenChrome Project. What I mean by “successfully” here is that over the past 2 years, I have been able to substantially improve the standby resume reliability of OpenChrome graphics stack. Unlike in the past, I can now put most of my VIA Chrome based computers, including laptops, to sleep and wake it up fairly reliably. In fact when one starts doing this, you happen to stumble across network device drivers that do not handle standby resume very well (it either freezes the system or cannot renegotiate with the network after standby resume). What was crucial in analyzing various standby resume issues was the existence of a backdoor register manipulation tool. This tool allows the developer to play around with hardware registers to figure out what is going on with the display and do some simple experiments before writing the software code to fix the issue.

For OpenChrome, one developer who was once VIA Technologies’s open source community liaison developed such a tool about 9 years ago, and I have to admit it was very helpful in analyzing various OpenChrome DDX / DRM bugs. Since such a tool worked out fairly well for me, I was thinking I will like to have something similar for the r128 graphics stack.

If I recall what I wrote previously, ATI Technologies RAGE 128 and early Radeon like R100 and RV100 actually have similar CRTC (display engine) registers. Hence, I figured maybe I can try to run a tool called radeontool with a RAGE 128, and maybe it will work.

So, I cloned the radeontool Git repository and built the binary.

git clone git://people.freedesktop.org/~airlied/radeontool
cd radeontool
./autogen.sh

Here is how to dump all registers.

sudo ./radeontool regmatch ‘*’

Here is how to disable CRTC1 display.

sudo ./radeontool regset CRTC_EXT_CNTL 0x00000448

Here is how to enable CRTC1 display.

sudo ./radeontool regset CRTC_EXT_CNTL 0x00000048

The good news is that I was successfully able to toggle a register bit to manipulate (disrupt) the display. Now, I need to figure out how to prevent the complete freeze after resuming from standby . . .

I did mention in an earlier post that I will discuss in more detail about r128 DDX’s present standby resume functionality. In general, when it comes to dealing with standby resume, it puts the developer in a tough spot if the OS completely locks up after standby resume. In my case, I am sort of in this situation presently with the following computer.

• AMD Sempron 3200+ (Socket 939)
• ASRock 939DUAL-SATA2
• 1 GB DDR400 DDR SDRAM (256 MB x 4)
• ATI Technologies RAGE 128 Pro 32 MB (I think it is Xpert 2000 Pro.)

If you are into PC mainboards, perhaps ASRock 939DUAL-SATA2 mainboard was probably one of the most exotic mainboard to ever exist. It comes with native Gen 1 PCIe x16 and AGP 8X slots (Note: A real AGP slot, not those “fake” AGP slots hooking up AGP cards to the South Bridge’s PCI bus.) It even comes with a AM2CPU upgrade card slot. What happens is that if I put the computer into standby and then resume it, the keyboard connected to it will respond for a few seconds (i.e., Num Lock or Caps Lock toggles), but it will soon freeze completely.

I also have another computer to mainly to work with RAGE 128.

• Intel Celeron 2.0A GHz
• SOYO Computer P4S Dragon Ultra
• 1 GB DDR266 DDR SDRAM (512 MB x 2)
• ATI Technologies RAGE 128 Pro 32 MB (I think it is Xpert 2000.)

For this board, it comes with a Universal AGP Pro slot, hence, I can use it with RAGE 128 (RAGE 128 does not support AGP 1.5 V signaling). Intel did not make chipsets that supported AGP 3.3 V signaling cards for their Pentium 4 chipsets (i.e., Intel 845 and 850), but SiS and VIA Technologies did. Furthermore, this mainboard supports ACPI S3 State, and it is actually pretty rare to find a mainboard that has a Universal AGP slot that happens to support ACPI S3 State. Anyway, with this mainboard, when I resume the computer from standby, the computer beeps and keyboard does not respond at all. Nothing is displayed on the screen.

Going back to the ASRock 939DUAL-SATA2 mainboard based computer, when it comes out of standby, if I frantically try to transition to VT (Virtual Terminal) and back to XFCE desktop, it is able to display “something.” The “something” here is a totally distorted display. Based on my experience of fixing most OpenChrome standby resume issues, I will assume that r128 DDX is not reinitializing all necessary registers for a proper operation.

Typically in this type of a situation, comparing the register values for before and after standby allows me to figure out which registers are causing display issue. But before I can do that, I will need to figure out how to regain control of the computer after I resume from standby.

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.

As promised, I am taking a break from developing OpenChrome for a while. I started to look at which other underserved graphics device I should improve the functionality. After looking at various candidates, I think for now, I should probably work on r128 graphics stack for ATI Technologies (they merged with AMD around mid to late Year 2000s) RAGE 128 family. I came to this conclusion based on the following reasons.

• ATI Technologies shipped quite a few RAGE 128 graphics cards during its hey day (from Year 1998 to 2000)
• I own about 8 different RAGE 128 based graphics cards (PCI and AGP)
• RAGE 128 was a relatively short lived family (Year 1998 to 2000), limiting the development scope
• Some technical documents can be found on the Internet
• Supports 32-bit color (many 20+ years old graphics devices support 24-bit color due to the very small frame buffer of that era) 2D and 3D acceleration

If I were to add one other major reason, it is that SiS and Matrox DDXs supports many generations of graphics devices within the DDX, and having to support more than one generation tends to complicate the device driver development. I also looked at S3 Savage and it appears to cover a fair number of devices than I originally imagined. Hence, I ended up with RAGE 128.

So, I started to look at the DDX code, and started the cleaning up process of the code. I have posted 10 patches over at xorg-driver-ati mailing list. The problem is, I do not have a commit privilege for the rest of xorg repositories (I only have commit privilege for OpenChrome related repositories.), so I cannot commit the code myself at this point.

Since I pay to host this blog, I have some freedom to say I think about what is going on, but I feel like some xorg developers drag their feet or play politics regarding the issue of who gets to commit the code into the repositories. I am not a newbie developer anymore, so I will feel like I should get repository commit privilege right away since I have been a responsible developer of OpenChrome graphics stack for the past 2 years. I have posted some of the patches 5 days ago, but I have yet to get the change committed into the repository as of this writing.