Slashdot Mirror

← Back to Stories (view on slashdot.org)

VIA Releases 16K-Line FOSS Framebuffer Driver

Posted by kdawson on 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."

125 of 159 comments (clear)

  1. 16434! by Anonymous Coward · · Score: 3, Funny

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

    1. Re:16434! by Anonymous Coward · · Score: 3, Funny

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

    2. Re:16434! by Anonymous Coward · · Score: 1, Funny

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

    3. Re:16434! by MadnessASAP · · Score: 1

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

      --
      I may agree with what you say, but I will defend to the death your right to face the consequences of saying it.
    4. Re:16434! by despisethesun · · Score: 1

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

      --
      This poo is cold.
    5. Re:16434! by Hal_Porter · · Score: 1

      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.

      --
      echo -e 'global _start\n _start:\n mov eax, 2\n int 80h\n jmp _start' > a.asm; nasm a.asm -f elf; ld a.o -o a;
    6. Re:16434! by MadnessASAP · · Score: 1

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

      --
      I may agree with what you say, but I will defend to the death your right to face the consequences of saying it.
    7. Re:16434! by Anonymous Coward · · Score: 2, Funny

      I'm not your buddy, friend!

    8. Re:16434! by goodster · · Score: 2, Funny

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

    9. Re:16434! by Anonymous Coward · · Score: 1, Funny

      I'm not your friend, guy!

    10. Re:16434! by Rysc · · Score: 1

      I'm not your buddy, friend.

      --
      I want my Cowboyneal
    11. Re:16434! by paxcoder · · Score: 1

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

  2. Lots of code? by pclminion · · Score: 1, Informative

    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?

    1. Re:Lots of code? by Anonymous Coward · · Score: 1, Insightful

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

    2. Re:Lots of code? by Anonymous Coward · · Score: 5, Insightful

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

    3. Re:Lots of code? by beelsebob · · Score: 5, Insightful

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

    4. Re:Lots of code? by j-pimp · · Score: 5, Funny

      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.

      --
      --- Justin Dearing http://www.justaprogrammer.net/ We're just programmers.
    5. Re:Lots of code? by Anonymous Coward · · Score: 2, Informative

      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.

    6. Re:Lots of code? by cheater512 · · Score: 5, Insightful

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

    7. Re:Lots of code? by naasking · · Score: 4, Interesting

      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.

      --
      Higher Logics: where programming meets science.
    8. Re:Lots of code? by Pseudonym · · Score: 2, Insightful

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

      It depends which 16K lines.

      --
      sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
    9. Re:Lots of code? by SanityInAnarchy · · Score: 5, Interesting

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

      --
      Don't thank God, thank a doctor!
    10. Re:Lots of code? by SanityInAnarchy · · Score: 1

      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.
      --
      Don't thank God, thank a doctor!
    11. Re:Lots of code? by Atriqus · · Score: 2, Funny

      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!

      --
      Hey, look! It's Bono's brother.
    12. Re:Lots of code? by rts008 · · Score: 1

      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.

      --
      Down With Slashdot BETA!!! I've been around the corner and seen the oliphant; you can only abuse me from your perspecti
    13. Re:Lots of code? by node+3 · · Score: 4, Interesting

      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.
    14. Re:Lots of code? by Artuir · · Score: 1

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

    15. Re:Lots of code? by naasking · · Score: 1

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

      --
      Higher Logics: where programming meets science.
    16. Re:Lots of code? by naasking · · Score: 1

      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.

      --
      Higher Logics: where programming meets science.
    17. Re:Lots of code? by ianare · · Score: 1

      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.
    18. Re:Lots of code? by Basje · · Score: 1

      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.

      --
      the pun is mightier than the sword
    19. Re:Lots of code? by iowannaski · · Score: 1

      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.

      --
      i forget
    20. Re:Lots of code? by SanityInAnarchy · · Score: 1

      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.
      --
      Don't thank God, thank a doctor!
    21. Re:Lots of code? by naasking · · Score: 1

      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.

      --
      Higher Logics: where programming meets science.
  3. More like giving up by AmiMoJo · · Score: 2, Interesting

    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.

    --
    const int one = 65536; (Silvermoon, Texture.cs)
    SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
    1. Re:More like giving up by Anonymous Coward · · Score: 2, Insightful

      So long as the community supports the driver well enough, why should we care?

    2. Re:More like giving up by Cillian · · Score: 5, Interesting

      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.

      --
      -- All your booze are belong to us.
    3. Re:More like giving up by edalytical · · 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.

      --
      Win a signed Stephen Carpenter ESP Guitar from the Deftones: http://def-tag.com/?r=0008781
    4. Re:More like giving up by edsousa · · Score: 2, Informative

      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.

    5. Re:More like giving up by AmiMoJo · · Score: 3, Informative

      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.

      --
      const int one = 65536; (Silvermoon, Texture.cs)
      SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
    6. Re:More like giving up by DrSkwid · · Score: 2, Insightful

      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
    7. Re:More like giving up by Darkness404 · · Score: 2, Informative

      Look forward to documentation and X.org drivers from VIA as well in the near future

      And so they are releasing the docs. As for why a Linux driver? Linux is by far the most popular OSS OS. *BSD is nice, but it can use most Linux things because Linux is open source as are the drivers. So why would VIA support *BSD over Linux when more VIA products run on Linux by default and not *BSD (gPC, Cloudbook, Etc.) and other then *BSD there aren't a lot of OSes that are OSS and popular (About the only other one I can think of is ReactOS and that isn't very stable yet....)
      --
      Taxation is legalized theft, no more, no less.
    8. Re:More like giving up by edalytical · · Score: 1

      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.

      --
      Win a signed Stephen Carpenter ESP Guitar from the Deftones: http://def-tag.com/?r=0008781
    9. Re:More like giving up by poopdeville · · Score: 5, Interesting

      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.

      --
      After all, I am strangely colored.
    10. Re:More like giving up by AmiMoJo · · Score: 1

      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.
      --
      const int one = 65536; (Silvermoon, Texture.cs)
      SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
    11. Re:More like giving up by Anonymous Coward · · Score: 5, Informative

      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.

    12. Re:More like giving up by DrSkwid · · Score: 3, Insightful

      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
    13. Re:More like giving up by Anonymous Coward · · Score: 3, Insightful

      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.

    14. Re:More like giving up by Vegeta99 · · Score: 4, Funny

      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.

    15. Re:More like giving up by Darkness404 · · Score: 2, Interesting

      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.

      --
      Taxation is legalized theft, no more, no less.
    16. Re:More like giving up by Kjella · · Score: 2, Insightful

      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.
      --
      Live today, because you never know what tomorrow brings
    17. Re:More like giving up by LizardKing · · Score: 3, 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 ...

    18. Re:More like giving up by blind+biker · · Score: 5, Insightful

      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.
    19. Re:More like giving up by poopdeville · · Score: 1

      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.

      --
      After all, I am strangely colored.
    20. Re:More like giving up by Trogre · · Score: 1

      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.

      --
      "Nine times out of ten, starting a fire is not the best way to solve the problem." - my wife
    21. Re:More like giving up by LWATCDR · · Score: 2, Interesting

      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.

      --
      See my blog http://ilovecookes.blogspot.com/ for light hearted technical information.
    22. Re:More like giving up by JimCDiver · · Score: 1

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

    23. Re:More like giving up by Kjella · · Score: 1

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

      --
      Live today, because you never know what tomorrow brings
    24. Re:More like giving up by something_wicked_thi · · Score: 3, Insightful

      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?

    25. Re:More like giving up by sprack666 · · Score: 1

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

    26. Re:More like giving up by AstrumPreliator · · Score: 4, Insightful

      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.

    27. Re:More like giving up by ThatCanadianGuy · · Score: 1

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

    28. Re:More like giving up by SanityInAnarchy · · Score: 2, 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.

      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!
    29. Re:More like giving up by SanityInAnarchy · · Score: 1

      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.
      --
      Don't thank God, thank a doctor!
    30. Re:More like giving up by SanityInAnarchy · · Score: 3, Insightful

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

      --
      Don't thank God, thank a doctor!
    31. Re:More like giving up by SanityInAnarchy · · Score: 1

      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.
      --
      Don't thank God, thank a doctor!
    32. Re:More like giving up by Koiu+Lpoi · · Score: 1

      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.

    33. Re:More like giving up by Hal_Porter · · Score: 1

      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.
      --
      echo -e 'global _start\n _start:\n mov eax, 2\n int 80h\n jmp _start' > a.asm; nasm a.asm -f elf; ld a.o -o a;
    34. Re:More like giving up by edsousa · · Score: 1

      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.

    35. Re:More like giving up by Magada · · Score: 1

      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.

      --
      Something bad is coming when people are suddenly anxious to tell the truth.
    36. Re:More like giving up by Anonymous Coward · · Score: 1, Informative

      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.

    37. Re:More like giving up by Lead+Butthead · · Score: 2, Insightful

      Sadly not. Most hardware documentation is wrong, and errata updates are the exception rather than the norm. However, understanding what the hardware was supposed to do from reading the documentation is often better than reading a magic number filled chunk of source code. Please note that this is not a criticism of the VIA code, which may be a model of well written and documented code ...

      Basic problem is that with ASIC work being done in places like Taiwan or China (or for that matter, non-English speaking countries in general) the typical Engrish documentations are generally near worthless.
      --
      ELOI, ELOI, LAMA SABACHTHANI!?
    38. Re:More like giving up by kelnos · · Score: 1

      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.

      --
      Xfce: Lighter than some, heavier than others. Just right.
    39. Re:More like giving up by OECD · · Score: 1

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

      --
      One man's -1 Flamebait is another man's +5 Funny.
    40. Re:More like giving up by Workaphobia · · Score: 1

      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.

      --
      Evidently, the key to understanding recursion is to begin by understanding recursion. The rest is easy.
  4. long history of VIA refusing to release documntn by Anonymous Coward · · Score: 2, Insightful

    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

  5. we are geeks here by Endymion · · Score: 1

    You can use "kLoC".

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

    --
    Ce n'est pas une signature automatique.
    1. Re:we are geeks here by Anonymous Coward · · Score: 1, Funny

      That's sixteen thousand libraries of Congress!

  6. mod parent up by harry666t · · Score: 2, Informative

    > 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

  7. Re:Zombu? by Anonymous Coward · · Score: 2, Funny

    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.

  8. Re:Zombu? by gEvil+(beta) · · Score: 2, Funny

    Am I the only one that read Zombu as Zombo?

    Well, remember, anything is possible...

    --
    This guy's the limit!
  9. Re:Patents and driver signing requirements by pla · · Score: 5, Insightful

    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.

  10. Re:Zombu? by 19thNervousBreakdown · · Score: 5, Funny

    Welcome to Slashdot.

    --
    <xml><I><am><so><damn>Web 2.0</damn></so></am></I></xml>
  11. Does "framebuffer" mean no HW acceleration? by l2718 · · Score: 1

    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?

    1. Re:Does "framebuffer" mean no HW acceleration? by Chandon+Seldon · · Score: 4, 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.

      --
      -- The act of censorship is always worse than whatever is being censored. Always.
    2. Re:Does "framebuffer" mean no HW acceleration? by Dred_furst · · Score: 3, Interesting

      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

    3. Re:Does "framebuffer" mean no HW acceleration? by Mike1024 · · Score: 3, Funny

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

      --
      "Goodness me, how unlike the FBI to abuse the trust of the American public." -- The Onion
  12. Re:Patents and driver signing requirements by tepples · · Score: 2, Informative

    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.
  13. Because they've played this game before. by pavon · · Score: 4, Informative

    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.

    1. Re:Because they've played this game before. by edalytical · · Score: 2

      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.

      --
      Win a signed Stephen Carpenter ESP Guitar from the Deftones: http://def-tag.com/?r=0008781
    2. Re:Because they've played this game before. by dwater · · Score: 1

      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?

      --
      Max.
    3. Re:Because they've played this game before. by glitchvern · · Score: 3, Interesting

      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.

    4. Re:Because they've played this game before. by Hal_Porter · · Score: 1

      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

      --
      echo -e 'global _start\n _start:\n mov eax, 2\n int 80h\n jmp _start' > a.asm; nasm a.asm -f elf; ld a.o -o a;
    5. Re:Because they've played this game before. by Mike+McTernan · · Score: 2, Informative

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

      --
      -- Mike
    6. Re:Because they've played this game before. by Hal_Porter · · Score: 1

      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.

      --
      echo -e 'global _start\n _start:\n mov eax, 2\n int 80h\n jmp _start' > a.asm; nasm a.asm -f elf; ld a.o -o a;
    7. Re:Because they've played this game before. by pavon · · Score: 3, Informative

      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.

    8. Re:Because they've played this game before. by kelnos · · Score: 1

      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.

      --
      Xfce: Lighter than some, heavier than others. Just right.
  14. Re:Slashdot == press release wire by bendodge · · Score: 2, Insightful

    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.
  15. Re:Patents and driver signing requirements by td04impostor · · Score: 1

    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 )

  16. Re:Slashdot == press release wire by mqduck · · Score: 2, Insightful

    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.
  17. mod abuse? by Anonymous Coward · · Score: 2, Insightful

    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.

    1. Re:mod abuse? by Anonymous Coward · · Score: 2, Funny

      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
    2. Re:mod abuse? by LaskoVortex · · Score: 3, Funny

      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.

      --
      Just callin' it like I see it.
    3. Re:mod abuse? by harry666t · · Score: 1

      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.

    4. Re:mod abuse? by dwiget001 · · Score: 1

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

  18. Re:Slashdot == press release wire by DigiShaman · · Score: 2, Insightful

    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.
  19. Re:Slashdot == press release wire by ikeleib · · Score: 2, Funny

    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.

  20. Re:Patents and driver signing requirements by KutuluWare · · Score: 4, Insightful

    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.

  21. Re:Slashdot == press release wire by BiggerIsBetter · · Score: 1

    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.
    --
    Forget thrust, drag, lift and weight. Airplanes fly because of money.
  22. Re:Zombu? by Spatial · · Score: 1

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

  23. Re:Slashdot == press release wire by ajlitt · · Score: 1

    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.

  24. A Win for Free Softare Either way. by gnutoo · · Score: 2, Insightful

    What matters is that vendor support of free software is here to stay. This is a direct break in the Microsoft monopoly, as the Intel graphics effort was, and others will follow. Via realized it's more their best interest to have hardware that works than it is to try to extract control over people.

    Size has nothing to do with this. If the code is small and complete, it shows that Nvidia and ATI never had much to offer and we should all wonder why they never bothered to cooperate. If the code is 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.

  25. Re:Patents and driver signing requirements by SanityInAnarchy · · Score: 2, 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 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!
  26. I must have hit an extra key... by Anonymous Coward · · Score: 2, Funny

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

  27. Re:Patents and driver signing requirements by tepples · · Score: 2, 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.
  28. I'm calling bullpoop on that... by Joce640k · · Score: 1

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

    --
    No sig today...
  29. Re:Slashdot == press release wire by SanityInAnarchy · · Score: 2, 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 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.
    --
    Don't thank God, thank a doctor!
  30. Re:Patents and driver signing requirements by rts008 · · Score: 1

    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.

    --
    Down With Slashdot BETA!!! I've been around the corner and seen the oliphant; you can only abuse me from your perspecti
  31. Re:Slashdot == press release wire by Kjella · · Score: 1

    It just makes me want to pour hot grits down my pants. To each his own, I'd rather have Natalie Portman there...
    --
    Live today, because you never know what tomorrow brings
  32. Not Necessarily Patented by Doc+Ruby · · Score: 2, Informative

    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.

    --

    --
    make install -not war

  33. Re:Patents and driver signing requirements by ajs318 · · Score: 2, Insightful

    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!
  34. They would need to invalidate all patents by tepples · · Score: 3, Insightful

    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.
    1. Re:They would need to invalidate all patents by Doc+Ruby · · Score: 1

      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.

      --

      --
      make install -not war

  35. Re:Patents and driver signing requirements by tepples · · Score: 2, Informative

    H.264 decoding is a purely mathematical operation, which lies outside the scope of patentability. In which country? Slashdot is based in the United States, where video transmission systems relying on computing devices programmed with a novel algorithm are considered novel.

    You might be able to patent a particular device capable of performing that operation, but not the operation itself. "The operation" is transmitting video, and "a particular device capable of performing that operation" is a computer programmed with the H.264 algorithms.

    Any device differing substantially from the implementation described in the patent would not be covered under the patent. Any device differing substantially from the implementation as described in the patent would also not be able to decode a video bitstream that conforms to the H.264 specification.
  36. How to make that part of the FOSS community happy. by LWATCDR · · Score: 1

    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.

    --
    See my blog http://ilovecookes.blogspot.com/ for light hearted technical information.