[06:28] <duflu> alf_: Is it possible compositor/renderer destruction no longer has a GL context?... https://bugs.launchpad.net/mir/+bug/1489720
[06:33] <alf_> duflu: I am not aware of any change that has affected gl context lifetimes. What does eglGetCurrentContext return?
[06:33] <duflu> alf_: Don't know. I'm not set up on that device right now
[06:34] <duflu> Although I will be soon
[06:39] <duflu> Poor mako. Batter just went from full to empty in a blink of the eye
[06:40] <duflu> I think it was always empty. Because the phone doesn't shut down properly with wily. And even if your force it, it turns itself on again and drains battery
[07:17] <duflu> alf_: Nope. Context not lost. Everything is sane and in context. Just that glDeleteTextures crashes. Although valgrind reports that android and the graphics driver are full of errors...
[07:17] <duflu> Might be able to bisect the issue
[12:58] <alan_g|lunch> alf_: any idea what's going on here? Weirdness in the mesa stack - I've a workaround, but don't understand why it works. https://bugs.launchpad.net/mir/+bug/1495459 (I'm pretty sure camako saw this last week too, but didn't have consistent results.)
[12:59] <alf_> alan_g: let me see if I can reproduce
[13:20] <alan_g> greyback_: please take a look at https://code.launchpad.net/~alan-griffiths/mir/MirBlob/+merge/269949 (I think it is what you're expecting but also see the discussion.)
[13:21] <greyback_> alan_g: on my list, will get to it
[13:21] <alan_g> greyback_: thanks
[13:33] <alf_> alan_g: removing config.add_options(x11_displays_option_name, ...) fixes the problem. No idea why.
[13:34] <alan_g> alf_: yes, I've just discovered removing "boost::program_options::value<std::string>()->default_value(std::string{"1280x1024"})," "fixes the problem too
[13:35] <alan_g> alf_: This is seriously weird. But likely not mesa weirdness.
[13:39] <alf_> alan_g: yes, and in particular it's the default_value() part that triggers the issue
[13:40] <alan_g> alf_: thanks for confirming that
[13:41] <desrt> src/platforms/mesa/server/kms/cursor.cpp #includes <drm/drm.h> which doesn't exist on debian.  changing that to <libdrm/drm.h> fixed it for me and also seems to work on ubuntu
[13:51] <anpok> desrt: looking at the current drm package.. libdrm seems to be the install path preferred by libdrm
[13:52] <desrt> maybe that's why debian doesn't have it?
[13:59] <anpok> desrt: hm linux-libc-dev provides the other
[14:09] <desrt> anpok: not on debian...
[14:19] <anpok> yes we should switch to libdrm
[14:51] <alf_> anpok: xf86drm already includes drm.h, so I don't think it's needed at all
[15:24] <desrt> so, having some issues with mir-on-X11.  anyone can help with that?
[15:24] <desrt> kgunn: ^ hi :)
[15:24] <kgunn> desrt: yo...yes... camako should be helpful ^
[15:24] <kgunn> it's his baby
[15:24] <desrt> that's the name i was looking for.  thanks :)
[15:25] <anpok> camako: knows most about it
[15:25] <kgunn> he'll be happy to see someone putting it through it's paces
[15:25] <desrt> camako: hey... having trouble bringing up drm for x11 because gbm: Last dlopen error: /usr/lib/dri/i965_dri.so: undefined symbol: _glapi_tls_Dispatch
[15:25] <desrt> even though this does get defined (in /usr/lib/x86_64-linux-gnu/libglapi.so.0.0.0, which is loaded)
[15:29] <desrt> we've sort of been chasing down one problem after another for the entire morning, and now we find ourselves here, and a bit stuck
[15:30] <desrt> fwiw, it works if i LD_PRELOAD that library, but this seems like a bit of a bad solution :)
[15:34] <desrt> k.  we're gonna break for lunch.  bbiab.
[16:12] <camako> desrt, I haven't encountered this issue before.
[16:13] <camako> desrt, what do you see when you do ...  ls /dev/dri/
[16:13] <camako> card0  card1  controlD64  controlD65  renderD128  renderD129
[16:13] <camako> this is what I see ^
[16:13] <camako> you need the render nodes
[16:14] <camako> bb after lunch
[16:45] <desrt> camako: we already hit the render node issues and got past that :)
[16:45] <desrt> this is a pure dynamic library problem
[16:45] <desrt> btw: this is debian jessie
[18:49] <camako> desrt, can you run mir with the mesa-kms? I.e. in a vt?
[18:51] <desrt> camako: yes.  this is an x11 problem.
[19:28] <camako> desrt, we shouldn't be using gl, only egl on mir-on-x (and gles is used in the compositor)
[19:28] <desrt> it is using egl
[19:29] <camako> desrt, but then why the libglapi related error? Did you build the mir binaries in the debian env yourself?
[19:30] <desrt> yes
[19:30] <desrt> i'm not sure it's really directly related to mir, in fact, since it's rather a problem with the dri drivers that mir tries to load
[19:33] <camako> desrt, yeah.. It's curious that mesa-kms works though. Shouldn't be that different. Can you make mesa-x11 the first platform on the 'platforms' list (like in cmake-gui) and then after building, do a 'make test'?
[19:33] <desrt> i built with only mesa-x11 this time, fwiw
[19:34] <desrt> i also disabled tests :)
[19:34] <desrt> i'll switch that back on again.  gimme a sec.
[19:34] <camako> desrt, let's enable and run them
[19:34] <camako> ok
[19:35] <desrt> (building)
[19:37] <camako> desrt, are you using lp:mir or something else?
[19:37] <desrt> *ahem* something else
[19:39] <desrt> the branch i am using is based on 365d58f5c662fb67dcfa352d9dcb07bc9b98783e
[19:41] <camako> lol gotcha