| === 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 | ||
| 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:32 |
| alan_g | Good | 09:33 |
| alan_g | Where are we with the changes to support Mir nested mode on mesa? | 09:34 |
| 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:39 |
| * alan_g didn't hear the explosions | 09:40 | |
| RAOF | They were localised. | 09:40 |
| RAOF | Oh, I guess that I should check that nested actually works, too. | 09:42 |
| alan_g | RAOF: that would help. (I think anpok was trying to use it yesterday - without success.) | 09:43 |
| 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:44 |
| 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:46 |
| * alan_g worries that the evil script is going to start spreading | 09:47 | |
| anpok | hmm too cute to be evil | 09:47 |
| 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:48 |
| 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:49 |
| alan_g | anpok: do you need usc to test your nested changes? It would involve fewer variables to stick to the mir examples. | 09:52 |
| 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:53 |
| anpok | then i'll move usc back to the other end of the stack.. | 09:54 |
| RAOF | So, um, why is the Nested platform trying to create a 1,1 pbuffer surface? | 09:58 |
| 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... | 09:59 | |
| 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:00 |
| 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 | 10:01 |
| === 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 | ||
| 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:34 |
| === 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 | ||
| greyback | alan_g: looking... | 15:51 |
| greyback | alan_g: surface_callback Callback function to be invoked when request completes = called when surface realized? | 15:59 |
| alan_g | greyback: when the call it's passed to completes. (Unrealized creation or realization | 16:01 |
| === dandrader is now known as dandrader|lunch | ||
| 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:28 |
| alan_g | why would mir define messages that it treats as opaque? | 16:29 |
| 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:31 |
| 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:32 |
| alan_g | kgunn: the question is whether that is envelope or content | 16:33 |
| alan_g | there should be versioning and structure - but Mir doesn't need to know | 16:34 |
| kgunn | alan_g: got it...so the versioning is extra-mir | 16:35 |
| kgunn | its really shell/papi responsibility | 16:35 |
| kgunn | ? | 16:35 |
| 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:37 |
| greyback | kgunn: yep, shell&papi will define their own versioned messaging scheme | 16:41 |
| 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:43 |
| greyback | yep, I think it best to keep it opaque | 16:44 |
| 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:45 |
| kgunn | racarr: ^ | 16:46 |
| 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:47 |
| 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:48 |
| greyback | racarr: +1 | 16:49 |
| 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:51 |
| alan_g | Of course, shellinator and unity8 are free to do something compatible. | 16:53 |
| anpok | thought we ended with .. we might do that later.. (providing extensibility in some form) | 16:54 |
| 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:55 |
| 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:56 |
| tvoss | greyback, yup, it supports forward and backwards versioning | 16:57 |
| greyback | tvoss: ok thanks, will look that up | 16:57 |
| tvoss | greyback, ack, look at cap'n'proto, too | 16:58 |
| * 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 | 16:59 |
| alan_g | mlankhorst: you know where we're going? | 17:00 |
| tvoss | alan_g, I tend to agree | 17:00 |
| === tvoss is now known as tvoss|test | ||
| === tvoss|test is now known as tvoss|dinner | ||
| * alan_g wonders what tvoss tended to agree to | 17:01 | |
| mlankhorst | to the bottom! | 17:01 |
| racarr | I can't parse this conversation anymore :p | 17:06 |
| racarr | the joys of IRC | 17:06 |
| racarr | I think the simplest thingMir can do that will work is omitIPC and require shells to export a protocol | 17:08 |
| === dandrader|lunch is now known as dandrader | ||
| racarr | soI dont think that is what we are aiming for | 17:08 |
| anpok | hm try | sort | uniq | 17:08 |
| racarr | aha | 17:09 |
| anpok | racarr: i think i misunderstood you, what are we aiming for? | 17:18 |
| racarr | anpok: Well, I just mean, I don't think "the simplest thing that Mir can do that will work" | 17:19 |
| racarr | is always the right thing for the combined architecture of Unity8 and Mir | 17:20 |
| anpok | understood .. | 17:22 |
| alan_g | racarr: I think we may have different values for "work". But do you have any objection to this approach? | 17:23 |
| 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:39 |
| alan_g | Why should Mir be responsible for dictating a protocol description language? | 17:42 |
| * alan_g thinks a PDL is a good idea, but where does it belong in the stack? | 17:44 | |
| racarr | alan_g: Because it's the 'lowest-common-denominator' for compatibility? | 17:47 |
| racarr | I'm not sure ;) | 17:47 |
| anpok | alan_g: in the shell creation framework/library? | 17:49 |
| anpok | brb | 17:49 |
| 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:53 |
| racarr | alan_g: That's fair. | 17:57 |
| === alan_g is now known as alan_g|EOD | ||
| 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 | 17:58 |
| === dandrader is now known as dandrader|afk | ||
| === dandrader|afk is now known as dandrader | ||
| === jono is now known as Guest63303 | ||
| robert_ancell | racarr, so I hear I can now run u8 on desktop... :) | 20:45 |
| kgunn | robert_ancell: the rumors are true | 20:56 |
| robert_ancell | kgunn, any idea when packages will hit the archive? | 20:56 |
| 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:57 |
| 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? | 20:58 |
| 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:00 |
| 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:02 |
| 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:03 |
| 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:04 |
| 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:11 |
| 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 | 21:12 |
| 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:04 |
| robert_ancell | yeah, I thought so | 23:05 |
| kgunn | robert_ancell: feel free to poke him continuously on mesa patches :) | 23:05 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!