Now that I have commit privilege for x.org 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/r128_drv.so (“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://anongit.freedesktop.org/xorg/driver/xf86-video-r128
patch -p 1 < (“File name of the patch”)
./autogen.sh –prefix=/usr CFLAGS=”-Wall”
(‘./autogen.sh –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 r128_drv.so was stored”)/r128_drv.so /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.
On a PowerMac you should probably check the device tree which might have the info you need in the properties of the card’s node.