VIA Releases 16K-Line FOSS Framebuffer Driver 159
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."
16434! (Score:3, Funny)
Re: (Score:3, Funny)
Re: (Score:2)
Re: (Score:2, Funny)
Re: (Score:2)
Re: (Score:2, Funny)
A: The Canadian tourist only has *one* Canadian flag on his backpack.
More like giving up (Score:2, Interesting)
Via just don't want to develop their Linux drivers any more. Watch as support disappears now they don't have to.
Re: (Score:2, Insightful)
Re:Patents and driver signing requirements (Score:5, Insightful)
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: (Score:3, Informative)
Re:Patents and driver signing requirements (Score:5, Insightful)
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: (Score:3, Insightful)
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 GPL
Re: (Score:3, Insightful)
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: (Score:2)
Dump out the MS Koolaide, and refill with some FOSS goodness.
Or at least please stay ontopic.
Not Necessarily Patented (Score:3, Informative)
They would need to invalidate all patents (Score:4, Insightful)
Re: (Score:2)
Patent exclusion proof is incumbent on the patentholder. I'd like to see an analysis from a third party, like a court ruling on an H.264 patent defense since that upset, indicating just which v
Re: (Score:3, Insightful)
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
Re: (Score:3, Informative)
H.264 decoding is a purely mathematical operation, which lies outside the scope of patentability.
In which country? Slashdot is based in the United States, where video transmission systems relying on computing devices programmed with a novel algorithm are considered novel.
You might be able to patent a particular device capable of performing that operation, but not the operation itself.
"The operation" is transmitting video, and "a particular device capable of performing that operation" is a computer programmed with the H.264 algorithms.
Any device differing substantially from the implementation described in the patent would not be covered under the patent.
Any device differing substantially from the implementation as described in the patent would also not be able to decode a video bitstream that conforms to the H.264 specification.
Re:More like giving up (Score:5, Interesting)
Re: (Score:3, Interesting)
Re:More like giving up (Score:5, Insightful)
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 (Score:4, Informative)
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: (Score:2)
But how does a product released in 2007 (from your link) supersede an announcement made on April 8, 2008 [via.com.tw]?
I'm not going to pretend to be an expert on this, I'm just curious.
Re: (Score:2)
Re:More like giving up (Score:5, Interesting)
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.
Re: (Score:2)
ATI and nVidia support hardware H.264 acceleration on Windows via the standard codec system.
That is debatable. If nVidia claimed H.264 acceleration, but in actual fact only supplied some docs I think most of their target market might be a little bit u
Re: (Score:2)
If Fluendo [wikipedia.org] can figure it out, so can VIA.
Re: (Score:3, Insightful)
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 l
Because they've played this game before. (Score:5, Informative)
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: (Score:3)
I believe this is probably true, but can you provide a link to a primary source? I'd like to see a FOSS developers blog post or something from a developer mailing list.
Again I don't doubt you, I'd just like to read about this in depth. My googling is coming up short.
Re:Because they've played this game before. (Score:4, Interesting)
Re: (Score:3, Informative)
I've had first hand experience of trying to get a Via EPIA EX1000 working nicely, and it was a bitter experience, see my previous posting here:
http://slashdot.org/comments.pl?sid=430420&cid=22186390 [slashdot.org]
Also, had the Via Arena forums not been erased when being replaced by the new TK Arena [tkarena.com] forums, you'd have been able to see many many posts complaining about driver support and frustrated users trying to work out how to get their boards working. Still, the TK Arena hasn't been up that long, but some of the
Re: (Score:2)
Re: (Score:2)
1. Company provides open source driver dump, which is buggy and not really suitable for end-user use.
2. Community cleans up driver and fixes numerous bugs, and packages the driver for end-users.
3. Community provides patches to fix those bugs to the company, but company ignores the patches.
4. Company releases a new version of the driver dump that fixes some bugs, adds support for new chipsets, adds more featu
Re:Because they've played this game before. (Score:4, Informative)
Like at first they had a binary download, but then to get the source you had to sign up and be a "serious" open source developer. I just wanted to get the source so I could recompile it with my kernel (which was not compatible with their binary), I filled out their form and then never heard back from then. They would release source saying it was under a certain license, but when the developers of the fork would look through it they would find all sorts of other claims of proprietary license in and accompanying the code, sometimes by third parties, and weren't sure which to believe. Inquires to VIA about such things often seemed to disappear into a blackhole.
I don't know what was going on inside VIA - if they hadn't decided whether they wanted to maintain the software themselves or if they wanted the community to do it, or if the development work was being done at VIA Taiwan and they hadn't given anyone at VIA America authority to handle relations with developers, or what, but it was a completely bungled arrangement.
I have no problem with companies depending on the community to maintain the drivers - that can be a very productive arrangement for everyone involved - but communication is absolutely essential for it to work. VIA is an interesting company, and I think they are in a unique position to benefit from a closer connection with the open source community - the encryption features in their processors are a good example of where they have done things right in the past. Hopefully their video/chipset drivers will see the same success in the future.
Re: (Score:2, Informative)
Re:More like giving up (Score:5, Informative)
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: (Score:2)
Re:More like giving up (Score:4, Insightful)
Re: (Score:2)
Re: (Score:3, Insightful)
Re: (Score:2, Informative)
Look forward to documentation and X.org drivers from VIA as well in the near future
And so they are releasing the docs. As for why a Linux driver? 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. So why would VIA support *BSD over Linux when more VIA products run on Linux by default and not *BSD (gPC, Cloudbook, Etc.) and other then *BSD there aren't a lot of OSes that are OSS and popular (About the only other one I can think of is ReactOS and that isn't very stable yet....)
Re:More like giving up (Score:4, Insightful)
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 (Score:5, Funny)
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 (Score:4, Insightful)
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.
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: (Score:3, Insightful)
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 por
Re: (Score:2, Interesting)
As for the licensing, I was assuming that VIA would release most code under some license other then the GPL (such as the BSD license) that would allow use in proprietary products. And, as in true
Re: (Score:2)
I was assuming that VIA would release most code under some license other then the GPL (such as the BSD license) that would allow use in proprietary products.
Pointless for two reasons.
First, the incompatibility goes both ways -- BSD code cannot be GPL'd, because BSD includes an advertising clause that the GPL doesn't. The few times drivers have made it across, it's been because the original, sole author gave permission.
Which brings us to the second reason: If VIA wants to use their driver in proprietary software, there's nothing stopping them, because they have copyright. They can release it under as many licenses as they want, so long as the license doesn't re
Re: (Score:3, Insightful)
Re:More like giving up (Score:4, Insightful)
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: (Score:2)
Re: (Score:3, Insightful)
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.
Re:More like giving up (Score:5, Insightful)
Re:More like giving up (Score:5, Insightful)
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: (Score:2)
Why should it be up to the manufacturers to write drivers for their hardware? If they release the specs, then the community of FOSS developers can most likely make better drivers than most hardware OEMs. And without nefarious licensing terms that restrict us packaging them however we want.
Re: (Score:2)
long history of VIA refusing to release documntn (Score:2, Insightful)
we are geeks here (Score:2)
I saw "N-line
Does "framebuffer" mean no HW acceleration? (Score:2)
Re:Does "framebuffer" mean no HW acceleration? (Score:5, Informative)
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.
Re:Does "framebuffer" mean no HW acceleration? (Score:4, Funny)
Re: (Score:3, Interesting)
Re:Lots of code? (Score:5, Insightful)
(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?
mod parent up (Score:2, Informative)
> 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?
DAMN RIGHT
mod abuse? (Score:2, Insightful)
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.
Re: (Score:2, Funny)
Re:mod abuse? (Score:4, Funny)
You must be new here, so I'll explain. Slashdot is a scientific community. We concern ourselves with inviolable scientific principles like Newton's First Law, Microscopic Reversibility, and Le Grande Balance Du Modpoints (the French did a lot of work in this area), which says "plus modpoints must equal minus modpoints". Random bitch slapping is essential to achieve this balance, especially given the well known dearth of trolls here.
Re: (Score:2)
I don't really care if someone mods me down. What? I lose my
Re: (Score:2, Informative)
Re:Lots of code? (Score:5, Interesting)
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."
I'm calling bullpoop on that... (Score:2)
Re: (Score:2, Funny)
Now grab your pitchfork and stop trying to be rational!
Re: (Score:2)
In reverse order:
2. This subject I was going to reply to, but you beat me and said it better than I had planned on.
Yes, WTF??!!??
This IS good news! Any time the GNU/Linux and/or the FOSS crowd get thrown a bone with this much meat on it, it is a GOOD THING! Soooner or later something like this will be 'the straw that broke the camel's back'. (pedant's warn-off...my old school grammar teachings have only been invalidated IN YOUR OWN
How to make that part of the FOSS community happy. (Score:2)
2. Give the full docs, benefits, a big pay check.
3. Send them to all the FOSS conferences.
4. Give the drivers away for free.
Not only must you provide specks but you must write the driver as well to make the FOSS community happy.
Re:Lots of code? (Score:5, Insightful)
Re:Lots of code? (Score:5, Insightful)
Pretty cool in my books.
Re:Lots of code? (Score:5, Interesting)
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: (Score:2)
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.
That's exactly why I'd be skeptical of it.
I mean, I'm not suggesting every app needs to be an exercise in golfing, but remember, 20 correct lines -- and I bet that's irrespective of language, which is why I prefer concise, high-level languages.
In general, which is more likely -- that there are 16k of high-quality, well-tested code? Code that's as simple as it can possibly be, but no simpler? (Apologies to Einstein.)
But often, it's 16k of absolutely horrible, untested spaghetti code, written by too small of
Re: (Score:2)
That's exactly the right conclusion to take from it IMO. One can take it a step further and also conclude that stricter languages with more static checking are also preferable, since the compiler can rule out certain classes of bugs independent of the quality of developer.
Re: (Score:2)
Re:Lots of code? (Score:5, Interesting)
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: (Score:2)
If you want to be pedantic, the correct wording is something like, "a single developer adds about 20 correct lines of code per day, on average".
but doesn't tell you *anything* about any particular basketball player
Perhaps not on a given day, but it will tell you what productivity to expect from a team of basketball players now won't it?
Back to the "studies" (studies? really?), they really only measure an a
Re: (Score:2)
If star programmers cobbled this together in record time, the value of code is no different than if average programmers did it in average time.
Re: (Score:3, Insightful)
It depends which 16K lines.
A Win for Free Softare Either way. (Score:2, Insightful)
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 incomple
Re: (Score:2)
Maybe someone with experience with this sort of development can elaborate on the difficulty of the code.
Re:Lots of code? (Score:5, Funny)
IBM didn't hire guys with beards? Well that completely explains AIX.
Re: (Score:2, Funny)
I don't think that's an unreasonable request. It's not like I'm going to eat your eyes.
Re: (Score:3, Funny)
Well, remember, anything is possible...
Re:Zombu? (Score:5, Funny)
Welcome to Slashdot.
I must have hit an extra key... (Score:2, Funny)
Re: (Score:3, Insightful)
Re: (Score:3, Insightful)
Re: (Score:3, Insightful)
Re: (Score:3, Funny)
Back in my day, when trolls were trolls and karma was numeric, slashdot was too obscure for companies to astroturf. It was fanboi vs fanboi for glowing praise and the comment threads were full of flame. How I miss the days of ole'. It just makes me want to pour hot grits down my pants.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:3, Insightful)
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 supporti