Linux will never get a PlayReady Media Extension. Linux users control the kernel of the device. Even if hypothetically TPM technology or similar could be used to play video "securely" nevertheless (with hypothetical future tech), it would still be too great a risk to let it on to such a "compromised" system.
You could delegate decryption to the video-card itself. This would also prevent the attack vector of running a 'secure' system inside of a transparent VM.
Not to mention the fact that Linux has some very smart people, with a history of reverse engineering stuff for compatibility; and breaking any advanced DRM system is an honor onto itself.
That was the hypothetical future tech I had in mind. AFAIK, it does not exist. It would also need to integrate with the audio, while still letting DRM-unprivileged processes manipulate the location on the screen, volume, pause, fast forward, etc etc etc. It's a pretty tall order to make all this work on a system where the user is controlling the entire rest of the software stack, and absolutely, positively ensuring that there is no way whatsoever to get the audio or the video, even though the user has every other bit of hardware at their disposal, in what are presumably numerous distinct hardware configurations. It's certainly theoretically possible but it would take numerous released-to-the-public iterations to get right and probably a few more for this to be remotely stable.
>ensuring that there is no way whatsoever to get the audio or the video
I await the patent on how to DRM photons.
Relating to the rest of your points, I am not convinced that it is that difficult to mix protected and non-protected graphics. The untrusted software tells the graphics card a square region of the screen where the movie should be played, and streams the cipher text to the card. When the graphics card goes to render a frame for the physicall display, it first renders the the protected content, then renders any unprotected content from the software. Where the two overlap, the protected content simply gets hidden by the unprotected content. Obviously, all of this rendering would happen in an undisplayed buffer, so the user only sees the finished frame.
Yes... the spec is simple. I don't deny that. But in a world where the leading graphics vendors can barely write drivers that don't crash on their own hardware... who, exactly, is going to get it all right? On real hardware? That people will buy?
It's all simple and obvious until you try to implement it on real hardware.
