View Single Post
Old 05-15-07, 06:19 PM   #13
hvengel
Registered User
 
Join Date: May 2006
Posts: 57
Default Re: AMD/ATI Commits to open source drivers

Quote:
Originally Posted by lightman
Slightly OT, but,



let me guess ? Monaco Systems and X-Rite ?
X-Rite and GretagMacbeth actually. They merged in June 2006. X-Rite had up until Dec 2006 always released device specific interface specs for their hardware to developers. No need to sign an NDA or even a license for that matter. Just sign up as a developer. On the other hand GretagMacbeth required developers to sign a license agreement that even precluded making calls to their interface libraries in open source software. GretagMacbeth stopped releasing hardware interface specifications for all hardware released after the Spectrolino and it's derivatives.

What makes this particular case so absurd is that the interfaces to these devices are actually very simple compared to something like a graphics card and all of the previously GretagMacbeth devices that are now shipped by X-Rite have had the low level protocols reverse engineered and there is now a GPL interface library available. I am now using this library in my software and it now has support for using a number of current and discontinued X-Rite/GretagMacbeth devices for calibrating and profiling displays in CVS. This has only been tested on Linux and BSD platforms so far but testing should begin on Windows and OSX soon.

I was told by the person who is the head of their software division that they would not release the low level interface specs since this would compromise their "IP" but they also refused to release the interface libraries for Linux/Unix platforms even though they had these available in house since at least 2004. So they basically backed the OSS community into a corner by refusing to provide any support even though I and others literally begged them to release the existing Linux/Unix libraries.

I know the person who did the reverse engineering on these devices and he told me that it took him several hundred hours to have the whole product line reverse engineered and working in his GPL libraries. He also told me that if he had access to the interface specs that he would ahve had a working library for these devices in perhaps 20 hours. So it appears that their notion of how to protect their IP was not very well connected to reality. In the end all they did was create a bad relationship between themselves and those of us in the OSS community who work in that field.

What this really points out is that hardware vendors can take a number of different paths.

1. The path that GretagMacbeth took - which is to basically say to the Linux/Unix/BSD community that you don't want to be bothered and that you will not even supply basic device information to allow them to write their own interfaces.

Clearly this approach does not work well for either the user community or the hardware vendor since in the end the user community will either reverse engineer the hardware anyway exposing whatever IP the vendor was trying to hide or it will walk away from the hardware vendor (if there are alternatives). In addition, it will also leave a bad image of the vendor in the user community.

2. You can take the approach that most of the video card vendors have taken which is to supply just enough in the way of binary drivers/interfaces to prevent the community from creating their own open source drivers.

Nvidia is one of the better examples of how this could be handled. But even at that there are lots of problems that still exist. For example, only a very limited number of hardware platforms are supported. In addition, it appears that most vendors can not pull off doing this successfully. All we have to do is look at ATI and Matrox for two examples of vendors that have failed to be successful at this.

3. You can take the old X-Rite approach and supply hardware specs and let the community take care of writing and supporting interface libraries/drivers. Not a bad approach really.

It does require the hardware vendor to write the specification documents and make them available. So there is some additional work involved on the part of the vendors compared to #1. But beyond that there are no significant negatives for the vendor compared to $1 and #2 above. And compared to #2 it likely results in much lower support costs for the vendor and in the long run should result in better overall support for their devices on these platforms.

4. The approach Intel has taken which is to embrace the community and release your drivers as open source. I personally think this is the best approach.
hvengel is offline   Reply With Quote