[00:20] <kgunn> kdub: ping
[00:21] <kdub> kgunn, pong
[00:22] <kgunn> kdub: hey, thanks for the hoop jumping on that crasher and working with alan_g
[00:23] <kdub> oh, sure, was just some shepherding a patch along :)
[00:24] <kdub> got me all updated to trusty too
[01:26] <omega9_> hello, I am interested in contributing to Mir and was wondering if there were mentored tasks that I could do to get started?
[01:34] <duflu_> omega9_: Welcome. I would suggest learning to build the code (from bzr lp:~mir-team/mir/development-branch) and looking at the docs in there (which are also on the web: http://unity.ubuntu.com/mir/)
[01:35] <duflu_> Once you can build, the immediate tasks are the bugs logged against the Mir project in Launcpad
[01:36] <omega9_> duflu_, are there tasks that are specifically flagged as beginner?
[01:36] <duflu_> omega9_: Not yet, sorry. It's more a matter of let contributors do whatever excites them, because that gets the ball rolling
[01:37] <omega9_> OK, thank you.
[08:07] <alf_> duflu: I retriggered fix-1246590
[08:07] <duflu> alf_, Thanks but probably not necessary
[08:36] <Xobs> I'd like to get an accelerated windowing system on my i.MX6-based board.  The vendor has Android support.  Is there a guide for extracting Android drivers from a BSP and using them in Linux?
[08:38] <Xobs> Basically: Given an Ubuntu armhf install, what do I need to add to get accelerated Mir?
[08:52] <duflu> Xobs: Mir will try to use the Android driver directly via libhybris. Though the Mir code often needs modification before new platforms work. So I suggest starting with doing an armhf build, running mir_demo_server_* and seeing what works/fails. Instructions are: http://unity.ubuntu.com/mir/
[08:54] <duflu> Xobs: Although that assumes you've got an Ubuntu image booting at all. So maybe start with: https://wiki.ubuntu.com/Touch/Porting
[08:55] <Xobs> duflu: What do I need to pull out of the Android BSP?  Or do I just need to copy the Android RFS somewhere on the Ubuntu RFS?
[08:55] <Xobs> duflu: I've gotten it booting in the past by using debootstrap.  At least, stock Ubuntu.
[08:55] <duflu> Xobs: Cool. Then follow the Mir build instructions and see if you can start one of the demo servers... or see where they fail
[08:56] <duflu> Xobs: I'm not sure what you need to pull out and where. It's likely in the porting guide (https://wiki.ubuntu.com/Touch/Porting)
[08:56] <Xobs> duflu: Thanks, I'll start working on that.
[08:57] <Xobs> duflu: One followup question: How do GL-accelerated apps work?  Do all Mir-accelerated programs require GLES, or do they use Mesa for libGL?
[08:57] <Xobs> duflu: The vendor only provides GLES binaries, not GL.  So what happens if e.g. I run something like Quake, that is written for full GL?
[08:57] <duflu> Xobs: It's always GLES right now. On desktop that's Mesa. On Android that's the native GL library via libhybris
[08:58] <Xobs> duflu: Fascinating.  So if (when?) Chrome or Firefox are ported, they'll automatically use Mir's GLES for WebGL?
[08:58] <duflu> Xobs: Mir is GLES only right now. So no problem. The only exception is on desktop you can run GLX apps over XMir. But the server is still GLES
[08:59] <Xobs> duflu: That is the best news.
[08:59] <duflu> Xobs: Something always goes wrong in porting, so it's always feasible, but never guaranteed to work
[09:00] <duflu> Xobs: XMir only supports desktop hardware though (intel/nouveau/radeon)
[09:00] <duflu> ... so far
[09:01] <Xobs> duflu: Right now, I'd just like to get compositing working first.  Dragging windows around on a 2560x1700 screen is a bit slow on this platform right now.
[09:02] <duflu> Xobs: On most ARM systems, it will still be slow even when ported at that resolution. You're likely to hit fill rate limitations even if done perfectly
[09:02] <Xobs> duflu: I had Wayland working (kinda), but not well at all.  I think Mir might be a better way to go.
[09:02] <Xobs> duflu: Wayland was running at 10fps or so.  glesmark2 was running at 40-50fps.
[09:03] <duflu> Xobs: It's hard to get a real answer of the physical frame rate though. Other than using your eyes. If you have desktop Ubuntu you can install the Benchmark compiz plugin from package "compiz-plugins" to find out the physical frame rate
[09:05] <Xobs> duflu: The vendor's Xorg drivers don't support AIGLX, meaning compositing is done with Mesa.  But given stability problems I've seen with Debian and the possibilities of Mir, I'm thinking more and more of getting Ubuntu running instead.
[09:06] <duflu> Xobs: Any idea what the fill rate specs are for that GPU?
[09:10] <Xobs> duflu: Still looking in the manual, but one site says the GC2000 does 1.066 Gpix/s
[09:13] <duflu> Xobs: So that's roughly 244FPS theoretical maximum at 2560x1700
[09:17] <Xobs> duflu: Yes, finally found the page in the manual.  1.066Gpix/s, 88M tri/s.  I think that Mir is the way to go to get good windowing performance.
[09:19] <duflu> Xobs: Sure. Only thing is Mir doesn't yet have a usable native desktop. We're working on that.
[09:19] <Xobs> duflu: I thought Ubuntu Phone used Mir?  Or is that Unity running under XMir?
[09:24] <duflu> Xobs: Yeah that's native, but I meant desktop. That's a touch OS
[09:26] <Xobs> duflu: Alright.  I'll give the porting guides a read, and fix errors as they crop up.
[09:38] <duflu> greyback: Somehow I've run out of time to review your doc today. I trust it's no disaster if it's not this week? (though it might be)
[09:38] <greyback> duflu: it's not a disaster, but I'd definitely like your input. Monday better?
[09:39] <duflu> greyback: I will be aiming for tomorrow anyway
[09:40] <greyback> duflu: ok
[18:02] <alan_g> kdub: I'm at EOD, but found an interesting problem - https://jenkins.qa.ubuntu.com/job/mir-android-trusty-i386-build/73/console  runs the tools/setup-partial-armhf-chroot.sh. And liblttng-ust0 doesn't exist ... looks like liblttng-ust2 is right. (From chant on #ubuntu-ci-eng)
[18:03] <alan_g> It's causing merges to fail
[18:03] <kdub> alan_g, ah, could MP a bump easily enough
[18:05] <cyphermox> kdub: could you give me a few minutes to look at the script and come up with a better solution?
[18:05] <alan_g> cyphermox: talk to kdub about the script ^
[18:05] <cyphermox> ahha ;)
[18:06] <cyphermox> kdub: can that script be deleted or is that used for something critical?
[18:09] <kdub> cyphermox, its mainly used in a development workcycle at the moment
[18:09] <kdub> cyphermox, so it can be deleted from the mir tree, we'll probably want to keep it around as a tool for mir devs though
[18:10] <kdub> cyphermox, if there's a better solution though, that would be great
[18:10] <cyphermox> well, if it's used manually it should still be updated to use the right libraries
[18:10] <cyphermox> but I guess the CI magic shouldn't be using it
[19:11] <cyphermox> kdub: has that script actually worked in the recent past?
[19:11] <cyphermox> seems to me like libboost is maybe broken and not so downloadable in this fashion
[19:11] <kdub> cyphermox, should work now
[19:12] <cyphermox> ok
[19:12] <cyphermox> then maybe it's my changes...
[19:12] <cyphermox> would you be able to test them? I put stuff over there: lp:~mathieu-tl/+junk/test-cross-compile
[19:12] <kdub> looking..
[19:12] <cyphermox> in the meantime I'll just do a MP for the quick bump to liblttng-ust2, but the changes I'm testing should help avoid having to change the script every time there is a library transition
[19:13] <kdub> cyphermox, sounds great
[19:17] <cyphermox> kdub: https://code.launchpad.net/~mathieu-tl/mir/armhf-chroot-script-fixes/+merge/193480
[19:18] <kdub>  +1ed, thanks
[23:46] <kgunn> kdub: or racarr ... can either of you  review...easy one https://code.launchpad.net/~mir-team/mir/bump-mirserver-to-10/+merge/193515
[23:47] <kgunn> quick note on it, i saw duflu had already bumped the debian version (for the abi)
[23:47] <kgunn> but alan_g told me earlier we have a true api break with unity-mir as well
[23:47] <kgunn> hence this mp