mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Indan Zupancic" <indan@nul.nu>
To: "Alex Deucher" <alexdeucher@gmail.com>
Cc: "Chris Wilson" <chris@chris-wilson.co.uk>,
	intel-gfx@lists.freedesktop.org, linux-kernel@vger.kernel.org,
	dri-devel@lists.freedesktop.org,
	"Matthew Garrett" <mjg@redhat.com>, "Len Brown" <lenb@kernel.org>,
	"Alan Cox" <alan@linux.intel.com>
Subject: Re: [PATCH] ACPI/Intel: Rework Opregion support
Date: Wed, 16 Mar 2011 01:02:39 +0100 (CET)	[thread overview]
Message-ID: <5ddb021757c3aec6d2eda30372a422ee.squirrel@webmail.greenhost.nl> (raw)
In-Reply-To: <AANLkTim6H3UCCsT1iAR2O=PL=5K4ypkT7UqcjqbAf3Vp@mail.gmail.com>

On Tue, March 15, 2011 17:06, Alex Deucher wrote:
> On Tue, Mar 15, 2011 at 7:46 AM, Indan Zupancic <indan@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.

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?

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.

This is getting more and more off-topic though, sorry for the noise.

Greetings,

Indan



  reply	other threads:[~2011-03-16  0:03 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-02-22 20:03 [PATCH 1/2] " Matthew Garrett
2011-02-22 20:03 ` [PATCH 2/2] staging: Use generic IGD opregion code for gma500 Matthew Garrett
2011-02-22 21:15   ` Alan Cox
2011-03-03  2:14   ` Len Brown
2011-03-03  2:16     ` Len Brown
2011-03-03 11:43       ` Alan Cox
2011-03-03 11:43     ` Alan Cox
2011-03-03 13:07       ` Matthew Garrett
2011-03-03 12:52         ` Alan Cox
2011-02-22 20:18 ` [Intel-gfx] [PATCH 1/2] ACPI/Intel: Rework Opregion support Jesse Barnes
2011-03-03  2:14 ` Len Brown
2011-03-14 17:59 ` [PATCH] " Chris Wilson
2011-03-15  1:18   ` Indan Zupancic
2011-03-15  1:52     ` Matthew Garrett
2011-03-15 13:30       ` [Intel-gfx] " Olivier Galibert
2011-03-15 13:32         ` Matthew Garrett
2011-03-15 13:40           ` Olivier Galibert
2011-03-15 13:43             ` Matthew Garrett
2011-03-15  8:37     ` Chris Wilson
2011-03-15 11:13       ` Indan Zupancic
2011-03-15 11:27         ` Peter Stuge
2011-03-15 11:46           ` Indan Zupancic
2011-03-15 16:06             ` Alex Deucher
2011-03-16  0:02               ` Indan Zupancic [this message]
2011-03-16  2:17                 ` Alex Deucher
2011-03-16  6:26                   ` Indan Zupancic
2011-03-16 14:11                     ` Jerome Glisse
2011-03-16  3:46       ` Dave Airlie

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5ddb021757c3aec6d2eda30372a422ee.squirrel@webmail.greenhost.nl \
    --to=indan@nul.nu \
    --cc=alan@linux.intel.com \
    --cc=alexdeucher@gmail.com \
    --cc=chris@chris-wilson.co.uk \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=lenb@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mjg@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

Powered by JetHome