[06:39] <tvoss> hmmm, taking eglSwapBuffers and eglSwapInterval strict, a turned off screen does not have vsync. With that, waiting for an eglSwapBuffers with an eglSwapInterval > 0 should never return
[06:43] <duflu_> tvoss: Yep. And so all compositors and apps sleep nicely when the screen is off.
[06:43] <duflu_> Unless you have the fglrx driver, which was buggy there
[07:00] <tvoss> duflu, I was thinking: If an application would decouple from vsync via a call to eglSwapInterval(0) in reaction to the screen being turned off, immediately returning false from eglSwapBuffers would be valid
[07:01] <duflu> tvoss: Returning false sounds correct. However I have seen drivers differ and buggy with respect to return values for an "off" screen.
[14:09] <mterry> kgunn, so I think the biggest risk factor with split greeter silo is the Mir bugs.  I'm going to look into the screen on/off one today a bit.  I think racarr was looking at my bugs too?  Do you know if he got anywhere?
[14:12] <kgunn> mterry: not sure...but good to know...do we have logged bugs for those ?
[14:12] <kgunn> to enable me to be really annoying :)
[14:12] <mterry> kgunn, um.  No, probably not.  /me is bad at paperwork
[14:12] <mterry> kgunn, will file
[14:13] <mterry> kgunn, will work on
[14:15] <kgunn> mterry: no worries....still steamy its all so new :)
[14:16] <kgunn> mterry: i do know anpok_ was poking around on the flicker
[14:16] <kgunn> like first few frames being transparent from greeter
[14:16] <mterry> kgunn, yeah...  That is something I was willing to live with and fix later
[14:16] <mterry> Not something users will always see
[14:18] <anpok_> kgunn: current status is in the review
[14:18] <anpok_> approved it as it is not cause by the change..
[14:19] <anpok_> i tried with a non-qt greeter (basic_server + eglplasma :)) but that is not a proper greeter..
[14:20] <anpok_> so I couldnt get to that sequence of turning off and on..
[14:20] <anpok_> I wanted to look at the qt side of things next..
[14:20] <mterry> kgunn, bug 1297876 and bug 1297878
[14:21] <anpok_> oh 1297876 is a mir issue
[14:21] <mterry> kgunn, I'll look at the first one because that seems like something I could track down (see where screen turns on and work back).  But the second one looks like it requires more knowledge of Mir than I have
[14:21] <mterry> kgunn, I think racarr was looking at one or both of them
[14:22] <mterry> anpok_, I *think* second one is too
[14:23] <kgunn> anpok_: want to dive in to 1297876...and maybe work with racarr when he comes on....
[14:23] <kgunn> let's see if we can kill these quickly
[14:24]  * kgunn wants to land split greeter soon!
[14:24] <anpok_> kgunn: sure - this one is very annoying, thought it was in a different part of the system.
[14:24] <anpok_> brb
[14:40] <AlbertA> so now that facebook will buy oculus do we still have to "pass the oculus rift test"? :)
[14:43] <anpok_> there is another company with augmented reality glasses
[14:43] <AlbertA> sony?
[14:43] <AlbertA> :)
[14:44] <anpok_> or in austria there is a vr startup
[14:44] <anpok_> i think we just rename it .. or have an indirection
[14:44] <ogra_> AlbertA, sure you do, we need to be prepared for when we acquire facebook as sub-devision after making billions and billions in the phone market
[14:44] <anpok_> "coolest displaying tec test"
[14:45] <AlbertA> I kinda like passing the "morpheus test"
[14:45] <AlbertA> though probably not applicable :)
[14:46] <anpok_> hmm i am sure the sony equipment will work in linux likewise..
[14:46] <AlbertA> unless we get ubuntu running on the ps4 :)
[14:56] <ogra_> lets start small, Ubuntu Phone on the PSP first ;)
[15:00] <anpok_> vita might be simpler .. no mips ...
[15:11] <alan_g> AlbertA: look at DemoPrivateProtobuf
[15:17] <AlbertA> alan_g: thanks
[15:17] <alan_g> yw
[16:32] <alan_g> Does anyone know why ConsumingPlacementStrategy exists in the codebase?
[16:44] <kdub> alan_g, I don't know
[16:52] <pietro10> Quick dev-related question: does Mir use libxkbcommon? Thanks.
[16:54] <kdub> its one of our dependencies
[16:54] <alan_g> $ grep libxkbcommon debian/control
[16:54] <alan_g>                libxkbcommon-dev,
[17:02] <pietro10> thanks
[19:02] <kgunn> AlbertA: trying to be better about public chat...so powerd will still contain brightness value ?
[19:02] <kgunn> and u-s-c will simply be a proxy for the ui in terms of requests to change that value...?
[19:03] <kgunn> i assume wrt actual screen state (on/off) that's still going to end up in u-s-c ?
[19:03] <AlbertA> kgunn: yes powerd will still handle the brightness logic
[19:03] <AlbertA> kgunn: I was pulling that into usc but from the conversation in the morning
[19:03] <AlbertA> kgunn: that was better left in powerd
[19:03] <kgunn> ok
[19:04] <AlbertA> kgunn: but usc will inform powerd when to act on brightness etc
[19:05] <kgunn> AlbertA: makes complete sense, any hw ctl & related hw logic should be in powerd...and usc is more about policy & req/resp on powerd
[19:06] <AlbertA> kgunn: yes basically usc will do the input event timeouts and display on/off, and it will inform powerd when to to dim the screen
[19:07] <AlbertA> kgunn: the settings will be obtained from the sessions possibly from a sidechannel using the same server socket mir uses
[19:07] <AlbertA> kgunn: or maybe we can incorporate it into display configuration - for now I'm leaning towards side channel as far as settings
[19:19] <kgunn> ack
[19:58] <kgunn> mterry: out of bug 1297876 and bug 1297878
[19:58] <kgunn> you really wanted help with 78 right ?
[19:59] <kgunn> just wanted to make sure i was asking racarr about the right thing
[19:59] <kgunn> or...asking him to look at the right thing
[19:59] <mterry> kgunn, both are blockers, but I think I can at least investigate 76 myself.  Plus 78 affects more than just split mode, so it's more critical.  I think racarr was looking more into 76 so far, but I'm not sure of his progress in either
[20:00] <kgunn> agreed...78 looks like the nastier of the 2
[20:00] <kgunn> in terms of ux effect
[20:01] <mterry> kgunn, 76 is mad annoying bro
[20:02] <mterry> but yes
[20:02] <kgunn> mterry: sorry...i meant 76
[20:02] <kgunn> no nvmd...
[20:02] <mterry> kgunn, they are both super annoying
[20:02] <kgunn> ah..my eyes o.O
[20:02] <mterry> kgunn, one drains battery and is startling.  One makes keyboard useless
[20:03] <kgunn> keyboard useless is worse imho
[20:03] <mterry> sure
[20:03] <mterry> I'm on the same page  :)  I just also hate 76
[20:21] <racarr> should I just
[20:21] <racarr> flip a coin/
[20:21] <racarr> ok no 78
[20:22] <racarr> mterry: kgunn: Anything known so far on 78 besides that is in the bug?
[20:23] <mterry> racarr, no
[20:23] <racarr> cool
[20:24] <racarr> ill be on it in an hour or so (have to do the usual flash phone clean, build clean stack, etc...)
[20:47] <kgunn> bregma: bschaefer ...meant to ask
[20:47] <kgunn> oops, wait...moving
[22:06] <mterry> racarr, regarding the 76 issue, your original instincts were right.  If I uncomment the "power_mode = default_power_state" bits in DefaultDisplayConfigurationPolicy::apply_to, problem goes away.  In your unity-mir branch, you say nested mode should do nothing for apply_to.  Should NestedDisplay() just not call apply_to?
[22:10] <racarr> mterry: Which branch of unity-mir are you using against mir devel? trunk isnt building
[22:10] <racarr> mterry: Err...let me think
[22:11] <mterry> racarr, whichever ended up in silo 004
[22:11] <mterry> kgunn_, which branches did you use for unity-mir in silo 004?
[22:12] <racarr> mterry: Err...so I cant remember exactly what I said in my unity-mir branch
[22:12] <racarr> I think it would make sense to say though, for example that
[22:13] <racarr> the nested server should inherit the display configuration from the system compositor by default
[22:13] <racarr> so the nested server could use a
[22:13] <racarr> DisplayConfigurationPolicy (overriding the_display_configuration_policy)
[22:13] <racarr> that doesnt initialize things to their default state
[22:13] <racarr> re-initialie/whatever
[22:21] <kdub> if they're different defaults, why not just provide an appropriate default implementation instead of overriding things
[22:23] <racarr> mterry: Ok where does silo 4 come from!
[22:23] <racarr> I guess maybe I can use binary packages of unity-mir
[22:23] <racarr> but...I think server abi broke
[22:23] <racarr> as early as like
[22:23] <racarr> every day for the past week
[22:23] <racarr> lol
[22:23] <racarr> so im not sure how this is possible
[22:23] <kgunn_> mterry: one moment
[22:23] <mterry> racarr, https://launchpad.net/~ci-train-ppa-service/+archive/landing-004/+packages
[22:24] <kgunn_> mterry: https://pastebin.canonical.com/107219/
[22:24] <kgunn_> racarr: ^ if needed
[22:26] <racarr> hmm I only see one unity-mir branch
[22:26] <racarr> which doesnt have the update
[22:26] <racarr> that the_session_authoried now has to implement screencast_is_allowed
[22:26] <racarr> maybe I got my local branches mixed up just a sec
[22:29] <racarr> mterry: Err, so I am not sure how you built mir/devel
[22:29] <racarr> against these packages
[22:30] <mterry> racarr, I apt-get sourced the package in the silo
[22:30] <racarr>  / are there missing um branches...
[22:30] <racarr> the mir package?
[22:30] <mterry> racarr, and worked off that.  That way, no rebuilding
[22:30] <mterry> racarr, yeah
[22:30] <racarr> oh
[22:30] <racarr> thats at least a week behind mir devel it seems
[22:31] <racarr> maybe more? screencast has been in for forever
[22:31] <mterry> racarr, well, good for fixing bugs anyway
[22:31] <racarr> mm
[22:31] <racarr> lemme get the PPA then
[22:39] <racarr> except apt-get update wont finish lol thats good
[22:42] <racarr> mterry: Just to make sure I understand how I am supposed to reproduce it
[22:42] <racarr> it should just show up in this silo
[22:42] <racarr> so there is nothing to isolate it to mir/mir devel in particular
[22:42] <mterry> racarr, yeah
[22:43] <mterry> racarr, uh.  76 needs silo.  78 should be reproducable with stock unity8 and silo
[22:43] <mterry> racarr, haven't tested 78 with stock unity8 and mir/devel
[22:43] <racarr> right but at this point it could be anything in the silo except unity8 right
[22:44] <racarr> i.e. papi/unity-mir
[22:44] <mterry> racarr, well papi/unity-mir are just rebuilds agains tmir
[22:53] <racarr> er...do you have to do something besides writable-image to make
[22:53] <racarr> apt work on the phones now
[22:53] <racarr> I am having all sorts of issues
[22:55] <mterry> racarr, no...
[22:55] <racarr> :/ apt-get update will never finish even though I can access the servers it claims to stall on
[22:55] <mterry> racarr, what errors?
[22:56] <racarr> and dist-upgrade is complaining about no space left ond evice
[22:56] <racarr> even though its a clean flash
[22:56] <mterry> racarr, I've gotten the stall before, a reboot can fix that sometimes
[22:56] <racarr> I dont even know space on what partition...and I check mount -v and see there are now liek
[22:56] <racarr> over 20 partitions lol
[22:56] <mterry> racarr, no space is an odd one after clean refresh.  two things can help:
[22:56] <mterry> apt-get purge 'language-pack.*' mir-test-tools
[22:56] <mterry> rm -r /var/cache/apt/archives/
[22:57] <racarr> I cant even run apt-get purge
[22:57] <racarr> because of no space
[22:57] <racarr> but I literally
[22:57] <racarr> emptied /var/cache
[22:57] <racarr> hmm
[22:59] <racarr> I guess I will reflash
[22:59] <racarr> with bootstrap
[22:59] <racarr> hopefully my flash isnt dieing
[22:59] <mterry> racarr, bootstrap shouldn't be needed, but couldn't hurt
[23:00] <racarr> shouldnt be right but
[23:00] <racarr> dont know what to do at this point
[23:00] <racarr> I mean I literally just flashed a new image without bootstrap immediately prior to this.
[23:02] <mterry> racarr, :(
[23:03] <mterry> racarr, did you accidentally do dd < /dev/random > /datafile?  common mistake
[23:05] <racarr> mterry: Maybe, thats my password
[23:05] <racarr> so maybe I entered it in the wrong prompt
[23:05] <mterry> :)
[23:05] <racarr> or maybe my flash is dead
[23:13] <racarr> lol ok everything seems happy now.
[23:13] <racarr> just going to pretend that never happened
[23:13] <racarr> my usb cable is pretty flaky maybe the flashing process went wrong or maybe my flash really is failing
[23:14] <racarr> maybe it was just overheating *shrug*
[23:16] <mterry> :-/
[23:17] <mterry> racarr, still before you re-install all the mir deps, you should probably run " apt-get purge 'language-pack.*' mir-test-tools" to help avoid in future
[23:18] <racarr> mterry: good call
[23:19] <racarr> woah
[23:19] <racarr> that was quite
[23:19] <racarr> the boot up experience
[23:20] <mterry> racarr, with the PPA?
[23:20] <racarr> yes
[23:20] <racarr> I can see also the osk
[23:20] <racarr> literally cant be dismissed lol
[23:20] <mterry> :)
[23:20] <racarr> I also got it stuck rotated somehow
[23:21] <mterry> If you re-summon it, it can come back unrotated
[23:29] <racarr> hmm ok well have to get unity-mir debug symbols now...
[23:29] <racarr> MirSurfaceManager::surfaceAttributeChanged is at least being called when the OSK comes up so cant understnad why
[23:29] <racarr> the surface wouldnt be getting the state
[23:29] <racarr> but we shall see
[23:55] <racarr> interesting
[23:55] <racarr> surface manager cant find the unity-mir side
[23:55] <racarr> osk surface at the time of
[23:55] <racarr> attribute
[23:55] <racarr> setting