Much has been said of the suitability of VIA’s Nano-, Pico-, and Mini-ITX mainboards for embedded and appliance computing. To a large extent, Linux has an application overlap in that domain. The combination of a modern Linux distribution with the small, yet powerful Mini-ITX platform is popular because the two are so well-suited to the challenges posed by an emerging set of applications requiring more computational power and platform flexibility than the embedded platforms of the past, but with much of the size, efficiency, and cost advantages that embedded applications have always sought after.
Thus, it is along this boundary that VIA’s EPIA mainboards will need to prove their viability as a platform for application development. Feasibility is largely a consequence of operating system support for the hardware. However, with open-source operating systems like Linux, implementing that support requires working with a community of developers. As VIA, like other manufacturers in the industry, continues to adjust to this model, the pace of development fluctuates rapidly. This is compounded by development upheavals in related open-source projects.
Historically, Linux support for the VIA Unichrome and Unichrome Pro families of graphics controllers has been highly indicative of some of these trends. I’ll investigate the events that led up to the current situation in this post.
This device list was compiled by the Unichrome Project:
- Originally named CastleRock. Found on the VIA CLE266 northbridge.
- First use of the name Unichrome. Found on the KM400, KM400A, KN400, and P4M800.
- Unichrome Pro, later renamed Unichrome Pro B, on the K8M800 and K8N800.
- Unichrome Pro A on the CN400, PM800, PM880, and PN800.
- Yet another Unichrome Pro on the P4M800Pro, VN800, CN700, and P4M800CE.
- Unichrome Pro on the CX700, CX700M, VX700, and CX700M2.
- Chrome9 IGP (but effectively a Unichrome) on the K8M890.
- Unichrome Pro on the P4M890 and VN890.
- Unichrome Pro on the CN750 and CN800.
- Chrome 9 HC IGP on the P4M900, VN896, and CN896.
I’ve provided the time line to the right for reference. Some of the historical details are hard to come by, but here’s what I’ve managed to piece together:
Several years ago, VIA had written a Linux driver for the Unichrome device present in the CLE266 chipset that it released in binary-only form. As anyone that’s been involved with the Linux kernel will tell you, binary-only drivers rarely last very long in the Linux community due to the simple fact that no one in the community can keep them up to date as the kernel continues to develop and interfaces change. This is equally true of XFree86 (and X.org). Eventually, VIA was convinced to release the driver in source form, and it did so. In April of 2003, this driver was imported into XFree86.
The XFree86 developers continued to improve the driver, and it remains in the XFree86 tree to this day. When X.org forked from the XFree86 tree in early 2004, the driver was carried over into the new fork, and the X.org developers, where it also continues to see active development.
VIA occasionally releases its own updates. Some of these updates are binary-only, and some are source releases. Not all source releases are licensed appropriately for inclusion into open-source projects.
In March of 2004, shortly after the X.org fork, the Unichrome Project was started. The purpose of the Unichrome project was to move forward with development of the driver that was currently in the X.org tree. It was to be a forum for more experimental development of that driver, and would contribute changes back to the X.org tree when they were deemed stable and appropriate enough.
As development progressed within the Unichrome Project, a conflict regarding development philosophy arose. While most of the developers were primarily interested in continuing to add features and support for new devices to the Unichrome driver, the founding developer wanted to pursue another path. Something of a driver purist, he wanted to strip out major driver features whose design he was dissatisfied with, as well as remove driver dependence on VESA BIOS Extensions (VBE).
This conflict resulted in yet another fork. In April of 2005, the openChrome Project was born. Its goal was to continue implementation of the Unichrome driver without introducing regressions.
After all that, the open-source community was left with the following driver
- VIA binary-only drivers
- VIA source drivers
- XFree86 driver
- X.org driver
- Unichrome driver
- openChrome driver
At this point, the VIA binary and source drivers are largely considered valuable
reference implementations, but not practically useful on most systems. Further,
since most modern distributions now ship with the X.org server, using the
XFree86 driver probably doesn’t make a lot of sense. Thus, the choices are
limited to the in-tree X.org driver, the Unichrome driver, and the openChrome
In my next post, I’ll look at the differences between these three drivers, the
limitations of each, and the what we can expect to see as development of each
driver carries on.