[00:02] <robert_ancell> RAOF, what is wrong with your connection in general? You G+ calls are barely working!
[00:04] <RAOF> I don't know.
[00:04] <RAOF> I *can* get
[00:04] <RAOF> I *can* get > 1MB/sec down from the internode mirror.
[00:10] <racarr> RAOF: I had to try really hard to laugh sometime in the meetings, becaue you would have a conversation with omeone and from my perpective it was about
[00:10] <racarr> 70% machine noise
[00:10] <racarr> and 30% word
[00:11] <racarr> that was why "We only need to care about input when we want to"
[00:11] <racarr> was so hilarious because it came out super clear after about 20 seconds of machine noise
[00:11] <racarr> haha
[00:11] <RAOF> Hah
[00:11] <racarr> I got what you were getting at though
[00:12] <RAOF> My natural verbosity is leveraged as an error-correcting code. Yay!
[00:39] <robert_ancell> Does anyone know of a method to give properties to a rendering backend? I need to tell the GBM platform to use a specific VT, but there doesn't seem to be any channel for backend properties
[00:48] <RAOF> There's currently no channel to do that.
[00:55] <RAOF> robert_ancell: I think to do that you'd need to (a) extend DefaultConfiguration to handle a new cmdline parameter, then (b) Extend the interface to create_platform() to pass those configuration options in, and then (c) make the GBMPlatform pass those through to GBMDisplay, and then (d) make GBMDisplay actually act on it.
[01:04] <robert_ancell> RAOF, yeah, I thought that would be likely
[01:04] <robert_ancell> RAOF, though the options might not come from the command line, so I was thinking just key-value paird
[01:04] <robert_ancell> pairs
[01:05] <RAOF> The options parser also handles environment variables, so that's close already.
[01:06] <robert_ancell> RAOF, the boost one?
[01:06] <RAOF> Whatever one we actually use. It might be the boost one?
[01:06] <racarr> Yep
[01:06] <racarr> each command line option is also
[01:07] <racarr> an enviroment variable, i.e. --foo-bar is MIR_SERVER_FOO_BAR
[01:55] <RAOF> Ok. Apparently the reason why unity-system-compositor doesn't give any output for me when it fails on startup is because it never gets to main()‽
[01:58] <duflu> RAOF: Nice. That would mean either failure to find DSOs, or a DSO is crashing in init (before main)
[01:59] <RAOF> Silently!
[02:00] <duflu> RAOF: env LD_DEBUG=all   ?
[02:00] <RAOF> Wow. That really dumps *all the things*, doesn't it.
[02:01] <duflu> There are alternatives to "all". Try "help"
[02:02]  * RAOF reboots to give that a whilrlygig.
[02:15] <RAOF> Hah. It must be getting SIGKILLed by lightdm for starting slowly :)
[02:15] <RAOF> That's not very useful.
[02:17] <robert_ancell> RAOF, It took more than 5 seconds?!
[02:17] <RAOF> robert_ancell: Oh, yes.
[02:17] <RAOF> You underestimate the boot time of my goddamned laptop.
[02:18] <robert_ancell> RAOF, If you have any clever idea of how to avoid that timeout let me know. I guess there has to be some hard coded value
[02:18] <robert_ancell> RAOF, you can set the timeout on a recent commit in the config file btw
[02:18] <RAOF> Yeah, I'll just set that and then be about my business.
[02:18] <RAOF> You could probably just wait for the system compositor to respond on its pipes or die; it's *probably* not going to hang.
[02:20] <robert_ancell> RAOF, it's the *probably* we need a catch for otherwise you'll hang forever
[02:20] <robert_ancell> Is there a number low enough for the user not to hard reset but to be pretty much sure the compositor/driver has failed? 30s? 1min?
[02:21] <RAOF> Dunno.
[02:22] <RAOF> Not hanging is something that we should be able to make the vast majority of cases, so we might just not catch that.
[02:22] <robert_ancell> RAOF, well, then setting it to 5 mins should work
[02:22] <RAOF> And rely on the failed-boot mechanics to get the user somewhere sane *next* boot.
[02:22] <robert_ancell> ah, true
[02:22] <robert_ancell> RAOF, it would make the regression tests faster if we drop that feature
[02:24] <RAOF> At some point we should be able to just drop it. That point might be now
[02:24] <RAOF> What's the config key for the timeout?
[02:25] <robert_ancell> unity-compositor-timeout in [SeatDefaults]
[02:26] <RAOF> Ta.
[02:27] <RAOF> Well, that's unhelpful.
[02:27] <RAOF> Ish.
[02:27] <RAOF> Setting that timeout to an insane value makes u-s-c work for me.
[02:28] <RAOF> NO BUG REPRODUCTION FOR YOU!
[02:29] <robert_ancell> RAOF, how long does it take? (from lightdm.log)
[02:29] <RAOF> HAH!
[02:29] <RAOF> 5.36s
[02:30] <RAOF> Sorry, 5.26s, 'cause it takes .10s to get to the point of starting u-s-c.
[02:30] <robert_ancell> !
[02:30] <robert_ancell> default -> 10s?
[02:30] <RAOF> Maybe?
[02:31] <RAOF> Why not go 60; that's a nice round number, and even the slowest, most degraded btrfs filesystem surely can't take more than 60s to start u-s-c. ☺
[02:32] <robert_ancell> sure
[02:32] <robert_ancell> RAOF, do you want to do the MP?
[02:32] <RAOF> Yeah, I can do that.
[02:33] <RAOF> Hm. I wonder why it's saing “Unable to set active session, unknown client name 0”?
[02:33] <RAOF> Or, rather, why can't it find that client name.
[02:34] <robert_ancell> RAOF, full log?
[02:37] <RAOF> robert_ancell: http://paste.ubuntu.com/5782352/
[02:37] <RAOF> That's startup, switching to a guest session, and back.
[02:37] <robert_ancell> Looks like the session hadn't connected in time
[02:37] <RAOF> Yeah.
[02:37] <robert_ancell> Though clearly some more logging is needed..
[02:38] <robert_ancell> I thought I'd linked up logs to when sessions connected, but apparently didn't find the right class for that..
[02:57] <duflu> robert_ancell: I was thinking there's a distinct lack of demo/manual test programs for the session stuff. It's a bit slow depending on lightdm to test that externally...
[02:58] <robert_ancell> duflu, not sure what you mean - 1-1 anyway?
[02:58] <duflu> robert_ancell: Yes am online
[02:58] <duflu> Allegedly
[03:08] <robert_ancell> RAOF, I think you merged into the wrong thing - https://code.launchpad.net/~raof/mir/lightdm-longer-u-s-c-timeout/+merge/170478
[03:08] <robert_ancell> lp:mir instead of lp:unity-system-compositor
[03:09] <duflu> https://code.launchpad.net/~vanvugt/lightdm/fix-1192051/+merge/170362
[03:34] <robert_ancell> RAOF, lp:~mir-team/lightdm/unity rather
[03:35] <RAOF> robert_ancell: Yeah, just retargetting.
[03:36] <robert_ancell> RAOF, can you do the 1-1 earlier, say nowish?
[03:37] <RAOF> Sure.
[04:51] <robert_ancell> RAOF, https://code.launchpad.net/~robert-ancell/lightdm/unity-disable-tests/+merge/170485
[04:55] <RAOF> robert_ancell: https://code.launchpad.net/~raof/lightdm/lightdm-longer-u-s-c-timeout/+merge/170486
[05:28] <tvoss> duflu, ping
[05:29] <duflu> tvoss: Pong. Seems I tend to get back from lunch when you log on in the mornings
[05:29] <tvoss> duflu, perfect timing then :)
[05:29] <tvoss> duflu, we both are sleepy, that is, and long for coffee
[05:30] <duflu> I got a real coffee on the way back from lunch \o/
[05:30] <tvoss> duflu, \o/
[05:47] <duflu> RAOF: What was your system-compositor exiting problem?
[05:49] <RAOF> duflu: It was taking 5.2 seconds to start, and lightdm was sending SIGKILL after 5 seconds.
[05:50] <duflu> RAOF: Oh. Why so slow?
[05:50] <RAOF> Because btrfs
[05:50] <duflu> Wow
[05:51] <RAOF> It's *significantly* better now than it has been. It takes less than a minute to get to the unity-greeter.
[05:51] <RAOF> It used to take more than five.
[05:52] <tvoss> RAOF, wow, that's long turnaround time
[05:52] <RAOF> btrfs *really* doesn't like snapshots on rotating rust.
[05:52] <RAOF> Over time its performance degrades to basically nothing.
[05:53] <RAOF> I think my worst-case boot time was 20 minutes to the greeter.
[05:53] <RAOF> Which is a pity, because btrfs has a bunch of awesome features.
[07:04] <RAOF> robert_ancell: Hey, is there currently any way for XMir to tell when it gains or loses focus?
[07:32] <robert_ancell> RAOF, I don't think so
[07:35] <RAOF> I think I could bodge something together by listening for motion events, but it's probably better to actually fix the protocol so that clients can tell when they're focussed.
[07:35] <RAOF> racarr? :)
[07:40] <robert_ancell> RAOF, did you confirm the X acceleration is fixed from boot?
[07:41] <RAOF> Yup.
[07:41] <robert_ancell> RAOF, i.e. bug 1191937
[07:41] <robert_ancell> Nice
[07:41] <RAOF> Works For Me™
[07:41] <RAOF> Breaks once you try and do user-switching, of course, but until then, it works fine :)
[07:42] <robert_ancell> I was just thinking that the VT number might be wrong based on the duflu review of my VT branch for mir - I set XDG_VNTR to the number in /dev/ttyN - but VT numbers are off by one
[07:42] <robert_ancell> i.e. tty1 = VT0
[07:42] <robert_ancell> or duflu has just confused me
[07:43] <RAOF> I think duflu might have confused you.
[07:43] <duflu> Well it doesn't look like a Mir bug. We're asking for VT n and it appears on tty n+1 (Alt+(Fn+1))
[07:43] <duflu> Looks designed that way
[07:44] <duflu> I mean tty n+1 appears on VT n :)
[07:44] <duflu> Which is confusion, even if by design, that we should hide from the user
[07:45] <robert_ancell> duflu, are you sure the mouse pointer has anything to do with that change? I can't see the connection
[07:45] <duflu> robert_ancell: I can't see the connection either but it doesn't happen to trunk
[07:45] <duflu> I think you triggered a side-effect
[07:47] <tvoss> RAOF, for focus events: stay tuned, working with ricmm and racarr on that bit
[07:47] <RAOF> tvoss: Cool. Presumably they'll come through the event fd, like everything else?
[07:47] <tvoss> RAOF, presumably
[07:49] <robert_ancell> RAOF, thanks for the corrections btw :)
[07:50] <duflu> RAOF: Only input comes through the fd. All other events come over the protobuf
[07:51] <RAOF> duflu: The things in common/event.h don't all come over the fd?
[07:52] <tvoss> RAOF, yup, the input stream is separate right now
[07:52] <duflu> RAOF: Oh, yes. Input events (most of event.h) are on the fd. But MirSurfaceEvent (of which there are multiple sub-types) are on protobuf
[07:53] <RAOF> Ah, of course!
[07:53] <RAOF> One more thing to send through my thread-to-eventloop mechanism, I guess.
[07:54] <tvoss> RAOF, not sure duflu did some experiments with unifying the streams, I did some preliminary investigations and having the event stream separate turned out to be a good idea
[07:54] <duflu> I've been meaning to write a "ping" type benchmark to establish a baseline and we can work from there
[07:55] <tvoss> duflu, will dig out my experiemtn I did on the phone
[07:55] <RAOF> Eh. I guess XMir will just get a callback on a random thread, I'll send it through the pipe, and pick it up in X's event loop.
[07:55] <duflu> tvoss: Though you can't "ping" with input. Only surface events have simple request/response sequences via the client API... (?)
[07:56] <tvoss> RAOF, fair
[07:57] <duflu> RAOF: Most exciting is that *all* event types come to clients in the same callback, regardless of the transport :)
[07:57] <RAOF> Yay!
[07:57] <duflu> It gets combined in the client library
[07:58] <tvoss> duflu, iirc I tagged the input events with a timestamp
[07:58] <tvoss> duflu, but let me find the code :)
[07:58] <duflu> Sure
[08:34] <tvoss> mmrazik, ping
[08:34] <mmrazik> tvoss: pong
[08:50] <robert_ancell> didrocks, o/
[08:50] <seb128> robert_ancell, hey, how are you?
[08:50] <robert_ancell> seb128, hey, good
[08:50] <robert_ancell> yourself?
[08:50] <seb128> I'm good thanks
[08:51] <seb128> better today that this heat wave is over, I didn't like the 36°C from the past days much :p
[08:51] <seb128> now that*
[08:51] <robert_ancell> seb128, ow, that's hot for you guys!
[08:52] <seb128> indeed
[08:52] <ogra_> seb128, lucky you ... we still have it
[09:23] <robert_ancell> RAOF, hey, not sure if you noticed but I added conf.d support to lightdm - so you should be able to make /etc/lightdm/lightdm.conf.d/99-unity-system-compositor.conf and set the seat type in there
[09:24] <robert_ancell> It should work better than lightdm-set-defaults?
[09:25] <robert_ancell> didrocks, ^ actually, do you know if there's anything using lightdm-set-defaults that wouldn't work switched to using the conf.d dir?
[09:27] <robert_ancell> tvoss, good to see I'm not the only one worried about feature freeze :)
[09:27] <tvoss> robert_ancell, yup
[09:28] <duflu> RAOF, anyone, can you please kick off a Mesa build for raring? We don't have one since libmirclient0 became libmirclient1 ... https://launchpad.net/~mir-team/+archive/staging/+packages
[09:28] <duflu> Hence the build failures and crashes I mentioned on mir-devel
[09:37] <robert_ancell> duflu, I'm having a look inside Jenkins. I know it can be done, but Jenkins is a little scary
[09:38] <duflu> robert_ancell, no problem. I have a workaround
[09:38] <duflu> But it's ugly
[09:38] <robert_ancell> duflu, for you or for everyone?
[09:38] <duflu> robert_ancell, on mir-devel
[09:38] <tvoss> mmrazik, can you help here?^
[09:39]  * robert_ancell wonders how close we are to dropping raring in the PPA
[09:40] <mmrazik> looking
[09:40] <mmrazik> duflu: what needs to be done? Just dput the mesa into ppa again?
[09:40] <duflu> mmrazik, Maybe. Haven't checked the cause of failure
[09:41] <didrocks> hey robert_ancell!
[09:41] <mmrazik> duflu, robert_ancell: FYI -- the following job takes whatever is in the git repo and dputs into the ppa
[09:41] <robert_ancell> didrocks, hello
[09:41] <mmrazik> :
[09:41] <mmrazik> http://10.97.2.10:8080/job/mesa-egl-platform-mir-dput/
[09:41] <mmrazik> just triggered it
[09:41] <didrocks> robert_ancell: I think they should be fine with using conf.d (it's mostly metapackages generated from the seeds)
[09:41] <robert_ancell> mmrazik, ta
[09:41] <mmrazik> usually its triggered by git change but if you trigger manually it will do the same
[09:42] <duflu> mmrazik, thanks. Fingers crossed
[09:58] <duflu> robert_ancell, should I spend the time trying to fix plymouth properly or move on to transitions?
[09:59] <robert_ancell> duflu, transitions
[09:59] <robert_ancell> duflu, because we need that to work for the phone
[09:59] <duflu> True
[09:59] <duflu> I might make some dinner instead. 6pm is a bad time to start something new
[10:00] <robert_ancell> :)
[10:00] <duflu> Not to mention 10pm
[10:14] <RAOF> duflu: Mesa won't build against libmirclient1 on raring until *Mir* 0.0.4 builds on raring.
[10:14]  * duflu looks
[10:17] <duflu> RAOF: As it happens, Mir 0.0.4 _can't_ build on raring due to the bug I'm trying to solve... https://launchpadlibrarian.net/142922154/buildlog_ubuntu-raring-amd64.mir_0.0.4bzr760raring0_FAILEDTOBUILD.txt.gz
[10:17] <duflu> And the build won't succeed until it's done against a Mesa that links libmirclient1 :/
[10:17] <duflu> Chicken or egg?
[10:18] <tvoss> duflu, RAOF, robert_ancell do we _need_ raring?
[10:18]  * duflu does for efficient development
[10:18] <robert_ancell> tvoss, no, just waiting for everything to finish using it
[10:19] <duflu> It's only a PPA problem. We can support raring if only we rebuild Mesa, somehow
[10:19] <RAOF> duflu: Why won't the build succeed until it's done against a Mesa that links libmirclient1?
[10:20] <duflu> RAOF: see my emails on mir-devel. Because we link to Mesa libs that use libmirclient0 (PPA) and also link to libmirclient1 locally
[10:21] <duflu> How did we fix it for saucy?
[10:21] <duflu> Should be the same solution
[10:22] <duflu> /usr/bin/ld: warning: libmirclient.so.0, needed by /usr/lib/gcc/x86_64-linux-gnu/4.7/../../../x86_64-linux-gnu/libEGL.so, may conflict with libmirclient.so.1
[10:23]  * tvoss wonders if it would be a lot of effort to split out the mesa egl into libEGL.so, which is a chim loading libEGL_${PLATFORM}.so
[10:24] <tvoss> duflu, RAOF ^?
[10:25] <duflu> tvoss: Not sure. I'm looking at the dependency graph...
[10:26] <tvoss> duflu, that would unbreak our build and ease multi-egl-platform support
[10:26] <duflu> Ah it's the client+server being built together that's the problem
[10:26] <RAOF> Yes.
[10:26] <RAOF> If we split libmirclient out, it would be much easier.
[10:27] <duflu> EGL depends on mirclient. And mirclient depends on nothing important but gets built *with* mirserver which depends on EGL. So we have a dependency cycle we don't really need
[10:27] <duflu> I think hikiko mentioned this before
[10:27] <tvoss> duflu, unfuck that please :)
[10:27] <tvoss> duflu, oh well, you are eod already :)
[10:27]  * duflu will try to /action/ that another day
[10:27] <tvoss> yup :)
[10:28] <tvoss> duflu, sorry :)
[10:28] <duflu> Sounds messy
[10:28] <duflu> tvoss: Looks like separation of source packages :P
[10:29] <tvoss> duflu, ack, noted it down to nag you tomorrow my morning :) or is it already friday for you? not sure ... damn tz
[10:41] <duflu> Do we *need* MirMesa on the build system? Could it just build with standard Mesa?
[10:41] <duflu> Have we added any symbols to libEGL for Mir?
[10:42] <alan_g> duflu: your sleep is more important
[10:43] <RAOF> duflu: We do not need MirMesa on the build system.
[10:43] <RAOF> duflu: We can happily build against stock mesa.
[10:43] <duflu> That's a solution then
[10:43] <duflu> if it works
[10:43] <duflu> Well, it's not a long term solution
[10:43] <duflu> We don't want to reach universe with this cycle problem
[10:45] <robert_ancell> bye all
[10:46] <tvoss> robert_ancell, bye )
[10:46] <tvoss> :)
[11:14] <tvoss> ffs, https://launchpad.net/~mir-team/+archive/system-compositor-testing/+build/4730486 is so slow I want to help the builder with compiling myself
[11:14]  * tvoss takes out pen and paper ... 
[11:48] <tvoss> RAOF, if still around: failed to install usc from system-compositor testing unity-system-compositor : Depends: libmirserver0 (= 0.0.4bzr759saucy0) but 0.0.4bzr760saucy0 is to be installed
[11:48] <kgunn> tvoss: no!!!!
[11:50] <tvoss> alf, mmrazik I think we just need to copy over usc again from staging to system-compositor-testing
[11:51] <mmrazik> usc?
[11:51] <tvoss> mmrazik, unity-system-compositor
[11:52] <tvoss> mmrazik, but you might want to wait until mir for i386 completes, although I think we are hitting a hanging builder :/
[11:52] <mmrazik> ok
[11:52] <RAOF> tvoss: Urgh, right. I shouldn't have copied the binaries for usc from staging.
[11:53] <RAOF> tvoss: Yeah, a new copy *without* binaries would work.
[11:53] <tvoss> RAOF, just forcing a rebuild against the current mir version, right?
[11:53] <RAOF> tvoss: Exactly. Except that it's built successfully before, so you need to bump the version to get launchpad to rebuild it :)
[11:54] <tvoss> RAOF, you mind doing that real quick?
[11:58] <RAOF> tvoss: Done like a dinner.
[11:58] <RAOF> I'll prepare for bed, then check that it's accepted into the PPA, then sleep :)
[12:00] <tvoss> RAOF, yup :) \o/
[12:00] <kgunn> RAOF: thnka you
[12:00] <kgunn> ....oh and thank you as well
[12:00] <arsson> So is there any ppa for mir that might actually work?
[12:03] <RAOF> Good, that's accepted. amd64 will be installable when https://launchpad.net/~mir-team/+archive/system-compositor-testing/+build/4730713 finishes.
[12:04] <RAOF> tvoss: Could I get you to babysit https://launchpad.net/~mir-team/+archive/system-compositor-testing/+build/4730715 ? You just need to hit the retry-build button once i386 mir has built.
[12:05] <RAOF> …which it looks like it's not going to, because the build has hung again. What is going on with the buildds?
[12:05] <RAOF> Anyway, I'm not going to get anything more done tonight.
[12:06] <tvoss> RAOF, sure, will look at it
[12:06] <tvoss> RAOF, will kill the mir i386 build and retry, too
[12:07] <tvoss> retriggered
[13:29] <tvoss> ffs
[13:30] <alan_g> tvoss: ?! No need for that
[13:33] <tvoss> alan_g, the buildd for the testing ppa hangs again
[13:35] <alan_g> tvoss: patience is considered a virtue
[13:35] <tvoss> alan_g, violence is not a solution but an option?
[13:36] <alan_g> tvoss: I usually find a polite request to mmrazik results in a solution
[13:37] <mmrazik> alan_g: when it comes to ppa/buildd I can't do much :-/
[13:37] <mmrazik> I can only help with jenkins
[13:37] <tvoss> mmrazik, yup :9
[13:38]  * tvoss muses that the buildds are hidden away in a 1.5 dimensional manifold somewhere/sometime
[13:39]  * alan_g wonders who can be made responsible for that bit of infrastructure
[13:41]  * kgunn wonders why tvoss keeps mentioning "flash file system" ;)
[13:42]  * kgunn unfortunately...actually knows why
[13:53]  * alan_g wonders why someone called a static library "mirsharedandroid"
[14:11] <tvoss> alan_g, would you mind checking if a clean mir checkout builds fine with dpkg-buildpackage for you?
[14:13] <alan_g> tvoss: I don't mind - but what's the incantation for it?
[14:18] <tvoss> alan_g, to rule out that we have something non-buildable in the repo
[14:18] <alan_g> tvoss: I mean I don't want to look up how to use it
[14:19] <tvoss> in mir's root: dpkg-buildpackage
[14:22] <alan_g> running...
[14:31] <tvoss> alan_g, thx
[14:32] <alan_g> np - but a single process takes a while
[14:33] <alan_g> (Tried -j8  but that borked)
[14:34] <tvoss> alan_g, how long can /build/buildd/mir-0.0.4bzr760saucy0/obj-i686-linux-gnu/bin/acceptance-tests --gtest_list_tests
[14:34] <tvoss> take?
[14:35] <alan_g> ...run. Finished OK
[14:35] <alan_g> tvoss: that depends
[14:36] <alan_g> But if it takes more than a few milliseconds you've a very slow box
[14:37] <alan_g> real	0m0.012s FWIW
[14:59] <kdub_> hello all
[15:08] <alf> kdub_: Hi!
[15:09] <alan_g> hello one
[15:12] <alf> alan_g: kdub_: Have a moment to take a look at https://code.launchpad.net/~afrantzis/mir/base-stubs-on-null-platform/+merge/170550 ? I have code that depends on this, waiting to be MPed :)
[15:12] <kdub_> sure
[15:13]  * alan_g thinks "this implies a way to avoid seeing those waiting MPs"
[15:21] <alf> alan_g: yes, so you, as the reviewer, get a double benefit from me doing it like this (and not using dependent branches) 1. you get simpler/cleaner MPs 2. you can control (to a degree) the incoming review queue :)
[15:22] <alf> alan_g: kdub_: thanks for the quick action
[16:00]  * tvoss goes to setup an i386 chroot
[16:23] <alf> Saviq: tvoss: What format do you expect the snapshot pixels to be in?
[16:24] <kdub_> tiled 3 planar yuv!
[16:25] <alf> kdub_: \o/ :)
[16:26] <kgunn> greyback: ^
[16:28] <greyback> alf: rgba probably, but I'm checking
[16:29] <alf> greyback: ok, r,g,b,a in memory or 0xRRGGBBAA as an int?
[16:35] <greyback> alf: ok, at the moment we read ARGB32 premultiplied, each pixel an unsigned char.
[16:39] <alf> greyback: can you point me to where you got this information?
[16:43] <greyback> alf: qtubuntu, src/modules/application/application_image.cc, line 63/64
[16:43] <alf> greyback: thanks
[16:43] <greyback> alf: that's where the platform api passes us the pixels for the image
[16:57] <mterry> racarr, poke when you've got a moment to talk libhybris crashes
[16:59] <racarr> mterry: I can try and parse :D feeling kind of out of it this morning
[16:59] <mterry> racarr, :-/ suck
[16:59] <mterry> racarr, so remember yesterday, I was seeing a crash in mir_demo_server on the nexus7
[16:59] <mterry> racarr, I finally got debug versions of libhybris and mir built
[16:59] <racarr> mm
[16:59] <mterry> racarr, this is the full bt: http://pastebin.ubuntu.com/5784142/
[17:00] <mterry> racarr, seems to actually be in thread 17 when it dies
[17:00] <mterry> racarr, which is in hooks.c in libhybris
[17:00] <mterry> I'm looking at that code now, but it seems hooks.c has an early opt-out for nvidia...
[17:02] <alan_g> Goodbye all!
[17:03] <kdub_> bye alan
[17:03]  * kdub_ thinks we might need a 'quirk' system for these closed drivers
[17:03] <kdub_> maybe.. :) we should probably try to avoid it
[17:08] <racarr> mterry: I can't really determine anything besides hybris is fucked
[17:12] <mterry> racarr, ah...  If I run mir_demo_server under GRAPHICS=NVIDIA, it doesn't segfault
[17:12] <mterry> racarr, so it was just the nvidia_hack not being used
[17:12] <mterry> I'll try to actually run the demo code
[17:14] <mterry> racarr, "Assertion `mir_connection_is_valid(connection)' failed." -- does that mean the server isn't running right
[17:16] <racarr> mterry: Yeah
[17:16] <racarr> mterry: Or say one is running as root and the other is user
[17:16] <racarr> or it crashed on connect
[17:17] <mterry> racarr, still seems to be running as root (same user)
[17:18] <racarr> does the server crash when you try and connect?
[17:18] <mterry> seemingly not, it's still runnig
[17:58] <arsson> I guess i'm running unity-system-compositor. still two cursors but unity de is working.
[18:00] <arsson> I have nouveau installed, should i install nvidia proprietary drivers?
[18:12] <arsson> tearing
[18:16] <kgunn> arsson: per the mir instructions....
[18:16] <kgunn> mir only works on open drivers atm
[18:16] <kgunn> unity-sys-comp will fallback to standard x (non-xmir)
[18:17] <kgunn> if you install proprietary drivers back in
[18:35] <mterry> racarr, how does a client connect to a server?  DBus or a socket or something?
[18:39] <racarr> mterry: Socket.
[18:40] <racarr> mterry: /tmp/mir_socket
[18:48] <mterry> racarr|dentist, hmm, it exists.  I want a super-verbose mode in Mir
[18:56] <kgunn> mterry: weird huh....mir working right....makes you wonder if its working :)
[18:59] <mterry> kgunn, I see your thing above about only working on open drivers.  What is our plan for nexus7?
[19:00]  * mterry has to run out
[19:10] <kgunn> mterry: ah...that statement is only a desktop thing
[19:10] <kgunn> libhybris allows for bins on mobile platforms
[19:16] <tvoss> RAOF, ping
[20:20] <arsson> cannot change icons.
[21:17] <robert_ancell> RAOF, assuming you're not online yet...
[21:34] <kdub> now if i can just get the driver to stop leaking buffers, i'm in the clear! :)
[21:36] <kgunn> robert_ancell: previously, i had been toggling successfully between xmir attempts (& back) simply #commenting out the type=unity
[21:36] <kgunn> in theory should that be all that's needed ?
[21:36] <robert_ancell> kgunn, yes
[21:38] <kgunn> robert_ancell: ok....so i'm on lightdm for this w/ type=unity commented _out_.....and i hang
[21:38] <robert_ancell> kgunn, check there's not a second entry for type - I have seen that
[21:40] <robert_ancell> kdub, do you need root for mir on android?
[21:40] <ricmm> hey guys
[21:40] <ricmm> is it possible to run mir/shell as user?
[21:40] <kdub> robert_ancell last i checked, yes
[21:40] <ricmm> oh, he already asked
[21:41] <ricmm> kdub: do you know the reason?
[21:41] <robert_ancell> ricmm, I know on desktop you need root for the VT stuff
[21:42] <kdub> ricmm, let me try to run as user, i'll see what happens...
[21:43] <kdub> oh, actually...
[21:44] <ricmm> getting a segfault in pthreads
[21:45] <kdub> seems ok on the nexus 4 for me
[21:49] <kgunn> robert_ancell: just in case https://pastebin.canonical.com/93186/
[21:49] <kgunn> this is my lightdm.conf
[21:49] <ricmm> kdub: do you have a maguro at hand?
[21:49] <robert_ancell> kgunn, yeah, you have type=unity on the last line
[21:50] <kdub> ricmm, yeah, i'll fire it up and see
[21:50] <ricmm> kdub: thanks!
[21:51] <kgunn> robert_ancell: so are the instructions wrong? http://unity.ubuntu.com/mir/using_mir_on_pc.html
[21:51] <robert_ancell> kgunn, sorry, you are trying to enable or disable xmir?
[21:51] <kgunn> robert_ancell: nvmd....sorry....i am officially an idiot
[21:51] <kgunn> actually....did you do something to auto-magically add that ?
[21:52] <kgunn> i dont remember that being there
[21:52] <robert_ancell> kgunn, RAOF made a change so u-s-c adds it on install
[21:52] <kgunn> cool
[21:52] <kgunn> now i know....sorry for not looking closer
[21:52] <kdub> ricmm, yeah... as far as I can tell, on maguro, you can't drive the display without root
[21:52] <robert_ancell> but it doesn't recognise a quoted out entry, so it adds a new one if you've got a previously disabled one
[21:52] <robert_ancell> kgunn, it caught me out the other day too :)
[21:53] <ricmm> kdub: are you seeing the same segfault tho?
[21:53] <kdub> yep
[21:53] <ricmm> or is it something else
[21:53] <ricmm> right
[21:53] <kdub> well, probably the same one :)
[21:54] <ricmm> ;)
[21:54] <ricmm> does it happen in pthread_mutex_destroy?
[21:56] <kdub> ricmm, yes
[21:56] <ricmm> ok
[21:56] <ricmm> I'll look into it, sucks tho, I only have maguro :(
[21:57] <ricmm> segfaults in pthread over hybris is rsalveti's land
[21:57] <ricmm> ill go cook while he returns
[21:57] <ricmm> racarr: welcome back
[21:57] <racarr> Danke.
[21:58] <racarr> now 50% done with teeth repair
[21:58] <racarr> not counting the root canal next week
[22:19] <robert_ancell> Can I get someone to do a quick review of https://code.launchpad.net/~robert-ancell/unity-system-compositor/command-line-options/+merge/170562 and https://code.launchpad.net/~robert-ancell/lightdm/unity-usc-command-line/+merge/170561
[22:19] <robert_ancell> Fairly small changes, but required to set the VT for XMir
[22:23] <robert_ancell> brb
[22:26] <robert_ancell> kgunn, ok, so I can get into my session from the u-s-c PPA
[22:26] <kgunn> robert_ancell: i'm sure its me....somewhere along the line
[22:27] <robert_ancell> kgunn, yeah, it looks like it
[22:27] <robert_ancell> kgunn, uninstall mir and u-s-c and then try reinstalling
[22:32] <kgunn> robert_ancell: ack...i'll leave you alone for real work....
[22:33] <robert_ancell> kgunn, finally! ;)
[22:34] <kgunn> robert_ancell: hah!
[22:57] <jono> robert_ancell, legend!
[22:57] <jono> thanks for doing the interview :-)
[22:58] <robert_ancell> jono, :)
[22:58] <jono> also, just sent https://lists.ubuntu.com/archives/mir-devel/2013-June/000183.html
[22:58] <jono> maybe this is something you chime in with
[23:16] <RAOF> robert_ancell: Correct! I'm not online at 7:15 :)
[23:28] <robert_ancell> RAOF, if looks like you doubly approved https://code.launchpad.net/~robert-ancell/lightdm/unity-usc-command-line/+merge/170561 and not the other one..
[23:28] <RAOF> Urgh, really?
[23:29] <RAOF> Welcome to the morning, I guess :/
[23:29] <robert_ancell> :)
[23:30] <robert_ancell> RAOF, I'm trying to find confirmation, but do VT numbers start at 1?
[23:30] <RAOF> I believe so.
[23:33] <RAOF> robert_ancell: vt_ioctl.c says ‘if you pass 0 in as the VT to VT_ACTIVATE you get a shiny new ENXIO error for your troubles’
[23:33] <robert_ancell> heh
[23:35] <mlankhorst> :>
[23:37] <ricmm> kdub: Dynamic exception type: boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::system::system_error> >
[23:37] <ricmm> std::exception::what: bind: Address already in use
[23:37] <ricmm> getting that, after a while of debugging my pthreads
[23:37] <ricmm> I was getting the shell to start but no graphics, probably due to permissions on the fb devices
[23:37] <ricmm> but once clearing perms I'm getting that
[23:37] <kdub> so are you still getting that error?
[23:37] <ricmm> no longer the segfault
[23:39] <kdub> so, is that a fatal error then?
[23:39] <ricmm> this one? yes
[23:39] <kdub> ah, ok. hmm
[23:39] <ricmm> bind: Address already in use
[23:39] <ricmm> stale socket?
[23:39] <kdub> sounds like an ipc sort of error
[23:39] <kdub> thats what i was thinking
[23:40] <kdub> stale root-owned socket maybe?
[23:40] <kdub>  /tmp/mir_socket
[23:40] <ricmm> yup, that was it
[23:40] <ricmm> so im running eglplasma and I get nothing on screen
[23:40] <ricmm> however I get the FPS ticker
[23:41] <kdub> hmm, getting closer
[23:41] <ricmm> yup, sounds like the screen isnt being turned on or something
[23:41] <ricmm> is this something that Mir does? maybe permissions on some node that controls it
[23:41] <ricmm> works fine as root
[23:42] <kdub> any errors or anything? (logcat, dmesg)
[23:44] <ricmm> E/IMGSRV  (  929): :0: PVRSRVCreateDCSwapChain: Error - 10 returned
[23:44] <ricmm> E/IMGSRV  (  929): :0: framebuffer_device_open: Failed to create flip chain; retrying
[23:44] <ricmm> I remember those, seen them before
[23:44] <ricmm> uhh
[23:44] <kdub> yeah, they just happen when it can't set up the display
[23:45] <ricmm> crap I remember doing something the last time I got that, but I forgot what it was