[08:32] <zzarr> hello anpok
[08:33] <anpok> hi
[08:33] <zzarr> anpok, here are the ump libs http://malideveloper.arm.com/resources/drivers/open-source-mali-gpus-ump-user-space-drivers-source-code-2/
[08:34] <zzarr> (or lib/code)
[08:36] <zzarr> anpok, are there sufficient code to write a Mir driver?
[08:38] <zzarr> anpok, other whys it looks like it's possible to use the android driver (I think that the kernel driver may be the same for both X and Android drivers, if I haven't misunderstood )
[11:32] <anpok> yes kernel side is the same, I did look into UMP User Space Drivers r4p0-00rel1
[11:32] <anpok> and there was no mentioning on how to get egl/glesv2 to render to an ump handle
[11:32] <anpok> zzar: that would be the problem to be solves
[11:32] <anpok> *solved
[11:33] <anpok> the other stuff is helpful.. as it tells you how to transfer handles been processes which is an important piece
[11:33] <anpok> s/been/between
[11:33] <anpok> they might have an extension to setup egl with that.. i dont now.. an alternative native window handle.. maybe
[12:42] <zzarr> anpok, as I'm still new to GPU drivers, I think that the android driver is the easiest way for me
[12:43] <zzarr> anpok, is there a tutorial how to install and configure the android lxc?
[12:44] <alan_g> kgunn: I'm going through the bugs targeting 0.20 and came across bug 1528384 - what is the latest status of that? Is it fixed in 0,19,2?
[12:44] <ubot5`> bug 1528384 in Unity System Compositor "unity-system-compositor crashed with std::runtime_error in mir::compositor::CompositingFunctor::wait_until_started() from usc::MirScreen::set_screen_power_mode (mir_power_mode_on)" [Critical,In progress] https://launchpad.net/bugs/1528384
[12:44] <anpok> zzarr: look for ubunte touch porting guide.. and ask in #ubuntu-touch .. e.g. people like ogra_  or morph or ...
[12:44] <anpok> *ubuntu
[12:44]  * kgunn checks
[12:45] <zzarr> I have asked in #ubuntu-touch
[12:47] <ogra_> well, rather ondra and morphis :) ... i'm not very familiar with the GPU driver setup on the android side
[12:48] <zzarr> okey ogra_, well, I'll read the text on the internet before asking
[12:48] <zzarr> if I get stuck I'll ask
[12:49] <kgunn> alan_g: ah yeah, that landed...the reporting....and AlbertA_ has branches up for 19.2 for that nasty bug
[12:49] <kgunn> alan_g: so we're going on the hope that there's not a seperate subtle bug lurking there
[12:50] <kgunn> for the case of 0.20 you can consider it ok
[12:50] <kgunn> done
[12:51]  * alan_g wonders how to convince LP it was committed in 0.19.2
[17:10] <alan_g> alf_: You have a USC release in the pipe? (I was about create a "no-change" release for Mir-0.20.0, but does this impact?)
[17:52] <alan_g> greyback__: Saviq - in doing a Mir release do I need to do anything for qtmir-gles? (Saviq left a note that one of the steps isn't needed, but there are other I suspect it applies to.)
[17:53] <greyback__> alan_g: usually, if you're not incrementing the qtmir version number, just proposing an empty MP against lp:qtmir/gles , and adding to train, is enough
[17:53] <Saviq> alan_g, nothing in changelog needed, but you should bump the dep in debian/control
[17:54] <Saviq> alan_g, basically, anything you change in debian/ for the non-gles MP, should be changed in the -gles one
[17:54] <Saviq> it's no longer necessary to mangle debian/changelog or debian/watch
[17:55] <alan_g> OK, so as (in this case) I've just an empty MP for qtmir that covers it.
[17:56] <alan_g> Or, I need an empty one for lp:qtmir/gles too?