Assessing the state of r128 graphics stack

Now that I decided to work on r128 (ATI Technologies RAGE 128) graphics stack, here is my assessment of the state of the graphics stack.

  • Standby resume does not work

Not surprising considering that FOSS (Free and Open Source Software) graphics developers back in early Year 2000 did not really care much about hardware state recovery from ACPI S3 State (Suspend to RAM). Since I do not really like keeping the computer on when I am not using it (even with a desktop computer), this is probably the first item I hope to fix. More analysis on this matter in a separate post.

  • EXA based 2D acceleration is fairly buggy

There was a developer who added this functionality in Year 2012. Unfortunately, he did not fully debug the code before committing the new code, so it creates all kinds of rending problems on one’s desktop.

  • Contains FBDEV and VBE mode setting code paths

In general, I am not a fan of complex, non-preemptive, multitasking OSes (yes, that was a big deal in the early Year 2000s) calling VBE (VESA BIOS Extension) for mode setting. I will like to get rid of it. That being said, some hardware specific information like PLL reference frequency appears to come only from the Video BIOS (there is a table entry that tells the graphics device driver about the PLL reference frequency) according to RAGE 128 technical documentation. This means that it is basically impossible to wean 100% off of Video BIOS. Probably what is going to happen is that r128 graphics stack will continue to use the hardware information that comes from the Video BIOS, and handle mode setting based on the information provided, but likely get rid of FBDEV and VBE mode setting code paths. Considering the age of r128 graphics stack, it is likely going to end up as a UMS / KMS dual mode setting graphics stack similar to what I am trying to do with OpenChrome graphics stack.

  • Lacks clear separation of display controllers (CRTC) and output devices

OpenChrome graphics stack has clean separation of display controller (people used to call this CRTC or Cathode Ray Tube Controller starting around ’70s until fairly recently since no one makes real CRTs for new displays anymore) and output devices. I will likely try to separate VGA, FP, DVI, and TV after I gain some programming experience with the hardware and after I obtain a laptop containing RAGE 128 (I think they were called RAGE Mobility 128, RAGE Mobility M3, and RAGE Mobility M4 back around Year 2000).

One more interesting thing I have observed after doing some digging is that RAGE 128 and early Radeon hardware (i.e., R100) appear to share practically the same display controller. This is a pretty good example of ASIC reuse (i.e., reusing the portions of the ASIC design) from a hardware design perspective. Of course, it helps reduce the burden of having to rewrite and test the software code as well. What this means is that I can use Radeon DRM code as a reference at least for the FP and DVI portion of the code if I get stuck with the development.

Selecting ATI Technologies RAGE 128 family as my next graphics device driver development target

As promised, I am taking a break from developing OpenChrome for a while. I started to look at which other underserved graphics device I should improve the functionality. After looking at various candidates, I think for now, I should probably work on r128 graphics stack for ATI Technologies (they merged with AMD around mid to late Year 2000s) RAGE 128 family. I came to this conclusion based on the following reasons.

  • ATI Technologies shipped quite a few RAGE 128 graphics cards during its hey day (from Year 1998 to 2000)
  • I own about 8 different RAGE 128 based graphics cards (PCI and AGP)
  • RAGE 128 was a relatively short lived family (Year 1998 to 2000), limiting the development scope
  • Some technical documents can be found on the Internet
  • Supports 32-bit color (many 20+ years old graphics devices support 24-bit color due to the very small frame buffer of that era) 2D and 3D acceleration

If I were to add one other major reason, it is that SiS and Matrox DDXs supports many generations of graphics devices within the DDX, and having to support more than one generation tends to complicate the device driver development. I also looked at S3 Savage and it appears to cover a fair number of devices than I originally imagined. Hence, I ended up with RAGE 128.

So, I started to look at the DDX code, and started the cleaning up process of the code. I have posted 10 patches over at xorg-driver-ati mailing list. The problem is, I do not have a commit privilege for the rest of xorg repositories (I only have commit privilege for OpenChrome related repositories.), so I cannot commit the code myself at this point.

Since I pay to host this blog, I have some freedom to say I think about what is going on, but I feel like some xorg developers drag their feet or play politics regarding the issue of who gets to commit the code into the repositories. I am not a newbie developer anymore, so I will feel like I should get repository commit privilege right away since I have been a responsible developer of OpenChrome graphics stack for the past 2 years. I have posted some of the patches 5 days ago, but I have yet to get the change committed into the repository as of this writing.

Status of OpenChrome Project (May 2018)

May 2018 went by pretty fast since all kind of things happened in my life, and not all of them were pleasant. Anyway, did make some solid progress with the OpenChrome Project.

After a modest April, I finally figured out why the newly written (borrowing portions written in Year 2016 by me for OpenChrome DDX) VIA Technologies VT1632(A) DVI transmitter code for OpenChrome DRM was not working. Now, it is working well with full standby resume support. Here is the post on that.

Based on the VT1632(A) code and the proven OpenChrome DDX code, I also went ahead and added Silicon Image SiI 164 DVI transmitter support to OpenChrome DRM. Here is the post on that. The code is untested.

Then, I went ahead and solicited opinions on how to get OpenChrome DRM mainlined inside the Linux kernel tree. Here is my post and here is the reply.

Although I announced that I will like to take a break from OpenChrome Project related development to work on DRM for underserved graphics devices, I was still working on figuring out why a laptop (Samsung NC20 netbook) with VX800 chipset does not resume from standby very well. Although not the same model, I have known for some time that VIA EPIA-M830 mainboard suffers from the same issue. After spending 4 to 5 hours straight on it, I found an okay solution that works most of the time. Here is the patch. I will post about this issue later.

Taking a break from OpenChrome Project development work

I have been working on OpenChrome graphics stack development virtually non-stop for the past 2 1/2 years. I do recall taking a one week break a week prior to XDC2017 to prepare presentation slides. As I recall those days, I just succeeded in porting OpenChrome DRM to Linux 4.13, and I had only one week to prepare for the presentation. If you happened to go through my commit history, there are times when I didn’t commit for weeks. The reality is that I cannot make commits every week since there are times when it takes several weeks to analyze what is going on, write the code, and test the code. This was the case when I finally succeeded in supporting VIA Technologies VT1632(A) DVI Transmitter for OpenChrome DRM, and that took 8 weeks.

Due to the enormous amount of time I have been spending on developing OpenChrome graphics stack for the past 3 years, I have put developing other underserved graphics stacks on the backburner. In fact it is worse than that to the point that there is no heat being applied to these underserved graphics stacks. Starting today, I will start devoting more time to develop a reusable DRM module for the underserved graphics stacks.

I also plan to devote some time into writing tutorials about compiling OpenChrome graphics stack (DDX and DRM), and other general useful tips. I expect the break to last about two weeks.

Looking to solicit opinions on the feasibility of getting OpenChrome DRM mainlined inside Linux kernel tree

Now that VIA Technologies VT1632(A) and Silicon Image SiI 164 DVI transmitters support were added to OpenChrome DRM, that concludes adding new device support to OpenChrome DRM for now. Since my XDC2017 presentation (presentation PDF is here), I have made major improvements in improving the stability of OpenChrome DRM in the areas of runtime screen resolution change, standby resume, and dual head display. Furthermore, I fixed many small bugs that affected specific devices like CLE266 chipset, KM400 chipset, K8M800 chipset, VX855 chipset, and Samsung NC20 netbook (The last one is untested for OpenChrome DRM. The testing was done on OpenChrome DDX UMS code.). At this point, the reliability of OpenChrome DRM KMS is comparable to the legacy OpenChrome DDX UMS, and the device support is about the same. The device support I am talking about here are VGA, DVI (except VX900 chipset integrated DVI / HDMI transmitter), and flat panel. That being said, there are small device support differences between the two.

  • TV out is supported by OpenChrome DDX UMS (User Mode Setting) code, but it is really broken
  • VX900 chipset integrated DVI / HDMI transmitter is supported by OpenChrome DRM KMS (Kernel Mode Setting) code, but it is somewhat broken

The TV out and VX900 chipset integrated DVI / HDMI transmitter code was entirely written by previous developers, so I am not really responsible for their code quality. Although some may not like it, I can possibly disable VX900 chipset integrated DVI / HDMI transmitter initially, and go fix it after the code is mainlined inside the Linux kernel tree. This affects those who might want to use Zotac VD01 HTPC box since it does not support VGA (it has HDMI and DisplayPort). I am planning to work on improving TV out support during the OpenChrome DDX Version 0.8 development cycle.

I have never done this, so I do not really know what to expect, but I will post an RFC (Request for Comment) over at dri-devel mailing list shortly about how to proceed for OpenChrome DRM. Since I have never done this, I may look foolish or ignorant about the procedures on how to get the code reviewed by much more experienced DRM maintainers, but I guess I need to go through this now rather than right at the last minute. I will likely have to defend the continued use of legacy (i.e., Year 2008 time frame) KMS interface, and the decision not to adopt universal planes and atomic mode setting at this point. If the DRM maintainer grants an exception to the continued use of legacy KMS interface, then I think OpenChrome DRM can be mainlined during Linux 4.19 or 4.20 development cycle. That will fulfill my prediction I made during XDC2017 presentation that I should be able to get OpenChrome DRM mainlined by 2H2018.

What is really motivating me to get OpenChrome DRM mainlined is the second class citizen treatment OpenChrome gets from Canonical and Fedora. OpenChrome DDX is no longer installed by default when performing a fresh install, and this causes various inconveniences to the average (non-computer technical) user. Ostensibly, this is due to DRI1 support, but it really appears to be the lack of KMS support that got Canonical and RedHat to drop the default install of OpenChrome DDX. I want things to be easier for the average user, hence, the need to get OpenChrome DDX back onto the list of default installed graphics device drivers.

To be honest, I know the window movement performance is pretty bad when OpenChrome DRM is in use since there is no acceleration activated at this point, but this will be worked on later after the code is mainlined. This was outlined during my XDC2017 presentation, and I am merely following what I predicted back then on how I will be proceeding forward. I guess I consider getting out of the second class citizenship status to be more important than the window movement performance. That’s the trade off I am making at this point.

Silicon Image SiI 164 DVI transmitter device support officially added to OpenChrome DRM

Well, it only took one day to do this. While watching Golden State Warriors beat down Houston Rockets mercilessly in the 4th quarter, I was also adding Silicon Image SiI 164 support to OpenChrome DRM. Here is the commit. Since VIA Technologies VT1632(A) is a 99% clone of SiI 164, the code I wrote for VT1632(A) was copied with small modifications to handle SiI 164. I do not know if it works since I do not have the equipment to test it. If someone knows how to compile Linux kernel and owns HP t5550, t5565, t5570, or t510, please test the code.

This will likely be the last device support added to OpenChrome DRM prior to getting it mainlined within the Linux kernel tree. I will talk about getting the code mainlined in the Linux kernel tree in the next post.

VIA Technologies VT1632(A) DVI transmitter device support officially added to OpenChrome DRM

As promised, VIA Technologies VT1632(A) DVI transmitter support was finally added to OpenChrome DRM. Here is the commit. VT1632(A) was the biggest missing device support that OpenChrome DRM had, and now that it is finally supported, this event will make the eventual Linux kernel tree mainlining closer to a reality. By adding VT1632(A) device support, I will say that OpenChrome DRM now handles almost all typical user display usage.

That being said, there are still several missing display devices for OpenChrome DRM.

  • Silicon Image SiI 164 DVI transmitter
  • VIA Technologies VT1622(A) TV encoder
  • VIA Technologies VT1623 TV encoder
  • VIA Technologies VT1625 TV encoder
  • VIA Technologies VT1631 LVDS transmitter
  • VIA Technologies VT1636 LVDS transmitter
  • Analog Devices AD9389B HDMI transmitter
  • VX900 chipset integrated DVI / HDMI transmitter
  • VX900 chipset integrated DisplayPort transmitter

Since VT1632(A) is a largely pin and register compatible clone of Silicon Image SiI 164, adding support for it should be fairly easy. In fact, OpenChrome DDX UMS code already supports it. The only problem is that I do not own a box that has SiI 164 in it. For TV encoders, even the existing OpenChrome DDX UMS code for them are broken, so I will need to fix them first before the code is ported over to OpenChrome DRM. VT1631 and VT1636 are I2C bus configurable LVDS transmitters for flat panel, but OpenChrome DDX UMS code never supported them in the first place. Analog Devices AD9389B comes soldered on VIA EPIA-P720 and P820 Pico-ITX boards. I recently purchased EPIA-P720 on eBay, but later realized that it did not come with a power cord in order to power it, so I cannot use it for now. While OpenChrome DRM currently supports VX900 chipset’s integrated DVI / HDMI transmitter, the code has some issues that it is not at Linux kernel tree mainlining quality. I have not tried to even support VX900 chipset’s integrated DisplayPort transmitter so far although register programming information is in the VX900 chipset technical documentation.

Furthermore, there were some hardware that used Chrontel transmitters / encoders in the past, but I do not own copies of them. I do not mind adding support for them to OpenChrome DDX / DRM someday.

Anyway, adding VT1632(A) support to OpenChrome DRM was a lot harder than I anticipated. It took a lot longer time than I would have wanted to spend on it. If you feel like I deserve some financial rewards for my 8 weeks of hard work, here is my PayPal donation page. Thanks.