[03:38] Argh. My right ear is blocked. [03:38] This is surprisingly distracting. === mmrazik is now known as mmrazik|afk === mmrazik|afk is now known as mmrazik [09:03] alf_: FYI http://isocpp.org/blog/2013/05/gcc-4.8.1-released-c11-feature-complete [09:04] alan_g: nice! === mmrazik is now known as mmrazik|afk === pete-woods is now known as pete-woods-lunch === mmrazik|afk is now known as mmrazik === alan_g is now known as alan_g|lunch === pete-woods-lunch is now known as pete-woods === alan_g|lunch is now known as alan_g [14:52] http://i.imgur.com/fjdJOzr.jpg <- display [14:52] sorry sdl display* [15:02] cool hikiko [15:02] :) [15:06] hikiko: nice. I want one. ;) [15:07] :D [15:07] I'll start the gbm integration tomorrow :) [15:09] now my day is over :) have a nice evening!! [15:16] Morning [15:18] alan_g, with the suggestion for the swapper-swapper branch... were you renaming 'end_responsibility' to 'release_buffers_to' ? [15:19] kdub_: that was the suggestion. But the problem I saw was the mismatch between code and comments. [15:49] yeah... i think it can have a better interface though while we're looking at it though too :) === olli_ is now known as olli [16:16] status: Wrapping up basic lttng support, investigating communications timings/overhead [16:17] status, trying to wrap up SwapperSwitcher, got lost in the weeds of reworking our situation with ms/msh::Surface a bit [16:18] might need to discuss how we keep synchronized state about the surface stack more widely :) === ogra_ is now known as ogra [16:24] status: trying to reverse engineer why egl (probably) does something strange with composition bypass attempt. [16:26] :/ [16:34] maybe i can write a 'storm in a teacup' to see if i can find any problems with that use mode === mmrazik is now known as mmrazik|afk [16:38] i'm going to open up a can of worms here but.... all of our state concerning surfaces is migrating into the ms::Surface class [16:39] which might be fine :) but I just want to make sure its an active decision about the surface stack state [16:39] just to open it up to a larger base of thinkers :) [16:46] kdub_: I think that's correct. [16:46] well [16:46] I dunno, I'm not sure, I've grown convinced that all the state we have now [16:47] to be more specific, we have the z-order in ms::SurfaceStack, but the position/alpha/etc are in ms::Surface [16:47] is central to surfaces (except perhap, attributes/types, still unconvinced there) [16:47] and then we have 'shell state' in msh::Surface [16:47] but have the thought that some state [16:47] i.e. say... [16:47] previous size [16:47] never belongs on ms::Surface [16:47] racarr, yeah, i'd agree about that :) [16:49] racarr, is the different state in msh/ms supposed to be like 'ms::Surface' state is state the compositor cares about, but 'msh::Surface' state is stuff we have to track, but the compositor doesn't really care about? === alan_g is now known as alan_g|EOD [17:18] kdub_: Whoops sorry I only answered you in my head XD [17:19] kdub_: Yeah I think, ms::Surface should be [17:19] the minimal set of information the [17:19] compositor and input stack have to know about [17:19] and msh::Surface (well now, I'm still not quite convinced this is correct) [17:19] holds extra state that we use to determine that [17:21] kdub_: It's all spelled out very clearly in RoughArchitecture.png [17:21] :p [17:21] haha [17:21] kdub_: I think part of the problem as it stands is [17:21] msh::Surface is a resource managing class as well [17:21] as this like [17:21] state proxy [17:21] so its unclear [17:22] Not only that it's a resource managing class [17:22] that manages [17:22] a resource managing class [17:22] XD [17:24] I think Alan thinks that perhaps the msh::Surface state [17:25] uh oh ;-) [17:25] should be assosciation rather than attribute [17:25] but I don't fully understand the implications in my head [17:25] sounds nice :p [17:26] well, perhaps its trying to get closer to the idea that the shell surface management acts as a policy proxy to the surface stack for the frontend [17:27] a in RoughArchitecture.png :p [17:27] but I don't know what the object structure would look like [17:27] racarr, i think that we have to rethink our 'views' (MVC connotation) a bit [17:28] ? [17:28] confusing, sorry :) [17:28] no I sort of get the idea im just not sure how we should rethink them [17:29] not rethink [17:29] refine [17:29] i am beginning to see 3 objects we have to provide info to [17:30] the compositor, input, and the shell [17:31] the shell is slightly different too because it's two way right [17:31] controller-view or something XD [17:32] right [17:33] i guess we're just globbing the information through ms::Surface === greyback is now known as greyback|away === dpm is now known as dpm-afk [20:08] racarr & kdub...just sharing, ogra delivered "container flip" [20:08] http://cdimage.ubuntu.com/ubuntu-touch/daily-preinstalled/current/ [20:09] ogra curious, so phablet-dev-boot -c would pull down container flip as part of the code base right ? [20:09] follow https://wiki.ubuntu.com/Touch/Install#Manual_Installation (might need a hard reset after the first flash, it tries to boot into the non existing second part) [20:10] nope [20:10] Nifty :D [20:10] kdub_ & racarr caveat....no Nexus7...but i think that only hurts me [20:10] these images will only get integrated with the phablet tools once we have them safely working [20:10] kgunn: I want to use my nexus 7 :p [20:11] :) [20:11] they boot, but apps start with white screen (platform-api most likely) and we need to fgure out the device access avcross the rootfses [20:12] we found a ton if bugs today that were partially already fixed, tomorrows image should look a bit better [20:13] cool....maybe we'll let it breath a bit before biting into it [20:14] they are ready to get an impression :) not for daily usage though ... but at least you dont need to chroot into ubuntu :) [20:23] oh i almost forgot about the container flip :) [20:23] i'll give it a go, very cool [23:12] RAOF, you are opposed to having a debconf question in the lightdm packaging? [23:16] window_handles.erase(it); window_handle = it->second; [23:17] pure genius [23:17] ;) [23:18] iteration fun [23:27] robert_ancell, RAOF, kgunn, bregma - once more, that was a good meeting, my comfort zone just got increased by large [23:27] now we just need to make it happen ;) [23:27] olli, details... :) [23:27] .oO(details...) [23:27] exactly [23:29] * kdub_ has heard the devil's in the details [23:31] sigh. I have an acceptance test in client-focus-notifications that hangs indefinitely [23:31] in valgrind [23:31] unless I turn on logging [23:31] in which case it completes almost immediately [23:32] *grin* [23:50] Wrapping up the day soon. Made good progress on platform API, not as much moving around as I thought. Finished mirclient (except for some last bits of hybris wiring), started on mirserver, should start review tomorrow [23:50] something going on in client-focus-notifications that I don't understand and am not going to today :p [23:50] fix-input-registrar-locking should be ready to land [23:53] racarr, what last bits of hybris wiring? [23:54] kdub_: Err, just setting up the platform API bits so we can load parts from hybris (i.e. sensors) and parts not from hybris (i.e. mir) and build all the appropriate versions [23:54] with the minimal amount of code duplication [23:54] XD [23:54] mostly missing bits in cmake but, there is this question of like... [23:54] is there platform_api.so that can intelligently load , mirserver, mirclient, or for now hybris [23:54] or is there platform_api_mirserver/mirclient.so and qtubuntu has the intelligent loading [23:55] or is there platform_api_server/client and qtubuntu server/client (even if Qtubuntu is the same codebase) [23:55] so ricmm wanted to sync up with loic on that [23:55] and in the mean time I am doing the mirclient/mirserver implementations