It kindof is, it is already installable. Just bugs to hunt down and documentation to update.
Mainly wifi power drain and video playback are critical, but not blocking installation.
2 Likes
I put the ZF8 and the Xperia 10 III side by side and picked them both up, and that made me pack up the Xperia and send it back.
It feels much more premium, the form factor is much nicer (for me, other people will most obviously not like a phone as small as this) and the prospect of (possibly) passable pictures is also a reason.
You see: I put all my hope in you and your skills 
No, seriously, I’m looking forward to when it finally becomes unlockable again.
(And since the end of Q3 is still far, there is probably a chance for working video playback 
)
I’m sure thay time will allow, if you didn’t have a chance to fix this until then. As I am waiting 2, 3 or 4 for ASUS, a couple of days wouldn’t add so much delay…
At least they are doing something. The error code inside the unlocking tool changed.
Most probably they are preparing the Zenfone 10 launch…
Day 27
(I may have skipped Day 26, it was filled with droidmedia debugging, I might come back to the notes,)
Let’s build the Lineage 19.1 kernel. Maybe it has better wifi, maybe video decoding.
Merging it gives hundreds of conflicts.
So I choose to just cherry-pick my commits
[HABUILD_SDK]$ git checkout -b hybris-19.1 origin/lineage-19.1
[HABUILD_SDK]$ git cherry-pick 9a1ba77f8b2b…eb682b239d51
[HABUILD_SDK]$ make -j$(nproc --all) hybris-hal libui_compat_layer
Ramdump on first boot…
And I tought I had everything prepared… for example, the /lib/modules already had the folder with the new kernel modules copied.
And init_enter_debug was created to stop and see if telnet works before any other crash.
As usual, there are no /sys/fs/pstore logs
Grepping thorugh this kernel there is no asusdebug.c either.
I can:
1, build a recovery-only Lineage img, to ease my debugging
2. enable back some of the kernel arguments I commented out (as they were redundant with vendor_boot)
3. run mer kernel checker to see if I merged some configs wrongly
4. build a new vendor_img too (that has dtb.img inside) and/or a dtbo.img
That last option seems the most promising - the crash is so early it could be from dtb.
[HABUILD_SDK]$ make -j$(nproc --all) vendorbootimage dtboimage
Hmm the dtbo and dtb imgs are not re-generated.
And unpacking the vendor_boot.img looks like I need to do step 2 avove too, too few kernel arguments now:)
But how to make dtb.img and dtbo.img?
Well, make dtboimage dtbimage doesn’t do anything, so I remove the targets and run them again.
The dtbo.img seems to be of the same size as before, but the dtb one is very different.
Chances are vendor_boot is the only one I need to re-flash…
$ diff <(xxd /mnt/datas/sake/backup/dtbo.img) <(xxd dtbo.img)
181273,181277c181273,181277
< 002c4180: 0000 0000 6474 626f 7633 f305 4129 686a ....dtbov3..A)hj
< 002c4190: 2f2d ff64 5fef f3b7 b93d b05b 2a0a 6ff4 /-.d_....=.[*.o.
< 002c41a0: 0b60 cb3d 7aa5 0c0b b30a 5973 f9a6 5b3b .`.=z.....Ys..[;
< 002c41b0: d500 7bc8 523e 4ba5 fd36 285b 6efe 88e3 ..{.R>K..6([n...
< 002c41c0: 3217 01dd fe97 9780 0000 0000 0000 0000 2...............
---
> 002c4180: 0000 0000 6474 626f 1d1e c038 232a c9e7 ....dtbo...8#*..
> 002c4190: dc03 e709 562b a5de 3483 103d f747 2e7f ....V+..4..=.G..
> 002c41a0: 3230 372f 67d2 d26f e429 b093 704d f895 207/g..o.)..pM..
> 002c41b0: 81c9 ec7e 1725 13ad 8e2f 1f66 4ef0 96fe ...~.%.../.fN...
> 002c41c0: e368 515b 0003 114f 0000 0000 0000 0000 .hQ[...O........
$ sudo fastboot flash vendor_boot vendor_boot.img
$ sudo fastboot boot hybris-recovery.img
Stuck at logo, more than 60 seconds.
Let’s just flash it instead of booting it, and also flash dtbo.
No good result.
Actually, even worse, what I think it is “stuck at logo” before is actually instant reboot to bootloader with the logo stuck on screen.
I look at the (still downloadable) vendor_boot and boot images for lineage 19.1 and surprise! they use image header v4, and gzip compression,
So I am alone with lz4 and header 3…?
Let’s give this kernel one more try: to split the parameters between vendor_boot and hybris-boot images, I selectively comment out some for one build and the others for the other build.
Neither does this idea fly.
So there is something in this kernel that crashes, in those …35661 commits.
Using meld to diff
/mnt/datas/sake/lineage/kernel/asus/sm8350
/mnt/datas/sake/hadk/kernel/asus/sm8350
Maybe I need to update BOARD_VENDOR_KERNEL_MODULES_LOAD in BoardConfig.mk ?
Wait, what do these options did?
CONFIG_POWER_RESET_QCOM_DOWNLOAD_MODE=y
CONFIG_POWER_RESET_QCOM_DOWNLOAD_MODE_DEFAULT=y # this is now gone
CONFIG_POWER_RESET_QCOM_REBOOT_REASON=y
Woow Qualcomm download mode enabled by default - CONFIG_QCOM_SCM_DOWNLOAD_MODE_DEFAULT - - kernelconfig.io
This is not the same config, but the description reminds me of Ramdump mode.
It may mean that disabling all of the above might disable ramdump screen (and get a regular reboot;)
Some power-saving new flags:
CONFIG_QCOM_RIMPS=y
lead me to
# Increase sleep duration (seconds) during IMPS
# 0 implies no periodic wake up from IMPS. Periodic wakeup is
# unnecessary if Idle Scan is disabled.
gImpsModSleepTime=0
Maybe I should try those on my current kernel.
Some GKI stuff, CONFIG_MSM_PERFORMANCE_QGKI is now explicitely enabled.
“new” entry
# CONFIG_PSTORE_DEFLATE_COMPRESS is not set
I am interesting in anything pstore related of course.
But the kernel diff is huge and inscrutinable…
…
Let’s search more about QCOM download mode.
A tool named QPST is mentioned on xda for example.
However, the tool is used with some params I don’t understand to recover a bricked device…
I am more interesting in downloading the error log.
Like Linaro / qcomlt / qdl · GitLab
Let’s flash vendor_boot from before (lineage 18.1)
qdl is available in Archlinux AUR
But it is not usable without mbn files.
QXDM5 / QCAT / PCAT / QDART / QRCT … scr*w it, closed tools to inspect my device.
Let’s disable those DOWNLOAD configs and reflash, see if it still calls bootloader ramdump…
Noope, still see the ramdump on whatever bug I’m stepping on and I don’t have telnet to run dmesg…
Disabling some more (CONFIG_QCOM_MINIDUMP, CONFIG_QCOM_MICRODUMP) but still ramdump screen ffs.
I found this dtsi def, msm-imem-dload-type
Used in drivers/power/reset/msm-poweroff.c too, not only drivers/power/reset/qcom-dload-mode.c
So for now my experiment to just upgrade the kernel is a failure and I cannot telnet and debug the error.
1 Like
I’m hitting the Day 29 milestone this season and was not able to coherently log what things I’ve tried (and failed) with video playback debugging and the lineage-19.1 kernel.
While I was reaching a bottom, @Mister_Magister has gone up to speed with building the system and hacking the kernel for this device. We have already made changes to the missing build steps and he already contributed a pixel_ratio fix (that makes the device fit 5 columns instead of 4 of everything - app grid and quick toggles alike).
But most importantly, Mister_Magister has made some serious advancements in enabling the device to sleep and the Wifi driver to consume less power. It still consumes more than on Android, mostly if your screen is on, but the “punishment” for forgetting the Wifi on for the device is like gone.
Another interesting development was that we noticed that his own Microtube does not have video playback issues while streaming (whereas the browser has, and the gallery has even more severe ones). I can only hope that this piece of information will help us unlock something there.
To be fair, Keijo also has the device - but just as other users in this post, is yet to be unlocked.
So now the number of porters becomes equal to the number of potential users - we should be in a good place:)
4 Likes
It seems that ASUS is indeed planning to enable the unlock again. I had already lost confidence, but here https://zentalk.asus.com/t5/zenfone-9/asus-quot-unlock-device-app-quot/m-p/375548/highlight/true#M4942 ASUS confirms again that the update of the tool is planned for Q3 when asked (whether the plans are still up to date or have changed because customer services of different countries give different information).
So let’s see who is faster: ASUS with their unlocking tool or you fixing the video issue 
Thanks for the update @multispeedlurker , let’s hope for the best.
In the video decoding department I have at least found a way to force software decoding with Gallery and gstreamer-droid apps in general for avc, but still fight with the browser decoding.
1 Like
Day 29
Finally a good html video test site: HTML5 audio/video tester - File type player - MIME type tester
With GECKO_CAMERA_DROID_NO_MEDIA_BUFFER=1 browser crashes sometimes on vp9 as on spring-vp9-vorbis.webm above.
When it doesn’t crash, it seems to display some color artifacts at the buttom of the frame or completely offset color planes for some of the videos in the test site above.
Crash is:
#7 0x0000007e6ea84638 in gecko::codec::DroidVideoDecoder::dataAvailable(DroidMediaCodecData*) () from /usr/lib64/gecko-camera/plugins/libgeckocamera-droid.so
Segfault at memcpy () at ../sysdeps/aarch64/memcpy.S:182
This one seems to be patched into geck-dev itself.
Logcat before crash:
07-14 12:45:57.505 22292 22423 D CCodecBuffers: [c2.qti.vp9.decoder#760:2D-BB-Output] popFromStashAndRegister: output format changed to AMessage(what = 0x00000000) = {
07-14 12:45:57.505 22292 22423 D CCodecBuffers: int32_t android._video-scaling = 1
07-14 12:45:57.505 22292 22423 D CCodecBuffers: Rect crop(0, 0, 2047, 857)
07-14 12:45:57.505 22292 22423 D CCodecBuffers: int32_t color-standard = 130816
07-14 12:45:57.505 22292 22423 D CCodecBuffers: int32_t color-range = 0
07-14 12:45:57.505 22292 22423 D CCodecBuffers: int32_t color-transfer = 65791
07-14 12:45:57.505 22292 22423 D CCodecBuffers: int32_t android._dataspace = 12648448
07-14 12:45:57.505 22292 22423 D CCodecBuffers: int32_t width = 2048
07-14 12:45:57.505 22292 22423 D CCodecBuffers: int32_t feature-secure-playback = 0
07-14 12:45:57.505 22292 22423 D CCodecBuffers: int32_t frame-rate = 30
07-14 12:45:57.505 22292 22423 D CCodecBuffers: Buffer hdr10-plus-info = {
07-14 12:45:57.505 22292 22423 D CCodecBuffers: }
07-14 12:45:57.505 22292 22423 D CCodecBuffers: int32_t height = 858
07-14 12:45:57.505 22292 22423 D CCodecBuffers: int32_t max-height = 2160
07-14 12:45:57.505 22292 22423 D CCodecBuffers: int32_t max-width = 4096
07-14 12:45:57.505 22292 22423 D CCodecBuffers: string mime = "video/raw"
07-14 12:45:57.505 22292 22423 D CCodecBuffers: int32_t priority = 0
07-14 12:45:57.505 22292 22423 D CCodecBuffers: int32_t rotation-degrees = 0
07-14 12:45:57.505 22292 22423 D CCodecBuffers: int32_t sar-height = 1
07-14 12:45:57.505 22292 22423 D CCodecBuffers: int32_t sar-width = 1
07-14 12:45:57.505 22292 22423 D CCodecBuffers: Buffer hdr-static-info = {
07-14 12:45:57.505 22292 22423 D CCodecBuffers: 00000000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
07-14 12:45:57.505 22292 22423 D CCodecBuffers: 00000010: 00 00 00 00 00 00 00 00 00 .........
07-14 12:45:57.505 22292 22423 D CCodecBuffers: }
07-14 12:45:57.505 22292 22423 D CCodecBuffers: int32_t android._color-format = 2135033992
07-14 12:45:57.505 22292 22423 D CCodecBuffers: int32_t color-format = 19
07-14 12:45:57.505 22292 22423 D CCodecBuffers: Buffer *image-data = 0x7e5c0209d0
07-14 12:45:57.505 22292 22423 D CCodecBuffers: int32_t stride = 2048
07-14 12:45:57.505 22292 22423 D CCodecBuffers: int32_t slice-height = 858
07-14 12:45:57.505 22292 22423 D CCodecBuffers: }
07-14 12:45:57.505 22292 22433 I DroidMediaCodec: Format changed from codec
07-14 12:45:57.505 22292 22433 I DroidMediaCodec: notifySizeChanged: width = 2048, height = 858
07-14 12:45:57.584 22292 22421 D AsyncCodecSource: [c2.qti.vp9.decoder] Output format changed! Buffers remaining: 0
Without GECKO_CAMERA_DROID_NO_MEDIA_BUFFER=1, no crash, but error later:
Initially:
> 07-14 13:00:52.800 24250 24346 D CCodec : setup formats input: AMessage(what = 0x00000000) = {
07-14 13:00:52.800 24250 24346 D CCodec : int32_t feature-secure-playback = 0
07-14 13:00:52.800 24250 24346 D CCodec : int32_t frame-rate = 30
07-14 13:00:52.800 24250 24346 D CCodec : int32_t height = 858
07-14 13:00:52.800 24250 24346 D CCodec : int32_t max-input-size = 16588800
07-14 13:00:52.800 24250 24346 D CCodec : string mime = "video/x-vnd.on2.vp9"
07-14 13:00:52.800 24250 24346 D CCodec : int32_t priority = 0
07-14 13:00:52.800 24250 24346 D CCodec : int32_t profile = 1
07-14 13:00:52.800 24250 24346 D CCodec : int32_t width = 2048
07-14 13:00:52.800 24250 24346 D CCodec : Rect crop(0, 0, 2047, 857)
07-14 13:00:52.800 24250 24346 D CCodec : } and output: AMessage(what = 0x00000000) = {
07-14 13:00:52.800 24250 24346 D CCodec : int32_t android._video-scaling = 1
07-14 13:00:52.800 24250 24346 D CCodec : Rect crop(0, 0, 2047, 857)
07-14 13:00:52.800 24250 24346 D CCodec : int32_t color-standard = 130817
07-14 13:00:52.800 24250 24346 D CCodec : int32_t color-range = 2
07-14 13:00:52.800 24250 24346 D CCodec : int32_t color-transfer = 65791
07-14 13:00:52.800 24250 24346 D CCodec : int32_t android._dataspace = 260
07-14 13:00:52.800 24250 24346 D CCodec : int32_t width = 2048
07-14 13:00:52.800 24250 24346 D CCodec : int32_t feature-secure-playback = 0
07-14 13:00:52.800 24250 24346 D CCodec : int32_t frame-rate = 30
07-14 13:00:52.800 24250 24346 D CCodec : Buffer hdr10-plus-info = {
07-14 13:00:52.800 24250 24346 D CCodec : }
07-14 13:00:52.800 24250 24346 D CCodec : int32_t height = 858
07-14 13:00:52.800 24250 24346 D CCodec : int32_t max-height = 2160
07-14 13:00:52.800 24250 24346 D CCodec : int32_t max-width = 4096
07-14 13:00:52.800 24250 24346 D CCodec : string mime = "video/raw"
07-14 13:00:52.800 24250 24346 D CCodec : int32_t priority = 0
07-14 13:00:52.800 24250 24346 D CCodec : int32_t rotation-degrees = 0
07-14 13:00:52.800 24250 24346 D CCodec : int32_t sar-height = 1
07-14 13:00:52.800 24250 24346 D CCodec : int32_t sar-width = 1
Then around the error
07-14 13:01:10.364 24250 24350 E Codec2-types: Null BaseBlock::nativeBlock.
07-14 13:01:10.364 24250 24350 E Codec2-types: Invalid WorkBundle::baseBlocks[0].
07-14 13:01:10.403 24250 24350 E qdgralloc: importBuffer: Unable to clone handle
07-14 13:01:10.404 24250 24350 E GraphicBufferAllocator: Failed to allocate (2048 x 864) layerCount 1 format 2141391878 usage 30010100: 5
07-14 13:01:10.407 24250 24350 E BufferQueueProducer: DroidMediaCodecBufferQueue dequeueBuffer: createGraphicBuffer failed
07-14 13:01:10.408 6482 24353 D C2BqBuffer: cannot dequeue buffer -12
and
07-14 13:01:11.505 24250 24342 W DroidMediaCodec: A buffer we don’t know about is being finished!
07-14 13:01:11.509 24250 24356 E DroidMediaCodec: Got EOS
07-14 13:01:11.513 24250 24345 D CCodecBufferChannel: [c2.qti.vp9.decoder#207] MediaCodec discarded an unknown buffer
07-14 13:01:11.516 24250 24345 E MediaCodec: Codec reported err 0x80000000, actionCode 0, while in state 9
07-14 13:01:11.516 24250 24345 D SurfaceUtils: disconnecting from surface 0x7e58011350, reason disconnectFromSurface
07-14 13:01:11.516 24250 24345 W MediaCodec: kWhatStopCompleted: presumably an error occurred earlier, but the operation completed anyway. (last reply origin=kWhatError:STOPPING)
07-14 13:01:11.519 6482 17672 I QC2Comp : NOTE: Release returning: 0 (OK=0)
Notice the color-standard, color-range and android._dataspace are different.
As in one of the previous days (27?), the dataspace 12648448 from NO_MEDIA_BUFFERS=1 is 0b110000010000000000000000 which is BT709, and 260 is BT709 too.
color-range is 0 with NO_MEDIA_BUFFERS and 2 without, which might be RANGE_UNSPECIFIED and RANGE_LIMITED from codec2/core/include/C2Config.h
color-standard: 0x1FF01 vs 0x1FF00
return kColorStandardVendorStart + primaries + coeffs * 0x100;
says libstagefright/foundation/ColorUtils.cpp
vendorStart is 0x10000, coeffs is probably FF, so primaries is 0 vs 1
PrimariesUnspecified in NO_MEDIA_BUFFER=1 case and PrimariesBT709_5 in the other one, according to headers/media_plugin/media/hardware/VideoAPI.h
Why is this? Let’s switch on LOGV
# setprop log.tag VERBOSE
Hmm… no clue.
Tried this lineage 20 commit w/o success CCodecBuffers: add support for reallocating graphic buffers · LineageOS/android_frameworks_av@a39882b · GitHub
Back to gecko-camera, using GECKO_CAMERA_DEBUG=1
For example, for HTML5 audio/video tester - File type player - MIME type tester I get
Jul 15 21:54:09 Zenfone8 gecko-camera[3938]: droid-codec configureOutput:766 – Configuring converter for stride:480 slice-height: 270 top: 0 left:0 width: 480 height: 270 format: 2141391876
Format 2141391876 is QOMX_COLOR_FormatYUV420PackedSemiPlanar32m.
(My tucana returns format 21 for the same video?, which is OMX_COLOR_FormatYUV420SemiPlanar!)
The dataAvailable that’s crashing only has this:
if (m_decoderListener && m_mapper.ready()) {
const YCbCrFrame frame = m_mapper.mapYCbCr(decoded);
m_decoderListener->onDecodedYCbCrFrame(&frame);
}
The DroidVideoFrameYUVMapper::mapYCbCr is in gecko-camera, while onDecodedYCbCrFrame is in the above gecko-dev patch.
The same DroidVideoFrameYUVMapper also has setFormat that reads like:
m_template.y = 0;
m_template.width = md->width;
m_template.height = rect->bottom - rect->top;
#define _ALIGN_SIZE(sz, align) (((sz) + (align) - 1) & ~((align) - 1))
if (md->hal_format == c.QOMX_COLOR_FormatYUV420PackedSemiPlanar32m) {
unsigned int height = _ALIGN_SIZE(md->height, 32);
m_template.yStride = m_template.cStride = _ALIGN_SIZE(md->width, 128);
m_template.cb = (const uint8_t *)(m_template.yStride * height);
m_template.cr = (const uint8_t *)(m_template.yStride * height + 1);
m_template.chromaStep = 2;
}
Above you can see our video color format. m_template is of type
struct YCbCrFrame {
const uint8_t *y;
const uint8_t *cb;
const uint8_t *cr;
uint16_t yStride;
uint16_t cStride;
uint16_t chromaStep;
uint16_t width;
uint16_t height;
uint64_t timestampUs;
};
The frame is read from gecko-dev like this:
VideoData::YCbCrBuffer buffer;
// Y plane.
buffer.mPlanes[0].mData = const_cast<uint8_t*>(frame->y);
buffer.mPlanes[0].mStride = frame->yStride;
buffer.mPlanes[0].mWidth = frame->width;
buffer.mPlanes[0].mHeight = frame->height;
buffer.mPlanes[0].mOffset = 0;
buffer.mPlanes[0].mSkip = 0;
// Cb plane.
buffer.mPlanes[1].mData = const_cast<uint8_t*>(frame->cb);
buffer.mPlanes[1].mStride = frame->cStride;
buffer.mPlanes[1].mWidth = (frame->width + 1) / 2;
buffer.mPlanes[1].mHeight = (frame->height + 1) / 2;
buffer.mPlanes[1].mOffset = 0;
buffer.mPlanes[1].mSkip = frame->chromaStep - 1;
// Cr plane.
buffer.mPlanes[2].mData = const_cast<uint8_t*>(frame->cr);
buffer.mPlanes[2].mStride = frame->cStride;
buffer.mPlanes[2].mWidth = (frame->width + 1) / 2;
buffer.mPlanes[2].mHeight = (frame->height + 1) / 2;
buffer.mPlanes[2].mOffset = 0;
buffer.mPlanes[2].mSkip = frame->chromaStep - 1;
gfx::IntRect pictureRegion(0, 0, frame->width, frame->height);
RefPtr<MediaData> data = VideoData::CreateAndCopyData(
mInfo, mImageContainer, inputFrame->mOffset,
inputFrame->mTime, inputFrame->mDuration,
buffer, inputFrame->mKeyframe, inputFrame->mTimecode,
pictureRegion, mImageAllocator);
And the memcpy crash is probably the CreateAndCopyData above.
That is here and it calls
if (!VideoData::SetVideoDataToImage(videoImage, aInfo, aBuffer, aPicture,
true /* aCopyData */)) {
which calls PlanarYCbCrData data = ConstructPlanarYCbCrData(aInfo, aBuffer, aPicture); and PlanarYCbCrImage::CopyData()
Ok, back to understanding YUV SemiPlanar: this is a very good explanation how the interleaving works:
Reading that, I think I understand what chromastep is too:)
However this does not make me understand how my color format works differently than the one without 32m suffix. Where do the 128 and 32 alignments come from?
There’s an interesting comment in gecko-camera encoder though, I should follow up on that…
Day 30
hardware/qcom-caf/sdm845/media/mm-video-v4l2/vidc/vdec/inc/omx_vdec.h lists the 32m YUV color format
But I don’t have that file for sm8350
vendor/etc/video_system_specs.json has
// control to force enable linear color format for decoder
// if this is enable, then decoder will produce linear color format output.
// it is bitmask:
// 0x0: no override,
// 0x1: enable 8 bit: linear format. 10 bit: compressed format
// 0x2: 8 bit: compressed format. 10 bit: linear format
// 0x3: 8 bit: linear format. 10 bit: linear format
"dec_linear_color_format": 0,
(also the instruction to kill media.hwcodec if you change it)
The media.hwcodec uses some libs from /vendor/lib/libqcodec2*.so
One of them (/vendor/lib/libqcodec2_v4l2codec.so) has this string qti-ext-dec-linear-color-format
Which corresponds to dec_linear_color_format above.
Other strings are:
dec-hdr-disable
qti-ext-dec-picture-order
qti-ext-dec-info-mbi
qti-ext-dec-info-sei_recovery
qti-ext-dec-info-misr
qti-ext-dec-info-crop
qti-ext-dec-info-interlace
qti-ext-dec-output-render-frame-rate
qti-internal-ext-dec-output-refresh-rate
qti-ext-dec-thumbnail-mode
qti-ext-dec-frame-rate
qti-ext-dec-frame-pack-s3d
qti-ext-dec-panscan
qti-ext-dec-info-aspect-ratio
qti-ext-dec-frame-qp
qti-ext-dec-linear-color-format
qti-ext-dec-caps-vt-driver-version
qti-ext-dec-forceNonUBWC
qti-ext-dec-heif-mode
qti-ext-dec-timestamp-reorder
qti-ext-dec-drop-corrupt
# mount -o ro,bind /etc/video_system_specs.json /vendor/etc/video_system_specs.json
Now let’s change the dec_linear_color_format to 3 first and kill media.hwcodec:
Here’s the hwcodec service startup log: Ubuntu Pastebin
Oops, no change to 3.
# mount -o ro,bind /etc/video_system_specs.json /vendor/etc/media_lahaina/video_system_specs.json
Ok, now 3 shows up in logs.
Let’s use qti-ext-dec-forceNonUBWC now.
Mmm… no difference. But that 3^^ above changed the way playback works with gst-droid … maybe a bit like in the browser (it works okish until it halts)
Btw, gecko-camera NO_MEDIA_BUFFER has no problem playing back OMX_COLOR_FormatYUV420Flexible (0x0x7F420888)
One thing that may happen is that QOMX_COLOR_FormatYUV420PackedSemiPlanar32m may actually have the two planes split at different memory locations. This means that the chance of it crashing is 99.99% because the second plane is off.
This would be pretty messy, as only CCodec2 API has layers access for multi-plane, the currently used MediaBuffer only provides one pointer at a time. It may also mean that the playback with NO_MEDIA_BUFFER=0 works for some time because each second buffer is the UV plane, but timestamps expire after some time since we’re reading 2 times slower… ?
In that case, reading the NO_MEDIA_BUFFER=0 queue implementation I think
m_queue->setMaxAcquiredBufferCount(2);
Could be 4, and
m_queue->setDefaultBufferFormat(HAL_PIXEL_FORMAT_YCBCR_420_888);
could be HAL_PIXEL_FORMAT_IMPLEMENTATION_DEFINED …?
Hmm… GraphicBuffer sp from NO_MEDIA_BUFFER=0 implementation has getLayerCount()…
Well, layer count: 1 so the theory does not hold?.
While logging the graphicBuffer stuff I notice one thing that turned out important… there was a new graphicBuffer for every frame.
The droidmedia system was (correctly before this?) assuming that the buffer would be recycled and that messages would have no graphic buffer if they recycled a previous one.
Aaand the first droidmedia patch that works in the browser: Buffers are not always recycled automatically by b100dian · Pull Request #111 · sailfishos/droidmedia · GitHub
This should fix browser video playback through gecko-camera !
This does not fix the gst-droid based players yet (Gallery, Quickddit, Gagbook, you name it)…
I still have the backup plan for enabling SW decoded AVC for them though.
2 Likes
As much as I may regret it - I have now sent the ZF8 back to the seller (several months unused…). The return policy has been very generous, but in a week the deadline would have expired. I just don’t feel like waiting for ASUS to change their mind.
But maybe I’ll come back to a ZF8 at some point, if ASUS proves to be more reliable than currently foreseeable 
Very sad But I really enjoyed following your livecast. Really exciting and nice that it worked out so well for you!
Hey, I’m sorry ASUS let you down. I hope they get their … stuff together.
(when seeing a reply notification I hoped it was a news about their unlocking service :grin : )
I very much appreciate your support (and also @lolek 's, and everyone who enjoyed this thread) throughout this journey which was not short, not a walk in the park : )
There is still stuff to be done, but the basics are there, workarounds exists and I will soon be daily driving this too.
Maybe you make that Jolla store contribution at least - they made this whole thing1 that can be shared on other devices, after all.
Cheers!
1 not the whole OS, but still this is the farthest coming linux distro for hybris adaptations.
2 Likes
I already bought a license for the Xperia 10 III
1 Like
thanks man for this large amount of information.
I checked how’s the status with Zenfone and it seems there’s some mobo problems with the first batch of the phones. Of course without contacting Asus you won’t know if the phone you bought is still vulnerable or not for the memdump issue as it’s HW problem.
I cannot speak for all the devices, but my device, which I initially identified as being produced in an early batch, only showed the ramdump screen when I triggered a kernel fault.
It was just a “let’s enter this secret1 debug mode” instead of a restart.
If you get a persistent loop with that screen without the possibility to flash other kernel then yes, you’re toast.
But I always had the option to reboot to bootloader and reflash something else (of course, anything, since I managed to unlock the bootloader timely).
So I would say that a HW error is the less probable issue… my bet is on a software error + users locked out (not owning the device) - that’s the more probable one.
But of course, all here is written without any guarantees of any "fitness for any purpose"™ so take it with a grain of salt.
1 Mister_Magister discovered that the ramdump screen is Qualcomm’s EDL mode (QDL?), and you can use https://github.com/bkerler/edl to download… 8GB of ram… dump:) to actually grep your memory for error logs.
1 Like
Wow… haven’t seen this log earlier - really cool!
1 Like
Oops… I sent my older device to service and switched the SIM cards to daily drive the Zenfone.
'Twas very nice, until I got a call and there was no audio.
What I called a “wonder” in Day 3 may be a struggle to bisect… although I did try to make notes of all my changes, there is a slight possibility of me having some softlinks on the device that did not make it to the repo when audio in calls worked (I even followed-up and made it work with bluetooth so I am 100% sure I wasn’t dreaming).
There is a slight possibility that the two (different operator) SIMs are differing in behavior, I’ll test that as soon as my other device is back, but that isn’t great news either.
So this would be like Day 1, Season 3.
I tried to find the reason nothing was heard when in a call. There must have been some on-device changes I didn’t commit, or some changes I did after the phonecall test.
Trying to revert what changes I had from April 22 till today one by one did not get me anywhere.
I also tried stracing pulseaudio with
HYBRIS_USE_VENDOR_NAMESPACE=yes strace -o outfile.txt -f -s2048 pulseaudio --daemonize=no -n --file=/etc/pulse/arm_droid_default.pa -vvvvvvvvvv
and did found that some .so were complaining about namespaces and some were searched for but not found.
I came up with something like
# Instead of ln -s
for library in libandroidicu libicuuc libicui18n libnativehelper; do
rm -f /odm/lib/${library}.so
touch /odm/lib/${library}.so
mount -o bind /apex/com.android.art/lib/${library}.so /odm/lib/${library}.so
done
for library in libaudioroute; do
rm -f /odm/lib/${library}.so
touch /odm/lib/${library}.so
mount -o bind /apex/com.android.vndk.v30/lib/${library}.so /odm/lib/${library}.so
done
rm -f /odm/lib64/libaudioroute.so
touch /odm/lib64/libaudioroute.so
mount -o ro,bind /apex/com.android.vndk.v30/lib64/libaudioroute.so /odm/lib64/libaudioroute.so
rm -f /usr/libexec/droid-hybris/system/lib64/libdl_android.so
touch /usr/libexec/droid-hybris/system/lib64/libdl_android.so
mount -o ro,bind /apex/com.android.runtime/lib64/bionic/libdl_android.so /usr/libexec/droid-hybris/system/lib64/libdl_android.so
But that didn’t help either, although the errors were gone.
Well except for some libs complaining about being 32-bit instead of 64 bit. I tried to bind mount those too!
mount -o ro,bind /vendor/lib64/soundfx/libqcomvisualizer.so /vendor/lib/soundfx/libqcomvisualizer.so
mount -o ro,bind /vendor/lib64/libqtigef.so /vendor/lib/libqtigef.so
mount -o ro,bind /vendor/lib64/soundfx/libqcompostprocbundle.so /vendor/lib/soundfx/libqcompostprocbundle.so
#mount -o ro,bind /vendor/lib64/libadm.so /vendor/lib/libadm.so
mount -o ro,bind /vendor/lib64/hw/sound_trigger.primary.lahaina.so /vendor/lib/hw/sound_trigger.primary.lahaina.so
Didn’t help either. I even noticed some access to acdbdata was wrong and fixed it
/usr/bin/pulseaudio: [AcdbIsDeltaFileAvailable] failed to open delta file /data/vendor/audio/acdbdata/delta/ZS590KS_General_cal.acdbdelta
which is
-rw------- 1 audioser audio 0 Mar 14 2022 /data/vendor/audio/acdbdata/delta/ZS590KS_General_cal.acdbdelta
Let’s chmod those to be group readable. All /data/vendor/audio/acdbdata/delta/ is -rw-------
# chmod g+r /data/vendor/audio/acdbdata/delta/*
But those didnt help either.
While going through all the possible quirks to be set for pulseaudio-modules-droid here I remembered there was another piece of software called audiosystem-passthrough.
I did have it running as root for once, but also in calls, as defaultuser.
But stracing it while running did not reveal any activity. This was wrong.
Long story short, I’ve added to that debug command
AUDIOSYSTEM_PASSTHROUGH_TYPE=qti HYBRIS_USE_VENDOR_NAMESPACE=yes pulseaudio --daemonize=no -n --file=/etc/pulse/arm_droid_default.pa -vvvvvvvvvv
And made a call… and it worked!
Next thing was finding a file to stick that define into: And /etc/sysconfig/pulseaudio was just that.
Now I need to have this double-checked by Mister_Magister since, as stated above, I already have (again) other modifications on my device…
Also, I would have linked to know what happened. As much as I tried diffing through the changelogs of SFOS 4.4.0.72 vs 4.5.0.16 and the pulseaudio diffs on git, I do not have a clue how would it be possible for this to have worked 6 months ago but not today…
1 Like
It seems that ASUS is out of the race when it comes to smartphones that can be used for ports…
2 Likes