| === chihchun_afk is now known as chihchun | ||
| === duflu_ is now known as duflu | ||
| === chihchun is now known as chihchun_afk | ||
| === chihchun_afk is now known as chihchun | ||
| RAOF | Bah! | 07:46 |
|---|---|---|
| RAOF | ThreadSanitizer! | 07:46 |
| RAOF | Plz be with the more reproducibleness. | 07:46 |
| === marcusto_ is now known as marcustomlinson | ||
| anpok | hi RAOF | 07:56 |
| RAOF | anpok: Yo! | 07:56 |
| RAOF | racarr: Oh, hey! I might need a little tutoring in what MirPointerButtons mean at some point :) | 08:19 |
| duflu | RAOF: Is it non-obvious? | 08:29 |
| duflu | ... | 08:29 |
| * duflu looks | 08:29 | |
| duflu | RAOF: Oh it's a set of MirPointerButton values :) | 08:30 |
| RAOF | Yeah. | 08:30 |
| * duflu likes that plural naming pattery | 08:31 | |
| RAOF | The interesting question is: what does membership of the set mean? :) | 08:31 |
| duflu | pattern | 08:31 |
| duflu | RAOF: It means it exists in some universe and may mean up, down, or colour depending on the variable name... ? :) | 08:31 |
| duflu | So it should be obvious like "MirPointerButtons buttons_down" | 08:32 |
| anpok | Ah, pressed vs changed during that event? pick the first | 08:32 |
| RAOF | Ah! But is that the set of buttons that are *now* down, or the set of buttons that changed for this event? | 08:32 |
| RAOF | anpok has the question right :) | 08:33 |
| duflu | RAOF: Usually in toolkit design yes. Usually the set of buttons down | 08:33 |
| duflu | Although other information is also handy | 08:33 |
| anpok | i believe the first.. at least i know a few places of code that assume that.. | 08:33 |
| RAOF | That was my understanding also. | 08:33 |
| alan_g | +1 | 08:33 |
| duflu | It's not very friendly for people who use mice upside down, but we care less about them | 08:34 |
| alan_g | You have reason to question that assumption? | 08:34 |
| RAOF | I think I'm getting confused because there's no guarantee that a pointer down event corresponds to *one* button being pressed. | 08:34 |
| duflu | RAOF: If you want one then you would get a MirPointerButton (singular) I guess | 08:34 |
| RAOF | I think my std::logic_error guard on the difference in state between the previous MirPointerButtons and the current MirPointerButtons not containing exactly one difference is being hit :) | 08:35 |
| duflu | Ah. You need MirPointerChord then | 08:36 |
| duflu | Which sounds like a joke but I have seen it in APIs before | 08:39 |
| alan_g | anpok: are we still trying to land 14.0? | 08:49 |
| anpok | there is no 0.14.0 in wily-proposed | 08:49 |
| anpok | s/no/now | 08:50 |
| alan_g | But not V+O? | 08:50 |
| anpok | the actual process was delayed because we waited for the deprecation cleanup in qtubuntu and platform-api to land before that | 08:50 |
| alan_g | Sure | 08:50 |
| anpok | dual landing did not work because we had to land packages not handled through mps... xorg-server gtk glmark.. | 08:51 |
| anpok | and I was told it would not work.. | 08:51 |
| duflu | alan_g: AFAICT the client API bump slowed things down more than usual | 08:51 |
| alan_g | duflu: that was to be expected. | 08:52 |
| * duflu wonders what the package count is that depends on libmirclient | 08:52 | |
| anpok | then on thu/fri there was a boottest failure.. because of mir landing | 08:52 |
| anpok | this uncovered one mistake in the spread sheet configuration - I forgot to include an url-dispatcher MP that I prepared | 08:53 |
| anpok | but still it is unclear why that boottest failure was related to that | 08:53 |
| alan_g | It sounds like we should schedule a retrospective on the landing. | 08:53 |
| anpok | yip | 08:53 |
| duflu | RAOF: Come to think of it, it sounds like you need the full state "MirPointerButtons presently_down, changed_since_last_time" | 08:55 |
| anpok | ah yes and we still need a libsdl bump which is currently in the works... | 08:55 |
| RAOF | duflu: Nah, I just need changed_since_last_time. | 08:56 |
| duflu | RAOF: So long as that's not the only thing you ever see :) | 08:56 |
| duflu | You wouldn't know up from down | 08:56 |
| duflu | Fortunately with have bit operations | 08:57 |
| RAOF | That's why we have mir_pointer_action_button_down/up | 08:57 |
| * duflu wonders if we can have the mouse wheel back as two buttons like other APIs do (and the hardware does) | 08:58 | |
| duflu | alf_: What approach are you using to test MPs to lp:mir with the dash? | 09:01 |
| * duflu wonders if it's faster than his | 09:01 | |
| anpok | alan_g: I also like the idea of a retrospective, because that implies that it will end some day | 09:01 |
| duflu | Heh | 09:01 |
| alan_g | Agreed | 09:02 |
| duflu | greyback: Silly question (not a trick): Is it easy to run unity8-dash in a Mir demo server? | 09:04 |
| anpok | nope | 09:05 |
| anpok | you need quite a few environment variables configured.. | 09:05 |
| duflu | -easy +possible | 09:05 |
| anpok | or it depends.. it might not work properly - I havent tried though.. | 09:05 |
| * duflu now realises it was easy for alf_ to backport changes to his phone because he already had 0.14.0 on it | 09:06 | |
| anpok | I tried unity8 a few times.. and always forgot something | 09:06 |
| anpok | yes | 09:06 |
| anpok | i mean .. you could still grab silo4 I guess. | 09:07 |
| anpok | or hmm run kvm with ubuntu-desktop-next on wily-proposed | 09:07 |
| anpok | ah you need display off | 09:07 |
| greyback | duflu: it's possible, I managed it a few times. You need a dbus server running and to set a couple of env vars, and to launch a few scope processes to make it useful | 09:12 |
| duflu | It's fine. I already know how to do this testing. Just wishing for a simpler way | 09:15 |
| alf_ | duflu: What I do is (in a script, which I can share if you like): stop lightdm, cross compile and copy to the phone, start lightdm | 09:16 |
| === vesar is now known as vesar_lunch | ||
| alf_ | duflu: For 0.14 vs 0.13 it is just a matter of using the silo vs not using it | 09:17 |
| duflu | alf_: Yeah that's the trick. You need a 0.14 phone so as to be mostly compatible with lp:mir | 09:17 |
| duflu | alf_: Aha! I think I can see what you did. You were flinging the dash instead of keeping your finger down, right? | 10:29 |
| duflu | That is indeed worse | 10:29 |
| duflu | But something I never tried | 10:29 |
| alf_ | duflu: right | 10:31 |
| duflu | alf_: Good to know. | 10:32 |
| duflu | Annoyingly lag with finger held down is still much lower with dynamic double buffering. One thing is worse and one is better :S | 10:32 |
| duflu | Oooh.. actually I see the same thing in Mir demos. The GPU enters low power mode if you're not touching it. That might be the problem | 10:33 |
| duflu | Anyone know a reliable way to keep an Android GPU in full power mode without touching the screen? | 10:37 |
| * duflu tries spinning the CPU | 10:37 | |
| anpok | change username to carmack? | 10:37 |
| duflu | I thought John recommended against it... | 10:38 |
| duflu | But this isn't all the time. Just sporadically | 10:39 |
| duflu | greyback: Possibly a more feasible question: During inertial scrolling of the dash, what's the animation frame time? | 10:40 |
| greyback | duflu: that animation should be ticking at the vsync rate | 10:40 |
| duflu | greyback: Sounds reasonable. Can I confirm it anywhere? | 10:41 |
| greyback | duflu: hmm, nothing obvious comes to mind without reading the renderer code | 10:42 |
| duflu | greyback: Just wondering because the shell's indicator pull-down thing doesn't have the same smoothness issues as the dash | 10:42 |
| duflu | Seems like it's done better | 10:43 |
| duflu | But also it has fewer servers to pass through | 10:43 |
| greyback | duflu: it's all the same animation framework | 10:43 |
| greyback | but I agree, there's something up | 10:43 |
| greyback | it's been this way for a year, I've never cracked it | 10:43 |
| duflu | greyback: It could also be that the number of hops from kernel to client code is double for the dash vs shell elements | 10:44 |
| duflu | I've seen nesting creating such bugs with Mir's demos too | 10:44 |
| duflu | We need to work harder to keep the extra layer smooth | 10:45 |
| greyback | duflu: yeah. | 10:45 |
| greyback | that's a possibility | 10:45 |
| greyback | but I suspect something with qt too, or as you maybe noted above: could the gpu be clocking down if finger is not on screen | 10:46 |
| anpok | alan_g: btw the boottest failed because it only upgrades mir packages and then tries to reboot.. so we end up attempting to launch unity-system-compositor with mircommon4 and mircommon5 and libmirplatform7 and libmirplatform8 simultaneously | 10:47 |
| greyback | duflu: but that would be a lousy experience for games. maybe it's configurable? | 10:48 |
| duflu | greyback: I know clock-down happens because I can see it with a simple triangle (and touching it helps) | 10:48 |
| anpok | because the upgrade replaces mir-platform-graphics-drivers-android | 10:48 |
| anpok | +2 | 10:48 |
| duflu | greyback: GPU driver authors try to tell you to let them handle it (sleeping and power states). But they also mess it up (as Intel has on desktop too) | 10:49 |
| anpok | duflu: maybe that just increases the cpu time of the client | 10:49 |
| anpok | wakes it more frequently | 10:49 |
| duflu | Yeah good point | 10:50 |
| anpok | enforces additional redraws? | 10:50 |
| greyback | duflu: there must be a knob somewhere, surely | 10:50 |
| anpok | or simply just affects the animation calc in a bad way | 10:50 |
| duflu | greyback: It's OK... I can see the numbers and have one idea in mind to try and fix Mir first... | 10:50 |
| alan_g | anpok: we need better ways to validate deployment not just fix up one scenario at a time | 10:50 |
| duflu | [1437388267.960199] perf: Scopes: 37.69 FPS, render time 17.79ms, buffer lag 34.87ms (2 buffers) | 10:50 |
| duflu | [1437388268.985012] perf: Scopes: 30.27 FPS, render time 25.22ms, buffer lag 40.29ms (2 buffers) | 10:50 |
| duflu | [1437388269.993894] perf: Scopes: 31.74 FPS, render time 23.42ms, buffer lag 40.46ms (2 buffers) | 10:50 |
| duflu | [1437388271.002470] perf: Scopes: 36.70 FPS, render time 19.13ms, buffer lag 35.59ms (2 buffers) | 10:50 |
| duflu | [1437388272.021942] perf: Scopes: 44.16 FPS, render time 15.96ms, buffer lag 29.12ms (2 buffers) | 10:50 |
| duflu | [1437388273.043734] perf: Scopes: 40.15 FPS, render time 17.85ms, buffer lag 31.90ms (2 buffers) | 10:50 |
| duflu | We're missing by a few milliseconds each time | 10:51 |
| duflu | Whereas with triple buffers it stays around 14ms and hits the frame deadline more | 10:51 |
| anpok | alan_g: i now wonder if we expect that to work at all? | 10:51 |
| alan_g | anpok: if we don't have an automated test for it... | 10:52 |
| duflu | And that will be an adventure for Tuesday | 10:54 |
| greyback | duflu: /sys/devices/platform/kgsl-3d0.0/kgsl/kgsl-3d0 on my nexus7 gives GPU clock info | 10:56 |
| greyback | I can see evidence of it clocking up when something animating anyway | 10:56 |
| duflu | greyback: Cool. I only have the old N7... do we still support the new one? | 10:57 |
| greyback | interestingly it's not clocking down | 10:57 |
| greyback | duflu: I think it's the new one I'm using, which is supported | 10:57 |
| greyback | N4 has same chip tho I think | 10:57 |
| * duflu jumps for joy at the lack of Tegra-ness | 10:57 | |
| duflu | greyback: Some simple but interesting figures to ponder... https://bugs.launchpad.net/mir/+bug/1476201 | 11:03 |
| ubot5 | Ubuntu bug 1476201 in Mir "Dynamic double buffering fails to detect inertial dash scrolling as slow; and stutters" [High,In progress] | 11:03 |
| greyback | duflu: certainly is interesting. With that /sys path I pasted above, you can force the gpu into its highest clock, might help isolate if it is a GPU thing | 11:05 |
| greyback | duflu: to me this motivates a mir test client which renders at 16ms | 11:06 |
| duflu | greyback: We already have some. Just not tested in tandem with queue scaling it seems | 11:07 |
| greyback | duflu: do we? Which one? | 11:07 |
| duflu | Actually we do have that too. It's just not enough | 11:07 |
| duflu | greyback: slow_client_framerate_matches_compositor | 11:08 |
| duflu | And others related | 11:08 |
| duflu | But that test only expects and tests 3+ buffers | 11:09 |
| greyback | duflu: ah ok, I was hoping it in mir-demos | 11:09 |
| duflu | greyback: Using mir-demos you can kind of... I use env MIR_CLIENT_PERF_REPORT=log mir_demo_client_flicker | 11:09 |
| duflu | And then watch the render time. Keep making the window bigger till the render time tips over the edge | 11:10 |
| greyback | that's an idea, will try it next time | 11:10 |
| alf_ | anpok: kgunn: hmm, I forgot that we shouldn't push to USC trunk until it is merged into usc/ubuntu, and approved a few MPs. Will that cause issues? | 11:58 |
| === alan_g is now known as alan_g|lunch | ||
| anpok | alf_: hum we might get away without a usc rebuild to resolve the remaining 0.14 issues | 12:14 |
| rakesh__ | Hi all | 12:50 |
| kenvandine | greyback_, I'm working on the mouse and touchpad panel for system-settings | 13:07 |
| kenvandine | greyback_, we need API's for those settings, I'm sure it's pretty similar to what jgdx was asking about for display settings | 13:08 |
| greyback_ | kenvandine: hey. We have zero apis ready for that | 13:08 |
| kenvandine | i figured :) | 13:08 |
| kenvandine | https://wiki.ubuntu.com/MouseAndTouchpad | 13:08 |
| kenvandine | i just wanted to make sure it' | 13:08 |
| kenvandine | s planned | 13:09 |
| greyback_ | it's on a list somewhere :) | 13:09 |
| greyback_ | lemme make trello cards to track it better | 13:09 |
| kenvandine | greyback_, can you make sure the plans match our spec? | 13:09 |
| kenvandine | greyback_, thanks! | 13:09 |
| kenvandine | greyback_, can you give me the link to your trello board? | 13:11 |
| greyback_ | kenvandine: https://trello.com/c/ceklQc5o/177-add-apis-for-mouse-trackpad-panel-of-system-settings | 13:11 |
| kenvandine | greyback_, can you add me? | 13:12 |
| greyback_ | kenvandine: ah sorry, done | 13:12 |
| kenvandine | thx! | 13:12 |
| greyback_ | feel free to add more detail to the card | 13:12 |
| === alan_g is now known as alan_g_ | ||
| kgunn | anpok: so catching up, i read backlog, what's the current thinking ? | 13:52 |
| alan_g | greyback_: @https://code.launchpad.net/~alan-griffiths/unity-system-compositor/add-display-config-option/+merge/262110 - updated | 14:13 |
| greyback_ | alan_g: great thanks. | 14:14 |
| anpok | kgunn: the problem of boottest with mir seems to only affect partial upgrades | 14:19 |
| anpok | which is what boottest really tests.. | 14:20 |
| anpok | kgunn: so I currently look into which mir libraries collide in a breaking way.. then we should probably make sure that they do not get loaded simultaneously | 14:22 |
| === chihchun is now known as chihchun_afk | ||
| === tvoss is now known as tvoss|afk | ||
| kgunn | anpok: i suppose the question is, did we think that we could support simultaneous versions ? or did we know/expect this would be an issue ? | 14:29 |
| kgunn | or did we just not realize this is how proposed migration tests this ? | 14:30 |
| seb128 | kgunn, well, proposed migration pointed a real issue | 14:31 |
| seb128 | not a common usecase one, but still real | 14:31 |
| seb128 | doing partial upgrades can result in a non starting u-s-c/unity8 | 14:32 |
| seb128 | I bricked my device this morning by using apt to update mir without updating u-s-c | 14:32 |
| kgunn | seb128: yikes | 14:32 |
| kgunn | so we missed this | 14:33 |
| anpok | kgunn: I think this not yet meant to work yet. And I guess we just missed the link dependency issue we ran into | 14:38 |
| anpok | i mean we havent done anything yet to load a server platform library from a diferent server version that potentially comes with its own set of mirplatform/common libs.. | 14:39 |
| kgunn | anpok: got it, and i think that even makes sense (server specific mirplatforms/common ver) | 14:41 |
| kgunn | so we just need a protection in place to avoid the partial upgrade | 14:42 |
| === dandrader is now known as dandrader|afk | ||
| racarr | Good morning | 15:48 |
| === dandrader|afk is now known as dandrader | ||
| seb128 | kgunn, anpok, so what's next? do you want to try to hack-around-unblock the update? or let it stay in proposed until you figure out & land some mir changes? | 16:11 |
| kgunn | camako: ^ | 16:11 |
| camako | seb128, kgunn, This will take rebuilding mir, unfortunately. anpok will be updating the symbols map for platform lib. | 16:25 |
| === mibofra is now known as Guest28602 | ||
| kgunn | camako: so will we need to retest ? or is this just about build order ? | 16:49 |
| camako | kgunn, not a full test. Just sanity to make sure what was failing doesn't. | 16:49 |
| camako | this is not a code change | 16:50 |
| camako | just linker symbols | 16:50 |
| kgunn | camako: ok, do we need to test a partial update doesn't fail ? | 16:50 |
| kgunn | or will that happen with boottest anyhow | 16:51 |
| camako | kgunn, not sure... anpok? | 16:53 |
| anpok | yes .. thats what I will test | 16:54 |
| kgunn | thanks | 16:54 |
| === alan_g is now known as alan_g|EOD | ||
| === dandrader is now known as dandrader|afk | ||
| === dandrader|afk is now known as dandrader | ||
| racarr | Lunch! | 18:44 |
| === mibofra_ is now known as mibofra | ||
| popey | bschaefer: kgunn I'm trying to run love2d on my nexus 7 / krillin / arale, and it seems to segfault in setMode (so I don't know if this is an SDL or Mir issue). should I file a bug or throw a click package at someone to look at? -> http://people.canonical.com/~alan/love2d.popey_0.17_armhf.click (it just tries to set a gl context full screen and segfaults when doing this) | 19:19 |
| bschaefer | hmm almost sounds like SDL, possibly (if the size if incorrect that'll be an issue. ie. the size of the window requested vs the size of the device) | 19:21 |
| bschaefer | but i should be checking an issue like that and printing an error (but thats to a log that isn't printed) | 19:21 |
| bschaefer | popey, also N7 works with unity8? Last time i tried touch didnt work on that device and unity8 crashed :) | 19:22 |
| bschaefer | this was like a year ago | 19:22 |
| popey | nexus 7 2013 | 19:22 |
| * bschaefer doesnt remember which n7 he has | 19:23 | |
| bschaefer | mako? | 19:23 |
| bschaefer | or something | 19:23 |
| popey | flo | 19:23 |
| popey | mako = nexus 4 | 19:23 |
| bschaefer | o dang | 19:23 |
| popey | grouper = nexus 7 (2012) | 19:23 |
| bschaefer | ooo yeah i have a 2012 one | 19:23 |
| popey | ok | 19:23 |
| bschaefer | shoots so i dont think i can test this out | 19:23 |
| popey | well I am mostly testing on arale actually | 19:24 |
| bschaefer | popey, is it reproduce able on desktop? | 19:24 |
| popey | am debugging with the love2d developer who is adding stuff to the game file so we can get more info for you | 19:24 |
| popey | no | 19:24 |
| popey | I'll get back to you when I have more info, thanks | 19:24 |
| bschaefer | popey, that would be nice, getting the SDL_LogError() | 19:24 |
| bschaefer | would be good | 19:24 |
| bschaefer | err let me double check that function | 19:24 |
| bschaefer | popey, SDL_error.h:42:extern DECLSPEC const char *SDLCALL SDL_GetError(void); | 19:25 |
| bschaefer | but for love2d... i think it uses | 19:25 |
| bschaefer | some other wrapper for SDL2 | 19:25 |
| * bschaefer looks up love2d | 19:25 | |
| bschaefer | o nm it looks like its cpp | 19:26 |
| bschaefer | popey, yeah i would check SDL_GetError() as thats where any error that is caught will be printed to | 19:26 |
| bschaefer | popey, also what version of mir are you running? | 19:27 |
| popey | uh | 19:27 |
| bschaefer | 0.13? (as SDL2 isn't 100% working on that atm | 19:27 |
| bschaefer | ) | 19:27 |
| popey | yes, 0.13 | 19:27 |
| popey | okay | 19:27 |
| bschaefer | yeah theres some ABI breakage | 19:27 |
| bschaefer | popey, im actually making a branch atm :) | 19:27 |
| popey | the fact I have love2d launching at all was some feat :) | 19:27 |
| bschaefer | well moving SDL to 0.14 | 19:28 |
| bschaefer | popey, i bet, anytime i try a new game out on SDL2 its usually a fight haha | 19:28 |
| popey | :) | 19:28 |
| popey | fun though :) | 19:28 |
| bschaefer | very! I like the part when the pixels start changing colors :) | 19:28 |
| bschaefer | popey, ill try to get this branch done in the next few days and put a ppa up | 19:29 |
| popey | sweet, thanks | 19:29 |
| bschaefer | np! thanks of testing all these new apps/devices out! | 19:29 |
| popey | np :) | 19:29 |
| mcphail | popey: where did you get the SDL library? The one in the repos segfaults in SDL_init | 19:29 |
| popey | uhhh | 19:30 |
| bschaefer | yeah repos should seg fault on mir 0.13 | 19:30 |
| popey | good question | 19:30 |
| bschaefer | from an ABI break | 19:30 |
| popey | I can't remember where I got it | 19:30 |
| popey | -rw-r--r-- 1 alan alan 2397348 May 22 10:46 libSDL2-2.0.so.0.4.0 | 19:30 |
| popey | is that one of your builds mcphail :) | 19:30 |
| mcphail | popey: let me find one... :) | 19:30 |
| popey | http://termbin.com/s0si | 19:33 |
| popey | oops | 19:33 |
| popey | wrong channel | 19:33 |
| popey | mcphail: which app should I steal them from? | 19:34 |
| popey | :) | 19:34 |
| popey | neverball seems like a good bet :) | 19:35 |
| mcphail | popey: d1948f790f196bc19a141c43cd453b67 libSDL2-2.0.so.0.4.0 -- probably mine :) | 19:38 |
| popey | d1948f790f196bc19a141c43cd453b67 libSDL2-2.0.so.0.4.0 | 19:39 |
| popey | yup | 19:39 |
| mcphail | have you managed to get access to the backtrace in gdb? | 19:42 |
| popey | mcphail: yeah, but no symbols so it's not much use | 19:57 |
| racarr | </lunch> tidied my branches and did some reviews this morning. finishing mir on X review now | 19:58 |
| racarr | then probably back in to input transport rework | 19:58 |
| mcphail | popey: if I get a chance, I'll write something up about importing symbols for gdb. Makes life a lot easier | 20:01 |
| bschaefer | you can always compile it with -g3 | 20:15 |
| mcphail | bschaefer: I mean something more like this: https://youtu.be/xTmAknUbpB0?t=32m16s where you're dealing with all those libs on the phone which don't have symbols embedded. Saves having to apt-get all the debug symbols and breaking the system image | 20:55 |
| bschaefer | mcphail, o thats interesting, thanks! (Ill have to watch this now :) | 20:57 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!