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.

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.