[Openchrome-devel] [ANNOUNCE] Made progress in supporting UniChrome IGP on drm-openchrome

[Kevin Brace]

Hi everyone,

I have not committed the code yet, but I am happy to report the first major progress in developing drm-openchrome.
drm-openchrome is the DRI2 / TTM / GEM / KMS supporting DRM module for VIA Technologies Chrome IGP.
This was the work done previously by James Simmons until early 2015.
Originally, I was only interested in fixing OpenChrome's standby resume reliability, but since no one was developing OpenChrome around late 2015, I ended up taking over the development of OpenChrome DDX entirely.
As a bonus for obtaining OpenChrome DDX repository commit privilege, I also obtained drm-openchrome repository commit privilege.
    Anyway, around mid-July, I had a personal disaster 4 days after I got back from a long vacation, and as a result, I did not have access to my collection of VIA IGP hardware at my place (I did not initially intend to collect them, but I eventually end up doing so since I started to develop OpenChrome seriously. Note that I am not really a fan of VIA Technologies as a silicon vendor.) for almost 2 months. 
Partially because of this, I ended up buying HP Pavilion a800n desktop PC (KM400A chipset) at a local computer equipment liquidator (i.e., junk coputer hardware warehouse; Silicon Valley has several of them since so many startups fail and big firms periodically get rid of old equipment) when they were doing a 50% off sale. (I got it for $12.50 USD. The original price was $25. 50% off was the reason why I bought it.)
Anyway, I decided to make this box my drm-openchrome development box, but I soon ran into number of problems.
One of it was that someone who built Ubuntu 12.04 (and their derivatives like Xubuntu and Lubuntu) built one of the package used during installation with SSE2 instruction, and for some reason, the software was not preventing AMD Athlon XP from running through SSE2 instruction code path.
As a result, I could not install Lubuntu 12.04 for weeks, and in the meantime, I thought the problem to be VIA PATA device driver's bug or a damaged CD-R media.
To avoid the VIA PATA device driver, I bought a PCI PATA card with a Silicon Image chip, but then ISOLinux refused to boot due to supposedly having a buggy firmware.
I now had to figure out how to update the PCI PATA card's firmware, which was hard to find on the Internet due to Silicon Image having been purchased by Lattice Semiconductor. (A small 5% market share FPGA vendor struggling against Xilinx and Intel / Altera.)
Eventually, I found the last release firmware image on the Internet somewhere, and flashed the image via Windows XP.
Now, I am using Silicon Image PATA, but the installation problem persists.
Eventually, the issue turned out to be the SSE2 instructions bug of Ubuntu 12.04 installer.
So just for the record, VIA PATA device driver is innocent here.
    Since I had a bad experience of installing Linux 3.19-rc6 kernel over Lubuntu 12.04 (Linux 3.2 kernel) where the mouse (USB or PS/2) will not function, I explored Lubuntu 14.04 as a target environment for drm-openchrome development since Lubuntu 14.04 shipped with Linux 3.13 kernel.
Fortunately, this choice was a good one, and I was able to install Linux 3.19-rc6 kernel with drm-openchrome over Lubuntu 14.04.
However, I ran into another problem where the Linux kernel will kernel panic during boot.
It turns out drm-openchrome appears to require more than 512 MB of RAM for now (I consider this a bug.), and it was crashing due to it requesting too much RAM during boot up. (It was running out of RAM.)
I eventually resolved this by putting 1 GB of RAM, but now nothing shows up on the screen on HP Pavilion a800n.
I looked at the Xorg.0.log and drm-openchrome is successfully obtaining EDID from the monitor.
I struggled with this for several weeks, and made some code updates related to analog VGA RAMDAC, but nothing will display on the screen.
After that, I started to look into how OpenChrome DDX UMS code initializes CLE266 and KM400 chipsets, and compared that to how drm-openchrome does it.
It appears that James wrote the code from scratch (or VIA Technologies donated some portions of the code prior to James making changes to them) so drm-openchrome was definitely initializing CLE266 and KM400 chipsets differently.
That is when I noticed that drm-openchrome had only one way it was calculating the dot clock of the video display engine.
It was calculating it in a way that appeared to target only UniChrome Pro (K8M800 chipset) or later devices, and it appeared that the way it was calculating it was quite different from how OpenChrome DDX did it for UniChrome. (i.e., CLE266, KM400, and P4M800 chipsets)
OpenChrome DDX UMS code has two routines, one for UniChrome and one for UniChrome Pro or later devices due to changes in how PLL parameters are calculated.
It appeared that James did not put in the necessary code to correctly calculate the dot clock for UniChrome family.
So I ported the OpenChrome DDX UMS code's UniChrome PLL calculation code to drm-openchrome, and after 3 hours of intense coding work (had to make some changes to the code due to lack of float type variable support), I finally got Lubuntu 14.04 with Linux 3.19-rc6 kernel and drm-openchrome to boot up the very first test I did after adding the UniChrome PLL calculation code.
What this means is that if you have CLE266, KM400 (including KN400 and KM400A), and P4M800 (not P4M800 Pro) chipsets, you will be able to boot X.Org Server with KMS activated.
I think what happened here is that James probably did the drm-openchrome development without UniChrome based devices, and as a result, it never worked since he did not put the necessary code to correctly calculate the PLL parameters for UniChrome.
For those with CLE266 chipset wishing to test drm-openchrome, you will likely have to use Gentoo Linux since almost all CLE266 chipset based boards shipped with VIA Technologies C3 processor, which does not support PAE. (Page Address Extension)
Most 32-bit Linux distributions already require PAE supporting processors, and this makes it harder to test CLE266 chipset most of the time.
    Regarding the stability of drm-openchrome, it still has number of problems in terms of its stability.
For example, if I change the screen resolution from say, 1280 x 1024, to 1024 x 768, it will crash the OS completely. (kernel panic)
The code is definitely crashing inside the drm-openchrome when it releases memory related to TTM.
I know that OpenChrome DDX UMS used to have a bug where changing the screen resolution will lead to a crash, and this was fixed in OpenChrome Version 0.5 by me.
I probably should not criticize a past developer who disappeared completely here, but it appears that James never tested cases where the user will wish to change the screen resolution during runtime for both UMS and KMS code. (Users change screen resolutions all the time.)
Also, standby mode (ACPI S3 State) resume is also a death trap for drm-openchrome.
Standby resume now works fine on KM400 chipset for X.Org Server 1.11 (Lubuntu 12.04), but appears to have stability issues for X.Org Server 1.15. (Lubuntu 14.04)
I sort of suspect that OpenChrome DDX may not be at fault here.
    Regarding the performance of OpenChrome DDX with drm-openchrome, EXA acceleration is off, so if you try to move a large window on the screen, you will definitely see a really slow window movement.
This will make drm-openchrome useless to anyone other than a developer.
That being said, text and graphics rendering performance is nominally acceptable to me, at least when I am using HP Pavilion a800n. (AMD Athlon XP 3200+; 2.2 GHz)
If you try OpenChrome DDX with drm-openchrome on CLE266 chipset, it will likely be so slow to the point where it is probably completely useless, I would imagine.
    Regarding the development roadmap for drm-openchrome, I will need to fix this screen resolution change hard crash first before proceeding forward.
After that, I will need to add code to OpenChrome DDX to support EXA acceleration when mated with DRI2.
When I brought up resuming drm-openchrome over at dri-devel mailing list in August, I did not really get receptive responses from what I will call "senior" LInux graphics stack developers.
Two of them who responded recommended to abandon drm-openchrome completely, and start over from scratch.
I did not think this was reasonable (I did not respond further since I did not want to be seen as a troll.) since VIA IGP was feature wise comparable to Intel IGP from 815 chipset until 4 series chipset.
VIA Technologies had 12 generations of IGP, so abandoning James Simmons' code will mean losing multiple years of coding work. (James appears to have spent 4 years on drm-openchrome.)
We are not dealing with a new ARM-based SoC's DRM / KMS module here that has only a few members of the family to support.
On a separate note, I tried contacting Dave Airlie, who maintains DRM, but I got completely ignored.
I would imagine that I will likely be on my own for the foreseeable future, but I have done many development projects on my own throughout my life (in hardware design field where I come from), so I am used to this kind of an arrangement.
One major problem of drm-openchrome is that it is written for Linux 3.19-rc6 kernel, and it will not compile for newer kernels like Linux 4.2.
I will need to get the code updated against the latest Linux 4.9 kernel since that is the latest in development.
At this pace, I suspect that drm-openchrome will likely be mainlined probably around Linux 4.15 timeframe, I would imagine.
I would imagine that I will need the "senior" Linux graphics stack developers' help on the infrastructure side like updating the drm-openchrome's repository's code to Linux 4.9 kernel, but other than that, I will likely continue the development portion on my own for the next several years.
For initial display device support, it will likely be limited to analog VGA, DVI (both integrated and external transmitters), FP, and HDMI. (only for VX900 chipset)
I will likely add TV (VIA TV encoders) and DisplayPort (VX900 chipset only) support later.
TV support for OpenChrome DDX UMS code is also very poor right now, but I plan to work on fixing it after OpenChrome Version 0.6 release.
    Anyway, at least I got one computer working with drm-openchrome, so I will likely convert 2 more computers (my main OpenChrome development laptop and a newly obtained mini-ITX computer with TV out) to have Lubuntu 14.04 (or Xubuntu 14.04) with drm-openchrome in the next several weeks.
After the OpenChrome Version 0.6 release, I will start devoting more time to fixing bugs of drm-openchrome and add EXA acceleration when mated with DRI2.

Regards,

Kevin Brace
The OpenChrome Project maintainer / developer