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.