I was hoping that by now I will have the code for VIA Technologies VT1632(A) working. Unfortunately, the weird blue color issue has not been resolved. I developed the code on Wyse X90L mobile thin client and tested the code there. Perhaps, this might be an issue specific to X90L (VN896 chipset) so I tested it on Wyse Cx0 thin client (VX855 chipset) as well. Unfortunately, the end result is identical to what I saw on X90L. This is not a hardware issue since the color is displayed properly with the legacy OpenChrome DDX mode setting (UMS). It might take a while to resolve this issue.
Okay, I fixed the I2C bus / EDID related issue. I still have the weird blue color issue discussed yesterday.
I poured considerable amount of time yesterday and today into writing code trying to get OpenChrome DRM to support VIA Technologies VT1632(A) DVI transmitter. I just tested the first version of the code a short while ago.
The good news is that I see something on the display connected to DVI. The bad news are that the code appears to have an I2C bus issue and displays an odd colored picture on the display. Standby resume is working when tested. I used Wyse X90L mobile thin client, SanDisk Extreme 64 GB USB 3.0 flash storage device, and Samsung SyncMaster 226BW display.
All this isn’t too bad for my first attempt. I will attempt to fix the issues tomorrow.
This week, I got bogged down with trying to get Lubuntu 16.04 to install with Averatec 3250 laptop (AMD Athlon XP-M and KN400 chipset). This laptop appears to have issues with Lubuntu 16.04’s systemd, and most of the time (roughly 80% of the time), it enters standby when booting. It did not do this prior to Canonical fully adopting systemd during boot. Due to a Linux kernel issue or buggy ACPI BIOS issue, at this time, it is impossible to get this computer to come out of standby without itself POSTing after resume (this also happens on Ubuntu 10.04 and 12.04). Standby resume works for other KM400 chipset based computers, although they are not laptops (i.e., desktop computers with VGA out only). Standby resume appears to work fine on Windows XP though.
Also, I had to deal with my aging Windows Vista laptop’s hard drive issue. I had to take out the hard drive, and attach it to a different Windows 7 computer just to run chkdsk utility. chkdsk has been running for already 2 days straight. I do still use Microsoft Windows sometimes, but it is mainly to print documents from a Canon laser printer with a USB interface. Other than that, I practically only use Linux based OS (Ubuntu based) nowadays since I actively develop OpenChrome almost everyday. This may sound like a case of humble brag, but it is a lot nicer using OpenChrome graphics based computers these days since I have made tremendous improvements in getting standby resume to work for most computers both legacy OpenChrome DDX’s mode setting code and OpenChrome DRM’s mode setting code. I honestly could not have imagined this computing arrangement (i.e., not using Windows too much) 10 years ago.
I have not put in too many hours into OpenChrome development this week, but I am trying to put in more hours today (Saturday) to make it up. Anyway, I think I should be able to get VIA Technologies VT1632(A) DVI transmitter code for OpenChrome DRM working in the next several days, unless I hit a snag.
If the code works, I hope to get it in the repository in a week or two. I will make sure that standby resume is going to work properly before committing the code.
Okay, I was finally able to test OpenChrome DRM Version 3.0.81 with Linux 4.16 rc7+. It is working fine including standby resume when tested on HP 2133 Mini-Note.
The promised fix for Chrome9 HCM (VX855 / VX875 chipset) hardware cursor also went into Version 3.0.81.
Previously, I have discussed my interest in using Wyse Cx0 thin client as an OpenChrome DRM test platform by attaching SanDisk Extreme 64 GB USB 3.0 flash memory storage to it. Back in January, there were several outstanding issues that prevented booting of Xubuntu 16.04 + OpenChrome DRM, so this was not successful. Anyway, since then I have fixed several bugs, along with added a few missing features, in order to properly support VX855 / VX875 chipset.
With the updated code, I booted Xubuntu 16.04 + OpenChrome DRM (Version 3.0.78). Unfortunately with this version of OpenChrome DRM, there was no hardware cursor displayed on the screen. Since the hardware cursor works on VX900 chipset, I was wondering what went wrong again. It turns out, commit a640d8e did not fix the hardware cursor bug for VX855 / VX875 chipset.
If I think about why commit a640d8e did not fix the bug, that’s because whoever assigned PCI Device ID labels for many of VIA Technologies devices picked misleading names. For example, for VX855 / VX875 chipset’s integrated graphics, the correct label for it turns out to be PCI_DEVICE_ID_VIA_VX875 instead of PCI_DEVICE_ID_VIA_VX855.
Anyway, the fix will be committed in the next day or two.