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
_______________________________________________
Openchrome-devel mailing list
Openchrome-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/openchrome-devel
