[01:07] RAOF: hey! You remember that buffer corruption? It happened because I forgot to filter out a surface buffer swap when using egl.... :/.... [01:08] RAOF: but.... after doing that, I don't get anything draw at all [01:08] Trevinho: So you were swapping twice? [01:08] when using egl swap with damage (eglBufferSwap stul works) [01:08] still^ [01:09] RAOF: yeh, i was... [01:09] Behind the back of EGL! Naughty! [01:09] RAOF: but now I presume is something more driver related at this point... [01:09] RAOF: like it says it supports swap with damage, while is not the case [01:09] Yeah, I'll just have a second look at what our WithDamage implementation does. [01:51] Trevinho: Ahem. We lie through our teeth about supporting SwapBuffersWithDamage [01:51] RAOF: ah! :) [01:51] Likewise, buffer_age [01:52] But at least in that case we always return 0. [01:52] So it's harmless. [01:52] Our SwapBuffersWithDamage returns EGL_FALSE [01:52] And nothing else :) [01:52] Ah, in fact I was getting an EGL_FALSE but then eglERrror didn't say anything about that, so I was wondering if I was wrong about it [01:53] fair enough btw... RAOF any plan for supporting them? [01:53] Yes. [01:54] I could trivially fix the buffer_age now. [01:54] In fact, I shall. [01:54] cool [01:54] But WithDamage requires that we actually implement some form of damage :) [01:54] I can fix that we say we support it, though :) [01:55] RAOF: that's enough for us I think [01:55] robert_ancell: ^^ so... it looks like that the at gdk level all is fine for supporting gl... .) [01:55] robert_ancell: got any chance to check that branch? [01:56] Trevinho, I'll have a look now [01:57] robert_ancell: thanks, as RAOF will fix the fact that egl says we've extensions we actually don't support, I guess I can also remove the hardcoded "return FALSE" on about supporting the buffer damage swap [01:58] robert_ancell: and... Once you've done with that, give a look if doing this makes sense to you: https://git.gnome.org/browse/gtk+/commit/?h=wip/mir-async-swaps&id=4073caf3b47a9c847b30d9238860e9f16118337c [02:03] Trevinho, can you convert it into a patch and put it in bugzilla? It will be easier to review like that [02:03] robert_ancell: sure [02:03] I immediately notice you've added gdk_mir_window_get_mir_surface which doesn't seem related or necessarily something we should be exposing [02:04] robert_ancell: you meant the whole branch or this last patch [02:04] I'm looking at the wip/mir-gdkgl branch [02:04] robert_ancell: yes, I added that because also other toolkits expose such stuff (x11 the xid, wayland the surface) and... we'd need it for clutter [02:05] Trevinho, right, but you need to just propose one change at a time [02:05] robert_ancell: that was my plan, i just forgot to remove that patch from the branch :( [02:05] OK, I'll have a look when you have a cleaned up patch in bz [02:25] robert_ancell: it's at https://bugzilla.gnome.org/review?bug=740346 [02:27] ops, no it seems I've squashed one patch that was out [02:30] RAOF, mir surfaces can change types? [02:31] robert_ancell: I believe so; I think we've got a design requirement for morphing windows. [02:32] Not clear if that ever changes parenthood. I think sabdfl was driving that idea === duflu_ is now known as duflu [02:33] I believe it might unset parenthood; dialog → normal would. [02:33] RAOF: Yeah that's one. [02:34] * duflu likes the idea of morphing because it's beautiful and computationally really simple to implement [02:34] I don't think any morph would reassign parent, though. [02:35] robert_ancell: I've removed the extra commit, patch updated at https://bugzilla.gnome.org/review?bug=740346&attachment=291049 [02:35] yep [02:35] reading it now [02:35] RAOF: Although to do it properly I think we might end up with separate src and dest surfaces [02:35] Not sure [02:36] robert_ancell: Oh, by the way: http://bazaar.launchpad.net/~mir-team/mir/development-branch/revision/2074 [02:36] RAOF, nice! [02:37] * Trevinho seconds that! [02:47] robert_ancell: about moving these functions to gdk_mir_window or gdk_mir_display... I wanted to do the same since the beginning but then I avoided to do that not to expose privately the definition of GdkMirGLContext... [02:47] robert_ancell: so I just followed what gdk was doing in other toolkits [02:48] robert_ancell: but... I agree that it would be better to keep these functions in the place where they override.... Not sure if it's better for reading the whole gl code btw... (I mean, having all these inside gtkmirglcontext makes easy to see the whole gl engine in the same place) [02:49] robert_ancell: let me know what you prefer... whether adding a gdkmirglcontex-private.h with the struct definition or the way it is [02:51] Trevinho, I'd prefer the private header [02:52] robert_ancell: ok, doing it [02:52] Trevinho, note the other backends do it that way but I changed that for the Mir backend [02:53] robert_ancell: yes, I noticed... [02:53] robert_ancell: want a new private header, or should I use gdkmir-private? [02:53] Trevinho, just commit the gdk_mir_display_get_mir_connection change directly if it's just a trivial change [02:53] k [02:54] Trevinho, use gdkmir-private === chihchun is now known as chihchun_afk [03:16] robert_ancell: updated [03:16] Trevinho, ack [03:17] Trevinho, #include "gdkglcontextprivate.h" [03:17] Doesn't exist in patch [03:17] (in gdkmir-private.h) [03:18] robert_ancell: it's provided by gdk.. [03:18] that's the genric [03:18] oh, duh [03:31] robert_ancell: updated [03:35] robert_ancell: ta === chihchun_afk is now known as chihchun === dandrader is now known as dandrader|afk === dandrader|afk is now known as dandrader [10:18] Rats! alf TA'd an MP I was updating in response to review comments. https://code.launchpad.net/~alan-griffiths/mir/restrict-access-to-private-headers/+merge/242097 - should I kill the updates? [10:26] alan_g: We can always switch to needs review again and cancel the autolanding job [10:26] alf: just doing that. ;) [11:08] When compiling with clang I get "multiple definition of `pthread_equal'" errors when linking the tests. Has anyone seen this? (vivid, clang 3.5.0) [11:14] hmm [11:16] I'm toying with enabling copy-less support on DRI2, but it seems to be more concerned about lifetime === dandrader is now known as dandrader|afk === chihchun is now known as chihchun_afk === ara is now known as Guest1529 === chihchun_afk is now known as chihchun === dandrader|afk is now known as dandrader [13:37] RAOF: hmm... how do I allocate depth buffers? [14:14] hi, is there any progress on https://bugs.launchpad.net/mir/+bug/1391976? i can't seem to get unity8 running from trunk because of it [14:14] Launchpad bug 1391976 in Mir "Loading libmircommon.so twice leads to a segfault in protobuf code" [High,Confirmed] [14:22] attente_: AFAIK that bug shouldn't be affecting unity8 - could you share why you think it does? [14:25] alan_g: not sure, but i keep getting this in .cache/upstart/unity8.log: http://paste.ubuntu.com/9123860/ [14:26] alan_g: is it possible that i need to rebuild another dependency against mir? i'm building u-s-c and unity8 [14:26] are you running on desktop or phone? Are you rebuilding qtmir? [14:27] does your u-s-c work? [14:27] alan_g: on the desktop, haven't rebuilt qtmir [14:28] attente_: unity8 uses mir through qtmir, you'll need that [14:28] greyback: anything I'm missing? ^^ [14:31] alan_g: thanks, i'll try rebuilding qtmir to see if it helps [14:36] bleh.. I wish I knew someone who understood this crap better than me :P [14:36] mlankhorst: hm depth buffers.. for that we should have an interface.. [14:36] but you are only using mir_client? [14:37] or again, you mean .. you want to configure the depth of the depth buffer? [14:49] I want to figure out how I can create a depth buffer and pass that along for dri2 to use [14:59] alan_g: nothing I can think of. [15:07] alan_g: can't seem to build qtmir for the same reason: tests are failing because of the libprotobuf problem: File already exists in database: mir_protobuf_wire.proto [15:08] attente_: can't *build* qtmir? [15:08] alan_g: yes [15:09] tests are failing because of that segfault [15:11] attente_: you don't somehow have the libmirplatform*-android platform library installed do you? [15:11] is there some special way of building/running them from trunk? i've just been trying to build using debuild and ccache, but wondering if there's an easier way to build and run from trunk [15:12] alan_g: no, those aren't installed [15:13] attente_: I don't often build them but I just point pkgconfig at a local install. [15:14] greyback: any better suggestion? ^ [15:15] attente_: easiest way to build qtmir (after bzr clean-tree) is: qmake "QMAKE_CXX=arm-linux-gnueabihf-g++-4.9" "QMAKE_LINK=arm-linux-gnueabihf-g++-4.9" "QMAKE_LINK_SHLIB=arm-linux-gnueabihf-g++-4.9" [15:15] then make & make install [15:15] but try "make check" - those are the tests [15:18] greyback: does this work for you on x86_64? [15:18] attente_: ah, I thought you on arm [15:18] attente_: qmake "QMAKE_CXX=g++-4.9" "QMAKE_LINK=g++-4.9" "QMAKE_LINK_SHLIB=g++-4.9" [15:25] greyback: hmm.. i still seem to be getting the protobuf error after doing make check [15:25] attente_: then it's something in Mir IMO [15:25] attente_: are you using a custom build of Mir? [15:26] do the mir-demos work for you? [15:26] greyback: it's mir from the current trunk [15:26] i built using debuild and ccache [15:27] attente_: have you other copies of the mir libraries in /usr/lib by any chance? [15:28] mir demo shell is working [15:29] greyback: i have libmircommon2/libmircommon3, libmirplatform3/libmirplatform4, etc. installed [15:29] attente_: you should only have 1 of each of those [15:29] but there seems to be a bunch of things (including unity8) that are depending on the old ones [15:30] as I'm not certain Mir is good at having multiple versions of itself installed at once [15:31] greyback: ok, i'll remove them and try again. thank you! [15:31] I'm certain it was bad at it and it's getting fixed (but possibly not there yet) [15:31] attente_: let us know if it helps [15:38] greyback: alan_g: ok, qtmir tests are passing again now, i am hopeful for the rest. thank you! [15:39] attente_: great! [15:42] attente_: :) [15:56] camako: are you working on bug 1394221? (If not I'll steal it) [15:56] bug 1394221 in Mir "acceptance_tests are too chatty" [Medium,Confirmed] https://launchpad.net/bugs/1394221 === chihchun is now known as chihchun_afk [16:02] alan_g, yes I am === chihchun_afk is now known as chihchun [17:31] camako: the problem you mentioned - https://code.launchpad.net/~alan-griffiths/mir/fix-set_logger/+merge/242392 [17:34] alan_g, oh sh*t... my fault... thx for the fix! [17:35] I just happened to look in the right place [17:38] * alan_g suspects he wrote the offending expression in an untested spike and also shares the blame for not seeing it at review time. === alan_g is now known as alan_g|EOD === chihchun is now known as chihchun_afk [22:00] mlankhorst: You allocate depth buffers yourself. [22:01] mlankhorst: Mir is only ever going to give you colour buffers. If you need any auxiliary buffers, you're free to allocate them however you want. [22:14] yeah I'll just implement it by ignoring it [22:14] I'm not sure anyone cares about sharing depth/stencil buffers [22:19] They manifestly do not; Intel at least has been ignoring that part of the spec for a number of years.