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.
Back in June, VIA Technologies rolled out its Chrome 9 DRM (for a second time) in hopes of pushing it into the mainline Linux kernel. At that time, VIA's DRM was again rejected and it led to a discussion over partial open-source drivers since the only user of this interface was their binary-only driver.
It has been a while since we last had any major to report on VIA with their open-source efforts, but this morning they have finally published DRM code that supports their Chrome 9 IGP hardware. The announcement regarding this new Chrome 9 DRM was made on the dri-devel list and was made up of three patches.
Back in November we saw the launch of the S3 Graphics Chrome 530 GT and with that they talked up a new magical Linux driver that would provide HD video acceleration support along with OpenGL 3.0 capabilities. But no driver was released, however, a day later it was confirmed by S3 Graphics that they were working on a new Linux driver. Their PR representative said the driver was to be released in December, but that didn't happen. In February they continued to talk up their Linux support but months later there still was no driver. However, that changed in late February when S3 Graphics did in fact roll out a new Linux display driver.
Last week S3 Graphics had released the Chrome 540 GTX, which is their newest and fastest PCI Express graphics card. Similar to when announcing the S3 Chrome 540 GT, in the Chrome 540 GTX press release they once again mention Linux support along with OpenGL 3.0 capabilities. However, they talk up Linux support, but fail to provide the support. We have just heard back though from S3 Graphics' Benson Tao, which is the one that previously told us there would be Chrome 500 Linux support in December along with a beta OpenGL 3.0 driver. What though did he have to say this time? His email is below.
S3 Graphics has announced this afternoon the release of the Chrome 540 GTX, which they advertise as "The World's Most Connected Hi-Def Card" with its HDMI, DisplayPort, and DVI connections. The Chrome 540 GTX runs at 850MHz, uses GDDR3 memory, and shares other features to the Chrome 530 GT that was introduced in the fourth quarter of 2008. In the press release announcing the S3 Graphics Chrome 540 GTX they once again mention Linux support... But is there any Linux support?
With VIA Technologies delivering on their promises by finally releasing 2D/3D documentation and driver code, and Tungsten Graphics creating a new VIA 3D stack for a client, there has been a lot to report on in the VIA Linux scene. Tungsten Graphics and VIA are both interested in creating a Gallium3D driver for the Chrome 9 series, Tungsten already created a feature-rich DRM and Mesa driver, and there is a lot of other work going on too. What's new this week is a build-able TTM-based OpenChrome driver.
Earlier this month we shared that Tungsten Graphics was creating a new VIA 3D stack for one of their clients. This new work has many improvements over the current Mesa and DRM code both on the technical level as well when it comes to what's supported for use by end-users. This morning the code for Tungsten's new support has been pushed out to OpenChrome.
Following the release of a new VIA 3D graphics stack by Tungsten Graphics, there has been a discussion on the OpenChrome development mailing list as to the next steps to take in open-source VIA support.
80 VIA news articles published on Phoronix.