[09:32] <alan_g> Hi RAOF - you got home OK?
[09:32] <RAOF> alan_g: Indeed I did.
[09:32] <RAOF> Only delayed by a little bit.
[09:33] <alan_g> Good
[09:34] <alan_g> Where are we with the changes to support Mir nested mode on mesa?
[09:39] <RAOF> alan_g: I've just realised why they make i965 explode in a heap with mesa 10.0, and am about to upload some packages to the archive.
[09:40]  * alan_g didn't hear the explosions
[09:40] <RAOF> They were localised.
[09:42] <RAOF> Oh, I guess that I should check that nested actually works, too.
[09:43] <alan_g> RAOF: that would help. (I think anpok was trying to use it yesterday - without success.)
[09:44] <anpok> .. hm yes it failed when creating a pbuffer surface in the nested compositor
[09:44] <anpok> i looked at building u-s-c with the partial chroot script of mir
[09:46] <anpok> how do you build that for ubuntu touch?
[09:46] <alan_g> anpok: I haven't, but it is small enough that I'd start by building on the device
[09:47]  * alan_g worries that the evil script is going to start spreading
[09:47] <anpok> hmm too cute to be evil
[09:48] <RAOF> usc doesn't need to link to any of the hybris-y bits, does it?
[09:48] <anpok> only qt5 core and qt5dbus is added
[09:48] <RAOF> I think you *should* be able to use an honest-to-god armhf chroot.
[09:48] <alan_g> Mir and dbus
[09:48] <anpok> and mir/build/ make install into the chroot  works good
[09:49] <anpok> but the cmake config files of qt5 are evil
[09:49] <RAOF> Install qemu-usr-static and “mk-sbuild --arch=armhf trusty” should get you something working.
[09:52] <alan_g> anpok: do you need usc to test your nested changes? It would involve fewer variables to stick to the mir examples.
[09:53] <RAOF> Unless you're actually working on usc you should be able to use mir_demo_server_shell; that's what I'm testing nested with.
[09:53] <anpok> two instances of mir_demo_server_shell
[09:53] <anpok> ah
[09:54] <anpok> then i'll move usc back to the other end of the stack..
[09:58] <RAOF> So, um, why is the Nested platform trying to create a 1,1 pbuffer surface?
[09:59] <RAOF> Because that's never worked on the mesa Mir platform.
[09:59]  * alan_g briefly wonders what a "1,1 pbuffer surface" is before tuning out...
[10:00] <RAOF> Might make more sense as a 1×1 pbuffer surface?
[10:00] <anpok> alan_g: offscreen EGL surface with width and height attributes 1,1
[10:01] <alan_g> what does it need that for?
[10:01] <anpok> i only debugged through release mode binaries and thought that the pbuffer allocation function was some empty fallback.. but that might just be a side effect of the release binary
[15:34] <alan_g> greyback: how's this feel as a message passing API? (Obviously not hooked up to anything yet) https://code.launchpad.net/~alan-griffiths/mir/message-passing-api/+merge/198422
[15:51] <greyback> alan_g: looking...
[15:59] <greyback> alan_g:  surface_callback Callback function to be invoked when request completes = called when surface realized?
[16:01] <alan_g> greyback: when the call it's passed to completes. (Unrealized creation or realization
[16:28] <greyback> alan_g: I'm trying to decide if having Mir define messages to be of type "key:value" is a good idea. What do you think?
[16:29] <alan_g> why would mir define messages that it treats as opaque?
[16:31] <greyback> alan_g: true. That was my obvious counter-argument :)
[16:31] <greyback> alan_g: but it would enforce a style between shell and client
[16:31] <greyback> alan_g: yeah leave it
[16:32] <kgunn> i thot the reason for a notion of msg was to have some versioning control to it ?
[16:32] <alan_g> greyback: I originally outlined some structure to the messages, but after the feedback I got in London I decided that Mir should stay out of that
[16:33] <alan_g> kgunn: the question is whether that is envelope or content
[16:34] <alan_g> there should be versioning and structure - but Mir doesn't need to know
[16:35] <kgunn> alan_g: got it...so the versioning is extra-mir
[16:35] <kgunn> its really shell/papi responsibility
[16:35] <kgunn> ?
[16:37] <alan_g> kgunn: there's loads of stuff: protocol id, version, structure that Mir can ignore. (Even if we have a canonical example in "shellinator")
[16:41] <greyback> kgunn: yep, shell&papi will define their own versioned messaging scheme
[16:43] <kgunn> greyback: alan_g ...ok...was just thinking RAOF was promoting the idea mir would have a bit of awareness there...
[16:43] <kgunn> personally...i'm a fan of fully opaque
[16:43] <kgunn> just trying to keep an open mind
[16:43] <kgunn> as people seemed to have traversed this ground with x
[16:44] <greyback> yep, I think it best to keep it opaque
[16:45] <alan_g> kgunn: greyback - that experience is good for the unity8 protocol. But IMO Mir can and should ignore it.
[16:45] <alan_g> Anything Mir needs to know about the shell can tell it.
[16:45] <kgunn> alan_g: greyback ...yep, it totally makes sense to me...just trying to elicit any pitfalls
[16:46] <kgunn> racarr: ^
[16:47] <racarr> Mornnning
[16:47] <anpok> in london the discussion went in a direction about adding extensibility to mir to be able to keep those portocols opaque, but defined in a way that others could make use of them
[16:48] <racarr> Right, that's animportant bit about having versioning/identified protocols
[16:48] <tvoss> alan_g, greyback protobuf supports on the fly message generation and extraction, too. I would think that we should stick with one way of marshalling, with Mir being able to ignore messages (treat them as opaque)
[16:49] <greyback> racarr: +1
[16:51] <alan_g> anpok: their needs to be protocol negotiation and versioning - the question is whether Mir or a shell handles it. I see only problems in Mir doing so.
[16:53] <alan_g> Of course, shellinator and unity8 are free to do something compatible.
[16:54] <anpok> thought we ended with .. we might do that later.. (providing extensibility in some form)
[16:55] <tvoss> alan_g, by protocol you mean payload versioning (up to the higher level shell from my pov) or would you also like to version to the framing (size + type) for example?
[16:55] <alan_g> anpok: I thought about it since and decided that Mir isn't the "we" that controls the protocol negotiation/versioning/structure
[16:56] <anpok> yup I agree in best case we get away without the need for control..
[16:56] <greyback> tvoss: has protobuf good versioning support? Just thinking worse-case where we'd need a non-backward compatibile change
[16:56] <alan_g> tvoss: I initially intended that, but after the discussion that led to in London I decided that Mir should do the simplest thing and leave it to the next layer in the stack
[16:57] <tvoss> greyback, yup, it supports forward and backwards versioning
[16:57] <greyback> tvoss: ok thanks, will look that up
[16:58] <tvoss> greyback, ack, look at cap'n'proto, too
[16:59]  * greyback loving that project name
[16:59]  * tvoss too
[16:59] <alan_g> The simplest thing Mir can do that will work is to shift bytes between processes. It doesn't care if the shell uses protobuf or cap'n'proto
[16:59] <mlankhorst> set sail for epic fail
[17:00] <alan_g> mlankhorst: you know where we're going?
[17:00] <tvoss> alan_g, I tend to agree
[17:01]  * alan_g wonders what tvoss tended to agree to
[17:01] <mlankhorst> to the bottom!
[17:06] <racarr> I can't parse this conversation anymore :p
[17:06] <racarr> the joys of IRC
[17:08] <racarr> I think the simplest thingMir can do that will work is omitIPC and require shells to export a protocol
[17:08] <racarr> soI dont think that is what we are aiming for
[17:08] <anpok>  hm try | sort | uniq
[17:09] <racarr> aha
[17:18] <anpok> racarr: i think i misunderstood you, what are we aiming for?
[17:19] <racarr> anpok: Well, I just mean, I don't think "the simplest thing that Mir can do that will work"
[17:20] <racarr> is always the right thing for the combined architecture of Unity8 and Mir
[17:22] <anpok> understood ..
[17:23] <alan_g> racarr: I think we may have different values for "work". But do you have any objection to this approach?
[17:39] <racarr> alan_g: I think it shoves work to differing shells (and now papi/differing client implementations)
[17:39] <racarr> that could easilybe solved at the mir level with a protocol description language and a code generator
[17:42] <alan_g> Why should Mir be responsible for dictating a protocol description language?
[17:44]  * alan_g thinks a PDL is a good idea, but where does it belong in the stack?
[17:47] <racarr> alan_g: Because it's the 'lowest-common-denominator' for compatibility?
[17:47] <racarr> I'm not sure ;)
[17:49] <anpok> alan_g: in the shell creation framework/library?
[17:49] <anpok> brb
[17:53] <alan_g> anpok: racarr I'm concerned that we get into a tarpit of alternate ways to provide a PDL and don't deliver what unity8 (or the proxy - greyback) needs right now,
[17:57] <racarr> alan_g: That's fair.
[17:58] <racarr> I will try and finish my email on the subject today
[17:58] <racarr> i'd like to talk to Mr.RAOF
[17:58] <alan_g|EOD> racarr: ack
[20:45] <robert_ancell> racarr, so I hear I can now run u8 on desktop... :)
[20:56] <kgunn> robert_ancell: the rumors are true
[20:56] <robert_ancell> kgunn, any idea when packages will hit the archive?
[20:57] <kgunn> hmm.... robert_ancell nothing changed in mir, i think it was just unity-mir and platform-api...and all that's needed is in trunk
[20:58] <kgunn> so a couple of days i'd guess
[20:58] <kgunn> i'll fwd you the mail
[20:58] <kgunn> if you need
[20:58] <robert_ancell> I got the email
[20:58] <robert_ancell> It seems qtubuntu it probably the big one
[20:58] <robert_ancell> so it's in flight then?
[21:00] <robert_ancell> also, racarr said "It will be necessary to run as root for now" - is there a plan to make this work non-root, or should I continue to add support to lightdm so we can run a u-s-c+u8 combo on desktop?
[21:02] <kgunn> robert_ancell: waiting on RAOF to land some mesa patches to enable nested mir...then usc can be used
[21:02] <kgunn> and spoke to mterry & greyback earlier this morning...there shoulnd't be need for anything else afaict
[21:03] <robert_ancell> Oh, I see. The shell needs to be run as root until we can get it to run in u-s-c then?
[21:03] <kgunn> exactly
[21:03] <kgunn> and robert_ancell yes you are correct the qt5.2 is kind of a big thing...
[21:04] <kgunn> not completely sure why 5.2 is a pre-req tho
[21:04] <kgunn> from this morning i think 5.2 will be in archive mid Jan (?)
[21:04] <kgunn> platform guys will know best
[21:11] <racarr> robert_ancell: The basic deal with 5.2 as a prereq is qtubuntu only selects an opengl elsl context and selecting a desktop context produces strange issues
[21:11] <racarr> but qt on the desktop is compiled with desktop gl
[21:11] <robert_ancell> aha
[21:11] <racarr> in 5.1, it emits shaders that dont work with GLES
[21:11] <racarr> but in 5.2 it emits shaders that happen to work
[21:11] <racarr> and things are worked around until qtubuntu is fixed
[21:11] <racarr> :)
[21:11] <robert_ancell> racarr, do the desktop drivers have problems with gles/egl?
[21:12] <racarr> no should be fine
[21:12] <racarr> something is rather weird in Qt with Desktop GL, v.GLES
[21:12] <racarr> I can't claim to understand it
[23:04] <robert_ancell> kgunn, is RAOF on leave?
[23:04] <kgunn> robert_ancell: nope
[23:04] <kgunn> robert_ancell: he was on a little early...and looked like he was on late yesterday....
[23:04] <kgunn> he might be jet lagged :)
[23:05] <robert_ancell> yeah, I thought so
[23:05] <kgunn> robert_ancell: feel free to poke him continuously on mesa patches :)