<html> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> </head> <body text="#000000" bgcolor="#FFFFFF"> <div class="moz-cite-prefix">On Thursday 13 July 2017 11:39 AM, Daniel Vetter wrote: </div> <blockquote type="cite" cite="mid:CAKMK7uE2U=xoEX_HxoC-HUinOk1vLC+MCXMLdYOxWEOnjOWeOg@mail.gmail.com"> <pre wrap="">On Wed, Jul 12, 2017 at 9:10 PM, Sean Paul <a class="moz-txt-link-rfc2396E" href="mailto:seanpaul@chromium.org"><seanpaul@chromium.org></a> wrote: </pre> <blockquote type="cite"> <blockquote type="cite"> <blockquote type="cite"> <pre wrap="">Why all these intermediate steps and different failure modes? Either hdcp works, or it doesnt (and we can split up with the type 0 or type 1 if needed), but I don't know what userspace would do with all the other stuff? </pre> </blockquote> <pre wrap="">enum values HDCP_ENABLE, HDCP_ENABLE_TYPE1 and HDCP_DISABLE along with kobj-uevent for HDCP state change, could do the bare minimal HDCP1.4 and HDCP2.2 configuration. And without Type info it is not possible for HDCP2.2. </pre> </blockquote> <pre wrap=""> I've had requests from chrome team to expose HDCP version, so I don't think this is too contentious. </pre> </blockquote> <pre wrap=""> I think it'd still be easier if we start out with the current content protection props that CrOS is using, and then figure out how to layer the exact version/standard on top? One thing at a time and all that. -Daniel</pre> </blockquote> I understand the approach. But Only problem is current upstreaming effort is for HDCP2.2 support at DRM with a design which can easily accommodate other versions too. So we need to stretch current CrOS property a bit with ENABLE_TYPE1 and UNSUPPORTED etc. Hope that should be fine for all. --Ram <blockquote type="cite" cite="mid:CAKMK7uE2U=xoEX_HxoC-HUinOk1vLC+MCXMLdYOxWEOnjOWeOg@mail.gmail.com"> <pre wrap=""> </pre> </blockquote> </body> </html>