=== thomi_ is now known as thomi === shuduo_afk is now known as shuduo === chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun === shuduo is now known as shuduo_afk === shuduo_afk is now known as shuduo === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun [09:32] Hi RAOF - you got home OK? [09:32] alan_g: Indeed I did. [09:32] Only delayed by a little bit. [09:33] Good [09:34] Where are we with the changes to support Mir nested mode on mesa? [09:39] 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] They were localised. [09:42] Oh, I guess that I should check that nested actually works, too. [09:43] RAOF: that would help. (I think anpok was trying to use it yesterday - without success.) [09:44] .. hm yes it failed when creating a pbuffer surface in the nested compositor [09:44] i looked at building u-s-c with the partial chroot script of mir [09:46] how do you build that for ubuntu touch? [09:46] 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] hmm too cute to be evil [09:48] usc doesn't need to link to any of the hybris-y bits, does it? [09:48] only qt5 core and qt5dbus is added [09:48] I think you *should* be able to use an honest-to-god armhf chroot. [09:48] Mir and dbus [09:48] and mir/build/ make install into the chroot works good [09:49] but the cmake config files of qt5 are evil [09:49] Install qemu-usr-static and “mk-sbuild --arch=armhf trusty” should get you something working. [09:52] anpok: do you need usc to test your nested changes? It would involve fewer variables to stick to the mir examples. [09:53] 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] two instances of mir_demo_server_shell [09:53] ah [09:54] then i'll move usc back to the other end of the stack.. [09:58] So, um, why is the Nested platform trying to create a 1,1 pbuffer surface? [09:59] 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] Might make more sense as a 1×1 pbuffer surface? [10:00] alan_g: offscreen EGL surface with width and height attributes 1,1 [10:01] what does it need that for? [10:01] 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 === shuduo is now known as shuduo_afk === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun === greyback is now known as greyback|lunch === chihchun is now known as chihchun_afk === dandrader is now known as dandrader|afk === dandrader|afk is now known as dandrader === greyback|lunch is now known as greyback [15:34] 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 === alan_g is now known as alan_g|tea === shuduo_afk is now known as shuduo === alan_g|tea is now known as alan_g === shuduo is now known as shuduo_afk [15:51] alan_g: looking... [15:59] alan_g: surface_callback Callback function to be invoked when request completes = called when surface realized? [16:01] greyback: when the call it's passed to completes. (Unrealized creation or realization === dandrader is now known as dandrader|lunch [16:28] 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] why would mir define messages that it treats as opaque? [16:31] alan_g: true. That was my obvious counter-argument :) [16:31] alan_g: but it would enforce a style between shell and client [16:31] alan_g: yeah leave it [16:32] i thot the reason for a notion of msg was to have some versioning control to it ? [16:32] 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] kgunn: the question is whether that is envelope or content [16:34] there should be versioning and structure - but Mir doesn't need to know [16:35] alan_g: got it...so the versioning is extra-mir [16:35] its really shell/papi responsibility [16:35] ? [16:37] 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] kgunn: yep, shell&papi will define their own versioned messaging scheme [16:43] greyback: alan_g ...ok...was just thinking RAOF was promoting the idea mir would have a bit of awareness there... [16:43] personally...i'm a fan of fully opaque [16:43] just trying to keep an open mind [16:43] as people seemed to have traversed this ground with x [16:44] yep, I think it best to keep it opaque [16:45] kgunn: greyback - that experience is good for the unity8 protocol. But IMO Mir can and should ignore it. [16:45] Anything Mir needs to know about the shell can tell it. [16:45] alan_g: greyback ...yep, it totally makes sense to me...just trying to elicit any pitfalls [16:46] racarr: ^ [16:47] Mornnning [16:47] 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] Right, that's animportant bit about having versioning/identified protocols [16:48] 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] racarr: +1 [16:51] 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] Of course, shellinator and unity8 are free to do something compatible. [16:54] thought we ended with .. we might do that later.. (providing extensibility in some form) [16:55] 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] anpok: I thought about it since and decided that Mir isn't the "we" that controls the protocol negotiation/versioning/structure [16:56] yup I agree in best case we get away without the need for control.. [16:56] tvoss: has protobuf good versioning support? Just thinking worse-case where we'd need a non-backward compatibile change [16:56] 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] greyback, yup, it supports forward and backwards versioning [16:57] tvoss: ok thanks, will look that up [16:58] greyback, ack, look at cap'n'proto, too [16:59] * greyback loving that project name [16:59] * tvoss too [16:59] 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] set sail for epic fail [17:00] mlankhorst: you know where we're going? [17:00] alan_g, I tend to agree === tvoss is now known as tvoss|test === tvoss|test is now known as tvoss|dinner [17:01] * alan_g wonders what tvoss tended to agree to [17:01] to the bottom! [17:06] I can't parse this conversation anymore :p [17:06] the joys of IRC [17:08] I think the simplest thingMir can do that will work is omitIPC and require shells to export a protocol === dandrader|lunch is now known as dandrader [17:08] soI dont think that is what we are aiming for [17:08] hm try | sort | uniq [17:09] aha [17:18] racarr: i think i misunderstood you, what are we aiming for? [17:19] anpok: Well, I just mean, I don't think "the simplest thing that Mir can do that will work" [17:20] is always the right thing for the combined architecture of Unity8 and Mir [17:22] understood .. [17:23] racarr: I think we may have different values for "work". But do you have any objection to this approach? [17:39] alan_g: I think it shoves work to differing shells (and now papi/differing client implementations) [17:39] that could easilybe solved at the mir level with a protocol description language and a code generator [17:42] 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] alan_g: Because it's the 'lowest-common-denominator' for compatibility? [17:47] I'm not sure ;) [17:49] alan_g: in the shell creation framework/library? [17:49] brb [17:53] 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] alan_g: That's fair. === alan_g is now known as alan_g|EOD [17:58] I will try and finish my email on the subject today [17:58] i'd like to talk to Mr.RAOF [17:58] racarr: ack === dandrader is now known as dandrader|afk === dandrader|afk is now known as dandrader === jono is now known as Guest63303 [20:45] racarr, so I hear I can now run u8 on desktop... :) [20:56] robert_ancell: the rumors are true [20:56] kgunn, any idea when packages will hit the archive? [20:57] 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] so a couple of days i'd guess [20:58] i'll fwd you the mail [20:58] if you need [20:58] I got the email [20:58] It seems qtubuntu it probably the big one [20:58] so it's in flight then? [21:00] 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] robert_ancell: waiting on RAOF to land some mesa patches to enable nested mir...then usc can be used [21:02] and spoke to mterry & greyback earlier this morning...there shoulnd't be need for anything else afaict [21:03] 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] exactly [21:03] and robert_ancell yes you are correct the qt5.2 is kind of a big thing... [21:04] not completely sure why 5.2 is a pre-req tho [21:04] from this morning i think 5.2 will be in archive mid Jan (?) [21:04] platform guys will know best [21:11] 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] but qt on the desktop is compiled with desktop gl [21:11] aha [21:11] in 5.1, it emits shaders that dont work with GLES [21:11] but in 5.2 it emits shaders that happen to work [21:11] and things are worked around until qtubuntu is fixed [21:11] :) [21:11] racarr, do the desktop drivers have problems with gles/egl? [21:12] no should be fine [21:12] something is rather weird in Qt with Desktop GL, v.GLES [21:12] I can't claim to understand it [23:04] kgunn, is RAOF on leave? [23:04] robert_ancell: nope [23:04] robert_ancell: he was on a little early...and looked like he was on late yesterday.... [23:04] he might be jet lagged :) [23:05] yeah, I thought so [23:05] robert_ancell: feel free to poke him continuously on mesa patches :)