[00:28] <jono> http://www.reddit.com/r/LinuxActionShow/comments/1alqka/regarding_matt_and_the_monkey_suit_its_on_like/
[00:29] <jono> probably best to not let this guy down ^
[00:29] <jono> :-)
[00:41] <RAOF> Used by default in a non-Ubuntu distro is a ballsy call.
[01:32] <robert_ancell> Has anyone compiled qmir before?
[01:32] <robert_ancell> qmake ; make doesn't seem to do it for me
[02:09] <smspillaz> RAOF: oh cool, you got buffer age working
[02:10] <RAOF> smspillaz: Yeah. Next up: actually using it in XMir.
[02:10] <RAOF> Actually, before that is probably ‘extend __DRIbuffer to allow me to pass prime fds to dri drivers, damnit’
[02:11] <smspillaz> RAOF: I wonder how you got it to work - the DRI drivers don't really make any guaruntees about what buffer you're going to get next
[02:11] <smspillaz> its all very driver specific
[02:11] <smspillaz> some drivers with copy-back-to-front on swap, others will swap, others triple buffer
[02:12] <smspillaz> though I guess that all happens within the xserver bits
[02:12] <RAOF> *Mir* knows exactly what buffer it's going to send to the client.
[02:12] <smspillaz> yeah I figured as much
[02:12] <RAOF> Right. Each buffer the client receives has a (client-)unique id; it's reasonably easy to implement age tracking on that ;)
[02:12] <smspillaz> RAOF: how do you handle the discrepancies between the drivers though ?
[02:13] <RAOF> Which discrepancies between drivers? We exclusively pageflip, and handle n-buffering ourselves.
[02:14] <RAOF> We don't use any of the X bits; we're not using the DRI2 protocol.
[02:15] <RAOF> Nothing ever gets a SwapBuffers request, except egl/platform_mir, which we own.
[02:15] <smspillaz> RAOF: remind me - do the Xorg bits of dri2 have driver-specific things there ?
[02:16] <smspillaz> I looked into doing this in X a while ago and remembered there was some driver-specific stuff that would have made it difficult, but it was a while ago
[02:16] <RAOF> Yes - the X bit of SwapBuffers calls into the DDXes SwapBuffers function.
[02:16] <smspillaz> ah okay that makes sense
[02:17] <RAOF> I think for X you would indeed need to push this all the way down to the DDX, or _possibly_ hook into the bits generating intel swap events.
[02:17] <smspillaz> RAOF: it was a total PITA
[02:18] <RAOF> This is not an uncommon sentiment when working with X :)
[02:18] <smspillaz> yeah it was this stuff here http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/tree/src/intel_dri.c#n838
[02:19] <RAOF> I tried to factor a bunch of that stuff out into the X server at one point.
[02:19] <RAOF> Because all 3 of the drivers were doing the _exact_ same thing, and they had exactly the same segfault bug.
[02:20] <smspillaz> heh
[02:20] <smspillaz> I think nouveau works a little differently
[02:20] <smspillaz> intel has the optional triple-buffer thing
[02:20] <smspillaz> nouveau didn't
[02:20] <smspillaz> I remember that much
[02:21] <RAOF> Yeah. At one point -ati and -nouveau had just copy&pasted the -intel code and run a sed over the names; it's diverged a bit from there :)
[02:21] <smspillaz> felt like it
[02:21] <smspillaz> Also I830
[02:21] <smspillaz> heh
[02:21] <smspillaz> Party like its 2002
[02:21] <racarr> smspillaz: !
[02:21] <smspillaz> racarr: hi'
[02:21] <racarr> RAOF: Just left some comments on buffer age...
[02:22] <smspillaz> no I'm not writing any code for you :p
[02:22] <racarr> Hi :)
[02:22] <racarr> thats what you say now
[02:22] <smspillaz> seriously, I'm not
[02:22] <smspillaz> :)
[02:22] <racarr> I know :)
[02:24] <smspillaz> also, you guys need to fix the privacy settings
[02:24] <smspillaz> I can't see half the merge proposals
[02:30] <racarr> wip
[02:30] <smspillaz> racarr: no, as in I click on them and I get a page that says "go away"
[02:31] <smspillaz> example: https://code.launchpad.net/~robertcarr/mir/prepare-for-inprocess-egl-clients/+merge/153889
[02:31] <smspillaz> (you'll need to log out)
[02:31] <RAOF> I _think_ it might be the merges or the branches that were set up prior to going public?
[02:31] <RAOF> It's not clear how to make them public.
[02:32] <smspillaz> RAOF: I think the lp settings are that projects are private or public, not branches
[02:32] <smspillaz> so something is broken somewhere
[02:32] <RAOF> Incorrect! lp:~raof/mir/client-side-buffer-age was a private branch.
[02:33] <RAOF> And now that it's a public branch the merge proposal is also public.
[02:33] <RAOF> Ok.
[02:33] <smspillaz> RAOF: I don't see the MP
[02:33] <smspillaz> its not public :)P
[02:33] <RAOF> https://code.launchpad.net/~raof/mir/client-side-buffer-age/+merge/151869
[02:33] <RAOF> ?
[02:33] <smspillaz> RAOF: so I can see if if you give me the link
[02:34] <smspillaz> but it doesn't turn up in +merges or +activereviews
[02:35] <RAOF> That might take a little while to propagate?
[02:35] <smspillaz> should be instant
[02:37] <racarr> I think it will be fixed once we get all the mps through
[02:41] <smspillaz> yeah
[02:42] <RAOF> racarr: Thanks for the review.
[02:47] <racarr> RAOF: Sorry its kind of scattered
[02:47] <RAOF> That's ok.
[02:47] <racarr> I am really tired...have been a little too full stream all around last 3-4 days :)
[02:47] <racarr> I thought I would try and say something though
[02:47] <racarr> and overall it makes sense :)
[02:49] <RAOF> What do you think of pulling the age() related bits into ClientBuffer; the implementation shouldn't be different between AndroidClientBuffer and GBMClientBuffer.
[02:51] <RAOF> I'm leary of mixing interface and implementation there.
[03:02] <RAOF> Woo! Android build builds!
[03:05] <tehcloud> does having an Android build mean Mir has been tainted with Java?
[03:05] <TheMuso> tehcloud: No
[03:06] <TheMuso> tehcloud: Java is only used for apps on android, I believe all the infrastructure stuff is C/++.
[03:06] <TheMuso> C/C++ even.
[03:13] <RAOF> And we're not even using that; we're using the android kernel and GLES drivers.
[03:23] <TheMuso> I know that, just clarrifying that java is only used at the app/UI level.
[03:23] <RAOF> Yeah, I presume you did, but tehcloud probably didn't :)
[03:24] <tehcloud> yeah, I'm not exactly an expert in this subject matter
[03:24] <smspillaz> TheMuso: brb, off invention "++"
[03:24] <smspillaz> its C++ with the C bits removed
[03:24] <smspillaz> oh wait that's Java, never mind
[03:25] <smspillaz> *inventing
[03:25] <TheMuso> lol
[03:25] <smspillaz> They should have called Java "++"
[03:25] <smspillaz> that would have ended up in so much hilarious confusion
[03:26] <tehcloud> in an ideal world there would be no Java
[03:26] <TheMuso> Java has its place, just like all languages.
[03:26] <TheMuso> I don't use it myself.
[03:26] <TheMuso> But can understand, accept and respect its usefulness.
[03:26] <tehcloud> that's why you think that way ;)
[03:26] <tehcloud> try using it at work
[03:27] <smspillaz> Java would be useful if we didn't have AWT
[03:33] <RAOF> Man, the ubuntu touch images don't even have rsync in them!
[03:37] <racarr> RAOF: "tsyncninja" A touch based file synchronization utility based on the popular fruit slicing mini game
[03:38] <RAOF> Hm. “make style_check” isn't really very useful, is it ☺
[03:38] <RAOF>  ~/Canonical/Mir/mir/build ⮀ make style_check 2>&1 | wc -l
[03:38] <RAOF> 1031
[03:38] <racarr> RAOF: I always grep for the files I modified
[03:39] <racarr> and just fix those
[03:39] <racarr> "always"->"on good days"
[03:51] <racarr> RAOF: I kind of like pulling the age related bits in...(just catching backscroll)
[03:51] <racarr> the mixing implementation and interface is a red flag though
[03:51] <racarr> the other red flag is the
[03:51] <racarr> implementation of the ageing semantics on the mock buffer with the expectations
[03:51] <racarr> in one of the tests
[03:51] <RAOF> Yeah, that's rather awkward.
[03:51] <racarr> which says that really there is
[03:51] <racarr> another object
[03:52] <racarr> BufferAgeTracker (complete strawman name)
[03:52] <racarr> and its an integration test
[03:52] <racarr> but...eh
[03:52] <racarr> I am not sure how strongly I feel about it
[03:52] <duflu> racarr: Orange flag at most. If there's no real testing value gained by mocking systems code then I think it's often OK to mix implementation with interface
[03:53] <racarr> Sure, orange flag :)
[03:53] <racarr> Maybe Buffer has a member
[03:54] <racarr> type BufferAge
[03:54] <RAOF> ClientBuffer could well have a public uint32_t age, yes.
[03:54] <duflu> On the other hand... being able to test code natively is preferable to mocking. And if you can do that, then you don't need to separate interface from implementation
[03:54] <racarr> RAOF: No I mean a
[03:54] <racarr> BufferAge age, and then the methods increment_age, mark_as_submitted, age()
[03:54] <racarr> etc
[03:54] <racarr> move to BufferAge definition
[03:54] <racarr> and out of the platform code
[03:55] <RAOF> Possibly. I *think* the Buffer might actually want to do something on mark_as_submitted(), though.
[03:55] <racarr> duflu: Here the interface is seperated because it actually has multiple implementations
[03:56]  * duflu stops generalizing about code he hasn't seen yet
[03:56] <racarr> RAOF: does it have to do with the age
[03:56] <racarr> duflu: Hehe. my number 1 hobby!
[03:56] <RAOF> racarr: No, not to do with age.
[03:56] <racarr> RAOF: Then I would imagine
[03:56] <duflu> Generally speaking... we should use Go.
[03:56] <racarr> buffer.submit() does that thing and
[03:56] <racarr> also calls buffer_age.mark_as_submitted()
[03:57] <RAOF> racarr: The *age* interface doesn't actually have multiple implementations, though.
[03:58] <racarr> RAOF: In what tense? Right now it does i.e. increment_age is implemented in the test, the android buffer and the gbm buffer
[03:58] <racarr> so the idea is to just move the implementation to a single shared BufferAge type
[03:58] <RAOF> racarr: In the sense that it's ever sensible to have different behaviour there.
[03:58] <racarr> mm
[03:58] <racarr> so I mean it's a concrete type
[03:58] <racarr> its just to avoid mixing implementation in to the ClientBuffer API
[03:59] <racarr> I guess there is still some :)
[03:59] <RAOF> Alternatively, ClientBuffer abstract, AgeableBuffer concrete, {GBM,Android}ClientBuffer inherits from both?
[04:00] <racarr> RAOF: Mm
[04:01] <racarr> RAOF: Anyway...I don't feel strongly enough about any of these to feel like
[04:01] <racarr> blocking on it...but maybe if you think one is a particularly good idea or europe has a good idea :)
[06:08] <RAOF> Hm, it seems that our coding style has a significant exception in the tests.
[06:17]  * duflu would prefer to call it a coding /fashion/
[06:19] <RAOF> Coding /ambiance/
[06:32] <tvoss> uRAOping
[06:32] <tvoss> RAOF, ping
[06:32] <RAOF> Yo!
[06:36] <RAOF> tvoss: What's up?
[06:37] <tvoss> RAOF, good morning :) looking at your buffer age branch, did you run it with XMir, yet?
[06:37] <RAOF> tvoss: No, haven't yet done the xmir bit.
[06:37] <tvoss> RAOF, ah, was just curious. I remember you mentioning that the buffer age stuff might help
[06:38] <RAOF> XMir is currently in a bit of flux, too; it's half way through being adjusted to lp:~raof/mir/use-dma-buf
[06:41] <tvoss> RAOF, ah cool :)
[06:41]  * tvoss is going to review racarr's branch now
[06:45] <RAOF> It should help with XMir performance though, yeah.
[06:45]  * RAOF has performance-parity third on his TODO list, under finish-buffer-age and use-dma-buf
[06:45] <RAOF> That's going to be _all manner of fun_
[06:48] <tvoss> RAOF, \o/
[08:55] <duflu> Hurray... mir just overflowed it's first page of bugs in Launchpad (75 per page) :/
[08:55] <duflu> *its
[08:57] <RAOF> A fair number of those are "fix committed", though.
[08:58] <duflu> Yeah, first comment still holds. But I wonder when the "0.0.2" release should be tagged and we move on to more meaningful milestone numbers...
[08:59] <duflu> Oh great. 0.0.2 is already marked as released, but also still active
[08:59] <duflu> That needs fixing
[09:00] <duflu> tvoss: What should our next milestone be? 0.0.3? 0.1.0?
[09:01] <duflu> Assuming 0.0.3. We can change it later...
[09:02] <RAOF> Are those milestones at all meaningful?
[09:03] <duflu> RAOF: No. I just realized....
[09:04] <duflu> RAOF: We need to fix up our branch-to-series relationships before milestones make sense
[09:04] <duflu> I'll bug Robert about it when he's online tomorrow
[09:09] <tvoss> duflu, yeah, talk to Robert or kgunn please
[09:09] <duflu> tvoss: Writing detailed email...
[09:10] <tvoss> duflu, thank you
[09:14] <alan_g> Good morning. (It is snowing!)
[09:16] <duflu> alan_g: Morning. Not sure whether to be jealous.
[09:17] <alan_g> duflu: don't be - it'll just make everything wet and cold
[09:19] <alan_g> duflu: we need to reach consensus about include (directory) names as Europe and Australia seem to think differently. Have you seen the thread on mir-devel?
[09:19] <duflu> alan_g: Keep forgetting to subscribe to that. Too many other mediums of Mir discussion. Will do so now
[09:21] <alan_g> duflu: A choice of mediums isn't bad.
[09:22] <duflu> Well, only if one is more effective than another and it's not being used
[09:26] <RAOF> alan_g: I'd be interested to hear your thoughts on the great "where to put buffer aging implementation"fest of '13 racarr & I had in backscroll, too.
[09:27]  * alan_g wonders where to find it
[09:30] <RAOF> alan_g: Ah, you don't have backscroll? Let me pastebin
[09:32] <RAOF> alan_g: http://paste2.org/p/3228842
[09:32] <alan_g> RAOF: Looking...
[09:36] <duflu> alan_g: As part of "breaking the dependency on Android input", doesn't that mean that desktop builds should not enter any *android* directories?
[09:36] <alan_g> RAOF: ...need to remind myself what the code looks like...
[09:36] <duflu> "[alan-griffiths] Input refactoring (don't depend on Android): DONE"
[09:38] <alan_g> duflu: It was porting the input stack to use std/boost instead of android equivalents.
[09:38] <duflu> alan_g: But still desktop builds enter a couple of *android* dirs?
[09:38] <alan_g> duflu: yes
[09:39] <duflu> That's a bit confusing.
[09:39] <duflu> Hmm
[09:41] <alan_g> duflu: we've adopted more android code than just the input stack
[09:42] <duflu> alan_g: Even the android input stack still seems to be required for desktop input. Is that right?
[09:42] <alan_g> duflu: we've forked the android input stack for use on all platforms
[09:43] <alan_g> duflu: and reduced its dependency on other android stuff to a bare minimum
[09:43] <duflu> Ah, OK. So there will be no escaping the 3rd party code generating all those errors/warnings that clang dislikes
[09:44] <alan_g> duflu: not without work
[09:44] <duflu> Heh
[09:48]  * RAOF heads bedwards
[10:36]  * duflu heads kitchen-wards
[10:57] <tvoss> katie, ping
[10:57] <katie> tvoss pong
[10:59] <tvoss> katie, hey, got anything to sync up?
[11:00] <katie> tvoss, a couple of things, yes.. shall we jump on a hangout?
[11:01] <tvoss> katie, sure, let me grab coffee :)
[14:23] <alan_g> alf_: ping
[14:36] <alf_> alan_g: pong
[14:36] <alan_g> alf_: do you want to do any more on render-surfaces-use-display-server or shall I set it to approved?
[14:37] <alf_> alan_g: I am ok for now, I prefer to do any additional enhancements in another MP
[14:43]  * alf_ prepares himself mentally for a review of lp:~robertcarr/mir/send-input-to-clients
[14:48]  * alan_g has just finished the mornings reviews. alf_, send-input-to-clients isn't the worst on the brain.
[14:48] <alan_g> *morning's
[14:49] <alf_> alan_g: I haven't checked in detail, I just saw the +1066 diff :)
[15:42] <kdub_> hey all, status, still up north at the gpu conference, will be back to a normal day tomorrow
[15:47] <alan_g> kdub: hope you're having fun!
[15:51] <kdub_> alan_g, thanks! picking up on some useful info, a lot of emphasis on gpu compute though
[15:52] <alan_g> kdub: that doesn't surprise me. I know a lot of folks that believe that is what GPUs are for.
[15:52] <alan_g> (That's what comes of working with investment banks.)
[16:07] <racarr> Morning
[16:10] <alf_> status: changed render-surfaces to use DisplayServer, reviewing, investigating test failure in VM CI and VM autolanding.
[16:21] <racarr> alan_g: for comments on send-input-to-clients
[16:22] <racarr> are you thinking just
[16:22] <racarr> msh::Surface implements mi::InputTarget or some such
[16:22] <racarr> or something else...
[16:22] <racarr> I thought about that but then it escaped my mind XD
[16:23] <alan_g> racarr: that sounds sensible
[16:28] <racarr> Ok :)
[16:30] <alf_> alan_g: racarr: @send-input-to-clients, in the same spirit as Alan's comment, I think that FocusSelector belongs in shell::, not in input::
[16:33] <alan_g> alf_: true
[16:37] <racarr> alf_: Yeah sounds right
[16:40] <racarr> alan_g: Lots of reinterpret_casts removed in r515 for prepare-for-inprocess-egl
[16:40] <alan_g> racarr: excellent!
[16:46] <racarr> alan_g: alf_: Do you guys need review on anything this morning before I sink in to
[16:46] <racarr> send-input-to-clients
[16:47] <alan_g> racarr: no - there were too many reviews for me to write any code
[16:48] <racarr> *whistles innocently*
[16:49] <tvoss> kdub, ping
[16:50] <alf_> racarr: no pending MPs for me, thanks!
[16:53] <racarr> Next feature branch for me btw is, clients-receive-input.
[16:53] <racarr> which is going to look like. MirSurface, takes a MirEventDelegate containing bool handle_event(...,MirEvent,...)
[16:54] <racarr> constructs an InputReceiverThread from it. InputReceiverThread uses epoll to wake when there is data on the FD and uses the InputReceiver to consume
[16:54] <racarr> pending events and hand them out to the callback
[16:54] <racarr> if anyone has any
[16:54] <racarr> thoughts/alternatives/etc
[17:37] <racarr> alan_g: I am struck trying to decide on the name of the
[17:37] <racarr> interface msh::Surface exposes to the InputManager
[17:37] <racarr> there also has to be one for msh::Session
[17:37] <racarr> input::Surface is just more trouble XD
[17:38] <alan_g> racarr: you had mi::InputTarget earlier. Changed your mind?
[17:38] <racarr> oh
[17:38] <racarr> alan_g: Well only because there are two
[17:38] <racarr> and SessionTarget reads weird
[17:39] <racarr> but really the session interface is not used as an input target (it doesn't have an FD) it's just for info
[17:39] <racarr> so mi::ApplicationInfo
[17:39] <racarr> mi::Target
[17:39] <racarr> set_input_focus_to(ApplicationInfo, target)
[17:39] <racarr> it feels redundant to write mi::InputTarget, etc.
[17:40] <alan_g> Does "Application" belong there? Or is it a more general "Session"?
[17:40] <racarr> alan_g: It's hard to say
[17:40] <racarr> we create a
[17:40] <alan_g> A little redundancy can help clarity
[17:40] <racarr> droidinput::InputApplicationHandle
[17:40] <racarr> from it
[17:42] <alan_g> Yeah, but android input stack wasn't quite our use case
[17:42] <racarr> mm
[17:42] <racarr> I think its probably closer to a session
[17:43] <alan_g> racarr: we can rename things in the input stack to bring it into line
[17:43] <racarr> set_input_focus_to(mi::SessionTarget, mi::SurfaceTarget)?
[17:43] <racarr> mm
[17:43] <alan_g> racarr: but lets do that later
[17:43] <racarr> yes aybe a good task for next week if we can land the basics of input this week
[17:43] <racarr> then clean up, (espescially down in droidinput)
[17:43] <racarr> next week once it is under end to end test
[17:44] <racarr> and ITERATE!
[17:45] <racarr> alan_g: Just realizing also...I guess msh::SingleVisibilityFocusMechanism needs to work in terms
[17:45] <alan_g> racarr: yes, and we can lose MIR_INPUT_USE_ANDROID_TYPES after that too
[17:46] <racarr> of msh::Session
[17:46] <racarr> and not mf::Surface :)
[17:46] <racarr> so it can see the SessionTarget type
[17:46] <alan_g> racarr: ack
[17:49] <racarr> ugh but there is no msh::Session anymore
[17:50] <racarr> just application session
[17:50] <racarr> which if you use that get back to the point where you cant mock session for the focus mechanism.
[17:50] <alan_g> racarr: there is, it is in the src directory
[17:50] <alan_g> racarr: sorry, you're right
[17:50] <racarr> alan_g: session not surface I got it
[17:50] <racarr> backwards too
[17:51] <alan_g> racarr: we're missing more than one interface around this area
[17:51] <racarr> mm
[17:52] <racarr> trying to find a way to proceed for this branch without tearing apart shell again aha
[17:53] <racarr> I dont like using the ApplicationSession interface for the FocusMechanism set_focus_arg because then it becomes cumbersome to mock
[17:54] <racarr> (need constructor args, etc...its weird)
[17:54] <racarr> but also don't like defining
[17:54] <racarr> hmm
[17:54] <racarr> at first I didn't like it...msh::ApplicationSession implements msh::Session implements mf::Session
[17:54] <racarr> but maybe that's really how it is.
[17:54] <racarr> default_surface for example
[17:54] <racarr> is part of
[17:55] <racarr> msh::Session
[17:55] <racarr> but not mf::Session
[17:56] <alan_g> racarr: yes, but that *ought* to be part of an interface, not just in an implementation
[18:00] <racarr> alan_g: Yes msh::Session is the interface
[18:00] <racarr> msh::ApplicationSession is the implementation
[18:00] <racarr> default_surface is introduced at msh::Session
[18:01] <alan_g> racarr: I'm sure you'll sort it all out while I take my wife out for a meal.
[18:01] <alan_g> ;)
[18:05] <racarr> alan_g: Have a good evening :)
[18:05] <racarr> ill sort it out
[18:05] <racarr> I have this suspiscion that (not for this branch)
[18:05] <racarr> but maybe really mf::Surface and mf::Sessio don't exist
[18:05] <racarr> and SessionStore::create_session and create_surface_for
[18:05] <racarr> return
[18:05] <racarr> SessionIPCPackage and SurfaceIPCPackage
[18:05] <racarr> except then how do you advance the buffer ;)
[18:06] <racarr> for now msh::Session I believe
[18:08] <alan_g|life> racarr: they exist, but they're not quite correct yet
[19:05] <racarr> This is a difficult refactoring
[19:06] <racarr> because...
[19:06] <racarr> hmm well if you introduce msh::Session inbetween mf::Session and ApplicationSession
[19:07] <racarr> the SessionManager wants to deal with things in terms of msh::Session (to say pass to the focus mechanism)
[19:07] <racarr> but has to take mf::Session as input and as output
[19:32] <racarr> mer...
[19:33] <racarr> feel stuck on a good solution. espescially one that doesn't double the diff size of this branch so breaking for lunch
[19:33] <racarr> thai should be coming any minute now...
[20:20] <racarr> if mf::SessionStore::open/close session used the same style as mf::Session open/close/get with ID.
[20:20] <racarr> then the internals (session container, focus mechanism including bridge to input) can work in terms of msh::Session (inherits mf::Session) which can implement
[20:21] <racarr> InputTarget...
[20:21] <racarr> the problem is app_container->remove_session/create_session has to take the same type (or a mapping must be maintained) as session_store open/close
[20:26] <racarr> nvm that is just weird. because the SessionMediator only accesses one instance of session
[20:26] <racarr> per instance
[20:39] <racarr> the only thing I can come up with, is
[20:39] <racarr> eeeeerrrr...no nvm
[20:39] <racarr> *facepalm*
[21:16] <CodyS> hello???
[21:16] <kgunn> robert_ancell: i swear i thot you changed this...i'm going bp crazy https://blueprints.launchpad.net/ubuntu/+spec/client-1303-mir-phone
[21:16] <kgunn> can you make it mir-team drafter ^
[21:16] <kgunn> CodyS: hello
[21:17] <robert_ancell> kdub, yeah, I'm sure I changed that too..
[21:17] <CodyS> ok thanks...i wasn't sure if i was lagging too bad...
[21:17] <kgunn> robert_ancell: arrgggg....cached webpage
[21:17] <robert_ancell> no, I just updated it then
[21:17] <kgunn> nevermind (sheepishly)
[21:18] <kgunn> oh
[21:30] <kgunn> robert_ancell: got another one https://blueprints.launchpad.net/ubuntu/+spec/client-1303-mir-inter-app-data-transfer
[21:30] <robert_ancell> kgunn, done
[22:09] <kdub_> racarr, for in-process-egl mp, i'm a bit hazy as to what eglNativeDisplayContainer is an interface to
[22:10] <kdub_> also hooray for android build ci!
[22:19] <robert_ancell> racarr, I'm reading alan_g|life's ML post about the use of mir_toolkit for server processes - when you use Qt in process does it need a special interface to compile against? i.e. an interface that is different to the server and the client interfaces
[23:00] <racarr> robert_ancell: I dont thinks o but some of the interfaces are shared between the server and client
[23:00] <racarr> I havent fully processed that ML discussion yet