Guest - Testers are needed for the reworked CDateTime core component. See... https://forum.kodi.tv/showthread.php?tid=378981 (September 29) x
v20 Which -DAPP_RENDER_SYSTEM value to choose for correct HDR support on kodi-gbm
#16
Progress... I was running the 6.1-lts kernel but switched to 6.6-mainline.  I also update mesa to 23.3.1.  Now I consistently get HDR detection with Omega+that patch but there is a heavy green tint on the HDR content.  Currently compiling Omega without the patch, just HEAD.

EDIT: compiling without any extra patches still causes the green tint to be displayed on the test clip.  Similar to this post.
Need help programming a Streamzap remote?
Reply
#17
I opened https://github.com/xbmc/xbmc/issues/24269
Need help programming a Streamzap remote?
Reply
#18
Why do you think a different broken behaviour from a kernel upgrade is suddenly a kodi issue?
First decide what functions / features you expect from a system. Then decide for the hardware. Don't waste your money on crap.
Reply
#19
From the posted log:
BT2020_YCC <- is used. Please compare that with an intel setup. Might be that the other HDR only works, cause "RGB" is output, e.g. BT2020RGB. Which would also show again certain downsides of the current implementation which is in no way ready for a yuvscanout when doing GLES render path. If intel really uses BT2020RGB, then yeah the picture is already converted at least once ... not sure how "accurate" the pseudo HDR then will be. I would just use tonemapping for the time being on those platforms.
First decide what functions / features you expect from a system. Then decide for the hardware. Don't waste your money on crap.
Reply
#20
(2023-12-18, 10:27)wsnipex Wrote: you might want to file a bug report with AMD/mesa

I opened Mesa #10331

Thanks for the replies, all!
Need help programming a Streamzap remote?
Reply

Logout Mark Read Team Forum Stats Members Help
Which -DAPP_RENDER_SYSTEM value to choose for correct HDR support on kodi-gbm0