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