Is there not a way to work around this ?
If the hardware doesn't support s3tc, then the driver simply don't advertize the that it can handle s3tc textures, so you would get out of the need to decompress the textures in the driver. On the other hand, if it is not possible to tell the app that you don't know how to compress textures, and are asked for it, then you just send the texture uncompressed or something such.
Ideally, there would be a way to tell the apps that you can receive and use s3tc compressed textures, but not uncompress them yourself.
What about apps that send uncompressed textures into the driver, expect the driver to compress then, and then read the textures back? According to the spec, the textures app will read-back compressed data. I don't see anyway to work around that.
Being that I'm not a lawyer, I'm not sure that the other work arounds would be legal either. Given the ambiguities and risk of it all, until we get explicit permission, I don't think any of the distros are likely to distribute ANYTHING with ANY S3TC support enabled.
------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
