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