OpenChrome DRM drm-next-4.18 branch is now EOL

OpenChrome DRM drm-next-4.18 branch is now EOL.  The bleeding edge development has now transitioned to drm-next-4.19 branch.  Due to DRM maintainer changing the Linux DRM subsystem upstream repository location, I lost sync with the repository for a while.  Besides that, Linux 4.17-rc5 had file system (BTRFS) related boot issues, so I had to wait until Linux 4.18-rc1 or rc2 to update the drm-next-4.18 branch and then transition to drm-next-4.19 branch.  Now that I caught up with the bleeding edge of DRM subsystem, I plan to pour more time into OpenChrome DRM development along with continuing the development of xf86-video-r128 DDX.

My first bug fix patch for RAGE 128 DDX posted

Now that I have commit privilege for X Server components, I was able to push some commits into the xf86-video-r128 DDX (RAGE 128 DDX) repository.  However, these commits did not alter the behavior of the code too much (they were almost all code refactoring commits), and did not fix any known problems of the code.

A few days ago when I was setting up my 64-bit x86 (x86-64 or AMD64) instruction set capable computer with an AGP slot for the purpose of kicking RAGE 128 DDX development into high gear, I plugged in RAGE 128 Pro Ultra 16 MB AGP graphics card into the AGP slot.  Unfortunately, the monitor connected to the graphics card complained about “out of range” signal coming out of the VGA connector.  I remembered that this particular card had this same issue back in Year 2015, and I reported the VGA display detection issue of RAGE 128 Pro Ultra back then.  Somehow, the bug report was closed with “RESOLVED FIXED” status even though the bug is still there.  Note that this bug affects certain models of RAGE 128 Pro, and not all models of RAGE 128 Pro are affected. The particular graphics card I used here is a pull from a Dell desktop PC.

I remembered that there is a workaround for this bug, and it is to limit the display frequency of the attached monitor via xorg.conf file.  With this workaround, display appears to work okay, but now the display is misidentified as DVI rather than VGA.  Since this workaround is merely a temporary band-aid, I decided to analyze the RAGE 128 DDX code to see what is going on, and try to fix the issue.  After analyzing the code, I came to the conclusion that the current RAGE 128 DDX code does not really detect the available display resources very well, and it will require a lot of work to try to fix the code.

For now, I will settle for a quick fix to the code that only benefits RAGE 128 on x86 platform.  This is because the fix relies on video BIOS supplied available display resources table, and it is unclear if there was something comparable to this on Apple PowerMac platform.  If you have any information about it, please contact me since I do not wish to break the code for PowerMac users.  Furthermore, if you have RAGE Mobility 128, M3, or M4, please test the patch as well to see if FP on your laptop is still working.  With this fix, I no longer have to limit the display frequency of the attached monitor, and X Server recognizes the attached monitor as VGA.  The patch is here and my supplemental post is here.

If I were to repost the instructions on how to compile the RAGE 128 DDX with the patch applied, this is what it looks like. Please note that ‘(“. . .”)’ portion should be replaced with actual storage location, and I assume that you are using Ubuntu based OS.

sudo cp /usr/lib/xorg/modules/drivers/ (“Anywhere appropriate to store a backup”)
sudo apt-get install git
sudo apt-get build-dep xserver-xorg-video-r128
(“sudo apt-get build-dep xserver-xorg-video-r128-hwe-16.04” for Ubuntu 16.04 with HWE)
mkdir (“Whatever appropriate name for a directory”)
git clone git://
cd xf86-video-r128
patch -p 1 < (“File name of the patch”)
./ –prefix=/usr CFLAGS=”-Wall”
(‘./ –prefix=/usr –enable-dri CFLAGS=”-Wall”‘ if you want DRI1 enabled)
sudo make install

If it did not work, you should be able to restore the r128 DDX this way.

sudo cp (“Location where the backup of was stored”)/ /usr/lib/xorg/modules/drivers/

If the patch does not cause a regression with PowerMac or RAGE Mobility based laptops, I will go ahead and release a new version of xf86-video-r128 DDX with this fix in the next few weeks.  Please note that this fix is just the first step, and I plan to fix several more issues of the code over the next few months.

If you appreciate my work on RAGE 128 graphics stack, please financially support me through a small donation via PayPal.  Part of the donation will pay for the increased electricity cost of running fairly power hungry AMD Opteron 165 on ASRock 939Dual-SATA2 mainboard.

Currently working on getting GPIO based I2C bus working for OpenChrome DDX

I am currently working on getting MSI CN700T mainboard’s DVI to properly handle the screen resolutions the monitor actually supports. At the present time, the DVI coming out of this mainboard can display certain screen resolutions X Server provides by default if EDID was not received by the DDX. I do not find this behavior to be very desirable. The issue I am observing here is that VIA Technologies VT1632A DVI transmitter is connected to GPIO2 / 3 pins to emulate I2C bus, but it is not working for the purpose of receiving EDID. That being said, it works for the purpose of detecting and controlling VT1632A. Please note that the code I am talking about is the existing OpenChrome DDX UMS (User Mode Setting) code for the upcoming Version 0.7 release.

Strange twist (?) to this saga is that if I let OpenChrome DRM to perform KMS (Kernel Mode Setting), its GPIO based I2C code works well, and I am able to obtain EDID from the monitor.

Finally was able to commit into xf86-video-r128 upstream repository

After weeks of delays, I was notified today that I now have the commit privilege to commit into xorg related components. Prior to this, I published 4 patches related to xf86-video-r128 DDX over at xorg-driver-ati mailing list. I used git-am to apply the patches to my local xf86-video-r128 repository.

git am (“Name of the patch”)

Since I had 4 patches, I repeated the above operation 4 times. Then, I pushed the changes to the upstream repository.

git push

Here is the first of the 4 patches I committed into the xf86-video-r128 DDX upstream repository.

Taking advantage of the software infrastructure Radeon graphics stack developers set up for RAGE 128 graphics stack development

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://
cd radeontool

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 . . .

More on r128 DDX standby resume support status

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.

Assessing the state of r128 graphics stack

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.