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