[FernetMenta]

Looks to me that this "HDR support" only passes on HDR metadata to the display. Since GLES rendering is still on 8 bit textures you won't get 10 bit depth.
@fritsch is this correct?

[fritsch]

Yes - LoadPlane still has the 10 bit knowledge, but then it seems to all end up on a 8 bit plane: https://github.com/xbmc/xbmc/blob/master...S.cpp#L308
So the HDR is basically: Telling the TV to do HDR, staying on the BT2020 transfer function but only providing 8 bit output, which has the 10 bit imported values downscaled before.

Is that what you are also seeing?

Edit: Never Mind ... the visuals are only 8 bit ... to start with ... so I don't see how 10 bit should reach the TV here ...

[Schenckmeier]

I've been using fritsch's legendary tutorial for a number of years by using x11.
Can somebody help me with an appropriate /etc/systemd/system/kodi.service for using a compiled kodi with GBM+GLES?

[username145]

Yes - LoadPlane still has the 10 bit knowledge, but then it seems to all end up on a 8 bit plane: https://github.com/xbmc/xbmc/blob/master...S.cpp#L308
So the HDR is basically: Telling the TV to do HDR, staying on the BT2020 transfer function but only providing 8 bit output, which has the 10 bit imported values downscaled before.

Is that what you are also seeing?

Edit: Never Mind ... the visuals are only 8 bit ... to start with ... so I don't see how 10 bit should reach the TV here ...

Does this mean Kodi doesn't actually support HDR on linux? Is this a bug and might there be a Github issue for it? I have not been able to find one.

Is LibreELEC any different in this area?

[jawilljr]

Yes - LoadPlane still has the 10 bit knowledge, but then it seems to all end up on a 8 bit plane: https://github.com/xbmc/xbmc/blob/master...S.cpp#L308
So the HDR is basically: Telling the TV to do HDR, staying on the BT2020 transfer function but only providing 8 bit output, which has the 10 bit imported values downscaled before.

Is that what you are also seeing?

Edit: Never Mind ... the visuals are only 8 bit ... to start with ... so I don't see how 10 bit should reach the TV here ...

Does this mean Kodi doesn't actually support HDR on linux? Is this a bug and might there be a Github issue for it? I have not been able to find one.

Is LibreELEC any different in this area?

Red Hat's Display/HDR Hackfest Scheduled For April

Linux probably won't see any real HDR support for another year or two.

Wayland's Weston 11.0 Released With HDR Display

Right now it is a work in progress.

[sarbes]

No! Kodi does support HDR. There is no bug.

The classic GLES renderer is operating on 8 bit textures with SDR output (still good for software decoding legacy formats). The renderer with DMABUF import takes unaltered 10 bit textures but can only output SDR (good if you need GPU tonemapping for an SDR display). And there is the hardware based approach, where the video is passed directly to the scanout device, never touching the GPU (this is the "HDR way").

If you are not using the latter on your low-end device for high resolution videos, you have other problems besides "HDR not working".

But this discussion is far away from what OP wants to achieve. Could you please take this elsewhere.

Edit: this was aimed at the post before the last one.

[sarbes]

Yes - LoadPlane still has the 10 bit knowledge, but then it seems to all end up on a 8 bit plane: https://github.com/xbmc/xbmc/blob/master...S.cpp#L308
So the HDR is basically: Telling the TV to do HDR, staying on the BT2020 transfer function but only providing 8 bit output, which has the 10 bit imported values downscaled before.

Is that what you are also seeing?

Edit: Never Mind ... the visuals are only 8 bit ... to start with ... so I don't see how 10 bit should reach the TV here ...

Does this mean Kodi doesn't actually support HDR on linux? Is this a bug and might there be a Github issue for it? I have not been able to find one.

Is LibreELEC any different in this area?

Red Hat's Display/HDR Hackfest Scheduled For April

Linux probably won't see any real HDR support for another year or two.

Wayland's Weston 11.0 Released With HDR Display

Right now it is a work in progress.

Please, do read the articles you are posting. Linux does support "real HDR" today. How else would Kodi be able to display HDR videos?

You seem to confuse Wayland with Linux.

[FernetMenta]

And there is the hardware based approach, where the video is passed directly to the scanout device, never touching the GPU (this is the "HDR way").

Would you mind elaborating on the hw specs required to get the hardware based approach. You don't get the "HDR way" on an average Intel or AMD system, do you?

[sarbes]

Oh yes, you can get HDR on recentish Intel/AMD systems. According to LibreElec documentation, support starts with the gen 7 series on Intel. It was more of a driver thing which prevented the systems from being utilized, but this changed in the last two years.

But I'm not too involved with all the specifics of our rendering pipeline. I don't even own HDR movies, despite having ported the tonemapping from DX to GL .

In general, you want to avoid the GPU if you can, as many are just not powerful enough to compose a 4k GUI onto the video. So for playback, the decoded frames are passed directly to the scanout engine, which composes the GUI and video plane. On Linux you need access to the DRM which is blocked by X/Wayland on classic desktop systems.

Oh and I think you can get HDR with the GLES renderer. It just doesn't make much sense as said above and we don't tonemap the GUI.

[fritsch]

Looks like it: https://github.com/xbmc/xbmc/blob/master...xt.cpp#L37
Okay, so at the end it works with two planes: https://github.com/xbmc/xbmc/blob/12e809...s.cpp#L212

And GLES is not processing the video data.

[sarbes]

The DRM magic is going on in here: https://github.com/xbmc/xbmc/blob/master...MPRIME.cpp. I don't think we can pass software decoded planes right now. This would be a great opportunity to further decouple the GUI from video playback.

[FernetMenta]

As far I understand the current code DRM rendering requires DRMPRIME video codec which is only available on platforms that provide a V4L2 video decoder. Intel and AMD don't provide a v4l2 decoder, do they?

[wsnipex]

Looking at LE, they add v4l2 patches to ffmpeg: https://github.com/LibreELEC/LibreELEC.t...rime.patch

[username145]

So has anyone been able to get proper HDR on an intel machine, without having to go the LibreELEC route?

Guessing I would need to compile with GLES, along with these patches?

https://github.com/LibreELEC/LibreELEC.t...ime-filter
https://github.com/LibreELEC/LibreELEC.t...2-drmprime

What about this one? Doesn't seem to apply cleanly when I also include the v4l2-drmprime patch: https://github.com/LibreELEC/LibreELEC.t...l2-request

I would *love* it if somebody more knowledgeable than myself could create a PKGBUILD based on this, for example: https://aur.archlinux.org/packages/kodi-nexus-git

Guessing it will all be working properly with the next Kodi major release, but that's probably a year or so away.

[FernetMenta]

There is no proper HDR in Intel.

• With the GLES path you only faked HDR with 8 bit. That is even worse than no HDR at all.
  
• Intel has no driver for v4l2, hence no drmprime decoder. The mentioned LE patch does no change this.
  

There is some ongoing work to map VAAPI surfaced to drm: https://github.com/xbmc/xbmc/pull/19142 Leaves the question open if Intel video driver on Linux supports reading out video plane separately.

EDIT: Be my guest and proof me wrong by posting a debug log which shows that an Intel system uses drmprime decoder.