mterrykgunn_, poke!01:11
mterrykgunn__, poke01:12
mterryIf 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 state01:16
mterryWhy might that be?01:17
racarrmterry: Always with the good news.01:23
mterryracarr, :)01:23
racarrI have no clue why that would happen but can look at it when I look at the screen stuff which should be first thingtomorrow01:24
mterryracarr, 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 changed01:26
duflumterry: 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:28
mterryduflu, it's not about the press events themselves I don't think.  Just whether the keyboard Mir surface reports that it is "maximized" or not01:29
* duflu wonders if the design docs define what "maximized" means for decoration-less touch devices01:30
mterryduflu, plus this is a weird keyboard surface anyway01:31
duflumterry: 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 problem01:31
mterryduflu, position of the OSK shouldn't have changed.  And it appears in the same place01:32
mterryduflu, 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 through01:32
duflumterry: 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 issue01:33
mterryduflu, I see.  And you think changes in Mir might have automatically changed it from fullscreen to smaller surface?01:35
duflumterry: 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 confused01:35
mterryduflu, in my testing, ubuntu-keyboard/unity-mir/maliit haven't changed01:36
mterryduflu, just been rebuilt against mir/devel (to my knowledge -- need kgunn to confirm which branches he pulled into the silo)01:36
duflumterry: OK. Do you know the API Unity is using to set maximized? I can check if notifications might have somehow changed01:36
dufluis it surface->configure(attrib, value)?01:37
mterryduflu, 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 === MirSurface.Maximized) {01:37
duflumterry: 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:38
mterryduflu, the enum is a unity-mir one, associated with the Mir enum that you'd expect01:39
mterryduflu, I assume the event also directly corresponds with a Mir one01:40
dufluWho ever thought a laptop which can't ventilate while it's on your lap is a good idea?02:10
dufluOh, right, HP02:10
racarr[       OK ] TestClientCursorAPI.client_may_disable_cursor_over_surface (116 ms)02:24
kgunn__mterry: its dev in silo402:25
mterrykgunn__, OK.  I assume you read some of the keyboard discussion?02:26
kgunn__mterry: mmm, no02:26
mterrykgunn__, one moment02:27
mterrykgunn__, I was debugging a problem with (I thought) my split branches02:28
mterrykgunn__, but I think it's in mir/devel now02:28
mterrykgunn__, the problem is that keyboard presses "fall through" and hit the shell too (or whatever is behind keyboard)02:28
mterrykgunn__, because unity-mir is waiting for a state change from the Mir surface to become maximized02:29
mterrykgunn__, with mir/trusty, the keyboard surface changes state correctly02:29
mterrykgunn__, with mir/devel it seems not to, so the keyboard is never finished being set up by qml02:29
mterrykgunn__, just heads up to test that before releasing a mir silo02:30
mterrykgunn__, it also makes it annoying to test my split silo, so I held off from sending a call for testing email02:30
kgunn__mterry: ack and yeah, we should fix that02:38
mterrykgunn__, also... how possible is it to do a silo just for lp:~mterry/gsettings-ubuntu-touch-schemas/volume?02:40
mterrykgunn__, it was supposed to be in tedg's silo, but he forgot it02:40
mterryit is needed for the indicator sound-syncing and is useful for desktop (and affects desktop)02:41
mterrySo I'm interested in landing it separately and as soon as possible for more testing02:41
mterryit has an approved FFe02:42
kgunn__mterry: lemme check if someone has gsettings-ubuntu-touch-schemas02:48
kgunn__mterry: looks like we can do it right now02:49
mterrykgunn__, sweet02:49
mterrykgunn__, robert's uploading a new lightdm too, so soon most of the deps of this split silo can be dropped02:50
* mterry rubs hands together02:50
racarrkgunn: RAOF: Party time?02:59
alan_gduflu: update_change_notification() => on_change_call()?10:08
duflualan_g: Sounds weird like "call" is somehow the primary noun (i.e. you're expecting a "call" object).10:09
dufluI like "on_change" or "set_whatever_callback"10:10
alan_gduflu: as in "on change call this"10:10
duflualan_g: As in "on change do ..." in my mind. Not "call"10:11
alan_gOK. I'll make it "on_change()" (unless anpok or alf__ objects)10:11
dufluIt's an established pattern in other projects "on_foo", so "call" sounds like the event being reacted to10:11
anpoki only object on the overall concept :)11:01
alan_gWhich concept?11:06
ogra_the one from the other channel ?11:11
anpokalan_g: that we use those callbacks to trigger a redraw immediately11:12
anpokbut thats maybe just an implementation detail of the scene..11:13
alan_ganpok: 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
anpokok it does not happen synchronous..11:15
anpokbut 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
anpokor a i missing something that ensures that the scene is in a stable state11:16
alan_gAs 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:22
anpokah that would be Scene::lock what I missed11:25
alan_ganpok: not really, scene::lock() is a piece of madness kdub is about to make obsolete11:37
anpokalan_g: what did it protect, and how is that solved then?12:32
alan_ganpok: It allows the compositor to lock and unlock the scene. The scene should manage its own locking.12:34
* alan_g is tempted by his usual rant about recursive mutex12:36
=== alan_g is now known as alan_g|lunch
=== alan_g|lunch is now known as alan_g
kgunnalf__: i have an urgent item, altho, unsure how quickly we might be able to generate something14:44
kgunnalf__: here let me grab a bug report real quick...14:45
kgunnalf__: https://bugreports.qt-project.org/browse/QTBUG-3767714:45
kgunn....i'll give you a moment to read14:45
kgunnbut the outcome is that, we'd like to return false on eglswapbuffers in the instance of screen off14:46
anpokkgunn: alf is on public holidays i believe?14:47
kgunnanpok: thanks!...can't believe i forgot14:47
kgunnhe only told me 5 times14:47
kgunnanpok: if you're willing to take a look, feel free...this may be one that we need to hand off across timezones14:48
kgunne.g. AlbertA might pick it up when he comes on, then duflu and then back again :)14:48
kgunnbut wrt eglswapbuffers, we'd return false, but not block, but also not throw EGL_CONTEXT_LOST14:50
anpokfalse when the surface is skipped because it got occluded14:50
anpokor only false when screen is off14:50
anpokprobably we need both14:51
alan_gkgunn: that is a major rework14:52
kgunnanpok: 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:52
kgunnanpok: screen off is the one we're trying to solve atm14:53
anpokwe would need to send something back to the client that the buffer was not used14:53
anpokand i think swap buffers currently only blocks when switching bundle runs out of buffers hmm14:54
anpokkgunn: alan_g: i dont know the mesa/egl mir platform part and the counterpart for android egl14:54
alan_ganpok: 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 android14:57
alan_gNothing in that path is written to handle failing to swap - the assumption is that blocking is the correct behaviour14:57
kgunnalan_g: anpok ...unfortunately, tvoss did his level best to argue about this blocking assumption from Qt14:58
kgunnand we're in a pickle14:58
kgunnwe've updates to Qt5.2....and lost the ux of music playing in background (not to mention some others)14:59
alan_gack. I'm just saying "that is a major rework"14:59
kgunnalan_g: ack & thanks14:59
tvosskgunn, the music player thingy is not the most important one14:59
kgunnjust letting you know voss & i aren't happy about it either14:59
tvosskgunn, I think it's the shell not reacting to volume buttons14:59
kgunntvoss: ack...14:59
kgunnand others...telephony signals14:59
kgunngps signals/map15:00
* alan_g didn't choose Qt for implementing the shell.15:00
kgunn:) thank you alan_g15:00
alan_gtvoss: is this needed for both out of process and in-process clients or just the lattter?15:01
kgunnalan_g: ok...point taken, its major rework & i would like to prevent disturbing your work15:01
AlbertAwhat about implementing the window hide15:02
AlbertAit's that doable in unity-mir or would it have to be done on all apps?15:02
kgunnAlbertA: its a 2 fold problem...there is the window expose event, but per the discussion they assume eglswap can never block15:02
AlbertAkgunn: oh yeah it could be a race if it's blocked and we turn off the screen15:03
anpokwhich would be the case for those occluded apps..15:03
AlbertAkgunn: standup15:04
=== dandrader is now known as dandrader|afk
tvossAlbertA, kgunn, alan_g, anpok another hangout might help15:17
kgunntvoss: https://plus.google.com/hangouts/_/calendar/a2V2aW4uZ3VubkBjYW5vbmljYWwuY29t.2k4udqa2ovs931siq3b5fprgkc15:17
=== dandrader|afk is now known as dandrader
=== dandrader is now known as dandrader|lunch
=== alan_g is now known as alan_g|EOD
=== pete-woods is now known as pete-woods-afk
=== jono is now known as Guest59567
=== dandrader|lunch is now known as dandrader
=== dandrader is now known as dandrader|afk
=== dandrader|afk is now known as dandrader

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!