-----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@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
