On 03/29/10 15:34, Corbin Simpson wrote:
There is already a non-infringing decoder inside Mesa, wired up correctly, that kicks in when the HW supports it, but there's no extension that exposes only decoding and loading functionality. As Ian said, you need an encoder as well, and no HW has it, so you'd have to write some questionable code.
So to clarify, you're saying a partial implementation (decoder only) isn't an option at all? If you expose an extension it must be complete? Can't you just do a NOOP on encoding or handle it uncompressed? I don't see why the encoder is so important since it seems to me that uncompressed data would cause no issues for software rendering and compressed data should cause no issues for hardware rendering (as stated earlier, on most modern hardware you can pass it through to VRAM). The main problem seems to be the lack of a decoder as it makes assets completely unusable on certain platforms whereas lack of an encoder typically only impairs efficiency except in fringe cases (games that compress textures "on-the-fly").
I'm kind of confused. Are you just trying to see if any of us can be convinced to write this code for you?
Yes. Though not for me as I don't play the games in question. However that's an oversimplification. What I'm really asking is when it was concluded no workaround is possible, to what extent was it discussed or was it agreed that nobody should look at the patent at all (willful infringement defense)? Are the legal opinions you are referring to made public? Is the issue a lack or resources, lack of interest, lack of alternatives, lack of understanding or just a general fear of unspecified litigation or vague threats. It was also an attempt to see where the EFF sits on this issue and whether that would consider investigating some of the broader claims in the patent as part of their patent busting efforts. After all, if there really is NO possible workaround it kind of implies, to a layman at least, that the patents claims may be overly broad. I am simply following a sensible process of elimination, which is: a.) Determine what can't be done. b.) Determine what can be done. c.) Substitute b for a. If you won't touch it, then you won't. If you don't want to talk about it (again) I completely understand. I can't force you and I won't nag you. But there may be others out there, perhaps sitting on the sidelines, who might have something new to offer. At the least consider this a case of simple curiousity as the FAQ is somewhat vague on the matter and the specific claim(s) at issue unclear (at least to me). Even with access to the archives of this list I don't have the benefit of knowing the full extent to which this issue has been explored behind the scenes. I raised the points I raised to assist in a way that seems positive. That is to cut through several pages of patent legalese to the specific claim elements blocking a new type of decoder and then try build a preliminary technical assessment that could guide programmers around the hurdles or be reviewed by a patent attorney without completely wasting their time. SpliFF -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org