#ubuntu-mir 2013-09-16
<kgunn> didrocks: can we make an attempt at libmirclient3 again ? we will need this for dpms
<didrocks> kgunn: we'll deliver first current Mir
<didrocks> kgunn: I ask Mirv to do it for tomorrow
<didrocks> then, we can merge your transition, but your team has to handle it
<kgunn> didrocks: so, handle it means...we send anounce on ubuntu-devel, we ping you (or someone like you), we place it on the ask sheet
<kgunn> didrocks:  is there anything else ?
<kgunn> racarr: ^
<didrocks> kgunn: and you ask your team to promptly upload the driver parts
<didrocks> as you break ABI, everything that deps on libmirclient has to be rebuilt
<kgunn> didrocks: yes...xmir dependency
<didrocks> and some parts are not under CI
<kgunn> RAOF: ^
<didrocks> so your team needs to upload that promptly to the ppa to not block everything
<didrocks> hence the "we need to coordinate"
<RAOF> Yup
<smspillaz> hmm
<smspillaz> how does one get the boost libs to appear in /usr/lib like the mir makefiles seem to expect
<smspillaz> they're installed in the arch-prefixed directories
<smspillaz> (symlinking doesnt count)
<kgunn> Mirv: hey was going to ask didrocks...but someone was noticing there is no saucy proposed (i haven't checked this)
<kgunn> Mirv: we were discussing the "ask" process...i indicated, trunk will still go to proposed
<kgunn> but won't be promoted to archive until its been approved via the ask process
<kgunn> sil2100: ^ can you see what i was saying to Mirv .... he might be mising in action
<kgunn> sil2100: there should be proposed with latest trunk from Mir right ?
<sil2100> kgunn: I think he's long gone, since he's EOD since 3 hours already
<sil2100> But looking
<sil2100> hmmm, no, I don't think it's like that
<sil2100> We're running releases of stacks manually now, so even daily-build doesn't have latest Mir
<sil2100> We'll be trying to release new Mir around tomorrow
<kgunn> sil2100: ug...so....to make sure i get it :) there will be a daily-build based on mir trunk latest
<kgunn> ?
<kgunn> which will actually be going thru testing...(per what didrocks indicated)
<kgunn> sil2100: just to let you know we are here in lexington at a mir sprint....so we're going to be pushing quite a bit of bug fixes thru
<sil2100> kgunn: we'll probably have a detailed talk about Mir tomorrow in the UTC morning, but the deal is - we're spinning releases manually (not automatically every 4 hours)
<sil2100> kgunn: so, essentially, there won't be a new Mir built in daily-build every 4 hours
<sil2100> kgunn: but whenever asac and didrocks decide that we will be testing a new Mir for the image, we'll be spinning manually a release of Mir which will land into daily-build
<sil2100> kgunn: go through our testing
<sil2100> kgunn: and if all is green we will release it to -proposed
<kgunn> sil2100: thank you...i realize you are the messenger so i won't shoot :)...but i am a little worried
<kgunn> this might cause us a bit of slow down...at least a little concerned we're not getting build/integration feedback
<kgunn> sil2100: ...any chance someone could help launch a manual build for latest trunk eod our time in US ??
<kgunn> we have some key things we want in today
<smspillaz> is there some sort of EGL_MIR_PLATFORM #define ?
<smspillaz> so that I get the right typedefs
<sil2100> kgunn: hmmm
<kgunn> sil2100: even now...we're 5 days diff from what's in archive to whats in trunk
<sil2100> kgunn: I personally doubt it, as asac is the person that needs to say 'OK!' when doing any building
<sil2100> kgunn: since we want to release Mir tomorrow
<sil2100> Not sure if he would give a green light for building things today ;p But maybe?
<kgunn> sil2100: thanks i'll ask
<sil2100> kgunn: it's best to poke asac as he's the guy in charge
<kgunn> asac: ^ we're in the midst of mir sprint in lexington (we traded places)
<kgunn> asac: i understand ur in manual build mode....any chance someone could kick us a manual build eod US time ?
<kgunn> ...we are hoping to have some key things lined up for merging/landing into archive today
<kgunn> and i was just pointing out...we're 5 days old in archive vs trunk
<asac> kgunn: so we work on a unity update that cannot be done with an updated mir
<asac> kgunn: from what i understand, one thing that would be soo  much easier if you guys would commit to maintain an abi/api properly.
<kgunn> asac: we are committed to that
<kgunn> asac: already discussed with didrocks as well
<kgunn> asac: and we do need to bump the api
<kgunn> asac: afaik that means we will need to land the corresponding xmir changes with it
<asac> kgunn: its also libmirserver
<asac> that one seems to be even more of a mess
<kgunn> asac: but....it will require a full rebuild of the stack
<asac> you say you will maintain that ?
<asac> kgunn: at the moment we have to rebuild the full stack before landing
<kgunn> asac: yes
<asac> kgunn: with proper versioning we can do that step by step (e.g. first land mir, then update the rest of the stack in a second shot)
<kgunn> asac: yes, i understand you have to rebuild the whole stack
<asac> sil2100: so from what i understand we have a daily-release
<kgunn> asac: yes...that's the plan, we have libmirserver3 in waiting, we are making sure this afternoon our changes on the xmir side correspond
<asac> and a daily-release-next ppa
<asac> correct?
<kgunn> asac: other mir clients simply need to rebuild (they don't use the new method)
<asac> sil2100: you think we could pipe kgunn into whatever we dont use right now?
<sil2100> kgunn, asac: we can use the -next PPA I guess...
<kgunn> asac: is there anyone in late U.S. time that could help here ? (realizing poor sil2100 wants to go to sleep sometime)
<asac> kgunn: kenvandine i guess
<kgunn> asac: ah...thanks
<asac> kgunn: dont you have a ppa you used in the past?
<asac> for the mir preview images?
<asac> etc.?
<asac> kgunn: and cyphermox as well
<asac> he knows the system pretty good
<kgunn> asac: we're shooting for archive...we can test all we want off trunk, but what I do want is the integration test result from being on a current desktop/touch image
<kgunn> does that make sense ?
<asac> kgunn: i am not sure :)
<kgunn> asac:  so olli_ is going to murder me if we aren't default xmir on desktop by thursday...
<asac> ok... that i understand :)
<sil2100> ;)
<asac> kgunn: everything on desktop you can just get in without being coordinated
<ogra_> asac, the question is, will you prevent it
<ogra_> :)
<asac> if it doesnt touch touch, i dont care
<sil2100> kgunn: I can propose a switch so that the new Mir stuff is going to land to the daily-build-next PPA, but you'll have to poke kenvandine or cyphermox to get the releases rolling anyway
<kgunn> asac: mir is the same component for both
<sil2100> kgunn: there's also the problem of needing a rebuild of unity8 and platform-api...
<kgunn> sil2100: that's awesome....thanks... and we have greyback & Saviq for any unity8 issues
<kgunn> RAOF: racarr ^ so i figure if we can square dpms away this afternoon...we can get a daily build going that we can put on all the systems here in lex
<kgunn> asac: reading my own scrollback...just to make sure, mir is obviously a touch & desktop component...so when we make changes it needs to happen in both (esp in the case of libmirclient3...we were bumping for desktop, but obviously touch components will need to accomodate)
<kgunn> racarr:  libmirclient relevant touch components are unity-mir & platform-api ? right?
<asac> kgunn: so unity mir fixes are scheduled tomororow. having you guys ramp up in the -next ppa is probably right
<asac> you guys can then test and work with cypher and ken on getting udpates intot he ppa so we can release tomorrow morning the next shot
<asac> kgunn: but my understanding is that if you pick up the libmirclient bump you also need new drivers etc.
<asac> sil2100: is that on your radar?
<kgunn> asac: right....only Xmir driver (which is RAOF 's and he is here) will be new...it uses the additional methods, but all other mir clients only need to be rebuilt
<kgunn> as the mir clients (other than xmir)  don't use the new api
<eleni> RAOF, https://code.launchpad.net/~hikiko/mir/mir.1226144
<olli_> asac, we need quick iterations to land stuff in time fro 9/19
<kgunn> sil2100: just to make sure i'm not crazy...is the autobuilding off for both desktop and touch ? or just touch ?
<olli_> can't afford to block on someone manually approving it, e.g. during the night shifts the team might be pulling here
<olli_> we need to have builds available when needed
<asac> olli_: you have a ppa
<sil2100> kgunn: define 'autobuilding' ;)
<asac> olli_: you can stage stuff there now
<asac> olli_: and kenvandine and cyphermox can help you getting updates in there
<kgunn> sil2100: "autobuilding" as opposed to the manual building that you're doing now
<sil2100> kgunn: ah, for daily-release you mean? Since the touch images take packages which we release, so basically both desktop and touch are in manual building mode...
<kgunn> sil2100: that's what i needed
<alan_g> hikiko:  http://unity.ubuntu.com/mir/building_source_for_android.html
<hikiko> alf_, https://bugs.launchpad.net/mir/+bug/1226144
<ubot5> Ubuntu bug 1226144 in Mir "switching to the "unity" (graphical) vt after exiting lightdm and mir causes a crash" [Critical,In progress]
#ubuntu-mir 2013-09-17
<tritonas00> is there a serius reason that canonical have chosen to go with mir
<tritonas00> why not wayland  ?
<tritonas00>  is there a serius reason that canonical have chosen to go with mir? why not wayland  ?
<tvoss__> tritonas00, RAOF has written a great series of articles on the subject. You might want to take a look at: http://blog.cooperteam.net/2013/03/artistic-differences.html
<tritonas00> thanks  i will read that
<davmor2> tvoss__:  screencap is a surface flinger only tool do you know if there is something similar for mir for screenshooting issues?
<kgunn> didrocks: ping
<kgunn> didrocks: ping (sorry if its a duplicate...not sure i was online)
<didrocks> kgunn: you were, I was running, back now
<kgunn> didrocks: can u meet now ?
<didrocks> kgunn: in 5 minutes? do you want to hangout?
<kgunn> didrocks: yeah
<kgunn> didrocks: will send you a link
<alan_g>  /msg NickServ identify 63%Octopull
<ogra_> thanks for yourt password
<ogra_> enjoy creating a new one
<alan_g> :(
<davmor2> guys screencap is a surface flinger only tool do you know if there is something similar for mir for screenshooting issues?
<ogra_> mircap ?
<ogra_> :)
<davmor2> ogra_: there's a cap for mir /me dashes off to the canonical store to buy it instantly
<ogra_> haha
<robert_ancell> didrocks, hey - we think it will be easier if we bump ABI just before we do the manual push into the archive otherwise our MPs will race to land if each one has an ABI bump. Is there a way to lock the automatic building in Jenkins so I can do the ABI bump and then tell you to take that to archive? Then you'd re-enable the building once that occurs
<didrocks> robert_ancell: so basically, you don't want to daily release, but on demand release only
<robert_ancell> didrocks, or was the idea to daily release from Mir trunk and get rid of the new PPA?
<didrocks> robert_ancell: right, that's for Mir trunk
<didrocks> and once you finish your sprint
<didrocks> we get rid of the new PPA
<didrocks> the new PPA is just for this week
<didrocks> to get you isolated
<robert_ancell> didrocks, ok. Sounds good, I'll re-discuss with the team here
<didrocks> ok
<robert_ancell> kgunn, ^
<didrocks> kgunn: robert_ancell: btw: https://launchpadlibrarian.net/150495448/buildlog_ubuntu-saucy-i386.mir_0.0.10%2B13.10.20130917-0ubuntu1_FAILEDTOBUILD.txt.gz
<didrocks> (so no Mir yet in the ppa)
<robert_ancell> didrocks, so, back to the issue this week - there will be a race between the soname MP and getting it to archive - do we just solve this by timing it between you and me?
<robert_ancell> carefully timing it I mean
<didrocks> robert_ancell: what issue? you will bump the build-dep, isn't it?
<didrocks> so the rest will rebuild
<didrocks> isn't it?
<didrocks> or you are talking about libmirclient, which has stuff dep on it not in the archive?
<robert_ancell> didrocks, the issue is you pull from trunk right? So if another MP has landed then you will pick up that change by accident
<didrocks> robert_ancell: well, it's not an accident, you put it to trunk
<didrocks> so it's releasable as per the process
<didrocks> robert_ancell: making sense? I'll drop in 8 minutes, so please answers before ;)
<kgunn> Mirv: sil2100 ...hey guys....didrocks dropped, but i wanted to kick another build for the mir package https://launchpad.net/~ubuntu-unity/+archive/experimental-prevalidation/+packages
<kgunn> belief is the i386 build test that failed is intermitent
<mterry> robert_ancell, what the heck with boost; I've lived in C land so long, this is all gobblygook
<robert_ancell> mterry, yeah, it's boost
<mterry> Just let me set open permissions!
<sil2100> kgunn: I'll take a look in a moment
<kgunn> sil2100: thanks much
<mterry> But I probably need an open-permissions-service-factor object
<kgunn> sil2100: nothing change between that and whats in archive..so...
<mterry> robert_ancell, guh you had to make the_socket_file() private...
<mterry> robert_ancell, so I was thinking of just chmod'ing the socket from USC?  Since this seemed like a special case of Mir, I wasn't sure I wanted to put it directly in libmirserver...  Also, boost didn't seem to make it easy to set socket permissions at open (unless I want to mess with umask)
<robert_ancell> mterry, yeah, that seems safe to me - you're dropping permissions rather than increasing them
<mterry> right, no race to worry about
<robert_ancell> mterry, and u-s-c considers that it knows the correct name of the socket, so it would be a critical error if Mir didn't use the requested name
<mterry> robert_ancell, how does USC know the socket name?  I can't just call the_socket_file(), but could re-discover it via the_options()
<robert_ancell> mterry, yeah, you'd have to look in the_options()
<mterry> robert_ancell, that's fine, but it duplicates the default value :(
 * mterry starts with that
<robert_ancell> mterry, you can consider it a critical error if it's not set if that helps
<robert_ancell> mterry, lightdm will always set the socket name
<mterry> robert_ancell, eh, that's fair
<mterry> but doesn't hurt to have a fallback either
<alan_g> kgunn: who did you talk to about the android tests? We're seeing what look like setup problems: https://jenkins.qa.ubuntu.com/job/mir-saucy-armhf-ci/7/console
<kgunn> alan_g: join #ubuntu-ci-eng with me
<alan_g> kgunn: done
<sil2100> kgunn: ok, getting back to the Mir issue now ;)
<kgunn> sil2100: yes...thanks
<kgunn> sil2100: i also noticed in that same ppa, unity7 didn't build... https://launchpadlibrarian.net/139999825/buildlog_ubuntu-raring-amd64.unity_7.0.0daily13.05.16ubuntu.unity.experimental.certified-0ubuntu1_FAILEDTOBUILD.txt.gz
<kgunn> complaining about dep's
<ricmm> racarr: ping
<ricmm> racarr: do you have an old imge running on your phone by any chance?
<sil2100> kgunn: it was a transient issue, building now
<xjunior> hey, a question about mir: Is it planned to make multitouch configurable?
<xjunior> maybe it's more unity than mir
<alan_g> mterry: lp:~alan-griffiths/mir/fix-nested-on-android
<robotfuel> kgunn: https://bugs.launchpad.net/unity-system-compositor/+bug/1218932
<ubot5> Ubuntu bug 1218932 in XMir "xmir/mir should depend on >= version of xserver-xorg-video-<driver> (intel|nouveau|radeon) that works with it." [Medium,Triaged]
#ubuntu-mir 2013-09-18
<alan_g> racarr: kdub - last call on: https://code.launchpad.net/~afrantzis/mir/base-config-fix/+merge/185940 before I top approve
<robert_ancell> alf_, can I get a second opinion on https://code.launchpad.net/~robert-ancell/mir/pause-status/+merge/186134?
<kgunn> alf_: arent you looking at this one https://bugs.launchpad.net/xmir/+bug/1216559
<ubot5> Ubuntu bug 1216559 in XMir "xmir multimon seems to crash X when turning off 2nd display thru settings dialog (& rarely unplug)" [Critical,Triaged]
<racarr> dpms-with-gbm-and-android is ready for review when people have time
<alan_g> racarr: dpms-with-gbm-and-android has been reviewed
<smspilla1> looks like chromium finally has their wm abstraction
<smspillaz> http://lists.freedesktop.org/archives/wayland-devel/2013-September/011146.html
<smspillaz> I'd try my hand at the Mir port, but I suspect that if I even tried to download the *source* for chromium I'd run out of free space (let alone the fact that this machine would overheat and run out of space compiling and linking it)
<racarr> smspillaz: Your link is brokeeen
<smspillaz> racarr: your chat client is broken :)
<racarr> oic
<smspillaz> works fine here, just resize your window
<racarr> Neat
<robert_ancell> alan_g, can you review https://code.launchpad.net/~robert-ancell/mir/parse-options/+merge/186389
<alan_g> robert_ancell: sure
<alan_g> robert_ancell: trivial "needs fixing" written
<om26er> is there a bug tracking screen not turning off with the power button using Mir ?
<mterry> robert_ancell, do you have much experience with passing --file to mir servers?
<davmor2> om26er: it's the same powerd one as I wrote
<davmor2> om26er: https://bugs.launchpad.net/unity-mir/+bug/1225190
<ubot5> Ubuntu bug 1225190 in unity-mir "Mir needs a powerd plugin" [Undecided,New]
<davmor2> om26er: I kept it quite loose to account for those things :)
<thomi> kdub: https://code.launchpad.net/~thomir/mir/enable-tests/+merge/186416
<ricmm> thomi: tests are working again? or will it hang all the buildd's once more
<thomi> ricmm: apparently it should work
<thomi> let's find out :)
<ricmm> right
<ricmm> ..sure :)
<alan_g> racarr: kdub alf_ - can someone else look at this (I've read it too many times now) https://code.launchpad.net/~mterry/mir/xdg-runtime-socket/+merge/186386
#ubuntu-mir 2013-09-19
<rsalveti> kdub_: hey, afaik nothing changed in libhardware that could affect mir
<rsalveti> kdub_: can you get some more details, and open a bug as well?
<rsalveti> I'm in vac this week, but I can take a look at the bug
<robert_ancell> mterry, https://launchpad.net/~ubuntu-unity/+archive/experimental-prevalidation
<mterry> robert_ancell, ah... that's a boring PPA that doesn't have armhf enabled  :(
<robert_ancell> mterry, :(
<mterry> robert_ancell, I'm trying to avoid rebuilding the "world" in armhf
<kdub> rsalveti, so, i have a theory about how to fix the nexus4 flicker
<kdub> but need some help spinning up a phablet build
<kdub> specifically, a kernel
<kgunn> ricmm: ^ could you possibly help kdub ?
<ricmm> kdub: whats the issue?
<kdub> ricmm, long story short... i want to make a build for mako with this in BoardConfig.mk
<kdub> TARGET_QCOM_DISPLAY_VARIANT := caf
<kdub> when i try to do so though, it needs a kernel with some new ioctls
<kdub> ricmm, the 'why' is that the hwcomposer.msm8960.so module that we're using is just what works for CM... its not what qcom ships from codeaurora forum
<ricmm> ok, ill build one for you
<ricmm> give me a bit
<kdub> ricmm, thanks
<rsalveti> kdub: ricmm: this might not be necessarily trivial but something to test
<kdub> rsalveti, not trivial because of the kernel changes?
<rsalveti> yup, not sure if our kernel has everything that's needed by it
<kdub> well, our kernel does not... i think the lge-kernel-mako from cyanogenmod does though?
<rsalveti> well, our kernel should reflect that, might not be completely updated with our current cyanogen branch
<kdub> its in the 10.2 kernel
<kdub> and we're still 10.1 basde?
<rsalveti> iirc, yes
<tvoss> kdub, are we able to reproduce the flicker issue with a simple test setup?
<kdub> tvoss, like, if i drive the display with the fb hal, i see it... or if i force surfaceflinger in certain ways
<kdub> the obvious problem is that the fb isn't being synced right
<tvoss> kdub, okay
<tvoss> kdub, was just curious
<kdub> and its plain to see why looking through the source for the hwc we're /currently/ using :)
<tvoss> kdub, ?
<tvoss> kdub, does that mean you know the root cause?
<kdub> i meant that its obvious that what the hwc is doing right now won't cause any fb sync
<tvoss> ah okay
<ricmm> rsalveti: yea right just saw that
<ricmm> so not trivial to build with what kdub needs
<ricmm> kdub: can you isolate the kernel patch? or got a link I can see the relevant bits in?
<kdub> ricmm, i'll see if i can dig up the kernel patch
<kdub> the relevant bits are
<kdub> the MSM_ROTATOR_IOCTL_BUFFER_SYNC ioctl in https://github.com/CyanogenMod/lge-kernel-mako/blob/cm-10.2/drivers/char/msm_rotator.c
<ricmm> kdub: how come we dont see this in SF tho?
<ricmm> we are running 10.1 and that isnt available there
<kdub> looking up sources... i minute
<kdub> 1 minute
<kdub> so if you look here... https://github.com/CyanogenMod/android_hardware_qcom_display/blob/cm-10.1/libhwcomposer/hwc.cpp#L283
<kdub> you see that hwc skips doing any fb sync if we have 1 layer (like mir runs with)
<kdub> sf always operates with 2 or more layers, so they get the sync code
<kdub> but really, i don't know where that hwc came from
<kdub> because the ones qualcomm puts out are in...
<kdub> here: https://github.com/CyanogenMod/android_hardware_qcom_display-caf/tree/cm-10.1
<kdub> i've tried to patch the one we're using, haven't gotten it quite right yet :)
<ricmm> that'd be a nicer solution :)
<ricmm> can you just do the sync outside of the check?
 * ricmm taking wild guesses
<tvoss> kdub, but the qualcomm one you are referring only syncs for more than one layer, too, see: https://github.com/CyanogenMod/android_hardware_qcom_display-caf/blob/cm-10.1/libhwcomposer/hwc.cpp#L367
<kdub> tvoss, right, but it goes and calls draw in l387
<kdub> whereas the first one just returns
<tvoss> kdub, true
<tvoss> and it does a display_commit, too
<ricmm> sounds patchable
<ricmm> whatever their argument for doing it differently, the patch will show if it works or not
<ricmm> ;)
<tvoss> ricmm, +1
<kdub> right, trying to make a patch, but i think we should move to the caf stuff from qualcomm
<ricmm> try the patch first, the other move might be more intrusive than you think
<ricmm> CM also has a reason for not using that, I guess
<kdub> i'm sure they do, just don't know if its a good reason (or one that applies to mir/ubuntu touch too)
<kdub> at any rate, trying to patch
<ricmm> ok, fingers crossed
<ricmm> good catch if it is that
<alan_g> thomi: did you figure out the valgrind incantation on arnhf? Maybe just run the tests without valgrind?
<thomi> alan_g: I did not
<thomi> I believe that's all done in the packaging
<thomi> so, we can do whatever we like there :)
<thomi> will try and get mir building on the phone though, that sounds like fun
<alan_g> do you also watch paint dry?
<tvoss> thomi, what's wrong with the cross-building setup?
<thomi> tvoss: the script? It used to fail in wierd and wonderful ways, so I generally don't trust it. Also I'm trying to make sure I can run the tests on the target hardware, so cross-compiling really isn't a solution here
<alan_g> thomi: the script is rubbish, but cross compiling works and I run the tests on an N4
<ricmm> kdub: ping, still around?
<kdub> ricmm, yep
<ricmm> kdub: I have this http://paste.ubuntu.com/6129884/
<ricmm> when running the gstreamer-backed mediaplayer
<ricmm> works under SF
<kdub> so... somehow a client has an egl context and is trying to...
<kdub> use buffers from the video decoders with it?
<ricmm> indeed
<ricmm> the gstreamer pipeline is set to use the android decoder
<ricmm> kdub: jhodapp is the guy
<jhodapp> yo
<kdub> jhodapp, so what's the scenario? specifically what egl windows are in play
<ricmm> jhodapp: maybe a quick run down of what the arch looks like for your gstreamer plugin
<jhodapp> kdub: I use eglGenTextures() to get a texture id, and then I use the Android SurfaceTexture call which I pass off to a SurfaceTextureClient
<jhodapp> kdub, that texture id is obtained from qtmultimedia, which passes it to my video sink, which does the calls into hybris where I make the Android calls to set up a SurfaceTexture
<kdub> simple, eh? ;-)
<jhodapp> hehe, yeah
<jhodapp> :)
<kdub> but with this backtrace http://paste.ubuntu.com/6129884/
<jhodapp> that's the high level call chain
<kdub> mir is used
<jhodapp> yes, and with this other logcat output: http://paste.ubuntu.com/6129901/, you can see that it blows up when trying to create the SurfaceTextureClient
<ricmm> I'll have to say that I was getting weird backtraces
<ricmm> like corrupt stacks or something, whenever I added some debugging it went past
<ricmm> until I started hitting some Mir in the backlog
<jhodapp> great
<ricmm> then I pinged people
<jhodapp> a heisenbug
<ricmm> but indeed the last I see is the ::connect(), client-wise
<kdub> so the client is rendering to a mir buffer
<kdub> i guess i don't see how a SurfaceTextureClient would mesh with a mir client
<jhodapp> is that a statement or a question?
<jhodapp> how so?
<kdub> jhodapp, a question, sorry
<kdub> so the client connects to the mir server, wit the intention of posting some buffers to the screen, right?
<jhodapp> I guess so, I'm not making any direct mir client/server calls myself
<jhodapp> have you essentially gutted the Android SurfaceTexture and SurfaceTextureClient underneith to use a mir buffer?
<ricmm> no no, this is a normal QtUbuntu client, out through mirclient
<ricmm> our SurfaceTexture is bound with the Mir window
<jhodapp> a SurfaceTextureClient just needs to be able to take a raw decoded frame and push that to the rendering texture buffer
<ricmm> the difference here is that we are then passing that ST to the decoder to dump back decoded buffers into it
<jhodapp> exactly
<jhodapp> the SurfaceTextureClient connects the GL API to do that buffer pushing that avoids the main CPU
<jhodapp> does that help at all kdub?
<kdub> jhodapp, okay so, the buffers that were acquired came from mir, via qtubuntu?
<jhodapp> ricmm, can you answer that one?
<kdub> because if you switch QT_QPA_PLUGIN environment variable, it will switch from getting the buffers from sf to mir
<jhodapp> kdub, I'm not familiar with how mir fits in behind the scenes as I developed everything with SurfaceFlinger
<kdub> jhodapp, right, so there might be some banging on mir bits to get it to work with the media stuff
<jhodapp> kdub, indeed...now I kind of wish ricmm and I were at the sprint with you to push through this
<kdub> jhodapp, so when you get a buffer to feed to the video decoders, that comes from where?
<ricmm> the buffer is allocated natively
<ricmm> directly out gralloc
<jhodapp> kdub, it comes from gralloc
<jhodapp> yes
<ricmm> jhodapp: this runs the same code path in hybris as the old media stuff, right?
<ricmm> the non-SF provided buffers
<jhodapp> ricmm, it is a new hybris compat layer, but it uses a SurfaceTextureClient and such just like the old one
<ricmm> kdub: SurfaceTextureClient's BufferQueue used to use the SF allocator by default, in the hybris code we now extracted that code natively into hybris
<ricmm> so we use GraphicBuffer() directly
<jhodapp> ricmm, it merely gets rid of using the MediaPlayer class, and uses MediaCodec instead
<ricmm> and thats what we pass to the STC
<jhodapp> so in theory it should be the same
<ricmm> jhodapp: oh, what file is that?
<jhodapp> ricmm: compat/media/media_codec_layer.cpp
<jhodapp> ricmm: and also take a look at surface_texture_client_hybris.cpp
<ricmm> _SurfaceTextureClientHybris::getInstance().surface_texture = new SurfaceTexture(texture_id, allow_synchronous_mode);
<ricmm> thats wrong, we need to pass the native BufferQueue as in media_compatibility_layer.cpp
<jhodapp> exactly
<ricmm> otherwise it will try to reach out into SF for it
<jhodapp> ricmm, I need a SurfaceTexture though because I need to be able to call updateTexImage() on it
<jhodapp> ricmm, if we can still do that with what you said, that's fine
<ricmm> thats fine, just look at how its done in media_compatibility_layer
<ricmm> its weird because I dont see the failing call out into SurfaceFlinger
<ricmm> but I'm sure that this code path will block that thread and maybe blow up somewhere else, perhaps
<ricmm> lemme get something for my wife and I'll give it a shot
<jhodapp> ricmm, so more like this, minus the SurfaceTexture: _SurfaceTextureClientHybris::getInstance().setISurfaceTexture(surface_texture->getBufferQueue());
<kdub> i got a little lost in the discussion there, but it sounds to me like the client is allocating the buffer for media usage directly?
<jhodapp> yes
<jhodapp> down on the bionic side
<kdub> in which case... you could composite it to a mir buffer
<ricmm> kdub: not yet, right now we realized theres something wrong in the code
<ricmm> we'll take a stab at fixing it
<kdub> okay
<jhodapp> ricmm, so you're wanting to try messing with it, is that right?
<jhodapp> ricmm, if so that's cool, otherwise I can try in the morning as I've got to run for the evening
<ricmm> jhodapp: go ahead, ill take a look
<ricmm> and if not ill get an email going with the three of us for later/tomorrow
<jhodapp> ricmm, ok, I can come back on later this evening...I'll ping you when I get home
<jhodapp> ricmm, let me know if you have any success
<ricmm> jhodapp: DONE
<ricmm> works
<jhodapp> lol
<ricmm> shipping now
<jhodapp> what's your change?
<ricmm> theres a weird flickering but its decoding and showing
<jhodapp> dude, you're on a role
<ricmm> made it use the native buffer allocator
<jhodapp> one line change?
<ricmm> I'll send a patch to salveti later
<ricmm> ~5
<jhodapp> ok, send it to me as well so I can update my local git branch
<ricmm> kk
<jhodapp> thanks dude
<jhodapp> the flickering sounds interesting
<jhodapp> ricmm, on maguro?
<ricmm> yep
<jhodapp> wonder if it would flicker on the n4
<jhodapp> ricmm, ok I'm out now
<ricmm> ok cya tomorrow
<jhodapp|afk> later
<ricmm> kdub: did you manage to get a patch for the hwcomposer ?
<kdub> ricmm, no, digging a bit deeper
<kdub> i have a suspicion though about why the patches aren't working, i'll let you know if it works out
<ricmm> alright
#ubuntu-mir 2013-09-20
<kgunn> robert_ancell: you there?
<kgunn> robert_ancell: is this that test that racarr says is a racy test ? https://launchpadlibrarian.net/150875268/buildlog_ubuntu-saucy-i386.mir_0.0.10%2B13.10.20130920.2-0ubuntu1_FAILEDTOBUILD.txt.gz
<kgunn> guess we'll be addressing that today....
<robert_ancell> kgunn, yep
<robert_ancell> kgunn, don't know if that's specifically one that racarr is tracking down
<kgunn> hikiko: it was this one https://bugs.launchpad.net/mir/+bug/1196744
<ubot5> Ubuntu bug 1196744 in Mir "intermittent acceptance test bug in TestClientInput" [Medium,Confirmed]
<hikiko> kgunn, thanks I'll get a look
<robert_ancell> RAOF, bug 958424
<ubot5> bug 958424 in gnome-control-center (Ubuntu) "[regression] Can't change refresh rate in Displays" [Wishlist,Triaged] https://launchpad.net/bugs/958424
<robert_ancell> RAOF, bug 1227961
<ubot5> bug 1227961 in XMir "Unity/Mir causes Motif dialog window shrunk" [Undecided,Incomplete] https://launchpad.net/bugs/1227961
<robert_ancell> RAOF, bug 1222923
<ubot5> bug 1222923 in Unity System Compositor "Screen lockup under XMir" [Undecided,New] https://launchpad.net/bugs/1222923
<robert_ancell> RAOF, https://code.launchpad.net/~robert-ancell/unity-system-compositor/app-lifecycle/+merge/186135 can i haz review plz?
<davmor2> tvoss, kgunn: on my xmir intel box I just hit http://paste.ubuntu.com/6133424 testing the commercial app anatridle a 3d space invader type game.
<davmor2> is it going to be an xmir issue or the app?
<kgunn> davmor2: huh, strange the app wouldn't run w/o a res change to 800x600...and then, i know there are diff res's supported via xmir (e.g. run phoronix test suite you can choose 800x600)
<davmor2> kgunn: well there another 914 apps to test yet :) I said I would forward any gfx based issues to the mir team :)
<RAOF> davmor2: That's kind of both the app's fault and Mir's fault. The app should handle not having an 800x600 mode, and Mir should synthesise a set of common default modes, even if the hardware can't directly support them.
<davmor2> RAOF: good to know this is the first I've I'm sure it won't be the last there are lots of quirky apps along the way :)
<davmor2> s/I've/I've hit,
<RAOF> https://bugs.launchpad.net/mir/+bug/1228323
<ubot5> Ubuntu bug 1228323 in Mir "Mesa is broken by Mir structure size changes" [High,New]
<robert_ancell> alan_g, can you review https://code.launchpad.net/~robert-ancell/mir/fix-config-file-loading/+merge/186865?
<robert_ancell> RAOF, https://code.launchpad.net/~robert-ancell/unity-system-compositor/video-blacklist/+merge/186771
#ubuntu-mir 2013-09-21
<dazza5000> Greetings - Is anyone available to help me troubleshoot a unity/mir issue in 13.10?
#ubuntu-mir 2014-09-15
<duflu> anpok, anyone: Please look at reviewing this ASAP. It's going to block everything and everyone... https://code.launchpad.net/~vanvugt/mir/fix-1369389/+merge/234613
<anpok> duflu: that mako failure is unrelated?
<anpok> ah ok no network on the ci-n4
<duflu> anpok: Yep
<alf_> duflu: thanks for finishing the 0.7.2 release (tarball etc)
<duflu> alf_: Thanks OK. I like to tie loose ends
<duflu> *That's OK
<duflu> (automatic dyslexic fingers)
<racarr> Morning
<greyback_> hey folks, brendand managed to hang shell, this is all the backtrace he's managed to get so far: http://paste.ubuntu.com/8350204/
<greyback_> it appears to be blocked at mir::scene::SurfaceEventSource::attrib_changed - does that make sense to anyone?
<anpok> why is there only one readable mirserver symbol?
<greyback_> anpok: no idea
<greyback_> he's on RTM, and I can't source him a dbg symbol package
<alf_> greyback_: is it reproducible?
<greyback_> http://ddebs.ubuntu.com/ubuntu-rtm/pool/universe/m/mir/ is missing anything to do with mirserver
<greyback_> alf_: not reliably afaik
<alf_> greyback_: anpok: The only codepath that would block there at poll() is blocking while sending event to the client. Do we know if the client has somehow hung? (btw, https://code.launchpad.net/~afrantzis/mir/fix-1350207-unresponsive-clients/+merge/233934 should help if this is the case).
<greyback_> alf_: I suspect the client has indeed hung
<greyback_> alf_: ok I'd postulate your MR will indeed fix this
<alf_> greyback_: in order for this to be the case, the client has to have hung for enough time for us to send enough surface related events (not input) to fill the socket send buffer. Can't be sure without more information.
#ubuntu-mir 2014-09-16
<anpok_> alf_: duflu: can we land https://code.launchpad.net/~afrantzis/mir/fix-1350207-unresponsive-clients/+merge/233934?
<duflu> anpok_: Kind of, maybe, no. I think a few of us want a little cleanup first
<anpok_> ... then after 7.2..
<anpok_> s/2/3
<duflu> anpok_: Does anything need fixing in 0.7.3? Or is it just another practice?
<anpok_> another practice, the unresponsive clients fix would be nice though..
<anpok_> there were rumors that someone already achieved that somehow
<duflu> anpok_: Yeah it's theoretically simple to trigger
<alf_> duflu: anpok_: I've pushed an update
<dandrader> if Alan on holidays?
<dandrader> s/if/is
 * dandrader needs some help google protobuf 
<dandrader> *help with
<kdub_> dandrader, yes he is
<dandrader> :(
<kdub_> doesn't hurt to ask though :)
<dandrader> I wonder how do I debug protobuf communication
<dandrader> client calls a server method, server replies, but client doesn't seem to get any content back, although the call seemed successful. later calls on the same method work though
<kdub_> dandrader, we have MIR_SERVER_MSG_PROCESSOR_REPORT=log
<kdub_> and MIR_SERVER_SESSION_MEDIATOR_REPORT=log for the server
<kdub_> more likely than not, the call triggered an exception within mir, which was reported back as an error string to the client
<dandrader> I'm using mir's "custom messages" feature though. ie, taking the protobuf channel and sending my own messages
<dandrader> kdub_, ^
<dandrader> for the clipboard copy() and paste() more specifically
<dandrader> kdub_, does that make any difference?
<kdub_> dandrader, yeah, then I don't know that it would work
<dandrader> kdub_, where is mir log going to nowadays?
<kdub_> stdout
<kdub_> or some reports can go to a lttng trace
<dandrader> kdub_, but those MIR_*_REPORT=log you mentioned earlier should go to stdout, right?
<kdub_> dandrader, right, the 'log' setting will go to stdout
<dandrader> yeah, I see them in .cache/upstart/unity8.log now
<dandrader> and they're no good for debugging custom messages :(
<anpok> AlbertA, kdub_, racarr: when you set the build type to coverage
<anpok> then build, run tests and run make coverage and make coverage-xml ..
<anpok> do you then get reasonable data in coverage.xml?
<kdub_> i can try it out
<AlbertA> anpok: no idea...
<AlbertA> :)
<anpok> https://jenkins.qa.ubuntu.com/job/mir-utopic-amd64-ci/
<anpok> hmm
<anpok> build history looks strange
<anpok> kdub_: thx, figured it out.. it seems like we relied on an old gcovr version that maybe ignored the -r parameter
<anpok> and the ppa in ca that provided it got updated .. hm at least after some changes it works locally again
<robotfuel> kgunn__: ping my lrt test has the ui frozen. the ui is totally unusable. who can I talk to about logs to check to determine the problem?
<robotfuel> kgunn__: I have this in logcat http://pastebin.ubuntu.com/8360154/ maybe a thermal issue on the n4.
<kgunn__> robotfuel: can you run top ?
<kgunn__> see who's active...almost certainly someone is pegging
<kgunn__> ChickenCutlass: ^ do you know anything about thermal sensor? if we've tuned it etc ?
<kgunn__> robotfuel: btw, n4 is dead to ChickenCutlass :)
<robotfuel> kgunn__: http://pastebin.ubuntu.com/8360176/
<kgunn__> ChickenCutlass: ...or do you know anyone who knows about thermal sensor...e.g. should the system recover from a thermal event like this ?
<kgunn__> robotfuel: huh, i suppose the event basically stopped all the threads
<ChickenCutlass> kgunn__, reading back log
<tvoss> kgunn__, robotfuel seems like system-settings is eating memory like crazy
<tvoss> 25.8% according to top
<robotfuel> tvoss: that's the screen it's frozen on
<kgunn__> robotfuel: yeah...but he's saying memory consumed....
<kgunn__> not cpu
<kgunn__> that's huge
<robotfuel> ah right I wasn't looking at that.
<racarr> oh yeah apt-cache-ng...this is some good stuff
<racarr> cacher*
<racarr> between sbuild and
<racarr> new machine with massive ram, I feel my days of compiling woes
<racarr> are finally over
<racarr> woah
<racarr> I just got the new google docs
<racarr> its so shocking I cant even remember what document I needed now.
<kgunn__> lol
#ubuntu-mir 2014-09-17
<RAOF> Ok. That's enough thinking about WaitHandles and the madness of force_completion(). Let's instead think about looking up surface coordinates!
<duflu> Ironically I only started thinking about WaitHandles 30 seconds ago
<duflu> Still agree though
<RAOF> If it wasn't a huge slog thorough the code I'm *pretty* sure we could just do with invoke ids.
<duflu> RAOF: Oh and vmware is thinking about WaitHandles right now too :)   https://bugs.launchpad.net/mir/+bug/1370386
<ubot5> Launchpad bug 1370386 in mir (Ubuntu) "libmirclient7 hang on client startup" [Undecided,New]
<RAOF> Heh.
 * duflu is frustrated (and happy) to see that the current input sampling algorithm apparently cannot be beaten
<duflu> Despite trying to improve on it for 2 days now
<duflu> It's a little suspicious though that I can see fingerpaint (which does rendering in software) is much more responsive in a nested server than Unity8 (which is meant to be rendered by hardware)
<duflu> The software rendering handicap on a phone should be large
<anpok> duflu: you access rgb pixels directly and only those that change due to the finger movement
<anpok> thats slightly different to dispatching user input through a qml scene
<RAOF> Also, Unity8 /is/ a nested server.
<duflu> RAOF: Yes, meaning there's /less/ indirection for Unity8 :)
<anpok> i would assume fingers paints memory bandwith usage is also below the command submission part of a gles driver redrawing an client application
<anpok> -"s "
<duflu> anpok: fingerpaint still flips (copies) the whole surface
<anpok> oh
<duflu> memcpy
<duflu> FTW
<RAOF> duflu: What? No, there's exactly the same indirection - usc â nested server â fingerpaint vs usc â unity8 â fingerpaint?
<duflu> anpok: The only way to avoid it is to implement a single buffering option
<anpok> ok i thought we had that by accident with software buffers
<RAOF> Or damage.
<duflu> RAOF: USC(Unity8(app))  vs  server_minimal(server_shell(fingerpaint))
<anpok> that would be so 2010
<duflu> hence Unity8 is closer to the metal
<anpok> duflu: but you mostly interact with unity8-dash.
<anpok> or depends on what you look
<duflu> anpok: Ah, yes. So the dash has no advantage.
<RAOF> fingerpaint could avoid flipping memcpying the whole surface *right now* pretty easily.
<duflu> RAOF: age?
<RAOF> Yes.
<duflu> RAOF: I'm intrigued if it's easy. Can you demo such a proposal?
<RAOF> The Mir side will also handle it better when we add damage support to swap_buffers.
<anpok> can mesa track damage internally?
<RAOF> Technically? Probably.
<anpok> and s/can/does?
<anpok> or would we provide another client api to submit damage with the next buffer switch?
<duflu> RAOF: Oh actually, please don't. I think I want to add support for multiple touch samples per frame first (demo client-side resampling as an option)
<RAOF> anpok: Does not, would probably be an arse to implement.
<duflu> Quad-tree madness? :)
<RAOF> eglSwapBuffersWithDamageEXT is the relevant entry point for most clients :)
<anpok> ah ok
<RAOF> We'd need support in libmirclient for that to actually translate into anything useful, obviously.
<RAOF> And mesa *does* support SwapBuffersWithDamage
<robotfuel> where can I find mir logs on the phone?
<robotfuel> kgunn_: kdub_ racarr ^
<kdub_> robotfuel, like in unity8 or usc?
<kdub_> or running some of the standalone things
<robotfuel> I have a qml app pegging the cpu and the ui is stuck
<kdub_> robotfuel, /var/log/lightdm/unity-system-compositor.log for USC and /home/phablet/.cache/upstart/unity8.log for unity8
<robotfuel> kdub_:  it is the warning in the USC log normal? http://pastebin.ubuntu.com/8367234/
<kdub_> robotfuel, those look normal to me
<racarr> seems normal yeah
#ubuntu-mir 2014-09-18
<duflu> RAOF: Fun fact: while our drivers don't link in a well-behaved fashion ${shlibs:Depends} finds no dependencies
<duflu> Obviously
<duflu> But there really should be some
<duflu> Although they're utterly unusable without the prerequisite libmirplatform so it's probably a clean and harmless dependency omission
<RAOF> Well, as it currently stands they don't _really_ have a dependency on libmirplatform.
<RAOF> They get those symbols from the libmirserver they're loaded into :)
<duflu> RAOF: Yeah symbols needed at runtime. But there's no reason to accurately detail those dependencies in the package details
<duflu> If you don't have the deps you can't load the drivers
<RAOF> Right.
<RAOF> (At some glorious future point you'll be able to load a driver linked against libmirplatform.so.N into a libmirserver linked against libmirserver.so.M and have everything work, but that's not now)
<duflu> RAOF: I'm not totally comfortable I know what the "platform" is yet. Would be nice to find the time for me to write a new driver as a learning exercise
<RAOF> I started an X11 one on Friday.
<duflu> Woot
<duflu> RAOF: Is a new mesa for utopic coming at all?
<RAOF> There's a surprising amount of Mir scattered through there.
<RAOF> duflu: I believe that mlankhorst is prepping a new Mesa now.
<duflu> All good news
 * duflu should log off early today in case that changes :)
<RAOF> Heh.
<RAOF> Of course, the X11 platform is only for output, and won't work for input...
<RAOF> That requires a reworking of âPlatformâ to fix.
<RAOF> But would be nice; then we'd have 4 1st class platforms - Mesa+evdev, Android+evdev, Mir, X11.
<duflu> RAOF: Not sure Mir is 1st class or higher than that even... since it's not an explicit driver implementation
<RAOF> Oh, but it is.
<RAOF> It's just that we don't treat it as such.
<duflu> 0.8th class (for royalty only)
<RAOF> (And, also, because we don't have any sort of input platform the Mir platform needs to be tightly bound)
<RAOF> But with not _too_ much work that binding can be cut.
<duflu> Yay, options
<bschaefer> racarr, hey, would you happen to know whos in-charge of setting the tool type for motion events? As im pretty sure we just copy it from the android event ... but for some reason I keep getting a 0 tool type (which is AMOTION_EVENT_TOOL_TYPE_UNKNOWN)
 * bschaefer re-calls hitting that problem a few months ago...
<racarr> bschaefer: I don't actually know what happens to that no...
<racarr> bschaefer: We dont even have mir defines, so I guess there is some work to do, if nothing else it needs to be under test
<racarr> and it sounds like this test would fail lol...
<racarr> can you file a bug?
<racarr> I'm getting ready to go to lunch as soon as the rain clears up
<racarr> and dont want to forget
<bschaefer> racarr, sure, i assume we never want a tool type to be UNKNOWN
<bschaefer> racarr, thanks!
<racarr> bschaefer: I guess sometimes its inevitable probably but preferably not
<bschaefer> yeah
<bschaefer> racarr, i should test it on the desktop to see if the MOUSE tool type is getting set correctly...i wonder if arm is doing something strange under the hood there...
<bschaefer> racarr, it could be worded poorly, but edit it how you think it should sound: https://bugs.launchpad.net/mir/+bug/1371282
<bschaefer> :)
<ubot5> Launchpad bug 1371282 in Mir "Mir Motion event tool type on touch device is 0 (AMOTION_EVENT_TOOL_TYPE_UNKNOWN)" [Undecided,New]
<racarr> bschaefer: Yay. thank you...will parse after lunch
<bschaefer> thanks! enjoy
 * bschaefer should eat at some point
#ubuntu-mir 2014-09-19
<racarr> yay...hypothetically cross built against rtm
<racarr> something didnt work
<alf_> greyback: what is "wizard_socket"?
<alf_> greyback: (Good morning!)
<greyback> alf_: hey. I've no idea, first I've heard of it
<greyback> too early to make a harry pooter joke
<greyback> alf_: I know hte startup wizard uses qtmir, as it needs to be a mir server in order to have an OSK client. Perhaps it decided to call its own socket that?
<alf_> greyback: Any idea where the start-up wizard project is?
<greyback> alf_: lp:ubuntu-system-settings
<alf_> greyback: thanks
<greyback> np
<greyback> alf_: yep, wizard/ubuntu-system-settings-wizard.conf sets a wizard_socket
<alf_> greyback: So, I guess unity8 has no business connecting to that socket, right?
<greyback> alf_: right
<alf_> greyback: I think it picks up by mistake, some leftover environment variable somehow
<alf_> greyback: I will check the start-up scripts
<greyback> alf_: in post-stop, might be good idea to unset MIR_SOCKET
<greyback> or else specify exactly the socket for unity8 to connect to in its startup job
<alf_> greyback: so ubuntu-system-settings-wizard-cleanup.conf supposedly restores the MIR_SOCKET to its previous value (WIZARD_ORIG_MIR_SOCKET), but there is probably some kind of race there
<greyback> alf_: agreed
<alf_> greyback: if only I could reproduce it...
<RAOF> Can we have a wizard_socket as a mainstay? :)
<greyback> RAOF: back to the muggle mines you
 * RAOF returns to his lunar abode
<duflu> Oh lunar. Cheesy.
<duflu> Mirv, tvoss: Can we drop the overly wordy (and wrong) description text here?... https://launchpad.net/ubuntu/+source/mir
<duflu> I don't seem to have permission
<tvoss> duflu, did you mean launchpad.net/mir
<tvoss> ?
<duflu> tvoss: No the link I just gave (under âmirâ package in Ubuntu)
<Mirv> duflu: I don't see any description there, aside from listing the packaging short descriptions
<duflu> Mirv: Yes, they're wrong. And very old
<Mirv> duflu: so that's a list of debian/control Description: first lines
<duflu> Delete please
<tvoss> duflu, those are auto generated
<duflu> Hmm where from?!
<duflu> Maybe from trusty
<duflu> ?
<tvoss> duflu, I don't know
<duflu> Ah yes. Looks like auto-generated  from trusty
<Mirv> duflu: is there some difference to the utopic ones on that page? http://bazaar.launchpad.net/~mir-team/mir/utopic/view/head:/debian/control
<Mirv> right, trusty
<Mirv> that's really a Launchpad problem/choice then
<duflu> Mirv: Yeah the ABI levels are different, and the package names are changing a bit
<Mirv> it's definitely a bug also that https://launchpad.net/ubuntu/utopic/+source/mir looks similar
<duflu> Excellent. Another important Launchpad page with misleading info we can't fix
<Mirv> :(
<duflu> Mirv: OK thanks for clarifying :/
<alf_> greyback: duflu: Any idea how to add ubuntu-system-settings as affected by the bug? The project doesn't track bugs in launchpad (it's tracked in the ubuntu package).
<duflu> alf_: I'll do it
<alf_> duflu: thanks
<duflu> alf_: (Also affects distribution...)
<alf_> duflu: ah, right, that one again... :)
<duflu> anpok_: Your 0.7.3 is served
<duflu> https://launchpad.net/ubuntu/+source/mir
<RAOF> Woo! Branches all green.
<duflu> RAOF: Time to run away then :)
<RAOF> Yup.
 * davmor2 lassos ROAF and stakes him down in front of a computer
<sil2100> kgunn: hello!
<kgunn> uh-oh
<kgunn> sil2100: hello ?
<kgunn> :)
<sil2100> kgunn: sooo, I'm preparing the FFe for touch inbetween stuff, and noticed that some parts of mir are now used in the default utopic desktop images
<sil2100> kgunn: we would like to know what things are planned for mir in this cycle still
<sil2100> kgunn: can you guarantee ABI stability at least? :)
<kgunn> camako: fyi....
<kgunn> sil2100: so right now we are truly in bug fix mode
 * camako is all ears (eyes)
<kgunn> so no FFe needed i think
<kgunn> for utopic
<kgunn> sil2100: however, yes, we still break ABI every now and then tho we try not to
<camako> what is FFe?
<kgunn> sil2100: only if a bug fix ends up causing us to do so
<kgunn> but we know all our clients....so...
<kgunn> FFe = feature freeze exception
<kgunn> camako: cause even tho we're thinking phone alot....there's utopic going on delivering to desktop
<sil2100> kgunn: ok, so we'll not include mir in the FFe, and simply make sure anything that gets released is a bugfix
<camako> I see
<kgunn> camako: do you agree with what i said?....i can't see anything that's a "feature" landing before Oct ?
<kgunn> everything is really just a bug fix
<camako> there will be a 0.8.0 release coming (probably next week)...  which will/should reduce ABI breaks
<kgunn> ...and we're not even cheating on definitions :)
<kgunn> camako: i think even that is ok....we just can't break client
<camako> yeah that's all under control... we have a deprecation path, rather than breakage
<sil2100> Excellent
<alf_> kgunn: @ lp bug 1371593, is the media hub part of the unity8 process, but something separate from it?
<ubot5> Launchpad bug 1371593 in media-hub (Ubuntu) "Media player crashes on 'sudo stop lightdm'" [Undecided,New] https://launchpad.net/bugs/1371593
<kgunn> alf_: seperate
<kgunn> alf_: haven't spoke in a while...have a nice weekend btw
<alf_> kgunn: (thanks, you too!) But it is loaded in the unity8 process, right (that's where I got the backtrace from)?
<alf_> kgunn: So it's a library used by unity8?
<kgunn> alf_: right....
<kgunn> rsalveti: so where's the best place to look for quick devel-proposed image#/date/commits ?
<kgunn> like a list
<rsalveti> ogra_'s changes list?
<rsalveti> like http://people.canonical.com/~ogra/touch-image-stats/222.changes
<rsalveti> that will at least show what was new in every image
<kgunn> rsalveti: sorry to bother...so was working on bisect, flashed image #235 devel-proposed....but
<kgunn> need to manually install unity8-autopilot
<kgunn> so...it needs to pull in a bunch of stuff
<rsalveti> right
<kgunn> but are those packages like blown away or something
<kgunn> i'm getting
<kgunn> Err http://ports.ubuntu.com/ubuntu-ports/ utopic/main python2.7 armhf 2.7.8-6ubuntu1
<rsalveti> might need to run apt-get update first
<kgunn> rsalveti: but...won't that take me to the latest ?
<kgunn> i don't want the latest...i want #235 stuff
<rsalveti> that will install the latest dependencies, yes
<rsalveti> hopefully that will not cause any issue
<kgunn> :-/
<rsalveti> but we don't store the older packages
<kgunn> well...asking for bisect ain't such a good idea then
<kgunn> this sucks
<kgunn> "hope"
<rsalveti> if the broken package is the one already available *in* the image, then it can still work
<rsalveti> I know it's not ideal
 * kgunn prepares to chase tail, wild gooses and red herrings
<kgunn> rsalveti: thanks for the info
<rsalveti> np, good luck
<rsalveti> this is painful
<kgunn> lol
<kgunn> tell me
<tvoss> morphis, ping
#ubuntu-mir 2015-09-14
<duflu> alf_: Is it possible compositor/renderer destruction no longer has a GL context?... https://bugs.launchpad.net/mir/+bug/1489720
<ubot5> Ubuntu bug 1489720 in Mir "[mako] mir_proving_server crashes on screen rotation" [Undecided,New]
<alf_> duflu: I am not aware of any change that has affected gl context lifetimes. What does eglGetCurrentContext return?
<duflu> alf_: Don't know. I'm not set up on that device right now
<duflu> Although I will be soon
<duflu> Poor mako. Batter just went from full to empty in a blink of the eye
<duflu> I think it was always empty. Because the phone doesn't shut down properly with wily. And even if your force it, it turns itself on again and drains battery
<duflu> alf_: Nope. Context not lost. Everything is sane and in context. Just that glDeleteTextures crashes. Although valgrind reports that android and the graphics driver are full of errors...
<duflu> Might be able to bisect the issue
<alan_g|lunch> alf_: any idea what's going on here? Weirdness in the mesa stack - I've a workaround, but don't understand why it works. https://bugs.launchpad.net/mir/+bug/1495459 (I'm pretty sure camako saw this last week too, but didn't have consistent results.)
<ubot5> Ubuntu bug 1495459 in Mir "Segmentation fault in MesaBufferIntegration.*" [Undecided,New]
<alf_> alan_g: let me see if I can reproduce
<alan_g> greyback_: please take a look at https://code.launchpad.net/~alan-griffiths/mir/MirBlob/+merge/269949 (I think it is what you're expecting but also see the discussion.)
<greyback_> alan_g: on my list, will get to it
<alan_g> greyback_: thanks
<alf_> alan_g: removing config.add_options(x11_displays_option_name, ...) fixes the problem. No idea why.
<alan_g> alf_: yes, I've just discovered removing "boost::program_options::value<std::string>()->default_value(std::string{"1280x1024"})," "fixes the problem too
<alan_g> alf_: This is seriously weird. But likely not mesa weirdness.
<alf_> alan_g: yes, and in particular it's the default_value() part that triggers the issue
<alan_g> alf_: thanks for confirming that
<desrt> src/platforms/mesa/server/kms/cursor.cpp #includes <drm/drm.h> which doesn't exist on debian.  changing that to <libdrm/drm.h> fixed it for me and also seems to work on ubuntu
<anpok> desrt: looking at the current drm package.. libdrm seems to be the install path preferred by libdrm
<desrt> maybe that's why debian doesn't have it?
<anpok> desrt: hm linux-libc-dev provides the other
<desrt> anpok: not on debian...
<anpok> yes we should switch to libdrm
<alf_> anpok: xf86drm already includes drm.h, so I don't think it's needed at all
<desrt> so, having some issues with mir-on-X11.  anyone can help with that?
<desrt> kgunn: ^ hi :)
<kgunn> desrt: yo...yes... camako should be helpful ^
<kgunn> it's his baby
<desrt> that's the name i was looking for.  thanks :)
<anpok> camako: knows most about it
<kgunn> he'll be happy to see someone putting it through it's paces
<desrt> camako: hey... having trouble bringing up drm for x11 because gbm: Last dlopen error: /usr/lib/dri/i965_dri.so: undefined symbol: _glapi_tls_Dispatch
<desrt> even though this does get defined (in /usr/lib/x86_64-linux-gnu/libglapi.so.0.0.0, which is loaded)
<desrt> we've sort of been chasing down one problem after another for the entire morning, and now we find ourselves here, and a bit stuck
<desrt> fwiw, it works if i LD_PRELOAD that library, but this seems like a bit of a bad solution :)
<desrt> k.  we're gonna break for lunch.  bbiab.
<camako> desrt, I haven't encountered this issue before.
<camako> desrt, what do you see when you do ...  ls /dev/dri/
<camako> card0  card1  controlD64  controlD65  renderD128  renderD129
<camako> this is what I see ^
<camako> you need the render nodes
<camako> bb after lunch
<desrt> camako: we already hit the render node issues and got past that :)
<desrt> this is a pure dynamic library problem
<desrt> btw: this is debian jessie
<camako> desrt, can you run mir with the mesa-kms? I.e. in a vt?
<desrt> camako: yes.  this is an x11 problem.
<camako> desrt, we shouldn't be using gl, only egl on mir-on-x (and gles is used in the compositor)
<desrt> it is using egl
<camako> desrt, but then why the libglapi related error? Did you build the mir binaries in the debian env yourself?
<desrt> yes
<desrt> i'm not sure it's really directly related to mir, in fact, since it's rather a problem with the dri drivers that mir tries to load
<camako> desrt, yeah.. It's curious that mesa-kms works though. Shouldn't be that different. Can you make mesa-x11 the first platform on the 'platforms' list (like in cmake-gui) and then after building, do a 'make test'?
<desrt> i built with only mesa-x11 this time, fwiw
<desrt> i also disabled tests :)
<desrt> i'll switch that back on again.  gimme a sec.
<camako> desrt, let's enable and run them
<camako> ok
<desrt> (building)
<camako> desrt, are you using lp:mir or something else?
<desrt> *ahem* something else
<desrt> the branch i am using is based on 365d58f5c662fb67dcfa352d9dcb07bc9b98783e
<camako> lol gotcha
#ubuntu-mir 2015-09-15
<tsdgeos> alf_: are you sure it's not mir leakign those fd's?
<tsdgeos> action_queue.cpp creates an eventfd that i don't immediately see being closed
<tsdgeos> same for threaded_dispatcher.cpp
<alf_> tsdgeos: not 100%, but I ran similar tests with a pure mir server and clients and there were no such leaks
<alf_> tsdgeos: @action_queue,threaded_dispatcher the fds are stored in a mir::Fd object which closes the fd on destruction
<tsdgeos> k
<ktatar156> Hello
<ktatar156> According to https://lists.launchpad.net/ubuntu-phone/msg15527.html
<ktatar156> could anyone help me asap? It's really important for me to get phone number that I mentioned in emails OTA-6 MX4 big problem
<alf_> ktatar156: We are investigating what's going on, but this seems difficult to reproduce.
<ktatar156> Ok, working again, after ~20 shutting off and on or restarting.
<ktatar156> Is there any information that I can provide?
<alf_> ktatar156: Some questions that would be helpful to answer: 1. when touch stops working, can you turn the screen on and off with the power button?
<ktatar156> Yes
<alf_> ktatar156: 2. When this happens, did you received any messages or other notifications just before?
<ktatar156> Yes
<ktatar156> But
<ktatar156> after call I put my phone into pocket. Checked it after few minutes. Try to unblock phone (entered 3 digits) and after that it stopped working
<ktatar156> WiFi off, BT off, GPS on all the time, mobile data off
<ktatar156> F###, Again. I had conversation 2 minutes ago
<ktatar156> and touch is blocked again
<ktatar156> Because It happens so many times, when I will go back into home, I will record video with that and show as many information as can
<guest42315> ktatar156, if you take a screenshot of Apps Scope (volume up + down) does the UI freezes for like 5-6 seconds?
<ogra_> alf_, there are a lot more input probs on arale ... not as bad as the above, but i often have it that an app doesnt take input at all anymore and it starts working again after i minimally swiped in the spread from the right ... and then there is bug 1494770
<ubot5> bug 1494770 in webbrowser-app (Ubuntu) "Scrolling inertia for webapps died on Meizu MX4 (stable channel)" [Undecided,New] https://launchpad.net/bugs/1494770
<ogra_> alf_, the one big difference on arale is the home button and the code to handle it ... i wonder if that causes Mir or unity input issues here
<guest42315> ogra_, something weird happened to me yesterday, opened telegram and i got the spinning circle (but not spinning) and the UI froze. i thought it's apport acting silly so i let it finish for 15 minutes. in the first 5 minutes the home button led responded to touch, and i could feel the vibrations when touching the screen with UI still frozen. after 5 minutes the touch input stoped working and i finally rebooted the phone after 15 minutes
<guest42315> mx4 stable
<ogra_> guest42315, did you try other UI elements (expanding the panel or right swipe) ?
 * guest42315 aw-food
<guest42315> ogra_,  yes, nothing worked
<guest42315> brb
<guest42315> food :P
<ogra_> enjoy
<ktatar156> guest42315, yes.
<guest42315> ogra_,  thanks :D grabbed some milk and cookies
<guest42315> ktatar156, can you please confirm/mark as it also affects you here https://bugs.launchpad.net/canonical-devices-system-image/+bug/1494480 ?
<ubot5> Ubuntu bug 1494480 in unity8 (Ubuntu) "taking screenshots locks the UI for 4-5seconds on Meizu MX4" [Undecided,Incomplete]
<ktatar156> alf_ do you need another information?
<alf_> ktatar156: no, that's enough for now, thanks. A video showing the problem would be helpful if you can get it and attach it to the bug.
<desrt> RAOF: don't suppose you're still awake :)
<desrt> so... i got this problem from mir
<desrt> terminate called after throwing an instance of 'std::out_of_range' what():  _Map_base::at
<desrt> Aborted
<desrt> and the backtrace is pretty much useless... the abort is on a thread and all i see is pthread calling libstdc++ code which is directly calling the throw/abort stuff
<desrt> probably because something nested threw the exception....
<desrt> and it got caught by the threading code and aborted from there
<desrt> any help?
<desrt> ahh... hello gdb "catch throw"
#ubuntu-mir 2015-09-16
<alan_g> greyback: I know it isn't your top priority (yet), but I'd like feedback on these questions before investing more time: https://code.launchpad.net/~alan-griffiths/mir/MirBlob/+merge/269949/comments/682826
<zzarr> hello, is there a mir version of java?
<kdub> zzarr, there arent mirclient api binding for java that I know of, although maybe a supported toolkit would have those bindings
<zzarr> okey, but xmir+java for x should work
<kdub> at that level, its more a question of whether X+java will work right, but sure :)
<zzarr> I have a Meizu MX4 Ubuntu Edition, how do I install xmir?
<zzarr> I run a stable release on it (OTA-6)
<anpok> zzarr: well if you just want to test stuff you can make the system image writable and apt-get install xmir
<zzarr> okey
<anpok> but I dont know whether the pixelformat issues were resolved yet
<anpok> robert_ancell who just left would know better
<zzarr> how do I test it?
<zzarr> okey
<anpok> you would start an Xmir instanec with: Xmir :0 -damage -mirSocket /run/user/<id>/mir_socket -mirAppId app-dialer
<anpok> oops
<anpok> s/mirAppid/mir
<anpok> and then launch an application with DISPLAY=:0 some_application
<zzarr> okey, thanks :)
<anpok> then what could possibly happen .. since there is no x window manager involved you get odd looking windows (you could launch something like unity7 though.. )
<anpok> and you application might try to access stuff that is not allowed in ubuntu touch
<zzarr> okey
<zzarr> can I use a chrooted environment?
<anpok> there is also a project called libertine that does exactly that with a container
<anpok> and ChrisTownsend and bregma work on that right now.
<zzarr> nice
<bregma> XMir on the phones is still problematic:  color format support and stray GLX calls are some of the problems
<ogra_> not to mention that it will trash your install :)
<anpok> color format is a recurring issue
<ogra_> (i.e. no proper upgrade mechanism after you installed debs ... needs re-flashing yadda yadda)
<zzarr> in that case I'll skip it until it's fixed
<zzarr> if it's not possible to run Xmir from a chroot (I think it's just a matter of bind mounting the correct file)
<anpok> i would think so too
<anpok> cairo on the phone has that color format issue too... we need a abgr support .. or was it bgra
<anpok> and of course what ogra_  said..
<ogra_> well, chroot might work. lxc container too ... (though i think you cant run lxc as user)
<zzarr> yes, sounds like what we need
<zzarr> ogra_, when's the next OTA?
<ogra_> zzarr, no idea :)
<zzarr> okey
<bregma> usermode LXC won't work on the phone because it requires a much newer kernel
<zzarr> okey, ogra_ if I change password, will that do something nasty to my pincode?
<ogra_> you mean from cmdline ?
<zzarr> yes
<ogra_> yeah, that would likely break ... you can switch the system to pw auth via the UI ... that should work then
<zzarr> okey
<zzarr> or is there a better way to make a ssh login possible with password?
<ogra_> the UI needs to know the auth method ... while the actual password db is used the UI wont give you the right input if you just change it underneath
<ogra_> oh
<ogra_> that wont work unless you hack the sshd setup
<ogra_> it is hardcoded to key auth
<zzarr> I can't change /etc/ssh/sshd_config ?
<ogra_> that is readonly and gets reverted on upgrade ...
<zzarr> okey
<ogra_> we set the configs in the ssh.override upstart job (but that will also be reverted on upgrade if you change it)
<ogra_> why not use a key ?
<ogra_> thats a lot safer
<zzarr> okey, how do I do that?
<ogra_> https://help.ubuntu.com/community/SSH/OpenSSH/Keys
<zzarr> thanks
<zzarr> I know I have asked before, but where's the wishlist for phone?
#ubuntu-mir 2015-09-17
<alan_g> alf_: your "Needs Fixing" has been addressed. OK now? https://code.launchpad.net/~andreas-pokorny/mir/libinput-package/+merge/269534
<alf_> alan_g: yes, (top) approved
<alan_g> ta
<jibel> anyone would know what the message in dbus.log means in bug 1496773 ? Is it a problem with mir ?
<ubot5> bug 1496773 in dbus (Ubuntu) "Dbus-daemon-system-fork on ota6 is using large amounts of CPU" [Undecided,New] https://launchpad.net/bugs/1496773
<jibel> it started suddenly this morning and makes the device very slow
<alan_g> jibel: mir itself doesn't do dbus
<jibel> alan_g, the dbus message refers to mir, any idea how I can find the source that triggers this message?
<jibel> davmor2, ^ when did the problem start?
<alan_g> jibel: well the Mir message says that an application is trying to connect to an invalid prompt session.
<davmor2> jibel, alan_g: this morning  uptime is in the paste-bin in the bug report,  I'd not seen any slow down till this morning
<alan_g> greyback: any idea why ^^ gets passed to dbus?
<greyback> alan_g: not a clue. does the SSO service somehow return it as an error to the dbus daemon?
<greyback> jibel: could you attach unity8.log to that bug please?
<jibel> greyback, all the logs are in https://bugs.launchpad.net/ubuntu/+source/dbus/+bug/1496773/+attachment/4466701/+files/logs.tar.xz
<ubot5> Ubuntu bug 1496773 in dbus (Ubuntu) "Dbus-daemon-system-fork on ota6 is using large amounts of CPU" [Undecided,New]
<greyback> jibel: ah nice
<alan_g> jibel: From Mir's POV when a prompt helper (the SSO) creates a prompt session it must identify the application. This is failing because Mir doesn't recognise the application (maybe it just exited). So the prompt session is rejected. No idea why failing to create a prompt session causes a dbus message (presumably from the SSO service).
<greyback> unity8 is indeed reporting online-account-service is starting and then stopping. No suggestion unity8 is interfering with it.
<jibel> alan_g, okay, thanks for the explanation.
<dandrader> anpok, ping
<anpok> pong
<dandrader> anpok, https://bugs.launchpad.net/mir/+bug/1496814
<ubot5> Ubuntu bug 1496814 in Mir "touchpad produces mouse events with zeroed relative_x and relative_y axes" [Undecided,New]
<dandrader> anpok, is that easy to fix?
<anpok> dandrader: yes I think so...
<tsdgeos> alf_: you there? i'm investigating fd leaks in uniy8 process and i'd need some help
<alf_> tsdgeos: sure, how can I help?
<tsdgeos> alf_: so the fd leaks i'm seeing now are of the type anon_inode:dmabuf
<tsdgeos> do you know where/if in mir one of those might be created?
<tsdgeos> maybe DMABufTextureBinder ?
<tsdgeos> alf_: the leaks now happen only when the process is killed because of memory pressure
<tsdgeos> i have as many leaked anon_inode:dmabuf as processes where killed my the memory pressure
<tsdgeos> unfortunately strace doesn't seem to "see" the calls that allocate those fds
<alf_> tsdgeos: these are fds backing buffer objects
<alf_> tsdgeos: that's on the desktop right?
<tsdgeos> alf_: no, phone
<alf_> tsdgeos: hmm, then I guess that's not the graphics buffers
<alf_> tsdgeos: so, DMABufTextureBinder is even there on the phone, it's in the mesa platform plugin
<tsdgeos> is -> isn't ?
<alf_> tsdgeos: "is *not* event there"
<alf_> tsdgeos: right
<tsdgeos> ok
<tsdgeos> so it's not that :/
<tsdgeos> alf_: do you have any idea what may be using dmabuf inotes?
<alf_> tsdgeos: not really, it's a general cross-device/driver buffer sharing mechanism, I am only familiar with its use for graphics buffers
<tsdgeos> ok, thanks
<tsdgeos> i'll keep trying to find out who's creating it
<alf_> tsdgeos: did you use strace -f , perhaps a subprocess is involved
<tsdgeos> alf_: but a subprocess could not create fds on the unity8 process, no?
<alf_> tsdgeos: right, thinko...
<alf_> tsdgeos: which calls are you tracking with strace (or all calls)?
<tsdgeos> alf_: all of them
<tsdgeos> the thing is
<tsdgeos> strace doesn't seem to be showing me the calls that create fds of dmabuf type
<tsdgeos> since for example i have fd 240 shown in proc
<tsdgeos> but the last time 240 shows up in the strace output
<tsdgeos> it was because it was a pipe
<tsdgeos> and was correctly closed
<alf_> perhaps they are sent to unity8 with sendmsg, does strace show fds sent this way?
<alf_> tsdgeos: ^^
<tsdgeos> i do not know
<tsdgeos> i'll check that thanks :)
<alf_> tsdgeos: also, now I am reading that android has started using dmabuf internally, so perhaps we can't rule out these being part of graphics buffers
<alf_> tsdgeos: (although at a lower level, which we don't access directly)
<tsdgeos> right
<alf_> tsdgeos: also, sometimes fd leaks are associated with memory leaks (classes holding fd resources internally, especially if the fd handling in the app is robust with RAII etc), so that's something to look out for in case the strace approach doesn't lead anywhere
<tsdgeos> totally
<kgunn> alf_: i rebooted about the time you were talking about android gfx possibly using dmabuf...curious if i missed anything
<alf_> kgunn: nothing new since then
<tsdgeos> so it's not sendmsg/receivemsg because it doesn't happen while starting apps
<kgunn> tsdgeos: on this idea of closing apps, any chance you've looked at associated screen shots in spread
<tsdgeos> kgunn: yeah getting there
<alan_g> bschaefer: your vote is "blocking" this. Do you want to reconsider? https://code.launchpad.net/~mir-team/mir/attestable-timestamps-server/+merge/270457
<bschaefer> alan_g, well i want to go through and fix the small things mentioned
<bschaefer> o wait you pushed some changes :)
<alan_g> bschaefer: just some small things
<bschaefer> yeah those changes look good
<bschaefer> anpok, braces of lambda functor? Should they be line or same line?
 * bschaefer reading through mir style
<bschaefer> alan_g, everything looks good to me, anything small can be fixed in later MPs
 * bschaefer will have to re-do the client code but shouldnt be to hard
<bschaefer> and will most likley need some changing around :)
 * alan_g thinks bschaefer will need to change "override_the_cookie_factory(mir::cookie::Secret const& secret);" to "override_the_cookie_factory(Builder<> const& builder);" to capture the secret in the builder.
<bschaefer> alan_g, well from what i understand you would store the secret before calling override
<bschaefer> at lease thats how it was done before when we kept the secret around in tests/default_server_config
<alan_g> Where would you get the first secret from?
<bschaefer> yes that'll be different
<alan_g> I think using a builder will solve it, and be more consistent with the rest of the API
<alan_g> ymmv
<bschaefer> right, just need to figure out what the builder is :)
<bschaefer> yeah we are trying to predict the future, which is fine just not 100% sure how RAOF imagined using it
<bschaefer> though this is a bit easier to predict how it *should* be used
<anpok> alan_g: there is one thing in the device settings MP.. that I still ponder about.. what would be the best way to indicate whether a setting is applicable for a device..
<zzarr> hello! I have a plan, to build a tablet/laptop 2-in-1 unit, I wish to use a strong SBC, I have looked att Hummingbird H88, wish have a A80 CPU
<alan_g> [&]() -> std::shared_ptr<CookeFactory> { ... }
<zzarr> do anyone know how "good" they are?
<anpok> that A80 is an allwinner?
<bschaefer> alan_g, cool, i see a lot of other examples in the code as well
<zzarr> anpok, yes AllWinner A80 is correct
<bschaefer> but mainly we pass in the way we want to build it (i guess?) Ill have to get a better understand once i attempt to implement it :)
<anpok> zzarr: where do you get your drivers from? and do those drivers provide access to the hardware overlays?
<alan_g> anpok: just pondering... Maybe you should be using a struct of optional fields?
<zzarr> anpok, on the page it says that it supports Android 4.4.2 and Linux 3.4.39
<anpok> alan_g: but struct might be more problematic for abi compilance?
<zzarr> anpok, but that sounds old in my ears
<alan_g> if we just add fields at the end it isn't much different to adding to vtab
<alan_g> Well, if we disable creating in user code
<zzarr> as it seams the source code for the SoC is open and some specifications http://linux-sunxi.org/images/1/10/A80_Datasheet_Revision_1.0_0404.pdf
<anpok> zzarr: driver quality is essential...
<anpok> i would look out for other projects that try to use it, and look for experiences..
<zzarr> I know, I might have to use another SoC
<zzarr> yepp
<zzarr> I'll do that
<anpok> zzarr: if you want to use mir you would have to use android drivers I guess..
<anpok> i guess the stock imagination tec winsys drivers wont let .. hmm ..
<anpok> that could be an interesting task.. not sure if the image tec winsys interface would allow you implement a mir platform ..
<anpok> alan_g: hm ok I will give it a try .. it is kind of annoying that this seems to become a growing struct.. (or structs i could split them into devices classes..)
<alan_g> anpok: I've not given it deep thought. Just been musing
<zzarr> anpok, yes, but is it a problem that it's an old version of Android?
<greyback_> bregma: can I have this added to your "sooner rather than later" list: https://bugs.launchpad.net/mir/+bug/1496814
<ubot5> Ubuntu bug 1496814 in Mir "touchpad produces mouse events with zeroed relative_x and relative_y axes" [Undecided,New]
<bregma> greyback_, sure
<greyback_> anpok: opinion would be appreciated, as that bug means our cursor handling code fails with trackpads
<anpok> nope oh I should add my thoughts on what causes this..
<anpok> -nope
<mhall119> camako: ping
<camako> mhall119, hi
<mhall119> camako: hey, I just watched https://www.youtube.com/watch?v=QCsZ2jYUTqk very cool stuff
<mhall119> I was wondering if qmlscene and QML apps can be run in a Mir on X window that way
<mhall119> and if so, how to tell qmlscene to use Mir instead of X11
<camako> mhall119, I haven't tried myself... Have you seen this? ---> https://plus.google.com/+MarcoTrevisan/posts/ZLWYfRMZWNG
<mhall119> yes, I did, and I asked Trevinho about it already, trying to get mir_demo_server working on my laptop
<mhall119> but I just want to run a single app, not all of Unity
<camako> mhall119, TBH, I haven't looked into it yet.
<Trevinho> mhall119: ah, if you only need an app, I think what's in wily should be enough to get that working
<Trevinho> Since last Mir is needed only for unity
<kgunn> Trevinho: that post is kick ass
<Trevinho> :)
#ubuntu-mir 2015-09-18
<alan_g> greyback: @MirBlob I get the impression that we're not quite in sync but I'm not yet sure where the differences are. Should we resolve in MP comments/IRC/hangout?
<greyback> alan_g: no need, am satisfied
<greyback> sorry, that thread keeps popping out of my mind
<alan_g> greyback: thanks. (I still have that niggling feeling - but that's for the future.)
<greyback> ack
<duflu> greyback: Actually I don't know how to connect clients to USC. It's the trust magic... and even when I get a connection the client exits immediately
<anpok> clients have to be fullscreen on all outputs..
<duflu> Opening session egldemo
<duflu> Mir chose pixel format 3.
<duflu> Using pixel format 4.
<duflu> Current active output is 1920x1200 +0+0
<duflu> Can't create a surface
<duflu> Closing session egldemo
<greyback> duflu: set MIR_SERVER_NAME=session-0
<duflu> greyback: K, ta
<alan_g> duflu: FWIW you can also use --debug-without-dm --debug-active-session-name <session you want to connect> for tests with USC
<greyback> alan_g: what does debug-without-dm do?
<duflu> Nope, still no luck
<alan_g> Stubs out the display manager related logic
<duflu> And it's getting late
<duflu> alan_g: You need to pass those to USC or the nested server?
<alan_g> duflu: USC
<duflu> alan_g: Yeah, no luck
<duflu> Same failures
<duflu> But I did just implement Xmir rootless resizing on desktop and phone. So that's something
<duflu> Fullscreen solitare
<duflu> FTW
<alan_g> duflu: if you're running demo server the default debug-active-session-name of "nested-mir@:/run/user/1000/mir_socket" is what you need
<duflu> alan_g: Can you email me a full working set of command lines?
<duflu> I need to start finishing up
<greyback_> MIR_SERVER_NAME=session-0 MIR_SOCKET=/run/mir_socket MIR_HOST_SERVER_FILE=$XDG_RUNTIME_DIR/mir_socket mir_proving_server &
<greyback_> that tends to work for me
<alan_g> duflu: I'll have to do that later. (Don't have a working USC built at the moment)
<duflu> alan_g: No problem. I'm using the default wily install
<alan_g> Me too
<alan_g> Guess I should just install USC
<anpok> duflu: oh xmir is now happy with the color formats on phone?
<duflu> anpok: Trunk git Xmir :)
<duflu> I guess we can do a build next week-ish
<anpok> duflu: cairo would need that happiness too
<alan_g> Hmm I used to be able to run USC with "sudo unity-system-compositor --debug-without-dm --arw-file" but now it tries (and fails) to access dbus.
<alan_g> duflu: I think that "feature" of USC is broken today
<greyback_> alf_: with display configuration, is "clone" mode something it can express?
<alf_> greyback_: yes, the (x,y,w,h) of the two displays in the virtual coordinate space just need to overlap
<greyback_> alf_: aha yes
<greyback_> thanks
<duflu> greyback_: clone mode is not always ideal though. More modes are possible that we don't have names for yet... https://bugs.launchpad.net/mir/+bug/1395416
<ubot5> Ubuntu bug 1395416 in Mir "Clone mode forces all outputs to render at the rate of the slowest one" [Medium,Triaged]
 * duflu -> weekend
<greyback_> duflu: ack
<greyback_> enjoy weekend!
<duflu> o/
<tsdgeos> guys, any idea what can cause http://paste.ubuntu.com/12449481/ on the desktop?
<alan_g> tsdgeos: not having root?
<tsdgeos> alan_g: i am root
<tsdgeos> error is
<tsdgeos> argument is not valid
<tsdgeos> or somethning like that when i translate back to enlgis
<tsdgeos> h
<alan_g> alf_: ^^?
<tsdgeos> greyback_ suggests i need to tear down lightdm?
<tsdgeos> back in aminute
<alf_> tsdgeos: are you running from a VT?
<alf_> tsdgeos: also, what exactly are you running? Is this a demo server or USC or unity8 or ...?
<tsdgeos> alf_: unity8
<tsdgeos> ok, greyback_ brought me a bit forward
<tsdgeos> i get unity8 to segfault at least :D
<tsdgeos> segfaults in mir+X11 :S
<tsdgeos> http://pastebin.ubuntu.com/12449639/
<tsdgeos> alf_: â
<alf_> tsdgeos: Can you install libmirserver33-dbsym?
<tsdgeos> on it
<tsdgeos> alf_: http://pastebin.ubuntu.com/12449714/
<tsdgeos> want me to install the dbgsym for egl and xcb too?
<greyback_> tsdgeos: could you start unity8 with MESA_DEBUG=1 EGL_LOG_LEVEL=debug - in case they print anything useful
<tsdgeos> sure
<tsdgeos> greyback_: nothing interesting i'd say http://pastebin.ubuntu.com/12449736/
<greyback_> libEGL debug: Native platform type: x11 (autodetected)  <- that's wrong
<greyback_> tsdgeos: (guess) unset DISPLAY ?
<tsdgeos> it's not set
<greyback_> yeah, was bit of a gamble that
<tsdgeos> greyback_: what should it say? kms?
<greyback_> libEGL debug: Native platform type: drm (autodetected)    <- what I get
<alf_> tsdgeos: can you please pastebin the whole log
<tsdgeos> alf_: that's the whole log :D
<tsdgeos> last line == segmentation fault
<greyback_> EGL_PLATFORM=drm
<alf_> tsdgeos: doesn't unity8/mir print anything else before crashing?
<tsdgeos> nope
<greyback_> tsdgeos: does that env var help?
<tsdgeos> greyback_: it now says drm, but still crashes :/
<greyback_> ouch
<greyback_> tsdgeos: what graphics chipset has this machine?
<tsdgeos> intel+nvidia monster
<alf_> tsdgeos: what's the output of ls /usr/lib/x86_64-linux-gnu/mir/server-platform ?
<tsdgeos> unity8@xps:~$ ls /usr/lib/x86_64-linux-gnu/mir/server-platform
<tsdgeos> graphics-mesa-kms.so.3  graphics-mesa-kms.so.4  server-mesa-x11.so.4
<alf_> tsdgeos: can you move server-mesa-x11.so.4 temporarily out of there please and try again
<tsdgeos> same thing
<alf_> tsdgeos: move graphics-mesa-kms.so.3 ?
<tsdgeos> same thing
<alf_> tsdgeos: does a demo server work?
<tsdgeos> usc is running
<tsdgeos> is that enough?
<alf_> tsdgeos: yes, although I would like to try a pure demo server in nested configuration to see if we can get more info
<tsdgeos> alf_: what do i run?
<alf_> tsdgeos: stop lightdm
<alf_> tsdgeos: do you have ssh access to that machine?
<alf_> tsdgeos: actually you don't need to stop lightdm
<alf_> tsdgeos: just switch to a VT
<tsdgeos> i'm in via ssh already
<tsdgeos> lighttdm stopped
<alf_> tsdgeos: ok, then switch to a VT
<alf_> tsdgeos: sudo bin/mir_demo_server
<alf_> tsdgeos: did you get a cursor ?
<alf_> tsdgeos: (which you can move)
<tsdgeos> yes
<alf_> tsdgeos: ok, from another ssh session: sudo mir_demo_server --host-socket /tmp/mir_socket -f /tmp/mir_nested
<alf_> tsdgeos: and from a third ssh session: sudo mir_demo_client_egltriangle -m /tmp/mir_nested
<tsdgeos> is that second thing supposed to return?
<alf_> tsdgeos: not immediately, did it output anything?
<tsdgeos> http://pastebin.ubuntu.com/12449924/
<tsdgeos> it's crashing the same as unity8
<tsdgeos> just doesn't say
<tsdgeos> but if run in gdb i get the same bt
<alf_> tsdgeos: can you please paste the log from the first mir_demo_server (the host)
<tsdgeos> where do i get it? the VT has the mouse
<tsdgeos> is it logged somewhere?
<tsdgeos> or should i kill it and start it with &> ?
<alf_> tsdgeos: no, use ctrl-alt-backspace to quit
<alf_> tsdgeos: then also start it from an ssh session (just be sure a VT is active in the target computer)
<tsdgeos> alf_: http://pastebin.ubuntu.com/12449956/ this is the first command output
<alf_> tsdgeos: ok, so could you get the backtrace of the second (nested) demo server, with egl debug symbols if possible
<tsdgeos> alf_: do i force drm with  EGL_PLATFORM=drm ?
<alf_> tsdgeos: no, let it run normally
<tsdgeos> alf_: http://pastebin.ubuntu.com/12450102/
<tsdgeos> one with xcb symbols coming
<alf_> tsdgeos: thanks
<tsdgeos> alf_: http://pastebin.ubuntu.com/12450115/
<tsdgeos> forcing drm http://pastebin.ubuntu.com/12450115/
<tsdgeos> forcing drm + valgrind http://pastebin.ubuntu.com/12450137/
<tsdgeos> and now with more symbols
<tsdgeos> http://pastebin.ubuntu.com/12450161/
<greyback_> any idea if your intel or your nvidia chip is the one being used?
<tsdgeos> in theory the intel one
<alf_> tsdgeos: is this latest wily?
<tsdgeos> alf_: no vivid+overlay
<tsdgeos> fwiw the egltriangle client has the same problem
<alan_g> FWIW the simplest client that shows anything is multiwin
<alf_> bregma: Does dual landing copy the packages from wily to vivid, or does it rebuild them from source for wily?
<alf_> bregma: sorry, I meant rebuild them from source for vivid
<bregma> alf_, it tweaks the wily changelog and rebuilds against vivid+overlay
<alan_g> alf_: nothing would work without rebuilding
<bregma> so, it's GCC-5 safe
<alf_> alan_g: yeah, I just wanted to make sure ...
<bregma> better to be sure
<alf_> tsdgeos: is there a reason you want vivid+overlay?
<tsdgeos> alf_: becuase is what we release products on
<tsdgeos> i have a wily chroot
<tsdgeos> but i'm getting
<tsdgeos> std::exception::what: Failed to find platform for current system
<tsdgeos> when running the demo_server
<alf_> tsdgeos: @products, well, not for the desktop (i think) :)
<tsdgeos> i guess it missses some stuff
<alan_g> tsdgeos: tried updating mir-graphics-drivers-desktop?
<tsdgeos> yeah
<tsdgeos> has anyone ever run mir in a chroot?
<mhall119> camako: I can't seem to get qmlscene to connect to the mir socket from mir_demo_server, any idea what I'm doing wrong?
<alan_g> I think I saw that at the PD sprint
<mhall119> mhall@mhall-thinkpad:~/projects/uReadIt/work$ MIR_SOCKET=/tmp/mir_socket QT_QPA_PLATFORM=ubuntumirclient qmlscene Main.qml --
<mhall119> Loading module: 'libubuntu_application_api_desktop_mirclient.so.3.0.0'
<mhall119> UbuntuClientIntegration: connection to Mir server failed. Check that a Mir server is
<mhall119> running, and the correct socket is being used and is accessible. The shell may have
<mhall119> rejected the incoming connection, so check its log file
<mhall119> do I need a compositor like Unity running in between mir_demo_server and qmlscene?
<camako> mhall119, default location for mir socket is the XDG_RUNTIME_DIR
<alan_g> mhall119: no. but the client needs access to the socket
<tsdgeos> ok, got it to run from the chroot
<tsdgeos> letÂ¡s try the ohter thing
<alan_g> if you run the server as root the socket is /tmp/mir_socket (but you need --arw-file on the server to make it globally accessible)
<mhall119> camako: I specified --file /tmp/mir_socket when launching mir_demo_server
<tsdgeos> alf_: wooooohooo, it works
<mhall119> alan_g: I ran the server as my user
<tsdgeos> so mir is broken in vivid+overlay for my configuration
<mhall119> srwxrwxr-x 1 mhall mhall    0 Sep 18 12:06 /tmp/mir_socket
<tsdgeos> works in wily
<alf_> tsdgeos: given that it is the same version, something mesa has changed
<alf_> tsdgeos: in mesa ..
<tsdgeos> :/
<camako> mhall119, how about mir demo apps, do they work ok?
<mhall119> camako: ah ha, they didn't at first, but after installing mir-client-platform-mesa3 they do
<mhall119> and now my qmlscene app doesn't segfault either, but still doesn't display
<camako> mhall119, is this under x?
<camako> mhall119, does the qmlscene work with the mesa-kms platform, and fail with mesa-x11?
<mhall119> camako: I'm running Unity 7, so yes under X, I don't know which mesa-* qmlscene is using
<mhall119> when I run the qmlscene app, it shows a white horizontal bar in the Mir on X window, like at hte top of the multiwin demo windows
<alan_g> mhall119: that's Mir's "title bar"
<camako> mhall119, it's the server using the platform not the app... Can you try your experiment by running the demo server in a vt?
<camako> mhall119, to rule out/confirm that it's mir-on-x
<camako> causing the problem
<mhall119> camako: how do I do that?
<alan_g> camako: could this be the intel/mesa extension that got fixed in Wily?
<camako> provide a '--vt 1' option to the demo server and run as sudo
<camako> alan_g, yeah that's what I'm thinking
<mhall119> camako: Unknown command line options: --vt 1
<camako> ??
<alan_g> mhall119: you need to specify --platform-graphic-lib /usr/lib/x86_64-linux-gnu/mir/server-platform/graphics-mesa-kms.so.4
<tsdgeos> alf_: oh well, now i know i need wily, monday more
 * tsdgeos waves
<alan_g> (Or equivalent)
<mhall119> alan_g: camako: it kind of works on vt 1
<mhall119> lots of flickering, but I can see the app's content
<camako> mhall119, I think it is due to the gles mesa extension that got fixed recently
<camako> mhall119, does your system use intel GPU?
<camako> You want to update your system to latest wily
<mhall119> camako: yes, intel
<mhall119> camako: I'm on vivid + operlay PPA
<camako> mhall119, yeah I don't think vivid has that fix
<mhall119> camako: do you know what version of the package has the fix?
<camako> mhall119, I don't exactly know what package the fix was in... some intel gpu and/or display driver.
<mhall119> camako: ok
<camako> mhall119, lemme look up the extension and then we can google it
<mhall119> is this what's causing it not to display the window on X11?
<camako> yes
<mhall119> ok
<camako> mhall119, I am pretty sure the fix is in the libegl1-mesa package... My version is libegl1-mesa:
<camako>   Installed: 10.6.3-1ubuntu1
<camako> mhall119, but for vivid, it's 10.5.* where this fix doesn't exist
<mhall119> camako: yup, I have 10.5.9, any chancce of 10.6.* going into the vivid overlay ppa?
<camako> mhall119, I don't know how these kinds of decisions are taken
<Guest30724> :( Xmir is not working for me on wily
<Guest30724> Xmir :2 --desktop_file_hint=geany.desktop
<Guest30724> oh well :(
<Guest30724> at least i get a black window :P
<anpok> -damage
<anpok> some improvements are on xmir git
<bkchr> Hi, kgunn are you online? I compiled mir on my phone, but it still doesn't work. I think that I need to compile the platform-api for my device?
<kgunn> bkchr: hey
<kgunn> bkchr: what exactly did you compile ?
<kgunn> like a different branch ?
<kgunn> or did you compile the src associate with the image you're using ?
<bkchr> ahh I see if taken the compile for pc tutorial :(
<bkchr> No, I switched the image to a newer one
<bkchr> To one from yesterday
<bkchr> I used this guide http://unity.ubuntu.com/mir/building_source_for_pc.html
<kgunn> bkchr: ah...inclding the bzr branch lp:mir bit ?
<kgunn> so that's actually our devel....
<kgunn> instead, what you might want to do is either use lp:mir/0.15 (cause that's what's in the current image)
<kgunn> rc-proposed that is
<bkchr> Running mir_demo_server I got the following http://pastebin.com/amEReypq
<kgunn> (stable would be lp:mir/0.14)
<kgunn> otherwise you could grab the src from the appropriate ppa
<kgunn> rc-proposed uses
<anpok> bkchr: runnig as root?
<bkchr> You think that switching the source would help me? :D Do
<bkchr> Yeah it's running as root
<kgunn> https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/stable-phone-overlay/+sourcepub/5379893/+listing-archive-extra
<kgunn> you'd need to download
<kgunn> mir_0.15.1+15.04.20150903-0ubuntu1.diff.gz (52.8 KiB)
<kgunn> mir_0.15.1+15.04.20150903-0ubuntu1.dsc (4.4 KiB)
<kgunn> mir_0.15.1+15.04.20150903.orig.tar.gz (1.6 MiB)
<anpok> bkchr: which device?
<kgunn> and build it from that
<kgunn> or if you're on stable
<kgunn> you'd get it from stable-snapshot
<anpok> kgunn: hm looks like hwc problem.. or broken implementation hwc set returning -1.. if that happens with lp:mir i would assume it might also happen with 0.15
<kgunn> ah
<anpok> at least that part hasent seen a lot of changes since 0.14
<bkchr> anpok: oneplus one
<kgunn> anpok: but i think bkchr is sstill mixing and matching mir's there...and gonna leat to other probs with needing to rebuild qtmir/u-s-c etc
<anpok> yes
<anpok> bkchr: here it would be interesting what parameters are passed to hwc prepare and hwc set .. because it is odd that prepare went fine and set fails..
<anpok> i guess kdub and AlbertA would be the best candidates for remote debugging
<kgunn> and actually, kdub might know how to just do a trick to skip hwc
<kgunn> and rely on gles alone
<kdub> nah, we always go through hwc these days
<kdub> unless bkchr's phone is really really old
<kdub> although, if you want to try a deprecated backup, move hwcomposer.*.so out of /system/lib/hw so mir can't find it, maybe the fb module will work
<bkchr> kgunn, so I should use either the 0.15 branch or the packages you proposed?
<kgunn> bkchr: are you on an image which is from rc-proposed ? or stable ?
<kgunn> bkchr: do system-image-cli -i
<bkchr> rc-proposed
<kgunn> ah nice
<kgunn> yeah lp:mir/0.15 will do it
<kgunn> same instructions for building otherwise
<bkchr> k
<bkchr> it's building
<kgunn> bkchr: sorry for confusion, i swear we're not trying to be difficult on purpose, that's all on accident ;-P
<bkchr> no problem^^ It already was a mess to get everything working so far.
<kgunn> i bet
<mhall119> camako: is it possible to use mirscreencast to get a screenshow of mir_demo_server?
<camako> mhall119, yes
<mhall119> I can't seem to get it to work
<mhall119> [1442605661.898312] <ERROR> MirBufferStreamAPI: Caught exception at client library boundary (in mir_buffer_stream_get_graphics_region): /build/mir-Xfl1I9/mir-0.15.1+15.04.20150903/src/platforms/mesa/client/client_buffer.cpp(63): Throw in function {anonymous}::ShmMemoryRegion::ShmMemoryRegion(const std::shared_ptr<mir::client::mesa::BufferFileOps>&, int, const mir::geometry::Size&, mir::geometry::Stride, MirPixelFormat)
<mhall119> Dynamic exception type: N5boost16exception_detail10clone_implINS0_19error_info_injectorISt13runtime_errorEEEE
<mhall119> std::exception::what: Failed to mmap buffer
<mhall119> 13, "Permission denied"
<mhall119> or sometimes just "Failed to create screencast" with no other output
<bschaefer> mhall119, you need to make sure you are using software buffer
<bschaefer> when you create the surface
<mhall119> how do I do that?
<bschaefer> o thats screencast?
<bschaefer> mhall119, are you writing a mir client atm? or just using screencast?
<mhall119> bschaefer: it's mirscreencast with -n1
<bschaefer> IIRC screencast was broken...
<bschaefer> but *should* have been fixed
<mhall119> just trying to take a picture of what it's doing
<bschaefer> but i dont remember what version fixed it :(
<bschaefer> yeah
<mhall119> bschaefer: I'mstill on vivid, maybe it's fixed in wily
<bschaefer> yeah i think duflu fixed in in 0.15 (i think?)
<mhall119> yet another reason to upgrade I guess
#ubuntu-mir 2015-09-19
<bkchr> Okay I'm back kgunn ^^ The 0.15 branch doesn't work, do you know how I can remount /system as read/write so that I can try the trick with hwcomposer*
#ubuntu-mir 2016-09-19
<alan_g> greyback: there's a couple of MirAL MPs I'd appreciate your thoughts on.
<greyback> alan_g: sure
<alan_g> greyback: you looked at better-resize-in-titlebar-wmp but didn't vote. As the current behaviour is "obviously broken" I'd like to progress the MP...
<greyback> alan_g: yes, I know. I was in middle of something else, was leaving proper review until after lunch. Hope that ok
<alan_g> greyback: that's fine. checking it wasn't forgotten
#ubuntu-mir 2016-09-22
<alan_g> greyback: will you take delivery of your order for --window-management-trace? I've already found it useful
<greyback> alan_g: ack
<greyback> alan_g: fyi qml-demo-shell now prints a table with the window stack with focus, type and state printed
<alan_g> That ought to make tracking discrepancies a lot simpler
<greyback> right
<greyback> I already see with qt apps that miral-qt thinks 2 surfaces have focus..
<greyback> and that qtubuntu needs work
<alan_g> I'm finding the gtk-mir *and* miral need work. (Am hoping to find a volunteer for the former)
<anpok> hm there are still three gtk-mir patches in flight.. that I havent updated for a couple of weeks now
<alan_g> anpok: could they affect bug 1625397?
<ubot5`> bug 1625397 in MirAL "[gtk] Focus is stuck on the save as window vs the main window" [Medium,Triaged] https://launchpad.net/bugs/1625397
<greyback_> alan_g: all approved, thank you
<alan_g> greyback_: thanks!
<anpok> alan_g: nope..
<anpok> alan_g: hm what do you mean by : "2.gtk-mir seems to impose its own input focus."
<alan_g> I mean that the server has posted events to one window and they result in updates to another
<anpok> alan_g: oh it is a dialog and and not a modal dialog
<alan_g> That's 1.
<alan_g> I need to go back and find a test case for proving MirAL gets the modal dialog wrong.
<anpok> i believe highscore dialogs in gnome games are modal
<alan_g> thanks, I'll try that
<anpok> oh found something..
<anpok> yeah there is something essential missing...
<anpok> in the window hint to mir type mapping..
<alan_g> anpok: that would explain why I can't find one. ;)
<anpok> I hope the gdk_window->"set_modal" call comes before we have to create the spec for the surface..
<alan_g> We can create another one
<alan_g> anpok: have I found my volunteer in you? ;)
<anpok> kind of .. not sure when I get around to do it..
<anpok> I feel a hurry to break the mircommon ABI as soon and as complete as possible
<alan_g> anpok: is there a place to track gtk-mir issues? Upstream? Launchpad?
<anpok> alan_g: hm I mostly start with a bug ticket in launchpad then add one in gnome bugzilla.. since this is where I submit the patches
<anpok> alan_g: i.e. like this https://bugzilla.gnome.org/show_bug.cgi?id=769554
<ubot5`> Gnome bug 769554 in Backend: Mir "[Mir] Touchpad scrolling not as smooth as it should be" [Normal,New]
<alan_g> anpok: ok
 * alan_g notices EOD flew by
#ubuntu-mir 2016-09-23
<duflu> abi-check says we removed a function from MIR_CLIENT_DETAIL_9 ... that's OK right?
<duflu> alan_g ^
<alan_g> duflu: yes(ish)
<RAOF> I would also say yes.
<duflu> It's an ABI but not as public
<alan_g> It won't break clients, the things it would break are distributed at the same time
<duflu> Indeed
<duflu> Just looks bad for our tooling as even after I fixed some minor problems 'make abi-check' fails due to it
<duflu> So you can't tell if other failures lurk after it
 * alan_g would like to reorg the code - but that would break ABIs
 * RAOF is happy to break any ABI that isn't the client ABI.
<alan_g> MirAL brings a new hope of a stable server-side ABI (but that includes getting mircommon stable)
<duflu> I would like to say it's too late in the week to think about that but I am presently looking at it
<RAOF> Re-exporting symbols is a thing, right?
<RAOF> Hm.
<alan_g> Hmm that is a thought
<duflu> RAOF: Definitely, in theory. Just need to know how with our tools
<RAOF> Actually, *why* can't we just include mircommon statically into mirclient?
<duflu> Because it's a waste of space. Also the break already happened anyway
<RAOF> I mean, we could *remove* libmircommon as a thing.
<alan_g> Because it is used by platform modules, the mirserver and mircommon
<RAOF> It's a trivial waste of space, and it simplifies our lives.
<alan_g> ODR rule
<duflu> RAOF: That solves the symbol version problems sure. But not header changes... ODR
<RAOF> alan_g: The ODR rule doesn't apply here, though?
<alan_g> Why not?
<duflu> Common sense by some other name then. Database normalization (?!
<duflu> )
<RAOF> Because there are no C++ objects in the interface between mirclient and mirserver/mirplatforms?
<duflu> libmirprotobuf is C++ but a different lib
<RAOF> I mean, it's not an ODR violation if glib internally has a class called mir::Dispatchable but it's not exported in the symbol table and never appears in the interfaces.
<duflu> Don't worry about it. We all know a fix is possible at the binary level. Just need to work out the high level syntax
<RAOF> (If that *is* an ODR violation then that's another area where C++ is insane)
<RAOF> (This might require getting rid of mirclientdetail, which exists, from memory, purely for the benefit of acceptance tests?)
<alan_g> I think also for the debug extension rubbish
<RAOF> Yeah, I'm happy to fold that in.
<RAOF> We'll have an *actual* extension mechanism *someday*.
<alan_g> One day we'll work out exactly what we need in what libraries and declare version 1
<duflu> I actually wanted to look at a version "25" but that idea fell flat when I realized mirserver is already higher :(
<duflu> How did we get here?
<alan_g> good intentions
<alan_g> Good session for the sprint?
<duflu> alan_g: Sounds like a session we've had (multiple times?) before
<duflu> Not sure I want to go through that again
<RAOF> This seems like a different session?
<RAOF> âHow can we make it so that mirclient (a) exports no C++ symbols and (b) is standaloneâ?
<RAOF> I don't think we've asked that before.
<duflu> I thought we kind of had tests for it?
<duflu> Or similar...
<alan_g> And (c) how do we make a stable server ABI?
<duflu> Making sure it doesn't re-export mircommon
<alan_g> The stuff MirAL actually uses from mircommon actually should be stable
<duflu> You can use anyone else's API/ABIs in your headers if they are version < 3. Otherwise (if they are ours) then maybe not
<alan_g> To make 3rd-party platforms viable they need a stable ABI from mircommon
<alan_g> To make 3rd-party server viable they need a stable ABI from mircommon + miral
<duflu> We break libmirplatform often too
<alan_g> Yep, all part of the big question
<duflu> BTW, I just logged some relevant bugs
<alan_g> I think we're now at a point where it is feasible, and getting important enough
<RAOF> An alternative: we ask legal to get the appropriate verbiage to make it clear that loadable platform modules *aren't* covered by the GPL, and then not expect them to link to mircommon.
<alan_g> mircommon provides stuff like "Rectangles" that we should be able to make stable
<RAOF> Absolutely.
<RAOF> Which is why having modules expect the server to supply those symbols is perfectly sensible :)
<RAOF> Actually, if mirclient stops linking with mircommon then we lose the pressure for mircommon to be the things common to client and server.
<duflu> BTW I've tried some experiments intentionally breaking things. Turns out a full wildcard * does not break existing symbols, but a partial one like ReadableFd does.
<RAOF> Which would make stripping out all the bits which *aren't* super-stable easier.
<duflu> I would also like to build one libmir* of everything with all symbols for testing, and then strip the private bits. No more object libs
<alan_g> I don't see a problem with linking to mircommon + mirplatform - we "just" need to ensure they only publish stable stuff.
<RAOF> Yeah, that's right.
<duflu> Remind me why mirplatform exists?
<RAOF> One of the current problems is that mircommon is that stable stuff, *plus* the bits shared between server and client that we actively change.
<alan_g> To define the interface between server and platform
<alan_g> (in an LGPL library)
<duflu> alan_g: Remember we have the graphics and input ABIs which are different to mirplatform
<alan_g> Follows from long discussions with legal
<duflu> Oh. Too lawyerish for a Friday
<RAOF> Yeah; again, an alternative would be an explicit grant of âno, your modules don't need to be GPLâ
<alan_g> Yeah, we'll not solve it here
<alan_g> One of the current problems is that mircommon is that stable stuff, *plus* the bits shared between server and client *and platform* that we actively change.
<RAOF> And one of the problems there is that I fully expect us to change the *platform ABI* reasonably frequently.
<duflu> Another reason why I would prefer our namespaces followed the library names... so you could also find #include "mir/common/*"
<RAOF> (For example: I don't think there's *ever* been an Xorg release that didn't change the graphics ABI)
<alan_g> I think we now have enough platforms to shake out the right abstractions
<duflu> RAOF: Xorg has the benefit of less frequent releases
<duflu> Slightly
<RAOF> duflu: Yes. I absolutely don't expect us to be bumping our platform ABI every release. But once a year seems perfectly plausible.
<RAOF> Now, our platforms are doing an easier job for us than Xorg's platforms, but still.
<duflu> RAOF: A separate stable trunk to save up those breaks?
<RAOF> Support >1 ABI.
<duflu> Or that
<RAOF> We've got it all set up so that we can (reasonably easily) do that!
 * RAOF EOD. For the moment.
<duflu> Or dinner
<duflu> alan_g: A bug that exists in mir_proving_server can't be MirAL can it?
<duflu> Or can it
<alan_g> They could have the same bug
<alan_g> But MirAL code isn't in proving_server
<duflu> Indeed
<duflu> So bug invalid for MirAL
<alf_> Saviq: greyback: Hi! How do apps tell unity8/qtmir that they want to keep the display on? Is it done through QT?
<greyback> alf_: not through Qt itself, I think people use the dbus api that powerd offers to keep the display on
<alf_> greyback: ok, how is losing focus handled?
<greyback> alf_: I *think* we trust the application to be good
<greyback> I'd need to look into it
<greyback> going off old memories here
<alf_> greyback: thanks, this came up again because I am working on the snap interface for keeping the screen on, and wasn't sure if things had changed.
<greyback> no changes afaik
<alf_> greyback: Ideally, as discussed in the past such requests should be sent to Unity8, and then unity8 can decide what to do depending on form factor, focus etc
<greyback> alf_: correct
<greyback> but nothing has happened on that front
<alf_> greyback: yeah, I will update the snap iface to work with what's currently in place and we can revisit the topic (perhaps in the sprint)
<alan_g> bschaefer: as my pointer confinement guru - could you check the miral integration? https://code.launchpad.net/~alan-griffiths/miral/confine_pointer/+merge/306635
<bschaefer> alan_g, yes!
<bschaefer> looks nice
<bschaefer> the only thing /me trying to remember if you'll need to specifically do something on a window creation spec for confinement
<bschaefer> alan_g, also how come you have to do the #if?
<alan_g> miral presents the same API/ABI on xenial as on yakkety
<alan_g> But xenial is on Mir-0.22
<bschaefer> o dang /me hopes it wont become an #if nightmere :|
<bschaefer> nightmare*
<bschaefer> alan_g, without actually testing it looks good to me (have you tried out the example?)
 * alan_g is only supporting LTS, Yakkety, and lp:mir
<alan_g> bschaefer: not yet
 * alan_g remembers not knowing what the example should do
<bschaefer> alan_g, i can re-compile and test it out after the standup
<bschaefer> alan_g, i made a mir demo :) (mir_demo_client_pointer_confinement)
<alan_g> I remember not knowing what to expect from that
<bschaefer> alan_g, o .. right well you should be able to move the red square for ever when pointer confinement is on
<bschaefer> when its off your cursor will go our of the screen boundary
<alan_g> I need something more recent that 0.24 don't I?
<bschaefer> alan_g, yeah there are some changes in 0.25 that fixed some pointer confinement issues
<bschaefer> mainly with WM stuff
<bschaefer> moving/resizing etf
<bschaefer> etc*
<alan_g> I mean for the demo
<bschaefer> alan_g, hmm i thought the demo was in 0.24 but i only have trunk mir branch /me checks
<alan_g> bschaefer: could you try it then - miral builds much faster
<bschaefer> alan_g, yeah i must have been compiling a chunk of mir not miral when i mention it the other day (took less then a min for miral)
<bschaefer> http://bazaar.launchpad.net/~mir-team/mir/development-branch/view/head:/examples/pointer_confinement.c
<bschaefer> alan_g, but yeah ill test after standup
<alan_g> bschaefer: well, it seems to do something
<bschaefer> alan_g, haha thats good (was answering an OSK)
<bschaefer> alan_g, theres hot keys to disable pointer confinement
<bschaefer> p i think
<alan_g> Yes, I had to read the code. and "F" to toggle fullscreen (What happened to F11?)
<bschaefer> alan_g, umm me breaking the standard :)
<alan_g> Yes, you ignore "close the window" too
<alan_g> ;)
<bschaefer> haha
<bschaefer> i thought i put q back in
<bschaefer> or tried to filter those events through...
<bschaefer> (do the underlying handle event)
 * bschaefer compiling now
<bschaefer> alan_g, umm invalid free / next
 * bschaefer checks things
<bschaefer> huh using 0.24 but i tihnk i compiled against 0.25 for some reason
<alan_g> I mean mir_event_type_close_surface
<bschaefer> alan_g, o ... that would have been something to use
<alan_g> It's only an example, but...
<bschaefer> yeah i like examples to be just as good as our code
<bschaefer> (mainly people look at examples to write their code)
<bschaefer_> that was strange..
<alan_g> ldconfig?
 * bschaefer_ doesnt understand joke
<bschaefer_> alan_g, i hit that mirshell session next thing
<bschaefer_> (possibly) where input didnt work but went to a tty to attempt to step through it and once i hit the tty hot keys my machine just stopped
<alan_g> bschaefer_: that's an evil bug.
<bschaefer_> yeah... im trying to get you more info
<bschaefer_> alan_g, i seem to hit it only using the x11 platform
<alan_g> then possibly one for camako
<bschaefer_> possibly just need more info before i can really poke anyone :(
<bschaefer_> a way to reproduce would be nice :)
<alan_g> yes, might mir-trunk related - which I don't use be default
<bschaefer> alan_g, very true i use trunk mir
<bschaefer> could be an ABI issue as well?
<bschaefer> no
<bschaefer> that would cause a crash...
<alan_g> *probably*
<bschaefer> i suppose if it ... somehow ABI match the bytes to a different function...
<bschaefer> haha that would be funny...
<anpok_> i think thats because the x11 platform tries to grab the keyboard?
<alan_g> probably need to ssh in from another computer
<bschaefer> alan_g, i was lucky to get into a tty for that current backtrace we have... but it froze this last time
<bschaefer> anpok_, could be, the strange thing all mouse events work fine
<bschaefer> (it just almost feels like the mir shell keeps grabbing focus ... ie keyboard grab?)
<alan_g> bschaefer: http://voices.canonical.com/alan.griffiths/2016/09/23/debugging-mir-servertoolkit-interactions/
<bschaefer> alan_g, sweet thanks i will be using this!
<bschaefer> for more debugging info for reports
 * bschaefer will be sure to include logs for reports as well
<alan_g> :)
#ubuntu-mir 2017-09-18
<alan_g> I'd not heard anything from Yunit for a while, but it is still going: https://yunit.io/yunit-project-updates-20170917/
<RAOF> alan_g: I shall miss our meeting tomorrow; at a performance by ZoÃ«. Since we'll catch up next week, that seems fine to me?
<alan_g> RAOF: ok. I guess the one question is what you think needs to land before we start 1.0 rolling?
<RAOF> alan_g: hmm. I should probably apply the same fix for hardware buffers as I did for software buffers.
<RAOF> I'll do that tomorrow morning, before hacking away further at a Wayland conformance suite.
<alan_g> OK, the thing I think needs to happen is fullscreen support. I can a poke around that.
<RAOF> Ok. You'll need to implement the obvious stub, and then send a configure event.
<RAOF> If you don't get to it today I guess I could do it tomorrow morning
<RAOF> Do the obvious thing tomorrow morning, and hope it works ð
<alan_g> OK, I'll see if I find it obvious. 8^)
<Son_Goku> congrats on getting Mir to run Wayland clients
<Son_Goku> alan_g ^
<alan_g> Son_Goku: thanks, but RAOF did the lifting on that.
<Son_Goku> does Mir still require the weird patches to mesa and libinput?
<alan_g> Son_Goku: yes, we're not yet ready to drop Mir EGL
#ubuntu-mir 2017-09-19
<RAOF> Hmm, bother.
<RAOF> My laptop appears to have lost its boot HDD.
<duflu> RAOF: As in it fell behind the couch, or failed?
<RAOF> As in failed.
<RAOF> Does not appear in the firmware menu.
<duflu> Great!
<RAOF> Set it all in fire
<greyback> RAOF: it dead? :(
 * alan_g wonders what
<RAOF> It dead
<RAOF> alan_g: the boot drive of my laptop
<RAOF> In related news, there is not an MP up fixing DRM buffers or input crashes.
<alan_g> Rotten thing to happen and rotten timing
<greyback> bah
<RAOF> Could be worse. I could be in the US already ð
<RAOF> The bandwidth from my backup server is much better here!
<alan_g> Or worse at US customs being asked to boot it
<RAOF> Heh
<alan_g> greyback: did you get a chance to see whether this fixes your scenario? https://code.launchpad.net/~alan-griffiths/mir/fix-1717910/+merge/330924
<greyback> alan_g: not yet, will look later today
<alan_g> Cool. The more testing we can do the more confident we can be about the 1.0 release.
<alan_g> greyback: updated with a version that removes the workaround for the gtk-mir bug, but works for Qt.
<greyback> alan_g: ok
#ubuntu-mir 2017-09-20
<alan_g> greyback: trying flickrview out on artful I get "module QtWebKit" not installed. Do you know which package I'm missing?
<greyback> alan_g: try qml-module-qtwebkit
<alan_g> greyback: that worked. Thanks!
<greyback> np
