Sorry if this is a noob question. But I thought the CE OS was Read-only. So how is this possible?
It is not read only. You can issue commands on the fly for certain parameters to adjust and tweak to your liking. The colorimetry flags are one of those parameters.
Connect to your box via SSH, and you can issue commands to adjust or find out more information.
1 Like
Just tried on my Odroid N2 with this result:
N2:~ # echo Y > /sys/module/hdmitx20/parameters/test
-sh: /sys/module/hdmitx20/parameters/test: Permission denied
N2:~ #
The parameter is created in the code when the module loads, so need the version that creates it, once created it has permissions set to then allow you to overwrite it.
1 Like
Understand now, thank you.
Also,
echo Y > /sys/module/hdmitx20/parameters/dovi_tv_led_no_colorimetry
is more correct for DoVi. I put this is autostart.sh until CPM’s upcoming changes are merged.
Thank you, much appreciated.
Noob question - what is CPM?
A lead developer of the CoreELEC dovi code.
1 Like
Thanks again.
So once CPM’s changes have been done, what needs to happen if you have setup:
echo Y > /sys/module/hdmitx20/parameters/dovi_tv_led_no_colorimetry
in autostart.sh.
Delete autostart.sh.
1 Like
What I mean is that it might not be a ‘bug’ in dovi.ko because DV5 works. DV5 uses a different color space so DV5 to HDR10 is required on HDR10-only TV. DV8/DV7 has HDR10 base layer. If user wants the best of DV8/DV7 either with STD-DV or LLDV, go buy a DV capable TV from business point of view.
If my assumption is true, can you do something after dovi.ko processes video? i.e., do LLDV first, then remove LLDV requirement before passing the signal to HDR10-only TV? (as you add/remove/change color space flag)
The defects are ignoring the hdmi luminance and ignoring the RPU.
An easy one to test yourself is using an out of sync RPU dv file:
For DV → SDR10 can see the RPU change being applied
For DV → HDR10 cannot see the RPU change being applied
——-
That aside it maybe possible to fake the EDID / work around the VSI not being present and thus allow LLDV (presuming the dovi.ko does no further checking hidden to us)
For DV p5 LLDV I am thinking it is not ITP space on the output but is already converted to YUV because of the devices that can be used to fake the EDID - but have not checked to be sure - ie the only true ITP is the tunnelled tv-led signal?
Note: I am pivoting to some of my other projects but may come back to this in the future.
1 Like
I think DV p5 LLDV should have been already converted to YUV. Otherwise, user should see green or purple picture on non-DV display.
Thank you for your efforts. DVtoHDR is not my concern. Just curious how can make it work under current situation. 
Is it Possible to somehow blacklist SD / HD TV Channels (TV Headend) so they don’t trigger VS10 but HD videos do? Thank you.
2nd gen Cube source is available here, kernel source is in the platform.tar
Probably a noob question, but how do i upload your updates if my coreelec is running from emmc? thank you.
Write a SD card with this update, plug in to your Ugoos and regular reboot. It will always reboot to the SD card
When done testing. Shutdown and eject SD card. Then turn back on, it will proceed to your regular CE boot on eMMC
Thanks, but what if i want to commit these changes to emmc?
When you’ve booted into the SD card, with it plugged in, run “ceemmc -x” again.
Then you can write from the SD card back to eMMC and overwrite the original image.
Probably a good precaution to disable updates, but I don’t believe nightly updates run anyway on custom images.
Unless information is carried in the hints it may not be possible - as this is downstream in the decoding not sure it would know much about the original source of the stream - I do not use this device for TV so cannot comment further.