Missing From Linux 2.6.36: VIA's TTM/GEM DRM

The Linux 2.6.36 kernel is set to carry some much-anticipated changes like AppArmor integration, major VFS performance improvements, a likely Btrfs performance regression fix, and quite a few changes when it comes to the graphics Direct Rendering Manager code. Just when it comes to the Linux DRM code in this next kernel release there is quite a bit of fun with the Intel kernel driver better supporting Embedded DisplayPort and tracepoints for page-flipping and vblank, the ATI Radeon kernel driver gaining R600/700 tiling support / support for reading R600 thermal sensors / R300 through R500 Hyper-Z support, and the Nouveau driver supporting KMS with the GeForce GTX 400 series and better DisplayPort capabilities. While the Intel, ATI/AMD, and NVIDIA/Nouveau DRM driver improvements will excite a majority of the desktop Linux user-base caring about open-source graphics drivers for their hardware, it's not enough to excite everyone. In particular, VIA is still missing from the field -- more than two years after they announced a new open-source initiative and promised to better engage within the Linux ecosystem.

VIA's pledged a lot to the open-source Linux community since their April 2008 announcement at the Linux Foundation Collaboration Summit in Texas, but they haven't actually delivered on much. VIA's driver shortcomings can not even be summarized within a single article, so for those not familiar with the situation we recommend reading VIA's Open-Source Efforts A Bluff?, VIA Publishes 2D/3D Documentation & Partners With OpenChrome, VIA Will Not Provide An OSS Chrome 9 3D Driver, and VIA's Linux Dreams Are Not Materializing, among many other Phoronix articles.

At the end of last year, VIA published a Linux TODO list for their Linux graphics driver and its first action item was to have a TTM/GEM module for the second quarter of 2010. Well, we are now into the third quarter and even with the Linux 2.6.36 merge window now being open, there is no VIA TTM/GEM code ready for integration. It will not be until at least the Linux 2.6.37 kernel that we could see this code emerge, but that would a Q4'2010 roll-out. VIA was hoping to have kernel mode-setting support going in the second half of 2010, but first they must get proper kernel memory management support integrated into the kernel. Unless they manage to push a large swoop of code into 2.6.37, this is pushing back their road-map into 2011 for KMS and that's not even counting their Gallium3D driver that was supposed to be in development for Q4'2010. For end-users with the VIA DRM code not being in the Linux 2.6.35 or 2.6.36 kernels, this is already making it not an option for distribution vendors updating their operating systems anytime this year.

It was back in March when we learned that VIA was working on a hidden open-source driver and supposedly handed off some memory management code for Translation Table Maps (TTM) and the Graphics Execution Manager (GEM) to OpenChrome driver developers, but nothing has yet materialized for mainline integration. This hidden DDX driver (xf86-video-openvia) hasn't even been touched in Git since the middle of May, the OpenChrome development mailing list hasn't even been used since April, no code changes have been made to the OpenChrome driver in SVN in weeks, and most importantly there have been no pull requests by any of the open-source VIA driver developers asking David Airlie (the Linux kernel DRM subsystem maintainer) to pull in any VIA DRM code so that Linus Torvalds in turn could pull in this code from David's tree. There's not even been any recent discussions on the DRI development list or Linux kernel mailing list by VIA's representatives about getting to such a point.

VIA Technologies has attempted to push their DRM code into the mainline Linux kernel code multiple times in the past, but it's been largely held up by the fact that their DRM code is dependent upon using a closed-source user-space X.Org driver, but this is supposed to be fixed with the VIA and OpenChrome "partnership" and also this new OpenVIA driver. This older DRM code for the Chrome 9 hardware has also lacked any form of proper kernel memory management, which is ultimately holding back the rest of the driver stack. Even if VIA were to publish their new DRM code tonight, while the 2.6.36 merge window is still open until the first release candidate, it's likely that it still wouldn't even make the cut for this next kernel release. VIA should start pushing out code soon and engaging in discussion with the X.Org developers soon if they hope for even Linux 2.6.37 integration.

With the pace that VIA developers and their "friends" (as described by VIA's Bruce Chang) are working on this open-source Linux support, it will truly be a surprise if VIA is even able to deliver on an open-source Linux driver stack with kernel mode-setting and a modest Gallium3D driver for any of their hardware generations before Ubuntu 12.04 LTS in April of 2012, which would mark the four-year anniversary of this most recent VIA open-source initiative. There is also the possibility that we may never even see this code materialize if VIA Technologies were to go bust or they just abandon their failed open-source efforts like they have done in the past.