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