Recently, Sean Paul from Google's ChromeOS team, submitted a patch series to enable HDCP support for the Intel display driver. HDCP - or High-bandwidth Digital Content Protection to its parents - is used to encrypt content over HDMI and DisplayPort links, which can only be decoded by trusted devices.

HDCP is typically used to protect high-quality content. A source device will try to negotiate a HDCP link with its downstream receiver such as your TV or a frame-capture device. If a HDCP link can be negotiated, the pixel content will be encrypted over the wire and decrypted by the trusted downstream device. If a HDCP link cannot be successfully negotiated and pixel data remains unencrypted, the typical behaviour is to fall back to a lower resolution, or quality that is in some way less desirable to capture.

This is a form of copy protection usually lumped in with Digital Rights Management, something the open source community is often jumpy about. Most of the sound and fury typically comes from people mixing up the acronym with the kernel's display management framework called the Direct Rendering Manager; this is thus the first known upstream submission of DRM for DRM.

Regardless, there is no reason for the open-source community to worry at all.

HDCP support is implemented almost entirely in the hardware. Rather than adding a mandatory encryption layer for content, the HDCP kernel support is dormant unless userspace explicitly requests an encrypted link. It then attempts to enable encryption in the hardware and informs userspace of the result. So there's the first out: if you don't want to use HDCP, then don't enable it! The kernel doesn't force anything on an unwilling userspace. Sinks (such as TVs) cannot demand an upstream link provide HDCP, either.

HDCP support is also only over the wire, not on your device. A common misconception is that DRM means that the pixel frames coming from your video decoder are encrypted. Not so: all content is completely unencrypted locally, with encryption only occurring at the very last step before the stream of pixels becomes a stream of physical electrons on a wire.

Technically speaking, this means that all framebuffers presented to DRM/KMS, are provided unencrypted; if GPU composition is involved, the buffers presented through OpenGL or Vulkan for composition are also unencrypted, as is the GPU output. These unencrypted buffers are placed on a plane, which is mixed into a single CRTC's unencrypted output by the display controller. Only once the final CRTC pixel stream makes it to the encoder stage (where it is transformed from pixel content into a stream of DisplayPort/HDMI signals) does the encryption occur. By this stage, the content is already unrecognisable, as it has been prepared for electrical transmission by 8/10b encoding, potentially cut into DisplayPort packets, and so on.

HDCP is only downstream facing: it allows your computer to trust that the device it has been plugged into is trusted by the HDCP certification authority, and nothing more. It does not reduce user freedom, or impose any additional limitations on device usage.

The only way for a secure decode pipeline to be implemented, is a complete hardware-backed verified boot sequence. In this, the hardware itself must be a vital link in the content pipeline (holding, e.g., decryption keys for content), and it must be able to attest that the device is only running trusted code which is unwilling to leak content. There are a number of ways to boil that particular ocean, but having your display hardware enable over-the-wire encryption is pretty much irrelevant.

In short, if you already run your own code on a free device, HDCP is an irrelevance and does not reduce freedom in any way.