It took more than 7 months of development, but I finally merged the new TTM memory allocator code into the upstream OpenChrome DRM repository.  Actually there were not that many lines of code, but it took some time for me to get used to dealing with TTM, and it was pretty hard figuring out how TTM works.  I still do not really like TTM.  Also, it took me 2 months figuring out why the X Server was not booting correctly, and during that 2 months, I also spent most of the time for testing and releasing X Server 1.19.7 and cleaning up compilation warnings of several DDXs.

Moving forward, I will start concentrating on the following areas of OpenChrome DRM development.

• Convert via_* labels to openchrome_* (easy, but there is a lot to go through)
• Implement universal plane support for the mouse cursor
• Implement atomic mode setting

Although I have not gone through exhaustive testing, the code stability appears to be about the same as the previous implementation.  For example, I was still able to handle dual head configuration on HP 2133 mini-note with the VGA output driving a 1680 x 1050 screen resolution monitor along with the regular 1280 x 768 flat panel.  That being said, the current implementation suffers from the hardware cursor getting corrupted from time to time (it goes away if you move the cursor around for several seconds).

The reason why I started implementing my own TTM memory allocator is to start adding KMS (Kernel Mode Setting) support to many PCI / AGP era forgotten, underserved graphics devices, and I plan to reuse the TTM memory allocator code for these devices.  If anymore has noticed, I have been going through cleaning up the compilation warnings of many of these graphics devices for a while.  Think of this as a preparation work, although I do not necessarily committing to a particular device since I have so many of them I will have to go through.

Anyway, this particular code development held up the OpenChrome DRM development for many months, and now that I am done with it, I plan to go through the above three areas for the next several months, along with implementing another DRM with KMS support.

It took close to 2 months to stabilize the code, but I finally figured out why OpenChrome DRM with the new TTM memory allocator was not working correctly all the time.  I did announce that I got the code working back in January here, but after further testing, it turns out the buggy version of the code was able to boot the OS only approximately 1/7 of the time.  Rest of the time, the OS will not boot (i.e., it gets stuck).  Obviously, this is not at the acceptable reliability level for the code to get pushed into the upstream repository.

Because of the difficulty I faced in getting the code working properly, I spent most of my development time in February working with other projects like eliminating compilation warnings from underserved DDXs (here, here, here, and here) and releasing X.Org X Server 1.19.7 (here).  Figuring out how to install the compiled X Server and packaging the code was really difficult due to various bugs in the scripts and the lack of resources on how to do such a thing.

I came back to working on the OpenChrome DRM’s new TTM memory allocator after I got X Server 1.19.7 released.  I am still not done with the code.  I still have to clean up the code by jettisoning unnecessary portions, but at least I have a clear path towards getting the code into the upstream repository.

Here is the announcement.  My primary motivation for getting involved in releasing a maintenance release of X.Org X Server 1.19 is to fix EXA 24 bpp (bit per pixel) crash bug that affects older graphics devices that do not support 32 bpp rendering.  Not too many such older devices got EXA support, but SiS DDX happened to get the support prior to the main developer calling it quits.  For all practical purposes, it particularly impacts SiS 6326 since SiS back then (20 years ago) sold quite a few millions of them (they were often sold as a $30 to $40 low end graphics card at computer dealers to those who did not care too much about brand or performance).  In practice, SiS 5597 / 5598 and even older devices benefits from the fix as well.

While I proposed doing this back in early January 2018, and I did not really start working on the matter until late January.  That being said, but it took a lot more time and personal efforts to figure out how to handle the whole process once I started working on this.  Compared to releasing a DDX, it is far harder to build X Server, and the difficulty lies in figuring out what to do when one encounters errors.  The thing is, the release build script (xorg/util/modular) has several issues, and one encounters them when building the X Server, not DDX.  Observing that using the release build script from around Year 2016 to 2017 rather than the latest script was one trick that helped me in the process.

There are two parts to this process: figuring out how to install my own compiled X Server without wrecking my own OS installation and building the X Server code archive correctly.  To be frank, I did not really reach a point where I can build the X Server, and getting it working without some “hacks.”  I was indeed able to run the compiled X Server, but I had to rely on certain keyboard related components prepared by Canonical (i.e., manually had to copy keyboard related files).  Without getting keyboard related components properly installed, X Server will not run at all.  If you are trying to compile your own X Server, please keep this in mind.

While there did not appear to be much interests in releasing another maintenance release of X Server 1.19, I wanted to do this for those who plan to stick with X Server 1.19.  One bad habit of many FOSS (Free and Open Source Software) developers is that they often move on to developing the next version without fixing the existing code they released some time ago.  I tend to stick to something that works right now rather than chasing the newest code, and I am sure I am not the only one who thinks this way.

Regarding, X Server 1.19, I can possibly do a few more releases if other people have small fixes to the existing code.  As long as there is no ABI break, I think it is okay to enhance the code.  As for this EXA 24 bpp fix, I plan to apply it to X Server 1.18 as well, and the fix itself is applicable all the way to X Server 1.7.

I tested the code on Voodoo Banshee (16 MB SDRAM, PCI  bus and 16 MB SGRAM, AGP bus), Voodoo 3 1000 (16 MB SDRAM, PCI bus), and Voodoo 5 5500 AGP (AGP bus; the original “monster” gamer graphics card) with Xubuntu 16.04.5 (X Server 1.19.6). Standby resume does not work.

This release actually fixes a bug that affects non-HiQVideo Chips & Technologies devices.  I tested the code on a Chips & Technologies 65548 1 MB PCI bus desktop graphics card (unknown manufacturer) with Xubuntu 16.04.5 (X Server 1.19.6). Standby resume does not work.

Here is the announcement.  I tested the code on Diamond Multimedia Stealth 3D 2000 (S3 ViRGE, 2 MB EDO DRAM, PCI bus) and Stealth 3D 4000 (S3 ViRGE / GX2, 4 MB SGRAM, AGP bus) with Xubuntu 16.04.5 (X Server 1.19.6).  Standby resume does not work.  If anyone has the hardware register documentation, feel free to e-mail me as long as you do not violate your NDA.

Here is the announcement.  I do not really have a graphics card that this DDX supports, so I was not able to test the code prior to the release.  Actually, I do have one card (from Miro) with a chip from Alliance semiconductor, but it is ProMotion 3210, which is not supported by this DDX.  I honestly doubt anyone on this planet uses this DDX anymore, but I updated the code anyway.  If anyone has the hardware register documentation, feel free to e-mail me as long as you do not violate their NDA.

It took me about 5 to 6 days to figure out what was wrong with the code, but I am happy to report that the initial implementation of TTM memory allocator for OpenChrome DRM appears to be working okay.  I have not gone through all the tests I should be doing at this point, but at least it is working on my HP 2133 mini-note.  I booted my usual Xubuntu 16.04.5 LTS 32-bit and now the code can start up the X Server properly.  Of course, standby resume is also working fine (A small unrelated bug with FP detection right after standby resume still exists in the code, but I have not encountered this yet).  I expect it will take another week or two to properly clean up the code for the commit push into the upstream repository.

Finally, I got the new TTM memory allocator code merged with OpenChrome DRM.  The code now compiles without syntax errors.  As expected, it could not boot the X Server the first time or the second time I tried it.  I am still working on getting it to work properly, and I expect this to take a week or two.  Code commit will probably not happen for 2 to 3 weeks.  Anyway, this is a huge step forward for OpenChrome Project, and my other future underserved graphics device revival projects.