On Thu, Jul 13, 2017 at 8:54 AM, Ramalingam C <ramalingam.c@xxxxxxxxx> wrote: > On Thursday 13 July 2017 11:39 AM, Daniel Vetter wrote: > > On Wed, Jul 12, 2017 at 9:10 PM, Sean Paul <seanpaul@xxxxxxxxxxxx> wrote: > > 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? > > 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. > > I've had requests from chrome team to expose HDCP version, so I don't think > this > is too contentious. > > 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 > > 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. Yeah, but if we just go with enable (without specifying the type) we could still enable the highest hdcp level (so 2.2 for our case). At least I don't see a reason why we need to already have the enable_type1 thing. Can you pls explain why you think this is necessary? There seems to be a need to force type1, but I think it's easier to do that as an extension. Of course we need to keep it in mind meanwhile. -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
