Become a fan of Slashdot on Facebook

 



Forgot your password?
typodupeerror
×
Graphics Software Linux

VIA Releases 16K-Line FOSS Framebuffer Driver 159

billybob2 writes "VIA has released 16,434 Lines Of Free & Open Source code that enables Linux natively to use the framebuffer on VIA's graphics chipsets. This comes a month after VIA announced that it will provide Open-Source drivers and documentation on its Web site so that its hardware will work out of the box with Linux distributions. This gives VIA-powered systems that come pre-installed with Linux — such as the gPC, 15.4" gBook, CloudBook, and Zonbu — the ability to output graphics through digital connections such as HDMI, and probably makes them the best-supported framebuffers Linux has ever had. Look forward to documentation and X.org drivers from VIA as well in the near future."
This discussion has been archived. No new comments can be posted.

VIA Releases 16K-Line FOSS Framebuffer Driver

Comments Filter:
  • 16434! (Score:3, Funny)

    by Anonymous Coward on Sunday May 11, 2008 @03:47PM (#23371400)
    Hey, that's 46 lines too much! Quick, someone delete 46 empty / comment lines!
    • Re: (Score:3, Funny)

      by Anonymous Coward
      Erm, I mean, 50 lines. Apparently I'm incapable of calculating a simple substraction in head. I blame... canadians!
  • More like giving up (Score:2, Interesting)

    by AmiMoJo ( 196126 )
    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: (Score:2, Insightful)

      by Anonymous Coward
      So long as the community supports the driver well enough, why should we care?
    • by Cillian ( 1003268 ) on Sunday May 11, 2008 @04:01PM (#23371516) Homepage
      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: (Score:3, Interesting)

        by LWATCDR ( 28044 )
        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.
    • by edalytical ( 671270 ) on Sunday May 11, 2008 @04:03PM (#23371528)

      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.

      • by AmiMoJo ( 196126 ) on Sunday May 11, 2008 @04:22PM (#23371686) Homepage Journal
        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 [theinquirer.net]

        There are loads of posts on the Via forums about this. The cryptographic acceleration is next to useless as well, since nothing much supports it. Vendors should be expected to support the features they claim to have themselves, not rely on open source projects to do it.
        • But how does a product released in 2007 (from your link) supersede an announcement made on April 8, 2008 [via.com.tw]?

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

          • by kelnos ( 564113 )
            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.
        • by poopdeville ( 841677 ) on Sunday May 11, 2008 @04:51PM (#23371892)
          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.
          • by AmiMoJo ( 196126 )

            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 u

          • Re: (Score:3, Insightful)

            And why would you expect random software to know about and make calls to VIA's API? H.264 decoding isn't exactly a DirectX function as far as I know.

            You know, it's really funny when people make statements like that, qualified with "as far as I know", and then turn out to be precisely as wrong as you could possibly be. [wikipedia.org]

            No, it's not h.264-specific, but it is a generic way to provide any codec. So all they have to do is provide their own DirectShow h.264 codec, and every app that uses DirectShow codecs will have hardware-accelerated h.264.

            At that point, if, say, Flash isn't using DirectShow (I don't know either way), then that will be their fault. But it l

      • by pavon ( 30274 ) on Sunday May 11, 2008 @05:29PM (#23372232)
        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.
        • 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.

          • by glitchvern ( 468940 ) on Monday May 12, 2008 @12:32AM (#23374814) Homepage
            Will an article [phoronix.com] 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: (Score:3, 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 [slashdot.org]

            Also, had the Via Arena forums not been erased when being replaced by the new TK Arena [tkarena.com] forums, you'd have been able to see many many posts complaining about driver support and frustrated users trying to work out how to get their boards working. Still, the TK Arena hasn't been up that long, but some of the
        • by dwater ( 72834 )
          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?
          • by kelnos ( 564113 )
            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 featu
    • Re: (Score:2, Informative)

      by edsousa ( 1201831 )
      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.
      • by Anonymous Coward on Sunday May 11, 2008 @05:05PM (#23372022)

        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: (Score:3, Insightful)

      by DrSkwid ( 118965 )
      There's more to the OSS world than Linux, I'd rather they released the docs than write a line of Linux code.
      • Re: (Score:2, Informative)

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

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

        • by DrSkwid ( 118965 ) on Sunday May 11, 2008 @05:09PM (#23372048) Journal
          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: (Score:3, Insightful)

          by 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 por

          • Re: (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.
            • I was assuming that VIA would release most code under some license other then the GPL (such as the BSD license) that would allow use in proprietary products.

              Pointless for two reasons.

              First, the incompatibility goes both ways -- BSD code cannot be GPL'd, because BSD includes an advertising clause that the GPL doesn't. The few times drivers have made it across, it's been because the original, sole author gave permission.

              Which brings us to the second reason: If VIA wants to use their driver in proprietary software, there's nothing stopping them, because they have copyright. They can release it under as many licenses as they want, so long as the license doesn't re

      • Re: (Score:3, Insightful)

        by Kjella ( 173770 )

        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.
        • by LizardKing ( 5245 ) on Sunday May 11, 2008 @05:41PM (#23372302)

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

          • by Kjella ( 173770 )
            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: (Score:3, Insightful)

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

            Basic problem is that with ASIC work being done in places like Taiwan or China (or for that matter, non-English speaking countries in general) the typical Engrish documentations are generally near worthless.

    • by blind biker ( 1066130 ) on Sunday May 11, 2008 @05:43PM (#23372322) Journal
      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.
      • by AstrumPreliator ( 708436 ) on Sunday May 11, 2008 @08:52PM (#23373508)
        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.
    • by Trogre ( 513942 )
      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.

    • by Magada ( 741361 )
      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.
  • by 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
  • You can use "kLoC".

    I saw "N-line ... framebuffer" and thought it was about some new, very-high resolution display technology...
  • 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?

Genius is ten percent inspiration and fifty percent capital gains.

Working...