=== 5EXABD84D is now known as infinity
=== mibofra is now known as Guest38719
=== chihchun_afk is now known as chihchun
=== davmor2_hols is now known as davmor2
=== tvoss is now known as tvoss|test
=== tvoss|test is now known as tvoss
[08:44] <alan_g> alf_: anpok got time today for a little USC MP? https://code.launchpad.net/~alan-griffiths/unity-system-compositor/incorporate-logo-into-spinner-binary/+merge/261181
[08:55] <anpok> ok
[09:20] <duflu> alan_g: Let me know if you ever find a vectorized version? (just a list of vertices is enough) I like the idea of infinite scalability and 3D effects using the logo in future projects :)
[09:20] <duflu> Although it has rotational symmetry so should not be too hard...
[09:21] <alan_g> duflu: sure. Maybe someone in design has something more tractable than a png?
[09:22] <duflu> alan_g: Dunno. Although I suspect the basic list of coordinates required and then repeated 3/6 times would be hilariously simple
[09:24] <alan_g> alf_: do you know a way to get a premultiplied image out of any tool? I really don't want to write a script to edit the header.
[09:28] <duflu> alan_g: Frankly that's the best option to edit in situ. Because the requirement for pre-multiplication is in the code using it and not the image. If someone were to extract the image header and want to edit it, they would not want it pre-multiplied
[09:29] <alf_> alan_g: I would say don't care about this for now, the sizes are small. I am more concerned about having both .h and .png
[09:30] <duflu> Even better if we generate the header from png at build time, which I'd recommend
[09:30] <alf_> duflu: alan_g: Ideally we would produce the .h from .png and change to pre-multiplied alpha there
[09:30] <alan_g> Creating the header during the build would introduce a dependency on a tool that does that.
[09:31] <duflu> alf_: Maybe, probably not. If you're using a generic bin2c tool then it should not interpret the bytes it's converting
[09:31] <alan_g> (And I don't know one that does pre-multiplication
[09:31] <duflu> alan_g: I've done it many times. Write a bin2c.c tool and generate it at build time too :)
[09:32] <alf_> duflu: we need to use a tool that dumps the pixel data, so it does know about the pixel format
[09:32] <alf_> alan_g: I am fine on USC build depending on such a tool
[09:33] <duflu> alf_: "need" is over-used there :)
[09:33] <duflu> Just generate your tools at build time. It's a simple matter of *make*
[09:33] <alf_> alan_g: (and I am fine not doing premultiplication for now)
[09:34] <duflu> It's not a performance issue. Running through the image once even on a slow device is quite fast enough
[09:35] <alan_g> How about I delete the .png and if anyone wants to generate the headers they can MP that?
[09:35] <duflu> alan_g: Reproducability says probably keep it
[09:36] <alf_> alan_g: In that case don't delete it, I will try to propose an MP with the build time generation later today or tomorrow
[09:38] <alan_g> alf_: works for me.
[10:00] <alan_g> Guys, any preferences for which client API? Two options here: http://paste.ubuntu.com/11645578/
[10:08] <duflu> alan_g: The second one will eventually be required (for type morphing) so probably better
[10:09] <alan_g> duflu: we can do type morphing with either
[10:09] <duflu> Well the second one makes more sense to me. You shouldn't need the connection object to morph
[10:11] <alan_g> The fist one is one call fewer and makes the existing mir_connection_create_spec_for_changes() more reasonable.
[10:11] <alan_g> *first
[10:11] <alan_g> But I too lean towards the second
[10:12] <duflu> alan_g: On that note, why is connection here? mir_connection_create_spec_for_changes(MirConnection* connection);
[10:15] <alan_g> I've a vague recollection it was for consistency with code we've now deleted.
[10:15] <alan_g> But I guess we don't need it for the new API
[11:33] <alan_g> Hmm. mir_surface_create() used the connection supplied to mir_connection_create_spec_for_XXX. Shouldn't the connection just be supplied to directly?
=== chihchun is now known as chihchun_afk
=== Guest38719 is now known as mibofra
=== tvoss is now known as tvoss|dinner
=== tvoss|dinner is now known as tvoss
=== alan_g is now known as alan_g|EOD
=== tvoss is now known as tvoss|test
=== tvoss|test is now known as tvoss
[20:20] <SturmFlut> tvoss: Ping
[20:20] <tvoss> SturmFlut, pong
[21:09] <robert_ancell> RAOF, ping
[22:54] <kgunn> robert_ancell: is it a holiday over there...wonder if he's off
[22:54] <robert_ancell> kgunn, ah, is that it
[22:54] <RAOF> robert_ancell: Pong
[22:54] <RAOF> kgunn: No, that was yesterday :)
[22:54] <kgunn> Queen's birthday :)
[23:05] <robert_ancell> RAOF, had a question about X drivers and Mir - why do the drivers need to know they're running inside Xmir?
[23:05] <RAOF> robert_ancell: For new glamor-based XMir they don't, because there are no X drivers.
[23:05] <robert_ancell> RAOF, ah, so we can drop all those patches?
[23:06] <RAOF> Correct.
[23:06] <RAOF> Although this is a bit of a bone of contention.
[23:06] <robert_ancell> RAOF, oh, why?
[23:06] <RAOF> My understanding is that nvidia would very much like to have the same sort of DDX interface that the Xorg binary provides.
[23:07] <RAOF> So that they can provide their own GLX, and expose all the funky features that their hardware supports.
[23:07] <robert_ancell> RAOF, right, but there's always the option of other driver interfaces to Mir like Android
[23:07] <robert_ancell> RAOF, and I should be pushing these all into Debian git?
[23:08] <RAOF> If you've got access, please.
[23:08] <robert_ancell> RAOF, I'm not sure - I guess I should just try and push
[23:20] <RAOF> Oh, that reminds me...