=== chihchun_afk is now known as chihchun
[07:49] <kgunn> duflu: this one
[07:49] <kgunn> https://cvs.khronos.org/bugzilla/show_bug.cgi?id=12052
[07:52] <RAOF> kgunn: Yeah, we need to work out what we want done there.
[07:52] <RAOF> Also, where did my comments go?
[08:03] <kgunn> RAOF: weird...my latest comment not there either ?
[08:11] <RAOF> EOD!
[08:12] <kgunn> alf__: for the non-block spike, duflu is wondering if we should "keep" the blocking eglswap as a potential path....
[08:13] <kgunn> in fact, he thinks non-block is effectively "swapinterval0+sync"
[08:13] <kgunn> sync meaning it doesn't tear
[08:13] <duflu> As the default path at least. So clients and compositors don't regress/spin/etc
[08:14] <kgunn> alf__: also makes me wonder, are we trying too hard on the spike ? .... duflu says the swapinterval 0 today is non-tearing
[08:14] <duflu> eglSwapSleep(dpy, GL_TRUE)
[08:14] <kgunn> hmmm...maybe not on android tho
[08:15] <alf__> kgunn: duflu: swapinterval 0 is not bound above by vsync, the spike is
[08:16] <alf__> kgunn: duflu: that is, with just swap interval 0, clients will render as fast as they can
[08:19] <kgunn> alf__: ah....its in between
[08:20] <kgunn> or rather requires vsync...true...
[08:20] <kgunn> its like it wants some blocking (just not indeterminate blocking :)
[08:21] <alf__> kgunn: at least some kind of throttling, which in the spike is a fake vsync at 60Hz
[08:24] <duflu> alf__: That's a bad idea. We fail the "zero wakeups" test during sleep. And that's something Mark mentioned this week too
[08:26] <alf__> duflu: the buffer consuming thread only wakes up if triggered by a scene change, like the other compositing threads. It's just also enforces a fake vsync. So it's no worse than having another screen attached.
[08:28] <duflu> alf__: It's a basic power management requirement to avoid wakeups during sleep. Only intentional background threads should be the exception
[08:28] <duflu> A fake vsync would create a regression we'd just be forced to remove/fix eventually
[08:31] <alf__> duflu: The fake vsync is only a throttling measure, it *doesn't* wake up the buffer consuming thread itself. The thread is only woken up if triggered by scene changes, and it consumes buffers at most at 60Hz, mimicking an output.
[08:32] <duflu> alf__: I know, but that's still poor power management, and a step backwards from Ubuntu as we know iyt
[08:33] <duflu> alf__: If nothing else, I think we need to keep defaulting to the existing behaviour. Then you can safely add optional behaviour for *anything*
[08:35] <alf__> duflu: The existing behavior (eglSwapBuffers blocking indefinitely) 1. breaks Qt 2. Khronos told us that it's not how things should work
[08:35] <alf__> kgunn: ^^ can you verify point 2, in case I misunderstood something
[08:36] <duflu> alf__: I know and I know. What I'm saying is don't make unblocking behaviour the default, but optional. We would break too many existing apps/compositors/toolkits
[08:36] <duflu> Plus you need buy-in from all the driver vendors, which will take time too
[08:41] <kgunn> alf__: accurate
[08:43] <kgunn> duflu: i agree, spec isn't clear & its not the greatest but side channels have to be used...which alot of OS's use (ios, android, qt)..so which toolkits don't have a side channel ?
[09:11] <kgunn> greyback: did you update the unity-mir branch for 0.1.8 ? (just wanted to make sure i wasn't mistakenly waiting)
[09:15] <greyback> kgunn: not yet, in meeting
[09:15] <kgunn> ack
=== chihchun is now known as chihchun_afk
=== chihchun_afk is now known as chihchun
[09:58] <greyback> kgunn: https://code.launchpad.net/~alan-griffiths/unity-mir/compatibility-with-mir-0.1.8/+merge/214610
[10:00] <kgunn> greyback: thanks...sorry about that...my fault
[10:25] <Saviq> duflu, https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1304959
[10:25] <ubot5> Ubuntu bug 1304959 in unity8 (Ubuntu) "unity8 crashed with SIGABRT in qt_message_fatal()" [Medium,New]
[10:34] <duflu> Saviq: That's the current (stable) Mir. I can't see any issue with Mir as yet
[14:03] <kgunn> racarr__: here's some fun...
[14:03] <kgunn> https://bugs.launchpad.net/mir/+bug/1305080
[14:03] <ubot5> Ubuntu bug 1305080 in Mir "libmirclientplatform-android isn't loaded upon libmirserver install" [Undecided,New]
[14:03] <kgunn> alf__ might have an opinion
[14:18] <mterry> kgunn, I tested your Mir 0.1.8 silo, seemed to work for me
[14:19] <mterry> kgunn, in related news, is there a silo open for split greeter again?  I think I can avoid the Mir troubles I was having last silo by just basing off 0.1.8 and patching it for the one fix I need (which doesn't break ABI)
[14:21] <PreSSion> hello! I want start to develoment a tool to be used in multiplataform linux smartphones, tablets and pc, I going to choose Qt, but I need the develoment of the MIR protocol is seriously and ubuntu will abandon this.
[14:21] <PreSSion> and sry for my "engrish"
[14:30] <kgunn> PreSSion: hi, Mir is serious and won't be abandoned
[14:31] <kgunn> PreSSion: consider the fact that Mir is _the_ display server being used by default in our ubuntu on phones & tablets
[14:31] <PreSSion> nice
[14:31] <kgunn> and we are working toward eventually making it the default display server on the desktop as well
[14:33] <PreSSion> because I want develoment a "yakuake" but not a command line, a tool to make a human script software, where you can say script in human language, for example: Delete files from /home/user that contain the word hello, and a voice input and i will try to add google voice
[14:33] <PreSSion> I think woulkd be fine, I have got money and I will have got full time then summer
[14:34] <PreSSion> I will write in Qt
[14:35] <PreSSion> and kgunn, just the last question, MIR will be use in the future in PC's¿?
[14:37] <kgunn> PreSSion: yes, absolutely, it will be used in our desktop / PC distributions
[14:37] <PreSSion> thanks! good bye
[14:37] <kgunn> PreSSion: you're welcome
=== jono is now known as Guest1478
=== olli__ is now known as olli
[16:26] <fginther> kgunn, is josharenson the right contact for the benchmarking work?
[16:28] <kgunn> fginther: he is!...i think he was able to connect with robotfuel but dunno
[16:28] <kgunn> he might have  more questions
[16:29] <robotfuel> fginther: is there a new way to stop unity8 that you know of?
[16:30] <robotfuel> fginther: stop unity8 as the phablet user used to work, but now I get stop: Unable to connect to Upstart: Empty address ''
[16:31] <fginther> robotfuel, I don't have any specific knowledge of this, try asking in ubuntu-ci-eng
[16:32] <fginther> kgunn, thanks
[16:32] <kgunn> fginther: no thank you!
[16:33] <kgunn> Saviq: ^ any ideas on robotfuel's ?
[16:38] <Saviq> robotfuel, upstart died for you
[16:39] <Saviq> robotfuel, there's a known crash
[16:39] <Saviq> robotfuel, restart lightdm as root
=== chihchun is now known as chihchun_afk
=== chihchun_afk is now known as chihchun
=== om26er_ is now known as om26er