[02:58] <mterry> Hrm.  Does trusty's Mir ftbfs for anyone else?
[02:58]  * mterry wonders how close new Mir is to landing
[03:00] <duflu> mterry: Like https://bugs.launchpad.net/bugs/1285955 ?
[03:00] <ubot5> Ubuntu bug 1285955 in mir (Ubuntu) "Ubuntu trusty update "glm 0.9.5.1-1" broke Mir builds" [Critical,Triaged]
[03:01] <mterry> duflu, looks like it, yeah
[03:01]  * mterry resigns himself to building mir/devel
[03:01] <mterry> I suppose I could steal that one patch
[03:01] <duflu> mterry: It's a simple patch to backport
[03:01] <mterry> duflu, thanks for the link
[03:02] <mterry> duflu, yeah, but I might as well test against latest anyway.  It's been a while since Mir dropped
[03:02] <duflu> mterry: Yeah 0.1.6 grew a bit larger than other releases
[03:02] <duflu> On the plus side, that means lots of fixes
[03:03]  * mterry loves fixes!  :)
[03:04] <duflu> mterry: BTW I've made changes to the rendering interfaces in 0.1.7 and more to come. So I would not recommend building /effects/ of any sort on what we have just yet
[03:04] <duflu> Because what we have won't exist that way for long
[03:05] <mterry> hmm, OK.  I'm just trying to track down weird nested mode behavior with split mode
[03:05] <duflu> The good news is, changes in that area are now landing(!)
[03:05] <duflu> mterry: Anything we know about? https://bugs.launchpad.net/mir/+bugs?field.tag=nested
[03:06] <mterry> duflu, no, don't think so.   I'm not even sure it's a Mir bug yet, but it's a good place to start debugging for one of my issues
[03:07] <mterry> duflu, these only show up when using split mode.  So may be a bug in my integration
[03:07] <duflu> mterry: Does split mean sidestage?
[03:07] <mterry> duflu, no sorry.  I mean split greeter
[03:07] <mterry> duflu, so like an actual separate greeter process
[08:07] <RAOF> Welcome to: It Works Fine On My System, XVII
[08:32] <RAOF> duflu: So, apparently bzr lp-sumbit doesn't particularly care to respect the submit branch I try to set :)
[08:33] <duflu> Hurrah
[08:33] <didrocks> RAOF: you have to set a target branch
[08:33] <didrocks> in your branch config
[08:34] <didrocks> (I know, it's stupid, but that's a launchpad "feature")
[08:34] <didrocks> I had to workaround that for daily release, so really conscious about the problem :)
[08:34] <RAOF> What?
[08:34] <didrocks> RAOF: what branch do you want to target against?
[08:35] <RAOF> The docs for bzr lp-propose strongly imply that ‘bzr lp-propose lp:mir/devel’ will try to be submitted to lp:mir/devel. On the basis that it's called SUBMIT_BRANCH :)
[08:35] <didrocks> yeah, but then launchpad is trying to be smarter
[08:35] <didrocks> and think "oh, but this SUBMIT_BRANCH has this parent branch"
[08:35] <didrocks> so I'll target that…
[08:36] <didrocks> RAOF: try running: bzr config -d lp:mir/devel public_branch=~mir-team/mir/development-branch
[08:36] <didrocks> then resubmit
[08:42] <RAOF> We'll see next time I want to submit something; I've already retargetted.
[08:57] <RAOF> Hm. google::protobuf declares itself to be not threadsafe for non-const methods. Why do we explicitly release all our locks before calling protobuf methods?
[08:59] <duflu> RAOF: Good question. I think otherwise it led to deadlocks. But that doesn't make it right
[09:01] <duflu> RAOF: Do we really have multiple threads using the protobuf objects though?
[09:01] <RAOF> If we have a multithreaded client, certainly.
[09:01] <duflu> RAOF: Ah
[09:02] <RAOF> Such as, say, having two separate nested outputs...
[09:02] <duflu> Critical blocking CI: https://bugs.launchpad.net/mir/+bug/1287600
[09:02] <ubot5> Ubuntu bug 1287600 in Mir "./cross-compile-chroot.sh: line 83: popd: build-android-arm: invalid argument popd: usage: popd [-n] [+N | -N]" [Critical,In progress]
[09:02] <duflu> Anyone?
[09:06] <RAOF> duflu: SUre.
[09:07] <duflu> RAOF: Ta
[09:45] <alan_g> duflu: @"something should be mentioned in debian/changelog" - I don't see anything in the changelog for the changes that broke USC (mostly -r1420)
[09:46] <duflu> alan_g: I just mean if it's not a standard part of the 0.1.6 release (r1433) then it needs a separate mention
[09:47] <alan_g> duflu: got it
[09:47] <duflu> alan_g: At the top-level of the bullet points so it's not under the 0.1.6 release stuff
[09:47] <alan_g> Although IIUC kgunn was busy pulling more stuff into 0.1.6 yesterday
[09:48] <alan_g> so it might be moot
[09:52] <duflu> alan_g: I reverted that. Because it included mostly my own work which I intentionally omitted from 0.1.6 wanting it to mature some more
[10:26] <alan_g> alf_: does "frame" mean "buffer filled with fresh pixels we want displayed" to you?
[10:30] <alf_> alan_g: frame => "buffer filled with pixels". Whether it's "fresh" or we want it displayed is another story.
[10:31] <alf_> alan_g: i.e. these are not implied by the term 'frame' without any other context
[10:39] <alan_g> alf_: thanks. Then "usable_frames()" would be reasonable for buffers we can compose?
[10:42] <alf_> alan_g: pending_frames?
[10:43] <alan_g> I don't like "pending" as it can include a frame that has been composited (either on this display compositor or one one for another output)
[10:44] <alan_g> "frames()"?
[10:45] <alan_g> completed_frames()?
[10:51] <alf_> alan_g: I don't agree with Daniel about using the terms 'frames'. This is a *Buffer*Stream, and I find using 'frames' confusing in this context. BufferStream::completed_buffers()? ready_buffers?
[10:53] <alan_g> alf_: the reason I went for composable_buffers() was that it also supplies client buffers and I wanted to avoid any possible confusion
[11:10] <alan_g> filled_buffers()
[11:34] <anpok_> I havent used our demos on android some time now, any ideas why clients cannot connect to demo shell
[11:36] <alan_g> anpok_: they can
[11:37] <anpok_> "Can't get connection"
[11:37] <alan_g> Are you running as the same user?
[11:37] <anpok_> yes
[11:38] <anpok_> tried with and without supplying the path to server and client. socket file is created properly
[11:38] <alan_g> It works on my kit
[11:39] <anpok_> hm i just stopped unity8 and lightdm
[11:39] <anpok_> ok will try with devel
[11:43] <anpok_> system error thrown by asio when it tries to connect to the socket .. cannot examine the system error category but error val is 2
[11:43] <anpok_> and that would be address in use o_O
[11:44] <anpok_> or no such file or directory
[11:46] <anpok_> oh ok that was all me
[11:48]  * alan_g assumes it works on anpok_'s kit too
[11:49] <alan_g> alf_: "buffers_ready_for_compositor_aka_frames()"?
[11:51] <alf_> alan_g: :)
[11:55] <anpok_> sounds reasonable
[12:10] <anpok_> hm is it intended that all motion events go to the topmost or focused surface even when those motion events did not originate from the screen region of the surface?
[12:13] <alan_g> anpok_: I think that is probably a policy decision - check the design guidelines
[12:13] <anpok_> ah ok that is the behavior of demo shell
[12:14] <anpok_> using focused application -> default_surface, which also explains why multi win behaves that way
[12:24] <alan_g> alf_: happy with the latest comment? https://code.launchpad.net/~alan-griffiths/mir/add-some-intelligence-to-scheduling-compositing/+merge/208633
[12:27] <anpok_> wet_buffers() ?
[12:27] <anpok_> that would have the freshly paint pixels.. and the term buffers
[12:28]  * ogra_ hands anpok_ a mop
[12:29] <anpok_> nah not needed, they are not leaking
=== alan_g is now known as alan_g|lunch
=== alan_g|lunch is now known as alan_g
[14:26] <kgunn> alan_g: so i saw duflu reverted our promotion branch, so re-cherry picked...
[14:26] <kgunn> http://bazaar.launchpad.net/~mir-team/mir/development-branch/revision/1440
[14:26] <kgunn> and
[14:26] <kgunn> http://bazaar.launchpad.net/~mir-team/mir/development-branch/revision/1438
[14:26] <kgunn> just fyi
[14:27] <kgunn> i'm supposing it was the renderable for rendering stuff he didn't want in yet
[14:28] <alan_g> kgunn: I am content to let you and duflu reach a consensus
[14:34] <alan_g> Anyway, your choices look sensible.
[16:25] <anpok_> do we have a usage scenarios behind set_inpput_rectangles?
[16:26] <anpok_> what is supposed to happen if somebody creates a surface. resizes it. then sets input_rectangles.. should the input_rectangles be resized too?
[16:29] <kdub> anpok_, is https://code.launchpad.net/~andreas-pokorny/mir/cursor-position-on-rotated-output/+merge/209076 ready to go?
[16:29] <anpok_> yes
[16:31] <kdub> cool
[16:32] <anpok_> alan_g: alf_: racarr_: kdub: I plan to propse something that would scale the input rectangles on resize, and apply the other transformations to the input rectangles (rotation and positioning) when querried through contains..?
[16:33] <anpok_> kdub: the other two things .. hot spot setting and managing rotated buffers will be done later.. hmm but should be straight forward..
[16:33] <alan_g> anpok_: would it be easier to merge the input rectangles into the surface hierarchy and not have to keep updating copies of the data?
[16:35] <anpok_> hm you mean reworking inputwindowinfo/handle?
[16:38] <alan_g> anpok_: we've far too many implementation classes representing the way surfaces interact with parts of the system. It sounds like you're struggling with keeping the input one in step with the others
[16:38]  * alan_g is guessing as he's not looked closely
[16:40] <anpok_> true, but the problem is now internal in basic_surface::input_rectangle not being updated
[16:41] <anpok_> actually revisiting the other bug.. I wonder which portion of the android object went out of date... since the main query method goes for surface::contains anyhow
[16:42] <anpok_> so maybe I will soon provide a cleaner fix for the other bug too, which ripps out more of the InputInfo
[17:43]  * alan_g is mildly irritated that a bug he fixed days ago on a one branch hosed his system when testing on another branch
[18:02] <alan_g> alf_: do you have time to re-review before EOD? https://code.launchpad.net/~alan-griffiths/mir/nested-sessions-dont-post-buffers-until-something-happens/+merge/209107
=== alan_g is now known as alan_g|EOD
[18:28] <racarr_> ok now that im not worried about accidentally saying chromium I live here again
[18:28] <racarr_> hi everyone :p
=== WebbyIT is now known as rpadovani
[20:08] <bschaefer> racarr_, the chromium work looks awesome! :)
=== veebers_ is now known as veebers
[20:48] <racarr_> bschaefer: Thanks :)
[22:24] <mterry> mf::Shell::open_session() is turning on the display for me  :-/
[22:25] <kdub> maybe its triggering a callback for a new surface
[22:29] <mterry> kdub, new surfaces turn on the display
[22:29] <mterry> ?
[22:35] <kdub> mterry, not sure why that would happen
[22:35] <kdub> mterry, have any ideas about this in unity-system-compositor.log, "Unable to set active session, unknown client name session-0"
[22:36] <mterry> kdub, that is known (harmless for now) race, fixed by a branch of mine....
[22:37] <mterry> https://code.launchpad.net/~mterry/unity-system-compositor/greeter-depth/+merge/207549
[22:38] <kdub> mterry, ok
[23:13] <kdub> mterry, another question, who is in charge of turning on the display today?
[23:13] <kdub> unity8, or usc
[23:14] <mterry> kdub, a bunch of people  :)  Normal flow is powerd asks USC to turn it on
[23:14] <mterry> kdub, unity8 shouldn't be involved anymore
[23:14] <kdub> and thats all landed?
[23:14] <mterry> kdub, yeah
[23:16] <kdub> and this branch did that? https://code.launchpad.net/~mterry/unity-mir/drop-dbusscreen/+merge/202236
[23:16] <kdub> i'm trying to test some mir changes with the whole stack, having a hard time getting all the ducks in a row
[23:16] <mterry> kdub, no, that just removed some old unused code (unused because USC is claiming the bus unity-mir wanted, so it never got it)
[23:17] <mterry> kdub, the branch that made the switch was just enabling nested mode by default
[23:17] <mterry> kdub, USC has had a copy of that dbus_screen code for a while, it just wasn't used until it got turned on by default
[23:17] <kdub> mterry, okay, thanks
[23:20] <mterry> Huh.  SessionMediator::next_buffer turns on the display
[23:20] <mterry> I'm not sure I like that