Re: [Intel-gfx] HDCP as a Kconfig option

2017-12-06 Thread A. Wilcox 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 04/12/17 15:24, Daniel Vetter wrote:
> Hi,
> 
> I understand there there's concerns about the content protection 
> stuff, but please note:
> 
> - The patches under discussion enforce nothing, they only allow you
> to enable HDCP if you chose to do so. For real content protection
> you need a complete system, locked down with secure boot or
> similar. I think any user concerned about their software freedoms
> knows to avoid such systems like the plague.


I am glad to learn this, as I am sure many others are.


> - Second, the code doesn't run by default at all. You can try to 
> enable HDCP only by explicitly requesting content protection
> through a drm property (which I think should be exposed to xrandr
> by default at least for the modesetting driver). Enterprising users
> can try out what happens if they want to, but by default nothing at
> all happens. So no risk of random breakage due to this.


Okay, this is truly the important part.  Giving the users the freedom
to choose what they want to do is ideal.  The risk of random breakage
was my main concern, especially after having dealt with some pretty
nasty HDCP surprises with Apple drivers for Intel GPUs.

Is this something that must be configured by the user then; i.e.
software cannot itself tell the DRM layer to enable it, it must be set
as an xorg.conf property (or similar)?  Or can any software request it
via xrandr once it's stable?  I would be able to see both sides of the
argument, as you don't want end users to have to play with xorg.conf
just to make (ex.) streaming work, but I also would be concerned that
users don't know their freedoms are being taken from them if HDCP was
something that software could silently enable.

Perhaps a property to force off / default off / default on / force on
might be useful for the driver.  I'm afraid I am not sure how feasible
that would be, but it might be something to consider down the line.
Then distros and users could determine what works best for them, and
it could be changed at any time without recompiling the kernel.


> Given those two reasons I don't think we need a Kconfig option to 
> disable the code even harder. I hope that explains the situation,
> and why the patches don't have a Kconfig option from the start.


Yes, this explanation is great.  I really appreciate your prompt
response and the clarity you've provided.  :)


> Also thanks very much for reaching out to developers instead of 
> everyone else who just panics on forums and passes around silly 
> conspiracy theories. We definitely don't want to merge code which 
> would hurt our users, that would kinda defeat the point of doing
> an open source driver. I don't think this is the case here.


After understanding this further (trying to read the code itself was a
bit gnarly, as the DRM layer is in general for me, so I admit I
couldn't tell whether or not it was on by default), I agree that this
isn't the case.

Again, thank you so much for offering your time to clear up the
situation.  We (the Adélie team, and the Linux user base in general)
appreciate the work you do, and your time in clearing this up.


All the best to you and yours,
- --arw

- -- 
A. Wilcox (awilfox)
Project Lead, Adélie Linux
http://adelielinux.org
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJaJ0XHAAoJEMspy1GSK50UswEP/Rl3mZPVx/FXj/G4ITV7XkEO
dfvQMBjkWq7SehbRrQH9KV+4TUBffi2bV/X3RZaeGrgdWVix3vAiyPbfWYaTP/Dv
VTDonhCFrpg7MZ530H+w+2huKEHTHrZ5lo8lajzGAcmLjYKoFjqWP1EsO3vS34oy
ZgGtU8kJSitnDDp0/qUKzVWf374zpuXoHSXEXHlEpslJZiyNTCiNhACnW//2VUq7
c7CSl9UqEaHnqIN54QNQVZ+ORqdNHMJv9XCCoL7BV+RwD8rkKCE+5+nSuUc3E5vg
VbYpwc7fIKH834+1CaWnfYb5Qr10hFKGdFKHu+R7HRAR4YWDHSdjEGZFsZ3v6c6X
8Klf1nywwdaycHeNikf/1dSi8Su/I9jHsRv2wcJJJgRFxx9yz7i7RTtrmagi1OSP
tHV4306/KbQVS8VYeBYaygJz1k4Yk+pE26g1G/EXeo6YWnPj7Ev2nML+3wUnP7nP
mXgTLMuFRT51tM+WxMy8o2usWwnF/bB70mafRuQIyKZqJbhO5quBdno4qqAVUcvL
ppcNCoS6bf1A71D19iaBQUarkD8mE2dUG5rFuAoMWLgPOua5kxatrvA9WJxAMC9I
vgXW6+czx7X/ZqO8JpKnlDdmqeEtY76knT3uVRwHHFwN+46HIeJ7iWjZXwCmopeH
yaatW4/va//jPmW1ilBd
=M9bh
-END PGP SIGNATURE-
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] HDCP as a Kconfig option

2017-12-06 Thread Daniel Vetter 
On Tue, Dec 05, 2017 at 07:20:10PM -0600, A. Wilcox wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> On 04/12/17 15:24, Daniel Vetter wrote:
> > Hi,
> > 
> > I understand there there's concerns about the content protection 
> > stuff, but please note:
> > 
> > - The patches under discussion enforce nothing, they only allow you
> > to enable HDCP if you chose to do so. For real content protection
> > you need a complete system, locked down with secure boot or
> > similar. I think any user concerned about their software freedoms
> > knows to avoid such systems like the plague.
> 
> 
> I am glad to learn this, as I am sure many others are.
> 
> 
> > - Second, the code doesn't run by default at all. You can try to 
> > enable HDCP only by explicitly requesting content protection
> > through a drm property (which I think should be exposed to xrandr
> > by default at least for the modesetting driver). Enterprising users
> > can try out what happens if they want to, but by default nothing at
> > all happens. So no risk of random breakage due to this.
> 
> 
> Okay, this is truly the important part.  Giving the users the freedom
> to choose what they want to do is ideal.  The risk of random breakage
> was my main concern, especially after having dealt with some pretty
> nasty HDCP surprises with Apple drivers for Intel GPUs.
> 
> Is this something that must be configured by the user then; i.e.
> software cannot itself tell the DRM layer to enable it, it must be set
> as an xorg.conf property (or similar)?  Or can any software request it
> via xrandr once it's stable?  I would be able to see both sides of the
> argument, as you don't want end users to have to play with xorg.conf
> just to make (ex.) streaming work, but I also would be concerned that
> users don't know their freedoms are being taken from them if HDCP was
> something that software could silently enable.
> 
> Perhaps a property to force off / default off / default on / force on
> might be useful for the driver.  I'm afraid I am not sure how feasible
> that would be, but it might be something to consider down the line.
> Then distros and users could determine what works best for them, and
> it could be changed at any time without recompiling the kernel.

I'd say if your concerned about HDCP getting enabled behind your back,
then don't run untrusted 3rd party apps/TPM-locked-down OS stacks that
might enforce this (think netflix on a settop-box). And in that case you
can't trust a force-option anyway, because it will be patched out.

I think the default-to-off behaviour we have now is all we need to avoid
regressions and issues. Anything else on top won't actually achieve more,
except outright refusing to merge perfectly fine open source code that
only exposes an already existing feature of the hw, based on some vague
notion of enforcing principles. That doesn't help anyone and is a nuisance
for the vendors who really care about having a fully open gfx
stack and pay for all this hard work we're putting into the open stack.

> > Given those two reasons I don't think we need a Kconfig option to 
> > disable the code even harder. I hope that explains the situation,
> > and why the patches don't have a Kconfig option from the start.
> 
> 
> Yes, this explanation is great.  I really appreciate your prompt
> response and the clarity you've provided.  :)
> 
> 
> > Also thanks very much for reaching out to developers instead of 
> > everyone else who just panics on forums and passes around silly 
> > conspiracy theories. We definitely don't want to merge code which 
> > would hurt our users, that would kinda defeat the point of doing
> > an open source driver. I don't think this is the case here.
> 
> 
> After understanding this further (trying to read the code itself was a
> bit gnarly, as the DRM layer is in general for me, so I admit I
> couldn't tell whether or not it was on by default), I agree that this
> isn't the case.
> 
> Again, thank you so much for offering your time to clear up the
> situation.  We (the Adélie team, and the Linux user base in general)
> appreciate the work you do, and your time in clearing this up.

Np, happy to explain stuff.

Cheers, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] HDCP as a Kconfig option

2017-12-04 Thread Daniel Vetter 
Hi,

I understand there there's concerns about the content protection
stuff, but please note:

- The patches under discussion enforce nothing, they only allow you to
enable HDCP if you chose to do so. For real content protection you
need a complete system, locked down with secure boot or similar. I
think any user concerned about their software freedoms knows to avoid
such systems like the plague.

- Second, the code doesn't run by default at all. You can try to
enable HDCP only by explicitly requesting content protection through a
drm property (which I think should be exposed to xrandr by default at
least for the modesetting driver). Enterprising users can try out what
happens if they want to, but by default nothing at all happens. So no
risk of random breakage due to this.

Given those two reasons I don't think we need a Kconfig option to
disable the code even harder. I hope that explains the situation, and
why the patches don't have a Kconfig option from the start.

Also thanks very much for reaching out to developers instead of
everyone else who just panics on forums and passes around silly
conspiracy theories. We definitely don't want to merge code which
would hurt our users, that would kinda defeat the point of doing an
open source driver. I don't think this is the case here.

Cheers, Daniel

On Mon, Dec 4, 2017 at 2:20 AM, A. Wilcox  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> (Note: I am not subscribed to the list, please cc me with replies.)
>
> Hello i915 developers,
>
> I represent Adélie Linux, a Linux distribution that has the goal of
> empowering users through the true freedom that only libre software can
> provide.  This new HDCP support patch for i915 has generated a lot of
> talking in our community, because even though it is 'open source' it
> implements hardware DRM.  We feel this to not be in the spirit of
> libre software.  Hardware DRM unevenly puts all of the control in the
> hands of hardware manufacturers and content producers, instead of with
> the people who have paid their hard-earned money to support them.
>
> In addition, different hardware supports different versions of HDCP,
> and in some cases, display panels and hardware cannot even speak the
> same version, which ends up being a nightmare for users who do not
> understand how video links work and just want to see a picture on
> their monitor.
>
> As such, we, the Adélie Linux distribution, respectfully request that
> the HDCP support – if added to the i915 driver (and if this is later
> factored out to generic code, then the generic framework itself) – be
> controllable via a CONFIG_ option in Kconfig, so that we may remove
> the entire feature from the module in our kernel package.
>
> Thank you very much for your time and consideration.
>
> Regards,
> - --arw
>
> - --
> A. Wilcox (awilfox)
> Project Lead, Adélie Linux
> http://adelielinux.org
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2
>
> iQIcBAEBCAAGBQJaJKLIAAoJEMspy1GSK50UMoEP/js0Jex7ToozGriWfzBxPClG
> Q0j8IMpDtKPrcktCTdp4Oo5pIYJcu33p3MG+LYmc/CNIKJ2WZIEPDoY5h2CoXLUg
> T9KhqiiqCMDeHqzuMpeb0C6dWhuzIJOYo3Q8+pDQLAtslWorLExZCN2vm5l2LeZO
> Xa1PG7wwjYGpTCU94e+Z3frBpIVFRb8IYO2N3CvcEu0G06nhQzHSyP+FplITiHpW
> 7G0vOs6Vg0UXyRvhgORr6XYLpWOHBcUwhzkJRAxnUbUOGNKihpy+8cWRuHqmt2bc
> MjfRQD5F3gqQJfG4GcksuAzJ8woUA/t+URRx/b3QXw1chY4CGnADYqtOAx5iAnIf
> Kbgx4RssABypFOXrOCOzdQhS9b21HogvBwLmwgaHxTGGtUi8m3K65XSyEnN3ZSqw
> PU1pVbBma/uh3REUXZmT5GskJckIjJngyjMJnfq77YZVYxIC9sPiA4rTmLL4Z2D3
> s5sTaBd5cdIcDOnlcF0P+rUJSLEos6A2DNu8S/T4AwS3tYg4AtceduHVA9m2Sl71
> XsyKp3KsWAh3A4oLXuPKWJWgJDG3M4MBp/vWg1+ORopnhMz62Gt3mX2GcE3jmLQt
> GRxXwpodyeSGTq/PxwQpr+7gpGm2Wb14wru0kSB2hgeP8V5cUy+7I9hvBY8YTj7F
> aIsMmPkww8F2ge3KJbU0
> =9mDI
> -END PGP SIGNATURE-
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx



-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] HDCP as a Kconfig option

2017-12-04 Thread A. Wilcox 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

(Note: I am not subscribed to the list, please cc me with replies.)

Hello i915 developers,

I represent Adélie Linux, a Linux distribution that has the goal of
empowering users through the true freedom that only libre software can
provide.  This new HDCP support patch for i915 has generated a lot of
talking in our community, because even though it is 'open source' it
implements hardware DRM.  We feel this to not be in the spirit of
libre software.  Hardware DRM unevenly puts all of the control in the
hands of hardware manufacturers and content producers, instead of with
the people who have paid their hard-earned money to support them.

In addition, different hardware supports different versions of HDCP,
and in some cases, display panels and hardware cannot even speak the
same version, which ends up being a nightmare for users who do not
understand how video links work and just want to see a picture on
their monitor.

As such, we, the Adélie Linux distribution, respectfully request that
the HDCP support – if added to the i915 driver (and if this is later
factored out to generic code, then the generic framework itself) – be
controllable via a CONFIG_ option in Kconfig, so that we may remove
the entire feature from the module in our kernel package.

Thank you very much for your time and consideration.

Regards,
- --arw

- -- 
A. Wilcox (awilfox)
Project Lead, Adélie Linux
http://adelielinux.org
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJaJKLIAAoJEMspy1GSK50UMoEP/js0Jex7ToozGriWfzBxPClG
Q0j8IMpDtKPrcktCTdp4Oo5pIYJcu33p3MG+LYmc/CNIKJ2WZIEPDoY5h2CoXLUg
T9KhqiiqCMDeHqzuMpeb0C6dWhuzIJOYo3Q8+pDQLAtslWorLExZCN2vm5l2LeZO
Xa1PG7wwjYGpTCU94e+Z3frBpIVFRb8IYO2N3CvcEu0G06nhQzHSyP+FplITiHpW
7G0vOs6Vg0UXyRvhgORr6XYLpWOHBcUwhzkJRAxnUbUOGNKihpy+8cWRuHqmt2bc
MjfRQD5F3gqQJfG4GcksuAzJ8woUA/t+URRx/b3QXw1chY4CGnADYqtOAx5iAnIf
Kbgx4RssABypFOXrOCOzdQhS9b21HogvBwLmwgaHxTGGtUi8m3K65XSyEnN3ZSqw
PU1pVbBma/uh3REUXZmT5GskJckIjJngyjMJnfq77YZVYxIC9sPiA4rTmLL4Z2D3
s5sTaBd5cdIcDOnlcF0P+rUJSLEos6A2DNu8S/T4AwS3tYg4AtceduHVA9m2Sl71
XsyKp3KsWAh3A4oLXuPKWJWgJDG3M4MBp/vWg1+ORopnhMz62Gt3mX2GcE3jmLQt
GRxXwpodyeSGTq/PxwQpr+7gpGm2Wb14wru0kSB2hgeP8V5cUy+7I9hvBY8YTj7F
aIsMmPkww8F2ge3KJbU0
=9mDI
-END PGP SIGNATURE-
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx