Separating UVD functionality out of fglrx, into a separate, closed source module

[runeks]

I've been thinking about the whole UVD-situation, and how we might best find a solution that respects both AMD's NDAs and users of the open source radeon driver.

One thing that came to mind is separating out the UVD functionality from fglrx - keeping the UVD code closed source so as to not reveal anything that AMD is unable to reveal - and enabling the functions of the UVD through this closed module in the open source radeon driver. The radeon driver could then use this optionally installable module to enable UVD in itself, without breaching any NDAs.

Haven't we come to a place where it would benefit everyone the most, if we could just get the functionality that is actually in the hardware, regardless of whether this functionality is provided by open source code or not?

If someone doesn't like the idea of an open source driver using a closed source library - and I fully respect that position - they can choose not to install the UVD module and the driver would be as open as it has always been. No change for them.

I'd love to hear the views of any AMD representatives on this.

Good day!

/Rune

[tettamanti]

One thing that came to mind is separating out the UVD functionality from fglrx - keeping the UVD code closed source so as to not reveal anything that AMD is unable to reveal - and enabling the functions of the UVD through this closed module in the open source radeon driver. The radeon driver could then use this optionally installable module to enable UVD in itself, without breaching any NDAs.

It's not about NDA, the issue is protecting the DRM core. I guess that a smaller binary library for UVD could be easier to reverse engineer with a black box approach.

[runeks]

Thanks for your reply.

Can you elaborate on the relationship between the "DRM core" and the UVD unit?

I'm not sure I understand the purpose of DRM functionality in a unit like UVD that is supposed to aid in decoding video. If we have some video content we would like to decode, what good would DRM do? We already have the video data that we would like to decode... What am I missing?

[pingufunkybeat]

If you decode a DRM-encrypted video, then the hardware must make sure that you can't simply take the decrypted video stream and save it to the hard disk. That's why we have the cluster*^$? that we do, and the DRM is closely tied with the decoding hardware. Of course it hurts legitimate users, but the media providers don't give a crap about that, of course.

At least in the current chips, since they were designed long before ATi had any intentions to write open drivers.

[runeks]

OK, I see. And this intermixing of the UVD- and DRM functionality in hardware makes it impossible to do just an implementation of UVD in software, ie. leaving out any DRM functionality and only providing features that accelerate video decoding?

[tettamanti]

OK, I see. And this intermixing of the UVD- and DRM functionality in hardware makes it impossible to do just an implementation of UVD in software, ie. leaving out any DRM functionality and only providing features that accelerate video decoding?

Technically it's probably possible. The point is that doing so might compromise the DRM exposing the decoded content leaving AMD open to legal problems (and maybe even revocation of hw keys). It's true that that HDCP master key has been compromised so the point is somewhat moot, but that attack vector requires ad-hoc hardware while breaking UVD would allow a software-only solution.

That's probably the official line IRL both AACS and BD+ have been cracked, so a "pirate" can access the protected content anyway (and in a much more practical way, it's not that easy to manage an uncompressed HD stream).

[runeks]

The point is that doing so might compromise the DRM [...]

OK. Initially I had a hard time imagining how this was possible, but when I think about it now I can imagine a scenario where implementing just UVD is basically impossible, eg. if the UVD calls go through some sort of DRM routines regardless of whether DRM is in use or not. In this case the DRM calls would have to be implemented in the software driver, exposing their inner workings for the world to see.

I guess it's true what they say; that when something seems to good to be true, it probably is .

[jonwil]

AFAIK no DRM is involved in the actual decoding hardware or the drivers, just that for the drivers to get the "this hardware can play protected content" signature/flags from Microsoft, they must take all possible steps to protect the unprotected compressed video content as its sent to the card.

This means they cant publish specs for the decoding part.
And they cant release a separate closed source module (since any such module could be trivially reverse engineered)

Personally, I think the best answer is to just reverse engineer (using a combination of the code/docs we already have and the binary FLGRX drivers) the relavent interfaces.