[00:08] kdub_: Pong [00:08] Yay! I can boot all the way to X again! [00:10] RAOF, so, the gbm-cleanup branch is ready to go from the mir side [00:11] And you'd like a review? [00:11] i guess I'm just trying to figure out how to land the mesa cleanup without disrupting too many people :) [00:11] Which mesa cleanup? Have I accidentally merged something that breaks the world? [00:12] well, that mp for mesa probably will break things if its pushed to the package [00:12] Oh, really? It didn't look like it, but I didn't actually test that :) [00:13] ah, well then I should just land ~kdub/mir/gbm-cleanup and everything will be ok then [00:15] It probably isn't in the mesa packaging yet, though; it got merged to egl-platform-mir, which requires an extra step. [00:15] RAOF, right, i suspect that the packaging hasn't picked up the change [00:15] I can make it so that the packages will do the right thing though. [00:17] RAOF, well, i guess lets do that [00:17] Yeah. [00:17] and then land gbm-cleanup right after they hit the ppa [00:18] really, i think "native_display.h" should probably be 'upstreamed' out of mir at some point [00:55] RAOF, close to my eod, should we do the transition tomorrow? [00:55] kdub_: I can probably walk it through myself. [00:56] It's just landing gbm-cleanup and the mesa changes at the same time, right? [00:56] right [00:57] Yeah, I can do that. [00:57] Oh. [00:57] Can you push a commit to gbm-cleanup bumping the version to 0.0.4? If not, I'll do that. [00:58] ah, sure [01:04] RAOF, done [01:04] bitchn. [01:35] kgunn: Got more details for https://bugs.launchpad.net/mir/+bug/1191937 ? [01:35] Launchpad bug 1191937 in Mir "loss of x acceleration when xmir is loaded" [Critical,Triaged] [01:36] duflu: only details i have are...bregma was able to run xmir on an intel core w/ amd gpu [01:36] it was super slow, and dash is opaque [01:36] i believe he's still running it....if you needed debug/log info [01:37] kgunn: Erm, sounds like Unity falling back rather than Mir. Maybe like https://bugs.launchpad.net/nux/+bug/1066764 [01:37] Launchpad bug 1066764 in Nux "Unity fails to load on old hardware (compiz enabling LLVMpipe has no effect and Mesa tries to use hardware still)" [High,In progress] [01:39] duflu: could be....altho (this may be a bad assumption on my part) gpu acceleration was there [01:39] prior to loading xmir [01:39] bregma ? ^ [01:39] bregma? If you have details please add to https://bugs.launchpad.net/mir/+bug/1191937 [01:39] Launchpad bug 1191937 in Mir "loss of x acceleration when xmir is loaded" [Critical,Triaged] [01:40] I do not have an AMD GPU [01:40] That's good news for me :) [01:42] bregma: my bad [01:43] RAOF, are you just copying the lightdm package into the system-compositor PPA? [01:53] robert_ancell: Yes. [02:00] 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] 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] Not super useful :) [02:15] done and attached [02:16] opening a terminal and using the Unity switcher are painfully slow, more signs of missing hardware acceletration [02:16] but flash games run OK in the browser :) === fdr is now known as rafaelfdr [02:22] Right. As I suspected, it's a permissions issue on /dev/dri/* === rafaelfdr is now known as fdr [02:28] 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:28] Launchpad bug 1191937 in Mir "loss of x acceleration when xmir is loaded" [Critical,Triaged] [02:29] RAOF, lightdm doesn't set any permissions - we did see similar issues when console kit support wasn't working [02:29] I guess that's what I mean. [02:30] and the sympton for that was random session behaviour and erorrs in .xsession-errors [02:31] 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] RAOF, so it changes permissions on VT switch? [02:34] Correct. [02:34] Oh. [02:34] I see where you're going here :) [02:35] RAOF, well, that shouldn't matter for the single login case because there is no VT switch [02:35] Except that it might not set the permissions *at all* if you don't VT switch? [02:35] and it's normal for the session to be run by the lightdm user, then the user of the session logged into [02:35] 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] RAOF, so my current /dev/dri is root.video after booting using xmir [02:36] Is that what you expect? [02:37] robert_ancell: How about getfacl /dev/dri/card0? [02:37] Because *that's* got user:chris:rw- [02:37] # file: dev/dri/card0 [02:37] # owner: root [02:37] # group: video [02:37] user::rw- [02:37] group::rw- [02:37] other::--- [02:38] Hm. Ok. [02:38] And you presumably don't have any acceleration. [02:38] It seems laggily so [02:38] What is it on a normal boot? [02:39] I'm in a normal boot, and mine contains user:chris:rw- [02:39] RAOF, I can't see anything in the consolekit source that might change this [02:40] or GDM [02:40] I know that *something* applies the correct ACL for the user of the active VT. [02:40] udev? [02:40] I'm pretty sure that's consolekit (when we're using consolekit, obviously) [02:40] udev doesn't know anything about VT switching. [02:40] which we aren't anymore [02:41] Right. Which would presumably be why XMir works for me; I'm on Saucy. [02:41] RAOF, but how would the ownership changes be synchronised? [02:41] Oh, are you on saucy now? [02:41] yes [02:41] Hm. And it still doesn't work. Odd. [02:41] RAOF, this is from a fresh boot, It seems accelerated if I stop lightdm, then start it with xmir [02:43] kgunn, are you restarting lightdm from a console or changing lightdm.conf and restarting your machine? [02:44] robert_ancell: so first i try restart lightdm from the console....which just results in the blinking cursor (x console? ) [02:44] then i restart [02:45] (hard boot) [02:45] note, i'm on saucy as well [02:46] when i say "first i try"...meaning right after i change lightdm.conf [02:46] and the hard boot results in the "you're running in low gfx mode" [02:48] Hm, ok. [02:48] I'll let these builds finish and then see if I can reproduce. [02:49] not sure if i said this...but i'm only toggling the lightdm.conf type=unity [02:49] kgunn: Are you running from ppa:mir-team/staging or from ppa:mir-team/system-compositor-testing? [02:49] RAOF: today...changed to the system-compositor-testing [02:50] (which i understand is supposed to be a stable collection) [02:50] (vs the staging that is) [02:51] Correct. [02:51] Ok. I'll pull from there, and see what falls out. [02:52] robert_ancell: Does the lightdm in the archive handle type=unity? [02:52] RAOF, no [02:53] Ok. So we need to bump the version of lightdm in the PPAs so that it supersedes the archive version. [02:53] kgunn: What does ‘apt-cache policy lightdm’ say+ [02:53] ? === jono is now known as Guest3821 [03:10] RAOF: 1.7.2-0ubuntu1 [03:11] Right. That's why yours isn't working. That version of lightdm doesn't know how to XMir. [03:13] is 1.7.0 the only version? [03:14] RAOF: so i'm confused....shouldn't the system-compositor-testing ppa be dictating my lightdm version? [03:15] Only if you've done the apt-pinning dance. [03:15] 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] kgunn, we should be on 1.7.2 but it looks like jenkins is not CI/autolanding LightDM at the moment [03:22] robert_ancell: confused by your statement....i am on 1.7.2.... [03:22] kgunn, you said " is 1.7.0 the only version" [03:23] Right, but the autolanding infrastructure should be autolanding 1.7.2+mir bits into the staging PPA. [03:23] RAOF, yeah, but it appears it's not anymore [03:25] duflu, have you ever checked the lightdm logs after it fails to start? [03:26] 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] robert_ancell: Working through morning jobs and getting xmir on saucy yet [03:26] I haven't used xmir for some... months :) [03:26] kgunn: lightdm trunk + lightdm patches for mir. [03:27] kgunn, more specifically - lp:~mir-team/lightdm/unity is the branch that has the unity (i.e. mir) support [03:27] RAOF: robert_ancell: thanks...making sense [03:28] robert_ancell: hence your point, ci not picking it up...so whatever is in the ppa is probably old (?) [03:28] duflu, ok. That bug has quickly become a "me to" bug for any issue in plymouth/lightdm/xmir/unity-system-compositor [03:28] not starting [03:28] kgunn, it's one version old [03:30] 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] robert_ancell: In XMir? [03:31] yes [03:31] 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] However that sounds a lot like the launcher misrendering that I've experienced with llvmpipe. [03:32] RAOF, http://imgur.com/S7Ei9iK [03:33] Yup, that's some crazy interaction between llvmpipe, compiz, and damage. [03:34] 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] ok [03:35] RAOF, why is llvmpipe running? I guess I'm not accelerated? [03:36] Yeah, that would be why. [03:37] RAOF, approved - you better land it before the existing trunk is built otherwise it wont make any difference... [03:38] robert_ancell: Whyso? Oh. [03:39] * RAOF hadn't noticed duflu approving the old branch. [03:40] Ok. I've un-approved kdub's gbm-cleanup, and it looks like I've done that before the autolander kicked in. [03:46] see you guys tomorrow [03:47] Bye kgunn [03:47] robert_ancell: I assume that's an important branch if only one reviewer :) [03:50] duflu: It's the branch that got previously reviewed, plus 2 trivial commits. [03:50] RAOF: Oh. I recommend setting the prerequisite field in future to clarify that in LP [03:51] Ok. Does that tell everyone “this should land *in stead of* the prerequisite branch”? [03:57] RAOF: Nah, no such option :/ [03:57] But mebbe at least reject the old one first :) [03:58] Otherwise some idiot like me might review and approve it [03:58] :) [04:21] 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] And it never lists 'lightdm' but the greeter still works [04:22] Does the greeter try to open /dev/dri? [04:22] I wouldn't expect so. [04:22] RAOF, so it's only once you try and open a GL app basically? [04:23] also, note it added me even though I hadn't logged in [04:24] It only *matters* once you try to open a GL app (as non-root) [04:24] 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] Ok. Without rebooting, everything works fine. [04:28] But then again, I still have the correct acl set. [04:28] Somehow. [04:35] Hm. And XMir works fine for me! [04:35] (Modulo the not-starting-on-boot-correctly bit, which I can now reproduce) [04:38] Huh. Possibly because I still have consolekit installed. [04:41] 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] RAOF, no, what would you like to send? [04:42] I'd like to enable error reporting :) [04:42] Because the default appears to be "log nothing" [04:43] I was wondering why /var/log/lightdm/unity-system-compositor.log always seemed to be empty! [04:45] Oh, that's right. There's no autolanding happening for lightdm/unity. [04:54] Huh. [04:55] RAOF, I've pinged QA about that, hopefully will be sorted when Martin awakes [04:55] RAOF, please do enable reporting! [04:56] RAOF, did you see what happened when it wasn't starting on boot?) [04:56] I haven't enabled the reporting yet, I was trying to reproduce the no-permissions problem. [05:00] laters [05:16] good morning :) [05:17] RAOF, ping [05:17] tvoss: Pong [05:17] RAOF, hey there :) how is it going? [05:17] Pretty well. [05:17] RAOF, I retriggered builds for some of the packages in system-compositor-testing yesterday, we were hitting a broken builder [05:18] Ah, ok. That's why i386 was built this morning :) [05:18] Thanks! [05:18] RAOF, yw :) however, I'm hitting the plymouth issue with both ppas and unity is running unaccelerated [05:19] RAOF, I can, however, get an accelerated variant in some hackish way [05:19] So, I'm reproducing the unaccelerated bit. [05:19] Which is really odd. [05:19] *Sometimes* when starting lightdm it'll remove you from the acl on /dev/dri/*, which breaks acceleration. [05:20] RAOF, I love these issues [05:20] * duflu thinks tvoss loves the wrong things about life [05:20] The first couple of times everything worked! [05:20] RAOF, so the point is: my hackish way to get acceleration is by _not_ restarting after installation but just restarting lightdm [05:20] tvoss: Yep that's what I've been doing since January :/ [05:21] Yeah, that should work. Also logging in to a VT and starting lightdm should *sometimes* work. [05:21] RAOF, I *think* lightdm tries to signal plymouthd in some way and does not succeed [05:21] I'm not sure what conditions are required for that to work. Maybe having an ssh connection? [05:21] RAOF, nope, I'm switching to a VT and call sudo service lightdm restart [05:23] Even after a reboot that should sometimes work. [05:23] But sometimes not! [05:23] RAOF, where is the race then? [05:23] RAOF, any gut feeling? [05:24] 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] I was talking about the unaccelerated bits. [05:24] RAOF, let me know if I can help :) I'm pretty fluent in resurrecting my system now [05:24] @unaccelerated: that's weird, why could that even happen? lightdm is setting us up for accel, right? [05:25] No, ish. [05:25] * tvoss branches kwin [05:25] RAOF, ish :) [05:26] 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] at interacts with lightdm, obviously, as lightdm is doing the login bity. [05:27] RAOF, hmmm ... [05:28] 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] (if you run getfacl /dev/dri/card0 you'll get user:tvoss:rw- in the output if everything's working) [05:29] duflu: Yes. Because the alternative is that unity-system-compositor inexplicably segfaults whenever libmirserver changes ABI, which is frequently. [05:29] duflu, that's why we have system-compositor-testing, which is a "snapshot" of staging that avoids that problem [05:30] RAOF: Oh yes. I forgot it depends on the less-settled libmirserver rather than client [05:32] * duflu changes PPAs then [05:43] RAOF: Umm, Jenkins just marked this as complete. Is it really? https://bugs.launchpad.net/mir/+bug/1130553 [05:43] Launchpad bug 1130553 in Mir "Mir does not support eglSwapInterval(0)" [Medium,Fix committed] [05:44] Once the corresponding mesa has built, yes. [05:50] 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] tvoss: Looks like it's not exposed to EGL. [05:52] RAOF, okay, thanks [05:52] 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] RAOF, is it a huge benefit to wire it up now? [05:56] ... that is after-all the intention of buffer_age (http://www.khronos.org/registry/egl/extensions/EXT/EGL_EXT_buffer_age.txt) [06:37] RAOF: I can deduce that X-something is meant to update the DRI device perms. But what? [06:37] 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: I can deduce that X-something is meant to update the DRI device perms. But what? [06:40] 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] No, it's something to do with our login-tracking infrastructure. [06:41] Because logging in to a VT sets the acl correctly. [06:41] RAOF: Where does such infrastructure live? [06:41] logind or consolekit, I believe. [06:41] libck-connector0? [06:42] On Saucy we shouldn't be using consolekit, so logind. [06:43] Wooo! [06:44] loginctl is the command to check, I think. [06:44] Hm3. [06:44] I seem to have three login sessions, one of which does not have a SEAT attached. [06:45] 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] 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] 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] It's Zoë [06:56] -time, but I'll come back and see what's what when that's done. [07:44] RAOF, thx for the feedback :) can you ping me once back? [07:46] tvoss: Back for 20 minutes or so before the next round of Zoination. [07:47] RAOF, how can we move ahead while you are offline? Trying to get a quick tasklisk down [07:48] 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] RAOF, noted down [07:49] RAOF, got a branch up that people can get started with or is this in trunk? [07:49] 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] Hm, no branch yet. Let me push those up. [07:50] RAOF, ack [07:52] So, getting debugging info out of unity-system-compositor requires lp:~raof/mir/unity-system-compositor-commandline-passing [07:52] RAOF, cool, thanks [07:53] tvoss: No accel: https://bugs.launchpad.net/mir/+bug/1191937 [07:53] Launchpad bug 1191937 in Mir "loss of x acceleration when xmir is loaded" [Critical,In progress] [07:53] Plymouth CPU: https://bugs.launchpad.net/ubuntu/+source/plymouth/+bug/1192051 [07:53] Launchpad bug 1192051 in plymouth (Ubuntu) "plymouthd spinning at 100% CPU" [High,New] [07:53] tvoss: Also needs lp:~raof/mir/lightdm-enable-u-s-c-logging [07:53] duflu, great, thx [07:59] So, it looks like pam-systemd is responsible for setting up the seat thingies. [08:01] Hm. Or maybe not? [08:02] RAOF, who might be able to clarify here? [08:02] pitti knows systemd best, I think. [08:09] So, I think dumping the dbus traffic to org.freedesktop.login1 would be instructive. [08:09] RAOF, cool [08:14] alan_g, ping [08:19] Gargh, logind. [08:19] VT != session. [08:27] 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] alf: I did have that bug Alan fixed but haven't tested the fix since it landed(?) [08:28] alf: Also I logged: https://bugs.launchpad.net/mir/+bug/1189770 [08:28] Launchpad bug 1189770 in Mir "[regression] Killing Mir with Ctrl+C often leaves the screen blank and difficult to recover " [High,New] [08:29] alf: The client's meant to hang right? So you mean your host hangs? [08:30] duflu: my whole system hangs, sometimes I can't even ssh :/ [08:30] alf: I did see one intel GPU hang kernel message (and actual hang) today [08:30] But only one [08:30] on saucy [08:31] 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] or src/seat-unity.c ;) [09:00] question: [09:00] g 21 [09:00] (hello!) [09:01] I am checking the demo_client_accelerated.cpp [09:01] there's no MirDisplay or something? you create windows using egl (EGLDisplay) and pass the egl surface to mir? [09:04] it seems that the client does the rendering using EGL :s but I might be wrong [09:10] hikiko: "Window" creation: surface = mir_connection_create_surface_sync(connection, &request_params); [09:11] oh yes there's MirSurface :) sorry! [09:26] Aha! [09:26] get_seat_from_display in systemd/login/pam-module.c [09:27] alan_g, RAOF is looking into the issue, too [09:27] * alf just recovered from another saucy graphics crash... [09:28] tvoss: should be move discussion where he can see it? [09:28] *we [09:28] alan_g, sure [09:28] alf: Just saw: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/761065/comments/86 [09:28] Launchpad bug 761065 in linux (Ubuntu Natty) "[Sandybridge] Spurious "*ERROR* Hangcheck timer elapsed... blt ring idle" messages in dmesg when using compiz" [Medium,Fix released] [09:28] RAOF: Oh good. I was trying to learn about "seats" and systemd [09:30] alan_g, the discussion is open here: https://bugs.launchpad.net/lightdm/+bug/1191937 [09:30] Launchpad bug 1191937 in Light Display Manager "loss of x acceleration when xmir is loaded" [Undecided,Confirmed] [09:30] 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] Hurray for new kernels and alpha distros [09:34] 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] And now, dinner. [09:38] 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] tvoss: hello [09:54] hey pitti :) [09:55] 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] pitti, RAOF had tracked it down to: 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] systemd/login/pam-module.c [09:57] tvoss: so that's the per-user-session MIR instance? that runs as the user? [09:57] or is that the system-wide compositor? [09:57] pitti, nope, that's the system-wide Mir session, being started by ligthdm [09:57] which runs as some system user? [09:57] pitti, yup [09:57] by lightdm? that sounds strange [09:58] I thought we'd have MIR running right from the start, for booting and lightdm [09:58] pitti, that's the goal, right now, it's lightdm starting Mir [09:58] pitti, for that, we have https://launchpad.net/unity-system-compositor [09:58] pitti, which takes over the seat essentially [09:58] tvoss: which user is that running as? [09:59] pitti, checking ... [09:59] tvoss: i. e. not "root" and not "martin", but it would be a system user like "lightdm" or "mir"? [09:59] pitti, yup [10:00] ok, this most likely doesn't have a PAM session [10:00] alan_g: No, stderr should be captured by the log. [10:00] and also, session tracking wouldn't really apply to this AFAICS [10:00] so it seems to me that it would be prudent to put this system user into the video group? [10:01] http://paste.ubuntu.com/5776654/ [10:02] pitti: c3 is my user XMir session, as started by lightdm. c1 is a VT login. [10:03] 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] right; we don't want ACLs for non-seat logins such as cron or ssh [10:04] RAOF: so lightdm starts a session which is basically xmir, which then starts the "real" session (like unity)? [10:04] pitti: lightdm basically starts Xservers as normal. [10:05] 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] RAOF: ah, so the concept of session tracking via observing VT switches doesn't work any more [10:07] pitti: Correct. [10:07] All the sessions run on the same VT. [10:07] mlankhorst, ping [10:09] RAOF: so I guess ATM all sessions are "active" at the same time [10:09] 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] RAOF: is there an equivalent of $DISPLAY, i. e. how does a Mir-aware program know which session it belongs to? [10:12] tvoss: pong [10:12] 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] 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] pitti: At least, it looks a lot like pam-systemd as it currently stands cannot do that. [10:13] right, that's where things go wrong [10:13] RAOF: are you sure the problem is in the PAM module? [10:14] 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] RAOF: can you accept the packages still in new? https://launchpad.net/ubuntu/precise/+queue?queue_state=0 [10:14] pitti: No, but the output of loginctl suggests that the session was set up without a VT set. [10:14] RAOF: I had thought the problem is in logind.c itself, in the actual session/seat tracking [10:15] mlankhorst: Do they need to be in main, or universe? [10:15] main [10:15] mlankhorst: They need to be in main, don't they. Cool. [10:15] pitti: We have hidden the information (clients should pass path NULL) but it is always using /tmp/mir_socket for now [10:16] No environment is used [10:16] mlankhorst: Done. [10:17] thanks! [10:17] 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] 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] Possibly both eventually. But I was trying to keep the path a secret to avoid hard-coded chaos [10:18] Indeed. [10:18] RAOF: hence my feeling that this needs to be changed in the active session tracking [10:18] Oh, we *also* need to change the active session tracking. [10:18] But we need that to support multi-user. [10:18] We need "actually associate with a seat" for it to work at all ;) [10:19] for seat, yes [10:20] RAOF: that will only cover devices which have per-seat ACLs though, like /dev/dri [10:20] not the per-session ones like audio [10:20] (or usb) [10:20] But that's ok because all sessions are treated as active :) [10:21] not really [10:21] we only want the active session to have access to audio devices, USB sticks, scanners, cameras and the like [10:21] Oh, yes. [10:21] otherwise there wouldn't be a clear "owner" of them, and concurrent access [10:21] 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] yes [10:24] RAOF: so the problem there is that the xmir process doesn't have any tty associated to it? [10:24] That is my suspicion. I haven't checked that (and it's 8:30 here, so I'm not likely to tonight :)) [10:28] RAOF: you can check the xmir process' /proc/pid/stat [10:28] the TTY is the 4th number after the state ('R') [10:29] 0, apparently. [10:29] Which should be a valid TTY. [10:29] no, it's "nothing" [10:29] that's a device number [10:29] i. e. a major/minor in one int [10:29] e. g. my bash has 34825, which is major 136, minor 9 [10:30] i. e. /dev/pts/9 [10:30] tty would be major 4, i. e. 1024+ttynumber [10:30] Ah, right. [10:30]