[00:48] <RAOF> Oh, *that's* what valgrind is complaining about!
[03:28] <mickgardner> I have a couple of questions with regards to Mir if anyone is able to answer (more high level than code level...):
[03:29] <duflu> mickgardner: Yes, the Australian shift is online at least :)
[03:29] <mickgardner> 1. When is Mir currently scheduled to be released as stable into PC land? (or is it already?)
[03:29] <mickgardner> :-) Melbourne here...
[03:29] <RAOF> Depends on what you mean, really.
[03:30] <RAOF> We've had a number of releases :)
[03:30] <duflu> mickgardner: Mir technically released for real in Ubuntu 13.10. The packages are not installed by default though. "Stable" is something we're always improving
[03:30] <RAOF> Probably what you mean, though, is ‘when will I be able to use Unity8 on the desktop’
[03:30] <mickgardner> okay then lets ask number 2 and get back to 1. duflu...thats fine.
[03:30] <mickgardner> 2. I'm developing a multi-seat, multi-touch table based on Linux.
[03:30] <RAOF> To which the answer is “should be soon” - AFAIK the current plan is Unity8 as an opt-in for 14.04.
[03:31] <mickgardner> I want to be able to have multiple inputs
[03:31] <mickgardner> on the screen at the same time.
[03:31] <mickgardner> apologies if this if vague...
[03:31] <duflu> mickgardner: Mir's multi-touch is working well right now. Although it's only well-tested on the phone/tablet
[03:31] <RAOF> You mean something like multi-pointer X?
[03:31] <mickgardner> yes basically.
[03:32] <duflu> ... and in theory it accepts all input devices simultaneously
[03:33] <mickgardner> I guess the main use case here is:  Two browser windows open, each person typing in something to their browser window at the same time (using some sort of on screen keyboard).
[03:33] <RAOF> I don't believe that anything in Mir prohibits that.
[03:33] <RAOF> Hm, actually, maybe it does.
[03:34] <duflu> mickgardner: The code is there already to handle multiple pointers at once. What's missing is (1) multiple cursors drawn on screen and (2) multiple simultaneous focuses
[03:34] <RAOF> And it'd need a shell that supported those features, too.
[03:35] <duflu> Actually (1) isn't missing if you just mean touch :)
[03:35] <duflu> and (2) is probably irrelevant if you just mean touch.
[03:36] <duflu> I think drag-to-scroll would become very confused in the multi-user case. That would need some work
[03:36] <duflu> Maybe...?
[03:37] <mickgardner> Thanks guys!
[03:37] <mickgardner> sorry, multi-tasking here...
[03:37] <RAOF> Multiple keyboard foci *is* something that'd need support.
[03:37] <duflu> mickgardner: No problem
[03:37] <duflu> RAOF: Sounds like keyboards are not involved anyway
[03:38] <RAOF> OSKs are.
[03:38] <duflu> RAOF: Oh, oops. Yes, still true for OSK
[14:52] <alan_g> didrocks: I'm not sure I understand the current process for updating lp:mir so I'm asking what I hope is a simple question. There's a change needed to avoid lp:~mir-team/mir/v0.1.1 breaking lp:unity-mir can we just merge that into the proposed branch and re-top-approve, or is there anything else needed?  https://code.launchpad.net/~alan-griffiths/mir/urgent-fix-unity-mir-build/+merge/195232
[14:57] <alan_g> didrocks: (repeated in case you missed it) I'm not sure I understand the current process for updating lp:mir so I'm asking what I hope is a simple question. There's a change needed to avoid lp:~mir-team/mir/v0.1.1 breaking lp:unity-mir can we just merge that into the proposed branch and re-top-approve, or is there anything else needed?  https://code.launchpad.net/~alan-griffiths/mir/urgent-fix-unity-mir-build/+merge/195232
[14:59] <alan_g> alf_: can you check this MP?  ^
[15:00] <alf_> alan_g: looking
[15:09] <didrocks1> grrr connexion…
[15:10] <didrocks1> 16:07:33  didrocks | alan_g: just ensure all branches with MP set to approved are coherent
[15:10] <didrocks1> 16:07:46  didrocks | meaning if there is an ABI break, everything has version bumped and so on
[15:10] <didrocks1> 16:07:53  didrocks | once the CI will be back, things will get merged again
[15:11] <alan_g> didrocks: thanks
[15:13] <alan_g> didrocks: (repeated in case you missed it) thanks
[15:13] <alan_g> ;)
[15:13] <didrocks> yw! ;)
[15:31] <alf_> alan_g: ok, validated fix locally
[15:32] <alan_g> alf_: thanks - if you approve then I'll merge into v0.1.1
[15:32] <alf_> alan_g: ok, top approved
[16:03] <racarr> Morning
[17:29] <tvoss_> kdub_, ping
[17:29] <kdub_> pong
[18:41] <mterry> greyback, hello!  I have to run out for a little errand, but I wanted to ask you a question that I've started looking at.  It seems that in nested mode, I'm seeing crashes in unity8 when using right-swipe or left-swipe *only* when an app is focused.  Does that make any sense?
[18:41] <mterry> I can answer questions or read feedback in a bit.  Just wanted to start your brain thinking
[18:42] <greyback> mterry: nothing obvious comes to mind. dandrader would be a better person to ask about this
[18:42] <mterry> greyback, ah OK.  dandrader ^ then  :)
[18:42] <kdub_> mterry, greyback i know the focus mechanism has changed a bit, maybe needs a recompile or something?
[18:42] <greyback> he understands the edge swipe detection code. It's black magic as far as I'm concerned :)
[18:42] <greyback> kdub_: good point. mterry, did you recompile unity-mir
[18:43]  * greyback recalls unity-mir fails to compile against mir10
[18:43] <mterry> kdub_, greyback, I'm running mir-in-trusty recompiled for extra debugging
[18:44] <mterry> so it shouldn't cause a problem with trusy unity-mir
[18:44]  * mterry has to run
[18:44] <greyback> ok
[18:47]  * dandrader reads the backlog
[18:51] <dandrader> mterry, greyback, hmm, I don't think the edge gesture code itself has anything to do with the crash...
[18:52] <greyback> mterry: I guess a backtrace would help
[19:35] <racarr> lunch
[20:16] <racarr> Back
[20:24] <mterry> back, want to test something first, then will try for a backtrace
[20:41] <kgunn> kdub_: nice work on n7
[20:41] <kgunn> mterry: hey...just been a few days...any luck on unity/mir-on-mir ?
[20:41] <kdub_> thanks kgunn!
[20:43] <mterry> kgunn, a little bit.  I figured the problem with autopilot not working at all.  Now I'm seeing a crash when you've got an app open, but you swipe the launcher in or swipe from the right...
[20:43] <mterry> kgunn, working on getting a trace
[20:43] <mterry> racarr, speaking of nested mir, did you get a chance to look at the u-s-c branches?
[20:44] <mterry> kgunn, performance numbers seem fine so far (was waiting on autopilot fix to get in-use numbers)
[20:46] <kgunn> mterry: "seem" = eyeball ?? (still a good sign even if so)
[20:46] <mterry> kgunn, no, using 'time' to time autopilot runs
[20:47] <mterry> kgunn, I'll add the numbers to the merge request, but first these crashes are stopping me from running the unity8 tests to completion  :-/
[20:47] <mterry> Also, they are crashes which are bad in their own right.  :)
[20:48] <kgunn> uh-oh mterry ...you mean just crashes due to unity?
[20:48] <mterry> kgunn, not sure why yet.  But the unity8 process crashes, yeha
[20:49] <mterry> kgunn, only seen on nested so far
[20:49] <mterry> kgunn, so many yaks!
[20:50] <kgunn> mmmm, i'll leave you be to debug mterry
[20:51] <mterry> kgunn, sorry it's taking so long, but progress is being made, albeit slowly
[20:51] <kgunn> hey...as long as you guys are on it...i got faith
[20:53] <mterry> kdub_, greyback, racarr: hey Mir folks.  the crash I'm seeing with nested Mir and swiping from right is a thrown "cannot bind buffer to texture without EGL context".  Ring any bells or do you want full core?
[20:54] <kgunn> alf_: ^ just in case no answer
[20:54] <kdub_> eglGetCurrentDisplay is failing in mga::Buffer::bind_to_texture
[20:54] <kgunn> kdub_: at about what time in your video is the crash from glreadpixels ?
[20:54] <kdub_> that video does not have the crash
[20:55] <kdub_> the bugreport has one though
[20:58] <kgunn> ah... yeah saw that one...sorry, just misread ur mail....still...great work
[20:59] <kdub_> mterry, make sure a context is active before trying to bind the buffer
[21:01] <mterry> kdub_, only difference I'm doing is nested vs standalone.  Why might a context not be active?
[21:02] <mterry> How is a context normally set active?
[21:02] <kdub_> eglMakeCurrent()
[21:03] <kdub_> mterry, are you doing development, or just debugging a crash that autopilot brought out?
[21:03] <mterry> kdub_, guh, this looks like some 'fun' tracing of both nested and standalone and seeing where the fork is
[21:03] <mterry> kdub_, the latter
[21:03] <mterry> kdub_, this isn't even autopilot related
[21:03] <mterry> kdub_, this is just when running nested
[21:03] <mterry> (but autopilot hits it)
[21:04] <mterry> kdub_, which of the various report modes do you recommend to debug egl?
[21:04] <kdub_>  --display-report log will print out some information
[21:05] <kdub_> but it sounds to me like we're missing a call to eglMakeCurrent somewhere
[21:06] <kdub_> mterry, is the host or the nested server complaining?
[21:06] <mterry> sure...  those look sprinkled throughout the code though
[21:06] <mterry> kdub_, nested server (unity8)
[21:49] <mterry> kdub_, hmm..  Will retest to make sure, but in nested mode, I don't get any output from the --display-report=log bits.  But in standalone I do get a chunk of them at the beginning
[21:50] <mterry> kdub_, presumably the host server is managing those bits?
[21:50]  * mterry adds the displayreport bit to u-s-sc
[21:51] <kdub_> mterry, i know the host server display class has the logging implemented, not so sure about the nested server display class
[21:51] <mterry> kdub_, ah interesting.  So there might be relevant code there, it might just not be logging it
[21:53] <kdub_> mterry, it looks like... the display report is in the constructor of mgn::NestedDisplay, but the functions just aren't called
[21:53] <kdub_> what concerns me is... (looking up line)
[21:54] <mterry> kdub_, yup, u-s-c shows all the normal graphics output from the report
[21:54] <mterry> as we'd expect
[21:55] <kdub_> http://bazaar.launchpad.net/~mir-team/mir/trusty/view/head:/src/server/graphics/nested/nested_display.cpp#L280
[21:56] <kdub_> i think you need the egl extension EGL_KHR_surfaceless_context
[21:56] <kdub_> to do that... not sure if n4 has that extension
[21:57] <mterry> kdub_, you're saying you think that line is being called, but with the wrong EGL flags?
[21:58] <kdub_> mterry, in http://bazaar.launchpad.net/~mir-team/mir/trusty/view/head:/src/server/graphics/android/android_display.cpp#L79
[22:00] <kdub_> mterry, i'm suggesting that
[22:00] <kdub_> http://bazaar.launchpad.net/~mir-team/mir/trusty/view/head:/src/server/graphics/nested/nested_display.cpp#L280
[22:00] <kdub_> fails silently
[22:01] <kdub_> we should check that returns EGL_TRUE
[22:06] <mterry> kdub_, hrm.  OK.  I can compile and test what that returns.  What was the bit about EGL_KHR_surfaceless_context ?
[22:07] <kdub_> mterry, if that fails silently, we can just make a dummy pbuffer surface for the nested display's context
[22:07] <kdub_> much like the host display class does
[22:19] <mterry> kdub_, yup, it's returning EGL_FALSE.  OK, will try with a dummy pbuffer surface
[22:20]  * mterry looks at how host display does it
[22:20] <mterry> kdub_, thanks for the help, btw!
[22:23] <kdub_> mterry, no problem
[22:26] <mterry> kdub_, so you're suggesting that NestedGLContext should create a pbuffer surface and always try to use that instead of EGL_NO_SURFACE, right?  (sorry if being a bit obtuse, but GL is relatively new to me)
[22:27] <kdub_> mterry, exactly :)
[22:28] <mterry> kdub_, both of these calls, NO_SURFACE or dummy, seem like they aren't intended to work.  Are these just fallback settings?
[22:29] <RAOF> Grr.
[22:29] <RAOF> Do we really need -pedantic?
[22:29] <kdub_> they're not fallback settings, we just want an context that has been shared with the display without a surface behind it
[22:30] <RAOF> Every compiler we care about is happy to provide C99 designated initialisers.
[22:32] <kdub_> RAOF, those would be nice, but i think pedantic is useful overall
[22:33] <kdub_> if its really useful :) we could push a pragma for a file
[22:33] <kdub_> i've wanted to do that for hwc in the past
[22:33] <RAOF> What does pedantic catch that our other -Werrors don't?
[22:33]  * RAOF is genuinely interested.
[22:35] <kdub_> not sure
[22:37] <RAOF> I don't believe (from the gcc manpage description) that it catches any *coding* errors. It explicitly *doesn't* guarantee that code that builds with -pedantic will build on any ISO C-compliant compiler, and having the clang build covers both of the compilers that we're reasonably likely to want to build with anyway.
[22:41] <mterry> kdub_, BAM, no crash.  You're the best
[22:41] <mterry> kdub_, will propose a branch
[22:41] <kdub_> mterry, yay \o/
[22:50] <mterry> kdub_, https://code.launchpad.net/~mterry/mir/fix-nested-crash/+merge/195320
[22:58] <RAOF> mterry: Hey, was that crash happening on the desktop or on android?
[23:00] <kdub_> racarr, do you know the magic build combo for the day (with unity mir?)
[23:02] <mterry> RAOF, android
[23:02] <RAOF> Ah, that'd be why.
[23:02] <mterry> RAOF, didn't try desktop
[23:02] <RAOF> It'd work on desktop.
[23:02] <RAOF> kdub_: Do you think we should gate that codepath on the presence of EGL_KHR_surfaceless_context?
[23:03] <kdub_> RAOF, alf_ has done some work with that
[23:03] <kdub_> https://code.launchpad.net/~afrantzis/mir/offscreen-display/+merge/194906
[23:03] <kdub_> about line 1094
[23:03] <kdub_> we have many places of mg::GLContext in the code... should be shared
[23:05] <kdub_> alf_ has a new GLContext for the offscreen display... and i have a branch that condenses the 3 different android mg::GLContexts into one
[23:05] <kdub_> so after that, i think we should go and mop all of them up
[23:05] <RAOF> Sounds reasonable.