**** BEGIN LOGGING AT Wed Apr 24 02:59:57 2019 Apr 24 07:02:15 Morning! Apr 24 07:20:21 Morning! Apr 24 08:26:32 So, the current status of warrior+Qt 5.12 on tissot isn't that good: firstuse works, but no vkb, and webappmanager doesn't seem to start anything (justtype, enyo apps...) Apr 24 08:29:28 all this is probably related to the change I did in luna-next, i.e. changing from deprecated WlShell to XdgShell Apr 24 08:31:44 I'm just surprised we don't get the same issues in qemu, but well. Apr 24 08:31:44 Tofe: Well the fix could be small then as well ;) Apr 24 08:33:00 Herrie|Laptop: I'm not to worried, there's a good chance this will be easy to fix Apr 24 08:33:46 I'll kick off a Hammerhead build in a minute Apr 24 08:33:52 And test that later Apr 24 08:34:04 I guess best to do normal and not mainline right? Apr 24 08:37:15 yes, let's stick to normal for now Apr 24 08:37:24 take my warrior branches Apr 24 08:37:49 for mainline I'll need to rebase my sumo commits anyway Apr 24 13:11:51 Tofe: Which meta-qt5 I need? MAster? Apr 24 13:12:28 Seems my layers.txt still has thud Apr 24 13:13:47 Seems that warrior = master Apr 24 13:13:51 warrior-next has 1 more commit Apr 24 13:14:40 Will take the warrior-next Apr 24 13:14:51 Diff is only the added tags for 5.12.3 Apr 24 13:27:03 Herrie|Laptop: warrior or master should be quite the same Apr 24 13:28:21 Herrie|Laptop: I took warrior on my side Apr 24 13:29:51 Well I took warrior-next but that's mainly to pick up the 5.12.3 release tags for some components Apr 24 13:30:07 https://github.com/meta-qt5/meta-qt5/commit/2d89985c573a5fb9b663183d75af0acada450bdc Apr 24 13:30:16 Shouldn't really have an impact on our things by the looks of it Apr 24 13:32:20 That failed quickly: https://bpaste.net/show/f25defde0ebb Apr 24 13:35:02 you took "warrior" from my Tofee meta-webos-ports repo, right ? Apr 24 13:35:07 same for meta-smartphone Apr 24 13:38:19 I have https://github.com/Tofee/meta-smartphone-1/tree/warrior Apr 24 13:38:50 that's fine Apr 24 13:38:52 Ah yours is ahead of webos-ports one Apr 24 13:39:00 Just the 2 months ago last commit mislead me Apr 24 13:39:24 yes, I picked commits from master Apr 24 13:40:35 OK retrying ;) Apr 24 13:40:57 Hopefully with this huge pile of commits, it's all-or-nothing Apr 24 13:54:21 Seems to behave better Apr 24 13:54:34 qtbase done, now qtwebengine will start I guess Apr 24 14:24:18 Still not finished !? You'll have to upgrade your rig ! ;-) Apr 24 14:27:15 Yeah it's a bit slow Apr 24 14:27:22 Well 97% of webengine Apr 24 14:27:26 So shouldn't be that much longer Apr 24 15:32:53 Tofe: Hmmz: https://bpaste.net/show/2a71246a59a1 Apr 24 16:14:34 my fault Apr 24 16:14:46 it's not the correct initramfs Apr 24 16:15:33 I am in the subway, I'll fix that in 30min Apr 24 16:16:22 ah it's because I took the patches from the hammerhead mainline Apr 24 16:16:39 it's just one line though Apr 24 16:16:54 in the machine conf Apr 24 16:46:32 Herrie|Laptop: I've pushed a new commit, should help Apr 24 16:46:42 in meta-smartphone Apr 24 16:46:59 Tofe: OK was just about to post that line :P Apr 24 16:47:47 Now I'll begin some luna-next investigation on tissot :p Apr 24 16:50:48 ah, first find: "Apr 20 05:32:20 tissot LunaWebAppManager[2799]: WARNING: 05:32:20.636: file:///usr/lib/qml/LuneOS/Components/LunaWebEngineView.qml:56:14: ".fullScreenSupportEnabled" is not available due to component versioning." Apr 24 16:50:58 that'll be an easy one Apr 24 16:54:37 Yeah should be Apr 24 16:55:48 though I don't really see why the versioning is wrong, we do "import QtWebEngine 1.4" and it's there since 1.2 Apr 24 17:10:44 looks like it's a bug in Qt due to QML properties versionning... Apr 24 17:11:05 but, hopefully, the default value it already the good one, so let's just remove this line Apr 24 17:15:28 https://github.com/webOS-ports/luneos-components/pull/90 Apr 24 17:18:10 I've push to my meta-webos-ports the SRCREV bump Apr 24 17:18:51 it fixed luna-webappmanager. Now there's still the vkb which doesn't show up, and justtype which shows up as a regular card Apr 24 17:18:54 Tofe: Seems it's disable by default Apr 24 17:19:11 https://doc.qt.io/qt-5/qml-qtwebengine-webenginesettings.html#fullscreenSupportEnabled-prop you sure? Apr 24 17:19:16 As per https://doc.qt.io/qt-5/qwebenginesettings.html Apr 24 17:19:17 +d Apr 24 17:19:56 This one says disabled: https://doc.qt.io/qt-5/qwebenginesettings.html Apr 24 17:20:09 ah, great, they didn't put the same default for QML and C++... Apr 24 17:21:22 I'll double-check in the code itself Apr 24 17:26:15 so, by default it's false, *but* the profile sets it to "true" when it's created Apr 24 17:26:58 https://github.com/qt/qtwebengine/blob/5.12/src/webengine/api/qquickwebengineprofile.cpp#L159 Apr 24 17:27:25 What a mess. But we're lucky, it's what we want... so we won't have to wait for the bugfix of the property versioning Apr 24 17:51:44 Ok, I think I understand the issue: XdgShell surfaces don't handle window properties anymore... Apr 24 18:09:47 Tofe: Is this of any help? Apr 24 18:09:54 https://patchwork.freedesktop.org/patch/216159/ Apr 24 18:18:13 nope, in itself the issue is that currently an xdgshell surface doesn't try to send the window properties through the "extendedsurface" wayland extension Apr 24 18:18:38 I could write a patch for that, but it would probably break at every qtwayland update Apr 24 18:20:05 in the end I see 3 ways of handling this: Apr 24 18:20:30 1. go back to wlshell (which still works), but then we're back at the black surface issue on qemu Apr 24 18:21:09 2. write the patch so that an xdgshell surface does handle extendedsurfaces Apr 24 18:21:53 3. find a way to use our own extension, independently of xdgshell, to communicate properties between clients apps and compositor Apr 24 18:22:12 Tofe: 2 is probably best future proof solution? Apr 24 18:22:27 For 3 isn't that why there was the Luna bus? Apr 24 18:22:42 To deal with such kind of things? Apr 24 18:23:56 I'll go and try 2., yes. Maybe there's a way for us to avoid being impacted too much by future updates Apr 24 18:24:20 For 3 I mean the Luna bus was made for these kind of communications system wide Apr 24 18:25:14 For 3. I'm just not sure if we'll need the actual window objects at some point or not Apr 24 18:26:40 For now, let's just try 2. Apr 24 18:27:38 2 is probably easier and some similar code might be around in other projects? Apr 24 18:30:41 I'll just copy/paste some code from WlShellSurface :) Apr 24 18:31:01 actually if I put it in the parent class, it might do the trick as well Apr 24 18:35:55 I think it's implemented now, more or less Apr 24 18:37:14 That's quick :P Apr 24 18:38:51 It was just moving some code around... but I didn't say it compiles, or run :p Apr 24 18:47:13 now it builds... let's test... Apr 24 18:47:38 :) Apr 24 18:51:59 mmh no, didn't help much Apr 24 20:14:15 Herrie: I've pushed two fixed in my meta-webos-ports Apr 24 20:14:36 it fixes justtype and such; but no vkb yet... Apr 24 20:16:15 actually it also fixes the vkb ! I just forgot to restart the systemd unit Apr 24 20:17:00 I think we're good for a merge now :p Apr 24 20:18:39 It wouldn't hurt to test if tenderloin is still ok, though Apr 24 20:21:44 that'll be all for tonight for me :) Apr 24 20:57:04 Tofe: Nice! Apr 24 20:57:09 Will test Hammerhead & Tenderloin **** ENDING LOGGING AT Thu Apr 25 03:00:02 2019