| === chihchun_afk is now known as chihchun | ||
| 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:51 |
|---|---|---|
| duflu | (it's the same set as is tagged rtm14) | 06:52 |
| camako | duflu, sounds good.. Though #1345533 is about hwc which tends to be device specific. | 06:56 |
| duflu | camako: *shrug* I don't have one of them to test with | 06:57 |
| camako | duflu, me neither :-)... | 06:57 |
| 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 | 06:59 |
| 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:00 |
| 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:07 |
| 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:09 |
| camako | duflu, yeah +1 on the responsiveness! | 07:10 |
| camako | ... #1343074 has already been committed. | 07:10 |
| 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:11 |
| duflu | Hmm, could even be more. I'm not familiar with the Android page flipping we use | 07:12 |
| 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:13 |
| camako | It's pretty significant.. No doubt.. | 07:14 |
| duflu | And hopefully there are other unrelated improvements coming soon | 07:14 |
| 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:16 |
| 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 | 07:17 |
| === renato is now known as Guest23306 | ||
| 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:08 |
| 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:32 |
| 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:33 |
| 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:38 |
| 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:40 |
| 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:56 |
| 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:57 |
| alf_ | duflu: Enjoy! | 09:59 |
| alan_g | camako: we've three MPs for 0.5 failing "mysteriously" in CI - is this something you're looking into? | 10:25 |
| * alan_g hopes to make 0.5 "someone else's problem" | 10:26 | |
| camako | alan_g, yea I saw that... Sure I can look into it. | 10:27 |
| camako | alan_g, or more like ask fginther who recently prepared the jenkins config for 0.5 | 10:28 |
| alan_g | camako: you can also try cihelp on #ubuntu-ci-eng (which will probably end up at fginther too) | 10:30 |
| 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:56 |
| 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) | 10: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:57 |
| 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 (?) | 13:58 |
| alf_ | kgunn: good to hear it's not just me, I though I had broken the device | 14:03 |
| 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:05 |
| 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:06 |
| 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:07 |
| 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:08 |
| 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:09 |
| ogra_ | the next lines are more worrying | 14:10 |
| 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:11 |
| 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:12 |
| rsalveti | /var/log/lightdm/unity-system-compositor.log will tell any mir specific error | 14:13 |
| davmor2 | right guys back with you now | 14:13 |
| davmor2 | rsalveti, kgunn: http://davmor2.co.uk/~davmor2/unity-system-compositor.log | 14:17 |
| 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:18 |
| 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:19 |
| camako | yeah | 14:20 |
| camako | kgunn | 14:20 |
| kdub_ | hmm | 14:22 |
| 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:24 |
| * 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:25 |
| 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:26 |
| kgunn | camako: altho...not sure i tested post alan's add | 14:27 |
| camako | kgunn, not on manta | 14:28 |
| 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:29 |
| === dandrader is now known as dandrader|afk | ||
| === greyback is now known as greyback|away | ||
| kdub_ | the problem is only on startup? | 14:52 |
| rsalveti | yes | 14:52 |
| 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:53 |
| kdub_ | right, I think that some restructuring changed it | 14:54 |
| rsalveti | right | 14:54 |
| kdub_ | does the n4 have the problem? | 14:55 |
| 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:56 |
| kdub_ | bug yet too? | 14:58 |
| kdub_ | if not i'll file one | 14:58 |
| kdub_ | oh 1345533 | 14:58 |
| rsalveti | that's for n5 | 15:01 |
| rsalveti | for manta I'm not sure we have one | 15:01 |
| kdub_ | probably same issue | 15:01 |
| === dandrader|afk is now known as dandrader | ||
| === greyback|away is now known as greyback | ||
| davmor2 | kdub_: n4 and n7 both work fine n10 and n5 seem to be hit by it | 15:20 |
| === 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 | ||
| greyback | racarr__: hey quick confirmation form you: there's no api for a client to know its position on screen is there? | 17:12 |
| racarr__ | greyback: Nope | 17:20 |
| greyback | racarr__: thanks | 17:20 |
| racarr__ | np :) | 17:23 |
| racarr__ | lunch | 17:27 |
| === dandrader|lunch is now known as dandrader | ||
| 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:37 |
| kdub_ | but I don't think the mir team has a n5 | 17:38 |
| davmor2 | kdub_: nor do I over to rsalveti for that I think | 18:09 |
| kdub_ | davmor2, ah, thought you had one, sorry | 18:10 |
| davmor2 | kdub_: I have the n10 | 18:11 |
| rsalveti | kdub_: will check n5 later today | 18:18 |
| rsalveti | do we have it in a silo or similar already? | 18:18 |
| rsalveti | just to be easier to grab the packages :-) | 18:19 |
| rsalveti | kdub_: not sure if that will fix n5 though | 18:20 |
| rsalveti | as the exception was a different one | 18:20 |
| rsalveti | or is display_on also triggering the vsync_signal_on? | 18:21 |
| rsalveti | if so, then yeah | 18:21 |
| AlbertA | rsalveti: right turn_screen_on() calls hwc->blank(...) and hwc->eventControl(..., HWC_EVENT_VSYNC,...) | 18:26 |
| rsalveti | great then :-) | 18:27 |
| davmor2 | back to the are there packages available? | 18:38 |
| davmor2 | kdub_: ^ | 18:43 |
| AlbertA | davmor2: no not yet... | 18:53 |
| AlbertA | camako will probably set up the silo when he comes online | 18:53 |
| davmor2 | AlbertA: ah cool thanks | 18:58 |
| kdub_ | rsalveti, right, the fix should catch/ignore either problem (vsync/blank) | 20:54 |
| AlbertA | racarr__: ping | 20:57 |
| racarr__ | AlbertA: pong | 20:58 |
| 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? | 20:59 |
| 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:00 |
| 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:01 |
| 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:02 |
| AlbertA | well | 21:03 |
| AlbertA | it's for a minor thing | 21:03 |
| AlbertA | there's this power dialog | 21:03 |
| 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:04 |
| racarr__ | yeah | 21:05 |
| AlbertA | basically I would want an ack or something | 21:05 |
| AlbertA | that unity8 consumed power key up | 21:05 |
| 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? | 21:26 |
| 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:06 |
| racarr__ | next time I get bored + don't feel bad doing something that has no upcoming deadline lol | 22:07 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!