In late 2009 an article was published entitled VIA's Linux TODO List... Maybe Look Forward To 2011? where we looked at their actual efforts since their 2008 open-source announcement and then at their newest TODO list they had shared with the open-source community. In that TODO list, VIA's Bruce Chang talked about "VIA has been having a dream to host VIA's developing source in public" and that they plan for a TTM/GEM module in Q2'2010, kernel mode-setting for VIA in H2'2010, and a VIA Gallium3D driver in Q4'2010. At least publicly, however, there is not much work going forward and this is far from going as planned where back in 2008 VIA had said in their original announcement they would be providing quarterly driver updates.
We're more than half-way through the second quarter and there are no signs of any TTM/GEM memory management support being imminent. Even if something were to materialize before the end of June (but we wouldn't bet on it), there may be waiting until the Linux 2.6.36 kernel for the DRM code with memory management support to be accepted into the mainline Linux kernel unless it's accepted late in the 2.6.35 cycle -- the merge window is open right now but not for much longer.
If VIA does publish new Direct Rendering Manager (DRM) code that offers Graphics Execution Manager / Translation Table Map support for in-kernel memory management on VIA hardware, it may be another challenge just to get the code accepted by the open-source developers. VIA's previous efforts to inject their DRM into the Linux kernel have been rejected multiple times for various reasons from code problems to there not being open-source drivers (but rather VIA blobs) that actually take advantage of the DRM.
Having DRM code with proper memory management support is a prerequisite for having kernel mode-setting (KMS) support and a Gallium3D driver, so this may in turn end up delaying the rest of VIA's open-source schedule too. This is all while VIA has said they will not provide an open-source Chrome 9 3D driver and that they were looking for the community to make them a Gallium3D driver. On top of this, VIA still has yet to provide any new code or documentation for their newest chipset -- even just for basic DDX mode-setting support -- and code/documentation is still missing for older ASICs.
VIA's open-source efforts are still lousy at best as they just continue dreaming of being "open-source friendly" and playing the Linux community. They really aren't much better than NVIDIA's open-source strategy, which consists of recommending the VESA driver until their proprietary driver can be installed. At least with NVIDIA there is an active community (Nouveau) that's doing the reverse-engineering work and open-source enablement.
We'll keep monitoring the situation and also see if VIA has anything to say on the matter. So far this is just looking like VIA's open-source attempts from years earlier where they just ended up dropping open-source support.