Is there a tutorial that shows how to get HDR working with Ubuntu 22.04/Xorg/Nexus?
#16
(2023-02-12, 14:50)graysky Wrote: How are you detecting that the HDR is not triggered?

When I play the movie and press info button on my TV remote the TV will list the info of it's current output.
When running ppa build (w/ GBM) and playing a HDR movie the output is listed as "3840 x 2160p 4K 16:9 Dolby Atmos - TrueHD". Same movie played with kodi (nexus) build from source with GLES/GBM, and the info bar is displayed as  "3840 x 2160p 4K 16:9 HDR (HDR10) Dolby Atmos - TrueHD"
Also you can immediatly notice the much higher peak brightness setting that gets applied with HDR content.
Reply
#17
I have a samsung TV.  I will look for the info you discussed.  Can you share your "hacked" modification to LinuxRendererGL.cpp as well?  I wonder if this is a legit bug?
Need help programming a Streamzap remote?
Reply
#18
So the info button on my Samsung produces this output which does not change when playing a video or sitting on the Kodi GUI.  I compiled a fresh package with -DAPP_RENDER_SYSTEM=gles for this test.

Code:
3840x2160 / 60p Input Signal Plus
[UHD]
Need help programming a Streamzap remote?
Reply
#19
(2023-02-12, 07:24)yasij Wrote: Is our goal to get HDR passthrough to work to an HDR capable display, or to just get HDR videos to display without being washed out? If it's the latter, turn on tone mapping in the video settings for the HDR video. Kodi 20 has a few different tone mapping options. Hable is pretty good.

If you want HDR passthrough, you'll need to use the GBM backend of Kodi with GLES. The GL backend does not have the code to turn on HDR passthrough, only GLES does. The Xorg and Wayland backends do not support HDR passthrough. Xorg has no HDR support, and Wayland's is in progress and incomplete (I'm not talking about Kodi, I'm talking about in general.)

To get the GLES backend for kodi GBM, you'll have to compile it yourself as the PPA version uses the GL backend. You will have to compile it with the -DGBM_RENDER_SYSTEM=gles option. Then you'll have to run Kodi from a regular text tty, and not X11. Switch to a tty with ctrl-alt-F2, log in, and run kodi --windowing=gbm.

Well we tried that tone mapping and that is not all all like having real HDR passthrough, it is better then without it but nowhere near real HDR.

Neither he nor I are coders and when I look at that page you linked to, it says "This guide has been tested with Ubuntu 16.04.4 (Xenial) x86_64, 18.04 (Bionic) and 20.04 (Focal)."  But he is running Ubuntu 22.04 and anyway those instructions make no sense to him or I, it looks like they were written for coders.  Are there any simplified instructions that apply specifically to Ubuntu 22.04, or better yet, a shell script you can run that will build a version of Kodi Nexus with the GLES backend included?
Reply
#20
(2023-02-12, 15:41)ryback Wrote:
(2023-02-12, 14:50)graysky Wrote: How are you detecting that the HDR is not triggered?

When I play the movie and press info button on my TV remote the TV will list the info of it's current output.
When running ppa build (w/ GBM) and playing a HDR movie the output is listed as "3840 x 2160p 4K 16:9 Dolby Atmos - TrueHD". Same movie played with kodi (nexus) build from source with GLES/GBM, and the info bar is displayed as  "3840 x 2160p 4K 16:9 HDR (HDR10) Dolby Atmos - TrueHD"
Also you can immediatly notice the much higher peak brightness setting that gets applied with HDR content.

Is there any chance you could post some kind of guide on how you made it work?  It would be much appreciated!
Reply
#21
(2023-02-12, 12:53)ryback Wrote: No idea why GL renderer (LinuxRendererGL.cpp) doesn't include the same HDR passthrough as GLES (LinuxRendererGLES.cpp) does.

I actually wish that someone who can figure out how would submit this as an issue, especially if that would make standard Kodi support HDR passthrough.  As I see it, the real issue here is that the version of Kodi you get from the repository doesn't support HDR passthrough, and while those experienced in coding can (maybe) build a version that will work, it requires skills beyond those of the average user.  And please don't assume that all Linux users are coders; even old people like me can install and use Linux nowadays but that doesn't mean we know the first thing about coding.

Anyway I thought about submitting an issue to the bug tracker but suffice it to say that's not a user friendly thing at all.  You have to create a GitHub account (whyHuh) and then they want a bunch of information and then you find out that you can't post anyway because your brand new account has been flagged for some reason.  So I give up on that, but if anyone knows how to get the developers to add that missing code it would be much appreciated, even though it won't help in the short term.
Reply
#22
Coder or not, you will need to do some serious legwork to get Kodi on GBM running on a desktop system. You need to compile in GLES support if the distro isn't offering it. And you need to do some serious scripting to launch Kodi. That's something I would avoid, even as a coder.

The limitation to GLES is because embedded platforms were the first with HDR support. Desktop systems followed later. GL support is low priority, as GLES is functionally the same as far as I know.

HDR is not possible on X (this wont change as far as I see), and Wayland is "not there yet". Kodi is amongst the few pieces of software that can present an HDR image by avoiding both systems. Even worse for Wayland, applications are not allowed to manipulate the refresh rate (AFAIK). So framerate switching support is uncertain. Additionally, only on GBM is it possible for Kodi to make use of the hardware compositor.

I don't understand the reluctance against LE. It makes very little difference having to choose between Kodi and the desktop at startup or at login.
Reply
#23
(2023-02-13, 00:55)jawilljr Wrote: Yes it can be done.
Sigh. Were did I wrote that it can't be done? You can always hack around, but that's not something you do if you want your application to be packaged by distributions. See https://github.com/xbmc/xbmc/issues/20614. But please, stop with the OT.

I want to reiterate that setting up a lasting solution using GBM is not trivial. Have you even considered a dual boot solution?
Reply
#24
(2023-02-13, 01:58)jepsizofye Wrote: i will add you to my list of people not to help here.
THANK YOU!!!

(See, I did finally thank you for something!)
Reply
#25
(2023-02-13, 02:17)sarbes Wrote: I want to reiterate that setting up a lasting solution using GBM is not trivial. Have you even considered a dual boot solution?

You weren't replying to me but I would like to hear more about that, if you care to elaborate.
Reply
#26
For the discussion GLES vs. GL. Yes only the GLES implementation sets the SetHDR of the TV. Keep in mind when you hack that in: also the srcPrimaries need changing, as we obviously want to send BT2020 like primaries to the TV and not BT709 done from EGL.
First decide what functions / features you expect from a system. Then decide for the hardware. Don't waste your money on crap.
Reply
#27
(2023-02-13, 02:45)oldtvwatcher Wrote:
(2023-02-13, 02:17)sarbes Wrote: I want to reiterate that setting up a lasting solution using GBM is not trivial. Have you even considered a dual boot solution?

You weren't replying to me but I would like to hear more about that, if you care to elaborate.

I was replying to you. It is just a bit "noisy" in here, due to the amount of offtopic.

I do have both Windows and Linux installed. The bootloader allows me to select between them at boot. This can be done with LE as well. Install it on a separate drive (a 64gb SSD should suffice) and and configure the bootloader of the Ubuntu drive.
Reply
#28
There is a bit of off topic stuff in here.  Is this a summary of the salient points?

* Only kodi-gbm is capable of displaying HDR out-of-the-box
* For HDR content to be display by kodi-gbm, it must be compiled it with GLES rendering
Need help programming a Streamzap remote?
Reply
#29
Well I have been reading everything in this thread and my head is kind of spinning, but my understanding is it is the desktop that is the problem, and also as I understand it you have to compile kodi-gbm with GLES rendering.  So, let's say you started with Ubuntu 22.04 server, which has no desktop and presumably no Xorg.  How difficult would it be to compile kodi-gbm on that?  Just for grins I asked GhatGPT and it actually gave me an answer, of course chances are it's an incorrect answer.  I asked:
Quote:I have been reading the thread at https://forum.kodi.tv/showthread.php?tid=371952 and I would like to know how to how to compile kodi-gbm with GLES rendering on Ubuntu 22.04 server. I am not a Linux expert so I need the entire process explained step by step.
And it replied as follows:
Quote:Compiling Kodi with GLES rendering on Ubuntu 22.04 server can be a complex process and requires some basic knowledge of using the terminal and installing dependencies. Here is a step by step guide to help you get started:

    Update the package lists:

sudo apt update
sudo apt upgrade

    Install necessary dependencies:

sudo apt install -y build-essential pkg-config git cmake libavcodec-dev libavformat-dev libswscale-dev libavutil-dev libavfilter-dev libgles2-mesa-dev libegl1-mesa-dev

    Clone the Kodi source code repository:

git clone https://github.com/xbmc/xbmc.git

    Navigate to the cloned repository and create a build directory:

cd xbmc
mkdir build
cd build

    Configure the build:

cmake -D ENABLE_GLES=ON ..

    Build Kodi:

make -j $(nproc)

    Install Kodi:

sudo make install

This should install Kodi with GLES rendering on your Ubuntu 22.04 server. Keep in mind that this process may take a long time to complete, so be patient.

Note: The number of CPU cores available to build Kodi can be obtained by running nproc. This number should be passed as an argument to the make command to speed up the build process.
Of course I am curious about whether this would actually work, but don't have time to test it tonight.  One thing I wondered about was where it said cmake -D ENABLE_GLES=ON ..  - I didn't know what the .. meant so I asked
Quote:In the line "cmake -D ENABLE_GLES=ON .." what do the .. characters at the end mean?
And ChatGPT replied:
Quote:The ".." characters at the end of the cmake -D ENABLE_GLES=ON .. line in the previous response indicate that you are running the cmake command from the build directory and want to configure the build using the files located in the parent directory of the build directory.

The ".." characters represent the parent directory in Unix-like systems, and by using them, you are specifying that the CMakeLists.txt file for your project is located one level up from your current working directory (the build directory).

In other words, the line cmake -D ENABLE_GLES=ON .. runs the cmake command with the ENABLE_GLES option set to ON and specifies that the root of your project is one level above the current working directory.
It is interesting that you can ask questions like that and get responses with that level of detail, I am just wondering now if it's actually a valid response!  Anyway I just thought that was interesting enough to share, and see if anyone feels like commenting one way or another.
Reply
#30
The answer is correct. What that guy is obviously not knowing is what ENABLE_GLES actually does. The rest is just a bit of AI suger stating the obvious Tongue emphasizing on the two "dots". While a human a technical expert has a semantic meaning for "GLES", ChatGPT did not have.

In general: Yes, ChatGPT can replace a whole lot of hot-air-pump people out there :-)
First decide what functions / features you expect from a system. Then decide for the hardware. Don't waste your money on crap.
Reply

Logout Mark Read Team Forum Stats Members Help
Is there a tutorial that shows how to get HDR working with Ubuntu 22.04/Xorg/Nexus?0