**** BEGIN LOGGING AT Sat Sep 23 03:00:03 2017 Sep 23 06:42:42 Morning! Sep 23 06:54:31 Morning! Sep 23 06:54:40 Herrie|Laptop: I'm building my tenderloin now Sep 23 06:59:38 Herrie|Laptop: I don't really have a defnite opinion about Settings rewrite in QML; it would be pretty easy to do I think, but what are the issues with the current app ? Sep 23 07:01:20 (also, does it come from HP code, or did we rewrite it?) Sep 23 07:01:41 also also, why QML over WebComponents ;) Sep 23 08:01:40 Tofe: Great! Sep 23 08:02:17 On Settings app: This was built from scratch in Enyo 2.0, so not from HP. Main problem is that it relkes Sep 23 08:02:47 it what ? Sep 23 08:03:35 s/relkes/relies on C++ plugins which we need to maintain ourselves for wifi & bt. Like now for BlueZ4->5 it would need to be updated for new API in BlueZ5. Sep 23 08:03:41 oh, that's an english verb -- looked like something else :) Sep 23 08:04:45 It doesn't just to LS2 calls ? Sep 23 08:04:50 Seeing that there are ready made bits that we could reuse for QML apps would mean we wouldn't have to maintain these plugins and could remove them from our webappmanager as well :-P Sep 23 08:04:53 s/to/do/ Sep 23 08:05:18 ooh those bits Sep 23 08:05:20 Tofe: Check luna-webappmanager: It does quite a bit more I think ;-) Sep 23 08:05:58 Seeing there's libconnman-qt5 etc that other projects are using and our UI is QML it might make sense? Sep 23 08:06:27 That's a good point yes Sep 23 08:06:30 Currently it's a bit hackidy hack solution if you ask me. Sep 23 08:06:57 nizovn: Do you have some thoughts on this as well? Sep 23 08:07:32 I'm sure there are not only pro's but also some cons Sep 23 08:07:43 For me the main argument for using QML in our core apps is when there is a high dependency on hardware (camera, phone...) - and for the browser, well, doing a browser in HTML looks like a mistake to me :) Sep 23 08:08:42 morphis already started a mock a long time ago, not sure to what extend that would still be somewhat usable or it would be better to start from scratch with the new styling Sep 23 08:08:50 well i always prefer Qt to JS Sep 23 08:09:21 nizovn: eh, you're not building Qt5 on webOS for nothing ;) Sep 23 08:09:58 Herrie|TP: using QtQuickControls2 for this would make a lot of sense Sep 23 08:10:47 Tofe: I guess we'd would need to give it some try with wifi and/or BT to see if it's feasible Sep 23 08:11:26 Not sure to what extend we could borrow some code from other projects for this, I.e. scanning, connecting etc Sep 23 08:11:27 Herrie|TP: well, firstuse manages wifi quite fine Sep 23 08:11:34 we can also split settings into several apps for legacy reasons Sep 23 08:12:16 Well it's a little buggy at times but so is the js plugin Sep 23 08:12:49 ah it uses LS2 all the time, I almost forgot Sep 23 08:13:56 Mer or Ubuntu probably has a QML component for abstracting this a bit more Sep 23 08:14:12 or a Qt Mobitily plugin Sep 23 08:15:45 Qt Bluetooth already has a QML plugin - and it supports BlueZ 4.x and 5.x Sep 23 08:19:43 that uses webos-connman-adapter which I guess we could kill completely too maybe Sep 23 08:19:56 Though it might be required for some legacy things Sep 23 08:23:32 I don't know how much is exposed by libconnman-qt5 (i.e. can we connect to a WiFi with password, etc) Sep 23 08:25:28 looks quite complete Sep 23 08:26:21 ah, the "android-version.h" yocto bug... annoying... Sep 23 08:26:47 I'll fill in an issue on our board, to remember about the analysis I just did Sep 23 08:28:59 Tofe: OK Sep 23 08:29:26 Tofe: Yeah and stuff like certificates etc for some corporate wifi, public hotspots etc Sep 23 08:33:59 http://issues.webos-ports.org/issues/1213 Sep 23 09:26:51 Tofe: I guess we need to ask JaMa when he's around for that one Sep 23 09:27:10 nizovn: Thnx for new qupzilla, I'll try it in a bit Sep 23 09:28:29 Herrie|TP: yes, I've tried to understand the issue, but I still don't see how android-headers is different from libhyrbis, which works well Sep 23 09:29:30 JaMa is Yocto guru so I'm sure he'll have a clue :-P Sep 23 09:29:36 yup :) Sep 23 09:29:53 speaking of headers, we'll need to switch to halium's ones Sep 23 09:30:06 they should be identical anyway Sep 23 09:31:21 Tofe: ok Sep 23 09:33:19 (here https://github.com/Halium/android-headers ) Sep 23 09:37:03 lol https://github.com/webOS-ports/org.webosports.app.settings/blob/qml-based/src/qml/MainPage.qml#L29 Sep 23 09:38:18 I think we can continue on top of morphis' work, it's almost an empty shell, so it's straightforward to port it to QtQuickControls2 Sep 23 09:39:07 We should just have a good way of loading and saving the settings Sep 23 09:51:59 Tofe: The only defconfig flags we have consistently across Mako, Hammerhead and Tenderloin are CONFIG_MSM_SMD_TTY=y CONFIG_KSM=y CONFIG_NF_CONNTRACK_SIP=y CONFIG_NF_NAT_SIP=y CONFIG_JBD=y CONFIG_MISC_FILESYSTEMS=y CONFIG_TIMER_STATS=y CONFIG_ARM_UNWIND=y Sep 23 09:52:19 ... that's all ? :D Sep 23 09:52:28 Doesn't seem very trivial most of them based on description. So I guess we could try Halium Hammerhead kernel + GCC patches Sep 23 09:52:40 Tofe: Well there are more, but we're not consistent in our 3 devices Sep 23 09:52:51 ok Sep 23 09:52:51 There's BT ones, but those are covered by the backports from Ubuntu Sep 23 09:52:59 yes Sep 23 09:52:59 And some FS ones Sep 23 09:53:35 Like CONFIG_EXT2_FS Sep 23 09:53:46 But the EXT4 variant can do 2 and 3 too Sep 23 09:53:49 So that should be fine Sep 23 10:01:50 For FS, we should harmonize it, it can be important Sep 23 10:08:43 Tofe: Yeah Sep 23 10:09:14 Tofe: Halium has CONFIG_EXT4_USE_FOR_EXT23=y which does: Allow the ext4 file system driver code to be used for ext2 or ext3 file system mounts. This allows users to reduce their compiled kernel size by using one file system driver for ext2, ext3, and ext4 file systems. Sep 23 10:09:18 So we should be OK Sep 23 10:13:07 yep Sep 23 10:16:12 But I guess we'd need to just test it Sep 23 10:16:24 Nothing too urgent anyway Sep 23 12:03:03 Herrie|Laptop: now flashing new TP image with alternative display-caf Sep 23 12:20:21 Tofe: Curious if anything improved Sep 23 12:22:31 nope, sorry, still crashes. But now I know where it crashes: in wayland, during a file desccriptor duplication Sep 23 12:22:49 (the "dup failed: Bad file descriptor" error message) Sep 23 12:23:37 must be something missing in the kernel for this call, either F_DUPFD_CLOEXEC or F_DUPFD Sep 23 12:24:02 or bugged Sep 23 12:34:40 I could pull kernel for Mako/Hammerhead & Tenderloin and compare those functions Sep 23 12:35:42 "W/Adreno200-ES20( 0): : GL_OUT_OF_MEMORY" ... Sep 23 12:36:19 which seems a bit weird, that early Sep 23 12:39:31 You mean it gets out of memory very quickly? Sep 23 12:41:22 yes, it resembles a lot what morphis had a couple of years ago Sep 23 12:41:41 https://github.com/webOS-ports/android_hardware_qcom_display-caf/commit/c22053f584ba7abf4c7d816aabbdb7a469c57742 could it be I forgot to set TENDERLOIN_HACKS ? Sep 23 12:42:32 ... very possible... Sep 23 12:44:47 That was removed with the 2nd commit for numdisplays Sep 23 12:45:22 ah yes, good catch Sep 23 12:45:54 https://github.com/webOS-ports/android_hardware_qcom_display-caf/commit/d62974c87ee05b89b473b2b5ca6f25c489b05397 Sep 23 12:46:08 https://groups.google.com/forum/#!topic/android-ndk/W5FTSeIA9QM Sep 23 13:10:37 Tofe: http://www.modaco.com/forums/topic/362828-confont-problems-while-compiling-cm101/ Sep 23 13:11:07 It's for ZTE target but fix might be the same Sep 23 13:12:42 unfortunately it's not the same issue, we don't have issues with genlock from what I can see Sep 23 13:13:55 Herrie|Laptop: note that for cm-11, we didn't use proprietary drivers Sep 23 13:14:10 just an emulator fallback Sep 23 13:16:24 Well the 2nd commit might have some pointers or workaround by the looks of it Sep 23 13:18:11 But it's old jellybean so not very useful I guess Sep 23 13:26:19 Grepping my way around Mako 3.4 kernel Sep 23 13:27:27 I think here still is an API mismatch Sep 23 13:28:19 I've printed the famous "bufferSize" which morphis had checked in his patch Sep 23 13:29:16 And it's not at all a size, it looks like a pointer address Sep 23 13:38:03 That's weird Sep 23 13:38:46 I found a missing option in libhybris for tenderloin, but it doesn't seem to fix the issue - too bad, it was quite promising Sep 23 13:41:04 I should try to get the full stack for this... Sep 23 13:56:43 ok, yes, there's a mismatch Sep 23 13:57:06 a call to "alloc" ends up in "alloc_size" Sep 23 13:57:28 from hybris/egl/platforms/common/server_wlegl.cpp:130 to hardware/qcom/display-caf/msm8660/libgralloc/gpu.cpp:351 Sep 23 13:59:22 oooh... ".cpp" ... CFLAGS... wait a minute... Sep 23 14:01:02 yes ! got it :) Sep 23 14:03:19 Tofe: Nice :) So that will solve it or only partly? Sep 23 14:05:34 well, I've got 4 apps right now Sep 23 14:06:49 I still get some crashes after some apps: "ION_IOC_ALLOC failed with error - Resource temporarily unavailable" Sep 23 14:06:54 but it's unrelated I think Sep 23 14:08:30 https://github.com/shr-distribution/meta-smartphone/pull/33 Sep 23 14:09:12 also a minor unrelated fix: https://github.com/webOS-ports/meta-webos-ports/pull/251 Sep 23 14:46:27 well then, I don't know, could be it's just using too much GPU memory Sep 23 14:51:15 Tofe: Well if the immediate urgent problem is gone that's already progress Sep 23 14:51:22 We can always try to fix this later Sep 23 14:51:40 Memory situation on TP was always somewhat problematic Sep 23 14:52:07 I think a clue might be "ION_IOC_ALLOC failed with error - Success" Sep 23 14:52:19 I'll wait for that meta-webos-ports one on JaMa Sep 23 15:22:27 Herrie|Laptop: I can propose a little patch which will improve the situation; but it really looks like there are some big leaks out there Sep 23 15:25:44 Herrie|Laptop: so we continue to use the current display-caf ? Sep 23 15:25:57 I didn't see any change with the other one... Sep 23 15:27:56 https://github.com/webOS-ports/android_hardware_qcom_display-caf/pull/1 Sep 23 15:34:32 Tofe: Well it has some changes but nothing too major it seems Sep 23 15:36:05 It has some ALLOC & ION changes: https://github.com/webOS-ports/android_hardware_qcom_display-caf/compare/tenderloin/halium-5.1...webOS-ports:tenderloin/halium-5.1-new Sep 23 15:36:10 Not sure how relevant though Sep 23 15:37:00 I don't know; as you wish, it's just a little commit, easy to port Sep 23 15:38:51 Seems we have HWC 1.3 and the new one is 1.4? Sep 23 15:40:25 I guess we could merge to both Sep 23 15:48:37 OK pushed it there too Sep 23 15:50:39 Tofe: You happen to have IPK for me for the libhybris? Sep 23 15:50:50 I guess I could suffice just pushing that in general right? Sep 23 16:27:09 a moment Sep 23 16:29:08 ygm Sep 23 16:48:27 Thnx Sep 23 16:48:32 Will have a look Sep 23 16:48:47 It should solve it partly at least right Sep 23 16:50:53 you'll get up to 3 apps Sep 23 16:51:03 and then, paf. Sep 23 16:58:22 now, let's give a second try to this sensor issue Sep 23 18:17:47 Herrie|Laptop: sensor thing solved, it's again a path issue Sep 23 18:18:21 our file is in /etc/qt5/..., but QSettings looks in /etc/xdg/... Sep 23 18:23:15 ah, ok: "dist/changes-5.9.0: lookup based on XDG spec (XDG_CONFIG_DIRS) on Unix based systems." Sep 23 18:24:23 so imho, the OE path is wrong, and should also follow xdg paths Sep 23 18:36:24 Herrie|Pre3: updated https://github.com/webOS-ports/meta-webos-ports/pull/251 Sep 23 18:39:30 So, when JaMa will merge meta-smartphone, and when the new halium build I triggered will be done, we can bump tenderloin's Halium image and trigger a testing, and then a stable image Sep 23 18:40:51 Morning! Sep 23 18:42:55 FYI - I checked out the new qemux86 today. No new issues :) "Check for updates" no longer generates notifications. Thanks. Sep 23 18:45:36 MartinHov: ok, thanks for checking :) Sep 23 18:47:31 Welcome - whenever there is new qemux86 and I have some spare time - I will try it and let you know about issues .. Sep 23 18:50:48 MartinHov: we are gently getting closer to the release now - I fixed two annoying bugs (orientation sensor and TP crashes) today, and now the road should be ok Sep 23 18:52:51 Hopefully the next releases won't introduce so many issues, as Qt 5.9 is LTS and I don't feel like running the rabbit all the time :) Sep 23 19:16:53 I see, Qt 5.9 is a great step forward for LuneOS. Thanks all for the effort. - Is there some Architecture picture of LuneOS - what tech we are using at what level and area? Sep 23 19:55:56 well, there is this good old page http://www.webos-ports.org/wiki/Architecture Sep 23 19:56:49 the diagram is still valid, from what I can see Sep 23 20:31:27 Tofe: Great news on the fix! Sep 23 20:31:45 Isn't this something JaMa should fix in meta-qt5 eventually? Sep 23 20:37:04 Sorry for late reply, was out for dinner :P Mrs has b'day tomorrow so we had some quality time :P Sep 23 20:41:50 Tofe/MartinHov: I opened all changes in various tabs so I guess I can start putting a changelog together tomorrow for the release :) Sep 23 20:42:09 And to write up a draft for the release announcement :) Sep 23 21:01:23 Herrie|Pre3: ok great :) there is a halium build in the pipe, and then it's up to JaMa Sep 23 21:02:05 Herrie|Pre3: for the /etc/qt5 vs /etc/xdg confusion, yes, that's something that should be discussed with him; my fix is only a short-term solution. Sep 23 21:07:23 Tofe: thanks for Architecture link. At least I see bunch of terms and how they interact high-level. a starting point for me .. Sep 23 21:18:42 MartinHov: Yeah there's plenty. These are the main Sep 23 21:19:01 Underneath there are 2000+ components that make up the OS :P Sep 23 21:19:19 Tofe: Well it will work to get the release out Sep 23 21:19:48 Unstable builds show interesting bits in log. Seems we have some kernel options tweaking to do by the looks of it Sep 23 21:20:24 Tofe: But unstable is for later. Most kernel flags should be easy anyway Sep 23 21:20:53 I haven't seen this before during builds, could be some new Yocto "feature" Sep 23 21:21:30 Which isn't necessarily a bad thing, just means some housekeeping and will avoid possible errors later by the looks off it **** ENDING LOGGING AT Sun Sep 24 03:00:00 2017