[01:07] <kdub> hmm, none of our top-approved things have landed today
[01:07] <kdub> good morning duflu
[01:14] <duflu_> kdub: Hi
[01:15] <duflu_> kdub: Same thing happened Friday-to-Monday
[01:23] <racarr> unity-mirisnt landingeither
[01:23] <racarr> also unity mir doesnt build against dev branch
[01:23] <racarr> also the sky is falling.
[01:26] <kdub> http://www.savagechickens.com/2013/01/jenkins.html
[02:31] <duflu_> kdub: I'll land them all manually
[03:17] <duflu> Back soon
[08:49] <ogra_> RAOF, android uses ueventd ... but in our setup where we run an android container under ubuntu, the ubuntu side has udev and can monitor the events without issue
[13:36] <ricmm> alf_: ping
[13:36] <alf_> ricmm: hey
[13:37] <greyback> alf_: pings.push_back(greyback)
[13:38] <ricmm> lol
[13:38] <ricmm> alf->pings.pop_back()
[13:38] <ricmm> I need 5 min
[13:39] <ricmm> greyback: go
[13:41] <greyback> alf_: just looking for some high-level advice. I had Qt rendering 1 frame successfully as a Mir compositor. But it crashes around the swapBuffer (DisplayBuffer::post_update) call, with a pretty useless stack trace
[13:43] <greyback> alf_: this is the sort of backtrace: http://pastebin.ubuntu.com/6405348/. The __GI_abort suggests to me an exception is being thrown, but I can't catch it in my code.
[13:44] <greyback> what would you recommend me do? Step through Mir code? Or track the GL calls with apitrace? Suggestions welcome
[13:44] <alf_> greyback: Is Mir built with debug symbols?
[13:44] <ricmm> so many threads
[13:45] <greyback> alf_: I'm using the last release, and dbg symbols are installed
[13:46] <ricmm> what sits at 0x4178671c?
[13:46] <ricmm> I'm gonna go ahead and guess one of the android GL blobs
[13:47] <greyback> yep
[13:47] <greyback> so that hints to me some bad GL call
[13:47] <alf_> greyback: why aren't you developing on the desktop? ;)
[13:48] <greyback> alf_: because it seems every time I try, I lock myself out of X completely :)
[13:49] <greyback> alf_: should I? Then I'd be using the usual gbm drivers,, which are probably easier to debug, I guess
[13:50] <alf_> greyback: That would be my proposal... do you have a laptop you can use as an ssh terminal (or the other way around)?
[13:52] <tvoss> greyback, seems to be the snapshotter is waiting ... just a wild guess: could you temporarily disable it?
[13:52] <greyback> tvoss: aye, that was an idea I had too
[13:52] <greyback> alf_: yep, ok, I'll do that so
[13:53] <alf_> greyback: in case you continue on the phone, ensure you have -dbg symbols/ddeb packages for all major packages in the stack (e.g. stdc++, qt), since on arm not only you don't get symbols, the backtrace is cut short...
[13:53] <alf_> tvoss: greyback: FWIW, it's normal for the snapshotter to just wait...
[13:54] <tvoss> alf_, yup, agreed: as I said, just a wild guess
[13:54] <greyback> alf_: ah, that's interesting. I thought short BT was only due to corrupted stack. Nice tip, thanks
[13:54] <ricmm> greyback: I would advise against doing this on the desktop
[13:54] <ricmm> greyback: as it wont be the first platform to use it
[13:55] <greyback> ricmm: that was my original motivation
[13:55] <ricmm> you know my feelings on these kind of things, and from experience we know where it can take us :)
[14:00] <ricmm> alf_: so my question went in another direction
[14:00] <ricmm> kdub's investigation of n7 showed that screenshotting is causing it to crash
[14:01] <ricmm> filling the texture from the buffer seems to be blowing everything up, the screen starts to flicker and it stops getting update
[14:03] <ogra_> ricmm, screenshotting crashes maguro too ... fwiw
[14:03] <ricmm> what screenshotting
[14:04] <ricmm> the shell's running apps thing?
[14:04] <ogra_> no, taking a screenshot :P
[14:04] <ricmm> screencap on adb?
[14:04] <ogra_> ignore, me, we obviously mean different things
[14:05] <ogra_> mirfbdump
[14:05] <ricmm> got it
[14:05] <ricmm> I dont have that one :)
[14:06] <ogra_> its a script from QA :)
[14:06] <ricmm> ok
[14:06] <ogra_> ricmm, http://paste.ubuntu.com/6405471/
[14:06] <ogra_> works well on mako ...
[14:07] <alf_> ricmm: so, if you disable the glReadPixels() call then everything continues to work ok (apart from getting invalid snapshots)?
[14:08] <ricmm> trying that
[14:08] <ricmm> I disabled the whole path
[14:08] <ricmm> sec
[14:13] <ricmm> alf_: yup, works fine with glReadPixels out
[14:13] <ricmm> well, not fine, but you know what I mean
[14:14] <alf_> ricmm: well, that indicates a driver issue, i.e., a glReadPixel call shouldn't mess up the system...
[14:15] <alf_> ricmm: what happens if you enable only the GL_RGBA read pixels path?
[14:20] <ricmm> alf_: still dies
[14:22] <alf_> ricmm: any errors logged after this by the driver (or does glGetError() say something)?
[14:36] <ricmm> alf_: no GL errors, no
[14:36] <ricmm> seeing something weird tho mmm
[14:36] <ricmm> sec
[15:12] <greyback> alf_: sorry this sounds stupid, but I'm confused. On my laptop (this machine, has X running), I switch to VT1, run "mir_demo_server_shell&" - the screen does not black out or anything. I expected that it should, no?
[15:13] <alf_> greyback: sudo ?
[15:13] <greyback> then I ssh in to kill mir_demo_server_shell, however now all key events don't get to the VT
[15:13] <greyback> sudo
[15:13] <greyback> damn
[15:14] <greyback> can we not have things fail if they don't have permission?
[15:15] <alf_> greyback: yes, ideally they would fail but just get you back to a useful VT. There seem to be some failure modes that mess up our tear down.
[15:20] <mterry> racarr, hello!  I'm back from an American holiday and am looking again at those issues from the sprint.  Are you still focused on scenegraph?
[15:22] <greyback> alf_: even with sudo, it doesn't seem to work. mir_demo_server_shell just locks my machine, and killing it leaves it in unusable state
[15:23] <alf_> greyback: what graphics card and driver are you using?
[15:23] <greyback> alf_: intel sandybridge
[15:25] <alf_> greyback: can you try running with gdb and 'catch throw'?
[15:27] <greyback> alf_: ok.
[15:30] <ricmm> alf_: this thing is still blowing up, no GL error and nothing from the driver in logcat
[15:30] <ricmm> Tegra has a bunch of weird issues, this might be one of them
[15:30] <ricmm> I know they dont support pbuffers, do we use that anywhere in the screenshotting path?
[15:30] <ricmm> 1/10 times it works
[15:31] <tvoss> ricmm, sounds racy
[15:32] <ricmm> it does
[15:32] <alf_> ricmm: yes, on android we create a EGL pbuffer as a dummy surface for the EGL context
[15:32] <ricmm> for the shared based context?
[15:32] <ricmm> base*
[15:33] <alf_> ricmm: For all "dummy" context including the shared one so we can make them current. Can you check if "EGL_KHR_surfaceless_context" is supported?
[15:36] <alf_> ricmm: one thing you could try is to make all instances of eglMakeCurrent() in android_display.cpp take 'EGL_NO_SURFACE,EGL_NO_SURFACE' instead of the dummy egl surfaces.
[15:37] <alf_> ricmm: so basically in AndroidGLContext::make_current() and AndroidDisplay::AndroidDisplay()
[15:38] <ricmm> right, will try
[15:38] <ricmm> I think it does support surfaceless_ctx
[15:40] <alf_> ricmm: ok, if using surfaceless contexts fixes snapshotting it's an easy fix to query the extension at runtime and act accordingly.
[15:42] <kgunn> mterry: you're a bit early for racarr ...and he got sidelined by a performance regression, but he was back to working on the autopilot input bug for mir on mir
[15:44] <mterry> kgunn, early for racarr?  he lives in UK right?
[15:45] <mterry> Well, I can continue my own investigation until he can get back to me
[15:46] <ricmm> mterry: CA
[15:47] <mterry> ricmm, kgunn: aha...  For some reason my memory of the Oakland sprint was that it was in London.  Yikes...
[15:47] <ricmm> ;
[15:49] <kgunn> mterry: haha, yeah...and i'd like you and he to continue that thread
[15:49] <mterry> kgunn, yar, for sure
[15:50] <kgunn> Mirv: didrocks ...so with ci off, what's the recommended for the mir update to trunk ? manual land ? or just wait?
[15:58] <didrocks> kgunn: better to wait, as we don't have dailies as well, we can't land it
[16:01] <kgunn> didrocks: ack, thot so...just double checking
[16:02] <didrocks> kgunn: I put Mir on the first thing in the list FYI
[16:03] <ricmm> alf_: so it supports it "theoretically"
[16:03] <ricmm> but it blows up the makeCurrent
[16:03] <ricmm> so, it really doesnt :)
[16:03] <ricmm> tegra is great
[16:07] <greyback> alf_: if I ssh into a laptop, can I run mir via ssh? Must it be from a VT?
[16:08] <alf_> greyback: you just need to have a VT active and use sudo, but it should work (that's how I do it)
[16:09] <greyback> alf_: yeah. It used to work for me a few months back too
[16:09] <greyback> sorry, "it" = running from VT. Running from ssh I didn't think would work either
[16:11] <alf_> ricmm: I just saw that in android_display.cpp we are requesting a config with just EGL_WINDOW_BIT (no EGL_PBUFFER_BIT). What happens if you add EGL_PBUFFER_BIT (EGL_WINDOW_BIT|EGL_PBUFFER_BIT) ?
[16:19] <alan_g> greyback: if you're running from ssh you need to specify --vt
[16:20] <kdub> ricmm, alf_ so we're thinking that the nexus 7 doesnt support pbuffers?
[16:22] <ricmm> whats the best way to confirm that? this comes from reading somewhere a comment that said tegra doesnt play nice with pbuffers
[16:22] <ricmm> but I cant find the wording in any official doc
[16:22] <ricmm> it certainly doesnt support EGL_KHR_surfaceless_context
[16:27] <kdub> i think checking that the config has EGL_PBUFFER_BIT is good... i'll try
[16:29] <ricmm> kdub: hmm tried here
[16:29] <ricmm> worked the first attempt but exploded with the second app
[16:29] <ricmm> checking again
[17:25] <kdub> alf_, with the screenshotting, should we be using the OES functions? o.O
[17:25] <kdub> like, glBindFramebufferOES
[17:28] <alf_> kdub: In OpenGL ES 2.0 the framebuffer extensions was merged into core so the suffix was dropped
[17:29] <kdub> ah, i kinda felt i was missing a data point like that
[17:30] <kdub> i just saw sf using all these OES functions to do screencap, but since they were merged, that should be fine
[17:35] <alf_> kdub: 18:11 < alf_> ricmm: I just saw that in android_display.cpp we are requesting a config with just EGL_WINDOW_BIT (no EGL_PBUFFER_BIT). What happens if you add EGL_PBUFFER_BIT (EGL_WINDOW_BIT|EGL_PBUFFER_BIT) ?
[17:35] <alf_> kdub: since we are creating pbuffers with this config we should ensure we choose a config with EGL_PBUFFER_BIT
[17:36] <alf_> kdub: (not sure if it is related with what ricmm is seeing)
[17:36]  * kdub is still trying to configure unity-mir but
[17:36] <kdub> ricmm said that didn't help
[17:37] <ricmm> doesnt help
[17:37] <ricmm> and thats generic enough, it would blow up in other cases
[17:37] <ricmm> this is a tegra-specific thing that has to do with the way we take the screenshot
[17:37] <ricmm> works for SF, not for us
[18:29] <racarr> microusb bit the dust
[18:29] <racarr> brb
[20:10] <kgunn> racarr: ping
[20:12] <kgunn> racarr: was just trying to run the egltriangle demo client per the instructions http://unity.ubuntu.com/mir/using_mir_on_pc.html
[20:12] <kgunn> racarr: but remembered we moved the mir socket...not sure how to now
[20:13] <kgunn> racarr: oops....nvmd....i just didn't sudo
[20:18] <racarr> kgunn: :)
[20:29] <kdub> what is up with jenkins? i noticed nothing was landing yesterday, but today, everything has landed from yesterday
[23:06] <xnox> it's been down, due to DC move.
[23:06] <xnox> not sure if it's fully up to speed yet.