[Xiaomi Mi 5 ROMs, Kernels, Recoveries, & Other Dev] -+BB+-:
I'm using stock clang provided by AOSP in their build environment

adb shell cat /proc/version
Linux version 4.4.302-B--B-EAS (nobody@android-build) (Android (8490178, based on r450784d) clang version 14.0.6 (https://android.googlesource.com/toolchain/llvm-project 4c603efb0cca074e9238af8b4106c30add4418f6)) #1 SMP PREEMPT Thu Apr
6 18:02:16 CEST 2023

Even if you only played with GCAM settings you are the one by far with most experience on GCAM usage :)

I barely take photos, that's why I never tried various settings, if someday I will take a look at them I will do only for generating a noise model for our device, but it's not in my priority list.

We could do the same thing in a cleaner way editing camera media profiles in device tree, but I'm a little bit reluctant to do that because that change may cause issues to other camera apps that doesn't support H265, so overriding stock media profile is probably better for compatibility reasons

I was taking a look some days ago trying to understand why my Grus is so slow processing HDR photos and I ended up reading QCOM SDK docs, for what I understood Halide operations for custom GCAM doesn't work in any device, and probably will never work. I will try to explain in a simple way: Hexagon devices like our Gemini allow apps to take advantage to DSP processing, which is faster than CPU for some operations like HDR processing. In order to do that, you need two libs: libhalide_hexagon_host.so and libhalide_hexagon_remote_skel.so, these libs can be compiled by anyone using QCOM SDK, signed with a signing key for testing purposes and shipped with the apk. But the test signature does not work in production devices, it works only on debug-signed devices like Dragonboard platforms. Only OEMs or QCOM can sign a working lib for production devices, this means that Hexagon DSP processing sadly will probably never work on GCAM

NOTE: starting from SM8150 devices DSP have an unsigned mode, but there are some limitations and one of them probably breaks HDR processing even on that devices. From SDK docs:

There's also another drawback with this bug: if you want to load libhalide_hexagon_host.so and libhalide_hexagon_remote_skel.so from the apk you must set the environment variable ADSP_LIBRARY_PATH. When you set that path on your app, the libs in your apk will override the libs provided with the ROM, this means that if a device have a native working implementation (Pixel devices, some Oneplus phone) the working libraries will be overridden by the libs with the wrong signature, and this will break HDR processing even in devices where is supposed to work fine natively

Log of Hexagon failing:

I com.shamim.cam: vendor/qcom/proprietary/adsprpc/src/apps_std_imp.c:865: Successfully opened file /data/user/0/com.shamim.cam/libhalide_hexagon_remote_skel.so
E com.shamim.cam: vendor/qcom/proprietary/adsprpc/src/fastrpc_apps_user.c:1286: Error 0xfffffffb: remote_handle_open_domain: dynamic loading failed for halide_hexagon_remote on domain 0 (dlerror signature
verify start failed for libhalide_hexagon_remote_skel.so) (errno Success)
E com.shamim.cam: vendor/qcom/proprietary/adsprpc/src/fastrpc_apps_user.c:1304: Error 0xfffffffb: remote_handle_open failed for halide_hexagon_remote (errno Success)
I halide : Hexagon: remote_poll_log failed 44
E libgcam : [halide_runtime.cc:100]: halide_error: Error: Initialization of Hexagon kernels failed

Android 10 with 3.18 or 4.4 kernel? BTW there are various reason that can cause this behaviour, I've already fixed one of the potential cause (thanks for your report, I've checked again camera power hints and stune boost was still broken and camera daemon was wrongly bind to system background cpuset instead of the reserved camera-daemon), don't know if now perf are the same we had in Android 10 ROMs but at least works as intended :)

There are multiple things that can cause this issue, not sure we can fix it but at least we can try to understand what's happening. You can try to see if you are hitting some SELinux denials if you are not using my ROM (i've disabled auditing for public builds here, but i can provide a kernel with auditing enabled for testing purposes if needed), just reboot your phone (optional, but this will reduce the denials list) and run from your PC

adb root && adb pull /sys/fs/selinux/policy policy

Then update e-money, let it fail and run

adb logcat -b events -d | audit2allow -p policy

This will print the list of the denials, if SELinux is blocking in some way NFC we will see it in the list

NOTE: you need audit2allow installed on your PC, on Debian/Ubuntu it's in policycoreutils-python-utils package

Also a logcat with NFC debug enabled would be helpful, to enable the verbose mode:

adb root
adb shell mount -o rw,remount /vendor
adb pull /vendor/etc/libnfc-nxp.conf

Open libnfc-nxp.conf with a text editor and replace from line 13 to line 20 0x00 with 0x03, then

adb push libnfc-nxp.conf /vendor/etc/libnfc-nxp.conf
adb reboot

Once you finish disable the debug and reboot your device, or in your case NFC will spam a ton of logs every few seconds

@dudinha could you please show me what you changed in nxp conf file? Because according to the logcat you posted NFC debugging is still disabled

No, Xiaomi stopped Gemini updates with Android 8, they dropped device support years ago, only thing you MAY receive are security updates, but I don't think they are still maintaining our legacy device. My experience with MIUI with all my devices is turn it on, enable developer option, unlock bootloader and wipe everything. I never used MIUI for everything else so probably I'm not the right person to ask about Xiaomi OS :)