Dolby Vision for Minix U22X-J (Max) and Ugoos AM6+

I’m pretty sure the correct if statement is:

if [ -e /sys/module/amdolby_vision/parameters/dolby_vision_wait_delay ]
then
    # Set the parameter to 16
    echo 16 > /sys/module/amdolby_vision/parameters/dolby_vision_wait_delay
    echo "Parameter set to 16."
else
    echo "File not found: /sys/module/amdolby_vision/parameters/dolby_vision_wait_delay"
fi

You just need to check if it exists, not the type of file. Also there’s an extra semi colon that shouldn’t be there.

Anyone want to run this command and output what’s returned?
modinfo amdolby_vision
(might be dovi instead)

Really hoping my AM6B+ arrives soon LOL

2 Likes
CoreELEC:~ # lsmod
Module                  Size  Used by
hci_uart               94208  1
btbcm                  16384  1 hci_uart
btqca                  16384  1 hci_uart
btintel                20480  1 hci_uart
ir_rc6_decoder         16384  0
ir_nec_decoder         16384  0
ir_lirc_codec          16384  0
lirc_dev               24576  1 ir_lirc_codec
meson_ir               16384  0
rc_core                32768  6 ir_rc6_decoder,ir_nec_decoder,ir_lirc_codec,meson_ir,lirc_dev
8021q                  28672  0
bluetooth             524288  27 hci_uart,btintel,btqca,btbcm
dhd                  1708032  0
dovi                  929792  0
nfsd                  299008  5
exportfs               16384  1 nfsd
nfs_acl                16384  1 nfsd
mali_kbase            454656  3
wireguard             151552  0
ip6_udp_tunnel         16384  1 wireguard
udp_tunnel             16384  1 wireguard
wifi_dummy             16384  0
amvdec_vp9            131072  0
amvdec_av1            155648  0
amvdec_vc1             65536  0
amvdec_real            40960  0
amvdec_ports          147456  0
videobuf2_dma_contig    20480  1 amvdec_ports
v4l2_mem2mem           28672  1 amvdec_ports
videobuf2_memops       16384  1 videobuf2_dma_contig
videobuf2_v4l2         24576  2 amvdec_ports,v4l2_mem2mem
videobuf2_core         45056  3 amvdec_ports,v4l2_mem2mem,videobuf2_v4l2
v4l2_common            16384  1 amvdec_ports
amvdec_mpeg4           65536  0
amvdec_mpeg12         114688  0
amvdec_mmpeg4          45056  0
amvdec_mmpeg12         49152  0
amvdec_mmjpeg          28672  0
amvdec_mjpeg           40960  0
amvdec_mh264          176128  0
amvdec_h265           159744  0
amvdec_h264mvc         57344  0
amvdec_h264           151552  0
amvdec_mavs            53248  0
amvdec_avs             73728  0
amvdec_avs2           212992  0
stream_input          176128  13 amvdec_h265,amvdec_mavs,amvdec_mh264,amvdec_h264mvc,amvdec_av1,amvdec_ports,amvdec_real,amvdec_vp9,amvdec_h264,amvdec_avs2,amvdec_mpeg12,amvdec_avs,amvdec_mmpeg12
decoder_common        221184  19 amvdec_h265,amvdec_mavs,amvdec_mjpeg,amvdec_mh264,amvdec_mmpeg4,amvdec_h264mvc,amvdec_av1,amvdec_mmjpeg,amvdec_ports,amvdec_real,stream_input,amvdec_vp9,amvdec_h264,amvdec_avs2,amvdec_mpeg12,amvdec_avs,amvdec_vc1,amvdec_mmpeg12,amvdec_mpeg4
firmware               24576  19 amvdec_h265,amvdec_mavs,amvdec_mjpeg,amvdec_mh264,amvdec_mmpeg4,amvdec_h264mvc,amvdec_av1,amvdec_mmjpeg,decoder_common,amvdec_real,stream_input,amvdec_vp9,amvdec_h264,amvdec_avs2,amvdec_mpeg12,amvdec_avs,amvdec_vc1,amvdec_mmpeg12,amvdec_mpeg4
media_clock            45056  17 amvdec_h265,amvdec_mavs,amvdec_mh264,amvdec_mmpeg4,amvdec_av1,amvdec_mmjpeg,decoder_common,amvdec_ports,firmware,stream_input,amvdec_vp9,amvdec_h264,amvdec_avs2,amvdec_mpeg12,amvdec_avs,amvdec_vc1,amvdec_mpeg4
video_framerate_adapter    16384  1 decoder_common
amlvideodri            20480  0
videobuf_res           16384  1 amlvideodri
videobuf_core          28672  2 amlvideodri,videobuf_res
videodev              208896  6 amlvideodri,v4l2_common,amvdec_ports,videobuf2_core,v4l2_mem2mem,videobuf2_v4l2
media                  45056  1 videodev
fuse                  106496  1
fbcon                  45056  0
bitblit                16384  1 fbcon
softcursor             16384  1 bitblit
font                   20480  1 fbcon
CoreELEC:~ # modinfo dovi
modinfo: ERROR: Module dovi not found.

Not sure why dovi doesn’t do anything. Modinfo on other modules works.

Looks like it’s because the dovi-loader script is inserting the kernel module from a specific path (I believe pulling from the Android filesystem in fact).

Try this instead:
modinfo /android/vendor/lib/modules/dovi.ko

CoreELEC:~ # modinfo /android/vendor/lib/modules/dovi.ko
filename:       /android/vendor/lib/modules/dovi.ko
license:        GPL
description:    Amlogic Dolby Vision Driver
depends:
vermagic:       4.9.y SMP preempt mod_unload modversions ARMv7

hope this helps

It appears that flag has many options, and can be up to 8 digits, and is hexadecimal.

It appears it’s “5” because

static unsigned int dolby_vision_flags = FLAG_BYPASS_VPP | FLAG_FORCE_CVM
thus:
#define FLAG_FORCE_CVM *0x01
#define FLAG_BYPASS_CVM 0x02
#define FLAG_BYPASS_VPP *0x04

Anyone know what CVM and CSC might mean in relation to Dolby Vision? I suspect csc stands for color space compression but that’s just a guess. No idea about CVM.

Want to try this for the flags:

echo 0x1308345 > /sys/module/amdolby_vision/parameters/dolby_vision_flags

Yep looks like there are a few options for the flags :slight_smile:

Big caveat - I am no expert in any of this just finding my way in the dark lol…
Anyone with knowledge please do speak up.

I have been checking the android 9 TV code here, closest code I can find to what I think the driver we are using is built from:

https://android.googlesource.com/kernel/arm64/+/refs/tags/android-tv-9.0.0_r0.3/drivers/amlogic/media/enhancement/amdolby_vision/amdolby_vision.c

#define FLAG_FORCE_CVM				0x01
#define FLAG_BYPASS_CVM				0x02
#define FLAG_BYPASS_VPP				0x04
#define FLAG_USE_SINK_MIN_MAX		0x08
#define FLAG_CLKGATE_WHEN_LOAD_LUT	0x10
#define FLAG_SINGLE_STEP			0x20
#define FLAG_CERTIFICAION			0x40
#define FLAG_CHANGE_SEQ_HEAD		0x80
#define FLAG_DISABLE_COMPOSER		0x100
#define FLAG_BYPASS_CSC				0x200
#define FLAG_CHECK_ES_PTS			0x400
#define FLAG_DISABE_CORE_SETTING	0x800
#define FLAG_DISABLE_DMA_UPDATE		0x1000
#define FLAG_DISABLE_DOVI_OUT		0x2000
#define FLAG_FORCE_DOVI_LL			0x4000
#define FLAG_FORCE_RGB_OUTPUT		0x8000
/* #define FLAG_DOVI_LL_RGB_DESIRED	0x8000 */
#define FLAG_DOVI2HDR10_NOMAPPING 	0x100000
#define FLAG_PRIORITY_GRAPHIC	 	0x200000
#define FLAG_DISABLE_LOAD_VSVDB		0x400000
#define FLAG_DISABLE_CRC			0x800000
#define FLAG_TOGGLE_FRAME			0x80000000

Yes the default value of 5 is because the 1st and 3rd bits are being set as per the code you pasted:
static unsigned int dolby_vision_flags = FLAG_BYPASS_VPP | FLAG_FORCE_CVM

From the code and its sparse comments I think the C stands for [C]omposer.

  • CVM I am surmising is Composer Video Metadata/Mapping - dare we say the RPU data? from code: /* bypass CVM when tunnel out */ maybe related to IPT other profiles in that case but a possible clue to what it is.
  • CSC I think is related to the EL layer - but cannot make out what it may stand for.
  • VPP is Video Picture Processing maybe? /* bypass all video effect */ is commented in code where FLAG_BYPASS_VPP is used.

Could it be that the default of 5 is designed to switch off all processing: RPU and EL and then force the RPU back on - in all cases including display led.

I.e. it does not by default process the EL Layer, and forces the processing of the RPU in all cases.
Maybe to provide the most compatibility with AMLogic SOC (some do not process the EL Layer) and TV (Some older models cannot do Display Led and must have Player Led)

Setting to 2 i.e. FLAG_BYPASS_CVM only I think just stops the RPU processing (fingers crossed the RPU is passed on in Display Led for the TV to process it!)

[UPDATE - Unfortunately not - RPU is not reflected when setting to 2 - see replies]

I did not want to bias anyone from my previous post to get impartial feedback - but for me and viewing on an LG E8, it is making an improvement - at the least it is very clear that things have changed in certain scenes both MEL and FEL. The change seen playing MEL - for me - indicates it is making a change in the RPU processing.

Overall it gives a sense of better depth, color and subtlety to the image making it less flat looking (obviously it is all relative - it is not like the picture was poor before!). I get the impression of more contrast - maybe a slightly darker tone overall helping make the contrast pop.

I see plenty of debug logging in the driver code so need to see if can pick that up on the box - not looked for it so far.

I don’t have a way to capture the HDMI externally to investigate from that side, which would be more conclusive.


For others your number 0x1308345 - using the the above code breaks down to:

FLAG_FORCE_CVM				0x01
FLAG_BYPASS_VPP				0x04
FLAG_CERTIFICAION			0x40
FLAG_DISABLE_COMPOSER		0x100
FLAG_BYPASS_CSC				0x200
FLAG_FORCE_RGB_OUTPUT		0x8000
FLAG_DOVI2HDR10_NOMAPPING	0x100000
FLAG_PRIORITY_GRAPHIC		0x200000
??							0x1000000

FLAG_PRIORITY_GRAPHIC I am 99% sure you would not want that set: Graphics (vs. Video) according to the Dolby Docs is for overlays/popups for on screen menus etc. - presumably so when showing and content playing in the background the contrast of the menus is kept under control and not moving with the RPU. see more here:

Page 16

Ohers I can guess at, but I believe would not be needed for getting the best operation and picture, the sense I get from the code is they are more there for forcing items in situations where normally they would/should not be triggered.

2 Likes

I have just tried this on my Philips 808, and first of all I don’t know if this TV supports TV-led but I’ve had no issues in that mod so far.

In my tests rpu is not processed at all when that flag is set to 2.

I’ve used the out of sync test files from this folder, they have easily noticable rpu changes throughout the video.

RPU RESPONSE TEST - Google Drive

Movies probably don’t do such drastic changes by scene, so please test your findings with these videos instead.

2 Likes

Thanks Kaan.

Yep you are correct it is not processing the RPU set to 2, guess I am just preferring something about that setting.

Back to the drawing board to understand more…

I think the bulk of the RPU processing logic is contained in these rather large methods:
parse_sei_and_meta_ext (line 6148)
which is called by:
parse_sei_and_meta

The parse_sei_and_meta_ext calls the function is_meson_tvmode repeatedly in several if statements. Only tm2 and txlx SOC types ever return true for that function.

Further it seems like those two SOCs specifically have an additional CORETV_BASE address. My guess is that’s related to the metadata processing that the g12 SOCs do always. My hunch is indeed the SC2 and G12 SOCs lack that crucial difference.

This section is interesting though:

FLAG_CERTIFICAION
/* bypass dither/PPS/SR/CM*/
/*   bypass EO/OE*/
/*   bypass vadj2/mtx/gainoff */

So may want to play with that flag setting.

Perhaps?

#define FLAG_BYPASS_CVM				0x02
#define FLAG_BYPASS_VPP				0x04
#define FLAG_CERTIFICAION			0x40

#define FLAG_DISABLE_COMPOSER		0x100
#define FLAG_BYPASS_CSC				0x200
#define FLAG_FORCE_RGB_OUTPUT		0x8000

0x8346

1 Like

I think you are referring to the code base under Android TV 13.

https://android.googlesource.com/kernel/arm64/+/refs/tags/android-tv-13.0.0_r0.6/drivers/amlogic/media/enhancement/amdolby_vision/amdolby_vision.c

I am thinking this box would be similar to the code under Android TV 9?

https://android.googlesource.com/kernel/arm64/+/refs/tags/android-tv-9.0.0_r0.3/drivers/amlogic/media/enhancement/amdolby_vision/amdolby_vision.c

Though had noticed the parameters that are being created (below), some of those only seem to apply to the Android TV 13 code. like force_best_pq.

Will look into the TV 13 code next.

As I understand this box is not Android TV but Android 9 - AOSP, and I believe Ugoos must be adding the amlogic library for a custom build - do you know a way to be sure what the code behind the build is?

-rw-rw-r--    1 root     root          4096 Feb 29 23:33 vtotal_add
-rw-rw-r--    1 root     root          4096 Feb 29 23:33 vpotch
-rw-rw-r--    1 root     root          4096 Feb 29 23:33 set_backlight_delay_vsync
-rw-rw-r--    1 root     root          4096 Feb 29 23:33 sdr_ref_mode
-rw-rw-r--    1 root     root          4096 Feb 29 23:33 primary_debug
-rw-rw-r--    1 root     root          4096 Feb 29 23:33 panel_max_lumin
-r--r--r--    1 root     root          4096 Feb 29 23:33 is_mel
-rw-rw-r--    1 root     root          4096 Feb 29 23:33 g_vtiming
-rw-rw-r--    1 root     root          4096 Feb 29 23:33 force_update_reg
-rw-rw-r--    1 root     root          4096 Feb 29 23:33 force_mel
-rw-rw-r--    1 root     root          4096 Feb 29 23:33 force_best_pq
-rw-rw-r--    1 root     root          4096 Feb 29 23:33 dv_ll_output_mode
-rw-rw-r--    1 root     root          4096 Feb 29 23:33 dv_graphic_blend_test
-rw-rw-r--    1 root     root          4096 Feb 29 23:33 dv_cert_graphic_width
-rw-rw-r--    1 root     root          4096 Feb 29 23:33 dv_cert_graphic_height
-rw-rw-r--    1 root     root          4096 Feb 29 23:33 dolby_vision_wait_on
-rw-rw-r--    1 root     root          4096 Feb 29 23:33 dolby_vision_wait_delay
-rw-rw-r--    1 root     root          4096 Feb 29 23:33 dolby_vision_tuning_mode
-r--r--r--    1 root     root          4096 Feb 29 23:33 dolby_vision_target_mode
-rw-rw-r--    1 root     root          4096 Feb 29 23:33 dolby_vision_status
-rw-rw-r--    1 root     root          4096 Feb 29 23:33 dolby_vision_src_format
-rw-rw-r--    1 root     root          4096 Feb 29 23:33 dolby_vision_run_mode_delay
-rw-rw-r--    1 root     root          4096 Feb 29 23:33 dolby_vision_run_mode
-rw-rw-r--    1 root     root          4096 Feb 29 23:33 dolby_vision_reset_delay
-rw-rw-r--    1 root     root          4096 Feb 29 23:33 dolby_vision_reset
-rw-rw-r--    1 root     root          4096 Feb 29 23:33 dolby_vision_profile
-rw-rw-r--    1 root     root          4096 Feb 29 23:33 dolby_vision_policy
-rw-rw-r--    1 root     root          4096 Feb 29 23:33 dolby_vision_mode
-rw-rw-r--    1 root     root          4096 Feb 29 23:33 dolby_vision_mask
-rw-rw-r--    1 root     root          4096 Feb 29 23:33 dolby_vision_ll_policy
-rw-rw-r--    1 root     root          4096 Feb 29 23:33 dolby_vision_level
-rw-rw-r--    1 root     root          4096 Feb 29 23:33 dolby_vision_hdr10_policy
-rw-rw-r--    1 root     root          4096 Feb 29 23:33 dolby_vision_graphics_priority
-rw-rw-r--    1 root     root          4096 Feb 29 23:33 dolby_vision_graphic_min
-rw-rw-r--    1 root     root          4096 Feb 29 23:33 dolby_vision_graphic_max
-rw-rw-r--    1 root     root          4096 Feb 29 23:33 dolby_vision_flags
-rw-rw-r--    1 root     root          4096 Feb 29 23:33 dolby_vision_enable
-rw-rw-r--    1 root     root          4096 Feb 29 23:33 dolby_vision_efuse_bypass
-rw-rw-r--    1 root     root          4096 Feb 29 23:33 debug_dolby_frame
-rw-rw-r--    1 root     root          4096 Feb 29 23:33 debug_dolby
-rw-rw-r--    1 root     root          4096 Feb 29 23:33 cfg_ll_id
-rw-rw-r--    1 root     root          4096 Feb 29 23:33 cfg_id
-rw-rw-r--    1 root     root          4096 Feb 29 23:33 atsc_sei
-rw-rw-r--    1 root     root          4096 Feb 29 23:33 ambient_test_mode

FLAG_BYPASS_CVM looks to always switch the RPU processing off.

dolby_vision_graphics_priority always looks to be being set to 1, cannot override - thinking maybe a settng in the base Android OS, need to check there.

I have been referring to:
https://github.com/CoreELEC/linux-amlogic/tree/amlogic-4.9-20-DV/drivers/amlogic/media/enhancement/amdolby_vision

1 Like

I’m using CoreELEC on the Fire TV 2nd gen Cube (s922x) with Dolby Vision working. The Cube uses a 64bit Dolby Vision module which is a little different than the AM6 & U22X-J that use a 32bit module. Perhaps the AM6 & U22X-J could also make use of the Cube’s DV module.

I made a separate post with a little more details as to not sidetrack the discussion here.

Thanks - been checking this code, and the Dolby debug log output.


I think the graphics priority is on constantly - have not found a way to turn off, set by this code:

is_graphics_output_off

It is like the On Screen Display is on all the time even if not showing - not sure if that is effecting the picture quality for AMLogic SOC - The Dolby docs state video priority should be used when playing video, graphics only for when onscreen menus are showing etc.

Logging is showing the same (note the gpr [graphic priority] at end of the log):
Mar 01 15:54:31 CoreELEC kernel: DOLBY: v 1: 3840x2160 0->0(T:1-700),g 1: 1920x1080 50->3000000,gpr


Some other observations:

FLAG_BYPASS_CSC → FEL and MEL play with purple and green colours

FLAG_DISABLE_COMPOSER → FEL gives a grey screen → MEL looks normal
(Seems Composer is required for the 12 bit composition BL+EL)

FLAG_BYPASS_VPP → FEL turns the RPU Off
(Need to get a file to test the effect conclusively on MEL, but would assume the same)

FLAG_CERTIFICAION → Causes a large frame rate drop maybe of half to 10-12 fps - no obvious picture difference


0->0(T:1-700) from the debug indicates source DV → dest DV with 1-700 nit range (the nits are possibly being picked up from the TV LG E8 though the HDMI comms)

g 1: 1920x1080 50->3000000 is the graphics overlay it thinks is on - can alter the “graphics” nit range with parameters:

dolby_vision_graphic_min
dolby_vision_graphic_max

Setting min to 1 to match TV and max to 1 (lowest acceptable value) - the brightness of the on screen controls (play / pause etc.) of Kodi are greatly reduced - so doing something. picture quality no obvious difference.

log when changed to:

Mar 01 16:33:21 CoreELEC kernel: DOLBY: v 1: 3840x2160 0->0(T:1-700),g 1: 1920x1080 1->10000,gpr

Changing the Kodi screen resolution had no effect of the graphics size reported in the logging.


My take at this point is this code is extracting the RPU meta data, BL and EL video and passing all to the kernel object dovi.ko (which is driving the SOC), alongside setting up registry values for the same.

Any RPU application is in these lower levels, possibly in the SOC itself.

My take on the SOC variations are they are basically divided into STB (Set Top Box) and TV (Embedded TV) RPU is passed on in both cases to the driver.

Just got my am6b+, FINALLY! I can confirm my remux of Dune has the exact same behavior. Interesting observation: with lossless set the movie immediately starts with 65 skipped frames. If I rewind to the start again another 65 skipped frames.
Also seems to stop at the Legendary logo for a little under 3 seconds. I think this is somehow related? With minimal EL set, it played to at least 5 minutes without any skipped frames.

I found a MEL title that’s even worse than Dune (and not entirely surprised): Gemini Man. On lossless it played maybe once out of 10 tries. Basically it just doesn’t want to play properly. With minimal EL it plays fine. That movie is the only 60FPS UHD 4K movie I have so it’s definitely unique in that way.

Are folks able to play the mehanik mortal engines fel test mkv? The copy I have immediately hangs when I play and there’s video corruption towards the bottom of the screen. I redownloaded again to make sure it was a good copy–it is and same behavior. It did play saving Private Ryan (which is FEL) fine, so not sure…

Also if I set to player-led I get a blanked out screen (TV reports no signal). My Dune HD Boxy does only player led so I know this TV can support that mode. Hopefully it’s just something I’m missing that’s obvious. I have an LG GX OLED TV. Oddly with the TV-led it’s reporting as RGB 12-bit whereas that reports correctly as RGB 8-bit in every other device I have doing TV-led (several Roku ultra, shield, fire tv, Panasonic UHD player, etc).

The dualboot firmware configuration was pretty simple and worked just as I suspected. It even updated itself to 19.5 and then I injected the 20.4-dv tar file and had to use the .nocompat file to make it go.

Yeah, that happens when I turn off refresh rate change, but I actually never use without that option so it never bothered me.

Did you try increasing “dolby_vision_wait_delay”? There is no need to switch to minimal el.

Some more observations:

Leaving the flags at the default 0x05 (using Display Led):

FLAG_FORCE_CVM		0x01
FLAG_BYPASS_VPP		0x04

I get:
Mar 02 12:00:19 CoreELEC kernel: DOLBY: v 1: 3840x2160 0->0(T:50-4000),g 1: 1920x1080 50->3000000,gpr

Changing to 0x0D, i.e. adding:

FLAG_USE_SINK_MIN_MAX 0x08

I get:
Mar 02 12:09:03 CoreELEC kernel: DOLBY: v 1: 3840x2160 0->0(T:1-700),g 1: 1920x1080 1->7000000,gpr

Changing back to 0x05 does not reset this and it stays at 1-700 (until I rebooted)
50-4000 are defaults from the code:

static unsigned int dolby_vision_target_min = 50; /* 0.0001 */
static unsigned int dolby_vision_target_max[3][3] = {
		{4000, 1000, 100}, /* DOVI => DOVI/HDR/SDR */
		{1000, 1000, 100}, /* HDR =>  DOVI/HDR/SDR */
		{600,  1000, 100},  /* SDR =>  DOVI/HDR/SDR */
};

DOVI src => DOVI dest


Not found a way to switch off the OSD, probably needs a code change.

From the CE source for linux-amlogic it has some docs on the - Amlogic Meson Display Controller from that I think we can confirm:

VPP: Video Post Processing
CSC: Colorspace Conversion

CVM - still not finding a definition

That FEL test video should play fine in lossless.
Here’s a link to the one I have

1 Like

I found another test video with flashing solid colors and some watermark (ie exclusively in the FEL layer) that says this device is capable of FEL playback or something along those lines. That played at least whereas it was only the flashing solid colors on my Shield Pro, so indeed it seems it’s handling FEL.

I have to retract some of what I said about especially Gemini Man and a few other titles that I reported about yesterday because the issue was related to my receiver. It has a Auto/Standard/Enhanced, setting for the HDMI Inputs. They were set at auto, but I ended up getting more issue with setting it to enhanced. I thought that meant the setting the HDMI to handle 18.0 Gbit/s but now not sure. The receiver I’m currently using is still pretty new and has its share of quirks.

Maybe CVM means:
“Our previous study [19] has shown that standard FP detection algorithms (Harris Corner [22] and DoG [23]) can be modified to improve detection in HDR images by using the coefficient of variation mask (CVM).”

That 1-700 sounds like it’s the luminance range of your TV and was probably determined via the HDMI EDID.

If you are referring to the code itself of the tv and stb named methods/variables, from what I can tell it’s the difference between TV-led vs player (ie the stb) led DV? I don’t think it means SOC types…

@Portisch Btw I briefly tried 20.5 and for the life of me, I couldn’t get either MEL or FEL DV titles to consistently work with in either player or TV-led, and by trying the force options. Either it eventually froze playback, I got only a black screen, or a blue-tinted screen (e.g. Gemini Man). I ended up rolling back to 20.4. Would you need logs for that?

For reference, with 20.4 I had to set force 4:2:2 and 12-bit for player-led, and force 8-bit for TV-led, and then set the dolby_vision_wait_delay of 16 in a startup script. The forced settings for player-led would appear to work for any video with a capable HDMI 2.0 setup (that can do the 594MHz signal) including SDR and HDR, for up to the max 60Hz. For TV-led that forced 8-bit would impact HDR playback it seems so I set it back when testing HDR media types. For Gemini Man which is a 60fps title, with the blue tint behavior, that issue seemingly went away with TV-led mode once I set 8-bit forced. So I’m wondering if the erroneously set 12-bit RGB on TV-led was causing that? With player-led and forced 4:2:2 and 12-bit, I seemingly also couldn’t trigger the blue-tint.

Nothing was changed, no. Forced cd or C’s is ignored on DV. Auto should do his job.
P7 is not really proof, so it’s more luck it works.
It’s to much time consuming to debug and play with this so maybe it get improved in future someday
Like when S5 with FEL and 5.15 kernel support come up. Homatics doesn’t support FEL at all. And I don’t have time to work on 4.9 EOL kernel.