| RAOF | racarr__: You wanted to discuss 1Hz-rendering | 00:03 |
|---|---|---|
| RAOF | ? | 00:03 |
| kdub | racarr__, quick side question :) is this one ready to go? https://code.launchpad.net/~mir-team/mir/cursor-spike-phase-2.5-rework-of-the-input-targets/+merge/213742 | 00:04 |
| racarr__ | kdub: Yeah! | 00:04 |
| racarr__ | RAOF: Um...in a bit (around meeting or something?) getting ready to make dinner | 00:04 |
| RAOF | racarr__: Sure! | 00:05 |
| kgunn | searching for a headset... | 01:00 |
| === chihchun_afk is now known as chihchun | ||
| RAOF | In Which I Gain A New Appreciation Of How Slow Nexus 4 Hardware Is. | 07:24 |
| anpok_ | RAOF: hm? | 07:27 |
| RAOF | anpok_: Oh, running into a race I thought couldn't happen. | 07:27 |
| RAOF | But does on N4. | 07:27 |
| RAOF | Under valgrind, admittedly. | 07:27 |
| RAOF | Turns out a thread sleeping for 1ms is not long enough for another thread to get unblocked and take the lock. | 07:28 |
| mlankhorst | RAOF: that's really really the wrong approach to locking ;P | 07:40 |
| RAOF | Well, I'm doing this in a test designed to expose a different race, so I can't really go into the code and lock at exactly the right point :) | 07:54 |
| mlankhorst | hah :p | 08:01 |
| mlankhorst | while (pthread_mutex_trylock()) unlock() sleep ? :D | 08:01 |
| RAOF | I'll just (a) bump it to 2ms and (b) move the locking closer. | 08:03 |
| duflu | RAOF: Script up a test which runs helgrind ;) | 08:07 |
| duflu | That will fail reliably | 08:07 |
| RAOF | duflu: Hush! | 08:07 |
| * duflu bows head and backs into hole | 08:08 | |
| RAOF | Anyway, EOD for me. | 08:08 |
| alf_ | duflu: Is https://bugs.launchpad.net/mir/+bug/1308843 about the buffer consuming thread running faster than the real compositor? | 08:16 |
| ubot5 | Launchpad bug 1308843 in Mir "[regression] Client judders, skipping frames periodically" [High,In progress] | 08:16 |
| duflu | alf_: Kind of yes. But unconditionally running both it seems, still results in the same problem. You get periodic aliasing/beating. The only real solution is to make the consumer conditional, which is fairly easy. I'm just stuck writing good test cases right now | 08:20 |
| === xnox is now known as NoNameYet_xnox | ||
| alf_ | duflu: "to make the consumer conditional" ? | 08:21 |
| duflu | It's exactly the same as multi-monitor with 59.9Hz vs 60.0Hz. With physical displays we accept the beating, but with the virtual one we shouldn't | 08:21 |
| alf_ | duflu: there's also RAOFs approach which shouldn't have this issue | 08:22 |
| alf_ | duflu: have you tried it? | 08:22 |
| duflu | alf_: No I was trying to solve regressions before doing more code reviews | 08:23 |
| duflu | Argh, we're all tangled | 08:23 |
| duflu | Anyway, the fix(es) are easy. I'll continue improving the regression tests regardless | 08:25 |
| duflu | Wow, that's huge | 08:30 |
| duflu | I think we can do better | 08:30 |
| alf_ | duflu: what's huge? | 08:32 |
| duflu | alf_: The diff | 08:32 |
| alf_ | duflu: diff of what? | 08:34 |
| duflu | alf_: 1Hz branch | 08:34 |
| duflu | I think I can solve multiple regressions with much less change | 08:34 |
| anpok_ | hm the timer functionality adds a lot | 08:34 |
| duflu | A lot of risk, definitely | 08:35 |
| duflu | And maintenance burden | 08:35 |
| === chunsang is now known as chunsang-away | ||
| === chihchun is now known as chihchun_afk | ||
| === chihchun_afk is now known as chihchun | ||
| === mpt_ is now known as mpt | ||
| kgunn | alf_: just want to say...non-block swap buffers on mir-devel seems to be rockin' | 13:39 |
| kgunn | i tested all day y'day on xmir...did a lot of suspends | 13:39 |
| kgunn | and comparing to regular X....didn't see any difference | 13:39 |
| kgunn | in fact, i see a bug sometimes on X suspend :) | 13:39 |
| kgunn | also, i put through the wringer on nexus 10...no new bugs | 13:40 |
| kgunn | any bugs around sidestage are the same/already present | 13:40 |
| alf_ | kgunn: Great. I have put up https://code.launchpad.net/~afrantzis/mir/consume-only-not-rendered-buffers/+merge/216725 for review, trying to combine the best of both worlds, but if everything is working fine at the moment, let's go with what we have and revisit in a few days when things have stabilized. | 13:43 |
| === dandrader is now known as dandrader|afk | ||
| === chihchun is now known as chihchun_afk | ||
| === alan_g is now known as alan_g|tea | ||
| === alan_g|tea is now known as alan_g | ||
| === chihchun_afk is now known as chihchun | ||
| anpok | so we wont integrate RAOFs MP? | 14:49 |
| anpok | I am asking because I would have a need for the Timer functionality that comes with that MP.. | 14:49 |
| alf_ | anpok: We haven't decided anything yet... just more alternatives for evaluation | 15:34 |
| AlbertA | anpok: that's up to the panel to decide :) | 15:34 |
| anpok | hehe | 15:34 |
| anpok | the elder? | 15:34 |
| anpok | *s | 15:34 |
| anpok | hmm | 15:34 |
| anpok | I was thinking about shamlessly ripping that part out and providing it as is in a separate MP | 15:35 |
| AlbertA | anpok: let's merge both and see what happens.... ;) | 15:35 |
| AlbertA | anpok: that's the spirit of open source | 15:36 |
| AlbertA | anpok: :) | 15:36 |
| anpok | alan_g: https://code.launchpad.net/~andreas-pokorny/mir/custom_input_dispatcher/+merge/215174/comments/514940 | 15:41 |
| anpok | alan_g: would you prefer a huge change that does everything in one MP - or several normal sized changes? | 15:43 |
| anpok | hmm it is already beyond 3k... | 15:44 |
| alan_g | anpok: I don't mind promises that "this is only like this until the next MP" | 15:46 |
| === dandrader|afk is now known as dandrader | ||
| anpok | can I reuse that promises since it will take a few more MPs untill that thing evaporates | 15:48 |
| alan_g | ack | 15:48 |
| anpok | and at some point I need to add (or understand that those events can be ignored) something to MirEvent | 15:49 |
| anpok | to store device reset events.. | 15:49 |
| anpok | which I expect leads to further discussions... | 15:50 |
| === dandrader is now known as dandrader|afk | ||
| === alan_g is now known as alan_g|EOD | ||
| === csslayer_ is now known as csslayer | ||
| racarr__ | I just noticed my desk is not only on a slanted part of my floor | 17:43 |
| racarr__ | but is bowing at the middle | 17:44 |
| racarr__ | and my keyboard is at quite an angle lol | 17:44 |
| racarr__ | Ive had this muscular thing that I thought was from playing piano...and now I think I know the culprit ;) | 17:44 |
| kdub | hah, all those earthquakes | 18:02 |
| kdub | any more takers on this: https://code.launchpad.net/~kdub/mir/gl-program-creation-factory/+merge/216218 ? | 18:03 |
| kdub | thanks AlbertA | 18:46 |
| === chihchun is now known as chihchun_afk | ||
| === dandrader|afk is now known as dandrader | ||
| kgunn | AlbertA: anpok on the topic of occlusion detection & alpha detection | 19:37 |
| kgunn | we still would allow the occluded app to render | 19:37 |
| kgunn | but the compositor would just ignore right ? | 19:37 |
| AlbertA | kgunn: right | 19:37 |
| AlbertA | kgunn: there's an MP that wants to delete the occlusion logic | 19:38 |
| AlbertA | kgunn: but I think since anpok has already done the work to switch to opaque surfaces in unity | 19:38 |
| AlbertA | kgunn: that is still worth keeping | 19:38 |
| kgunn | AlbertA: i agree with you...that's still so obviously valuable we shouldn't remove it | 19:38 |
| kgunn | AlbertA: do i need to reject? | 19:38 |
| racarr__ | Eh I was going to reject it later too so | 19:39 |
| kgunn | racarr__: AlbertA ...i don't mind being the team punching bag :) | 19:39 |
| AlbertA | kdub: ^ | 19:40 |
| AlbertA | kgunn: I disapproved | 19:40 |
| kgunn | anpok: while you're here :)....in your mind are we "done" satisfying greyback and dandrader's requirements | 19:40 |
| kgunn | sorry i fell out of touch on the android input wrapper | 19:40 |
| anpok | AlbertA: hm I think we could go with really opaque by default, and change osk and popups to enforce transparency | 19:41 |
| anpok | best in one go.. | 19:41 |
| anpok | kgunn: I pushed a branch for dandrader that is enough to unblock | 19:42 |
| anpok | but not complete | 19:42 |
| anpok | i.e. all in all it allows a custom dispatcher and provides a working API to send input events to mir clients through mir::input::Surface | 19:42 |
| kgunn | anpok: thanks...so i suppose your in polishing mode on that until its MP worthy ? | 19:43 |
| anpok | but .. still missing is .. proper cleanup when surfaces leave scene.. detection of non responding client | 19:44 |
| dandrader | anpok, btw, is input_sender.cpp all-new code or did you copy-pasted-and-modified code from andoird::InputDispatcher? | 19:44 |
| anpok | s | 19:44 |
| anpok | kgunn: yes | 19:44 |
| anpok | dandrader: all new | 19:44 |
| dandrader | anpok, brave man! :) | 19:44 |
| anpok | dandrader: considered c&p but feared the review | 19:44 |
| kgunn | heh | 19:45 |
| kgunn | hehe | 19:45 |
| anpok | kgunn: so yes... several branches in the queue .. based on https://code.launchpad.net/~andreas-pokorny/mir/custom_input_dispatcher/+merge/215174 .. and hopefully someday the mess I caused is cleaned up | 19:46 |
| racarr__ | I will review that again today....havent caught up on your last few adys of work | 19:46 |
| anpok | racarr__: no real change on that one. just some smaller findings .. | 19:47 |
| racarr__ | I know I just want to review the whole um | 19:47 |
| racarr__ | sort of stack | 19:47 |
| racarr__ | Right now though I am deep in meditation seeking the true nature of mir::graphics::CursorImage | 19:48 |
| racarr__ | ;) | 19:48 |
| anpok | AlbertA: kgunn: I would like to push opaque surfaces - but do not see it happen before input singularity | 19:49 |
| anpok | so if urgent someone else should take over *wink* | 19:49 |
| kgunn | anpok: agreed...rightly so, i see that as a nice optimization | 19:49 |
| kgunn | actually...i'd probably ask for some acceptance test love first :) | 19:50 |
| anpok | oh dear | 19:50 |
| AlbertA | anpok: I don't think it's urgent :) | 19:50 |
| racarr__ | Sigh...I really dont want to remove cursor_theme from the client API over a debate of the name of the class that supplies cursor images | 19:52 |
| racarr__ | so that we can come add it again later | 19:52 |
| kgunn | AlbertA: can i say powerd, display state stuff is "done" | 19:52 |
| kgunn | cleaning up blueprints | 19:52 |
| kgunn | if you think there is still some churn there we'll leave it open | 19:52 |
| AlbertA | tvoss: ^ | 19:53 |
| AlbertA | kgunn: I believe tvoss had an re-architecture plan for powerd? | 19:53 |
| AlbertA | tvoss__:^ | 19:53 |
| AlbertA | kgunn: so I haven't seen myself any activity in powerd so it's up in the air right now... | 19:54 |
| AlbertA | kgunn: the last discussion I had, it seemed like the MP I have pending in USC would be sufficient | 19:54 |
| AlbertA | kgunn: but tvoss mentioned yesterday he had some plans for rearchitecture I think I don't know what things will change | 19:55 |
| racarr__ | so I am considering cursor_name->cursor_spec, which can take the form like "rightarrow" "default/rightarrow" "gamecursors/rightarrow" | 19:55 |
| racarr__ | but then that requires a whole description of what a cursor spec is and limits cursor names and | 19:55 |
| racarr__ | all in all seems kind of silly | 19:56 |
| AlbertA | racarr__: more naming wars? | 19:56 |
| AlbertA | :) | 19:56 |
| kgunn | AlbertA: what's holding up landing the mp pending in usc ?.....is it me landing it ? | 19:58 |
| AlbertA | kgunn: no pending on powerd rework | 19:59 |
| kgunn | AlbertA: is that seth ? | 19:59 |
| AlbertA | kgunn: I dunno if anybody got assigned to that work - rsalveti: ^ | 19:59 |
| rsalveti | AlbertA: kgunn: which MR? | 20:00 |
| AlbertA | rsalveti: the one about removing the display state changes from powerd | 20:01 |
| AlbertA | rsalveti: and the input parsing | 20:01 |
| rsalveti | I think tvoss__ will indeed change powerd's architecture, but not for now | 20:01 |
| rsalveti | AlbertA: have the links in hands? | 20:01 |
| AlbertA | rsalveti: no, last time I asked you were going to submit the mr so I don't have a link | 20:01 |
| rsalveti | sure, for powerd I still need to create them :-) | 20:02 |
| rsalveti | just saying where can I find the other MRs, for usc | 20:02 |
| AlbertA | the MP for USC is here: | 20:02 |
| AlbertA | https://code.launchpad.net/~albaguirre/unity-system-compositor/screen-power-state-handling/+merge/213957 | 20:02 |
| rsalveti | I remember I had 2 pending changes to do: | 20:02 |
| rsalveti | 1 - export the dim value via dbus | 20:03 |
| rsalveti | 2 - remove the display state changes | 20:03 |
| AlbertA | rsalveti: right and also no input parsing is needed since the inactivity timers would move to usc | 20:03 |
| rsalveti | right | 20:03 |
| kgunn | AlbertA: rsalveti ...so is this something we can do before the next "re-architecture" ? | 20:04 |
| rsalveti | cool, let me try to get something today still and will ping you back | 20:04 |
| rsalveti | kgunn: for sure | 20:04 |
| kgunn | cool | 20:04 |
| kgunn | (also a question of do we want to...sounds like we do) | 20:04 |
| rsalveti | yup | 20:04 |
| racarr__ | run -> lunch -> back in a bit | 20:08 |
| === beidl_ is now known as beidl | ||
| kgunn | kdub: wrt android driver compliance test suite, do you consider our integration tests actually providing that function ?...or is more needed ? | 20:34 |
| kdub | kgunn, they provide a test that integrates the drivers with mir | 20:35 |
| kdub | I don't know if we should produce a test suite for one of our dependencies though | 20:36 |
| kdub | an example... gralloc should be able to open and close cleanly, but it seems strange to make a test that just checks that without any mir code involved | 20:36 |
| kgunn | mmm | 20:37 |
| kgunn | camako: ^ interesting task kdub has been pushing for a long time now... | 20:37 |
| kgunn | e.g. if you're an oem, how do you know you've got all the required bits to run mir | 20:37 |
| kgunn | kdub: at any rate i'll reword the task in the bp | 20:38 |
| camako | kgunn: yes since android itself is evolving | 20:38 |
| kdub | kgunn, okay | 20:38 |
| kdub | if the integration tests run, there's a pretty good chance the server/client will run okay | 20:39 |
| kdub | the one coverage gap that I can think of is hitting the driver with our screenshotting code | 20:40 |
| camako | kgunn, kdub: especially important if oem ever does mir before android :-) | 20:41 |
| kdub | sure :) | 20:42 |
| anpok | racarr__: ping when you are back.. | 20:49 |
| racarr__ | anpok: Poonng | 21:03 |
| anpok | playing with InputRegistrar .. | 21:04 |
| anpok | cleaned some of my mess | 21:05 |
| anpok | but now that I look at it -> why not introduce something like a SceneObserver? | 21:05 |
| anpok | that gets surface_added .. surface_removed.. | 21:05 |
| AlbertA | anpok: you mean like racarr__ mp: https://code.launchpad.net/~mir-team/mir/introduce-scene-observer/+merge/215969 | 21:07 |
| racarr__ | Indeed | 21:08 |
| racarr__ | that is getting reproposed today | 21:08 |
| racarr__ | with some modifications | 21:08 |
| racarr__ | tried the observer ownership thing...but I guess its not really the best either | 21:08 |
| anpok | ah I remember | 21:10 |
| anpok | I changed InputRegistrar into something similar | 21:10 |
| anpok | but with an awkward name | 21:11 |
| anpok | racarr__: will the new version still hold a lock while calling the observers? | 21:13 |
| racarr__ | another way of conversational standstill on cursor images yay | 21:25 |
| racarr__ | sorry got distracted from IRC | 21:25 |
| racarr__ | anpok: Um. Yes so far | 21:26 |
| racarr__ | its possible to copy the observers...its also possible | 21:26 |
| racarr__ | in the case of the dispatcher, well | 21:26 |
| racarr__ | signal in to a dispatcher thread or something | 21:26 |
| racarr__ | err wait | 21:27 |
| racarr__ | why does it matter? | 21:27 |
| AlbertA | racarr__: last time I tested it one of the tests deadlocked | 21:29 |
| racarr__ | yeah...I fixed that in the rebased off of rework | 21:30 |
| racarr__ | surface-observer | 21:30 |
| racarr__ | version | 21:30 |
| racarr__ | but now have to unrebase | 21:30 |
| anpok | racarr__: because of possible deadlocks.. yeah copy observers .. or remember changes and apply after the loop.. | 21:36 |
| anpok | or .. something fancy in between.. | 21:36 |
| racarr__ | why is InputRegistrar/Dispatcher changing anything | 21:36 |
| racarr__ | maybe it should get const mi::Surface | 21:37 |
| anpok | just a general thing.. | 21:47 |
| racarr__ | anpok: There are lots of solutions...copy the observers is one but I am inclined to think its kind of costly for something that happens so frequently | 21:50 |
| racarr__ | other approaches include, recursive mutex, using try_lock on the mutex (And simply mute recursive observations)) | 21:50 |
| racarr__ | remembering changes, something fancy inbetween that remembers changes, or maybe something fancy inbetween that just remembers to emit the notifications | 21:51 |
| racarr__ | ...so I dont know how to pick one | 21:51 |
| racarr__ | but I think for now, input can deal with const mi::Surface mostly? and | 21:51 |
| racarr__ | the compositor jumps the problem with the multiple threads | 21:52 |
| racarr__ | and ther eis a test in place for that | 21:52 |
| racarr__ | so I think we can just delay picking something until we are forced and | 21:52 |
| racarr__ | then we will be able to choose better | 21:52 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!