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