| === chihchun_afk is now known as chihchun | ||
| 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:19 |
|---|---|---|
| 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:20 |
| alan_g | Cool. | 08:22 |
| 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:28 |
| alan_g | synchronicity | 08:29 |
| * greyback presses F5 | 08:29 | |
| 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:30 |
| 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:36 |
| greyback | alan_g: ah good to know | 08:37 |
| greyback | all feedback welcome, so "nit" away | 08:37 |
| alan_g | alf_: why has "woken_" grown a "_"? | 08:38 |
| alf_ | alan_g: I added a woken() method | 08:39 |
| alan_g | ok | 08:40 |
| === chihchun is now known as chihchun_afk | ||
| === alan_g is now known as alan_g|lunch | ||
| 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 | 12:52 |
| 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:00 |
| 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:01 |
| kgunn | alf_: greyback ...are we able to test non-blocking ? | 13:02 |
| 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:04 |
| 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:05 |
| 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:06 |
| === alan_g|lunch is now known as alan_g | ||
| 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:07 |
| kgunn | alf_: let's chat at our standup...but, my preference would be to promote wholesale from dev to trunk | 13:08 |
| * kgunn assumed you were asking about cherry picking | 13:09 | |
| alf_ | kgunn: that would be my preference too | 13:10 |
| anpok | alf_: https://code.launchpad.net/~andreas-pokorny/mir/custom_input_dispatcher/+merge/215174/comments/511794 is that beneficial enough | 13:11 |
| anpok | asking because I tend to believe your proposal would yield a smaller change set | 13:12 |
| alf_ | anpok: it feels strange conceptually for the DefaultInputConfiguration to both depend on and provide the InputDispatcherConf... | 13:21 |
| alf_ | anpok: It means that the InputDispatcherConfiguration is a completely independent entity | 13:22 |
| anpok | yes, we could see it that way.. we split the stack in to entities | 13:23 |
| anpok | *two | 13:23 |
| 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:24 |
| anpok | s/register/be connected/.. | 13:25 |
| 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:36 |
| anpok | the connection is currently done in InputConfiguration and there is a short cut if the dispatcher is the android dispatcher. | 13:37 |
| === alan_g is now known as alan_g|afk | ||
| anpok | cannot remember any reasons why I also have the_input_dispatcher_configuration() inside InputConfiguration .. | 13:39 |
| anpok | or InputReaderConfiguration | 13:39 |
| === alan_g|afk is now known as alan_g | ||
| 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:54 |
| greyback | kgunn: not yet, working on it | 13:55 |
| kgunn | ack | 13:55 |
| alan_g | kgunn: alf_ anpok we've too many (IMO) MPs in flight. We need to finish stuff as well as start it. | 14:03 |
| kgunn | alan_g: can you elaborate ?....i guess you are saying people need to do reviews and get stuff merged ? | 14:06 |
| alan_g | kgunn: mostly address review comments. But "do reviews" too. | 14:07 |
| racarr__ | Morning! | 14:07 |
| kgunn | racarr__: mornin' | 14:08 |
| 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:13 |
| 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:17 |
| anpok | yes | 14:18 |
| anpok | alf_: wifi issues - did we reach a conclusion i might be unaware of? | 14:33 |
| alf_ | anpok: no, let's talk after the stand-up | 14:37 |
| === alan_g is now known as alan_g|tea | ||
| 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:38 |
| racarr__ | I am going to spend a good portion of the morning reviewing the input bits :) | 14:39 |
| === 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 | ||
| 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:22 |
| kdub | right | 16:23 |
| kdub | so will the compositors eventually use the newObserver + the SurfaceObserver to figure out when to recomposite? | 16:23 |
| 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:24 |
| 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:25 |
| kdub | I'm trying to target the whole recomposition system to be nicer | 16:26 |
| 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:27 |
| alan_g | that would be nice - not thought through getting there | 16:28 |
| kdub | I can see a path to doing that, probably would be a side clean-up for me | 16:29 |
| 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:30 |
| 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:31 |
| kdub | racarr__, yeah, good point | 16:32 |
| kdub | thanks alan_g & racarr__ | 16:35 |
| === dandrader is now known as dandrader|lunch | ||
| 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:51 |
| 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:57 |
| racarr__ | and InputSender (manges seq ids, receiving finished signals, broken channels, etc) | 16:58 |
| anpok | i thought that (inputsender) would be the inputchannel in a few mps | 16:59 |
| 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:00 |
| === alan_g is now known as alan_g|EOD | ||
| 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:01 |
| racarr__ | alan_g|EOD: Thanks :) | 17:02 |
| racarr__ | still so sore from the plane need to go for a walk or something...back in 30 | 17:10 |
| racarr__ | ibuprofen granola bar and a walk around the block...catch all miracle cure. | 17:32 |
| kdub | hah, I didn't know they made ibuprofen in granola bar form ;) | 17:33 |
| 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:41 |
| 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:42 |
| racarr__ | somehow I had ambitions of reviewing every open branch before lunch... | 17:43 |
| racarr__ | and its already clear that is not going to happen lol | 17:44 |
| === dandrader|lunch is now known as dandrader | ||
| 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:27 |
| anpok | no not at all | 18:30 |
| anpok | thought you meant the input channel thing | 18:33 |
| 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:36 |
| dandrader | or is that to be done later | 18:37 |
| 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:38 |
| 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:39 |
| 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:40 |
| 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:41 |
| 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:42 |
| racarr__ | is this on your agenda? should I help? | 18:43 |
| anpok | thats also what alf_ pointed me to | 18:43 |
| 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:44 |
| 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:45 |
| racarr__ | yes | 18:46 |
| anpok | racarr__: I dont know to which degree we can work on that thing at the same time | 18:46 |
| 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:47 |
| 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:48 |
| 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:49 |
| 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:50 |
| dandrader | anpok, what's wrong with InputChannel? | 18:51 |
| 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:52 |
| 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:53 |
| racarr__ | just going to leave comments 1 by 1 on this as I go through because its a large diff lol | 18:58 |
| racarr__ | anpok: Ok I left a bunch of comments lol | 19:20 |
| racarr__ | im | 19:42 |
| racarr__ | gonna make it | 19:42 |
| racarr__ | so hungry but only two branches left | 19:42 |
| racarr__ | LUNCCCCCCCH | 19:59 |
| racarr__ | *triumph and joy* | 19:59 |
| racarr__ | oh man spot on too | 19:59 |
| racarr__ | A+ lunch | 20:39 |
| racarr__ | Iterating on cursor spike in just a sec then in to ozone world until EOD | 20:39 |
| === Wellark_ is now known as Wellark | ||
| === marrusl is now known as marrusl_afk | ||
| === marrusl_afk is now known as marrusl | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!