How VIA Could Have Not Screwed Its Linux Chances

Written by Michael Larabel in X.Org on 25 May 2010 at 11:30 AM EDT. 21 Comments
Yesterday we reported on how VIA's open-source Linux dreams are not materializing and then this morning reported on a new secret driver being developed (xf86-video-openvia) between VIA Technologies, some VIA "friends", and the OpenChrome developers. However, as I said in this morning's VIA article, the situation is still a murky mess, this new OpenVIA driver isn't receiving much work, the DRM code with TTM/GEM memory management is still missing, and these open-source efforts by VIA are not very well organized.

VIA's Linux TODO list doesn't even offer hope for having kernel mode-setting support until later this year and any Gallium3D driver for offering OpenGL acceleration will not come until late this year at the earliest. If such code is delivered on time, it will likely not be until H1'2011 that this code is found in most Linux distributions like Ubuntu 11.04, which will be three years since VIA announced its most recent open-source driver strategy.

How though could have VIA avoided this mess when figuring out their open-source role? Well, here's a few things VIA could (and should) have done.

Improve Its Web-Site / Community Portal: Back in April of 2008 when VIA announced its most recent open-source initiative they had launched A couple files have been added since then, but for the most part there isn't a whole lot to look at. The bug tracking and forum sections of the VIA Linux web-site have been "under construction" since its inception more than two years ago.

The VIA Linux site really doesn't offer much value beyond offering download links for a couple of open- and closed-source graphics drivers and old DRM source code. They don't even reference any Git repositories, the OpenChrome driver they even partnered with, the original X.Org Unichrome driver, or this new xf86-video-openvia driver.

Beyond offering better download information or mentioning what VIA packages can be found in what distribution repositories, they should setup a Wiki or provide information similar to what's available with the Intel / ATI / Nouveau content available via the X.Org Wiki. Via the X.Org Wiki you can easily find information for other drivers on how to build it from Git, what games/apps work with a given driver, and the current status of the driver, among other valuable information. Right now all of this information for VIA's Linux offerings is just scattered around on Phoronix, among other locations on various web-sites. This just makes it a pain for any customers or potential customers to figure out what VIA hardware works under Linux, to what extent, and what hurdles may be encountered in getting the VIA IGPs to even mode-set with their favorite Linux distribution.

For VIA's bug tracking, they could be like all the other open-source Linux graphics drivers could use the BugZilla. If they are after community forums, we are more than happy to help them out on the Phoronix Forums. In fact, we already have an active VIA Linux forum.

VIA also doesn't use for hosting any of their source-code (like the other X.Org components), but the OpenChrome project uses their own SVN server and this new OpenVIA driver is hosted over on an unadvertised GitHub account.

The status quo for them now just leads to a higher barrier of entry for trying out and running the latest VIA Linux code and confusion amongst its potential customers to what is actually supported or working under Linux. VIA has no centralized source.

Hire A Professional: Shortly after making their 2008 Linux announcement, VIA Technologies announced that it contracted Harald Welte to be their open-source liaison. Harald has done good things for Linux and free software communities within the Linux kernel, creating an organization to track down GPL violations, and working with the OpenMoko project, but he hasn't played much of a role within the X.Org community. He really didn't do much while serving as this liaison for VIA and he no longer is even in this role.

VIA's own staff also isn't too involved within the X.Org community and its development processes (as can be seen from many mailing list messages where they are asking questions). VIA also goes unrepresented at X.Org conferences like X@FOSDEM and the annual X Developers' Summit. VIA could have hired or at least contracted an X.Org / Linux veteran to become involved, such as Luc Verhaegen.

Luc may have ambitious ideas and beliefs that go against the ways of other key X.Org developers, which often result in mailing list arguments and disagreements with other X.Org contributors, but he at least is familiar with the graphics driver development process and would have been a fitting candidate to work on community documentation and code. Luc is the maintainer of the original X.Org Unichrome graphics driver that he has worked on in his spare time for some years, was one of the key members of the RadeonHD driver and the open-source AMD proposal, and has other qualifications. This would have been similar to AMD picking up Alex Deucher when they began with their official open-source support a year earlier, in addition to AMD partnering with Novell for work on the RadeonHD driver.

It's not that VIA didn't know of Luc, but they had contacted him along the way to hopefully ride on some of AMD's open-source success. Luc was let go from Novell in 2009 during a round of German layoffs, but VIA Technologies still didn't offer up anything even when he had approached the company. The opportunity is now gone, but they could have easily fetched him to move their open-source efforts along. If they didn't want to work with Luc, they could have approached Red Hat for a business deal where they have many skilled developers with a forte for Linux graphics.

Seed Hardware To Developers: If VIA Technologies doesn't want to hire any employees or contractors (or doesn't have it within their budget), they can at least offer up VIA hardware to active open-source developers. This would certainly motivate such developers and make them more likely to work on VIA support with greater hardware availability. Some of the most notable open-source VIA work to date has been from community developers, such as VMware's Thomas Hellström getting TTM to work with OpenChrome in a branched version.

From Bruce's email to Phoronix last night, it appears that VIA does send some hardware to their "friends" in Taiwan, but this situation isn't clear and it appears those community developers are bound by Non-Disclosure Agreements.

Kill, Open The Blobs: While they may not be able to open-source their entire binary driver code-base due to third-party licensing, not wanting to cause any Digital Rights Management problems, or exposing some sensitive areas, they could at least open-source a majority of their currently closed-source code. Even if it's not in a usable, it should prove to be of use in jump-starting any kernel mode-setting (KMS) or Gallium3D driver efforts within the community. If they diverted their limited development resources away from working on their binary drivers, which are also of very poor quality, their open-source drivers could get greater attention.

With the xf86-video-openvia driver and new but unreleased DRM code it looks like they may be doing this somewhat, but it's years too late to do real good especially when their community developers are limited and not too active.

Actually Do Something: VIA's open-source / Linux work really seem to be a part-time effort at the moment. Documentation and code drops are far from frequent and there really isn't even much communication with the community or other X.Org developers. We do know that VIA Technologies does have more documentation ready than what has been publicly released, but through an NDA they have been funneling some of these documents to OpenChrome developers.

It's a rare occurrence to see any VIA employees write on the OpenChrome, X.Org, or Mesa mailing lists. You also don't see them engaging with their user-base or community, such as responding to questions on message boards such as ours. This is while, AMD for example, has John Bridgman very frequently answering questions of our readers along with Alex Deucher and they are both active on the ATI/X.Org/Mesa mailing lists too. Alex also occasionally writes about graphics driver programming and other topics on his personal blog. VIA also does not appear or represent itself at any X.Org conferences or other Linux development events.

Of course, these suggestions just hit the tip of the iceberg for how VIA Technologies could better improve their open-source Linux support, but sadly we doubt VIA Technologies will finally learn (even though they have failed in the past) and implement any striking changes to make it a really viable option for those consumers interested in open-source Linux graphics drivers. You can share your thoughts for how VIA could improve its Linux image via the discussion link below.
Related News
About The Author
Michael Larabel

Michael Larabel is the principal author of and founded the site in 2004 with a focus on enriching the Linux hardware experience. Michael has written more than 20,000 articles covering the state of Linux hardware support, Linux performance, graphics drivers, and other topics. Michael is also the lead developer of the Phoronix Test Suite, Phoromatic, and automated benchmarking software. He can be followed via Twitter, LinkedIn, or contacted via

Popular News This Week