1. 08 Jul, 2019 1 commit
  2. 07 Jul, 2019 2 commits
  3. 05 Jul, 2019 4 commits
  4. 04 Jul, 2019 5 commits
    • Ankit Nautiyal's avatar
      libweston: Add content-protection protocol implementation · 5cfe03c8
      Ankit Nautiyal authored
      This patch adds the content-protection protocol implementation, to
      enable a weston client application to request for content-protection
      for its content via HDCP.
      Signed-off-by: Ankit Nautiyal's avatarAnkit Nautiyal <ankit.k.nautiyal@intel.com>
      5cfe03c8
    • Ankit Nautiyal's avatar
      libweston: Add support to set content-protection for a weston_surface · 4b6e73d6
      Ankit Nautiyal authored
      The protection requested for a given surface, must reach through the
      weston_surface::pending_state, in the commit-cycle for the
      weston_surface, so that it gets updated in the next commit.
      
      As some protection is requested for a given weston_surface, it means
      protection must be set for each of the outputs which show the surface.
      
      While setting the protection of a weston_output, care must be taken
      so as to avoid, degrading the protection of another surfaces, enjoying
      the protection. For this purpose, all the weston_surfaces that are
      shown on a weston_output are checked for their desired protection.
      The highest of all such desired protections must be set for the
      weston_output to avoid degrading of existing protected surfaces.
      A surface requesting protection for a lower content-type can still be
      provided protection for a higher type but the converse cannot be
      allowed.
      
      This patch adds support to set content-protection for a suface, which
      inturn sets the content-protection for each of the outputs on which
      it is shown, provided, none of the existing surface's protection
      request is downgraded.
      Signed-off-by: Ankit Nautiyal's avatarAnkit Nautiyal <ankit.k.nautiyal@intel.com>
      4b6e73d6
    • Ankit Nautiyal's avatar
      libweston: Compute current protection for weston_output and weston_head · 4f64ff8b
      Ankit Nautiyal authored
      The actual protection status for a given weston_head depends upon the
      corresponding drm_head's connector HDCP properties. On the other hand,
      the actual protection for a weston_output is the minimum of the
      protection status of its attached heads.
      As a head's protection changes, the current protection of the output
      to which the head is attached is recomputed.
      
      This patch adds the support to keep track of the current
      content-protection for heads and the outputs.
      Signed-off-by: Ankit Nautiyal's avatarAnkit Nautiyal <ankit.k.nautiyal@intel.com>
      4f64ff8b
    • Ankit Nautiyal's avatar
      libweston: Add support to set content-protection for a weston_output · 2690a770
      Ankit Nautiyal authored
      For making an output secure, the content-protection should be set for
      each of head attached to that output. So whenever the protection for
      a weston_output is desired, it means that protection is desired for
      each of the weston_head attached to that weston_output.
      
      This patch introduces a new enum in libweston to represent the
      requested/current protection statuses, equivalent to the type enum
      defined by the weston-secure-output protocol. The new enum helps to
      extend the content-protection status and requests to libweston and
      the backends.
      This patch also adds a new member desired_protection to store the
      desired protection for an output in weston_output.
      Signed-off-by: Ankit Nautiyal's avatarAnkit Nautiyal <ankit.k.nautiyal@intel.com>
      2690a770
    • Scott Anderson's avatar
      protocol: Add content-protection protocol · 06aeb0ea
      Scott Anderson authored
      This protocol allows a client to ask the compositor to only allow it to
      be displayed on a "secure" output. This initial version of the protocol
      supports HDCP.
      
      This is loosely based on the chromium secure-output protocol [1].
      
      This protocol is mostly useful for closed system, where the client can
      trust the compositor, such as set-top boxes. This is not a way to
      implement any kind of Digital Rights Management on desktops. The
      compositor would be free to lie to the client, anyway.
      Signed-off-by: Scott Anderson's avatarScott Anderson <scott.anderson@collabora.com>
      Signed-off-by: Ankit Nautiyal's avatarAnkit Nautiyal <ankit.k.nautiyal@intel.com>
      
      [1]
      https://chromium.googlesource.com/chromium/src/+/master/third_party/wayland-protocols/unstable/secure-output/secure-output-unstable-v1.xml
      06aeb0ea
  5. 01 Jul, 2019 5 commits
  6. 28 Jun, 2019 1 commit
  7. 27 Jun, 2019 1 commit
  8. 26 Jun, 2019 19 commits
  9. 25 Jun, 2019 2 commits