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."

Comments

Zombu?

[niteice]

Am I the only one that read Zombu as Zombo?

Re:Zombu?

[Anonymous Coward]

Well, all I think of is BRAAAAINS!!! And how I wish to eat them.

I don't think that's an unreasonable request. It's not like I'm going to eat your eyes.

Re:Zombu?

[gEvil (beta)]

Am I the only one that read Zombu as Zombo?

Well, remember, anything is possible...

Re:Zombu?

[19thNervousBreakdown]

Welcome to Slashdot.

Re:Zombu?

[Spatial]

But if true, doesn't that mean it's impossible for something to be impossible? Oh shit!

Re:Zombu?

[soulfury]

I really don't know why I read it from beginning to end...

16434!

[Anonymous Coward]

Hey, that's 46 lines too much! Quick, someone delete 46 empty / comment lines!

Re:16434!

[Anonymous Coward]

Erm, I mean, 50 lines. Apparently I'm incapable of calculating a simple substraction in head. I blame... canadians!

Re:16434!

[Anonymous Coward]

I'd be a lot more impressed if they only wrote 1729 lines of code. Heck, I'd still give them props if they wrote it in 87539319 lines of code. 16434 is a boring number.

Re:16434!

[Anonymous Coward]

Canadians are the leading cause of substraction [sic] deficiencies worldwide.

Re:16434!

[MadnessASAP]

Only because Canadians never lose something we only add to our awesomeness.

Re:16434!

[despisethesun]

You can't blame us this time, buddy! We're on strike!

Re:16434!

[Hal_Porter]

I hope you're abroad you can get the Canadian flag off your rucksack quickly if the BC Human Rights Tribunal finds Mark Steyn not guilty.

Re:16434!

[MadnessASAP]

I would be more worried about all the Americans who are abroad with Canadian flags on there backpack.

Re:16434!

[Anonymous Coward]

I'm not your buddy, friend!

Re:16434!

[goodster]

Q: How can you tell the difference between an American tourist and a Canadian Tourist?
A: The Canadian tourist only has *one* Canadian flag on his backpack. :)

Re:16434!

[Anonymous Coward]

I'm not your friend, guy!

Re:16434!

[Rysc]

I'm not your buddy, friend.

Re:16434!

[paxcoder]

Not to mention it's lines, not bytes. P.S. Canada is cool.

Lots of code?

[pclminion]

I had two immediate thoughts:

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.

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?

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

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

[j-pimp]

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

[Anonymous Coward]

With DirectX you have to do a ton of code just to initialize a drawing environment. It's not a compact API to begin with.

Re:Lots of code?

[cheater512]

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

Re:Lots of code?

[naasking]

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?

[Pseudonym]

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

It depends which 16K lines.

Re:Lots of code?

[Anonymous Coward]

(2) Why are the first few comments so negative?

Because over the past year or two, Slashdot has become a pro-Microsoft forum and this is a positive step for Linux.

Re:Lots of code?

[SanityInAnarchy]

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?

[SanityInAnarchy]

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 a team on too short a deadline -- that of course got pushed back, because rushing meant, in some cases, code that was actually too buggy to use.

I really hope it's good stuff, but 16k by itself doesn't say much one way or the other, aside from how big the download will be.

Re:Lots of code?

[Atriqus]

Hey, this is Slashdot; if they're a hardware manufacturer, they're doing something wrong.

Now grab your pitchfork and stop trying to be rational!

Re:Lots of code?

[rts008]

First, congrat's on getting modded this high as an AC! seriously, Well Done!

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 MINDS, not mine- Back Off with the it's/its possessive/plural crap...I'm not impressed or interested)

1.I'll have to take your word here, as I know next to nothing about frame buffer coding. #2 was what I was interested in responding to. Thanks.

Re:Lots of code?

[node 3]

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?

[Anonymous Coward]

Typical C, 15k declarations and comments, 1k code. Most of it doesn't produce code, it just tells how to produce code.

Re:Lots of code?

[Anonymous Coward]

(2) Why are the first few comments so negative? Well, I'm being redundant here (pasting a link that has been posted above me), but for the sake of clarity: see this Phoronix article.

Among others, it contains this quote from an Openchrome developer:

There have been numerous communication attempts with VIA, but they never showed a great interested, were hard to convince to provide docs even under the terms of their NDA, took very long to answer to mails, and even completely stop communication for months. The article highlights VIA's longstanding career of claiming "Linux support", while providing only binary drivers and/or very rudimental open-source drivers.

Re:Lots of code?

[Artuir]

+5 insightful indeed. That always really irritates me about that portion of the FOSS crowd - they bitch and moan about something and then when they get it, the manner it was delivered was not up to their "standards". Or something, somehow, was off. I really don't understand this crap.

Hopefully this will encourage other companies to open up and possibly down the road we can actually start getting some serious gaming support for various distros. That would be awesome.

Re:Lots of code?

[naasking]

Even if you reword it to say, "the average developer..." you still have a fairly meaningless statement.

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 average of whatever specific development teams they measured.

IIRC, the studies were retroactive analyses of code commits vs. resulting bugs, over the entire lifetime of a number of projects, hence the conclusion "20 lines of *correct* code" per day. And these were analyses of high assurance software, written in C, C++ and Ada. Think NASA and the aerospace industry (at least for the studies I read. Hardly your garden variety programmer there. This metric is independent of language, as another poster mentioned.

I find it hard to see exactly what's so objectionable about this metric. The fact that projects go through a rapid prototyping phase followed by a slower incremental phase simply implies that the prototype has many bugs, and incremental changes fix bugs and slowly introduce new non-breaking changes. This does not make the conclusion "nonsense".

Re:Lots of code?

[naasking]

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.

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

[ianare]

Except it doesn't really take that long to write 16K lines, so it's sort of a weak boast. Depends on the code, no? I mean if you're doing GUI stuff you can easily have tons of lines just for your buttons and forms, but a complex algorithm that takes weeks to get just right could be pretty short.
Maybe someone with experience with this sort of development can elaborate on the difficulty of the code.

Re:Lots of code?

[Basje]

Even if you're right, the number of lines is still very meaningful. It's not interesting how long it took the particular developers in this project to create this code. It is _a_ measurement of what the code is worth.

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

[iowannaski]

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.

"Average" is directly implied. "Professional developer" can be reasonably assumed without making a pedantic ass of yourself.

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.

Sure, but it gives you a pretty good idea of how many families it takes to produce 1600 children.

Re:Lots of code?

[SanityInAnarchy]

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. I would argue that the rest of the code isn't going to be "independent of the quality of developer", and I tend to find that most such strict languages also aren't as concise or as fun to work in as a high-level, highly dynamic language.

Re:Lots of code?

[naasking]

I would argue that the rest of the code isn't going to be "independent of the quality of developer"

Depends what you mean. I specifically said "the absence of certain runtime errors", as that's exactly the guarantee a type system provides. If you mean code structure and maintainability, then yes, that depends on developer quality. Still, in my experience static type systems tend to produce higher quality code exactly because they are stricter in what they allow.

I tend to find that most such strict languages also aren't as concise or as fun to work in as a high-level, highly dynamic language.

I think you'll find this depends greatly on what statically typed languages you've used. Java, C#, and C/C++ are not what I'm talking about. OCaml, SML and Haskell are where it's at. Scala is kind of a middle road, where it's safer and more expressive than Java, but not quite as safe as OCaml.

More like giving up

[AmiMoJo]

This seems more like Via giving up than wanting to properly support Linux. Look at how they supported the C7 platform - it was supposed to have hardware H.264 decoding, but it was only supported by an open-source patched mplayer on Linux and never under Windows.

Via just don't want to develop their Linux drivers any more. Watch as support disappears now they don't have to.

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

[Cillian]

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

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

[edsousa]

Look at how ATI/AMD supports Linux. Even the much praised nVidia still lacks proper (read: in comparison with Windows) drivers. Do they release a single line of code? Nop... At least Via chipsets will have RandR and other usefull functions fully implemented and supported.

Re:More like giving up

[AmiMoJo]

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

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

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

[Darkness404]

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

[edalytical]

But how does a product released in 2007 (from your link) supersede an announcement made on April 8, 2008?

I'm not going to pretend to be an expert on this, I'm just curious.

Re:More like giving up

[poopdeville]

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.

Re:More like giving up

[AmiMoJo]

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?

ATI and nVidia support hardware H.264 acceleration on Windows via the standard codec system.

Absurd. You got what you paid for.

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 upset about that. Considering they are selling consumer devices, and most consumers are not programmers. Also, when the C7 came out years ago, there were no docs, and when the did finally come, they were poor.

It's a bit like a car manufacturer selling you a new machine that can do 180MPH, but actually only does 150 and you have to tune it yourself get 180. Most people are not car tuners, they expect that if the box says it does something then it does it.

Re:More like giving up

[Anonymous Coward]

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

[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

[Vegeta99]

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

[Darkness404]

Ok, you are right, I guess for a second I forgot how drivers had to be written at such a low level (I program mostly in python...) and yes that would make porting drivers a pain.

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 /. fashion, I didn't read TFA.

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

[poopdeville]

ATI and nVidia support hardware H.264 acceleration on Windows via the standard codec system.

Fair enough, and I agree. A "standard" system exists to provide this kind of acceleration on Windows. VIA could/should have used it.

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 upset about that. Considering they are selling consumer devices, and most consumers are not programmers. Also, when the C7 came out years ago, there were no docs, and when the did finally come, they were poor.

The Windows and Linux markets are a bit different. Which codec library should VIA target? All of them? libavcodec? (That's the main one Mplayer uses) Even if they write the software, third parties are involved. The libavcodec programmers might not want to include it in the main source tree. And there's nothing VIA can do about it but branch.

It's a bit like a car manufacturer selling you a new machine that can do 180MPH, but actually only does 150 and you have to tune it yourself get 180. Most people are not car tuners, they expect that if the box says it does something then it does it.

Your car won't go very fast at all without a driver... is this the manufacturer's fault? I don't mean to confuse the issue, but your car needs something to give it instructions before it will "go". So does your motherboard. In this case, it is your video player or encryption library. I agree that not including an H.264 codec for Windows was an enormous oversight, and if I used Windows I would not be pleased with VIA. But I am willing to be more charitable in the Linux case.

Re:More like giving up

[Trogre]

Correct me if I'm wrong, but isn't this exactly what we want?

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

[LWATCDR]

Umm. Community support is sometimes better than that given by companies. Sometimes it is not. In this case community support is now possible thanks to the support given by the company.

Re:More like giving up

[Anonymous Coward]

Awesome. Can you point me to a guide on how to turn on PurevideoHD under linux so I can get accelerated hi-def video playback like under windows?

Re:More like giving up

[JimCDiver]

"ReactOS" And should, in theory, be able to use Windows drivers.

Re:More like giving up

[Kjella]

True, but I was thinking more like code with some #defines and some useful short comments. If it's obfuscated to only be a bunch of magic numbers, then yeah I guess. On the other hand, if the documentation is all how "poke this with that" rather than why, you're not better off. *I guess you can have useless versions of both and helpful versions of both...

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

[sprack666]

C7 processor has the cryto support (SHA, AES, MM and RNG) the chipset had the mpeg decode.

Re:More like giving up

[Anonymous Coward]

Not relevant - on linux, you just get an unDRMed download from TPB and use the GL accel mode of mplayer.

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.

Re:More like giving up

[ThatCanadianGuy]

Are you surprised? its VIA they don't want to do anything.

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.

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

[SanityInAnarchy]

The Windows and Linux markets are a bit different. Which codec library should VIA target? It almost doesn't matter. Pick one, even start your own. People will write wrappers for the others. I'd probably start with GStreamer, but really, whatever.

If Fluendo can figure it out, so can VIA.

Re:More like giving up

[SanityInAnarchy]

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

Re:More like giving up

[SanityInAnarchy]

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 require them to give up copyright. MANY open source projects are "dual-licensed" -- there's a commercial version, which comes with support, under a different license, and costs money, and then there's the GPL'd version, for which the project generally only accepts contributions which give them copyright.

But you see, if this code gets integrated into the kernel -- where it most likely belongs -- then it's GPLv2, period. VIA can't take it back and make it proprietary. They still own all the code that they wrote, but now people will be contributing to the kernel fork, which will most likely pull ahead -- and VIA won't really be able to do anything but sit back and watch, and sell hardware.

And that, to me, is the most important point -- VIA is a hardware company. Honestly, they should public-domain their drivers, so that we can relicense them however we want -- as there's really no reason they should care about anyone "stealing" their software. Stolen software equals more hardware sales for them.

Re:More like giving up

[Koiu Lpoi]

Indeed, I remember a few years back turning my GeForce4 Ti 4400 into a Quadro through driver hacks, without ever touching the card's flash.

Re:More like giving up

[Anonymous Coward]

It's not a gift, you paid for the hardware. It is more akin to somebody selling you VCR with a 200 button remote control and then refusing to give you the manual.

Re:More like giving up

[Hal_Porter]

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. Man up, nancy. I've written drivers using an IDA disassembly of a binary driver for another OS as documentation. And if you want drivers for Plan9, that's what you'll need to do.

Re:More like giving up

[edsousa]

I said when comparing to Windows. Both ATI and nVidia cards don't work properly with RandR. For me, worker, not gamer, this is a must. For example, you don't get extended desktop in Linux with different monitor resolutions as you can in Windows. Binaries can be the same, but its bindings to OS (which is still part of the driver) suck.

Re:More like giving up

[Anonymous Coward]

About the only other one I can think of is ReactOS and that isn't very stable yet....

Haiku and Syllable. ReactOS & Syllable could use these sources as-is, as they're both GPL, Haiku & BSD can not. The most obvious one is X.org: the fb driver sources can't be used to update the X.org driver!

Re:More like giving up

[Magada]

Yes, it does! And here's to many other hardware vendors becoming as lazy in the future! Hardware people have no business writing (or supporting) software anyway. The more of them realize this and take the obvious steps (i.e. give up developing drivers in-house for microsoft's benefit), the better.

Re:More like giving up

[Anonymous Coward]

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.

Actually, the present DirectX API does have calls for the parts of H.264 you accelerate in hardware (obviously not a complete decoder, you still have to write a fair bit yourself); there is a standard way of doing it, which is why you can get hardware-accelerated h264 codecs which will work on more than one type of graphics card.

Re:More like giving up

[Anonymous Coward]

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.

Do you know that most commercial hydrogen is made from natural gas?

Re:More like giving up

[Anonymous Coward]

nividia drivers, while they don't currently support the very latest xrandr, certainly do support different monitor resolutions - I'm using a 1600x1200+1280x1024 desktop right now (note also that nvidia drivers 3D accelerate all heads in a xinerama setup, not just the first). So all you get is a big fat "huh?", sorry. Maybe you're too dumb to read the readme or something, I dunno.

Re:More like giving up

[Anonymous Coward]

When did the FOSS community become this collection of curmudgeons?

What makes you think that a small number of noisy 'curmudgeons' in any way represent 'the FOSS community'? They seem to be well outnumbered by those who are welcoming this move.

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.

Re:More like giving up

[Anonymous Coward]

The people who could use this are actually paying Via -- they bought its hardware.

Via is not doing charity, it's trying to get more Via chips sold. So get of your high horse.

Re:More like giving up

[kelnos]

I think the point being made is that VIA has a long history of dragging its feet, going back on its promises to the OSS community, and providing much less than they say they will. Why should this time be any different? I wouldn't be surprised if they just got fed up with it all and are trying to provide enough to the community so they can just wash their hands of it and avoid any further bad PR.

Re:More like giving up

[Anonymous Coward]

> And why would you expect random software to know about and make calls to VIA's API?

Nobody expects that. The random software should use the normal video rendering API (which *is* part of DirectX as I understand it), and VIA should provide the hardware accelerated codec.

Re:More like giving up

[Anonymous Coward]

It is my understanding that VIA did in fact choose libavcodec, and that the mplayer team decided to not roll it into trunk.

Re:More like giving up

[OECD]

Grandparent was perfectly clear to me. I had to read yours twice to figure out which 'they're' confused you, though. :/

Re:More like giving up

[Anonymous Coward]

You don't have VIA hardware, do you ?

> they didn't _have to_ [release the code]

Right. But then they should have provided working drivers. And they didn't do that. Just think about it, what would happen if they sold hardware for windows without providing drivers _or_ specs ?

> you aren't paying them

Exactly how do you think I got my hardware ? Sure I paid them! They are hence obliged to provide working drivers - preferably open-source - but working drivers nonetheless.

Re:More like giving up

[Workaphobia]

Linux users/developers don't want corporate support for drivers anywhere near as badly as they want openness in hardware specifications. Teach a man to fish, etc., etc.

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

we are geeks here

[Endymion]

You can use "kLoC".

I saw "N-line ... framebuffer" and thought it was about some new, very-high resolution display technology...

Re:we are geeks here

[Anonymous Coward]

That's sixteen thousand libraries of Congress!

mod parent up

[harry666t]

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

DAMN RIGHT

Patents and driver signing requirements

[tepples]

So long as the community supports the driver well enough, why should we care? Two reasons. For one thing, H.264 is patented. So VIA needs to support the decoder, even if only by acting as a patent sublicensor to the community. 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.

Re:Patents and driver signing requirements

[Darkness404]

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.

So in other words it is a MS problem? It would have nothing to do with VIA supporting or not supporting the graphics card, it is a Windows problem and MS could fix it (though, given how broken most other parts of their OS is, I doubt that they would).

As for the patents, they don't apply to some parts of the world so distros such as Ubuntu would include the drivers anyways, though it would be a pain it would be do-able.

Now it would be nice for VIA to support the drivers, but if not, its not the end of the world.

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

[tepples]

In addition, Windows Vista 64-bit requires Which has what, exactly, to do with a Linux framebuffer driver? AmiMojo wrote:

Look at how they supported the C7 platform - it was supposed to have hardware H.264 decoding, but it was only supported by an open-source patched mplayer on Linux and never under Windows. Besides, patents are still relevant.

Re:Patents and driver signing requirements

[td04impostor]

Well, let's say you are a fervent free software supporter, but being stuck in Windows for some reason, you still want to use open sourced stuff the most you can... ( I used to be like that, but never with drivers, though )

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

[rts008]

And exactly what does VIA starting to cater/support Linux have to do with MS Vista 64?

Dump out the MS Koolaide, and refill with some FOSS goodness.
Or at least please stay ontopic.

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.

Re:Patents and driver signing requirements

[tepples]

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.

Does "framebuffer" mean no HW acceleration?

[l2718]

Can some help a non-expert in the audience: I assume that a "framebuffer" driver only gives pixel-level access to the card, without access to the HW acceleration features?

Re:Does "framebuffer" mean no HW acceleration?

[Chandon Seldon]

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?

[Dred_furst]

if anything of what their current driver release for linux is, it has full 3d accelleration plus the much needed xv interface, I presume this code is in the release of the Framebuffer

Re:Does "framebuffer" mean no HW acceleration?

[Anonymous Coward]

It's still unbelievable. The only thing such a driver would have to do it calling the OS-independent VBE protected mode routines in the VGA Option ROM. It gives you routines to map the buffer, do Buffer flipping and BitBlts, and reading/writing to the framebuffer would be simply writing to a memory-mapped I/O location. The last time I did that was on DOS with Turbo Pascal, and required only about 200 lines of code.

Did they reimplement the VBE BIOS or what?

Re:Does "framebuffer" mean no HW acceleration?

[Mike1024]

16,000 libraries of congress? That *is* a lot of data.

Because they've played this game before.

[pavon]

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.

[edalytical]

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.

[dwater]

I'm confused...do *they* have to accept patches? Why doesn't someone fork it onto sourceforge or something so you can easily fix it?

Re:Because they've played this game before.

[glitchvern]

Will an article 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:Because they've played this game before.

[Hal_Porter]

I thought that was the point of Open Source?

At the moment it seems like it works like

1) Company releases some hardware
2) People complain about no Linux driver.
3) Company releases a Linux driver
4) People complain it's not open source, tell company if they release source the community will maintain it.
5) Company releases driver source code
6) People complain that the code is not documented or maintained

Re:Because they've played this game before.

[Mike McTernan]

Hi,

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

Also, had the Via Arena forums not been erased when being replaced by the new TK Arena 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 posts are already starting to look familiar:

http://www.tkarena.com/forums/video-graphics-arena/34947-tv-out-problems-cn700-chipset.html

I do hope things improve, but somehow I think I'm stuck on Fedora 5 for my Via EPIA board :(

Re:Because they've played this game before.

[Anonymous Coward]

They key to understanding this is the realization that these aren't all the same sets of people.

Re:Because they've played this game before.

[Hal_Porter]

Yeah, but considering there are lot less Linux users than Windows or Mac users it seems pretty silly to harass companies that try to support Linux like this.

Re:Because they've played this game before.

[pavon]

My reaction at VIA was more of befuddlement than anything else. I mean they went to through all the effort to write these drivers, and they were nice enough to make the source available, but then there was just a complete breakdown of communication when it came to letting people do the last 10% that was necessary to make the drivers useful.

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:Because they've played this game before.

[kelnos]

They don't have to, of course, but it would make the process easier for all concerned. Say:

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 features (say, better HW acceleration that wasn't present in the old version), etc. But, the driver is still buggy in many of the old ways, and is still unsuitable for end-user use as-is.
5. Community has to painstakingly go through the new driver code base and merge all the old patches, many of which probably don't apply cleanly (or at all) anymore.
6. New bugs/deficiencies are found and fixed by the community. Company ignores this patch as well, and we're right back at step #3, but with a bigger patch set and more work for the next driver dump.

If the community could be truly independent, this wouldn't matter. After the first code dump, they could maintain their own version of the driver and mostly ignore future upstream releases (aside from cherry-picking useful stuff from time to time). But, without specs, it's very hard to add support for incomplete/missing features and new chipsets, so the community always has to work with the company for these things, which is made harder by the fact that the company doesn't really want to work with the community in a productive manner.

Slashdot == press release wire

[ikeleib]

This post just gushes about VIA. Since when did slashdot become a site for vendors to have their sock puppets write glowing posts for them?

probably makes them the best-supported framebuffers Linux has ever had

Give me a break.

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: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."

Re:Slashdot == press release wire

[DigiShaman]

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?

Re:Slashdot == press release wire

[ikeleib]

Based on your account number, your obviously not new around here

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:Slashdot == press release wire

[BiggerIsBetter]

Since when did slashdot become a site for vendors to have their sock puppets write glowing posts for them? You sir, must be new here.

Re:Slashdot == press release wire

[ajlitt]

I think it began the same day Slashdot started giving preferential treatment to blogwhores who link to a 2 line treatment on their own site rather than the material being discussed.

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:Slashdot == press release wire

[Kjella]

It just makes me want to pour hot grits down my pants. To each his own, I'd rather have Natalie Portman there...

Re:Slashdot == press release wire

[Anonymous Coward]

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

Via enables better framebuffer support on their hardware. Intel re-architects the framebuffer/X interface for all hardware (theirs included) to remove the horrible Xorg/fbdev mess that has been festering for years.

http://kerneltrap.org/node/8242

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.

Re: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. DAMN RIGHT

Re:mod abuse?

[LaskoVortex]

The point of moderation is to find and highlight gems not bitch slap people at random.

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:mod abuse?

[harry666t]

I'm slowly getting used to it (:

I don't really care if someone mods me down. What? I lose my /. karma? Meh, it's just an integer in a database. The "real world" karma is more important to me. And it is excellent.

Re:mod abuse?

[dwiget001]

Godwin. You forgot Godwin's Law as one of the laws that drives /. No really.

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:A Win for Free Softare Either way.

[Anonymous Coward]

Yes, indeed yesterday you were shilling your own posts and telling us about this.

Re:A Win for Free Softare Either way.

[Anonymous Coward]

Isn't it interesting twitter, that when you avoid things like these people actually mod you up. Why in the world could that be due to? Do you have any ideas? Any at all?

I must have hit an extra key...

[Anonymous Coward]

I meant to type slashdot.org, not slashdot.org/b/

I'm calling bullpoop on that...

[Joce640k]

Several thousand lines? Not possible, no matter how badly you're doing it.

Not Necessarily Patented

[Doc Ruby]

In January last year, a court ruled that one of the patents on which H.264 is based was invalid. It's not clear whether patent exclusions from H.264 are valid anymore.

This is great!

[Anonymous Coward]

The code looks nice and clean (needs a little extra documentation perhaps). It appears to support multi head output, LVDS (laptop build in screen) & DVI & HDMI output, VESA power saving, 2D hardware acceleration (fill, copy, hardware cursors, hardware clipping etc.).

Thanks VIA!

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:They would need to invalidate all patents

[Doc Ruby]

Possibly. Sometimes the whole house of cards collapses. In the wake of that Qualcomm defeat, lots of analysis said it was now safe for free H.264 implementations, and several were launched. It might be that H.264 was truly dependent on only that one patent, and can be implemented without conflict with any that remain.

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 valid patents still protect H.264. There's a difference between actual "essential" patents, and extras thrown in to encumber a tech with a toll gate.

How to make that part of the FOSS community happy.

[LWATCDR]

1. Hire the FOSS programmers that are already working on the driver.
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.