What Do You Want In Linux Drivers This Year?

[Kano]

Maybe ATI can keep the bugs, when I get every month 100 euro for every bug I found which was not fixed but reported one month before Would be 1700 euro for the rendering bug I found in the 8.41.7

[Craig73]

We *can* do whatever we want... it's just that if we don't do what other people want (DRM implementation in the Windows drivers, carefully protected) we lose maybe 70-80% of our market

This applies to all the hardware vendors; this is not an ATI/AMD-specific problem.

Bridgman, not knowing the nuances of driver writing, would it be possible to split the driver into core rendering/display control functionality and plug DRM into it? That way hardware support/2d/3d/video acceleration is possible for non-DRM content in an open source driver, and the DRM could be compiled in as required (or possible added as a binary blob)? [or would this expose too much of the driver internals providing possible circumvention routes... like QTFairUse used to do to iTunes]

[deanjo]

Just as a FYI, it's not only DRM that holds back features. The big player licence several technologies from 3rd parties which may or not wish for their tech to be opened sourced. AFAIK several of the features found in the windows/blob drivers also contain IP from the likes of S3 (S3TC), PowerVR, SGI, etc. When a product uses their IP they want to get paid for it and still have their IP protected.

[Craig73]

Just as a FYI, it's not only DRM that holds back features. The big player licence several technologies from 3rd parties which may or not wish for their tech to be opened sourced. AFAIK several of the features found in the windows/blob drivers also contain IP from the likes of S3 (S3TC), PowerVR, SGI, etc. When a product uses their IP they want to get paid for it and still have their IP protected.

Fair enough... I was aware of that but was just more focused in my statements. Not being involved in driver development, I wasn't sure where the opportunities were to maximize code reuse while splitting out the items of concern (similar to how Gallium3d or the various memory managers represent code that the drivers would otherwise need to implement).

I suppose cleanly integrating code that uses the IP and DRM might dictate a driver structure that makes it difficult to separate out... but that was more the basis of my question. [Even if it could be easily split out, that might be a rewrite which might be hard to justify and easier to just let the open source driver to develop separately]

[bridgman]

Bridgman, not knowing the nuances of driver writing, would it be possible to split the driver into core rendering/display control functionality and plug DRM into it? That way hardware support/2d/3d/video acceleration is possible for non-DRM content in an open source driver, and the DRM could be compiled in as required (or possible added as a binary blob)? [or would this expose too much of the driver internals providing possible circumvention routes... like QTFairUse used to do to iTunes]

There are two problems here. One is that if you isolate DRM to a single module with an API between it and the rest of the stack then it becomes too easy to reverse-engineer the DRM module. It's like putting a big "Kick Me" sign on the DRM code

The second is that for performance reasons the DRM logic is integrated with the video decoder logic. The question is whether we can identify a subset of programming information which lets an open source driver developer make use of the hardware without providing enough information for someone else to be able to get around the DRM.

Bottom line is that most of the challenges here relate to making sure that software on Linux does not reveal hardware information which could be used to attack software on Windows or MacOS. The organization of the software on Linux doesn't seem to make that much difference.

[RobbieAB]

You've got the resources - how about you put all those OpenCL capable cards you've got there to some good use and blast open that ridiculous hurdle.

I wonder, would a brute force cracking of the key constitute a bypass of the access restriction under the DMCA? After all, you ARE going in through the standard route...

[bridgman]

Legal or not, I can't imagine that doing something like that would improve our ability to work closely with Microsoft on future OS and DX releases

[RobbieAB]

Some how, nor do I. I was just musing on the comic value of that as a legal defence..

And I suspect I forgot the sarcasm tags...

[bridgman]

Some how, nor do I. I was just musing on the comic value of that as a legal defence..

And I suspect I forgot the sarcasm tags...

No worries, I understood

[Vighy]

What do I want???

EVERYTHING!

no, just to be able to play with KMS and all those other nice things