Okay, I spent about 6 to 7 hours yesterday trying to figure out how to fix K8M890 chipset’s Chrome9 IGP’s mouse cursor not being displayed on the screen when running OpenChrome DRM. It turns out, OpenChrome DRM did not have the code to properly handle the older generation Chrome IGPs with only one hardware icon (in VIA Technologies documents, it is abbreviated as HI or HWI).

One major problem when dealing VIA Chrome IGP is that older models have support for only one HI, and it can be displayed on either IGA1 (primary display) or IGA2 (secondary display), but not both at the same time. Eventually, someone noticed that this is inconvenient, so VIA added a second HI. This is particularly helpful when one is using two screens at the same time, and portions of the screen overlap.

Going back to the discussion about HI, the problem is, there is no clear boundary of which models have dual HI and which models don’t. Based on some experiments I performed with OpenChrome DDX, it appears that K8M890 chipset’s Chrome9 IGP does not have support for dual HI. Just for the sake of discussion, K8M890’s graphics engine is called Chrome9, and its 3D engine has been rumored to be based on S3 Graphics DeltaChrome. DeltaChrome was probably the last time S3 Graphics (at the time, a fully owned subsidiary of VIA Technologies) seriously tried to reenter discrete PC graphics market back in Year 2003 to 2004 time frame. That being said, all the Chrome9 family’s 2D / video / display engines are merely the evolved version of UniChrome Pro’s 2D / video / display engines. For example, the hardware registers are generally backward compatible, and this makes it easier to take unified device driver approach to the graphics device driver development.

Anyway, once I was convinced that K8M890 chipset’s Chrome9 graphics engine has only one HI, I ported the working hardware cursor code from OpenChrome DDX to OpenChrome DRM. Luckily, I got the hardware cursor working the second time I compiled OpenChrome DRM code for the explicit purpose of fixing this bug. That’s pretty good considering that I expected this bug to be much harder than that to fix. I already have a patch I can apply to the existing OpenChrome DRM to fix this bug, but I will put off committing the code into the upstream repository for several more days since I am trying to get drm-next-4.xx branch to get to drm-next-4.17 (currently, it is at drm-next-4.15). I am also waiting for drm-next branch of DRM upstream repository to be updated with newer code so that I can advance drm-next-4.xx branch to drm-next-4.16 and then drm-next-4.17. After drm-next-4.xx branch gets to drm-next-4.17, I will apply the patch and commit the code into the upstream repository. Then, I will backport the code to the drm-next-3.19 branch.

For the next three days, I will be attending an electronic hardware industry trade show (DesignCon 2018), so I will have less time to work on OpenChrome. I will likely bring a laptop (my usual HP 2133 mini-note) to continue to work on the OpenChrome DRM code, but I do not expect to make that much progress for the next few days.

During December 2017, I wrote code for OpenChrome DRM to program the CLE266 and KM400 chipset families’ display FIFO registers when performing a mode setting. I noticed some time ago that OpenChrome DRM was not programming the display FIFO registers at all for these chipsets (code was missing). This was leading CLE266 and KM400 chipsets to display artifacts on the screen after resuming from a standby. Unfortunately, I did not have access to VIA EPIA-M mainboard for several weeks, so I was not able to test the code before committing the code. Lo and behold, I put in the wrong register parameters for CLE266 chipset, and it made a display driven by IGA1 (think of it as display controller #1) to display a highly distorted screen.

Now, I have access to EPIA-M again, and I did put in a fix for OpenChrome DRM drm-next-3.19 branch. drm-next-4.15 or later branch will get the fix within a week.

As an added bonus (?), standby resume is now working correctly, and the artifacts I used to see after resuming from standby no longer shows up.

I am sure talking about money issues is not something visitors of this blog like to see, but I will like elaborate regarding this issue.

I started to work on OpenChrome one way or another sometime in Year 2015. If I remember it correctly, I bought a cheap (i.e., inexpensive) VIA chipset based laptop in early 2015 off of ebay for about $20 including shipping. It contained VIA C7-M processor and VN896 chipset (mobile version of P4M900 chipset). Soon, I realized that OpenChrome DDX does not really handle standby resume very well, so I wanted to fix that and move on. In my opinion, OpenChrome DDX’s code was not in a very good shape, so I started to fix various issues along the way. That’s how I got into developing OpenChrome, and I have continued working on it ever since.

I set up this blog, along with a PayPal donation link recently, in the hopes of monetizing the hard work I have put into the OpenChrome Project since Year 2015. If you have noticed that your VIA Chrome IGP based laptop’s flat panel is working after resuming from standby, that’s very likely because I fixed a lot of those issues (it is still not perfect, but it works with many more models than the past) since I took over developing OpenChrome. If you have noticed that your VIA chipset based thin client’s DVI port is now working, I resolved several remaining issues related to the chip (i.e., VIA Technologies VT1632A and Silicon Image SiI 164) used for the DVI port. Perhaps, you are an enterprise thin client user, and the improved reliability of OpenChrome allowed your firm to put off replacing VIA chipset based thin client for several more years, perhaps that is because I put in a lot of effort into improving OpenChrome. If these cases applies to you, it is highly appreciated if you can donate some money for all the hard work I have put into the OpenChrome Project.

Monetary donation does encourage me to continue working on improving OpenChrome, such as eventually bringing OpenChrome DRM into the Linux kernel tree (this year or next). I am an unusual developer who works on developing code for the underserved (i.e., old and neglected) graphics devices, and if you think about it, I am likely the only one who does this (most FOSS graphics stack developers are employed by major corporations like Intel, AMD, Red Hat, VMware, Google, etc.).

If you decided to donate some money to further develop the underserved graphics devices graphics stack, again, here is the PayPal donation link. If you have already donated to Brace Computer Laboratory, I appreciate the financial support I have received from you.

As promised, drm-next-4.14 branch is now EOL (End of Life). The new drm-next-4.15 branch is getting within a dozen commits of drm-next-3.19 branch. drm-next-3.19 branch is still being maintained in order to test OpenChrome DRM against VIA C3 processor and CLE266 chipset. Due to VIA C3 processor not having PAE (Page Address Extension), there aren’t too many Linux distributions I can run VIA C3 processor these days. I tried Debian 8 with Linux 4.13 rc5+ kernel, but unfortunately, it suffers from storage (i.e., hard drive) recognition problem after resuming from a standby, so it is practically useless as a test configuration.

In order for the drm-next-4.xx branch to catch up to drm-next-3.19 branch, I did use a faster computer to compile OpenChrome DRM. I used AMD Athlon 64 X2 based computer with ECS K8M890M-M mainboard. With -j3 option when compiling the Linux kernel (make -j3), I can now get OpenChrome DRM to compile in about 5 minutes as long as the Linux kernel is already precompiled (i.e., compiling OpenChrome DRM only). I think this is pretty good considering that it takes HP 2133 mini-note’s VIA C7-M processor about 25 minutes . . . VIA C7-M is a horrendously slow microprocessor . . . Anyway, this ECS K8M890M-M mainboard does not support ACPI S3 State correctly (it tells Linux kernel it supports S3 State during boot time, but in reality, it does not turn off the fans, so it appears to be faking the S3 State behavior of all the fans turning off), so I do not really like it as a mainboard. One thing I never liked about ECS is that for some reason, they do not support ACPI S3 State with Taiwanese chipsets (i.e., VIA Technologies, SiS, etc.), but supports it with Intel or NVIDIA chipsets. I do not buy the notion that VIA or SiS chipsets’ ACPI S3 State implementation to be broken since major vendors like ASUS, GIGA-BYTE, MSI, etc. have supported them since Year 2002 or so.

Anyway, it appears that VIA K8M890 chipset’s Chrome9 IGP has only one hardware cursor instead of two for newer chipsets (i.e., P4M900 chipset). What this means is that when operating in a dual head configuration, X Server has to activate software cursor or one of the screen will not have a cursor displayed. At this point, OpenChrome DRM’s hardware cursor support for K8M890 chipset is broken. I am now actively trying to figure out a fix for this issue since I cannot really test OpenChrome DRM on K8M890 chipset too extensively due to the missing hardware cursor making the computer very hard to operate.

I just committed the drm-next-4.14 branch to the upstream OpenChrome DRM repository. As a result, drm-next-4.13 branch is now EOL (End Of Life). No more development is planned on drm-next-4.13 branch. drm-next-4.14 branch has a lot of catching up to do with drm-next-3.19 branch since its version is at 3.0.70 right now.

drm-next-4.13 branch was an important branch since I jumped from Linux 3.19 rc6+ kernel to Linux 4.13 rc2+ kernel and eventually to Linux 4.13 rc5+ kernel. It look about 40 days to figure out why OpenChrome DRM was not working. 14 version jump is really hard for a newbie developer . . . This commit finally fixed the bug that was leading to the crash during boot time. Interestingly, a developer from Huawei got hit with the same bug, and I will imagine that he was doing the same thing I was doing (i.e., porting an old DRM to a new Linux kernel). I knew about this flaw since September 2017, and during XDC2017, I told one major AMD developer present that I was planning to contact another AMD developer who appears to be the author of commit (ea642c3216cb2a60d1c0e760ae47ee85c9c16447) that caused this callback table null pointer reference bug. I forgot to send a “strongly worded” e-mail to this AMD developer. At least the bug will now be fixed with Linux 4.16 kernel. Perhaps, I can still send it, but it will not be so strongly worded anymore.

Going back to drm-next-4.14 branch, probably within a week, it will be updated to drm-next-4.15 branch, and drm-next-4.14 branch will be EOL instantly. I do realize that OpenChrome DRM’s drm-next-4.xx branch is still not on the correct Linux kernel (since the drm-next-4.14 is on Linux 4.14 rc7+ kernel, it should really be called drm-next-4.16), but I got distracted with various events during November and December 2017 that I did not really update the Linux kernel the bleeding edge of OpenChrome DRM should be using. I am now trying to catch up as soon as possible so that drm-next-4.xx and drm-next-3.19 will track each other closely.

So, how did it go? Well, it did not work. But thankfully, it was due to an initialization bug of OpenChrome DRM. I was able to read kern.log located at /var/log/ and that appears to be the case. In other words, the issue is fixable. The version of OpenChrome DRM I tried is Version 3.0.57. This is the current bleeding edge of drm-next-4.13 branch.

I wanted to get a confirmation that this USB flash storage device is going to work with OpenChrome DRM, so I sticked into another computer with ECS VX900-I mainboard. Fortunately, it worked like a regular computer with a hard drive / SSD. I tested standby resume, and unfortunately, the display (VGA) got disrupted. It appears to be a fixable bug.

From my own testing, I got OpenChrome DRM to work on VX800 chipset based mainboard called VIA EPIA-M830. I will assume that OpenChrome DRM was not really tested on VX855 chipset by the previous developer, and I will need to go fix the bug down the road.

Sort of related to yesterday’s OpenChrome Project “plugfest” (Since I am using that PCI-SIG term, I still seem to have some residual interest in wanting to work as a ASIC / FPGA design engineer . . .), I did bring Wyse Vx0 (not sure the exact model) and Wyse Cx0 (C10LE) with me.

The thing is, even though I work on an underserved (neglected) graphics device like VIA Chrome IGP, I do not really like thin client type devices. This is because thin clients often have only 1 GB or so local storage, and in order to comfortably develop even OpenChrome DDX requires about 8 GB of storage if you include even a stripped down OS like Lubuntu and a decent IDE like Eclipse.

About a year ago, the same friend who gave me the Wyse X90L mobile thin client showed me how one can straight install (“straight install” in this case means not having to perform extra steps to get the device functioning properly) Linux based OS to a USB flash storage device. What he told me was that if the USB flash storage device identifies as a USB hard drive, most likely one can boot from that device and can function like a device booting from a regular hard drive or SSD. I have been dealing with x86 based PCs and Linux for some years, but I did not know that you can do this.

The 16 GB USB flash storage device he gave me was SanDisk Cruzer Refurbished edition. I find this sort of scary considering that flash memory inherently has write endurance issues. Plus, I assume most USB flash storage devices sold out there are based on TLC 2D NAND flash memory. So far, the device has not failed (it contains Lubuntu 12.04), so I guess I am okay with it for now . . .

Going back to the whole thin client world, it is sometimes pretty hard to obtain VIA Technologies Chrome IGP based devices that are not thin client based. This is because VIA’s silicon devices were not that competitive against Intel and AMD starting around Year 2005 or so even at the low end of the PC market, and therefore, they had to seek markets other than PCs. Since thin clients do not require too much performance, it was a fairly safe niche VIA was able to milk it until Intel Atom processor showed up around Year 2008 or so and ARM camp significantly improved the performance of their licensable processors (i.e., Cortex A series).

Now that I know that I can boot Linux off of a USB flash storage device and I have to deal with thin clients for validation reasons, I guess I will go with this idea of installing Linux on a USB flash storage device, but I cannot stand the idea of frequent writes (i.e., kernel log files) to a TLC 2D NAND flash memory based USB flash storage device causing eventual data errors. I decided to solve this issue by paying more for the USB flash storage device, and hopefully the device vendor will use higher write endurance flash memory.

A little over a week ago, I purchased SanDisk Extreme 64 GB USB 3.0 flash storage device for about $32.99 + sales tax over at Micro Center (it is being discontinued with a newer product). It comes with a lifetime warranty and that is why I choose this one. While writing this blog post and the previous one, I was compiling OpenChrome DRM with a much newer generation computer (I did not use my VIA processor + chipset computer to compile the Linux kernel for this occasion. In other words, I cheated.) that has USB 3.0 support. I do have to admit that it was really fast. I am now ready to test OpenChrome DRM with Wyse C10LE (VX855 chipset). This is really the first time I am trying this (validating in development DRM with a USB flash storage device). I will report the results maybe tomorrow or so. Stay tuned.

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 . . .

I wanted to summarize what happened with the OpenChrome Project at the end of 2017, but unfortunately, I did not have this blog (Brace Computer Laboratory blog) set up at the end of 2017. I guess I will go ahead and do a late year end review about 2 weeks behind schedule.

During 2017, the following major events happened with the OpenChrome Project.

• Release of OpenChrome DDX Version 0.6
• Made some progress on the upcoming OpenChrome DDX Version 0.7
• Succeeded in porting OpenChrome DRM to Linux 4.13 kernel
• Reviving the Development of OpenChrome presentation at XDC2017

Most of my development effort started to shift to OpenChrome DRM starting around July 2017. Since then, about 90% of my development time has gone into OpenChrome DRM development and most of the rest to OpenChrome DDX development. I also started to work on a generic DRM for other forgotten graphics devices I discussed during XDC2017 presentation (i.e., SiS, S3 Savage, Trident, Matrox G series, ATI Technologies RAGE 128, etc.), but that work has somewhat stalled towards end of the year.

Hi there. This is Brace Computer Laboratory’s (BCL) first post. Brace Computer Laboratory (BCL) blog will write primarily about the following computer / electronics related topics.

• Open source software development, with a particular emphasis on graphics stack development like DDX (Device Dependent X) and DRM (Direct Rendering Manager) device drivers for Unix like OSes (i.e., Linux and BSD)
• Electronics repair, particularly computer related
• Reviews about the computer hardware related to open source software development projects

Although I am late by almost 2 weeks, I will be posting about the progress I made with the OpenChrome Project during 2017 soon.