[10:04] <alan_g> dednick: re ..._trusted socket. I think the essentials are done (I need some tests around starting up providers - but it ought to "just work" as a side effect of the production changes). Let me know if you try it: lp:~alan-griffiths/mir/permissions-and-error-handling-for-prompt-sessions
[10:05] <dednick> alan_g: thanks. i'll take a look
[10:05] <alan_g> dednick: Sorry, wrong branch in paste buffer...  lp:~alan-griffiths/mir/spike-trusted-helper-socket
[10:43] <alf_> greyback: Hi! In case you know... why are using a QCoreApplication in USC? Is it a left-over? Are we going to need it in the near future?
[10:43] <greyback> alf_: I don't know. mterry would
[10:44] <alf_> greyback: yes, but US is on vacation today :) thanks
[10:49] <greyback> alf_: sorry, I've barely looked as USC code
[10:49] <alf_> greyback: no, worries, I will just remove it and we can put it back if needed
[10:51] <greyback> alf_: it's mainly just adds an event loop so you can use qt signal/slots - it's not used for GUIs
[10:53] <alf_> greyback: ahh, it's used by our dbus infrastructure in USC
[10:54] <greyback> alf_: yeah, would be needed for that too
[11:15] <greyback> alf_: can I ask you some questions on mir, gl configs & mesa?
[11:16] <alf_> greyback: of course
[11:16] <greyback> alf_: the qtcompositor code right now just uses the gl context that Mir chooses for it. Which is perfect on phablet devices as GLES is supported
[11:16] <greyback> alf_: but on desktop, Qt compiled with only desktop GL support.
[11:17] <greyback> alf_: I know in qtubuntu we had a hack to call eglBindAPI(OPEN_GL) which persuaded Mesa to let us use a GLES context with GL shaders and stuff
[11:17] <greyback> alf_: was that it? Nothing else had to be done?
[11:18] <greyback> I'm trying to do the same thing for QtComp but am not having success.
[11:20] <alf_> greyback: I don't recall the detail, only that this was a hack that just happened to work with Mesa. The issue is that since Mir uses GLES2 it links with libGLES2. If qtcompositor comes and indirectly links with libGL (which offers many of the same symbols) there could be trouble.
[11:21] <greyback> alf_: that's an idea. Perhaps there's some lib preloading happening somewhere to get around that
[11:26] <mpt> Oh dear I just realized that default window positioning depends on whether you’re using an LTR or an RTL language
[11:27] <alf_> greyback: but ideally Qt should support selecting GL vs GLES2 at runtime... I think they have made some first steps to support this?
[11:27] <greyback> alf_: qt5.3 does, but our packaging hasn't turned it on
[11:32] <greyback> alf_: ah, it's windows only :( So no change there
[11:33] <alf_> greyback: So, what kind of errors are you getting?
[11:37] <greyback> alf_: http://pastebin.ubuntu.com/7746717/ just a snippit (bit messy, I've debug code in)
[11:44] <alf_> greyback: ok, how about creating a new GL context shared from the GLES2 context that Mir gives you and using that with Qt?
[11:45] <greyback> alf_: that's what qtcomp is doing actually
[11:46] <greyback> http://bazaar.launchpad.net/~mir-team/qtmir/trunk/view/head:/src/platforms/mirserver/miropenglcontext.cpp
[11:47] <greyback> combined with http://bazaar.launchpad.net/~mir-team/qtmir/trunk/view/head:/src/platforms/mirserver/mirserverintegration.cpp#L124
[11:47] <alf_> greyback: it seems though, that Qt produces a fragment shader for GL but is being compiled with a GLES2 context, and thus complains about missing precision
[11:48] <greyback> alf_: right. So I tried calling eglBindAPI(EGL_OPENGL_BIT) before makeCurrent and swapBuffers, but no good
[11:49] <greyback> err eglBindAPI(EGL_OPENGL_API)
[11:49] <greyback> but same error
[11:50] <greyback> so a difference I see is that in qtubuntu, eglBindAPI is also called before the context is created
[11:54] <alf_> greyback: I don't see how the code in miropenglcontext sets the context to desktop GL. It eventually calls DisplayBuffer::make_current() which will use the built-in mir context (which is GLES2)
[11:55] <greyback> alf_: it doesn't. I had thought that Mesa would "force" a GLES context to accept desktop GL
[11:56] <greyback> alf_: I can confirm, if I hack Mir to use a desktop GL context, this works fine
[11:56] <greyback> this = Qt Comp on desktop
[11:56] <greyback> it's just the GL/GLES mismatch that I'm fighting
[11:57] <greyback> and I'm trying to emulate what qtubuntu does
[11:57] <alf_> greyback: From what I understand, what Mesa accepts is linking against libGLESv2 and asking for a desktop GL context and vice versa and it works
[11:58] <alf_> greyback: but if the current context is GLES2 you can't do GL stuff with it
[11:59] <greyback> alf_: which makes sense to me.
[12:00] <greyback> alf_: so is qtubuntu actually creating a desktopGL context: http://bazaar.launchpad.net/~phablet-team/qtubuntu/trunk/view/head:/src/platforms/base/context.cc#L55
[12:00] <greyback> just by having bound the api before eglCreateContext
[12:00] <greyback> ?
[12:03] <alf_> greyback: right
[12:03] <greyback> alf_: ok. Then that's my problem then so. Mir creates GLES2 context, but Qt needs desktopGL.
[12:10] <alf_> greyback: what do you change in Mir to force a GL context? Only the eglBindAPI() call in display_helpers?
[12:11] <greyback> alf_: I hacked Mir to choose GL context, just to prove to myself Qt would work with it on desktop. I've not tried this eglBindAPI thing before
[12:12] <alf_> greyback: right, I mean how did you hack it, do you have a diff?
[12:13] <greyback> alf_: all extremely messy: http://pastebin.ubuntu.com/7746824/ I hope you can see what I'm attempting though
[12:17] <alf_> greyback: You also mentioned that you hacked Mir itself to produce a desktop GL context. Do you have a diff for that?
[12:17] <greyback> alf_: ah. Maybe, lemme see if I kept it. It was several months ago now
[12:19] <greyback> alf_: I doubt it'll apply cleanly: http://pastebin.ubuntu.com/7746849/
[12:20] <greyback> it was to add a compile-time option to mir, similar to what Qt had. Think it broke more than it solved overall
[12:21] <greyback> EGL_RENDERABLE_TYPE, EGL_OPENGL_BIT, <- the main bit really
[12:26] <alf_> greyback: If you can confirm that just changing EGL_RENDERABLE_TYPE, EGL_OPENGL_BIT and eglBindAPI(EGL_OPENGL_API) in display_helpers.cpp (while still building mir against libGLESv2) works for you, we can provide a workaround in Mir
[12:26] <alf_> greyback: with the understanding that this is the WRONG way to do it :)
[12:26] <greyback> alf_: it is, definitely
[12:29] <alf_> greyback: but barring Qt having runtime GL vs GLESv2 selection (or perhaps Mir having it?) there is not much we can do, other than take advantage of this fortunate quirk in Mesa
[12:29] <greyback>  alf_ yeah. If I can manage to exploit the Mesa quirk, I might be happy enough for now
[12:30] <alf_> greyback: ok, so try just hacking EGL_OPENGL_BIT and eglBindAPI(EGL_OPENGL_API) in display_helpers.cpp and if it works let me know
[12:32] <alf_> greyback: (I want to stress again the "while still building mir against libGLESv2" part)
[12:32] <greyback> alf_: sure
[13:06] <MacSlow> Greetings!
[13:09] <MacSlow> I'm constantly getting the error "libEGL warning: unsupported platform (null)" when trying to run a mir-client (using mir_demo_server_basic from lp:mir) on my desktop machine (ATI Radeon, driver: Gallium 0.4)
[13:09] <MacSlow> I also tried passing EGL_PLATFORM=mir, but that doesn't fix it.
[13:09] <MacSlow> starting a mir-client on this very system used to work just fine a couple of weeks ago.
[13:10] <MacSlow> What changed in the required procedure to make that work?
[13:10] <alf_> MacSlow: I don't think the error is related, we have been getting it forever (on working systems)
[13:11] <MacSlow> alf_, I'll try some other clients just for cross-checking...
[13:12] <alf_> MacSlow: How exactly are you are running the server and client, are you using you own build, or packages?
[13:12] <MacSlow> alf_, hm... the egltriangle example from lp:mir works
[13:12] <MacSlow> odd
[13:13] <MacSlow> alf_, the mir-client I'm trying to get to work is the unity-system-compositor-spinner... which works fine on the phone (N4)
[13:13] <MacSlow> alf_, guess i've to dig deeper
[14:55] <MacSlow> How would one start a mir-client on a current UbuntuTouch image running the unity-system-compositor?
[15:03] <alan_g> MacSlow: I think USC still exports a socket to the filesystem, so check you have +rw access and supply that via "-m"
[15:06] <MacSlow> alan_g, sudo ./unity-system-compositor-spinner -m /run/mir_socket
[15:06] <MacSlow> alan_g, is what I try to execute... but it fails and only spits out...
[15:06] <MacSlow> Current active output is 2560x1600 +0+0
[15:06] <MacSlow> Server supports 3 of 6 surface pixel formats. Using format: 1
[15:06] <MacSlow> and then exits
[15:06] <MacSlow> running mir-clients used to be a piece of cake some weeks ago
[15:08] <alan_g> MacSlow:  ls -l /run/mir_socket?
[15:10] <MacSlow> srwxrwxrwx 1 root root 0 Jul  4 16:50 /run/mir_socket=
[15:10] <MacSlow> I just tried MIR_SOCKET=/run/mir_socket /usr/bin/unity-system-compositor-spinner
[15:10] <MacSlow> which did not fail or exit... but the greeter is unresponsive to touch-inputs... I'm restarting the N10
[15:15] <alan_g> MacSlow: how does a demo client behave? E.g. mir_demo_client_display_config -m /run/mir_socket
[15:18] <MacSlow> alan_g, I've a way to test it... greyback suggested to kill lightdm/unity-system-compositor and start the mir_demo_server_shell
[15:18] <MacSlow> alan_g, with that as basis it allows me to get my mir-client  running and visible
[15:19] <alan_g> MacSlow: if you can work with mir_demo_server_shell it eliminate a bunch of code from the mix.
[15:21] <MacSlow> hm... but oddly the locally compiled unity-system-compositor-spinner (from lp:unity-system-compositor) segfaults while the system-wide installed one does work
[15:23] <alan_g> Are they built with the same compiler?
[15:24] <alf_> MacSlow: alan_g: Confirmed, I get the same behavior
[15:26] <alf_> MacSlow: ==9958== Invalid read of size 4
[15:26] <alf_> ==9958==    at 0x50C5D60: cairo_surface_status (in /usr/lib/x86_64-linux-gnu/libcairo.so.2.11301.0)
[15:26] <MacSlow> cairo_surface_status() crashes according to the backtrace
[15:26] <alf_> ==9958==    by 0x4032FB: uploadTexture (eglspinner.c:150)
[15:26] <alf_> ==9958==    by 0x403BA1: main (eglspinner.c:365)
[15:26] <alf_> ==9958==  Address 0x1c is not stack'd, malloc'd or (recently) free'd
[15:30] <alf_> MacSlow: cmake .. -DCMAKE_INSTALL_PREFIX=/usr
[15:30] <alf_> MacSlow: it can't find the png file otherwise
[15:32] <alf_> MacSlow: of course it should just print a nice error message instead of crashing :)
[15:33] <MacSlow> alf_, I'll add something while I'm fixing the issue I initially wanted to address :)
[15:41] <alan_g> dednick: any feedback on lp:~alan-griffiths/mir/spike-trusted-helper-socket? (I've MP'd it now)
[15:42] <dednick> alan_g: hm. I was waying for tyhicks, but just realised that he's on holiday today. 4th July.
[15:42] <dednick> s/waying/waiting
[15:42] <MacSlow> greyback, alan_g, alf_: got all issues sorted out (on N10 and desktop) soaring away with the optimization for the spinner now... thanks!
[15:43] <alf_> MacSlow: great, have fun :)
[15:43] <greyback> good to hear
[15:43] <alan_g> dednick: ack
[15:43] <dednick> alan_g: he's back on monday
[15:43] <alan_g> MacSlow: \o/
[15:45] <alan_g> dednick: while that discussion might obsolete the approach I think we need something like this short term.
[15:46] <dednick> alan_g: yes. i agree. I can try take a look at the MP this afternoon