AMD Catalyst 7.12 Linux Driver -- The Baby's In Surgery

[eigerhar]

Reverse engeneering

Reverse engeneering is possible also from an XP-dll.
Do you think that linux will never have hardware decoding of h.264 only because it is open source?
H.264 is the future for DVB-H. Do you think that this future will not be accessible for open source only because some poeple interconnected DRM with hardware encoding?
I'm not interested in DRM contents.
Already now it is possible to have software decoding of h.264. There is no difference if this is done by hardware now.
I think that linux has shown his good will to protect the copy rights.
There is no real danger that this would change with a hardware decoder of h.264.
Any way reverse engeneering will be done in the legal limits. There is no difference if this is done from XP (see ReactOS) or from an ATI-Linux codec.

[rbmorse]

All you have to do is convince AMD legal that such RE'ing isn't a violation of the DMCA.

Now...I don't care what anyone else does, but for my purposes the approach Fedora takes with the Fluendo codecs works for me. I pay the money, use licensed CODECs and life goes on. Maybe the same kind of deal could be worked out with h.264.

[bridgman]

Doing some kind of library is a possibility for non-protected video decoding. It's a non-starter for protected video because we need to protect the decoded output and that depends on the driver "vendor" being willing to put their signature on the driver and vouch for the robustness of the protected path (and of course there *is* no "driver vendor" for an open source driver), but for non-protected content we would only need to worry about tamper-proofing the module to prevent exposing DRM issues via RE.

If you can RE it we can't ship it -- it's that simple.

For clarity, I am *not* saying we're going to do anything like this, just that it's one of the options we will look at. Writing the module is a *lot* more than a week once you do enough performance tuning to make it useful on laptops and desktop cards with narrow memory buses. Making a working prototype might be a week's work but it's probably 50x that to get it to the point where it really works for most users, and it would probably take the same amount of work to get robust tamper-proofing in place on a useable module.

I know it sucks but we didn't invent DRM despite what you read on Slashdot

[eigerhar]

reactos.org

On ReactOS.org you can read under which conditions reengeneering is LEGAL.

So the only choice to have hardware decoding is reactOS or Windows?
Or is there any hope that RadeonHD will have other conditions than catalyst?

So it was a big mistake to buy Radeon HD 2600 XT because of UVD.

I'd better have waited for a Penryn which has no problem to do all the decoding on software.
(That's what INTEL praises Penryns for.)

[bridgman]

Just to be clear, I'm saying that we don't have a solution today for exposing UVD to open source developers. We have more options with catalyst.

Any modern high end CPU can do the decoding in software -- I don't think you need a Penryn. We didn't bother including UVD in R600 because (within reason) anyone buying an R600 would also have a high end CPU and could decode in SW without a problem. UVD really adds value in laptops and midrange PCs which don't have the fastest CPUs or memory subsystems.

[givemesugarr]

Just to be clear, I'm saying that we don't have a solution today for exposing UVD to open source developers. We have more options with catalyst.

Any modern high end CPU can do the decoding in software -- I don't think you need a Penryn. We didn't bother including UVD in R600 because (within reason) anyone buying an R600 would also have a high end CPU and could decode in SW without a problem. UVD really adds value in laptops and midrange PCs which don't have the fastest CPUs or memory subsystems.

in fact i'm looking forward to it for my laptop.... and maybe someday i'll be able to watch h264 high quality videos without killing the machine.... but maybe before that to happen i'll go with a new r600 or 700 mobile chip.

ps. since sony bmg, last house to still support drm, is starting to drop it, will there be a chance for future amd gpus without that ugly stuff that only bothers the community sometime? i know that average linux users don't use that kind of stuff for their most free contents that they use, it wouldn't be so bad to have future gpus without its burden.

[ivanovic]

You seem to be mixing two things:
1) DRM on music. That is basically dead by now since most labels do also offer the songs with "just" some watermark.

2) DRM used for video material. That is heavily used and will be used since it is basically part of the specification of Blue-Ray and HD-DVD. And the movie studios do not want to drop that, at least it does not look like they do want to, even though the copy protection is basically broken already.

What the DRM issues amd/ati (and we as users, too) seems to be facing is basically related to DRM on video content. So it will take until DRM on video is just a bad part of history until amd/ati will really be able to free all the info about that part of hardware.

I really do hope that they will find a way to open some specs so that the graphics card can be used for accelerating video decodeing (and maybe encoding too, that would be great...).

[eigerhar]

Keep clean from DRM!

One good thing is that Linux user will keep clean from DRM content.

It is good that there doesn't exist any driver in Linux that easily plays commercial DRM's. Otherwise poeple would buy this commercialistic products. But if you haven't a High END PC, it is better to download bittorrents in divx. (There are enough converters anyway).

All this problems with ATI-UVD makes it clear: There is a big commercial force behind this DRM. They want to take money from us for every breath we do. They want to link every multimedia instrument to their commercial products.

The bad thing is that h.264 compression is missing.

[Vighy]

why don't you like DRM? if you pay you get, and if someone sells anything, you mustn't steal it, and DRM is just a way to prevent it.

correct me if I'm wrong but:
what sounds strange to me is that the security of this drm module implemented in ati cards, is based on the secrecy of its specifications.

if it's true, it's one of the worst things anyone can ever do! it's a general law that says: "the security of an algorithm (hardware or software) must be only related to the key, and not to the secrecy of the algorithm itself"

but this is not much in topic any more.

what about the issue I'm experiencing with this last version of this driver?
I'll paste the original post here:

Hi, I got a strange issue with this new release: when running the composite extensions (and a compositor manager of course) i get a swap of cold a warm colors.
with the previous releases didn't happen.
I'm using a M76 and running Xorg 7.2 on a x86_64

ah I forgot to say that without

Option "BackingStore" "true"

and composite enabled Xorg crashes in th first 30 seconds of activity.

finally, does anybody know how to turn on anti-aliasing for 32bit 3D apps under a 64bit environment?

Thank's :-)

bye! :-)

[eigerhar]

Why I don't like DRM

There is nothing wrong about DRM if it is done on a honest way. If anyone wants to buy DRM contents, he may watch it. But if the industry blocks MY graphical card with ALL hardware decoding only because I don't want to look their stupid content I get very angry.

If anyone wants to use commercial content its his problem. But to contrain everyone to do the same is CRIMINAL!

I don't want to see anything of their stupid content. I want only my system to WORK!!!