**** BEGIN LOGGING AT Sat Nov 23 02:59:57 2019 Nov 23 08:05:18 Morning Nov 23 08:18:41 Morning! Nov 23 08:22:35 Herrie: our appmanager starts an app using palm://org.webosports.webappmanager/launchUrl ... this isn't going to work with OSE's WAM :) Nov 23 08:23:12 sorry, using "palm://org.webosports.webappmanager/launchApp" Nov 23 08:25:03 ah no sorry, you already changed that, I didn't look at the right branch Nov 23 08:25:35 need more coffee :p Nov 23 08:27:33 mmmh "Miss launch parameter(s)" Nov 23 08:30:16 "params" arg name changed to "parameters" Nov 23 08:32:59 Well that's easy to fix ;) Nov 23 08:35:34 ... and parameters needs to be an object, damn Nov 23 08:45:49 ah, now we hit the missing wayland extensions! Nov 23 08:46:14 [1110/143251.812276:ERROR:ozone_wayland_window.cc(155)] Not implemented reached in virtual void ui::OzoneWaylandWindow::InitPlatformWindow(ui::WaylandPlatformWindow::PlatformWindowType, gfx::AcceleratedWidget) Nov 23 08:57:54 Tofe: I have seen something similar in OSE VBox log Nov 23 08:58:09 Not sure it was the same though Nov 23 08:59:14 well it's not fatal here, but surprising, because the window type is "PLATFORM_WINDOW_TYPE_WINDOW_FRAMELESS" which is quite usual for webos Nov 23 08:59:34 our background apps are all like that Nov 23 08:59:44 then, later on, it just crashes Nov 23 08:59:59 in viz::SoftwareOutputDeviceOzone::SoftwareOutputDeviceOzone () at ../../git/src/components/viz/service/display_embedder/software_output_device_ozone.cc:18 Nov 23 09:01:55 the whole stack: https://bpaste.net/show/XUF6Q Nov 23 09:02:22 so many things might have go wrong, I wonder which one it is :) Nov 23 09:05:51 Herrie: I pushed the luna-appmanager fix on top of your branch Nov 23 09:11:33 It looks like the whole renderer thing couldn't start properly Nov 23 09:38:04 Tofe: Thnx for push Nov 23 09:52:50 and now I have another crash in wayland... let's just use chromium's wayland. Nov 23 10:04:39 Tofe: worth a try Nov 23 10:05:02 This is also still Chromium 68 and not 72 because 72 has build issues with Zeus still Nov 23 10:16:40 It's true that webruntime seems to build faster... I'm already at 52% Nov 23 10:23:15 I guess it's somehow better taking advantage of multiple CPU's. I noticed it's significantly faster v.s. qtwebengine Nov 23 10:37:39 mmh build failed :( Nov 23 10:39:41 ah, my bad, I forgot ozone_platform_wayland=true Nov 23 10:39:59 let's go for another build... Nov 23 11:40:29 morning Nov 23 11:44:07 it's using jumbo builds which might make some difference Nov 23 13:37:41 I think that *not* using upstream wayland has not been tested on OSE builds Nov 23 13:38:04 both AGL and webOS use upstream as far as I can see Nov 23 13:38:24 oh, well. Then let's just try to make it work. Nov 23 14:48:27 I think I figured out the real issue here; it's about wayland extensions, unfortunately Nov 23 14:49:24 our luna-next provides a "xdg_wm_base" shell extension, which is about integrating the windows in a desktop, roughly Nov 23 14:50:27 but chromium doesn't know that kind of extension yet... Nov 23 14:50:42 (it's a pretty recent one) Nov 23 15:06:13 Tofe: Chromium 68 doesn't know it yet or 72 also not? Nov 23 15:07:24 I didn't check 72 Nov 23 15:08:26 Herrie: nope: https://github.com/webosose/chromium72/blob/master/src/ozone/wayland/shell/shell.cc#L96 Nov 23 15:09:12 I can try to make so that luna-next handles both wl_shell and xdg_wm_base Nov 23 15:10:36 or even propose wl_webos_shell... not sure though at that point Nov 23 15:11:56 at some point, we might even try to make SAM work with our cardshell Nov 23 15:12:52 Yes, SAM = luna-sysmgr more or less. Not 1:1 but most is there. We still have some things we use from luna-sysmgr that are not in SAM I think. Nov 23 15:13:19 ah, SAM isn't just the compositor? Nov 23 15:13:28 wl_webos_shell comes from OSE Wayland extensions I guess? Nov 23 15:13:32 yes Nov 23 15:14:23 I think luna-surfacemanager is the compositor but could also be their cardshell Nov 23 15:15:13 Description Nov 23 15:15:13 This package contains the wayland compositor implementation for webOS based on Qt/QML Nov 23 15:15:53 So seems that's their compositor Nov 23 15:17:04 it's the cardshell too, it seems; it's merged Nov 23 15:22:16 In the end, using SAM with our cardshell seems the way to go; but we need smaller steps :p Nov 23 15:22:45 so, I guess proposing an alternate simple wl_shell in luna-next can provide that Nov 23 15:23:52 Yes. You might be even able to borrow code from luna-surfacemanager for wl_webos_shell? Nov 23 15:24:56 wl_shell, not wl_webos_shell Nov 23 15:25:25 I don't think the effort of support their shell is worth it, compared to switching to SAM Nov 23 15:38:25 Tofe: Trust you on that **** BEGIN LOGGING AT Sat Nov 23 15:44:16 2019 Nov 23 16:00:33 mmh black window Nov 23 16:00:41 (and fullscreen) Nov 23 16:01:02 but it might also be my hammerhead Nov 23 16:04:13 Herrie: https://github.com/webOS-ports/luna-next/tree/tofe/webruntime Nov 23 16:06:29 Herrie: https://paste.ubuntu.com/p/4N4nsX5NRR/ this has to be applied to chromium so that it doesn't crash with our newer wayland Nov 23 16:07:10 the rest of my fixes are just changing UID and GID to "root" in the shell, and exporting XDG_RUNTIME_DIR=/tmp/luna-session Nov 23 16:08:03 ah and the change in luna-appmanager too Nov 23 16:09:56 Now I think it's EOL for my testing on hammerhead-mainline, as I can't say if the black screen is because of the graphic driver or because of chromium... I wanted to keep that build, but well, I'll switch back to some more "classic" target :) Nov 23 16:39:04 Tofe: thnx, will try this all on qemux86 on my side Nov 23 16:39:19 How do I change the GID and UID? Nov 23 16:47:23 just modify the shell script Nov 23 16:48:31 Herrie: https://paste2.org/gDFmeLzb Nov 23 16:50:51 Ah ok, easy enough. Busy with some painting of basement today, might have some time tonight or tomorrow **** ENDING LOGGING AT Sun Nov 24 02:59:58 2019