VIA Releases 16K-Line FOSS Framebuffer Driver

billybob2 writes "VIA has released 16,434 Lines Of Free & Open Source code that enables Linux natively to use the framebuffer on VIA's graphics chipsets. This comes a month after VIA announced that it will provide Open-Source drivers and documentation on its Web site so that its hardware will work out of the box with Linux distributions. This gives VIA-powered systems that come pre-installed with Linux — such as the gPC, 15.4" gBook, CloudBook, and Zonbu — the ability to output graphics through digital connections such as HDMI, and probably makes them the best-supported framebuffers Linux has ever had. Look forward to documentation and X.org drivers from VIA as well in the near future."

Re:More like giving up

[Anonymous Coward]

So long as the community supports the driver well enough, why should we care?

Re:More like giving up

[edalytical]

How does a summary that reads "VIA announced that it will provide Open-Source drivers and documentation on its Web site so that its hardware will work out of the box with Linux distributions" translate, in your mind, to "Via just don't want to develop their Linux drivers anymore"?

The story sounds more like they are opening development up to the FOSS community, not "giving up". This should be applauded.

Re:Lots of code?

[Anonymous Coward]

it says 16,434

less lines same task = better.

I remember IBM used to (around about the same time they wouldn't hire guys with beards in the 80's) look at productivity by the lines of code instead of the task..off topic ramble...

Re:More like giving up

[DrSkwid]

There's more to the OSS world than Linux, I'd rather they released the docs than write a line of Linux code.

Re:Lots of code?

[Anonymous Coward]

(1) I think you vastly underestimate the complexity of modern framebuffer management. I know our game engine has several thousand lines of code just to manage page flipping in all the various combinations (different hardware, SLI cards, etc), and that is even with DirectX drivers doing most of the heavy lifting.

(2) Why are the first few comments so negative? First you criticize all the graphics vendors becuase they won't open up their code, then when VIA goes and *does* open up their code, the first reactions are so critical? What the hell? Just take it for what it is: a gesture of openness and an opportunity for the community to pick up VIA's code and maybe make some interesting things out of it?

long history of VIA refusing to release documntn

[Anonymous Coward]

for those with short memories it might be worth reading the many years of complaints and downright hostility between OS developers and VIA - VIA's Australian mouthpiece Fiona has promised many times in past that info would be forthcoming - never was - until they release sensible info on the hardware (including all the numerous mis-designs that the windoze package codes around) a good driver will be a pipedream

Re:Lots of code?

[beelsebob]

Hang on, you think more lines would be a boast? I would think *only* 16k lines would be the boast here.

Re:Patents and driver signing requirements

[pla]

In addition, Windows Vista 64-bit requires

Which has what, exactly, to do with a Linux framebuffer driver?

Sure, having the source, we could proably port it to the Windows world, but the Windows world has no shortage of drivers already. Granted, they don't always count as the most reliable option, but at the risk of sounding a tad snarky - You run Vista 64-bit, "reliable" doesn't really enter the picture.

Re:Lots of code?

[cheater512]

Making a chip output the console to HDMI with 16k lines?
Pretty cool in my books.

Re:More like giving up

[DrSkwid]

The world benefits from docs not drivers.
BSD and Linux drivers for framebuffers will be rather different.
VIA will never ever support my OS of choice (Plan9) and I don't expect them to, thats what the documentation is for. And no, source code is not documentation when it comes to drivers, it's one person's interpretation of what they read/fiddled with to get it to work. Porting drivers is more work that you seem to think.

Re:More like giving up

[Anonymous Coward]

Linux is by far the most popular OSS OS. *BSD is nice, but it can use most Linux things because Linux is open source as are the drivers.

I'm not exactly sure what you're trying to say there, but I read it as "BSD can just copy the source code from Linux". If that's the case, there's a technical reason why you're wrong, and a non-technical reason why you're wrong.

Most "Linux things" can run on BSD because they are both UNIX-like operating systems, meaning they both implement enough of POSIX to make porting back and forth easier than porting to a non-POSIX system. But that only works for user software. The underlying kernel architectures and code are massively different, and anything that has to interact directly with the kernel, such as device drivers, are significantly different between the two operating systems. It's nowhere near as trivial as you imply.

Secondly, even if it were technically possiblethe license for BSD and Linux aren't necessarily compatible. BSD kernels and (most) drivers are under the (shock) BSD license, which, for better or worse, is more lenient than the GPL. The result is that you can't copy Linux code into BSD kernels because BSD allows the source to be used in a closed source product, while the GPL doesn't.

Re:More like giving up

[Kjella]

There's more to the OSS world than Linux, I'd rather they released the docs than write a line of Linux code.

True, but I think it's easier to make working documentation out of working code than working code out of non-working documentation... Documentation is nice, but if you have someone that's already put it all together to form a driver I'd be happy not sad.

Re:More like giving up

[LizardKing]

I think it's easier to make working documentation out of working code than working code out of non-working documentation.

Sadly not. Most hardware documentation is wrong, and errata updates are the exception rather than the norm. However, understanding what the hardware was supposed to do from reading the documentation is often better than reading a magic number filled chunk of source code. Please note that this is not a criticism of the VIA code, which may be a model of well written and documented code ...

Re:More like giving up

[blind biker]

When did the FOSS community become this collection of curmudgeons? When a company releases code, it should be politely welcomed. After all, they didn't _have to_ but they still did, because there's this little light that open source software could benefit many instead of the few. And then a bunch of cranky and unpleasant douchebags find the nerve to complain? I can't believe this.

Re:Slashdot == press release wire

[bendodge]

Slashdot tends to gush whenever anyone does something nice specifically for the Linux community. Much of what Linux has in hardware support has been painfully achieved reverse-engineering.

Re:Lots of code?

[Pseudonym]

Except it doesn't really take that long to write 16K lines, [...]

It depends which 16K lines.

Re:Slashdot == press release wire

[mqduck]

Not sure why you're complaining. Heck, Slashdot would provide a community service to announce this as an official offer. "Open-source your hardware driver, get a free glowing review press release as a Slashdot story."

mod abuse?

[Anonymous Coward]

Dear /.,

I'm concerned that giving moderation access to most everyone is counterproductive. This didn't require any moderation at all. Flamebait? No. Redundant maybe, but not to the point that it's annoying. This should not have been moderated at all. The point of moderation is to find and highlight gems not bitch slap people at random.

Thanks,
Anon.

Comment removed

[account_deleted]

Comment removed based on user account deletion

Re:Patents and driver signing requirements

[KutuluWare]

Please can we stay even a bit on topic here? We're talking about a Linux Framebuffer Driver here. You can't use the Linux framebuffer device drivers on Windows because they're not Windows Drivers. That's ignoring the fact that Windows already has all the display drivers it needs to use this hardware, so claiming that VIA "won't support" their hardware on Windows is just ridiculous.

Taking some arbitrary good deed by a hardware vendor and tacking a cynical "I bet it doesn't work on Windows" doesn't make you smart or insightful -- it makes your just another slashdouche.

Re:More like giving up

[something_wicked_thi]

The world benefits from docs not drivers.

Right. It's good to know that I've been running my computer on docs all this time. No, docs just let you write more drivers.

Porting drivers is more work that you seem to think.

And writing drivers is more work than you seem to think. Do you honestly believe that writing a driver from scratch, given the docs, is easier than porting a working driver given the docs?

Re:More like giving up

[AstrumPreliator]

Exactly what I was thinking. It's as if an acquaintance shows up to your birthday party and he gives you a nice card and $20 and you just ask him, "Is this it?"

VIA wasn't obligated to do this for you, you aren't paying them, how about you say "thank you, we appreciate your help" and support their product. They may just help out the FOSS community more in the future. If you spit in their face then they won't do this sort of thing again.

Don't look a gift horse in the mouth.

A Win for Free Softare Either way.

[gnutoo]

What matters is that vendor support of free software is here to stay. This is a direct break in the Microsoft monopoly, as the Intel graphics effort was, and others will follow. Via realized it's more their best interest to have hardware that works than it is to try to extract control over people.

Size has nothing to do with this. If the code is small and complete, it shows that Nvidia and ATI never had much to offer and we should all wonder why they never bothered to cooperate. If the code is incomplete, more has been promised and will be delivered. All of this is great news.

Thanks VIA. Good graphics joins good power efficiency in the VIA appeal.

Re:Patents and driver signing requirements

[SanityInAnarchy]

For one thing, H.264 is patented.

I'm not sure entirely how this affects us. We wouldn't be implementing H.264 so much as calling the existing (patented) hardware implementation, right?

Unless, of course, they exaggerated how much hardware help they had.

In addition, Windows Vista 64-bit requires that all drivers that include a kernel-mode component be published by an established company, or the operating system will display unhideable "Test mode" banners in the four corners of the screen.

Is this something that it's impossible for the user to override? In other words, is the set of certificates or CAs hardcoded, or is it user-modifiable?

Regardless, I don't see how this affects us, either. These are drivers for Linux, so it's good that they're open. It means they can't be GPLv3, but neither can Linux itself. And it means we can't then port them to Vista 64-bit -- seems like a small loss to me.

Re:More like giving up

[SanityInAnarchy]

And why would you expect random software to know about and make calls to VIA's API? H.264 decoding isn't exactly a DirectX function as far as I know.

You know, it's really funny when people make statements like that, qualified with "as far as I know", and then turn out to be precisely as wrong as you could possibly be. [wikipedia.org]

No, it's not h.264-specific, but it is a generic way to provide any codec. So all they have to do is provide their own DirectShow h.264 codec, and every app that uses DirectShow codecs will have hardware-accelerated h.264.

At that point, if, say, Flash isn't using DirectShow (I don't know either way), then that will be their fault. But it looks like VIA didn't even try.

It's up to cryptography library writers/PMs to determine whether they want to fold VIA encryption acceleration into THEIR libraries.

Assuming they're supporting Linux, there are kernel drivers for various crypto algorithms, and I believe some can optionally use hardware acceleration where it's available. It would be trivial for them to at least enable that much.

In software, most crypto seems to be done by openssl or gpg, both of which have fairly centralized, well-established libraries.

So it's pretty clear what you'd have to do to get the crypto stuff supported by pretty much every Linux app that isn't statically linked.

Re:Patents and driver signing requirements

[tepples]

I'm not sure entirely how this affects us. We wouldn't be implementing H.264 so much as calling the existing (patented) hardware implementation, right?

Unless, of course, they exaggerated how much hardware help they had.

I bet that's the case. In the late 1990s, I sometimes had to endure slowdown caused by "modems" that were not much more than a sound card. They employed "host signal processing", which put all the modulating and demodulating into a driver on the CPU. Likewise, video codec accelerator chips might accelerate only a few steps, such as the frequency domain block transform, the motion reconstruction, and the YCC to RGB conversion, leaving the rest to the driver.

Re:More like giving up

[SanityInAnarchy]

And even then, I still can't use the h.264 acceleration.

Re:Slashdot == press release wire

[SanityInAnarchy]

This post just gushes about VIA.

Because VIA just did something awesome -- something we, as a community, have been pushing vendors to do for a long time.

Since when did slashdot become a site for vendors to have their sock puppets write glowing posts for them?

Since forever, as long as those vendors are releasing high-quality open source drivers.

"probably makes them the best-supported framebuffers Linux has ever had..." Give me a break

That's pretty much factually true, unless Intel drivers are better. Other than those two, just about all Linux video drivers are either reverse engineered -- which works pretty well, most of the time, but often features are missing -- or proprietary, which supports the features they feel like supporting, breaks frequently, and there's nothing we can do when it breaks -- I'm looking at you, nVidia.

If you don't think these are the best-supported framebuffers Linux has ever had, provide a counterargument.

Re:Patents and driver signing requirements

[ajs318]

H.264 decoding is a purely mathematical operation, which lies outside the scope of patentability. You might be able to patent a particular device capable of performing that operation, but not the operation itself. Any device differing substantially from the implementation described in the patent would not be covered under the patent.

You know, if you had a sensible legal system where lawyers could not demand a penny in payment before a verdict was delivered, then it would be much harder for unscrupulous corporations to drag out court cases to the point where people who are in the right can't afford to fight on. Just saying is all.

They would need to invalidate all patents

[tepples]

In January last year, a court ruled [wikipedia.org] that one of the patents on which H.264 is based was invalid.

We have to get all essential patents invalidated, or the H.264 format will remain encumbered by the patents that have not been invalidated. Even one patent is too much for Free implementations if the patent is not available for licensing in a manner compatible with free software.

Re:More like giving up

[Lead Butthead]

Sadly not. Most hardware documentation is wrong, and errata updates are the exception rather than the norm. However, understanding what the hardware was supposed to do from reading the documentation is often better than reading a magic number filled chunk of source code. Please note that this is not a criticism of the VIA code, which may be a model of well written and documented code ...

Basic problem is that with ASIC work being done in places like Taiwan or China (or for that matter, non-English speaking countries in general) the typical Engrish documentations are generally near worthless.