WIP: DRM HDR support

[LaserEyess]

This is a rebase of #8648 and #8456 and supersedes them. It is not finished, so please do not spam this PR with "when will this be merged?", it won't be for a while.

Some TODOS:

• Is the way HDR is deactivated correct? (apparently)
• --gpu-api=vulkan?
• --vo=gpu-next?
• Automatically set --drm-format= if needed
• Automatically set --target-trc, etc. like is done on windows
• Get someone to review the drm atomic stuff
• Make sure the colorspace being passed in is correct

@evelikov @emersion I believe I addressed most (all?) of your comments from the previous PRs, but I am a complete novice at drm so any drive-bys would be appreciated.

For others testing, the following command (in a tty) will work:

mpv --vo=gpu --gpu-api=opengl --gpu-context=drm $my_hdr_file

DRM metadata should be automatically sent.

Closes #8219

[philipl]

For the record, this can't be used with vulkan because Vulkan takes ownership and you can't call the necessary DRM methods from underneath it. The only way is to use the native Vulkan mechanism to pass HDR state which is only implemented in amdvlk, and therefore not helpful.

[patrakov]

I have tested this on a very old GPU, Mesa Intel(R) HD Graphics 4600 (HSW GT2). It, surprisingly, can send the correct HDR metadata, but the playback via --vo=gpu is something like 1 frame per second. --vo=drm plays the same file smoothly, but without HDR metadata. Could you please add support for --vo=drm?

[patrakov]

Forget that. I added --hdr-compute-peak=no and the playback is smooth.

[LaserEyess]

There's still some infrastructure required to get the correct HDR data sent to the screen. Right now that's not being done at all, it's sending image metadata but not HDR metadata. That being said, it can be added to --vo=drm, but you likely don't want to use that as that's a software rendered VO and it's strictly slower (with far less features) than --vo=gpu{,-next}

[patrakov]

you likely don't want to use that as that's a software rendered VO and it's strictly slower (with far less features) than --vo=gpu{,-next}

Well, this is false in my case. Does Haswell support hardware-accelerated OpenGL for 10bpc formats? For some unknown reason, --hdr-compute-peak=yes (which is the default) causes a lot of slowdown. Is this computation supposed to happen on the CPU or the GPU? Is it skipped with --vo=drm?

[LaserEyess]

It's not false, it's the difference of rendering on the CPU vs. rendering on the GPU. The reason --vo=gpu is slower for you, specifically, is due to a bug with intel's drivers, see #8981. The reason --vo=drm works better is because it's skipping that function, the CPU renderer doesn't implement it among many, many other features that --vo=gpu implements.

[LaserEyess]

Quick rebase for the DRM changes, it compiles but I didn't check if it still works. No new comments addressed

[patrakov]

Just a warning - this branch broke for me. It worked before, now it doesn't switch the monitor to the HDR mode. I cannot say precisely when exactly it broke, because of the force-pushing that prevents the bisection.

[patrakov]

Actually I do have the old commits, so:

• 248a7d0 works
• 16d0be8 doesn't

[LaserEyess]

I'll try and work on this some more this week, at least to get it back to working status again.

[TheGreatMcPain]

I guess this doesn't work on Nvidia yet? I've got a GTX1050 (driver version 530.41.03) and a GP27U monitor.

My monitor doesn't switch to HDR on the latest version of this branch as well as commit 16d0be8.

I did try with Nouveau, but it doesn't work due to Nouveau not having DRM atomic support.

My guess is that the nvidia-drm module doesn't have HDR implemented yet.

[LaserEyess]

nvidia is unlikely to work for anything drm related until their driver is merged upstream.

[aloisklink]

nvidia is unlikely to work for anything drm related until their driver is merged upstream.

I had a look into this a few weeks ago and I can confirm. mpv --vo=gpu --gpu-api=opengl --gpu-context=drm doesn't even work for Nvidia blob drivers on the master branch for SDR, due to libdrm's drmModeGetResources() throwing an ENOTSUP error.

Edit: the error message is [vo/gpu/opengl] Cannot retrieve DRM resources: Operation not supported, for anybody using a search engine.

Now that their blob drivers are partially open-source (see https://github.com/NVIDIA/open-gpu-kernel-modules/tree/main/kernel-open/nvidia-drm), it might be possible to get DRM in SDR working at least, (there's already a draft MR for libdrm, see https://gitlab.freedesktop.org/mesa/drm/-/merge_requests/238), but I don't even know if their driver supports HDR (it looks like their driver at least outputs a hdr_output_metadata).

[TheGreatMcPain]

I should probably clarify. The HDR videos I've tried do play in SDR using nvidia's DRM module.

The monitor just doesn't switch to HDR.

[Randrianasulu]

I have stupid question: does mpv's code use any of those DRM lease (from X) protocols?

https://cgit.freedesktop.org/~keithp/kmscube/?h=drm-lease

I ask because I have hard time understanding how windowed mode with HDR content should behave .... Tonemapped to SDR as usual, with switching to fullscreen drm (gles?) mode with metadata output to connector?

edit: it seems to be in xrandr 1.6 ...

https://stackoverflow.com/questions/72357389/is-it-possible-on-linux-to-run-a-drm-app-that-takes-over-the-screen-while-the-x

Edit 2:
https://haagch.frickel.club/#!drmlease.md

====
Basic overview

HMDs and potential other nonstandard display hardware like apple touchbar displays are hardcoded (by EDID data) in the kernel to have a property called non-desktop.

Displays with the non-desktop property will be advertised as disconnected by X.org, which will cause the usual desktop configuration tools to ignore these displays, though it is still possible to enable them, set modes etc. with tools like xrandr.

Applications that want to render to non-desktop displays (e.g. SteamVR compositor) use the Vulkan extension VK_EXT_direct_mode_display (optionally with EXT_acquire_xlib_display) to acquire access to the display through a drm-lease. Then the application can render directly to the display and bypass X.org, desktop compositors, window managers, ...

In X.org the non-desktop property can be temporarily overwritten at runtime:

xrandr --output HDMI-A-0 --set non-desktop 0

After this command the HMD display will be recognized by X as a newly connected standard display which can be enabled and managed with monitor configuration utilities.

Likewise the property can be enabled:

xrandr --output HDMI-A-0 --set non-desktop 1

This command even works on currently enabled displays and will cause X.org to advertise an event as if the display was manually disconnected.

It can be used on any display, even those not tagged as non-display by the kernel, so direct mode can be potentially used on HMDs that have not been added to the kernel.

====

[Randrianasulu]

Also possibly related?

https://patchwork.freedesktop.org/series/111864/
"Enable Colorspace connector property in amdgpu
Submitted by Harry Wentland on Dec. 12, 2022, 6:21 p.m."

found via KODI's bugtracker on BT2020 support on Intel:

xbmc/xbmc#21845

[quietvoid]

Also possibly related?

https://patchwork.freedesktop.org/series/111864/ "Enable Colorspace connector property in amdgpu Submitted by Harry Wentland on Dec. 12, 2022, 6:21 p.m."

Yes. It'll be necessary for proper HDR output.
Intel already supports it but AMD doesn't yet.

[patrakov]

I should probably clarify. The HDR videos I've tried do play in SDR using nvidia's DRM module.

Could you please verify whether an older commit (248a7d0) works? If it does, the breakage is likely the same as on Intel.

[TheGreatMcPain]

I should probably clarify. The HDR videos I've tried do play in SDR using nvidia's DRM module.

Could you please verify whether an older commit (248a7d0) works? If it does, the breakage is likely the same as on Intel.

Yes, I've tried both (248a7d0) and the latest version of the branch. They both play videos just fine via nvidia-drm, but my monitor won't switch to HDR.

(I may have forgotten to proof read my previous comment, because it looks like I wrote the wrong hash.)

[LaserEyess]

I have stupid question: does mpv's code use any of those DRM lease (from X) protocols?

Nothing about Xorg or Wayland is relevant here, nothing. And it never will be, so any progress you see about Wayland and HDR is completely separate from this PR. This PR is not required for mpv to support any eventual Wayland HDR, either.

Could you please verify whether an older commit (248a7d0) works? If it does, the breakage is likely the same as on Intel.

My rebase is still untested. There was a DRM refactor that changed how DRM atomic stuff worked. The next steps in this PR are to do the following:

1. Refactor context_drm_egl.c to work with setting up plane properties in reconfig, and not init
2. Refactor HDR blob creation to work in reconfig, and setting up SDR blobs in init/uninit
3. Using actual metadata so that e.g. XRGB2101010 is automatically selected when necessary

If you don't know what these mean then please do not comment on this PR. I apologize for being delinquent with it but it's just not ready yet, so you will not be able to test it.

Edit: Another point, that I'd really like to stress, nvidia will never be supported, so if you have an nvidia GPU and this doesn't work then that sucks but you'll have to take it up with them. This will be tested with intel and AMD which have usable, upstreamed drivers.

[inodentry]

Hey, I'd just like to chime in to say that I really really appreciate the work you are doing. <3

We have a home server / media center PC, connected to a 4K HDR OLED TV, and switching from kodi to mpv would be a great improvement to our home media experience, for watching HDR movies. If there is anything I could test or otherwise help with, please let me know!

[oscarbg]

Curious if somebody tested with 545.xx driver from Nvidia.. it should work?

[llyyr]

There's a cleaner solution here for HDR passthrough on Linux through gamescope.

gamescope --hdr-enabled -- mpv --target-colorspace-hint --fs [video] should allow HDR passthrough on any gpu that gamescope supports.

[John-Gee]

There's a cleaner solution here for HDR passthrough on Linux through gamescope.

gamescope --hdr-enabled -- mpv --target-colorspace-hint --fs [video] should allow HDR passthrough on any gpu that gamescope supports.

Don't you need something like this first: https://github.com/Zamundaaa/VK_hdr_layer/tree/work/frog-protocol ?

[misyltoad]

No, Gamescope WSI layer shipped with Gamescope already does that

[LaserEyess]

Giving up on this. I learned a lot about DRM, but HDR is still a mystery to me and I don't have the time to learn it. For anyone wanting to pick this up, the next steps are

1. rebase this
2. Refactor context_drm_egl.c to work with setting up plane properties in reconfig, and not init
3. Refactor HDR blob creation to work in reconfig, and setting up SDR blobs in init/uninit
4. Using actual metadata so that e.g. XRGB2101010 is automatically selected when necessary
5. ???
6. HDR works (maybe)

[John-Gee]

No, Gamescope WSI layer shipped with Gamescope already does that

Thank you for this answer and your work on HDR!

[John-Gee]

No, Gamescope WSI layer shipped with Gamescope already does that

Actually, can I use this with current Plasma 5 or does it require the future Plasma 6? I'm asking because running it on 5 does not seem to work. Is there a better wayland compositor for mpv to work properly?

Thanks!