[PATCH] ACPI/Intel: Rework Opregion support
Alex Deucher
alexdeucher at gmail.com
Tue Mar 15 19:17:34 PDT 2011
On Tue, Mar 15, 2011 at 8:02 PM, Indan Zupancic <indan at nul.nu> wrote:
> On Tue, March 15, 2011 17:06, Alex Deucher wrote:
>> On Tue, Mar 15, 2011 at 7:46 AM, Indan Zupancic <indan at nul.nu> wrote:
>>> They don't give their Linux devs any Fusion hardware, nor do they
>>> open the UVD spec, but at least they release info like this.
>>
>> They do give us fusion hw; before launch even. That's why we had
>> Linux support before hw was available publicly. My board just
>> happened to get bricked recently during a failed bios upgrade.
>> A new one is on the way.
>
> Okay, that's better than I thought. I remember a dev saying that
> no one had Fusion hardware, that's where I got this notion from.
>
>> Also we are looking into a potential release of
>> UVD, but unfortunately, our decode hw is intimately tied in with
>> our drm implementation and if someone managed to use the released
>> information to compromise the drm in our windows driver it would very
>> negatively impact our ability to sell into the windows market and
>> would probably get the open source graphics initiative shut down.
>
> Are you talking about HDCP or something else? Because the HDCP master
> key already leaked, so the whole security aspect of it is already a
> joke, open source UVD won't make any difference.
>
It's not HDCP, encrypted bluray is the main issue. And while there
are hacks for bluray around already, contractual obligations don't
care whether existing hacks are available or not.
> Basically you're telling me that I or someone else should reverse
> engineer de Catalyst driver and break all drm before you consider
> opening up UVD? I'd argue that opening up UVD now is more secure
> because it takes away the only morivation to break UVD's drm.
>
> Alternatively, can't you open up UVD spec except the drm bits,
> so people can at least write their own UVD driver to watch
> unencrypted data?
Without going into detail, they are very intertwined. The hw was
designed long before we planned to support open source as much as we
are now. Fortunately, we have been working with our hw teams to make
future UVD implementations take the open source driver into account.
>
> It would be nice to have an open source Fusion based media player/
> IPTV decoder, but I guess that's hoping for too much.
>
> I understand if AMD/ATI wants to keep its 3D driver secret, but
> hardware video decoding?! If you have to keep it secret it means
> shortcuts were taken and it's all insecure anyway. That if it gets
> broken the Open source driver gets blamed is ridiculous and more
> politics than anything else.
We don't keep the 3D engine secret. Most of the code we've written
and specs we've released are 3D engine stuff. Fortunately 3D is less
tied up in drm compared to video. It's all about mitigating risk.
Imagine you run a company and someone asks you this: "Can we release
programming info for a part of our chip to support 2-3% of our market
that may put at risk 90% of our market?" What would you do? The
reason the review is taking so long is that we want to be real sure
that the risk is safe.
>
> This is getting more and more off-topic though, sorry for the noise.
>
Agreed.
Alex
> Greetings,
>
> Indan
>
>
>
More information about the dri-devel
mailing list