Last month, I posted 2 posts (here and here) on this blog regarding the state of OpenChrome DRM drm-next-4.20 branch. Although I initially suspected I2C bus helper service to be the suspect, after some testing, I started to suspect something within the DRM core was causing the issue. Unfortunately, I was not able to track down the suspect commit of DRM core even though I did try several times.
I tried Linux 4.19 rc2 from DRM subsystem repository several weeks ago, but that did not resolve the issue. I just tried Linux 4.19 rc5 from DRM subsystem repository now, and this time around, OpenChrome DRM is working again! Basically, I had to live with the bleeding edge of OpenChrome DRM not working for about 2 1/2 months. It was really frustrating when someone else causes a problem that I have little control over it, but I am happy I am now out of this long tunnel.
I still have not figured out why the OpenChrome DRM drm-next-4.20 branch is not working. Looked at I2C bus subsystem related code commit, but could not really find a commit that will cause a crash like what I observed. As an experiment, played around with Linux 4.18 rc6 to see how it will perform. The good news is that this version is working, and in fact, I am writing this post from the computer I used to compile the code (VIA Embedded EPIA-M830 with VIA Nano 1 GHz). I will test Linux 4.18 rc7 shortly. Since I went back to performing full compilation, it might take a few hours to compile the code and test it.
I moved the OpenChrome DRM development into drm-next-4.20 branch more than a week ago, but I discovered that when OpenChrome DRM is being used, it can no longer boot the OS.
The reason for this is due to a strange bug introduced by I2C bus subsystem device driver between Linux 4.18 rc4 and rc7. The matter was not resolved by upgrading to Linux 4.19 rc1. I have tried to find the offending commit of I2C bus subsystem, but I am not able to find the bad commit so far. I contacted the I2C bus subsystem maintainer, but he denied that “core” I2C bus subsystem device driver has changed recently. Generally speaking, the I2C bus subsystem maintainer did not show much interest in the issue when I reported the issue to him directly via e-mail. I guess I will have to go bisect the issue myself.
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.