[00:14] <lool> /!\ Mir FTBFS in PPA
[00:15] <lool> racarr: https://launchpadlibrarian.net/153780284/buildlog_ubuntu-saucy-amd64.mir_0.0.15%2B13.10.20131014-0ubuntu1_FAILEDTOBUILD.txt.gz
[00:15] <lool> it's this flaky new test
[00:15] <lool>  10/155 Test  #10: acceptance-tests.ServerShutdown/OnSignal.* .............................***Failed    0.02 sec
[00:15] <lool> I've retried the builds
[00:15] <lool> but this is no good
[00:15] <lool> kgunn: ^
[00:22] <kdub> lool, alan_g was looking into that towards the end of euro-day
[00:23] <lool> failed again
[00:26] <lool> it's kind of unfortunate because it built on armhf
[00:26] <lool> and that will block other builds like the platform-api fix
[00:42] <lool> ok, succeeded on 3rd try
[00:45] <racarr> lool: Yay. Thanks
[00:46] <lool> racarr: would still be good to fix this  :-/
[01:10] <racarr> lool: I know I think Alang is working on it
[01:16] <lool> unity-system-compositor and platform-api now in PPA
[01:23] <racarr> lool: I think we should get some good autopilot runs when it runs :D
[01:25] <lool> yeah
[01:25] <lool> especially with the keyboard fix
[01:47] <racarr> Mm :D
[02:11] <RAOF> mlankhorst: What ended up being the problem with nested? I'm trying to rework it to remove the bonghits involved in mystically passing around a gbm_device *.
[03:25]  * duflu wonders what said "bonghit" looks like in code
[07:02] <tvoss> good morning
[07:03] <RAOF> tvoss: Good morning!
[07:03] <tvoss> RAOF, hey there :) how goes?
[07:04] <RAOF> Acceptably.
[07:05] <RAOF> Thinking about foreign surfaces, still trying to figure out precisely what mlankhorst's patches for nested-gbm actually *do*, so we can make the nested code less maniacal, the usual.
[07:05] <duflu> Maniacal is fun, in small portions
[07:09] <RAOF> I'm a fan of not doing http://bazaar.launchpad.net/~afrantzis/mir/spike-nested-gbm-egl-image-hack/view/head:/src/server/graphics/nested/nested_platform.cpp#L59 and http://bazaar.launchpad.net/~afrantzis/mir/spike-nested-gbm-egl-image-hack/view/head:/src/server/graphics/gbm/native_gbm_platform.cpp#L37
[07:44] <tsdgeos> guys
[07:44] <tsdgeos> what's calling mir::graphics::android::MirNativeWindow::dequeueBuffer ?
[07:44] <tsdgeos> i can't seem to grep-find what calls it
[07:44] <tsdgeos> but i have a thread here that is doing it
[07:44] <tsdgeos> so someone is :D
[07:45] <tsdgeos> #25 0x42aad0c4 in mir::graphics::android::MirNativeWindow::dequeueBuffer (this=<optimized out>, buffer_to_driver=0x5219b970) at /build/buildd/mir-0.0.14+13.10.20131011/src/shared/graphics/android/mir_native_window.cpp:165
[07:45] <tsdgeos> #26 0x4468ab0e in ?? ()
[07:45] <tsdgeos> #27 0x4468ab0e in ?? ()
[07:51] <alf_> tsdgeos: AFAIK, it's called only by the driver. We pass this to the android drivers, as part of our custom native window implementation.
[07:52] <om26er> duflu, hello! when your second branch lands re: bug 1227739 is someone working on using those changes in unity-mir or platform-api ?
[07:52] <tsdgeos> alf_: i see
[07:53] <duflu> om26er: The main fix for Mir isn't even proposed yet. Those awaiting review are just prereq enhancements. But no, no one is assigned the platform-api task.
[07:54] <om26er> duflu, that means you have another branch inprogress ?
[07:54] <tsdgeos> alf_: thing is, if i shutdown unity+mir when nothing is moving, it's all fine, if i shut it down while some animation is going on (i.e. there's painting) this is one of the threads that seems to be kept alive
[07:55] <duflu> om26er: Yes. It's blocked by the one still awaiting review (because I fear it could be rejected so don't want to complete the fix based on that)
[07:55] <tsdgeos> can't totally blame on it, but i wonder who is supposed to tear it down
[07:56] <om26er> duflu, ok, thanks.
[07:56] <tsdgeos> btw, if the comment in https://code.launchpad.net/~aacid/mir/fix_mismatched_delete/+merge/190885 is true shouldn't the CI job be fixed so that it merges the target before running CI?
[08:00] <alf_> tsdgeos: Mir should be tearing the graphics subsystem down. A couple of things could be going wrong here: 1. Mir is not tearing down correctly 2. Mir is not tearing down at all, because e.g. the shell is still holding a shared_ptr to a Mir resource/subsystem
[08:01] <tsdgeos> alf_: mir is teared down
[08:01] <tsdgeos> or looks like it to me
[08:02] <tsdgeos> at least mir::run_mir has returned
[08:02] <tsdgeos> of course that doesn't mean it has tearned down properly or much i guess :D
[08:02] <alf_> tsdgeos: what I mean is that if e.g. the shell is holding a strong pointer to Mir's graphics subsystem, the server will be torn down, but the graphics subystem will not be uninitialized
[08:03] <alf_> tsdgeos: at least not at the right time
[08:03] <tsdgeos> alf_: but that "not tearing down" problem only happens when there's an animation running
[08:03] <tsdgeos> if all is static it works
[08:03] <tsdgeos> i don't see us holding an extra resource when animating
[08:04] <tsdgeos> which may be of course :D
[08:04] <tsdgeos> maybe just still haven't found that bit of code
[08:04] <alf_> tsdgeos: yeah, I am not sure either, just guessing, trying to give some leads :)
[08:05] <tsdgeos> sure :-)
[08:08] <alf_> tsdgeos: I know that unity-mir is holding a shared_ptr to a MirSurface, which may be related to this problem. So one possible scenario is: mir server is torn down, graphics torn down, but the MirSurface (which is backed by a "native window" used by the driver) is not destroyed because shell/qt/qml is still trying to use it
[08:09] <tsdgeos> may be
[08:09] <alf_> tsdgeos: valgrind may give you more hints about what is going on there
[08:09] <tsdgeos> i does actually hang/deadlock while we are deleting the window
[08:09] <tsdgeos> i.e. i successfully leave qt's event loop
[08:09] <tsdgeos> and when i try to delete the window
[08:10] <tsdgeos> it goes deep in somewhere
[08:15] <alan_g> duflu: I didn't get a chance to look at lp:~mir-team/mir/verify-MirConnection - is it still a problem?
[08:15] <duflu> alan_g: Not really. I'm now questioning the whole exercise. Might be best to reconsider all libmirclient error handling semantics post-saucy
[08:16] <duflu> Because we need to halt broken clients and show them where they're broken... but that conflicts with the existing design of allowing invalid connection handles to many functions. And in many cases silently ignoring them
[08:17] <alan_g> duflu: OK. What we've implemented isn't self-consistent
[08:17] <duflu> alan_g: Correct
[08:18] <duflu> alan_g: I think we need to detect bad parameters and crash the client immediately. But that's enough of a semantic change I'm struggling to call it a "fix" we could squeeze into saucy
[08:20] <alan_g> duflu: I think it is too big a discussion for this week. But I agree the broad principle
[08:27] <duflu> alan_g: https://bugs.launchpad.net/mir/+bug/1239978
[08:43] <alf_> Saviq: Do you also need a "stopped" event from mir? Returning from run_mir is essentially a "stopped" event.
[08:44] <Saviq> alf_, not right now, but dunno if it'll be needed later by something
[08:44] <alf_> Saviq: My plan is to add "started" for now. If we need it it can be trivially added.
[08:44] <alf_> Saviq: (stopped)
[08:44] <Saviq> alf_, +1
[08:45] <tjaalton> the xorg packages keep getting xmir related crashes all the time, and I doubt those will get fixed as sru?
[08:47] <duflu> tjaalton: True. It would only be a big problem if the crashes can't be easily de-duplicated though... ?
[08:47] <tjaalton> de-duplicated? i've no idea which ones are related to which
[08:49] <duflu> tjaalton: I mean we can deal with it so long as there's sufficient stack info for you to know it's a Mir bug... and then for us to recognize which Mir bug
[08:49] <tjaalton> i mean, shouldn't there be a word sent out that anyone sticking to saucy should just disable xmir?
[08:49] <tjaalton> oh I can recognize xmir from ProcCmdline
[08:49] <duflu> tjaalton: That's a nice thought but in the world of Ubuntu, users will constantly customize and experiment even when we suggest not to
[08:50] <tjaalton> so that's fine, but the bug view is getting cluttered with all these bugs with '[xmir]..' :)
[08:50] <duflu> tjaalton: Is it? Are they correctly assigned to the xmir project?
[08:50] <tjaalton> no
[08:50] <tjaalton> crashers are sent to xorg-server
[08:50] <tjaalton> it's a manual process after that
[08:51] <duflu> tjaalton: I know how that is. Spent most of the past could of years dealing with Unity crashes landing in Compiz :/
[08:51] <tjaalton> although xdiagnose could be smarter..
[08:51] <tjaalton> now that I think of it
[08:52] <duflu> tjaalton: If you could automagically bump them to the xmir project then we'd see them and help with the triage
[08:53] <tjaalton> yeah I'll see if it can be done
[08:54] <tjaalton> depends on apport I think
[09:04] <asac> it would be nice if Mir team could run apt-get install ubuntu-ui-toolkit-autopilot + phablet-test-run ubuntuuitoolkit and see what happens
[09:04] <asac> (something bad, in short, after a couple of minutes)
[09:04] <asac> err
[09:04] <asac> "it would be nice if Mir team could run apt-get install ubuntu-ui-toolkit-autopilot + phablet-test-run ubuntuuitoolkit and see what happens
[09:04] <asac> (something bad, in short, after a couple of minutes)"
[09:04] <asac> kgunn: ^^
[09:04] <asac> thats again uncovered/triggered by MIR landing still
[09:05] <tvoss> asac, do we have any more detail on what is going wrong?
[09:06] <asac> tvoss: no its misty dark
[09:06] <asac> tvoss: you run the APs one by one its kind of working... but if it runs all in one shot it will stall completely
[09:12] <tvoss> asac, okay
[09:12] <tvoss> asac, any reason we suspect mir and not u8?
[09:18] <asac> tvoss: so unity8 could be the candidate, but since mir landing started regressing all the tests
[09:18] <asac> its the first stop for every issue until we have managed to get the rest to green once
[09:18] <asac> then we can more easily blame the right folks again
[09:18] <asac> tvoss: if you feel its u8 from the looks, lets have Saviq also check
[09:18] <asac> Saviq: sdk team tests:
[09:18] <asac> 11:04 < asac> "it would be nice if Mir team could run apt-get install ubuntu-ui-toolkit-autopilot +  phablet-test-run ubuntuuitoolkit and see what happens
[09:18] <tvoss> asac, reflashed phone, testing now
[09:19] <tvoss> asac, just saying that both the Mir team and the U8 team should look into regressions to be more efficient
[09:19]  * Saviq checks
[09:19] <asac> tvoss: yeah. good news is that mir team is in the same team as unity8 :)
[09:19] <asac> so... :)
[09:19] <Saviq> asac, except we're not ;)
[09:20] <asac> we put them organizationally close to each other for such cases
[09:20] <asac> Saviq: both report to kgunn ... who spans this bigger team
[09:32] <alf_> greyback: https://code.launchpad.net/~afrantzis/mir/server-started-notification/+merge/191134 , let me know if this is enough for you
[09:34] <greyback> alf_: looks reasonable, will test it out in ~1 hour
[09:34] <alf_> greyback: ok
[09:42] <alan_g> duflu: shall we move the "privatize" and "tidy-up" branches to WIP for the time being?
[09:42] <duflu> alan_g : Yeah "Resubmit" for when we have a T-series branch
[10:26] <tvoss> alf_, got an eta on https://code.launchpad.net/~afrantzis/mir/server-started-notification/+merge/191134
[10:26] <tvoss> ?
[10:32] <tvoss> alan_g, ping
[10:32] <alan_g> tvoss: ?
[10:33] <tvoss> alan_g, hey, so we are seeing slowdown of rendering after multiple app starts/stops in autopilot test scenarios
[10:33] <tvoss> alan_g, as I have seen some mp's for ensuring correct session deconstruction recently, could you check if we actually clean up sessions, their surfaces and buffers?
[10:34] <tvoss> alan_g, I have a gut feeling that we somehow have closed sessions alive in mir/unity8
[10:34] <alan_g> tvoss: you mean like the one I wasn't convinced cleaned sessions up?
[10:35] <tvoss> alan_g, yup :)
[10:35] <tvoss> alan_g, perhaps we can prove with a simple cout in the session/surface d'tor?
[10:36] <alan_g> tvoss: have you tried enabling the session mediator report?
[10:36] <tvoss> alan_g, nope, not yet
[10:37] <tvoss> Mirv, didrocks again, to establish a baseline: how do we run the uitk testsuite?
[10:38]  * alan_g realizes that won't prove anything
[10:38] <didrocks> phablet-test-run ubuntuuitoolkit
[10:38] <Mirv> tvoss: flash, apt-get install ubuntu-ui-toolkit-autopilot on device, run phablet-test-run ubuntuuitoolkit
[10:39] <tvoss> Mirv, didrocks thx
[10:39] <alan_g> tvoss: is is probably ms::surfaces that need to be cleaned up - and it is entirely possible that unity hangs onto them after the session closes. (We need a surface manager report)
[10:40]  * alan_g hasn't looked at the unity code for a long time - "possible" is not an accusation
[10:45] <tvoss> alan_g, can you help me and look into that?
[10:50] <alan_g> tvoss: I'm going to knock up a quick report from surface manager and first try a basic mir server. If that's clean I'll try dropping it into u8
[10:51] <tvoss> alan_g, +1, and many thanks
[10:51]  * alan_g hates interruptions
[11:04] <alan_g> tvoss: the ownership of surfaces is such a mess that I can't spot an effective place to report on it. Digging...
[11:05] <alf_> tvoss: I am the submitter, you should ask the reviewers :)
[11:05] <alf_> tvoss: ah, you mean about the fix, working on it
[11:06] <tvoss> alf_, sorry, ENOCONTEXT ;)
[11:06] <alf_> tvoss: @eta for server-started-notification
[11:07] <tvoss> alf_, ah, thanks
[11:07] <dandrader> alf_, Since you have a recent fix in qtubuntu I suppose you've also built it in your device recently. I'm trying to build it myself but I'm getting these errors: http://paste.ubuntu.com/6240031/  I should have all the needed  libraries installed as I've run "apt-get build-dep qtubuntu"
[11:08] <dandrader> any ideas?
[11:10] <alf_> dandrader: the build command is not linking against -lEGL, but I don't know why that is, I didn't have any problems with it
[11:11] <dandrader> alf_, so it's not "-lGLESv2"?
[11:14] <alf_> dandrader: that is only GLES 2, you also need to link against EGL
[11:15] <dandrader> alf_, ah, ok. "EGL", "GLES", they look so similar. :)    thanks for the hint!
[11:36] <Mirv> congrats on the performance improvements (the situation after a fresh boot), extremely nice. scrolling not hitch free yet, but that's probably a combination of many factors.
[11:37] <Mirv> but it's night-and-day difference in swiping between lenses or indicators with the new mir
[11:39] <tvoss> Mirv, thanks :) all credit to kdub :)
[11:53] <alf_> kdub: ^^ \o/
[12:39] <om26er> racarr, ping
[12:48] <tvoss> Mirv, which image will have the performance fix?
[12:57] <Mirv> tvoss: it's now in release pocket (since 0.5h), so the next one. I assume the number is #98.
[13:03] <mlankhorst> RAOF: see the patch I wrote
[13:03] <mlankhorst> RAOF: basically the GBM allocator expected a gbm_surface
[13:03] <mlankhorst> and then it passed gbm_surface->dri_private to the mir call
[13:05] <mlankhorst> RAOF: look at the forwarding calls defined in src/gbm/backends/dri/ for dri2_loader_extension
[13:07] <mlankhorst> dri_get_buffers_with_format  dri_flush_front_buffer dri_get_buffers
[13:11] <om26er> Mirv, when do we spin a new build ?
[13:13] <Mirv> om26er: ask ogra_ or didrocks
[13:13] <ogra_> om26er, once everything planned is in the archive

[13:24] <alf_> greyback: did you get a chance to try the server-started-notification branch with unity(-mir)?
[13:25] <greyback> alf_: just compiling now
[13:26] <alf_> greyback: ok
[14:34] <greyback> alf_: well I've tried your branch, I get a started() call, but I'll have to trust you that it happens when mir is ready to get client connections
[14:35] <alf_> greyback: Trust me, I know what I am doing https://www.youtube.com/watch?v=nnwWKkNau4I
[14:36] <greyback> alf_: :D
[14:41] <Saviq> ogra_, https://code.launchpad.net/~saviq/unity8/raise-sigstop/+merge/191212 looking sane for the SIGSTOP?
[14:42] <ogra_> Saviq, awesome !
[14:48] <alan_g> tvoss: The mir code doesn't leak surfaces. I'll have to update my phone image to investigate further - here's the code if it helps you: https://code.launchpad.net/~alan-griffiths/mir/draft-surfaces-report/+merge/191215
[15:00] <Saviq> ogra_, so... that makes us pause when ran by hand... any way we can detect we're running under upstart?
[15:00] <Saviq> ogra_, to only emit it if we are?
[15:00] <Saviq> hmm we could set an env var
[15:08] <ogra_> Saviq, one sec ... meeting ...
[15:08] <Saviq> ogra_, we went for $UPSTART_JOB == "unity8"
[15:12] <ogra_> Saviq, i dont really get what you are referring to
[15:12] <ogra_> the above patch looks just fine
[15:13] <Saviq> ogra_, if we just "$ unity8" in bash
[15:13] <Saviq> ogra_, the process will pause
[15:13] <ogra_> yeah you should never do that
[15:13] <Saviq> ogra_, and we need to SIGCONT it (or well, "$ fg")
[15:14] <Saviq> ogra_, for testing
[15:14] <ogra_> use upstart to start and stop it
[15:14] <Saviq> ogra_, we often need console output and stuff
[15:14] <ogra_> ah, k
[15:14] <Saviq> ogra_, and it's just easier to not have to go through upstart
[15:14] <ogra_> yeah then add stuff to the unity8 job that reacts to an env var
[15:15] <ogra_> and sets debug options etc
[15:15] <Saviq> ogra_, we have that
[15:15] <Saviq> ogra_, it's still easier to just ./unity8
[15:16] <Saviq> ogra_, I just did if ($UPSTART_JOB == "unity8") raise(SIGSTOP);
[15:16] <ogra_> well, but that wont give you the same env that the user has
[15:16] <Saviq> ogra_, that seriously wrong?
[15:16] <ogra_> i dont think so
[15:16] <ogra_> but i think testing stuff without upstzart involved will taint your results
[15:16] <Saviq> ogra_, we obviously will
[15:16] <Saviq> ogra_, autopilot does, if nothing else
[15:17] <Saviq> ogra_, it's just for day-to-day dev
[15:17] <ogra_> right
[15:17] <ogra_> ship a developer start script ;)
[15:17] <Saviq> ogra_, we do ;D
[15:17] <ogra_> start-unity8
[15:17] <Saviq> ./run
[15:17] <ogra_> ah,, good
[15:17] <Saviq> ogra_, and that we'll make to use upstart
[15:17] <ogra_> ok
[15:18] <Saviq> ogra_, but we don't want to break the "./unity8" case unnecessarily
[15:18] <ogra_> right
[15:31] <kgunn> racarr, hey did you happen to look into why unwanted characters show up in text fields sometimes ? e.g. * when you hit the power button ?
[15:35] <tvoss> alan_g, thanks, are you looking further
[15:35] <tvoss> ?
[15:35] <alan_g> tvoss: Am updating my phone image as we chat
[15:35] <tvoss> alan_g, ack
[15:36]  * alan_g thinks it weird the instructions haven't changed since last time
[15:49] <alf_> Saviq: +1 for not breaking './unity8' case
[15:51] <alf_> Saviq: if the $UPSTART_JOB scheme doesn't work, we could make unity8 read e.g. UNITY8_SIGSTOP_ON_STARTED env. variable, and set that in unity8.conf
[15:51] <alf_> Saviq: when invoking unity8
[15:55] <tvoss> greyback, for my mp: unity-mir already uses mir, which uses exceptions
[15:57] <tvoss> greyback, also: how do you handle cases where creation of an object would result in an invalid object? with an isValid() accessor?
[15:59] <greyback> tvoss: true, we can't avoid that, but it's why if mir throws an exception, unity-mir doesn't try to catch it, nor does unity8, so unity8 quits
[15:59] <greyback> tvoss: yes
[16:00] <tvoss> greyback, well, that's the opposite of exception safety
[16:01] <tvoss> greyback, just saying :)
[16:02] <greyback> tvoss: I'm not arguing, I'm just saying what we do with Qt
[16:03] <tvoss> greyback, ack, I will adjust the mp. Still saying we should revisit how we consider exception safety :)
[16:04]  * alan_g wonders why mir exceptions are propagating to unity on a thread Mir doesn't own
[16:05] <greyback> tvoss: no objection here, as long as Qt's particulars are considered. It was written before exceptions were commonplace, so it wasn't designed to use exceptions itself. I'd love a primer on safe exception usage with Qt
[16:18] <tvoss> greyback, ack
[16:19] <tvoss> greyback, I left the static functions, they are at least as good as const static members
[16:19] <tvoss> greyback, addressed your other comments
[16:21] <greyback> tvoss: thank you
[16:44] <racarr> Morning
[16:44] <racarr> kgunn: I am not sure * whn you hit the powe button was a real thing...I could never reproduce it I think we fixed the other unwanted characters though, that's the thing I was pinging you about it yesterday
[16:46] <racarr> reworded: We fixed some kind of unwanted character bug
[16:46] <racarr> not sure about the power button
[16:46] <racarr> are you sure thats a thing?
[16:49] <davmor2> racarr: open terminal hit the power button you got a ? in the terminal and then a second when you powered it back on
[16:50] <davmor2> racarr: let me see if it is still in place on 97
[16:51] <davmor2> racarr: Ah is a * now
[16:51] <davmor2> racarr: I forgot open terminal and tap it so the keyboard it up then press the power button
[16:52] <davmor2> racarr: although it might be fixed by the fix you are talking about
[16:53] <davmor2> racarr: does that help?
[16:54] <racarr> davmor2: Yes thanks I am checking now
[16:54] <racarr> it could be the bug from yesterday actually...
[16:55] <racarr> as the surface loses focus
[17:00] <racarr> davmor2: kgunn: Ok. it's a thing. its not the thing from yesterday actually just the key event really is going through
[17:00] <racarr> and getting mapped incorrectly
[17:00] <racarr> the shell needs to grab it...need to figure out how to do that with the monitor situation
[17:04] <davmor2> racarr: \o/
[17:08] <racarr> I really thought  I tried that last week
[17:08] <racarr> wonder if I did something silly or there really is some sort of
[17:08] <racarr> inconsistency to the mismapping
[17:08] <racarr> *shrug*
[17:36] <kgunn> racarr: thanks (sorry late response, i had an early lunch)
[17:36] <racarr> s'ok
[17:36] <kgunn> racarr: so the "thing" yesterday...does it potentially fix this one https://bugs.launchpad.net/ubuntu/+source/unity-mir/+bug/1238098
[17:37] <racarr> kgunn: Yes
[17:37] <kgunn> sweet
[17:40] <racarr> kgunn: Very hopefully...shouldn't we have new AP runs very soon
[17:40] <racarr> or do we have them *checks*
[17:40] <kgunn> racarr: yeah...Saviq was saying we should be down to like 1 failure on unity8 AP run
[17:40] <kgunn> racarr: which means they should turn almost everything back on
[17:41] <racarr> http://reports.qa.ubuntu.com/smokeng/saucy/touch_ro/mako/97:20131015:20131015/4732/
[17:41] <racarr> unity8 and ubuntu-ui-toolkit finally succeeded
[17:41] <racarr> which is nice
[17:41] <racarr> I think the extra characters really are gone because that was killing
[17:41] <racarr> ui toolkit
[17:41] <racarr> filemanager and rssreader got worse?
[17:41] <kgunn> racarr: cool...i'm gonna mark that fixed, was that fix in unity-mir or mir or ubuntu-keyboard
[17:42] <racarr> kgunn: platform-api
[17:42] <kgunn> racarr: thanks...the only one i didn't guess :)
[17:42] <kgunn> wow...its getting creepy dark here in dallas....
[17:42] <kgunn> storm movin' in
[17:43] <racarr> kgunn: lol, and my initial guess for where it would be was
[17:43] <racarr> qtubuntu
[17:43] <racarr> its like some sort of bug wheel of fortune
[17:43] <kgunn> :))
[17:44] <kgunn> ubuntu-roullette
[17:44] <racarr> kgunn: No, that's the adult themed free software chat roulette alternative
[17:44] <kgunn> lol
[17:45] <racarr> I want to write a phone app.
[17:52] <racarr> kgunn: ricmm had a fix in the pipe for the power key stuff https://code.launchpad.net/~ricmm/unity-mir/add-keyfilter-interface/+merge/189727 we are testing, coordinating, etc :)
[17:52] <kgunn> racarr: thanks
[19:00] <lool> guys, just tested latest mir from image that was just published and it's *flying* much better performance with the locking changes   \o/
[19:00] <tvoss> kdub, ^ \\o//
[19:00] <tvoss> lool, thx
[19:03] <kdub> :D
[20:01] <racarr> It actually feels really smooth now :) except for the occasional
[20:01] <racarr> pause
[20:02] <racarr> kgunn: I think you were right with that idea you had last week that
[20:02] <racarr> something happens to the animation curve when you lift
[20:02] <racarr> your finger up
[20:03] <kgunn> racarr: yeah..the numbers from qml timing seem to indicate that also....
[20:03] <kgunn> and gerry was pretty sure there's a decelration in qt somewhere
[20:03] <kgunn> which we've selected by default
[20:04] <racarr> I'm not sure it's exactly that (lifting the finger actually)
[20:04] <racarr> I've just been sitting here for like 5 minutes flipping the dash trying to figure out why it doesnt look right lol
[20:04] <racarr> I think the thing is
[20:04] <racarr> it's quite slow to accelerate, you notice just
[20:04] <racarr> put your finger around an icon and quickly drag
[20:05] <racarr> and the icon falls far behind your finger
[20:05] <racarr> quite a bit...
[20:05] <racarr> and I think
[20:05] <racarr> the finger jerks in response to this haha
[20:05] <racarr> i.e. my physical finger
[20:06] <racarr> because if I really focus on making a smooth motion with my finger and not look at the screen as much it seems pretty smooth
[20:06] <racarr> *shrug*
[20:07] <racarr> it seems also like if you go really fast it will keep up
[20:07] <racarr> so there must be some sort of deacceleration or some acceleration with a weird curve
[20:08] <racarr> there's also something that looks strange when you
[20:08] <racarr> flick fast and focus on white blocks
[20:08] <racarr> like the top bar text...
[20:09] <racarr> but I think that might just be...a weird effect from when the white passes over the light part of the background
[20:09] <racarr> it definitely doesnt look right though
[20:10] <racarr> On the other hand. It works well enough that you can investigate minor issues like this without being distracted by general system failure. Huzzah :D
[20:11] <racarr> kgunn: If nothing critical comes up can I spend some time investigating the animation model? or do I need to dig in to autopilot more
[20:11] <racarr> http://reports.qa.ubuntu.com/smokeng/saucy/
[20:11] <racarr> build 98 is running I guess?
[20:13] <racarr> ricmms branch fixes the power key thing :) just need gerry and saviq to review I guess
[20:35] <Saviq> racarr, ricmm, do we know where the asterisk come from in any case?
[20:36] <Saviq> like who translates PowerKey to * ?
[20:39] <racarr> Saviq: Probably a combination of xkbcommon and qtubuntu...
[20:39] <racarr> probably mostly qtubuntu
[20:39] <racarr> by that I mean we probably have errors in both our xkbcommon mapping and the interpretation in qtubuntu
[20:40] <racarr> though. it does in fact come out of xkbcommon
[20:40] <racarr> mapped to volume up
[20:40] <racarr> and we added that to the qt key table mapping
[20:40] <racarr> so it's a little hard to say
[20:41] <racarr> *thinks*
[21:17] <RAOF> mlankhorst: Where's the canonical location of your patch? I don't think I've got the whole context of your changes.
[21:18] <mlankhorst> RAOF: shrug I merged ubuntu debian packaging, upstream/9.2 branch
[21:18] <mlankhorst> sec :P
[21:18] <mlankhorst> real changes were 2 pastebins I posted here before
[21:19] <mlankhorst> http://paste.debian.net/58054/ git show + git diff appended
[21:20] <mlankhorst> probably applies against the egl-image*-i965 branch
[21:22] <RAOF> Oh, right.
[21:29] <RAOF> Because we were populating gbm_dri.
[21:31] <RAOF> So that's a perfectly good fix, just one that doesn't allow me to stop passing the gbm_dri_device * through the platform.
[21:36] <mlankhorst> :P
[21:36] <mlankhorst> well the #if 0'd code still works
[21:37] <mlankhorst> but yeah needs gbm if available
[21:37] <mlankhorst> lookup extension probably sitll fails, dno if there is one or not
[21:37] <mlankhorst> but it expects a gbm something
[21:38] <mlankhorst> I if 0'd it for debugging, mostly
[21:38] <mlankhorst> that way i can test nested mir path with a demo client
[22:07] <RAOF> mlankhorst: I mean I'd prefer to do something like http://paste.ubuntu.com/6242735/ , which doesn't work, but I don't really see why not.