Hi all,
As we discussed in this review thread before, "UNSUPPORTED" state is
added to the HDCP property to indicate a situation when HDCP is not
possible, though hdcp property is attached to connector obj. In such
case I would prefer to detach the hdcp property from connector, which
would have been clear indication of no support. Since that is not
possible at present in our kernel, I have added this state in the property.
In v4 of the uAPI RFC, "UNSUPPORTED" state of Enum is assigned with
"-1", so that it doesn't alter the existing CrOS user space HDCP uAPI
states {UNDESIRED=0, DESIRED=1, ENABLED=2}. Current CrOS User space need
not change anything to use proposed uAPI. v4 of this uAPI RFC posted
should be compatible for downstream uAPI of CrOS. So in current state of
CrOS user space, as usual it can set the property for DESIRED for
enabling the HDCP. But it will be rejected as no HDCP is possible in the
platform. Please share if there is any concern. This can be removed as
it is not a compulsory state for functionality.
Multiple questions are asked in off line discussions, on why can't we
make uAPI as HDCP version agnostic. Sharing the reasoning with
community, so that we all can be on same page.
For first phase of HDCP2.2 development, uAPI proposed is version
agnostic. Thats the reason we are able to use the CrOS's HDCP1.4 support
as user space consumer for Phase 1. But in Phase 2 when we enable
complete HDCP2.2 spec in kernel along with required user space consumer,
uAPI will be extended to support required interface. Such uAPI extension
will expose the platforms HDCP v2.2 capability to the user, and in some
cases, allows the users to mandate the HDCP v2.2 encryption only for
their content. I am bringing this up as we need community agreement for
this second phase of uAPI also. Reasoning for such extension is as follow:
HDCPv2.2 Spec provides an option to the content provider, to tag a
stream, such that it will be given to HDCP2.2(or latest) compliant
devices only through out the distribution chain. This tagging is nothing
but calling the stream as Type 1. In Other words, Type 1 streams are
always encrypted with HDCPv2.2. This stream type info will be passed to
the All HDCP2.2 sinks as part of authentication. So that sinks such as
repeaters/converters wont be transmitting the received encrypted stream
to the HDCP device which is non-compliant with HDCP V2.2.
If a stream can be distributed to HDCP1.4 compliant devices also, that
is tagged as Type 0. Refer the below diagram for pictorial
representation for flow of encrypted stream tagged as Type 0 and 1.
+---+ HDCP v2.2 protected
| HDCP v2.2 | Type 0
Content Type 1 Content
|Transmitter| flow
path flow path
+-+-+
| | |
| v2.2 link | |
v v v
+++ | |
|HDCP v2.2| | |
| Repeater| | |
+--+---+--+ | |
| | +-+-+ +-+
v2.2 link | |v1.4 link |
| |
+--+ +---+ +--+ +---+
+--+
| | | ||
v v v vv
++++++
|HDCP v2.2||HDCP v1.4|
| Panel || Panel |
+-++-+
Note: none of the protected content streams Type0/1 will be shared to
panels which are non HDCP compliant.
We need uAPI to pass the type of stream from user space to kernel because:
1. When Digital Right Management(DRM) wants HDCP2.2 encryption, it will
tag the stream as Type 0/1.
2. One of the parameter for encryption formula of HDCP v2.2 is this
Type info. So Type classification of stream defined by DRM should be
passed to kernel.
3. Many content providers(DRM) want their content to be encrypted only
in V2.2, as v1.4 is already compromised. To fulfill such
requirement, we need to expose the capability of HDCP v2.2 to user
space and also interface to set such requirement to kernel. Adding
option to set type info of stream clears both requirements.
Option 1: All of the above requirements can be fulfilled just by adding
a property state to a existing hdcp property to represent the type info
of the stream. such as {UNDESIRED, DESIRED, ENABLED, TYPE1_DESIRED,
TYPE1_ENABLED}.
Option 2: Assume still we prefer HDCP version agnostic uAPI, as Enum
property with {UNDESIRED, DESIRED, ENABLED}. For HDCP enable request,
latest HDCP version supported will be invoked for encryption. When the
latest version capable is v2.2, still
