**** BEGIN LOGGING AT Sun Oct 27 02:59:58 2013 Oct 27 08:45:39 morning Oct 27 09:05:32 Tofe: Morning Oct 27 11:02:08 morphis: I think I may have a lead Oct 27 11:02:36 we don't manage at all the transientParent hierarchy, and it looks like we should... Oct 27 11:02:56 I'm currently modifying a bit the compositor to see if I can improve that Oct 27 11:34:05 morphis: pong Oct 27 11:38:20 Tofe: ping Oct 27 11:53:13 JaMae: had an issue with initramfs-boot-android not rebuild when I build the kernel but it was my fault **** BEGIN LOGGING AT Sun Oct 27 12:14:10 2013 Oct 27 12:22:46 morphis: pong Oct 27 12:23:13 Tofe: what do you with that we don't manage the transientParent hierarchy? Oct 27 12:24:20 well, first, I can distinguish a "real" top-level window from a window that is actually positionned relatively to its transientParent Oct 27 12:25:36 but also, when a transientParent is destroyed with should *perhaps* (I'm not 100% sure) destroy its "children" surfaces Oct 27 12:26:26 Tofe: interesting Oct 27 12:26:52 https://github.com/webOS-ports/luna-next/commit/ed7b6e7e34d0bcbd45455a4fe3882bb0e8c02b6a <-- here are my current modifications Oct 27 12:27:32 it helps with the positionning of the transient child (the magnified in letter for instance) Oct 27 12:28:14 unfortunately it doesn't solve any other crash/problem with currently have (emulator of gnexus) Oct 27 12:28:49 so we get a well place keyboard with this? Oct 27 12:28:51 so the part about the destruction of transient children is currently useless, as far as I can observe Oct 27 12:28:56 yes Oct 27 12:29:32 but as soon as the keyboard is hidden, the party is over Oct 27 12:30:03 so we don't get it visible again, right? Oct 27 12:30:12 Right. also, the magnified letter never disappears. I think it's all connected. Oct 27 12:30:41 maybe we should not destroy the keyboard window Oct 27 12:30:42 ah, and in the emulator, it actually crashes in swapBuffer, so there may still be a fix missing Oct 27 12:30:44 but just hide it Oct 27 12:31:06 Tofe: maybe the emulator doesn't include the fix I submitted recently Oct 27 12:31:13 or did you build the emulator image locally? Oct 27 12:31:26 about surface format ? it does, I rebuilt it to make sure it does Oct 27 12:31:36 ok Oct 27 12:32:52 Tofe: maybe we have to follow the line starting from the input context plugin to see what maliit does and how we should work with that Oct 27 12:33:09 afaik the input context only says show or not show the input panel Oct 27 12:34:02 yes, it's also what I can see, just does show/hide. Maybe we are interpreting the wrong way. Oct 27 12:37:44 I'm surprised that wayland calls surfaceAboutToBeDestroyed just to hide a QQuickView Oct 27 12:38:40 Tofe: https://github.com/maliit/framework/blob/master/src/quick/inputmethodquick.cpp#L161 Oct 27 12:40:11 Tofe: it seems like maliit sets the size of the input method area to zero Oct 27 12:40:19 when it should be hidden Oct 27 12:41:45 Tofe: maybe time to ask in #maliit Oct 27 12:42:03 maybe Oct 27 12:42:57 or ask at http://lists.maliit.org/listinfo.cgi/maliit-discuss-maliit.org Oct 27 12:46:26 Tofe: btw. you tried running maliit-server with MALIIT_DEBUG=1? Oct 27 12:46:38 mmmh no, not that one Oct 27 12:49:35 Oct 27 05:47:28 maguro maliit-server[1531]: WARNING: QEGLPlatformContext::makeCurrent: eglError: 300b, this: 0xcfe970 , I think when trying to show it again Oct 27 12:49:51 Tofe: https://github.com/maliit/framework/blob/master/src/mimpluginmanager.cpp#L976 is called when the input context requests to hide the input panel Oct 27 12:52:32 Tofe: 300b is EGL_BAD_NATIVE_WINDOW Oct 27 12:52:45 so the window is destroyed when it's still needed Oct 27 12:52:50 what we expected Oct 27 12:53:11 ok, I'll inhibit the destruction of maliit windows Oct 27 12:54:24 Tofe: https://github.com/maliit/plugins/blob/master/maliit-keyboard/plugin/inputmethod.cpp#L384 Oct 27 12:54:37 thats what it's doing for the maliit keyboard Oct 27 12:54:41 it hides all windows Oct 27 12:54:55 and shows and updates them when the input panel should be visible again Oct 27 12:55:14 yes, but why are we called in surfaceAboutToBeDestroyed ? shouldn't we simply be called on unmap ? Oct 27 12:55:16 so we really should not destroy the surfaces but take the visible state into account Oct 27 12:55:29 hm Oct 27 12:55:39 maybe it's something about resource management Oct 27 12:55:57 if the window is hidden why shouldn't we reallocate the surface when it gets visible again? Oct 27 12:57:30 I'm going to try a quick hack: if( window->checkIsAllowedToStay() ) return; at the start of surfaceAboutToBeDestroyed Oct 27 12:58:18 ok Oct 27 12:58:40 DDURI: hey Oct 27 12:59:04 hi Oct 27 12:59:49 Tofe: btw. you see it too that the gnexus restarts sometimes when it crashes? Oct 27 13:00:08 morphis: yes Oct 27 13:00:16 no often, but yes Oct 27 13:00:47 ok Oct 27 13:05:16 morphis: my hack didn't help that much; I still get crashes, and maliit-server[1805]: WARNING: QEGLPlatformContext::makeCurrent: eglError: 3009, this: 0x1ebc510 when I hide the keyboard, just before maliit crashes Oct 27 13:05:54 hm, 3009 is EGL_BAD_MATCH Oct 27 13:06:07 so some format issue Oct 27 13:07:03 a problem also is that the first magnigied window always stays visible, is never updated/hidden/moved when I hit another key Oct 27 13:09:50 Tofe: we're currently set the position of a window when it's created, right? Oct 27 13:10:10 so maybe we have to check for position updates as well Oct 27 13:12:14 right Oct 27 13:12:44 but the QWaylandSurfaceItem should go that job Oct 27 13:12:47 do* Oct 27 13:13:37 hm Oct 27 13:14:00 we are called on surfaceUnmapped, I guess when it wants to hide Oct 27 13:16:42 possible Oct 27 13:18:02 but then I don't understand how a show/hide could work in our compositor: surfaceMapped is not symmetric to surfaceUnmapped Oct 27 13:20:25 Tofe: but it seems to be a qtwayland problem then as from what I understood it should be symmetric Oct 27 13:20:55 I was looking at https://qt.gitorious.org/qt/qtwayland/source/1b39d072c2601d39354fe83dff8b1e5c05095aaf:examples/qml-compositor/main.cpp#L112 where it is symmetric Oct 27 13:24:12 Tofe: hm, we're creating a new compositor window inside surfaceMapped each time Oct 27 13:24:46 the qml-compositor does it only if no one exists Oct 27 13:24:55 maybe thats one problem here Oct 27 13:25:11 I've inserted the test on our side Oct 27 13:25:11 we're taking every surfaceMapped signal as there is a new window created Oct 27 13:25:29 which isn't the case everytime (when we're dealing with show/hide) Oct 27 13:26:10 ok Oct 27 13:27:17 I think that will help to some degree Oct 27 13:27:43 at least it's cleaner Oct 27 13:28:20 right Oct 27 13:28:30 does it help at runtime? Oct 27 13:30:23 not so much, I still get a EGL_BAD_MATCH when hiding the keyboard Oct 27 13:32:51 hm Oct 27 13:36:18 It may be that we are being too soft when handling unmapped Oct 27 13:36:51 too soft? Oct 27 13:37:17 well, the qml compositor I gave earlier does destroy the window item when unmapped occurs Oct 27 13:37:30 we only do... well, nothing. Oct 27 13:37:52 yeah, but why should we destroy the window? Oct 27 13:38:11 we can try that but I doubt it will help Oct 27 13:38:42 It doubt it too, frankly. But we can still hide the CompositorWindow itself. Oct 27 13:39:40 it you mean hiding the QWaylandSurfaceItem in QML? Oct 27 13:39:52 no, in the compositor Oct 27 13:39:57 hm Oct 27 13:40:28 otherwise, doesn't it try to render it, when it maybe has no surface mapped ? Oct 27 13:42:06 hm Oct 27 13:42:14 afaik it should not when visible = false Oct 27 13:44:20 ok, have to leave for some time Oct 27 13:44:38 oki Oct 27 14:49:10 Tofe: back Oct 27 15:05:27 Tofe: any news while I was away? Oct 27 15:13:05 morphis: no, not much Oct 27 15:13:13 ok Oct 27 15:13:27 I've debugged the hide/show, and we go in hide() and show() in maliit when we should Oct 27 15:13:51 there are some mysterious surfaces mapped, though, when the keyboard gets hidden Oct 27 15:14:37 morphis: are you fluent in wayland debug messages ? Oct 27 15:16:19 http://pastebin.com/xSs93Abm Oct 27 15:17:01 here is an output; the interesting stuff (hide of maliit) happens around line 1950 Oct 27 15:17:18 Tofe: let me look Oct 27 15:18:20 I especially don't understand lines 1953-1956 Oct 27 15:20:30 My guess is that somehow, maybe because we didn't repect wayland protocol somewhere or something else, we end up we maliit that believes he already has its windows mapped and visible Oct 27 15:20:42 s/we/with Oct 27 15:20:53 Tofe: 1953-1956 are: Oct 27 15:20:54 Oct 27 07:21:15 maguro maliit-server[1610]: [2990335.069] wl_callback@40.done(2) Oct 27 15:20:54 Oct 27 07:21:15 maguro maliit-server[1610]: WARNING: QEGLPlatformContext::makeCurrent: eglError: 3009, this: 0xd86f50 Oct 27 15:20:54 Oct 27 07:21:15 maguro maliit-server[1610]: [2990336.900] qt_extended_surface@26.onscreen_visibility(1) Oct 27 15:20:54 Oct 27 07:21:15 maguro maliit-server[1610]: [2990336.961] qt_extended_surface@29.onscreen_visibility(1) Oct 27 15:20:57 ? Oct 27 15:21:11 yes Oct 27 15:21:35 but that is *after* I clicked outside the text entry to make maliit hide itself Oct 27 15:22:17 ah Oct 27 15:22:18 line 1960 is where maliit's window get unmapped, if I'm not mistaken. Oct 27 15:22:23 and not before? Oct 27 15:22:32 as Oct 27 15:22:32 Oct 27 07:21:15 maguro maliit-server[1610]: [2990324.357] -> wl_surface@24.attach(nil, 0, 0) Oct 27 15:22:32 Oct 27 07:21:15 maguro maliit-server[1610]: [2990324.479] -> wl_surface@24.commit() Oct 27 15:22:32 Oct 27 07:21:15 maguro maliit-server[1610]: [2990324.632] -> wl_surface@27.attach(nil, 0, 0) Oct 27 15:22:32 Oct 27 07:21:15 maguro maliit-server[1610]: [2990324.693] -> wl_surface@27.commit() Oct 27 15:22:37 looks also interesting Oct 27 15:22:50 yes, but I don't know what attach is for Oct 27 15:23:02 * morphis hopes nobody has a problem with him pasting things here for a better and fluent discussion .. Oct 27 15:23:22 Tofe: attach sets the content of a wayland surface Oct 27 15:23:31 like attaching a buffer with content to a surface Oct 27 15:23:46 ok, it's the link between the wayland surface and the native surface Oct 27 15:24:11 or native buffer. Well, ok, I understand. Oct 27 15:24:27 Tofe: http://cgit.freedesktop.org/wayland/wayland/tree/protocol/wayland.xml#n982 Oct 27 15:24:56 Tofe: http://cgit.freedesktop.org/wayland/wayland/tree/protocol/wayland.xml#n1021 is interesting Oct 27 15:25:31 so it looks like the hide is already starting in line 1932 Oct 27 15:28:32 the first detach is line 1924 Oct 27 15:28:55 yes Oct 27 15:29:00 is there one numbering per process ? Oct 27 15:30:02 because wl_surface@21 seems pretty important for luna-next Oct 27 15:31:40 I am not sure yet about the numbering Oct 27 15:32:02 looks like wl_surface@21 is the keyboard window, I'd say Oct 27 15:32:46 maliit asks for detach line 1924, which is treated line 1957 by luna-next Oct 27 15:33:01 (I've activated both client and server side for WL debug) Oct 27 15:33:18 hm, it only unmaps one window but maps two afterwards Oct 27 15:34:56 Tofe: btw. starting from line 69 it unmapps both keyboard windows Oct 27 15:35:02 the magnifier and the keyboard itself Oct 27 15:36:01 mmh yes. Oct 27 15:36:31 oh wait, I've made a little mistake in my pastebin: it's a bit too long; line 925, I did restart maliit and luna-next Oct 27 15:36:59 still, you're right, see line 1128 Oct 27 15:37:38 I quite don't know what these surfaces are Oct 27 15:39:35 ah, I got it: I never hit a key, so it means the magnifier and the extended surfaces are never shown, thus never mapped Oct 27 15:40:01 ah Oct 27 15:40:11 that explains it Oct 27 15:40:34 surface @21 is the main keyboard surface, surfaces @24 and @27 are the other ones, the transient children Oct 27 15:41:33 ok, from what I've read in the maliit keyboard source all three windows are shown at the same time Oct 27 15:41:44 but the helper ones have a size of 0x0 Oct 27 15:43:38 so lines 1963 and 1964 are a mystery to me: why bother mapping this one now ? Oct 27 15:44:41 and I don't see why line 1954 (the EGL error) occurs. Oct 27 15:44:54 hm Oct 27 15:45:49 are we ever setting the surfaceItem? Oct 27 15:46:46 ah QWaylandSurfaceItem does it Oct 27 15:47:24 yeah, and later on I'm eventually able to retrieve the surfaceItem of the keyboard surface to make it the parent of the two transient children Oct 27 15:50:06 It would be great if I would put a callback when the lines 1954-1956 occur Oct 27 15:53:11 I've got to leave; but i'll try to see what trigger this visibility of the two secondary surfaces Oct 27 15:53:51 ok Oct 27 15:54:07 I will think and read a little bit about this whole thing a little bit Oct 27 15:54:19 it really looks like we've overseen something Oct 27 15:54:39 yes Oct 27 15:55:01 btw, line 2034 is where maliit asks for show(), I think. Oct 27 15:55:26 maybe we just didn't update something in QML ? Oct 27 16:10:19 Tofe|Away: btw. with your recent changes for luna-next you're going to add the window twice if it gets remapped Oct 27 16:10:45 when we get a surfaceMapped signal for a window which already has a surfaceItem we should not send the windowAdded signal again Oct 27 16:11:34 Tofe|Away: ah and you're not handling the windowHidden signal too Oct 27 17:05:53 morphis: oh, right **** ENDING LOGGING AT Mon Oct 28 02:59:58 2013