[00:00] <racarr> Well, just I am trying to get all the focus policy in to one object
[00:00] <racarr> this object, basically, makes the assosciation, this surface is the focused one (only above this, does "focus" really exist)
[00:01] <racarr> and, ties up the bits to implement focus
[00:02] <kdub> racarr, sounds useful (although hard to say for sure...)
[00:02] <racarr> 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] <racarr> mm. still hard to say XD
[00:02] <kdub> i'm just trying to detangle the surface ownerships
[00:02] <racarr> so the problem is
[00:02] <racarr> some surface is focused
[00:02] <racarr> and it's destroyed
[00:02] <racarr> how does this object know to choose a new mechanism for focus
[00:03] <racarr> err
[00:03] <racarr> a new surface
[00:03] <racarr> I don't want to
[00:03] <racarr> pass this object down through the session manager and session like before, and have the those bits contain the logic
[00:04] <kdub> like, just floating up the factories and untangling the objects ownerships, i'm starting to see how it'll happen
[00:04] <racarr> "when surface is destroyed, focus the last surface", etc
[00:04] <kdub> still too early to say though
[00:04] <racarr> so I am wondering about
[00:04] <racarr> some sorst of change_callback system
[00:04] <kdub> 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] <racarr> to mirror what we have on the graphics side...
[00:05] <racarr> Haha. yeah ....
[00:05] <kdub> racarr, that makes sense
[00:05] <kdub> the callback for input
[00:05] <racarr> 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] <racarr> on shell side state changes
[00:07] <racarr> I just had a crazy idea
[00:07] <racarr> the FocusArbitrator/Setter/Whatever
[00:08] <racarr> could hand out like...
[00:08] <racarr> surface->receive_focus(std::unique_ptr<FocusToken>)...
[00:08] <racarr> and the destructor knows what to do
[00:11] <kdub> well, what if you want to get that token back though
[00:11] <kdub> like, a manual reassignment of focus
[00:11] <racarr> kdub: std::move XD
[00:12] <racarr> I'm not sure...
[00:14] <racarr> I find a certain appeal to this but may jjust have C++ addiction
[00:20] <RAOF> Not *every* problem needs to be modelled in the type system :)
[00:20] <RAOF> But it does have a certain charm. Also parallels desrt's focus-stealing-prevention idea.
[00:21] <racarr> it's a nice way to be explicit about the signalling needed (surface destroyed)
[00:21] <racarr> I think without clogging up other listener interfaces, or using generic change callbacks
[00:21] <racarr> etc
[00:21] <racarr> which will end up with more coupling
[00:21] <racarr> but im still not sure
[00:21] <racarr> I think ill let it stew until tomorrow
[00:22] <RAOF> So, how close are we to having a "focus-gained" and "focus-lost" signal on our surfaces?
[00:22] <racarr> well
[00:22] <racarr> the session_listener has
[00:22] <racarr> focused and unfocused
[00:22] <racarr> and the EventSink will probably give them eventually
[00:23] <racarr> I dunon that's the thing though, we don't really want signals so to speak
[00:23] <racarr> i.e. this same problem could be solved by having the focus bit do
[00:23] <RAOF> Let me rephrase: at what point will XMir be able to tell when it's not focused, and give up input?
[00:23] <racarr> surface.subscribe_to_signal("about_to_close"
[00:23] <racarr> now!
[00:23] <racarr> oh
[00:23] <racarr> I made that up
[00:23] <RAOF> Woo! How!
[00:23] <racarr> soon
[00:23] <RAOF> Oh ☹
[00:23] <racarr> no I made that up ignore me
[00:23] <racarr> XD
[00:23] <racarr> if xmir needs that
[00:23] <racarr> I can finish it soon
[00:24] <racarr> well
[00:24] <racarr> xmir does need that
[00:24] <RAOF> Only if you'd like to be able to switch sessions without all sessions getting all input :)
[00:27] <racarr> RAOF: *shrug* I'm not too picky
[00:45] <thomi> hey guys, what's required to run openarena on mir?
[00:45] <thomi> is there a custom build somewhere?
[00:53] <RAOF> Does that just need SDL?
[00:53] <RAOF> Or do you want to run it in XMir?
[00:54] <bschaefer> thomi, it should work on Mir with the SDL package in the ppa (I haven't tried yet though)
[00:54] <bschaefer> tried openarena that is
[00:56] <thomi> ok, I'll give that a go
[00:56] <thomi> RAOF: I'll tackle xmir soon
[00:56] <thomi> just mir right now
[01:57] <RAOF> 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] <duflu> RAOF: Oh? Why not?
[01:58] <RAOF> If I drop it, it no longer interposes.
[01:58] <duflu> 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] <RAOF> 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] <duflu> RAOF: That's weird. I suggest it's maybe because it's got C++ linkage and needs C. Look at "nm"
[01:59] <duflu> RAOF: Yeah just do an 'extern "C"', or put it in a C file
[02:00] <RAOF> I'm pretty sure I checked.
[02:01] <RAOF> Oh, except that I may have had the ‘please demangle my symbols’ option enabled...
[02:01] <RAOF> Which would somewhat defeat the purpose of that check :)
[02:18] <duflu> RAOF: Yeah don't use the -C option. Just nm -D
[02:28] <RAOF> Why do we make it so hard to set an environment variable in a CMake test?
[02:28] <duflu> Ahhhh why can't we keep trunk stable enough to build any more?
[02:28] <duflu> It's a new FTBFS every day
[02:39] <robert_ancell> duflu, why are you still consuming mir on raring?
[02:40] <duflu> robert_ancell, because that's my desktop. Hence much faster to do some jobs
[02:40] <duflu> ... than the suacy laptops
[02:40] <duflu> *saucy
[02:40] <robert_ancell> duflu, well, it's just wasting time fixing bugs in raring
[02:41] <duflu> robert_ancell, It's not a waste if other distros get the same errors, and they are real errors in our code
[02:41] <duflu> It would be nice to catch them before they land, is all
[02:41] <robert_ancell> duflu, just require those other distros to use gcc 4.8. It's not a difficult dependency
[02:41] <duflu> robert_ancell, I think that would be arrogant of us. If the fix to support existing compilers is simple
[02:42] <robert_ancell> 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] <duflu> 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] <robert_ancell> disagree
[02:43] <duflu> I know this from experience. Supporting up to 15 platform combos at once
[02:45] <duflu> Bah, we can argue about "easiest" forever
[02:46] <robert_ancell> 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] <robert_ancell> duflu, :)
[02:55] <RAOF> Um, why do we have a hunk of parsing code to emit CTest test files?
[02:55] <RAOF> Rather than just using add_test?
[03:11] <robert_ancell> duflu, in that fix you made for plymouth you call 'plymouth deactivate' every time in the loop - was that intentional?
[03:12] <duflu> robert_ancell: Yes but now you mention it, it could probably only happen once
[03:12] <duflu> There's no reason to repeat it
[03:12] <robert_ancell> ok, cool
[03:12] <duflu> robert_ancell: That's the result of many iterations. You get leftovers of previous algorithms
[03:12] <robert_ancell> heh
[03:15] <duflu> RAOF: Was it feasible to resolve the libdrm_radeon issue? (https://launchpad.net/~mir-team/+archive/staging/+build/4741584)
[03:16] <RAOF> Eh, screw it. I'll just copy saucy's libdrm into the PPA for you :)
[03:26] <robert_ancell> duflu, I'm looking at the plymouth source and it does appear to block on deactivate correctly
[03:26] <robert_ancell> duflu, are you sure that was causing the problem?
[03:26] <duflu> robert_ancell: Yes, absolutely. The lightdm log shows it has to try twice before success
[03:27] <duflu> And inserting a sleep works also :)
[03:34] <robert_ancell> 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] <robert_ancell> So effectively all the patch has done is add a sleep(1)
[03:34] <duflu> robert_ancell, I also clear the cache to force it to contact each time
[03:35] <robert_ancell> duflu, ah, missed that
[03:35] <duflu> So that part is working
[03:35] <duflu> And I get two attempts logged in my lightdm.log
[03:35] <duflu> So it takes somewhere inside a second to complete
[03:37] <duflu> 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] <duflu> -"not crash" +"not spin"
[03:37] <robert_ancell> duflu, yeah, I'm just trying to merge it into master, so need to work out the correct fix
[03:37] <duflu> Well, see previous comment :)
[03:37] <robert_ancell> duflu, I suspect it's the drm plugin that's not working correctly
[03:38] <duflu> robert_ancell: Yes, I think I mentioned that. It's about DRM mastership... stuff
[03:38] <robert_ancell> RAOF, do you know - does drmDropMaster() work immediately?
[03:38] <duflu> If Mir jumps in too soon it confuses plymouth's drm plugin
[03:38] <robert_ancell> yeah
[03:39] <RAOF> robert_ancell: I think it waits before returning. Let me check.
[03:39] <RAOF> ARGH. How do you specify an environment variable for a cmake test?
[03:40] <RAOF> Hint: Setting CTEST_ENVIRONMENT does *not* do what you want. Or, as far as I can tell, anything.
[03:44] <duflu> RAOF: setenv in code?
[03:44] <RAOF> Too late for LD_PRELOAD!
[03:46] <duflu> RAOF: I'm not sure the universe wants us to achieve that goal. It's a bit wrong :)
[03:52] <RAOF> Why are all build systems so ridiculously broken?
[03:55] <RAOF> Why is there always something that should be trivial but ends up being a huge pain in the arse?
[03:58] <duflu> RAOF: Well if you mean CMake then yeah... so many things Make can do that CMake prevents you from doing
[04:20] <thomi> did we stop shipping binaries in the mir-demos package at some point? i.e.- mir_demo_server?
[04:20] <thomi> or am I going stupid
[04:22] <thomi> WTF? why are the demo binaries now in /usr/lib/x86-linux-gnu/mir/examples ?
[04:31] <robert_ancell> thomi, ask didrocks. It seems stupid to me
[04:33] <thomi> ugh
[04:33] <thomi> me too
[04:57] <robert_ancell> Did someone just update mir in the system-compositor PPA? u-s-c has a broken dep now
[04:57] <robert_ancell> It looks like a RAOF to me
[04:58] <RAOF> I did indeed.
[04:58] <robert_ancell> thomi, ^
[04:58] <thomi> RAOF: any chance you could push the matching libmirserver0 please?
[04:58] <thomi> otherwise it's uninstallable
[04:58] <thomi> thanks robert_ancell
[04:58] <RAOF> 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] <RAOF> thomi: Are you pulling from system-compositor-testing?
[04:59] <thomi> RAOF: yes
[04:59] <RAOF> Should I be bouncing through *another* PPA to ensure atomic updates of system-compositor-testing?
[05:00] <thomi> RAOF: I don't think the words "atomic" and "PPA" can ever appear within a mile of each other
[05:01] <thomi> but I might be wrong. I certainly don't know how to push several packages in an atomic fashion
[05:01] <robert_ancell> RAOF, if you copied u-s-c  0.0.1bzr29saucy0.87  at the same time it should work without rebuilding right
[05:02] <robert_ancell> then we'd just have a break if the copies are out of sync (assuming they will be)
[05:02] <RAOF> 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] <robert_ancell> 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] <thomi> robert_ancell: you want the lp:mir revno in the u-s-c package version?
[05:03] <robert_ancell> thomi, yeah, then you could tell exactly which version of mir u-s-c was compiled against
[05:04] <thomi> robert_ancell: don't we already do that with the Depends line?
[05:04] <robert_ancell> thomi, yes, I guess so - though that is harder to read from the list of packages in the PPA
[05:04] <robert_ancell> (I'm guessing the answer is too hard)
[05:05] <robert_ancell> This will all get solved by didrocks in the next week or so as it hits universe
[05:05] <thomi> robert_ancell: I don't know the answer, I'll fire off an email to people who will know though
[05:05] <thomi> yeah, it's all crazy distro stuff
[05:05] <robert_ancell> thomi, I don't think it will be worth it in time
[05:05] <thomi> ok
[05:06] <RAOF> thomi, robert_ancell: Either of you know how to wrangle an environment variable into our unit-tests?
[05:06] <robert_ancell> RAOF, no
[05:06] <thomi> RAOF: how do you mean?
[05:07] <RAOF> thomi: I want to LD_PRELOAD a library for running the unit-tests (as I'm interposing a libc symbol).
[05:07] <RAOF> 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] <tvoss> good morning all :)
[05:08] <thomi> RAOF: that's some crazy stuff right there O.0
[05:08] <thomi> hi tvoss
[05:08] <robert_ancell> tvoss, welcome
[05:08] <RAOF> Or maybe a wild tvoss knows!
[05:08] <tvoss> thomi, hey, welcome back :)
[05:08] <thomi> tvoss: thank
[05:08] <thomi> s
[05:08] <tvoss> RAOF, how can I help?
[05:08] <RAOF> thomi: We're already interposing libdrm and libgbm symbols, it's no more weird than that :P
[05:09] <RAOF> tvoss: Do you know how to get an environment variable set in our unit-test's environment.
[05:09] <RAOF> tvoss: Specifically, to set LD_PRELOAD=lib/lib-mir-test-double-platform.so
[05:09] <tvoss> RAOF, why not alter the env with cmake?
[05:10] <RAOF> Hm, will that work?
[05:10]  * RAOF investigates.
[05:10] <tvoss> RAOF, mind giving me some background?
[05:10] <robert_ancell> 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] <RAOF> robert_ancell: I thought I already had made that change?
[05:11] <robert_ancell> RAOF, it doesn't appear so
[05:11] <robert_ancell> RAOF, ok, I see it in git...
[05:12] <tvoss> RAOF, is that still about the prober-mp?
[05:12] <RAOF> 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] <thomi> RAOF: so I guess the problem is the environment in the package build
[05:13] <tvoss> RAOF, okay :) did my mail help?
[05:13] <thomi> you're setting it locally when you run the test yourself?
[05:14] <RAOF> thomi: Actually, I don't *need* to set it locally. Which is another oddity.
[05:14] <thomi> RAOF: !??
[05:14] <RAOF> But that's fragile, as it depends on the linker loading the right symbol first.
[05:14] <thomi> that's a bit strange, isn't it?
[05:16] <RAOF> Yes.
[05:16] <RAOF> But not totally outlandish; trying to interpose a libc symbol is fairly niche :)
[05:17] <veebers> tvoss, racarr: hello, have you had the chance to follow up on the input stack issue I queried about?
[05:17] <tvoss> veebers, could you remind me real quick, only had one coffee so far :)
[05:18] <veebers> 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] <tvoss> veebers, ah, no that helps. So the question becomes, if we want to do it for the official phone images right now
[05:20] <veebers> 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] <tvoss> veebers, that's only for the browser, right?
[05:21] <veebers> tvoss: at this stage I believe so (anything that needs to type 'shifted' characters)
[05:21] <tvoss> veebers, okay, couldn't we add bookmarks for the pages we want to access and then open the bookmarks?
[05:23] <veebers> 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] <thomi> tvoss: veebers: that would still leave us without test coverage for a very large part of the app (and other apps too).
[05:24] <veebers> thomi: agreed
[05:24] <tvoss> 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] <thomi> tvoss: I see
[05:25] <tvoss> thomi, trying to find out what we lose by not doing it right now
[05:25] <thomi> tvoss: what's the timeline for introducing mir?
[05:26] <tvoss> thomi, asap,we have an alternate image running it
[05:27] <thomi> veebers: perhaps you could try the alternate image then?
[05:27] <tvoss> thomi, not recommended right now for quality stuff
[05:27] <thomi> tvoss: that's with --flipped, right?
[05:27] <veebers> thomi, tvoss: It would be interesting to run it and ensure the issue we were experiencing are solved
[05:27] <tvoss> thomi, not only, it's flipped + mir. an alternate alternate image, if you want so
[05:27] <thomi> haha
[05:28] <tvoss> 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] <tvoss> s/create/creative
[05:30] <thomi> 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] <tvoss> thomi, I'm pretty sure it won't just work, and our timelines on resource measurement are tight.
[05:33] <tvoss> veebers, do you have a bug open somewhere about the keymapping behavior?
[05:33] <veebers> veebers: yep, one moment
[05:33] <veebers> tvoss: https://bugs.launchpad.net/autopilot/+bug/1181216
[05:34] <thomi> tvoss: ack
[05:40] <tvoss> veebers, for the bug: why do you need a : to open a webpage?
[05:40] <tvoss> www.cnn.com should work, too
[05:40] <veebers> tvoss: I suspect the test is typing http: . . .
[05:41] <veebers> tvoss: that is a good point
[05:41] <tvoss> veebers, well, the short term workaround might be to get rid of the http:
[05:41] <veebers> tvoss: I'll look into getting those tests update w/ the workaround
[05:41] <thomi> RAOF: got a sec? the u-s-c package you pushed seems a little broken to me
[05:41] <tvoss> veebers, thx a lot
[05:41] <RAOF> thomi: Boo. In what way?
[05:42] <veebers> tvoss: thanks for pointing that out :-)
[05:42] <thomi> RAOF: it depends on bzr773 libmirserver0, but 774 is the latest version, and the one that's built in the PPA
[05:42] <thomi> so I'm not sure how that is possible
[05:42] <tvoss> veebers, yw
[05:42] <tvoss> thomi, staging?
[05:42] <thomi> RAOF: shouldn't it take the package version number from whatever it built against?
[05:43] <thomi> tvoss: no, the compositor test ppa
[05:43] <tvoss> thomi, hmmm
[05:43] <RAOF> Correct.
[05:43] <thomi> although I note that the package version is the same in both PPAs,except staging has a newer mir
[05:44] <tvoss> veebers, I will add a comment to the bug report
[05:44] <veebers> tvoss: awesome, thanks
[05:44] <RAOF> thomi: amd64 certainly depends on 774.
[05:44]  * RAOF checks i386
[05:45] <tvoss> veebers, done
[05:45] <RAOF> thomi: As does i386.
[05:45] <RAOF> thomi: You're installing the wrong u-s-c.
[05:45] <thomi> RAOF: WTF? why does my laptop insist it's 773?
[05:45] <thomi> maybe I just missed the update or something?
[05:45] <RAOF> You have both system-compositor-testing and staging PPAs enabled?
[05:45] <thomi> RAOF: nope
[05:46] <thomi> RAOF: should I?
[05:46] <RAOF> No, but that could cause this sort of problem :)
[05:46] <thomi> 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] <thomi> \o/ works now :)
[05:47] <RAOF> The plot thickens!
[05:47] <thomi> it seems I must have apt-get update'd a few minutes too early
[05:49] <RAOF> :)
[05:50] <robert_ancell> that hash sum mismatch makes me really wary about our infrastructure  - I see that too often
[05:51] <thomi> hmmmm
[05:51] <thomi> I think I may have broken lightdm
[05:51] <thomi> after changing lightdm.conf to enable u-s-c I seem to be stuck at boot on the 'ubuntu' spinning dots screen
[05:53] <tvoss> thomi, do we have autopilot integration for udevmock?
[05:54] <thomi> tvoss: I'm not sure what udevmock is. so probably not :)
[05:54] <RAOF> thomi: You may have double-enabled it - /etc/lightdm/lightdm.conf.d should have a snippet automatically enabling u-s-c
[05:54] <RAOF> tvoss: Ooooh, good idea!
[05:55] <thomi> RAOF: no, it turns out lightdm is not installed because it relies on a newer glib than I have available... FFS
[05:55] <thomi> nothing seems to be working for me today
[05:55] <RAOF> Win!
[05:55] <tvoss> RAOF, trying to address the testing issue
[05:55] <robert_ancell> thomi, really? That's odd
[05:55] <RAOF> Are you trying this on saucy?
[05:55] <thomi> RAOF: yes
[05:55] <thomi> did a dist upgrade this morning, and I have no pending updates
[05:57] <robert_ancell> RAOF, duflu, racarr, kdub, tvoss, hikiko meeting reminder
[05:57] <tvoss> robert_ancell, yup, I'm on a broadband connection, sitting in the tax office :) Mind if I participate via irc?
[05:57] <robert_ancell> tvoss, np
[05:58] <duflu> tvoss: Sounds like fun
[05:58] <tvoss> duflu, totally _not_
[05:58] <thomi> can someone please link me the hangout link?
[05:58] <robert_ancell> tvoss, is audio-only not fast enought?
[05:58] <thomi> for some reason my calendar does not show it
[05:58] <tvoss> duflu, building a display server is the one thing, german tax is the other :)
[05:58] <robert_ancell> tvoss, zing!
[05:58] <alf> thomi: https://plus.google.com/hangouts/_/a9abbc8e84f85360faaab30196768ca2d9129d09
[05:58] <tvoss> robert_ancell, let me try to find a quiet spot
[05:59] <robert_ancell> kgunn, if you're actually here (I hope not) ^
[05:59] <RAOF> Time for another exciting round of "how crap is my internet today?!
[06:03] <tvoss> robert_ancell, sorry, quiet spot found but only edge :/
[06:03] <robert_ancell> tvoss, :(
[06:03] <robert_ancell> tvoss, we're discussing multi-monitor at the moment
[06:04] <tvoss> robert_ancell, argh ...
[06:15] <thomi> ugh, internet issues, you all sound like chipmunks every 10 seconds or so
[06:17] <veebers> thomi: issue or feature :-)
[06:54] <didrocks> robert_ancell: hey, what happens when someone runs manually unity-system-compsitor?
[06:54] <robert_ancell> didrocks, it complains you didn't set up the pipes to talk to it
[06:54] <didrocks> robert_ancell: should it be in libexec rather?
[06:55] <robert_ancell> didrocks, no
[06:55] <didrocks> as lightdm and others will only be able to run it?
[06:55] <robert_ancell> libexec is stupid
[06:55] <didrocks> well, shipping in /usr/bin when most people can't run it is stupid :)
[06:55] <robert_ancell> there's loads of stuff in /usr/bin
[06:56] <didrocks> most of them, people can run them and see a result
[06:56] <didrocks> but fine, not my project
[06:57] <robert_ancell> it should be in sbin though
[06:58] <didrocks> robert_ancell: I'm more ok with this
[06:58] <robert_ancell> didrocks, it's the same as lightdm
[06:58] <didrocks> yeah, sbin makes sense
[06:58] <didrocks> robert_ancell: I'll move it while proposing my fixes
[06:59] <robert_ancell> didrocks, ok
[06:59] <didrocks> robert_ancell: do you want me to make MP for lightdm and unity-greeter for daily release as well?
[07:00] <robert_ancell> didrocks, yes, as long as we have the integration tests to confirm they work together
[07:00] <didrocks> robert_ancell: do you have them? I think it's like xmir, qtmir and unity-system-compositor, there isn't any?
[07:00] <didrocks> robert_ancell: I can prepare the package for a ppa then, daily releasing there until you have them
[07:01] <robert_ancell> didrocks, I sent an email about it
[07:01] <didrocks> robert_ancell: I answered I guess ;)
[07:02] <didrocks> I should use https://code.launchpad.net/~lightdm-team/lightdm/mir-packaging I guess
[07:03] <didrocks> 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] <robert_ancell> didrocks, we're using ~lightdm-team/lightdm/trunk-packaging for the CI
[07:04] <robert_ancell> didrocks, u-g has inline packaging now
[07:05] <robert_ancell> didrocks, I'm trying to work out what we can do for lightdm inline packaging that makes sense
[07:05] <robert_ancell> 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] <didrocks> robert_ancell: ok, have a good night!
[07:11] <hikiko> RAOF, and alf sorry:) I thought we are still in the hangout
[07:11] <tvoss> RAOF, did the vt-fix propagate to the ppa, yet?
[07:11] <tvoss> cannot switch to vt after an upgrade
[07:12] <didrocks> alf: hey! do you have time this morning?
[07:13] <RAOF> tvoss: Should have.
[07:14] <tvoss> RAOF, so whre do I find the VT? ctrl+alt+?
[07:14] <RAOF> F1-F12?
[07:14] <alf> hikiko: You were welcome to stay :)
[07:15] <tvoss> RAOF, hmmm, that leaves me with the desktop on screen and no login prompt
[07:15] <alf> didrocks: sure, I will work on top of your branch if that's ok
[07:15] <RAOF> Hm. So we may have one additional VT bug.
[07:15] <didrocks> alf: perfect! thanks :)
[07:15] <mlankhorst> RAOF: will the mir system compositor replace kmscon? :P
[07:16] <RAOF> mlankhorst: Absolutely@!
[07:16] <RAOF> #dontcheck
[07:16] <RAOF> Sorry, in joke.
[07:16] <mlankhorst> I find your failed attempt at humor amusing. :)
[07:18] <tvoss> RAOF, mind repinging me the udev mock thingy on google?
[07:18] <tvoss> s/google/chromium
[07:18] <RAOF> https://code.google.com/p/chromium/issues/detail?id=248824 ?
[07:19] <alf> 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] <alf> mlankhorst: (in Mesa/Gallium)
[07:19] <alf> mlankhorst: are you the right person to talk to?
[07:21] <mlankhorst> probably
[07:23] <mlankhorst> I don't think I've ever tried flushing from 2 threads though
[07:24] <mlankhorst> but what is it hanging on?
[07:26] <tvoss> RAOF, thx
[07:28] <didrocks> alf: should the source be name qtmir or qmir?
[07:28] <didrocks> also, do you have any packaging somewhere? :)
[07:30] <didrocks> hey RAOF, do you have a minute to discuss about xmir?
[07:30] <RAOF> didrocks: Sure.
[07:30] <alf> 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] <RAOF> didrocks: Probably not more than 5 minutes, though (I'll be available later, too, if necessary)
[07:31] <didrocks> RAOF: ok, let's try to be short: how do you want that we treat xmir?
[07:31] <didrocks> as if it was a canonical upstream for us? with dailies?
[07:31] <mlankhorst> alf: hm what I thought, change pipe_condvar_signal to pipe_condvar_broadcast in radeon_drm_cs_emit_ioctl ?
[07:31] <didrocks> or you keep everything in git?
[07:31] <RAOF> didrocks: I guess as a patch on top of the regular X package?
[07:32] <didrocks> RAOF: ok, so X source + patch for having an additional binary package
[07:32] <didrocks> right?
[07:32] <alf> mlankhorst: I tried that, but it didn't work, although I didn't investigate more
[07:32] <didrocks> not a separate source, nothing…
[07:32] <RAOF> didrocks: No extra binary package, although I could create one if we wanted.
[07:32] <didrocks> 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] <didrocks> RAOF: the only question is how would you treat mir ABI then?
[07:33] <didrocks> and it's not stable AFAIK
[07:33] <RAOF> mirclient ABI *is* stable.
[07:33] <alf> mlankhorst: I will investigate more and let you now
[07:33] <alf> mlankhorst: know
[07:33] <didrocks> RAOF: ah ok, so no biggie I guess :)
[07:33] <duflu> RAOF: ABI yes, not API ;)
[07:33] <RAOF> At least, it's stable enough that I bumped the SONAME recently.
[07:34] <didrocks> RAOF: so, for mesa + xmir, I have nothing to do, nothing to daily release, right?
[07:34] <RAOF> didrocks: Right.
[07:34] <didrocks> \o/
[07:34] <didrocks> thanks RAOF :)
[07:34] <alf> didrocks: tvoss: Didn'd we abandon qmir/qtmir in favor of qtubuntu with a mir backend?
[07:34] <didrocks> ah?
[07:35] <tvoss> alf, I would think so for the time being. We should keep it around, though
[07:35] <didrocks> tvoss: so qtubuntu binary package contains the mir backend?
[07:35] <didrocks> and that's what Saviq's team is using?
[07:35] <tvoss> didrocks, exactly
[07:36] <mlankhorst> alf: afaict glisse reworked the whole thread code, no wonder it looked a lot more complicated than before ;P
[07:38] <mlankhorst> I don't see why the ncs member is atomic either, considering it's always protected by cs_stack_lock
[07:38] <duflu> Out of curiosity, has anyone tried a native GL (not ES) client in Mir? I can't remember seeing anyone having done so
[07:39] <alf> duflu: yes, glmark2-mir works
[07:39] <duflu> alf: Cool. I thought that was a port of "-es" ?
[07:41] <alf> duflu: Not really a port, the glmark2 code can produce binaries for both GL and GLES2.0, depending on the --with-flavors= you pass
[07:41] <duflu> alf: So you tested both?
[07:41] <duflu> Which is in the PPA?
[07:41]  * duflu looks
[07:42] <mlankhorst> alf: but the whole thread code looks messy to me :/
[07:43] <alf> mlankhorst: I will try to come up with a minimal example that hangs, so we can investigate (and prove the problem upstream) easier
[07:43] <mlankhorst> ok
[07:43]  * duflu realizes no glmark2 is in the testing PPA :/
[07:43] <mlankhorst> if you have one I'll fix it
[07:43] <alf> mlankhorst: great, thanks
[07:52] <tvoss> veebers, mind pinging me the bug number again?
[07:52] <mlankhorst> alf: but that code looks like a mess, needs more locking :P
[07:53] <mlankhorst> radeon_drm_cs_flush looks like it could deadlock if called from 2 threads simultaneously, might be by design though..
[07:55] <alf> mlankhorst: that would be a strange design... :)
[07:56] <mlankhorst> alf: I'm not sure it's legal to flush the same cs twice, but I'll know more with the reduced testcase
[07:56] <veebers> tvoss: sure: https://bugs.launchpad.net/autopilot/+bug/1181216
[07:56] <tvoss> veebers, thx
[07:57] <veebers> tvoss: nw
[07:57] <alf> mlankhorst: is the cs per process or per context?
[07:57] <mlankhorst> per context
[07:58] <alf> mlankhorst: and shared contexts also share the cs?
[08:00] <mlankhorst> I'll wait for the testcase first I guess, then I know if what you're doing is ok or not :p
[08:00] <alf> mlankhorst: ok
[08:05]  * tvoss is impressed by the brain to totally ignore the second cursor after some time of painful practice
[08:10]  * duflu thinks it's still handy to have a "watermark"
[08:11] <duflu> Because it tells me which display server I'm really using
[08:11] <duflu> But then so does the absence of VT switching :(
[08:13] <cking> thomi, ping
[08:15] <tvoss> duflu, RAOF I thought the vt switching was solved
[08:16] <duflu> tvoss: Nope. Just retested. Asked Robert if he thinks I'm missing any packages
[08:16] <duflu> tvoss: https://bugs.launchpad.net/bugs/1192429
[08:17] <tvoss> duflu, ack, thx for the bug
[08:34]  * tvoss off to kubuntu-desktop world
[08:36] <RAOF> BAH!
[08:36] <RAOF> Of course!
[08:37] <RAOF> I'm not mocking out enough.
[08:54] <RAOF> tvoss: Argh! I I realised why the device-probing branch isn't passing CI. There are no devices to probe under CI!
[08:55] <thomi> cking: hey, I'm kind of here, if it's quick.
[08:56] <cking> thomi, oh, I sent an email, it may be quick for you, not for me
[08:56] <RAOF> tvoss: Sending a mock through the GBMPlatform it is :)
[08:56]  * thomi looks
[08:57] <tvoss> RAOF, :)
[08:57] <RAOF> But tomorrow; I'm not going to have time to get that all ready before I need to sleep, so it can wait to tomorrow.
[08:59] <tvoss> RAOF, ack, I will see if I can get the powerful google udev stuff pulled out in a sane way somehow
[09:22] <alf> didrocks: https://code.launchpad.net/~afrantzis/mir/move-lttng-libs/+merge/171492
[09:25] <alf> duflu: @SnapshotStrategy, I tried to avoid verbified nouns, but in essence it is a Snapshotter or SnapshotTaker. Perhaps SnapshotTakingStrategy?
[09:26] <alf> duflu: oops that's nounified verbs
[09:26] <duflu> alf: I find *Strategy confusing. If you can communicate better with my feeble brain then I'm sure others might benefit similarly
[09:28] <alf> duflu: I am open to suggestions, but I couldn't find anything better without going to noun-ified verbs.
[09:28] <duflu> alf: Not sure about suggestions until I can understand what it is
[09:30] <alf> duflu: It's an interface (a role) that provides the functionality to take snapshots of surfaces
[09:31] <duflu> alf: A "camera" takes snapshots. I wonder if there's a good simile of "camera"
[09:32] <alf> duflu: I thought of "camera", but I found e.g. SessionCamera more confusing in terms of what it really is
[09:33] <duflu> alf: Yeah agreed it's not a good word. I think we're still in the realm of naming things according to what they do instead of what they are
[09:33] <duflu> Which sometimes suggests the functionality should not be in that class, but the class that uses it
[09:34] <duflu> But that might be over-generalizing
[09:34] <duflu> alf: What varies between different SnapshotStrategies?
[09:35] <alf> duflu: Many classes, however, are just helper classes that have a very specific role to play (also for TDD). It's hard to describe these in terms of a noun/object.
[09:36] <duflu> alf: Being more concrete doesn't eliminate TDD. Just makes it harder to think of the right words :)
[09:36] <duflu> But once you do, many people will benefit
[09:37] <alf> alf: Right now nothing, since we have only one production SnapshotStrategy. Potentially, everyything. You tell it to take a snapshot, and it can do it any way it likes.
[09:37] <alf> duflu: ^^
[09:38] <didrocks> alf: src/shared/lttng/tracepoint_provider.cpp is pre-processed?
[09:38] <didrocks> ({MIR_TRACEPOINT_LIB_INSTALL_PATH} is replace?)
[09:39] <alf> didrocks: it's a preprocessor definition (see src/shared/lttng/CMakeLists.txt)
[09:40] <didrocks> alf: interesting, didn't know that cmake had that! better than manually processing a config.h
[09:40] <didrocks> alf: approving then, thanks!
[09:40] <duflu> alf: Abstained. If neither of us can think of better names yet then it's not worth blocking on
[09:41] <alf> duflu: thanks, perhaps the US has some more suggestions
[09:57] <katie> tvoss_, time for a catch up in 3 mins?
[09:57] <tvoss_> katie, yup, let me grab coffee :)
[10:00] <katie> tvoss_, mpt is joining too
[10:00] <alf> didrocks: typo in MP, fixing
[10:01] <didrocks> ok :)
[12:44] <dholbach> Could anyone brainstorm with me which information we have which could go into fixing these docs bugs? https://bugs.launchpad.net/mir/+bugs?field.tag=docs
[13:12] <didrocks> michi___: small question on unity-api, from what I see, the .pc files won't be different per archs, right?
[13:13] <didrocks> ah, you -L the multiarch path in it (shouldn't be needed)
[13:24] <mterry> racarr, you might want to merge platform-api/mir-with-packaging with trunk for that `ua_ui_session_properties_set_remote_pid' issue I ran into yesterday
[13:54] <didrocks> mterry: speaking of platform-api, mind having a quick look at https://code.launchpad.net/~didrocks/platform-api/changelog-cleanup/+merge/171476?
[14:09] <mterry> didrocks, what do you mean you detect the arches we can't build for?
[14:10] <mterry> didrocks, but we don't change the control file, so we are still uploading to archive and causing dep-wait packages, right?
[14:11] <didrocks> mterry: detect the arch -> yeah, we don't live in stone age! :)
[14:11] <didrocks> mterry: basically I'm checking if we build-dep for an unimportant arch in distro
[14:11] <didrocks> (from last uploda)
[14:11] <didrocks> upload*
[14:11] <didrocks> if so, I'm ignoring the arch state in daily release
[14:12] <didrocks> (right now, "important archs" are i386, amd64, armhf)
[14:53] <kdub> morning all
[14:57] <alf> kdub: Hi! Long time no see :P
[14:57] <kdub> indeed
[15:00] <kgunn> kdub!
[15:00] <kdub> hello!
[15:05] <alf> status: [spike] Investigating how our components (mainly the compositor and friends) react to display configuration changes, and how we can solve the problems that come up.
[15:06]  * kdub is trying to drain the msh::Surface/ms::Surface swamp a bit :) also investigating how to hook the shell up to a signal to turn the screen off 
[16:14] <kdub> we should have a moratorium on classes with 'surface' in them for a while :)
[16:15] <mterry> greyback_, racarr : in compiling unity8-integrate-mir, I get:
[16:15] <mterry> /usr/include/mirserver/mir/default_server_configuration.h:21:28: fatal error: mir/cached_ptr.h: No such file or directory
[16:16] <mterry> which looks more like just a mir bug actually, since it's from a mir include
[16:17] <greyback_> mterry: that should be in /usr/include/mircommon, is that installed?
[16:17] <mterry> hmm, mirserver.pc requires mircommon.pc which has the right includes
[16:17] <mterry> greyback_, yes
[16:19] <greyback_> mterry: I'm not sure so. What's the compiler line "VERBOSE=1 make"
[16:21] <mterry> greyback_, oh weird.  main.cpp uses "#include <mirserver/mir/run_mir.h>" but I would expect it to use "#include <mir/run_mir.h>" with the appropriate -I cflags
[16:22] <mterry> and CMakeLists.txt doesn't seem to use the pc files
[16:22] <mterry> greyback_, but since this is a team branch I can fix myself
[16:22] <greyback_> mterry: it was hacked together to work, nothing more :)
[16:23] <greyback_> mterry: please do
[16:23] <mterry> racarr, it might be convenient if your other mir-packaging branches were team based too
[16:28] <mterry> greyback_, let's say I get unity8-integrate-mir built and installed on my phone.  How do I use it?  Like, how do I stop surfaceflinger from starting?
[16:29] <mterry> oh, he's gone
[16:29] <mterry> greyback_, let's say I get unity8-integrate-mir built and installed on my phone.  How do I use it?  Like, how do I stop surfaceflinger from starting?  Or do I just have to use the ./run -m -i script?
[16:30] <greyback_> mterry: the script works when you execute it from your PC
[16:31] <greyback_> mterry: else manually, adb root, "stop" to stop SurfaceFlinger
[16:31] <greyback_> mterry: make sure unity8 is not running
[16:32] <greyback_> then in the ubuntu chroot, run "QT_QPA_PLATFORM=ubuntumirserver unity8"
[16:33] <mterry> greyback_, hmm...  I bet there's a way to install it and modify the upstart jobs to not run surfaceflinger and to use that QT_QPA_PLATFORM variable.  I'll look into that in a bit (I'm trying to actually test final on-phone integration)
[16:33] <greyback_> mterry: the android side runs surface flinger, it's not upstart
[16:33] <mterry> guh, hm
[16:34] <mterry> greyback_, is this where flipped mode comes in?
[16:34] <greyback_> mterry: ultimately, it will help a lot, yes
[16:39] <kdub> mterry, i'd advise a stronger, 'make sure that surfaceflinger has never ran'
[16:40] <mterry> kdub, you mean "never ran this boot", not that surfaceflinger makes some permanent filesystem changes that are bad, right?
[16:40] <kdub> right
[16:40] <mterry> k..  I guess I need flip mode for that, and to modify how we start the android side...
[16:40]  * mterry is in unfamiliar territory
[16:41] <kdub> its just that sometimes, surfaceflinger hands out resources to the clients that persist after sf's actual death
[16:41] <kdub> and causes mir problems
[16:46] <greyback_> yep, I've noticed that. I make sure all UI apps are killed after stopping SF, before I run Mir
[18:49] <mterry> racarr, heyo.  So I realized that my goals with testing Mir are a little different than yours with that sketchpad.  I'm looking to have a fully installed Mir, rather than the ability to run a branch from your pc on the phone.  So rather than have two sets of instructions on the sketchpad, I started a new in-progress wiki page: https://wiki.ubuntu.com/Touch/Testing/Mir
[19:15] <racarr> mterry: Yay. Thanks.
[19:21] <gotwig> hello world
[19:23] <gotwig> is there a PPA for Unity + Mir ?
[19:24] <gotwig> oh I found this http://www.phoronix.com/scan.php?page=news_item&px=MTM5Mzc
[19:27] <racarr> kdub: http://www.phoronix.com/scan.php?page=news_item&px=MTM5NTg
[19:27] <racarr> congratulations, you've won the official phoronix most revisions award
[19:27] <racarr> I'll be picking up your trophy at the engraver
[19:28] <kdub> haha :)
[19:39] <gotwig> guys have you seen this?
[19:39] <gotwig> http://www.phoronix.com/scan.php?page=news_item&px=MTM5NDU
[19:40] <gotwig> racarr, nice
[19:41] <kgunn> mhall119: ping
[19:44] <mhall119> kgunn: pong
[19:44] <kgunn> mhall119: do you happen know why on this automagic site http://unity.ubuntu.com/mir/installing_prebuilt_on_pc.html
[19:44] <kgunn> that the numbering stays on one ?
[19:45] <kgunn> when the *.md file source that populates it, is clearly 1,2,3,4, etc
[19:45] <kgunn> (i'm considering just removing the #s....will that be easier?)
[19:45] <mhall119> is that doxygen generated?
[19:47] <kgunn> mhall119: from *.md to wiki...i dunno (i thot you had helped us with this? i'm wrong?)
[19:48] <mhall119> no, I can publish docs, but I'm not the one who gets them put together
[19:48] <mhall119> it might have been thomi ?
[19:51] <gotwig> why havent you talked to the wayland devs, in "the secret development process" of mir?
[19:55] <thomi> morning guys
[19:55] <thomi> (and girls)
[20:00] <gotwig> you should read the "Mir Development Stats Dominated By Canonical comments http://phoronix.com/forums/showthread.php?81653-Mir-Development-Stats-Dominated-By-Canonical&p=338644#post338644 ﻿
[20:02] <gotwig> or this http://phoronix.com/forums/showthread.php?81653-Mir-Development-Stats-Dominated-By-Canonical&p=338687#post338687
[20:05] <gotwig> it would be nice if someone could answer me
[20:05] <gotwig> mhall119, ?
[20:09] <racarr> gotwig: I'm not sure what you are asking :)
[20:09] <gotwig> racarr, well, have you read the posts?
[20:09] <racarr> We have talked to Wayland devs, and the development process, isn't particular secret
[20:10] <gotwig> I mean right at the beginning of the development
[20:10] <gotwig> I know what commit logs are..
[20:12] <gotwig> racarr, have you read the last post I linked?
[20:12] <gotwig> he basicly says that in wayland apps can run without a compositor, and can directly talk to GPU
[20:12] <gotwig> in Mir, however, he states that the concept is similar to Xorg
[20:13] <racarr> :) I think it's pretty normal to develop some confidence in your ideas before going public with them, espescially when you are a large organization under a lot of scrutinity and with a lot of responsibility to your users.
[20:13] <racarr> I
[20:13] <racarr> don't really understand the post sorry
[20:13] <racarr> it seems to be quibbling about the fact that 'wayland' is just a specification
[20:14] <racarr> on the other hand, I think anyone can talk about "wayland"
[20:14] <racarr> and it's understood what they mean ;)
[20:14] <gotwig> racarr, you really dont understand it?
[20:14] <racarr> Mir applications can access the frame buffer
[20:14] <racarr> directly
[20:14] <racarr> no, I don't. I don't think it makes sense
[20:15] <racarr> it's setting up a false dichotomy, i.e.
[20:15] <gotwig> well, I am not such a die hard core level dev, so I just want to find something intressting to read, so I can understand it better
[20:15] <racarr> Mir is a server, whereas wayland is a specification, therefore mir applications can't access the framebuffer directly
[20:15] <gotwig> and I found these answers
[20:15] <racarr> but
[20:15] <racarr> that's not true
[20:16] <gotwig> why would apps want to access the framebuffer directly
[20:16] <racarr> Imagine you have made a video fullscreen, it seems pretty wasteful to wake up the compositor every time
[20:16] <racarr> the video changes right?
[20:16] <gotwig> why do you go with this "server" way? Because you want to have something more practical than in theory?
[20:17] <gotwig> greyback_, howdy =)
[20:17] <racarr> gotwig: It's not so different, a weston compositor is a 'server' too
[20:17] <gotwig> racarr, but wayland apps dont have to use a compositor
[20:17] <greyback_> gotwig: hi there
[20:17] <racarr> gotwig: Well, yes, if you want to run one at a time from a virtual terminal
[20:18] <racarr> in any real use cases though, it doesn't make a difference, because you either need to composite, or sometimes you can let apps skip composition (like fullscreen videos)
[20:18] <gotwig> racarr, he says that its better with the "wayland" way for fullscreen games, which dont need any overload from any system compositor stuff ;X
[20:18] <racarr> and it's something both wayland, X11, and mir all support pretty easily.
[20:18] <racarr> gotwig: There's no overhead :)
[20:19] <racarr> that's why I don't understand the post
[20:19] <mhall119> gotwig: Weston is the Wayland compositor, IIRC
[20:19] <gotwig> but as of today compositing can also be disabled on Xorg
[20:19] <gotwig> what is different here?
[20:19] <gotwig> as of today I think is the wrong phrase ;D
[20:20] <gotwig> mhall119, I know =)
[20:20] <mhall119> gotwig:  I think whomever wrote this doesn't have a clear understanding of what is what
[20:20] <racarr> in non composited Xorg, rather than having offscreen memory buffers (in GPU of course) for window regions
[20:20] <mhall119> or at least they didn't do a good job of communicating it
[20:20] <racarr> the applications all share the framebuffer
[20:21] <racarr> this is why, in non composited, when you drag a window off from another one, sometimes you can see
[20:21] <racarr> it takes a while to update.
[20:21] <racarr> Mir and Wayland only support uncomposited in the case of a single fullscreen surface
[20:22] <gotwig> are there any major things which are going to be faster/slower in Mir/Wayland?
[20:22] <gotwig> flaws, from the concept
[20:23] <kgunn> gotwig: can you make a proposal what might be faster/slower in terms of a concept ?
[20:23] <kgunn> thomi: just checking...do we have stress as part of CI ?
[20:23] <gotwig> kgunn, no, that is because I ask this question...
[20:23] <kgunn> gotwig: surely you could propose something you might consider a potential ?
[20:24] <gotwig> Mir is going to be the always wanted "System Compositor" for Ubuntu, as far as I understand it
[20:24] <mhall119> gotwig: both Mir and Wayland are likely to be much faster than X11 because of their design
[20:25] <mhall119> they will probably be comparable in terms of speed between them
[20:25] <kgunn> gotwig: keep in mind regardless of a name, any compositor can be "bypassed", this is industry standard practice
[20:26] <mhall119> so the poster seems more familiar with Wayland, and I think is trying to address inaccurate descriptions of Wayland's features
[20:26] <mhall119> I don't think he's saying there's anything wrong with Mir
[20:27] <kgunn> mhall119: sure...just trying to help....because statements like "apps can run without a compositor, and can directly talk to GPU"
[20:27] <kgunn> just aren't sensible
[20:28] <kdub> yeah
[20:29] <mhall119> it seems he's saying that technically you could run a single Wayland client, which wouldn't require a compositor like Weston (or Gnome Shell)
[20:29] <kgunn> gotta go
[20:30] <mhall119> but in reality nobody's gonna do that, they're going to have a session compositor and multiple windows
[20:30] <mhall119> and only bypass the compositor for things like fullscreen games
[20:30] <mhall119> which is the same in X.org, Mir and Wayland
[20:30] <racarr> plus you can use libmirserver to run without  compositor ;)
[20:30] <racarr> like unity does
[20:31] <racarr> it's compositors all the way up and down
[20:31] <racarr> :p
[20:31] <mhall119> gotwig: so tl;dr, there's not that much conceptual difference between Wayland and Mir
[20:32] <gotwig> thx
[20:47] <gotwig> you may want to read this http://www.phoronix.com/vr.php?view=MTM5NDU
[20:47] <gotwig> Xserver integration in the linux kernel for a performance boost
[21:04] <kdub> racarr, starting to see the light at the end of the tunnel with msh::Surface :)
[21:08] <racarr> kdub: Yay
[21:09] <racarr> I am trying to pass the socket credentials up through the frontend...it's pretty mundane :p
[21:10] <thomi> kgunn: not yet, hoping to get that done this week
[21:12] <racarr> class that receives (pid, app-id) (desktop file)
[21:12] <racarr> and says hey you can connect or hey go away
[21:13] <racarr> SessionAuthorizer, Approver?
[21:15] <robert_ancell> Hmm, has olli actually gone sailing or is that his standard quit message?
[21:15] <robert_ancell> kgunn, ^
[21:22] <racarr> robert_ancell: I think I have seen that before
[21:23] <racarr> olli went sailing 2/3 times he quit today XD
[21:27] <robert_ancell> olli, that was a quick sail :)
[21:27] <olli> :)
[22:06] <robert_ancell> kgunn, https://code.launchpad.net/~kgunn72/mir/instructional_updates/+merge/171654 updated
[22:07] <kgunn> robert_ancell: ta!
[22:08] <thomi> robert_ancell: I finally got all the u-s-c stuff installed, now when I reboot I get the "low graphics mode" dialog box, and my mouse doesn't work. Any ideas?
[22:08] <robert_ancell> thomi, look at lightdm.log
[22:08] <robert_ancell> it failed to start X it seems
[22:09] <kgunn> robert_ancell: approved https://code.launchpad.net/~robert-ancell/mir/instructional_updates/+merge/171677
[22:09] <robert_ancell> kgunn, you'll have to manually merge it, see the "to merge this branch" line at the top. Then push it to your branch to update your MP
[22:10] <olli> RAOF, ping
[22:12] <kgunn> robert_ancell: so "bzr merge lp:~robert-ancell/mir/instructional_updates" merges it locally(on my box) ? or remote as well ?....e.g. then do i have to do a subsequent push ?
[22:12] <robert_ancell> kgunn, just locally, then bzr commit it, the bzr push it to LP
[22:13] <kgunn> robert_ancell: thanks again for your patience :)
[22:13] <robert_ancell> kgunn, I thought it would be a good example of bzr so I did it this way :)
[22:14] <thomi> robert_ancell: the log looks fine to me: http://paste.ubuntu.com/5803018/
[22:14] <robert_ancell> thomi, [+16.12s] DEBUG: Process 1423 terminated with signal 6 - that's u-s-c crapping out. Look at unity-system-compositor.log
[22:15] <robert_ancell> readable error that followed: [+16.12s] DEBUG: Stopping Unity seat, compositor terminated
[22:15] <robert_ancell> thomi, what hardware btw?
[22:15] <thomi> robert_ancell: http://paste.ubuntu.com/5803023/
[22:16] <thomi> robert_ancell: I believe it's a radeon something something
[22:16] <robert_ancell> terminate called after throwing an instance of 'boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<std::runtime_error> >'
[22:16] <robert_ancell>   what():  Failed to schedule page flip
[22:16] <robert_ancell> RAOF, any idea?
[22:16] <robert_ancell> thomi, that's the problem..
[22:17] <thomi> robert_ancell: no, I tella  lie, it's an intel i915
[22:17] <robert_ancell> and it looks like X locked up, because it didn't respond to signal 15, or die when u-s-c died
[22:18] <robert_ancell> thomi, can you check versions of lightdm, u-s-c, x to confirm?
[22:18] <thomi> sure
[22:18] <thomi> lightdm is 1.7.3bzr1628saucy0.71u-s-c is 0.0.1bzr29saucy0.87
[22:19] <thomi> what package should Ibe looking at for x? 'xorg'?
[22:21] <robert_ancell> thomi, xserver-xorg-core
[22:21] <thomi> xserver-xorg-core is 2:1.13.3+xmir1-0
[22:22] <robert_ancell> thomi, I have an older u-s-c, I'll update and see if I get the problem
[22:22] <thomi> ok, thanks
[22:23] <robert_ancell> thomi, I'm 00:02.0 VGA compatible controller: Intel Corporation Core Processor Integrated Graphics Controller (rev 18) for the record
[22:26] <mterry> kdub, hello!  So let's say I have a unity8 binary that I think should work.  Do I need to start a system compositor first, or will just running that binary autostart all the necessary mir bits?
[22:27] <olli> robert_ancell, one quick q
[22:28] <kdub> mterry, i think it should work just like that
[22:28] <olli> why do we need to pin mir
[22:28] <olli> to make sure the ppa has always a higher prio?
[22:28] <robert_ancell> olli, otherwise an update in main might drop the additional features, e.g. lightdm
[22:28] <olli> ok
[22:28] <robert_ancell> you would be safe, but you'd stop using Mir every time it would happen
[22:29] <mterry> kdub, hmm, ok.  It seems to be running, but nothing shows on device screen.  Will dig deeper
[22:43] <thomi> robert_ancell: any luck upgrading u-s-c?
[22:44] <robert_ancell> thomi, just in the middle of a mir build, will try once that's complete
[22:44] <thomi> ok, I'll try and be a bit more patient :)
[22:45] <kgunn> thomi: so i see above you had issues....
[22:45] <kgunn> i was about to wade into the deep....were you building
[22:45] <kgunn> or using staging or using sys-comp-testing
[22:45] <kgunn>  ?
[22:45] <thomi> kgunn: I'm running the sys-comp-testing PPA
[22:46] <kgunn> thomi: eeeewwww, giving me second thots
[22:46] <thomi> kgunn: heh
[22:46] <thomi> kgunn: if robert_ancell can reproduce, then I guess we have a problem
[22:46] <kgunn> thomi: hmmm, think i'll hold off....go do my personal errands and check IRC a bit later :)
[22:46] <thomi> BTW, why the need for a second PPA?
[22:56] <robert_ancell> thomi, for the sys-comp-testing ppa over the staging PPA?
[22:56] <robert_ancell> 92%...
[22:56] <thomi> robert_ancell: the sys-comp-testing ppa
[22:56] <thomi> I don't have the staging PPA enabled
[22:56] <RAOF> olli: Pong.
[22:56] <robert_ancell> thomi, were you asking why we have both PPAs?
[23:00] <RAOF> robert_ancell, thomi: That would be what it says on the box - Mir failed to schedule a pageflip (ie: to actually display something), which probably means the GPU hung.
[23:01] <robert_ancell> RAOF, did we do the correct behaviour in this case, i.e. give up?
[23:01] <RAOF> I think give up is a perfectly reasonable response.
[23:02] <thomi> RAOF: why would that be though? the mir_demo_server always works on this machine
[23:02] <thomi> I don't understand why it would fail now?
[23:03] <RAOF> thomi: Does dmesg have anything radeonish?
[23:03] <thomi> RAOF: I was mistakedn about it being radeon, it's an intel i915
[23:04] <thomi> ...and I would tell you, but I just tried rebooting it, and now it hangs somewhere in the boot phase with a blank screen
[23:05] <robert_ancell> thomi, you might want to look at https://code.launchpad.net/~robert-ancell/mir/mir-demos-install-path/+merge/171685. In particular I'm not sure how your lttng libs are supposed to work, thought that might be related to bug 1194555?
[23:05] <kgunn> thomi: this is weird...but have you tried hitting keys to inject noise/slow down...and see if it boots
[23:05] <robert_ancell> ok, trying new u-s-c now..
[23:06] <thomi> ugh. black kscreen hang, no response to any keys, cannot ssh in :-/
[23:06] <kgunn> i had same boot to hung screen (black)
[23:06] <kgunn> right....start hitting as soon as its booting....
[23:07] <kgunn> frighteningly...i have to do this currently to get into my machine on boot now :)
[23:07] <thomi> kgunn: nope, no difference
[23:07] <kgunn> thomi: eeewww....now i'm really not gonna try the latest
[23:07] <thomi> I guess it's time to start downloading a new raring image then
[23:07] <thomi> good thing it's my testing laptop, not my main
[23:10] <robert_ancell> thomi, from cold-boot to session with new u-s-c, no problems
[23:12] <thomi> robert_ancell: I'll reinstall the machine. Kind of worrying that it's possible to brick a laptop with this PPA though :-/
[23:12] <thomi> well
[23:12] <thomi> not "brick", but make unrecoverable
[23:12] <robert_ancell> thomi, couldn't you uninstall u-s-c from low graphics mode?
[23:13] <thomi> robert_ancell: I have no keyboard or mouse in low graphics mode. The machine is basically frozen
[23:13] <robert_ancell> we really should have some support to detect if you made it to a shell, but a bit harder to add
[23:13] <thomi> Ctrl+Alt+F1 does nothing either
[23:15] <RAOF> Huh.
[23:15] <RAOF> If you wave your mouse around in low graphics mode you should eventually get a cursor.
[23:15] <RAOF> The cursor doesn't show up until it's over the dialog box.
[23:15] <RAOF> Which is silly, yes.
[23:16] <thomi> well, while I'm downloading the new image I might head into town to run some errands. BBL
[23:18] <robert_ancell> thomi, bye
[23:22] <robert_ancell> RAOF, do we have enough info to debug what thomi is seeing? Is there anything else we could add?
[23:24] <RAOF> robert_ancell: Not really enough info. *Some* sort of log would be handy!
[23:24] <robert_ancell> RAOF,  from mir?
[23:24] <RAOF> From anything - mir, dmesg, lightdm. But mir would be an obvious candidate.
[23:25] <RAOF> Even booting without splash and seeing where it hangs would be good.
[23:31] <olli> robert_ancell, I was looking at the VT bugs... trying to find one that describes how my password (when entered in Xmir/u7) ends up on console
[23:31] <olli> is that reported yet?
[23:31] <robert_ancell> olli, I'll get you the bug
[23:32] <olli> https://bugs.launchpad.net/unity-system-compositor/+bug/1192429
[23:32] <olli> https://bugs.launchpad.net/lightdm/+bug/1193207
[23:32] <olli> it's neither of these imho
[23:32] <robert_ancell> nope
[23:33] <robert_ancell> olli, bug 1102756
[23:33] <robert_ancell> bug #4 on the list :)
[23:34] <olli> robert_ancell, thx
[23:34]  * olli adds a "don't try at home" disclaimer