Slashdot Log In
VIA Releases 16K-Line FOSS Framebuffer Driver
Posted by
kdawson
on Sun May 11, 2008 03:41 PM
from the can-only-get-better-from-here dept.
from the can-only-get-better-from-here dept.
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."
Related Stories
[+]
Linux: VIA Announces Open Source Driver Initiative 134 comments
Aron Schatz writes "VIA has announced that they will start a new site (http://linux.via.com.tw — doesn't exist yet) specifically for the development of open source drivers. From their press release: 'Over the following months, VIA will work with the community to enable 2D, 3D and video playback acceleration to ensure the best possible Open Source experience on VIA Processor Platforms. 'To further improve cooperation with the community, VIA will also adhere to a regular quarterly release schedule that is aligned with kernel changes and release of major Linux distributions. In addition, beta releases will be issued on the site as needed, and a bug report and tracking feature will also be integrated.' Nvidia should be next."
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
16434! (Score:3, Funny)
Re: (Score:3, Funny)
Re:More like giving up (Score:5, Interesting)
Parent
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.
Parent
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.
Parent
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.
Parent
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.
Parent
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)
Parent
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: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.
Parent
Re: (Score:3, Insightful)
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 ...
Parent
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.
Parent
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.
Parent
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?
Parent
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:More like giving up (Score:5, Insightful)
Parent
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.
Parent
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.
Parent
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.
Parent
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.
Not Necessarily Patented (Score:3, Informative)
They would need to invalidate all patents (Score:4, Insightful)
Parent
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.
Parent
Re:More like giving up (Score:4, Insightful)
Parent
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?
Parent
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."
Parent
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.
Parent
Re:Lots of code? (Score:5, Insightful)
Parent
Re:Lots of code? (Score:5, Insightful)
Pretty cool in my books.
Parent
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.
Parent
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.
Parent
Re: (Score:3, Insightful)
It depends which 16K lines.
Re:Lots of code? (Score:5, Funny)
IBM didn't hire guys with beards? Well that completely explains AIX.
Parent
Re: (Score:3, Funny)
Well, remember, anything is possible...
Re:Zombu? (Score:5, Funny)
Welcome to Slashdot.
Parent
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.
Parent
Re:Does "framebuffer" mean no HW acceleration? (Score:4, Funny)
Parent
Re: (Score:3, Interesting)
Re: (Score:3, Insightful)
Re: (Score:3, Insightful)
Re: (Score:3, Insightful)
Of course, and why not? This post is about VIA providing drivers for the Linux OS.
Since when did slashdot become a site for vendors to have their sock puppets write glowing posts for them?
Based on your account number, your obviously not new around here. So why did you even make this statement? Come on, you know the answer to that. But in case you forgot I will tell you.
Slashdot will praise any company and/or its technology that provides unobstructed freedom and functionality
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: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