**** BEGIN LOGGING AT Tue Sep 24 02:59:59 2019 Sep 24 09:38:32 Tofe: New PinePhone video looks good. Seems Clock app needs a little tuning though ;) Sep 24 09:57:18 Yes, there might be some hardcoded value or something Sep 24 09:57:18 Seems so ;) https://github.com/webOS-ports/core-apps/blob/webOS-ports/master/com.palm.app.clock/css/clock.css#L46 Sep 24 09:57:18 And there are more like that Sep 24 09:57:18 Would need to have a look at my 2.2.x webOS devices to see what it does there **** BEGIN LOGGING AT Tue Sep 24 09:58:30 2019 Sep 24 18:03:04 Tofe: While testing Qemux86-64 I noticed that I cannot click on the layers that appear in for example Maps app when you enter an address. I need to confirm this issue is existing on actual devices though Sep 24 18:03:27 I kinda recalled that it worked when I tested previously, so could be it's limited to qemux86-64 Sep 24 18:03:34 MAybe something you can quickly check on Pinephone? Sep 24 18:06:52 let's see Sep 24 18:08:18 ah but wait I don't have wifi yet on pinephone :P Sep 24 18:08:24 Tofe ah ;) Sep 24 18:10:27 Let me try on Hammerhead then Sep 24 18:11:02 i'm on tissot Sep 24 18:11:21 you mean the checkboxes? Sep 24 18:12:05 well the UI is badly scaled (far too big), but otherwise it's functional Sep 24 18:12:16 Tofe: No in Google maps when you enter an address, the overlay with address suggestions Sep 24 18:12:24 I cannot tap on those in qemux86 Sep 24 18:12:47 it's working on tissot Sep 24 18:13:16 OK probably just something on the qemu then Sep 24 18:13:25 maybe yes Sep 24 18:13:26 The tap ripple is randomly at the wrong place too sometimes Sep 24 18:13:41 ah, that thing again?... Sep 24 18:13:54 Well it's mainly OK, just sometimes it appears at the wrong place Sep 24 18:14:03 ok Sep 24 18:14:16 I would say 90% of time it's OK. 10% at wrong place Sep 24 18:14:23 Bit of clicking around and it behaves again Sep 24 18:14:43 Actually overlay now works in qemu Sep 24 18:14:51 Could be it's the VKB that's causing the issue somehow Sep 24 18:15:53 Hmmz something weird going on. Overlay worked, then VKB stopped working, I killed Maps now it doesn't want to restart Sep 24 18:15:55 Let me check logs Sep 24 18:16:14 meh Sep 24 18:19:46 https://paste.ubuntu.com/p/GTt4BFZcFT/ Sep 24 18:20:23 Sep 24 19:16:59 qemux86-64 LunaAppManager[474]: The Wayland connection broke. Did the Wayland compositor die? Sep 24 18:20:31 And Sep 24 19:17:02 qemux86-64 LunaAppManager[474]: Application org.webosports.app.maps is already running and registered with the process manager Sep 24 18:20:34 But it doesn't show Sep 24 18:20:51 luna-next crashed?... Sep 24 18:20:53 So I guess destruction of the app window somehow fails Sep 24 18:21:05 Tofe: Well cardshell works and I can launch browser Sep 24 18:21:25 mmh wreird Sep 24 18:21:26 QML apps work, Enyo 1/2 not Sep 24 18:21:42 ok, then luna-webappmanager might have crashed Sep 24 18:22:52 Well it doesn't seem like it... Just some other wayland issues it might be: Sep 24 18:22:54 Sep 24 19:16:28 qemux86-64 LunaWebAppManager[759]: WARNING: 19:16:28.140: Setting cursor position is not possible on wayland Sep 24 18:22:54 Sep 24 19:16:28 qemux86-64 LunaWebAppManager[759]: WARNING: 19:16:28.174: Non-toplevel surfaces can't request window states Sep 24 18:23:54 those ones aren't very fatal I think Sep 24 18:26:21 If i restart luna-webappmanager things behave again Sep 24 18:27:04 mmh Sep 24 18:27:26 systemd should have taken care of that, weird Sep 24 18:28:51 Well it didn't die Sep 24 18:29:00 I just did systemctl restart luna-webappmanager Sep 24 18:29:05 Sep 24 19:27:44 qemux86-64 LunaWebAppManager[1158]: [1158:1182:0924/192744.509292:WARNING:spdy_session.cc(3097)] Received HEADERS for invalid stream 5 Sep 24 18:29:12 That doesn't look healthy either Sep 24 18:29:26 nope... Sep 24 18:29:57 Sep 24 19:28:34 qemux86-64 luna-next[542]: WARNING: 19:28:34.433: virtual void QWaylandXdgPopupPrivate::xdg_popup_grab(QtWaylandServer::xdg_popup::Resource*, wl_resource*, uint32_t) Not implemented Sep 24 18:30:06 All shouldn't be too fatal by themselves Sep 24 18:30:40 Just this doesn't look healthy: Sep 24 19:28:56 qemux86-64 LunaAppManager[474]: mimeType: [application/crt] , primary: { "mime": "application\/crt", "extension": "crt", "appId": "org.webospThe Wayland connection broke. Did the Wayland compositor die? Sep 24 18:30:47 Could be qemu specific though Sep 24 18:30:55 Woudl need to test more on actual device Sep 24 18:32:47 could be, hard to tell Sep 24 18:33:01 Well I'm just clicking around some app, doing a few things and checking Sep 24 18:33:17 If you do the same on Tissot & check logs you might have a clue Sep 24 18:40:41 Hmmz on Hammerhead it's stuck on "Loading Google Maps API" :s Sep 24 18:40:47 google.com, html5test.com work :S Sep 24 18:40:52 restart maps Sep 24 18:41:25 Doesn't help restarting luna-next now Sep 24 18:41:54 Hmmz same, weird Sep 24 18:42:18 Ah date issue I guess Sep 24 18:42:36 ah could be Sep 24 18:43:59 Set it but doesn't seem to take direct effect everywhere, rebooting Sep 24 18:46:57 Seems OK now Sep 24 18:47:00 Was the date Sep 24 18:47:07 I guess causing the https calls not to work Sep 24 18:48:53 ok Sep 24 18:49:20 sorry I'm not too focused on this issue, but I'm trying to setup sensorfw for pinephone Sep 24 18:50:17 Ah ok, any luck? Sep 24 18:50:38 well sensorfw builds fine, now I'm trying to plug it into qtsensors Sep 24 18:58:48 Tofe: That never really was an issue before? Sep 24 18:59:57 for halium we have sensorfw already well configured Sep 24 19:00:30 plus, we use https://github.com/webOS-ports/qtsensors-sensorfw-plugin, but I'm not sure why; QtSensors seems to support sensorfw natively now Sep 24 19:01:54 https://github.com/qt/qtsensors/tree/5.12/src/plugins/sensors/sensorfw Sep 24 19:03:54 Qt Sensors: sensorfw ............................... no Sep 24 19:04:00 ok, issue identified :)) Sep 24 19:04:01 we want to have it in separate package, only for needed machines? Sep 24 19:04:50 if sensorfw supports iio sensors, we would want to use it as a generic backend Sep 24 19:05:02 though machine dependent still Sep 24 19:05:15 because it uses libybris on halium targets Sep 24 19:09:32 Tofe: Well our plugin basically is a small subset of qtsensors Sep 24 19:09:47 I remember updating it based on Qt repos at some point Sep 24 19:10:51 The code didn't change a whole lot over the years, just a few new sensors were added if I recall correctly Sep 24 19:11:36 I don't really see why we bother with our own fork here Sep 24 19:13:55 Tofe: Seems it was historical. Happy to use upstream where possible Sep 24 19:14:07 me too :) Sep 24 19:14:22 Just never got to clean it up, just kept it updated with the changes Sep 24 19:14:44 I'll do a big commit for sensors once I get it running with pinephone Sep 24 19:17:26 morphis explained that here: http://logs.nslu2-linux.org/livelogs/webos-ports/webos-ports.20150225.txt Sep 24 19:19:03 ah ok, qtsensors shouldn't become MACHINE_ARCH Sep 24 19:20:52 though I'm not sure I see an issue with qtsensors becoming so Sep 24 19:21:37 Tofe: We could also just structure the repo so it's a submodule ? Sep 24 19:22:12 for the moment I'll just push the qtsensor possibility, and see more precisely why we would get stuck Sep 24 19:30:25 I would suspect that anyway it's MACHINE_ARCH already maybe Sep 24 19:31:55 not yet no Sep 24 19:42:28 btw: I've triggered all builds on unstable to see how good or bad Zeus is, it should be released probably next week Sep 24 19:51:29 ah, luna-sysmgr would become MACHINE_ARCH... that's not nice Sep 24 19:51:55 ok let's keep our fork then :p **** ENDING LOGGING AT Wed Sep 25 02:59:57 2019