Wayland content-protection extension

Fri Jun 15 13:40:20 UTC 2018

On Fri, 15 Jun 2018 15:06:05 +0200
Arnaud Vrac <rawoul at gmail.com> wrote:

> On Fri, Jun 15, 2018 at 10:08 AM Pekka Paalanen <ppaalanen at gmail.com> wrote:
> >
> > On Thu, 14 Jun 2018 13:09:24 +0200
> > Arnaud Vrac <rawoul at gmail.com> wrote:
> >  
> > > On Wed, Jun 13, 2018 at 12:34 PM, Nautiyal, Ankit K
> > > <ankit.k.nautiyal at 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/
> > > >
> > > > As per the IRC discussion on #wayland about content protection extension for
> > > > Wayland (yesterday, 12th June 2018) , please find below the agreed points:
> > > >  
> > >
> > > Hi Ankit,
> > >
> > > Thanks for working on this, overall I agree with your design, which
> > > provides a first level of security when more advanced output
> > > protection enforcement is not available. I missed the discussion on
> > > IRC so I'm sorry if my comments are reduntant.
> > >
> > > I see one problem with this approach of hiding the output state to the
> > > client: there is no way to choose the content in advance based on the
> > > output protection capabilities.  
> >
> > Hi,
> >
> > generally there cannot be in-advance information. Until a window is
> > actually mapped, the compositor will not know where it will show up as
> > the scenegraph may change due to the client, other clients, or hotplug,
> > etc.
> >
> > It would be a narrow special case compositor that would know
> > before-hand what the protection for a surface would be.
> >
> > I have assumed that applications are able to switch the content quality
> > at runtime to match changes in the protection status. If this is not
> > the case, the issue needs to be brought up now.
> >
> > OTOH, an application can always map the window with non-sensitive
> > content to see what it will get. I don't think that would be a problem
> > if the system design otherwise guarantees that the protection status
> > does not change while the window is mapped. However, I don't think we
> > should make the demand of status not changing in the protocol extension.  
> 
> Hi Pekka,
> 
> A content provider can provide many stream versions for the same
> content, based on the codec, profile, level supported by the video
> decoders of the platform, the capabilities of the display hardware
> (max resolution, hdcp level support, hdr modes), and the capabilities
> of the connected outputs. There's no point in serving 4k content if
> the display or decoders do not support it, or if the display block or
> connected sink does not support the required protection level.
> 
> So I believe wl_output (or an extension of it via a separate protocol)
> should expose its supported protection levels (which would be the
> intersection of the display block and the connected sink
> capabilities). This does require negotiating with the connected output
> for its protection capabilities beforehand.

Does it have to be per wl_output, why not just a single global maximum
level?

After all, clients generally do not get to pick where they show, so
knowing per wl_output does not seem useful.

(Btw. anything you want per-connector is per-wl_output, so that is
right, even for clone mode IMO.)

I'm still not quite sure what the benefit is. You can hotplug a display
with higher capabilities at any time. Or is that out of scope?

Btw. is the content itself can carry something (SRM table?) that
affects the possible protection level, would you need to report maximum
possible protection level per surface?

> > > Most content providers have the same
> > > content available in multiple qualities, and the better qualities will
> > > be available based on the device and output capabilities.
> > >
> > > Since the client has no way of knowing on which output the video
> > > surface will be shown, the maximum protection level supported by all
> > > outputs should be exposed to the client, and the client can then
> > > determine if it's worth switching to a higher quality, and if there's
> > > a chance it will be displayed on at least one output.  
> >
> > I'm not sure knowing the chance is possible given how the DRM UAPI for
> > it has been designed: you will know only after attempting to enable a
> > specific content type whether you got what you asked for. If you ask
> > for Type 1 and receive "no", that won't tell you anything about whether
> > Type 0 would succeed, so the compositor has to try again. I'm told that
> > HDCP negotiation can take a noticeable amount of time, so I assume
> > compositors would not want to attempt it speculatively.
> >
> > At least I am assuming that a compositor would not want to enable HDCP
> > unless it is actually wanted. If a compositor is enabling maximum
> > protection at all times, then it would know the chances.  
> 
> You're right, enabling HDCP can take time and even cause screen
> flickering. To avoid this it is preferable to negotiate the highest
> level supported to avoid switching at runtime. This is not required
> though to query the sink HDCP capabilities, so exposing the wl_output
> HDCP capabilities is still possible without enabling encryption.

It sounded like the kernel UABI precludes that.

> > Then again, I suppose if a compositor knows what the protection status
> > will be, it can send events for it even before mapping the window. I
> > just don't want to require it, and I would not want to imply that apps
> > can rely on it.  
> 
> Unfortunately all the major content providers already require this for
> their "official" app to work correctly and expose the proper video
> streams (and their PlayReady/Widevine/foo DRM license, which contains
> the stream output protection level requirement). I don't see how they
> could handle this use-case efficiently without this information.

Show a "please wait, setting up Digital Rights Management" image,
before actually choosing the stream source?

Or simply the player UI, "loading", "buffering", whatever.

Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20180615/1477e59a/attachment.sig>