TrevinhoRAOF: hey! You remember that buffer corruption? It happened because I forgot to filter out a surface buffer swap when using egl.... :/....01:07
TrevinhoRAOF: but.... after doing that, I don't get anything draw at all01:08
RAOFTrevinho: So you were swapping twice?01:08
Trevinhowhen using egl swap with damage (eglBufferSwap stul works)01:08
TrevinhoRAOF: yeh, i was...01:09
RAOFBehind the back of EGL! Naughty!01:09
TrevinhoRAOF: but now I presume is something more driver related at this point...01:09
TrevinhoRAOF: like it says it supports swap with damage, while is not the case01:09
RAOFYeah, I'll just have a second look at what our WithDamage implementation does.01:09
RAOFTrevinho: Ahem. We lie through our teeth about supporting SwapBuffersWithDamage01:51
TrevinhoRAOF: ah! :)01:51
RAOFLikewise, buffer_age01:51
RAOFBut at least in that case we always return 0.01:52
RAOFSo it's harmless.01:52
RAOFOur SwapBuffersWithDamage returns EGL_FALSE01:52
RAOFAnd nothing else :)01:52
TrevinhoAh, 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 it01:52
Trevinhofair enough btw... RAOF any plan for supporting them?01:53
RAOFI could trivially fix the buffer_age now.01:54
RAOFIn fact, I shall.01:54
RAOFBut WithDamage requires that we actually implement some form of damage :)01:54
RAOFI can fix that we say we support it, though :)01:54
TrevinhoRAOF: that's enough for us I think01:55
Trevinhorobert_ancell: ^^ so... it looks like that the at gdk level all is fine for supporting gl... .)01:55
Trevinhorobert_ancell: got any chance to check that branch?01:55
robert_ancellTrevinho, I'll have a look now01:56
Trevinhorobert_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 swap01:57
Trevinhorobert_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=4073caf3b47a9c847b30d9238860e9f16118337c01:58
robert_ancellTrevinho, can you convert it into a patch and put it in bugzilla? It will be easier to review like that02:03
Trevinhorobert_ancell: sure02:03
robert_ancellI immediately notice you've added gdk_mir_window_get_mir_surface which doesn't seem related or necessarily something we should be exposing02:03
Trevinhorobert_ancell: you meant the whole branch or this last patch02:04
robert_ancellI'm looking at the wip/mir-gdkgl branch02:04
Trevinhorobert_ancell: yes, I added that because also other toolkits expose such stuff (x11 the xid, wayland the surface) and... we'd need it for clutter02:04
robert_ancellTrevinho, right, but you need to just propose one change at a time02:05
Trevinhorobert_ancell: that was my plan, i just forgot to remove that patch from the branch :(02:05
robert_ancellOK, I'll have a look when you have a cleaned up patch in bz02:05
Trevinhorobert_ancell: it's at https://bugzilla.gnome.org/review?bug=74034602:25
Trevinhoops, no it seems I've squashed one patch that was out02:27
robert_ancellRAOF, mir surfaces can change types?02:30
RAOFrobert_ancell: I believe so; I think we've got a design requirement for morphing windows.02:31
duflu_Not clear if that ever changes parenthood. I think sabdfl was driving that idea02:32
=== duflu_ is now known as duflu
RAOFI believe it might unset parenthood; dialog → normal would.02:33
dufluRAOF: Yeah that's one.02:33
* duflu likes the idea of morphing because it's beautiful and computationally really simple to implement02:34
RAOFI don't think any morph would reassign parent, though.02:34
Trevinhorobert_ancell: I've removed the extra commit, patch updated at https://bugzilla.gnome.org/review?bug=740346&attachment=29104902:35
robert_ancellreading it now02:35
dufluRAOF: Although to do it properly I think we might end up with separate src and dest surfaces02:35
dufluNot sure02:35
RAOFrobert_ancell: Oh, by the way: http://bazaar.launchpad.net/~mir-team/mir/development-branch/revision/207402:36
robert_ancellRAOF, nice!02:36
* Trevinho seconds that!02:37
Trevinhorobert_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
Trevinhorobert_ancell: so I just followed what gdk was doing in other toolkits02:47
Trevinhorobert_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:48
Trevinhorobert_ancell: let me know what you prefer... whether adding a gdkmirglcontex-private.h with the struct definition or the way it is02:49
robert_ancellTrevinho, I'd prefer the private header02:51
Trevinhorobert_ancell: ok, doing it02:52
robert_ancellTrevinho, note the other backends do it that way but I changed that for the Mir backend02:52
Trevinhorobert_ancell: yes, I noticed...02:53
Trevinhorobert_ancell: want a new private header, or should I use gdkmir-private?02:53
robert_ancellTrevinho, just commit the gdk_mir_display_get_mir_connection change directly if it's just a trivial change02:53
robert_ancellTrevinho, use gdkmir-private02:54
=== chihchun is now known as chihchun_afk
Trevinhorobert_ancell: updated03:16
robert_ancellTrevinho, ack03:16
robert_ancellTrevinho, #include "gdkglcontextprivate.h"03:17
robert_ancellDoesn't exist in patch03:17
robert_ancell(in gdkmir-private.h)03:17
Trevinhorobert_ancell: it's provided by gdk..03:18
Trevinhothat's the genric03:18
robert_ancelloh, duh03:18
Trevinhorobert_ancell: updated03:31
Trevinhorobert_ancell: ta03:35
=== chihchun_afk is now known as chihchun
=== dandrader is now known as dandrader|afk
=== dandrader|afk is now known as dandrader
alan_gRats! 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:18
alfalan_g: We can always switch to needs review again and cancel the autolanding job10:26
alan_galf: just doing that. ;)10:26
alfWhen 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:08
mlankhorstI'm toying with enabling copy-less support on DRI2, but it seems to be more concerned about lifetime11:16
=== 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
mlankhorstRAOF: hmm... how do I allocate depth buffers?13:37
attente_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 it14:14
ubot5Launchpad bug 1391976 in Mir "Loading libmircommon.so twice leads to a segfault in protobuf code" [High,Confirmed]14:14
alan_gattente_: AFAIK that bug shouldn't be affecting unity8 - could you share why you think it does?14:22
attente_alan_g: not sure, but i keep getting this in .cache/upstart/unity8.log: http://paste.ubuntu.com/9123860/14:25
attente_alan_g: is it possible that i need to rebuild another dependency against mir? i'm building u-s-c and unity814:26
alan_gare you running on desktop or phone? Are you rebuilding qtmir?14:26
alan_gdoes your u-s-c work?14:27
attente_alan_g: on the desktop, haven't rebuilt qtmir14:27
alan_gattente_: unity8 uses mir through qtmir, you'll need that14:28
alan_ggreyback: anything I'm missing? ^^14:28
attente_alan_g: thanks, i'll try rebuilding qtmir to see if it helps14:31
mlankhorstbleh.. I wish I knew someone who understood this crap better than me :P14:36
anpokmlankhorst: hm depth buffers.. for that we should have an interface..14:36
anpokbut you are only using mir_client?14:36
anpokor again, you mean .. you want to configure the depth of the depth buffer?14:37
mlankhorstI want to figure out how I can create a depth buffer and pass that along for dri2 to use14:49
greybackalan_g: nothing I can think of.14:59
attente_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.proto15:07
alan_gattente_: can't *build* qtmir?15:08
attente_alan_g: yes15:08
attente_tests are failing because of that segfault15:09
alan_gattente_: you don't somehow have the libmirplatform*-android platform library installed do you?15:11
attente_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 trunk15:11
attente_alan_g: no, those aren't installed15:12
alan_gattente_: I don't often build them but I just point pkgconfig at a local install.15:13
alan_ggreyback: any better suggestion? ^15:14
greybackattente_: 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
greybackthen make & make install15:15
greybackbut try "make check" - those are the tests15:15
attente_greyback: does this work for you on x86_64?15:18
greybackattente_: ah, I thought you on arm15:18
greybackattente_: qmake "QMAKE_CXX=g++-4.9" "QMAKE_LINK=g++-4.9" "QMAKE_LINK_SHLIB=g++-4.9"15:18
attente_greyback: hmm.. i still seem to be getting the protobuf error after doing make check15:25
greybackattente_: then it's something in Mir IMO15:25
greybackattente_: are you using a custom build of Mir?15:25
greybackdo the mir-demos work for you?15:26
attente_greyback: it's mir from the current trunk15:26
attente_i built using debuild and ccache15:26
greybackattente_: have you other copies of the mir libraries in /usr/lib by any chance?15:27
attente_mir demo shell is working15:28
attente_greyback: i have libmircommon2/libmircommon3, libmirplatform3/libmirplatform4, etc. installed15:29
greybackattente_: you should only have 1 of each of those15:29
attente_but there seems to be a bunch of things (including unity8) that are depending on the old ones15:29
greybackas I'm not certain Mir is good at having multiple versions of itself installed at once15:30
attente_greyback: ok, i'll remove them and try again. thank you!15:31
alan_gI'm certain it was bad at it and it's getting fixed (but possibly not there yet)15:31
greybackattente_: let us know if it helps15:31
attente_greyback: alan_g: ok, qtmir tests are passing again now, i am hopeful for the rest. thank you!15:38
greybackattente_: great!15:39
alan_gattente_: :)15:42
alan_gcamako: are you working on bug 1394221? (If not I'll steal it)15:56
ubot5bug 1394221 in Mir "acceptance_tests are too chatty" [Medium,Confirmed] https://launchpad.net/bugs/139422115:56
=== chihchun is now known as chihchun_afk
camakoalan_g, yes I am16:02
=== chihchun_afk is now known as chihchun
alan_gcamako: the problem you mentioned - https://code.launchpad.net/~alan-griffiths/mir/fix-set_logger/+merge/24239217:31
camakoalan_g, oh sh*t... my fault... thx for the fix!17:34
alan_gI just happened to look in the right place17:35
* alan_g suspects he wrote the offending expression in an untested spike and also shares the blame for not seeing it at review time.17:38
=== alan_g is now known as alan_g|EOD
=== chihchun is now known as chihchun_afk
RAOFmlankhorst: You allocate depth buffers yourself.22:00
RAOFmlankhorst: 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:01
mlankhorstyeah I'll just implement it by ignoring it22:14
mlankhorstI'm not sure anyone cares about sharing depth/stencil buffers22:14
RAOFThey manifestly do not; Intel at least has been ignoring that part of the spec for a number of years.22:19

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!