**** BEGIN LOGGING AT Tue Apr 20 02:59:56 2021 Apr 20 09:43:01 Morning! Apr 20 09:43:46 Tofe: You think I should add "android.hardware.sensors@1.0-service" as well? Apr 20 10:04:19 Herrie: it can't hurt, yes Apr 20 10:04:29 and I think I saw some failures about sensors too Apr 20 10:15:49 Tofe: OK Apr 20 10:16:09 Trying to fix the kernel build in Halium, then things should be OK again hopefully and I'll push a new build to build server Apr 20 10:28:02 Seems I need a few minor fixes on Halium side Apr 20 10:54:06 Tofe: OK kernel on Halium side is happy, new Halium image on build server, now doing whole OS Apr 20 10:54:19 See if GCC is happy with kernel changes as well :p Apr 20 11:04:44 Herrie: good ! :) Apr 20 11:11:23 Tofe: http://build.webos-ports.org/halium-luneos-9.0/luneos-dev-package-mako-0-20210420.zip Apr 20 12:06:44 Herrie: you also bumped the kernel, right? Apr 20 12:35:37 Tofe: Yeah to latest srcrev Apr 20 12:39:24 ok, great, it's flashing Apr 20 12:44:36 library "/vendor/lib/egl/libGLESv2S3D_adreno.so" not found Apr 20 12:44:53 missing entry in proprietary-files, I guess Apr 20 12:46:38 mmmh no, it's really not there Apr 20 12:50:16 maybe it's not critical; let see Apr 20 12:51:05 Tofe: Let me check if I can find it somewhere Apr 20 12:51:26 https://github.com/ubports/ubuntu-touch/issues/352 looks like it's not necessarily there Apr 20 12:52:44 Tofe: Seems there's: https://github.com/TheMuppets/proprietary_vendor_lge/blob/lineage-16.0/mako/proprietary/vendor/lib/egl/libGLESv2_adreno.so Apr 20 12:53:06 yes, that one I have Apr 20 12:54:14 we're also missing a piece for vibrator service, I'd say Apr 20 12:54:26 not sure if that one is fatal, I'd be surprised if it is Apr 20 12:55:04 I added this: https://github.com/Herrie82/android_device_lge_mako/blob/halium-9.0/device.mk#L263 Apr 20 12:55:06 We need more? Apr 20 12:55:29 not sure, it does look like all is here on device Apr 20 12:57:46 Is it booting or Android still acting up? Apr 20 12:57:48 ah, we're missing either vibrator.default.so or vibrator.mako.so or vibrator.msm8960.so Apr 20 13:01:09 I cannot find it in vendor anywhere, not even in cm12.1 from TheMuppets Apr 20 13:01:17 Could be it needs building in Android side? Apr 20 13:03:43 I think it is built by a standard aosp component in libhardware Apr 20 13:04:34 I think adding vibrator.mako in the device.mk should be enough to trigger it Apr 20 13:06:21 but ideally it would be triggered by dependencies... Apr 20 13:10:55 but anyway it's not necessarily the cause of the issue here Apr 20 13:11:09 it's just the only thing that still pops up in logcat Apr 20 13:24:02 Not really sure how that's working for Hammerhead Apr 20 13:24:08 I don't see anything there in the device.mk? Apr 20 13:24:21 neither do I... Apr 20 13:24:36 must be an indirect dependency somehow Apr 20 13:29:59 Tofe: Trying with vibrator.mako now Apr 20 13:30:20 It should build some vibrator.mako.so right in the out folder? Apr 20 13:30:46 Will just do a "find . -name "vibrator*" Apr 20 13:35:56 should be in system/lib/hw or something like that Apr 20 13:37:49 Nope not there Apr 20 13:37:51 https://bpa.st/BWUA here's the strace output for the vibrator service, btw Apr 20 13:39:08 But maybe it's not picking up my local changes Apr 20 13:39:11 Let me do from scratch Apr 20 13:39:44 Anyway quick enough here Apr 20 13:39:47 Small build for Mako Apr 20 13:43:05 I can also try on my side, I already have Halium 9.0, I just need mako repos Apr 20 13:50:19 Nope.... Apr 20 13:50:26 Should I give you the manifest? Apr 20 13:50:57 https://bpa.st/H6OQ Apr 20 13:53:49 Herrie: I'll give it a try tonight Apr 20 13:54:20 Trying with vibrator.msm8960 now Apr 20 14:02:05 Nope still the same :S Apr 20 14:02:05 Weird Apr 20 14:46:40 Tofe: Invited you to the android_device_lge_mako repo ;) Apr 20 14:46:46 Saves you PR-ing Apr 20 14:48:04 good idea, thanks Apr 20 17:23:50 Herrie: it was vibrator.default :p Apr 20 17:29:39 Herrie: logcat is clean now, but luna-next continues crashing :( Apr 20 17:30:14 "QSGRenderThread: type=1701 audit(0.0:29): auid=4294967295 uid=0 gid=0 ses=4294967295 reason="memory violation" sig=11" Apr 20 17:32:18 and this time, there isn't any display-caf override, I guess Apr 20 17:37:11 Tofe: OK well 1 down, another to go I guess Apr 20 17:37:25 Well it could be that there is some CAF/non-caf stuff there Apr 20 17:37:36 let me see in which .so we crash Apr 20 17:38:45 it's in /android/system/vendor/lib/hw/hwcomposer.msm8960.so Apr 20 17:40:50 it's true that the crash looks fairly similar, and at about the same point in time for luna-next Apr 20 17:42:28 I remember that we had this QCOM_BSP flag for Mako probably Apr 20 17:42:41 for all qualcomm, yes Apr 20 17:43:38 We might be able to take the one from Tenderloin simply... Worth a try Apr 20 17:43:47 The repo I mean Apr 20 17:45:08 Since it's the same 8960 Apr 20 17:51:25 I'm trying the tenderloin patch, which fixes the "numDisplay" for loops Apr 20 17:58:48 damn, our gdb can't read the android symbols generated by the Halium build Apr 20 18:02:47 ooh but maybe the gdb on my computer can Apr 20 18:08:41 nope, can't get a stack Apr 20 18:20:50 got a stack, it crashes in hardware/qcom/display-caf/msm8960/libhwcomposer/hwc.cpp:145 Apr 20 18:22:19 Well that's a lead at least Apr 20 18:23:55 there seems to be a mismatch, it's weird Apr 20 18:24:12 in gdb I have: #0 0xb0cec4c4 in reset (numDisplays=, displays=0x36d7d0, ctx=) Apr 20 18:24:40 but the header of the "reset" function in the cpp seems to be reset(hwc_context_t *ctx, int numDisplays, hwc_display_contents_1_t** displays) Apr 20 18:26:40 maybe it's just the debugger that is a bit lost Apr 20 18:33:23 ok, the numDisplay is incorrect somehow Apr 20 18:33:37 I got luna-next to work by forcing it to numDisplay=3 Apr 20 18:41:14 with the hack in place, we get UI, touch, sound, wifi, rotation, no bluetooth, maybe telephone (not tested), no camera (provoked a reboot !). Apr 20 18:42:13 Tofe: Well that's a very decent start! Apr 20 18:42:32 BT might need some patches Apr 20 18:42:37 I didn't add any Apr 20 18:42:55 I think you added the backport ones to Hammerhead right? Apr 20 18:43:12 Herrie: I don't think so, it just worked Apr 20 18:43:19 ah OK Apr 20 18:43:30 Then it was the old kernel I saw I guess Apr 20 18:43:34 I didn't look at all why bt doesn't work here Apr 20 18:44:53 maybe adding bluebinder would help Apr 20 18:45:04 I did push that Apr 20 18:45:08 ah ok Apr 20 18:45:10 But didn't point you to it Apr 20 18:45:19 Or maybe I didn't add it to build ;) Apr 20 18:45:34 I know I added it locally in my git and pushed it, but that's on my laptop, not on my builder :P Apr 20 18:45:42 there isn't any bluebinder process, at least Apr 20 18:46:20 Seems I didn't Apr 20 18:46:40 also, VHCI need to be enabled in kernel for this to work Apr 20 18:48:18 I have some backports it seems? https://github.com/Herrie82/android_kernel_lge_mako/blob/222eadd7491e327336d94d7381b69457f4ca8ca0/arch/arm/configs/lineageos_mako_defconfig#L202-L206 Apr 20 18:48:35 I can add this if needed? https://github.com/Tofee/tissot/commit/28cfffc8ab361e49654bb376d385f425e017e357 Apr 20 18:48:47 I don't see any VHCI in /proc/config.gz Apr 20 18:48:57 yes, please do so Apr 20 18:49:17 I think the backports may have been related to the other mako kernel Apr 20 18:49:32 Yeah Apr 20 18:49:38 I'll rebuild halium as well Apr 20 18:49:43 but using VHCI is quite fine Apr 20 18:50:02 let me give you the little hack Apr 20 18:50:38 vibrator.default I need to build right? Apr 20 18:51:02 yes exactly Apr 20 18:51:08 you were nearly there :p Apr 20 18:51:25 https://bpa.st/4XKA (ignore the first line, I let it here so that you have the relative path) Apr 20 18:52:17 actually numDisplay could be "3" I guess Apr 20 18:55:06 (testing this right now) Apr 20 18:55:37 yes, 3 is probably the correct value here Apr 20 18:56:59 not sure how to have this as a proper fix :/ Apr 20 18:58:33 Yeah it's weird... Probably we need a fork of the display repo just for this... Apr 20 18:58:42 I don't think we can apply device specific patch really Apr 20 18:59:03 So I should update the patch with 3 instead of 2 ? Apr 20 18:59:23 as you wish, I don't see any difference here Apr 20 18:59:30 OK Apr 20 18:59:41 I add this in hybris-patches right? Apr 20 18:59:53 And this is the standard display repo right? Not the tenderloin one? Apr 20 19:00:25 it's the standard repo yes Apr 20 19:00:47 I'm looking at the QPA hwcomposer plugin, which is where the call comes from Apr 20 19:01:48 I think there was a way to set the number of displays there Apr 20 19:04:23 I saw this: https://github.com/mer-hybris/qt5-qpa-hwcomposer-plugin/pull/21/commits/a6c564e51955f4a238e83ff4fb53c7f19a43cf5c Apr 20 19:08:02 mmh hardcoded to "3" in android Apr 20 19:08:24 I wonder why we suddently gave another value. Apr 20 19:11:02 Tofe: In standard repo your patch doesn't seem to apply? Apr 20 19:11:30 that's strange Apr 20 19:11:39 it's just a diff in the msm8960 subfolder Apr 20 19:12:11 and I didn't change anything else Apr 20 19:12:14 Or I have something funny at my end Apr 20 19:12:36 Wrong display folder ;) Apr 20 19:12:37 you do "git apply" from within hardware/qcom/display-caf/msm8960 gith ? Apr 20 19:12:38 right Apr 20 19:12:41 ok :) Apr 20 19:14:42 Tofe: well i added it to hybris-patches Apr 20 19:14:46 Maybe I did something wrong Apr 20 19:14:50 manually patched for now Apr 20 19:15:00 Halium building Apr 20 19:17:13 https://github.com/Halium/android-headers/blob/halium-9.0/hardware/hwcomposer_defs.h#L276 huh !? Apr 20 19:18:47 compared to https://github.com/LineageOS/android_hardware_libhardware/blob/lineage-16.0/include/hardware/hwcomposer_defs.h#L267 Apr 20 19:20:16 That's weird indeed Apr 20 19:20:27 Maybe NotKit did something wrong Apr 20 19:20:36 Or he took AOSP headers which are different from LOS? Apr 20 19:21:50 I don't know, but this value is used to allocate arrays, so it's a good lead for our crash here Apr 20 19:22:56 Nope seems AOSP is OK too: https://android.googlesource.com/platform/hardware/libhardware/+/refs/heads/pie-release/include/hardware/hwcomposer_defs.h#L267 Apr 20 19:23:05 https://android.googlesource.com/platform/hardware/libhardware/+/refs/heads/pie-gsi/include/hardware/hwcomposer_defs.h#L267 Apr 20 19:23:12 Both for pie-release and pie-gsi branch Apr 20 19:23:24 Question is where it comes from and what other values might have issues Apr 20 19:24:56 Tagged @NotKit via Telegram channel Apr 20 19:24:57 Let's see Apr 20 19:26:13 Tofe: Image is uploading now Apr 20 19:26:40 Should be ready in 3 mins: http://build.webos-ports.org/halium-luneos-9.0/luneos-dev-package-mako-0-0.zip Apr 20 19:26:52 Herrie: great :) Apr 20 19:28:50 Having a value too high on luneos side doesn't seem to be a big issue, but on android side it's a thin line: we tell him we have 8 display, but the driver only knows how to manage 3 of them, so... Apr 20 19:31:55 Herrie: your build already has bluebinder and VHCI ? Apr 20 19:32:50 thinking back about tenderloin, it might have solved our crash too, maybe Apr 20 19:32:58 Tofe: Yes Apr 20 19:33:00 It has Apr 20 19:33:19 wonderful Apr 20 19:33:22 Added the bluebinder to packagegroup, update Halium build and defconfig Apr 20 19:33:43 and now I have to wait an eternity to download this little zip Apr 20 19:33:54 ETA 7min Apr 20 20:27:30 Tofe: And? Apr 20 20:43:39 Tofe: In general we could regenerate the 9.0 headers Apr 20 20:43:43 and android doesn't start anymore :p Apr 20 20:43:45 Script is in libhybris I think Apr 20 20:46:00 Yup:https://github.com/libhybris/libhybris/blob/master/utils/extract-headers.sh Apr 20 20:46:03 I guess I can try that Apr 20 20:46:55 From our 9.0 tree Apr 20 20:51:15 Herrie: you sure about your new build ?... Apr 20 20:51:47 Tofe: Well unless I messed up the Android side somehow.... Apr 20 20:52:21 I don't know, but android doesn't start at all now Apr 20 20:53:25 Weird... Apr 20 20:53:32 Well I could try to repatch the hwcomposer Apr 20 20:53:38 I'm doing the headers now Apr 20 20:53:39 let me try with my last kernel first Apr 20 20:53:56 then I'll push my last halium image Apr 20 20:54:17 ok, not the kernel it seems Apr 20 20:55:40 now trying your kernel/my halium Apr 20 20:56:08 nope, it's quite weird Apr 20 20:57:03 oh, "EXT4-fs (mmcblk0p23): ext4_orphan_cleanup: deleting unreferenced inode 613386" Apr 20 20:57:11 ok let me just reflash Apr 20 20:58:47 Tofe: Well headers shows interesting stuff: https://github.com/Halium/android-headers/compare/halium-9.0...herrie/halium-9.0-proper?expand=1 :S Apr 20 20:59:55 it's a huge diff Apr 20 21:00:52 Yeah well lots of NFC files added it seems Apr 20 21:00:58 But otherwise not too much Apr 20 21:01:40 Just they broke the script with latest commit: https://github.com/libhybris/libhybris/commit/336ba4fa8b5745a158f180d35cba3a26a64aaa9c#diff-e725f8491108a923ba1fb2399671ed627c6a7b3559299451124fa731155bbeba#L246 Apr 20 21:01:50 L246 doesn't have a fi.... Apr 20 21:02:38 Well this was from patched Halium tree... Should do unpatched of course :S Apr 20 21:02:46 ah, yes Apr 20 21:02:58 though it won't change things a lot Apr 20 21:03:16 ok, /data reformatted, reflashed, good as new, booting.... Apr 20 21:03:20 Probably now Apr 20 21:03:26 s/now/not Apr 20 21:04:26 still no android :( Apr 20 21:05:31 "init: Couldn't open /sys/fs/selinux/null: No such file or directory" Apr 20 21:07:00 I don't understand Apr 20 21:08:41 and same thing with my working kernel Apr 20 21:13:24 ah , my kernel + my halium, it still works Apr 20 21:13:39 damn Apr 20 21:16:43 ah wait, no, now I can boot also with your kern----nope, it crashed and rebooted Apr 20 21:17:14 was just a one-time crash it seems Apr 20 21:19:33 bluetooth android service crashed when activating BT Apr 20 21:20:08 but well, anyway, the status is good enough for me. It's just mako, nearly noone has that device anymore Apr 20 21:23:47 I can still see graphic artefacts -- maybe the hwcomposer situation isn't perfect yet Apr 20 21:58:39 Tofe: Let's have a discussion with NotKit about the headers when he's around Apr 20 21:58:54 And then see from there Apr 20 21:59:17 I think we're in good enough shape in general for it to move to 9.0 with some minor fixes here and there maybe Apr 20 22:16:41 yes, I agree Apr 20 22:20:23 I've opened a PR just to get some feedback Apr 20 22:20:40 Also made some comments on libhybris about the broken extract-headers.sh script ;) Apr 20 22:20:49 Should get some feedback soon I guess Apr 20 22:21:00 As in tomorrow or the day after :P Apr 20 22:33:09 yes, it's a good way to discuss it **** ENDING LOGGING AT Wed Apr 21 03:01:26 2021