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.

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.

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.

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.

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.

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.

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.

It took about 3 times the estimated time to get it working, but I finally got OpenChrome DRM to properly control VIA Technologies VT1632(A) DVI transmitter. Since I am doing the work, I do have higher standards than other FOSS graphics stack developers (especially the 10+ years ago people who almost never bothered with getting the mode setting right after standby resume), so naturally, I also got standby resuming working perfectly as well. Otherwise, I would not consider this to be “working.”

My initial post about supporting VT1632(A) was back in early April 2018. I posted an interim progress posts here. I posted my initial code status here and a small fix here. Then, I posted about not being able to solve the weird color issue coming out of DVI here. After that, a lot of stuff happened in my personal life, so I was not able to put in as much time as I would have liked to into getting the DVI to properly work out of VT1632(A). During this “dark” period, I really could not find the reason why DVI was not working. I did post an update about it here, but the workaround fix was not really working for VN896 chipset (Wyse Xn0L) or VX855 chipset (Wyse Cx0).

Eventually, reexamination of the code along with narrowing down the problem to a register that handles power on / off of VT1632(A) uncovered a programming error on my part (i.e., inadvertently clearing out crucial control bits of VT1632(A) Register 08H). When I corrected that, I was cautiously optimistic that the DVI will now work, and when I tested the code, the DVI was finally working on my first try. It was working like it does with the existing OpenChrome DDX UMS (User Mode Setting) code. No more weird bluish or yellowish screen! I quickly tested the standby resume and it was properly setting all the relevant registers to restore the display.

Back in March 2018, I posted a TODO list for OpenChrome DRM here. Supporting VT1632(A) DVI transmitter was one of the item, In practice, supporting VT1632(A) is a crucial step I needed to go through before getting OpenChrome DRM mainlined inside the Linux kernel tree. This is because OpenChrome DDX UMS code already supports VT1632(A), and when the transition from OpenChrome DDX UMS code to OpenChrome DRM KMS code for mode setting happens, I think it will not be acceptable in the eyes of the users that the shiny new OpenChrome DRM somehow does not support DVI coming out of VT1632(A), but the older code does. Basically, device support needs to be same or better for OpenChrome DRM KMS to have a smooth transition from OpenChrome DDX UMS to OpenChrome DRM KMS. I also need to support Silicon Image SiI 164 DVI transmitter since it is on the TODO list. The code to support Silicon Image SiI 164 will be based on the code for VT1632(A), and it should be available in a week, although I do not really have the means to test it. To test the code, you will need HP T5550, T5565, T5570, or T510 thin client. I do not own these thin clients myself.

As for the validation, I tested the code on Wyse Vx0 and Cx0 thin clients. For Vx0, it does not appear to support ACPI S3 State (also known as Suspend to RAM or STR), but Cx0 does. Cx0 appears to be properly resuming from standby except you will need to tinker with the VIA Velocity Gigabit Ethernet device driver discussed here.

Anyway, I still have not committed the code to the upstream repository as of this posting. Of course, I will not post about this unless it was working to my satisfaction, and the code commit is coming in a day or two.

I have resumed trying to figure out why the newly written OpenChrome DRM code to support VIA Technologies VT1632(A) DVI transmitter is not working properly. In particular, why I get this weird color display issue.

For this, I used Wyse X90L mobile thin client and C00X thin client. Unfortunately, I got identical results. Out of desperation, I tried MSI Fuzzy CN700 mainboard that came inside MSI Axis 700. This one has CN700 chipset, which is basically P4M800 Pro chipset for VIA x86 processor. I bought this mainboard on eBay from a seller in Europe in Year 2016. I only bought the mainboard only with the fitting back I/O plate. While the color being displayed is still somewhat weird, I was able to finally get proper color display by manipulating CR9B[2:0]. These register bits apparently manipulates the clock output timing of DVP1 (Digital Video Port 1). I do not recall the existing OpenChrome DDX needing this hack for the DVI to display properly for this particular mainboard.

I am starting to suspect that I need to look into how the PLLs are being set up. I have observed that when I do register dump between OpenChrome DDX vs. DRM, I do notice the PLL values to be somewhat different. If I understand it correctly (and I can be wrong), OpenChrome DDX and DRM have different PLL calculation code. Maybe that’s why they behave differently when this DVI transmitter is in use.

I finally finished compiling Linux 4.16 rc7 kernel with OpenChrome DRM on Averatec 3250 laptop. As discussed recently, this laptop has a severe ACPI BIOS bug that causes the computer to go back into POST (Power On Self Test) when the computer tries to perform a standby resume. By accident, I found one method of working around this bug, and that is to run Windows XP first, restart the computer without shutting it down, then boot Linux. See this post.

However, there is one problem with this computer. That is, it comes with only 512 MB of RAM. Honestly, you really cannot clone the OpenChrome DRM Git upstream repository without the use of a swap file with such small amount of RAM. This posting over at Digital Ocean blog has been very helpful in setting up a swap file without the use of a separate partition just for a swap file.

https://www.digitalocean.com/community/tutorials/how-to-add-swap-space-on-ubuntu-16-04

Setting up a separate partition just for a swap file is the “official” way Canonical handles the swap file creation, but since I originally used Microsoft Windows extensively, I never really liked this approach. I prefer each partition have its own swap file.

Anyway, there are actually a few additional tricks needed to get Linux kernel compiled from scratch to be able to boot from a computer with only 512 MB of RAM. I will discuss this in a different post.

Averatec 3250 laptop has a buggy BIOS that causes many issues with Linux, but once I get past that, I went into testing the OpenChrome DDX with OpenChrome DRM. The good news is that thanks to all the effort I have put into getting this really troubled, buggy OpenChrome DRM into shape for the past year and a half, I was able to get the computer to handle standby resume the very first time I tried! Sweet!!! I also tried dual head mode (flat panel and VGA) and it worked for the most part. The only time I observed a hard crash was when I tried to put two screens left and right, with the VGA having to accept a relatively low screen resolution of 800 x 600 (FP is 1024 x 768) due to a hardware limitation of 2044 dot across the horizontal direction in 32-bit color mode (two 1024 x 768 screens will exceed the 2044 dot limit). Obviously, I will need to fix this bug before the mainlining of OpenChrome DRM.

What I mentioned so far is the good news (except the hard crash just observed). Here comes the bad news. The rendering speed of the current unaccelerated OpenChrome DDX (I am told it is letting ShadowFB do the rendering.) is really bad . . . It is in the territory of “atrociously bad” level performance compared to the existing OpenChrome DDX accelerated 2D rendering. This is particularly noticeable when dragging (moving) a window.

There are weird device driver issues with VIA Rhine Ethernet, and what I observed was that booting Lubuntu 18.04 with the Ethernet cable attached causes a weird boot failure. Just boot the OS without it and attach the cable after the OS reaches the log in screen.

It took me several days of tries to get Averatec 3250 laptop to properly boot Lubuntu 18.04. If you are using this laptop, I hope these tips save you a lot of time.