On Monday 18 June 2018 02:23 PM, Pekka Paalanen wrote:
On Mon, 18 Jun 2018 13:38:09 +0530
Ramalingam C <ramalinga...@intel.com> wrote:
On Monday 18 June 2018 01:34 PM, Pekka Paalanen wrote:
On Sat, 16 Jun 2018 12:50:52 +0530
Ramalingam C <ramalinga...@intel.com> wrote:
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.
Pekka,
We proposed a uevent from kernel for indicating the HDCP status change.
But that didn't fly. Right now the merged interface expects compositor
to poll
the property state for the runtime failures.
Ugh. :-(
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.
Compositor is expected to store the latest SRM in the non-volatile and
update with only newest versions.
And it will supply the latest version to kernel(irrespective of what
version is provided by app). This caching is not per connector.
SRM table itself provides the version of it. and The validity of an SRM
is established by verifying the integrity of its
signature with the Digital Content Protection LLC public key, which is
specified by the Digital
Content Protection LLC. So no fake SRM will be accepted.
Right, so I would propose to make that completely separate.
Ok. So how that should be implemented? As another protocol extension?
Thanks,
Ram.
Thanks,
pq
_______________________________________________
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
