[07:46] <RAOF> Bah!
[07:46] <RAOF> ThreadSanitizer!
[07:46] <RAOF> Plz be with the more reproducibleness.
[07:56] <anpok> hi RAOF
[07:56] <RAOF> anpok: Yo!
[08:19] <RAOF> racarr: Oh, hey! I might need a little tutoring in what MirPointerButtons mean at some point :)
[08:29] <duflu> RAOF: Is it non-obvious?
[08:29] <duflu> ...
[08:29]  * duflu looks
[08:30] <duflu> RAOF: Oh it's a set of MirPointerButton values :)
[08:30] <RAOF> Yeah.
[08:31]  * 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:32] <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:33] <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:34] <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:35] <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:36] <duflu> Ah. You need MirPointerChord then
[08:39] <duflu> Which sounds like a joke but I have seen it in APIs before
[08:49] <alan_g> anpok: are we still trying to land 14.0?
[08:49] <anpok> there is no 0.14.0 in wily-proposed
[08:50] <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:51] <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:52] <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:53] <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:55] <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:56] <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:57] <duflu> Fortunately with have bit operations
[08:57] <RAOF> 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] <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:02] <alan_g> Agreed
[09:04] <duflu> greyback: Silly question (not a trick): Is it easy to run unity8-dash in a Mir demo server?
[09:05] <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: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] <anpok> I tried unity8 a few times.. and always forgot something
[09:06] <anpok> yes
[09:07] <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:12] <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:15] <duflu> It's fine. I already know how to do this testing. Just wishing for a simpler way
[09:16] <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:17] <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
[10:29] <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:31] <alf_> duflu: right
[10:32] <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:33] <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:37] <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:38] <duflu> I thought John recommended against it...
[10:39] <duflu> But this isn't all the time. Just sporadically
[10:40] <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:41] <duflu> greyback: Sounds reasonable. Can I confirm it anywhere?
[10:42] <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:43] <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:44] <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:45] <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:46] <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:47] <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:48] <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:49] <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:50] <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:51] <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:52] <alan_g> anpok: if we don't have an automated test for it...
[10:54] <duflu> And that will be an adventure for Tuesday
[10:56] <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:57] <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
[11:03] <duflu> greyback: Some simple but interesting figures to ponder... https://bugs.launchpad.net/mir/+bug/1476201
[11:05] <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:06] <greyback> duflu: to me this motivates a mir test client which renders at 16ms
[11:07] <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:08] <duflu> greyback: slow_client_framerate_matches_compositor
[11:08] <duflu> And others related
[11:09] <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:10] <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:58] <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?
[12:14] <anpok> alf_: hum we might get away without a usc rebuild to resolve the remaining 0.14 issues
[12:50] <rakesh__> Hi all
[13:07] <kenvandine> greyback_, I'm working on the mouse and touchpad panel for system-settings
[13:08] <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:09] <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:11] <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:12] <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:52] <kgunn> anpok: so catching up, i read backlog, what's the current thinking ?
[14:13] <alan_g> greyback_: @https://code.launchpad.net/~alan-griffiths/unity-system-compositor/add-display-config-option/+merge/262110 - updated
[14:14] <greyback_> alan_g: great thanks.
[14:19] <anpok> kgunn: the problem of boottest with mir seems to only affect partial upgrades
[14:20] <anpok> which is what boottest really tests..
[14:22] <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:29] <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:30] <kgunn> or did we just not realize this is how proposed migration tests this ?
[14:31] <seb128> kgunn, well, proposed migration pointed a real issue
[14:31] <seb128> not a common usecase one, but still real
[14:32] <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:33] <kgunn> so we missed this
[14:38] <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:39] <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:41] <kgunn> anpok: got it, and i think that even makes sense (server specific mirplatforms/common ver)
[14:42] <kgunn> so we just need a protection in place to avoid the partial upgrade
[15:48] <racarr> Good morning
[16:11] <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:25] <camako> seb128, kgunn, This will take rebuilding mir, unfortunately. anpok will be updating the symbols map for platform lib.
[16:49] <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:50] <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:51] <kgunn> or will that happen with boottest anyhow
[16:53] <camako> kgunn, not sure... anpok?
[16:54] <anpok> yes .. thats what I will test
[16:54] <kgunn> thanks
[18:44] <racarr> Lunch!
[19:19] <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:21] <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:22] <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:23]  * 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:24] <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:25] <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:26] <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:27] <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:28] <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:29] <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:30] <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:33] <popey> http://termbin.com/s0si
[19:33] <popey> oops
[19:33] <popey> wrong channel
[19:34] <popey> mcphail: which app should I steal them from?
[19:34] <popey> :)
[19:35] <popey> neverball seems like a good bet :)
[19:38] <mcphail> popey: d1948f790f196bc19a141c43cd453b67  libSDL2-2.0.so.0.4.0 -- probably mine :)
[19:39] <popey> d1948f790f196bc19a141c43cd453b67  libSDL2-2.0.so.0.4.0
[19:39] <popey> yup
[19:42] <mcphail> have you managed to get access to the backtrace in gdb?
[19:57] <popey> mcphail: yeah, but no symbols so it's not much use
 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
[20:01] <mcphail> popey: if I get a chance, I'll write something up about importing symbols for gdb. Makes life a lot easier
[20:15] <bschaefer> you can always compile it with -g3
[20:55] <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:57] <bschaefer> mcphail, o thats interesting, thanks! (Ill have to watch this now :)