Day 30
test_hwcomposer still crashes. minimer still doesnt start the display. It says
library "libcutils.so" not found library "libc++.so" not found library "libz.so" not found library "libion.so" not found library "libhardware.so" not found library "android.hardware.graphics.mapper@3.0.so" not found library "android.hardware.graphics.mapper@4.0.so" not found library "android.hardware.graphics.mapper@2.0.so" not found library "libhidlbase.so" not found library "libutils.so" not found library "android.hardware.graphics.common@1.0.so" not found library "android.hardware.graphics.common@1.1.so" not found library "android.hardware.graphics.mapper@2.1.so" not found library "android.hardware.graphics.common@1.2.so" not found library "libandroidicu.so" not found
Linking libandroidicu to odm/lib64: ln -s /apex/com.android.art/lib64/libandroidicu.so /odm/lib64/libandroidicu.so gives back
library “libandroidicu.so” needed or dlopened by “/usr/libexec/droid-hybris/system/lib64/libmedia.so” is not accessible for the namespace “(default)”
Let’s unmount /linkerconfig 
Maybe /linkerconfig/default needs to be mounted on /linkerconfig, rather than bootstrap?
Also:
ln -s /vendor/lib64/egl/libGLESv2_adreno.so /odm/lib64/egl/libGLESv2_adreno.so
ln -s /vendor/lib64/egl/eglSubDriverAndroid.so /odm/lib64/egl/eglSubDriverAndroid.so
I also find that the droid-config submodule is “too new” according to hadk-hot.
I reset that to the recommended sha and make some corresponding changes to the files on device,
To my surprise, after reboot… Lineage tries to start again. (logo appears, but it doesn’t start)
This may mean that I only get a couple of boots before the slot is changed → my bootctl service does not correctly mark the system as booted.
I force reboot it to recovery and in /data, .stowaways is still there. Flashing hybris-boot:
Writing ‘boot_b’ OKAY [ 0.705s]
Indeed, it switched slot. Let’s hope super is not gone again.
I have a healthcheck process that restarts, from /system/etc/init/flags_health_check.rc
on property:sys.boot_completed=1
setprop persist.device_config.attempted_boot_count 0
on property:sys.init.updatable_crashing=1
exec - system system -- /system/bin/flags_health_check UPDATABLE_CRASHING
That last line. But I see on the line above that boot_completed resets some counter.
Indeed, persist.device_config.attempted_boot_count returns 1 (after it just switched the slot).
Back to linkerconfig. There’s a patch by Elros to make the switch from bootstrap to default, linked above.
Before that:
# ls /linkerconfig/ld.config.txt -l
-rw-r--r-- 1 root root 92135 Mar 31 10:50 /linkerconfig/ld.config.txt
# ls /linkerconfig/default/ld.config.txt -l
-rw-r--r-- 1 root root 4907 Mar 31 10:49 /linkerconfig/default/ld.config.txt
# ls /linkerconfig/bootstrap/ld.config.txt -l
-rw-r--r-- 1 root root 4907 Mar 31 10:49 /linkerconfig/bootstrap/ld.config.txt
After: no default or bootstrap subfolders. ld-config.txt still is 92kib
Let’s “fix” that time_daemon: adding to disabled_services.rc
service time_daemon /vendor/bin/time_daemon_HYBRIS_DISABLED
override
disabled
I also find that the droid-config submodule is “too new” according to hadk-hot.
I reset that to the recommended sha and make some corresponding changes to the files on device,
Let’s try harder (this is the commit to “revert” on device)
/ # rm /usr/lib/systemd/user/jolla-actdead-charging.service.d/50-compositor.conf
/ # rm /usr/lib/systemd/user/jolla-startupwizard-pre-user-session.service.d/50-compositor.conf
/ # rm /usr/lib/systemd/user/lipstick.service.d/50-compositor.conf
Ok, now I do get bootanimation + surfaceflinger to work (It’s another sanity test - just start these two (disabled) services by hand to see something on screen. Lineage un-smile in this case.)
But not minimer, that doesn’t turn on the screen.
03-31 04:12:01.936 7994 8050 I Adreno : IsValidNativeBuffer: Buffer has a NULL handle
03-31 04:12:01.936 7994 8050 I Adreno : DequeueBuffer: Dequeued Buffer is not valid
03-31 04:12:01.936 5980 8001 W SDM : DisplayBase::SetVSyncState: Can't enable vsync when display 54-0 is powered off or SecureDisplay/TUI in progress
7995 is minimer
8001 is /vendor/bin/hw/vendor.qti.hardware.display.composer-service
Fortunately I have the sources for that part: android_hardware_qcom_display/sdm/libs/core/display_base.cpp at lineage-18.1-caf-sm8350 · LineageOS/android_hardware_qcom_display · GitHub
Also, I can strace -p 8001.
With a similar command, and another PID, I get a “irisConfigureGetIoctl” error.
Strace shows the ioctl, but how to decrypt?
ioctl(13, _IOC(_IOC_WRITE, 0x64, 0x90, 0x10), 0x7fe3bc1fe8) = -1 EINVAL (Invalid argument)
Nevermind. This ioctl error happens with surfaceflinger too.
However, instead of “SetVSyncState” error, when I start bootanim I get some other messages:
03-31 06:00:00.826 5988 5988 E FMQ : grantorIdx must be less than 3
03-31 06:00:00.828 5988 6899 I SDM : HWCColorModeStc::ApplyCurrentColorModeWithRenderIntent: Applying Stc mode (gamut 1 gamma 1 intent 1), curr mode 7, render intent 0, hdr present 0
logcat when minimer connects to composer:
HWCSession::RegisterCallback: Registering callback: Hotplug
HWCSession::RegisterCallback: Hotplugging primary...
HWCSession::RegisterCallback: Handling built-in displays...
HWCSession::RegisterCallback: Handling pluggable displays...
HWCSession::HandlePluggableDisplays: Handling hotplug...
HWCSession::HandlePluggableDisplays: Handling hotplug... Done.
HWCSession::RegisterCallback: Registering callback: Refresh
HWCSession::RegisterCallback: Registering callback: Vsync
DisplayBase::SetDisplayState: Set state = 1, display 54-0, teardown = 0
DisplayBase::SetDisplayState: Same state transition is requested.
logcat when surfaceflinger connects to composer:
HWCSession::RegisterCallback: Registering callback: Hotplug
HWCSession::RegisterCallback: Hotplugging primary...
HWCColorModeStc::GetColorModeCount: Supported color mode count = 4
HWCColorModeStc::GetColorModes: Color mode = 0 is supported
HWCColorModeStc::GetColorModes: Color mode = 7 is supported
HWCColorModeStc::GetColorModes: Color mode = 9 is supported
HWCColorModeStc::GetColorModes: Color mode = 12 is supported
HWCColorModeStc::GetRenderIntentCount: mode: 0 supported rendering intent count = 1
HWCColorModeStc::GetRenderIntents: Color mode = 0 is supported with render intent = 0
HWCColorModeStc::GetRenderIntentCount: mode: 7 supported rendering intent count = 1
HWCColorModeStc::GetRenderIntents: Color mode = 7 is supported with render intent = 0
HWCColorModeStc::GetRenderIntentCount: mode: 9 supported rendering intent count = 2
HWCColorModeStc::GetRenderIntents: Color mode = 9 is supported with render intent = 0
HWCColorModeStc::GetRenderIntents: Color mode = 9 is supported with render intent = 1
HWCColorModeStc::GetRenderIntentCount: mode: 12 supported rendering intent count = 1
HWCColorModeStc::GetRenderIntents: Color mode = 12 is supported with render intent = 2
HWCSession::RegisterCallback: Handling built-in displays...
HWCSession::RegisterCallback: Handling pluggable displays...
HWCSession::HandlePluggableDisplays: Handling hotplug...
HWCSession::HandlePluggableDisplays: Handling hotplug... Done.
HWCSession::RegisterCallback: Registering callback: Refresh
HWCSession::RegisterCallback: Registering callback: Vsync2.4
HWCSession::RegisterCallback: Registering callback: VsyncPeriodTimingChanged
HWCSession::RegisterCallback: Registering callback: SeamlessPossible
DisplayBase::SetDisplayState: Set state = 1, display 54-0, teardown = 0
DisplayBase::SetDisplayState: Same state transition is requested.
Notice Vsync vs Vsync 2.4
And other callbacks registered. Plus, getting color modes, and rendering intents (whatever that means)
Surfaceflinger… hhm.
There’s qt5-qpa-surfaceflinger-plugin recently adapted by nephros probably fixing build.
Maybe I should use that? But let’s not give up on hwcomposer yet.
Let’s disable minisfservice → this seems to make lipstick not fail at boot time. No screen changes though.
(‘/vendor/bin/thermal-engine’ makes some noise like timed, I need to disable that too)
Bootctl seems to not start
droid-bootctl.service: Main process exited, code=exited, status=70/n/a
Trying this fix: GitHub - mer-hybris/hadk-faq: FAQ for Sailfish OS porting guide (HADK)
It seems to work - hopefully I wont’ have reboots that switch slots anytime soon…
Well, still no display, but less time fighting reboots:)