[00:08] <RAOF> kdub_: Pong
[00:08] <RAOF> Yay! I can boot all the way to X again!
[00:10] <kdub_> RAOF, so, the gbm-cleanup branch is ready to go from the mir side
[00:11] <RAOF> And you'd like a review?
[00:11] <kdub_> i guess I'm just trying to figure out how to land the mesa cleanup without disrupting too many people :)
[00:11] <RAOF> Which mesa cleanup? Have I accidentally merged something that breaks the world?
[00:12] <kdub_> well, that mp for mesa probably will break things if its pushed to the package
[00:12] <RAOF> Oh, really? It didn't look like it, but I didn't actually test that :)
[00:13] <kdub_> ah, well then I should just land ~kdub/mir/gbm-cleanup and everything will be ok then
[00:15] <RAOF> It probably isn't in the mesa packaging yet, though; it got merged to egl-platform-mir, which requires an extra step.
[00:15] <kdub_> RAOF, right, i suspect that the packaging hasn't picked up the change
[00:15] <RAOF> I can make it so that the packages will do the right thing though.
[00:17] <kdub_> RAOF, well, i guess lets do that
[00:17] <RAOF> Yeah.
[00:17] <kdub_> and then land gbm-cleanup right after they hit the ppa
[00:18] <kdub_> really, i think "native_display.h" should probably be 'upstreamed' out of mir at some point
[00:55] <kdub_> RAOF, close to my eod, should we do the transition tomorrow?
[00:55] <RAOF> kdub_: I can probably walk it through myself.
[00:56] <RAOF> It's just landing gbm-cleanup and the mesa changes at the same time, right?
[00:56] <kdub_> right
[00:57] <RAOF> Yeah, I can do that.
[00:57] <RAOF> Oh.
[00:57] <RAOF> Can you push a commit to gbm-cleanup bumping the version to 0.0.4? If not, I'll do that.
[00:58] <kdub_> ah, sure
[01:04] <kdub_> RAOF, done
[01:04] <RAOF> bitchn.
[01:35] <duflu> kgunn: Got more details for https://bugs.launchpad.net/mir/+bug/1191937 ?
[01:36] <kgunn> duflu: only details i have are...bregma was able to run xmir on an intel core w/ amd gpu
[01:36] <kgunn> it was super slow, and dash is opaque
[01:36] <kgunn> i believe he's still running it....if you needed debug/log info
[01:37] <duflu> kgunn: Erm, sounds like Unity falling back rather than Mir. Maybe like https://bugs.launchpad.net/nux/+bug/1066764
[01:39] <kgunn> duflu: could be....altho (this may be a bad assumption on my part) gpu acceleration was there
[01:39] <kgunn> prior to loading xmir
[01:39] <kgunn> bregma ? ^
[01:39] <duflu> bregma? If you have details please add to https://bugs.launchpad.net/mir/+bug/1191937
[01:40] <bregma> I do not have an AMD GPU
[01:40] <duflu> That's good news for me :)
[01:42] <kgunn> bregma: my bad
[01:43] <robert_ancell> RAOF, are you just copying the lightdm package into the system-compositor PPA?
[01:53] <RAOF> robert_ancell: Yes.
[02:00] <RAOF> bregma: Can you add the output of “LIBGL_DEBUG=verbose glxinfo” to that bug - that'll give some idea of what's failing. (My guess is that it's lightdm failing to set permissions on the dri device properly)
[02:06] <bregma> hmm, if I close the lid on this laptop networking goes away and never comes back, that's new...  unrelated to Mir, but new in the last couple of days...
[02:08] <RAOF> Not super useful :)
[02:15] <bregma> done and attached
[02:16] <bregma> opening a terminal and using the Unity switcher are painfully slow, more signs of missing hardware acceletration
[02:16] <bregma> but flash games run OK in the browser :)
[02:22] <RAOF> Right. As I suspected, it's a permissions issue on /dev/dri/*
[02:28] <RAOF> robert_ancell: https://bugs.launchpad.net/mir/+bug/1191937 is a “lightdm failed to set permissions to /dev/dri/* correctly” bug. I remember this happening before, and you fixed it. Do you happen to remember how? :)
[02:29] <robert_ancell> RAOF, lightdm doesn't set any permissions - we did see similar issues when console kit support wasn't working
[02:29] <RAOF> I guess that's what I mean.
[02:30] <robert_ancell> and the sympton for that was random session behaviour and erorrs in .xsession-errors
[02:31] <RAOF> ConsoleKit would also be setting up the permissions for /dev/dri; they're meant to be rw- for the active session, and --- for everyone else.
[02:34] <robert_ancell> RAOF, so it changes permissions on VT switch?
[02:34] <RAOF> Correct.
[02:34] <RAOF> Oh.
[02:34] <RAOF> I see where you're going here :)
[02:35] <robert_ancell> RAOF, well, that shouldn't matter for the single login case because there is no VT switch
[02:35] <RAOF> Except that it might not set the permissions *at all* if you don't VT switch?
[02:35] <robert_ancell> and it's normal for the session to be run by the lightdm user, then the user of the session logged into
[02:35] <RAOF> Actually, I don't know whether it changes permissions on VT switch, or whether you can tell it that the current VT is where the logged in user is.
[02:36] <robert_ancell> RAOF, so my current /dev/dri is root.video after booting using xmir
[02:36] <robert_ancell> Is that what you expect?
[02:37] <RAOF> robert_ancell: How about getfacl /dev/dri/card0?
[02:37] <RAOF> Because *that's* got user:chris:rw-
[02:37] <robert_ancell> # file: dev/dri/card0
[02:37] <robert_ancell> # owner: root
[02:37] <robert_ancell> # group: video
[02:37] <robert_ancell> user::rw-
[02:37] <robert_ancell> group::rw-
[02:37] <robert_ancell> other::---
[02:38] <RAOF> Hm. Ok.
[02:38] <RAOF> And you presumably don't have any acceleration.
[02:38] <robert_ancell> It seems laggily so
[02:38] <robert_ancell> What is it on a normal boot?
[02:39] <RAOF> I'm in a normal boot, and mine contains user:chris:rw-
[02:39] <robert_ancell> RAOF, I can't see anything in the consolekit source that might change this
[02:40] <robert_ancell> or GDM
[02:40] <RAOF> I know that *something* applies the correct ACL for the user of the active VT.
[02:40] <robert_ancell> udev?
[02:40] <RAOF> I'm pretty sure that's consolekit (when we're using consolekit, obviously)
[02:40] <RAOF> udev doesn't know anything about VT switching.
[02:40] <robert_ancell> which we aren't anymore
[02:41] <RAOF> Right. Which would presumably be why XMir works for me; I'm on Saucy.
[02:41] <robert_ancell> RAOF, but how would the ownership changes be synchronised?
[02:41] <RAOF> Oh, are you on saucy now?
[02:41] <robert_ancell> yes
[02:41] <RAOF> Hm. And it still doesn't work. Odd.
[02:41] <robert_ancell> RAOF, this is from a fresh boot, It seems accelerated if I stop lightdm, then start it with xmir
[02:43] <robert_ancell> kgunn, are you restarting lightdm from a console or changing lightdm.conf and restarting your machine?
[02:44] <kgunn> robert_ancell: so first i try restart lightdm from the console....which just results in the blinking cursor (x console? )
[02:44] <kgunn> then i restart
[02:45] <kgunn> (hard boot)
[02:45] <kgunn> note, i'm on saucy as well
[02:46] <kgunn> when i say "first i try"...meaning right after i change lightdm.conf
[02:46] <kgunn> and the hard boot results in the "you're running in low gfx mode"
[02:48] <RAOF> Hm, ok.
[02:48] <RAOF> I'll let these builds finish and then see if I can reproduce.
[02:49] <kgunn> not sure if i said this...but i'm only toggling the lightdm.conf type=unity
[02:49] <RAOF> kgunn: Are you running from ppa:mir-team/staging or from ppa:mir-team/system-compositor-testing?
[02:49] <kgunn> RAOF: today...changed to the system-compositor-testing
[02:50] <kgunn> (which i understand is supposed to be a stable collection)
[02:50] <kgunn> (vs the staging that is)
[02:51] <RAOF> Correct.
[02:51] <RAOF> Ok. I'll pull from there, and see what falls out.
[02:52] <RAOF> robert_ancell: Does the lightdm in the archive handle type=unity?
[02:52] <robert_ancell> RAOF, no
[02:53] <RAOF> Ok. So we need to bump the version of lightdm in the PPAs so that it supersedes the archive version.
[02:53] <RAOF> kgunn: What does ‘apt-cache policy lightdm’ say+
[02:53] <RAOF> ?
[03:10] <kgunn> RAOF: 1.7.2-0ubuntu1
[03:11] <RAOF> Right. That's why yours isn't working. That version of lightdm doesn't know how to XMir.
[03:13] <kgunn> is 1.7.0 the only version?
[03:14] <kgunn> RAOF: so i'm confused....shouldn't the system-compositor-testing ppa be dictating my lightdm version?
[03:15] <RAOF> Only if you've done the apt-pinning dance.
[03:15] <RAOF> I've made it so that all the XMir bits have a higher version than what's in the archive, but I don't have the ability to do the same for lightdm.
[03:18] <robert_ancell> kgunn, we should be on 1.7.2 but it looks like jenkins is not CI/autolanding LightDM at the moment
[03:22] <kgunn> robert_ancell: confused by your statement....i am on 1.7.2....
[03:22] <robert_ancell> kgunn, you said " is 1.7.0 the only version"
[03:23] <RAOF> Right, but the autolanding infrastructure should be autolanding 1.7.2+mir bits into the staging PPA.
[03:23] <robert_ancell> RAOF, yeah, but it appears it's not anymore
[03:25] <robert_ancell> duflu, have you ever checked the lightdm logs after it fails to start?
[03:26] <kgunn> RAOF: robert_ancell ...when you say "1.7.2+mir bits"....do you mean lightdm trunk + lightdm patches just for mir ? or something else ?
[03:26] <duflu> robert_ancell: Working through morning jobs and getting xmir on saucy yet
[03:26] <duflu> I haven't used xmir for some... months :)
[03:26] <RAOF> kgunn: lightdm trunk + lightdm patches for mir.
[03:27] <robert_ancell> kgunn, more specifically - lp:~mir-team/lightdm/unity is the branch that has the unity (i.e. mir) support
[03:27] <kgunn> RAOF: robert_ancell: thanks...making sense
[03:28] <kgunn> robert_ancell: hence your point, ci not picking it up...so whatever is in the ppa is probably old (?)
[03:28] <robert_ancell> duflu, ok. That bug has quickly become a "me to" bug for any issue in plymouth/lightdm/xmir/unity-system-compositor
[03:28] <robert_ancell> not starting
[03:28] <robert_ancell> kgunn, it's one version old
[03:30] <robert_ancell> RAOF, do you get a purple box where the launcher should be (if launcher set to autohide) that redraws if you move the mouse over it?
[03:30] <RAOF> robert_ancell: In XMir?
[03:31] <robert_ancell> yes
[03:31] <RAOF> Not last time I tried, but all my builds have now finished and I'm in the process of switching to XMir. So, I can give you an answer soon :)
[03:32] <RAOF> However that sounds a lot like the launcher misrendering that I've experienced with llvmpipe.
[03:32] <robert_ancell> RAOF, http://imgur.com/S7Ei9iK
[03:33] <RAOF> Yup, that's some crazy interaction between llvmpipe, compiz, and damage.
[03:34] <RAOF> robert_ancell: Care to review/approve https://code.launchpad.net/~raof/mir/gbm-cleanup-extra/+merge/169972 ? It's a couple of packaging commits on top of https://code.launchpad.net/~kdub/mir/gbm-cleanup/+merge/169306, which has already been approved.
[03:35] <robert_ancell> ok
[03:35] <robert_ancell> RAOF, why is llvmpipe running? I guess I'm not accelerated?
[03:36] <RAOF> Yeah, that would be why.
[03:37] <robert_ancell> RAOF, approved - you better land it before the existing trunk is built otherwise it wont make any difference...
[03:38] <RAOF> robert_ancell: Whyso? Oh.
[03:39]  * RAOF hadn't noticed duflu approving the old branch.
[03:40] <RAOF> Ok. I've un-approved kdub's gbm-cleanup, and it looks like I've done that before the autolander kicked in.
[03:46] <kgunn> see you guys tomorrow
[03:47] <duflu> Bye kgunn
[03:47] <duflu> robert_ancell: I assume that's an important branch if only one reviewer :)
[03:50] <RAOF> duflu: It's the branch that got previously reviewed, plus 2 trivial commits.
[03:50] <duflu> RAOF: Oh. I recommend setting the prerequisite field in future to clarify that in LP
[03:51] <RAOF> Ok. Does that tell everyone “this should land *in stead of* the prerequisite branch”?
[03:57] <duflu> RAOF: Nah, no such option :/
[03:57] <duflu> But mebbe at least reject the old one first :)
[03:58] <duflu> Otherwise some idiot like me might review and approve it
[03:58] <RAOF> :)
[04:21] <robert_ancell> RAOF, those dri permissions are very weird. I can confirm it doesn't have 'bob' when I'm using xmir, but it does when I'm using vanilla X. However - if I log in as 'belinda' it still only has 'bob' explicitly listed in the permissions
[04:22] <robert_ancell> And it never lists 'lightdm' but the greeter still works
[04:22] <RAOF> Does the greeter try to open /dev/dri?
[04:22] <RAOF> I wouldn't expect so.
[04:22] <robert_ancell> RAOF, so it's only once you try and open a GL app basically?
[04:23] <robert_ancell> also, note it added me even though I hadn't logged in
[04:24] <RAOF> It only *matters* once you try to open a GL app (as non-root)
[04:24] <RAOF> It should be correctly set up first, though.
[04:24]  * RAOF goes to see how u-s-c is broken on his system, now that everything's built and installed!
[04:27] <RAOF> Ok. Without rebooting, everything works fine.
[04:28] <RAOF> But then again, I still have the correct acl set.
[04:28] <RAOF> Somehow.
[04:35] <RAOF> Hm. And XMir works fine for me!
[04:35] <RAOF> (Modulo the not-starting-on-boot-correctly bit, which I can now reproduce)
[04:38] <RAOF> Huh. Possibly because I still have consolekit installed.
[04:41] <RAOF> robert_ancell: There's no way to change the parameters given to unity-system-compositor by lightdm without changing the code, is there?
[04:41] <robert_ancell> RAOF, no, what would you like to send?
[04:42] <RAOF> I'd like to enable error reporting :)
[04:42] <RAOF> Because the default appears to be "log nothing"
[04:43] <RAOF> I was wondering why /var/log/lightdm/unity-system-compositor.log always seemed to be empty!
[04:45] <RAOF> Oh, that's right. There's no autolanding happening for lightdm/unity.
[04:54] <RAOF> Huh.
[04:55] <robert_ancell> RAOF, I've pinged QA about that, hopefully will be sorted when Martin awakes
[04:55] <robert_ancell> RAOF, please do enable reporting!
[04:56] <robert_ancell> RAOF, did you see what happened when it wasn't starting on boot?)
[04:56] <RAOF> I haven't enabled the reporting yet, I was trying to reproduce the no-permissions problem.
[05:00] <robert_ancell> laters
[05:16] <tvoss> good morning :)
[05:17] <tvoss> RAOF, ping
[05:17] <RAOF> tvoss: Pong
[05:17] <tvoss> RAOF, hey there :) how is it going?
[05:17] <RAOF> Pretty well.
[05:17] <tvoss> RAOF, I retriggered builds for some of the packages in system-compositor-testing yesterday, we were hitting a broken builder
[05:18] <RAOF> Ah, ok. That's why i386 was built this morning :)
[05:18] <RAOF> Thanks!
[05:18] <tvoss> RAOF, yw :) however, I'm hitting the plymouth issue with both ppas and unity is running unaccelerated
[05:19] <tvoss> RAOF, I can, however, get an accelerated variant in some hackish way
[05:19] <RAOF> So, I'm reproducing the unaccelerated bit.
[05:19] <RAOF> Which is really odd.
[05:19] <RAOF> *Sometimes* when starting lightdm it'll remove you from the acl on /dev/dri/*, which breaks acceleration.
[05:20] <tvoss> RAOF, I love these issues
[05:20]  * duflu thinks tvoss loves the wrong things about life
[05:20] <RAOF> The first couple of times everything worked!
[05:20] <tvoss> RAOF, so the point is: my hackish way to get acceleration is by _not_ restarting after installation but just restarting lightdm
[05:20] <duflu> tvoss: Yep that's what I've been doing since January :/
[05:21] <RAOF> Yeah, that should work. Also logging in to a VT and starting lightdm should *sometimes* work.
[05:21] <tvoss> RAOF, I *think* lightdm tries to signal plymouthd in some way and does not succeed
[05:21] <RAOF> I'm not sure what conditions are required for that to work. Maybe having an ssh connection?
[05:21] <tvoss> RAOF, nope, I'm switching to a VT and call sudo service lightdm restart
[05:23] <RAOF> Even after a reboot that should sometimes work.
[05:23] <RAOF> But sometimes not!
[05:23] <tvoss> RAOF, where is the race then?
[05:23] <tvoss> RAOF, any gut feeling?
[05:24] <RAOF> Oh, you're talking about the possibly plymouth race. I guess that's going to be plymouth not dropping DRM master soon enough, but I'm rebuilding lightdm so that I can get some actual debug logs.
[05:24] <RAOF> I was talking about the unaccelerated bits.
[05:24] <tvoss> RAOF, let me know if I can help :) I'm pretty fluent in resurrecting my system now
[05:24] <tvoss> @unaccelerated: that's weird, why could that even happen? lightdm is setting us up for accel, right?
[05:25] <RAOF> No, ish.
[05:25]  * tvoss branches kwin
[05:25] <tvoss> RAOF, ish :)
[05:26] <RAOF> What *should* be happening is the login process thingy (consolekit or logind) should be setting the correct ACL on /dev/dri/* (ie: the user of the current VT should have access).
[05:26] <RAOF> at interacts with lightdm, obviously, as lightdm is doing the login bity.
[05:27] <tvoss> RAOF, hmmm ...
[05:28] <duflu> Is it right that unity-system-compositor depends on an exact version of libmirserver0? This means whenever the former fails to build, the previous build is uninstallable because libmirserver0's build number has incremented
[05:28] <RAOF> (if you run getfacl /dev/dri/card0 you'll get user:tvoss:rw- in the output if everything's working)
[05:29] <RAOF> duflu: Yes. Because the alternative is that unity-system-compositor inexplicably segfaults whenever libmirserver changes ABI, which is frequently.
[05:29] <tvoss> duflu, that's why we have system-compositor-testing, which is a "snapshot" of staging that avoids that problem
[05:30] <duflu> RAOF: Oh yes. I forgot it depends on the less-settled libmirserver rather than client
[05:32]  * duflu changes PPAs then
[05:43] <duflu> RAOF: Umm, Jenkins just marked this as complete. Is it really? https://bugs.launchpad.net/mir/+bug/1130553
[05:44] <RAOF> Once the corresponding mesa has built, yes.
[05:50] <tvoss> RAOF, can you give me a status of buffer_age, that is, take a look to what degree we have it wired up?
[05:52] <RAOF> tvoss: Looks like it's not exposed to EGL.
[05:52] <tvoss> RAOF, okay, thanks
[05:52] <duflu> That reminds me... When I wrote fingerpaint and needed single-buffering, I thought a nice alternative might be to have some client-side visibility of aging buffers. It would have been much more efficient if I knew the API would guarantee persistence of some sort...?
[05:53] <tvoss> RAOF, is it a huge benefit to wire it up now?
[05:56] <duflu> ... that is after-all the intention of buffer_age (http://www.khronos.org/registry/egl/extensions/EXT/EGL_EXT_buffer_age.txt)
[06:37] <duflu> RAOF: I can deduce that X-something is meant to update the DRI device perms. But what?
[06:37] <duflu> It can only know to do that after a user as logged in. So maybe it's a hook in the X graphics driver we broke?
[06:40] <duflu> RAOF: I can deduce that X-something is meant to update the DRI device perms. But what?
[06:40] <duflu> It can only know to do that after a user as logged in. So maybe it's a hook in the X graphics driver we broke?
[06:40] <RAOF> No, it's something to do with our login-tracking infrastructure.
[06:41] <RAOF> Because logging in to a VT sets the acl correctly.
[06:41] <duflu> RAOF: Where does such infrastructure live?
[06:41] <RAOF> logind or consolekit, I believe.
[06:41] <duflu> libck-connector0?
[06:42] <RAOF> On Saucy we shouldn't be using consolekit, so logind.
[06:43] <RAOF> Wooo!
[06:44] <RAOF> loginctl is the command to check, I think.
[06:44] <RAOF> Hm3.
[06:44] <RAOF> I seem to have three login sessions, one of which does not have a SEAT attached.
[06:45] <RAOF> So, now that I've got unity-system-compositor doing some loging, I'm going to reboot and see what's happening when it doesn't work on boot.
[06:55] <RAOF> Ok. So, unity-system-compositor dies with no output before “I0618 16:52:50.382107  2032 glog_logger.cpp:80] [graphics] Successfully setup native resources.”
[06:56] <RAOF> Also, it looks like XMir sessions get registered with logind but not associated with a seat, which is plausibly the reason for the permission problem.
[06:56] <RAOF> It's Zoë
[06:56] <RAOF> -time, but I'll come back and see what's what when that's done.
[07:44] <tvoss> RAOF, thx for the feedback :) can you ping me once back?
[07:46] <RAOF> tvoss: Back for 20 minutes or so before the next round of Zoination.
[07:47] <tvoss> RAOF, how can we move ahead while you are offline? Trying to get a quick tasklisk down
[07:48] <RAOF> tvoss: For the plymouth-doesn't-die-on-boot thing, tracing the code to see what could cause unity-system-compositor to bail *before* it would normally log “[graphics] Successfully setup native resources” would be the way to go.
[07:48] <tvoss> RAOF, noted down
[07:49] <tvoss> RAOF, got a  branch up that people can get started with or is this in trunk?
[07:49] <RAOF> For the “No accel in XMir” problem, checking the logind documentation/source to see how/where/why it doesn't set the /dev/dri/* acl.
[07:49] <RAOF> Hm, no branch yet. Let me push those up.
[07:50] <tvoss> RAOF, ack
[07:52] <RAOF> So, getting debugging info out of unity-system-compositor requires lp:~raof/mir/unity-system-compositor-commandline-passing
[07:52] <tvoss> RAOF, cool, thanks
[07:53] <duflu> tvoss: No accel: https://bugs.launchpad.net/mir/+bug/1191937
[07:53] <duflu> Plymouth CPU: https://bugs.launchpad.net/ubuntu/+source/plymouth/+bug/1192051
[07:53] <RAOF> tvoss: Also needs lp:~raof/mir/lightdm-enable-u-s-c-logging
[07:53] <tvoss> duflu, great, thx
[07:59] <RAOF> So, it looks like pam-systemd is responsible for setting up the seat thingies.
[08:01] <RAOF> Hm. Or maybe not?
[08:02] <tvoss> RAOF, who might be able to clarify here?
[08:02] <RAOF> pitti knows systemd best, I think.
[08:09] <RAOF> So, I think dumping the dbus traffic to org.freedesktop.login1 would be instructive.
[08:09] <tvoss> RAOF, cool
[08:14] <tvoss> alan_g, ping
[08:19] <RAOF> Gargh, logind.
[08:19] <RAOF> VT != session.
[08:27] <alf> RAOF: tvoss: duflu: Have you seen any problems with VT switching with Mir in saucy? Every time I try to VT switch my graphics hang... (everything worked fine in raring) :/
[08:28] <duflu> alf: I did have that bug Alan fixed but haven't tested the fix since it landed(?)
[08:28] <duflu> alf: Also I logged: https://bugs.launchpad.net/mir/+bug/1189770
[08:29] <duflu> alf: The client's meant to hang right? So you mean your host hangs?
[08:30] <alf> duflu: my whole system hangs, sometimes I can't even ssh :/
[08:30] <duflu> alf: I did see one intel GPU hang kernel message (and actual hang) today
[08:30] <duflu> But only one
[08:30] <duflu> on saucy
[08:31] <alan_g> tvoss: pong (sorry missed you)
[08:38]  * duflu wonders why we're not considering the bug to be in lightdm as he looks at the lightdm source (seating logic)
[08:42] <duflu> or src/seat-unity.c ;)
[09:00] <hikiko> question:
[09:00] <Stskeeps> g 21
[09:00] <hikiko> (hello!)
[09:01] <hikiko> I am checking the demo_client_accelerated.cpp
[09:01] <hikiko> there's no MirDisplay or something? you create windows using egl (EGLDisplay) and pass the egl surface to mir?
[09:04] <hikiko> it seems that the client does the rendering using EGL :s but I might be wrong
[09:10] <duflu> hikiko: "Window" creation:     surface = mir_connection_create_surface_sync(connection, &request_params);
[09:11] <hikiko> oh yes there's MirSurface :) sorry!
[09:26] <RAOF> Aha!
[09:26] <RAOF> get_seat_from_display in systemd/login/pam-module.c
[09:27] <tvoss> alan_g, RAOF is looking into the issue, too
[09:27]  * alf just recovered from another saucy graphics crash...
[09:28] <alan_g> tvoss: should be move discussion where he can see it?
[09:28] <alan_g> *we
[09:28] <tvoss> alan_g, sure
[09:28] <duflu> alf: Just saw: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/761065/comments/86
[09:28] <duflu> RAOF: Oh good. I was trying to learn about "seats" and systemd
[09:30] <duflu> alan_g, the discussion is open here: https://bugs.launchpad.net/lightdm/+bug/1191937
[09:30] <alf> duflu: Thanks, but this happens on radeon. This time I just tried to stop a mir client and server and the whole system froze :(, plus I can't get find any useful log messages about what happened...
[09:30] <duflu> Hurray for new kernels and alpha distros
[09:34] <RAOF> So, I think I see where it's going wrong. pam-systemd tries to do a reverse-lookup from the DISPLAY socket to the VT, and hence the seat. It does this by looking up the controlling tty of the xserver process. I don't _think_ that will be a VT in the nested case, so this fails.
[09:35] <RAOF> And now, dinner.
[09:38] <alan_g> RAOF: just been looking at failures in EGLHelper::setup (i.e. before the "Sucessfully setup" log) - the exceptions would be caught in main() and reported to std::cerr. Am I right in thinking this won't be captured?
[09:41]  * tvoss is compiling piglit :)
[09:48]  * tvoss notes: running piglits sanity tests results in unity crashing :)
[09:54] <pitti> tvoss: hello
[09:54] <tvoss> hey pitti :)
[09:55] <tvoss> pitti, we are running into an issue where hardware accel for mir as the system compositor is not working due to the acl for /dev/dri* not being setup correctly
[09:55] <tvoss> pitti, RAOF had tracked it down to: <RAOF> So, I think I see where it's going wrong. pam-systemd tries to do a reverse-lookup from the DISPLAY socket to the VT, and hence the seat. It does this by looking up the controlling tty of the xserver process. I don't _think_ that will be a VT in the nested case, so this fails.
[09:56] <tvoss> systemd/login/pam-module.c
[09:57] <pitti> tvoss: so that's the per-user-session MIR instance? that runs as the user?
[09:57] <pitti> or is that the system-wide compositor?
[09:57] <tvoss> pitti, nope, that's the system-wide Mir session, being started by ligthdm
[09:57] <pitti> which runs as some system user?
[09:57] <tvoss> pitti, yup
[09:57] <pitti> by lightdm? that sounds strange
[09:58] <pitti> I thought we'd have MIR running right from the start, for booting and lightdm
[09:58] <tvoss> pitti, that's the goal, right now, it's lightdm starting Mir
[09:58] <tvoss> pitti, for that, we have https://launchpad.net/unity-system-compositor
[09:58] <tvoss> pitti, which takes over the seat essentially
[09:58] <pitti> tvoss: which user is that running as?
[09:59] <tvoss> pitti, checking ...
[09:59] <pitti> tvoss: i. e. not "root" and not "martin", but it would be a system user like "lightdm" or "mir"?
[09:59] <tvoss> pitti, yup
[10:00] <pitti> ok, this most likely doesn't have a PAM session
[10:00] <RAOF> alan_g: No, stderr should be captured by the log.
[10:00] <pitti> and also, session tracking wouldn't really apply to this AFAICS
[10:00] <pitti> so it seems to me that it would be prudent to put this system user into the video group?
[10:01] <RAOF> http://paste.ubuntu.com/5776654/
[10:02] <RAOF> pitti: c3 is my user XMir session, as started by lightdm. c1 is a VT login.
[10:03] <RAOF> pitti: And the problem is that - if I don't have a VT session logged in - my user isn't added to the /dev/dri/* acl, because logind doesn't have it associated with a seat, and logind only sets the acls for seated-things.
[10:03] <pitti> right; we don't want ACLs for non-seat logins such as cron or ssh
[10:04] <pitti> RAOF: so lightdm starts a session which is basically xmir, which then starts the "real" session (like unity)?
[10:04] <RAOF> pitti: lightdm basically starts Xservers as normal.
[10:05] <RAOF> pitti: It's just that lightdm *first* starts the system-compositor, doesn't VT switch, and hooks all the Xservers up with unity-system-compositor.
[10:06] <pitti> RAOF: ah, so the concept of session tracking via observing VT switches doesn't work any more
[10:07] <RAOF> pitti: Correct.
[10:07] <RAOF> All the sessions run on the same VT.
[10:07] <tvoss> mlankhorst, ping
[10:09] <pitti> RAOF: so I guess ATM all sessions are "active" at the same time
[10:09] <RAOF> pitti: Correct - as you can see, both my VT session and XMir session are active, because they both happen to be on VT 1.
[10:12] <pitti> RAOF: is there an equivalent of $DISPLAY, i. e. how does a Mir-aware program know which session it belongs to?
[10:12] <mlankhorst> tvoss: pong
[10:12] <pitti> RAOF: I guess we'd need to teach logind about that method then, unless we still have $DISPLAY (that might even be enough for the XMir case)
[10:13] <RAOF> pitti: We still have $DISPLAY (as you can see from my output), but I *don't* think you can reverse map $DISPLAY to the VT it's running on.
[10:13] <RAOF> pitti: At least, it looks a lot like pam-systemd as it currently stands cannot do that.
[10:13] <pitti> right, that's where things go wrong
[10:13] <pitti> RAOF: are you sure the problem is in the PAM module?
[10:14] <pitti> RAOF: that just tries to separate the cases of "VT given" from "display given", and passes it as two separate arguments to CreateSession
[10:14] <mlankhorst> RAOF: can you accept the packages still in new? https://launchpad.net/ubuntu/precise/+queue?queue_state=0
[10:14] <RAOF> pitti: No, but the output of loginctl suggests that the session was set up without a VT set.
[10:14] <pitti> RAOF: I had thought the problem is in logind.c itself, in the actual session/seat tracking
[10:15] <RAOF> mlankhorst: Do they need to be in main, or universe?
[10:15] <mlankhorst> main
[10:15] <RAOF> mlankhorst: They need to be in main, don't they. Cool.
[10:15] <duflu> pitti: We have hidden the information (clients should pass path NULL) but it is always using /tmp/mir_socket for now
[10:16] <duflu> No environment is used
[10:16] <RAOF> mlankhorst: Done.
[10:17] <mlankhorst> thanks!
[10:17] <RAOF> We're likely to end up either with an environment variable or just a well-known path. I think we're more likely to end up with the latter.
[10:17] <pitti> RAOF: hm, so we are only ever going to have one VT for everything, we can't use the VT number to track sessions
[10:18] <duflu> Possibly both eventually. But I was trying to keep the path a secret to avoid hard-coded chaos
[10:18] <RAOF> Indeed.
[10:18] <pitti> RAOF: hence my feeling that this needs to be changed in the active session tracking
[10:18] <RAOF> Oh, we *also* need to change the active session tracking.
[10:18] <RAOF> But we need that to support multi-user.
[10:18] <RAOF> We need "actually associate with a seat" for it to work at all ;)
[10:19] <pitti> for seat, yes
[10:20] <pitti> RAOF: that will only cover devices which have per-seat ACLs though, like /dev/dri
[10:20] <pitti> not the per-session ones like audio
[10:20] <pitti> (or usb)
[10:20] <RAOF> But that's ok because all sessions are treated as active :)
[10:21] <pitti> not really
[10:21] <pitti> we only want the active session to have access to audio devices, USB sticks, scanners, cameras and the like
[10:21] <RAOF> Oh, yes.
[10:21] <pitti> otherwise there wouldn't be a clear "owner" of them, and concurrent access
[10:21] <RAOF> But for a first go, having a single user have access to those things is nice!
[10:21]  * duflu thinks these guys have it under control and goes to make dinner
[10:21] <pitti> yes
[10:24] <pitti> RAOF: so the problem there is that the xmir process doesn't have any tty associated to it?
[10:24] <RAOF> That is my suspicion. I haven't checked that (and it's 8:30 here, so I'm not likely to tonight :))
[10:28] <pitti> RAOF: you can check the xmir process' /proc/pid/stat
[10:28] <pitti> the TTY is the 4th number after the state ('R')
[10:29] <RAOF> 0, apparently.
[10:29] <RAOF> Which should be a valid TTY.
[10:29] <pitti> no, it's "nothing"
[10:29] <pitti> that's a device number
[10:29] <pitti> i. e. a major/minor in one int
[10:29] <pitti> e. g. my bash has 34825, which is major 136, minor 9
[10:30] <pitti> i. e. /dev/pts/9
[10:30] <pitti> tty would be major 4, i. e. 1024+ttynumber
[10:30] <RAOF> Ah, right.
[10:30] <pitti> my X process has 1031, i. e. tty7
[10:30] <RAOF> Yeah, no tty for xmir.
[10:31] <pitti> ok, that's a bit odd
[10:34] <pitti> RAOF, tvoss ^ so that seems strange for a process not not have any tty/pty; is that deliberate?
[10:35] <pitti> phone, brb
[10:35] <tvoss> pitti, wrong person to ask
[10:35]  * tvoss that is
[10:42] <RAOF> pitti: No, that actually seems perfectly sane - XMir doesn't open a tty, so it won't have a controlling tty.
[10:43] <RAOF> X would normally open a tty in order to do VT switching, but XMir can't do that.
[10:48] <pitti> ok, RAOF is gone
[10:49] <pitti> so, I'll make some investigations how that could happen; I'm not that proficient in that tty/pty area
[10:50] <didrocks> (told the guy knowing on which major block device numbers are using the ttys)
[10:50] <didrocks> apart if you cheater with ls -l /dev/tty7, but I would be disappointed :)
[10:57] <ogra_> note that the ubuntu touch kernels largely dont have VT support enabled
[10:57] <ogra_> (there are no /dev/yyz[0-9] at all
[10:57] <ogra_> )
[10:57] <ogra_> err
[10:57] <ogra_> tty
[12:13] <alan_g> \o/ My desktop finally booted a saucy image
[13:48] <alf> alan_g: Have you tried using clang on saucy?
[13:48] <alan_g> alf not yet
[13:49] <alf> alan_g: ok, I am getting stddef.h cannot be found errors
[13:52] <alan_g> alf: I've just got to the point of being able to build g++/naive on my desktop - will try clang next if it helps
[13:52] <alan_g> alf: just a thought - you did vape the cmake cache first?
[13:53] <alan_g> Hmm - "4 tests failed"
[13:53] <alf> alan_g: no haste, it's not blocking me, just wondering if you had seen it. I did a build in a clean dir, plus just compiling a trivial .c file fails with clang
[13:54] <alan_g> sounds like clang isn't installed correctly
[14:18] <alan_g> alf: FWIW clang compiles fine for me (tests hang of course)
[14:19] <alf> alan_g: thanks, so I guess something went wrong during the upgrade
[14:20] <alan_g> alf: I ended up repartitioning my system disk before I got saucy to boot
[14:20] <alan_g> So, for once, I've a pretty clean install
[14:21] <alf> alan_g: do you have clang 3.2 or 3.3?
[14:22] <alan_g> 3.2
[14:23] <alf> alan_g: can you please try and pastebin the output of "clang -v bla.c" (where bla.c includes eg. stdio.h)
[14:28] <alan_g> alf: https://pastebin.canonical.com/93010/
[14:29] <alf> alan_g: thanks
[14:43] <alf> alan_g: heh, just removing and reinstalling clang fixed things...
[14:50] <alan_g> alf: of course. (That's the fun of upgrades)
[15:01] <racarr> tMorning
[15:03] <kdub_> morning
[15:07] <alan_g> afternoon
[15:23] <racarr> ** DONE Land platform API...
[15:23] <racarr> that was a todo for...too long
[15:25] <tvoss> racarr, it's in? :)
[15:26] <racarr> yep, qtubuntu or today
[15:26] <racarr> for*
[15:27] <tvoss> racarr, not bad :) not bad :)
[15:59] <alf> kdub_: IIRC, at some point you proposed some noexcept changes for NiceMock/StrickMock. Any update? (I updated our internal gmock and have come across the same issues again with 4.7... 4.8 works fine without any change)
[16:07] <kdub_> alf, no, not a lot of movement upstream https://groups.google.com/forum/?fromgroups#!topic/googlemock/ZO4Q1vR7XfM
[16:08] <alf> kdub_: ok, I will apply the patch manually then
[16:40] <racarr> alan_g: Applied your suggestion (misread them the first time ;)) to https://code.launchpad.net/~robertcarr/mir/improve-input-acceptance/+merge/169483
[16:40] <racarr> if you have time for another review before EOD
[16:40] <racarr> I have to write some acceptance tests today and was hoping to use it :D
[16:40] <alan_g> racarr: sure
[16:41] <racarr> thanks :)
[17:17] <racarr> I feel like oprah on launchpad today
[17:17] <racarr> and you get an approve! and you get an approve! and you get an approve!
[17:26] <racarr> kdub_: Is there any trick for adb shell just...working weird in terms of terminal functionality? i.e. every text editor has some weird glitches
[17:26] <racarr> that make it super hard for me to edit files on the phone
[17:26] <kdub_> no, not really... unless i'm investigating kernel crashes or something, i usually ssh in
[17:27] <mterry> racarr, I'm trying to follow http://studio.sketchpad.cc/gmY0M6iqeh but ran into a problem with boost
[17:27] <racarr> mterry: Of what sort?
[17:27] <mterry> racarr, I know!  Like nano doesn't like Enter
[17:28] <mterry> racarr, I am at the ./build -s step of unity
[17:28] <mterry> racarr, and it wants to install libboost1.49-dev, which conflicts with libboost1.53-dev
[17:29] <racarr> mterry: hmm
[17:29] <racarr> I don't have an immediate guess as to why that happened...but I think
[17:29] <racarr> you could find the explicit 1.49 dependency and just make it
[17:30] <racarr> non explicit or 1.53
[17:30] <mterry> racarr, I see your platform-api change landed in trunk, but not yet the packaging changes to build with mir?
[17:30] <racarr> mterry: Thoe live in lp:~robertcarr/platform-api/mir-with-packaging
[17:31] <racarr> we are doing parallel CI
[17:31] <racarr> also you can use bzr branch lp:~unity-team/unity/phablet-integrate-mir
[17:31] <racarr> instead of phablet-tuesday now
[17:31] <racarr> XD
[17:32] <racarr> mterry: Im in the process of testing out the qtubuntu packaging build on the phone
[17:32] <racarr> but um. had to reimage my phone
[17:32] <racarr> and building everything takes a long time
[17:33] <racarr> I really enjoy this sketchpad thing
[17:33] <racarr> XD
[17:40] <mterry> racarr, ah, looks like phablet-integrate-mir needs to merge from trunk.  It has boost1.49 in its ./build script, but trunk has fixed that
[17:40] <mterry> and by trunk, I mean unity/8.0
[17:42] <racarr> ah probably
[17:42] <racarr> I dont think I am in unity-team so you will have to do it locally for now
[17:42] <racarr> mterry: ^
[17:42] <racarr> oh
[17:42] <racarr> I definitely am
[17:43] <racarr> merging and what not
[17:47] <racarr> hmm
[17:47] <racarr> I need to find a base revision manually apparently
[17:50] <racarr> hmm
[17:50] <racarr> 91 conflict
[17:50] <racarr> all time record
[17:58] <racarr> I think I don't understand bzr
[17:59] <racarr> I found a base revision but then apparently it becomes a 'reverse cherry pick' and loses branch history
[17:59] <racarr> and also I cant use weave merge
[18:04] <racarr> oh
[18:04] <racarr> I see
[18:04] <racarr> they literally have no common ancestory because its
[18:04] <racarr> a new repo
[18:04] <racarr> -.-
[18:54] <kdub_> android drivers don't like us shuffling the buffers out from underneath them while we ignore their reference requests...
[20:29] <arsson> just manage to install unity-system-compositor and unity was gone but i have two cursors
[20:30] <arsson> you do some strange thing in there :)
[20:30] <tvoss> arsson, that's expected :)
[20:30] <tvoss> arsson, raof is working on getting rid of that, it's only the hw cursor not being wired up to the X side completely, yet
[20:31] <tvoss> arsson, please note that you might be running unaccelerated X right now, too, as the acl on /dev/dri* are not setup correctly (being worked upon, too) :)
[20:31] <tvoss> arsson, which ppa did you use?
[20:31] <arsson> stagein
[20:32] <arsson> Mir staging ppa
[20:33] <tvoss> arsson, cool, thx
[20:33] <arsson> well unity-system-compositor is not installable anymore
[20:33] <arsson> that was quik
[20:34] <tvoss> arsson, yup, the components in there rev too fast, that's why we have system-compositor-testing ppa, same team
[20:36] <arsson> do i dare to try that?
[20:37] <tvoss> arsson, not yet, you should wait for the permission issue to be fixed
[20:37] <tvoss> arsson, I'm waiting for that, too :))
[20:38] <arsson> ok. lets watch porn then! :)
[20:39] <tvoss> arsson, I'd rather prefer wine, but have fun :)
[20:46] <kgunn> :)
[20:48] <kgunn> robert_ancell: anything i can do here to help debug or try
[20:49] <robert_ancell> kgunn, you get the lock up on boot right?
[20:50] <kgunn> robert_ancell: depends on definition of lock up....
[20:50] <robert_ancell> fails to get to greeter?
[20:51] <kgunn> i was getting to the little gui...."you are running in low gfx mode".....but effectively stuck there
[20:51] <kgunn> robert_ancell: for sure...fails to get greeter
[20:51] <robert_ancell> kgunn, ugh, I haven't seen that
[20:53] <robert_ancell> I'm trying to track down plymouthd using 100% CPU and the system-compositor failing to start
[20:53] <kgunn> robert_ancell: yeah...but didn't we determine i had an incompat lightdm mismatched
[20:54] <kgunn> robert_ancell: wonder if i need to ppa-purge....start fresh
[20:58]  * kdub_ was hoping we didn't have to give android drivers strong refs to their buffers... looks we do though
[20:59] <kdub_> will get rid of that weird "ensure_no_live_buffers_are_bound()" interface on mg::GLRenderer
[21:07] <kdub_> the whole 'dynamic buffers!' has been good for polishing out some rough edges of the android system
[21:08] <kdub_> maybe even one day, we'll be able to resize ;-)
[21:29] <kgunn> kdub_: don't tease
[22:39] <racarr> Hmm
[22:39] <racarr> so now when I try and build trunk I get warnings that libEGL.so may conlict withw
[22:39] <racarr> libmirclient.so
[22:39] <racarr> and then check-discover-acceptance-tests
[22:39] <racarr> crashes
[22:40] <racarr> any ideas?
[22:42] <racarr> I guess my mesa needs updating
[23:08] <kdub_> racarr, yep
[23:21] <RAOF> Mornin' all.
[23:21] <racarr> kdub_: is the mesa I need int he PPA?
[23:21] <racarr> I am having series of strange link errors
[23:22] <racarr> Morning RAOF :)
[23:22] <RAOF> racarr: Grr. Let's have a butchers.
[23:23] <racarr> blerp?
[23:23] <RAOF> “butcher's hook” → “look”
[23:24] <racarr> this seems like
[23:24] <racarr> some pretty advanced rhyming slang
[23:27] <kdub_> lets see...
[23:27] <RAOF> It's the standard double-indirect cockney rhyming slang!
[23:29] <RAOF> racarr: The mesa you need is *not* in the PPA, apparently because Launchpad hasn't noticed that libmirclient-dev 0.0.4 has built.
[23:30] <racarr> oh
[23:30] <racarr> that sounds suspiciously similar to something that would cause the link errors
[23:30] <RAOF> Stupid launchpad. It's meant to trigger when the dependencies of a dep-wait package are built!
[23:30] <racarr> I am getting
[23:31] <RAOF> Anyway, amd64 is now appears to be building, so everything should be peachy soon.
[23:32] <RAOF> racarr: What do I have to do to get unity-system-compositor to *not* appear to freeze when pressing <alt>+<left>?
[23:32] <RAOF> (Because that's going to the kernel VT subsystem, which is switching VTs, so unity-system-compositor is suspended)
[23:34] <racarr> RAOF: I think something like this
[23:34] <racarr> https://code.launchpad.net/~robertcarr/mir/disable-sequences-and-add-terminate-handler/+merge/164014
[23:34] <racarr> in particular around here
[23:34] <racarr> + int make_raw(int vt_fd)
[23:37] <RAOF> Oooh, of course.
[23:37] <RAOF> I could totally do that in u-s-c.
[23:47] <kdub_> RAOF, thanks for handling the driver bump, btw
[23:47] <RAOF> No probelm.
[23:48] <RAOF> Oh, *arse*.
[23:48] <RAOF> 0.4 ≠ 0.0.4
[23:48] <RAOF> *That's* why!