=== chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun === greyback__ is now known as greyback === chihchun is now known as chihchun_afk [11:03] hah, looks like I can use the drm EGL platform in standalone Xmir instead of the Mir EGL platform. :P [11:05] at least that one cleans up correctly.. [11:09] RAOF: should I file a bug for eglTerminate not cleaing up correctly with Mir? [11:18] https://bugs.launchpad.net/ubuntu/+source/mir/+bug/1414999 [11:18] Launchpad bug 1414999 in mir (Ubuntu) "double free in mir when calling eglTerminate and gbm_device_destroy" [Undecided,New] === alan_g is now known as alan_g|lunch === dandrader is now known as dandrader|bbl === chihchun_afk is now known as chihchun === alan_g|lunch is now known as alan_g [14:02] alf_: you should mention your suspicions of cloud-worker-13 on #ubuntu-ci-eng [14:19] alan_g: Have we had an other strange failure? I think I want to wait for one more data point at least. [14:20] alf_: Ack. (I've not been counting.) === dandrader|bbl is now known as dandrader [15:49] I’m working on the surface management spec, and I have a question about the minimized state [15:49] Does/Should an app know, and be able to change, whether each of its windows is minimized? [15:50] If it could, it could suspend decoding/display of video, pause games, etc, saving battery [15:51] the client API allows an app to query the state, get updates when the state changes and to request a state change. [15:51] Ok :-) thanks === dandrader is now known as dandrader|afk === alan_g is now known as alan_g|EOD === dandrader|afk is now known as dandrader [19:06] AlbertA: you around? [19:07] AlbertA: camako: so will mir permit clients to pass in a preference of positioning ? [19:09] kgunn: we don't have that in the api yet...but there's a question for base windows on [19:09] what would the coordinate system be === greyback__ is now known as greyback [19:10] but I see it as an optional field in MirSurfaceSpec [19:11] AlbertA: so was just chatting with mzanetti, and he was saying this is important for the "memory" aspect [19:11] that when you flip between mobile and desktop [19:12] desktop just ends up with all the windows in the same spot...even if you previously spread them all out [19:12] whereas, the desire would be for it to recall where they were and put them back into position [19:12] kgunn: I would have thought this would be part of the "cookie" stuff [19:12] which would be used by a shell to save/restore window information on the server side... [19:14] oh look...already a bug [19:14] https://bugs.launchpad.net/qtmir/+bug/1415161 [19:14] Launchpad bug 1415161 in Unity 8 "U8 application windows don't remember their location or size when switching between Windowed->Staged->Windowed" [Undecided,New] [19:15] AlbertA: true, shell could do the tracking in the near term [19:16] kgunn: at first glance I put it in the same bucket as restoring window positions when an application starts again from scratch which is the [19:17] so I'm in 2 minds about Mir saving window state/position. Since we have 2 distinct view states (desktop/tablet) that would imply there's 2 separate state/position settings to track for each surface [19:17] -surface+window [19:17] should Mir have to support that? [19:17] cookie thing racarr/chris have mentioned in the past [19:18] I would imagine something like [19:18] the client requests a unique cookie from the server [19:18] and gets associated with session/surface maybe [19:19] then a server side interface just asks a helper [19:19] to store/retrieve info, given that cookie - the shell implementation would then [19:19] save whatever pertinent information it wants (like desktop/tablet mode, last known position etc...) [19:20] and likewise, mir server would ask the same helper, given that cookie to retrieve stored state... [19:22] the alternative is the client specifying initial positions.... [19:22] but then we have to agree on what type of coordinate system to use... [19:23] it would probably have to be something normalized to the current view coordinate system [19:24] AlbertA: right, and we want to avoid absolute positioning iirc [19:27] yeah that's fair, let the shell save what it needs [19:30] AlbertA: client cookie only good for child surface tho right? [19:31] e.g. topmost parent isn't going to know it's position right ? [19:43] camako: just wondering, looks like racarr addressed alan's comment, we can ta ? [19:43] https://code.launchpad.net/~mir-team/mir/add-non-input-event-ctors-and-port-event-sinks/+merge/247084 [20:01] kgunn, done [20:01] camako: no prob...was just askin' really [20:01] sure [20:02] camako: i'm kinda cross referencing backlog and branches....seeing where we're really at [20:02] kgunn, need help? [20:02] camako: i might ping you as i go...and you might wanna skim it after i finish [20:02] kgunn, sure [20:27] kgunn: cookie is more anything I think, basically to persist data and give it a unique id [20:28] AlbertA: thanks...i did find it in the backlog "MirCookie/MirReference support (focus grant, cross-session/client parenting/referencing)" [20:28] kgunn: oh...yeah that maybe a bit different, that's more about cross-process ids [20:29] kgunn: but could be related...I have not given it deep thought :) [21:23] camako: this feels like we should approve, fixes a bug as well... [21:23] https://code.launchpad.net/~vanvugt/mir/fix-buffers_ready_for_compositor/+merge/247124 [21:24] altho if you want to review first, i'd understand [21:24] kgunn, I looked at it.. yeah it looks reasonable [21:24] was going to take a deeper look [21:27] camako: and is jenkins still being a punk ? [21:27] https://code.launchpad.net/~mir-team/mir/add-dispatchable-interface/+merge/246372 [21:28] ah...nope seems he's gotta conflict [21:28] kgunn, alf noticed some failures but thought they were contained or due to one specific server [21:29] kgunn, yes that particular one need TLC from RAOF [22:12] RAOF: you on? [22:12] kgunn: Indeed I am [22:12] so i was trying to help :) [22:13] RAOF: and i goofed, but already figured out how to do it right...but [22:13] don't know how to undo one particular thing [22:13] so i was addressign the conflict on [22:13] lp:~mir-team/mir/add-dispatchable-interface [22:14] and thot i addressed the right --take but i didn't [22:14] shoulda done by hand [22:14] Heh. [22:14] ...and pushed, only to realize the goof [22:14] so how does one "revert" the push [22:15] Either by adding an extra commit, or by push --overwrite. [22:15] cause if you uncommit/revert...then push, it says "you've diverged you fool" [22:15] so opportunity to learn for me as well [22:15] RAOF: what's the penalty if any of --overwrite ? [22:15] Yeah, “push --overwrite” is what you want in that circumstance. [22:16] or does it simply obliterate that last commit [22:16] It obliterates what's currently in the branch and replaces it with what you push. [22:16] (e.g. does it negate your approve votes or do some weird history loss thing) [22:16] ok...will do that [22:16] No, nothing like that. [22:17] Some tools can get a bit confused because they expect the contents of a revision to be immutable (ie: rev 2278 has one contents now and will have a different contents after --overwrite) [22:17] But it's all fairly harmless. [22:41] RAOF: ok, that seemed to work...took a while to make sure i did it correct...of course, i only touch ./tests/CMakeLists.txt [22:41] but after...now it's complaining about others [22:41] https://code.launchpad.net/~mir-team/mir/add-dispatchable-interface/+merge/246372 [22:41] is that common ? [22:43] No. That would suggest that there are other conflicts introduced. [22:44] RAOF: i suppose i should have done merge lp:mir ...vs lp:mir/tests/CMakeLists.txt [22:44] ? [22:44] I'm not sure what lp:mir/tests/CMakeLists.txt would do? [22:44] it only merges that file [22:44] I didn't know you could do that :) [22:44] hehe [22:45] I'd probably just do “bzr merge lp:mir” and check that everything's ok. [22:45] ok...merging the entire tree [22:45] woa... 5 conflicts encountered [22:46] and lots of stuff moved about [22:46] Yeah, the ABI things now conflict. [22:46] yep [22:46] Text conflict in common-ABI-sha1sums [22:46] Text conflict in platform-ABI-sha1sums [22:46] Text conflict in server-ABI-sha1sums [22:46] Text conflict in src/common/symbols.map [22:46] Text conflict in tests/CMakeLists.txt [22:46] RAOF: i assume the map gets taken care as part of the sha1sum updates [22:46] ? [22:47] symbols.map? No, that needs manual merging. [22:48] RAOF: how does one resolve the sha1sums ? script ? [22:48] You need to manually edit it to resolve the conflict. [22:48] k [23:09] RAOF: ok...doing the symbols.map last, and it looks like an hour ago robert added a 3.2 [23:09] http://bazaar.launchpad.net/~mir-team/mir/development-branch/revision/2267 [23:09] does that mean [23:10] i need to mannually add a 3.3 for your adds ? ...or just merge them under 3.2 since we haven't release yet ? [23:11] Can probably merge them under 3.2 [23:11] RAOF: does order matter ? [23:11] No [23:15] RAOF: one last one... on your add of 3.2 your close brace has MIR_COMMON_3.1; whereas sir robert's has MIR_COMMON_3; [23:16] i see 3.1 closed with MIR_COMMON_3 as well... [23:16] what would be the correct convention [23:16] It doesn't _really_ matter; 3.1 would be slightly more correcct. [23:17] Indeed, you can leave out the base-revision entirely. It's basically just saying “These symbols comprise MIR_COMMON_3.2, and require MIR_COMMON_3.1” [23:19] that was my guess [23:20] RAOF: thanks for letting me do, learned a little....pushed [23:20] gonna kick jenkins, if it passes we should top approve [23:26] And I'll merge that through all the dependent branches. Thanks! [23:26] Soooo. [23:27] For those playing at home, Grim Fandango remastered is available on Linux. [23:33] On by default the last timeI used it [23:33] ... [23:33] lol [23:33] up + enter mishap [23:36] qtmir -> event 2.0 port finished...of coursemuch manual testing required [23:37] Woot! [23:37] racarr: Remember to buy Grim Fandango for the plane trip to Brussels :) [23:38] I've never played it actually... [23:39] Yeah, that's what I though. [23:39] t [23:39] It might have been a bit before your time :P [23:39] Which is why you should buy it, silly! [23:41] who doesn't love mexican skull art really [23:41] in a video game no less [23:41] oh that is kind of my jam [23:41] never heard of this...but now i am totally intrigued [23:41] OH MAN! [23:41] You're a travel agent in the land of the dead! [23:43] Starting on the day of the dead! [23:44] Intrigue! Mystery! Skeletal pigeon eggs! [23:44] hehe