Yesterday (Sunday), I met a friend who has been helping me out debug OpenChrome from time to time. I went over what I did for the past year. Although I did not feel like I accomplished much during that meeting, I was able to get a hold of Wyse X90L mobile thin client. I was able to see how OpenChrome DDX Version 0.6.170 (the current bleeding edge version) performed against Wyse X90L.

Actually, this same friend gave me this same model about a year ago, but for some reason, I could never get its DVI-D port to work at all with OpenChrome DDX. I did not feel like opening up the chassis of the mobile thin client, so I did not know which vendor’s TMDS (DVI) transmitter it was using. Wyse X90L comes with VIA Technologies VN896 chipset (i.e., mobile version of P4M900 chipset), and P4M900 chipset family does not come with an integrated DVI transmitter.

I happened to not bring a DVI cable for this OpenChrome “plugfest” session (I regret that), but since I have put such emphasis on fixing OpenChrome DDX and DRM’s longstanding standby resume issues, I was curious as to how Wyse X90L performed against a newer X.Org X Server and bleeding edge OpenChrome DDX (Version 0.6.170). Unfortunately, standby resume of the flat panel did not work out too well, but we managed to get VGA output to work. In that process, I was able to take a look at Xorg.0.log under /var/log/, and noticed that OpenChrome DDX was automatically detecting VIA Technologies VT1632A DVI transmitter.

I guess what this means is that I happened to have a broken Wyse X90L unit, and this is why OpenChrome DDX was not detecting its DVI transmitter.

Regarding Wyse X90L and standby resume, I do believe I have gotten its flat panel to come back after standby resume when I tested it on Lubuntu 12.04 with a USB flash memory stick while back. I believe I encountered a screen saver authentication issue, to which I cannot go past. I will revisit this issue in a few weeks.

By the way, the use of the term “plugfest” sounds awfully similar to what PCI-SIG does several times a year to ensure compatibility between various PCI Express devices. Some years ago, I worked on a PCI interface IP core for Xilinx FPGA (initiator / target cable) using Verilog HDL and more recently worked on PCI Express Physical Layer MAC (Media Access Controller) block’s awfully complicated initialization sequence (LTSSM). I only managed to implement Detect State and essential parts of Polling State (Polling.Active and Polling.Configuration) so far, although it is implemented enough to the point I got two PCIe devices to exchange TS1 OS (Training Set 1 Ordered Set) and periodically insert SKP OS (Skip Ordered Set) on an HDL simulator. Okay, hardware design stuff is not related to the OpenChrome Project, so I will digress . . .