OpenChrome DRM drm-next-4.21 branch is now EOL. The bleeding edge development has now transitioned to drm-next-5.1 branch. Currently, working on integrating the new TTM memory allocator and I hope to compile the code in the next few days.
I finished removing the unfinished acceleration code. It was a little harder than I expected it and took a few days, but the code is back to working fine. Now that there is an ABI break, the version of OpenChrome DRM is now Version 3.1.x rather than 3.0.x.
When the code is finally in the Linux kernel mainline tree, I expect the version to be incremented to Version 4.0.x. There will be no acceleration support initially. Version 4.1.x and later should support acceleration.
I am now in the process of integrating my own TTM memory allocator into OpenChrome DRM. I expect this to take a few weeks. I hope to reuse this code with other DRM implementations down the road.
Although it appears from the outside that the development pace of OpenChrome DRM has slowed down considerably over the past few months (i.e., frequency of the code commit into the OpenChrome DRM upstream repository), I have been working on implementing my own implementation of TTM memory allocator since July 2018. After trying out several implementation ideas, I am hoping the current implementation will work out. The code has not even been through compilation yet, and even after this, it may not work right away. I hope to get the TTM memory allocator committed in the next few weeks.
That being said, I was told by the DRM maintainer back in June 2018 that I will need to remove the previous developer, James Simmons, developed unfinished acceleration related code before Linux kernel tree mainlining. The thing is, I do not really like the code quality of the acceleration related code along with the fact that I want more control of the design of the acceleration related code. I now plan to throw out all the unfinished acceleration related code. I am in the process of doing this for the past few days, but due to various interlocking modules of the code present in the OpenChrome DRM, it is taking longer than I hoped.
My plan is to remove all of the unfinished acceleration related code, compile OpenChrome DRM to see if the code is still working fine. After that, I plan to substitute in my own initialization code and header file. Then, I plan to integrate my own TTM memory allocator code with OpenChrome DRM.
I will write more when I have something new to report.
As the year comes to an end, I will like to recap what Brace Computer Laboratory was able to accomplish this year.
For first half of the year, most of my efforts were devoted to further developing OpenChrome graphics stack. Probably the biggest accomplishment this year for OpenChrome DRM was finally figuring out why changing the screen resolution during run time causes X Server to crash. I finally added device support for VIA Technologies VT1632(A) and Silicon Image SiI 164 DVI transmitters. I discovered that code to properly set up display FIFO for CLE 266 and KM400 chipsets was missing, so I added the code to properly support CLE266 and KM400 chipsets. With all of these efforts, OpenChrome DRM KMS code achieved rough feature parity with OpenChrome DDX UMS code.
However, during the second half of the year, the momentum slowed down considerably. Although this happened during the first half of the year, the test code that would have formed the foundation of the code to replace the current GEM / TTM memory allocator code got lost along with ADATA Ultimate SU800 SSD 128 GB suddenly dying. That effort got restarted, but the newer code, which is more complete, is still not finished for me to test the code.
Regarding OpenChrome DDX, I did not put in as much effort into developing it like I did during prior years, but made some progress in fixing several outstanding issues. For example, I fixed Samsung NC20 netbook and VIA Embedded EPIA-M830 mainboard standby resume issues. Fixed ECS VX900-I mainboard VGA screen distortion when an HDMI display is connected simultaneously. Towards end of the year, I put in the initial effort into fixing VT (Virtual Terminal) display issue (i.e., blank screen) after the computer has gone through at least one standby resume. Unfortunately, the code was not perfect. Finally, I worked together with someone who wanted the VT issue solved yesterday, and appears to have fixed the issue (used HP 2133 Mini-Note for validation). Now, you should be able to use VT even after standby resume (Previously, this only worked only when OpenChrome DRM is in use.).
Starting the second half of the year, I started getting into developing other graphics stacks other than OpenChrome. I chose R128 (ATI Technologies RAGE 128) graphics stack. I did do two minor releases (here and here), but the second one was merely to fix an issue introduced by the first release. Spent some time trying to figure out how to fix standby resume issue and EXA rendering artifacts issue. Unfortunately, made no progress in those areas this year.
Towards end of the year, I started to do minor maintenance work of cleaning up the old, neglected DDXs so that at least they do not give so many compilation warnings with newer X Servers. I cleaned up all the code compilation warnings and released newer versions of DDX for Intel740, Number Nine Imagine 128, Matrox, NeoMagic, and Chips & Technologies.
Finally, I will like to appreciate all of those who supported me financially by donating to Brace Computer Laboratory. I hope to continue improving and fixing underserved graphics device drivers next year and for many years to come.
For some time, I have known that when OpenChrome DDX UMS (User Mode Setting) code goes through one or more standby resume (i.e., recovering from an ACPI S3 State), the computer will more or less likely completely lose the control of the VT (Virtual Terminal) screen. It is highly system dependent and some models do not exhibit this behavior. However, models that do not exhibit this behavior is fairly small. The real answer as to why I could not deal with this was due to the lack of an idea on how to solve the issue.
Probably about several months ago, I started to think that if the DDX saved all display related registers during DDX initialization (i.e., X Server initialization), then I figured it should be able to restore perfectly all the time, including even after going through one standby resume cycle. So I made this commit in November that fixed the issue for some models (i.e., ones without an FP).
Two days ago, I got together with one actual OpenChrome user and this person pointed out the VT screen issue since the November commit. After noticing that one particular register (CRA2 or 3X5.A2) was different between the code before the November commit and after, I was able to come up with the fix quickly. VT now works fine before and after standby resume. We both used HP 2133 Mini-Note for the validation (different OSes).
The problem I saw here was the flaws in the X Server RandR era callback functions. It has no serious mechanism to handle a situation like this, and I had to come up with a “scheme” (or you can call this a “hack”) to deal with the matter. I am probably the last person on Earth who will ever deal with X Server DDX UMS, but if there is going to be someone else who will deal with this, saving all the VGA registers during initialization “scheme” appears to do the trick for restoring VT.
Here is the announcement. I do not really have a functional laptop that has a NeoMagic graphics chip, so I have no idea if the code even works. You probably have to resort to using PuppyLinux, in order to run xf86-video-neomagic since laptops that had NeoMagic graphics chip typically did not support more than 256 MB of main memory. I do not really have the option of testing the code on a desktop mainboard since I have never seen a stand alone AGP or PCI NeoMagic graphics chip based graphics card. I am sure it existed back then (i.e., more than 20 years ago) solely for use by laptop PC manufacturers during laptop development. (i.e., reference design card) This will mean that there probably will never be KMS support for it since you need a minimum of 512 MB for Linux kernel related development nowadays and 1 GB or more is preferred.