Trident Micro Update
grendelkhan writes: "According to Linux Today, Trident is denying that they are no longer supporting open source developers for XFree86." This message from Eich clarifies the events leading up to this. Looks like Trident chips will continue to be supported, one way or another.
I don't think the email really answers the question. It sounds to me kind of like it's still in negotiation.
The simple truth is that interstellar distances will not fit into the human imagination
- Douglas Adams
Well I went through the process of sending their customer relations department a nice letter.
I calmly informed them if quality drivers for their products ceased to emerge in the marketplace that I would seek other alternatives.
At the time I felt like an informed reader and now I feel like an ass.
"You should always go to other people's funerals; otherwise, they won't come to yours." -- Yogi Berra
From Egbert's linked email:
"Alan Hourihane has tried to obtain documentation for the latest Trident chipsest (CyberBladeXP and CyberBladeXPm) without success. He offered to sign an NDA with 'source code exception clause' a clause which allowed distribution of unobfuscated source developed with the help of documentation otherwise covered by the NDA.
Trident appearantly didn't accept a 'source code exception clause'."
Just being the casual observer that I am, I would question if it is in fact settled. Trident has yet to provide the documentation requested by the XFree86 group in the manner in which it has been received prior to this chipset. All Trident has provided is some PR spin about their "policy" not changing. This is often times done by companies to try and do some damage control.
Until they provide the documentation needed they still need to be pressured.
...just twisted.
You can release the source- and in many situations, you can fix it, so long as the bugs aren't with the interactions with the device. In that case, you need to enter into an NDA with the company to get the data. So long as they're willing to allow people to be involved as they show interest, then there's little problem- otherwise you end up with the joke that NVidia pulled with the Utah-GLX driver support.
It's doable, just nowhere near as useful as releasing everything to let anybody work on it.
I am not merely a "consumer" or a "taxpayer". I am a Citizen of the State of Texas
I've said this in the last posting of the story, but it was at the bottom so I don't know how many people saw it:
We should have IBM, Micron, or who ever else uses these chips in their laptops to ask Trident to release the documentation that is needed to develop a driver for FreeX.
It's harder to ignore IBM than it is a single developer.
III.IIVIVIXIIVIVIIIVVIIIIXVIIIXIIIIIIIIVIIIIVVIII
If I read all of the above correctly...
Trident's policy has been, and still is, to require an NDA. That NDA prohibits source code distribution of a driver based off information obtained under NDA. Apparantly, from the successful development of drivers for past Trident chipsets, this part wasn't enforced.
Now, Trident seems to be enforcing that part -- by not providing information to XFree86 developers on the CyberBladeXP and CyberBladeXPm chipsets. The XFree86 developers wanted to amend the NDA to allow source distribution.
Since there has been no change in the NDA, only in enforcement, Trident is claiming that they provide the same support as before. Technically, they do -- sign the NDA and provide binary-only drivers and they'll provide docs.
So, if you support the idea of source code availability for video drivers, keep an eye on the graphics chipset used in your next potential laptop. If it is Trident, look elsewhere.
Learning HOW to think is more important than learning WHAT to think.
From what I read, you are required to sign an NDA to get the specs.
If you write a driver, and then publish the source to that driver, are you not 'disclosing' the stuff you said you wouldn't?
Either accept the terms of the NDA, or don't. It's Trident's call whether they want to allow you to release how to write drivers to their hardware to the general public or not.
The poster has given a dead on assessment of the current Trident situation. Trident will not give documentation to XFree86 under the conditions it has previously agreed to give the documentation. XFree86 cannot accept an NDA agreement that requires obfuscating source code, or receiving only a binary component for a feature supported by XFree86.
Who cares that Trident SAYS they support the Linux community if they make it functionally impossible to produce code based on their "support"?
If you want to have working Trident drivers for Linux, the Linux community will still have to apply its consumer pressure in order for XFree86 to be able to provide Trident drivers.
There is no America. There is no democracy. There is only IBM and AT&T and DuPont, Dow, General Electric, and Exxon
The gist is that, the driver will only be able to be distribued in a binary form if they are required to sign the NDA. So, all the VP did was beat around the bush, and say that we will continue to support open source, but without saying it, he reaffirmed the position that you can get the docs, but you can't share the info, thus only a binary driver can be distributed.
http://www.tridentmicro.com/videcomm/tridproduc
The Encoder offers "MacroVision Version 7.01 Copy Protection support" If that's the case then most likely they can not have source code released that may allow someone to circumvent the protection scheme. If you know anything more about this please post.
It only sort-of worked, didn't have DMA support, and needed their documentation (which they weren't giving out) to fix things right. This is not the same driver that they're shipping right now, but was their "open source" driver they gave to us prior to it. People are slowly fixing it as I write this, but it's taking 10 or more times more effort to get things there.
I am not merely a "consumer" or a "taxpayer". I am a Citizen of the State of Texas
It's straight up MacroVision like you'd find on a video tape from MPAA's member companies. So what if it means it's never turned on? It's only supposed to be turned on by a DVD player anyhow to prevent it from getting in the way of other non DVD uses of the composite/SVHS signal. Since we, as the general Linux using public, can't get DVD players "officially", I can't see why they'd be making that an issue- never mind the fact that purchasing a MacroVision scrubber is currently legit and undoes it anyway.
I am not merely a "consumer" or a "taxpayer". I am a Citizen of the State of Texas
They did change theri stance. when a request was placed, just like the others for the earlier chipsets was placed, was denied, it's because the rules were changed.
The letter from trident is just corperate doublspeak designed for damage control. Until they say "oops sorry, we sacked that guy that denied you access" and give up the documents under the NDA like they used to it is still a changed policy.
Do not look at laser with remaining good eye.
From the email:
2. Alan Hourihane has tried to obtain documentation for the latest
Trident chipsest (CyberBladeXP and CyberBladeXPm) without success.
He offered to sign an NDA with a 'source code exception clause'
a clause which allowed distribution of unobfuscated source
developed with the help of documentation otherwise covered by the
NDA.
Trident appearantly didn't accept a 'source code exception clause'.
We therefore assumed that Trident Microsystems has modified its policy
of providing technical documentation.
If Trident says you can't distribute unobfuscated source code based on NDA-covered infromation and XFree86 says they won't accept an NDA with these terms, the roadblock remains. Trident can say they support OSS all they want and that nothing has changed, but it still makes it impossible for XF86 to use the information.
"that's not encryption - it's a new perl script that I'm working on..." - from some Matrix parody
don't expect an answer. The person who did this used his moderator points and therefore cannot post in this discussion. Sorry :)
karma capped