We're hiring!

Why HDCP support in Weston is a good thing

Pekka Paalanen avatar

Pekka Paalanen
October 03, 2019

Share this post:

First I'll reiterate what HDCP is and why supporting it cannot take away any freedoms. Then I'll give some background on Weston's ideology and justify supporting HDCP in Weston with both economical and technical arguments. While I do work for Collabora, these are my personal opinions.


HDCP is a specification with multiple versions (e.g. HDCP 2.2) which among other things define encryption of the video data going through some standard cables like HDMI. The aim of HDCP is to authenticate the video sink (e.g. a monitor or a TV) with the hopes that an authenticated sink cannot leak the video content where it is not intended. At least, that is the theory. HDCP is essentially a hardware feature. You flip a switch in hardware and it attempts to enable HDCP secured link with the video sink devices. The hardware tells you if it succeeded or not. That is all. There is no change at all in how software (e.g. Weston) will drive the display.

As already explained by Daniel Stone a long time ago, supporting HDCP in a free open-source software (FOSS) project cannot take any user rights or freedoms away. It cannot restrict what you can do. It is just a way to make use of a hardware feature when you choose to do so. Otherwise it will just sit there doing nothing.

Only if your whole operating system (OS) has already been locked down and left you outside, only then could HDCP actually enforce someone else's policy of Digital Rights Management onto you against your will. On the other hand, you could lock down your own OS according to your own policies to prevent others from stealing your content. Want to lend a laptop to someone to watch some animations you made, for instance? Maybe a professional photographer wants to let people watch the drafts in their own TV without fear of them stealing all the pictures? These are examples I made up.

The Wayland protocol extension for HDCP is also very simple: the client (application) tells the compositor that it wants its content protected, and the compositor replies yes or no. The compositor is completely free to lie about protection, and there is no way for the client to know it was lied to. Both the HDCP design in general and the Wayland protocol extension presume the compositor (display server) is trusted.

HDCP support in Weston gives you the freedom to enable it if you want it.

Weston's ideology

Weston's license is MIT. Why is it not GPL or LGPL?

I was not participating in the project yet when the license was chosen, but I agree with it. I, with my upstream Weston maintainer hat on, want Weston to be used by companies, including in their shipping products. MIT license makes that very easy for the companies. GNU GPL or LGPL could make it hard, especially GPL v3+ which many companies just steer very clear of. This is the reality outside of our control, however sad you might think it is. Forced with a trade-off not unique to the Weston project, it chose to favour adoption over strong copyleft, as did other open source projects before, Xorg and Mesa for example.

When Weston is used in shipping products, it is much more likely that companies will provide resources to improve Weston also in upstream. Even if companies did not directly do that, they might hire others like Collabora to work on Weston, and then Collabora can redirect some of that revenue back to Weston upstream development. That will likely benefit also other users of Weston, even the private home users and hobbyists. It is all the same reasons why hardware drivers should go into the Linux kernel upstream, just in much smaller scale.

The above paragraph is not speculation. It is happening, and it has already allowed significant investments from e.g. Collabora into Weston upstream over the past years.

HDCP support in Weston is but one more reason to consider using Weston in shipping products. It is indeed unlikely that HDCP support would be useful under a normal FOSS OS. HDCP support is there to attract more resources around Weston to hopefully benefit everyone. Who knows, maybe someone will figure out a use for HDCP that does not involve attempting to enforce the Digital Rights Management policies of major media companies.

Technical reasons

Weston is a reference Wayland compositor. As such, it is used to test and prove new technologies, ideas, protocol extensions, APIs, and so on. Some of that is downstream forks only, some of it ends up in Weston upstream.

Above the upstreaming of a hardware driver into the Linux kernel was mentioned as a highly desireable thing from both user and vendor perspectives. Sometimes the hardware has features that the existing kernel-userspace programming interfaces (UAPI) do not support. In that case, new UAPI must be introduced. HDCP 2.2 is a feature that requires a small UAPI addition.

The problem with UAPI is that once it has been released with a Linux kernel and programs using that UAPI have appeared, it cannot be broken or removed. Ever. The kernel has an extremely strict policy on this: if upgrading the kernel breaks a program, the kernel is at fault. It does not matter if the program is misusing the kernel, works by luck, or is plain incorrect in its UAPI usage, but the program used to work and then it does not work anymore, the kernel is at fault. This makes it really important to get UAPI as right as possible from the start, as it will be a maintenance cost forevermore.

Therefore the Linux Direct Rendering Manager (DRM) subsystem has a rule: all new UAPI must come with real userspace consumers. A test program is not enough.

Weston can be used to prove the suitability of new Linux UAPI. This is a big part of why HDCP support is coming to Weston. The HDCP support reviews with Weston have already induced changes to the proposed UAPI by asking for an event for HDCP status changes.

Weston is also a Wayland compositor where one can implement and prove Wayland protocol extensions, similar to how one proves Linux UAPI. The HDCP support comes with a Wayland protocol extension, so that Wayland clients (end user applications) could make use of HDCP. One can even argue that proving the Linux UAPI for HDCP will not be complete without the Wayland protocol extension, because a display server cannot guess which content actually needs protection and Wayland is here now with some fundamental differences compared to e.g. X11 protocol.


By the release of Weston 7.0.0, the Wayland protocol extension support for HDCP has alrady landed in Weston upstream, but the HDCP UAPI usage has not. This means that while Weston 7.0.0 is internally prepared to handle protected content, the DRM-backend will not yet attempt to actually enable HDCP in hardware. The remaining patches were tracked in Weston MR 48 and have landed post 7.0.0 release.

HDCP support in Weston cannot take away anyone's freedoms. It does not allow building Digital Rights Managed video players that could reliably work against your will on your desktop, you can simply hack Weston to lie to them. You could even make the lying a feature and submit it to Weston upstream, if it meets the code quality requirements it will get merged. HDCP support adds the freedom to turn on HDCP encryption if you want to.

Technical and economical reasons are the major points why HDCP support is coming to Weston. Making Weston more attractive to companies will provide more resources to Weston upstream work that will benefit everyone in the long run.

It is true, that this work is adding features and protocol that could be used in non-free shipping products that are designed to restrict users' capabilities. Specifically supporting technologies that are used in Digital Rights Management could be seen as endorsement, even though it has no such intent. However, such non-free products are going to be made with or without Weston's support, and I think in this case the benefits to the Weston project outweigh the negative impact.

Comments (1)

  1. Jesse:
    Oct 10, 2019 at 04:15 PM

    The problem here is not the ability to turn on HDCP but rather the rest of the ecosystem. As you say, the ability to turn HDCP on or off on the transmitter can only add to the user's ability to use their hardware. The problem is that HDCP is completely useless without a user-hostile, locked-down device on the other side of the link. Your own examples demonstrate that: If the display device is capable of receiving HDCP-encrypted AV streams but doesn't prevent its owner from recording the decrypted animations or photos then enabling HDCP at the link level served no purpose beyond complicating the display system. (And in fact this is more-or-less the case now since HDCP-stripping hardware is readily available to the public.)

    Reply to this comment

    Reply to this comment

Add a Comment

Allowed tags: <b><i><br>Add a new comment:

Search the newsroom

Latest Blog Posts

Using syzkaller, part 4: Driver fuzzing


Syzkaller is much needed tool for Linux kernel testing and debugging. With some work, it can also be enhanced to find bugs in specific drivers,…

Cross building Rust GStreamer plugins for the Raspberry Pi


Previously, we discussed about how Rust can be a great language for embedded programming. In this article, we'll explain an easy setup to…

Generating MPEG-DASH streams for Open Source adaptive streaming with GStreamer


Adaptive streaming is a technique to provide flexibility and scalability by offering variable bit-rate streams to the client. Here's a quick…

Bifrost meets GNOME: Onward & upward to zero graphics blobs


With only free software, a Mali G31 chip can now run Wayland compositors with zero-copy graphics, including GNOME 3. We can run every scene…

Using regmaps to make Linux drivers more generic


Device drivers can support more revisions and SoC platforms by abstracting away specific hardware interface layouts. Let's examine a specific…

Cross-compiling with gst-build and GStreamer


gst-build is one of the main build systems used by the community to develop the GStreamer platform. In my last blog post, I presented gst-build…

Open Since 2005 logo

We use cookies on this website to ensure that you get the best experience. By continuing to use this website you are consenting to the use of these cookies. To find out more please follow this link.

Collabora Ltd © 2005-2020. All rights reserved. Privacy Notice. Sitemap.