[06:51] <duflu> camako: I'm kind of hoping we can add more fixes and performance improvements to RTM yet. You can see them targeted for a "0.5.1": https://launchpad.net/mir/+milestone/0.5.1
[06:52] <duflu> (it's the same set as is tagged rtm14)
[06:56] <camako> duflu, sounds good.. Though #1345533 is about hwc which tends to be device specific.
[06:57] <duflu> camako: *shrug* I don't have one of them to test with
[06:57] <camako> duflu, me neither :-)...
[06:59] <camako> duflu, also I wasn't sure about #1316867 since it has to do with DRM and rtm is android...
[06:59] <duflu> camako: Oh, yes. Worth having in a stable branch but not relevant to Android
[06:59] <duflu> Kinda.. It's relevant to all platforms. Just starting with DRM
[07:00] <duflu> But that one in 0.6 in time for utopic is enough
[07:00] <camako> duflu, also it has to do with the fatal_error branch which is causing controversy... :-)
[07:07] <camako> duflu, #1240909 would be nice but would like to see a solution in devel first.. Don't wanna hold up rtm for it... We can always backport...
[07:09] <duflu> camako: Well if you think there will be a 0.5.2 then no problem. Otherwise double buffering offers potentially the biggest performance improvement yet to land, so it's worth trying to get in ASAP
[07:09] <duflu> I mean the biggest improvement in responsiveness
[07:10] <camako> duflu, yeah +1 on the responsiveness!
[07:10] <camako> ... #1343074 has already been committed.
[07:11] <duflu> Because Ubuntu touch is 8-buffered (3 in the client + 3 in the nested server + 2 in the native server). The double branch will get that down to 6-ish
[07:11] <duflu> Minus 1 to calculate best case input lag. It's still not great
[07:12] <duflu> Hmm, could even be more. I'm not familiar with the Android page flipping we use
[07:13] <duflu> Actually, I confused the numbers. Lag is 2 + 2 + 1 = 5 right now.  The double branch gets that down to 1+1+1 = 3
[07:13] <duflu> Almost halved
[07:13] <duflu> Delay between client and screen will be at least 32ms less
[07:14] <camako> It's pretty significant.. No doubt..
[07:14] <duflu> And hopefully there are other unrelated improvements coming soon
[07:16] <duflu> Actually, I think we might be weeks away from out-performing Android on the same hardware
[07:16] <duflu> Just got to tweak some things
[07:17] <camako> duflu, @ releasing 0.5.2 and even beyond, I fully expect that to happen.... until the device receives a final image which is weeks away.
[07:17] <camako> the rtm device that is
[09:08] <alan_g> any more review comments for this? https://code.launchpad.net/~mir-team/mir/cursor-spike-phase-7-name-some-cursors/+merge/225242
[09:32] <alf_> duflu: @double, Could you elaborate on 115+ if (used_buffers > min_buffers() && max_buffers > 1), I am not sure I get the intent.
[09:33] <duflu> alf_: That's when the minimum requirement drops (framedropping turned off). That code pre-dates the same check now present in the framedropping toggle.
[09:33] <duflu> Might be redundant now
[09:33] <duflu> But still good to keep
[09:38] <alf_> duflu: wait, I think I may have completely misunderstood the MP... isn't this MP's goal to change the queue size depending on client demand? Or does it only change the queue when changing between non-framedropping and framedropping?
[09:38] <duflu> alf_: That is now the only indicator of demand
[09:38] <duflu> ... which is pretty new yes
[09:40] <alf_> duflu: so it just switches between a fixed size of 2 buffers for non-framedropping and 3 buffers when allow_framedropping(true) ?
[09:40] <duflu> alf_: Yes. Much simpler than earlier versions
[09:56] <alf_> duflu: Simpler, yes, but is it sufficient? The fixed 2 buffer queue reduces latency, but it also uncoditionally drops all the benefits triple buffering brings (like the ability to deal with frames occasional missing the frame time limit)
[09:57] <duflu> alf_: Yes, it is sufficient in all testing so far. There is an argument to make it configurable sure
[09:57] <duflu> alf_: Forgive me for preparing to go offline soon
[09:59] <alf_> duflu: Enjoy!
[10:25] <alan_g> camako: we've three MPs for 0.5 failing "mysteriously" in CI - is this something you're looking into?
[10:26]  * alan_g hopes to make 0.5 "someone else's problem"
[10:27] <camako> alan_g, yea I saw that... Sure I can look into it.
[10:28] <camako> alan_g, or more like ask fginther who recently prepared the jenkins config for 0.5
[10:30] <alan_g> camako: you can also try cihelp on #ubuntu-ci-eng (which will probably end up at fginther too)
[10:56] <ogra_> did you guys test the latest Mir and sysstem-compositor uploads on manta ? seems it is unbootable ...
[10:56] <ogra_> http://paste.ubuntu.com/7829641/
[10:57] <ogra_> I/hwcomposer( 2071): Using 2560x1600 60Hz resolution for 'fb0' from modes list
[10:57] <ogra_> I/hwcomposer( 2071): unblank ioctl failed (display already unblanked)
[10:57] <ogra_> W/libEGL  ( 2071): eglTerminate() called w/ 1 objects remaining
[10:57] <ogra_> E/libEGL  ( 2071): validate_display:263 error 3001 (EGL_NOT_INITIALIZED)
[13:57] <davmor2> kgunn: you about?  Manta is broken since the landing of 0.5.0 by the look of it.  It gets to the google logo and no further.
[13:58] <kgunn> davmor2: i'm here, hmmm, is that news? i experienced that last week during our testing and i was told that was due to something else
[13:58] <kgunn> davmor2: it was on irc, i think i recall someone saying it had to do with telephony stuff (?)
[14:03] <alf_> kgunn: good to hear it's not just me, I though I had broken the device
[14:05] <davmor2> kgunn: it works fine in 136 pre 0.5.0 and then breaks in 137 http://paste.ubuntu.com/7829641/ and http://davmor2.co.uk/~davmor2/syslog  is the only info I have from it which seems according to ogra_ to point to egl
[14:06] <davmor2> kgunn: I only got back today so hit it testing something else.
[14:06] <davmor2> kgunn: also wouldn't the flo play up too if it was the telephony stack?
[14:06] <ogra_> kgunn, seems hammerhead broke at the same time ... i think they use the same driver
[14:06] <ogra_> (at least thats what rsalveti claimed (the brokeness))
[14:07] <kgunn> ogra_: not the same driver....in fact N7==N4 on driver
[14:07] <rsalveti> not the same driver, but could be broken the same way
[14:07] <ogra_> ok
[14:07] <rsalveti> bug 1345533 for hammerhead
[14:08] <rsalveti> no bots anywhere
[14:08] <ogra_> yeah, they went on a group vacation it seems
[14:08] <ogra_> super special group offer
[14:08] <rsalveti> davmor2: can you check /var/log/lightdm/unity-system-compositor.log
[14:08] <rsalveti> on the broken image
[14:08] <rsalveti> hahah
[14:09] <davmor2> rsalveti: sure give me a few
[14:09] <kgunn> interesting before egl failure in that log i see "I/hwcomposer( 1015): unblank ioctl failed (display already unblanked)"
[14:09] <kgunn> oh...that's just unblanking
[14:09] <kgunn> nvmd
[14:10] <ogra_> the next lines are more worrying
[14:11] <kgunn> ogra_: yeah, but it looks like egl succeeded...then its bailing subsequent
[14:11] <ogra_> right ... but we had no android changes during that time
[14:12] <ogra_> image 136 had an android update ...
[14:12] <ogra_> 137 had the new Mir ...
[14:12] <ogra_> the former image works flawless ... the latter doesnt
[14:13] <rsalveti>  /var/log/lightdm/unity-system-compositor.log will tell any mir specific error
[14:13] <davmor2> right guys back with you now
[14:17] <davmor2> rsalveti, kgunn: http://davmor2.co.uk/~davmor2/unity-system-compositor.log
[14:18] <rsalveti> right, similar but different
[14:18] <rsalveti> a bunch of calls are now triggering an exception in case of errors
[14:18] <rsalveti> in this case it's  display_on
[14:19] <rsalveti> on nexus 5 it was vsync_on
[14:19] <kgunn> camako: ^ you following?
[14:19] <rsalveti> so yeah, indeed mir causing the issue
[14:20] <camako> yeah
[14:20] <camako> kgunn
[14:22] <kdub_> hmm
[14:24] <davmor2> kgunn: if you and your team need info from a broken device just ping me as this manta now no longer turns off it will be available for logs etc if you need any that rsalveti didn't cover :)
[14:25]  * kdub_ can look, seems more important than the optimization stuff i was looking at this morning
[14:25] <kgunn> kdub_: thanks
[14:25] <kdub_> also though, I have to whine that we don't have a nexus 5, and only test the nexus 4 in CI
[14:25] <kdub_> :)
[14:25] <kdub_> so I'll poke around the n10
[14:25] <kgunn> kdub_: i keep forgetting your on CST now :)
[14:26] <kgunn> i was waiting to bother you cali time :)
[14:26] <kgunn> camako: i distinctly recall testing on manta....for mir0.5...did you ?
[14:27] <kgunn> camako: altho...not sure i tested post alan's add
[14:28] <camako> kgunn, not on manta
[14:29] <kdub_> MI is EST, I now get the jump on the texans!
[14:29] <kgunn> kdub_: oh wow...didn't realize that
[14:29] <kgunn> EST
[14:52] <kdub_> the problem is only on startup?
[14:52] <rsalveti> yes
[14:53] <rsalveti> hart to know if it'll happen later on though, as it's not even able to start
[14:53] <kdub_> I have an idea of what's going on
[14:53] <rsalveti> from what I saw in the diff the difference is that now those errors are critical
[14:53] <kdub_> working on confirming
[14:53] <rsalveti> which wasn't the case before
[14:53] <rsalveti> but they were always there
[14:54] <kdub_> right, I think that some restructuring changed it
[14:54] <rsalveti> right
[14:55] <kdub_> does the n4 have the problem?
[14:56] <AlbertA> kdub_: no it works fine here with mir 0.5.0
[14:56] <kdub_> ah, I have a very good idea then
[14:56] <rsalveti> nops
[14:58] <kdub_> bug yet too?
[14:58] <kdub_> if not i'll file one
[14:58] <kdub_> oh 1345533
[15:01] <rsalveti> that's for n5
[15:01] <rsalveti> for manta I'm not sure we have one
[15:01] <kdub_> probably same issue
[15:20] <davmor2> kdub_: n4 and n7 both work fine n10 and n5 seem to be hit by it
[17:12] <greyback> racarr__: hey quick confirmation form you: there's no api for a client to know its position on screen is there?
[17:20] <racarr__> greyback: Nope
[17:20] <greyback> racarr__: thanks
[17:23] <racarr__> np :)
[17:27] <racarr__> lunch
[17:37] <kdub_> davmor2, rsalveti : lp:~mir-team/mir/fix-1345533-0.5 has been checked on the nexus10, and will likely fix the n5 too
[17:38] <kdub_> but I don't think the mir team has a n5
[18:09] <davmor2> kdub_: nor do I over to rsalveti for that I think
[18:10] <kdub_> davmor2, ah, thought you had one, sorry
[18:11] <davmor2> kdub_: I have the n10
[18:18] <rsalveti> kdub_: will check n5 later today
[18:18] <rsalveti> do we have it in a silo or similar already?
[18:19] <rsalveti> just to be easier to grab the packages :-)
[18:20] <rsalveti> kdub_: not sure if that will fix n5 though
[18:20] <rsalveti> as the exception was a different one
[18:21] <rsalveti> or is display_on also triggering the vsync_signal_on?
[18:21] <rsalveti> if so, then yeah
[18:26] <AlbertA> rsalveti: right turn_screen_on() calls hwc->blank(...) and hwc->eventControl(..., HWC_EVENT_VSYNC,...)
[18:27] <rsalveti> great then :-)
[18:38] <davmor2> back to the are there packages available?
[18:43] <davmor2> kdub_: ^
[18:53] <AlbertA> davmor2: no not yet...
[18:53] <AlbertA> camako will probably set up the silo when he comes online
[18:58] <davmor2> AlbertA: ah cool thanks
[20:54] <kdub_> rsalveti, right, the fix should catch/ignore either problem (vsync/blank)
[20:57] <AlbertA> racarr__: ping
[20:58] <racarr__> AlbertA: pong
[20:59] <AlbertA> racarr__: is there a way to know if an input event has been handled on the nested case?
[20:59] <AlbertA> basically if I install a eventfilter
[20:59] <AlbertA> in the server
[20:59] <AlbertA> can a client in a nested scenario consume the event so that my filter doesn't run?
[21:00] <racarr__> sorry not quite parsing
[21:00] <racarr__> whhere is the filter? where is the client?
[21:00] <racarr__> (host/nested)
[21:00] <AlbertA> so imagine unity system compositor
[21:00] <racarr__> ok
[21:00] <AlbertA> installs an event filter
[21:00] <AlbertA> i.e. an append to the composite_filter
[21:01] <racarr__> ok that will be like the first thing ever
[21:01] <racarr__> to see events basically
[21:01] <AlbertA> ok
[21:01] <racarr__> before shell
[21:01] <racarr__> etc
[21:01] <AlbertA> so it's there a way for me to know if the a client like unity8, consumed a key event?
[21:01] <racarr__> except...lol I wonder if
[21:01] <racarr__> unity8
[21:01] <racarr__> input filters probably dont work in unity8 right now
[21:02] <racarr__> but not an urgent problem
[21:02] <racarr__> um no.
[21:02] <AlbertA> ok
[21:02] <racarr__> currently all events are handled
[21:02] <racarr__> there is some infrastructure for handling/not handling events
[21:02] <racarr__> but not on the client side
[21:02] <racarr__> there is also some design documentation that...we should one day have an accept/reject model
[21:02] <racarr__> do we need it?
[21:03] <AlbertA> well
[21:03] <AlbertA> it's for a minor thing
[21:03] <AlbertA> there's this power dialog
[21:04] <AlbertA> that shows up if you hold up the power key for 2s
[21:04] <AlbertA> but USC has policies
[21:04] <AlbertA> to shutoff display on power key up (after a power key down)
[21:04] <AlbertA> so we had to add hacks to ignore that if hits the 2s...etc
[21:04] <AlbertA> so that USC does not shut off display
[21:04] <racarr__> ah
[21:04] <AlbertA> and instead unity8 can show the power off dialog
[21:05] <racarr__> yeah
[21:05] <AlbertA> basically I would want an ack or something
[21:05] <AlbertA> that unity8 consumed power key up
[21:26] <racarr__> robert_ancell: wanted to let you know header with mir cursor names landed so you should be able to add gtk cursor support
[21:26] <racarr__> when...the fancy strikes you :)
[21:26] <robert_ancell> racarr__, nice. Are there plans for custom cursors too?
[22:06] <racarr__> robert_ancell: Yeah. it just needs protocol + add mir_cursor_configuration_from_rgba_pixels_function_names_are_so_long_:(
[22:06] <racarr__> etc
[22:07] <racarr__> next time I get bored + don't feel bad doing something that has no upcoming deadline lol