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

Community support is often better than that given by companies, and now community support is possible. I think it's be difficult to see this as a bad thing.

Re:More like giving up

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:More like giving up

It's the way that they do it which is the problem. The C7 was widely advertised as having H.264 decoding ability, plus crytographic acceleration. It sounded perfect for a lot of apps, especially low power silent media centres.

Only problem is, it doesn't decode H.264 in hardware, at least not on Windows. The only option is to use a special version of mplayer on Linux: http://www.theinquirer.net/en/inquirer/news/2007/05/18/tiddly-mobo-doesnt-do-what-it-says-on-the-tin [theinquirer.net]

There are loads of posts on the Via forums about this. The cryptographic acceleration is next to useless as well, since nothing much supports it. Vendors should be expected to support the features they claim to have themselves, not rely on open source projects to do it.

Re:More like giving up

Only problem is, it doesn't decode H.264 in hardware, at least not on Windows. The only option is to use a special version of mplayer on Linux:

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. Indeed, isn't this why you have to install an H.264 codec in the first place?

There are loads of posts on the Via forums about this. The cryptographic acceleration is next to useless as well, since nothing much supports it. Vendors should be expected to support the features they claim to have themselves, not rely on open source projects to do it.

Absurd. You got what you paid for. It's up to cryptography library writers/PMs to determine whether they want to fold VIA encryption acceleration into THEIR libraries. This is true whether the library writers are targeting Windows or Linux. VIA is not responsible for the actions of third parties, though they do seem to be interested in helping these third parties support their hardware with as little trouble as possible.

Because they've played this game before.

Via has "supported" linux in the past, and all it amounted to was dumping some poorly written and undocumented code, and then not doing anything to maintain the code themselves, and not accepting accepting patches, not responding to queries for documentation/clarification from those that wanted to improve the drivers themselves.

I hope they are doing the right thing this time, and will gladly praise them if they do, but I can understand why some people would be skeptical until then.

Re:Because they've played this game before.

Will an article [phoronix.com] from phoronix.com do? They quote an irc conversation with Luc Verhaegen who started the Unichrome Project, and also quote what Xavier Bachelot, an Openchrome developer, told them in a message. They don't say what kind of message (email, irc, whatever). The article gives a very good overview of why people doubt what Via says until they have code and/or documentation in hand. Part of Xavier's quote is particularly relavent, "I certainly wouldn't want them to claim that they support Linux and FOSS, like they did several times in the past, and don't put their money where their mouth is." I don't know if this most recent release contains any unknown useful material and will reserve judgement until X dev's speak. Please note the phoronix article and quotes are from before this release.

Re:More like giving up

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:More like giving up

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.

Re:Patents and driver signing requirements

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:Patents and driver signing requirements

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

Even the much praised nVidia still lacks proper (read: in comparison with Windows) drivers

Huh? No. The nvidia linux binary drivers are actually nearly identical to the windows ones, nvidia actually use the same sources for windows/linux/solaris. Performance is slightly higher on linux for the same card, and various nvidia and arb extensions to opengl 2.x make up for any power-differences from directx10 (that's something gamer fanboys tend not to understand, the opengl 3rd party extension mechanism, allowing for a stable core and bleeding-edge goodies at once.)

Now, the fact they're binary sucks, but they're binary on windows too. nvidia cards are _heavily_ used in the "pro" 3D area, as is (believe it or not) linux - these days, engineering workstations running windows are the exception rather than the rule (at least here in euro-land).

The problem is, nvidia differentiates their pro vs. gamer 3D cards mainly by software changes in the drivers. That's the real reason they're leery of open-sourcing them - they lose their artificial market stratification. ho hum.

Re:More like giving up

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

Re:More like giving up

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

Plan9?

For some reason, that just makes me think of someone driving down the road in a Hydrogen-powered Fiat to work at a Texas oil field.

Re:More like giving up

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

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:Lots of code?

(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?

Re:Lots of code?

I think they're legitimate criticisms.

That said, I'm also going to seriously look at VIA the next time I build a MythTV box. You're never going to escape criticism, no matter what you do -- but VIA absolutely did the right thing there, and I applaud them for that.

Thank you, VIA. Looks like some genuine competition for Intel as the "most well-supported Linux video cards."

Re:Lots of code?

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

Re:Lots of code?

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

Re:Lots of code?

1. Why tout 16K lines? Why give an exact number? It's like it's a boast. Except it doesn't really take that long to write 16K lines, so it's sort of a weak boast.

Well, studies have repeatedly shown that a single developer only adds about 20 correct lines of code per day. Assuming this is high quality code that has been well-tested, those 16K lines of code are nothing to scoff at.

2. On the other hand, I wonder why so many lines simply to give me a framebuffer? The card has to be programmed into the right mode, sure, but how can that possibly require 16 thousand lines?

That was my first thought too.

Re:Lots of code?

Well, studies have repeatedly shown that a single developer only adds about 20 correct lines of code per day.

Absolute nonsense.

First, let's assume there is such a study, and your recital of the findings are accurate. There's no way you can say something like, "a single developer only adds about 20 correct lines of code per day". It just doesn't make any sense.

Even if you reword it to say, "the average developer..." you still have a fairly meaningless statement. That's like saying "the average basketball player cannot slam-dunk", which is true, but doesn't tell you *anything* about any particular basketball player. After all, the vast majority of basketball players are children and at-or-below average height people playing street ball. Even a reasonably tall person (say, 6'5"), is going to have a hard time dunking a ball without a lot of effort.

Back to the "studies" (studies? really?), they really only measure an average of whatever specific development teams they measured. For example, at the start of a project, you probably write hundreds of lines of code, and as the project approaches completion, you write less and less code, perhaps only a handful of lines per day. It also doesn't take into account some developers who have very little to contribute to a specific project (i.e., do they count the UI guy's code across the whole lifetime of the project? Will that developer bring the average down from the developers who add potentially hundreds of lines per day?).

After all, American's average 1.5 children per couple, or something silly like that, as well, but it's exceeding rare to find a couple that actually has 1.5 children.

Re:Lots of code?

I remember IBM used to (around about the same time they wouldn't hire guys with beards in the 80's)

IBM didn't hire guys with beards? Well that completely explains AIX.

Re:Zombu?

Welcome to Slashdot.

Re:Does "framebuffer" mean no HW acceleration?

If that were true, it wouldn't take 16 kLoC for a driver. With that much code, it's exposing quite a bit of hardware-specific functionality - which means hardware acceleration for something.