Slashdot Mirror
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."
So long as the community supports the driver well enough, why should we care?
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.
Win a signed Stephen Carpenter ESP Guitar from the Deftones: http://def-tag.com/?r=0008781
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...
There's more to the OSS world than Linux, I'd rather they released the docs than write a line of Linux code.
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
(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?
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
Hang on, you think more lines would be a boast? I would think *only* 16k lines would be the boast here.
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.
Making a chip output the console to HDMI with 16k lines?
Pretty cool in my books.
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.
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
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.
Live today, because you never know what tomorrow brings
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 ...
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.
"The agriculture ministry is not in charge of Gundam" - Japanese ministry official.
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.
The government can't save you.
It depends which 16K lines.
sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
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."
Property is theft.
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.
This post just gushes about VIA.
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 for all the worlds' geeks. As such, they deserve to be praised. After all, this is the kind of behavior we want to encourage is it not?
Life is not for the lazy.
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.
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?
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.
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.
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.
Don't thank God, thank a doctor!
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.
Don't thank God, thank a doctor!
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.
And even then, I still can't use the h.264 acceleration.
Don't thank God, thank a doctor!
If you don't think these are the best-supported framebuffers Linux has ever had, provide a counterargument.
Don't thank God, thank a doctor!
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.
Je fume. Tu fumes. Nous fûmes!
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.ELOI, ELOI, LAMA SABACHTHANI!?