3.14.29-69-osmc - and a cold reboot got it working again 
2 Likes
If you look closely, the quotes are 66/99-type quotes, as found in WYSIWYG text editors.
It should have been
echo "round0" etc.
though the quotes are actually unnecessary.
So, installing the absolute latest build should solve the banding and jittery HDR without any special settings afterwards? Or is that still needed?
No.
Sorry, is that no, you don’t need to fiddle with settings afterwards, or no it doesn’t solve it yet?
It’s not yet solved.
1 Like
Thanks for the hint on the “callbacks” addon. Working perfectly as a workaround now. 
I did some more testing in regards of banding because even with the round0/1 debug option there is some very slight banding left: So I compared the Vero4k (S905X) with my Minix U9 (S912) and with the Minix I was unable to see any banding at all (Libreelec with new kernel).
So why is the S912 superior to the S905X in regards of banding?
As far as I know the S905X only has an 8Bit processing path with extrapolated 10Bit at the end of it.
The S912 in contrary has a full 10 Bit processing path and therefore keeps the full 10 Bit from the input.
1 Like
Can you share your script to this thread? I’d rather just chmod +x and use yours with callbacks instead of tinkering around with one myself.
Sure, it’s very simple. Not sure if the sleep is needed but I left it in
#!/bin/bash
sleep 5
echo round1 >/sys/class/amhdmitx/amhdmitx0/debugSleep is necessary. After some tests i had good results setting it to only 1 second.
If this is true that the Vero 4k is only 8bit, I feel pretty ripped off, the whole reason I got the thing after I already had a shield tv was to play my 4K HDR files perfectly and natively, not doing fake 10bit.
? It does 10bit just fine
Is it native 10 bit or extrapolated 10 bit? I’m asking because of Mule’s post that talks about how the S912 has no banding but our S905x does.
The first time i heard of it was from one of the LibreELEC developers.
You can also see some of the differences in capibilities between Meson-GXM (S912) and Meson-GXL (S905X) in the driver source code: https://github.com/LibreELEC/linux-amlogic/blob/amlogic-3.14.y/drivers/amlogic/hdmi/hdmi_tx_20/hw/hdmi_tx_hw.c
For example the below extracted part from the driver source code (it is for setting up the correct rounding/dithering options for S925/S905X) which was fixed by Sam in order to get rid of the flickering. As you can see GXM and GXL are working with different bit depth/precision. Maybe Sam can give some more information, but maybe the exact details are only known to AMLogic.
if (get_cpu_type() >= MESON_CPU_MAJOR_ID_GXM) {
unsigned int hs_flag = 0;
/* 12-10 dithering on */
hd_set_reg_bits(P_VPU_HDMI_FMT_CTRL, 1, 4, 1);
/* hsync/vsync not invert */
hs_flag = (hd_read_reg(P_VPU_HDMI_SETTING) >> 2) & 0x3;
hd_set_reg_bits(P_VPU_HDMI_SETTING, 0, 2, 2);
/* 12-10 rounding off */
hd_set_reg_bits(P_VPU_HDMI_FMT_CTRL, 0, 10, 1);
/* 10-8 dithering off (2x2 old dither) */
hd_set_reg_bits(P_VPU_HDMI_DITH_CNTL, 0, 4, 1);
/* set hsync/vsync */
hd_set_reg_bits(P_VPU_HDMI_DITH_CNTL, hs_flag, 2, 2);
} else {
hd_set_reg_bits(P_VPU_HDMI_FMT_CTRL, 0, 4, 1);
hd_set_reg_bits(P_VPU_HDMI_FMT_CTRL, 0, 10, 1);
}
Do not worry about banding/no banding. The differences are marginal. I could not even see any difference when using my TV. Only when using my projector I could recognize some minimal differences when using test patterns.
There is no AMLogic SoC called S925.
There is additional post processing on the S912 but this is not necessary; nor wanted unless you are playing DV content.
Please be careful with the suggestions you make.
Sam
S925 was a typo should have been S912 (already updated my posting).
Where did I made any suggestions?
How did you set up callbacks? Was it triggered by event? I assume on playback but just need a little guidance as I’ve never used this add-on before.
Yes, triggered by event “on playback”.
Ok thanks