VIA's Linux Strategy Takes A Turn With Hidden Driver

Yesterday we reported on VIA's Linux dreams not materializing with their GEM/TTM memory management support still missing even though we are half-way into 2010 -- more than two years after VIA announced its most recent open-source initiative. It turns out, however, for what VIA views as its memory management work is actually done. VIA has inconspicuously handed over some of its code to the OpenChrome developers in order to create a new driver that has been dubbed the "openvia" driver. VIA has supposedly provided the source-code to an X driver plus TTM/GEM DRM, but this new project largely remains a hidden mystery.

VIA's Bruce Chang, who has been their face for this most recent open-source strategy, was contacted yesterday by Phoronix and he replied with an update regarding this work. According to Bruce, VIA has handed over source-code to an X driver that has GEM/TTM support to the OpenChrome developers with they along with VIA's "friends" have been migrating their code-base to this VIA code-base in order to create a unified driver for VIA's platform. In other words, VIA has its binary Linux driver, an xf86-video-via driver, there's long been the xf86-video-unichrome driver, the OpenChrome driver that was forked from xf86-video-unichrome, another driver that launched last year, and now there's this new driver that is marrying some new VIA code with OpenChrome. Does VIA & co think the more drivers the merrier? This new driver is being called "openvia", but Bruce says he still prefers to call it OpenChrome. The same developers working on this are also busy with an OLPC (One Laptop Per Child) project right now so their schedule might be delayed beyond VIA's earlier Q2 target.

The OpenChrome developers have this X driver and TTM/GEM code, but it is not publicly released by VIA Technologies, at least not yet. We've long known that VIA has been providing OpenChrome developers with programming documentation that's not available publicly via Non-Disclosure Agreements, but apparently they are sending over such "open-source" code too. Bruce writes, "Anyway, VIA will still share the TTM/GEM and further source we are having. In fact, the source code has been shared with free developers in Taiwan." When asked about who these "free developers in Taiwan" are, Bruce responded that "They are VIA's friends and belong to community. We support them hardware, code and something we are having."

VIA's GEM/TTM raw source code may not be available yet, but this married OpenVIA driver is not readily available either. Searching the Internet for OpenVIA, xf86-video-openvia, and other terms turns up barely anything. Even when looking on the OpenChrome's Trac system there was no mention of OpenVIA or on their mailing list. When Bruce was asked about this, "OpenChrome friends showed me the git repository before but I forgot it's address now," he replied. This really begs how much VIA is actually involved with the open-source development process if VIA does not even know where to fetch the code of their new driver.

However, with the help of Luc Verhaegen, the former RadeonHD developer at Novell who also works on the xf86-video-unichrome driver, we managed to find the Git repository to the DDX portion. It is not found on the FreeDesktop.org or OpenChrome servers, but it is found over in a personal GitHub repository. The commit history for xf86-video-openvia is sad with it just having two commits in the past two months. This year in fact there were only six commits that happened on three different days with three of the commits simply dropping code that was used in VIA's blob. Jon Nettleton appears to be handling this work. It appears that VIA had handed over this X driver code to OpenChrome developers back in early December of last year. This driver does evidently support their recent VIA Chrome 9 hardware too; however, this is all for their user-space side and we have not found the DRM code that contains the actual GEM/TTM bits.

In terms of this driver's future, apparently OpenChrome and VIA's friends out in Taiwan are going base their kernel mode-setting support upon this code base too. Bruce added in another message, "Internally, we are evaluating the G3D to identify its project scope." When elaborating on that, VIA is trying to understand the Gallium3D architecture and the connections between Gallium3D, the X driver, and TTM/GEM. According to Bruce's original timeline for this open-source VIA enablement, a Gallium3D driver is not being targeted until at least the fourth quarter of this year (see VIA's Linux TODO List... Maybe Look Forward To 2011?).

Let us hope that this new plan of VIA's will eventually work. Right now there is the source code to the xf86-video-openvia driver, but that already is not actively being worked on and just seems to be tucked away as some hidden project. There is few commits to this OpenVIA driver in its short life and their new TTM/GEM DRM code cannot be found and we have no idea what state that is in, but it is probably not pleasant. Once this code is found it will be another question whether it can actually be integrated into the mainline Linux kernel, unlike VIA's earlier attempts with having its DRM rejected. It's a pity that VIA nor OpenChrome know how to get involved with the open-source communities and to communicate their plans and intentions (i.e. so is xf86-video-openchrome now deprecating itself?), but rather leave this whole open-source VIA situation a murky mess. Stay tuned for more details.