[00:00] Well, just I am trying to get all the focus policy in to one object [00:00] this object, basically, makes the assosciation, this surface is the focused one (only above this, does "focus" really exist) [00:01] and, ties up the bits to implement focus [00:02] racarr, sounds useful (although hard to say for sure...) [00:02] i.e. raises the surface when it receives focus and targets it for keyboard events. (this could be a seperate mechanism object still, not sure how helpful it really is) [00:02] mm. still hard to say XD [00:02] i'm just trying to detangle the surface ownerships [00:02] so the problem is [00:02] some surface is focused [00:02] and it's destroyed [00:02] how does this object know to choose a new mechanism for focus [00:03] err [00:03] a new surface [00:03] I don't want to [00:03] pass this object down through the session manager and session like before, and have the those bits contain the logic [00:04] like, just floating up the factories and untangling the objects ownerships, i'm starting to see how it'll happen [00:04] "when surface is destroyed, focus the last surface", etc [00:04] still too early to say though [00:04] so I am wondering about [00:04] some sorst of change_callback system [00:04] it kinda feels like those zelda levels, where if you go in the wrong door, you have start the maze over at this point in time [00:04] to mirror what we have on the graphics side... [00:05] Haha. yeah .... [00:05] racarr, that makes sense [00:05] the callback for input [00:05] I guess I am just brought it up because it kind of ties in to the EventSink bits...how do various portions of msh:: notify eachother [00:05] on shell side state changes [00:07] I just had a crazy idea [00:07] the FocusArbitrator/Setter/Whatever [00:08] could hand out like... [00:08] surface->receive_focus(std::unique_ptr)... [00:08] and the destructor knows what to do [00:11] well, what if you want to get that token back though [00:11] like, a manual reassignment of focus [00:11] kdub: std::move XD [00:12] I'm not sure... [00:14] I find a certain appeal to this but may jjust have C++ addiction [00:20] Not *every* problem needs to be modelled in the type system :) [00:20] But it does have a certain charm. Also parallels desrt's focus-stealing-prevention idea. [00:21] it's a nice way to be explicit about the signalling needed (surface destroyed) [00:21] I think without clogging up other listener interfaces, or using generic change callbacks [00:21] etc [00:21] which will end up with more coupling [00:21] but im still not sure [00:21] I think ill let it stew until tomorrow [00:22] So, how close are we to having a "focus-gained" and "focus-lost" signal on our surfaces? [00:22] well [00:22] the session_listener has [00:22] focused and unfocused [00:22] and the EventSink will probably give them eventually [00:23] I dunon that's the thing though, we don't really want signals so to speak [00:23] i.e. this same problem could be solved by having the focus bit do [00:23] Let me rephrase: at what point will XMir be able to tell when it's not focused, and give up input? [00:23] surface.subscribe_to_signal("about_to_close" [00:23] now! [00:23] oh [00:23] I made that up [00:23] Woo! How! [00:23] soon [00:23] Oh ☹ [00:23] no I made that up ignore me [00:23] XD [00:23] if xmir needs that [00:23] I can finish it soon [00:24] well [00:24] xmir does need that [00:24] Only if you'd like to be able to switch sessions without all sessions getting all input :) [00:27] RAOF: *shrug* I'm not too picky [00:45] hey guys, what's required to run openarena on mir? [00:45] is there a custom build somewhere? [00:53] Does that just need SDL? [00:53] Or do you want to run it in XMir? [00:54] thomi, it should work on Mir with the SDL package in the ppa (I haven't tried yet though) [00:54] tried openarena that is [00:56] ok, I'll give that a go [00:56] RAOF: I'll tackle xmir soon [00:56] just mir right now [01:57] duflu: I don't think I can drop the varargs annoyance in the open() wrapper. Or, at least, I don't think I want to. [01:57] RAOF: Oh? Why not? [01:58] If I drop it, it no longer interposes. [01:58] RAOF: In C/C++, the caller determines how many parameters to pass. It can be any number. So to assume it is 2 or 3 is pretty simple and safe [01:58] I suspect it's because it no longer matches the prototype in the libc header, so doesn't get the symbol version applied, so the linker doesn't consider it. [01:58] RAOF: That's weird. I suggest it's maybe because it's got C++ linkage and needs C. Look at "nm" [01:59] RAOF: Yeah just do an 'extern "C"', or put it in a C file [02:00] I'm pretty sure I checked. [02:01] Oh, except that I may have had the ‘please demangle my symbols’ option enabled... [02:01] Which would somewhat defeat the purpose of that check :) [02:18] RAOF: Yeah don't use the -C option. Just nm -D [02:28] Why do we make it so hard to set an environment variable in a CMake test? [02:28] Ahhhh why can't we keep trunk stable enough to build any more? [02:28] It's a new FTBFS every day [02:39] duflu, why are you still consuming mir on raring? [02:40] robert_ancell, because that's my desktop. Hence much faster to do some jobs [02:40] ... than the suacy laptops [02:40] *saucy [02:40] duflu, well, it's just wasting time fixing bugs in raring [02:41] robert_ancell, It's not a waste if other distros get the same errors, and they are real errors in our code [02:41] It would be nice to catch them before they land, is all [02:41] duflu, just require those other distros to use gcc 4.8. It's not a difficult dependency [02:41] robert_ancell, I think that would be arrogant of us. If the fix to support existing compilers is simple [02:42] duflu, that's not arrogant - all dependencies have minimum versions. It's not a problem to apply patches if someone else takes the time to find them but we have no need to [02:42] Supporting multiple platforms/archs/environments is the single easiest way to build code quality, because each new one will show you errors you previously missed [02:43] disagree [02:43] I know this from experience. Supporting up to 15 platform combos at once [02:45] Bah, we can argue about "easiest" forever [02:46] Can I get a review on https://code.launchpad.net/~robert-ancell/lightdm/unity-sys-comp-release-vt2/+merge/171190? [02:47] * duflu fears the number of code reviews he's now got involved in and needs to chase up today [02:49] duflu, :) [02:55] Um, why do we have a hunk of parsing code to emit CTest test files? [02:55] Rather than just using add_test? [03:11] duflu, in that fix you made for plymouth you call 'plymouth deactivate' every time in the loop - was that intentional? [03:12] robert_ancell: Yes but now you mention it, it could probably only happen once [03:12] There's no reason to repeat it [03:12] ok, cool [03:12] robert_ancell: That's the result of many iterations. You get leftovers of previous algorithms [03:12] heh [03:15] RAOF: Was it feasible to resolve the libdrm_radeon issue? (https://launchpad.net/~mir-team/+archive/staging/+build/4741584) [03:16] Eh, screw it. I'll just copy saucy's libdrm into the PPA for you :) [03:26] duflu, I'm looking at the plymouth source and it does appear to block on deactivate correctly [03:26] duflu, are you sure that was causing the problem? [03:26] robert_ancell: Yes, absolutely. The lightdm log shows it has to try twice before success [03:27] And inserting a sleep works also :) [03:34] duflu, hmm, I think it only works because of the sleep - the termination condition is !plymouth_has_active_vt() - but that only contacts Plymouth once [03:34] So effectively all the patch has done is add a sleep(1) [03:34] robert_ancell, I also clear the cache to force it to contact each time [03:35] duflu, ah, missed that [03:35] So that part is working [03:35] And I get two attempts logged in my lightdm.log [03:35] So it takes somewhere inside a second to complete [03:37] robert_ancell: We could enhance plymouth to honour --wait with deactivate, or just not crash. But I figured we in too much hurry to corrdinate fixes across multiple projects and add new ones to the PPA [03:37] -"not crash" +"not spin" [03:37] duflu, yeah, I'm just trying to merge it into master, so need to work out the correct fix [03:37] Well, see previous comment :) [03:37] duflu, I suspect it's the drm plugin that's not working correctly [03:38] robert_ancell: Yes, I think I mentioned that. It's about DRM mastership... stuff [03:38] RAOF, do you know - does drmDropMaster() work immediately? [03:38] If Mir jumps in too soon it confuses plymouth's drm plugin [03:38] yeah [03:39] robert_ancell: I think it waits before returning. Let me check. [03:39] ARGH. How do you specify an environment variable for a cmake test? [03:40] Hint: Setting CTEST_ENVIRONMENT does *not* do what you want. Or, as far as I can tell, anything. [03:44] RAOF: setenv in code? [03:44] Too late for LD_PRELOAD! [03:46] RAOF: I'm not sure the universe wants us to achieve that goal. It's a bit wrong :) [03:52] Why are all build systems so ridiculously broken? [03:55] Why is there always something that should be trivial but ends up being a huge pain in the arse? [03:58] RAOF: Well if you mean CMake then yeah... so many things Make can do that CMake prevents you from doing [04:20] did we stop shipping binaries in the mir-demos package at some point? i.e.- mir_demo_server? [04:20] or am I going stupid [04:22] WTF? why are the demo binaries now in /usr/lib/x86-linux-gnu/mir/examples ? [04:31] thomi, ask didrocks. It seems stupid to me [04:33] ugh [04:33] me too [04:57] Did someone just update mir in the system-compositor PPA? u-s-c has a broken dep now [04:57] It looks like a RAOF to me [04:58] I did indeed. [04:58] thomi, ^ [04:58] RAOF: any chance you could push the matching libmirserver0 please? [04:58] otherwise it's uninstallable [04:58] thanks robert_ancell [04:58] thomi: I was waiting for the mir to publish. I've just copied u-s-c; once it's rebuilt, all will be well. [04:59] thomi: Are you pulling from system-compositor-testing? [04:59] RAOF: yes [04:59] Should I be bouncing through *another* PPA to ensure atomic updates of system-compositor-testing? [05:00] RAOF: I don't think the words "atomic" and "PPA" can ever appear within a mile of each other [05:01] but I might be wrong. I certainly don't know how to push several packages in an atomic fashion [05:01] RAOF, if you copied u-s-c 0.0.1bzr29saucy0.87 at the same time it should work without rebuilding right [05:02] then we'd just have a break if the copies are out of sync (assuming they will be) [05:02] robert_ancell: That's true. I just don't trust the staging PPA to be in a consistent state at an arbitrary time. [05:02] thomi, any chance we can get the mir revision number in the u-s-c build so it's easier to tell which ones match [05:03] robert_ancell: you want the lp:mir revno in the u-s-c package version? [05:03] thomi, yeah, then you could tell exactly which version of mir u-s-c was compiled against [05:04] robert_ancell: don't we already do that with the Depends line? [05:04] thomi, yes, I guess so - though that is harder to read from the list of packages in the PPA [05:04] (I'm guessing the answer is too hard) [05:05] This will all get solved by didrocks in the next week or so as it hits universe [05:05] robert_ancell: I don't know the answer, I'll fire off an email to people who will know though [05:05] yeah, it's all crazy distro stuff [05:05] thomi, I don't think it will be worth it in time [05:05] ok [05:06] thomi, robert_ancell: Either of you know how to wrangle an environment variable into our unit-tests? [05:06] RAOF, no [05:06] RAOF: how do you mean? [05:07] thomi: I want to LD_PRELOAD a library for running the unit-tests (as I'm interposing a libc symbol). [05:07] thomi: This is https://code.launchpad.net/~raof/mir/prober-drm-device-probe/+merge/170765 by the way, which passes the tests *just fine* locally. [05:08] good morning all :) [05:08] RAOF: that's some crazy stuff right there O.0 [05:08] hi tvoss [05:08] tvoss, welcome [05:08] Or maybe a wild tvoss knows! [05:08] thomi, hey, welcome back :) [05:08] tvoss: thank [05:08] s [05:08] RAOF, how can I help? [05:08] thomi: We're already interposing libdrm and libgbm symbols, it's no more weird than that :P [05:09] tvoss: Do you know how to get an environment variable set in our unit-test's environment. [05:09] tvoss: Specifically, to set LD_PRELOAD=lib/lib-mir-test-double-platform.so [05:09] RAOF, why not alter the env with cmake? [05:10] Hm, will that work? [05:10] * RAOF investigates. [05:10] RAOF, mind giving me some background? [05:10] RAOF, Any thoughts on the ARM builds failing due to that broken dep (https://bugs.launchpad.net/mir/+bug/1194002). I did some investigation, but the sticking plaster of just explicitly adding the dependency would solve the immediate problem - can you make that change in your git branch [05:10] Launchpad bug 1194002 in Mir "Mesa armhf builds don't depend on libmirclient" [High,Triaged] [05:10] robert_ancell: I thought I already had made that change? [05:11] RAOF, it doesn't appear so [05:11] RAOF, ok, I see it in git... [05:12] RAOF, is that still about the prober-mp? [05:12] tvoss: Context is https://code.launchpad.net/~raof/mir/prober-drm-device-probe/+merge/170765 - I've worked around the double-ctor problem, but can't get the open() wrapper to interpose in CI. [05:13] RAOF: so I guess the problem is the environment in the package build [05:13] RAOF, okay :) did my mail help? [05:13] you're setting it locally when you run the test yourself? [05:14] thomi: Actually, I don't *need* to set it locally. Which is another oddity. [05:14] RAOF: !?? [05:14] But that's fragile, as it depends on the linker loading the right symbol first. [05:14] that's a bit strange, isn't it? [05:16] Yes. [05:16] But not totally outlandish; trying to interpose a libc symbol is fairly niche :) [05:17] tvoss, racarr: hello, have you had the chance to follow up on the input stack issue I queried about? [05:17] veebers, could you remind me real quick, only had one coffee so far :) [05:18] tvoss: heh :-) This is regarding keyboard mapping entering characters like '$' etc. using uinput on the devices. I can fwd the previous email if that helps [05:19] veebers, ah, no that helps. So the question becomes, if we want to do it for the official phone images right now [05:20] tvoss: ah ok. I might mention that fixing this will fix the bug in autopilot that is blocking gemas work on the memory/power usage tests [05:21] veebers, that's only for the browser, right? [05:21] tvoss: at this stage I believe so (anything that needs to type 'shifted' characters) [05:21] veebers, okay, couldn't we add bookmarks for the pages we want to access and then open the bookmarks? [05:23] tvoss: if the intention of the test is to ensure loading a page works (and measuring usage while that happens) as opposed to testing entering a url and hitting enter etc. [05:24] tvoss: veebers: that would still leave us without test coverage for a very large part of the app (and other apps too). [05:24] thomi: agreed [05:24] thomi, sure, but: fixing it in the current official images right now would mean touching the ubuntuappmanager, which is going away with Mir [05:25] tvoss: I see [05:25] thomi, trying to find out what we lose by not doing it right now [05:25] tvoss: what's the timeline for introducing mir? [05:26] thomi, asap,we have an alternate image running it [05:27] veebers: perhaps you could try the alternate image then? [05:27] thomi, not recommended right now for quality stuff [05:27] tvoss: that's with --flipped, right? [05:27] thomi, tvoss: It would be interesting to run it and ensure the issue we were experiencing are solved [05:27] thomi, not only, it's flipped + mir. an alternate alternate image, if you want so [05:27] haha [05:28] veebers, hold on, let's focus on unblocking gema here: if you really can't workaround the keymap issue, I will work with racarr to fix it in the ubuntuappmanager, but: we might try to be create to unblock gema [05:29] s/create/creative [05:30] tvoss: if the flipped & mir image is the way of the future, surely gema can/should be testing that anyway? and if it "just works", wouldn't that be the path of least resistance? [05:32] thomi, I'm pretty sure it won't just work, and our timelines on resource measurement are tight. [05:33] veebers, do you have a bug open somewhere about the keymapping behavior? [05:33] veebers: yep, one moment [05:33] tvoss: https://bugs.launchpad.net/autopilot/+bug/1181216 [05:33] Launchpad bug 1181216 in Autopilot "Autopilot does not type : (colon) on devices" [Critical,In progress] [05:34] tvoss: ack [05:40] veebers, for the bug: why do you need a : to open a webpage? [05:40] www.cnn.com should work, too [05:40] tvoss: I suspect the test is typing http: . . . [05:41] tvoss: that is a good point [05:41] veebers, well, the short term workaround might be to get rid of the http: [05:41] tvoss: I'll look into getting those tests update w/ the workaround [05:41] RAOF: got a sec? the u-s-c package you pushed seems a little broken to me [05:41] veebers, thx a lot [05:41] thomi: Boo. In what way? [05:42] tvoss: thanks for pointing that out :-) [05:42] RAOF: it depends on bzr773 libmirserver0, but 774 is the latest version, and the one that's built in the PPA [05:42] so I'm not sure how that is possible [05:42] veebers, yw [05:42] thomi, staging? [05:42] RAOF: shouldn't it take the package version number from whatever it built against? [05:43] tvoss: no, the compositor test ppa [05:43] thomi, hmmm [05:43] Correct. [05:43] although I note that the package version is the same in both PPAs,except staging has a newer mir [05:44] veebers, I will add a comment to the bug report [05:44] tvoss: awesome, thanks [05:44] thomi: amd64 certainly depends on 774. [05:44] * RAOF checks i386 [05:45] veebers, done [05:45] thomi: As does i386. [05:45] thomi: You're installing the wrong u-s-c. [05:45] RAOF: WTF? why does my laptop insist it's 773? [05:45] maybe I just missed the update or something? [05:45] You have both system-compositor-testing and staging PPAs enabled? [05:45] RAOF: nope [05:46] RAOF: should I? [05:46] No, but that could cause this sort of problem :) [05:46] hmmm: W: Failed to fetch bzip2:/var/lib/apt/lists/partial/ppa.launchpad.net_mir-team_staging_ubuntu_dists_saucy_main_binary-amd64_Packages Hash Sum mismatch [05:47] \o/ works now :) [05:47] The plot thickens! [05:47] it seems I must have apt-get update'd a few minutes too early [05:49] :) [05:50] that hash sum mismatch makes me really wary about our infrastructure - I see that too often [05:51] hmmmm [05:51] I think I may have broken lightdm [05:51] after changing lightdm.conf to enable u-s-c I seem to be stuck at boot on the 'ubuntu' spinning dots screen [05:53] thomi, do we have autopilot integration for udevmock? [05:54] tvoss: I'm not sure what udevmock is. so probably not :) [05:54] thomi: You may have double-enabled it - /etc/lightdm/lightdm.conf.d should have a snippet automatically enabling u-s-c [05:54] tvoss: Ooooh, good idea! [05:55] RAOF: no, it turns out lightdm is not installed because it relies on a newer glib than I have available... FFS [05:55] nothing seems to be working for me today [05:55] Win! [05:55] RAOF, trying to address the testing issue [05:55] thomi, really? That's odd [05:55] Are you trying this on saucy? [05:55] RAOF: yes [05:55] did a dist upgrade this morning, and I have no pending updates [05:57] RAOF, duflu, racarr, kdub, tvoss, hikiko meeting reminder [05:57] robert_ancell, yup, I'm on a broadband connection, sitting in the tax office :) Mind if I participate via irc? [05:57] tvoss, np [05:58] tvoss: Sounds like fun [05:58] duflu, totally _not_ [05:58] can someone please link me the hangout link? [05:58] tvoss, is audio-only not fast enought? [05:58] for some reason my calendar does not show it [05:58] duflu, building a display server is the one thing, german tax is the other :) [05:58] tvoss, zing! [05:58] thomi: https://plus.google.com/hangouts/_/a9abbc8e84f85360faaab30196768ca2d9129d09 [05:58] robert_ancell, let me try to find a quiet spot [05:59] kgunn, if you're actually here (I hope not) ^ [05:59] Time for another exciting round of "how crap is my internet today?! [06:03] robert_ancell, sorry, quiet spot found but only edge :/ [06:03] tvoss, :( [06:03] tvoss, we're discussing multi-monitor at the moment [06:04] robert_ancell, argh ... === sg is now known as Guest63927 [06:15] ugh, internet issues, you all sound like chipmunks every 10 seconds or so [06:17] thomi: issue or feature :-) [06:54] robert_ancell: hey, what happens when someone runs manually unity-system-compsitor? [06:54] didrocks, it complains you didn't set up the pipes to talk to it [06:54] robert_ancell: should it be in libexec rather? [06:55] didrocks, no [06:55] as lightdm and others will only be able to run it? [06:55] libexec is stupid [06:55] well, shipping in /usr/bin when most people can't run it is stupid :) [06:55] there's loads of stuff in /usr/bin [06:56] most of them, people can run them and see a result [06:56] but fine, not my project [06:57] it should be in sbin though [06:58] robert_ancell: I'm more ok with this [06:58] didrocks, it's the same as lightdm [06:58] yeah, sbin makes sense [06:58] robert_ancell: I'll move it while proposing my fixes [06:59] didrocks, ok [06:59] robert_ancell: do you want me to make MP for lightdm and unity-greeter for daily release as well? [07:00] didrocks, yes, as long as we have the integration tests to confirm they work together [07:00] robert_ancell: do you have them? I think it's like xmir, qtmir and unity-system-compositor, there isn't any? [07:00] robert_ancell: I can prepare the package for a ppa then, daily releasing there until you have them [07:01] didrocks, I sent an email about it [07:01] robert_ancell: I answered I guess ;) [07:02] I should use https://code.launchpad.net/~lightdm-team/lightdm/mir-packaging I guess [07:03] robert_ancell: one part of daily release is to have the packaging inlined, it's not the case for lightdm and unity-greeter I think? [07:04] didrocks, we're using ~lightdm-team/lightdm/trunk-packaging for the CI [07:04] didrocks, u-g has inline packaging now [07:05] didrocks, I'm trying to work out what we can do for lightdm inline packaging that makes sense [07:05] didrocks, sorry, I have to go - please email me any other questions. I'm here late tomorrow so we'll have overlap then too [07:07] robert_ancell: ok, have a good night! [07:11] RAOF, and alf sorry:) I thought we are still in the hangout [07:11] RAOF, did the vt-fix propagate to the ppa, yet? [07:11] cannot switch to vt after an upgrade [07:12] alf: hey! do you have time this morning? [07:13] tvoss: Should have. [07:14] RAOF, so whre do I find the VT? ctrl+alt+? [07:14] F1-F12? [07:14] hikiko: You were welcome to stay :) [07:15] RAOF, hmmm, that leaves me with the desktop on screen and no login prompt [07:15] didrocks: sure, I will work on top of your branch if that's ok [07:15] Hm. So we may have one additional VT bug. [07:15] alf: perfect! thanks :) [07:15] RAOF: will the mir system compositor replace kmscon? :P [07:16] mlankhorst: Absolutely@! [07:16] #dontcheck [07:16] Sorry, in joke. [07:16] I find your failed attempt at humor amusing. :) [07:18] RAOF, mind repinging me the udev mock thingy on google? [07:18] s/google/chromium [07:18] https://code.google.com/p/chromium/issues/detail?id=248824 ? [07:19] mlankhorst: I think I found a race in the radeon driver cs thread. In particular, if trying to flush from two contexts sometimes one of them may hang. [07:19] mlankhorst: (in Mesa/Gallium) [07:19] mlankhorst: are you the right person to talk to? [07:21] probably [07:23] I don't think I've ever tried flushing from 2 threads though [07:24] but what is it hanging on? [07:26] RAOF, thx [07:28] alf: should the source be name qtmir or qmir? [07:28] also, do you have any packaging somewhere? :) [07:30] hey RAOF, do you have a minute to discuss about xmir? [07:30] didrocks: Sure. [07:30] mlankhorst: In radeon_drm_cs_flush() the code is waiting for the cs_queue to become empty pipe_condvar_wait(cs->ws->cs_queue_empty,...). In the case that we flush from two different (but shared) contexts sometimes it gets stuck there. [07:31] didrocks: Probably not more than 5 minutes, though (I'll be available later, too, if necessary) [07:31] RAOF: ok, let's try to be short: how do you want that we treat xmir? [07:31] as if it was a canonical upstream for us? with dailies? [07:31] alf: hm what I thought, change pipe_condvar_signal to pipe_condvar_broadcast in radeon_drm_cs_emit_ioctl ? [07:31] or you keep everything in git? [07:31] didrocks: I guess as a patch on top of the regular X package? [07:32] RAOF: ok, so X source + patch for having an additional binary package [07:32] right? [07:32] mlankhorst: I tried that, but it didn't work, although I didn't investigate more [07:32] not a separate source, nothing… [07:32] didrocks: No extra binary package, although I could create one if we wanted. [07:32] RAOF: oh, I don't really, as long as it's part of the same X source, I'm fine (so no dailies for it) [07:33] RAOF: the only question is how would you treat mir ABI then? [07:33] and it's not stable AFAIK [07:33] mirclient ABI *is* stable. [07:33] mlankhorst: I will investigate more and let you now [07:33] mlankhorst: know [07:33] RAOF: ah ok, so no biggie I guess :) [07:33] RAOF: ABI yes, not API ;) [07:33] At least, it's stable enough that I bumped the SONAME recently. [07:34]