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