/srv/irclogs.ubuntu.com/2014/07/04/#ubuntu-mir.txt

=== renato_ is now known as Guest91990
=== chihchun_afk is now known as chihchun
=== benonsoftware is now known as Guest69253
alan_gdednick: 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-sessions10:04
dednickalan_g: thanks. i'll take a look10:05
alan_gdednick: Sorry, wrong branch in paste buffer...  lp:~alan-griffiths/mir/spike-trusted-helper-socket10:05
=== doko_ is now known as doko
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
greybackalf_: I don't know. mterry would10:43
alf_greyback: yes, but US is on vacation today :) thanks10:44
greybackalf_: sorry, I've barely looked as USC code10:49
alf_greyback: no, worries, I will just remove it and we can put it back if needed10:49
greybackalf_: it's mainly just adds an event loop so you can use qt signal/slots - it's not used for GUIs10:51
alf_greyback: ahh, it's used by our dbus infrastructure in USC10:53
greybackalf_: yeah, would be needed for that too10:54
greybackalf_: can I ask you some questions on mir, gl configs & mesa?11:15
alf_greyback: of course11:16
greybackalf_: the qtcompositor code right now just uses the gl context that Mir chooses for it. Which is perfect on phablet devices as GLES is supported11:16
greybackalf_: but on desktop, Qt compiled with only desktop GL support.11:16
greybackalf_: 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 stuff11:17
greybackalf_: was that it? Nothing else had to be done?11:17
greybackI'm trying to do the same thing for QtComp but am not having success.11:18
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:20
greybackalf_: that's an idea. Perhaps there's some lib preloading happening somewhere to get around that11:21
mptOh dear I just realized that default window positioning depends on whether you’re using an LTR or an RTL language11:26
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
greybackalf_: qt5.3 does, but our packaging hasn't turned it on11:27
greybackalf_: ah, it's windows only :( So no change there11:32
alf_greyback: So, what kind of errors are you getting?11:33
greybackalf_: http://pastebin.ubuntu.com/7746717/ just a snippit (bit messy, I've debug code in)11:37
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:44
greybackalf_: that's what qtcomp is doing actually11:45
greybackhttp://bazaar.launchpad.net/~mir-team/qtmir/trunk/view/head:/src/platforms/mirserver/miropenglcontext.cpp11:46
greybackcombined with http://bazaar.launchpad.net/~mir-team/qtmir/trunk/view/head:/src/platforms/mirserver/mirserverintegration.cpp#L12411: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 precision11:47
greybackalf_: right. So I tried calling eglBindAPI(EGL_OPENGL_BIT) before makeCurrent and swapBuffers, but no good11:48
greybackerr eglBindAPI(EGL_OPENGL_API)11:49
greybackbut same error11:49
greybackso a difference I see is that in qtubuntu, eglBindAPI is also called before the context is created11:50
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:54
greybackalf_: it doesn't. I had thought that Mesa would "force" a GLES context to accept desktop GL11:55
greybackalf_: I can confirm, if I hack Mir to use a desktop GL context, this works fine11:56
greybackthis = Qt Comp on desktop11:56
greybackit's just the GL/GLES mismatch that I'm fighting11:56
greybackand I'm trying to emulate what qtubuntu does11: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 works11:57
alf_greyback: but if the current context is GLES2 you can't do GL stuff with it11:58
greybackalf_: which makes sense to me.11:59
greybackalf_: so is qtubuntu actually creating a desktopGL context: http://bazaar.launchpad.net/~phablet-team/qtubuntu/trunk/view/head:/src/platforms/base/context.cc#L5512:00
greybackjust by having bound the api before eglCreateContext12:00
greyback?12:00
alf_greyback: right12:03
greybackalf_: ok. Then that's my problem then so. Mir creates GLES2 context, but Qt needs desktopGL.12:03
=== alan_g is now known as alan_g|lunch
alf_greyback: what do you change in Mir to force a GL context? Only the eglBindAPI() call in display_helpers?12:10
greybackalf_: 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 before12:11
alf_greyback: right, I mean how did you hack it, do you have a diff?12:12
greybackalf_: all extremely messy: http://pastebin.ubuntu.com/7746824/ I hope you can see what I'm attempting though12:13
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
greybackalf_: ah. Maybe, lemme see if I kept it. It was several months ago now12:17
greybackalf_: I doubt it'll apply cleanly: http://pastebin.ubuntu.com/7746849/12:19
greybackit was to add a compile-time option to mir, similar to what Qt had. Think it broke more than it solved overall12:20
greybackEGL_RENDERABLE_TYPE, EGL_OPENGL_BIT, <- the main bit really12:21
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 Mir12:26
alf_greyback: with the understanding that this is the WRONG way to do it :)12:26
greybackalf_: it is, definitely12:26
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 Mesa12:29
greyback alf_ yeah. If I can manage to exploit the Mesa quirk, I might be happy enough for now12:29
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 know12:30
alf_greyback: (I want to stress again the "while still building mir against libGLESv2" part)12:32
greybackalf_: sure12:32
=== alan_g|lunch is now known as alan_g
MacSlowGreetings!13:06
MacSlowI'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
MacSlowI also tried passing EGL_PLATFORM=mir, but that doesn't fix it.13:09
MacSlowstarting a mir-client on this very system used to work just fine a couple of weeks ago.13:09
MacSlowWhat 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:10
MacSlowalf_, I'll try some other clients just for cross-checking...13:11
alf_MacSlow: How exactly are you are running the server and client, are you using you own build, or packages?13:12
MacSlowalf_, hm... the egltriangle example from lp:mir works13:12
MacSlowodd13:12
MacSlowalf_, 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
MacSlowalf_, guess i've to dig deeper13:13
=== Guest91990 is now known as renato___
=== chrisccoulson_ is now known as chrisccoulson
=== alan_g is now known as alan_g|tea
=== alan_g|tea is now known as alan_g
MacSlowHow would one start a mir-client on a current UbuntuTouch image running the unity-system-compositor?14:55
alan_gMacSlow: I think USC still exports a socket to the filesystem, so check you have +rw access and supply that via "-m"15:03
MacSlowalan_g, sudo ./unity-system-compositor-spinner -m /run/mir_socket15:06
MacSlowalan_g, is what I try to execute... but it fails and only spits out...15:06
MacSlowCurrent active output is 2560x1600 +0+015:06
MacSlowServer supports 3 of 6 surface pixel formats. Using format: 115:06
MacSlowand then exits15:06
MacSlowrunning mir-clients used to be a piece of cake some weeks ago15:06
alan_gMacSlow:  ls -l /run/mir_socket?15:08
MacSlowsrwxrwxrwx 1 root root 0 Jul  4 16:50 /run/mir_socket=15:10
MacSlowI just tried MIR_SOCKET=/run/mir_socket /usr/bin/unity-system-compositor-spinner15:10
MacSlowwhich did not fail or exit... but the greeter is unresponsive to touch-inputs... I'm restarting the N1015:10
alan_gMacSlow: how does a demo client behave? E.g. mir_demo_client_display_config -m /run/mir_socket15:15
MacSlowalan_g, I've a way to test it... greyback suggested to kill lightdm/unity-system-compositor and start the mir_demo_server_shell15:18
MacSlowalan_g, with that as basis it allows me to get my mir-client  running and visible15:18
alan_gMacSlow: if you can work with mir_demo_server_shell it eliminate a bunch of code from the mix.15:19
MacSlowhm... but oddly the locally compiled unity-system-compositor-spinner (from lp:unity-system-compositor) segfaults while the system-wide installed one does work15:21
alan_gAre they built with the same compiler?15:23
alf_MacSlow: alan_g: Confirmed, I get the same behavior15:24
alf_MacSlow: ==9958== Invalid read of size 415:26
alf_==9958==    at 0x50C5D60: cairo_surface_status (in /usr/lib/x86_64-linux-gnu/libcairo.so.2.11301.0)15:26
MacSlowcairo_surface_status() crashes according to the backtrace15: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'd15:26
alf_MacSlow: cmake .. -DCMAKE_INSTALL_PREFIX=/usr15:30
alf_MacSlow: it can't find the png file otherwise15:30
alf_MacSlow: of course it should just print a nice error message instead of crashing :)15:32
MacSlowalf_, I'll add something while I'm fixing the issue I initially wanted to address :)15:33
alan_gdednick: any feedback on lp:~alan-griffiths/mir/spike-trusted-helper-socket? (I've MP'd it now)15:41
dednickalan_g: hm. I was waying for tyhicks, but just realised that he's on holiday today. 4th July.15:42
dednicks/waying/waiting15:42
MacSlowgreyback, alan_g, alf_: got all issues sorted out (on N10 and desktop) soaring away with the optimization for the spinner now... thanks!15:42
alf_MacSlow: great, have fun :)15:43
greybackgood to hear15:43
alan_gdednick: ack15:43
dednickalan_g: he's back on monday15:43
alan_gMacSlow: \o/15:43
alan_gdednick: while that discussion might obsolete the approach I think we need something like this short term.15:45
dednickalan_g: yes. i agree. I can try take a look at the MP this afternoon15:46
=== alan_g is now known as alan_g|EOW

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