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.

Finally got OpenChrome DRM to properly support VIA Technologies VT1632(A) DVI transmitter

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.

Some modest progress in figuring out why the OpenChrome DRM VIA Technologies VT1632(A) DVI transmitter code is not working

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.

OpenChrome DRM KMS works on Averatec 3250 laptop

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.

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.