[OFFICIAL/UNOFFICIAL] LineageOS 19.1 for Amlogic G12*/SM1 Family Devices

[npjohnson]

Looking at changes for 20220918 build, saw that VENDOR.PROP still has this:
ro.vendor.sdr2hdr.enable=true

I believe that is from Amlogic's source-code by default, which has been affecting other Amlogic devices for the last few years of automatically forcing SDR-to-HDR upscaling, and has somehow been migrated into these builds.

@npjohnson can we get that prop flipped to FALSE or removed from build completely?

merged https://review.lineageos.org/c/LineageOS/android_device_amlogic_g12-common/+/339786 - I'll fix TvSettings side and revert it soon.

 

[samdsmith]

which rom is for tanix tx3 mini?anyone can tell?help plz

 

[endera]

radxa zero ?

 

[nshah2810]

Hello, I am trying to build dopinder from scratch since last week. I am able to flash lineage-19.1-20220908-unofficial-dopinder.zip release and that works but when I flash my own build it fails to boot.

Can someone help me debug the issue? I flash recovery, dtb, dtbo followed by adb sideload of the image.

The build log is from today, I think this might be the error.

ibfdt fdt_check_header(): FDT_ERR_BADMAGIC
aml_config_dtb 633
aml_config_dtb 663
No FDT memory address configured. Please configure
the FDT address via "fdt addr <address>" command.
Aborting!

Full logs attached below

Thanks,
Nirmit Shah

 

[nshah2810]

not able to attach the file

boot_log_dopindr - 18490a5e

bl2_stage_init 0x01 bl2_stage_init 0x81 hw id: 0x0000 - pwm id 0x01 bl2_stage_init 0xc1 - 18490a5e

controlc.com

 

[RiCkLaR]

Is it implemented in a different way for R or higher?

Every certified device I've seen running android 11 (usually on a X4 or Y4 SoC), has this setting in display->screen resolution;

View attachment 5720365

What you "see" as a user may have changed, but Amlogic's code that interacts with the SoC stays the same and didn't change from Android 9/10/11 unless there was something completely f'kd up.

That HDR setting in the picture has incorrect label, {HDR_POLICY} for Amlogic refers to whether to get the HDR state from the media "SOURCE" or the connected "SINK" device in the code. That setting should instead have been labeled {HDR_MODE}.

I believe I have a runtime fix for HDR issues. The problem is not sdr2hdr but the S905Y2 hdr_policy setting.

Tested:
1) Setting sdr2hdr false in /vendor/build.prop did not change behavior
2) Setting /sys/module/am_vecm/parameters/hdr_policy to 1 produced SDR video from SDR sources and HDR video from HDR sources.

I would recomend leaving sdr2hdr as true (this probably enables the capability, rather than forcing the upscaling) and define /sys/module/am_vecm/parameters/hdr_policy as 1. That option could eventually be addressed in Settings if the UI option is implemented.

HDR_POLICY = "0" || #0 = SINK (connected TV or AVR determines HDR mode)
HDR_POLICY = "1" || #1 = SOURCE (media file determines HDR mode)

 

[RiCkLaR]

merged https://review.lineageos.org/c/LineageOS/android_device_amlogic_g12-common/+/339786 - I'll fix TvSettings side and revert it soon.

This may help...

DROIDLOGIC "HdrManager"

String KEY_HDR_MODE = "persist.vendor.sys.hdr.state"

int
MODE_OFF = 0;
MODE_ON = 1;
MODE_AUTO = 2;

 

[Deleted member 11959327]

HDR_POLICY = "0" || #0 = SINK (connected TV or AVR determines HDR mode)
HDR_POLICY = "1" || #1 = SOURCE (media file determines HDR mode)

int
MODE_OFF = 0;
MODE_ON = 1;
MODE_AUTO = 2;

How does AUTO (2) work? What's the effect of the source media and/or the edid of the sink while in auto mode?

That HDR setting in the picture has incorrect label, {HDR_POLICY} for Amlogic refers to whether to get the HDR state from the media "SOURCE" or the connected "SINK" device in the code. That setting should instead have been labeled {HDR_MODE}.

Are there actually two distinct settings (HDR_POLICY and HDR_MODE), or only one setting that was mislabeled? If the former, should the HDR_POLICY setting not have any user control?

I'm slightly more confused now.

 

[tenfox]

HDR_POLICY = "0" || #0 = SINK (connected TV or AVR determines HDR mode)
HDR_POLICY = "1" || #1 = SOURCE (media file determines HDR mode)

Agree. And, apparently "2" is debug mode, which I have not yet tested.

hdr_mode changes do not appear to have an effect, as when set "0" (off) with or without sdr2hdr, HDR sources still output a HDR stream, but I have not tested this exhaustively.

hdr_policy = 1 is probably what we want for most use cases. CoreElec (media player distro) also chose it as their amlogic default.

Are there actually two distinct settings

Yes

If the former, should the HDR_POLICY setting not have any user control?

It seems to have the most control over output selection, so it should be user controlable.

 

[RiCkLaR]

...
hdr_mode changes do not appear to have an effect, as when set "0" (off) with or without sdr2hdr, HDR sources still output a HDR stream, but I have not tested this exhaustively.
...

So it is my belief that the PROP:ro.vendor.sdr2hdr.enable=true originated in Amlogic's source-code because the JAVA coding for the SdrManager was originally written with only 2 variables OFF & AUTO, the ON variable was missing; and instead of just adding the coding for ON, they added it as a PROP to save time, which ironically forces it ON when it doesn't need to be ON, let alone forced_on by having the prop=true, which is what's happening by setting it as a "Read-Only" prop in the vendor.prop for sdr2hdr.

Of course, I may be wrong, maybe the system_root permission file doesn't even allow sdr2hdr to be set when the prop is coming via vendor init and not system init; just letting you know my thinking on the issue.

 

[Deleted member 11959327]

If that hypothesis is true, how do some of the factory builds, like sabrina, manage to switch hdr on and off properly as needed?

I realize that this hdr issue has been a problem in various certified amlogic builds for years, but a few devices have fixed it. How was it fixed in those builds?

 

[RiCkLaR]

If that hypothesis is true, how do some of the factory builds, like sabrina, manage to switch hdr on and off properly as needed?

I realize that this hdr issue has been a problem in various certified amlogic builds for years, but a few devices have fixed it. How was it fixed in those builds?

Do you have a SABRINA? Fortunately, I don't, but all other devices use Amlogic's DROIDLOGIC subsystem which gives control to things like HDR_POLICY. Sabrina may not need Droidlogic to make HDR function properly if all the Droidlogic TVsettings, like HDR_POLICY, were hardcoded or hooked into the stock com.android.TVsettings.apk .

You familiar with the TiVo Stream4K (S905Y2), it used {HDR_POLICY=1} as default when it was on Android 9, but when they pushed out the Android 10 Q update the default is now {HDR_POLICY=0}, which I hate; but all these settings "should" be End-User selectable via DROID_SETTINGS vendor app if the software engineer took the time to go through Amlogic code and doesn't just build the firmware as-is. And with the TiVo at least it gives access to some of the Droidlogic coding, but not all; with its HDR settings hardcoded into the TVsettings.

So, if I choose to watch HDR content on the TiVo, I have made an ACTIVITY shortcut with the tvQuickActions app to activate its HDR_POLICY setting overlay manually. The Activity that toggles HDR_POLICY inside the TiVo is found inside the package:com.droidlogic.tv.setttings as a DolbyVision setting.

ADB shell command to toggle the setting:

am start 'com.droidlogic.tv.settings/com.droidlogic.tv.settings.display.dolbyvision.DolbyVisionSettingActivity'

But, that same shell command used with a stock Amlogic device without the DolbyVision license, will give two options: Enable or Disable. You DO NOT want to enable it, possible Green screen of death for the Onn.4K if enabled, or at least that what I believe seeing as the Onn.4K didn't block access to DolbyVision setting activities last I checked in its stock original firmware releases.

 

[Deleted member 11959327]

Thanks, that's very helpful. The interplay of dolbyvision with the hdr switching issue has been confusing to me. My optimum stream device (sdmc dv8555 s905x2 operator tier device w/dolbyvision) has done better with hdr switching than some of my sei devices like the tivo stream 4k. A recent review of a new sei804 based device also has hdr switching effected by whether or not the relevant app supported dolbyvision. The various chinese odm/oem (sei, sdmc, etc.) do all of the engineering a-to-z on these builds. It has repeatedly demonstrated to be quite sloppy.

You've obviously dove into this issue pretty deeply. I'm just trying to understand.

 

[nshah2810]

Hello, I am trying to build dopinder from scratch since last week. I am able to flash lineage-19.1-20220908-unofficial-dopinder.zip release and that works but when I flash my own build it fails to boot.

Can someone help me debug the issue? I flash recovery, dtb, dtbo followed by adb sideload of the image.

The build log is from today, I think this might be the error.

Full logs attached below

Thanks,
Nirmit Shah

Not to spam but do we expect dopinder build from source to be stable? Can anyone assist me with it?

 

[npjohnson]

Not to spam but do we expect dopinder build from source to be stable? Can anyone assist me with it?

Make sure you bootloader is the latest stock one, and it will boot fine.

 

[nshah2810]

Make sure you bootloader is the latest stock one, and it will boot fine.

Hi, thanks for the reply. Yes it does boot if I manually flash the stock bootloader on top of my build. However it gives a different KeystoreService error, although the aidl is present.

[email protected]]- logd: logdr: UID=1017 GID=1017 PID=3342 n tail=0 logMask=1 pid=3320 start=0ns deadline=0ns
[ [email protected]]- DEBUG: *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***DEBUG: Build fingerprint: 'Onn/sti6140d360/sti6140d360:10/QT/20220523:user/release-keys'DEBUG: Revision: '0'DEBUG:.
[ [email protected]]- DEBUG:
[ [email protected]]- DEBUG: Caused by:
[ [email protected]]- DEBUG: 0: In KeystoreSecurityLevel::new_native_binder.
[ [email protected]]- DEBUG: 1: In get_keymint_device.
[ [email protected]]- DEBUG: 2: In connect_keymint: Trying to connect to genuine KeyMint service.
[ [email protected]]- DEBUG: 3: Binder transaction error NAME_NOT_FOUND.'DEBUG: r0 00000000 r1 00000cf8 r2 00000006 r3 ffdeb2f8DEBUG: r4 ffdeb30c r5 ffdeb2f0 r6 00000cf8 r7 00000162
[ [email protected]]- init: Control message: Could not find 'aidl/android.system.keystore2.IKeystoreService/default' for ctl.interface_start from pid: 3091 (/system/bin/servicemanager)

here are the full logs. I even tried adding KeystoreService to DCM but the error is the same.

boot_log_fail - c652588d

board_late_init(): store dtb read 1000000 fail [KM]Error:f[keymanage_dts_parse]L317:not a - c652588d

controlc.com

 

[npjohnson]

Hi, thanks for the reply. Yes it does boot if I manually flash the stock bootloader on top of my build. However it gives a different KeystoreService error, although the aidl is present.



here are the full logs. I even tried adding KeystoreService to DCM but the error is the same.

boot_log_fail - c652588d

board_late_init(): store dtb read 1000000 fail [KM]Error:f[keymanage_dts_parse]L317:not a - c652588d

controlc.com

Yup. It boots but secure keystore is broken.

Welcome to dopinder at the moment. That's why wade and Deadpool shipped but dopinder didn't.

 

[nosillock]

Hello, I have several dopinder devices still on 18.1 that I would like to update to 19.1. What is the process for updating 18.1 to 19.1? I only see instructions in the wiki for updating a build within the version.

 

[bigCrashdev]

Seems like holding the button and having usb connected to a host triggers a different mode as documented here for the adt3.

Google Issue Tracker

issuetracker.google.com

Not shoving in the USB plug all the way, so only power gets connected until recovery or bootloader is booted and then shoving it in all the way leads to the expected result.

Unbelievable, but that did the trick for me.

As it might be of interest for others (puzzling random replies together ):

I am trying to flash to wade. The first steps (as described in lineage wiki) went without any problems, up to the point where I had to reboot into recovery (after flashing it via fastboot). This just gave me a black screen. So I booted normally which worked. However, from then on rebooting into bootloader did NOT work anymore. Also, rebooting into recovery did not work anymore (in both cases the brand's logo got "stuck" without adb or fastboot being able to communicate).

I then did @Jann F 's USB trick and bam. LineageOS recovery from where I could sideload the rom.

 

[nosillock]

Unbelievable, but that did the trick for me.

As it might be of interest for others (puzzling random replies together ):

I am trying to flash to wade. The first steps (as described in lineage wiki) went without any problems, up to the point where I had to reboot into recovery (after flashing it via fastboot). This just gave me a black screen. So I booted normally which worked. However, from then on rebooting into bootloader did NOT work anymore. Also, rebooting into recovery did not work anymore (in both cases the brand's logo got "stuck" without adb or fastboot being able to communicate).

I then did @Jann F 's USB trick and bam. LineageOS recovery from where I could sideload the rom.

I cannot believe this works, but it does!