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