[01:11] <mterry> kgunn_, poke!
[01:12] <mterry> kgunn__, poke
[01:16] <mterry> If anyone can test and confirm that with latest mir/devel, unity8 & keyboards have the weird reaction that keypresses "fall through" to shell behind it -- seemingly because the keyboard surface doesn't switch to the "maximized" Mir state
[01:17] <mterry> Why might that be?
[01:23] <racarr> mterry: Always with the good news.
[01:23] <mterry> racarr, :)
[01:24] <racarr> I have no clue why that would happen but can look at it when I look at the screen stuff which should be first thingtomorrow
[01:26] <mterry> racarr, if you are the one that ends up looking at it -- I got as far as noting that unity-mir blocks the keypresses falling through once the surface switches to the Mir maximized state in OSKController.qml.  But I didn't see why the maximized behavior would have changed
[01:28] <duflu> mterry: Could it be because the OSK was written assuming the old Mir behaviour of MirMotionEvent.x/y always being relative to the screen? That changed recently and the touch events will be relative to the top-left corner of the OSK, which if it hasn't been updated will easily be off-screen :)
[01:29] <mterry> duflu, it's not about the press events themselves I don't think.  Just whether the keyboard Mir surface reports that it is "maximized" or not
[01:30]  * duflu wonders if the design docs define what "maximized" means for decoration-less touch devices
[01:31] <mterry> duflu, plus this is a weird keyboard surface anyway
[01:31] <duflu> mterry: From a high level I can tell you that input coordinates have changed. So if the position of the OSK has changed, then that will definitely be a problem
[01:32] <mterry> duflu, position of the OSK shouldn't have changed.  And it appears in the same place
[01:32] <mterry> duflu, it's just that Mir never sends a "state changed to maximized" event which unity-mir listens for in order to stop key presses falling through
[01:33] <duflu> mterry: It *appears* to be in the same place. But if it's been converted from a fullscreen surface (with transparency) to a smaller surface positioned at the bottom of screen then that's an issue
[01:35] <mterry> duflu, I see.  And you think changes in Mir might have automatically changed it from fullscreen to smaller surface?
[01:35] <duflu> mterry: No, for performance we need to (and might have already) got rid of the fullscreen approach. If that happened at the same time as global input coordinates going away (which they did) then it could get confused
[01:36] <mterry> duflu, in my testing, ubuntu-keyboard/unity-mir/maliit haven't changed
[01:36] <mterry> duflu, just been rebuilt against mir/devel (to my knowledge -- need kgunn to confirm which branches he pulled into the silo)
[01:36] <duflu> mterry: OK. Do you know the API Unity is using to set maximized? I can check if notifications might have somehow changed
[01:37] <duflu> is it surface->configure(attrib, value)?
[01:37] <mterry> duflu, it's not setting maximized (I'm not sure how that's done -- probably deep in ubuntu-keyboard).  It's doing this:          onStateChanged: {
[01:37] <mterry>             if (__oskSurface.state [01:38] <duflu> mterry: OK, that's not actually Mir code so I don't know. We seem to have some confusion with identical class names between projects :)
[01:39] <mterry> duflu, the enum is a unity-mir one, associated with the Mir enum that you'd expect
[01:40] <mterry> duflu, I assume the event also directly corresponds with a Mir one
[02:10] <duflu> Who ever thought a laptop which can't ventilate while it's on your lap is a good idea?
[02:10] <duflu> Oh, right, HP
[02:24] <racarr> [       OK ] TestClientCursorAPI.client_may_disable_cursor_over_surface (116 ms)
[02:24] <racarr> yay
[02:25] <kgunn__> mterry: its dev in silo4
[02:26] <mterry> kgunn__, OK.  I assume you read some of the keyboard discussion?
[02:26] <kgunn__> mterry: mmm, no
[02:27] <mterry> kgunn__, one moment
[02:28] <mterry> kgunn__, I was debugging a problem with (I thought) my split branches
[02:28] <mterry> kgunn__, but I think it's in mir/devel now
[02:28] <mterry> kgunn__, the problem is that keyboard presses "fall through" and hit the shell too (or whatever is behind keyboard)
[02:29] <mterry> kgunn__, because unity-mir is waiting for a state change from the Mir surface to become maximized
[02:29] <mterry> kgunn__, with mir/trusty, the keyboard surface changes state correctly
[02:29] <mterry> kgunn__, with mir/devel it seems not to, so the keyboard is never finished being set up by qml
[02:30] <mterry> kgunn__, just heads up to test that before releasing a mir silo
[02:30] <mterry> kgunn__, it also makes it annoying to test my split silo, so I held off from sending a call for testing email
[02:38] <kgunn__> mterry: ack and yeah, we should fix that
[02:40] <mterry> kgunn__, also... how possible is it to do a silo just for lp:~mterry/gsettings-ubuntu-touch-schemas/volume?
[02:40] <mterry> kgunn__, it was supposed to be in tedg's silo, but he forgot it
[02:41] <mterry> it is needed for the indicator sound-syncing and is useful for desktop (and affects desktop)
[02:41] <mterry> So I'm interested in landing it separately and as soon as possible for more testing
[02:42] <mterry> it has an approved FFe
[02:48] <kgunn__> mterry: lemme check if someone has gsettings-ubuntu-touch-schemas
[02:49] <kgunn__> mterry: looks like we can do it right now
[02:49] <mterry> kgunn__, sweet
[02:50] <mterry> kgunn__, robert's uploading a new lightdm too, so soon most of the deps of this split silo can be dropped
[02:50]  * mterry rubs hands together
[02:59] <racarr> kgunn: RAOF: Party time?
[10:08] <alan_g> duflu: update_change_notification() => on_change_call()?
[10:09] <duflu> alan_g: Sounds weird like "call" is somehow the primary noun (i.e. you're expecting a "call" object).
[10:10] <duflu> I like "on_change" or "set_whatever_callback"
[10:10] <alan_g> duflu: as in "on change call this"
[10:11] <duflu> alan_g: As in "on change do ..." in my mind. Not "call"
[10:11] <alan_g> OK. I'll make it "on_change()" (unless anpok or alf__ objects)
[10:11] <duflu> It's an established pattern in other projects "on_foo", so "call" sounds like the event being reacted to
[11:01] <anpok> i only object on the overall concept :)
[11:06] <alan_g> Which concept?
[11:11] <ogra_> the one from the other channel ?
[11:11] <ogra_> :)
[11:12] <anpok> alan_g: that we use those callbacks to trigger a redraw immediately
[11:13] <anpok> but thats maybe just an implementation detail of the scene..
[11:15] <alan_g> anpok: what we do now is signal "something changed" and the compositor decides to schedule a redraw sometime in the future. What we plan to do is signal "this changed" and the compositor decides whether to schedule a redraw sometime in the future. In neither case do we redraw immediately.
[11:15] <anpok> ok it does not happen synchronous..
[11:16] <anpok> but it if you want to make multiple changes due to some form of event processing you do not know which changes end on screen on the next frame..
[11:16] <anpok> or a i missing something that ensures that the scene is in a stable state
[11:16] <anpok> *am
[11:22] <alan_g> As I see it the scene should only be sending notifications when in a "stable state".
[11:22] <alan_g> (When things are not stable a lock should be held - and one shouldn't be making calls or callbacks (to things one doesn't "own") when there's a lock held.
[11:25] <anpok> ah that would be Scene::lock what I missed
[11:37] <alan_g> anpok: not really, scene::lock() is a piece of madness kdub is about to make obsolete
[12:32] <anpok> alan_g: what did it protect, and how is that solved then?
[12:34] <alan_g> anpok: It allows the compositor to lock and unlock the scene. The scene should manage its own locking.
[12:36]  * alan_g is tempted by his usual rant about recursive mutex
[14:44] <kgunn> alf__: i have an urgent item, altho, unsure how quickly we might be able to generate something
[14:45] <kgunn> alf__: here let me grab a bug report real quick...
[14:45] <kgunn> alf__: https://bugreports.qt-project.org/browse/QTBUG-37677
[14:45] <kgunn> ....i'll give you a moment to read
[14:46] <kgunn> but the outcome is that, we'd like to return false on eglswapbuffers in the instance of screen off
[14:47] <anpok> kgunn: alf is on public holidays i believe?
[14:47] <kgunn> anpok: thanks!...can't believe i forgot
[14:47] <kgunn> he only told me 5 times
[14:48] <kgunn> anpok: if you're willing to take a look, feel free...this may be one that we need to hand off across timezones
[14:48] <kgunn> e.g. AlbertA might pick it up when he comes on, then duflu and then back again :)
[14:50] <kgunn> but wrt eglswapbuffers, we'd return false, but not block, but also not throw EGL_CONTEXT_LOST
[14:50] <anpok> false when the surface is skipped because it got occluded
[14:50] <anpok> or only false when screen is off
[14:51] <anpok> probably we need both
[14:52] <alan_g> kgunn: that is a major rework
[14:52] <kgunn> anpok: yeah...i think both cases are valid, screen off is obvious, the other is like, when you have the lockscreen on top (but other apps are still runnig)
[14:53] <kgunn> anpok: screen off is the one we're trying to solve atm
[14:53] <anpok> we would need to send something back to the client that the buffer was not used
[14:54] <anpok> and i think swap buffers currently only blocks when switching bundle runs out of buffers hmm
[14:54] <anpok> kgunn: alan_g: i dont know the mesa/egl mir platform part and the counterpart for android egl
[14:57] <alan_g> anpok: kgunn it means that instead of (as well as?) blocking in the buffer swapper that the swap buffer call fails. And a protocol update is needed for that in RPC - as well as the "internal client" code for mesa and android
[14:57] <alan_g> Nothing in that path is written to handle failing to swap - the assumption is that blocking is the correct behaviour
[14:58] <kgunn> alan_g: anpok ...unfortunately, tvoss did his level best to argue about this blocking assumption from Qt
[14:58] <kgunn> and we're in a pickle
[14:59] <kgunn> we've updates to Qt5.2....and lost the ux of music playing in background (not to mention some others)
[14:59] <alan_g> ack. I'm just saying "that is a major rework"
[14:59] <kgunn> alan_g: ack & thanks
[14:59] <tvoss> kgunn, the music player thingy is not the most important one
[14:59] <kgunn> just letting you know voss & i aren't happy about it either
[14:59] <tvoss> kgunn, I think it's the shell not reacting to volume buttons
[14:59] <kgunn> tvoss: ack...
[14:59] <kgunn> and others...telephony signals
[15:00] <kgunn> gps signals/map
[15:00]  * alan_g didn't choose Qt for implementing the shell.
[15:00] <kgunn> :) thank you alan_g
[15:01] <alan_g> tvoss: is this needed for both out of process and in-process clients or just the lattter?
[15:01] <kgunn> alan_g: ok...point taken, its major rework & i would like to prevent disturbing your work
[15:02] <AlbertA> what about implementing the window hide
[15:02] <AlbertA> it's that doable in unity-mir or would it have to be done on all apps?
[15:02] <kgunn> AlbertA: its a 2 fold problem...there is the window expose event, but per the discussion they assume eglswap can never block
[15:03] <AlbertA> kgunn: oh yeah it could be a race if it's blocked and we turn off the screen
[15:03] <anpok> which would be the case for those occluded apps..
[15:04] <AlbertA> kgunn: standup
[15:17] <tvoss> AlbertA, kgunn, alan_g, anpok another hangout might help
[15:17] <kgunn> tvoss: https://plus.google.com/hangouts/_/calendar/a2V2aW4uZ3VubkBjYW5vbmljYWwuY29t.2k4udqa2ovs931siq3b5fprgkc