[00:03] <RAOF> racarr__: You wanted to discuss 1Hz-rendering
[00:03] <RAOF> ?
[00:04] <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:05] <RAOF> racarr__: Sure!
[01:00] <kgunn> searching for a headset...
[07:24] <RAOF> In Which I Gain A New Appreciation Of How Slow Nexus 4 Hardware Is.
[07:27] <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:28] <RAOF> Turns out a thread sleeping for 1ms is not long enough for another thread to get unblocked and take the lock.
[07:40] <mlankhorst> RAOF: that's really really the wrong approach to locking ;P
[07:54] <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 :)
[08:01] <mlankhorst> hah :p
[08:01] <mlankhorst> while (pthread_mutex_trylock()) unlock() sleep ? :D
[08:03] <RAOF> I'll just (a) bump it to 2ms and (b) move the locking closer.
[08:07] <duflu> RAOF: Script up a test which runs helgrind ;)
[08:07] <duflu> That will fail reliably
[08:07] <RAOF> duflu: Hush!
[08:08]  * duflu bows head and backs into hole
[08:08] <RAOF> Anyway, EOD for me.
[08:16] <alf_> duflu: Is https://bugs.launchpad.net/mir/+bug/1308843 about the buffer consuming thread running faster than the real compositor?
[08:20] <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:21] <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:22] <alf_> duflu: there's also RAOFs approach which shouldn't have this issue
[08:22] <alf_> duflu: have you tried it?
[08:23] <duflu> alf_: No I was trying to solve regressions before doing more code reviews
[08:23] <duflu> Argh, we're all tangled
[08:25] <duflu> Anyway, the fix(es) are easy. I'll continue improving the regression tests regardless
[08:30] <duflu> Wow, that's huge
[08:30] <duflu> I think we can do better
[08:32] <alf_> duflu: what's huge?
[08:32] <duflu> alf_: The diff
[08:34] <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:35] <duflu> A lot of risk, definitely
[08:35] <duflu> And maintenance burden
[13:39] <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:40] <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:43] <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.
[14:49] <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..
[15:34] <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:35] <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:36] <AlbertA> anpok: that's the spirit of open source
[15:36] <AlbertA> anpok: :)
[15:41] <anpok> alan_g: https://code.launchpad.net/~andreas-pokorny/mir/custom_input_dispatcher/+merge/215174/comments/514940
[15:43] <anpok> alan_g: would you prefer a huge change that does everything in one MP - or several normal sized changes?
[15:44] <anpok> hmm it is already beyond 3k...
[15:46] <alan_g> anpok: I don't mind promises that "this is only like this until the next MP"
[15:48] <anpok> can I reuse that promises since it will take a few more MPs untill that thing evaporates
[15:48] <alan_g> ack
[15:49] <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:50] <anpok> which I expect leads to further discussions...
[17:43] <racarr__> I just noticed my desk is not only on a slanted part of my floor
[17:44] <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 ;)
[18:02] <kdub> hah, all those earthquakes
[18:03] <kdub> any more takers on this: https://code.launchpad.net/~kdub/mir/gl-program-creation-factory/+merge/216218 ?
[18:46] <kdub> thanks AlbertA
[19:37] <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:38] <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:39] <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:40] <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:41] <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:42] <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:43] <kgunn> anpok: thanks...so i suppose your in polishing mode on that until its MP worthy ?
[19:44] <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:45] <kgunn> heh
[19:45] <kgunn> hehe
[19:46] <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:47] <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:48] <racarr__> Right now though I am deep in meditation seeking the true nature of mir::graphics::CursorImage
[19:48] <racarr__> ;)
[19:49] <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:50] <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:52] <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:53] <AlbertA> tvoss: ^
[19:53] <AlbertA> kgunn: I believe tvoss had an re-architecture plan for powerd?
[19:53] <AlbertA> tvoss__:^
[19:54] <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:55] <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:56] <racarr__> all in all seems kind of silly
[19:56] <AlbertA> racarr__: more naming wars?
[19:56] <AlbertA> :)
[19:58] <kgunn> AlbertA: what's holding up landing the mp pending in usc ?.....is it me landing it ?
[19:59] <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: ^
[20:00] <rsalveti> AlbertA: kgunn: which MR?
[20:01] <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:02] <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:03] <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:04] <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:08] <racarr__> run -> lunch -> back in a bit
[20:34] <kgunn> kdub: wrt android driver compliance test suite, do you consider our integration tests actually providing that function ?...or is more needed ?
[20:35] <kdub> kgunn, they provide a test that integrates the drivers with mir
[20:36] <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:37] <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:38] <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:39] <kdub> if the integration tests run, there's a pretty good chance the server/client will run okay
[20:40] <kdub> the one coverage gap that I can think of is hitting the driver with our screenshotting code
[20:41] <camako> kgunn, kdub: especially important if oem ever does mir before android :-)
[20:42] <kdub> sure :)
[20:49] <anpok> racarr__: ping when you are back..
[21:03] <racarr__> anpok: Poonng
[21:04] <anpok> playing with InputRegistrar ..
[21:05] <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:07] <AlbertA> anpok: you mean like racarr__ mp: https://code.launchpad.net/~mir-team/mir/introduce-scene-observer/+merge/215969
[21:08] <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:10] <anpok> ah I remember
[21:10] <anpok> I changed InputRegistrar into something similar
[21:11] <anpok> but with an awkward name
[21:13] <anpok> racarr__: will the new version still hold a lock while calling the observers?
[21:25] <racarr__> another way of conversational standstill on cursor images yay
[21:25] <racarr__> sorry got distracted from IRC
[21:26] <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:27] <racarr__> err wait
[21:27] <racarr__> why does it matter?
[21:29] <AlbertA> racarr__: last time I tested it one of the tests deadlocked
[21:30] <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:36] <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:37] <racarr__> maybe it should get const mi::Surface
[21:47] <anpok> just a general thing..
[21:50] <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:51] <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:52] <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