Yesterday when writing about VIA Technologies preparing a new graphics open-source push, it made me curious where the S3 Graphics Linux driver is at today.
Here's a very unexpected but welcoming surprise for the holidays: there's some source code that's about to be released by VIA Technologies.
For any unfortunate Linux souls still stuck with VIA hardware, here's a status update about the OpenChrome driver project for providing an open-source graphics driver for VIA integrated graphics processors.
Back in January I heard from VIA that their open-source Linux strategy / support was basically dead. They don't have the resources or justification to do the work any longer, and their Linux TODO list was basically shot. In the years since they announced they were trying to become open-source friendly (and follow the steps of ATI/AMD), they only managed to push out some partially open-source code and some chipset documentation. But could they be playing around with open-source graphics drivers again?
While the Intel, Radeon, and Nouveau DRM drivers are now mature with kernel mode-setting -- and the Intel Poulsbo KMS driver is even getting ready to leave the staging area -- there's still one fairly common name missing from the desktop Linux KMS scene: VIA Technologies. While VIA defenestrated their open-source efforts and completely blew their TODO list, James Simmons, an independent developer, has basically been the community VIA development source.
James Simmons has written a status update to the OpenChrome development list concerning his ongoing work towards enabling kernel mode-setting (KMS) support for VIA hardware with this community-maintained VIA Linux project.
In the KMS (kernel mode-setting) world there is not only news today to report on a new open-source Freescale KMS driver, but on the state of VIA's kernel mode-setting driver. VIA Technologies may have killed off their open-source strategy, but for the past number of months there's been a developer writing a VIA KMS/TTM DRM driver that would work with the OpenChrome user-space X.Org driver.
The xf86-video-chrome driver, which is the open-source VIA Linux X.Org driver from the One Laptop Per Child project, now says their driver is "stable" after fixing up some rendering bugs.
While the group behind the One Laptop Per Child (OLPC) child ended up writing their own VIA Linux graphics driver, which is further fragmenting VIA's nasty Linux situation, James Simmons now has his OpenChrome-based VIA DRM kernel mode-setting driver working from the OLPC hardware.
VIA's small Linux development community is badly fragmented; there is yet another group of developers creating their own VIA driver. I wish it was a joke, seeing as there are already a number of drivers for the same VIA chipsets and none of them are feature complete or in really great condition, but a new driver has been released. This time the new driver comes from the OLPC (One Laptop Per Child) crew and it's just being dubbed xf86-video-chrome. Not only though is there yet another X.Org driver, but it's bringing its own kernel DRM.
Thanks to James Simmons, an independent developer in the open-source community, last month a patch was published that adds TTM/GEM memory management support to the VIA DRM Linux kernel driver. This was after VIA basically admitted defeat for their Linux / open-source strategy. Over the weekend the second version of this TTM/GEM patch was published by James.
While it was just a couple weeks ago that a VIA Technologies representative had admitted to me their Linux / open-source strategy is basically dead (and they had failed in delivering their Linux goals for 2010), it seems that today the first Chrome 9 (VIA VX900 IGP) documentation has been released. It appears to originate from VIA Technologies but this public release is coming to the community through the OpenChrome driver project. This documentation covers the 2D, 3D, and video engines for these integrated graphics processors.
Just one month ago an independent developer began working on VIA TTM/GEM support for the VIA kernel DRM driver along with VIA kernel mode-setting support, even while VIA's open-source Linux strategy is dead. Just a few weeks later, James Simmons' VIA TTM/GEM memory management patches are now ready.
While VIA defenestrated its open-source Linux graphics driver strategy, there has been some recent work under-way on providing a GEM/TTM + KMS driver for VIA's integrated graphics processors by the community. In particular, this work is being done by James Simmons, the former Google Summer of Code student developer who was working on 3Dfx kernel mode-setting support a few months back.
For those that were hoping that VIA Technologies would pull through in providing their open-source graphics driver support like they had promised with kernel mode-setting, a Gallium3D driver, and being Linux friendly, kiss those thoughts goodbye as they've been basically thrown out the window. Sadly, it's not happening. I had a very productive conversation with VIA's Stewart Haston, who is their international marketing specialist, and their Linux outlook is extremely dark.
While VIA isn't working on their Linux graphics support, they are continuing to design new hardware. For the Consumer Electronics Show in Las Vegas, VIA Technologies has just released their Nano X2 Dual-Core CPU.
At the end of December we reported on the 3Dfx KMS Linux developer working on VIA code to provide kernel mode-setting support for VIA's IGPs in the Linux kernel and thus TTM/GEM memory management support too. This is after VIA had promised to deliver this support (along with Gallium3D support) in 2010, but failed miserably. This code though is now moving along but without any support for VIA.
Not only has Intel's Sandy Bridge met the world today, but VIA Technologies launched the VIA eH1. The VIA eH1 is a discrete graphics card for PCI Express systems, but will it work with Linux?
With VIA not really doing anything for open-source and Linux as all of their efforts seemed to have stalled, the small open-source development community centered around VIA has become quite fragmented as we have talked about multiple times now. There's multiple X.Org drivers for VIA, with not a single one clearly dominating or being feature-complete and well maintained, while other areas like the DRM/KMS and Mesa/Gallium3D support are just in shambles.
One year ago VIA came out with their Linux TODO list, which was disappointing. This list had a VIA TTM/GEM memory manager module for Q2'2010, a kernel mode-setting driver in the works for H2'2010, and a Gallium3D driver in-development for Q4'2010. Even meeting this TODO list would be bad as the support most Linux customers are after (3D and KMS to a lesser extent) would not be arriving until three years after VIA announced this newest Linux strategy. But, VIA has failed miserably in accomplishing any of these mile-stones for KMS and open-source 3D acceleration support. Though resulting in VIA's Linux community being fragmented even more, new VIA X.Org (DDX) drivers seem to keep popping up. If there wasn't already enough of these not-fully-working and rarely-touched open-source drivers, another VIA Chrome X.Org driver has been started recently that's a fork of another open-source VIA driver.
Last night when checking to see if VIA has made any open-source / Linux progress that went unnoticed (they haven't), that also led me to see what S3 Graphics is up to these days. S3 Graphics doesn't back any open-source driver strategy and they don't have many GPUs on the market, but their binary Linux driver claims to support OpenGL 3, VDPAU, and even kernel mode-setting since last year.
While other hardware vendors are constantly improving their open-source support, this isn't the case for all vendors. VIA's open-source Linux support is still in very bad shape -- two and a half years after they had envisioned themselves becoming open-source friendly.
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.
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.
Back in 2008 there was the announcement from the Linux Foundation Collaboration Summit in Texas that VIA had joined the open-source driver bandwagon after having abandoned previous open-source attempts. However, for the past two years, this has largely been a media bluff. VIA Technologies did things like appoint an open-source liaison (Harald Welte, who is actually no longer contracted by VIA and didn't even do much for their efforts), launch a VIA Linux web-site (that is ill-maintained and two years later there are still portions of the site "under construction"), but they have done some things like put out some code and republishing old documentation. We're almost half-way through 2010 and it doesn't look like VIA will be doing much this year for their open-source graphics drivers.
A few weeks back we shared VIA's Linux TODO list, which was very disappointing to say the least. VIA Technologies has gone through several phases of trying to be "open-source friendly" and they certainly try to brand themselves as such, but it's still going to be a year (or longer) before they have a viable open-source driver stack and by that time the VIA hardware that's supported will be dated. Read the above-linked article for all of the details on the matter. This morning, however, VIA Technologies has let their puppets with the OpenChrome driver project release some new documentation -- but this documentation is not actually new.
A month ago we shared that VIA tried again to push some new DRM code into the mainline Linux kernel. This was months after VIA Technologies had already tried multiple times pushing new Direct Rendering Manager code for its hardware into the kernel, but failed for various reasons. With this latest attempt, the patches received no comments nor were they accepted into the mainline tree. However, this morning they have finally received some comments.
Earlier this year Luc Verhaegen, one of the key contributors to the RadeonHD graphics driver, was laid off from Novell after a round of cutbacks at their German facility. While remaining unemployed, Luc has contributed to the CoreBoot project with ATI graphics card flashing support and native VGA text mode support, among other work. Additionally, he continues to dabble with his own open-source VIA driver, xf86-video-unichrome.
Last December the Linux folks at VIA Technologies had released their Chrome 9 series DRM code, which is needed for Linux 3D support with these newer-generation VIA IGPs, but this initial version ended up getting rejected from inclusion into the mainline kernel on the basis of the rest of VIA's 3D stack for the Chrome 9 being closed-source and some problems with the code itself. The situation was similar to that of Intel's Poulsbo DRM being rejected from reaching the mainline Linux kernel earlier this year.
While VIA's Chrome 9 DRM has yet to be accepted into the mainline Linux kernel since its mostly used by VIA's binary-only driver and then recently an updated 2D driver, with the viafb driver outside of X.Org, this frame-buffer driver has picked up many improvements with the Linux 2.6.32 kernel.
88 VIA news articles published on Phoronix.