[00:26] <racarr> ricmm: Last time that was
[00:26] <racarr> surface flinger running
[00:26] <racarr> I think?
[00:27] <ricmm> yup, this was ssomething similar, wsomeone else was starting a qt process with qtubuntumir
[00:27] <ricmm> not the main issue anyways
[01:49] <robert_ancell> duflu, can you recheck https://code.launchpad.net/~robert-ancell/mir/vt-option/+merge/170476?
[01:50] <duflu> robert_ancell: Yeah no problem. It will be done today
[01:50] <duflu> And hopefully "done"
[01:59] <RAOF> And then I get to use the same infrastructure to make input not go to the VTs! Yay!
[03:44] <duflu> robert_ancell: Approved but you typically need a second review
[03:45] <robert_ancell> duflu, ta
[03:46] <RAOF> I'll do that one.
[04:04] <robert_ancell> I do believe I just did a cold boot, past plymouth, into a XMir greeter and into a session with acceleration
[04:04] <robert_ancell> RAOF, what was the command to check the /dev/drm permissions?
[04:05] <RAOF> getfacl /dev/dri/*
[04:06] <RAOF> Also, I'm not surprised. That's been working for me since your XDG_SEAT fix yesterday :)
[04:06] <robert_ancell> RAOF, the VT fix seemed to fix the last problem for me
[04:07] <robert_ancell> RAOF, did you see https://code.launchpad.net/~robert-ancell/unity-system-compositor/lightdm-conf.d/+merge/170730 btw?
[04:07] <RAOF> I did not.
[04:08] <RAOF> That's not _quite_ the same thing as debconf, though?
[04:08] <RAOF> Although people can always delete the conf.d snippet, I guess.
[04:09] <robert_ancell> RAOF, yeah, I think that's the idea
[04:09] <robert_ancell> And it handles multiple packages fighting over the same setting
[04:09] <RAOF> That's fine by me. Going to update the testing instructions?
[04:09] <robert_ancell> Not today, but can do when it's merged
[04:11] <robert_ancell> RAOF, duflu, are you subscribed to u-s-c merges btw? It would be handy to have a pool of us who can review them
[04:12] <RAOF> I think I am, but I think they get filed into a folder I don't regularly look at.
[04:12] <robert_ancell> ok, coo
[04:12] <robert_ancell> l
[04:12] <duflu> robert_ancell: Not subscribed but I can remember to look at the launchpad page
[04:12] <RAOF> We're in the same timezone, so I think pinging will scale reasonably well.
[04:12] <robert_ancell> there's some other low priority merges, just wanted to check someone will see them at some point
[04:12] <RAOF> Ish.
[04:12] <duflu> I tend to ignore the mail noise and go straight to the summary pages
[04:13] <robert_ancell> and some for lightdm
[04:15] <robert_ancell> RAOF, oh, you merged it - do you know where the instructions are to modify off hand?
[04:16] <RAOF> https://docs.google.com/a/canonical.com/document/d/1M7aH9QF1Q1EXd0UOYz4CWa3HGmBAHewFdQ3kmQO25_o/edit#heading=h.b75suqfnic7w
[04:27] <robert_ancell> RAOF, do we consider system-compositor-testing PPA still broken?
[04:28] <RAOF> It's broken for i386 because of hateful buildds, but I don't think it's broken outside that.
[04:28] <RAOF> It should probably have a big ‘don't VT switch or try user switching’ disclaimer, though.
[04:33] <robert_ancell> That second cursor is super annoying...
[04:40] <robert_ancell> bye all - last chance for anything that needs resolving before next week..
[04:40] <robert_ancell> RAOF, duflu?
[04:40] <duflu> robert_ancell, annoying but there was a request for a temporary watermark feature ;_
[04:40] <duflu> ;)
[04:40] <robert_ancell> duflu, not likely
[04:40] <duflu> robert_ancell: No in that document it was requested
[04:40] <RAOF> I think I'm most of the way through fixing that cursor, but other things have bumped it off the priority.
[04:42] <duflu> RAOF, robert_ancell: https://bugs.launchpad.net/mir/+bug/1192916
[04:42] <robert_ancell> duflu, yep
[04:42] <robert_ancell> it's only cosmetic
[04:44] <duflu> RAOF: If you're working on it, please claim the bug
[04:44] <RAOF> Have done so, thanks.
[05:10] <tvoss_> RAOF, ping
[05:10] <RAOF> tvoss_: Pong.
[05:11] <tvoss_> RAOF, good morning :) any good news from the buildd or do I need to setup a vm with an ancient kernel and try to reproduce?
[05:11] <RAOF> No good news from the buildd, sorry.
[05:12] <tvoss_> RAOF, I don't understand why it is failing only on i386 when it used to work before
[05:13] <RAOF> Possibly the buildds having their kernels upgraded? But that wouldn't be the case, because they've out of support.
[05:14] <tvoss_> RAOF, here is what webops were able to extract: https://pastebin.canonical.com/93178/
[05:16] <RAOF> That's... annoying?
[05:16] <tvoss_> RAOF, attached to the hanging process via gdb and interrupted
[05:16] <RAOF> Something in the free path has deadlocked?
[05:17] <tvoss_> RAOF, not deadlocked, the process is spinning even
[05:17] <RAOF> So livelocked then.
[05:18] <tvoss_> yup, okay, ancient kernel debugging then *fun*
[05:18] <RAOF> Can there be any more desirable use of a Friday?
[05:21] <tvoss_> totally not
[05:38] <tvoss_> olli, ping
[05:39] <olli> tvoss_, wazzup
[05:39] <tvoss_> olli, good morning/good night :)
[05:40] <olli> just read some backlog
[05:40] <olli> yay for working infrastructure
[05:41] <olli> tvoss_, I am about to log off, was there anything you wanted to ping me about?
[05:41] <tvoss_> olli, nope, sent you a pm, though
[05:41] <tvoss_> olli, wanted to check if you were able to install the ppa
[05:42] <olli> didn't get to it
[05:42] <olli> updated to saucy though ;)
[05:42] <olli> baby steps
[05:42] <tvoss_> olli, \o/ later then :)
[05:42] <olli> cya in a few hours
[05:43] <jono> olli, working late?
[05:43] <olli> just wrapping up
[05:43] <olli> u?
[05:43] <jono> ditto
[05:48] <jono> night all
[05:49] <olli> cya all
[05:57] <duflu> RAOF: Can you give my the idiot's guide to what kind of Mir surface XMir is?
[05:57] <duflu> -my +me
[05:59] <RAOF> Whatever is set by default.
[05:59] <RAOF> duflu: I don't currently explicitly set it to anything.
[05:59] <duflu> RAOF: I mean hardware or software?
[06:00] <duflu> EGL?
[06:00] <duflu> Blitted by memcpy?
[06:01] <RAOF> Oh, hardware.
[06:01] <RAOF> Direct access to the contents of the mir_buffer_package.
[06:01] <RAOF> Blitted by hardware.
[06:02] <duflu> RAOF: Hmm so XMir is technically GBM-native?
[06:02] <RAOF> XMir is very much GBM-native at this point.
[06:03] <duflu> RAOF: I was thinking it would be beneficial to configure Compiz to use its old buffer aging logic (circa 2012 and prior) because that's faster and all we need when another compositor is on top. But was also wondering if XMir itself is optimal
[06:04] <duflu> -on top +underneath
[06:04] <RAOF> XMir is not itself optimal.
[06:05] <duflu> I'm glad you say that
[06:05] <duflu> It means it could get even faster
[06:05] <RAOF> Indeed.
[06:05] <RAOF> First optimisation is to use the buffer_age field to do partial updates.
[06:05] <RAOF> Second optimisation is to do GLX passthrough for fullscreen surfaces.
[06:06] <duflu> RAOF: Yeah Compiz can do that without the buffer_age extension, I mean
[06:06] <RAOF> But it does it by not SwapBuffering, right? XMir can't do that.
[06:06] <duflu> Hmm
[06:07] <duflu> RAOF: Yes I think XMir would have to translate that into buffer_age logic
[06:08] <duflu> Just trying to get Compiz closer to the hardware, even when Mir is in the middle...
[06:09] <RAOF> Compiz always outputs to a fullscreen GLX window, right?
[06:09] <RAOF> Composite-bypass for XMir gets you as close to the hardware as you can be.
[06:10]  * RAOF heads out to get stuff for dinner before it gets dark and even colder.
[06:17] <duflu> RAOF: Yes Compiz _only_ supports fullscreen GLX composting
[06:18] <duflu> Hah
[06:18] <duflu> -composting  +compositing
[06:18] <duflu> :)
[06:30] <RAOF> duflu: Then we should be able to hand the buffer from Mir all the way through to Compiz. Once Mir also does composite bypass, that'll have Compiz drawing on the framebuffer.
[06:30] <duflu> RAOF: Sounds quite awesome
[06:59] <tvoss> didrocks, ping
[06:59] <didrocks> tvoss: pong
[07:49] <RAOF> duflu: If you've got a moment would you kindly check that lp:~raof/mir/prober-drm-device-probe works for you?
[07:49] <duflu> RAOF: What's it do?
[07:49] <duflu> Meant to..
[07:49] <RAOF> It's meant to actually probe the drm devices, rather than hope that one of {i915, radeon, nouveau} will bind to the right thing.
[07:50] <RAOF> As a secondary benefit, it should also throw sensible errors if it *can't* find a drm device, unlike the current state of things which always returns EPERM on error.
[07:51] <RAOF> Heh. Misspelt branch name - that's meant to be *proper*-drm-device-probe :)
[07:52] <duflu> RAOF: Oh I was going to do something similar. Should then include vmware support?
[07:52] <RAOF> Assuming vmware does sensible EGL, this *is* vmware support.
[07:52] <RAOF> Or maybe I've misinterpreted what you've said.
[07:52] <duflu> No, that's cool
[07:53] <RAOF> Yes, this should include vmware support, assuming vmware can do EGL on their raw kms device.
[07:53] <RAOF> I'm not sure if that assumption holds, but it seems reasonable.
[07:53] <duflu> RAOF: You mean Mesa fully implements vmware support in its EGL... ?
[07:54] <RAOF> Mesa certainly has support for vmware, and I don't _think_ it does anything fancy like needing help from it's X driver.
[07:56] <RAOF> Prf_Jakob will know!
[07:57] <duflu> RAOF: Well I hoped not
[07:57] <duflu> RAOF: Just tinkering with linker madness then I'll test it
[07:57] <RAOF> :)
[07:57] <RAOF> duflu: Oh, sorry. I should have fixed the testing PPA, shouldn't I?
[07:58] <duflu> RAOF: I was working on fixing the code so it builds. What would you "fix"?
[07:58] <RAOF> The easy way to do that will be to create a new PPA, build Mir in it against the archive mesa, then copy that including the binaries into the testing PPA.
[07:58] <RAOF> But if you're actually splitting out the libmirclient build then that's much more useful.
[07:58] <RAOF> Please don't let me interrupt you from doing that!
[07:58] <duflu> RAOF: That's a workaround that's kind of specific to here and now. I'm trying to find a more permanent solution
[08:20] <dholbach> hey hey
[08:24] <dholbach> so regarding the documentation improvements Jono mentioned on the mailing list - would it make sense to file bugs on mir about this? AFAIK http://unity.ubuntu.com/mir/ is generated from the docs in lp:mir? I could tag them with 'docs' or something
[08:27] <RAOF> dholbach: Yeah, that'd be reasonable.
[08:28] <dholbach> great - I'll do that and follow up on the mailing list
[08:39] <alan_g> duflu: about the "ProtobufSocketCommunicator::start()" - I'm not sure how to make it clearer. Any suggestions?
[08:40] <duflu> alan_g: Not sure. I didn't spend enough time looking at it
[08:41] <alan_g> np
[09:22] <RAOF> tvoss_: I'm not sure if we want further sabdfl testing right at the moment, but if we do, https://code.launchpad.net/~raof/mir/prober-drm-device-probe/+merge/170765 should at least generate a more useful error.
[09:53] <tvoss_> katie, ping
[09:57] <katie> tvoss_, pong
[10:04] <duflu> Got to run. Sorry in advance for my merge proposal.
[10:08] <tvoss_> RAOF, for the build issue in the ppa?
[10:08] <tvoss_> RAOF, do you think it makes sense to disable i386 to make propagation working fine again?
[11:29] <sil2100> Hi guys! hm,
[11:31] <sil2100> Can I get some status update on mir related work? Since currently we're not doing any daily-releases of mir and its components - do you think mir is ready for daily-releasing right now?
[11:31] <sil2100> What is the overall status?
[11:33] <tvoss_> sil2100, we are busy preparing a ppa right now
[11:33] <tvoss_> sil2100, I think once that is done, we can start working towards a daily release
[11:33] <tvoss_> say: sometime next week
[11:33] <tvoss_> makes sense?
[11:33] <sil2100> Excellent, thanks for the update
[11:33] <sil2100> Then I'll re-poke you guys in a week
[11:34] <tvoss_> sil2100, cool and thanks for asking
[11:34] <sil2100> Ah, guys/girls ;)
[11:34]  * sil2100 has a habbit of using 'guys' to address everyone in the room
[12:15] <olli> gm
[13:04] <greyback> hi guys, small question. I'm playing with mir_demo_server and clients. In VT1 I run the server. But then switching to another VT, I see just a blank screen. Ideas?
[13:06] <greyback> note I'm on saucy
[13:11] <tvoss_> greyback, ?
[13:11] <tvoss_> greyback, what do you expect to see on another vt?
[13:12] <greyback> tvoss_: another login screen
[13:12] <tvoss_> greyback, hmm, that shouldn't be gone, I'm happily using it like that right now
[13:12] <tvoss_> greyback, if you don't start mirserver as root, you cannot switch vt's
[13:12] <greyback> tvoss_: aha
[13:12] <tvoss_> tvoss_, so you might think you have switched :)
[13:13] <greyback> tvoss_: talking to yourself again :)
[13:13] <tvoss_> tvoss_, sure, as always :)
[13:13] <tvoss_> tvoss_, it's great to always win all arguments, I'm a huge fan of myself ;)
[13:14] <greyback> tvoss_: which means all clients must run as root too
[13:14] <greyback> which is fine, just while I'm testing my work
[13:14] <tvoss_> greyback, not entirely sure, I would need to check with duflu
[13:14] <tvoss_> greyback, but yeah, all root right now will work
[13:14] <greyback> tvoss_: it segv on me, server as root, client as me.
[13:15] <greyback> but not big deal right now. I've enough to work with
[13:15] <greyback> thanks
[13:15] <tvoss_> greyback, ack
[13:41] <alan_g> alf: could I get you to review this? https://code.launchpad.net/~alan-griffiths/mir/dlopen-graphicsplatform/+merge/170797
[13:41] <alf> alan_g: sure
[14:12] <alf> alan_g: all good :)
[14:12] <alf> alan_g: but jenkins doesn't agree :/
[14:12] <alan_g> alf: thanks.
[14:14]  * alan_g see it is that packaging stuff he's never understood properly.
[14:55] <olli> tvoss_: kgunn ping
[14:55] <olli> are we all good? Kgunn is presenting?
[14:55] <kgunn> olli: sure
[14:56] <tvoss_> olli, dialing
[15:02] <kdub> morning, status, trying to get the n4 driver to release deleted buffers (eg, triple buffered to double buffered transition)
[15:14] <alf_> status: wrapping up the mir part of session snapshots...
[16:10] <kdub> alf_, so the basic idea for xmir multimonitor support is to negotiate the display information on behalf of xmir?
[16:11] <kdub> eg, xmir will ask to change the resolution, and we'll service that. or a hotplug will come in and we'll notify xmir
[16:13] <alf_> kdub: right, that's the grand plan (C), as a first step we will let xmir handle event but we will implement the decision. So xmir will catch hotplug, read configuration, and send us the configuration to apply.
[16:14] <kdub> ah, so the hotplug goes to xmir
[16:16] <kdub> seems some resizing work is needed too
[16:16] <alf_> kdub: I guess, to begin with, we can destroy/recreate surfaces?
[16:17] <kdub> i mean, should be easy enough to pop a new swapper with new buffers in there
[16:18] <kdub> just don't see the scenario we'd need for doing that atm :)
[16:30] <alan_g> alf_: kdub: I'm off on vacation next week (back following Tuesday). Anything you from me need before then?
[16:31] <alf_> alan_g: no, enjoy your vacation!
[16:31] <kdub> yep, have a good time
[16:32] <mterry> racarr, heyo.  So do you have any pointers except for gdb tracing for trying to figure out my mir connection issue?  (client can't see demo server)
[16:33] <mterry> racarr, or is it expected that running with the nvidia hack would screw things up?
[16:33] <alan_g> If anyone has time to double check the install/package changes in dlopen-graphicsplatform  before I go it would give me peace of mind. (As I'm not 100% sure what correct looks like.)
[16:36] <racarr> mterry: Not really, we hve some logging options, etc but if connecting isn't working
[16:36] <racarr> they seemingly aren't
[16:36] <racarr> it seems like it must be the nvidia hack
[16:36] <racarr> butttttttt
[16:36] <racarr> Not sure how
[16:38] <mterry> racarr, I had hoped that our reference device would work better.  :-/
[16:38] <mterry> stupid nvidia
[16:38]  * mterry kicks a pebble
[16:39]  * kdub thought using the 'nvidia hack' was a thing of the past
[16:40] <kdub> mterry, iirc, the nvidia hack just skips over shared process mutexes, so the nvidia driver would explode if both server/client are hybrisized
[16:41] <racarr> That could be it!
[16:41] <racarr> XD, I didn't know what the nvidia hack was ;)
[16:41] <racarr> mterry: You may be able to run the inprocess shell
[16:41] <racarr> oh right but you cant :(
[16:42] <mterry> kdub, mir_demo_server crashes without the hack
[16:42] <kdub> mterry, are you still moving that hwcomposer.so file so mir can't find it?
[16:43] <mterry> kdub, um...  Shoot maybe I didn't this time
[16:44] <kdub> yeah, at the moment, i'd recommend no nvidia hack, and move the hwcomposer.*.so to force mir to use the fb device instead of hwc
[16:44] <kdub> apparently the n7 hwc doesn't hybrisize well
[16:48] <racarr> XD. I'm worried this will one day devolve in to
[16:48] <racarr> NVIDIA_HACK_0=0 NVIDIA_HACK_1=1 NVIDIA_HACK_2=0...
[16:48] <racarr> lol
[16:49] <kdub> its probably okay to remove the "nvidia_hack" from hybris
[16:54] <alf_> all: Have a great weekend
[16:56] <racarr> See ya! you too
[20:40] <kgunn> ok...going to tread back onto trying xmir & figuring out why in the heck it wants old boost libs