RAOFracarr__: You wanted to discuss 1Hz-rendering00:03
kdubracarr__,  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/21374200:04
racarr__kdub: Yeah!00:04
racarr__RAOF: Um...in a bit (around meeting or something?) getting ready to make dinner00:04
RAOFracarr__: Sure!00:05
kgunnsearching for a headset...01:00
=== chihchun_afk is now known as chihchun
RAOFIn Which I Gain A New Appreciation Of How Slow Nexus 4 Hardware Is.07:24
anpok_RAOF: hm?07:27
RAOFanpok_: Oh, running into a race I thought couldn't happen.07:27
RAOFBut does on N4.07:27
RAOFUnder valgrind, admittedly.07:27
RAOFTurns out a thread sleeping for 1ms is not long enough for another thread to get unblocked and take the lock.07:28
mlankhorstRAOF: that's really really the wrong approach to locking ;P07:40
RAOFWell, 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
mlankhorsthah :p08:01
mlankhorstwhile (pthread_mutex_trylock()) unlock() sleep ? :D08:01
RAOFI'll just (a) bump it to 2ms and (b) move the locking closer.08:03
dufluRAOF: Script up a test which runs helgrind ;)08:07
dufluThat will fail reliably08:07
RAOFduflu: Hush!08:07
* duflu bows head and backs into hole08:08
RAOFAnyway, 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
ubot5Launchpad bug 1308843 in Mir "[regression] Client judders, skipping frames periodically" [High,In progress]08:16
duflualf_: 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 now08:20
=== xnox is now known as NoNameYet_xnox
alf_duflu: "to make the consumer conditional" ?08:21
dufluIt'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't08:21
alf_duflu: there's also RAOFs approach which shouldn't have this issue08:22
alf_duflu: have you tried it?08:22
duflualf_: No I was trying to solve regressions before doing more code reviews08:23
dufluArgh, we're all tangled08:23
dufluAnyway, the fix(es) are easy. I'll continue improving the regression tests regardless08:25
dufluWow, that's huge08:30
dufluI think we can do better08:30
alf_duflu: what's huge?08:32
duflualf_: The diff08:32
alf_duflu: diff of what?08:34
duflualf_: 1Hz branch08:34
dufluI think I can solve multiple regressions with much less change08:34
anpok_hm the timer functionality adds a lot08:34
dufluA lot of risk, definitely08:35
dufluAnd maintenance burden08: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
kgunnalf_: just want to say...non-block swap buffers on mir-devel seems to be rockin'13:39
kgunni tested all day y'day on xmir...did a lot of suspends13:39
kgunnand comparing to regular X....didn't see any difference13:39
kgunnin fact, i see a bug sometimes on X suspend :)13:39
kgunnalso, i put through the wringer on nexus 10...no new bugs13:40
kgunnany bugs around sidestage are the same/already present13: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
anpokso we wont integrate RAOFs MP?14:49
anpokI 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 evaluation15:34
AlbertAanpok: that's up to the panel to decide :)15:34
anpokthe elder?15:34
anpokI was thinking about shamlessly ripping that part out and providing it as is in a separate MP15:35
AlbertAanpok: let's merge both and see what happens.... ;)15:35
AlbertAanpok: that's the spirit of open source15:36
AlbertAanpok: :)15:36
anpokalan_g: https://code.launchpad.net/~andreas-pokorny/mir/custom_input_dispatcher/+merge/215174/comments/51494015:41
anpokalan_g: would you prefer a huge change that does everything in one MP - or several normal sized changes?15:43
anpokhmm it is already beyond 3k...15:44
alan_ganpok: I don't mind promises that "this is only like this until the next MP"15:46
=== dandrader|afk is now known as dandrader
anpokcan I reuse that promises since it will take a few more MPs untill that thing evaporates15:48
anpokand at some point I need to add (or understand that those events can be ignored) something to MirEvent15:49
anpokto store device reset events..15:49
anpokwhich 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 floor17:43
racarr__but is bowing at the middle17:44
racarr__and my keyboard is at quite an angle lol17:44
racarr__Ive had this muscular thing that I thought was from playing piano...and now I think I know the culprit ;)17:44
kdubhah, all those earthquakes18:02
kdubany more takers on this: https://code.launchpad.net/~kdub/mir/gl-program-creation-factory/+merge/216218 ?18:03
kdubthanks AlbertA18:46
=== chihchun is now known as chihchun_afk
=== dandrader|afk is now known as dandrader
kgunnAlbertA: anpok on the topic of occlusion detection & alpha detection19:37
kgunnwe still would allow the occluded app to render19:37
kgunnbut the compositor would just ignore right ?19:37
AlbertAkgunn: right19:37
AlbertAkgunn: there's an MP that wants to delete the occlusion logic19:38
AlbertAkgunn: but I think since anpok has already done the work to switch to opaque surfaces in unity19:38
AlbertAkgunn: that is still worth keeping19:38
kgunnAlbertA: i agree with you...that's still so obviously valuable we shouldn't remove it19:38
kgunnAlbertA: do i need to reject?19:38
racarr__Eh I was going to reject it later too so19:39
kgunnracarr__: AlbertA ...i don't mind being the team punching bag :)19:39
AlbertAkdub: ^19:40
AlbertAkgunn: I disapproved19:40
kgunnanpok: while you're here :)....in your mind are we "done" satisfying greyback and dandrader's requirements19:40
kgunnsorry i fell out of touch on the android input wrapper19:40
anpokAlbertA: hm I think we could go with really opaque by default, and change osk and popups to enforce transparency19:41
anpokbest in one go..19:41
anpokkgunn: I pushed a branch for dandrader that is enough to unblock19:42
anpokbut not complete19:42
anpoki.e. all in all it allows a custom dispatcher and provides a working API to send input events to mir clients through mir::input::Surface19:42
kgunnanpok: thanks...so i suppose your in polishing mode on that until its MP worthy ?19:43
anpokbut .. still missing is .. proper cleanup when surfaces leave scene.. detection of non responding client19:44
dandraderanpok, btw, is input_sender.cpp all-new code or did you copy-pasted-and-modified code from andoird::InputDispatcher?19:44
anpokkgunn: yes19:44
anpokdandrader: all new19:44
dandraderanpok, brave man! :)19:44
anpokdandrader: considered c&p but feared the review19:44
anpokkgunn: 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 up19:46
racarr__I will review that again today....havent caught up on your last few adys of work19:46
anpokracarr__: no real change on that one. just some smaller findings ..19:47
racarr__I know I just want to review the whole um19:47
racarr__sort of stack19:47
racarr__Right now though I am deep in meditation seeking the true nature of mir::graphics::CursorImage19:48
anpokAlbertA: kgunn: I would like to push opaque surfaces - but do not see it happen before input singularity19:49
anpokso if urgent someone else should take over *wink*19:49
kgunnanpok: agreed...rightly so, i see that as a nice optimization19:49
kgunnactually...i'd probably ask for some acceptance test love first :)19:50
anpokoh dear19:50
AlbertAanpok: 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 images19:52
racarr__so that we can come add it again later19:52
kgunnAlbertA: can i say powerd, display state stuff is "done"19:52
kgunncleaning up blueprints19:52
kgunnif you think there is still some churn there we'll leave it open19:52
AlbertAtvoss: ^19:53
AlbertAkgunn: I believe tvoss had an re-architecture plan for powerd?19:53
AlbertAkgunn: so I haven't seen myself any activity in powerd so it's up in the air right now...19:54
AlbertAkgunn: the last discussion I had, it seemed like the MP I have pending in USC would be sufficient19:54
AlbertAkgunn: but tvoss mentioned yesterday he had some plans for rearchitecture I think I don't know what things will change19: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 and19:55
racarr__all in all seems kind of silly19:56
AlbertAracarr__: more naming wars?19:56
kgunnAlbertA: what's holding up landing the mp pending in usc ?.....is it me landing it ?19:58
AlbertAkgunn: no pending on powerd rework19:59
kgunnAlbertA: is that seth ?19:59
AlbertAkgunn: I dunno if anybody got assigned to that work - rsalveti: ^19:59
rsalvetiAlbertA: kgunn: which MR?20:00
AlbertArsalveti: the one about removing the display state changes from powerd20:01
AlbertArsalveti: and the input parsing20:01
rsalvetiI think tvoss__ will indeed change powerd's architecture, but not for now20:01
rsalvetiAlbertA: have the links in hands?20:01
AlbertArsalveti: no, last time I asked you were going to submit the mr so I don't have a link20:01
rsalvetisure, for powerd I still need to create them :-)20:02
rsalvetijust saying where can I find the other MRs, for usc20:02
AlbertAthe MP for USC is here:20:02
rsalvetiI remember I had 2 pending changes to do:20:02
rsalveti1 - export the dim value via dbus20:03
rsalveti2 - remove the display state changes20:03
AlbertArsalveti: right and also no input parsing is needed since the inactivity timers would move to usc20:03
kgunnAlbertA: rsalveti ...so is this something we can do before the next "re-architecture" ?20:04
rsalveticool, let me try to get something today still and will ping you back20:04
rsalvetikgunn: for sure20:04
kgunn(also a question of do we want to...sounds like we do)20:04
racarr__run -> lunch -> back in a bit20:08
=== beidl_ is now known as beidl
kgunnkdub: wrt android driver compliance test suite, do you consider our integration tests actually providing that function ?...or is more needed ?20:34
kdubkgunn, they provide a test that integrates the drivers with mir20:35
kdubI don't know if we should produce a test suite for one of our dependencies though20:36
kduban 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 involved20:36
kgunncamako: ^ interesting task kdub has been pushing for a long time now...20:37
kgunne.g. if you're an oem, how do you know you've got all the required bits to run mir20:37
kgunnkdub: at any rate i'll reword the task in the bp20:38
camakokgunn: yes since android itself is evolving20:38
kdubkgunn, okay20:38
kdubif the integration tests run, there's a pretty good chance the server/client will run okay20:39
kdubthe one coverage gap that I can think of is hitting the driver with our screenshotting code20:40
camakokgunn, kdub: especially important if oem ever does mir before android :-)20:41
kdubsure :)20:42
anpokracarr__: ping when you are back..20:49
racarr__anpok: Poonng21:03
anpokplaying with InputRegistrar ..21:04
anpokcleaned some of my mess21:05
anpokbut now that I look at it -> why not introduce something like a SceneObserver?21:05
anpokthat gets surface_added .. surface_removed..21:05
AlbertAanpok: you mean like racarr__ mp: https://code.launchpad.net/~mir-team/mir/introduce-scene-observer/+merge/21596921:07
racarr__that is getting reproposed today21:08
racarr__with some modifications21:08
racarr__tried the observer ownership thing...but I guess its not really the best either21:08
anpokah I remember21:10
anpokI changed InputRegistrar into something similar21:10
anpokbut with an awkward name21:11
anpokracarr__: will the new version still hold a lock while calling the observers?21:13
racarr__another way of conversational standstill on cursor images yay21:25
racarr__sorry got distracted from IRC21:25
racarr__anpok: Um. Yes so far21:26
racarr__its possible to copy the observers...its also possible21:26
racarr__in the case of the dispatcher, well21:26
racarr__signal in to a dispatcher thread or something21:26
racarr__err wait21:27
racarr__why does it matter?21:27
AlbertAracarr__: last time I tested it one of the tests deadlocked21:29
racarr__yeah...I fixed that in the rebased off of rework21:30
racarr__but now have to unrebase21:30
anpokracarr__: because of possible deadlocks.. yeah copy observers .. or remember changes and apply after the loop..21:36
anpokor .. something fancy in between..21:36
racarr__why is InputRegistrar/Dispatcher changing anything21:36
racarr__maybe it should get const mi::Surface21:37
anpokjust 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 frequently21: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 notifications21:51
racarr__...so I dont know how to pick one21:51
racarr__but I think for now, input can deal with const mi::Surface mostly? and21:51
racarr__the compositor jumps the problem with the multiple threads21:52
racarr__and ther eis a test in place for that21:52
racarr__so I think we can just delay picking something until we are forced and21:52
racarr__then we will be able to choose better21:52

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!