[00:10] <RAOF> Hm. Dear Mir: I'm *pretty* sure that I don't want to drive my external panel at 23.91Hz.
[00:15] <kgunn> :))
[00:24] <RAOF> Sweet. That seems to work.
[00:34]  * robert_ancell -> lunch
[00:47] <RAOF> robert_ancell: Please test xorg-server_1.14.2.901-2ubuntu3+xmirMM4 once it's built; that works for me.
[01:36] <robert_ancell> RAOF, will do
[01:45] <duflu> robert_ancell: Is it still qa-testing to use?
[01:45] <robert_ancell> duflu, yes
[01:46] <duflu> RAOF: Is there a tool for visually tweaking colour profiles?
[01:46] <RAOF> duflu: Not to my knowledge.
[01:48] <RAOF> Also worth noting that u-s-c won't apply any colour profile you might set, anyway.
[01:49] <duflu> RAOF: Yeah, wasn't for any test machine. Was just wondering in general.
[01:55] <duflu> RAOF: Is it possible to go above D65? I found profiles from Lenovo which claim to, but provided no visual change (not using Mir)
[01:57] <RAOF> duflu: As the target colour temperature? Sure.
[01:59]  * RAOF 's old CRT had two colour temperature presets: 6500K & 9000K
[02:00] <duflu> RAOF: Yeah, this particular display just seems to not change anything for the Lenovo profiles which claim to be higher
[02:00] <RAOF> Possibly it's not actually a display-correction capable profile?
[02:01] <RAOF> Stupid bloody flaky xvfb-run test!
[02:01] <duflu> RAOF: Fair point. Copied from Windows drivers...
[02:02] <RAOF> duflu, robert_ancell: amd64 packages have built in qa-testing, but you'll need to force install them as the i386 build that produces xserver-common has hung again.
[02:02] <robert_ancell> RAOF, yeah, watching that
[02:02] <olli> RAOF, is there something worth giving a shot?
[02:02] <robert_ancell> RAOF, did you just restart i386?
[02:02] <olli> or are you still building the xorg-server
[02:02] <RAOF> robert_ancell: I did indeed.
[02:02] <RAOF> olli: Yeah, this works for me¹
[02:03] <RAOF> ¹: Although I wasn't testing against a unity-system-compositor with multi-surface leak fix, so X rapidly became useless.
[02:03] <olli> RAOF, ok, I am about ready for bath & bedtime duty
[02:03] <olli> but will check back in ~1.5h
[02:03] <olli> exciting
[02:03] <RAOF> Everything should have built by then :)
[02:05] <kgunn> robert_ancell: RAOF ....so can't download amd64 until i386 finished either
[02:06] <robert_ancell> kgunn, you can, but you have to do it manually
[02:06] <robert_ancell> it's not published until both are built
[02:06] <robert_ancell> kgunn, i.e. click on each .deb and install them that way
[02:06] <RAOF> No, it's published, but apt will refuse to install it (as there's a strict dependency on xserver-common, which is only built by the i386 build)
[02:07] <kgunn> RAOF: right...that's what i experienced
[02:07] <kgunn> and there is no xserver-common yet
[02:07] <kgunn> scary...i am smart enough that i actually checked cache policy on boot...saw mm3 was installed, but mm4 was candidate
[02:08] <robert_ancell> RAOF, ah, that's annoying...
[02:08] <kgunn> tried to manually install then saw the complaining about common
[02:08] <robert_ancell> we really should build 'any ' packages on amd64 now
[02:08] <RAOF> kgunn: So, just downloading xserver-xorg-core, xserver-xorg-xmir .debs and dpkg --install --force-depends will work.
[02:08] <RAOF> ¹: Should ☺
[02:14] <kgunn> RAOF: mmmm...thanks...i'll just wait...would hate a false negative
[02:16] <kgunn> so curious...has anyone had any success with lttng on arm ?
[02:16] <kgunn> its installed and i can query kernel hooks...
[02:16] <kgunn> and i can create a log for mir..but it immediately throws an error for every command after that
[02:21] <robert_ancell> i386 built...
[02:31] <robert_ancell> and published!
[02:32] <RAOF> Hah. Seems like bypass might have broken it.
[02:33] <ricmm> kgunn: hey, still around?
[02:33] <kgunn> ricmm: yes
[02:33] <kgunn> RAOF: please tell me that's your crazy aussie humor :-/
[02:38] <kgunn> robert_ancell: RAOF ...i booted into X it seems
[02:39] <RAOF> kgunn: Well, on my dual-head test it ‘works’, but u-s-c only updates the display when I VT switch to it.
[02:39]  * RAOF is building the multi-surface fix branch minus bypass to see if that's a fix.
[02:40] <kgunn> hmmm....wait a minute...u-s-c not installed?
[02:40] <kgunn> oh...that's weird...updates on vt switch
[02:42] <robert_ancell> RAOF, the X package seems to have built against the system mir, not the one in the PPA - is that because the PPA is now behind the archive?
[02:42] <robert_ancell> Do PPAs not pin to themselves?
[02:42] <RAOF> robert_ancell: No, they do not.
[02:42] <robert_ancell> damn
[02:42] <kgunn> right....
[02:42] <robert_ancell> I'll update Mir, and we'll have to rebuild before main updates...
[02:43] <robert_ancell> kgunn, that  was blocking me from installing u-s-c - you probably have the same issue
[02:43] <kgunn> wait...so instead of waiting...i could try the --force-depends method right ??
[02:43] <RAOF> Oh, *that's* why it's broken!
[02:43] <robert_ancell> kgunn, maybe? It will still have built against the wrong Mir and without a stable ABI that's very dangerous
[02:44] <RAOF> Oh, actually, no, that's not it.
[02:44] <kgunn> robert_ancell used the word dangerous...i think i'll wait
[02:44] <RAOF> kgunn, robert_ancell: We *have* a stable ABI for mirclient, so it's harmless.
[02:44] <kgunn> dang it...i'm really running out of energy...
[02:44] <RAOF> We don't need to build XMir against the exact mir version.
[02:45] <robert_ancell> RAOF, oh, true. It just has a depends with a higher number than the one provided
[02:45] <robert_ancell> RAOF, what version of u-s-c are you running? The -cft one?
[02:45] <RAOF> yes
[02:46] <robert_ancell> So once we recompile Mir, we wont have to recompile X
[02:46] <RAOF> Oh, no. Sorry. Not using cft
[02:46] <RAOF> bah
[02:47] <robert_ancell> new mir uploaded...
[02:49] <kgunn> dude...how do we change the script to rid the i386 run for the time we're iterating
[02:50] <robert_ancell> I'm just asking the launchpad guys...
[02:51] <robert_ancell> previous builds indicate this will take ~45 mins
[02:51] <robert_ancell> Apparently that's the time to build all of android :)
[02:57]  * duflu wonders why apt-get upgrade wants to remove USC and xmir
[03:00] <robert_ancell> duflu, because it's built against libmirclient2 from the archive which is greater than the PPA version
[03:00] <robert_ancell> StevenK confirms it - i386 is hardcoded to be the "any" architecture so you can't drop it from a PPA
[03:00] <robert_ancell> duflu, we're rebuilding mir now..
[03:07]  * duflu now wonders why i915 is stuck around 90 wakeups/sec when compiz is less around 15
[03:08] <RAOF> The base-rate for i915 is going to be ~60Hz when there's been some form of activity.
[03:08] <duflu> And my fan/temperature is quite bad... This is with Mir though
[03:08] <duflu> *This is without Mir
[03:09] <duflu> RAOF: AFAIK, Intel will still clock down to 40Hz when it can
[03:09] <duflu> ... Just that you can't configure 40Hz modes any more. Is that intentional?
[03:12] <RAOF> duflu: Really? What monitors support a 40Hz refresh rate *and* support seamlessly changing between 40Hz and 60Hz?
[03:14] <duflu> RAOF: I haven't seen a physical 40Hz for a few years (Dell E4200 could do it). But the number of wakeups for i915 still drops to 40Hz when it can
[03:15] <RAOF> It *should* drop to 0 under conditions of no-load, but whenever output has occurred it'll pop back up to $REFRESH_RATE Hz as the vblank interrupts keep coming.
[03:16] <duflu> I remember that used to be a *feature* of Intel graphics, dynamically switching between 40/60Hz and Ubuntu did it no problem. Maybe intel dropped it in more recent chips
[03:17] <RAOF> Deliberately missing every third vsync?
[03:17] <duflu> RAOF: Something like that. Showed up as a mode you could fix in xrandr too
[03:19] <duflu> It appears i915 staying at 90 wakeups/sec is side-effect of multiple monitors. User processes are behaving though
[03:20] <RAOF> Oh, yeah. It'll be vsync interrupts.
[03:24] <robert_ancell> duflu, you got revision 1000!
[03:24] <duflu> Woo, I win, nothing
[03:26] <duflu> Weird, i915 seems to scale in multiples of 40/45 wakeups per second.
[03:28] <olli> is there anything to test
[03:34] <olli> RAOF, robert_ancell?
[03:34] <robert_ancell> olli, in progress..
[03:34] <olli> oki
[03:34] <robert_ancell> olli, just need u-s-c to rebuild
[03:35] <olli> ok, I guess I will bisect my kernel then for a while ;)
[03:35] <olli> also fun
[03:46] <kgunn> for the love of it all...even the publishing takes an eternity
[03:51] <RAOF> Hm. So, r985 + the client buffer tracking fix gets me something that's mostly working, but needs some damage region fixing in xmir
[03:54] <robert_ancell> published
[03:59] <duflu> Cool. Except I'll go to lunch first.
[04:01] <kgunn> rebooting...
[04:02] <robert_ancell> brb
[04:04] <kgunn> so i chose to hotplug, vga cable...looks like x crashed
[04:04] <kgunn> when i disconnected, it punted me back out ot the greeter
[04:10] <robert_ancell> hmm, not so good. Works fine without the second monitor, then flickers, mirrors for a bit (in greeter) then everything crashes
[04:11] <kgunn> hdmi - same computer...ends up with nothing on second...but "low gfx mode" on built-in
[04:11] <kgunn> altho...it has already crashed once...i should reboot to be fair
[04:13] <robert_ancell> this is VGA for me
[04:16] <kgunn> ok...i rebooted for hdmi, it does exact same thing as vga....which is 1st & second screen flicker & shows up (w/ purple feild...no unity....but a mouse cursor on both)
[04:17] <kgunn> and when i diconnect (both hdmi/vga) it flickers...punts me out to greeter
[04:17] <robert_ancell> RAOF, does this sound like the damage region issue you mentioned earlier?
[04:17] <RAOF> No; that didn't crash for me, it just only updated the display on VT switch.
[04:18] <robert_ancell> RAOF, it seems to be updating fine here, but unstable
[04:18] <RAOF> So, unity-greeter would come up and I'd see purple on each monitor ('cause that's the first thing that unity-greeter draws)
[04:20] <RAOF> Seems to work fine here in cloned mode, but not draw properly in non-cloned mode.
[04:20] <RAOF> And, yeah, a bit unstable on xrandr changes.
[04:22] <kgunn> RAOF: robert_ancell ...how to set mirror mode before connecting (at least the setting ui is greyed out until you connect the monitor)
[04:22] <RAOF> I started with both monitors attached :)
[04:23] <RAOF> So that defaults to clone on X startup.
[04:23] <robert_ancell> kgunn, X has a default that is hard-coded / set in the X config
[04:23] <robert_ancell> then an XRANDR client (e.g. gnome-setting-daemon) picks up the event and applies what it wants
[04:24] <kgunn> hmmm - i just booted with both monitors connected and it showed two purple fields/with 2 mice....but no ui after greeter login
[04:24] <kgunn> greeter login cloned just fine
[04:25] <robert_ancell> kgunn, no glitches while cloning?
[04:25] <kgunn> i should say my second screen is larger than my built in....
[04:26] <kgunn> don't know if that makes a diff
[04:26] <robert_ancell> I got flickering, especially in the top of the built-in and corruption on the bottom of the external
[04:26] <robert_ancell> same setup
[04:26] <kgunn> robert_ancell: i can't see a ui no matter how i connect the 2nd monitor vga/hdmi/boot/post-boot
[04:26] <robert_ancell> kgunn, oh, just purple?
[04:26] <kgunn> yep
[04:26] <robert_ancell> RAOF, what info can we get for debugging?
[04:27] <RAOF> kgunn: *That's* what I was seeing, and I'm pretty sure that's related to bypass.
[04:27] <RAOF> kgunn: If you get to all purple, VT switch away, then VT switch back, you should be able to see unity-greeter.
[04:28] <RAOF> duflu: What would be causing that ^^^
[04:28] <kgunn> RAOF: freaky....yes
[04:28] <duflu> RAOF: Never seen that
[04:28] <duflu> robert_ancell: What GPU?
[04:29] <RAOF> duflu: How much bypass testing did you do with multi-surface clients?
[04:29] <robert_ancell> duflu, Intel Corporation Core Processor Integrated Graphics Controller (rev 18)
[04:29]  * RAOF is likewise intel.
[04:29] <duflu> RAOF: None. We only have one multi-surface client and it doesn't trigger bypass. But shouldn't matter.
[04:29] <RAOF> We now have a second multi-surface client )
[04:29] <RAOF> :)
[04:29] <duflu> Yep
[04:30] <duflu> RAOF: Bypass has no visibility to clients. It only deals on a per surface basis
[04:31] <RAOF> *Something* between r985 and what's in the PPA broke updates on multi-head xmir.
[04:32] <duflu> I'm actually more concerned it sounds like no one has XMir+saucy+radeon/nouveau on a single machine. I know I don't.
[04:32] <kgunn> i don't get flickering...it like updates a frame or 2...then appears frozen (but its actually rendering...somwhere)
[04:33] <kgunn> if i keep vt switching back and forth....i see i've moved the mouse or launched an app....in the steady state i expect it
[04:33] <duflu> kgunn: What GPU?
[04:34] <RAOF> kgunn: Yeah. X clients are rendering, but it's not getting displayed by something in the XMir/unity-system-compositor stack.
[04:37] <duflu> Eventually my USC died with exception: Output has not associated crts
[04:37] <duflu> *crtc
[04:37] <duflu> That's after getting nowhere on login
[04:37] <kgunn> duflu: intel
[04:38] <robert_ancell> RAOF, should we expect improvement in MM5?
[04:38] <kgunn> this is freaky...i got youtube up...seeing if i can start a video
[04:38] <duflu> kgunn: If you can recover without rebooting or ssh in then check /var/log/lightdm/unity-system-compositor.log
[04:39] <robert_ancell> duflu, I have a fix to keep the old log on trunk, just don't want to make a lightdm release on a Friday...
[04:39] <kgunn> duflu: looks normal...dm_connection_start, set_active_session '0', set_active_session
[04:39] <RAOF> robert_ancell: Yes; it might be more stable, and in conjunction with the new xf86-video-intel it should render *both* heads in a non-cloned setup.
[04:40] <robert_ancell> RAOF, there's a new -intel MM4?
[04:42] <kgunn> wild...i got a youtube video playing (well i hear the audio...but obviously not playing on screen)
[04:42] <kgunn> ooo, and can vt switch really fast for stop motion video :)
[04:42] <RAOF> :)
[04:42] <RAOF> robert_ancell: Indeed there is.
[04:43] <RAOF> kgunn: Yeah. The problem is in the copying to Mir, not in the X client rendering.
[04:44] <kgunn> RAOF: so you gonna kick off the intel mm5 ?
[04:44] <kgunn> i'll stay up for one more round if so....but after that i'm cooked
[04:45] <duflu> That's annoying. We use the same exception message in multiple locations so I can't tell what really failed
[04:47] <duflu> robert_ancell: I'm going to try and do some more integration testing of bypass + MM. Where is the new MM stuff not on trunk yet? Any?
[04:47] <robert_ancell> duflu, it's the stuff in the ppa basically
[04:48] <duflu> robert_ancell: Yeah, but is there any MM functionality we're using not in lp:mir yet?
[04:48] <robert_ancell> duflu, the only unmerged branch is lp:~raof/mir/fix-multi-surface-buffer-tracking
[04:48] <duflu> ... there's none awaiting review
[04:48] <robert_ancell> it fails the tests on android
[04:48] <robert_ancell> but we don't care about that for this testng
[04:53] <duflu> OK, I'm going to take XMir out of the equation and try some integration testing of the constituent branches not on trunk yet
[04:56] <RAOF> https://code.launchpad.net/~raof/mir/fix-multi-surface-buffer-tracking/+merge/181259 is known-good
[04:57] <RAOF> In the sense that this is what I'm running now, and it fails in ways that should be fixed in xserver MM6 & xf86-video-intel MM4
[05:00] <duflu> RAOF: Yeah feels like integration issues, where each branch works fine by itself
[05:01] <RAOF> Entirely plausible.
[05:04] <duflu> If nothing else, bug 1211700 still scares me. And I do know that bypass makes that one worse.
[05:06] <tvoss_> good morning
[05:08] <duflu> Morning tvoss_
[05:17] <duflu> Note to self: Don't trust benchmarks while building on all cores
[05:17] <tvoss_> duflu, :)
[05:19] <robert_ancell> RAOF, are you building these changes locally before uploading? :)
[05:19] <RAOF> robert_ancell: I am now :)
[05:19]  * robert_ancell reads the debian/changelog entries
[05:19] <RAOF> The last couple were "obvious" changes :)
[05:23] <robert_ancell> btw the Mir build in ppa:mir-team/qa-testing2 is merged with trunk, because we need the version number bumped to be greater than archive. Do you think that would cause any issues?
[05:23] <robert_ancell> RAOF, ^
[05:25] <robert_ancell> I've got to do family jobs and dinner now so will keep popping back here to update builds and test things
[05:26] <duflu> Having per-session(client) monitor layouts is very confusing when I Alt-tab between clients :)
[05:26] <duflu> I Alt+Tab to a client and it's not there any more, it moves!
[05:27] <robert_ancell> duflu, heh, I think that's only meant to be allowed by the shell when they're full-screen
[05:27] <duflu> robert_ancell: Or rather "when the session is a login". We don't distinguish between client as a session, and login as a session
[05:28] <RAOF> robert_ancell: I don't think that will cause issues.
[05:35] <RAOF> Lets see if this does indeed give me multiple outputs...
[05:46] <duflu> I suspect Mir's hyper-sensitivity to the DRM state could become a problem. The slightest imperfection and it will die with an exception. We have managed to avoid such issues till now, but I wonder if XMir changing output configurations dynamically could affect that
[05:55] <RAOF> Woot.
[05:55] <duflu> ?
[05:55] <RAOF> Ok, so this mostly works; unity just doesnt' get the memon that the display config changed.
[05:56] <RAOF> Also there's some weird off-by-one-frame problem in the bit of the 2nd monitor that's not covered by both monitors.
[05:58]  * duflu thinks mir_demo_server_shell needs some key combos for manual testing of layout changes
[05:58] <RAOF> Yeah, that'd be fun.
[05:59] <duflu> RAOF: Merging both our branches with trunk and using two monitors works flawlessly. XMir must be doing something we don't or can't test yet. See previous comment
[06:00] <RAOF> Two fullscreen surfaces from one client?
[06:01] <duflu> RAOF: I shall hack together some testing for that
[06:02] <RAOF> I fiddled with mir_demo_client_accelerated to do that  recently. The patch should still be in backscroll
[06:04] <robert_ancell> RAOF, ppa:mir-team/qa-testing2 has mir+u-s-c ready - copy over the X packages when ready
[06:06] <duflu> RAOF: Actually I'm seeing a new regression with multi-win clients using plain old trunk :/
[06:07] <RAOF> duflu: :(
[06:08] <duflu> RAOF: Does demo_client_multiwin work for you any more?
[06:11] <kgunn> robert_ancell: RAOF amd64 xorg-intel failed due to wanting a new xmir...so i restarted it (guessing it was going out of order)
[06:12] <kgunn> i loaded the usc/mir on top of the last xorg....clone was ok-ish (still got punted to greeter)....and extended desktop was gnarly (eventual punt to greeter)
[06:13] <kgunn> i'm gonna head of to sleep...good luck guys
[06:13] <duflu> kgunn: OK bye
[06:13] <duflu> RAOF: There looks like a related issue on trunk, before either of the new branches: https://bugs.launchpad.net/mir/+bug/1215754
[06:28] <RAOF> duflu: Yup, confirmed.
[06:34] <duflu> Almost bisected...
[06:43] <duflu> RAOF: Bisected. Could bug 1215754 be relevant?
[06:44]  * duflu is presently rebuilding on a revision that *works* to try bypass with multi-surface clients
[06:46] <RAOF> duflu: Maybe? The symptoms are quite different.
[06:46]  * duflu is not aware of any symptoms with the PPA other than USC logging runtime_errors thrown about DRM
[06:47] <arsson> My both saucy installations is broke after todays updates, anyone else?
[06:47] <duflu> arsson: With PPAs or vanilla?
[06:47] <RAOF> v
[06:48]  * duflu goes back to no-PPAs for a sanity check of sauncy
[06:48] <duflu> *saucy
[06:49] <arsson> duflu: well i was having QA-testing on another ubuntu
[06:49] <duflu> arsson: Yes qa-testing is broken
[06:55] <arsson> But what happens to the other? There i was having xorg edgers, but i don't remember if it was enabled because i just needed that to take nvidia-325 driver.
[07:00] <dholbach> good morning
[07:10] <robert_ancell> RAOF, qa-testing2 is good to go now?
[07:10] <robert_ancell> RAOF, though I notice mir got out of date at some point
[07:14] <tvoss_> robert_ancell, which launchpad branch should I build?
[07:14] <robert_ancell> tvoss_, for multi-monitor?
[07:14] <tvoss_> robert_ancell, ack
[07:14] <robert_ancell> tvoss_, lp:mir + lp:~raof/mir/fix-multi-surface-buffer-tracking merged in
[07:15] <robert_ancell> tvoss_, or just use lp:~robert-ancell/mir/multi-monitor which is just that (and what is going into the PPA)
[07:16] <tvoss_> robert_ancell, ack
[07:18] <RAOF> robert_ancell: Yeah, it's got everything in it. It's more working, but still not all the way there.
[07:19] <duflu> OK, I think I might have found a bypass bug. But only reproducable with software surfaces, and lp:mir <=990 (because 991 and later is broken for other reasons)
[07:20] <duflu> RAOF: What's the pixelformat of XMir?
[07:20] <RAOF> rgbx_8888
[07:20] <RAOF> Or some permutation of that.
[07:27] <duflu> RAOF: How does XMir choose it? Or hardcoded?
[07:27] <RAOF> Hardcoded.
[07:28] <RAOF> It should expose the available formats to the XMir driver and then have that choose, but for the moment it's hardcoded.
[07:37] <RAOF> Aha!
[07:37] <RAOF> (Maybe)
[07:48]  * RAOF is the man who Creates all the Pixmaps!
[08:08] <duflu> Too many ideas, no time left.
[08:08] <asac> hi!
[08:09] <asac> so i am using unity-system-compository/xmir
[08:09] <asac> and it works great :)
[08:09] <asac> however, i have my x220 in a dock with external monitor and the resolution is not correct
[08:09] <asac> can i force this thing to use 1080p?
[08:11] <robert_ancell> asac, not yet, we're just testing multimonitor support
[08:12] <asac> robert_ancell: yeah... thought i might be able to force this thing somehow to take the resolution from this screen
[08:12] <asac> rather than automagic
[08:13] <robert_ancell> asac, at the moment it just uses the native resolution of the primary monitor
[08:13] <asac> yeah thats what i experience
[08:13] <asac> there is no brute-force way?
[08:13] <asac> :)
[08:13] <asac> no trick?
[08:13] <asac> :-P
[08:14] <robert_ancell> asac, the trick is to apt-get source, add support and recompile :)
[08:15] <robert_ancell> brb
[08:15] <asac> sounds eaasy
[08:15]  * asac doesa that
[08:16] <asac> wonder if thats the xorg mir thing or the compositor
[08:16] <asac> guess the former
[08:23] <robert_ancell> RAOF, I'm getting the same behaviour in ppa:mir-team/ppa-testing2 as I was in ppa:mir-team/ppa-testing
[08:27] <alan_g> ricmm: re session_lifecycle - you seem to have incorporated reverting recent changes into the MP.
[09:05] <RAOF> robert_ancell: Which behaviour was that again?
[09:16] <robert_ancell> RAOF, flickering, corruption on second screen
[09:16] <robert_ancell> RAOF, also, it appears unity crashes out when logging in
[09:39] <RAOF> robert_ancell: Ah, that's likely to be my "acutally resize the screen pixmap" bug that I'm fixing now.
[09:40] <RAOF> In other news: I've said this before, but ALWAYS #include <xorg-config.h> IN YOUR FILES, LEST YOUR STRUCTURES MAGICALLY HAVE A DIFFERENT LAYOUT THAN YOU EXPECT
[09:47] <pete-woods> tvoss: hi, do you have any time today to talk about the music hub / service? I've been asked to hook the sound indicator up to it
[09:47] <tvoss> pete-woods, sure, let me grab coffee real quick
[09:50] <pete-woods> cool
[10:00] <tvoss> pete-woods, can you open a hangout?
[10:02] <pete-woods> tvoss:sure
[10:02] <tvoss> pete-woods, thx
[10:03] <pete-woods> tvoss: https://plus.google.com/hangouts/_/453d38c0debd30d880901eef7114cd0241ef2f8e?authuser=1&hl=en
[10:14] <robert_ancell> RAOF, Will MM8 come in the next half hour or so?
[10:27] <robert_ancell> ok, my battery is telling me to call it a night. See you tomorrow
[10:28] <RAOF> robert_ancell: Should do.
[10:28] <RAOF> robert_ancell: 'gnight.
[10:40] <ricmm> alan_g: not sure what happened there, pushing fixed branch in a sec
[10:40] <ricmm> my bad
[10:42] <alan_g> ricmm: np
[10:47] <ricmm> alan_g: seems to be fine now
[10:47] <alan_g> ricmm: I will have another look...
[10:48] <ricmm> thanks
[12:05] <kgunn> RAOF hey...so will MM8 be worthy ? or is MM7 already worthy?
[12:07] <tvoss> kgunn, nope, better, but there is a stray Damage event killing us potentially
[12:08] <kgunn> updating now...i'm supposing we get punted to the greeter?
[12:09] <tvoss> kgunn, on monitor connect, yes
[12:24] <ricmm> alan_g|lunch: MR updated, last comment I dont think it warrants a change
[12:24] <ricmm> its just a trigger for the communication, which is what I'm testing
[12:24] <ricmm> and it guarantees arrival when expected if done that way
[12:27]  * ricmm coffee
[12:59] <ricmm> alan_g|lunch: went ahead and changed it too
[13:05] <alan_g> ricmm: ok
[13:39] <ricmm> alan_g: thanks for approving
[13:39] <ricmm> last jenkins just ran for the final rev
[13:39] <ricmm> if you want to top-approve at some point
[13:39]  * ricmm off to the doc
[13:39] <alan_g> ricmm: sure - but I like to give other team members a chance to review first
[14:58] <tvoss> racarr, you around?
[15:10] <tvoss> alan_g, I'm inclined to approve ricmm's mp
[15:11] <alan_g> tvoss: too late - I already did
[15:11] <tvoss> alan_g, ah :)
[15:19] <alan_g> ricmm: your MP failed to land - looks like a merge conflict
[15:22] <alan_g> tvoss: we were sabotaged by racarr and ricmm both adding an enum at the same place in the file
[15:22] <tvoss> alan_g, \o/
[15:26] <ricmm> sabotages
[15:26] <ricmm> :(
[15:29] <ricmm> alan_g: ok, conflict solved and pushed
[15:31] <alan_g> ricmm: top approved
[15:31] <ricmm> thanks
[15:32] <alan_g> yw
[16:38] <ricmm> alan_g: still around? same branch from robert added a test that was missing a method on my modified event sink
[16:38] <ricmm> so, need to top approve again :(
[16:38] <alan_g> ricmm: you've updated?
[16:39] <ricmm> yes
[16:39] <ricmm> test_surface.cpp builds fine now
[16:40] <alan_g> ricmm: top approved
[16:40] <ricmm> cheers
[16:52] <racarr> tvoss: Pong?
[17:54] <racarr> kgunn: So, DPMS coming back on still isn't cracking
[17:54] <racarr> talked about it with robert_ancell yesterday, and made the plan to land the API changes, etc
[17:55] <racarr> so we can update XMir
[17:55] <racarr> and finish the GBM impl as a bug
[17:55] <racarr> Make sense?
[18:18] <kgunn> racarr: so...does that mean android is happy? but gbm "no workie" ?
[18:18] <kgunn> racarr: if so, yes, plan makes sense
[18:19] <racarr> kgunn: No android isn't happy either
[18:19] <racarr> becuse android doesn't have display configuration yet
[18:19] <racarr> the deal is the clients can happily set DPMS but nothing happens yet :/
[18:19] <kgunn> racarr: ok...so this is simply about updating needed api's
[18:20] <racarr> yes
[18:20] <kgunn> racarr: makes sense....who will this break ? e.g. do we need to shout it out ?
[18:20] <racarr> Yeah mirclient API
[18:20] <racarr> I bumped ABI
[18:20] <racarr> :(
[18:21] <racarr> I wonder if its worth adding some padding to some of the structs at the same time
[18:21] <racarr> so i we need to change display configuration again can do it without breaking ABI
[19:09] <ricmm> https://launchpadlibrarian.net/148264842/buildlog_ubuntu-saucy-i386.mir_0.0.9%2B13.10.20130823.2-0ubuntu1_FAILEDTOBUILD.txt.gz
[19:09] <ricmm> :( ??
[19:42] <mlankhorst> racarr: .. or just a version in the struct :p
[19:44] <tvoss> ricmm, flaky, try again
[19:44] <ricmm> yea, already done
[19:47] <racarr> kgunn: Hey we got lucky for once!
[19:47] <racarr> I finally got to the stress test
[19:47] <racarr> so I decided to test if it still crashed in the same way
[19:47] <racarr> and just ran it for about 5 minutes while moving the mouse around and no crash
[19:47] <racarr> thomi: ^
[19:47] <racarr> When was the last time you tried XD
[19:49] <racarr> I think the create_surface_for changes may have made it so that the invalid surface exception you could get out of focus/input from the get_surface 'race'
[19:49] <racarr> is handled non fatally now
[19:49] <racarr> the only thing is its notabbly slower than it was when I had the test running a few weeks ago
[19:49] <racarr> i.e. I used to be able to run it and move the cursor with no noticeable lag
[19:49] <racarr> now there is definitely lag
[19:51] <racarr> seems too good to be true
[19:59] <tvoss> racarr, that there is a lag?
[20:00] <racarr> tvoss: No that the stress test fixed itself
[20:01] <racarr> and I don't have to
[20:01] <racarr> stress about it
[20:01] <tvoss> racarr, well, if there is a lag, we might want to investigate where :)
[20:02] <racarr> True
[20:02] <racarr> but its still nice to have part of it done
[20:04] <racarr> Going to let it run for the full 10 minutes no
[20:04] <tvoss> racarr, yeah, was just about to say that it's nice that it is working
[20:07] <racarr> tvoss: Except it was too good to be true
[20:07] <racarr> and almost immediately brought my hole system down this time
[20:07] <racarr> :p
[20:07] <racarr> back to the fun
[20:08] <tvoss> racarr, enjoy :)
[20:12] <racarr> tvoss: definitely :p
[20:18] <racarr> SessionMediator should only have a weak reference
[20:18] <racarr> to session
[20:18] <racarr> if its going to use
[20:18] <racarr> close/open session
[20:18] <racarr> and the session container is going to have ownership
[20:18] <racarr> can fix one of the races this way but I dont even know if this one is still exhibiting because I can't get backtraces or recover my system anymore
[20:21] <racarr> strange, that fixes the lag
[20:21] <racarr> maybe the lag was a bunch of handled exceptions
[20:21] <racarr> frontend handles some exceptions silently
[20:22] <racarr> Giving it a ten minute run again cross your fingers
[20:26] <kgunn> fingers crossed
[20:42] <racarr> Lag is intermittent
[20:42] <racarr> got two ten minute runs
[20:42] <racarr> with no crash though
[20:46] <racarr> ok another ten minute stress brb
[20:58] <racarr> :)
[21:07] <robert_ancell> RAOF, let me know when you're online
[21:16] <racarr> robert_ancell: So if the stress test is fixed (I think it is!) is there something I should be doing more important than trying to make DPMS impl ork?
[21:17] <robert_ancell> racarr, I think DPMS is a good goal
[21:18] <racarr> Ok ill work on it today, ill be around tomorrow too, and write up a hand over email/potentially finish it depending on how things go
[21:18] <racarr> sunday morning am gone though
[23:35] <RAOF> Alright. Where's that damageptr going wrong.
[23:35] <RAOF> robert_ancell: Good morning.
[23:36] <robert_ancell> RAOF, hi
[23:37] <RAOF> You were up early!
[23:38] <robert_ancell> normal time
[23:38] <RAOF> Or are you 2 hours ahead of me?
[23:38] <robert_ancell> yes
[23:39]  * RAOF always forgets that
[23:39] <robert_ancell> there's a merge conflict with  lp:~raof/mir/fix-multi-surface-buffer-tracking - I've fixed it in lp:~robert-ancell/mir/multi-monitor but you probably want to update your branch
[23:39] <RAOF> Urgh, ok.
[23:39] <robert_ancell> some whitespace changes around your change
[23:40] <RAOF> Will do while this server builds with -DDAMAGE_VALIDATE_ENABLE
[23:40] <robert_ancell> RAOF, also, I tried testing by running mir_demo_server then X -mir and I can reproduce the issues (flickering, X crash when plugging in monitor)
[23:41] <RAOF> There are two problems there; one mispassed pointer and then the stray damageptr
[23:41] <robert_ancell> RAOF, is there an easy way to build your branch locally so I can try it? Does it need all of debian/patches/*
[23:41] <robert_ancell> fixed in MM8?
[23:42] <RAOF> robert_ancell: I've pushed qa-testing-ppa to github.com/RAOF/xserver
[23:42] <robert_ancell> cool
[23:42] <robert_ancell> RAOF, also tvoss said he still had issues with MM8
[23:42] <RAOF> Yeah, the mispassed pointer should be fixed in MM8. The damage issue is still pending.
[23:48] <robert_ancell> X has a scary number of compile warnings
[23:50] <RAOF> It comes of being a codebase that still contains some honest-to-got K&R C
[23:58] <robert_ancell> RAOF, btw, did you find time to write that blog post?
[23:58] <RAOF> No
[23:58] <robert_ancell> k