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.

 

 

VIA Technologies VT1632(A) DVI transmitter support for OpenChrome DRM hits a snag

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.

My first attempt at supporting VIA Technologies VT1632(A) DVI transmitter on OpenChrome DRM

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.