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. Thanks, pq
pgp41_ZLIdhDX.pgp
Description: OpenPGP digital signature
_______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
