On Monday 02 July 2018 07:30 PM, Pekka Paalanen wrote:
On Mon, 2 Jul 2018 16:25:28 +0300
Pekka Paalanen <[email protected]> wrote:
On Fri, 29 Jun 2018 21:41:33 +0530
Ramalingam C <[email protected]> wrote:
The idea here was that set_srm_table() is a simple API we can easily
maintain upstream. The external plugin would check the SRM table dates
and signatures and if they pass, call set_srm_table(). The external
plugin would also offer the client interface, whether it is Wayland,
DBus, or something else, to the video players. I believe this is a
design we could the very least agree to in upstream Weston, provided
there is a way to test set_srm_table() by feeding a sample SRM table
e.g. through a small test plugin in upstream.
Oh, and if saving the latest SRM table to persistent memory is needed,
the external plugin could do that as well.
I forgot to note, the Wayland protocol implementation would be in
Weston upstream. There should be no reason to push that out to an
external plugin. So Weston upstream would not only offer
set_srm_table() but also take care of tracking the protection status,
enabling HDCP on Wayland client request and reporting the status to the
client.
That sounds good!
It is only the SRM table management that I am concerned about. And the
topology thing, but I know nothing about that yet.
At least for SRM handling we have some clarity now.
Topology info will be a structure as a blob from kernel. Compositor is
expected to pass that to client.
We need an API lets say get_hdcp_topology() similar to set_srm_table for
passing the downstream topology. Plugin will read it and pass it to clients
for their consumption.
Thanks,
Ram.
Thanks,
pq
_______________________________________________
wayland-devel mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
