Learn about Linux
Download Linux
Get Linux helpSpecial Offers
Feature: Open Source
Two views on VIA's open source release
Share
Print
CommentsIn response to points raised by the Unichrome developers, VIA Arena Editor Fiona Gatt said in an email to NewsForge the goal of the VIA VeMP and VeXP players -- described as "blindly forked to support binary nonsense" by Verhaegen -- was to produce players that could demonstrate software optimized for use with the MPEG-2/4 hardware acceleration in VIA's CLE266 and CN400 chipsets.
"Since then, due in part to the feedback from the open source community, the VeXP project leaders have recently contacted the Xine project to check in VIA's source code," Gatt wrote. "We are willing to discuss changes and requirements with those developers. We have listened to the feedback from developers in the Unichrome Project and users who use their software and we're making every effort to improve the way we work with them."
As for the disclaimer described and criticized by Verhaegen, Gatt said the disclaimer is being changed with the next release.
Responding to the criticism that VIA's open source efforts are missing the point, Gatt indicated overall response to the company's moves has been positive.
"Whilst there are still some improvements to be made, the open source community has in fact responded with great thanks and enthusiasm to recent efforts by VIA and changes to communications and types of support provided," she said. "There have been issues in the past, but we have listened to feedback and acted upon it and we will continue to do so."
Free development and opportunity
Gartner Research Vice President Martin Reynolds said VIA's move was made to leverage the free support that is taking place around the company's products.
"It makes it easier to get people to come and develop on your platform if the drivers are available, particularly VIA because they really go to peripheral applications and it's important to have access to modify or change them," he said.
Reynolds agreed that VIA and other companies typically assess the value of the intellectual property at stake and the potential support and market as a result of opening it.
"It makes it easier for VIA to keep these things going and keeping them bug free," he said. "It was a case where it was ideal for open sourcing, unlike Transmeta and their transaction layer. They won't open that because it doesn't help them. It's usually a goal to get more customers and the support of developers."
Reynolds said open source developers and users can look forward to such open source releases only when the company stands to gain from them.
"It's more for their convenience," he said. "There's not going to be this huge rush to open everything up. Only where it makes market sense."
Long Linux relationship, list of complaints
Mercury Research president and graphics chip industry analyst Dean McCarron said he did not see VIA's open source efforts as intended to help out open source developers using their products. Instead, the analyst said the company has seen the support it is getting from the open source community and when looking at what it had to lose in the intellectual property of the drivers, decided the move would be beneficial.
"They're getting what amounts to free support and they're saying, 'Let's not penalize these guys. Let's let them help us,'" McCarron said. "Having the hardware interfaces under cover is a challenge for open source groups like X.org and XFree86 to support. There's difficulty there."
The analyst said the open source driver effort and Linux market that VIA is trying to serve are really one in the same, and may have been underestimated by VIA. "The existence of the groups is indicative of the demand," he said. "In some cases, they were maybe not aware how much demand there was."
McCarron said the growth of open source operating systems such as Linux and FreeBSD will force more, similar open sourcing of drivers, but the trend is unlikely to reach the top of the market, where Nvidia and ATI support open source systems, but keep their solutions proprietary.
"What I suspect will happen is certain portions of the hardware interface will get exposed -- maybe the 2D interface, but for the hard core 3D, there's so much intellectual property wrapped up in that, it's very unlikely that piece will end up being open sourced."
Likening the situation to Intel's forced support for wireless Linux -- which has improved dramatically in the last year with open source driver programs supported by the chip giant -- McCarron said Linux users will get more support and more source code, but there will always be proprietary catches, particularly in cases where the company cannot divulge intellectual property based on contract, acquisition, or other stipulation.
"For the purists, there's the issue that you don't necessarily get a direct plug to established organizations like X.org," McCarron said.
Comments
on Two views on VIA's open source releaseNote: Comments are owned by the poster. We are not responsible for their content.
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.
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?
It's all in the method they use to cloak themselves. There must be a more Linux-friendly way!
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.
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.
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.
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]
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")
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, X.org 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
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?
<A HREF="http://ivor.org/" title="ivor.org">ivor.org</a ivor.org>
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.
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.
The swines.
I don't think VIA completely understands
Posted by: Anonymous Coward on May 05, 2005 07:43 PMHaving 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.
#