Similar to what I usually do with OpenChrome Project, I will start giving end of the month summary of what happened with what I will call, “legacy graphics stack development project.”  For now, this will mainly mean ATI Technologies RAGE 128, but it will likely expand into other devices down the road.

In June, I decided to start working on ATI Technologies RAGE 128.  This was due to RAGE 128 having good technical documentation and the device driver has limited device support scope.  Some time in early July, I was able to commit code myself.  At the present time, I am focused on code refactoring (mainly initialization code) and fixing standby resume.  I am starting to learn how the EXA code works in order to figure out why the EXA code renders some junk on the screen sometimes.

In addition to that, I went ahead and released xf86-video-r128 Version 6.11.  It fixes a bug that causes some RAGE 128 Pro models to output out of range signal to the monitor.  At this rate, I think it will take several months before I can fix one significant bug of RAGE 128 DDX.

I missed reporting the status of OpenChrome Project for June 2018, so I will make it up, and combine it with the July 2018 edition.

Ever since I started to work on developing ATI Technologies RAGE 128 graphics stack, inevitably, the time dedicated to developing OpenChrome graphics stack went down quite a bit.  I must admit that I am personally pretty bad at handling multiple tasks, so as a result, vast majority of the time went into working on RAGE 128 graphics stack, particularly xf86-video-r128 (RAGE 128 DDX).  You can verify this from RAGE 128 DDX commit log.

Anyway, I still managed to get a few things done with OpenChrome.  I helped figure out why standby resume was not working properly on Samsung NC20 netbook when Xubuntu 18.04 is used.  Also, I managed to fix VGA display issue of ECS VX900-I and VIA Embedded VE-900 mainboards when VGA and HDMI are both connected.  Furthermore, I found a remedy for VIA Embedded EPIA-M830 not restoring the display properly after standby resume.  OpenChrome DRM got the fix, but have not committed the fix for OpenChrome DDX yet due to personal laziness.  Please note that VIA Embedded EPIA-M830 still suffers from a different standby resume issue (complete freeze), and I do not think it is OpenChrome related (OpenChrome DDX and DRM are both affected).

I auctioned off VIA Embedded EPIA-M800 mainboard in June, but unfortunately, it got destroyed during transit (USPS Priority Mail).  There was a hole that penetrated even the VIA Embedded box inside a USPS Priority Mail flat rate box, and badly damaged the mainboard. If the seller packed the box better, that might have saved the mainboard.  It was insured, so I got the money back.  I was hoping to test its integrated DVI transmitter (some early revisions of VX800 chipset contained a TMDS transmitter to support DVI), but it may never happen.

The last item to report is that I restarted the development of GEM / TTM memory allocator code.  I hope to put more time into developing OpenChrome next month.

Back in February, I discussed about completely rewriting OpenChrome DRM’s GEM / TTM code here.  The original motivation for this activity was to see if the GEM / TTM code developed by the previous developer was the cause of runtime screen resolution X Server crash I was observing.  While I did not discuss the matter in detail, I did manage to rewrite GEM / TTM code back in February, but after testing the code, the runtime screen resolution crash was still occurring, so I pulled the plug developing this code further, concluding that it was not really necessary.  That being said, it allowed me to look into other possible causes, and solved the matter in early March.

As discussed here, the SSD I was using (ADATA Ultimate SU800 SSD) died a few months ago, and took away the code I spent a few weeks writing . . .  Since then, I decided to expand into developing a new r128 DRM with KMS support, and I now have more reasons to get this GEM / TTM code developed so that the new r128 DRM can reuse the code.  I do not want the new r128 DRM project to become another vaporware project (meaning, I am going to finish it unlike other Linux graphics developers who tried, but failed to finish several KMS supporting DRM projects in the early Year 2010s), and having some proven code reused helps with the r128 DRM development.

Actually, there are two other reasons why I will like to implement my own implementation of GEM / TTM code.  First is, DRM maintainer wants OpenChrome DRM to remove unfinished acceleration code before the code goes into the mainline tree.  The way I look at this request is that it is an opportunity to remove unmaintainable GEM / TTM code written by the previous developer, and replace it with my own implementation.  Second is, I have observed freezes on VX900 chipset.  This happened when changing the screen resolution during runtime.  Yes, this issue was remedied back in March 2018, but apparently, it is a different bug from the one fixed in March 2018.  This new bug was discovered only recently.  It involves a crash with TTM.  Hence, the impetus the replace the existing GEM / TTM code.

This time around, the new GEM / TTM code is safely inside the trustworthy SanDisk Extreme 64 GB USB 3.0 flash storage stick.  It will stay inside there until it is ready to replace the existing code.

I have been spending quite a few hours rewriting the aging xf86-video-r128 (ATI Technologies RAGE 128 DDX) code this week.  Unfortunately, portions of the code are written in a way that makes it hard to separate EXA and XAA acceleration initialization.  Furthermore, it supports the virtually deprecated DRI1 as well.  The initialization of these items (EXA, XAA, and DRI1) were written in a way that is very confusing and fragile ways that it is taking a lot of time to carefully untangle them.

What I am trying to do here is to untangle and isolate the initialization of these standards so that I can disable them without causing issues.  Furthermore, by implementing the initialization process this way, it will later make it easier to add DRI2 and KMS support down the road.

For now, I am trying to untangle the code without breaking the existing code.  I expect this to continue for several weeks.

I released xf86-video-r128 DDX for ATI Technologies RAGE 128 sometime yesterday.  It is a bug fix release where some RAGE 128 Pro cards get their VGA mistakenly recognized as DVI.  Worse, EDID (Extended Display Identification) based automatic detection of display was not working properly, and this was leading to the display complaining about “out of range” display signal being sent from the graphics chip.  This situation required the user to specify the monitor refresh rate inside xorg.conf.  With this release, there is no longer the need to do this.

At least the fix I committed fixes one bug, and there has been no new release for a while, so I just went ahead and released a new one.  Starting with Version 6.11, I will be changing the version naming convention, and patch level (i.e., the third number) will be going up more frequently as I rewrite / add new code.  For the next few months, most of my development effort for RAGE 128 DDX will be to stabilize the existing DDX UMS (User Mode Setting) code.

As of Version 6.11 release, the code contains these two major issues.

• Standby resume freezes the computer upon resume
• Occasional display of junk on the screen (i.e., when scrolling within a window or dragging a window)

I am actively working on both issues, but have not found the solution to the issues yet.

Anyway, if you support my work fixing and enhancing abandoned old graphics device drivers, please consider a small donation through my donation link here.

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.

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
cd 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)
make
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.

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.

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.