Thanks, tried that patch and while the log now shows that vsync is enabled:-
2025-12-22 15:36:17.705 T:986 info <general>: GLES: Enabling VSYNC
It unfortunately doesn’t fix the gui tearing issue.
So, two years later, I’ve pulled up my X96 X10 again. SoC S5 S928X - #129 by hyc
With 21.3 installed on a microSD card now, and the dovi.ko file, it thinks it supports Dolby Vision but I just get a blank screen whenever playing any DV content. My video projector says it’s receiving a DV feed, there’s just nothing in it. Both TV Led and Player Led do the same thing.
Also, with the GUI default of 1920x1080 rez, when watching a 3840x2160 video, the GUI is still 1920x1080. It just draws in the upper left of the screen. If I set the GUI explicitly to 3840x2160, it still does that. If I turn off GUI scaling, then it’s drawn properly at full size.
Are these known issues? I’ve spent hours searching here and haven’t found solutions.
Yes, CE-NE is EOL. Use CE-NO.
Hi
Is there a dovi.ko file that works on recent ce-no nightlies on a x928x-j box (x96 x10 pro)?
Yep this one
No FEL however
this one from AM8 is no longer compatible with the kernel
module from homatics ended up working in the end
I use this on my Ugoos SK1. DV works, but FEL is not supported, of course. However, I don’t have any Dolby Vision option in the CoreELEC settings.
If your TV doesn’t support Dolby Vision, you won’t be able to see these features
My TV supports Dolby Vision, and Dolby Vision playback works perfectly. The only thing is that after updating to the NO beta1 build, I no longer have the Dolby Vision option in the CoreELEC settings. Apart from that, everything works very well.
Install the TinyPPI plugin you’ll see the necessary information.
Hmmmmmm
And in System Settings you are on Expert/Advanced?
After change sometimes default settings are applied
@Portisch I have an X96 X10 (S928X, 4GB) and I’m testing CoreELEC 22.0-Piers_beta1.
I found a DTB issue during the update process:
The official s5_s928x_x96_x10.dtb from /device_trees/ works correctly and is about 43 KB.
After an update, /flash/dtb.img is replaced with a generated DTB of about 22 KB.
The box then no longer boots correctly.
Restoring the original DTB manually makes the box boot normally.
Could you please check whether this DTB conversion/replacement is expected for the X96 X10, or if there is an issue with S928X DTB handling during the update?
I can provide the update logs, original DTB and generated dtb.img for comparison.
Still looking normal (43kb):
portisch@Ubuntu:~/CE/CoreELEC/build.CoreELEC-Amlogic-no.aarch64-22/build/linux-799e6a3d791a34720f5ca89ef95251541e024ab3/common_drivers/arch/arm64/boot/dts/amlogic$ ls -al s5_s928x_x96_x10.dtb
-rw-rw-r-- 1 portisch portisch 43565 Aug 13 13:30 s5_s928x_x96_x10.dtb
Thanks, that confirms that the original DTB in the CoreELEC build is correct (43565 bytes).
The problem occurs specifically during the update on my X96 X10. The original s5_s928x_x96_x10.dtb is about 43 KB, but after the update /flash/dtb.img becomes about 22 KB and the box no longer boots correctly.
When I restore the original 43 KB DTB to /flash/dtb.img manually, the box boots normally again.
So I suspect the DTB is being modified or replaced somewhere during the update process rather than the source DTB being incorrect.
I previously traced the update process to /flash/user-update.sh, convert_dtname, and /usr/lib/coreelec/dtb-xml.
Could the dtb-xml processing be responsible for changing the DTB size/content on this S928X device?
There is no problem. Maybe your boot media is faulty or you did reset before finished.
It is not.
No.
You have a update log in /flash. Try clean fresh install. Something is broken on your setup.
I checked the files on my current system:
/flash/dtb.img — 43,565 bytes
/flash/trees/s5_s928x_x96_x10.dtb — 43,551 bytes
The MD5 hashes are different.
The current /flash/dtb.img works correctly and the box boots normally.
However, after the previous update, /flash/dtb.img became about 22 KB and the box stopped booting. Restoring the 43,565-byte DTB manually fixed it.
There is currently no update log in /flash — I only see the normal system files, dtb.xml and the trees directory.
I can reproduce the update and check /flash/dtb.img immediately before and after the update, if that would help.
/storage/init-previous.log
/storage/init.log
And is it really too hard to compare the files content? Just upload the smaller one somewhere.
Thanks. I have both files.
I checked the current working 43,565-byte dtb.img as well.
Interestingly, both files are Amlogic Multi-DTB images containing both:
- s5_s928x_x96_x10_4g
- s5_s928x_x96_x10_8g
The working 43,565-byte file contains two FDTs:
- X96 X10 / s5_s928x_x96_x10_4g
- X96 X10 Pro / s5_s928x_x96_x10_8g
So the problem does not appear to be simply selecting an 8GB DTB instead of the 4GB one.
I can provide both the working 43,565-byte Multi-DTB and the ~22KB Multi-DTB from the failed update for comparison.
dtb(bad22kb).img (21.4 KB)
dtb(work).img (42.5 KB)
I found the update log you mentioned.
/storage/init.log no longer exists, but /storage/init-previous.log contains the log from the problematic update.
The relevant lines are:
Updating Kernel … 100% Updating Kernel md5… 100% Updating System … 100% Updating System md5… 100% Updating Boot Files… Updating device tree with s5_s928x_x96_x10.dtb… Updating dtb.img by dtb.xml… Updating cfgload… Updating aml_autoscript… Updating recovery.img… Boot Files Updated. Cleaning up… done
The update completed successfully, but afterwards /flash/dtb.img was ~22 KB and the X96 X10 would no longer boot correctly.
Restoring the original 43,565-byte Multi-DTB manually makes the box boot normally again.
So we now have the update log and both Multi-DTB files (working 43,565-byte and bad ~22 KB) for comparison.
Test tomorrow nightly update again. If still bad DTB replace it again with good one and update again with same new nightly. Then latest it should work as it should.
@vpeter did found some issue about Amlogic multidtb handling and it should be fixed with tomorrow nightly.
We think the bug is there since about 1.5 years…