On Thu, Dec 4, 2014 at 8:03 PM, Sean Paul <seanpaul@xxxxxxxxxxxx> 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@xxxxxxxxxxxx> > --- > > 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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
