| RAOF | Oh, *that's* what valgrind is complaining about! | 00:48 |
|---|---|---|
| === chihchun_afk is now known as chihchun | ||
| mickgardner | I have a couple of questions with regards to Mir if anyone is able to answer (more high level than code level...): | 03:28 |
| 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:29 |
| 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:30 |
| 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:31 |
| duflu | ... and in theory it accepts all input devices simultaneously | 03:32 |
| 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:33 |
| 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:34 |
| 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:35 |
| 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:36 |
| 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:37 |
| RAOF | OSKs are. | 03:38 |
| duflu | RAOF: Oh, oops. Yes, still true for OSK | 03:38 |
| === 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 | ||
| 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:52 |
| 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:57 |
| alan_g | alf_: can you check this MP? ^ | 14:59 |
| alf_ | alan_g: looking | 15:00 |
| didrocks1 | grrr connexion… | 15:09 |
| 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:10 |
| alan_g | didrocks: thanks | 15:11 |
| === didrocks1 is now known as didrocks | ||
| alan_g | didrocks: (repeated in case you missed it) thanks | 15:13 |
| alan_g | ;) | 15:13 |
| didrocks | yw! ;) | 15:13 |
| alf_ | alan_g: ok, validated fix locally | 15:31 |
| alan_g | alf_: thanks - if you approve then I'll merge into v0.1.1 | 15:32 |
| alf_ | alan_g: ok, top approved | 15:32 |
| racarr | Morning | 16:03 |
| === greyback is now known as greyback|away | ||
| === dandrader|lunch is now known as dandrader | ||
| === greyback|away is now known as greyback | ||
| tvoss_ | kdub_, ping | 17:29 |
| kdub_ | pong | 17:29 |
| 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:41 |
| 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:42 |
| * 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:43 |
| mterry | so it shouldn't cause a problem with trusy unity-mir | 18:44 |
| * mterry has to run | 18:44 | |
| greyback | ok | 18:44 |
| * dandrader reads the backlog | 18:47 | |
| dandrader | mterry, greyback, hmm, I don't think the edge gesture code itself has anything to do with the crash... | 18:51 |
| greyback | mterry: I guess a backtrace would help | 18:52 |
| racarr | lunch | 19:35 |
| racarr | Back | 20:16 |
| mterry | back, want to test something first, then will try for a backtrace | 20:24 |
| 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:41 |
| 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:43 |
| mterry | kgunn, performance numbers seem fine so far (was waiting on autopilot fix to get in-use numbers) | 20:44 |
| kgunn | mterry: "seem" = eyeball ?? (still a good sign even if so) | 20:46 |
| mterry | kgunn, no, using 'time' to time autopilot runs | 20:46 |
| 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:47 |
| 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:48 |
| mterry | kgunn, only seen on nested so far | 20:49 |
| mterry | kgunn, so many yaks! | 20:49 |
| kgunn | mmmm, i'll leave you be to debug mterry | 20:50 |
| 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:51 |
| 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:53 |
| 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:54 |
| kdub_ | the bugreport has one though | 20:55 |
| kgunn | ah... yeah saw that one...sorry, just misread ur mail....still...great work | 20:58 |
| kdub_ | mterry, make sure a context is active before trying to bind the buffer | 20:59 |
| mterry | kdub_, only difference I'm doing is nested vs standalone. Why might a context not be active? | 21:01 |
| mterry | How is a context normally set active? | 21:02 |
| kdub_ | eglMakeCurrent() | 21:02 |
| 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:03 |
| 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:04 |
| kdub_ | but it sounds to me like we're missing a call to eglMakeCurrent somewhere | 21:05 |
| 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:06 |
| 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:49 |
| mterry | kdub_, presumably the host server is managing those bits? | 21:50 |
| * mterry adds the displayreport bit to u-s-sc | 21:50 | |
| 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:51 |
| 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:53 |
| mterry | kdub_, yup, u-s-c shows all the normal graphics output from the report | 21:54 |
| mterry | as we'd expect | 21:54 |
| kdub_ | http://bazaar.launchpad.net/~mir-team/mir/trusty/view/head:/src/server/graphics/nested/nested_display.cpp#L280 | 21:55 |
| 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:56 |
| mterry | kdub_, you're saying you think that line is being called, but with the wrong EGL flags? | 21:57 |
| kdub_ | mterry, in http://bazaar.launchpad.net/~mir-team/mir/trusty/view/head:/src/server/graphics/android/android_display.cpp#L79 | 21:58 |
| 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:00 |
| kdub_ | we should check that returns EGL_TRUE | 22:01 |
| mterry | kdub_, hrm. OK. I can compile and test what that returns. What was the bit about EGL_KHR_surfaceless_context ? | 22:06 |
| 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:07 |
| mterry | kdub_, yup, it's returning EGL_FALSE. OK, will try with a dummy pbuffer surface | 22:19 |
| * mterry looks at how host display does it | 22:20 | |
| mterry | kdub_, thanks for the help, btw! | 22:20 |
| kdub_ | mterry, no problem | 22:23 |
| 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:26 |
| kdub_ | mterry, exactly :) | 22:27 |
| mterry | kdub_, both of these calls, NO_SURFACE or dummy, seem like they aren't intended to work. Are these just fallback settings? | 22:28 |
| 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:29 |
| RAOF | Every compiler we care about is happy to provide C99 designated initialisers. | 22:30 |
| kdub_ | RAOF, those would be nice, but i think pedantic is useful overall | 22:32 |
| 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:33 | |
| kdub_ | not sure | 22:35 |
| 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:37 |
| mterry | kdub_, BAM, no crash. You're the best | 22:41 |
| mterry | kdub_, will propose a branch | 22:41 |
| kdub_ | mterry, yay \o/ | 22:41 |
| mterry | kdub_, https://code.launchpad.net/~mterry/mir/fix-nested-crash/+merge/195320 | 22:50 |
| RAOF | mterry: Hey, was that crash happening on the desktop or on android? | 22:58 |
| kdub_ | racarr, do you know the magic build combo for the day (with unity mir?) | 23:00 |
| 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:02 |
| 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:03 |
| 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. | 23:05 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!