Linux is not the issue here but ARM processor as OP said. First DRM library for ARM came only earlier this year so finally I am able to play DRM content on Raspberry Pi 4 in Chromium but I am not going to because chromium is painfully slow and plugin maintainers have figured out how to play Netflix in Kodi.

edit: DRM library still doesn't get to "fully FLOSSed"

So then Netflix et al.'s requirement of Windows or macOS in order to play high definition video is purely artificial on x86?

Last time I checked (a few months ago) they didn't even support Chrome (either Windows or Mac) for UHD, they required Safari, Edge or their own Windows app.

The UHD restriction is not a technical one. Content producers and the rest of the media industry has strict requirements about streaming. UHD content uses proprietary DRM systems from Microsoft and Apple that are considered more secure than WideVine, which is why those browsers are permitted to watch 4k.

You can't watch UHD content on Edge for Linux, for example, because the necessary DRM isn't implemented.

So does this mean that the DRM is still at least partially implemented in software?

I also seem to remember that Netflix on Windows (don't know about mac) also requires hardware decoding support for HEVC1 (or whatever their codec is). I never got it to work with an intel GPU (8th gen udh630 — supposed to support it) but it worked with an AMD GPU.

Partially, for sure. However, even with hardware support you need some kind of licensed (signed?) binary interface with the DRM hardware to ensure that nobody is decoding a hundred Netflix streams at a time.

I don't know a lot about how everything works below the hood, but you can probably find some of the details on the Microsoft website [0] if you want.

[0]: https://www.microsoft.com/playready/

Although, you used to be able to watch it in Windows Edge in Wine.

Between the video decoder and the screen is the display server (e.g. Xorg or GNOME Shell) which is untrusted.

This wasn't my understanding. If the decoding happens in hardware, I wouldn't have expected the decoded video to be passed back to the display server to be sent back again to the GPU and out to the screen.

My understanding was that there was some kind of compositing going on, in hardware, where the display server would tell the GPU to display the output between some coordinates, but the server itself wouldn't know what the actual output would be.

Here is the libva documentation which seems to support this: http://intel.github.io/libva/group__api__prot.html