[PATCH v2 2/2] drm: Add Content Protection properties to drm

[Daniel Vetter]

On Thu, Dec 4, 2014 at 8:03 PM, Sean Paul <seanpaul at chromium.org> wrote:
> Add new standard connector properties to track whether content protection
> (ex: hdcp) is desired by userspace. There are two properties involved,
> "Content Protection" and "Content Protection KSV".
>
> The "Content Protection" property allows userspace to request protection
> on a connector. Set "Desired" to enable, "Undesired" to disable.
>
> The "Content Protection KSV" property reflects the current state of
> protection. If the KSV is 0, the connection is not protected. Once the
> driver has enabled protection, it will update the the value with the KSV
> (or similarly unique identifier, if not using HDCP) of the first-hop
> device (sink or repeater).
>
> Signed-off-by: Sean Paul <seanpaul at chromium.org>
> ---
>
> Changes in v2:
>         - Split property into 2
>                 - one for desired/undesired
>                 - one for disabled/ksv


So this came up again, and I have a slightly less abritrary opinion on
the split vs. non-split property topic. My assumption was that we want
to tell userspace the ksv so that it can do the blacklisting. But it
sounds like at least all the designs with some kind of secure
processor (maybe that's a hdcp2.x thing only) will do the blacklisting
in that special processor and fail to set up encryption if the sink is
blacklisted. So for those cases I think just the tri-state property +
maybe some way to update the SRM (system renewability message iirc,
aka The Blacklist) would be the better interface.

We might still need the split approach that exposes the the ksv in a
separate property. And for that probably still need a tri-state to
lock down the ksv to a specific one, to allow userspace to blacklist
it. But I think we should only add that once we have hw that needs it
(doesn't seem the case for now after a quick irc chat).

tldr; I'm leaning back to v1 ;-)

Patch itself needs updating since properties are a bit more formal
nowadays - we haz real docs, and we expect some core support for
standardized props - something along the lines of the recently floated
"link status" stuff is imo the new gold standard. Wrt naming bikeshed:
I think we can just go with this since it's shipping in cros, makes
the entire userspace thing much easier ;-)
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch