<html> <head> <meta content="text/html; charset=utf-8" http-equiv="Content-Type"> </head> <body bgcolor="#FFFFFF" text="#000000"> <div class="moz-cite-prefix">On 11/22/2018 1:01 PM, C, Ramalingam wrote: </div> <blockquote cite="mid:5c3ca099-1eb2-9dc3-d45a-af95e814c103@intel.com" type="cite"> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> Hi Scott, I am working on enabling the HDCP1.4 and 2.2 in kernel and Weston from Intel. Would like to share some points here. <div class="moz-cite-prefix">On 11/21/2018 7:35 AM, Scott Anderson wrote: </div> <blockquote type="cite" cite="mid:48e7a313-15a5-a80f-61f7-ae1989baae92@collabora.com">Hi, As far as I understand, the different types and versions of protection a client would want is based on the resolution of the content, rather than anything about what the content actually is. Is there any particular reason a client would care if their content is being used on a higher HDCP version than is necessary? e.g. would a client with 720p content care about using HDCP 2.2? </blockquote> </blockquote> No it does not matter to client, and it does not matter to the compositor as well. The policy that which protocol to use, for the given content type rests with the kernel. If HDCP2.2 is the strongest available (on all connected connectors), the kernel will use it, even if the content is 720p. <blockquote cite="mid:5c3ca099-1eb2-9dc3-d45a-af95e814c103@intel.com" type="cite"> <blockquote type="cite" cite="mid:48e7a313-15a5-a80f-61f7-ae1989baae92@collabora.com"> If that's the case, I think it would make sense for the compositor to always try to negotitate the strongest level of protection that it can (or a lower level if set by some policy), and report to the client the largest resolution that it can support securely. With that, the client can then make the decision about what content it can provide. </blockquote> </blockquote> In case of HDCP, A HDCP2.2 compliant sink supports Type-0 and Type-1 and HDCP1.4 supports Type-0 only. The compositor at most can tell the client, based on the capabilities of the connected displays, the highest type of content that it can show securely. The client can then show the content according to the suggested type or lower. The problem with that is - for getting the capabilities of the connected displays, kernel needs to actually do full authentication on all connectors. Which will not be useful, if the client does not have the content with suggested type. <blockquote cite="mid:5c3ca099-1eb2-9dc3-d45a-af95e814c103@intel.com" type="cite"> <blockquote type="cite" cite="mid:48e7a313-15a5-a80f-61f7-ae1989baae92@collabora.com"> <interface name="..."> <event name="secure_resolution"> <arg name="width", type="int"> <arg name="height", type="int"> <arg name="refresh", type="int"> </event> </interface> This would remove a lot of the back-and-forth between the client and the compositor, where the client says what content it has, and the compositor saying if it can securely display it. </blockquote> <pre>But the problem is HDCP2.2 spec leave the content type classification(type 0 and Type 1) to the content provider (in our case client).</pre> </blockquote> Yes right, mostly the content-provider, if one considers services like Netflix, Amazon prime etc, divide the type of content as UHD, FHD, SD based on stream quality. UHD is mostly 4K which definitely will require highest protection, FHD that would be 1080P, would require some reasonable protection and the SD that will be below 1080P, in case of no-protection at all. In that view, instead of client passing the resolution, the content-type or category (Type 0 and Type 1 as defined by hdmi spec) seems to be more in line with what content-providers would like, than the resolution. Regards, Ankit <blockquote cite="mid:5c3ca099-1eb2-9dc3-d45a-af95e814c103@intel.com" type="cite"> <pre>As you mentioned these type classifications just mandates the minimum HDCP spec that they need to be authenticated with. Like Type 0 content can be transmitted to HDCP1.4 /2.2 authenticated digital sink but where as Type 1 has to be transmitted the HDCP2.2 authenticated digital sink. Considering this we can see that type of content should come from content providers (clients). And as pekka mentioned in runtime any surfaces can be dragged to any output, compositor/hdcp protocol server will make sure all the required sinks are authenticated with minimum required HDCP spec. And clients trust the compositors on the status events generated. These HDCP protection status prone to break incase of new hotplug. So compositor needs to give the status as whether content protection status has met the type requirement from client or not. In this way IMHO we need not tag the surface whether protected or not and filter them on outputs based on their content protection status. Based on the compositor events let the surface provider (client) decide whether required HDCP status is met to render the protected surface or not. This makes the design simple and to the requirement. Please point me out if something is missed in this approach. Thanks, --Ram </pre> <blockquote type="cite" cite="mid:48e7a313-15a5-a80f-61f7-ae1989baae92@collabora.com"> This event could also be re-emitted when the protection status changes. There could also be the special case of 0x0, where the compositor failed to negotiate any secure connection, and no resolution is secure. A compositor may also choose to emit this signal based on what output the client is set to display on, but that would probably be left up to the compositor policy. It's possible that wl_output could be integrated into this somehow, but I haven't thought too much about how yet. Scott _______________________________________________ wayland-devel mailing list <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:wayland-devel@lists.freedesktop.org">wayland-devel@lists.freedesktop.org</a> <a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://lists.freedesktop.org/mailman/listinfo/wayland-devel">https://lists.freedesktop.org/mailman/listinfo/wayland-devel</a> </blockquote> <fieldset class="mimeAttachmentHeader"></fieldset> <pre wrap="">_______________________________________________ wayland-devel mailing list <a class="moz-txt-link-abbreviated" href="mailto:wayland-devel@lists.freedesktop.org">wayland-devel@lists.freedesktop.org</a> <a class="moz-txt-link-freetext" href="https://lists.freedesktop.org/mailman/listinfo/wayland-devel">https://lists.freedesktop.org/mailman/listinfo/wayland-devel</a> </pre> </blockquote> </body> </html>