This is a read-only archive. Find the latest Linux articles, documentation, and answers at the new!

Feature: Open Source

Two views on VIA's open source release

By Jay Lyman on May 05, 2005 (8:00:00 AM)

Share    Print    Comments   

It appeared the open source community had a bone thrown to it by VIA, which announced open driver source codes earlier this month. However, those experienced in providing the needed Linux drivers, including developers of the Unichrome Project, said there are still proprietary roadblocks in using VIA's released drivers with Linux. They add that while their pure open source project is successfully bridging the gap, VIA would have been better off participating in the community effort rather than forking code for the sake of its press releases.

For a number of reasons -- mostly cost and its presence in emerging markets -- VIA has long been the graphics hardware of choice for Linux users. However, the company's drivers have been closed source, and there has long been friction between VIA and the open source community, which has been successful in recent years in opening the drivers primarily through efforts such as Unichrome.

Ivor Hewitt, one of four core developers behind the Unichrome driver that provides open source support for the VIA/S3G Unichrome graphics controller, said VIA's history on the matter illustrates a lackluster approach and rocky relationship with open source developers. Hewitt, who began reverse-engineering the ddmpeg library after he became frustrated working with VIA's limited code and API releases, said VIA's open source plan has missed the point.

"Attempts to discuss these problems were met with silence or simply statements that they had released their API and would not be providing any more information," Hewitt said in an email to NewsForge. "They didn't even provide a reference manual for their proprietary API."

Hewitt explained that after attempts to work with VIA and the company's code, open source developers chose to drop the ddmpeg interface and extend the standard XvMC interface used by Nvidia to provide MPEG acceleration. Use of the standard API proved fruitful, as illustrated by the MPlayer interface, which took only two days to be implemented.

Hewitt -- who also complained the VIA open source package contains a non-free, opaque binary library that encapsulates its MPEG interface -- said that although VIA's source code releases are a recognition of the significant Linux market, they miss the point of community development.

"It provides hope in the fact that it shows that VIA now considers the Linux market to be an important one," he wrote. "On the other hand, it is disheartening when I hear statements from VIA saying, 'We hope this will encourage open source developers to support our platform.' Open source developers have been supporting their platform as best they can. VIA, however, has simply not been engaging with the community. VIA refuses to release programming specifications for their MPEG chipsets; these have to be reverse-engineered to work, which is simply crazy. It is a complete waste of time and effort. I think we simply need to look at VIA's actions to date to decide whether they have a constructive, cohesive open source policy."

"I wouldn't describe it as a marketing scam, but they just seem to be getting it so wrong," Hewitt continued. "Perhaps it is fear of getting involved and losing control, and they won't retain complete control of all code written for their platform. This really is missing the point of open source. For example, take their actions over Xine and MPlayer -- they forked the entire codebase of both projects simply to add support for the ddmpeg library. They didn't get involved in the projects, they didn't contribute to the mailing lists, and then they make a bold press release announcement saying they have contributed to the open source community by providing an 'enhanced' version. This is not the right way to contribute to the open source community."

Hewitt also expressed some concern that Unichrome will now be facing competition from a major corporation that has technical specs, a large team of developers, and marketing power.

"How are we going make our voices heard when VIA up 'til now has always tried to steer customers to their binary drivers and will now try to steer them to their source drivers instead?" he said.

Nevertheless, Hewitt described Unichrome as a healthy project, and indicated the community will likely find the open source effort more advantageous.

"I don't think people will choose the Unichrome project driver simply because it is completely open source," he said. "I think they will make that decision based on the fact that there is a vibrant developer community around our driver, there are mailing lists they can discuss problems in, and they can clearly see all the changes we make to our code and why."

'This is not open source'

Luc Verhaegen, who started the Unichrome Project, echoed Hewitt and argued the code recently released by VIA has been available for quite some time. "All it did was drop the request form nonsense," Verhaegen said in an email to NewsForge.

That "nonsense," as Verhaegen described it, has been accompanied by VIA ignoring all X-related work and making "quite irregular releases," making the source code available through an Open Source Developers (OSD) request form.

"Here, they had people request source, after which some drone reviewed the application and could accept it or reject it without ever getting word back (which has happened several times)," he wrote. "This is not open source."

Verhaegen said after his verbosity on the OSD, he was able to connect with VIA's Joseph Chan -- who is part of the software development team in VIA's Taipei office -- to fix some dogging issues: fixing of non-free licenses; offering tarballs for direct download to free up admin support on Via Arena, where Verhaegen was banned for using the words "Linux, buzzword, marketing, and scam" in a question, he said; and change to a disclaimer issue with VIA's version of the MIT license, which Verhaegen said is only partially fixed.

"For any new file we drag in, we need to start begging again," he said.

Verhaegen -- who called VIA's latest press release "a half truth" and "hugely blown out of proportion" -- added that VIA is further antagonizing the community by trying to regulate the distribution of source code it claims to have opened, and by abstaining from participation in active open source projects.

"VIA keeps on ignoring open source developers and users, and keeps on forking highly active and high-profile open source projects," he said. "There is no help for anyone on VIA Arena, especially not if you happen to use anything but the latest Windows XP (beware if you use anything but Internet Explorer). There is and will be no change in VIA's behavior towards the free and open source world."

Next: VIA responds

Share    Print    Comments   


on Two views on VIA's open source release

Note: Comments are owned by the poster. We are not responsible for their content.

I don't think VIA completely understands

Posted by: Anonymous Coward on May 05, 2005 07:43 PM

Having read both sides, I conclude that VIA still hasn't really got the picture. They're obsessed with the "value" of their "intellectual property". That means they've spent a lot of resources writing drivers in the past, and can't bring themselves to face up to the fact that the monetary value of all that is now zero. It's a sunk cost. They're a hardware company and should aim to earn money by selling hardware.

Although I'm not involved with the people in the Linux community who are working on these drivers, I have worked on video drivers for S3 chips in the past, and I think I know what they want. They want the specs of how to program the chips: I/O addresses, control codes, data formats, sequence rules. Not software. Not specs of how to build the chips. Specs of how to program the chips. The kind of info that was always routinely and freely made available by chip manufacturers until about a dozen years ago. Open-source software from VIA would be nice, because examples are useful in understanding specs, but it's not as important as the specs.


Re:I don't think VIA completely understands

Posted by: Anonymous Coward on May 05, 2005 08:35 PM
But if they released the specs.... well, actually I can't see what harm it could possibly do. Why do companies keep this hidden?


Re:I don't think VIA completely understands

Posted by: Anonymous Coward on May 06, 2005 08:57 AM
"They're obsessed with the "value" of their "intellectual property""

They're a hardware company without their own fabs. Their entire worth as a company is their IP (and brand name to a small extent). A software company can survive as an open source company if they can earn money based on a service model as does Red Hat. VIA does not have hardware that requires services. If their drivers contain code that could allow someone to create equivilent hardware with a fraction of the R&D expense, VIA would soon be out of business if they released it. If the hardware is just a specialized DSP, the driver code could in effect be the specs for building the chip's instruction set.


Re:I don't think VIA completely understands

Posted by: MikeFM on May 06, 2005 02:59 PM
It's just driver code and interface specs. If that is all that sepperates a company from it's competition then there is nothing sepperating them. The only thing useful to do with such IP is to interface to the device. What are they worried about? That BrandX will make a device that does the same thing and shares the same interface? They'd still have to do all their own R&D on building the device. They'd just save a little effort by not having to write drivers. What companies fail to realize is that opensource developers will write everybody's drivers for them, for free, if they only open their specs. Unless you're #1 in your market there is no reason not to standardize on opensource drivers. Even if you are #1 there is good reason to standardize - to keep everyone else from ganging up against you and turning the users (your customers) against you.


Re:I don't think VIA completely understands

Posted by: Anonymous Coward on May 07, 2005 12:59 AM
Expecting people to do your work for free sounds like a great business model. Also, it's VIA's name on that hardware. Their reputation if things don't work or cause data loss. People expect drivers when a product is released. Giving out specs before release so drivers can be created for free can also take away competitive advantage as competitors will know exactly what you are working on.


Re:I don't think VIA completely understands

Posted by: andrecaldas on May 06, 2005 03:40 PM

Their entire worth as a company is their IP (and brand name to a small extent). A software company can survive as an open source company if they can earn money based on a service model as does Red Hat. VIA does not have hardware that requires services.

Are you talking about hardware or software? What about making money selling hardware? Or you are thinking about people redistributing their hardware over the internet?


Re:I don't think VIA completely understands

Posted by: SarsSmarz on May 06, 2005 10:28 PM
I think he's saying that if they totally went naked, then it might be revealed that they are using a standard programmable dsp chip. Then anybody could sell a via-knockoff chip. All companies survive on a barrier to entry that allow them to sell at a margin.

It's all in the method they use to cloak themselves. There must be a more Linux-friendly way!


all the same

Posted by: SarsSmarz on May 05, 2005 09:02 PM
These specialty chip makers are all the same now. They want to cloak the inner workings of the chip. Perhaps its competition (somebody finding something like the Intel bug?). They should just put on a standard cloaking interface.

I'm now buying a new fancy machine, latest Shuttle, AMD, and PCI express card. I now know from my last machine that Linux will take a year before it works, mainly because of the new chips. So, this is an XP game machine for a while.


Not all the same

Posted by: Anonymous Coward on May 06, 2005 02:00 AM
I now know from my last machine that Linux will take a year before it works, mainly because of the new chips.

Based on my own experience, I don't agree. It depends on exactly what you have got. It's possible to pick new video cards that don't have good Linux drivers, but equally, it's possible to pick ones that do.

It's always a good idea to look at Linux support before buying. If more people did that, chipmakers would get the message from the marketplace.


Yeah, I'll buy that...

Posted by: Anonymous Coward on May 06, 2005 02:43 AM
"It's always a good idea to look at Linux support before buying."

I jumped into a wireless card too quickly, thinking, "Linksys runs Linux on their routers, so they'll have support for their cards." Oops! Broadcom chip, no specs, no (native) driver.

Boneheaded move on my part.


Re:Yeah, I'll buy that...

Posted by: Anonymous Coward on May 07, 2005 02:10 PM
"Broadcom chip, no specs, no (native) driver."

We can blame their fear of the FCC and lack of imagination on this. No company wants to be fined for causing interference in the 2.4GHz band. Which if we "unscrupulous" Linux wireless users were to acquire the code for these software controlled radios... well our hooliganism would shine through and radios would operate on more frequencies than 1-11. This would cause American Society to collapse, so in a manor they are doing us all a public service and we should be grateful.[/sarcasm]


Why bother?

Posted by: andrecaldas on May 06, 2005 03:48 PM

May be it's just because I don't really care about the "graphics". But... why bother?

So that people will value more the "beer" version of free? Just for "Linux marketing"? (I avoided "GNU/Linux" here because there is no such a thing like "GNU/Linux marketing", there is only "Linux marketing")


Because of these things...

Posted by: Anonymous Coward on May 07, 2005 07:42 AM
There are some very good reasons to bother. For one, even using VESA drivers for the S3 chips seems to result in nothing more then a 60Hz vertical refresh rate. This is a real pain to try and live with - that alone is reason to try and get drivers.

Let me detail in brief for you some of the problems getting a working driver for the Unichrome Pro chipset in my K8M800.

First, the regular S3 Unichrome driver won't work. The VESA driver will work; but the chipset refuses to listen to custom modelines. You're stuck with whatever resolution you like with a 60Hz vertical refresh rate. It's a real pain. Any attempt I made to use VBE extensions to change that resulted in a hardlocked machine.

Not only do I have to use a CVS version of the source code, I have to use a hacked version of the CVS source code (Although I'm not really sure I can call Ivor's work a hack, it's more elegant then that, but it's still CVS based off a CVS version of a driver)

Once you get that up, you'll notice your system will be slower then congealed blood. Your console will probably show five or six "Disabling IRQ 11" messages *just to start X*.

Thats right, you have an IRQ cascade bug, as nearly as I can tell in the BIOS ACPI implementation and its interaction<nobr> <wbr></nobr>/not/ with the linux kernel ACPI driver but with the Unichrome driver itself.

If you happen to use a USB keyboard or mouse, you're in particular trouble. Just typing an email results in my fingers getting ahead of what the screen can keep up with.

And if you happen to be using the integrated ethernet rhine-ii chipset, you're uttlerly out of luck - the IRQ cascading problem results in it being essentially completely unusable. So you no longer can get on the internet (If thats what you use it for) to try and fix the problem.

So you have the unichrome IGP, the ethernet, the keyboard, the mouse, and anything else the motherboards BIOS chooses to put on IRQ 11...

My first solution was to tell X not to use the IRQ to interact with the hardware. Sure, this gets "rid" of alot of the IRQ cascades, but the ethernet is still useless and using the keyboard still results in problems.

Sure, I can get a whopping 500 fps in glxgears, but I can't really do anything.

So I compiled a linux kernel without APM or ACPI. Guess what? This seems to resolve the Cascade issue... to a small extent. My ethernet is usable... As long as I don't use any 3d accellerated programs.

And if I do, not only is my ethernet unusable, but my wireless card starts outputting what looks like the contents of<nobr> <wbr></nobr>/dev/urandom!

so no matter what I do, I can't reach a totally usable state.

So my next step (As VIA did their "massive open-source support movement" at that time) was to download all of their drivers I could find on viaarena.

Oh my god, I get a whole framebuffer driver! Does that support 3d Accelleration?<nobr> <wbr></nobr>...

Damn, it won't even compile! What the...

Via would have been well advised to integrate an ATI Rage IIc chipset on the motherboard. It would already be fully supported in the linux community, and from the times I've used them in modern computers the 3D performance would also have been twice as good as their S3 Unichrome Pro chipset is.

So I did the last thing I wanted to do - I got my ATI Radeon 9700 out of the computer I need it for, and put it in this one.

Comparitively, the drivers were a complete breeze to install. IRQ 11 works like it ought to. My idle load dropped from between 0.3 and 0.6 to 0.0 - where I would expect it to be with an AMD64 2800+ doing essentially nothing.

So if you have a motherboard with an S3 Unichrome chipset, you have substantial reason to try and get the drivers working - a 60Hz v refresh rate is enough to drive alot of people to learn how to use it. However, I have seen story after story where people took the motherboard back because part of the reason they bought it was for the integrated graphics - they didn't want to have to buy a cheap video card and put it in to make it work right.

Also, having maintained and updated a system by hand for almost ten years, from its original 486DX to the AMD64 I'm running now, I have a significant advantage in knowing how to track down hardware problems and do things to fix them - yet I reached a dead end.

Over half my drivers were CVS versions. I spent over 80 hours troubleshooting, installing, uninstalling, testing, and compiling drivers for the S3 Unichrome Pro. In comparison, installing the newest Binary ATI Drivers (BADs) that everyone hates, I spent a grand total of 4 hours - while being exhausted from not having slept in 24 hours. Had I slept, it would have been half that.

VIA should at least provide drivers that work relatively painlessly on current systems.

To recap briefly:

There are a multitude of reasons that will provoke someone to try and use the drivers for the S3 IGP's - 60Hz refresh rate, for me. Many of them buy these motherboards to use as MythTV boxes - they have to have decent drivers to use the TV-out ports present on these IGP's. Being able to play games at a half decent framerate is a big reason for many others.

There is still many problems with these drivers, especially the S3 Unichrome Pro drivers - IRQ cascades, unusable hardware, strange bugs that don't make any sense (How does viewing glxgears cause my wireless card to output static? This should be impossible) and a plethora of hardware bugs that will hopefully be fixed in later BIOS revisions.

Then there is simply the amount of knowledge required to compile the necessary programs if you have a problem - new kernels, kernel patches / externally built modules for the kernel, sources, patches, and new subtrees, etc. etc.

Sure it can be done. Luc and Ivor have done incredible work on these drivers. How much support do they recieve from VIA? Half-eaten bones, in my opinion. Source code that doesn't even placate the masses trying to get VIA's hardware to work.

It's all, frankly, quite annoying


Re:Because of these things...

Posted by: andrecaldas on May 08, 2005 08:52 AM

You have the wrong hardware... So what?

What are you talking about? I am not saying that you should not care that VIA does not want to open the specs. In fact I was saying exactly the opposed thing: "Why bother giving support to a company that does not want to contribute?" I was just saying that a comunity should not work hard just to promote some company that explicitly is anti-the-same-community.

Let's suppose you get rid of your VIA card - and now all you hardware problems are solved. Would you try to promote their hardware and make more people buy VIA cards after all the trouble you had?


Posted by: Anonymous Coward on May 07, 2005 08:08 AM
It seems hard to take seriously the vendetta of someone who devotes their personal homepage to a dispute with his neighbor over a hedge.

<A HREF="" title=""></a>


so what

Posted by: Anonymous Coward on May 08, 2005 04:30 PM
So what's wrong with that? and how's it any worse than the zillion personal blogs out there filled with complete drivel?


Posted by: Anonymous Coward on May 10, 2005 09:17 PM
Why are only 2 of the supposed 4 developers interviewed? What happened to the other 2? Oh, Andreas left because of Luc's attitude? Thomas left because of Luc's attitude? I think that says a lot more about what is actually going on here than what was said by either Luc or Ivor.

I use VIA's own drivers for my Linux box and they work just fine. The new version of Xine runs great and gives well below 20% total CPU usage watching a 720x480 mpeg or a DVD.


Posted by: Anonymous Coward on May 11, 2005 04:26 AM
Please get your facts straight.

If you were keeping up to date you'd have noticed that Ivor had left too, but both he and Thomas are still working on the code.

You are also intentionally misleading readers Xine DOES NOT WORK WITH VIA'S DRIVERS, you are referring to Via's forked copy of Xine called VeXP.
The real current official Xine only works with the open source drivers.


Posted by: Anonymous Coward on May 11, 2005 04:29 AM
Damn these open source dudes and their vendetta's to produce fully functional working drivers for users in the absence of vendor support.

The swines.


This story has been archived. Comments can no longer be posted.

Tableless layout Validate XHTML 1.0 Strict Validate CSS Powered by Xaraya