About Brace Computer Laboratory (BCL) Blog

Brace Computer Laboratory (BCL) blog writes 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 For all practical purposes, BCL blog is Kevin Brace's personal blog related to computer / electronics. As for myself, I am a self taught electronic hardware developer with specializations in external memory (DRAM) controller design and I/O subsystem (PCI and PCI Express) controller design. I am also quite experienced with Xilinx FPGA. I am fluent in Verilog HDL and VHDL based design (both RTL and verification, but prefer RTL). I decided to start this blog to publicize my open source software development projects I work on, but also to raise funds to support my open source software development projects. I specialize in developing code for underserved (i.e., old and neglected) graphics devices. At this time, I primarily work on OpenChrome (community developed device driver stack for VIA Technologies integrated graphics). I maintain (testing and code release) and develop OpenChrome. I also plan to develop code for other underserved graphics devices in the near future as well.

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.


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.

Status of OpenChrome Project (April 2018)

April 2018 was a modest month for the OpenChrome Project.

Following the successful March 2018, I went for implementing VIA Technologies VT1632(A) DVI transmitter support for OpenChrome DRM. While the feasibility experiment and coding portion took about 2 1/2 weeks, I could not figure out how to resolve the weird blue color issue, so the code did not get committed into the upstream repository. This is so weird because I was able to get integrated DVI transmitter for CX700 / VX700 / VX800 chipset to working fairly easily while back. This branch is now put on hold for the time being.

While the external DVI transmitter support is now put on hold, I still need to move the project forward, so I worked on the long overdue renaming of OpenChrome DRM .c and .h files.

While this does not seem important, I also figured out how to get Averatec 3250 laptop (KN400 chipset) to resume from standby. I just wanted to know how to do this just for testing OpenChrome DDX mode setting code to cope with standby resume. Fortunately, the latest OpenChrome DDX mode setting code can handle the flat panel reinitialization properly.

I have not posted a detailed blog post yet, but two of my A DATA Ultimate SU800 SSD (128 GB model and 256 GB model) died in a span of a week. The 128 GB model just died early this morning. 256 GB model died last week. 256 GB model always had issues. Both were virtually used exclusively inside the reliable HP 2133 Mini-Note. Unfortunately, the 128 GB model had the unfinished rewrite of GEM / TTM code. I will likely have to rewrite the code from scratch. Next time, I will store such important code inside the reliable SanDisk Extreme USB 3.0 flash storage (it is rather expensive, but comes with a lifetime warranty, so it is worth the money). I am disappointed with the quality of ADATA SSD products. I will write more about this soon.

Figuring out how to get Averatec 3250 laptop to handle standby resume on Linux (non-perfect method accidentally discovered!)

Some people might be wondering why I spend so much time trying to get old VIA Technologies chipset based integrated graphics to work on Linux. To answer that, I do not really have to work on this (no one is forcing me to work in this area), but I just want to contribute my computer related technical skills for the benefit of the society since Linux (and eventually xBSD) is still relatively underdeveloped compared to Microsoft Windows based platform.

Maybe this is pretty obvious to some, but the current lack of excitement surrounding Microsoft Windows based platform is that it is already a mature, stable platform, and there isn’t that much more to develop to make Windows interesting to many. It is already good enough for a lot of people, including me. As a one time microprocessor design engineer “wannabe” (I did officially study computer architecture within an Electrical Engineering degree program in college, although I learned far, far more on my own than from college. At this time, I do not think I will ever get hired by any firm that develops a serious microprocessor since I do not I belong to a “group” that fits the profile of a typical microprocessor design engineer of Year 2018. Hence, the use of a term, “wannabe.”), I think Intel has the same issue with x86 architecture. x86 architecture based platform already is good enough for most people, therefore, I do not see too many people buying PC mainboards at Fry’s Electronics these days (“Components” section is pretty empty most of the time when I visit Fry’s.).

It is strange to confess this, but I am actually not a huge Linux / xBSD fan, and sometimes I find it pretty crazy that internals of Apple macOS (formerly MacOS X) is actually BSD based. I always thought making non-computer technical people to use Unix based OS to be something of a selling snake oil to non-technical people. As for myself, it really took me working on OpenChrome graphics stack to get myself to regularly using Linux, and prior to that, I really hated using Linux since the device driver reliability is far worse than of the Windows platform (i.e., standby resume reliability, device automatic detection, regression between versions, etc.).

I probably should get to the relevant subject matter of this blog post finally, rather than ranting about some unrelated matters. Ubuntu 18.04 was released a few days ago. For my first official installation of non-beta Ubuntu 18.04 based OS, I decided to try it with Averatec 3250 laptop first. I discussed this sick puppy laptop about two weeks ago here. I do test many VIA integrated graphics chipset based computers, particularly with standby resume, but perhaps this one is the buggiest of all I have seen so far with VIA chipset. Because of this, it seems really waste of even my time (I say like this because there are some people who think why I waste my own time still writing code for such old graphics hardware like VIA Chrome.)

After several crashes / freezes during Lubuntu 18.04 upgrade installation, I managed to stabilize the OS (I think). I think I got all the missing package dependencies resolved, although you never know. The computer still suffers from the weird systemd related entry into standby during boot issue discussed previously, but what I want to add today is how I managed to activate standby resume on Linux (Lubuntu) by accident on this laptop.

I have known for sometime that this laptop’s standby resume works flawlessly on Windows XP, but not on Linux. What I tried two days ago was that I first booted Windows XP, immediately restart the computer, and then without turning off the computer (warm boot), boot Lubuntu 18.04 with recovery mode afterwards. The OS will now enter Recovery Menu. There, select resume. Since the computer still suffers from the systemd induced standby, almost all the time, the computer will enter standby once or twice during boot. However, if I go through this procedure, most of the time, the computer will now successfully resume from standby!

So, with this odd “accidental” discovery (in some ways, all that time I spent on this sick puppy laptop was not in vain), I can proceed into what the developer of OpenChrome graphics stack (me) does all the time: Test OpenChrome DDX’s standby resume behavior.

Since I am now on Lubuntu 18.04, Canonical got OpenChrome DDX Version 0.6 by default (finally). Since we still have not gotten OpenChrome DRM to become mainlined, you will need to manually install OpenChrome DDX yourself (Essentially, Canonical does not perform default install of OpenChrome DDX since we still do not officially support KMS, yet.).

sudo apt-get install xserver-xorg-video-openchrome

From here, I install the latest OpenChrome DDX (as of today, Version 0.6.174) over the existing Version 0.6. This post has the instructions (a little dated, but still works). Of course, you will need to reboot after installing OpenChrome DDX for the new code to take effect.

So, how is the result? FP (flat panel) does get correctly restored as well as the VGA. This is really thanks to the countless hours I spent improving the OpenChrome DDX’s mode setting code for the past 2 years straight (I sound like I am bragging about this, but it is really my contribution to the code. I am proud of my work.). VIA Technologies VT8235M’s integrated Rhine Ethernet does go nuts after resume (i.e., you will lose Ethernet), but you can remedy this by reinstalling the VIA Rhine device driver.

sudo rmmod via-rhine

sudo modprobe via-rhine

I am currently compiling Linux 4.16 rc7 kernel with the latest OpenChrome DRM, in order to test standby resume with OpenChrome DRM. I hope it works (it should since critical portions of the FP mode setting code are essentially the same for both OpenChrome DDX and DRM).

For those who wish to use AMD Athlon / Athlon XP based computers with VIA Technologies chipset, I will soon compile a post about how to avoid various weird pitfalls with recent releases of Ubuntu based OS. Yes, many of them are the notorious SSE2 instructions related issues (Chromium / Firefox / Ubuntu’s installer).

Testing OpenChrome DRM on Wyse Cx0 thin client (standby freeze workaround)

Since I recently fixed a hardware cursor issue that affects VX855 / VX875 chipset (Chrome9 HCM), I am now fully able to test OpenChrome DRM against VX855 / VX875 chipset.

For this, I used Wyse Cx0 thin client. Unfortunately, I soon discovered that when I try to get the thin client into standby, it will freeze completely when it is trying to enter standby. This behavior is not observed on Xubuntu 16.04.4’s stock kernel (based on Linux 4.13). Since I was fairly confident that this is not an OpenChrome DRM bug, I looked into comparing this hardware to other hardware I typically use for testing, and I noticed that Wyse Cx0 thin client uses VIA Technologies Velocity Gigabit Ethernet chip for its Ethernet port.

I decided to remove the loaded VIA Velocity device driver the following way.

sudo rmmod via-velocity

Now the computer will correctly enter and exit standby! Actually, if I manually reinstall the VIA Velocity device driver during runtime after removing it manually, it can still enter and exit standby correctly as well.

sudo modprobe via-velocity

Strange . . ., this is the only Ethernet device driver that causes issues with standby that I have encountered so far.

All I want to say here is that not all the crash / freeze you may encounter is OpenChrome’s fault. Sometimes, it is another device driver / buggy ACPI BIOS.

How to get OpenChrome working on Debian 9

I got a user asking about having issues getting OpenChrome to work properly on Debian 9. The thing is, since Linux 4.5 kernel, vesafb, viafb, and vt8623fb frame buffer device drivers conflict with OpenChrome DDX, hence, they need to be blacklisted. In order to do this, you need to edit blacklist-framebuffer.conf configuration file located under /etc/modprobe.d/ as a root.

. . .
#blacklist tridentfb
#blacklist vesafb
#blacklist vfb
#blacklist viafb
#blacklist vt8623fb
#blacklist udlfb

Remove # before blacklist to blacklist the device driver. Do this for vesafb, viafb, and even vt8623fb. Reboot the computer and OpenChrome should be working.