On Sat, 16 Jun 2018 12:50:52 +0530 Ramalingam C <ramalinga...@intel.com> wrote:
> On Friday 15 June 2018 04:16 PM, Nautiyal, Ankit K wrote: > > > > Hi Pekka, > > > > Thanks for the suggestions. Please find my responses inline: > > > > On 6/15/2018 1:16 PM, Pekka Paalanen wrote: > >> On Wed, 13 Jun 2018 10:34:45 +0000 > >> "Nautiyal, Ankit K"<ankit.k.nauti...@intel.com> wrote: > >> > >>> Hi All, > >>> > >>> I am working on wayland content-protection protocol extension, to > >>> enable content-protection (HDCP1.4, HDCP2.2) in wayland. DRM layer > >>> already has support for HDCP1.4 and patches for HDCP2.2 are in > >>> review :https://patchwork.freedesktop.org/series/39596/ > >>> > >> From what I heard, the hardware will continuously or periodically > >> confirm the protection status of the display data stream on the wire, > >> and it is possible that the hardware status will change at runtime. The > >> very least hotplug is a thing. > > > > Yes agreed. The app will have a listener to content protection status. > > It makes sense to have the even named as on/off. > Yes. HDCP Link status can change in run time for any connector. > So Compositor is expected to check the current HDCP status of all > connectors on those protected surface is rendered. > And inform the client with runtime cumulative HDCP protection for that > protected surface. How does the kernel signal to userspace that the HDCP status has changed? Do you piggyback on the hotplug event? Anything that would require userspace to repeatedly re-read properties without any events triggering it is bad design. If nothing is happening, the compositor needs to be able to stay asleep. > > As I understand the SRM messages will be delivered with content, to > > the kernel. > > There is a separate Connector proprty of type blob for this. > > SRM can be transmitted with a cable TV signal. It might be keep on > > getting updated as more devices, keep on adding to the table. > > > > SRM table will be updated by DCP LLC as and when device is revocated. > And updated SRM table will be shared to all protected content providers. > So the protected content player needs to supply the SRM to the kernel > for the revocation step in authentication, through compositor. > > Compositor has to store the latest version in non-volatile memory and > expected to provide this information as a > blob to all the connector for the authentication at the kernel. Storing > in non-volatile is required to fulfill the HDCP spec. That sounds like the SRM table should not be part of a Wayland extension. Let's say you have two apps: A and B. Vendor of A is shipping an updated SRM table. Vendor of B is not shipping it yet, so it has an outdated SRM table. A user launches app A, then app B, to watch both. A trivial protocol implementation will have app B overwrite the SRM table with an outdated version. The SRM table smells very much like compositor configuration, especially because a) it is global state: you cannot program two different tables to the same connector, and b) the compositor is required to save it and use it later for all clients(?). One can also envision a security issue, if a system allows third party apps: an app could install a fake SRM table with a fake date. So I would recommend keeping the SRM table updates out of this protocol extension and work on that separately. Also, do you have a way or requirement to authenticate the SRM table? Is it signed? How do you install the verification key? > > > >>> * Downstream topology handling by the compositor, in case of, > >>> HDCP repeaters. > >> Why would that be an issue affecting the protocol? > > > > The topology information needs to be sent to client, in case of repeater. > > I thin Ram can shed more light on it. > This interface is required to implement the repeater using the intel > platforms. > In such scenario, each connectors will be considered as one HDCP > downstream ports. > Compositor and kernel will be used for the HDCP authentication of the > downstream devices. > And a userspace module can implement upstream port's HDCP authentication > through wireless/wired channel. > > So this interface will be used for collecting the downstream devices in > each ports and provide them > to the upstream hdcp device for the repeater authentication step. > > I will try to compose complete flow in a mail. That will help us to be > in sync about the design we need and feasible. Good, because I really didn't quite understand who does what now in there. Thanks, pq
pgpCrlxO8_SjE.pgp
Description: OpenPGP digital signature
_______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
