×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

VIA Releases 16K-Line FOSS Framebuffer Driver

kdawson posted more than 5 years ago | from the can-only-get-better-from-here dept.

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

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

159 comments

Zombu? (0, Offtopic)

niteice (793961) | more than 5 years ago | (#23371352)

Am I the only one that read Zombu as Zombo [zombo.com]?

Re:Zombu? (-1, Offtopic)

Anonymous Coward | more than 5 years ago | (#23371560)

A few years ago, while browsing around the library downtown, I had to take a piss. As I entered the john, a big beautiful all-American football hero type, about twenty five, came out of one of the booths. I stood at the urinal looking at him out of the corner of my eye as he washed his hands. He didn't once look at me. He was "straight" and married -- and in any case I was sure I wouldn't have a chance with him.

As soon as he left, I darted into the booth he'd vacated, hoping there might be a lingering smell of shit and even a seat still warm from his sturdy young ass. I found not only the smell but the shit itself. He'd forgotten to flush. And what a treasure he had left behind. Three or four beautiful specimens floated in the bowl. It apparently had been a fairly dry, constipated shit, for all were fat, stiff, and ruggedly textured. The real prize was a great feast of turd -- a nine inch gastrointestinal triumph as thick as a man's wrist. I knelt before the bowl, inhaling the rich brown fragrance and wondered if I should obey the impulse building up inside me. I'd always been a heavy rimmer and had lapped up more than one little clump of shit, but that had been just an inevitable part of eating ass and not an end in itself.

Of course I'd had jerkoff fantasies of devouring great loads of it (what rimmer hasn't?), but I had never done it. Now, here I was, confronted with the most beautiful five-pound turd I'd ever feasted my eyes on, a sausage fit to star in any fantasy and one I knew to have been hatched from the asshole of the world's handsomest young stud.

Why not? I plucked it from the bowl, holding it with both hands to keep it from breaking.

I lifted it to my nose. It smelled like rich, ripe limburger (horrid, but thrilling), yet had the consistency of cheddar. What is cheese anyway but milk turning to shit without the benefit of a digestive tract? I gave it a lick and found that it tasted better then it smelled. I've found since then that shit nearly almost does. I hesitated no longer. I shoved the fucking thing as far into my mouth as I could get it and sucked on it like a big brown cock, beating my meat like a madman. I wanted to completely engulf it and bit off a large chunk, flooding my mouth with the intense, bittersweet flavor. To my delight I found that while the water in the bowl had chilled the outside of the turd, it was still warm inside. As I chewed I discovered that it was filled with hard little bits of something I soon identified as peanuts. He hadn't chewed them carefully and they'd passed through his body virtually unchanged. I ate it greedily, sending lump after peanutty lump sliding scratchily down my throat. My only regret was the donor of this feast wasn't there to wash it down with his piss. I soon reached a terrific climax. I caught my cum in the cupped palm of my hand and drank it down. Believe me, there is no more delightful combination of flavors than the hot sweetness of cum with the rich bitterness of shit. Afterwards I was sorry that I hadn't made it last longer. But then I realized that I still had a lot of fun in store for me. There was still a clutch of virile turds left in the bowl. I tenderly fished them out, rolled them into my hankercheif, and stashed them in my briefcase.

In the week to come I found all kinds of ways to eat the shit without bolting it right down. Once eaten it's gone forever unless you want to filch it third hand out of your own asshole -- not an unreasonable recourse in moments of desperation or simple boredom.

I stored the turds in the refrigerator when I was not using them but within a week they were all gone.

The last one I held in my mouth without chewing, letting it slowly dissolve. I had liquid shit trickling down my throat for nearly four hours. I must have had six orgasms in the process. I often think of that lovely young guy dropping solid gold out of his sweet, pink asshole every day, never knowing what joy it could, and at least once did,bring to a grateful shiteater.

Re:Zombu? (2, Funny)

Anonymous Coward | more than 5 years ago | (#23371770)

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.

16434! (3, Funny)

Anonymous Coward | more than 5 years ago | (#23371400)

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

Re:16434! (3, Funny)

Anonymous Coward | more than 5 years ago | (#23371490)

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

Re:16434! (1, Funny)

Anonymous Coward | more than 5 years ago | (#23373002)

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

Re:16434! (0)

Anonymous Coward | more than 5 years ago | (#23371884)

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

Lots of code? (1, Informative)

pclminion (145572) | more than 5 years ago | (#23371404)

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? (1, Insightful)

Anonymous Coward | more than 5 years ago | (#23371550)

it says 16,434

less lines same task = better.

I remember IBM used to (around about the same time they wouldn't hire guys with beards in the 80's) look at productivity by the lines of code instead of the task..off topic ramble...

Re:Lots of code? (5, Funny)

j-pimp (177072) | more than 5 years ago | (#23371732)

I remember IBM used to (around about the same time they wouldn't hire guys with beards in the 80's)

IBM didn't hire guys with beards? Well that completely explains AIX.

Re:Lots of code? (5, Insightful)

Anonymous Coward | more than 5 years ago | (#23371690)

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

mod parent up (2, Informative)

harry666t (1062422) | more than 5 years ago | (#23371722)

> 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

mod abuse? (2, Insightful)

Anonymous Coward | more than 5 years ago | (#23372748)

Dear /.,

I'm concerned that giving moderation access to most everyone is counterproductive. This didn't require any moderation at all. Flamebait? No. Redundant maybe, but not to the point that it's annoying. This should not have been moderated at all. The point of moderation is to find and highlight gems not bitch slap people at random.

Thanks,
Anon.

Re:mod abuse? (2, Funny)

Anonymous Coward | more than 5 years ago | (#23372852)

Dear /., I'm concerned that giving moderation access to most everyone is counterproductive. This didn't require any moderation at all. Flamebait? No. Redundant maybe, but not to the point that it's annoying. This should not have been moderated at all. The point of moderation is to find and highlight gems not bitch slap people at random. Thanks, Anon.
DAMN RIGHT

Re:Lots of code? (2, Informative)

Anonymous Coward | more than 5 years ago | (#23371812)

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

Re:Lots of code? (-1, Flamebait)

Anonymous Coward | more than 5 years ago | (#23373250)

do you think, that if you need thousands of lines for page flipping, that you are doing the right thing?

i am more in opengl than in directx, but this seems to be completely moronic to me

Re:Lots of code? (0)

Anonymous Coward | more than 5 years ago | (#23373434)

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

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

Re:Lots of code? (5, Interesting)

SanityInAnarchy (655584) | more than 5 years ago | (#23373592)

I think they're legitimate criticisms.

That said, I'm also going to seriously look at VIA the next time I build a MythTV box. You're never going to escape criticism, no matter what you do -- but VIA absolutely did the right thing there, and I applaud them for that.

Thank you, VIA. Looks like some genuine competition for Intel as the "most well-supported Linux video cards."

Re:Lots of code? (2, Funny)

Atriqus (826899) | more than 5 years ago | (#23373900)

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

Now grab your pitchfork and stop trying to be rational!

Re:Lots of code? (1)

rts008 (812749) | more than 5 years ago | (#23373930)

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.

I have an idea (-1, Flamebait)

aztektum (170569) | more than 5 years ago | (#23371726)

Now that the code is available

1) Who cares?

2) Stop posting on /. and see what you can to trim it down.

Re:I have an idea (-1, Flamebait)

Anonymous Coward | more than 5 years ago | (#23372180)

2) Stop posting on /. and see what you can to trim it down.


Or better yet, see what you can do to trim it down. Try getting off your lazy ass and proofreading before you presume to tell anyone else what they should do, you fucking douchebag. Speaking of trimming something down, I bet that lazy ass of yours is also a big blubbery fatass too.

Re:Lots of code? (5, Insightful)

beelsebob (529313) | more than 5 years ago | (#23371730)

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

Re:Lots of code? (4, Interesting)

naasking (94116) | more than 5 years ago | (#23372622)

1. Why tout 16K lines? Why give an exact number? It's like it's a boast. Except it doesn't really take that long to write 16K lines, so it's sort of a weak boast.

Well, studies have repeatedly shown that a single developer only adds about 20 correct lines of code per day. Assuming this is high quality code that has been well-tested, those 16K lines of code are nothing to scoff at.

2. On the other hand, I wonder why so many lines simply to give me a framebuffer? The card has to be programmed into the right mode, sure, but how can that possibly require 16 thousand lines?

That was my first thought too.

Re:Lots of code? (1)

SanityInAnarchy (655584) | more than 5 years ago | (#23373620)

Well, studies have repeatedly shown that a single developer only adds about 20 correct lines of code per day. Assuming this is high quality code that has been well-tested, those 16K lines of code are nothing to scoff at.
That's exactly why I'd be skeptical of it.

I mean, I'm not suggesting every app needs to be an exercise in golfing, but remember, 20 correct lines -- and I bet that's irrespective of language, which is why I prefer concise, high-level languages.

In general, which is more likely -- that there are 16k of high-quality, well-tested code? Code that's as simple as it can possibly be, but no simpler? (Apologies to Einstein.)

But often, it's 16k of absolutely horrible, untested spaghetti code, written by too small of a team on too short a deadline -- that of course got pushed back, because rushing meant, in some cases, code that was actually too buggy to use.

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

Re:Lots of code? (2, Insightful)

Pseudonym (62607) | more than 5 years ago | (#23372666)

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

It depends which 16K lines.

A Win for Free Softare Either way. (2, Insightful)

gnutoo (1154137) | more than 5 years ago | (#23373636)

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

Size has nothing to do with this. If the code is small and complete, it shows that Nvidia and ATI never had much to offer and we should all wonder why they never bothered to cooperate. If the code is incomplete, more has been promised and will be delivered. All of this is great news.

Thanks VIA. Good graphics joins good power efficiency in the VIA appeal.

Re:A Win for Free Softare Either way. (0)

Anonymous Coward | more than 5 years ago | (#23373822)

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

More like giving up (2, Interesting)

AmiMoJo (196126) | more than 5 years ago | (#23371410)

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

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

Re:More like giving up (2, Insightful)

Anonymous Coward | more than 5 years ago | (#23371512)

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

Patents and driver signing requirements (0, Offtopic)

tepples (727027) | more than 5 years ago | (#23371738)

So long as the community supports the driver well enough, why should we care?
Two reasons. For one thing, H.264 is patented. So VIA needs to support the decoder, even if only by acting as a patent sublicensor to the community. In addition, Windows Vista 64-bit requires that all drivers that include a kernel-mode component be published by an established company, or the operating system will display unhideable "Test mode" banners in the four corners of the screen.

Re:Patents and driver signing requirements (0, Offtopic)

Darkness404 (1287218) | more than 5 years ago | (#23371792)

In addition, Windows Vista 64-bit requires that all drivers that include a kernel-mode component be published by an established company, or the operating system will display unhideable "Test mode" banners in the four corners of the screen.


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

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

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

Re:Patents and driver signing requirements (5, Insightful)

pla (258480) | more than 5 years ago | (#23371848)

In addition, Windows Vista 64-bit requires

Which has what, exactly, to do with a Linux framebuffer driver?

Sure, having the source, we could proably port it to the Windows world, but the Windows world has no shortage of drivers already. Granted, they don't always count as the most reliable option, but at the risk of sounding a tad snarky - You run Vista 64-bit, "reliable" doesn't really enter the picture.

Re:Patents and driver signing requirements (2, Informative)

tepples (727027) | more than 5 years ago | (#23371980)

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

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

Re:Patents and driver signing requirements (-1, Offtopic)

Anonymous Coward | more than 5 years ago | (#23372140)

way to selectively quote irrelevant stuff. try this one instead

Via just don't want to develop their Linux drivers any more. Watch as support disappears now they don't have to.
now what does windows have to do with these open source linux drivers again

Re:Patents and driver signing requirements (1)

td04impostor (1200577) | more than 5 years ago | (#23372652)

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

Re:Patents and driver signing requirements (4, Insightful)

KutuluWare (791333) | more than 5 years ago | (#23373088)

Please can we stay even a bit on topic here? We're talking about a Linux Framebuffer Driver here. You can't use the Linux framebuffer device drivers on Windows because they're not Windows Drivers. That's ignoring the fact that Windows already has all the display drivers it needs to use this hardware, so claiming that VIA "won't support" their hardware on Windows is just ridiculous.

Taking some arbitrary good deed by a hardware vendor and tacking a cynical "I bet it doesn't work on Windows" doesn't make you smart or insightful -- it makes your just another slashdouche.

Re:Patents and driver signing requirements (2, Insightful)

SanityInAnarchy (655584) | more than 5 years ago | (#23373650)

For one thing, H.264 is patented.
I'm not sure entirely how this affects us. We wouldn't be implementing H.264 so much as calling the existing (patented) hardware implementation, right?

Unless, of course, they exaggerated how much hardware help they had.

In addition, Windows Vista 64-bit requires that all drivers that include a kernel-mode component be published by an established company, or the operating system will display unhideable "Test mode" banners in the four corners of the screen.
Is this something that it's impossible for the user to override? In other words, is the set of certificates or CAs hardcoded, or is it user-modifiable?

Regardless, I don't see how this affects us, either. These are drivers for Linux, so it's good that they're open. It means they can't be GPLv3, but neither can Linux itself. And it means we can't then port them to Vista 64-bit -- seems like a small loss to me.

Re:Patents and driver signing requirements (2, Insightful)

tepples (727027) | more than 5 years ago | (#23373778)

I'm not sure entirely how this affects us. We wouldn't be implementing H.264 so much as calling the existing (patented) hardware implementation, right?

Unless, of course, they exaggerated how much hardware help they had.
I bet that's the case. In the late 1990s, I sometimes had to endure slowdown caused by "modems" that were not much more than a sound card. They employed "host signal processing", which put all the modulating and demodulating into a driver on the CPU. Likewise, video codec accelerator chips might accelerate only a few steps, such as the frequency domain block transform, the motion reconstruction, and the YCC to RGB conversion, leaving the rest to the driver.

Re:Patents and driver signing requirements (1)

rts008 (812749) | more than 5 years ago | (#23373994)

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

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

Re:More like giving up (5, Interesting)

Cillian (1003268) | more than 5 years ago | (#23371516)

Community support is often better than that given by companies, and now community support is possible. I think it's be difficult to see this as a bad thing.

Re:More like giving up (2, Interesting)

LWATCDR (28044) | more than 5 years ago | (#23372926)

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

Re:More like giving up (5, Insightful)

edalytical (671270) | more than 5 years ago | (#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.

Re:More like giving up (3, Informative)

AmiMoJo (196126) | more than 5 years ago | (#23371686)

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.

Re:More like giving up (1)

edalytical (671270) | more than 5 years ago | (#23371854)

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.

Re:More like giving up (5, Interesting)

poopdeville (841677) | more than 5 years ago | (#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.

Re:More like giving up (1)

AmiMoJo (196126) | more than 5 years ago | (#23372006)

And why would you expect random software to know about and make calls to VIA's API? H.264 decoding isn't exactly a DirectX function as far as I know. Indeed, isn't this why you have to install an H.264 codec in the first place?


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

Absurd. You got what you paid for.


That is debatable. If nVidia claimed H.264 acceleration, but in actual fact only supplied some docs I think most of their target market might be a little bit upset about that. Considering they are selling consumer devices, and most consumers are not programmers. Also, when the C7 came out years ago, there were no docs, and when the did finally come, they were poor.

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

Re:More like giving up (1)

poopdeville (841677) | more than 5 years ago | (#23372454)

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

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

That is debatable. If nVidia claimed H.264 acceleration, but in actual fact only supplied some docs I think most of their target market might be a little bit upset about that. Considering they are selling consumer devices, and most consumers are not programmers. Also, when the C7 came out years ago, there were no docs, and when the did finally come, they were poor.

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

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

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

Re:More like giving up (1)

SanityInAnarchy (655584) | more than 5 years ago | (#23373806)

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 [wikipedia.org] can figure it out, so can VIA.

Re:More like giving up (2, Insightful)

SanityInAnarchy (655584) | more than 5 years ago | (#23373716)

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 looks like VIA didn't even try.

It's up to cryptography library writers/PMs to determine whether they want to fold VIA encryption acceleration into THEIR libraries.
Assuming they're supporting Linux, there are kernel drivers for various crypto algorithms, and I believe some can optionally use hardware acceleration where it's available. It would be trivial for them to at least enable that much.

In software, most crypto seems to be done by openssl or gpg, both of which have fairly centralized, well-established libraries.

So it's pretty clear what you'd have to do to get the crypto stuff supported by pretty much every Linux app that isn't statically linked.

Re:More like giving up (1)

sprack666 (877400) | more than 5 years ago | (#23373322)

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

Because they've played this game before. (4, Informative)

pavon (30274) | more than 5 years ago | (#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.

Re:Because they've played this game before. (2)

edalytical (671270) | more than 5 years ago | (#23372514)

I believe this is probably true, but can you provide a link to a primary source? I'd like to see a FOSS developers blog post or something from a developer mailing list.

Again I don't doubt you, I'd just like to read about this in depth. My googling is coming up short.

Re:Because they've played this game before. (1)

dwater (72834) | more than 5 years ago | (#23372924)

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

Re:More like giving up (2, Informative)

edsousa (1201831) | more than 5 years ago | (#23371610)

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 (5, Informative)

Anonymous Coward | more than 5 years ago | (#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:More like giving up (-1, Offtopic)

Anonymous Coward | more than 5 years ago | (#23373010)

> Now, the fact they're binary sucks, but they're binary on windows too.

Wow, that was difficult to read...I first thought you mean "their" instead of "they're", which would make the first part was commenting on the quality of their binary.

...but then the second part of the sentence didn't make sense.

Then I figured you really did mean "they're", and you're commenting that there's no source, on either Linux or Windows.

If that's so, it would be helpful to have a "that", ie "the fact *that* they're binary sucks" - that makes it more readable for me, at least. YMMV.

Re:More like giving up (0)

Anonymous Coward | more than 5 years ago | (#23373016)

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

Re:More like giving up (0)

Anonymous Coward | more than 5 years ago | (#23373450)

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

Re:More like giving up (2, Insightful)

DrSkwid (118965) | more than 5 years ago | (#23371688)

There's more to the OSS world than Linux, I'd rather they released the docs than write a line of Linux code.

Re:More like giving up (2, Informative)

Darkness404 (1287218) | more than 5 years ago | (#23371758)

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


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

Re:More like giving up (3, Insightful)

DrSkwid (118965) | more than 5 years ago | (#23372048)

The world benefits from docs not drivers.
BSD and Linux drivers for framebuffers will be rather different.
VIA will never ever support my OS of choice (Plan9) and I don't expect them to, thats what the documentation is for. And no, source code is not documentation when it comes to drivers, it's one person's interpretation of what they read/fiddled with to get it to work. Porting drivers is more work that you seem to think.

Re:More like giving up (4, Funny)

Vegeta99 (219501) | more than 5 years ago | (#23372118)

Plan9?

For some reason, that just makes me think of someone driving down the road in a Hydrogen-powered Fiat to work at a Texas oil field.

Re:More like giving up (3, Insightful)

something_wicked_thi (918168) | more than 5 years ago | (#23373170)

The world benefits from docs not drivers.

Right. It's good to know that I've been running my computer on docs all this time. No, docs just let you write more drivers.

Porting drivers is more work that you seem to think.

And writing drivers is more work than you seem to think. Do you honestly believe that writing a driver from scratch, given the docs, is easier than porting a working driver given the docs?

Re:More like giving up (3, Insightful)

Anonymous Coward | more than 5 years ago | (#23372062)

Linux is by far the most popular OSS OS. *BSD is nice, but it can use most Linux things because Linux is open source as are the drivers.

I'm not exactly sure what you're trying to say there, but I read it as "BSD can just copy the source code from Linux". If that's the case, there's a technical reason why you're wrong, and a non-technical reason why you're wrong.

Most "Linux things" can run on BSD because they are both UNIX-like operating systems, meaning they both implement enough of POSIX to make porting back and forth easier than porting to a non-POSIX system. But that only works for user software. The underlying kernel architectures and code are massively different, and anything that has to interact directly with the kernel, such as device drivers, are significantly different between the two operating systems. It's nowhere near as trivial as you imply.

Secondly, even if it were technically possiblethe license for BSD and Linux aren't necessarily compatible. BSD kernels and (most) drivers are under the (shock) BSD license, which, for better or worse, is more lenient than the GPL. The result is that you can't copy Linux code into BSD kernels because BSD allows the source to be used in a closed source product, while the GPL doesn't.

Re:More like giving up (2, Interesting)

Darkness404 (1287218) | more than 5 years ago | (#23372128)

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

As for the licensing, I was assuming that VIA would release most code under some license other then the GPL (such as the BSD license) that would allow use in proprietary products. And, as in true /. fashion, I didn't read TFA.

Re:More like giving up (1)

SanityInAnarchy (655584) | more than 5 years ago | (#23373884)

I was assuming that VIA would release most code under some license other then the GPL (such as the BSD license) that would allow use in proprietary products.
Pointless for two reasons.

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

Which brings us to the second reason: If VIA wants to use their driver in proprietary software, there's nothing stopping them, because they have copyright. They can release it under as many licenses as they want, so long as the license doesn't require them to give up copyright. MANY open source projects are "dual-licensed" -- there's a commercial version, which comes with support, under a different license, and costs money, and then there's the GPL'd version, for which the project generally only accepts contributions which give them copyright.

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

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

Re:More like giving up (2, Insightful)

Kjella (173770) | more than 5 years ago | (#23372156)

There's more to the OSS world than Linux, I'd rather they released the docs than write a line of Linux code.
True, but I think it's easier to make working documentation out of working code than working code out of non-working documentation... Documentation is nice, but if you have someone that's already put it all together to form a driver I'd be happy not sad.

Re:More like giving up (3, Insightful)

LizardKing (5245) | more than 5 years ago | (#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 ...

Re:More like giving up (1)

Kjella (173770) | more than 5 years ago | (#23373114)

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

Re:More like giving up (5, Insightful)

blind biker (1066130) | more than 5 years ago | (#23372322)

When did the FOSS community become this collection of curmudgeons? When a company releases code, it should be politely welcomed. After all, they didn't _have to_ but they still did, because there's this little light that open source software could benefit many instead of the few. And then a bunch of cranky and unpleasant douchebags find the nerve to complain? I can't believe this.

Re:More like giving up (4, Insightful)

AstrumPreliator (708436) | more than 5 years ago | (#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.

Re:More like giving up (1)

Trogre (513942) | more than 5 years ago | (#23372776)

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.

long history of VIA refusing to release documntn (2, Insightful)

Anonymous Coward | more than 5 years ago | (#23371694)

for those with short memories it might be worth reading the many years of complaints and downright hostility between OS developers and VIA - VIA's Australian mouthpiece Fiona has promised many times in past that info would be forthcoming - never was - until they release sensible info on the hardware (including all the numerous mis-designs that the windoze package codes around) a good driver will be a pipedream

we are geeks here (1)

Endymion (12816) | more than 5 years ago | (#23371716)

You can use "kLoC".

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

Re:we are geeks here (1, Funny)

Anonymous Coward | more than 5 years ago | (#23372122)

That's sixteen thousand libraries of Congress!

Does "framebuffer" mean no HW acceleration? (1)

l2718 (514756) | more than 5 years ago | (#23371940)

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

Re:Does "framebuffer" mean no HW acceleration? (4, Informative)

Chandon Seldon (43083) | more than 5 years ago | (#23372016)

If that were true, it wouldn't take 16 kLoC for a driver. With that much code, it's exposing quite a bit of hardware-specific functionality - which means hardware acceleration for something.

Re:Does "framebuffer" mean no HW acceleration? (3, Interesting)

Dred_furst (945617) | more than 5 years ago | (#23372046)

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

Slashdot == press release wire (0, Troll)

ikeleib (125180) | more than 5 years ago | (#23372254)

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

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

Give me a break.

Re:Slashdot == press release wire (2, Insightful)

bendodge (998616) | more than 5 years ago | (#23372500)

Slashdot tends to gush whenever anyone does something nice specifically for the Linux community. Much of what Linux has in hardware support has been painfully achieved reverse-engineering.

Re:Slashdot == press release wire (2, Insightful)

mqduck (232646) | more than 5 years ago | (#23372678)

Not sure why you're complaining. Heck, Slashdot would provide a community service to announce this as an official offer. "Open-source your hardware driver, get a free glowing review press release as a Slashdot story."

Re:Slashdot == press release wire (2, Insightful)

DigiShaman (671371) | more than 5 years ago | (#23372900)

This post just gushes about VIA.

Of course, and why not? This post is about VIA providing drivers for the Linux OS.

Since when did slashdot become a site for vendors to have their sock puppets write glowing posts for them?

Based on your account number, your obviously not new around here. So why did you even make this statement? Come on, you know the answer to that. But in case you forgot I will tell you.

Slashdot will praise any company and/or its technology that provides unobstructed freedom and functionality for all the worlds' geeks. As such, they deserve to be praised. After all, this is the kind of behavior we want to encourage is it not?

Re:Slashdot == press release wire (2, Funny)

ikeleib (125180) | more than 5 years ago | (#23373034)

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

Back in my day, when trolls were trolls and karma was numeric, slashdot was too obscure for companies to astroturf. It was fanboi vs fanboi for glowing praise and the comment threads were full of flame. How I miss the days of ole'. It just makes me want to pour hot grits down my pants.

Re:Slashdot == press release wire (1)

Kjella (173770) | more than 5 years ago | (#23374072)

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

Re:Slashdot == press release wire (1)

BiggerIsBetter (682164) | more than 5 years ago | (#23373276)

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

Re:Slashdot == press release wire (1)

ajlitt (19055) | more than 5 years ago | (#23373426)

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

Re:Slashdot == press release wire (2, Insightful)

SanityInAnarchy (655584) | more than 5 years ago | (#23373928)

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.
Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...