Answers from Harald Welte, "VIA's Open Source Representative" 65
Earlier this month you asked Harald about VIA's open source strategy and his work with gpl-violations.org. Here are his well-thought-out, informative answers.
1) More interesting mobile developments? -- by radimvice
Your Wikipedia bio mentions that you left your position as Lead System Architect for the OpenMoko project in 2007 due to "internal friction and demotivation". What are your current thoughts on the OpenMoko platform, has it made significant improvements since your decision? What are the biggest hurdles it still needs to overcome before you would consider it a successful project? Are there any other upcoming mobile platforms that have you excited for the future of open source development on mobile phones, or is the industry/market perhaps still too premature for open-architecture Linux on the cell phone?
Harald:
Openmoko has made quite a number of improvements but at the same time has many internal problems to resolve. Only few of those are technical, and the least of them are software related.
The biggest hurdle I see is the creation of more competitive hardware, both from mechanical design as well as providing 3G / 3.5G cellular connectivity.
I am not too excited about other mobile platforms, since though some of them are Linux based, everyone expects them to be locked-down with signed bootloader/kernel images which completely circumvents the freedom to modify the code and run modified versions of it.
And yes, the traditional carrier-driven market is much too premature and stuck in their monopolistic and proprietary structures. But if they don't change at some point, I think the number of GSM phones sold independent of carriers will rise again. The subsidized-phone-sold-by-carrier-bundled-with-simcard model is extremely against an open market, fair competition and equal opportunities.
2) What's the situation with VIA drivers for Linux -- by glop
A friend just got a Wibrain b1 that came with Ubuntu. The drivers for all the VIA stuff are binary blobs which prevents him from upgrading the kernel. They also don't seem very reliable as he is seeing crashes.
Is there already Open Source drivers for that kind of hardware or is this part of your mission for VIA?
Harald:
I do not understand why there are any binary-only kernel drivers involved.
To the best of my knowledge, VIA does not have any binary-only drivers, and particularly not graphics related. The agpgart and DRI/DRM drivers are all GPL licensed open source. The chipset used in the Wibrain device is a unichrome based chipset, and those drivers are all part of the mainline kernel.
There are some other more recent VIA integrated graphics chipsets utilizing the Chrome9 graphics core. The DRI/DRM driver is not yet integrated into the mainline kernel, but it is available as GPL licensed source code from http://linux.via.com.tw/
Binary-only userspace drivers (like the 3D and TVout enabled Xorg driver as released by VIA) do not impose any restrictions on kernel updates, since the kernel ABI towards userspace is fixed.
3) v2 or v3 -- by larry bagina
Do you prefer the GPL version 2 or version 3?
Harald:
It's a hard question. I personally prefer GPLv2, but not for much rational reasons. Rather it's "the thing that I'm used to" and "the license that I've managed to enforce successfully". So it's like a proven, reliable and trustworthy legal tool.
On the other hand, v2 has some shortcomings. I like the fact that GPLv3 makes it explicit that you cannot use cryptographically signed code to circumvent the "freedom to run modified versions". In GPLv2 you can only argue for this by doing a license interpretation - i.e. not something that will have a certain outcome in court. If v2 was more explicit in this regard, we would not have seen the tivo-ization of products suhc as the Motorola Linux based phones on which you cannot change a single line of code. It is _sooooo_ much against the purpose, intention and spirit of the license. It hurts.
What I prefer about v2 is that there is a more explicit 'automatic termination' clause and no implicit way how an infringing entity can 'heal' their infringement within a certain deadline. The v3 part about this is creating an entirely new set of complexity for license enforcement which I believe is unjustified.
So for any new code that I write I usually put it under 'v3 only', unless it is a contribution to an existing v2-only project like the Linux kernel, or unless there are contractual obligations requiring the code to be v2-only.
I personally don't believe in the 'version X or any later version' idea, since I have a hard time to preemptively agree to something that neither I nor anyone else has ever seen.
4) VIA and Netbooks -- by Van Cutter Romney
My recent brush with VIA is when I bought a HP mini-note laptop which uses the VIA C7 processor. Unfortunately, I ended up picking the laptop with Windows Vista and I'm sorry to say that it is not the right operating system for this category of portable laptops. I am much more happier with Ubuntu loaded on the machine now.
My question to Mr. Welte is, how is VIA working with vendors like HP to promote Linux on this new and exciting range of netbooks that coming out?
Harald:
First of all: I can understand your pain, as I have bought the same vista-based HP mininote in order to illustrate the problems with VIA's old binary-driver strategy on Linux. Right now it is just impossible to install any mainline distribution on that system (or similar systems employing VIA's recent products), even if you're a very experienced Linux user, sysadmin or developer.
To the best of my knowledge, VIA is not promoting the use of any Operating System to their system integrators. It's rather the other way around, i.e. the system integrators / notebook manufacturers who want to create a Linux-based product ask or rather demand good Linux support from chip manufacturers like VIA.
5) Have you ever accused an innocent? -- by BitterOldGUy
From your Bio you started gpl-violations.org.
Have you ever accused anyone of violating the GPL and then found out that they didn't?
Harald:
No. The way we work at gpl-violations.org is to first do a test purchase and obtain evidence of the copyrigt (and GPL) violation. After that, we send a legal warning notice demanding the infringing entity to cease and desist from their doing.
6) 3D Support? More support than Unichrome series? -- by Svartalf
It's my understanding that VIA has recently provided a dump of new "cleaner" code to x.org that supports the Unichrome lineup more properly. (By the way, thanks...)
However, this doesn't help fully in the big-picture sense of things.
Right now, an Atom based netbook will have 3D capable of doing Compiz (I know, I've played with it on at least two differing eeePC models right now...) and some lower-end FOSS 3D games out of the box. With what has been given out so far, you still can't do this with VIA's offerings, which include the netbook designs and the EPIA boards. That, alone, isn't a good thing or selling point, really, for those designs right now. What is VIA planning to do in regards to fixing the 3D situation on the stuff that you have already released stuff for?
The aforementioned only talks to Unichrome/Unichrome Pro/Unichrome II. What's the story with the other Chrome lineup? Are we going to see FOSS support for those chips or are they even relevant going forward?
Harald:
I am sorry to say that there is no quick solution for FOSS support of Chrome9 products. It is one of the hottest topics of my work inside VIA, and everyone is trying their best to find a solution. I cannot disclose any details for the reasons for this difficulty, but any possible solution is likely going to take quite a significant amount of time.
For 3D FOSS support (Xorg/DRI/DRM/Mesa driver) for unichrome / unichrome pro the situation is much better and we will see that code disclosed at some not too distant point in the future.
Just think of what ATI has been going through some time ago. They were unable to release the source for their existing binary-only driver and had to start a new driver, which needs time.
7) S3 & Via -- by bill_mcgonigle
Can you illuminate the relationship between S3 and Via for us? I've tried in the past getting basic technical specs (e.g. textures per pass, triangle rates, pps, fill rates) on the video hardware that comes with Via boards. This kind of information is readily available from other manufacturers, and occasionally a whitepaper will show up from Via or S3 for a random chipset, but asking Via for this kind of information results in stacks of legal forms to be signed in duplicate, allegedly because of NDA's between Via and S3. Yet, S3 bills itself as "a VIA Technologies, Inc. joint venture company". Doing open source work, I've avoided the NDA entanglements, and ultimately went to ATI for video hardware because I could find specs reliably without 'buying one of each' (this was actually suggested to me). Mostly it's all very confusing for people who just want to develop stuff, and I wonder how this relationship affects the open source drivers and the stuff that's not currently available (3D, hardware media decoding) but is essential for some embedded work.
The related question would be does Via realize that we're out here and want to buy their hardware but are being forced to rule out Via due to secretiveness?
Harald:
I have just started working for VIA, so I am not as familiar with all of the corporate details, as you can imagine.
However, S3 Graphics is an entirely independent company and not a subsidiary of VIA. That basically means that VIA is holding some stock, but that's more or less all. They also promote their products together.
The S3 Graphics discrete GPU's are developed independently from the VIA integrated graphics, and they share no common hardware core or driver.
So since VIA has taken steps to become more supportive of Open Source and particularly Linux and Xorg, we will see improvement for the VIA integrated graphics products. This has no relationship to what S3 does for their products.
And I totally agree with your statement of VIAs [past] secretiveness and lack of open documentation and open source drivers is definitely hurting their ability to sell to the Linux based market, including the Linux based embedded market.
This is precisely why VIA is changing now, and has hired me as part of that process. Some of those changes are visible now, other changes will only be visible with future products. There is always a lead time involved in any R&D...
8) IP and moving forward with open-sourcing by TheModelEskimo
How much did IP (intellectual property) concerns weigh on the process of opening the driver code? We've been hearing from companies like nVidia that IP issues prevent them from opening their own code, so I'd be interested to hear just how it is that VIA were able to get to this point in the face of today's treacherous environment regarding IP.
Harald:
First of all, I dislike the use of 'IP', since it confuses trademarks, patents, copyright and other rights.
Yes, 3D graphics and video codecs are a minefield of patents. Those patents and the way their licensing works cause significant trouble and present legal risks for anyone involved with them.
So even if you assume the best case and assume that you can manage to build an open source solution that's still in compliance with the patent licenses, you will have to waste a lot of time on carefully analyzing the legal situation and possibly spend just as much time on it as on writing code.
This is why less contentious code like 2D drivers can usually be disclosed fairly quickly, and others cause quite a lot of headache :(
As far as copyright is concerned, to the best of my knowledge VIA wrote all parts of their drivers themselves and did not license parts of it from any other entity. This means they are the sole copyright holder and can therefore decide on whether to relicense existing code under a FOSS license.
9) Drivers Drivers Drivers (Score:5, Insightful by dan the person
VIA has a history of releasing chipsets packed full of great video acceleration, but no drivers to make use of that acceleration, sometimes there are even no windows drivers either.
Looking at the linux drivers for instance[1], there are big gaps, and it is disappointing to see no drivers to support the base MPEG4 acceleration let alone new features such as h.264 acceleration.
I have an EPIA SP8000E and the MPEG2 acceleration (XvMC) implemented by the openchrome drivers is awesome, such a shame more than that cannot be supported.
VIA has once again re-launched their linux drivers[2], and once again the support is very limited, only a small number of distributions, a small number of chipsets, and a small number of hardware features supported. Furthermore applications that can make use of these drivers features are almost non-existent
Wouldn't it be better to work with the the established driver teams such as openchrome, who have broad distribution support, broad chipset support, and are broadly supported by applications, to add the missing hardware support?
[1]http://wiki.openchrome.org/tikiwiki/tiki-index.php?page=HardwareCaveats
[2]http://linux.via.com.tw
Harald:
The problem with hardware accelerated video playback is that the company creating a 'consumer product' sold to an 'end user' has to pay the royalties to the MPEG-LA.
So any chip maker like VIA is not required to pay the patent licensing royalties since they just produce an 'intermediate product' which somebody else can turn into a 'consumer product'.
This works fine in an environment where VIA makes chips and provides reference driver code under NDA to a system integrator, who then sells a bundle of software and hardware to an end user. In that case the system integrator either pays the royalties and can sell that product, or doesn't pay the royalties and can just sell the hardware without the proprietary software drivers and programs to actually make use of those hardware features.
Now imagine the open source situation for this. If VIA was suddenly selling chips as intermediate products, but also disclosing free player software to make use of that acceleration features? Would that then be a 'consumer product'? Who knows. But it would definitely be distributed to an 'end user' since it's available to anyone who wants to download it.
So if any independent free software or proprietary software program implements those codec acceleration features, they might violate the patents on those video codecs. Just in the same way mplayer, xine and other FOSS programs do not pay the per-installation/copy/download royalties for MPEG2/H.264/... playback products. Maybe you can call a sourcecode implementation just a 'reference implementation for scientific purpose', but that's open to legal interpretation and as far as I know there is no precedent in this area. But it is their decision on what legal risk they take.
It's the very same reason why distirbutions generally refrain from shipping that player software. Because there is significant indication that they would have to pay per-unit royalties. And with free software, you never know how many units there are, so you don't even know how much to pay - and you also have no revenue from things that you don't sell...
10) GPL Violations by PingXao
You have stated that your ability to pursue claims against those who violate the GPL is hampered by lack of resources. What amount and type of resources, in your estimate, would be required to pursue all such claims? I'm thinking in terms of everything from vetting the claims to see if they're warranted all the way through the hiring of legal representation to file and pursue lawsuits against the violators.
Harald:
The limited resources basically come down to a lack of 'trustworthy time' for actually doing technical analysis of an alleged infringement. Since I am in the end the person who is personally liable with everything I own, I have to trust such an analysis.
And in order to have that trust, I usually have to do it on my own. Over recent years, my 'second-in-command' at gpl-violations.org (Armijn Hemel) has started to do this kind of work and I trust him to be able to do it correctly.
However, if such a person makes a mistake, and I obtained a preliminary injunction banning a company from sales of their products which later gets overruled since there actually was no [sufficient] evidence for copyright infringement, then I'm liable for the loss of revenue to that company. Now if you think of the kind of consumer products and the quantities that they are sold, you can quickly imagine that it is prohibitive to get into that position.
There is no shortage on finding qualified legal representation to handle all those cases. Though at some point there is an issue where my personal liability is multiplied by the number of cases that run in parallel.
One way to address this problem is to over time get more engineers involved who can earn that level of trust. But it will likely take quite a lot of time to get there (possibly years). The other point is to incorporate the project to get myself out of the personal liability. We have some plans for that, but their implementation is again hampered by the limited amount of time that I can spend on the project.
I'm involved in way too many projects, and all of them are suffering desparately to get some more time and love by me. But I'm constantly thrashed and just only have a limited number of timeslices available. OpenPCD and librfid are the prime candidates for urgent need of time. The u-boot s3c24xx code and mainline submission of all the Linux kernel code that I wrote for Openmoko are other really important tasks that need to get done soon. Some other projects like ulogd and OpenEZX have managed to attract enough interest and involvement from other people so I have to worry less about them.
So that's why gpl-violations.org can only deal with a few cases. At the moment, we are doing up to 10 cases in parallel, and I expect we will probably get to something like 50-75 cases per year. But more would be too much.
-- Harald Welte http://laforge.gnumonks.org/
Via Set Top Boxes (Score:3, Interesting)
I find it interesting how the lack of open source and "freedom" of their drivers becomes detrimental. In a project I just worked on, we would have deployed thousands of their set top boxes if drivers weren't an issue.
Re: (Score:2)
I think the GP poster was referring to a design miss/fail on VIA's part.
Without credible driver support (which they still don't have...) they don't get to have their foot in the door on a lot of designs. I suspect that the GP poster was referring to the fact that his company chose something else instead of an EPIA or similar design for set-top boxes because they don't have the right stuff with regards to Linux.
Can't sign the NDA? (Score:3, Informative)
If I understood the article correctly, VIA pays no royalties on patents covering their chipsets, as they are seen only as intermediate products. The onus in on the manufacturer that makes the final product to take care of those. In this case your company would be the manufacturer that markets to the public. By signing an NDA with VIA, a reference implementation could be had, so there would be some sort of driver support. If the conditions of the NDA allow for the driver to be open sourced subsequently and w
I wish I asked this differently... (Score:5, Interesting)
5) Have you ever accused an innocent? -- by BitterOldGUy
From your Bio you started gpl-violations.org.
Have you ever accused anyone of violating the GPL and then found out that they didn't?
Harald: No. The way we work at gpl-violations.org is to first do a test purchase and obtain evidence of the copyrigt (and GPL) violation. After that, we send a legal warning notice demanding the infringing entity to cease and desist from their doing.
I really wish I asked, "If the the entity you accused denied it at first and then "fessed" up so that the would avoid legal costs to fight in court."
Unfortunately, most of the time, it's cheaper to pay up than to fight in court. His answer doesn't address that nor does my question - I admit my own failing.
I have a real problem with this... (Score:2)
I have a concrete example and I'm afraid to mention it because it would violate my NDA with IBM. It's in regards to OS/2 for Windows and MS.
Re: (Score:2)
Obviously, if they've gone through some trouble to make code paths different, changed static strings and symbols around, then you don't necessarily know without spending a lot of time to see if the resulting code seems to do step-by-step what a compiled version of your original code does.
Re: (Score:2)
Obviously, if they've gone through some trouble to make code paths different, changed static strings and symbols around, then you don't necessarily know without spending a lot of time to see if the resulting code seems to do step-by-step what a compiled version of your original code does.
They've done what you've said? They reversed compiled it? They've compared entry points and everything?
If so, then they've got a case.
Re: (Score:2)
Indeed. I can't speak for gpl-violations' work. But without doing this I don't see how a case is possible from a technical perspective.
Re: (Score:1, Informative)
In a lot of the cases I've seen, just running 'strings' on the binary promptly dumps clear copyright notices for busybox or whatever ... or they didn't strip symbols and all the function names are still in there. Often it seems manufacturers, especially asian ones where the culture is to take "free" things and improve them, just think "yeah whatever it's free" and ignore the GPL. They don't usually try to obfuscate that they've done this because they don't regard it as wrong to begin with. This was the case
Re: (Score:2)
If symbols are stripped, they can compare the object code. Compile the code with a bunch of different compiler versions to see which version they used. Its pretty straightforward.
-molo
Re: (Score:2)
How in the World can you tell if someone has ripped off your code?
Sometimes, they will straight out tell you that they did.
GPL violation happens most often with those who make embedded products, who make absolutely no effort to hide their mistakes (they simply didn't understand what GPL meant---but I think that's changing, thankfully), e.g. sometimes they will say somewhere either on the manual or the website that the product uses something like busybox.
Of course, there are some really bad guys who do all the obfuscation others mention, but for the most infringers, their
Re: (Score:2)
The first thing would probably be to look for strings / constants in the binary. It won't show up anything if the copier has changed those, but then again how many do? I highly doubt that it would be sufficient as evidence in court, but it is a quick "smell test" to see if there's anything suspicious going on.
Then you could do things like compare how the original and the suspect behaves on identical input (f.ex. if it is a TCP/IP stack, compare fingerprints or isn plots). If you know of a particular bug or
Re: (Score:1)
Why is that unfortunate? If the infringing party settles out of court, the copyright holder wins -- the company either stops redistributing infringing material or complies with the GPL. How is that anything other than good?
Re:I wish I asked this differently... (Score:4, Insightful)
Unfortunately, most of the time, it's cheaper to pay up than to fight in court. His answer doesn't address that nor does my question - I admit my own failing.
I don't follow you. How is 'fessing up' to a violation you didn't actually commit a way out here? There is no option to buy your way out of a GPL violation. If Harald accused someone of a violation, the accused can only avoid legal action by releasing the source code or removing the code from their product. They can't just pay a fine and continue on with no other change.
If they are in fact innocent, and Harald is still convinced they've pinched some GPL code, 'fessing up' makes no sense.
Besides which, in all cases of GPL violation I've every heard of, the use of the code in question was never in dispute, but rather it was the interpretation of the GPL itself that was at issue.
yankpop
Hey Fox News ... (Score:1, Insightful)
Why don't you let *us* decide whether his answers are well-thought out and informative?
Re:Hey Fox News ... (Score:4, Interesting)
Re: (Score:1, Insightful)
I think you are reading too much into it. Between his job, his volunteer activities and (presumably) a life he *is* amazingly busy and it is generous of him to take the time to talk to us in this fashion.
Re: (Score:2, Insightful)
Yeah, I think you're reading too much into it. I read it as a gracious, brief introduction. Which I also think is pretty appropriate and necessary -- it's important to get a "thank you" in early because the comments can be pretty gripe-heavy for anyone doing a /. interview on a contentious subject.
We're not a 'known friendly' media outlet -- for any business that makes us risky, and thus really hard to justify time for. Far better to do 'safe' interviews and PR releases. The only way we're going to get peop
Re: (Score:3)
Hardware Acceleration (Score:5, Interesting)
This works fine in an environment where VIA makes chips and provides reference driver code under NDA to a system integrator, who then sells a bundle of software and hardware to an end user. In that case the system integrator either pays the royalties and can sell that product, or doesn't pay the royalties and can just sell the hardware without the proprietary software drivers and programs to actually make use of those hardware features.
Now imagine the open source situation for this. If VIA was suddenly selling chips as intermediate products, but also disclosing free player software to make use of that acceleration features? Would that then be a 'consumer product'? Who knows. But it would definitely be distributed to an 'end user' since it's available to anyone who wants to download it.
How about Option #3: Don't provide reference code at all, just properly document the hardware and less the FOSS crowd write their own?
Re: (Score:1)
Takes time too (Score:3, Interesting)
How about Option #3: Don't provide reference code at all, just properly document the hardware and less the FOSS crowd write their own?
just properly document in a way that doesn't violate any agreement and doesn't piss off any licensor the hardware which probably was never documented in the first place, only reference code was used and everything needs to be written from scratch and less the FOSS crowd write their own.
Here, fixed for you.
The documentation will probably require lots of efforts, for which VIA doesn't have unlimited resources, and even after that, will require even more time as it goes through all the necessary legal checks.
Re:Takes time too (Score:4, Insightful)
This isn't hardware they licensed, it is in-house designed stuff. Are you trying to tell me that they built chips, yet have no documentation on pinouts, low-level register settings or functional hardware blocks? Exactly what did their in-house software team use to develop the reference drivers?
Cry me a river. If they don't consider the Linux/FOSS market big enough to worry about then say so and be done with it. Intel will gladly take their business [intellinuxgraphics.org].
If you're simply saying "this will take time", then fine. As long as they are interested in taking that path, patience is a virtue. However, it wasn't mentioned in the article and I was bringing it up as a possibility. The preferred one, from many perspectives.
Re: (Score:2)
This isn't hardware they licensed, it is in-house designed stuff. Are you trying to tell me that they built chips, yet have no documentation on pinouts, low-level register settings or functional hardware blocks? Exactly what did their in-house software team use to develop the reference drivers?
Hasn't MicroSoft had trouble complying with the EU rulings partly because they didn't have any real documentation, they could just look at the code when they needed to know something? I'd imagine the same situation would be possible here, although probably less likely unless everyone knows both C and VHDL/Verilog.
Documentation (Score:5, Interesting)
Are you trying to tell me that they built chips, yet have no documentation on pinouts, low-level register settings or functional hardware blocks? Exactly what did their in-house software team use to develop the reference drivers?
(BTW: Pinouts are irrelevant to driver making, they come into play when making the PCB).
What the free software community needs is a really neatly done documentation. With nice exhaustive tables listing all internal registers, their meaning, along with pseudocode describing the effect and small snip showing usage examples.
Along this, also diagrams showing sequence for initialising stuff, sending stuff to some pipe line. Etc. All this in the kind of quality that you find in books about hardware available in libraries, or books that a company specialised in selling chip design will provide (i.e.: a company that will necessarily need to provide all the information to some 3rd party).
And that's probably what they *don't* have.
What they have is probably a huge mess. Of couple of things partially documented, some piece of documentation describing obsoleted designs (but that doesn't matter because hardware engineer responsible for it is just next door to the programmer making the driver and could verbally notify about the differences), things instead of being neatly organised, are neatly interwoven with other elements that are irrelevant or even licensing violations (say some generic demonstration code snip just next a some fragment of actual production code - a clear violation of the MPEG patent's licensing terms).
At no point was there initially any plan to release professional grade book documenting the programming of the hardware. Hence, at no time did anyone go through all the expense of writing a clear detailed and extensive one. Instead, as things were built in house, information could be quickly exchanged internally, in e-mails, verbally or scribbled on napkins.
I've already seen industrial applications (controlling lab instruments) which where initially designed only to pilot the equipement, and on which an SDK was only tackled as an after-though, with completely botched documentation, where only half of the symbols in the DLL are covered by the book (including crucial API calls which were just skipped), ambigously worded partial documentation (As in "FooBazor() - this function sets the new foobaz". Well thanks, but WTF is a foobaz ?)
That has never stopped them from producing a functional software because, well, they were doing it internally and they could always ask a colleague who knew.
And that a situation where :
- there's no licensing issue covering the software it self (the IP is the equipement itself), unlike the "patent minefield" of codecs, so the equipment manufacturer was much more free to release info.
- the company has at some point taken the decision to document their code to be able to cite "open to extension" as a selling point. Unlike VIA which only starts to document (as in write a documentation for external users) now.
The company I currently work at is even a bigger mess as most of the documentation is simply the source code's comments.
The available stand alone documentation is minimalistic at best. And nowhere is any diagram of the overall flow.
I really seriously thing that, what another /.er proposed - reading the VHDL/Verilog as a form of documentation - happens much more in such settings than we suspect. Specially in rather small teams, doing all the work internally. And a huge part of the rest is transmitted verbally or scribled.
Re: (Score:1)
In many hardware companies in Taiwan (and even smaller hardware companies that I've seen in US/Europe) it is "standard practise" to not have hardware reference documentation. Sure, the pinout and electrical side is documented, since board manufacturers need to integrate the hardware.
Wit some luck there is also a register adress map, and maybe it is correct.
But an actual description of the hardware, i.e. how it works, how the state machines look like, how the flow of command works, etc. simply doesn't exist
Re: (Score:2)
It wouldn't be so bad if they had made an effort to partner with someone to make software with hardware acceleration available, even at a price. ATI and nVidia both went along that route, requiring you to buy the software to make use of h.264 acceleration. With VIA, there isn't even that option, there is literally zero support for a feature they are touting to sell their products.
Re: (Score:1)
How about Option #3: Don't provide reference code at all, just properly document the hardware and less the FOSS crowd write their own?
In addition to the other replies, there's this reason [slashdot.org] - you're putting the end-user first impression, which is absolutely critical for PR and repeat business, in someone else's hands. You can't assume volunteers will deliver to your product launch cycles. You can't even assume you'll get competent and motivated volunteers at all - you probably will, but I wouldn't bet the farm on it.
Re: (Score:2)
Re: (Score:1)
The end user isn't the person buying a single unit, it's the person buying a few tens of thousands to ship in their systems. These people don't need to rely on volunteers, they hire someone to write the drivers from the documentation.
I'm not sure that helps. Hypothetically:
Intel say "We can supply you 100,000 chips at 50 cents each, including working drivers from day one and software support."
VIA say "We can supply you with 100,000 chips at 40 cents each, 10 cents cheaper than Intel. We estimate it will cost you $100,000 and three months to develop your own drivers from our documentation."
Intel are cheaper and - even if they weren't - have no risk of delaying your project. So whose do you buy?
Re: (Score:3, Insightful)
Re: (Score:1)
But that can go the other way too. Without reference drivers to build proof-of-concepts how do you know that VIA's hardware actually does everything you need in the first place? If VIA have no reference drivers to give you how did they test it themselves - how far can you trust them? Does the hardware contain bugs that your drivers would expose? You wouldn't discover that until months into development when it'd cost a fortune to change chip. Support lifetime, OK, fair enough - you'd need to get that in the
Aubrey de Grey (Score:2)
VIA and Mini/Pico-ITX (Score:3, Interesting)
I understand that's question to different department. But still.
Does VIA intends to promote and produce further Mini/Pico-ITX mainboards?
What I'm really missing is barebone PCs based on such mainboards. There is a whole zoo of component - but they are not always compatible. In my case, for example, I found a good case for Mini-ITX I wish to buy - now the problem is that I can't find Mini-ITX mobos which are as per spec are compatible with it. Apparently physical measurements of the Mini/Pico-ITX are not completely standardized or are not sufficient to cover all what other manufacturers want to throw into the mix.
Also, Mini/Pico-ITX lacks its own spec for power supplies. The ones shipped with cases are often of bad quality (or overhear or too noisy).
Does VIA intends to start selling complete Mini/Pico-ITX solutions? Something I need to throw in only hard drive/RAM/etc - and I have a ready system.
Re: (Score:1)
Is this what you want?:
http://www.mini-itx.com/store/ [mini-itx.com]
They have full systems like:
http://www.mini-itx.com/store/configure.asp?sid=HUSH-B1 [mini-itx.com]
Re: (Score:2)
Most cases will fit most motherboards, exception often being the "silent" boards and intel boards... I don't think it's ever a problem except for those two, because they are the only two that might have parts rising over the backplate.
As for whole systems, logicsupply has some, and the ARTIGO kit is very good for picoITX.
For power supplies, well, picoPSU is the only good one to be honest. =/
Just pay the license... (Score:2, Interesting)
So any chip maker like VIA is not required to pay the patent licensing royalties since they just produce an 'intermediate product' which somebody else can turn into a 'consumer product'. This works fine in an environment where VIA makes chips and provides reference driver code under NDA to a system integrator
Just pay the license and tell the system integrator that each machine comes with an MPEG2/H.264/... license. Yeah, you product will seem more expensive (to the stupid system integrator). :)
Re: (Score:2)
Why would you do this when not all of the systems integrators actually need the MPEG2/H.264 licenses?
Re: (Score:1)
Regarding 3D support answers... (Score:5, Insightful)
Shame. Easiest answer would be to divulge the programming info for the GPU cores in question. Something AMD managed to do.
I suspect you have a serious problem on your hands though, based on your response regarding S3, which still claims itself as being a VIA "joint venture". Typically, the parents of a joint venture has a bit more pull on the child company than you're implying. While they're autonomous, you would typically have enough pull to at least do things like dump programming info on the IGP lineup.
Time, really, is something VIA doesn't have a lot of on their side at this point. You have Intel breathing down your necks and while the Isiah CPU is an awesome product from the things you've been demoing, it doesn't do any good for you if the IGP you're relying upon in the netbook and baseline ITX board lineup hasn't any support for things like 3D or video acceleration in it's support on Linux. Something Intel's already got lined up- in spades compared to VIA. Power consumption or speed of the CPU doesn't buy you anything if you can't USE them.
Heh... It's funny that you should mention ATI. AMD had to do that, yes. But, you missed mention of the other thing AMD has done- give out technical documentation for most of the chipset's functionality. They're even working on divulging the 3D programming info on their latest offerings right now. Now, I'm not saying that VIA (or you for that matter) are in a position to fix that situation on the UniChrome/Chrome9 components. But to say that AMD's situation is even roughly analogous to yours and that it takes time is a bit disingenious, Harald, because of the other little detail.
Re: (Score:1, Informative)
>I am a Citizen of the State of Texas
You are a citizen of the United States. You reside in the state of Texas.
Re: (Score:2)
>I am a Citizen of the State of Texas
You are a citizen of the United States. You reside in the state of Texas.
You might find this interesting:
http://en.wikipedia.org/wiki/State_citizenship [wikipedia.org]
Re: (Score:2)
Why any mods saw fit to mod your post as "informative" is beyond me. But then, this IS /. afterall...
Re: (Score:1)
'divulge the chrome9 programming information': To the best of my knowledge, particularly the 3D chrome9 core has zero documentation. So there is nothing that could be 'divulged'.
S3 graphics has not developed the VIA IGP products, but VIA has. S3 would not have any more knowledge about the register map of VIA's IGP chipsets.
ATI/AMD: I still think the situation is very similar, just with a difference in the timing. I'm not saying that VIA's situation NOW is comparable to ATI/AMD's situation NOW. But it is
Re: (Score:2)
Considering that S3's claiming they provided the CORE for the IGP "The following VIA Technologies North Bridge chipsets include an integrated S3 Graphics UMA core. Click on the logo for details from VIA's website:" [s3graphics.com], that's a bit conflicting with what you just said.
Moreover, I'm a bit disturbed by the following remark:
Re: (Score:2)
Okay... I found out WHY you haven't got documentation.
Guess what, VIA's got a serious problem on their hands because of those "standard practices".
VIA lost my business (Score:5, Interesting)
VIA would have had a lot of business from me had their drivers either worked, or their communication been good, or they'd opensourced all this stuff earlier.
In my last job we produced kiosk and signage displays, as well as multiple display units for bookmakers shops. Each shop ran up to 32 displays, and some customers had 4-5000 shops. That's a lot of hardware.
We first looked at VIA miniitx boards as they had everything we needed, technically speaking. But the drivers sucked, bore no resemblance to any documentation, were incapable of being accelerated, and couldn't be rotated (for portrait displays) no matter how much they were supposed to. If they supported opengl properly it wouldn't have been an issue. This is without going into the problems of the thousands of different revisions of VIA hardware, all of which failed in subtly different ways.
I left the company but they're now using NVidia boards which are more capable, but not as suitable for an embedded solution. Like me the rest of the techies got sick of fighting VIA stupidity.
If this new open methodology gives us proper opengl support and video decode in a mainline kernel they will win a lot of customers. As it is, it's still some way from that. A real shame.
Too many projects? (Score:2, Funny)
I'm involved in way too many projects, and all of them are suffering desparately to get some more time and love by me. But I'm constantly thrashed and just only have a limited number of timeslices available.
Get back to work, you slacker, and stop spending so much time on Slashdot!
Publishing just drivers should not violate patents (Score:1)
Re: (Score:2)
any hardware capable of breaking the patent should always be considered capable of doing so.
Sucks to be Intel, then.
Re: (Score:1)
Re: (Score:2)
Mpeg-2 is afaik [mpegla.com] $2.50 each for encode and decode per unit.
Add $0.25 per unit above 50'000 for Mpeg-4 SP/ASP.
For H.264 (a.k.a Mpeg-4 AVC) it is as far as I can figure [mpegla.com]:
0-100'000 units: free
100'000 - 5 mill: $0.20 per unit
5 mill+ : $0.10 per unit
You want fries [mpegla.com] (erm, VC-1) with that? Similar licensing cost as with AVC.
All said and done it doesn't look like it should add more than a few $ at retail. Probably the same price as now, actually, because somewhere in the value chain someone is already paying the licen
On GPL Violations (Score:2)
I'm surprised my Q actually made it onto the list. Harald has my unending gratitude, not for answering my question, but for all the work he's done pursuing GPL violators. It's obvious more needs to be done. No way should Harald be personally liable for unforseen consequences in this area.
I certainly favor the carrot over the stick, but when you have solid evidence a for-profit company has stolen code and is profiting from it then copyright holders have got to stand up for their rights. I'm glad BusyBox
Very useful Q & A (Score:2)
Thanks Slashdotters for the good questions.
Thank you Harald for the detailed answers and all the work you have done for Free Software.
Thank you Slashdot for providing the forum.