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