[08:19] <alan_g> greyback: alf_ do you still need to "hold" https://code.launchpad.net/~alan-griffiths/mir/move-more-stuff-to-scene/+merge/214752?
[08:20] <alf_> alan_g: greyback: I am OK with it getting in, but I can't speak for Gerry and the unity-mir etc side
[08:20] <greyback> alan_g: ok from me.
[08:22] <alan_g> Cool.
[08:28] <greyback> alan_g: could I get you to cast your eye over this please: https://code.launchpad.net/~gerboland/unity-mir/fix-compatibility-with-mir-0.1.8/+merge/215454
[08:28] <alan_g> greyback: https://code.launchpad.net/~gerboland/unity-mir/fix-compatibility-with-mir-0.1.8/+merge/215454/comments/511654
[08:29] <alan_g> synchronicity
[08:29]  * greyback presses F5
[08:30] <alf_> alan_g: also please take a look at https://code.launchpad.net/~afrantzis/mir/fix-1306464/+merge/215387  (fixes a cause of intermittent CI failures)
[08:30] <alan_g> alf_: ack
[08:36] <alan_g> greyback: Not quite a "nit" https://code.launchpad.net/~gerboland/unity-mir/fix-compatibility-with-mir-0.1.8/+merge/215454/comments/511656
[08:37] <greyback> alan_g: ah good to know
[08:37] <greyback> all feedback welcome, so "nit" away
[08:38] <alan_g> alf_: why has  "woken_" grown a "_"?
[08:39] <alf_> alan_g: I added a woken() method
[08:40] <alan_g> ok
[12:52] <greyback> Anyone in here familiar enough with platform-api to review https://code.launchpad.net/~gerboland/platform-api/fix-compatibility-with-mir-0.1.8/+merge/215455
[13:00] <kgunn> greyback: i'm building with https://code.launchpad.net/~gerboland/unity-mir/fix-compatibility-with-mir-0.1.8/+merge/215454 & https://code.launchpad.net/~gerboland/platform-api/fix-compatibility-with-mir-0.1.8/+merge/215455
[13:01] <greyback> kgunn: great, thanks
[13:01] <kgunn> i assume its all i needed...and ready to go
[13:01] <greyback> kgunn: yes, I built all & tested this morning, it should be good
[13:01] <kgunn> thank you
[13:02] <kgunn> alf_: greyback ...are we able to test non-blocking ?
[13:04] <greyback> kgunn: I think all the code is ready to land, but I suppose a silo would be good to bring all the bits together
[13:04] <kgunn> greyback: yep...that's what i meant, i'd like to give it a full day of team beating on it in silo
[13:05] <kgunn> (...or even more than a day...)
[13:05] <greyback> sure
[13:05] <alf_> kgunn: so the code for Mir is in mir/devel, and the needed changes for usc is in https://code.launchpad.net/~afrantzis/unity-system-compositor/non-blocking-swap-buffers/+merge/214759 and can be merged at will
[13:06] <kgunn> alf_: awesome! ...and thanks for tackling a tedious surgery :)
[13:06] <alf_> kgunn: np
[13:06] <kgunn> i'll ping here and shoot a mail with silo#
[13:07] <alf_> kgunn: what's the plan for making a release with them (and the other changes, e.g. scene refactoring that Alan is working on)?
[13:08] <kgunn> alf_: let's chat at our standup...but, my preference would be to promote wholesale from dev to trunk
[13:09]  * kgunn assumed you were asking about cherry picking
[13:10] <alf_> kgunn: that would be my preference too
[13:11] <anpok> alf_: https://code.launchpad.net/~andreas-pokorny/mir/custom_input_dispatcher/+merge/215174/comments/511794 is that beneficial enough
[13:12] <anpok> asking because I tend to believe your proposal would yield a smaller change set
[13:21] <alf_> anpok: it feels strange conceptually for the DefaultInputConfiguration to both depend on and provide the InputDispatcherConf...
[13:22] <alf_> anpok: It means that the InputDispatcherConfiguration is a completely independent entity
[13:23] <anpok> yes, we could see it that way.. we split the stack in to entities
[13:23] <anpok> *two
[13:24] <anpok> the one that reads input from devices or from the mir conncetion
[13:24] <anpok> and the part that sits on top of that and dispatches the input to clients/internally
[13:24] <anpok> hmm at some point one has to register to the other
[13:25] <anpok> s/register/be connected/..
[13:36] <alf_> anpok: if the two parts (read,dispatch) are really independent, and it's a pain if we want to override only one part, I wonder if we should split InputConfiguration into two independent interfaces.
[13:36] <anpok> alf_: I could rename InputConfiguration to InputReceiverConfiguration.. and I think I can easily remove the input_dispatcher_configuration from InputReceiverConfiguration..
[13:37] <anpok> the connection is currently done in InputConfiguration and there is a short cut if the dispatcher is the android dispatcher.
[13:39] <anpok> cannot remember any reasons why I also have the_input_dispatcher_configuration() inside InputConfiguration ..
[13:39] <anpok> or InputReaderConfiguration
[13:54] <kgunn> greyback: hey...don't you have a unity-mir branch that would need to go with alf_'s non-blocking branch ?(e.g. expose event)
[13:55] <greyback> kgunn: not yet, working on it
[13:55] <kgunn> ack
[14:03] <alan_g> kgunn: alf_ anpok we've too many (IMO) MPs in flight. We need to finish stuff as well as start it.
[14:06] <kgunn> alan_g: can you elaborate ?....i guess you are saying people need to do reviews and get stuff merged ?
[14:07] <alan_g> kgunn: mostly address review comments. But "do reviews" too.
[14:07] <racarr__> Morning!
[14:08] <kgunn> racarr__: mornin'
[14:13] <kgunn> greyback: ok, just hit me up when you got it...i can't get a silo until then
[14:13] <greyback> kgunn: ok
[14:17] <dandrader> anpok, so that would be that last missing bit, right? https://code.launchpad.net/~andreas-pokorny/mir/use-input-channel-to-send-input/+merge/215450
[14:18] <anpok> yes
[14:33] <anpok> alf_: wifi issues - did we reach a conclusion i might be unaware of?
[14:37] <alf_> anpok: no, let's talk after the stand-up
[14:38] <alf_> anpok: I am OK with the two interfaces, but I am not intimately familiar with the input side of things and would appreciate some discussion
[14:38] <anpok> k
[14:39] <racarr__> I am going to spend a good portion of the morning reviewing the input bits :)
[16:22] <kdub> alan_g, so were you intending SurfaceObserver to eventually become the way the compositors are notified of scene changes? or was it just for purposes of the shell?
[16:22] <alan_g> kdub: SurfaceObserver can notify changes to a surface, but not to e.g. the stacking order. That's a whole new Observer
[16:23] <kdub> right
[16:23] <kdub> so will the compositors eventually use the newObserver + the SurfaceObserver to figure out when to recomposite?
[16:24] <racarr__> That was my conclusion on what seemed nice when I studied it for the CursorController
[16:24] <alan_g> There's nothing stopping class CompositeScheduler : public  ms::SurfaceObserver, public ms::StackObserver
[16:24] <racarr__> which uses the surface stack change callback (as in multiple-change-callbacks)
[16:24] <racarr__> like the compositor
[16:25] <racarr__> but for optimization and clarity shouhld also be
[16:25] <racarr__> SurfaceObserver, StackObserver
[16:25] <kdub> ack, and then ms::Scene doesn't have to change much immediately
[16:25] <kdub> that seems sensible
[16:25] <kdub> *mc::Scene
[16:26] <kdub> I'm trying to target the whole recomposition system to be nicer
[16:27] <kdub> instead of callback, render, check Renderables, render, check Renderables
[16:27] <kdub> just callback, render, callback, render
[16:27] <kdub> no more mg::Renderable::buffers_ready_for_compositor()
[16:28] <alan_g> that would be nice - not thought through getting there
[16:29] <kdub> I can see a path to doing that, probably would be a side clean-up for me
[16:30] <kdub> I guess the other longer-term thought is callback, renderable_list_for(), callback, renderable_list_for(), etc
[16:30] <kdub> could just be a callback containing the renderable list
[16:30] <kdub> but that's further down the road :)
[16:31] <racarr__> it seems like specialized callback is useful, because for example if the only scene change is a renderable dissapearing
[16:31] <racarr__> as the compositor I should be able to recognize this
[16:31] <racarr__> without having to search a list or anything
[16:32] <kdub> racarr__, yeah, good point
[16:35] <kdub> thanks alan_g & racarr__
[16:51] <anpok> racarr__: hm regarding input - then I need to do more in the case we replace the droidinput dispatcher - I need to process the finished signals produced by the clients..
[16:51] <anpok> with the current mps those signals sent back to the server are never read..
[16:57] <racarr__> anpok: Well its not an immediate requirement...but yes there is some work there
[16:57] <racarr__> this is why I am favoring this approach where we split the InputDispatcher
[16:57] <racarr__> in to an InputTargeter
[16:57] <racarr__> err
[16:57] <racarr__> or like InputTargetSelector
[16:58] <racarr__> and InputSender (manges seq ids, receiving finished signals, broken channels, etc)
[16:59] <anpok> i thought that (inputsender) would be the inputchannel in a few mps
[17:00] <anpok> hm but yeah channel might be not the right name then...
[17:00] <alan_g> racarr__: I've posted some thoughts to the spike MP. Hope they help
[17:01] <anpok> but back to the finished signal - we would fill the socket and block some time if I dont start to work something out in that direction
[17:02] <racarr__> alan_g|EOD: Thanks :)
[17:10] <racarr__>  still so sore from the plane need to go for a walk or something...back in 30
[17:32] <racarr__> ibuprofen granola bar and a walk around the block...catch all miracle cure.
[17:33] <kdub> hah, I didn't know they made ibuprofen in granola bar form ;)
[17:41] <racarr__> kdub: Hahaha no just a missing comma
[17:41] <racarr__> thats a great idea though
[17:41] <racarr__> granola bar infused with ibuprofen
[17:41] <racarr__> vitamin infused ramen
[17:41] <racarr__> sell it to college students
[17:42] <racarr__> $$$
[17:42] <kdub> now that we have a great idea, we just need a name! GranolaBarHeadSaver
[17:42] <racarr__> kdub: Needs fixing.
[17:42] <racarr__> :p
[17:42] <kdub> lol
[17:43] <racarr__> somehow I had ambitions of reviewing every open branch before lunch...
[17:44] <racarr__> and its already clear that is not going to happen lol
[18:27] <racarr__> so
[18:27] <racarr__> many
[18:27] <racarr__> branches
[18:27] <racarr__> oh no
[18:27] <racarr__> now Im on custom-input-dispatcher
[18:27] <racarr__> this is the hard one lol
[18:27] <racarr__> well maybe not
[18:30] <anpok> no not at all
[18:33] <anpok> thought you meant the input channel thing
[18:36] <dandrader> anpok, so are you planning to split android::InputDispatcher responsibilities (target selection and supervision of event delivery through channels) in your custom-input-dispatcher branch?
[18:37] <dandrader> or is that to be done later
[18:38] <racarr__> I think it should probably be done later...
[18:38] <dandrader> +1. I think this splitting is going to be a big big patch
[18:38] <racarr__> I mean maybe it could have been done now but on the other hand anpok has already done this so its good to just unblock qt compositor
[18:39] <racarr__> well this patch ended up pretty big too because of all the input configuration changes, etc...whereas
[18:39] <anpok> I wanted to do that last week
[18:39] <racarr__> if InputDispatcher was a sensible interface
[18:39] <racarr__> we could just expose it and
[18:39] <anpok> but it looked liked a lot of work ..
[18:39] <anpok> so I thought that I would do that
[18:40] <anpok> and while keeping the interface further cleanup the InputDispatcher
[18:40] <anpok> as in splitting functionalities out..
[18:40] <racarr__> I think aim at collapsing the input configuration hierarchy...right now its only a seperate hierarchy
[18:40] <racarr__> to hide android bits that we havent...made sensible yet basically
[18:41] <anpok> hm that was two weeks ago
[18:41] <racarr__> what I mean is like, InputReader, EventHub, InputDispatcher, etc
[18:41] <anpok> then in between other stuff hapened..
[18:41] <racarr__> are all too ...
[18:41] <racarr__> poorly defined to have like
[18:41] <racarr__> ServerConfiguration::the_input_dispatcher, etc...because it depends on too many android details
[18:42] <anpok> yes
[18:42] <racarr__> but as we split responsibilities, DefaultServerConfiguration::the_input_target_selector DefaultServerConfiguration::the_input_event_sender(relay?) etc
[18:42] <racarr__> make perfecnt sense and we can
[18:42] <racarr__> delete a lot of header file code lol
[18:42] <racarr__> and just kind of clarify things
[18:43] <racarr__> is this on your agenda? should I help?
[18:43] <anpok> thats also what alf_ pointed me to
[18:44] <anpok> as in he didnt like InputConfiguration and InputDispatcherConfiguration
[18:44] <racarr__> Mm
[18:44] <anpok> right now I feel I have to make sure that the InputConsumer does not block at some point
[18:45] <anpok> I would like to to get rid of things like the input_registrar too
[18:45] <anpok> and the co-ordinate calculations being buried inside the InputDispatcher ..
[18:45] <anpok> and all that
[18:46] <racarr__> yes
[18:46] <anpok> racarr__: I dont know to which degree we can work on that thing at the same time
[18:47] <dandrader> I would say, unblock the qt compositor work now and do all the refactoring later
[18:47] <anpok> so .. to unblock the consumer it I have the feeling I should establish the inout sender ..
[18:48] <racarr__> haha yes I guess what I meant do you have time for it now
[18:48] <racarr__> anpok: well for now qtcompositor has a copied modified version of input dispatcher
[18:48] <anpok> racarr__: no other thing on my direct agenda.. i also have fix-126726 something that is in that area..
[18:48] <racarr__> so they can be unblocked by that...
[18:49] <racarr__> I mean...now I am just reviewing the diff for correctness and then It hink am happy to just go with that for the next few weeks
[18:49] <racarr__> but would like to bring real sanity to the area soon :D
[18:49] <racarr__> anpok: Ok. I leave it in your capable hands lol
[18:49] <racarr__> I have chromium and X input driver to keep me busy at least this week
[18:50] <anpok> dandrader: i would keep the current mir::input::InputDispatcher rather stable wrt further refactorings, but InputChannel .. I have to change rather sooner..
[18:50] <anpok> or the thing to dispatch the input too
[18:51] <dandrader> anpok,  what's wrong with InputChannel?
[18:52] <racarr__> one thing is send_event(seq_id, MirEvent) is weird because the caller cant know how to use seq_id really so its weird as a public interface
[18:52] <anpok> it has to be non null :) and should not collide with other input sequences
[18:52] <anpok> and nobody reads the ACK signals that come back from the input reader..
[18:53] <racarr__> indeed but they will
[18:53] <anpok> I only discovered that part today
[18:53] <dandrader> racarr__, true
[18:53] <racarr__> and if it has to be non null and not collide and thats all
[18:53] <racarr__> then it should just be hidden inside the object
[18:58] <racarr__> just going to leave comments 1 by 1 on this as I go through because its a large diff lol
[19:20] <racarr__> anpok: Ok I left a bunch of comments lol
[19:42] <racarr__> im
[19:42] <racarr__> gonna make it
[19:42] <racarr__> so hungry but only two branches left
[19:59] <racarr__> LUNCCCCCCCH
[19:59] <racarr__> *triumph and joy*
[19:59] <racarr__> oh man spot on too
[20:39] <racarr__> A+ lunch
[20:39] <racarr__> Iterating on cursor spike in just a sec then in to ozone world until EOD