[00:55] anyone from the mir team around still? [00:55] kgunn: ^ [00:55] quite a lot of packaging changes landed with the new mir [00:55] breaking the vivid touch build as we're depending on a package that got renamed [00:55] just trying to understand the changes [01:29] rsalveti: Hi [01:29] rsalveti: I think im the only one around so ill give a best effort [01:29] rsalveti: Wait RAOF is around and he made the changes [01:29] RAOF: ^ [01:29] err [01:30] he's not around [01:30] it seems the backend can be dynamically loaded now [01:30] rsalveti: He is hes just not in this channel I pinged him on mir [01:30] https://code.launchpad.net/~mir-team/mir/server-platform-probing/+merge/244982 [01:30] rsalveti: Sure. [01:30] rsalveti: Yes but thats basically what is it so [01:30] tmpRAOF: hey :-) [01:30] yes so the soname version isnt required anymore [01:30] racarr: You need to highlight tmpRAOF now, as freenode ate my RAOF registration :) [01:30] and the libraries got renamed [01:30] tmpRAOF: our vivid build is broken because it is still depending on the older packages [01:30] is the summary of my understanding [01:30] tmpRAOF: :) [01:31] - add_package install ubuntu-minimal mir-client-platform-android libmirplatform5driver-android ubuntu-touch [01:31] + add_package install ubuntu-minimal mir-client-platform-android mir-platform-graphics-android ubuntu-touch [01:31] I changed this [01:31] but we also had the update-alternatives for it [01:31] and it seems it's not required anymore [01:31] Correct. [01:31] tmpRAOF: how is mir finding out the backend to load now? [01:31] By loading them all and finding the one that works. [01:31] The only reason not to have mir-graphics-drivers [01:32] The only reason not to have mir-graphics-drivers-mesa on the touch images is you'll waste some disc space. [01:32] tmpRAOF: right, that's something I'll check on the next build, in case we get that package installed for whatever reason [01:32] tmpRAOF: but in case both are installed at the same time, how to select which one to use? [01:33] not sure if mesa will indeed fail on touch [01:33] It will. [01:33] great, will remove the update-alternatives and trigger a new build then [01:34] Unless it can *actually* work, in which case it's fine to use :) [01:34] lol [01:34] in which it turns out mesa worked on nexus devices this whole time [01:34] :-) [01:34] ;) [01:34] well, it might work with software rendering [01:34] not sure how is the current support though [01:35] No, our mesa platform doesn't support software rendering. [01:35] Also, you'd need a kms driver. [01:35] Mm I think we are covered...because of the modesetting bit [01:35] and then even if one did appear the platforms get "priorities" [01:35] (And once we *do* support software rendering, the mesa platform will only load with software rendering if there's nothing better; android will be better in that case) [01:36] and if an android driver is available (dont remember exactly how it works, but something like...can we load libhardware and open gralloc or whatever) [01:36] right, awesome then [01:36] then it gets priority "Best" [01:36] rsalveti: So, the only package you should need is mir-graphics-drivers-android (conversely, mir-graphics-drivers-mesa for desktop). [01:36] right, that's already in our seeds [01:37] racarr: That's correct - android probes by trying to open gralloc. [01:39] interestingly (not to this conversation, just to people interested generically in EGL implementations) mesa provides a DRI based implementation of gralloc [01:39] for running android on intel free drivers [01:39] kdub and I discovered it before hybris appeared as a driver solution and it took an hour or so of like...does this do what we need? Wait no this is [01:39] the exact opposite... [01:39] rsalveti: So, you should be able to drop mir-client-platform-android and keep just mir-graphics-drivers-android. We guarantee not to rename that one, and it'll always depend on a full set of packages required to get a fully functional Mir drivers on android. [01:39] it took me an hour or so maybe kdub understood because he knew gralloc lol [01:40] tmpRAOF: yeah, that's the change I did [01:40] will trigger a new image in a few and let you konw [01:41] Sweet. [02:36] Mhmmh... I've just updated the gdk-GL mir backend to match upstream changes... and well, with then now after few seconds I run the test-gl I'm getting a kernel panic on MIR! :o [02:40] gdk changes are basically: [02:40] https://bugzilla.gnome.org/show_bug.cgi?id=741946 plus the relative changes to the mir backend... [02:40] Gnome bug 741946 in Widget: GtkGLArea "OpenGL context should allow for GL attribute selection" [Normal,Resolved: fixed] [02:42] basically things have been moved to gl 3.2 APIs by default... But Not sure how I can help to fix this... I'd say it's mostly a driver issue.... [03:01] Trevinho: What requires GL 3.2? [03:01] duflu_: gdkgl === duflu_ is now known as duflu [03:02] That's unfortunate. We still have Ubuntu users limited to GL 1.x which I aim to support with Mir. It would be a pity if they just can't run GTK [03:02] duflu: they can run gtk, but not gtk-gl apps [03:03] Ah OK [03:03] duflu: they supported legacy gl till few days ago, then they removed that as it was overcomplicating stuff for them [03:03] Trevinho: P.S. Sleep [03:04] duflu: so basically now in gtk you can create a gl context inside your app and make it interact with the rest [03:04] Trevinho: I know. I've written toolkits with GLAreas :) [03:04] duflu: I was about to go, then I got a friendly ping :) [03:04] duflu: yeah, stuff like that... arrived just a little late... [03:05] I mean, instead of putting such the efforts in clutter, maybe.... [03:08] Trevinho: Yeah, kernel panics are very much Not Our Fault™ [03:08] yes, I was wondering that... [03:09] I've not them in X, but I guess it's due to the fact it's using a different driver [03:10] It's not really using a different driver. Unless you're using the nvidia binary drivers for X and nouveau for Mir (or fglrx/radeon) [03:10] mh, no I'm using radeon currently... But I thought it was using an egl driver at mesa level, isn't it? [03:11] Yeah; GTK doesn't use EGL on X as well? [03:12] glx [03:12] There certainly are differences in the uses, though. If you could capture the panic it might point to something we obviously do differently and possibly wrong. [03:12] Huh. Fair enough. [03:12] well, I currently I've no clue how to debug that kind of panic... 😢 [03:14] probably I need to ping someone with hands at lower levels than me :) [03:14] * Trevinho also can't build current mir without http://pastebin.ubuntu.com/10182012/ [03:14] Yeah, we've got some weirdness with our headers at the moment. [03:15] maybe it works with pre-compiled headers, but I guess I've disabled them [04:48] Get:335 http://ftpmaster.internal/ubuntu/ vivid/main mir-platform-graphics-mesa i386 0.11.0+15.04.20150209.1-0ubuntu1 [91.6 kB] [04:48] Get:336 http://ftpmaster.internal/ubuntu/ vivid/main mir-platform-graphics-android i386 0.11.0+15.04.20150209.1-0ubuntu1 [82.4 kB] [04:48] tmpRAOF: both were installed, will check the image in a few [04:48] not sure why we're still getting the mesa package === chihchun_afk is now known as chihchun [04:49] libmirserver29 depends on it [04:49] as it's |, it seems it will always get the first [04:50] even when my seeds is forcing the android one [05:02] rsalveti: Garh, sorry. [05:03] rsalveti: I fixed that for the client platform earlier, but at that point the server loading bit hadn't landed. [05:03] right [05:07] rsalveti: For what it's worth: https://code.launchpad.net/~mir-team/mir/server-doesnt-depend-on-drivers/+merge/249449 [05:09] tmpRAOF: great, thanks [06:03] Trevinho: I just tried out building Mir on trusty. There are lots of hacks required. More than you suggest. How/where are you building mir? [08:45] hey guys, could someone please have a look at bug #1417773 and see if the attached traces suggest a Mir thread blocked somewhere? [08:45] bug 1417773 in unity8 (Ubuntu RTM) "Unity8 completely frozen (unable to unlock, receive calls, etc)" [Undecided,New] https://launchpad.net/bugs/1417773 [09:49] * duflu looks at the bug [09:53] Saviq: Fun. Looks like some kind of deadlock in Mir's GlibMainLoop with Mir's framedropping logic [09:54] duflu, that sounds fun indeed [09:54] * duflu shies away from owning problems he violently tried to stop from us having [09:54] Also it's time to make dinner [09:55] from us? us from. [09:57] Saviq: I know we did try to decide both ends of that deadlock so that deadlocks can't happen. But sounds like we're not there yet [09:58] Saviq: RTM running Mir 0.10? That sounds odd given https://launchpad.net/ubuntu-rtm/+source/mir [09:59] Oh, also a stack from 0.11 [09:59] duflu, my gdb output was from vivid indeed [10:00] Saviq: Was the actual deadlock on vivid? [10:00] duflu, yes, my gdb output was from vivid 0.10 and 0.11 today [10:00] I don't think that analysis is correct? [10:00] It looks more like RPC failure? [10:00] duflu, might be I misattributed the lock incorrectly [10:00] Saviq: OK, that needs clarification. Deadlocked on Mir 0.8 but retraced using Mir 0.10/11 symbols? [10:01] (Note one of the threads has blocked in recvmsg) [10:01] duflu, no no [10:01] duflu, the original bug was from rtm [10:01] duflu, and rsalveti's trace should be from there [10:01] duflu, my deadlocks were both on vivid, and retraced then and there, while the device was deadlocked [10:02] Saviq: rsalveti's looks quite different (dbus deadlock instead) [10:02] Do we have two bugs in one? [10:02] duflu, very much possible [10:03] duflu, there was a bunch of random lockups reported [10:04] Saviq: That's a huge can of worms. Time to make dinner [10:04] duflu, enjoy [10:06] Saviq: Did you break and then continue in this backtrace? [10:06] tmpRAOF, I just attached gdb and got the trace there, didn't continue [10:07] Saviq: So, the fact that it was blocked in recvmsg suggests that something in the RPC stack was being bogus, and the deadlock was U8 waiting for some RPC to finish. [10:08] tmpRAOF, if you have any pointers as to what else should I check (continue + break) the next time I see that, please comment on the bug [10:08] Saviq: It might be helpful to work out what unity-system-compositor is doing when this happens. === chihchun is now known as chihchun_afk === dandrader_ is now known as dandrader === alan_g is now known as alan_g|lunch === alan_g|lunch is now known as alan_g === snadg3 is now known as snadge === dandrader is now known as dandrader|lunch [16:32] AlbertA: hey, I've got QtCreator working reasonably well using this patch on top of your use-mir-surface-types: http://pastebin.ubuntu.com/10190374/ [16:33] thought I should share the changes I've made, in case it helps [16:34] greyback_: cool...I've changed the branch a bit too.... [16:34] :) [16:34] AlbertA: ack, will pull and see [16:41] AlbertA: moveResize deletes & re-creates the mir surface?! Cheeky ;) [16:42] greyback_: works for menus lol [16:48] in which we become what we once hated :( [16:48] :p [16:54] :) [16:57] racarr: that's why we are going to support client resize :) it's good for the mir team to feel the pain :) === dandrader|lunch is now known as dandrader === alan_g is now known as alan_g|EOD === sturmflut_ is now known as sturmflut [20:49] yeah no other way :P [20:49] soon you'll find you want to support client hit testing for cursors too [20:50] and then realize you want to give sub windows a cursor to make it feel more responsive [21:19] Hello is there anyone who can help with: tiny.cc/i8lytx (porting ubuntu touch)