[Intel-gfx] HDCP as a Kconfig option
A. Wilcox
awilfox at adelielinux.org
Wed Dec 6 01:20:10 UTC 2017
-----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-----
More information about the Intel-gfx
mailing list