**** BEGIN LOGGING AT Wed Feb 15 03:00:02 2017 Feb 15 08:39:38 morning Feb 15 08:43:37 morphis: morning Feb 15 08:43:49 Herrie|Pre3: morning! Feb 15 08:44:47 We were playing with recent libhybris bumps and noticed some issues Feb 15 08:44:54 Wanted to check if you're aware? Feb 15 08:45:23 Seems the Android 6 bits are acting up on 12.1 HAL Feb 15 08:52:57 Herrie|Pre3: what kind of issues? Feb 15 08:56:16 morphis: We had issues with hwcomposer on CM13 with Hammerhead. With CM12.1 and latest libhybris UI crashes. Feb 15 08:56:33 Sensors work which didn't on Hammerhead without a hack with older libhybris Feb 15 08:56:50 Tofe is doing some lower level debugging so he might have more details. **** BEGIN LOGGING AT Wed Feb 15 09:15:17 2017 Feb 15 09:16:11 morphis: so far, I'm at this level of analysis: http://paste.ubuntu.com/23997310/ Feb 15 09:16:39 Tofe: where is that? Feb 15 09:16:44 in which .so? Feb 15 09:17:45 Tofe: you may want https://code-review.phablet.ubuntu.com/gitweb?p=aosp/platform/frameworks/native.git;a=commit;h=6604fc9b4bc04bd79e590069a13bf2bd9db13da8 on the Android side Feb 15 09:17:46 morphis: the EGL crash itself is in libEGL.so (the patched one), in setGlThreadSpecific, where it calls __get_tls_hooks. Feb 15 09:19:05 morphis: ah, yes, that's very interesting! I wonder with the mer guys didn't pick it up yet Feb 15 09:19:37 don't know Feb 15 09:19:44 maybe they did Feb 15 09:19:54 well, thanks, I think that'll help :) Feb 15 09:19:57 Tofe: but you saw that you can select a different linker version per platform now? Feb 15 09:20:06 so you can use the 4.x or the 5.x one Feb 15 09:20:22 morphis: yes, but there is only jb or mm, right? Feb 15 09:20:28 correct Feb 15 09:20:40 but for example we're using the jb one still on 5.x devices Feb 15 09:20:49 for me it detects 5.1.0, so jb, on my side Feb 15 09:21:03 no 5.1.0 should go to mm by default Feb 15 09:21:28 ah well, there are definitely some inconsistencies then Feb 15 09:22:15 I didn't set any env variable so far to select the linker, and it selects jb. But the line https://github.com/libhybris/libhybris/blob/master/hybris/common/hooks.c#L2877 suggest it should be mm, as you say Feb 15 09:22:38 s/linker/jb linker/ Feb 15 09:24:22 ok, I see the issue: I didn't build libhybris with experimental, so "WANT_MM" isn't defined Feb 15 09:26:21 morphis: I think it should output a stong warning, if the API level is >21 and WANT_LINKER_MM isn't defined Feb 15 09:26:27 strong* Feb 15 09:27:16 Tofe: where would API level >21 be defined? at runtime? Feb 15 09:28:47 morphis: well, for instance, in my case, I don't have WANT_LINKER_MM. However, is still uses the mm hooks is level>21 (see previous link). That's bad, right? Feb 15 09:28:58 s/is/if/ Feb 15 09:29:29 oh yeah that is right, but then we should make the mm_hooks conditional on WANT_LINKER_MM instead Feb 15 09:30:34 yes, that would work too :) It's just that you were saying your jb linker with 5.1.0 is a-priori a bad idea Feb 15 09:30:46 s/your/using/ Feb 15 09:31:04 (sorry, my fingers just don't want to write things correctly today) Feb 15 09:34:30 Anyway, I now have two things to try tonight: using mm linker, and applying the commit for libegl. Good! Feb 15 10:05:58 Tofe: no, jb linker with 5.1.0 isn't a bad idea Feb 15 10:06:31 we had good results with it and when we did the Android 6 enablement we didn't wanted to put our productions devices at risk and decided to stay on them with the jb linker Feb 15 10:07:03 morphis: ok, so if I validate our target devices, then it's good to go Feb 15 10:07:25 could be, however it's also valid for you to stay with the tp/n4 with a 4.x based bsp Feb 15 10:07:30 no need to update it Feb 15 10:09:37 for TP, that's what we're doing; for N4, options are open. The idea was to validate the "overlay" approach for libhybris usage on N4, and now that it's done, we'll keep it I think Feb 15 10:11:30 Tofe: ok, just saying that you shouldn't spend your time on getting to a newer Android version on an already working device Feb 15 10:11:47 morphis: sure :) Feb 15 10:34:52 morphis: I think updating the Mako was more for testing the waters and having some of the benefits that 12.1/13.0 offers compared to 11.0 and just to have a more solid build process because our 11.0 bits had issues after updating some of the back end serv Feb 15 10:34:52 er infrastructure. Feb 15 10:38:17 Herrie|Pre3: which benefits does 12.1/13.0 offer over 11.0? :-) Feb 15 10:38:57 Some things like sfdroid, camera etc that were problematic on cm11 from what I understood Feb 15 10:39:12 And Tofe only had a Mako at the time :P Feb 15 10:39:20 So hence the testing waters Feb 15 10:40:18 sfdroid is a mess anyway, and camera is somehow problematic through how its being integrated on sf Feb 15 10:40:21 however :-9 Feb 15 10:40:28 s/:-9/:-)/ Feb 15 10:40:58 morphis: Yeah not a big fan of sfdroid :P Feb 15 10:41:12 Looking forward to the other one :P Feb 15 10:41:54 What's wrong with their camera approach and what would you suggest, because that's something we might be looking into shortly. Same with GPS Feb 15 10:42:23 Herrie|Pre3: the problem is that sf tries to access the camera HAL directly (at least last time I looked) Feb 15 10:42:45 on ubuntu we have abstracted the camera HAL stuff behind our own API which basically never changes Feb 15 10:43:03 and use texture streaming to get the picture through the layers Feb 15 10:43:55 Are these bits public or closed? Feb 15 10:44:02 public Feb 15 10:44:13 https://github.com/libhybris/libhybris/tree/master/compat/camera Feb 15 10:45:00 https://code.launchpad.net/qtubuntu-camera Feb 15 10:48:03 Great thnx :) Feb 15 11:17:36 Have there been any LuneOS ports to aarch64-based devices? Feb 15 11:18:35 linux_unix-10: To date not yet Feb 15 21:44:37 Tofe: Any luck with the hints from morphis? Feb 16 01:40:15 Does the webOS ports porting guide still apply to CM13/AOSP 6 sources? Those are the earliest codebases available for my device. **** ENDING LOGGING AT Thu Feb 16 03:00:01 2017