From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ramalingam C Subject: Re: [RFC v1 01/20] drm/hdcp: HDCP bitmask property for connectors Date: Thu, 13 Jul 2017 12:24:33 +0530 Message-ID: References: <1499848144-8456-1-git-send-email-ramalingam.c@intel.com> <1499848144-8456-2-git-send-email-ramalingam.c@intel.com> <20170712095444.7x6msswrmrfvkas6@phenom.ffwll.local> <20170712191022.rgrpra5ni6n2vqx5@art_vandelay> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1017414742==" Return-path: In-Reply-To: Content-Language: en-US List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" To: Daniel Vetter , Sean Paul Cc: Daniel Vetter , intel-gfx , dri-devel List-Id: dri-devel@lists.freedesktop.org This is a multi-part message in MIME format. --===============1017414742== Content-Type: multipart/alternative; boundary="------------1D883B8904D7F564D9DCFAEA" Content-Language: en-US This is a multi-part message in MIME format. --------------1D883B8904D7F564D9DCFAEA Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On Thursday 13 July 2017 11:39 AM, Daniel Vetter wrote: > On Wed, Jul 12, 2017 at 9:10 PM, Sean Paul 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. --Ram --------------1D883B8904D7F564D9DCFAEA Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

On Thursday 13 July 2017 11:39 AM, Daniel Vetter wrote:

On Wed, Jul 12, 2017 at 9:10 PM, Sean Paul <seanpaul@chromium.org> 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.

--Ram

--------------1D883B8904D7F564D9DCFAEA-- --===============1017414742== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KSW50ZWwtZ2Z4 IG1haWxpbmcgbGlzdApJbnRlbC1nZnhAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHBzOi8vbGlz dHMuZnJlZWRlc2t0b3Aub3JnL21haWxtYW4vbGlzdGluZm8vaW50ZWwtZ2Z4Cg== --===============1017414742==--