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

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]

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

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

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

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.

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

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

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.

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.

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.