open source drivers and TV out/video decoding

[jonwil]

I see references in a number of threads to various "legal issues" preventing the release of specs for the TV output and/or hardware video en/decoding built into the ATI boards, can someone explain just what these "legal issues" actrually are?

[bridgman]

There are a few separate issues. For TVOut the output hardware includes the ability to apply Macrovision encoding to the output, so that a DVD played over TVOut can not be recorded on a VCR or DVD recorder. In order to enable tvout in an open source driver, we need to release enough info to let you enable TV outputs but without giving you the ability to turn off Macrovision protection.

This is obviously less of an issue than it was 10 years ago (particularly since DVD copying programs are so common and some of the relevent patents have expired), but we still need to worry about it a bit from a legal perspective. That said, we have already separated out the Macrovision control stuff and released working TVOut code for NTSC, although I think there are still problems with getting proper colours on PAL. So TVOut = done-ish

For video decoding, the big issue there is that video decode hardare is primarily there to play AACS-encoded media (ie BluRay disks) and that requires the video to be protected (encrypted) all the way through the chip. We enter into various legal agreements to keep tose protected video paths robust; without those agreements, we lose the ability to sell into most OEM markets.

The chips can play non-encrypted video but in order to release programming info for open source drivers we need to find a subset of information we can release which lets driver devs use the decoder but does not give enough hardware information for anyone to hack into our proteced video playback paths on other OSes. Unlike TVOut, we have not found a way to do this yet. Video decode = not done.

Video encode is a third issue; various locales have requirements that anyone capturing video broadcasts must recognize specific flags (eg the aborted Broadcast Flag in North America) and refuse to propogate that video. We don't yet have a good way to let you write a capture driver while properly enforcing any future Broadcast Flag-like legislation. I'm not totally clear on the legal requirements for capture, but that's not a problem yet -- video capture was never on the roadmap although we I guess we will look at it after finishing all the things we said we would do.

[jonwil]

With regards to the video decoding stuff, would some kind of binary blob that allows for the hardware video decoding but doesnt provide specific documentation of the actual hardware registers (thus not allowing someone to figure out what they need to hook into in order to grab the DRM protected streams from e.g. a Windows box) work?

Although I guess you then have a situation where hackers reverse engineer the binary blob easily due to its small size (as has happened with WiFi drivers that used binary blobs to protect the stuff that needed to be protected in order to make the WiFi device legal). Also, you then have a situation where the binary blob needs to be updated all the time (support for new hardware, support for new kernel/x versions etc) as well as ported to other operating systems that people may want to port the ATI OSS drivers to (such as BSD, Solaris or ReactOS)

[bridgman]

Exactly; a small binary blob surrounded by open source code is just too easy to reverse-engineer. We might as well give documentation and/or sample code.

[lxnt]

For TVOut the output hardware includes the ability to apply Macrovision encoding to the output, so that a DVD played over TVOut can not be recorded on a VCR or DVD recorder.

Does that mean that you are bound to make any TVOut slightly unrecordable, even if it's just an xearth on root window?

We don't yet have a good way to let you write a capture driver while properly enforcing any future Broadcast Flag-like legislation.

Does that mean that you are bound to enforce future, and thus non-existent legislation?

Now I can imagine a contract binding you to the former, but for this latter part, I'm, err, slightly astonished.

[rbmorse]

They have to worry about what happens when Broadcast Flag (or similar) is enacted.

If they release an open, non-compliant driver right now there is no meaningful penalty, but they will effectively wipe out their entire product line once BF or similar legislation goes into effect.

Given the current crowd of wackos in Congress, and the amount of Money the TV and Motion Picture industry has "invested" in getting people who are supportive of their concerns elected, I expect to see "broadcast-flag" legislation resurrected and passed in this Congress.

[bridgman]

Does that mean that you are bound to make any TVOut slightly unrecordable, even if it's just an xearth on root window?

Not exactly... we are only bound to make the TVOut unrecordable if an API call has been made to *make* it unrecordable. Normally that call is not made on Linux, although my guess is that the certified DVD players probably use the API.

We mostly need to make sure we don't release programming information which allows you to turn off the protection on *other* OSes. I know you guys don't care about other OSes, but it's all the same hardware.

Does that mean that you are bound to enforce future, and thus non-existent legislation? Now I can imagine a contract binding you to the former, but for this latter part, I'm, err, slightly astonished.

It's not quite that bad. We don't need to make drivers today that implement future legislation... but we can't release hardware information *today* which might allow you to get around a *future* driver, on any OS, which implements support for future legislation.

So... part of our job is to anticipate future legislation, anticipate what the driver design would be to implement that legislation, anticipate the potential attacks on that future driver, and be careful not to release information OR enable the reverse-engineering of information which would enable a future attack on a future driver.

As I said before, if your head is starting to spin and you feel a dull headache coming on, that means you're starting to understand

They have to worry about what happens when Broadcast Flag (or similar) is enacted. If they release an open, non-compliant driver right now there is no meaningful penalty, but they will effectively wipe out their entire product line once BF or similar legislation goes into effect.

Exactly. Releasing a closed, non-compliant driver is fine because that doesn't expose information about how to hack a future, compliant driver. Open drivers are a different story; every scrap of information, documentation or code, released or potentially reverse-engineered, has to consider the impact on our ability to comply with both present and future legislation.

Nobody said this would be easy, just that we were going to do it anyways

[grantek]

So I assume that if any of this stuff is reverse-engineered with no help from AMD, you're clear? I mean video encode/decode can be (and is being) done on the CPU, and you don't hear anyone complaining to Intel yet (although I have scary premonitions about "trusted" computing making inroads here).

[bridgman]

Nope, we're equally screwed whether the info is released by us or reverse-engineered independently.

That's what makes my job so much fun

It's not the ability to encode/decode that we have to protect, it's the associated ability to manage protected content. They're not separate blocks though; everything is integrated to reduce power consumption and improve performance.

[lxnt]

I now understand, thank you.

It is sad that we have to pay for useless parts of hardware and witness massive waste of effort on part of engineers, but I guess I can live with that for as long as documented parts and non-wasted effort provide enough gpu power.

Currently x1950 -s can be had for around $26 and that's more than good enough.

Thank you.