[01:01] <AlbertA> kgunn: wiki looks good
[01:01] <kgunn> thank you sir
[01:02] <kgunn> btw, new qtubuntu in packages
[01:52] <kgunn> AlbertA: you still on? do you kow if you can get screen shots on unity8 desktop preview ?...or do we still have the mesa bug ?
[01:54] <AlbertA> kgunn: like with mirscreencast you mean or something else?
[01:54] <kgunn> AlbertA: yeah screencast
[01:55] <kgunn> olli: ^
[01:55] <AlbertA> kgunn: I wasn't aware of a mesa bug. but screenshots should work let me check on the demo server
[01:56] <olli> how exactly do i do that
[01:56]  * olli has to bath the baby
[01:56] <kgunn> AlbertA: you gotta pass in flags right ? ...or you can enable on the fly
[01:56] <kgunn> ?
[01:56] <olli> bbiab
[01:56] <kgunn> seems olli you'll likely have to hack the scripts somewhere to pass flags in to enable screenshotting
[01:58] <AlbertA> kgunn: yeah it's a command line utility
[01:58] <kgunn> hmmm....we almost need a "special" usc to just do this when we need to...
[01:59] <AlbertA> you should be able to do
[02:00] <AlbertA> mirscreencast -m /tmp/mir_socket
[02:01] <AlbertA> if you do mirscreencast -m /tmp/mir_socket --query it tells you where the file name will be and where it will end up
[02:01] <AlbertA> so for a screenshot in my laptop I did
[02:02] <AlbertA> mirscreencast -m /tmp/mir_socket -n 1
[02:03] <AlbertA> kgunn: and then you can use convert -depth 8 -size 1920x1080 /tmp/mir_screencast_1920x1080_60Hz.bgra screenshot.png
[02:04] <kgunn> AlbertA: mmm....so, mirscreencast is really just like a client app ?? so olli can just glom on to the existing usc server started by the unity8 session ??
[02:05] <kgunn> duflu: you better ?
[02:05] <AlbertA> kgunn: yeah I think the default authorization to allow screenshoting
[02:10] <kgunn> ok...i better bail, wife kinda irritated
[02:34] <olli> AlbertA, thx
[02:34] <olli> I'll give it a shot
[08:44] <alf_> duflu: https://code.launchpad.net/~vanvugt/mir/no-savings/+merge/216084/comments/513688
[08:45] <duflu> alf_: OK. Unfortunately there's not long left in the week. I suspect we might have triggered an odd multi-monitor frame sync bug because I believe the change is theoretically correct
[08:45] <duflu> I might try a couple of machines and see if I can find one which exhibits the issue.
[08:45] <duflu> alf_: What GPU?
[08:46] <duflu> number of monitors?
[08:46] <alf_> duflu: i965, built-in laptop monitor
[08:47] <duflu> alf_: Hmm. Then again Intel is showing obvious vsync regressions at times. Wonder if that's related
[08:47] <duflu> ... seems to have come with the new kernel in trusty
[08:47] <duflu> alf_: No (idle) monitor attached?
[08:51] <alf_> duflu: with either only the built-in monitor or a monitor attached with sidebyside configuration I get the speed-up. However with monitor attached and clone configuration I don't.
[08:53] <duflu> alf_: OK, obviously something somewhere is violating the basic rule of getting a new buffer only when buffer(id) is called with a previously seen id
[08:53] <duflu> ... the buffer consuming stuff should behave just like another monitor
[08:55] <alf_> duflu: at some point something happens and things get locked for a bit in [BufferConsuming] compositor_acquire enter: (0x7f1cd80025e8,nfree=0,nclients=0,nready=3,ncompositors=0)
[08:56] <alf_> [BufferConsuming] same_frame: 1 can_recycle: 0
[08:56] <alf_> duflu: and the same for [Compositing]
[08:56] <duflu> alf_: Sounds like a deep problem I won't fit into my head today, or this week
[08:57] <duflu> On the plus side, there is some serious sleep on the horizon
[08:58] <alf_> duflu: enjoy :)
[09:28] <duflu> Oh, umm, happy LTS release day
[09:28] <duflu> The web site's not showing it published yet though
[11:25] <greyback> kgunn: hey, for bug 1308735, at step 2, does the video play continually in the background? For me it stops after ~3 seconds, which is as I'd expect as it is SIGSTOPped
[11:28] <greyback> kgunn: never mind, I misread your description
[14:46] <dandrader> anpok,  any estimate on when you will have the needed input branches ready?
[14:46] <anpok> hmm probably not today..
[14:46] <anpok> i think it will come with an easter egg?
[14:49] <anpok> so the new send part is now as far as the other MP
[14:49] <anpok> just right now adding the result handling
[14:52] <anpok> dandrader: interface is more or less ready - i can update the WIP branch
[14:52] <anpok> and you could start using it..
[14:53] <dandrader> anpok, awesome
[14:54] <josharenson> kgunn: How important is it that we run glmark w/ and w/o bypass?
[14:54] <josharenson> kgunn: because if I remove that part, it would be nice to get the code merged and start working on the reporting tool (which robot fuel has provided me with info for)
[14:58] <kgunn> josharenson: totallly want to get the ci part done....then we can fart around with variants
[14:59] <kgunn> +1 on your thinking
[14:59] <josharenson> kgunn: ok, its close
[15:23] <kdub> alan_g, when your'e done with the discussion, could you weigh in on https://code.launchpad.net/~kdub/mir/platform-specific-bypass-option/+merge/214816 again?
[15:24] <kdub> some back-and-forth over enum class vs bool
[15:33]  * alan_g sighs
[15:33] <kdub> sorry :)
[16:57] <josharenson> kgunn: any value in writing a helper class for performance tests that can add PPAs and install packages? It seems that installing glmark2 during the test is the best way to go about things...
[18:38] <kgunn> josharenson: that seems valuable to me
[18:39] <kgunn> josharenson: also, to be sure, you're not turning on preformance tests/glmark2 by default as part of the build process ? (e.g. jenkins job runs it just like android integration tests...only for hw)
[18:40] <kgunn> camako: thank you for the list
[18:41] <camako> kgunn: Sure.. A bit raw but a start
[18:52] <josharenson> kgunn: ack
[18:53] <kgunn> AlbertA: did a test get added for stale socket removal ? panic the driver, orphan the socket and ensure it gets cleaned
[18:54] <AlbertA> kgunn: yeah
[18:54] <AlbertA> kgunn: probs with it?
[18:54] <kgunn> excellent
[18:54] <kgunn> nope just wanted to make sure
[18:54] <AlbertA> kgunn: oh you scared me there for a moment
[18:54] <AlbertA> kgunn: :)
[19:49] <ahayzen> kgunn, Hi I'm one of the music-app devs, FYI i've just tried your NonBlockingSwapTesting and after some quick testing it appears to have resolved our issues. I'll continue testing over the next few days and report any issues I find. Thanks for all the hard work your team has put into this.
[19:51] <kgunn> ahayzen: thanks for testing!
[19:51] <ahayzen> kgunn, no problem