[00:00] <robert_ancell> RAOF, ah
[00:48] <mterry> robert_ancell, guh, so many layers of abstraction to make a surface, and none of them include the session
[00:48] <robert_ancell> mterry, yes..
[00:48] <mterry> robert_ancell, I'm going to file a bug
[00:49] <robert_ancell> mterry, please do
[00:50] <mterry> robert_ancell, https://bugs.launchpad.net/mir/+bug/1200035
[00:50] <ubot5> Ubuntu bug 1200035 in Mir "Should expose the session that a new surface is for" [Undecided,New]
[01:11] <mterry> robert_ancell, is that bug something I should assign to you?
[01:11] <mterry> Or shall I look into it?
[01:11] <robert_ancell> mterry, if you feel up to it go ahead
[01:11]  * robert_ancell -> lunch
[01:11] <mterry> robert_ancell, it will take me longer, but I suspect you are pretty busy already
[01:12] <robert_ancell> yep :)
[01:12]  * mterry rolls up sleeves
[01:12] <mterry> robert_ancell, but basic approach is just to modify all the layers between session and surface to include session pointer, eh?
[01:12] <mterry> in the create_surface call
[02:34] <robert_ancell> thomi, is the docs uploader still broken?
[02:53] <duflu> robert_ancell: Do you prefer Skype or Hangouts?
[02:53] <robert_ancell> duflu, hangouts
[02:53] <duflu> robert_ancell: OK, the usual one?
[02:54] <robert_ancell> duflu, there's a usual one?
[02:55] <duflu> robert_ancell: Umm, give me a link, any link
=== jono is now known as Guest7396
[04:34] <RAOF> Damn duflu's flaky internet!
[04:34] <thomi> robert_ancell: yeah, I need to update the configuration, it's been on my TODO list all day
[04:34] <thomi> will do it now
[04:34] <robert_ancell> thomi, ta
=== Mirv_ is now known as Mirv
[05:18] <didrocks> robert_ancell: hey, FYI, kevin told me he would look at the clang issue if he has time, I have no idea how to fix it as I don't use it
[05:28] <thomi> robert_ancell: IS are fixing something relating to the mir docs uploads. I'll come back later and see if it's fixed. Gotta go help with dinner now though
[05:38] <duflu> YES. Internet tubing fixed. Let's hope it sticks.
[05:42] <RAOF> WOOT!
[05:42] <RAOF> duflu: Hey, can I ask some compiz rendering questions?
[05:42] <duflu> RAOF: OK. Might remember
[05:43] <RAOF> Well, I guess it's really only a single question.
[05:43] <RAOF> In two parts!
[05:43] <duflu> Does it always swapbuffers? :)
[05:43] <RAOF> 1) Does compiz use the composite-overlay window? and
[05:44] <RAOF> 2) Does it ensure the composite overlay window is fullscreen?
[05:44] <duflu> 1) Can't remember. I vaguely recall the "overlay window" is deprecated.
[05:44] <duflu> smspillaz can verify
[05:45]  * duflu looks at the code
[05:46] <duflu> RAOF: Yes it does use overlay windows: plugins/composite/src/screen.cpp
[05:47] <duflu> Also window.cpp
[05:48] <RAOF> Ok.
[05:48] <duflu> RAOF: And they are not guaranteed full screen
[05:48] <RAOF> Hrm.
[05:48] <duflu> Which I guess is part of the reason why unredirect works with multi-monitor
[05:49] <RAOF> Heh, yeah.
[05:49] <duflu> Oh, hang on
[05:50] <duflu> RAOF: There was other logic mentioning overlay. I think the answer is yes it is only ever one overlay == root window:     overlay = XCompositeGetOverlayWindow (screen->dpy (), screen->root ());
[05:51] <duflu> But the root window is all outputs, not "full screen"
[05:51] <RAOF> Right.
[05:53] <RAOF> Getting GLX bypass for anything spanning more than one monitor is not going to happen. Sadly.
[05:54] <RAOF> But that's not soooo bad.
[05:55] <duflu> RAOF: Can we still have it for windows which fit a single monitor?
[05:55] <RAOF> Yes.
[05:56] <duflu> Cool. Though I just realize my existing logic doesn't handle the multi-monitor case for bypass
[05:56] <duflu> +d
[05:56] <duflu> Then again, there are no multi-monitors yet
[05:56] <RAOF> The condition should be “GLX window exactly covers an entire monitor and has override-redirect set”
[05:57] <duflu> RAOF: No, not override-redirect. It's a normal window. The decision is based on stacking order
[05:58] <duflu> RAOF: "Full screen" is generally a WM hint only.
[05:58] <RAOF> duflu: That can't work in general, right? There's nothing saying that a fullscreen, on top window has to be uncomposited.
[05:59] <duflu> RAOF: If it's on top, and lacks an alpha channel, and not being transformed, and fits the full monitor then it's unredirected/bypassed
[05:59]  * RAOF goes digging in the compiz code to see how the server can tell.
[05:59] <duflu> Apps generally flag full screen with WM hints. They never set override redirect any more
[05:59] <RAOF> Nor does compiz?
[06:00] <duflu> RAOF: Compiz doesn't ever "set" override redirect. That's an app/toolkit decision.
[06:01] <RAOF> Oh, right. I'm getting my terminology mixed up, aren't I.
[06:01] <duflu> RAOF: More generally Compiz does not use the WM flags in deciding to bypass. It looks at window placement and size in the end.
[06:02] <duflu> ... that way bypass decisions are right no matter how old-fashioned or modern the fullscreen method it
[06:02] <duflu> *is
[06:03] <duflu> RAOF: P.S. Old-fashioned fullscreen is seen with glxgears. Modern hinted full screen is seen in browsers or gnome-terminal. Though the latter uses RGBA so is never bypassed
[06:04] <RAOF> What I actually want to gate on is composite status, isn't it.
[06:05] <duflu> RAOF: You mean take the XComposite redirection state? Probably...?
[06:05] <RAOF> Right.
[06:05] <tvoss> good morning :)
[06:05] <duflu> tvoss: Hi
[06:06] <tvoss> duflu, hey :) how goes?
[06:06] <duflu> tvoss: Going slowly but I finally have fast internet again. So that's something
[06:06] <thomi> robert_ancell: mir-docs-upload job is fixed. Documentation uploads should be working again now
[06:06] <RAOF> What ended up being the problem, by the way?
[06:06]  * thomi goes to eat dinner
[06:07] <duflu> RAOF: I was on a noisy cable to the exchange in which all the pairs experienced heavy noise. They put me on a different cable
[06:07] <tvoss> thomi, hey there :)
[06:08] <tvoss> duflu, \o/
[06:09] <tvoss> RAOF, good morning
[06:09] <RAOF> tvoss: Yo!
[06:11] <tvoss> robert_ancell, good morning :)
[06:35] <duflu> alf__, ping
[06:37] <alf__> duflu: pong
[06:37] <NikTh> Hello everyone
[06:37] <duflu> alf__: BufferSwapperMulti is being constructed (a second time) with a buffer list of length 1
[06:37] <duflu> Is that meant to happen?
[06:38] <NikTh> Somehow apport allowed me to report a bug, even with third party software (Xmir PPA) installed. I filled a new bug report here, now full logs are listed. https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1200097
[06:38] <ubot5> Ubuntu bug 1200097 in unity (Ubuntu) "compiz crashed with SIGSEGV in nouveau_pushbuf_kick() - Xmir" [Undecided,New]
[06:39] <NikTh> Hope this helps devs to spot the exact problem :-)
[06:39] <duflu> NikTh, ok thanks
[06:39] <NikTh> duflu: Hey :-) good to see you again
[06:41] <alf__> duflu: What's the scenario?
[06:42] <duflu> alf__: I have client_queue constructed as size 1, even when swapper_size==3. And one is not enough so I hang waiting for a new buffer
[06:42] <duflu> Haven't verified the same issue is on trunk
[06:43] <duflu> Maybe it's not an issue, but designed that way. If so then it might partly explain how in_use_by_client dips to -1
[06:47] <alf___> duflu: If this happens while switching swappers then it is possible that the client is holding 2 buffers and only one is passed to the new swapper, that's ok. However in_use_by_client falling to -1 is a bug, probably because when we switch to a new swapper this is not set correctly.
[06:48] <duflu> alf___: OK maybe not a bug then. But with bypass it will be so I'll figure it out
[06:50] <duflu> alf___: Yes BTW. The client is holding one and the DisplayBuffer holding the other (as it's being scanned out via bypass)
=== alf___ is now known as alf__
[07:07]  * duflu counts the underscores again
[07:38] <dholbach> good morning
[07:57] <robert_ancell> didrocks, ok
[07:57] <robert_ancell> thomi, thanks!
[07:57] <robert_ancell> tvoss_, hello
[07:57] <robert_ancell> tvoss_, I think you called me via G+? We were on the hangout in the meeting invite and didn't see you on IRC
[08:08] <tvoss_> robert_ancell, yeah, tried to call via g+ as I was on a birthday
[08:08] <tvoss_> robert_ancell, damn android, couldn't figure out how to join the hangout from the meeting invite :)
[08:08] <robert_ancell> tvoss_, sorry about that, too many windows
[08:08] <tvoss_> robert_ancell, know that problem :)
[08:09] <robert_ancell> tvoss_, did you want a quick call without mterry or reschedule?
[08:09] <tvoss_> robert_ancell, reschedule is fine with me, it's not urgent, just want to touch base with the both of you
[08:10] <robert_ancell> sure
[08:10] <robert_ancell> we discussed a bit together, try again at a similar time?
[08:10] <tvoss_> robert_ancell, yup, let me quickly check my calendar
[08:11] <tvoss_> I've got a call at 8:30 my time, what is my 9pm in your timezone?
[08:12] <tvoss_> RAOF, your doc mp failed ci ;) https://jenkins.qa.ubuntu.com/job/mir-saucy-amd64-ci/220/console
[08:12] <RAOF> tvoss_: You've probably got the vpn setup required to hit the “retry” button, don't you?
[08:13] <tvoss_> RAOF, nope, did a fresh install yesterday after my adventures in "all the DEs"-land
[08:13] <RAOF> Because that's clearly a nondeterministic test.
[08:13] <RAOF> Oh, bah.
[08:13] <tvoss_> mzanetti, ping
[08:13] <RAOF> robert_ancell ^^ ?
[08:14] <tvoss_> mzanetti, mind hitting retry here: https://code.launchpad.net/~raof/mir/more-doc-doc-docies/+merge/174121
[08:14] <tvoss_> ?
[08:14] <robert_ancell> RAOF, I retries it
[08:14] <robert_ancell> tvoss_, ^^
[08:14] <RAOF> Hurray!
[08:14] <robert_ancell> retried it already I mean
[08:14] <robert_ancell> tvoss_, that's 7am my time
[08:14] <RAOF> We should really turn on dbgsyms for the PPA, too.
[08:15] <tvoss_> robert_ancell, bit early, isn't it? let's postpone to next week then
[08:15] <robert_ancell> tvoss_, ok
[08:15] <robert_ancell> tvoss_, yeah, my daughter gets up then so it clashes for me
[08:16] <tvoss_> robert_ancell, no worries, next week it is
[08:19] <mzanetti> tvoss_: you mean a test rebuild or autolanding?
[08:19] <tvoss_> mzanetti, hold on, robert ancell already hit the button
[08:21] <RAOF> To the pizza!
[08:27] <tvoss_> RAOF, enjoy
[08:29] <smspillaz> RAOF: 1) yes, 2) It is always fullscreen
[08:30] <smspillaz> (except when there are other "unredirected windows")
[08:30] <smspillaz> (in which case its fullscreen but shaped)
[08:30] <duflu> smspilaz: Kinda... It's fullscreen in the single monitor case
[08:34] <duflu> Man, I've lost a buffer and don't know what's holding it
[08:34]  * duflu looks behind the fridge
[08:34] <racarr> smspillaz: Lol internet
[08:35] <racarr> (smspillaz and I just got back from berkeley ;))
[08:36] <smspillaz> racarr: dude
[08:36] <racarr> smspillaz: I met some guy who seemed like he was a compiz developer on the bart
[08:36] <racarr> but I thought he was a total hack
[08:37] <smspillaz> oh you meam robert parr?
[08:37] <racarr> haha
[08:37] <smspillaz> i occasionally run into him
[08:37] <tvoss_> hmmm, the doc mp fails on clang :)
[08:37] <smspillaz> he stalks me or something
[08:38] <duflu> tvoss_: It's the build machine broken, not clang
[08:39] <tvoss_> duflu, still annoying as we cannot land the mp. mzanetti: mind taking a look here: https://jenkins.qa.ubuntu.com/job/mir-clang-saucy-amd64-build/1155/console?
[08:39] <smspillaz> duflu: the cow is always screensize
[08:39]  * duflu realizes it's past midnight in California and stops trying to make sense of the (likely) drunk people
[08:39] <smspillaz> well im not drunk anymore
[08:40] <smspillaz> but by cow i mesnt composite overlay window
[08:40] <smspillaz> its just phone typing
[08:40] <racarr> Sam speaks truth. Its only me thats drunk
[08:40] <racarr> (Zzz...)
[08:40] <duflu> smspillaz: OK, so not http://www.flickr.com/photos/joshmt/5604316602/
[08:41] <smspillaz> racarr: not as drunk as i was last night :)
[08:42] <racarr> I dunno I did fall over on that old woman.
[08:42] <racarr> err ^H^H^H^H
[08:42] <racarr> Im going to go to sleep ;)
[08:42]  * duflu is only jealous
[08:43] <duflu> of the drinking, not the falling
[08:43] <smspillaz> lolllllllll
[08:43] <smspillaz> and the dropped glass
[08:43] <smspillaz> XD
[08:44] <racarr> Ok, I think everyone gets the picture.
[08:48] <duflu> smspillaz: I meant that the COW covers all screens. All the while a "fullscreen" window usually only covers one
[08:48] <smspillaz> (theres really not mich more than that)
[08:49] <duflu> It's important if you're using multiple monitors and need one of them unredirected to play HD video :)
[08:49] <smspillaz> duflu:ah, correct. im the case though the cow may effectively be smaller than the screensize
[08:50] <duflu> Yes, where "Screen" is the compiz word for Mir's "Display"
[08:51] <smspillaz> anyways, the main caveat is that the assunption tjat cow output size == screensize vreaks when there is internal redirection happening
[08:51] <smspillaz> anywyas, night :)
[08:54] <duflu> smspillaz: Night. Happy holidays
[09:03] <mzanetti> tvoss_: I logged in jenkins and tried to reproduce the failure. couldn't reproduce. then I retriggered the job and it past that point now
[09:04] <tvoss_> mzanetti, thx
[09:04] <mzanetti> tvoss_: probably some temporary network issues
[09:04] <tvoss_> mzanetti, saw it being merged
[09:10] <alan_g> duflu: you're building on raring? I'm failing to do so because I can't find a libmockdev.dev package. What was your solution?
[09:12] <tvoss_> alan_g, are you looking into the test hang on armhf?
[09:12] <alan_g> tvoss_: no
[09:12] <alan_g> tvoss_: I thought racarr had a solution
[09:15] <tvoss_> alan_g, don't see an mp up and the bug is blocking us from landing in distro
[09:16] <alan_g> tvoss_: "<racarr> alan_g: Yes. client-focus-notifications contains a solution"
[09:16] <tvoss_> didrocks, mind sending me your .pbuilderrc again?
[09:16] <didrocks> tvoss_: sure
[09:16] <duflu> alan_g: Yes just install the saucy packages: https://launchpad.net/ubuntu/+source/umockdev
[09:16] <didrocks> tvoss_: http://paste.ubuntu.com/5864291/
[09:17] <didrocks> tvoss_: you probably want to change the HOOK_DIR :)
[09:17] <alan_g> duflu: thanks
[09:17] <didrocks> tvoss_: if you need any hook, tell me
[09:19] <xnox> RAOF: i think you said you'd want to see bugs when dual screen setup is not mirrored.
[09:19] <xnox> bug 1200130
[09:19] <ubot5> bug 1200130 in Mir "Multi-monitor bug: different results after VT-switch" [Undecided,New] https://launchpad.net/bugs/1200130
[09:19] <xnox> bug 1200129
[09:19] <ubot5> bug 1200129 in Mir "Multi-monitor bug: different brightness" [Undecided,New] https://launchpad.net/bugs/1200129
[09:19] <xnox> bug 1200127
[09:19] <ubot5> bug 1200127 in Mir "Multi-monitor bug: different resolution" [Undecided,New] https://launchpad.net/bugs/1200127
[09:26] <duflu> alf__: Is there a high-level description of how buffers are shared safely between server threads?
[09:26] <duflu> A locking plan even?
[09:27] <alf__> duflu: the idea is that once a buffer is extracted from the swapper, whoever extracts it owns that thread. There hasn't been a need for multiple buffer ownership until now. Do you have a use case?
[09:28] <alf__> duflu: ...owns that buffer...
[09:29] <duflu> alf__: Yes unfortunately the compositor/flipper thread now needs to own the buffer, not just till the flip, but also until the next page flip. And that's a different thread to the session mediator
[09:29] <duflu> Hmm, maybe it's the compositor locking I should be looking at
[09:30] <alf__> duflu: to be clear, there hasn't been a use case for multiple buffer ownership with both readers/writers. There can be multiple read-only users of a buffer.
[09:32] <duflu> alf__: Alright. I need to figure out the multi-thread implications... or figure out how to avoid multi-threaded ownership
[09:33] <duflu> ... also to figure out where my buffers are going. Because the session_mediator should never be starved with 3 buffers. Somehow it is
[09:36] <alf__> duflu: could we do all this by switching compositing strategies when a full-screen session is active?
[09:37] <duflu> alf__: That's part of the plan, kind of. And possibly not exactly what I'm talking about right now
[09:39] <alf__> duflu: I mention this because the amount of time a buffer is held is currently managed in the compositing strategy. With a different strategy we could use a different policy for holding buffers.
[09:40] <duflu> alf__: Yes I noticed the multithreaded compositor locking is a big factor. I need to clarify the problem further before I ask you more questions
[09:41] <duflu> And maybe make dinner
[09:41] <alf__> duflu: ok, enjoy!
[09:54] <duflu> Hmm, the throttling of swapinterval=1 clients is a much more implicit chain of events than I expected
[09:56] <tvoss_> duflu, I'm surprised that thoughts like that arise while doing dinner :)
[09:56] <duflu> If I was making dinner I wouldn't be logged in
[09:56] <duflu> My IRC presence is more definitive than other peoples
[09:59] <dandrader> what do you guys do when you wanna build mir packages? doing so in an armhf chroot (with qemu) is taking forever...
[10:06] <dandrader> ... and qemu crashes when running the acceptance tests
[10:06] <duflu> dandrader: We usually develop via cross compilation, for speed. I'm not sure anyone else has ever needed "fast" builds of armhf debs
[10:09] <didrocks> the nexus 4 + ccache works fine with Mir for my tests
=== dandrader is now known as dandrader|afk
=== dandrader|afk is now known as dandrader
[11:03] <tvoss_> alf__, ping
=== alan_g is now known as alan_g|errands
[11:22] <tvoss_> alf__, ping
[11:22] <alf__> tvoss_: pong
[11:22] <tvoss_> alf__, hey there :) got a list of the Mir lttng tracepoints handy?
[11:25] <alf__> tvoss_: grep -C2 -R TRACEPOINT_EVENT src/
=== alan_g|errands is now known as alan_g
=== dandrader is now known as dandrader|lunch
=== alan_g is now known as alan_g|tea
[15:03] <derEremit> just booted with mir ppa and:
[15:03] <derEremit> cat /var/log/lightdm/x-0.log:
[15:03] <derEremit> Fatal server error:
[15:03] <derEremit> no screens found
[15:04] <derEremit> intel core i7
[15:04] <derEremit> also as second card nvidia ( optimus ) if that matters
=== dandrader|lunch is now known as dandrader
[15:15] <kdub> didrocks, i'm trying a new approach for getting gmock out of our tree, hopefully will get it through jenkins today
[15:17] <didrocks> kdub: what do you mean by new approach?
[15:17]  * didrocks is interested
[15:18] <kdub> by having cmake build the external project (ExternalProject_Add), instead of just adding the out of tree sources as internal sources
[15:19] <didrocks> kdub: neat idea :)
=== alan_g|tea is now known as alan_g
[15:37] <mlankhorst> fwiw, the xorg-server needs to be refreshed
[15:47] <xjunior> mlankhorst: what do you mean?
[15:48] <mlankhorst> system-compositor-testing xorg-server is out of date :-)
[15:57] <mlankhorst> anyway I'm EOD, if anyone else wants to pick up some fixes for unity-system-compositor..
[15:58] <mlankhorst> http://paste.debian.net/15562/ <- attempt to fix xserver-xorg-video-radeon alignment
[15:59] <mlankhorst> seems to hard lock up here, but it does show the cursor for a bit before it hard locks up :P
[15:59] <mlankhorst> http://paste.debian.net/15490/ <- experimental fix to enable sna in xserver-xorg-video-intel
[16:00] <mlankhorst> probably RAOF will look at it, I'll be back on monday
[16:00] <mlankhorst> kgunn_: that ati fix should help your radeon https://bugs.launchpad.net/mir/+bug/1195425 bug
[16:00] <ubot5> Ubuntu bug 1195425 in Mir "Corrupted screen using radeon drivers" [Critical,Triaged]
[16:01] <mlankhorst> EOD, EOW
[16:01] <katie> racarr, hello
[16:02] <kgunn_> mlankhorst: thanks!
=== om26er is now known as om26er|afk
[16:33] <greyback> racarr: ping
=== alan_g is now known as alan_g|EOD
=== om26er|afk is now known as om26er
[19:02] <racarr> Woo. Root canal 2/3rds complete
[19:02] <racarr> sorry I forgot to send an email
=== Cimi_ is now known as Cimi
=== popey_ is now known as popey
=== JoseeAntonioR is now known as jose
=== TheDrums_ is now known as TheDrums
[21:38] <robert_ancell> kgunn, oh sorry, I missed the meeting
[21:39] <kgunn> robert_ancell: no problem really, everyone's got their bit to do...bregma was waiting on an arm build to finish & then we should be good to go for universe (i think)
[21:40] <robert_ancell> kgunn, awesome
[21:42] <olli_> robert_ancell, quick q, will we have lightdm on the phone
[21:42] <robert_ancell> olli_, yes, I believe that is what the phone team decided, and I'm working to implement the required changes
[22:14] <olli_> robert_ancell, thx for putting the doc together
[22:14] <robert_ancell> olli_, np
[22:30] <kdub> i guess resizing the display is more associated with the MirConnection than the MirSurface
[22:31] <kdub> 'is this session allowed to change the resolution' more than 'is this surface on this session allowed to do change it'
[22:56] <RAOF> kdub: Yup, that sounds right.
[23:20] <kgunn> wrt lib deps, does anyone know why it seems sometimes android-input is the dep...sometimes 3rd_party...but 3rd_party seems to be a wrapper for android-input
[23:22] <kgunn> seems redundant/overkill?
[23:22] <kdub> kgunn, we've been working on deflating that directory, eventually it should just become android-input
[23:23] <kgunn> kdub: thanks...confirmation i'm actually understanding my unwinding exercise :)
[23:45] <kdub> RAOF, what is the easiest way for xmir to get 'display changed' notifications?
[23:46] <kdub> trying to come up with an api for monitor configuration that makes sense for xmir
[23:52] <RAOF> kdub: Use whatever racarr's using for focus notification?
[23:54] <kdub> hmm
[23:54] <RAOF> I'm resigned to the fact that it's likely to be a callback from a random thread :)
[23:55] <kdub> yes, likely
[23:55] <kdub> i guess i'm just asking what happens in the xserver when that callback happens though
[23:56] <kdub> like, does it go and recompute the output configuration the xserver wants, and then asks to apply it?
[23:56] <RAOF> I guess that depends on the cause of the notification.
[23:57] <RAOF> ie: there are two possibilities - “the hardware has changed”, or “some other client changed the configuration”
[23:58] <RAOF> Actually, now that I think about it - no.
[23:58] <RAOF> The X server never does any output configuration directly.
[23:59] <RAOF> It's just going to forward that notification on to whatever clients are listening to RANDR events.
[23:59] <kdub> ah, interesting
[23:59] <RAOF> And there's no guarantee what they think they'll want to be doing.
[23:59] <kdub> so it does indeed need a callback signal, that it would pass on to the xrandr-subscribed clients