On Wed, Jan 13, 2021 at 2:39 PM Sean Paul <sean@xxxxxxxxxx> wrote:
>
> On Wed, Jan 13, 2021 at 5:34 AM Anshuman Gupta <anshuman.gupta@xxxxxxxxx> wrote:
> >
> > On 2021-01-07 at 04:08:58 +0530, Sean Paul wrote:
> > > From: Sean Paul <seanpaul@xxxxxxxxxxxx>
> > >
> > > The HDCP 1.4 spec does not require the QUERY_STREAM_ENCRYPTION_STATUS
> > IMHO DP 1.4 vesa specs I.3.5 mark QSES as desirale for both HDCP 1.4 and HDCP 2.2.
> > "The MST Source device may use a QUERY_STREAM_ENCRYPTION_STATUS message
> > transaction to query the downstream status for a particular stream."
> >
> > I feel it useful for scenario in which a non hdcp supported monitor
> > is hot plugged to MST branch. Source really doesn't know about the hdcp
> > capable device on MST branch, it just know the capability of immediate
> > downstream device. QSES can fetch the HDCP capability from MST topology.
> > We don't require to enable stream encryption for such streams.
>
> I agree it's useful when it works, but unfortunately it's broken on at
> least 2 MST bridge chips I've encountered :/
>
> Until we can figure out a) how to fix them (ie: firmware updates), or
> b) how to enumerate all of the broken chips to create quirks, we
> probably just want to disable QSES for HDCP 1.4.
What happens when the user plugs in a non-hdcp screen into a hub which
doesn't do QSES? Just black screen?
That would suck a bit, otoh with broken hw I don't see how we could do
better :-/
-Daniel
> Sean
>
> > > check, it was always a nice-to-have. After deploying this across various
> > > devices, we've determined that some MST bridge chips do not properly
> > > support this call for HDCP 1.4 (namely Synaptics and Realtek).
> > >
> > > I had considered creating a quirk for this, but I think it's more
> > > prudent to just disable the check entirely since I don't have an idea
> > > how widespread support is.
> > May be we can remove it from the link check and can retain as utility ?
> > Thanks,
> > Anshuman Gupta.
> > >
> > > Signed-off-by: Sean Paul <seanpaul@xxxxxxxxxxxx>
> > > ---
> > > drivers/gpu/drm/i915/display/intel_dp_hdcp.c | 26 +-------------------
> > > 1 file changed, 1 insertion(+), 25 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
> > > index 03424d20e9f7..b6a9606bf09a 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
> > > @@ -640,30 +640,6 @@ intel_dp_mst_hdcp_toggle_signalling(struct intel_digital_port *dig_port,
> > > return ret;
> > > }
> > >
> > > -static
> > > -bool intel_dp_mst_hdcp_check_link(struct intel_digital_port *dig_port,
> > > - struct intel_connector *connector)
> > > -{
> > > - struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
> > > - struct intel_dp *intel_dp = &dig_port->dp;
> > > - struct drm_dp_query_stream_enc_status_ack_reply reply;
> > > - int ret;
> > > -
> > > - if (!intel_dp_hdcp_check_link(dig_port, connector))
> > > - return false;
> > > -
> > > - ret = drm_dp_send_query_stream_enc_status(&intel_dp->mst_mgr,
> > > - connector->port, &reply);
> > > - if (ret) {
> > > - drm_dbg_kms(&i915->drm,
> > > - "[CONNECTOR:%d:%s] failed QSES ret=%d\n",
> > > - connector->base.base.id, connector->base.name, ret);
> > > - return false;
> > > - }
> > > -
> > > - return reply.auth_completed && reply.encryption_enabled;
> > > -}
> > > -
> > > static const struct intel_hdcp_shim intel_dp_mst_hdcp_shim = {
> > > .write_an_aksv = intel_dp_hdcp_write_an_aksv,
> > > .read_bksv = intel_dp_hdcp_read_bksv,
> > > @@ -674,7 +650,7 @@ static const struct intel_hdcp_shim intel_dp_mst_hdcp_shim = {
> > > .read_ksv_fifo = intel_dp_hdcp_read_ksv_fifo,
> > > .read_v_prime_part = intel_dp_hdcp_read_v_prime_part,
> > > .toggle_signalling = intel_dp_mst_hdcp_toggle_signalling,
> > > - .check_link = intel_dp_mst_hdcp_check_link,
> > > + .check_link = intel_dp_hdcp_check_link,
> > > .hdcp_capable = intel_dp_hdcp_capable,
> > >
> > > .protocol = HDCP_PROTOCOL_DP,
> > > --
> > > Sean Paul, Software Engineer, Google / Chromium OS
> > >
> > > _______________________________________________
> > > Intel-gfx mailing list
> > > Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
> > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> _______________________________________________
> dri-devel mailing list
> dri-devel@xxxxxxxxxxxxxxxxxxxxx
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
