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