#ubuntu-mir 2013-09-30
 * duflu vomits on the boost docs
<alf_> RAOF: After the latest saucy updates, any program that uses libglx crashes. Unfortunately this includes firefox, too, so I can't really do a proper search for this problem... Have you seen this?
<alf_> mlankhorst: ^^?
<alf_> mlankhorst: (btw, this is plain X not XMir)
<mlankhorst> no?
<mlankhorst> lets see..
<mlankhorst> alf_: what card? open or closed d rivers?
<alf_> mlankhorst: 5750, r600g, Xorg log: http://paste.ubuntu.com/6174634/
<alf_> mlankhorst: EGL works fine (e.g. glmark2 crashes X, glmark2-es2 works fine)
<mlankhorst> ok
<mlankhorst> wouldn't compiz crash too, then?
<alf_> mlankhorst: I am not running compiz
<alf_> mlankhorst: my WM doesn't use GL
<mlankhorst> alf_: starts for me(TM)
<mlankhorst> oh glamor
 * mlankhorst installs
<mlankhorst> still no issue with glamoregl installed :P
<mlankhorst> alf_: can you install xserver.*dbg and xserver-xorg-glamoregl-dbgsym?
<alf_> mlankhorst: sure
<alf_> mlankhorst: does glamoregl-dbgsym need a special repository?
<mlankhorst> yeah ddebs.ubuntu.com
<alf_> mlankhorst: thanks
<mlankhorst> hm doesn't exist i think, grr
<alf_> mlankhorst: the backtrace using xserver.*dbg is not more helpful...
<mlankhorst> meh, valgrind? :P
<alf_> nick alf|debugging_x
<alf|debugging_x> mlankhorst: http://paste.ubuntu.com/6174709/
<mlankhorst> string = (const char *) CALL_GetString(GET_DISPATCH(), (name));
<mlankhorst> can you try with valgrind? :P
<mlankhorst> oh missed a bunch of updates
<mlankhorst> hold on updating first then retrying
<alf|debugging_x> mlankhorst: the interesting part of the valgrind log: http://paste.ubuntu.com/6174744/
<mlankhorst> nope interesting part is the whole log :P
<alf|debugging_x> mlankhorst: whole log: http://paste.ubuntu.com/6174771/
<alf|debugging_x> mlankhorst: (all of these are produced by starting X and then glmark2)
<mlankhorst> hmz, works for me :S
<mlankhorst> do you have libgl1-mesa-dri/glx installed correctly?
<alf|debugging_x> mlankhorst: I think so, let me --reinstall them
<mlankhorst> same with whole of xserver-xorg-core and xserver-xorg-video-radeon to be sure
<duflu> alf|debugging_x, mlankhorst, Confirmed -- I get the same valgrind error/crash
<duflu> That's relatively new... only must have crept in past couple of weeks
<mlankhorst> but I don't :/
<mlankhorst> is that with usc?
<alf|debugging_x> mlankhorst: not in my case, just plain X
<duflu> mlankhorst: Using mir_demo_server_basic and connecting a Xorg to it manually
<mlankhorst> hm..
<alf|debugging_x> mlankhorst: reinstalled packages, no difference
<mlankhorst> something like Xorg :0 & DISPLAY=:0 glmark2 right?
 * duflu tries without Mir
<alf|debugging_x> mlankhorst: right, here are my package versions http://paste.ubuntu.com/6174795/
<mlankhorst> alf|debugging_x: can you remove glamoregl ?
<mlankhorst> and meh, same versions here
<alf|debugging_x> mlankhorst: removing glamoregl removes video-ati...
<mlankhorst> hm indeed
<duflu> I don't remember X being this bad in valgrind. Now I get a huge stream of uninitialized jumps from libpixman and the intel DDX
<mlankhorst> duflu: oh ignore that
<mlankhorst> intel ddx needs valgrind enabled, and it might not have been
<duflu> Dear ickle, that's slightly silly
<mlankhorst> I mean for valgrind warnings
<mlankhorst> but it should work with the most recent versions afaict
<mlankhorst> anyway I have no idea what you 2 have in common that glx fails, my system works :/
<mlankhorst> even with mir_demo_server_basic, although it has the same bug that cursor has in multimonitor, afaict..
<mlankhorst> frames that jump backwards
<mlankhorst> it happens when i only run glmark2 in the nested xorg..
<duflu> mlankhorst: The jumpy frames fix landed upstream today. Should hit the archive soon enough
<mlankhorst> ah k
<mlankhorst> anyway running only the versions in the archive doesn't seem to trigger it for me..
<alf|debugging_x> duflu: do you get the crash with plain X?
<duflu> alf|debugging_x: No. Although my system is all over the place now. Not reliably doing the same thing
<mlankhorst> meh could it be from some residual mir stuff?
<alf|debugging_x> mlankhorst: @residual mir stuff, I don't think its very likely
<mlankhorst> alf|debugging_x: meh I have no idea what's different then :/
<mlankhorst> you're on amd64 right?
<mlankhorst> alf|debugging_x: oh btw this is for your egl image branch http://paste.debian.net/47487/
<alf|debugging_x> mlankhorst: yes
<alf|debugging_x> amd64
<mlankhorst> afaict that should be the correct paths here, it still doesn't work but it looks like it's because garbage gets copied or something
<alf|debugging_x> mlankhorst: thanks
<mlankhorst> so I would try without bypass first :P
<alf|debugging_x> mlankhorst: I need to fix my development environment first :)
<mlankhorst> ok then bypass second, I guess
<mlankhorst> O:-)
<alf|debugging_x> mlankhorst: it seems that I am getting a NULL struct gl_api table..., i.e. _glapi_tls_Dispatch is NULL
<mlankhorst> hm
<mlankhorst> that's in fact possible
<alf|debugging_x> mlankhorst: arghh... for some reason glx is looking in /usr/lib/dri/... to find drivers, but the drivers are in fact in /usr/lib/x86_64/dri, creating a symlink fixes the problem...
<mlankhorst> now THAT is weird :P
<mlankhorst> I have no /usr/lib/dri either, but glx works
<mlankhorst> dpkg-shlibdeps: warning: debian/libgl1-mesa-dri/usr/lib/x86_64-linux-gnu/dri/radeon_dri.so contains an unresolvable reference to symbol _glapi_tls_Context: it's probably a plugin
<mlankhorst> I should probably link radeon_dri against libglapi now
<mlankhorst> and the other *_dri.so too
<mlankhorst> but that would only affect classic drivers
<alf|debugging_x> mlankhorst: before symlinking http://paste.ubuntu.com/6175350/
<mlankhorst> hm just why..
<mlankhorst> alf|debugging_x: somewhere something is seriously messed up, mesa is built debian/rules:   --with-dri-driverdir=/usr/lib/$(DEB_HOST_MULTIARCH)/dri \
<mlankhorst> debian/rules:   --with-dri-searchpath='/usr/lib/$(DEB_HOST_MULTIARCH)/dri:\$$$${ORIGIN}/dri:/usr/lib/dri' \
<mlankhorst> do you have anything in your environment?
<mlankhorst> env |grep usr.lib
<mlankhorst> and ldd /usr/bin/glxgears to make sure the right libgl is used
<mlankhorst> In fact you probably have a different libGL, built with static glapi. It's the easiest way to explain why _glapi_tls_Dispatch is NULL..
<mlankhorst> same for duflu I guess :P
<alf|debugging_x> mlankhorst: you are right, it seems there were /usr/lib/libGL.so* files, but I have no idea where the came from... perhaps some upgrade path is not working correctly?
<alf|debugging_x> mlankhorst: thanks for the hint!
<mlankhorst> more like ancient mir leftovers, or compiled yourself..
<mlankhorst> even precise didn't stuff libGL in /usr/lib any more
<alf|debugging_x> mlankhorst: could be, although I had been using this setup without issues before the upgrade
<mlankhorst> shrug, maybe during updates it disabled the alternative and added it again, causing it to find the old libgl or something because it was cached?
<alf_> mlankhorst: we will probably never know, I am just happy that I have a working system again...
<mlankhorst> I'm guessing leftover from egl-image testing:P
<mlankhorst> plus a bug in xorg, it seems
<mlankhorst> https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1232000
<ubot5> Ubuntu bug 1232000 in xorg-server (Ubuntu) "Xorg crashed with SIGABRT in DoGetString()" [Medium,Confirmed]
<mlankhorst> yep, crashes here too, ok lets fixup that fail..
<mlankhorst> alf_: but it looks like the glapi_tls_Dispatch thing is a separate issue :P
<mlankhorst> DISPLAY=:0 LIBGL_ALWAYS_INDIRECT=1 glxinfo
<alf_> mlankhorst: confirming that glapi_tls_Dispatch is still a problem
<alf_> mlankhorst: (confirmed)
<mlankhorst> yeah easy to reproduce like that
<mlankhorst> normally glapi is pulled in, I guess xorg-server doesn't because it doesn't use libGL
<mlankhorst> hm what does it use, though..
<mlankhorst> oh no it loads /dri/* directly
<mlankhorst> ok one line patch made
<mlankhorst> nope, weird stuff :/
<mlankhorst> afaict the dri libs deliberately do not link against shared libglapi, and xserver provides its own
<mlankhorst> meh :/
<davmor2> kgunn: Video of sf vs mir done, uploading to u1 currently will paste the link once complete.  https://pastebin.canonical.com/98152/  stop unity line here throws up the following stop: Unknown job: unity is the command correct and do I just carry on?
<kgunn> davmor2: crap...i told you wrong...stop unity8
<kgunn> davmor2: also i learned from some chatting on fri
<davmor2> kgunn: http://ubuntuone.com/78ciDgDqX8zEZfFAWs5KmW here is the video link it might take a while to download it and it's mov format so it works for me on raring no idea about saucy yet :)
<mlankhorst> alf_: wow it looks nasty
<davmor2> kgunn:   or not phablet@ubuntu-phablet:/$ stop unity8           stop: Unknown job: unity8
<kgunn> davmor2: i learned that for su phablet you want to do....sudo -u phablet -i (instead of just su phablet)
<mlankhorst> oh god it's exactly what I thought it was.. damn
<davmor2> kgunn: ah right will do
<kgunn> davmor2: sorry...should've pinged you when i learned  it :)
<kgunn> davmor2: also...i had to totally reboot...to get the state right
<alf_> mlankhorst: what did you think it was? :)
<kgunn> davmor2: if you've been su phablet'ing
<davmor2> kgunn: I wrote down the steps that I've done anyway so I'll just replicate it again with the timings now :)
<mlankhorst> alf_: interaction with glamor-egl..
<mlankhorst> rm /usr/lib/xorg/modules/libglamoregl.so is a workaround
<alf_> mlankhorst: :/
<davmor2> kgunn: overall I think mir is a good 20 seconds slower that sf on this fairly simple set of tests.  The biggest ones being app launch, indicator pull down (it's much smoother but slower because of it by the look of things) app switch is slower, rotate is slow on both but worse on mir and I'll retry the commands once the phone is back up
<kgunn> davmor2: what  image are you on? (i tried late friday afternoon...and it looked really good)
<kgunn> davmor2: but i had seen pretty awful rotation prior to that
<davmor2> kgunn: todays
<kgunn> w/ mir
<kgunn> ah...ok
<kgunn> still downloading video...
<kgunn> i should watch that first
<davmor2> kgunn: rotate is crappy on sf and mir
<kgunn> davmor2: oh yeah...and you're on maguro/galaxynexus right ?
<davmor2> kgunn: 2 vids first is mir second is sf.  I'm on maguro yes and I'm on image 70
<kgunn> i keep forgetting that
<kgunn> davmor2: galaxynexus has an omap4460 in it
<kgunn> davmor2: i managed the gfx team at ti for 5 yrs
<kgunn> davmor2: let's just say...omap4470 was a truly awesome chip...and  i would totally work on a program that used the chip
<kgunn> davmor2: omap4460....mmm....well.....
<davmor2> kgunn: I have to admit mir is a hell of a lot better just a little slower.  It's still a little jerky on app switch but everything else is really smooth
<davmor2> kgunn: haha
<kgunn> davmor2: there are some things that really effect gfx/ux there...
<kgunn> davmor2: and some secret sauce we don't have access to using binaries
<davmor2> kgunn: You can stop with the excuses already, man are you a race driver in your spare time? ;)  No I get there are issues between all the layers that need to be overcome.  There are issues on sf that don't seem to be present on mir and visa versa
<kgunn> davmor2: just lots of scar tissue (years of it) listening to people talk/complain about gfx performance that have no clue :)
<kgunn> davmor2: so thank you for understanding :) most people just throw rocks instead
<davmor2> kgunn: I'm amazed at how stable it has become and how quickly mir has been put together to be honest.   But more import for me is it's this |   | short of being a daily driver :)  rather than this much  |                                             | a couple of weeks back :)
<davmor2> typical line breaks in the wrong place but you get the idea ;)
<greyback> alf_: alan_g: question for you guys. I need to get the display geometry when a mir server isn't running. You think there's some way to fetch that information without actually running the mir server?
<kgunn> davmor2: lol....gonna use ascii art on my progress tracking
<alan_g> greyback: what counts as "running"?
<greyback> alan_g: I've not started any compositor or event handler - I've not called "run_mir"
<alan_g> You can create a configuration object and init part of the system by getting the objects you need. That doesn't start the compositor
<alf_> greyback: you could call the_display() to get the display and then get the current configuration, but keep in mind that if you release it the next the_display() call would be a different object
<greyback> alf_: that'll probably be enough. Will try
<hikiko> hey:)
<hikiko> question
<hikiko> is the include/share/mir
<hikiko> the right place to add an fd wrapper clasS?
<alf_> greyback: also note that getting the_display() brings up the display, and releasing it tears it down (i.e. there will probable be visual effects of doing so)
<greyback> alf_: this is for autopilot tests to get screen geometry before it starts running the shell. Visual flicker should be ok
<alf_> greyback: ok then
<greyback> alf_: can you think of any other way I could fetch that information?
<alf_> greyback: not really in a platform independent manner
<greyback> alf_: ok, I'll try this idea and will see
<kgunn> greyback: so that flicker will really only be associated with AP tests...not 100% of boot times
<kgunn> ?
<greyback> kgunn: only for AP
<kgunn> coolio
<davmor2> kgunn: https://pastebin.canonical.com/98223/ posted to to phablet by accident, my phone is hating your commands you know :(
<kgunn> davmor2: are you cdimage or system ?
<davmor2> kgunn: system
<kgunn> wonder if writability is an issue...
<kgunn> just a thot
<davmor2> kgunn: I'll make it rw and try again
<kgunn> davmor2: cool....just a guess
<alf_> greyback: you could probably avoid any effects by holding the_display() until mir is finished (i.e. after run_mir returns). Mir will reuse the same instance internally in that case.
<davmor2> kgunn: No it just hates me https://pastebin.canonical.com/98225/  no the touch command at the end to ensure RW was in play :)
<davmor2> s/no/note
<kgunn> davmor2: lol...crap
<kgunn> davmor2: i admittedly have seen what you see every now and then...i usually suspect myself...and reboot/reflash...and 99% it corrects
<kgunn> but wonder if something else is going on there
 * kgunn imagines the phone silently hating davmor2  while the screen is off...waiting for him to just hit the power button
<davmor2> kgunn: No hit the power button sends it into rage mode I mean it's got power then and everything :)  It quietly hates me while it is turned off :)
<mhall119_> kgunn: I'll be a couple minutes late
<kgunn> mhall119_: np
<davmor2> kgunn: no just hates me https://pastebin.canonical.com/98226/  that's all the commands so you can confirm I'm not missing something
<davmor2> kgunn: /me needs to stop playing with this now as I need my phone and I got loads to do, feel free to give me a ping if you figure something out :)
<kgunn> davmor2: will do
<kgunn> davmor2: i'll try to pester someone else on my team with a galaxy nexus...wonder if we broke something somehow
<FunnyLookinHat> I know this isn't the right place to ask about it - but maybe you guys know where it would be?  Wondering about feature-set of Multitouch on Ubuntu w/ touchscreens - specifically, a lack of two-finger scrolling ?
<FunnyLookinHat> Wow - I've never typed less of a grammatically correct sentence in my life.
<kdub> mir supports multigesture, its up to the shell and the applications to use them
<FunnyLookinHat> Ah ok - I'll take my question to #ubuntu-unity :)
<racarr> Good morning team mir
<davmor2> kgunn: looking at it another good test is to get your contacts on the phone and then scroll through them.
<davmor2> kgunn: mir might of introduced an old bug,  open 2 apps, close the one on the left, the one on the right should now replace it.  What is happening for me is it is opening the second app instead
<davmor2> kgunn: In fact you know what.  Tomorrow I might try and spend the entire day on mir and see what bugs I hit :)
<kgunn> davmor2: all good
<kgunn> appreciate it
<kgunn> racarr: mornin'
<racarr> kgunn: Morning :)
<kgunn> ok, gonna take a break and go run...
<kgunn> bbiab
<racarr> Enjoy :D
<kgunn> ok bbiab for real
<greyback> racarr: quick question, in case you know it on top of your head: you have 2 apps open. You unfocus. Then one app closes. Does Mir keep the unfocus state, or give focus to the remaining app?
<kdub> stupid darn hwc implementations
<kdub> exynos5 hwc checks that a garbage value is set in a deprecated field (and fails without error code if not set) just because surfaceflinger sets the field
<kdub> -_-
<ChickenCutlass> kdub, wow
<kgunn> kdub: good old semico software :)
<kdub> yeah... grumble grumble
<kgunn> racarr: hey, would you mind reviewing https://code.launchpad.net/~gerboland/unity-mir/whitelist-musicplayer/+merge/188387
<kgunn> ricmm: or you could ^
<kgunn> hot one...of course
<kgunn> looks simple tho
<kgunn> dandrader: ^ or you could
<kgunn> just someone holler as to who's gonna take it
<ricmm> looks fie
<ricmm> fine*
<ricmm> kgunn: I'll do some testing later and I'll get it in trunk before EOD
 * ricmm takes it
<FunnyLookinHat> Yo guys - it looks like Mir / Unity System Compositor still are only in universe ( not default ) - any idea on when  that's getting tightened up?
<FunnyLookinHat> brb
<kgunn> racarr: ping
<robert_ancell> thomi, are you working on bug 1232054 at the moment?
<ubot5> bug 1232054 in unity-mir "[mir] Need to expose geometry for autopilot consumption" [Critical,In progress] https://launchpad.net/bugs/1232054
<kgunn> robert_ancell: thomi is runing errand/appt right now afaik
<robert_ancell> k
<robert_ancell> kgunn, there were no problems with that other change yesterday?
<kgunn> robert_ancell: none that i'm aware of
<robert_ancell> kgunn, regarding duflu's email about the merging to lp:mir making it harder to bisect. I guess he's right there, the other option is just to bzr push the dev branch to lp:mir periodically. Any thoughts on that?
<robert_ancell> If we did switch to that we'd have to do a bzr push --overwrite the first time which would change the history but not the contents
<robert_ancell> Or the other option is to perhaps cherry pick each commit over and manually push them. Seems like a lot of work though
<racarr> kgunn: Ponnng sorry, IRC session was hung
<kgunn> racarr: hey was wondering if you were working on the api/support that zanetti needs to make the hud spyglass work (i think there was something else requiring that...nbut can't remember)
<racarr> kgunn: https://bugs.launchpad.net/mir/+bug/1233378 :)
<ubot5> Ubuntu bug 1233378 in Mir "Unity requires input injection API from Mir " [Undecided,In progress]
<racarr> halfway done
<racarr> :)
<kgunn> racarr: awesome! thanks...i don't mind it not being there for a day or so....kind of want to avoid an api break while we're turning on mir by default :)
<kgunn> robert_ancell: it is true...about what duflu says...
<racarr> ok
<kgunn> robert_ancell: but on the other hand...there's also no mystery where those changes are coming from :)
<racarr> I just want to get it out of the way so I can get back to API
<kgunn> so, one could easily go look at the dev branch
<robert_ancell> kgunn, yeah, and I guess it's possible to bisect inside a merge perhaps?
<kgunn> racarr: ack...no worries...you get it on dev branch and robertA and i will manage the api break
<kgunn> robert_ancell: i think this would actually be worthwhile to have a session on at the management sprint
<kgunn> e.g. why are we on sacred lp:mir/trunk
<kgunn> we should be on lp:mir/sacred
<robert_ancell> kgunn, i.e. reverse it?
<kgunn> and see if we can effect some change that way
<kgunn> robert_ancell: well...i think most engineers are bothered that "trunk" is considered sacred
<racarr> kgunn: ill come in my ripped jeans, tell the story of a poor developer forced out on to the streets through branching practices
<racarr> it will be a real sob piece.
<kgunn> :))
<robert_ancell> racarr, ha!
<kgunn> robert_ancell: i'm actually not suggesting to change anything at the moment - we should stay the course for the moment
<kgunn> just because we're finaly landing things without issue (other than duflu upset about having to dig a litte :)
<robert_ancell> kgunn, yeah, we've had enough change to confuse everyone. The current system is not great but it works for now and it's ultimately temporary
<kgunn> rigth
<kgunn> right even
<kgunn> robert_ancell: more like just a session with asac & didrocks on a proper pulling system
<robert_ancell> kgunn, yep
<kgunn> that would in effect help us in the upstream branch managemewnt
<kgunn> or management even
<kgunn> racarr: have you ever run autopilot on the phone?
<racarr> No.
<racarr> having to implement the inverse of mia::Lexicon
<racarr> ><
<kdub> at least you can have some interesting class names as a result
<kdub> mir::input::ReverseLexicon
<racarr> haha no just new methods on the lexicon
<racarr> alternatively mir::input::Leximonicon
<kdub> mir::input::Lexicant
<racarr> kdub: Which is of course the concrete implementation.
<racarr> had a misconfusion about the input dispatcher API...there is still a missing piece of machinery for the input injection
<racarr> trying to sort out which path to take...but it will take a little longer any way.
<racarr> The input dispatcher injection goes through the normal targetting interface, rather than taking a target at injection time
<racarr> adding a direct injection interface, isn't trivial, and requires mucking around with InputDispatcher a bunch
<racarr> it would be pretty easy to add like
<racarr> input_injection_mode_skip_shell_surfaces
<racarr> which works well
<racarr> but then we need, something internal to ms::Surface which indicates
<racarr> a 'shell' surface
<kdub> seems not very generic
<kdub> i guess this goes back to the central model problem
<kdub> racarr, the problem is you need to dish out input to certain clients, but we iterate over the ms::Surfaces
<kdub> ?
<racarr> kdub: Yes.
<racarr> or the alternate problem is modify the input dispatcher to support injection in a particular clients queue
<racarr> I think that may be the harder/riskier approach though
<kdub> yeah
<kdub> hmm, maybe there should be a bitmask (of sorts) that filters the input to the surfacestack
<kdub> (just musing, might be a dumb idea :) )
#ubuntu-mir 2013-10-01
 * robert_ancell -> lunch
<sarnold> does anyone know the reasoning behind the piles of these compile warnings? http://paste.ubuntu.com/6177885/
<sarnold> I would have thought that "const typet" and "typet const" would have been interchangable, but g++ is complaining that  const std::shared_ptr< msh::DisplayLayout > is different than std::shared_ptr< shell::DisplayLayout >
<sarnold> sigh, moment... const std::shared_ptr< msh::DisplayLayout >   and  std::shared_ptr< shell::DisplayLayout > const
<duflu> sarnold: I agree they look the same :/  Make sure you're using gcc 4.8 or later...?
<sarnold> duflu: this appears to be gcc-4.8_4.8.1-10ubuntu4
<duflu> sarnold: Oh, I see. You probably have not aliased "msh". Replace it with "mir::shell"
<sarnold> duflu: this is in the standard fullscreen_placement_strategy.cpp file, "namespace msh = mir::shell;
<duflu> Don't know then
<sarnold> drat :)
<sarnold> src/client/gbm/* is full of similar looking warnings..
<bschaefer> duflu, hey, i've a question, what does fullscreen mean to mir atm?
<bschaefer> ie. if we want to take a window and make it full screen (say its 1080x768 surface on a 1600x900 screen)
<bschaefer> s/window/surface
<duflu> bschaefer: The fullscreen state is "set" but not used. Our demos "fullscreen" just by setting the window size manually. The two are not wired up yet
<bschaefer> duflu, will there be an API for this? To turn the active surface fullscreen?
<duflu> bschaefer: Yes it exists, but does not affect surface size at all yet ... mir_wait_for(mir_surface_set_state(surface, mir_surface_state_fullscreen));
<bschaefer> duflu, awesome, I didn't see that when I was digging through the API :)
<bschaefer> I saw I could make the server fullscreen, by an option, but that caused some problems (crashes)
<duflu> bschaefer: Yes I agree it's confusing but you can see the function in  include/client/mir_toolkit/mir_client_library.h and the args in include/shared/mir_toolkit/common.h
<bschaefer> duflu, yeah I missed this: shared/mir_toolkit/common.h:65:    mir_surface_state_fullscreen, along with the set state
<bschaefer> that'll fix up my problem where im not sure what to do when asked to make the window fullscreen :)
<duflu> bschaefer: It will still do nothing for now.  :)
<bschaefer> duflu, but when it does, I should be safe :)
<bschaefer> duflu, O yeah, about that scroll V/H bug you made
 * bschaefer digs it up
<duflu> That comes under the heading of "surface resizing not implemented yet"
<bschaefer> https://bugs.launchpad.net/mir/+bug/1233089
<ubot5> Ubuntu bug 1233089 in Mir "MirMotionEvent can't tell which direction the mouse wheel is scrolling" [Undecided,New]
<bschaefer> duflu, Cool, hopefully when its implemented that API will stay somewhat the same
<duflu> bschaefer: You have a solution for scrolling?
<bschaefer> duflu, So I had that scroll direction implemented, but we talked that this should be handled differently, as one big problem was the event queue was being overflowed
<bschaefer> duflu, Yeah I did, then we talked about it in Denmark, and we reverted it
<bschaefer> https://code.launchpad.net/~brandontschaefer/mir/mir-vscroll-hscroll-event-data
<duflu> bschaefer: Cool, please link relevant stuff and comment
<bschaefer> duflu, i've done, but its reverted, let me make a new branch and get that back in :)
<bschaefer> It was another problem I needed to address in my own project
<duflu> bschaefer: I didn't start working on Mir until many months after Denmark... ?!
<bschaefer> duflu, hmm I swear that was Denmark ... but now that I think about it it was Okalnd
<bschaefer> Oakland*
<duflu> Yeah about then. I started immediately after
<duflu> Oh
<duflu> Oops
<duflu> No
<bschaefer> to many places with small rooms with out windows
<duflu> I had started by then
<sarnold> hehe
<duflu> It was San Mateo. Yeah :)
<bschaefer> Cool :), yeah it was more about the responsibility of what mir should be doing
<bschaefer> duflu, It was a bit ago, soo Im now forgetting the complete reason...
<duflu> Where am I now? :S
<bschaefer> duflu, O yeah, you mentioned it should be the toolkit that is responsible for it
<bschaefer> https://code.launchpad.net/~brandontschaefer/mir/remove-vscroll-hscroll-events/+merge/162284
<duflu> bschaefer: I have no opinion on the solution until I get to reviewing it :)
<bschaefer> duflu, well let me propose the old solution I had, then when a correct one comes around we can drop it :)
<bschaefer> duflu, https://code.launchpad.net/~brandontschaefer/mir/lp.1233089-fix-v-h-scroll/+merge/188498
<bschaefer> so a MirMotionEvent motion; can get the v/h scroll info by:  motion.pointer_coordinates[0].hscroll/motion.pointer_coordinates[0].vscroll
<bschaefer> duflu, though...this will break the ABI :(
<duflu> bschaefer: Possibly... That's actually less important for the server right now. But changing the structure size for clients could be a problem.
<duflu> bschaefer: Fortunately we have a few unused fields in MirMotionEvent to steal bytes from ;)
<thomi> robert_ancell: know anything about the ubuntu_platform_api_mirclient library implementation?
<bschaefer> duflu, well if I can steal 2 then this will work :), I could also use a union and only need to steal 1
<thomi> or, alternatively, know anyone who's awake right now who does?
<robert_ancell> thomi, not really
<robert_ancell> racarr, ^ ?
<bschaefer> as it can only be a vscroll xor hscroll
<bschaefer> though a union would not look very pretty :(
<duflu> bschaefer: It's generalized for any device (including those which don't exist yet) so perhaps don't assume XOR
<bschaefer> duflu, very true!
<bschaefer> duflu, We could also hold off on this bug until something else that needs to break any structures anywhere to merge this in with that?
<bschaefer> duflu, as Im assuming the ABI will have to be broken again at some point...
<duflu> bschaefer: I hope that time comes... it's a matter of project planning
<bschaefer> duflu, Right, and letting those who use Mir know when its coming I would think
<bschaefer> duflu, think again, I don't know what: touch_major; touch_minor are for in the motion struct
<bschaefer> s/think/then*
<duflu> bschaefer: Yes there's a lot of copy/paste from Android. Hence bug 1175362
<ubot5> bug 1175362 in Mir "MirMotionEvent fields lack documentation" [Medium,Triaged] https://launchpad.net/bugs/1175362
<bschaefer> Thats a good bug :), the v/hscroll bits where in there at that point haha
<sarnold> duflu: thanks for the help :)
<duflu> robert_ancell, kgunn: Should we add bug 1227739 to the phone priorities?
<ubot5> bug 1227739 in Mir "Mir continues to render application surface even when the indicator surface is on top" [High,Triaged] https://launchpad.net/bugs/1227739
<duflu> (cos I know how to solve that one :)
<robert_ancell> duflu, looking
<thomi> racarr: ping?
<duflu> sarnold: No problem
<kgunn> thomi: maybe ricmm
<thomi> ricmm: awake?
<thomi> kgunn: so I've gotten it to the point where I think it should work, but I get a segfault instead :-/
<robert_ancell> duflu, I agree with kgunn here - it's just an optimization so it doesn't need solving until we have all the other phone v1 features done
<kgunn> duflu: of course...if its done prior...its gravy
<robert_ancell> mmm gravy
<duflu> Gravy's full of wheat :/
<thomi> heh, will you look at that. segfault comes from libmirclient3 :-(
<kgunn> duflu: gluten free icing ?
<kgunn> thomi: do you need some help
<kgunn> from mir team
<duflu> kgunn: Surprisingly icing sugar is also often flour :/
<thomi> kgunn: my plan at the moment is to clean this up and push it, then send you an email
<thomi> kgunn: it doesn't look like anyone who understands the platform API is awake, so...
<robert_ancell> thomi, do you have a WIP MP?
<thomi> robert_ancell: really soon...
<thomi> robert_ancell: just doing packaging changes now. Branch is at lp:~thomir/python-ubuntu-platform-api/add-mir-pkg
<thomi> robert_ancell: will make a MP once the packaging stuff works
<thomi> robert_ancell: Mp created: https://code.launchpad.net/~thomir/python-ubuntu-platform-api/add-mir-pkg/+merge/188503
<kgunn> duflu: gotta ur nexus4 back yet ?
<duflu> kgunn: I expect it would have only just arrived there. Expect about another week :P
<robert_ancell> thomi, the segfault is in libmirclient or libmirserver?
<kgunn> thomi: is there a "here's how you run AP tests on the phone" wiki
<thomi> libmirclient3
<kgunn> duflu: bummer
<duflu> kgunn: So I reverted to Nexus7. Not quite usable for Mir but much better than expected
<kgunn> duflu: shocking really
<duflu> ... as in there's only one bug AFAIK
<thomi> kgunn: I don't think there's a wiki page. I believe most people still use the 'phablet-test-run' script
<thomi> kgunn: just doing some research for you. I believe you can run 'phablet-click-test-setup' to download all the test cases
<thomi> and then 'phablet-test-run unity8' for example to run that test suite
<duflu> kgunn: Tracking says it arrived Sydney on Friday
<duflu> Although the Australian Play Store still shows (discounted) Nexus 4 in stock
<duflu> Can we assume all touch surfaces are full screen right now? Or do they exclude the notification bar?
<duflu> -touch +phone
<bschaefer> duflu, hey, one more question :). If I set mir_surface_state_fullscreen, then when its toggle off of fullscreen should the state be set to: mir_surface_state_restored?
<bschaefer> or possibly unknown?
<duflu> bschaefer: A floating window will usually be "restored" I think
<bschaefer> duflu, hmm so thats more or less the default state of a surface?
 * bschaefer should have just checked the source for the default state :)
<bschaefer> duflu, Looks like: mir_surface_state_unknown; is getting set on the creation of a MirSurface
 * bschaefer finds that to be a strange state name...unknown...
<duflu> bschaefer: Tis correct. The state is stored in the server and the client considers the state unknown till it receives the first notification of what the state is
<duflu> bschaefer: The server won't send such a notification unless you change it I think... ?
<bschaefer> duflu, so when we want to set the state back to default, unknow it is! Sounds good, just wasn't the first thing I thought it was doing...
<duflu> bschaefer: That will probably fail. I think restored is a more sane default
<bschaefer> duflu, O, that makes sense as well :)
<duflu> bschaefer: Oh. I vaguely recall that setting unknown is know you force the server to tell you the real value. Just wait_for the set and then get the value
<duflu> -know +how
<duflu> !?
<bschaefer> duflu, well my goal is to set fullscreen when asked, thats simple
<bschaefer> the thing is once fullscreen gets toggled off, the state will still be fullscreen, so i was just wanting to go back to default in a sense
<bschaefer> duflu, Should I be setting the state on creation?
<bschaefer> duflu, Im also not sure if these things are even hammered out yet :)
<bschaefer> duflu, You're correct, if the state is unknown, then the surface gets configured when asked what the state is:
<bschaefer> http://paste.ubuntu.com/6178269/
<duflu> bschaefer: Restored is a safe bet. "Restore" means "please put the surface back how it was before fullscreen/maximize.
<duflu> "
<bschaefer> duflu, yeah, that sounds good, I just got curious on how unknown was handled :). Thanks! I should head off for the night
<bschaefer> duflu, have a good rest of your day!
<duflu> bschaefer: I don't think I intended "unknown" to be used by clients
<duflu> ...
<duflu> Good night
<bschaefer> :), well at lease it doesn't look like it should be used haha
<budgee> holla mirs
<budgee> Is Mir perhaps the reason I cannot get synergyc to connect to another synergys?
<budgee> synergyc is running on a 13.10 machine with Mir
<budgee> and synergys is running on 13.04
<mlankhorst> version difference I guess?
<mlankhorst> synergy has a debug mode that might help
<alf_> alan_g: The question is whether we should treat send failures as critical errors and close the connection, or rely on getting an error next time we try to read from the socket (as is done now). The latest version of socket-messenger-race keeps the current behavior and doesn't propagate the send errors further.
<alan_g> alf_: until recently ProtobufMessageProcessor::dispatch() handled write errors by dropping the connection. I think we should reinstate that.
<alan_g> It changed as a side-effect of suppressing a lack of error handling when sending unsolicited events to the client.
<alf_> alan_g: I agree, and also make sendmsg() (for FDs) failures throw too. Does the client handle such events properly now?
<alan_g> alf_: I've a rework of the client -side code sitting on a branch that does handle stuff correctly. Not sure about trunk
<duflu> alan_g: Not immediately required, but if you come across any documentation for asio that's actually readable (unlike the official docs) then please let us all know?... It seems very black magic
<alan_g> duflu: I was moaning about the same thing in Boston
<duflu> alan_g: My concern is that it seems like only one of us (you?) has ever figured out how it works. And that's detrimental to our maintenance efforts
<alan_g> duflu: I share your concern (and I don't have it figured out yet)
 * alan_g thinks that if he ever does figure it out an article would be a good idea.
 * duflu gets out the pen an paper; finds 12 server-side "surface" classes and counting :P
<duflu> greyback: Unity8 on Mir ... forgive my ignorance but is that finally multi-surface? And are app surfaces usually fullscreen on the phone?
<greyback> duflu: shell is single surface at the moment, work in underway to change that though. Yes app surfaces are usually fullscreen
<duflu> greyback: So the shell gets lowered or always-on-top-but-hidden?
<greyback> duflu: always on top, marks itself transparent to hide
<greyback> s/marks/makes/
<duflu> greyback: Argh. OK... so that's using Mir's hidden attribute?
<greyback> duflu: sorry no, it just makes its surface transparent, so surface underneath is visible
<duflu> greyback: Oh. That will pose a problem to my occlusion testing I guess.... unless... the whole surface has alpha==0 ?
<greyback> It does not tough the visible/hidden attribute
<greyback> duflu: no, say if launcher out, the launcher bit is fully opaque, but the rest of the shell surface is transparent
<duflu> greyback: Eeek. So I can't do occlusion testing on that. I guess I need to wait for Unity changes
<duflu> greyback: Unless there's a definitive way to identify when the top (shell) surface and launcher is hidden?
<greyback> duflu: sorry for my ignorance how, but what is occlusion testing?
<duflu> greyback: Finding out what's hidden to optimize rendering
<duflu> greyback: Final question before I go: Can I tell from Mir that the launcher is hidden by the shell surface state somehow?
<greyback> duflu: I see. Shell is doing complex things, so there's no easy way for outsider to determine what parts of the surface is opaque and not
<duflu> greyback: Well, I'm looking from inside the server, not outside. But still, will need something more efficient than testing every pixel of the surface for opacity
<duflu> That's OK, I've found more things that need cleaning up and moving around before any of that
<greyback> duflu: you could watch the input areas that the shell surface defines. Generally if it has an input area, that area is not-transparent
<duflu> greyback: Interesting heuristic but not reliable. At least not on non-touch platforms
<greyback> but that's the only way I can think mir is even aware of what shell is doing
<greyback> yep, I've nothing better to suggest, sorry
<duflu> greyback: OK, keep me posted on changes to the shell surface implementation?
<duflu> Time to make dinner!
<greyback> duflu: sure, but I expect it to be after the 1.0 release
<duflu> greyback: Yep
<greyback> bon appetit
<davmor2> kgunn: well that is my plan of using mir all day out of the window,  no sound on received calls or sms,  I'm just going to compare that with SF but I can't understand why mir would stop that
 * ricmm was making calls on Mir yesterday
<ricmm> theres is no reason for Mir to block any kind of sound, something else in your setup is probably triggering it
<ricmm> perhaps something triggered by the Mir selector, but certainly not the shell itself
<davmor2> ricmm: it's okay it dead on sf too apparently there was an issue that is/has been resolved and I might just need a new image and then I can start again
<ricmm> perfecto
<davmor2> ricmm: apparently it is an issue with the infographics stuff so it effects anything it touches, so no camera sms or phone by the look of it :(
<ricmm> wow
<davmor2> ricmm: ah usermetrics sorry, the bit that infographics gets it's info from :)
<kgunn> mornin greyback, need any help ?
<greyback> kgunn: not yet, am not out of ideas just yet
<Saviq> racarr, ping
<kgunn> tjaalton: mlankhorst hey do you guys know anything about potential open source driver roadmaps, primarily when/if opengl4 would be supported?
<mlankhorst> when we get around to it, if someone gets around to it :P
<tjaalton> kgunn: http://www.x.org/videos/XDC2013/ian_romanick_mesa_update.avi that should tell, iirc
<tjaalton> maybe next year
<mlankhorst> sarnold:  might know better than me, tbh
<mlankhorst> sarvatt*
<tjaalton> http://www.youtube.com/watch?v=Lk20sLDI1eE&feature=youtu.be
<tjaalton> better link
<greyback> alan_g: what does this error imply:   what():  bind: Address already in use
<ricmm> kgunn: ping
<kgunn> ricmm: pong
<ricmm> kgunn: hey kevin, about the autopilot stuff... Mir blows up internally when the hwc is in a blanked state upon starting
<ricmm> thats not really the shell's fault, the Mir code needs to account for this case
<ricmm> bring the hwc to a clean slate etc
<kgunn> greyback: oh crap... alan_g is out this afternoon dealing with a speeding ticket i think
<ricmm> it is possible that unity8 will crash unexpectedly at some point while the screen is blanked
<kgunn> alf_: ^ can you help greyback
<ricmm> in which case Mir needs to make sure it can account for a startup with a hwc in any state
<ricmm> the only case unity8 can protect is the oen where it has been explicity asked to quit itself
<ricmm> one*
<alf_> greyback: perhaps some left-over mir socket file?
<ricmm> its usually the left over /tmp/mir_socket yea
<kgunn> ricmm: hmmm....wonder if that's because of some discussion i saw yesterday about AP stuff, creating some objects out of order...
<ricmm> greyback: you sure its not there?
<ricmm> kgunn: its not APs fault, nor the shell
<kgunn> ricmm: i'm not saying it is
<greyback> ricmm: I get this when running shell through AP, so need to figure out why
<ricmm> greyback: only through AP?
<kgunn> ricmm: i'm saying that you're right in that we may need to put in some safety code for a new order of things
<greyback> ricmm: yep, I can run manually
<alf_> greyback: can you run in gdb and get a backtrace?
<ricmm> greyback: just strace it, you'll see the failing syscall()
<ricmm> kgunn: indeed, we need some protection when initializing the hwc to make sure it is reset to an unblanked state
<ricmm> kgunn: technically spurious ->blank() or ->unblank() calls shouldnt fail, according to API
<ricmm> but robert's code is catching it somewhere
<ricmm> im sure he can sort it in miutes
<kgunn> ricmm: well...that is semiCo code :)
<kgunn> ricmm: yeah...we have mir stand up in 45 minutes
<kgunn> kdub always makes it... racarr is a sometimes...
<ricmm> kgunn: I could join and explain if you want
<kgunn> ricmm: sounds great
<kgunn> will invite
<ricmm> perfect
<didrocks> kgunn: oh, just a note, when you merge from the dev branch to trunk, please use a better and more detailed commit message "merge from latests dev branch" isn't very informative :)
<kgunn> didrocks: ack....i can populate with aggregate commit
<didrocks> kgunn: yeah, seems to be the right strategy ;)
 * kgunn still claims victory for not breaking build :)
<om26er> The performance of Mir on Nexus 4 was on par with SF a few weeks ago, what changed? Is there a bug report somewhere ?
<om26er> davmor2, maybe you know ? ^
<davmor2> om26er: I don't have mako I have maguro which is slower anyway.
<davmor2> om26er: I took some basic videos yesterday and posted them here showing that mir was slower.  I was going to run with mir all day today but then I get no notifications about calls and messages so need to get image 75 first.
<om26er> davmor2, is 75 coming soon ?
<davmor2> om26er: as soon as all the bits required have built which isn't happening currently
<kgunn> kdub: alf_ racarr hikiko ricmm standup
<hikiko> joining kgunn
<hikiko> goodbye!
<ricmm> kdub: ping
<kdub> pong
<ricmm> kdub: http://paste.ubuntu.com/6180049/
<ricmm> you can see the last working blocking pread() on the vsync fd in line 1
<ricmm> returns in line 7 with valid data
<ricmm> line 8's returns immediately with empty data
<kdub> off the top of my head
<ricmm> and then its spuriously happening like that consuming the full CPU where that thread schedules
<kdub> that looks like the vsync signal that is polled for, which surfaceflinger uses to trigger its own composition, and sends that signal on to the clients
<kdub> we should probably disable/enable that signal on a blank
<ricmm> you dont use that signal at all?
<kdub> and i'll think about disabling it, we're getting vsync from the commit fences right now
<kdub> right
<ricmm> oh then by all means disable it
<ricmm> as it wakes the thread on vsync
<kdub> yeah, disabling it makes more sense
<ricmm> not costly, but then it causes this crap
<kdub> i might re-enable it for performance logging or something at some point though
<ricmm> is it easy to disable?
<kdub> yeah, easy
 * ricmm likes these answers
<ricmm> tell me how I can test :)
<ricmm> kdub: why are we polling for the signal anyways? or is that the hwc polling it
<ricmm> if its unused for anything in Mir I mean
<kdub> we used to use it to get vsync
<ricmm> ah ok
<kdub> and hwc10 still does
<ricmm> maguro is 1.0 ?
<kdub> right
<ricmm> hmm
<ricmm> I havent tested this breakage in maguro, although in maguro we dont blank
<ricmm> we just suspend
<ricmm> which in turn turns the hwc off and gpu, etc
<kdub> ricmm, http://bazaar.launchpad.net/~mir-team/mir/development-branch/view/head:/src/server/graphics/android/hwc_common_device.cpp#L68
<ricmm> I guess it will blow up maguro if you remove it, which we dont wanr
<kdub> turn that last argument from a 1 to a 0
<kdub> or just delete lines 68-76
<ricmm> ok
<kgunn> alf_: i'd ask duflu...since he's not on, do you know if raof/duflu actually fixed the radeon corrupt render issue ?
<kgunn> alf_: having a hard time deciphering bug correspondence
<kdub> android display creation needs some cleanup
<alf_> kgunn: the radeon issue we were seeing during the sprint (vertical black lines) has been fixed: https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1218815
<ubot5> Ubuntu bug 1218815 in xserver-xorg-video-ati (Ubuntu) "[radeon] Graphic glitches and screen corruption (vertical lines) on XMir surfaces only" [Critical,Fix released]
<alf_> kgunn: however, there seems to be a new radeon glitch: https://bugs.launchpad.net/mir/+bug/1233545
<ubot5> Ubuntu bug 1233545 in mir (Ubuntu) "Screen corruption on radeon chipset" [Critical,New]
<kgunn> alf_: thanks...arg, marked invalid for xmir...that's why
<kgunn> alf_: yeah...saw that :)
<alan_g> greyback: @"bind: Address already in use" - the socket filename is already being used
<mterry> Hello!  I'm looking at a bug with unity8-on-Mir where a frame or two of the dash can be seen before the greeter appears on screen-turn-on.  I'm told that the Mir compositor stops accepting frames when the screen is blanked.  But it seems that Mir is shutting down frames sooner than unity8 can respond to the screen-blank event and thus can't prepare the screen.  :(  Any hints?
<mterry> racarr, alan_g: ^ ?
<alan_g> mterry: not anything I'm familiar with. Sorry
<ricmm> kdub: seems to be doing the same
<ricmm> I still get the VSYNC pollers
<ricmm> perhaps they are enabled by default, what I did was remove the code
 * ricmm readds
<ricmm> kdub: http://androidxref.com/4.2.2_r1/xref/hardware/libhardware/include/hardware/hwcomposer.h#337
<kdub> yeah, we're doing that wrong
 * mterry has to run for lunch, but will be back
<kdub> ricmm, try setting to zero
<kdub> really, that thread looks like its started in registerProcs
<ricmm> kdub: so should I first disable in the eventControl before registering the thread with registerProcs?
<ricmm> perhaps it doesnt disable on the fly
<ricmm> kdub: neg this is how SF does it so should be fine
<kdub> just reading through the code for that thread
<kdub> it should be able to be disabled on the fly
<kdub> and it should start off
<ricmm> well I still see the pread()s
<ricmm> is it possible that what is disabled is the event delivery through vsync() ?
<ricmm> yet it still polls internally
<kdub> it should be waiting on a condition variable here https://github.com/CyanogenMod/android_hardware_qcom_display/blob/cm-10.1/libhwcomposer/hwc_vsync.cpp#L96
<kdub> alf_, do gbm buffers have fences?
<kdub> just wondering if mg::BufferBasic should have fence-related functions, or if that's just an android think
<kdub> thing
<mterry> Back.  Still curious if anyone knows much about Mir compositing as the screen blanks
<ricmm> kdub: im at a loss here, im clearly disabling it
<ricmm> condition is zero'd in the qcom hwcomposer
<ricmm> so that thread should block on it
<kdub> but its still not blocking? strange
<ricmm> yea
<ricmm> we shouldn't be reaching the pread at all
<bschaefer> racarr, ping
<mterry> kdub, I see you in bzr log for some HWC stuff.  Do you know much about how Mir handles blanking/unblanking the screen?  Specifically, is there an opportunity for the shell to change the screen before Mir stops accepting new frames upon a blank event?
<ricmm> mterry: the blanking is requested by the shell, so yes the shell knows when its going to unblank
<ricmm> exactly what are you trying to do?
<mterry> ricmm, requested by shell?  Not powerd?
<mterry> ricmm, I'm looking at a bug with unity8-on-Mir where a frame or two of the dash can be seen before the greeter appears on screen-turn-on.  It seems that Mir is shutting down frames sooner than unity8 can respond to the screen-blank event and thus can't prepare the screen
<kdub> well, i think powerd talks dbus to the shell, and the shell commands mir what to do
<kdub> if i understand
<ricmm> mterry: powerd -> DBus to shell -> shell out to Mir to blank
<ricmm> yup
<mterry> kdub, interesting... ideally what I'd really like to happen is "blank screen; display something on that screen; have Mir stop accepting new frames"
<mterry> ricmm, kdub: OK, will look in shell code for where we do that.  May help me figure a workaround
<ricmm> AFAIK hwcomposer blanking means the composer stops accepting frames, as well
<ricmm> so whatever you want in place needs to be there before the blanking happens
<ricmm> because also when we return to powerd, it will try to suspend (stop some pipelines, more weird behaviour(
<kdub> well, we stop the composition pass, which in effect, stalls the clients
<mterry> ricmm, seems like a jarring experience for user.  Ideally they see dash -> black -> greeter
<kdub> so seems we could display a fade (or whatever design wants) to black
<kdub> then blank
<kdub> then turn on, and start rendering a fade from black (or whatever)
<ricmm> I would believe that would be communication between shell and greeter
<ricmm> shell can hide, draw greeter and blank
<ricmm> it all happens rather quickly anyways
<racarr> bschaefer: Pong
<bschaefer> racarr, hey, sooo it looks like we want v/hscroll back into mir again :(
<bschaefer> racarr, problem, is we break the size of the event structure mp:
<bschaefer> https://code.launchpad.net/~brandontschaefer/mir/lp.1233089-fix-v-h-scroll/+merge/188666
<bschaefer> racarr, and was wondering if you have any preference to which event info we could remove to make room for v/h scroll info :)
<mterry> OK, yup.  I see chain now.  powerd calls com.canonical.Unity.Screen.setScreenPowerMode (defined in unity-mir) which calls Mir's configure_output
<bschaefer> racarr, i also need to fix that branch up...some extra stuff got into it?
<racarr> bschaefer: I don't think...at least first thought
<racarr> that we should remove another event
<racarr> to make room for v/h scroll
<racarr> sounds like eventually you have to break ABI twice
<racarr> i.e. will we want it back later
<bschaefer> racarr, true, thats another option :)
<racarr> just a big confusion
<racarr> etc
<bschaefer> yeah
<racarr> so I would rather just bump mir client ABI but maybe
<bschaefer> i can fix up the branch and wait for the next ABI break to go in
<racarr> its really not opssible anymore
<racarr> yeah I think that would be good unless its a rush
<bschaefer> missing that event info causes some things to not work, but not a rush
<mterry> greyback, so I'm looking at sequence on screen-blanking.  unity-mir receives a request from powerd to blank, then it asks Mir.  Is it reasonable to add a unity-mir signal to shell that it is about to blank, "better get any frames that you want in now"?
<mterry> greyback, maybe in Unity.Application...?
<greyback> mterry: maybe? So you want shell to be able to delay the screen blank?
<mterry> greyback, I don't know about delay, but I'd like to prepare the screen for wake-up, so that user doesn't see a frame of the dash upon wakeup before the greeter can appear
<racarr> kgunn: When can we break mirclient ABI again?
<mterry> racarr,  :)
<racarr> I have an idea
<racarr> re: mterry and greyback
<greyback> mterry: sure, I understand the problem. But how to make sure we've the right frame ready isn't obvious to me. I thought the easiest solution is for Mir's compositor to allow shell to push a few more frames after the screen has blanked...
<racarr> The problem is, the client tries to swap buffers after
<racarr> the screen blanks
<racarr> which blocks, because it cant get a new buffer, because the compositor can't display its buffer
<racarr> its old buffer
<mterry> greyback, well, we could also squeeze in a frame before blanking, same diff?  I don't know if we do it right before blanking if user would see it before screen goes dark or not
<racarr> so basically the problem is that there are these 1 or 2
<racarr> buffers in flight, 1 held by the client
<racarr> which it wants to swap
<racarr> and potentially the last one held by the compositor which it may have not gotten a chance to render yet
<greyback> racarr: could we just empty the Buffer ring for shell?
<racarr> yes, that's what I am getting at
<racarr> just cancel all the buffers, so after screen unblank
<greyback> yep, sounds ok to me
<racarr> the first swap buffers wont display anything/perhaps its some sort of error
<racarr> and then you get a buffer back, and get a chance to draw a frame
<racarr> yeah :D
<racarr> Ok
<racarr> I can't immediately work on that...
<greyback> so we'd need to somehow get to the SwitchingBundle for the shell, and call compositor_buffer on it a few times?
<ricmm> if you have no time to work on it right away, why dont we just block unity-mir blanking until the shell says "cool"
<ricmm> I can see it being just a few lines of code
<racarr> greyback: I think maybe we can use "drop_frames"
<racarr> it should be internal to the graphics backend though
<greyback> racarr: sure
<greyback> mterry: yeah, that's probably the quickest option: to unity-mir add a signal this is emittedwhen powerd asks for blanking. In unity8, connect to that signal, have the greeter slide in
<greyback> mterry: then also to unity-mir add an invokable method which actually does the blanking. Then call that function from QML after greeter slide-in animation complete
<greyback> so at least the pre-blank and post-blank visuals will be identical
<mterry> greyback: I plan to drop the slide-in animation when blanking
<mterry> greyback, so should be immediate
<racarr> but then there is just
<racarr> one frame before you blank
<racarr> that is wrong
<greyback> mterry: but then we've the problem again. There'll be some old pre-blank frames in the shell's buffer of frames, which will only be rendered after screen unblanked
<greyback> Mir does triple buffering for apps, so every app has up to 3 frames ready at any one time
<mterry> greyback, heh, you mean by making the greeter show faster, I'm making it worse?  :)
<greyback> s/apps/clients/
<mterry> greyback, guh, seems like the empty-queue method is the right way
<mterry> greyback, but that's not going to happen soon you don't think?
<racarr> I mean I can probably get to it by thursday
<racarr> I just mean I cant do it right now
<mterry> racarr, I don't think this is AAA priority
<ricmm> its not AAA priority
<mterry> racarr, it is marked for v1freeze, but doesn't need to be fixed today
<racarr> ok
<ricmm> wait a sec
<mterry> racarr, for tracking purposes, bug is 1233564
<racarr> ill mention it at the weekly meeting to confirm the approach
<greyback> racarr: yeah, good idea
<ricmm> if it will be the Mir way, then it needs to happen ASAP, because Mir has a long turnaround and it usually breaks other things
<racarr> and hopefully do it on thursday
<ricmm> if its shell it can wait as its higher level and simpler
<racarr> mir ;)
<greyback> racarr: let us know if the other Mir guys approve of it or not
<racarr> ok
<racarr> it made it in to the .org file :)
<mterry> racarr, to ricmm's point, do you know if there will be enough time afterward to land well?  When are you guys planning last drop?
<racarr> "last drop" -> *chills up spine*
<racarr> I...honestly don't know
<racarr> kgunn: ^?
<mterry> racarr, thanks btw for offering to do the work.  I've got the unity8 side of this, but would not be able to do Mir side in any reasonable timeframe
<ricmm> kdub: my bad in the end
<ricmm> disabling it does work fine
<ricmm> sorry
<racarr> mterry: No worries
<racarr> my current delegation is to be a unity<->mir bug fairy and work on the mirserver API inbetween :)
<kdub> ricmm, no problem, i'll mp a fix that disables that signal
<ricmm> kdub: thank you, make sure it doesnt break maguro
<racarr> [ RUN      ] TestClientInput.clients_receive_injected_input_per_norm
<racarr> [       OK ] TestClientInput.clients_receive_injected_input_per_norm (17 ms)
<racarr> and they like it too.
<racarr> lots of mechanical event conversion code to write + tests before motion events make it through
<racarr> but got the inject to handle mechanism established
<davmor2> kgunn: image 75 is finally with us, So I'll give mir a hammering tonight and tomorrow am and let you know what I find :)
<kgunn> mterry: racarr as to last code drop - well Oct 10 is supposed to be the cut off
<racarr> not that anyone is counting right?!?!
<racarr> >< ok thanks
<thomi> kgunn: ping?
<thomi> actualkly, nvm. read my email
<kgunn> thomi: :)
<thomi> this is such a mess. to make matters worse, I'm pretty sure I'm getting sick :-/
<kgunn> racarr: mterry it seems we almost need a compositor flush command ?
<kgunn> if i understand the scrollback correctly
<racarr> yeah
<davmor2_> kgunn: I had to stop running mir after an hour animation ground to a standstill.  Are there any logs or info that would be useful to diagnosing why and I'll try again
<kgunn> davmor2_: anything in var/crash ?
<davmor2_> kgunn: hud service crash maliit crash and a couple of others.
<davmor2_> kgunn: I'll clear it down though then run some more tests, also hud didn't work under mir but is under sf.  I'll run top and look at crash reports and grab some logs tomorrow it's getting late now :-)
<kgunn> davmor2_: yep...knew about the hud...
<kgunn> davmor2_: do you know how to unwind a crash file ?....have to download symbols
<kgunn> run apport backtrace or some such....i'll try to find the wiki...
<kgunn> but getting slammed in another channel atm
<davmor2_> kgunn no rush dude I'm calling it a night just ping me or mail me on dave.morley@canonical.com  I'll be testing in the morning now any way :-)
<kgunn> racarr: ping
<racarr> kgunn: pong
<kgunn> racarr: in unity...we think we might be screwwed on AP test enabling
<kgunn> thomi was just pointing out
<kgunn> that AP is built to just launch apps w/o shell
<kgunn> but i don't think that's possible (atm)
<kgunn> racarr: ^ ?
<racarr> part of the plan with
<racarr> this idea that only the shell would launch apps/it would verify the PIDs
<racarr> were that 1. The shell would grow a dbus interface for launching apps
<racarr> 2. upstart could be used directly by things that want to launch apps
<racarr> and unity recognizes the PID from upstart and matches them
<racarr> I don't believe 2 is implemented
<thomi> racarr: is 1. implemented?
<racarr> No, but it seems like it could be quickly
<racarr> I mean, to unblock things
<thomi> ok. We need it in like.... 30 minutes... doable?
<racarr> unity-mir could have an environment variable
<racarr> UNITY_MIR_DISABLE_SESSION_AUTHORIZER
<racarr> for test runs
<racarr> that's doable in 30 minutes :p
<racarr> god you guys scared me
<kgunn> racarr: thanks...if you could....
<racarr> I thought it was just like "none of the tests work"
<kgunn> racarr: you have no idea
<racarr> yeah will do it right now!
<thomi> racarr: so.. we'd need to export that before unity8 started?
<thomi> cos that runs inside upstart, so we'd need some upstart hacks as well
<thomi> racarr: ?
<thomi> I guess this also means that we can no longer run apps without the shell running?
<racarr> thomi: https://code.launchpad.net/~robertcarr/unity-mir/disable-authorizer-env/+merge/188717
<racarr> yes
<thomi> dandrader: veebers - you guys should probably read this conversation: ^^
<thomi> racarr: yes to which question?
<racarr> yes we need to export it before unity 8 starts
<racarr> I don't know how upstart environments work
<racarr> presumably, as this is a required in 30 minutes solution, upstart can echo UNITY_MIR_DISABLE_SESSION_AUTHORIZER=1 to /etc/some/file/that/i/dont/know/the/name/of
<racarr> and restart unity :p
<racarr> err
<racarr> upstart can echo, I mean
<racarr> autopilot can echo
<kgunn> veebers: ^ AP can echo ?
<veebers> kgunn: yep, it can shell out or write a file etc.
<veebers> I'm just reading the backlog to get context
<kgunn> racarr: https://plus.google.com/hangouts/_/16ed3d4ac7bbdd50e109aaabbce63c149b8fb526?authuser=1&hl=en
<racarr> brt
<racarr> ill brb whole system performance
<racarr> is awful
<racarr> need to restart X
<kgunn> thomi: so racarr is free ?
<kgunn> ...or we still need the UNITY_MIR_DISABLE_SESSION_AUTHORIZER=1 to /etc/some/file/that/i/dont/know/the/name/of
<racarr> seems unnnecessary because
<thomi> kgunn: We probabyl won't need that
<racarr> they have this desktop file hint workaround thing
<thomi> but lets keep it around, just inc ase
<thomi> thanks for that though racarr :)
<racarr> ok, leaving for space burning man, see you guys in a month.
<kgunn> :))
<racarr> ...:p
<racarr> back to input injection
<racarr> 80% done
<racarr> reversing the lexicon and the assosciated tests is turning out to be really tedious
<Saviq> racarr, btw, bug #1233245 - known issue?
<ubot5`> bug 1233245 in unity8 (Ubuntu) "Volume up/down keys not working with Mir" [High,Incomplete] https://launchpad.net/bugs/1233245
<racarr> Saviq: new to me
<Saviq> racarr, we're not getting any VolumeUp / VolumeDown keys - neither when there's an app in focus or not
<Saviq> racarr, also, the fact that if you try starting unity8 when screen is blank results in "cannot unblank screen" and then you need to reboot, otherwise "address already in use" happens?
<racarr> second one sounds like a stale unity 8 process is lingering
<racarr> not sure what is supposed to happen when multiple procsses try and useHWC
<racarr> first one...I think ugh
<racarr> there may be an issue with unity8 actually getting key events because of the way its input areas work
<racarr> its pretty unlikely that it would have key focus...
<racarr> I guess, the first step would be to ensure mir_demo_server_input_filter produces key events on volume up/down but im almost certain it does (it certainly used to)
<racarr> then to ensure a normal Qt client can receive them
<racarr> and if so then the shell just isn't getting focus
<racarr> but maybe they are getting lost in the Qt keymapping (As an example) which isn't tested much because OSK shortcircuits it
<racarr> Saviq: probably the absolute first thing to try is run unity8 with MIR_SERVER_INPUT_REPORT=log and MIR_SERVER_LEGACY_INPUT_REPORT=log
<racarr> and see how far the events get
<racarr> ill start updating my phone ;)
<racarr> but I can't spend a bunch of time on it right now, I need to power through this input injection thing
<racarr> so we can get the HUD going
<Saviq> racarr, yeah, k
<racarr> mzanetti: Needs another hour or two of work before it can land but this should work: https://bugs.launchpad.net/mir/+bug/1233378
<ubot5`> Ubuntu bug 1233378 in Mir "Unity requires input injection API from Mir " [Undecided,In progress]
<racarr> rtt
<racarr> err
<racarr> https://code.launchpad.net/~robertcarr/mir/input-injecter-api/+merge/188743
<sarnold> hrm, what does the #ifdef ANDROID _really_ mean here, and why does ANDROID platform not have std::make_shared? http://paste.ubuntu.com/6181654/
<racarr> sarnold: IT means is mir built with MIR_PLATFORM=android, i.e. are we using the android graphics drivers
<racarr> android does have make_shared, the code is a little tricky to parse, on android it is returning a new instance
<racarr> of the MirNativeBuffer object
<racarr> on not android (GBM or nested) it is returning an empty shared pointer (null) of type MirNativeBuffer
<racarr> "returning a new..." -> "returning a pointer to a newly allocated instance"
<sarnold> racarr: thanks :)
<thomi> racarr: still awake?
<thomi> kgunn: the next issue seems to be input related - the autopilot input emulators don't have any effect on the launched applications.
<thomi> as in, we try and tap on a button, and nothing happens
<thomi> python
<thomi> dammit, wrong window again
<thomi> robert_ancell: who else can I ping about this?
<racarr> thomi: oi
<thomi> oh, you are awake :)
<thomi> racarr: so.. any time I try and use the UInput touch driver that autopilot has, a big fat nothing happens on the screen
<racarr> ok that is supposed to be synthetic udev devices right?
<thomi> yes, essentially it's a user-space udev driver
<racarr> It should work, so the first step is really to get MIR_SERVER_INPUT_REPORT=log and MIR_SERVER_LEGACY_INPUT_REPORT=log
<racarr> then we should be able to see if the devices are loaded/recognized
<racarr> and what happens
<thomi> so, I should set those before starting unity8, and then paste you the unity8 log file?
<thomi> I suspect the problem is that the udev device node only gets created when autopilot creates the touch device, which is long after the shell has started
<thomi> does that sound plausible?
<racarr> about pasting the log file and startying unity8: Yes :D lets get stderr and stdout
<racarr> about the theory: It's plausible but device adding/removing should work
<thomi> OK, I'll do that now
<racarr> cool
<racarr> we should have a MIR_DUMP_EVERYTHING_THAT_MAYHAPS_BE_USEFUL_FOR_DEBUGGING
#ubuntu-mir 2013-10-02
<thomi> racarr: ok, log incoming
<thomi> racarr: http://paste.ubuntu.com/6181800/
<thomi> racarr: I don't see any mention of the uinput device
<thomi> racarr: which is called 'autopilot-finger' BTW
<thomi> racarr: in that log, the input events are me unlocking unity8 with my finger
<thomi> no autopilot
<thomi> I wonder about these two lines:
<thomi> [EE, android-input] [EventHub]could not open /dev/input/event6, Permission denied
<thomi> [EE, android-input] [EventHub]could not open /dev/input/event7, Permission denied
<thomi> yeah, so when we create the autopilot touch driver, even6 and event7 appear on the /dev/input folder
<racarr> thomi: i would say thats almost certainly it
<thomi> not sure why we get 'Permission denied' though, the permissions on those device nodes are identical to all the others
<racarr> I guess unity8 isnt run with root, but something sets the permissions on the /dev/input nodes it needs to something it can use
<racarr> group?
<racarr> apparmor?
<racarr> secret-security-framework-number-9
<thomi> group is all the same, android_input
<thomi> who would I talk to about apparmor?
<racarr> I dunno
<thomi> Jamie maybe, if he's still awake
<racarr> I bet ricmm would know more than me
<racarr> ricmm_: ^ ?
<racarr> maybe its a race with setting the permissions
<racarr> and opening hte device
<racarr> I dont know
<racarr> where the permissions
<racarr> comes from
<kgunn> thomi: good grief...
<kgunn> i mean how did that work prior to mir....shoulda been the same right
<thomi> kgunn: racarr, OK, I've eliminated apparmor as a culprit
<thomi> racarr: are you able to see what would cause that permission denied error in mir?
<racarr> its the same error you get if you urn it on the desktop without
<racarr> permissions to open the /dev/input devices
<racarr> looking
<thomi> I see it's in EventHub.cpp:961
<racarr> Mm
<racarr> errno doesnt lie
<racarr> permission is denied
<racarr> (kind of catchy when you say it outloud)
<thomi> but...
<thomi> http://pastebin.ubuntu.com/6181858/
<thomi> what. thefuck. is. goingon!?
<thomi> robert_ancell: does mir drop priviledges after starting up?
<thomi> oops, I meant racarr ^
<thomi> like, maybe when it loads initially, it's running as root, but then it drops to being run as a user that isn't root or in the android_input group?
<racarr> not that I know of
<robert_ancell> thomi, it does not
<thomi> bums
<racarr> is it possible the devices are being probed after mir opens , mir tries to open them fails, gives up, then they get given
<racarr> the appropriate permissions?
<thomi> I'll try creating the devices first, then starting mir
<sarnold> are there devices that refuse O_RDWR but work fine for O_RDONLY ?
<kgunn> thomi: any luck
<thomi> kgunn: long answer: check out #ubuntu-touch scrollback. short answer, no luck at all. Have managed to stump several people much smarter than I am :-/
<kgunn> thomi: i see you are basically left to contemplate the infinite in #touch...can you summarize where you are, maybe duflu in his inifinite linux device wisdom might have some tricks
 * duflu thinks you have the wrong name there
<thomi> kgunn: sure
<thomi> actually, I should probably file a bug so my progress is not lost to the grey mist I'm happy to call my memory
<kgunn> thomi: so this same thing works in SF ?
<thomi> yup
<thomi> just writing up a bug report. Will be done in a few minutes
<kgunn> thomi: hmmm....by removing sf, could something not be setting wider permissions that should?
<duflu> Thank you for not continuing the tradition of bugs that only exist in IRC
<thomi> we looked pretty exhaustively at permissions
<thomi> duflu: :)
<thomi> this is a big one
<kgunn> ditto to the documenting it in a bug
<duflu> robert_ancell: Please stop removing distro tasks. They are absolutely required where bugs are reported against distro, and fixed in distro
<robert_ancell> duflu, none of the other bugs have distro tasks and all mir bugs affect distro. There's no need to duplicate entries
<duflu> robert_ancell: They're not duplicate. They clearly delineate where a fix is upstream or in distro
<duflu> Launchpad is designed that way
<robert_ancell> duflu, in the case of mir upstream == distro
<duflu> robert_ancell: Not true. Our upstream fixes are usually days (or weeks) ahead of distro. And after we branch properly, months
<duflu> Hence you need separate tasks
<robert_ancell> duflu, when it's marked fixed released it's in distro
<duflu> robert_ancell: No, that means fix released upstream (usually as a tarball). Hence Fix Released upstream often happens after distro in reality
<robert_ancell> duflu, in reality our releases are done automatically and straight into distro. There's no tarballs
<duflu> robert_ancell: You can't make up your own rules different to the rest of Ubuntu. People need and expect ubuntu tasks to know what's going on
<robert_ancell> duflu, you can, we have, there's no point making ensuring ever bug has both an upstream and ubuntu task open on it. All Mir bugs are Ubuntu bugs, we've decided to track them all in the upstream tracker
<thomi> duflu: kgunn, anyone else who cares: this is what I've been bashing my head against all day: https://bugs.launchpad.net/mir/+bug/1233944
<ubot5> Ubuntu bug 1233944 in Mir "Unity8/Mir is unable to open autopilot uinput devices" [Critical,New]
<duflu> robert_ancell: Anyone who uses Ubuntu and Launchpad knows that fixed in "Mir" does not mean fixed in "Ubuntu". We need to communicate more clearly and there's a simple protocol in place. Why not just make the bugs *accurate* ?!
<kgunn> robert_ancell: racarr (if you're on) kdub ^
<thomi> I will purchase many drinks for the person who solves this for me
<duflu> robert_ancell: If you want, I will do it. I do so anyway. I just can't stand working in an environment where even the information describing what we're doing is wrong
<robert_ancell> duflu, I'd say most people who use Launchpad don't know or care about the distinction between upstream and downstream tasks. The bugs are accurate.
<robert_ancell> duflu, no, it's a huge amount of pointless paperwork
<duflu> It's not huge, and it has a very clear purpose. Launchpad's bugs a multidimensional for good reason
<robert_ancell> duflu, they were done like that because there was a large number of components that have different upstreams and downstreams. In this case that has not occurred. The software center team used this practise because it made things much easier and it matches my experience too
<thomi> I gotta go walk in the pouring rain to clear my head for a bit. When I get back, I expect to see a bugfix waiting for me ;)
<thomi> brb
<robert_ancell> thomi, I'm looking at this bug but you probably know more about the input layer than me
<robert_ancell> thomi, I'm a little unsure of what you mean in the report - does Mir never get input from these devices or only if they are created before Mir starts?
<thomi> robert_ancell: mir is only able to open the devices if they exist before mir starts
<robert_ancell> thomi, and you get the input events from them?
<thomi> robert_ancell: well, I never got that far, but the open() call doesn't fail, which is what's happening in the error case
<robert_ancell> thomi, so the bug essentially seems to be "mir fails to hotplug input devices"?
<thomi> I guess so
<kgunn> thomi: robert_ancell ...ok thinking aloud (and yes i'm a manager i'll try not to hurt myself)
<thomi> robert_ancell: feel free to change the bug title :)
<kgunn> but...it bothers me this is "3rd party code"..so i dig around in cynagenmod
<robert_ancell> thomi, can you show me the code that creates the devices?
<thomi> robert_ancell: sure... one second
<kgunn> it seems that eventhub.cpp is built into either libui or libinput
<robert_ancell> thomi, wondering if they're created with wrong permissions and then they're updated (just a guess)
<kgunn> depending on when the change happened
<thomi> robert_ancell: well, we use uinput, and the uinput system creates the actual event* devices
<kgunn> so could one of these libs that is actually in the device be causing this? with some primordial android input setup code
<thomi> robert_ancell: http://bazaar.launchpad.net/~autopilot/autopilot/trunk/view/head:/autopilot/input/_uinput.py#L192
<kgunn> e.g. just like surfaceflinger would fight with mir over the display....maybe one of these is fighting mir for the input dev
<thomi> basically, work out the device capabilities, and hand it all off to the kernel
<robert_ancell> thomi, can you reproduce on the desktop or just the phone?
<thomi> robert_ancell: I haven't tried on the desktop. Should I just run mir_demo_server, or something more complicated?
<robert_ancell> thomi, that should be fine, you're just looking for the error message when they're created
<thomi> ok, need to install some things first...
<kgunn> thomi: reading your instructions...cd ~/autopilot, is that on the device ?
<thomi> kgunn: yes
<kgunn> ah i see it...forget to run setup after i reflashed
<thomi> kgunn: that directory gets created when you run phablet-click-test-setup
<thomi> yeah
<thomi> robert_ancell: so I'm having problems testing mir on the desktop since I don't currently have a second machien to SSH into the first one, so I can't create the uinput devices after mir starts
<robert_ancell> thomi, ah - what do I need to install to test it here?
<thomi> robert_ancell: python-autopilot
<robert_ancell> thomi, the archive one or a branch?
<thomi> robert_ancell: archive is fine
<thomi> make sure you export those mir env vars :)
<robert_ancell> thomi, I can just run the contents of create_touch_device() to test this right?
<thomi> robert_ancell: probably, yes
<robert_ancell> (trying to break this down to the simplest repeatable case)
<thomi> I usually just start the python interpreter, and write:
<thomi> from autopilot.input import Touch; t = Touch.create()
<thomi> simple enough for me :)
<robert_ancell> ta
<robert_ancell> brb
<robert_ancell> thomi, seems to run fine on desktop
<robert_ancell> thomi, but u-s-c is being run as root, the shell on the phone is being run as a user account right?
<kgunn> thomi: as part of the instructions in the bug...do you assume they've loaded your python-ubuntu-platform-api deb ?
<thomi> kgunn: ahhhh yes!
<thomi> kgunn: thanks for that
<thomi> robert_ancell: yesh, that's correct
<thomi> kgunn: will update the bug now :)
 * kgunn wonders if yesh is a michael scott/office reference
<thomi> kgunn: bug updated
<robert_ancell> heading out for 20 mins...
<kgunn> thomi: should that same example AP test (ubuntu ui tookit) run on SF even with the new deb installed ?
<thomi> kgunn: yes
<thomi> kgunn: are you saying that it doesn't?
<kgunn> thomi: verifying that now...
<ricmm_> thomi: can you try with apparmor=0 passed to the kernel?
<ricmm_> you can probably looking into our flash-kernel script to see how it constructs a blob with command line to flash
<ricmm_> if that fails, make sure you put everything in the bug
<ricmm_> and ill pick it up in the AM EST
<thomi> ricmm_: we ruled out apparmor
<thomi> I'm about to EOD, but the bug is pretty well documented
<ricmm_> DENIED in syslog is not enough to rule it out
<thomi> oh?
<ricmm_> ruling it out is apparmor=0 in the kernel command line
<ricmm_> some things are silent, or at least im told so :)
<thomi> huh.. that's not what the apparmor guys said earlier. OK, so how do I chaneg the kernel parameter on the phone?
<ricmm_> look into the flash-kernel script
<ricmm_> but if you are about to EOD, go EOD
<ricmm_> ill look into it tomorrow
<ricmm_> midnight here
<thomi> ricmm_: 'flash-touch-kernel'?
<ricmm_> indeed
<ricmm> anyways you've put enough in the bug, update with the apparmor result or just go and ill try it tomorrow
<thomi> ok
<thomi> I'll try and figure this script out, or eat dinner, whichever happens first :)
<kgunn> thomi: i get https://pastebin.canonical.com/98327
<thomi> kgunn: you need to be the phablet user: sudo -i -u phablet
<thomi> kgunn: adding that bit of infomration to the bug as well :)
<kgunn> gah
<kgunn> thomi: op now i get the awesome testibilty arg prob
<thomi> kgunn: the fact that you get a warning is not necessarily a sign that something broke. post your output somewhere?
<kgunn> https://pastebin.canonical.com/98328 thomi
<kgunn> again this is still just running with surface flinger
<kgunn> stepping away to get a drink to stay awake
<thomi> kgunn: you need to download https://raw.github.com/akkana/scripts/master/termsize and run it - get your terminal back :)
<thomi> I mean that as an aside, it won't fix your problem
<thomi> but it will make you less suicidal while developing on the phone :)
<thomi> kgunn: hte unknown option is a red herring. Your actual problem is this: MismatchError: After 10.0 seconds test on Standard.selected failed: True != dbus.Boolean(False, variant_level=1)
<thomi> kgunn: I'm *sure* this worked for me earlier today... let me reboot & double check
<thomi> kgunn: ahhh, you need to unlock the shell before you run the test
<thomi> kgunn: yeah, that'll be it
<thomi> OK, I gotta go help with dinner
 * thomi -> BBL
<kgunn> thomi: so how to unlock the shell ?
<kgunn> thomi: nvmd i see you updated
<kgunn> thomi: ok...totally works
<thomi> kgunn: :)
<kgunn> thomi: did you have any trouble with the mir logging...i'm running ok (expected failure on mir) but don't get the input log after the env setting
<kgunn> ...and yes i was sudo -u phablet -i when i set the env variables
<thomi> kgunn: nope, it just worked for me
<thomi> kgunn: note that if you're running unity8/mir under upstart you need to use initctl set-env,  otherwise, if you're running it directly use export
<robert_ancell> thomi, duflu, RAOF, racarr, kdub, kgunn, alf_, hikiko, meeting in 4 mins..
<robert_ancell> hikiko, meeting!
<hikiko> robert_ancell, i am having a problem connecting i ll be there in 2 minutes
<robert_ancell> hikiko, np
<duflu> Was I the only one thinking of Brady Bunch music when the second alf appeared?
<robert_ancell> racarr, so you wanted to talk to kdub and I wanted to talk to RAOF or alan :)
<racarr> In my case, I should have just talked to kdub during the day XD
<racarr> I am so useless by the time we have these meetings ><
 * alf_ upgraded hangouts, let's see if it's going to be better next time
<duflu> It's a story of a man named Frantzis, who was bringing up some very lovely clones...
 * duflu goes back to real work
<robert_ancell> bye all
<duflu> Bye robert_ancell
<racarr> bye
<geomyidae> can we have a small hint about the gpu drivers? pleeeease
<duflu> racarr: Still around?
<mlankhorst> morning
<duflu> mlankhorst: Morning. Did any of that nouveau vsync timing work land, anywhere?
<mlankhorst> nah but maintainer is looking at it :/
<dandrader> alan_g, so, about that FakeEventHub MP review, ARBITRARY_TIME should be simply arbitrary_time (so one can't infer if it's const, local, global or member variable)?
<hikiko> hi, did anyone get the stop lightdm crash recently?
<hikiko> because I got it today and I couldnt switch VTs from ssh anymore
<alan_g> dandrader: Yes. But one can infer it isn't a macro.
<dandrader> ok
<dandrader> although one would handle a macro pretty much the same way it would a const variable.
<dandrader> ricmm, ping
<davmor2> guys you possibly know this already but there are crashers for maliit and hud when you start mir
<jibel> bug 1233988
<ubot5> bug 1233988 in maliit-framework (Ubuntu) "maliit-server crashed with SIGABRT in __gnu_cxx::__verbose_terminate_handler()" [Medium,Confirmed] https://launchpad.net/bugs/1233988
<jibel> davmor2, is it the one you're seeing ^
<jibel> and I couldn't retrace hud
<davmor2> jibel: possibly,  I had a few that I couldn't retrace so far
<davmor2> jibel: I'm trying a few things currentl'y when I get back from Lunch I'll add some debug symbols and see if I can get some info from it
<greyback_> folks, I've an issue with Mir and clients which are SIGSTOP-ed. It appears that sometimes Mir considers that client dead and disconnects it.
<greyback_> is there any way to prevent that?
<kgunn> davmor2: i don't have an issue with assigning the maliit crash to mir if its the cause...but please do some testing on SF to compare....at least, i've seen OSK be fairly unstable in the SF config as well
<kgunn> davmor2: hud for sure is a unity-mir/mir issue
<kgunn> https://bugs.launchpad.net/unity-mir/+bug/1231713
<ubot5> Ubuntu bug 1231713 in unity-mir "HUD spyglass doesn't appear on bottom-upward swipe on unity-mir" [High,In progress]
<greyback_> kgunn: I need some Mir team help with the above query, please push it to near the top of the stack. It's causing big app-management problems
<davmor2> kgunn: I cleared out /var/crash before starting mir so I think it is possibly just an issue with maliit but on a fresh sf boot I don't see any crashes but that isn't to say that the reboot didn't cause the maliit crash if that makes sense.
<davmor2> kgunn: my phone is completely locked up now.  I'm about to dig into it and see what is  what.
<davmor2> kgunn: ouch adb isn't connecting
<kgunn> greyback_: ack.... alan_g this sounds related to how the server handles crashing shell (altho more to the second phase of restoring apps)
 * kgunn waits for alan_g to tell me there's code sitting on dev branch i should have merged to trunk (braces)
<alan_g> kgunn: if you know it, why should I tell you?
<greyback_> kgunn: the server handling crashing shell is probably unity-mir/my fault. I've idea on possible fix
<alan_g> greyback_: how quickly does this happen? After half an hour? Or in seconds?
<jibel> kgunn, I don't get this maaliit crash with SF, but it is there on every boot with MIR enabled
<kgunn> jibel: ack...can you log a specific bug to that effect (maliit crash on every mir boot)...thank you
<kgunn> greyback_:  https://code.launchpad.net/~alan-griffiths/mir/client-dies-without-server/+merge/187797
<kgunn> which i s on our dev branch....
<greyback_> alan_g: minutes
<kgunn> dev branch most definitely breaks api
<kgunn> so...gotta do all the paperwork first
<greyback_> kgunn: oh interesting
<kgunn> https://code.launchpad.net/~mir-team/mir/development-branch
<kgunn> ...which i'll just go ahead and start right now....
<alan_g> kgunn: it would be good to land https://code.launchpad.net/~alan-griffiths/mir/fix-1201436/+merge/188535 too - that's got more RPC cleanup
<jibel> kgunn, bug 1233988
<ubot5> bug 1233988 in maliit-framework (Ubuntu) "With MIR enabled: maliit-server crashed with SIGABRT in __gnu_cxx::__verbose_terminate_handler()" [Medium,Confirmed] https://launchpad.net/bugs/1233988
<kgunn> alan_g: shall i top approve? (i take it "fix nits" addresses duflu's "needs fixing")
<kgunn> jibel: thank you1
<kgunn> or thank you! even
<jibel> is there a know issue for unity8 using 100% CPU when the phone is idle with screen blank?
<alan_g> kgunn: yes
<kgunn> jibel: yes...there are actually 2 disctint bugs for that
<jibel> I found 1233870 but not the other, do you have it handy?
 * kgunn wonders if i just lied to jibel...one moment
<alan_g> greyback_: can you get a server log from msg-processor-report? That ought tell why the server decides to disconnect
<greyback_> alan_g: ok
<kgunn> jibel: i knew it was a unity8 bug....but it seems there are a few more :) https://bugs.launchpad.net/unity8?field.searchtext=cpu&search=Search&field.status%3Alist=NEW&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.status%3Alist=FIXCOMMITTED&field.assignee=&field.bug_reporter=&field.omit_dupes=on&field.has_patch=&fiel
<kgunn> d.has_no_package=
<alan_g> I suspect that something happens on the socket - but...
<jibel> kgunn, no worries, I'll continue searching
<kgunn> jibel: i think i was thinking of this one https://bugs.launchpad.net/unity8/+bug/1217099
<ubot5> Ubuntu bug 1217099 in Unity 8 "Unity consumes 50% CPU when screen turns off" [Undecided,Incomplete]
<davmor2> kgunn: had to take the battery out of my phone, now digging into if there were any crash reports
<davmor2> kgunn: the only addition to the crash count seems to be _usr_lib_arm-linux-gnueabihf_upstart-app-launch_zg-report-app.32011.crash  I'll try that script that does seem to work ish and get some info on it
<kgunn> davmor2: cool
<davmor2> kgunn: http://paste.ubuntu.com/6183885/  hope that is useful I think it stopped saying there were missing symbols
<davmor2> kgunn: would there be a dbg package for this from /usr/lib/arm-linux-gnueabihf/qt5/plugins/platforms/libqubuntumirclient.so
<kgunn> davmor2: there must be somewhere
<davmor2> kgunn: apt-cache search libqubuntumirclient returns nothing
<kgunn> greyback_: ^ best way to get debug pkg for libqubuntumirclient.so ?
<kgunn> davmor2: so...what was happening when you got this? http://paste.ubuntu.com/6183885/
<kgunn> davmor2: looks like glib got upset somehow...
<davmor2> kgunn: pass that was the only additional crash I found after removing the battery so I could get the device back up after it completely locked up on me
<kgunn> tedg: mind looking at this real quick http://paste.ubuntu.com/6183885/  just thot you might have an idea
<tedg> kgunn, You don't have zeitgeist installed
<kgunn> davmor2: ^
<kgunn> packaging mistake ?
<greyback_> davmor2: the qtubuntu-android-dbgsym package, from ddebs.ubuntu.com repo
<davmor2> tedg: this is image 75
<om26er> davmor2, what's the package name for bugs against Mir ?
<greyback_> davmor2: see https://wiki.ubuntu.com/DebuggingProgramCrash#Debug_Symbol_Packages for info
<davmor2> greyback_: thanks
<davmor2> greyback_: I think it was more my apt-cache search foo letting me down :)
<greyback_> davmor2: :)
<om26er> wow unity8 takes 100% cpu probably that's the reason for slowness I see on mako
<davmor2> om26er: https://launchpad.net/mir
<om26er> davmor2, I wanted the package name, but I'll find it from that link. Thanks
<davmor2> kgunn, jibel: that's about as good a stack as I can get for the maliit issue http://paste.ubuntu.com/6183984/ jibel does that match yours?
<Saviq> guys, you're hogging our testing vms again! ;P
<davmor2> Saviq: I'm on a my own hardware so I doubt that :P
<Saviq> davmor2, it was a general remark to the Mir guys ;)
<jibel> davmor2, yes, it seems to match
<jibel> davmor2, why don't you submit the crash with apport and let the retracer do the work
<jibel> ?
<jibel> pitti fixed them few days ago to produce usable stack traces
<davmor2> jibel: cause it's fun :)
<jibel> davmor2, you have too much spare time ;)
<davmor2> jibel: I have no spare time I have a script and installing a few dbg packages :)
<davmor2> jibel: how are you doing that?  apport-collect/cli/bug?
<jibel> davmor2, apport-cli /path/to/crash on the device
<kgunn> jibel: really...that simple huh ?
<tedg> kgunn, So it seems the answer to your question is: people just putting data into Zeitgeist doesn't make it important enough to have.
<jibel> davmor2, then send and when it asks to open the browser, copy the link to the browser on your desktop
<tedg> Stupid shortsightedness
<kgunn> tedg: :)
<om26er> kgunn, do we have a bug for 100% cpu usage of unity8 on mako or should I report one ?
<jibel> om26er, read backlog
<kgunn> om26er: we have it
<jibel> *scroll
<kgunn> om26er: we have a handful actually :)
<kgunn> davmor2: that last one is interesting http://paste.ubuntu.com/6183984/ seems you need libmirclient dbg symbols
<ricmm> kdub: ping
<om26er> ok
<davmor2> kgunn: apparently I don't have some up-to-date packages so I'm updating the image and trying again, shuggin fashin packages
<kgunn> davmor2: ack
<kgunn> dandrader: before i forget
<kgunn> dandrader: if you mp, please target this branch https://code.launchpad.net/~mir-team/mir/development-branch
<dandrader> kgunn, sure
<kgunn> dandrader: we're using that as a staging area to prevent un-shepherded server api breaks
<kgunn> ricmm: he's west coast
<kgunn> ricmm: can anyone else help ?
<kgunn> altho he's prompt at ...he'll be in in 30min
<ricmm> kgunn: just wanted to see where he was at with the branch to remove the vsync signal
<ricmm> for the cpu usage bug
<kgunn> ricmm: yep :) me too...feel free to join our standup
<ricmm> ill join it for the first few mins
<ricmm> thx
 * ricmm tea aswell
<dandrader> kgunn, the sleep&retry hack works, but a lot of cycles seems to be needed (i.e. a big delay between the device file showing up and udev rules getting applied to it), which is a bit unnerving
<kgunn> didrocks: what's that incantation to bump the deb changelog ?
<kgunn> dandrader: have you tested a few times...is it consistent?
<didrocks> kgunn: dch -i
<kgunn> didrocks: dang it...thot so...sorry for the ignorant interupt
<didrocks> kgunn: seems obvious isn't it? ;) (j/k)
<didrocks> no worry, if you don't practice it regularly, yeah, it's normal that you don't remember ;)
<kgunn> dandrader: i know you were going to try-wait in a loop...guessing it tries multiple times ?
<kgunn> dandrader: wonder if your attempts slow it down ?
<kgunn> dandrader: curious, are you able to run through autpilot test ? e.g. ubuntuuitoolkit per the bug
<dandrader> kgunn, anyway, the quick hack is not so quick in the end. aiming at the proper fix now
<kgunn> dandrader: so, not MP worthy ?
<dandrader> kgunn, if I have to spend time debugging a quick hack it's because it's not quick anymore :)
<kgunn> dandrader: sure
<dandrader> kgunn, and a second problem is hit:
<dandrader> "[InputReader]  Touch device 'autopilot-finger' did not report support for X or Y axis!  The device will be inoperable."
<dandrader> kgunn, so that might be a second hurdle waiting after the current one
 * kgunn goes for another cup of coffee...and considers running into the street to be hit by oncoming traffic
<dandrader> lol
<alan_g>  /me wonders how he has lived this long
<ricmm> kgunn: give it two more weeks
<ricmm> then we can all just get on a bus and do the same
<kgunn> :)
<ricmm> kgunn: ill skip the standup, I just saw emails from kevin that I had missed
<ricmm> its up for review, the changes requested are trivial
<ricmm> im sure kevin will have it ready within 1-2 hours
<ricmm> im testing it locally now and will do my review
<kgunn> ricmm: cool...appreciate the testing
<hikiko> good evening!
<mhall119> kgunn: is it possible to run a Wayland session compositor on top of the Mir system compositor?
<kgunn> mhall119: i would assume you mean in theory ?
<mhall119> yeah
<mhall119> and if there's been any discussion and/or plans
<kgunn> mhall119: sure...you'd have to write a wayland-mir back end
<kgunn> mhall119: its been discussed...like over beer...but nothing more than that
<mhall119> ok
<alan_g> kgunn, mhall119: FWIW we've had similar discussions about implementing Wayland using the Mir library. (IT would be "fun", but isn't currently planned or worked on.)
<mhall119> alan_g: would that work to run an upstream Gnome-Shell-as-Wayland-compositor on top of a Mir system compositor?  I thought implementing the Wayland protocol would only let us run Wayland clients
<davmor2> kgunn: right completely fresh install on the default SF all I have crash wise is for _sbin_ureadahead.0.crash so I will delete that now and then reboot into mir and see what appears then
<alan_g> mhall119: Maybe. In that case the "Weston" session compositor would need to talk the protocol that the Mir system compositor uses (and currently that's the internal Mir one). For that you'd need to implement a session compositor as a Mir client.
<alan_g> But if the system compositor talked Wayland...
<alan_g> * s/Weston/Wayland/
<kdub> right, you'd have to implement a fb backend based on mir in weston
<pete-woods> hi all, according to (http://unity.ubuntu.com/mir/installing_prebuilt_on_android.html) I should be able to run mir on nexus 7 with a special  libhybris
<pete-woods> questions 1) is this true? 2) if so, where do I get it?
<kdub> pete-woods, i think that support landed, so no special one needed anymore
<kdub> haven't tried in a while
<pete-woods> kdbub: I just tried running it, and basically ran into this bug (https://bugs.launchpad.net/mir/+bug/1231917)
<ubot5> Ubuntu bug 1231917 in libhybris (Ubuntu) "Mir servers crash with SIGSEGV in libhybris-common.so.1 on Nexus7" [Undecided,New]
<pete-woods> and figured that it must be that libhybris thing mentioned in the wiki
<kdub> might be that hwc isnt working for nexus 7
<pete-woods> I don't know what hwc is (hardware compositor?), but I'm guessing I can't fix it myself
<kdub> pete-woods, posted a suggestion on the bug
<pete-woods> kdub: thanks for the suggestion, /system seems to be mounted ro, is there a safe way to change this?
<kdub> mount -o remount,rw /system
<pete-woods> okay
<pete-woods> kdub: I just wanted to check I wasn't going to explode stuff if I did that
<pete-woods> :)
<kdub> if it explodes, move it back
<pete-woods> :)
<kdub> alan_g, on that deactivate-notifications-when-display-off branch, changed the name to mode(MirPowerMode)
<kdub> reads much cleaner, no new enums or confusing bools
 * alan_g goes to look...
<pete-woods> sadly that removing the hwcomposer shared lib doesn't seem to help, but thanks for the suggestion
<kdub> pete-woods, thanks for giving it a try
<pete-woods> np
<pete-woods> I am obviously the one with most to gain from a fixed display server
<kdub> i'm wandering around hwc code for the next bit, so there's hope i can get it working... no time promises though
<alan_g> kdub: approved
<kdub> alan_g, thanks
<pete-woods> kdub: well I have my fingers and toes crossed :)
<kgunn> alan_g: kdub alf|xmir_devel .....any takers https://code.launchpad.net/~kgunn72/mir/bump-libmirserver5/+merge/188877
<kgunn> its an easy one
<kgunn> kdub: you want mp 188751 top approved ? or should we wait for duflu ?
<kgunn> going for a run bbiab
<kdub> kgunn, let me fix that nit, should be done by the time you get back
 * kdub wishes mocking ioctls was easier
<kgunn> kdub good to go ?
<kdub> oh sure
<kgunn> racarr: you around ?
<kgunn> racarr: don't hate me...but it'd be really really useful if you could a) review  https://code.launchpad.net/~dandrader/mir/hack_lp1233944/+merge/188889
<kgunn> and b) test it out on a phone against an AP run per https://bugs.launchpad.net/mir/+bug/1233944
<ubot5> Ubuntu bug 1233944 in Mir "Unity8/Mir is unable to open autopilot uinput devices" [Critical,In progress]
<kgunn> bschaefer: you got a phone?
<bschaefer> kgunn, sadly no, i've a nexus 7 that refuses to be recognized by my laptop :(
<kgunn> :-/
<kgunn> greyback: ^ in case you're feeling benevolent
<kgunn> i'll try...but i go at manager speed :-|
<racarr> kgunn: THATS IT THATS THE LAST
<racarr> FUCKING STRAW I HAVE HAD
<racarr> :p
<racarr> Don't worry, you're too nice to hate.
<racarr> um, ok let me figure out what is going on
<greyback> kgunn: I'm in middle of other debugging session at the moment, can take it on after. In case the bi-polar racarr scares you :)
<kgunn> racarr: and i have an interesting relationship...he rages a lot :)
<racarr> aha, no I don't mind doing this at all, I was just playing a long
<racarr> phone is at dead battery though. so it will be a bit
<racarr> branch itself looks fine
<racarr> err
<racarr> hmm
<racarr> worried about opening a device multiple times now
<racarr> ok I think it will open devices multiple times potentially
<racarr> and its not clear what will happen
<racarr> going to propose a thing
<kgunn> ok
<kgunn> altho...shouldn't that be a well defined device interface thing (e.g. multiple open calls from a client result in 1 device handle)
<kgunn> or some such
<racarr> its just a file
<racarr> so you keep on getting file descriptors to it I guess
<racarr> if you keep on opening it by path
<davmor2> kgunn: you have a nexus 4 right?
<kgunn> yes sir
<davmor2> kgunn: can you install solitare and try moving the cards around for me on mir they are really jumpy on maguro
<davmor2> kgunn: I'm just after finding out if it is a maguro thing (which I'm expecting it is) or if it is an animation that mir isn't happy with in general
<kgunn> davmor2: give me a few
<davmor2> kgunn: no worries
<racarr> kgunn: I proposed a merge in to dandraders branch
<racarr> but it seems like he isn't around? and this probably needs to go quick?
<kgunn> racarr: yeah...he eod'd
<kgunn> davmor2: hey...so...when i try to download solitare it keeps telling me err, please go sign into ubuntu1 via system settings
<kgunn> davmor2: i can;t find that in sys setting....but used the ubuntu1 app
<kgunn> i signed in, but still gives me the same error
<davmor2> kgunn: open the setting app,  in setting click on accounts, login to u1
<thomi> morning all
<kgunn> thomi!
<thomi> hey kgunn, pitti tells me he found the bug
<thomi> pitty is like... super engineer. I bet it took him 2 minutes
<kgunn> thomi: maybe 10 :)
<racarr> kgunn: Ok I am going to repropose it sourced from my branch then someone else can review
<kgunn> racarr: totally makes sense
<kgunn> then poor kdub will need to review
<racarr> ok done
<racarr> https://code.launchpad.net/~robertcarr/mir/1233944-addendum/+merge/188900
<kgunn> thomi: if you want to rebuild mir use that ^ and see if that solves it
<kdub> daniel will be the only one who can pull that in
<thomi> OK. grabbing now
<racarr> I still cant get my nexus to physically turn on...
<kgunn> kdub: no, i think racarr retargeted it to dev branch instead of daniels ....so i guess that means we'd simply need to take both if we want them
<kgunn> or do i have it wrong?
<racarr> no mine contains daniels so just merge the second one
<kdub> yeah, didn't refresh my page
<racarr> I actually resbmitted daniels proposal sourced from my branch
<racarr> but im not sure what that means different than retargeting
<racarr> my proposal
<kgunn> racar right so if we pull yours in daniel's comes with it i think
<racarr> yeah
<kgunn> davmor2: ok...instructions were good, logged into u1 ok...but now, i hit the install button on solitaire and it just sits here
<kgunn> wonder if getting an error prior to logging in properly is an issue
<kgunn> or logging into the u1 app and the settings app
<kgunn> is an issue
<davmor2> kgunn: :( have you thought about joining qa?
<kgunn> davmor2: because i find so many weird things wrong ? :)
<davmor2> kgunn: because you break stuff as easily as I do :)
<davmor2> kgunn: apparently there is a link being added that takes you to the settings page which will land soon :)
<davmor2> kgunn: you may need to reboot I'm afraid (Yes the proverbial turn it off and turn it on again fix) :D
<thomi> hey mir folk - can someone point me to the pbuilder/sbuild cross compile info again? I seem to have wiped my setup
<kgunn> thomi: you mean this http://unity.ubuntu.com/mir/building_source_for_android.html
<thomi> kgunn: I want to build packages, not raw binaries :-/
<kdub> we should eliminate those instructions...
<kdub> tricky part is getting everyone bootstrapped with their cross build setups
<thomi> kgunn: racarr: are there plans to use ueventlib instead of inotify? I trust pitti when he says that it's the correct solution
<kgunn> thomi: yes...but even pitti points to a quick hack soln
<thomi> sure
<kgunn> uevent a longer term thing
<thomi> just wanted to make sure this was going to get patched, and not forgotten about :)
<thomi> I didn't mean today :)
<kgunn> thomi: you know me by now...we'll at least have a bug indicating we're a bunch of scally wags
<kgunn> kdub: so what are the instructions ? (i've just built per the wiki....realized i've never cross compiled mir and then installed on a device)
<thomi> heh, ok
<thomi> you can do it with pdebuild/pbuilder, but I can never remember how
<kdub> the instructions are 'make an armhf with the needed dependencies, then use a certain cmake command'
<thomi> also, sbuild will do it I believe
<thomi> kdub: oh, there's an easier way than that :)
 * thomi continues searching
<kgunn> ls
<kgunn> oops
<kdub> thomi, but with cross compiling?
<kdub> not emulated compiling
<thomi> yeah
<thomi> oh, well, does it make a difference?
<kdub> not in what's produced, but in time
<kdub> emulated compiling is slow for a development workcycle
<kdub> its slow for a packaging one, but more tolerable
<kdub> and i know how to make a chroot :) its just the scripting of making the chroot that i haven't been able to do
<thomi> I see. maybe I have a blinging laptop.. I never noticed it being significantly slower that native compiles
<kdub> well, i'd say that native and emulated compiles are roughly on par
<kdub> but cross compiles are faster than both
<kdub> thomi, right now, we just run the top level script 'cross-compile-chroot.sh'... but its a bit of a hack
<thomi> yeah... but I'm pretty paranoid about copying binaries over to system locations. If I get a package at least I can revert those changes safely
<thomi> it turns out, the CI system produces such packages, so I'll grab them
<kgunn> kdub: sorry if i'm being dense...so, after running  cross-compile-chroot.sh...do i just copy all the libmir*.so's over to the device in the directory /usr/lib/arm-linux-gnueabihf/
<kdub> kgunn, that's what i usualy do... like thomi noted though doing that can cause headaches though if you're not careful
<kgunn> kdub: :) define "careful"
<kdub> make sure the linkage is what you expect
<kgunn> kdub: oh...like version numbers and the fact that android input is a static lib and all the so's probably link to it
<kdub> well, its a static lib, but it goes out in... libmirserver.so?
<kgunn> kdub:  i was just gonna push everything to be certain
<kgunn> hey...so doing this...and kind of double checking stuff....i noticed something
<kgunn> in the ubuntu-system image....there's no libmirclientlttng.so
<kgunn> remember last night i said logging didn't work for me...
<kgunn> thomi: did you install seperately ?
<thomi> kgunn: not yet
<thomi> waiting for CI to do it's thing
<kgunn> thomi: no i meant last night...when you were using mir logging....had you installed the libmirclientlttng.so seperately ?
<thomi> kgunn: nope
<thomi> kgunn: but I wasn't using lttng
<thomi> gah
<thomi> jenkins is down, and I can't find those instructions anywhere
<thomi> I really don't want to have to build the package on the phone, that sounds like a bad idea
<racarr> kgunn: Should I still try and test this autopilot stuff?
<racarr> Just finished up input-injecter
<thomi> kgunn: found them - was looking in the wrong wiki: https://wiki.canonical.com/PES/Engineering/DevelopingWithPbuilder?highlight=%28compile%29%7C%28armhf%29
<thomi> racarr: that would certainly help me out
<racarr> yay the red light is back on my phone
<racarr> should be operable soon
<racarr> thomi: Ok ill get on it
<thomi> thanks
<racarr> it wll be 20 minutes to upgrade, 20 minutes to build the new mir branch, etc...
<racarr> should I just start from cdimage-touch or is there
<racarr> a specific image
<thomi> racarr: I'd grab the ubuntu-system image from the devel-proposed channel
<racarr> thomi: Can phablet flash do that?
<thomi> sure
<thomi> one second
<racarr> I think maybe I have seen this incanation before
<kgunn> https://wiki.ubuntu.com/Touch/Install
<racarr> but I keep on downloading the images and using clockwork mod XD
<kgunn> racarr: ^ see section 4
<thomi> yeah, what he said :)
<racarr> phablet-flash --help has gotten worse and worse
<racarr> and phablet-flash has gotten
<racarr> better and better lol
<racarr> ok thanks :D
<kgunn> its like phablet-flash ubuntu-system --channel devel-proposed --no-backup -d mako
<kgunn> no backup is like --wipe
<kgunn> and like i always saw...its always good to wipe
<racarr> oi
<kgunn> in life and on phone flashing
<racarr> kgunn: That could either be a very zen metaphor or a very juvenile one :p
<kgunn> racarr: do you know who you're talking to ? :)
<racarr> I guess that makes it double zen.
<racarr> oi :p
<kgunn> the product of living with a 15 yr old boy
<kgunn> racarr: rest of the instructions here... https://bugs.launchpad.net/mir/+bug/1233944 for running AP tests
<ubot5> Ubuntu bug 1233944 in Mir "Unity8/Mir is unable to open autopilot uinput devices" [Critical,In progress]
<racarr> thanks
<racarr> im cross compiling mir in parallel with the flash so it shouldn't really take that long
<kgunn> racarr: also...missing from that bug...you have to install on the device...python-gi & unity8-fake-env
<kgunn> to get AP to run
<bschaefer> racarr, hey, if you get a chance, could you comment on this MP: https://code.launchpad.net/~brandontschaefer/mir/lp.1233089-fix-v-h-scroll/+merge/188666
<racarr> kgunn: ok
<kgunn> thomi: i flashed hours ago...those packages still not there^
<racarr> bschaefer: Ill do that now while my phone flashes!
<bschaefer> racarr, sweet :)
<thomi> kgunn: the littng .so? You don't need it
<bschaefer> racarr, i know we talked about waiting on it, which we might have to, but duflu has made a comment as well :)
<kgunn> thomi: no...the AP dependent modules
<kgunn> thomi: python-gi & unity8-fake-env
<thomi> kgunn: oh yeah, that's why you need to apt-get install the -autopilot packae
<thomi> *package
<kgunn> thomi: oh my bad...
<thomi> that's not going to get fixed until we kick sergio's ass  a bit more :)
<racarr> bschaefer: touch_major/minor
<racarr> is used by qtubuntu
<bschaefer> oo, soo can't use that :)
<racarr> it uses some sort of mathematics to compute the touch "area"
<racarr> tbh I think its all used
<bschaefer> racarr, orientation/pressure might not be bad to remove?
<bschaefer> dam
<racarr> orientation
<racarr> is unused
<racarr> pressure is used
<bschaefer> racarr, well, now I wish I hadnt reverted this a bit ago...
<bschaefer> racarr, alright, what about raw_x/raw_y?
<racarr> sorrry
<racarr> raw_x and raw_y are used :(
<racarr> maybe x and y aren't used
<bschaefer> dang, id?
<racarr> or maybe if we keep x and y and offset
<racarr> we can remove raw_x and raw_y or something
<racarr> ID is probably only used forlogging and hashing
<bschaefer> yeah...which is a useful one hmm I can look at trying to compress the raw_x/raw_y into an offset
<bschaefer> but it has to be a sizeof(float)
 * bschaefer doesn't know the android input stack super well :)
<bschaefer> racarr, to bad vscroll and hscroll isn't an XOR...otherwise I could just do a union and drop 1 float
<racarr> mm
<racarr> trying to put two floats in one floats sounds pretty bad though, there will be no precision
<bschaefer> racarr, well I was thinking (yesterday at lease) that you can only have a vscroll XOR hscroll if so then you can just union those 2
<bschaefer> cause it'll only ever be one, though it'll be hard to tell which direction it really is...
<bschaefer> racarr, yes you are right though, no precision :)
<robert_ancell> thomi, any change on the input issue?
<bschaefer> racarr, whats size used for in the struct?
<racarr> oh you could lose one precision bit and
<racarr> best to avoid bit hacks though
<racarr> bschaefer: hm?
<bschaefer> iagree
<bschaefer> racarr, http://paste.ubuntu.com/6185447/
<bschaefer> line 6 in the paste...im not sure what size would be used for
<bschaefer> size of the blob?
<bschaefer> well that explains it: http://developer.android.com/reference/android/view/MotionEvent.html#AXIS_SIZE
 * bschaefer digs through qtubuntu
<racarr> size of the touchpoint is my guess
<racarr> qtubuntu doesnt really use it
<racarr> from grep
<kgunn> think i just ran into the careful you were talking about kdub
<racarr> maybe you could get away with size and orientation
<kgunn> its up..unity8 running...but nothing on screen
<racarr> this is kind of worrying me though
<bschaefer> racarr, well i want to make sure if i remove something, it wont be needed in the future...
 * bschaefer as well
<racarr> I think there is nothing to remove then
<racarr> just stuff we dont use now
<bschaefer> racarr, as v/h scroll is somewhat needed as well...
<greyback> kgunn: just a note, thanks to ricmm, the problem I was having with disappearing apps is solved
<bschaefer> racarr, and we can't change the size of that strcut, as it'll break things... <sadface>
<racarr> Well in the future we can break ABI
<racarr> I guess we just can't right now.
<bschaefer> racarr, sounds good, i can make a comment on that MP
<bschaefer> racarr, thanks for the info!
<kgunn> greyback: thats a great note!
<racarr> grr phone died int he middle of flashing
<kgunn> f!...reflashing
<kdub> you should always leave ubuntu touch plugged in at all times ;-)
<racarr> I know but I only have so at the end of day when my computer becomes a nexus of audio cables it always ends up unplugged
<racarr> should find my wall charger
<racarr> only have so many usb*
<kdub> racarr, the change 12233944 looks okay enough... just don't know enough to say that it won't break anything
<kdub> not too familiar with the code, or the problem
<racarr> me either so we will wait on testing it to land
<racarr> well, I have some idea that it's ok :p but not 100% confident
<kdub> racarr, yeah :/
<kdub> android system code (like sf or the input stack) always seems like a big else-if chain based around flags to me
<racarr> lol yes
<racarr> most of the android input classes have some big methods that basically is like
<racarr> changeState(new state)
<racarr> with a massive case statement
<racarr> lol
<kdub> maybe vtables are just too slow for them :) better to have every object have an int, with flags set
<racarr> I think, a lot of it is symptomatic of this sort of OO pattern of avoiding too much abstraction
<kdub> and the code switches function calls around the int flags
<kdub> :P
<racarr> i.e. all the objects in the input stack kind of
<racarr> correspond
<racarr> to some, object that you could kind of imagine
<racarr> as a physical object or like an actor
<racarr> but I think trying to stick to that ideal
<racarr> normally just leads to object explosion
<racarr> and the input stack would be a lot cleaner, if InputDispatcher were several more abstract components
<racarr> etc
<racarr> Ok lunch while my phone chargers so we dont have a repeat
<racarr> bbiab
<kgunn> thomi: can i cheat assuming you're ahead of me...what's in your pcreate proj file ?
<kgunn> deb & deb-src urls
<thomi> kgunn: you men ~/.pbuilderrc ?
<kgunn> thomi: the one where you create the proj
<thomi> kgunn: ummm, I'm not sure what you mean - I'm following this: https://wiki.canonical.com/PES/Engineering/DevelopingWithPbuilder?highlight=%28compile%29%7C%28armhf%29
<thomi> essentially you run pcreate ... and then pbuild
<olli> thomi, are you still building?
<thomi> olli: yup :-/
 * olli is curious to hear if the fix helped
<olli> did dandrader test it locally?
<kgunn> thomi: right, but pcreate prompts you with a text editor to enter proj location info
<thomi> it's a race to see if pbuild or the CI process finished first
<kgunn> see the wiki "Create Project:pcreate" then #2
<thomi> kgunn: gotchya, just leave it blank
<kgunn> ?
<kgunn> cool
<thomi> kgunn: in the past you needed additional sources.list lines, but not anymore
<thomi> everything is in the archive these days
<kgunn> thomi: ....and my wife says i don't follow instructions...ha
<thomi> following instructions is for the weak willed anyway
<robert_ancell> racarr, was https://code.launchpad.net/~robertcarr/mir/1233944-addendum/+merge/188900 meant to superceed Daniel's MP or be merged into it?
<robert_ancell> Anyway, it looks sane to me as a workaround, are you abstaining since it looks like you've proposed it or you're not sure about it
<racarr> robert_ancell: Abstaining because I reproposed it
<racarr> it was originally going to go in to daniels mp
<racarr> but then daniel is EOD
<racarr> so I resubmitted my branch with daniels to dev branch
<racarr> which is the one that should land
<racarr> it still needs testing though
<racarr> so dont top approve
<robert_ancell> racarr, ack
<racarr> wait did my flash fail again? errrrrgggg
<racarr> it seemed to be doing so well and was ont he on device install and now lonnng black screen
<racarr> ok I need to let my phone charge for > 30 minutes apparently
<thomi> kgunn: racarr, anyone else - packages for racarr's branch are now available from here: https://jenkins.qa.ubuntu.com/view/All/job/mir-saucy-armhf-ci/77/
<thomi> download them to phone with wget, and install with dpkg. job done.
<kgunn> thomi: does it actually work ?
<kgunn> drumroll
<thomi> just installing now
<olli> drumroll
<thomi> still installing...
<thomi> you all understimate the crappieness of NZ "broadband"
<olli> you install via broadband?
<olli> did you build a whole new image?
<thomi> nah, just downloading the new mir packages
<thomi> and their dependencies
<thomi> 3 minutes left...
<olli> I see, no local build
<olli> I thought you might have done a local build and as such using "broadband" didn't compile
<thomi> 30 seconds....
<thomi> olli: I tried, but it was faster to let the CI machinery do the build for me
<kgunn> olli: ^ and that's a cf
<olli> cf?
<olli> as in cluster f?
<kgunn> c=cluster
<olli> I hear you
<kgunn> olli:  and i built local using the meta chroot...which built fine, but when i installed the so's manually it didn't work
<kgunn> so...the whole pbuilder thing is the _right_ way
<olli> yep
<thomi> hmmmm
<racarr> ok did some chores while my phone recovered...back on board now :)
<olli> that doesn't sound like the cheering I was hoping for
<thomi> so I don't see the logging output anymore
<thomi> it works!
<thomi> but I don't see the log messages I was looking for
<thomi> but hey
<thomi> it freaking works :)
<kgunn> hells yeah
 * thomi runs some AP test suites
<kgunn> justice leaque right there
<olli> thomi, ok, getting closer to the cheers
<olli> so
<olli> thomi, how is the phone performance
<olli> any noticeable lag
<thomi> olli: tests seem to be running quickly
 * kgunn almost thinks olli wants there to be lag
<thomi> I'll run the complete test suite set and see what happens
<thomi> but the input problem seems to be solved
<kgunn> thomi: so ubuntuuitoolkit worked basically...any others
<racarr> there is definitely still lag on n4
<kgunn> racarr: i think olli meant, with this fix in did it get worse
<racarr> nah
<olli> just checking
<thomi> uh oh
<kgunn> :-| ?
<thomi> a bunch of AP tests locked up, and now the phone doesn't respond to my touches
<thomi> as in, my actual finger
<thomi> but unity8 is still running
<kgunn> thomi: do you have an error like "[InputReader]  Touch device 'autopilot-finger' did not report support for X or Y axis!  The device will be inoperable."
<thomi> kgunn: nope
<thomi> but then, for some reason, I get no mir logging at all
<kgunn> what does /userdata/.cache/upstart/unity8.log say
<ricmm> I think Mir just fried my screen
<ricmm> I have this white-ish cloud on top of everything
<ricmm> super sad
<kgunn> ricmm: GN or N4 ?
<ricmm> N4
<kgunn> ricmm: was this testing kdub 's unblank fix ?
<thomi> kgunn: http://paste.ubuntu.com/6185918/
<ricmm> not really just normal usage
<ricmm> tracking some issue that required me restart mir a bunch of times
<racarr> we all overheat our phones a lot :/
<ricmm> this happened before and disappeared rather fast
<ricmm> seems like its fading away slowly
<ricmm> maybe it is indeed overheated
 * ricmm puts it in the freezer
<kdub> yeah, probably overheated
<racarr> lol
<thomi> racarr: am I going crazy? Why don't I get mir log messages anymore? I set those mir log env vars
<racarr> kdub: Maybe the code to hack the users brain through electrical impulses out of the touch screen went bad.
<kdub> i run mir on the phone off the usb port in my freezer
<kdub> don't know how all of you run it...
<kdub> :P
<kgunn> thomi: anything in /var/crash
<racarr> thomi: Some of the android stuff goes to stderr I believe is
<racarr> a possibility
<thomi> kgunn: yeah, but not from today
<kdub> ricmm, usually temperature warnings will appear in logcat
<ricmm> maybe this means I need to stop for the day
<thomi> racarr: this worked yesterday
<ricmm> as its my personal phone
<kdub> but really, i've never overheated my phone to the point it stops working
<kgunn> thomi: mmm, this was what i saw too...no logging
<ricmm> it wasnt really hot
<ricmm> its something else
<ricmm> it was workin fine, I restart mir and the cloud was there
<ricmm> rebooted and it was still there on the Google logo
<ricmm> slowly fading away
<ricmm> left some burned dash items there as well, which are almost completely gone by now
<kdub> very strange
<ricmm> witchcraft
<ricmm> kgunn: what kind of "team" are you running?
 * ricmm calls a priest
<kgunn> :)
<kgunn> racarr: kdub we need to help thomi on the logging situation....or at least, i guess racarr should be runnable in a moment
<kdub> logging situation?
<thomi> kgunn: racarr: something in that branch seems to have killed logging, as strange as that sounds
<racarr> im setting up the autopilot stuff now
<kgunn> thomi: double check, did you echo your env variables
<racarr> I think that's
<racarr> almost definitely not what happened :p
<thomi> I've now tried with both upstart and without
<thomi> kgunn: yeah, with 'initctl list-env' I can see that they're set correctly
<thomi> even without upstart, and exporting those variables directly I don't see any logs
<thomi> racarr: this is still correct, yes?
<thomi> initctl set-env MIR_SERVER_INPUT_REPORT=log
<thomi> initctl set-env MIR_SERVER_LEGACY_INPUT_REPORT=log
<racarr> setting up autopilot now
<racarr> I believe so, I don't know what initctl does though, but the env variables are still right
<racarr> err how am I supposed to install the packages from CI
<racarr> I am getting hundreds of apt errors about overwriting some file about /tmp/var/ci blabla
<racarr> *patiently waits on apt*
<thomi> racarr: huh?
<thomi> racarr: dpkg -i package_name.dev
<thomi> err, sudo ...
<thomi> racarr: initctl is upstart
<racarr> dpkg -i * led to disaster
<racarr> :(
<racarr> running an apt-get update an apt-get -f and
<racarr> all that such
<thomi> racarr: right, because you installed the -dev packages, didn't you:)
<racarr> thomi: I guess, grabbed all the packages and dpkg -i them XD
<racarr> didnt have the dev packages before
<thomi> yeah
<thomi> but that's ok, apt-get install -f will sort it out
<racarr> no apt wotn work because
<racarr> it cant find the archive file for libmirserver4
<racarr> which it claims needs to be reinstalled ><
<thomi> racarr: you shouldn't have done an apt-get update
<thomi> now it's trying to install newer versions :-/
<racarr> it was the same before...
<thomi> racarr: rm your -dev packages
<racarr> no it can't install anything apt just immediately bails
<thomi> and do dpkg -i *.deb
<racarr> mm I removed the dev packages
<racarr> and dpkg -r them
<thomi> cool
<racarr> g libmirprotobuf0_0.0.12+13.10.20131001.1bzr1101pkg0saucy77_armhf.deb (--install): unable to install (supposed) new info file `/var/lib/dpkg/tmp.ci/postinst': File exists
<racarr> Preparing to replace libmirserver4:armhf 0.0.12+13.10.20131001.1bzr1101pkg0saucy77 (using libmirserver4_0.0.12+13.10.20131001.1bzr1101pkg0saucy77_armhf.deb) ...
<racarr> err, pkg: error processing:
<thomi> dude
<racarr> then dependency problems
<thomi> WTF did you do!?
<thomi> that's totally borked
<thomi> re-flash?
<thomi> in the mean time... why don't I get any log messages?
<racarr> all the way down
<racarr> I dunno I downloaded all the packages and dpkg -i * them :(
<racarr> lol
<racarr> apparently not very well
<racarr> I think it might fix itself if I coudl resolve the dependencies but I cant use apt
<racarr> apt-get download maybe
<racarr> grr resolved the dependnecies but this
<racarr>  /tmp.ci/postint thing
<racarr> keeps it from working
<racarr> but there is not even such a folder /var/lib/dpkg/tmp.ci/postint
<racarr> even dpkg --forrce-all doesn't work
<racarr> I don't know
<racarr> I am reflashing
<racarr> as for log messages
<racarr> I think almost certainly they aren't being captured to a file
<racarr> or the environment isn't really set
<racarr> start exploring, i.e. do mir demos produce logs
<racarr> is the environment really set (attach with GDB to the running process and verify)
<kgunn> i've never been able to get a log
<racarr> do the other mir logs work?
<thomi> racarr: this was working yesterday
<thomi> with upstart, I'm totally confident that the variables are set as we expect them to be
<kgunn> robert_ancell: hey...i need a pointer...probably just a bzr command i lack knowledge of
<thomi> anyway, time for lunch for me
<kgunn> https://code.launchpad.net/~kgunn72/mir/bump-libmirserver5/+merge/188877
<kgunn> robert_ancell: if you look at that ^
<kgunn> you'll see i attempted to replace debian/libmirserver4.install with 5
<kgunn> so on my local i did mv libmirserver4.install libmirserver5.install
<kgunn> but when i pushed...it didn't seem to include the libmirserver5
<kgunn> wondering if there was a step in the bzr commit i missed
<kgunn> grabbing food brb...thomi / racarr ...i know its not perfect, but its progress lend me your thots no merging
<kgunn> thomi: would it be worth it to reflash, enable mir, enable logging ??
<kgunn> then stepwise ensure logging continues working
<thomi> kgunn: I'm running more tests now, I'll keep running tests on mir over today.
<thomi> kgunn: TBH, I'm getting pretty fed up with all the various quirks/issues I'm running into
<thomi> so I'll run the rest of the tests, and see what happens
<racarr> yay no apt suicide this time
<racarr> no unity8 though once I touched .display-mir
<racarr> these packages must be ABI incompatible?
<racarr> thomi: Which unity-mir, etc are you using with these packages
<thomi> racarr: hmmm, says "none"
<thomi> oh FFS
<thomi> guess what?
<thomi> I'm not running freaking mir
<racarr> libunity-mir1
<thomi> 0.1+13.10.20131001-0ubuntu1
<thomi> rebooting now
<racarr> it seems unlikely the unity-mir is going to work with these packages
<racarr> kgunn: which ppa has the most recent builds of
<racarr> unity-mir against development-branch?
<thomi> adb shell
<thomi> oops
<racarr> thomi: adb hell is the what the pros use
<thomi> is this channel logged?
<racarr> I dunno probably one way or another
 * thomi restrains himself
<racarr> no adb hell is a real command
<racarr> try it
<racarr> :p
<thomi> racarr: I know
<racarr> aha
<racarr> sorry
<racarr> ok so to test this we need an updated unity-mir and platform-api mirserver too
<thomi> racarr: I'm referring to the burning rage I'm feeling right now, and my desire to express it verbally here, in this channel
<thomi> racarr: surely your change doesn't break ABI?
<racarr> no but this package doesn't contain only that change vs the
<racarr> packae ina rchive almost certainly
<racarr> well I dunno, actually even after I removed .display-mir im still not getting anything so I think it was
<racarr> phablet-click-test-setup
<racarr> that broke things.
<racarr> I shouldn't have installed the packages and run that at the same time
<thomi> kgunn: ^^
<racarr> oh hey I tried to reflash again and there are new images
<racarr> going to take things STEP by step this time :)
<thomi> kgunn: this is totally fubar. I've run out of patience. I say merge it, it can't be worse than what we already have. merge it and spin up a new image
<thomi> right now this feels like a waste of my time, at least until we get something that boots all the way
<racarr> theres nothing fubar about it we have just been skipping steps
<racarr> on the image, unity works, then mir works, then the new mir packages are installed and mir doesn't work
<racarr> but that's expected if there are any ABI changes between development-branch and what is in archive
#ubuntu-mir 2013-10-03
<thomi> racarr: sure, I understand the reasons. Can you let me know when there's a set of binary packages that will work together please?
<racarr> thomi: I'm just going to build everything on the phone while I cook dinner and see if autopilot runs
<racarr> then we can just ladn the branch
<racarr> the longest part is fetching the build deps because my phone only gets like 100 KBs but its almost done
<robert_ancell> kgunn, there?
<kgunn> thomi: racarr robert_ancell sorry...went for food
<kgunn> ok...so, i vote no merge until racarr finishes his dinner :) and has a chance to try
<robert_ancell> kgunn, np. I think you just need to do a 'bzr revert debian/libmirserver4.install' then a 'bzr mv debian/libmirserver4.install debian/libmirserver5.install'
<robert_ancell> BUT, I'd recommend using that script instead
<kgunn> robert_ancell: well i've already got a branch....what if i just do a bzr add debian/libmirserver5.install
<kgunn> won't the effect be the same
<robert_ancell> kgunn, I don't think it would treat that as a move like git does
<kgunn> just in lp it'll show removed and added, instead of renamed ?
<robert_ancell> and that makes merges harder
<kgunn> robert_ancell: ok...i'll revert....should i just pull down that mp and redo
<robert_ancell> kgunn, it will just revert the one file
<kgunn> robert_ancell: which script are you refering to ?
<robert_ancell> kgunn, the one I sent you last time, I'll find it again
<robert_ancell> I'll send it to the mailing list
<kgunn> robert_ancell: thanks...i'm extra stupid today (series of late nights/early morns)
<robert_ancell> np :)
<robert_ancell> http://paste.ubuntu.com/6186191/
<kgunn> robert_ancell: thanks...i'm gonna try to fix manually with bzr first
<robert_ancell> kgunn, you also need to edit debian/libmirserver5.install and change the 4 to a 5
<robert_ancell> i.e. usr/lib/*/libmirserver.so.4 -> usr/lib/*/libmirserver.so.5
<kgunn> yes ;)
<kgunn> robert_ancell: ok...unhappy w revert...gonna pull fresh and run the script
<robert_ancell> :(
<kgunn> do i run it just at the top dir of my mir branch
<kgunn> robert_ancell: ok...just blew it away & went fresh (thanks for the script...) would you
<kgunn> give me 2 secs...
<kgunn> robert_ancell: ok...for reals now...can you review https://code.launchpad.net/~kgunn72/mir/bump-libmirserver5-take2/+merge/188968
<robert_ancell> kgunn, +mir (0.0.12-0ubuntu2) UNRELEASED; urgency=low should be +mir (0.0.13-0ubuntu1) UNRELEASED; urgency=low
<robert_ancell> otherwise good
<kgunn> damn it...
<robert_ancell> kgunn, oh, and you need to edit CMakeLists.txt and set set(MIR_VERSION_PATCH 13)
<kgunn> ack...fixing it
<robert_ancell> kgunn, you still have -0ubuntu2 not -0ubuntu1..
<kgunn> robert_ancell: i feel i could tear up a steel ball with a rubber hammer tonight
 * robert_ancell feels glad to be on the other side of the world
<kgunn> robert_ancell: not angry...just capable of f'ing up something so simple
<robert_ancell> packaging/abis/versioning just *look* simple
<kgunn> robert_ancell: ...ok..surely...there's nothing left to have been incorrect :)
<kgunn> robert_ancell: thanks man
<robert_ancell> no worries
<kgunn> racarr: any luck ?
<kgunn> thomi: can you send another update ?
<kgunn> at the end of your day
<thomi> kgunn: sure, I'm waiting to hear from racarr once he's rebuilt the world and we can actually launch unity
<racarr> kgunn: mir build at 47 percent
<racarr> I guess lets abort building the tests
<thomi> racarr: wait, why are you building mir? I thought we had to rebuild everything else?
<racarr> I dont want to deal with the packages because the dev packages
<racarr> are broken
<racarr> apparently?
<racarr> or
<racarr> it tries to pull in newer versions
<racarr> or apt insanity
<racarr> so I dont know how I can get the build dependencies for everything else with the packages
<racarr> so im just building the branch on phon
<kgunn> racarr: hmmm...you mean the packages associated with dev-proposed
<racarr> e
<racarr> no the packages from the CI build
<kgunn> racarr: totally agree with you...
<thomi> right
<thomi> the -dev packages need to pull in other things
<kgunn> racarr: building on the phone....nuke it from orbit, its the only way
<thomi> racarr: if you install them, then do apt-get -f install, everything workls
<thomi> racarr: just don't do an update
<thomi> or... you're gonna have a bad time
<racarr> well it's too late buidling unity-mir now
<thomi> kgunn: srsly. Can we just merge it?
<racarr> is merging it now going to be any better than merging it in 20 minutes when its tested
<thomi> racarr: if it really is 20 minutes, then no. I'm sceptical though
<kgunn> thomi: is starting to learn the estimate/reality ratio :)
<kgunn> thomi: i'd prefer to test it first
<kgunn> if its holy hell for racarr then we'd avoid a nasty one
<kgunn> takin' a little break brb
<thomi> kgunn: ok
<duflu> robert_ancell: Seems NZ DST crept up on me. Hangout?
<robert_ancell> duflu, yep
<racarr> kgunn: thomi: Ok it at least starts!
<racarr> will test autopilot after I buy grociers
<racarr> but unity runs fine so it's safe at least
<thomi> racarr: I don't suppose you have binary packages so I can try it as well?
<racarr> no.
<kgunn> robert_ancell: and the trunk https://code.launchpad.net/~mir-team/mir/development-branch/+merge/188975
<kgunn> mainly...commit msg ok to you ?
<robert_ancell> kgunn, looking
<robert_ancell> kgunn, you have a merge conflict
<robert_ancell> in debian/changelog
<kgunn> robert_ancell: ok...how to handle...
<robert_ancell> kgunn, you need to run 'bzr merge lp:mir'
<robert_ancell> then edit the file manually and run 'bzr resolve'
<robert_ancell> then bzr commit and push
<kgunn> ack
<kgunn> thot so ...just feels a bit weird in a way
<kgunn> robert_ancell: when i push...it'll be lp:~mir-team/mir/??? development-branch ?
<kgunn> in order to merge back in the conflict resolution ?
<kgunn> back in== into the dev branch
<robert_ancell> kgunn, ah yeah. hmm. why did trunk get out of sync?
<robert_ancell> let me try locally
<kgunn> thanks...if you fix, lemme know...i want to know for next time...
<kgunn> takin' a break to edit a freshman english paper
<robert_ancell> hmm. It merges locally fine. Is LP confused?
<robert_ancell> kgunn, manual merge did the trick
<kgunn> robert_ancell: so are you proposing or want me to ?
<robert_ancell> kgunn, I did the merge and the MP looks good
<robert_ancell> I've approved it
<robert_ancell> (not top)
<kgunn> thnank you sir...i'll top approve
<kgunn> racarr: any luck ?
<kgunn> did we lose racarr ?
<duflu> kgunn: I think he mentioned groceries?
<robert_ancell> be back in 20 mins
<duflu> RAOF: Please correct me where I'm wrong (again); https://bugs.launchpad.net/bugs/1234502
<ubot5> Ubuntu bug 1234502 in xserver-xorg-video-nouveau (Ubuntu) "XMir support for bypass incomplete -- there's still one buffer copy the DDX's" [Undecided,New]
<RAOF> Correct.
<duflu> RAOF: Jetlagged much?
<RAOF> Oddly.
<RAOF> I got back on Saturday.
<RAOF> And have been waking early and sleeping early since then.
<kgunn> robert_ancell: just to verify for thomi....if he rebuilds on the phone, mir, he'll have to rebuild unity-mir & platform-api....and the order won't matter
<RAOF> In possibly related news, ZoÃ« reliably wakes at 5:45am.
<duflu> How convenient
<kgunn> robert_ancell: cause racarr 's input branch is based on dev...which is broken/updated server api
<kgunn> not yet in archive
<thomi> well, presumably I'll have to install those mir*-dev packages first, then rebuild unity-mir & platform-api?
<kgunn> thomi: right
<kgunn> thomi: so for all the effort today...did you ever run the AP test with mir enabled ??
<thomi> ok, well, I'm re-flashing the phone now, because somehow I managed to completely bork it
<kgunn> i was confused from some of the scrollback
<thomi> kgunn: nope :(
<thomi> kgunn: I was confused as well - turns out I was running SF
 * kgunn just threw up
<thomi> not literally I hope
<kgunn> thomi: virtually
<thomi> good, well, sorry about that. I guess I'll start rebuilding this stuff
<kgunn> thomi: so...if you enabled mir...what happens (oh...nvmd..borked)
<kgunn> right ?
<thomi> kgunn: if I enable mir, unity won't start
<thomi> ABI mismatch
<kgunn> thomi: gah...right
<kgunn> thomi: thank you for your efforts
<thomi> kgunn: no worries, I'll rebuild this stuff. I just wish there was a faster way
<kgunn> thomi: think there's anyone in integration team/ci/phonedations that could help build us an image quicker ?
<kgunn> based on that branch ?
<thomi> kgunn: not at this time of night, I doubt it. I can ask though
<thomi> kgunn: this is why I was saying ewarlier we should just go ahead and merge it
<kgunn> robert_ancell: ^ thots...
<kgunn> thomi: ok...based on racarr> but unity runs fine so it's safe at least
<kgunn> i agree...
<kgunn> robert_ancell: i need your guru knowledge...racarr kinda did a weird one...dandrader had a branch
<kgunn> robert_ancell: racarr originally merged ontop ...but then retargetd the whole thing to dev
<kgunn> https://code.launchpad.net/~robertcarr/mir/1233944-addendum/+merge/188900
<kgunn> do i just approve racarr's and then it pulls it all in ?
<kgunn> thomi: racarr robert_ancell ...ok...whoever cares..i just top approved it
<thomi> kgunn: I'll have a go at building *all the things*
<thomi> kgunn: if not before, I'll TA it at my EOF
<thomi> err, EOD
<kgunn> alf|xmir_devel: are you seriously here?
<kgunn> thomi: robert_ancell ok...gonna go watch some tv, try not to fall asleep then merge dev onto trunk
<kgunn> thomi: also...can you provide a very explicit list of instructions of what should be run in terms of AP testing
<thomi> kgunn: sure, to whome?
<kgunn> thomi: i'd like it if you could send that to dandrader and cc me...this way, if that code getsmerged he can test his morning
<thomi> sure thing
<robert_ancell> kgunn, ok, we're all go :)
 * thomi installs build-deps for unity-mir
<robert_ancell> thomi, are you just doing a bzr-buildpackage from lp:unity-mir?
<thomi> robert_ancell: a 'bzr bd', yeah
<thomi> it'll take a while since I'm on the phone :-/
<robert_ancell> oh, right
<thomi> some decent armhf hardware wouldn't go astray. I wonder if we could set something up....
<robert_ancell> thomi, what are the options currently?
<thomi> options?
<robert_ancell> thomi, for purchasable hardware
<robert_ancell> with decent power
<thomi> robert_ancell: oh, I have no idea. I was thinking maybe Canonical could buy and then set aside a few calxeda (sp?) boxes, for custom builds
<thomi> another thing that I could set up that would save me a lot of time is a caching apt proxy server
<robert_ancell> thomi, it looks like calxeda doesn't sell products directly. I guess you buy a Dell or HP server?
<thomi> robert_ancell: yeah, or talk to them nicely :)
<kgunn> robert_ancell: so can i just propose rcarr's branch directly to trunk? in parallel...it'd be faster
<robert_ancell> kgunn, I guess so - it shouldn't have any major side effects (famous last words)
 * thomi starts building unity-mir
<robert_ancell> kgunn, it's ready to land in development-branch right?
<kgunn> already approved...waiting for merge
<robert_ancell> just saw that
<robert_ancell> go jenkins!
<kgunn> robert_ancell: just wanting it to hit trunk before didrocks gets on
<robert_ancell> kgunn, sure
<robert_ancell> kgunn, are you going to MP it or manually merge from development branch?
<kgunn> was going to mp then you could approve...i mean, we have the approvals we know what we want & trust it
<kgunn> robert_ancell: ^
<kgunn> and a subsequent dev merge to trunk, that diff should just get ignored
<robert_ancell> sounds good - it will take time for jenkins to merge it but safer to have the check
<robert_ancell> I guess it's better than doing the double wait for jenkins (dev-branch merge, then merge to trunk)
<kgunn> robert_ancell: oh yeah...wouldn't consider anything else
<kgunn> i heart ci
<robert_ancell> ci saves our bacon
<kgunn> right
<kgunn> robert_ancell: ok...can you approve and i'll ta https://code.launchpad.net/~robertcarr/mir/1233944-addendum/+merge/188983
<robert_ancell> hey, it merged cleanly
<robert_ancell> kgunn, approved
<kgunn> robert_ancell: thanks...
<thomi> robert_ancell: what's the platform-api lp project name?
<thomi> ubuntu-platform-api or something?
 * robert_ancell looks
<robert_ancell> thomi, lp:platform-api
<robert_ancell> I don't know why they didn't put the ubuntu- prefix on it
<kgunn> ok...going to bed...night guys
<robert_ancell> later
<robert_ancell> I'll be back in 2 hours
<thomi> ok, I finally have a coherent set of binary packages.
<thomi> rebooting
<thomi> robert_ancell: no luck - seems like nothing happens now
<thomi> robert_ancell: I ger this: "ofono/ofono/account0 initialized" in an endless loop in the unity8 log
<thomi> robert_ancell: and a segfault when I start unity8 manually
<thomi> robert_ancell: BT looks bad too:
<thomi> #0  0x409cd640 in ?? () from /lib/arm-linux-gnueabihf/libc.so.6
<thomi> #1  0x409cf324 in malloc () from /lib/arm-linux-gnueabihf/libc.so.6
<thomi> robert_ancell: OK, so good news! After messing about some more, it now works
<thomi> I have mir/unity8 running, and can drag the home screen around with autopilot
<didrocks> hey kgunn
<didrocks> kgunn: please update the spreadhseet once the commits are in, and we'll try to get it for image 77 (or 78)
<didrocks> we'll get it then ASAP
<duflu> We're still using the spreadsheet idea?
<didrocks> duflu: we do
<duflu> didrocks: I look forward to us having separate development and maintenance branches post-saucy, to make things more clear
<didrocks> duflu: well, we still need to have trunk always releasable.
<duflu> didrocks: Yes, but you know what I mean
<didrocks> yeah ;)
<didrocks> I think there will be a lot of discussions on how to release tings
<didrocks> things
<didrocks> nobody (even us) aren't happy about it
 * duflu assumes that's a mistaken double-negative
<didrocks> duflu: yeah, it is (or you can take it as a hope :p)
<alf|xmir_devel> kgunn: no, forgot to change nick... :)
<alf|xmir_devel> RAOF: Hi! Do you have a moment to check the latest commit in https://github.com/afrantzis/xserver/tree/multimonitor-stabilize ? I change the code to assign root_fragments dynanically to crtcs as needed, so that when mirroring we can have a single root_fragment/MirSurface. The mirroring parts works great, but I somehow managed to cause glitches in non-mirror (extended) modes. Any ideas?
<RAOF> alf|xmir_devel: I'll have a butcher's.
<alf|xmir_devel> RAOF: The glitches are there only when bypassing in mir
<alf|xmir_devel> RAOF: thanks
<RAOF> Ah, bypass.
<duflu> It's true, when I wrote bypass I knew nothing about DDXs and assumed XMir must work something like glamor :P
<mlankhorst> haha
<robert_ancell> didrocks, we have all the changes in the landing pipeline doc on row 129 except for the autopilot fix - should I append that entry or add another one?
<robert_ancell> sorry, I just noticed the autopilot is on line 130, so all is good right?
<didrocks> robert_ancell: yeah, all good :) (Mir is building right now)
<didrocks> robert_ancell: you didn't add anything for the past 30 minutes, right?
<robert_ancell> didrocks, no, and nothing planned to land
<didrocks> (in Mir trunk)
<didrocks> ok, great!
<didrocks> so we're good, I merged the rest of the transitions
<didrocks> and everything is rebuilding
<budgee> Howdy, further to my note a couple of days ago about Synergy and Mir, please see output at: http://pastebin.com/pZVrqJqa
<duflu> budgee: I'm not sure that log helps.... However we did land a fix for Mir exclusively locking input devices, so that sounds like the kind of fix you need. Not sure if it has been packaged yet
<alf|xmir_devel> RAOF: trying the multimonitor-stabilize branch on intel, I don't get glitches, but I am not sure if the glitches I see on radeon are because of radeon or because on my desktop (with radeon) the system moves from clone -> extended configuration on startup. That is, because I can't mirror on my laptop, I can't tell whether after cloning we mess up bypass somehow for future extended configurations...
<robert_ancell> bye all
<alf|xmir_devel> RAOF: I am leaning towards the glitches being a radeon issue. With plain vladmir-upstreaming with a single monitor I still get an occasional glitch on radeon, none with intel. Plus, I get a a segfault with radeon_drv in the back trace when plugging in/out monitors http://paste.ubuntu.com/6187470/
<budgee> duflu: thank yuou
<alf|xmir_devel> RAOF: FYI, here is the valgrind output: http://paste.ubuntu.com/6187493/
<davmor2> kgunn: so mir, gets very, very, very slow if you start opening lots of apps on the maguro.  Also I've noticed that memory usage is up when I enable mir over SF but I can't say for sure that, that is the cause as I'd added apps and debugging stuff etc
<davmor2> kgunn: if I open 4 apps on mir it's like running through treacle (molasses), 4 apps on SF is noticeably fast.  It faster loading and switching and using the app.
<davmor2> kgunn: on the plus side though I only had it lock up on me once.  So mir is definitely more stable than it was by a huge a margin.
<duflu> davmor2: (1) kgunn is offline. (2) maguro is known to be slow with bug 1182930. (3) Multi-surface performance is known to be bad on Android due to bug 1227739. (4) There's always room for improvement later
<ubot5> bug 1182930 in Mir "[mir] Galaxy Nexus rendering performance is too low" [High,Triaged] https://launchpad.net/bugs/1182930
<ubot5> bug 1227739 in Mir "Mir continues to render application surface even when the indicator surface is on top" [High,In progress] https://launchpad.net/bugs/1227739
<davmor2> duflu: Yep I know kgunn is offline, only I'm going to be busy latter.  Thanks for the bug info though I will add myself to those.  I'm still overly impressed by the fast that mir has gone from crashing if you look at it wrong to locking up once in 16 hours use
<duflu> davmor2: Yeah, though once in 16 hours is too much :/
<davmor2> unfortunately I couldn't find anything that screamed crash so I'm assuming there might be a memory leak and the system just ran out of space but I couldn't get access to check, adb was out and the phone was unusable even a long hold on the power button did nothing :(
<davmor2> I had to remove the battery in the end to reset it so I could use it :(
<duflu> I wish more of us had maguro. Most of the mir team does not. So progress on it is slow
<davmor2> duflu: Yeah that is somewhat daft as it is a supported device. But you can't have everything :)
<hikiko> https://bugs.launchpad.net/mir/+bug/1234679 RAOF alf_ look at an interesting bug I found
<ubot5> Ubuntu bug 1234679 in XMir "multimonitor fails to render the screen correctly when both Xmir and X are running and produces "cannot switch monitor configuration" error notification" [Undecided,New]
<hikiko> the screenshot is from monitor 2 I ll upload another one as well
<kgunn> mzanetti: or Saviq ....so there was some prelim AP test attempts on mir, here's what psivaa got...http://pastebin.ubuntu.com/6188183/
<Saviq> kgunn, ze Germans are on holiday today
<kgunn> Saviq: :) i like how an english-as-a-2nd-lang can still crack a "ze" joke
<Saviq> kgunn, "terminate called after throwing an instance of 'boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<std::runtime_error> >'what(): display factory cannot create fb display"
<Saviq> kgunn, sounds like unity8 failed to start - probably an app running still holding the framebuffer
<Saviq> kgunn, now that you mention it, though - we have the indicators_client tests that won't work, 'cause we don't have unity8 running for them
<Saviq> kgunn, will need fixing
<olli> keep beating on the germans
<olli> and I'll unleash the thostr
<kgunn> Saviq: to make sure i understand...this is the old "you need the shell up for everything"...hard to isolate problem ?
<Saviq> kgunn, for indicators_client, yes
<Saviq> kgunn, for now we relied on sf being there always - need to change that
<Saviq> kgunn, the failure above, though, suggests there's a stale app running that blocks "new" unity8 from getting the framebuffer
<Saviq> kgunn, even though unity8 itself isn't there anymore
<kgunn> Saviq: ah
<kgunn> what's weird he said he gets 100% failures...
<kgunn> trying to square that with "stale app" suggestion
<kgunn> alf_: can i ask you to sort of ready yourself to potentially help on some making mir default on touch work ?
<kgunn> alf_: i feel we may have some digging to do...but nothing specific atm
<kgunn> alf_: at the rate we've been going, it'd be good just to be ready...like, at least phablet-flash ubuntu-system --channel devel --no-backup
<kgunn> to get the latest image
<kgunn> alf_: and you know, touch /userdata/.writable_image & touch /home/phablet/.display-mir
<alf_> kgunn: sure, I am on it
<dandrader> alan_g, do you guys have a way of building mir packages using cross-compilation?
<alf_> dandrader: do you care about packages in particular, or binaries will do?
<dandrader> alf_, for binaries there are those scripts which work fine
<dandrader> alf_, but sometime it's nice to be able to build packages to ensure the whole system is using your libraries
<alf_> dandrader: ok, AFAIK, we don't have a straightforward way to cross-compile mir packages, at least I haven't heard of anyone doing it.
<alan_g> dandrader: What alf_ said
<kgunn> dandrader: alf_ actually
<kgunn> dandrader: alf_ to replicate what _will_ be image 79....just flash the current devel-proposed....then apt-get update, install libmirserver5
<kgunn> don't forget to make it writable first ;)
<kgunn> and then turn on mir
<kgunn> dandrader: alf_ then you can either follow thomi's instructions in the bug
<kgunn> or the ci guys said they tried with this reboot, wait for Nautilus window to pop up the mounted share (connection breaks at that moment, takes about 30s after unity8 is visible), run phalet-test-run -n unity8 (after also installing unity8-autopilot)
<kgunn> jibel: would you mind doing an impromptu run down on the bugs you've found...say in 30 minutes
<alf_> kgunn: so that's --channel devel-proposed? Is there a way to go from devel to devel-proposed without downloading an image from scratch?
<kgunn> alf_: i don't think so...and that's the only way to get the latest...otherwise, there's like a day lag in image creation
<alf_> kgunn: channel devel-proposed didn't bring in any new image for me...
<alf_> kgunn: still 78
<kgunn> alf_: hmmm....i suppose there's a moment of promotion where they are equal
<jibel> kgunn, sure, in 30 min.
<dandrader> alf_, how do you tell the image number?
<jibel> (more like 25 now)
<alf_> dandrader: I saw messages like: INFO:phablet-flash:Pushing /home/alf/Downloads/phablet-flash/imageupdates/devel-proposed/mako/version-78.tar.xz.asc to /cache/recovery/
<alf_> dandrader: and I noticed that using the devel-proposed channel didn't download any new files, it reused the ones I had downloaded from devel
<dandrader> alf_, ah, ok. I'm also getting 78
<kgunn> alf_: mind if i assign you that nasty one ? where he can't reboot to a ui
<alf_> kgunn: np
<dandrader> where's the mir log that comes out of unity8?
<dandrader> I see nothing in /tmp...
<dandrader> do I have to enable it somehow?
<dandrader> alan_g, ^
<dandrader> so far I've been using a modified mir_demo_standalone_input_filter to get log messages....
<alf_> dandrader: check http://unity.ubuntu.com/mir/component_reports.html
<dandrader> alf_, thanks!
<dandrader> wow, real documentation!
<alan_g> dandrader: if you want it in /tmp then add --glog/MIR_SERVER_GLOG
<dandrader> hmmm, it seems the android-input logging is not wired to that mir log system
<dandrader> alf_,  or maybe I should set the minimum priority level or something. is there such filtering in mir?
<alf_> dandrader: if you are using glog you can set the level, but by default it should log everything. Using the built-in/default logging mechanism should just print everything to either stdout or stderr. Are you capturing both?
<dandrader> alf_, I'm getting output on stdout and that's fine. but nothing from android-input. will dig further...
<kgunn> dandrader|lunch: ok...as you try to run the AP's hopefully you can repro what plars is seeing
<kgunn> plars can be found in #ubuntu-ci-eng
<kgunn> basically this....<plars> kgunn: running phablet-test-run -n (for unity8) and you see unity8 go off, but never come back.
<kgunn> <plars> kgunn: also, for all ap tests, we have a script that unlocks the screen and restarts unity8 in -testability mode. It doesn't seem to function now either
<kgunn> bbiab
 * alan_g hates it when he backs out all his changes and the problem they cause is still there
<kdub> i like how tdd forces me to refine the dumb interfaces i sometimes invent
 * alan_g discovers that the tests that are failing work fine if they're  run on their own
<alan_g> ... or together
 * alan_g|EOD knows where a nice pint of beer will clarify everything
<racarr> kgunn: Are there images that need testing today?
<racarr>  /bugs that need chasing
<racarr> if not I think the up/down volume keys are my task
<om26er> racarr, hey! would you know if we have a bug to track recent slowness under Mir ? (talking Nexus 4 here)
<om26er> or even did anyone else report that ?
<om26er> I am pretty sure rendering was pretty fast like 10 days ago
<kgunn> latest image 79 supposedly up...boom
<kgunn> racarr: did you already finish the new i/f for zanetti ?
<kgunn> i think it was need to help hud show up
<racarr> kgunn: the input injection yeah, proposed it yesterday
<kgunn> ta
<racarr> ohh and
<racarr> 2 needs fixings
<racarr> >iterates<
<kgunn> :)
<kgunn> racarr: i asked alf_ to look into this one https://bugs.launchpad.net/mir/+bug/1234609
<ubot5> Ubuntu bug 1234609 in unity8 (Ubuntu) "unity8 crashed with SIGABRT in __gnu_cxx::__verbose_terminate_handler()" [Critical,Triaged]
<kgunn> but i'm sure he'd take a second set of eyeballs...
<kgunn> kdub: you used to have a n10 branch up...did you take it down ?
<kdub> kgunn, yeah, put it on pause until i can get the display up
<kdub> no real reason i shouldn't reintroduce it and land it though
<racarr> alf_: kgunn: From this stacktrace https://launchpadlibrarian.net/152224751/Stacktrace.txt
<racarr> the bug looks like...
<racarr> the grand surface race.
<racarr> we need to make it safe to hold shared_ptr<msh::Surface>
<racarr> kgunn: alf_: This may be enough for 1234609: https://code.launchpad.net/~robertcarr/mir/hold-surface-alive/+merge/189156
<racarr> but it needs some thought
<racarr> im not 100% sure yet it's ok
<kgunn> woohoo racarr love it when that happens...
<racarr> kgunn: We'll see :D
<kgunn> dandrader: any luck reproducing what plars was seeing...e.g. not being able to unlock the shell with args...or not having the fake shell load
<dandrader> kgunn, still fiddling with mir code to get android-input logging out of unity8.
<dandrader> that part is not being properly initialized
<racarr> dandrader: Even with MIR_SERVER_LEGACY_INPUT_REPORT=log
<racarr> ?
<dandrader> ah, another undocumented thing. gonna try....
<kdub> code churn thursday
<racarr> dandrader: Technically it's in --help but I guess it's not really very clear at all
<kgunn> kdub: its like hump day...but not as funny
<dandrader> racarr, I was pointed to http://unity.ubuntu.com/mir/component_reports.html. but it must be outdated
<kgunn> plars: so...if you manually unlock and run the AP tests...what do the results look like ??
<kgunn> any passing? or is it dismal ?....any #'s ?
<racarr> dandrader: ah yeah
<plars> kgunn: yes, but not unity8 tests
<plars> kgunn: those are the ones that require the restart of unity though
<plars> kgunn: the ones that don't seem to run ok as long as I manually unlock it
<kgunn> plars: thanks...so passing tests (other than unity8) for the most part ?
<kgunn> plars: sorry...i'm being pestered for some #s  just to be a windsock
<plars> kgunn: I haven't tried but a few (friends-app and notes)
<kgunn> hence my being an irritant :)
<plars> kgunn: np
<dandrader> racarr, works now. thanks
<kgunn> plars: ok...but passing ?
<dandrader> well, wasted a good chunk of time
<kgunn> dandrader: i'm gonna log in a bit...and write down the instructions and update the wiki
<plars> kgunn: for those two, yes
<kgunn> drives me crazy
<plars> kgunn: if I get some time, I can try others, but since it's manual it will be a bit
<kgunn> plars: ack...thanks for that
<racarr> dandrader: :D
<racarr> sorry :(
<plars> kgunn: if you have any you are specifically concerned about, let me know
<plars> I can try those first
<kgunn> thomi: ^ ? ...he might when he comes on...
<kgunn> Saviq: ^ maybe you have a suggestion for plars  in terms of AP tests that would be good to prioritize (besides unity8) ?
<Saviq> kgunn, not really
<kgunn> dandrader: so it seems like the best item to debug first is the AP run for unity8 since it seems the fake-unity8 load is unhappy....and looks like we at least can run other AP test manually
<racarr> short lunch back in 20
<kgunn> plars: at least gallery & camera apps would be good to run
<kgunn> then msg
<dandrader> racarr, need your approval here, btw
<dandrader> https://code.launchpad.net/~dandrader/mir/mergeFakeInputReaders/+merge/188662
<dandrader> kgunn, do you know if I still need to install that? http://people.canonical.com/~thomir/python-ubuntu-platform-api_1.1daily13.06.13-0ubuntu1_armhf.deb
<kgunn> dandrader: it should be in image 79
<kgunn> dandrader: i saw robru indicate he pushed it to trunk...you could install just to be on the safe side
<dandrader> kgunn,  I have version 1.1+13.10.20131001.1-0ubuntu1 installed. but I'm too dumb to figure out for sure if this version number is higher than 1.1daily13.06.13-0ubuntu1
<kgunn> dandrader: lemme dig for a moment
<kgunn> dandrader: yes...it has the relevent mp merged into that one...you're good to go
<kgunn> don't need to load that deb
<dandrader> kgunn, ok, thanks
<racarr> back
<dandrader> plars, hey
<dandrader> kgunn, told me you're able to run some autopilot tests successfully on the device with unity8-mir
<dandrader> "notepad and friends"...
<dandrader> plars, is that so?
<kgunn> dandrader: so i'm on n4, image 79(latest one)...i just ran the single ubuntu toolkit ap test per thomi's bug...it worked no prob
<thomi> morning
<dandrader> thomi, hi!
<thomi> o/
<dandrader> kgunn, ok, I certainly *must* have some outdated package them. gonna re-flash
<kgunn> thomi: \o/
<kgunn> thomi: we're so much better than where we were....wanna quick hang out to catch up ?
<dandrader> was using a 78 image + apt-get update&dist-upgrade
<kgunn> dandrader: yeah...slightly untrustworthy...
<thomi> kgunn: sure
<kgunn> dandrader: my steps were flash, touch writable_image & display-mir, then phablet-click-test-setup, then sudo apt-get install ubuntu-ui-toolkit-autopilot...then autopilot run -v ubuntuuitoolkit.tests.gallery.test_gallery.GenericTests.test_navigation
<kgunn> and it just worked...pretty sure its a bum img/package cfg you got there
<thomi> kgunn: ready when you are
<kgunn> https://plus.google.com/hangouts/_/d3c5982669f82db12c38b740a81c7e362e6bbdfe?pqs=1&authuser=0&hl=en
<kgunn> thomi: ^
<kgunn> dandrader: ^ if you wanna join in case you got AP queries
<dandrader> thomi, hey, don't forget about testing autopilot tests with unity8-mir in maguro. it's certainly not working for me
<kgunn> dandrader: no doubt...paul just verified he tested on a n4
<thomi> dandrader: yeah, weill do
<thomi> flashing my GN now
<kgunn> thomi: so http://bazaar.launchpad.net/~phablet-team/powerd/trunk/view/head:/cli/powerd-cli.h
<kgunn> according to chicken
<thomi> kgunn: so I tried that
<kgunn> but
<thomi> kgunn: problem is, you need to run it as root
<thomi> also, it doesn't appear to work
<kgunn> ricmm: no problem...we're discussing here
<thomi> well, it worked for a while, then my screen flashed, now it's black, and I cannot wake it up any more
<thomi> ahhh, unity8 crashed
<ricmm> thomi: have you managed to autopilot unity8 yet then?
<ricmm> or only apps
<kgunn> ricmm: only apps...
<thomi> ahh, I see. adb bug. adb drops shell connections when you attach a second device :-/
<kgunn> unity8 suffers the weird screen blank scenario
<thomi> ricmm: just flashing my GN, since people said they were having input problems with it
<ricmm> thomi: did you get around the -fullscreen issue?
<thomi> ricmm: I'm not sure what that issue is, sorry
<ricmm> $ unity8 -testability -fullscreen
<ricmm> was failing for me, because -fullscreen actually made Mir try and setup ./ullscreen as the socket path
<ricmm> it taks a file,f argument for it
<ricmm> takes*
<thomi> haha
<thomi> nice
<ricmm> kgunn: I think a fix for that should be in Mir, making the server process take such a common argument like -f or -file sounds problematic
<ricmm> make it mir_socket_path or something instead
<thomi> or maybe make mir understand --
<thomi> so you could do something like ./unity8 -some -mir -options -- -some -unity8 -options
<ricmm> or that
<kgunn> ricmm: you need it like asap ?
<ricmm> kgunn: I dont need it, we can probably get away with a change in unity8-autopilot itself
<kgunn> ricmm: thomi ...back to the wakelock need....what's the best way to manage a wakelock between unity8 and fakeunity8
<racarr> robert_ancell: brt
<robert_ancell> bus rapid transit?
<thomi> kgunn: just confirmed that mir does not recognise the AP-created device on a maguro
<thomi> filing a bug now
<thomi> kgunn: racarr: what do you think? https://bugs.launchpad.net/mir/+bug/1234956
<ubot5> Ubuntu bug 1234956 in Mir "mir does not recognise autopilot autopilot input device on maguro" [Undecided,New]
<thomi> kgunn: seems like that should be 'critical', but I'll let you decide :)
<kgunn> racarr: can you have a look ? ^
<racarr> I have no maguro
<racarr> kgunn: ^
<kgunn> dang ti
<kgunn> and it
<racarr> ok heres the thing though do we even know
<racarr> that autopilot finger is the issue as the bug implies
<racarr> because don't we get that output on the nexus 4 too
<racarr> while it works
<kgunn> thomi: ^ ?
<thomi> racarr: I don't think so, but I can test
<thomi> one second.. have to replicate mysetup :-/
<thomi> s/second/10 minutes/
<kgunn> turns into a day
<racarr> ok. ill start theorizing...?
<racarr> not sure how else to help
<racarr> thomi: Is there anything after
<racarr> "Device added id=8, etc" in the log
<thomi> racarr: no
<thomi> there's the WW line, then the II line that you just referred to, then nothing
<racarr> thomi: ok I think I see the problem
<racarr> event hub.cpp l315
<racarr> (('ABS_X', 0L),
<racarr>                    AbsInfo(value=0, min=0, max=0, fuzz=0, flat=0, resolution=0)),
<racarr>                   (('ABS_Y', 1L),
<racarr>                    AbsInfo(value=0, min=0, max=0, fuzz=0, flat=0, resolution=0)),
<racarr> min = max
<racarr> so mir detects it as an invalid axis
<thomi> any ideas why it works on the mako?
<thomi> interestingly, that's not what autopilot sets
<thomi> we set screen resolution as the max value
<racarr> perhaps that code has a problem
<kgunn> racarr: so you think its in autopilot code?
<kgunn> racarr: or eventhub ?
<thomi> easy enough to print out what capabilities we're setting
<thomi> in autopilot i mean
<racarr> I mean
<racarr> the python log from checking the device
<racarr> without mir involved
<racarr> is returning this device with no valid x or y axis
<racarr> so I think the problem is elsewhere
<racarr> I think it would work, is ABS_X/ABS_Y had min or max values
<racarr> or there was a
<racarr> REL_X and REL_Y
<thomi> that's true, I wonder if that's because autopilot is setting it invalid'ly, or the uinput system is changing it on us?
<kgunn> thomi: ok..i feel stupid asking this, because its been such a _thing_ but the "unlocking shell" automation....where would that bug be ?
<racarr> we should see what
<racarr> evdev says about the device on uh
<racarr> nexus 4
<racarr> though that doesn't tell us that much really
<racarr> im checking it out
<thomi> kgunn: ugh. That's a topic for a hangout call
<kgunn> now ?
<thomi> kgunn: if you like
<kgunn> https://plus.google.com/hangouts/_/463beb0eb5cb65ab4981da5ea7d6cbcf45202c13?pqs=1&authuser=0&hl=en
<racarr> on nexus 4 the axis are set http://pastebin.ubuntu.com/6190026/
<racarr> just using python and creating a device
<thomi> ahhh, the problem is that the upa hack/fix returns 0,0,0,0 on the maguro
<thomi> easy to fix, at least
<lool> racarr: ^
<thomi> racarr: robert_ancell, do either of you have a Nexus 10?
<robert_ancell> thomi, no, I think only duflu has one int the team
<robert_ancell> I mean kdub
<thomi> kdub: awake still?
<kdub> still awake!
<kdub> i have a nexus 10
<thomi> kdub: can you please tell me what this returns?
<thomi> adb shell getprop ro.product.device
<kdub> probably manta... checking
 * thomi hopes it returns "manta\\n"
<kdub> yes, manta
<thomi> cool. Could I get someone to approve this please https://code.launchpad.net/~thomir/python-ubuntu-platform-api/fix-1234956/+merge/189193
<thomi> and robert_ancell, could you please add that to the landing SS?
<thomi> it's super-duper-critical.
<robert_ancell> thomi, sure
<thomi> like.. the world will 'splode otherwise
<thomi> thanks :)
<kdub> thomi, looks okay to me.. do i have approve powers?
<robert_ancell> thomi, is ro.hardware an obsolete key?
<kdub> i think its just a key that not everything sets
<thomi> well, the problem was that on maguro it returned "tuna"
<thomi> robert_ancell: I'm not sure what you mean by an "absolute key"
<kdub> ah, a hardware variant key
<thomi> kdub: if you approve it I can really approve it
<robert_ancell> thomi, huh, it appears I can't edit that spreadsheet
<robert_ancell> kgunn, ^
<kdub> thomi, i did +1
<thomi> kdub: thanks
<thomi> that worked
<thomi> canonical-ps is in ~python-upa-team
<thomi> so, \o/
<thomi> robert_ancell: paste me the link? I might have edit rights still
<robert_ancell> I guess there's a whitelist of editors?
<kgunn> robert_ancell: the landing sheet ?
<robert_ancell> kgunn, yes, but thomi has got access to it
<thomi> OK, I added it. not sure I did it right
<kgunn> robert_ancell: shared with you again...
<thomi> kgunn: do I need to ping anyone?
<thomi> or is adding it to the SS enough?
<kgunn> robert_ancell: it was the other google avatar :)...so you have access twice
<robert_ancell> ah, that makes sense
<robert_ancell> I *thought* I had access
<kgunn> thomi: no, you might just update the status when its merged....but if you put waiting for merge & "its for mir" :) then it usually fast tracks it
<kdub> oh boy, found the ioctl i needed in a package we already depend upon
#ubuntu-mir 2013-10-04
<thomi> kgunn: OK, it's landed in trunk, I updated the SS
<RAOF> Mmm.\
<RAOF> A piglit run is an excellent way to trigger those radeon multihead glitches!
<alf_> RAOF: glad you can reproduce them, is this with pure xmir, or with the multimonitor-stabilize branch?
<RAOF> alf_: Pure xmir.
<RAOF> The multimonitor-stabilise code looks fine (but not tested on this glitchy radeon yet)
<RAOF> Actually, I had some thoughts about how to remove the rest of the mir_wait_for()s, which we should do to prevent those EQ overflows.
<alf_> RAOF: +1, if it can be done reasonably
<RAOF> alf_: Oh, has nested gbm got itself magically fixed while I was otherwise engaged, or is that still up for grabs?
<alf_> RAOF: not fixed, mlankhorst tool a look at the code, and cleaned up the paths we should be taking (ping him for the cleanup). He said the code could work in theory, but for some unknown reason it doesn't...
<RAOF> alf_: Heh. That was what I concluded when I looked at it in Lexington :)
<RAOF> alf_: I think *something*'s closing a handle when it shouldn't, but I didn't start to track it down.
<alf_> Saviq: How do I start unity8 manually on the phone? E.g. after a crash, or if I want to run with gdb or valgrind?
<mlankhorst> RAOF: meh just hack the kernel to not re-use gem handles
<alf_> jibel: Hi! How do I start unity8 manually on the phone? E.g. after a crash, or if I want to run with gdb or valgrind? So far I have 'export QT_QPA_PLATFORM=ubuntumirclient' and the 'unity8' but that crashes with http://paste.ubuntu.com/6191320/
<alf_> Saviq: ^^
<jibel> alf_, Hi, I use upstart with 'start unity8', the job is in /usr/share/upstart/sessions/unity8.conf
<jibel> but it apparently only does an exec unity8
<alf_> jibel: is that with the phablet user?
<jibel> alf_, yes sorry, as phablet
<jibel> sudo -i -u phablet
<jibel> then start unity8
<alf_> jibel: thanks! also, I don't seem able to ssh into the phone, although I can ssh locally in the phone, and network is working. Have you come across that?
<pete-woods> hey guys, random question, I have a library (libusermetrics) that unity8 is using, it listens to dbus signals from a system dbus service
<pete-woods> under mir, it doesn't seem to react to the signals any more
<pete-woods> can anyone think of anything stupid I could have done that would tie it into x/surface flinger?
<pete-woods> it's using the qt dbus libraries
<jibel> alf_, no, I generaly use adb
<Saviq> alf_, alan_g, hey guys, can you please have a look at bug #1235159 and bug #1235000
<ubot5> bug 1235159 in mir (Ubuntu) "Mir fails to start if there's a stale socket" [Undecided,New] https://launchpad.net/bugs/1235159
<ubot5> bug 1235000 in unity8 (Ubuntu) "Unity8 wont start on Mir when screen is blanked" [Undecided,New] https://launchpad.net/bugs/1235000
<alf_> Saviq: sure
<alan_g> Saviq: 1235159 is a consequence of fixing https://bugs.launchpad.net/bugs/1216237
<ubot5> Ubuntu bug 1216237 in mir (Ubuntu) "Mir silently overwrites and reuses /tmp/mir_socket, rendering the previous server useless" [Medium,Fix released]
<Saviq> alan_g, yeah, I mentioned that in the description
<Saviq> alan_g, but couldn't we find out that the socket is stale? or would that be unity8's / unity-mir's responsibility?
<alan_g> Saviq: Of course it is *possible* to find out. But it does complicate things - what is the use case that requires it?
<Saviq> alan_g, it happens in connection with the "can't unblank" issue
<Saviq> alan_g, starting unity8 with mir when screen is off results in that â
<Saviq> alan_g, then, when you kill it and want to try again, the socket's preventing it from starting
<alan_g> Saviq: so, a possibly simpler solution would be an atexit handler that deletes the socket?
<Saviq> alan_g, sure, if that's not in place yet?
<alan_g> Saviq: I believe not - although it would depend on how violently the process is killed
<Saviq> alan_g, yeah, so not reliable enough at times
<Saviq> alan_g, one other idea would be for the upstart job to delete it on startup
<Saviq> alan_g, arguably when the unity8 job starts, there should not be a mir socket lying around
<alan_g> Saviq: arguably the mir socket shouldn't outlive the process - there must be more Mir can do to clean up. I'll look into it this afternoon.
<Saviq> alan_g, thank you
<alan_g> alf_: is the blanked screen one something you've got a handle on?
<alf_> alan_g: I am not very familiar with that part of the android code, but I will give it a try, when I am done with https://bugs.launchpad.net/mir/+bug/1234609
<ubot5> Ubuntu bug 1234609 in Mir "unity8 crashed with SIGABRT in __gnu_cxx::__verbose_terminate_handler()" [Critical,In progress]
<alan_g> alf_: me neither. Thanks
<alf_> Saviq: what part of unity8 exactly depends on libmirserver? That is, if I change libmirserver (breaking ABI), what other libraries do I need to rebuild to try it out?
<alf_> Saviq: the rdepends I see are libunity-mir1 and libubuntu-application-api-mirserver1
<Saviq> alf_, yeah, sounds right
<Saviq> greyback, anything else â ?
<gema> hi, any mir dev around at this time?
<gema> or anyone using mir on their phone daily
<greyback> alf_: that's it
<alf_> Saviq: greyback: thanks
<Saviq> gema, alf_ and alan_g are devs
<gema> Saviq: ack
<alan_g> gema: what's up?
<gema> alf_, alan_g I have observed a big degradation in performance overnight to the point that hhis morning my phone was almost non responsive
<gema> alan_g: is this something you guys are aware of?
<gema> alan_g: and my batery was almost completely drained, as well
<ogra_> gema, did you log in and check with top whats eating your device ?
<ogra_> (very unlikely thats Mir)
<gema> ogra_: no, I didn't I was on the move this morning when this happened
<gema> ogra_: mir is the only thing I have enabled yesterday that is super new
<gema> ogra_: I have been leaving my phone overnight since day one and doing same test cases as yesterday night in the morning
<gema> ogra_: ok, so your theory is that there is some other process at 100%
<gema> ogra_: the only reason I am blaming mir is because the transitions were super slow , the gallery would come up white screened, etc
<gema> ogra_: by the time it was a brick and I checked at home, top looked ok
<ogra_> gema, there are knoen issues with unity8 and suspend under Mir
<gema> ogra_: what does suspend mean in this context?
<ogra_> ?
<gema> I haven't suspended the phone, does it go into suspend mode after a while or.. ?
<ogra_> your device is always suspended unless the screen is on
<gema> ogra_: but it can take calls
<ogra_> yes, that bit isnt suspended
<gema> ogra_: so it is not totally suspended
<gema> ogra_: can I adb into it if it is suspended?
<ogra_> arm allows to keep single devices unsuspended
<ogra_> it is suspended
<gema> ogra_: ok
<ogra_> if you connect a cable USB (and adbd) are unsuspended
<alf_> gema: there was a bug about unity8 + mir taking 100% cpu, it seems to be fixed in the latest devel-proposed image (80)
<gema> alf_: ack, will move to that one then
<ogra_> (and everything you need to use adbd ... which means the whole system wakes up in this case
<ogra_> )
<gema> ogra_: ack
<gema> alf_: thanks, will try system settings on that one and keep it running for a day or so to see if it degrades
<gema> alf_: in fact today is friday, I am going to run it over the weekend :D
<alf_> gema: even better :)
<gema> alf_: thanks!
<gema> ogra_: whilst I have your attention, do you know if this change is on image 80: http://bazaar.launchpad.net/~indicator-applet-developers/indicator-messages/trunk.13.10/revision/383
<gema> ogra_: or where do I check for it
<ogra_> if you click on "back to branch summary"  you should see if it was merged some time
<om26er> gema, I talked about the slowness with Saviq yesterday as well. He was not seeing it but I see it, very clearly
<Saviq> om26er, I'm seeing it now, too
<Saviq> om26er, gema, top shows nothing hogging the CPU, but there's definitely something wrong with unity8@mir there
<ogra_> gema, and at the top of this branch you see that the package was released only 31min ago ... so will likely be in the next build
<ogra_> (last commit that is)
<om26er> Saviq, I can even note the slowness in a progress indicator If I look closely
<gema> Saviq: good that you are seeing it, it's a bit sneaky to put a finger on it
<gema> Saviq: I have been trying :/
<gema> ogra_: ack, thanks
<Saviq> ogra_, have you seen the device not waking up properly under Mir? I can ping it, but adb is not working nor does the shell come up?
<ogra_> Saviq, nope, havent had that yet
<Saviq> ogra_, it's what tsdgeos says in -touch
<ogra_> Saviq, tsdgeos cant reboot
<Saviq> ogra_, I think mine might be the same, really, only I misattributed it
<gema> ogra_: I couldn't reboot in the end either
<om26er> yeah, reboot does not work for me as well. have to press the power button for 10secs to bring it back to life
<Saviq> alf_, for me it's very easy to reproduce gema's and om26er's slowdown - just run calculator app autopilot test suite - after it's finished everything just crawls :/
<Saviq> alf_, top is silent, so is iotop
<Saviq> swap isn't touched
<gema> om26er: do you have a bug number?
<om26er> gema, no, didn't report it (yet)
<gema> om26er: ack, I am reflashing by now, please let me know number whenever you have it
<om26er> gema, same here, reflashing. I'll report a bug now
<gema> om26er: ack
<om26er> Saviq, Should I report for unity8 or Mir ?
<Saviq> om26er, both, please
<Saviq> alf_, restarting just unity8 helps - so there's something going on between unity8 and mir for sure
<om26er> gema, bug 1235190
<ubot5> bug 1235190 in mir (Ubuntu) "[mako] Unity8 on Mir got slow" [High,New] https://launchpad.net/bugs/1235190
<gema> om26er: thanks
<om26er> np
<gema> om26er: confirmed :D
<gema> Saviq, alf_: bug 123519
<ubot5> bug 122009 in vino "duplicate for #123519 ** ERROR **: file vino-preferences.c: line 108 (vino_preferences_dialog_get_password_from_keyring)" [Critical,Fix released] https://launchpad.net/bugs/122009
<gema> oh, not that one
<Saviq> nope ;)
<gema> bug 1235190
<ubot5> bug 1235190 in mir (Ubuntu) "[mako] Unity8 on Mir got slow" [High,Confirmed] https://launchpad.net/bugs/1235190
<gema> :D
<alf_> gema: thanks
<om26er> gema, can you try this: go to system settings there try to change the wallpaper, when the picker appear tap 'cancel' CRASH!!
<om26er> it seems if an app tries to exit itself system hangs because the same problem happens in the video player when I tap it close button (the one on the extreme left)
<gema> om26er: what happens is that if you have an extra app open, the flow goes to that app instead of going back to system settings
<gema> om26er: can you try having only system settings open?
<om26er> gema, I only had system settings opened. no other apps were opened.
<gema> om26er: ok, let me try that
<gema> om26er: doesn't crash for me but it takes two clicks to get rid of the gallery for some reason
<gema> om26er: I am on image 80, btw
<om26er> I am on 80 as well(just flashed) and the crash is pretty consistent.
<Saviq> om26er, I think lool mentioned settings crashing around wallpaper selection
<Saviq> om26er, please apport-bug it and affect mir
<lool> goal is trying to identify the top issues (Mir or other things needing porting to Mir) that prevent most tests from failing; I'm sure there's commonality in the AP regressions we're seeing across the board
<om26er> Saviq, that's bug 1235195
<ubot5> bug 1235195 in mir (Ubuntu) "[Mir] Unity8 crashes when an app tries to exit itself" [High,New] https://launchpad.net/bugs/1235195
<Saviq> om26er, can you apport-bug it so that we get the traceback?
<Saviq> om26er, I mean apport-bug /var/crash/blah.crash
<Saviq> om26er, or maybe apport-collect now? is it possible to send the .crash post-factum?
<om26er> Saviq, I attached the .crash file. having hard time reporting a bug using apport-bug file.crash since I have to pull the file first to my laptop.. and apport does not seem to like that
<Saviq> om26er, why do you have to pull that file over?
<Saviq> om26er, apport-bug is there just fine on the device?
<om26er> Saviq, apport bug is supposed to open a browser link, isn't it ?
<Saviq> om26er, it will print it out for you
<Saviq> om26er, just copy-paste to your desktop
<om26er> Saviq, yeah. it worked with apport-cli :)
<jibel> om26er, ubuntu-bug falls back to apport-cli if there is no display, if it doesn't it is a bug in apport
<om26er> ok. reported a new bug https://bugs.launchpad.net/mir/+bug/1235209
<ubot5> Error: ubuntu bug 1235209 not found
<om26er> its private while the retracer runs
<alan_g> alf_: when you've got the headspace, would you take a look at https://code.launchpad.net/~alan-griffiths/mir/mir_lifecycle_connection_lost/+merge/189021
<alf_> alan_g: sure
<dandrader> ping kgunn
<kgunn> dandrader: pong
<dandrader> kgunn, so, did the guys try the autopilot tests on galaxy nexus?
<dandrader> kgunn,  did they work?
<kgunn> dandrader: yes...found out someone was picking up wrong
<kgunn> dandrader: product variable...was using tuna instead of maguro
<kgunn> dandrader: thomi fixed it in the ap plugin
<dandrader> ah, great. so I wasn't crazy afterall :)
<kgunn> dandrader: nope...you no crazy :P
<kgunn> ok...brb
<olli> alan_g, dandrader, do we have somebody looking at https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1233245
<ubot5> Ubuntu bug 1233245 in unity8 (Ubuntu) "[mir] key events not working through input devices" [High,Incomplete]
<olli> Saviq, just mentioned it as an issue for AP tests that "type"
<dandrader> olli, can start on it right away, if it's a priority
<olli> dandrader, got other high priorities?
 * dandrader as just getting started on https://bugs.launchpad.net/unity-mir/+bug/1234570
<ubot5> Ubuntu bug 1234570 in unity-mir "With Mir - When an app is closed next app on 'Recent apps' opens" [High,In progress]
<dandrader> s/as/was
<olli> Saviq, is 1234570 less important?
<Saviq> dandrader, that'd be what you call an interrupt ;)
<Saviq> olli, â
<dandrader> not really, still flashing my device with the latest stuff
<olli> Saviq, iow: ok for dandrader to look at 1233245?
<Saviq> dandrader, if you could look at the keyboard input, that would be nice - either with autopilot or the volume up/down keys - should effectively be the same issue
<Saviq> olli, yes
<olli> k
 * olli is tired
<olli> dandrader, thx!
<olli> can you have it fixed in say... -1h ;)
<dandrader> Saviq, olli np, will switch to the keys bug then
<olli> thx man
<dandrader> hehehe. unfortunately my time machine is broken at the moment :)
<olli> so fixing that might be an even higher prio
<alf_> alan_g: what's the purpose of the time limit in test_server_disconnect.cpp ?
<alf_> alan_g: (in MyTestingClientConfiguration)
<alan_g> alf_: To stop the test running forever (but maybe it isn't needed...)
<alf_> alan_g: the problem I see is that if the timeout occurs we don't have a condition to check success/failure
<olli> dandrader, kgunn just mentioned that racarr might be looking into that as well, pls coordinate when he is online
<alan_g> alf_: then we won't have had a callback and we fail
<alan_g> 243	+ EXPECT_CALL(mock_event_handler, handle(mir_lifecycle_connection_lost)).Times(1).
<alf_> alan_g: ahh, missed that, thanks
<alan_g> alf_: np
<greyback> dandrader: please test unity-mir trunk for bug 1234570, I should have fixed that
<ubot5> bug 1234570 in unity8 (Ubuntu) "With Mir - When an app is closed next app on 'Recent apps' opens" [High,Triaged] https://launchpad.net/bugs/1234570
<dandrader> greyback, ah, good to know
<dandrader> will leave a note on the bug itself
<kgunn> greyback: do i need to get that on the "ask sheet" :)
<greyback> kgunn: yep
<kgunn> greyback: shall i say pull all trunk or cherry ?
<kgunn> i said trunk...
<alan_g> greyback: Can I get your opinion? Re getting apps to save state when the server goes away. rcimm suggested sending "mir_lifecycle_state_will_suspend", but I've proposed a new event "mir_lifecycle_connection_lost" in https://code.launchpad.net/~alan-griffiths/mir/mir_lifecycle_connection_lost/+merge/189021
<greyback> kgunn: there's only 1 commit, so trunk
<greyback> alan_g: why would an app need to distinguish the two events? In both cases, it should save it's state and prepare to be killed
<alan_g> greyback: Well, I did it that way because I wanted to call "raise(SIGTERM)" for the latter
<alan_g> greyback: And I am doing that in a default event handler
<greyback> alan_g: the only distinction I see from the app's perspective is that, with "mir_lifecycle_state_will_suspend" it has 3 seconds to save its state, whereas with "mir_lifecycle_connection_lost" does it have any such time guaranteed?
<greyback> because a suspended app may be killed at any time. We don't guarantee it will be resumed
<alan_g> greyback: From my perspective "mir_lifecycle_connection_lost" allows the app to decide to save and then exit, or to drop the existing connection and try to connect again
<alan_g> but maybe that is too flexible
<greyback> alan_g: if it is possible to drop existing connection and try reconnecting, then I support having a different signal. I wouldn't use 'lifecycle' in the name though for that case
<dandrader> olli, Saviq please ignore me. I was running under SF :/
<olli> dandrader, ignored
<Saviq> dandrader, thing is, it started working for me suddenly...
<dandrader> Saviq, did you restart unity8?
<Saviq> dandrader, yeah, like a few times
<Saviq> dandrader, am restarting all the time due to bug #1235190
<ubot5> bug 1235190 in Mir "[mako] Unity8 on Mir got slow" [Critical,Confirmed] https://launchpad.net/bugs/1235190
<alan_g> greyback: There's nothing in Mir that require the process exits - it is "just" the connection that has gone bad. (Of course, the server may well be gone for a while.)
<alan_g> greyback: Although defaulting to "raise(SIGTERM)" makes the Mir examples behave better when the server dies.
<greyback> alan_g: sure, I just got the impression that reconnecting to new Mir server instance wasn't possible, that Mir held some client state it couldn't do without. If reconnect possible, I say it's better solution than kill/respawn
<alan_g> greyback: Mir holds client state against the connection, clear down the connection and you can start again
<dandrader> Saviq, are you sure you're not running under SF? :)
<Saviq> dandrader, just checked, yes :)
<alan_g> We have tests with multiple, independent connections from one client
<greyback> alan_g: ok, well I approve the added signal. For my info, what client state does Mir hold? Surface geometry?
<alan_g> greyback: The connection has info about the display and a collection of surfaces, the surfaces have geometry and buffer info
<greyback> alan_g: ok, what I expected. Thanks
<alan_g> greyback: do you want to suggest another name for the event?
<greyback> alan_g: it isn't really related to lifecycle, so maybe just "mir_connection_lost" ?
<alan_g> greyback: Well, it is part of the MirLifecycleState enum passed to the MirLifecycleEventCallback
<greyback> alan_g: ok, "mir_lifecycle_connection_lost" will do
<dandrader> Saviq, do you know what turns the screen on and off when you press the power button?
<Saviq> dandrader, powerd
<dandrader> Saviq, so powerd listens directly to the /dev/input/event files, right?
<Saviq> dandrader, more or less, yes
<davmor2> kgunn: quick test, Under mir, open the terminal popup the keyboard.  No rotate the phone, now open the keyboard again do both sides of the keyboard work
<kgunn> davmor2: definitely skim osk bugs for rotation (and restest with SF...there were lots of issues previously)
<davmor2> kgunn: very quickly if I do /home/phablet/.display-mir (reboot) and then do ps aux |  grep unity-system-compositor I should see it there right?
<kgunn> davmor2: nope
<kgunn> davmor2: your only means to see if mir is running on touch
<kgunn> davmor2: is to ps aux | grep surfaceflinger
<kgunn> davmor2: if you do not see it...then you're running mir
<davmor2> kgunn: ah that showed nothing
<davmor2> kgunn: thanks I had this horrible feeling that maybe part of it wasn't installed when I didn't see unity-system-compositor
<kgunn> davmor2: yeah, bit of a negative test...cause on touch, mir is in the unity8 process
<davmor2> kgunn: ah right okay that makes sense :)
<davmor2> kgunn: also is there a way to get screenshot yet?  I'm assuming not but thought I would double check
<kgunn> davmor2: not yet...its kinda anti-security in a way....we're talking about how to add for "special" apps to use for debug and such
<kdub> can't you cat the fb? i thought that trick still worked
<dandrader> racarr, ping
<racarr> Morning
<alan_g> Evening
 * davmor2 resorts to using cheese as a screenshoter for mir.  Thinking outside the box :D
<dandrader_> racarr, have you started working on that yesterday? https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1233245
<ubot5> Ubuntu bug 1233245 in Mir "[mir] key events not working through input devices" [Undecided,In progress]
<alan_g> kdub: I was targetting the wrong branch. Please re-review https://code.launchpad.net/~alan-griffiths/mir/mir_lifecycle_connection_lost/+merge/189375
<kdub> done
<alan_g> quick! ;)
<alan_g> Have a good weekend!
<racarr> dandrader: I think I will start working on it ASAP
<dandrader> racarr, because I'm on it
<racarr> the problem is unity8 can't really get focus the way things are set now
<racarr> so I was planning to add a new component in unity-mir "KeybindingEventFilter"
<racarr> which lets you like
<dandrader> racarr, I'm thinking along the lines of adding an input filter for such key events in unity-mir
<racarr> bind_key(keycode, surface)
<dandrader> s/input/event
<racarr> and uses the input-injecter
<racarr> not yet quite landed
<racarr> to inject them to the shell surface
<racarr> yes. I think using an input filter is the way to go
<racarr> but I think we should inject them to the shell surface so the rest of the shell
<racarr> can handle as normal
<racarr> bind_events_to_surface(std::function<bool(MirEvent const&)> consumes_event, std::shared_ptr<msh::Surface> const& target)
<racarr> dandrader: Does that make sense?
<racarr> the input injecter api which you can merge from ~robertcarr/mir/input-injecter-api
<racarr> is very simple just, surface->inject_input(shared_ptr<InputInjecter>, MirEvent)
<racarr> InputInjecter comes from the_input_injecter()
<dandrader> by "inject them to the shell surface" you mean letting those volume key events reach shell's qt event loop in the same way as any other event
<dandrader> then yes
<dandrader> racarr, ^
<racarr> dandrader: Yes
<racarr> if that can be done just directly through Qt I guess that is fine
<racarr> but there isnodirect
<racarr> MirEvent->Qt translation code
<racarr> because it goes through the ubuntu-platform-api
<racarr> and the Event struct there
<racarr> so I think using the InputInjecter, and injecting it on to the channel and the client reads it just like normal
<racarr> will be the best way
<dandrader> racarr, sure
<racarr> ok sounds good to me
<racarr> one thing to watch out for
<racarr> is scan codes are not mapped to key codes
<racarr> on the server side
<racarr> but I think there is some AINPUT_KEY_VOLUME_DOWN scancode or such
<racarr> that you can safely use
<racarr> ok I am going to start reproducing crashes here https://docs.google.com/a/canonical.com/document/d/1b-X9tN2Q9c_5r39XzA-Ppebbjuin5zVf9SkAGMcdp9Q/edit#
<racarr> and hopefully pick one off
<racarr> yay think I found the problem in hold-surface-alive
<mlankhorst> ]
<racarr> Lunch!
<racarr> will be verifying the fix to hold-surface-alive when I get back then using that environment
<racarr> to reproduce some more bugs
<racarr> Back
<racarr> ricmm: taskcontroller.h:57:5: error: âupstart_app_launch_app_failed_observer_tâ does not name a type upstart_app_launch_app_failed_observer_t failureCallback;
<racarr> do you know what I need?
<dandrader> racarr, build from trunk
<dandrader> racarr, lp:upstart-app-launch
<racarr> dandrader: Thanks :D
<dandrader> racarr, MirEvent takes the key code from android::InputEvent as it is, unmodified
<dandrader> racarr, so AKEYCODE_* are used/valid there
<dandrader> racarr, but those keycodes are not exported by mir headers
<racarr> dandrader: you should be able to use KEY_VOLUMEDOWN and KEY_VOLUMEUP on the scancode
<racarr> from linux/input.h
<dandrader> racarr, ok, but I wonder what's the use of those mir key codes
<dandrader> at the moment, it seems they're unusable
<racarr> yes
<racarr> xkb_mapper should be used
<racarr> on the server side
<racarr> to put xkb keysyms in the keycode
<racarr> before the event filter
<dandrader> racarr, and why we wanna use xkbcommon instead of whatever comes with android-input
<dandrader> racarr, it's more powerful or better suited for desktop use cases?
 * dandrader just skimmed through the subject
<racarr> kdub: I am getting lots of could not unblank display on startup
<racarr> and it seems like maybe some other people are too
<racarr> any idea?
<kdub> logcat & dmesg?
<racarr> kdub: what is logcat?
<kdub> android-chroot; logcat
<racarr> ah
<racarr> D/hwcomposer( 2561): hwc_blank: Doing Dpy=0, blank=0
<racarr> E/hwcomposer( 2561): hwc_blank: failed. Dpy=0, blank=0 : Operation not permitted
<racarr> I/ServiceManager(  695): service 'display.qservice' died
<racarr> I/ServiceManager(  702): Waiting for service SurfaceFlinger...
<racarr> I/ServiceManager(  702): Waiting for service SurfaceFlinger...
<racarr> I/ServiceManager(  702): Waiting for service SurfaceFlinger...
<racarr> I/ServiceManager(  702): Waiting for service SurfaceFlinger...
<racarr> I/ServiceManager(  702): Waiting for service SurfaceFlinger...
<racarr> I/ServiceManager(  702): Waiting for service SurfaceFlinger...
<racarr> I/ServiceManager(  702): Waiting for service SurfaceFlinger...
<racarr> aren't you suspiscious
<kdub> yep, something has wrong permissions
<kdub> perhaps...
<racarr> something
<racarr> is unblanking the display
<kdub> racarr, if you run the mir demos as root vs phablet, see if that has the same problem
<racarr> mm
<racarr> I think it will, the thing is the display really is unblanked
<racarr> even when unity8 isnt running
<racarr> nor sf
<racarr> but the backlight is on...
<racarr> kdub: Err, running the mir demos as root
<racarr> also gives can not unblank display
<racarr> operation not permitted
<kdub> how did it get in that state?
<racarr> I dunno.
<racarr> seems like probably unity8 crashes on boot
<racarr> because it never comes up
<kdub> i just flashed pending, didn't see the problem
<kdub> well, this
<kdub> phablet-flash ubuntu-system --channel devel-proposed --no-backup
<racarr> mm, that's what I did but then I rebuilt the world
<racarr> I am sure something went wrong
<racarr> too many variables right now...ill dig
<kdub> i'm trying to rebuild the world too
<racarr> kdub: Best of luck on your voyage :p
<racarr> I think I may have just not installed platform api to the right path
<racarr> but I think maybe if mir crashes leaving the screen unblanked
<racarr> then it can fail to unblank the screen on startup and wont come back?
<racarr> yay ok it works
<racarr> swas just papi misinstall
 * kdub feels like i'm a poorly-drawn seafarers in a 15th century sea chart
<kdub> i'm now navigating through the straits of platform-api too
<racarr> yay and hold surface alive fix works
<racarr> so...the surface isn't inevitably alive
<racarr> wow I didnt use the screen so it turned off
<racarr> then I pressed the power button and it came back on
<racarr> is this really mir
<racarr> wow
<racarr> it is :D
<racarr> :p
<racarr> kdub: https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1235000
<ubot5> Ubuntu bug 1235000 in unity8 (Ubuntu) "Unity8 wont start on Mir when screen is blanked" [High,Confirmed]
<racarr> cant make sense of it yet though
<racarr> how do I run touch apps from the command line
<racarr> I thought it was something about desktop file hint
<racarr> but not working
<racarr> I need to not use upstart because I am trying to run it in GDB with electric fence
<racarr> I guess I could run it with electric fence in upstart then attach in GDB
#ubuntu-mir 2013-10-05
<racarr> Have a good weekend everyone :D
<racarr> ill be around. espescially on gtalk.
<kdub> you too racarr
<kdub> there's something funny with the development channel image
<kdub> i'm kinda suspecting container problems of some sort
<kdub> even older known-working revisions of mir look broken on this image
<kdub> hmm
<racarr> kdub: What are you seeing?
<racarr> alan_g on reddit :D http://www.reddit.com/r/programming/comments/1nsg93/growing_c_software_guided_by_tests/
#ubuntu-mir 2013-10-06
<Saviq> kdub, https://bugs.launchpad.net/ubuntu/+source/mir/+bug/1235000
<ubot5> Ubuntu bug 1235000 in unity8 (Ubuntu) "Unity8 wont start on Mir when screen is blanked" [High,Confirmed]
<Saviq> kdub, right, ignore me
<Saviq> kdub, just wanted to point out it's a known issue...
<Saviq> kdub, but writable image doesn't help at all
<Saviq> kdub, you just need to use the power button to toggle the display (and remove /tmp/mir_socket bug #1235159 if there)
<ubot5> bug 1235159 in mir (Ubuntu) "Mir fails to start if there's a stale socket" [Undecided,New] https://launchpad.net/bugs/1235159
<Saviq> kdub, and then it will start fine
#ubuntu-mir 2014-09-29
<Avagetto> hi
<Avagetto> Anybody  can help me, and answer on my stupid questuions?)
<Avagetto> for example mir was work on arm board with  mali t-760 gpu and rk3298 soc
<Avagetto> whether to work with hardware decoding and 3D acceleration?
<anpok__> i think we havent had a phone or tablet yet that used t760.. s
<anpok__> so it might just work .. or fail.
<Avagetto> i have board., android sdk . and was able to install ubuntu on it
<Avagetto> it works but does not have hardware decoding. and i want to try  use mir display server to use android drivers
<anpok__> so what happens if you instal hybris and the android graphics platform of mir?
<Avagetto> I have not had time to install mir . decided to ask the experts is it possible?
<Avagetto> or at this stage, mir can only work with a particular condition
<Avagetto> ?
<Avagetto> ok
<Avagetto> sorry for english.
<Avagetto> thx
<anpok__> i doubt that it will work with a vanilla kernel
<anpok__> Avagetto: best chances to get it woriking using the android drivers would be through: https://wiki.ubuntu.com/Touch/Porting
<anpok__> unless of course you have drm capable mali drivers that work with current linux kernels
<Avagetto> i try to use.
<Avagetto> what is drm?
<anpok__> direct rendering manager.. a linux kernel framework and (partly) generic interface for dealing with graphics resources and rendering control and outputs
<anpok__> Avagetto: mir has currently two hardware accelerated platforms for rendering - one that relies on the android hwc and (hopefully obselete) fb interfaces, and another one that uses drm.
<anpok__> all open source drivers (apart from lima) usually integrate and use drm
<anpok__> all the others.. have there own way into kernel space
<Avagetto> ok.
<Avagetto> thank you very much. I'm just a novice in this. I will try to understand this in more detail. Sorry for wasting your time.
<anpok__> you have not
<anpok__> just now wondering where to get one of these
<Avagetto> ?
<anpok__> i just saw a benchmark for rk3288 based board
<anpok__> it seems to be quite powerful
<Avagetto> yes it is wonderfull.
<Avagetto> http://t-firefly.com/
<Avagetto> i try use this board
<Avagetto> http://www.t-firefly.com/
<anpok__> Avagetto: http://lkml.iu.edu/hypermail/linux/kernel/1409.3/01550.html
<anpok__> there is a not yet merged drm driver..
<anpok__> so if they ship user space drivers too, you might have a good chance to run mir without the android parts
<anpok__> if thats not the case you would only have kms-swrast runable
<Avagetto> i found this
<Avagetto> http://malideveloper.arm.com/downloads/drivers/TX011/r4p1-00rel0/TX011-SW-99002-r4p1-00rel0.tgz
<Avagetto> this can help me?
<anpok__> driver looks good, at first sight prime support, page flipping... is available
<anpok__> but those are only the kernel parts.. are there user space drivers available too? and in which form?
<Avagetto> no . i not see user space drivers=(
<anpok__> https://github.com/linux-sunxi/sunxi-mali.git those seem to be older ones.. and that would only allow mir to run as a server
<Avagetto> on android  we have ko
<anpok__> to get mir clients run on top of that you need a to either hook into the egl implementation in some way or have an open source egl implementation
<Avagetto> in android i have only bin (user space driver), if i not wrong he work as module of kernel
<Avagetto> on linux - nothing
<anpok__> then better go with ubuntu-touch porting for now
<Avagetto> ok. are you ubuntu devoloper?
<anpok__> yes working on mir - but usually dealing withe mesa/drm
<anpok__> -e
<Avagetto> I guess that's fine, interence to work for this company=)
<lex_> hello there
<lex_> anyone from the devs here?
<anpok> yes
<anpok> there are some around
<lex_> alright then
<lex_> question to mir, license and ubuntu development in general
<lex_> i am a former user of ubuntu
<lex_> i was quite happy for some time
<lex_> then later moved to different os and now thinking about coming back
<lex_> BUT there are some things which hinder me:
<lex_> 1. Why does canonical lately not contribute so much in community projects? > mir > upstart
<lex_> 2. why does mir have such strange license. the critics i read where about restrict contributed code, making a business out of it etc.
<lex_> 3. why are ubuntu versions sometimes developed behind close doors? im not saying that the code is not free after all, but the development takes place behind doors sometimes.
<lex_> these are things which are somehow bothering me and i would be happy to get some info and i am more than happy to be proven wrong with my opinions/feelings
<anpok> lex_: 1) thats a very general complaint. on what do you base that on? canonical employee are contributing to a lot of projects.. submitting patches and play by the rules of the project involved..
<anpok> or is that rather a complain that software developers develop software?
<anpok> % typos..
<anpok> 2. i guess you dont mean gpl and lgpl?
<anpok> back then when I worked for a closed source company we also disliked gpl software..
<anpok> 3. in case of mir... most discussions happen inside MPs on launchpad.. some of those discussion leak into IRC here..
<lex_> 1. well i was just reading some news sites and wikipedia etc. and was just wondering what the actually facts are
<lex_> 2. yes, thats what i mean. what are you trying to say when talking about disliking gpl in closed source company?
<lex_> canoncial is not supposed to be one, is it?
<anpok> 2. no it is not.. and will not .. the source is out there. I just wanted to state that I can understand that complaint that gpl is stopping you if you are working on closed source software and you want to integrate gpl
<anpok> s/gpl/that project
<lex_> hmmm
<lex_> aight
<lex_> unlike upstart, mir will probably stay, right? together with unity 8
<lex_> are there any plans of dropping it?
<anpok> why should there be any?
<lex_> dont know
<lex_> just askilng
<lex_> i dont want to get back to a distro which will change a lot in the next 6 to 12 years, you know
<lex_> i want something stable, but 14.04 will do it i guess
<lex_> anyway ima try it
<anpok> why do you dislike changes?
<lex_> thx for the info
<lex_> I do not
<lex_> I like unity in general
<lex_> I like ubuntu overall design
<lex_> I like many features
<lex_> I like a lot about it
<lex_> but I think its just strange that even distros like Xubuntu / Kubuntu / Lubuntu sort of turn their backs on Ubuntu
<lex_> maybe its the childish community
<lex_> or the direction Ubuntu is heading to
<lex_> i dont know
<lex_> however i am going to give them a try
<lex_> havent in quite some time
#ubuntu-mir 2014-09-30
<duflu> Oh. Mesa 10.3 released to utopic an hour ago
<kdub_> friendly lurkers :)
<kdub_> anyone interested in writing a shell?
<kdub_> I'm mulling writing some sort of tutorial/walkthrough for mir based shells
<anpok_> kdub_: i recently tried to talk morphis into doing that
<anpok_> (writing a mir based shell for the yet new webos offspring)
<alan_g> How did that go? Any issues we should look at addressing?
<alan_g> The biggest one I'm aware of is the lack of API stability. (Which we're in the process of addressing.)
<anpok_> alan_g: nothing we can solve i guess
<anpok_> alan_g: problems include lack of time, and not being able to just reuse ubuntu-touch as is entirely..
<alan_g> Lack of time is always code for "something else is more important to me"
<anpok_> what could be more important than shells?
<alan_g> Ask my wife! ;^)
#ubuntu-mir 2014-10-01
<alan_g> alf__: anpok I trust there's no objection to TAing https://code.launchpad.net/~alan-griffiths/mir/use-compare_exchange_weak-correctly/+merge/236557?
<alf__> alan_g: let me take a quick look
<alan_g> alf__: sure, np
<alf__> alan_g: ok, TAed
<alan_g> alf__: thanks
<anpok> alan_g: no objections oh that was too late
<alan_g> anpok: 8)
<kdub_> it was a long while ago that this written, but I'm wondering why the mir.protobuf.Buffer.fds_on_side_channel (and similar) is not in the wire protocol
<kdub_> seems like the wire protocol should be the raw bytes and fds, and then it gets further parsed into the mir_protobuf.proto concepts
<alan_g> kdub_: It is probably that the fd passing depends on the message type - and that's just raw data in the wire protocol.
<alan_g> And then the fd passing got added to one message after another.
<alan_g> What you suggesting could well make sense. (Any problems will only become apparent from trying to do it.)
<kdub_> we can determine that an invocation needs to get fds from the side channel based on the message type, i'm grappling with how we can tell how many fds we need to collect before dispatching the method
<kdub_> I have a smallish MP i'll propose and see what people think about it I suppose
<kdub_> (its been a while since I considered the wire protocol), but its also strange that our events get jammed in the rpc response message type too
<alan_g> that comes from thoughts about batching messages that were never fully realized
<kdub_> ah, okay. that satisfies my curiosity about it
<alan_g> It will all go away when RAOF re-implements it using Wayland
<kdub_> :) sounds good to me
<robotfuel> kgunn: ping, I noticed this https://bugs.launchpad.net/ubuntu/+source/unity-system-compositor/+bug/1376324 crash on errors.u.c (has not happened during long running tests) can you triage it for me?
<ubot5> Ubuntu bug 1376324 in unity-system-compositor (Ubuntu) "/usr/sbin/unity-system-compositor:*** Error in `unity-system-compositor': free(): invalid pointer: ADDR ***" [Undecided,New]
<kgunn> camako: can you pick a voluteer for that one ^
<kgunn> looks like it'd be childs play
<camako> kgunn, ack
#ubuntu-mir 2014-10-02
<mzanetti> hey. any ETA on the Mir 0.8.0 release?
<mzanetti> asking because I'd need to release rtm silo 23 but there seems to be a conflict we need to coordinate on
<duflu> mzanetti: I'm not so sure it should exist at all, at least not in utopic/rtm :) I've documented my concerns and camako can decide
<mzanetti> ack
<duflu> We don't really gain anything other than risk, compared to the stable 0.7 series
<duflu> (which has been working for a while now)
<mzanetti> so I'm going ahead with silo 23, given that's already tested and just waiting to be QA signed off
<duflu> Wow. That should never have built...
<duflu> (unrelated to previous conversation)
<camako> mzanetti, 0.8 is not ready.. So go ahead.. We'll rebuild and retest anyways..
<mzanetti> camako: ack, thanks
<alan_g> mzanetti: camako is working on it
<alan_g> Hmm that was a bit late
<mzanetti> :)
<kdub_> recvmsg is a terrible function
#ubuntu-mir 2014-10-03
<duflu> Europe comes online and Launchpad times out lots :)
<duflu> alf: We don't use the snapshot logic for screencasting, right?
<duflu> And "screenshots" use screencasting
<alf__> duflu: right and right
<duflu> screensnapcastshot
<duflu> thing
<duflu> (tm)
<tsdgeos> does anyone know at what point the SessionAuthorizer is created for qt apps?
<alan_g> tsdgeos: during Mir startup - when the_session_authorizer() is called setting up the connector.
<tsdgeos> alan_g: yeah i found
<tsdgeos> alan_g: so i have a small problem not sure if you're able to help
<tsdgeos> alan_g: basically the sessionauthorizer is calling things "too early" and my other singleton that is supposed to work together with it is still not ready
<tsdgeos> i guess that's more qtmir than mir
<alan_g> tsdgeos: yeah, Mir doesn't like singletons
<tsdgeos> alan_g: well it's not really even a singleton (Well it is, but it's basically loaded by another plugin :D)
 * tsdgeos checks when Gerry is back from holydays
<alan_g> tsdgeos: so your SessionAuthorizer does stuff when created?
<tsdgeos> alan_g: no, thing goes like this
<tsdgeos> SessionAuthorized is created
<tsdgeos> someone calls connection_is_allowed
<tsdgeos> but the other thing we use to "naswer" connection_is_allowed is still not created
<tsdgeos> so things go wrong
<tsdgeos> unfortunately "the other thing" is in a different plugin
<tsdgeos> so synchronizing them seems to be pretty hard
<tsdgeos> more for me that have no clue at all about that code :D
<tsdgeos> dandrader: maybe you know a bit about SessionAuthorizer/ApplicationManager ?
<dandrader> tsdgeos, a bit, don't expect much
<alan_g> Is there a way to block connection_is_allowed until the needed helper is loaded?
<tsdgeos> alan_g: i guess that'd be it, but being in different plugins is not that optimal i'd say
<tsdgeos> dandrader: do you know if/how unity8 finds out about apps that were running before it started?
<alan_g> Well, I'm not sure why Mir would be started before unity is ready to handle connections
<tsdgeos> because everything is a plugin :/
<alan_g> But it doesn't need to be *started* when the plugin loads
<dandrader_> tsdgeos, I recall that it didn't know about them
<dandrader_> tsdgeos, but that might have changed recently
<tsdgeos> ok
<dandrader_> tsdgeos, as you already mentioned, Gerry is the one that has been working on that part
<alan_g> camako: this bug is about the time taken by this test to run. Not about it failing (which I don't deny). https://bugs.launchpad.net/mir/+bug/1375211/comments/4
<ubot5> Ubuntu bug 1375211 in Mir "[regression] unit_tests AndroidInputReceiverSetup.* takes excessive time" [Low,In progress]
<camako> alan_g, Before r1955, it was taking excessive time but passing jenkins... with r1955 (tried to address the issue of time taken) but the test itself failed on jenkins every time.
<alan_g> camako: about the test - https://code.launchpad.net/~vanvugt/mir/fix-1375211-v2/+merge/236989/comments/580795
<camako> alan_g, so you're okay with the fix in there but not the test?
<alan_g> camako: yeah. The test is well motivated, but flaky
<camako> alan_g, if it passes jenkins, then no harm done by the test (or is that not the case?)... if it doesn't, then duflu will then agree to remove it.
<alan_g> camako: the test, in effect, set a timer to 0ms and then tests that it expires in under 1ms at least one time in a hundred. Which is likely, but *not* guaranteed by anything we can control. (we're not a RTOS)
<alan_g> think valgrind on slow, loaded build servers...
<camako> I agree it's not a guarantee... but it's a problem if it fails with high probability. It's difficult to say it will. My thought is if it passes jenkins then it's good enough.
<alan_g> That attitude is how we get annoying intermittent test failures. If a thousand tests each passes 99.9% of the time we have trouble landing.
<camako> If that were true, yes... I'm just saying it'll be more convincing if you can get it to fail locally, for instance, by simulating a loaded server.
<alan_g> I'll remind you of that when it goes wrong during an urgent release.
<camako> :-)
<camako> I understand what you're saying anfd they are valid points. But without evidence (and assuming it passes jenkins - which *is* a loaded server), it's difficult to support one-side of the argument over the other. Feel free to put these comments on the review and even disapprove.
<robotfuel> kgunn: are you the person to get unity-scopes-api bugs triaged? I have this new top crasher today https://errors.ubuntu.com/problem/72efb07867c31436ac312b1a5027bfa6ee90b0bd
<robotfuel> kgunn: hmm never mind it looks like it might be apparmor
<kgunn> robotfuel: for future, that'd be thostr
<robotfuel> kgunn: I ran in to this on both mako and krillin today https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1360593
<ubot5> Ubuntu bug 1360593 in unity8 (Ubuntu) "unity8 freezes randomly" [Critical,Confirmed]
<robotfuel> I unmarked the duplicate of the location services bug
<robotfuel> :(
<robotfuel> let me know if you'd rather have a new bug open
<robotfuel> kgunn: ^
<robotfuel> ah I see in the last comment you want a fresh bug.. so I'll do that
<kgunn> robotfuel: also can you please attach a profile of the memory being used ?
<kgunn> e.g. list of all processes and threads
<kgunn> i'd be curious if this might be the damn OOM killer killing services
<kgunn> it shouldn't
<robotfuel> kgunn: sure, it's very low on memory
<robotfuel> kgunn: this the new bug https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1377332 I grabbed extra logs so let me know if I can help with more
<ubot5> Ubuntu bug 1377332 in unity8 (Ubuntu) "UI randomly freezes" [Undecided,New]
<robotfuel> I have dinner plans have to run
#ubuntu-mir 2015-09-28
<RAOF> *Man* I'd love a signal/slot interface here...
<RAOF> Woo!
<RAOF> Acceptance test that not only runs, but it also both fails to crash *and* passes!
 * alan_g wonders how to get the screen "on" after stopping lightdm. "sudo powerd-cli display on bright&" gives a dbus error.
<alan_g> alf_: has something changed in the power management? I'm trying to run mir tests on the phone but can't get anything on the screen unless I've also got U8 running (and fighting over the display).
<alf_> alan_g: I've had this problem too, not sure what changed. I think the behavior depends on the device
<alan_g> greyback: do you know what's changed? ^^
<greyback> alan_g: that's been the case for many months now, afaik
<greyback> stopping usc turns off hte backlight
<alf_> alan_g: powerd-cli wants to communicate with Unity.Screen dbus interface which is implemented by USC
<greyback> alan_g: I'm told there's a backlight util in mir-utils
<greyback> I tend to hunt for a "brightness" file in /sys/devices and write 255 to it :)
<alf_> greyback: alan_g: right, mirbackligh is a shell script that does more or less what you described
 * alan_g goes to update his notes
<alf_> anpok: @extended-mock-of-libinput, Could you elaborate on "InputDeviceInfo of the device is no longer initialized on demand, this lead to adding umockdev those tests."
<anpok> alf_: getting that device info means accessing evdev
<alf_> anpok: isn't access to evdev mocked though?
<anpok> hm
<anpok> not yet..
<anpok> I could actually use libevdev
<anpok> in some sense that code which still accesses evdev should probably move to libinput some day
<alf_> anpok: ok, so looking at the code, we seem to monitor all devices, shouldn't we filter somewhere only for input related devices?
<anpok> you are right
<alf_> vogons: I top approved lp:~cemil-azizoglu/mir/merge-post-mir-16-changelog and it got merged without running an autolanding job. Has anyone seen this?
<anpok> that was the first landing since .. some time friday
<alan_g> alf_: yes, not sure what the logic is but I've seen it before
<anpok> alf_: oh it seems I had no test for it.. but there is filtering happening
<anpok> and the new test passes..
<alf_> anpok: filtering in the sense that we get events only for interesting devices, or in the sense that we get events for all but then only succeed in creating mir objects for real input devices?
<alf_> anpok: ah, never mind, I see it now "this->monitor->filter_by_subsystem("input");"
<anpok> yes .. I was to tired to see it when skimming through the file
<anpok> brb
<greyback_> alan_g: hey, would you please merge trunk into https://code.launchpad.net/~alan-griffiths/qtmir/small-refactoring-of-MirWindowManager/+merge/266698
<greyback_> I'd like to see why CI wasn't happy the last time
<alan_g> greyback_: on my list
<greyback_> thanks
 * pixel_ ping facebook o_O
 * pixel_ he dead?
<robert_ancell> kgunn, are there any existing Jenkins jobs that rebuild dependencies for checking?
<robert_ancell> I know Jenkins can do practically anything, wondering if this is new ground or not
<kgunn> robert_ancell: i think we rely on the autopackage testing to actually do the building/running of rdep tests
<kgunn> robert_ancell: but i suppose, if you wanted to create jenkins jobs for xorg and mesa, you could...and as part of any update (via MP) you could do that same
<robert_ancell> kgunn, being a traditional package, we don't do MPs for xorg / mesa. If we can now use Launchpad for git and link up to the MPs there we could link into this infrastructure.
<kgunn> robert_ancell: i hear about lp for git working, but not real sure how that all works... i don't mind that approach
<kgunn> but is there something limiting wrt trying to use autopackage testing ?
<robert_ancell> kgunn, I don't know how that works - is that just adding something into debian/ ?
<robert_ancell> And the tests are run on upload?
<kgunn> robert_ancell: that's my understanding
<kgunn> right
<robert_ancell> kgunn, do you know an existing packge to look at?
<robert_ancell> So, we can add something that essentially says "rebuild Mir for this upload and check it still builds"?
<kgunn> robert_ancell: afaik, this is the wiki for that
<kgunn> http://packaging.ubuntu.com/html/auto-pkg-test.html
<robert_ancell> kgunn, ta
<kgunn> robert_ancell: ....kind wonder if there's a newer wiki than that
<robert_ancell> kgunn, that's suggesting to me that the tests can only run things, not rebuild anything (which is what I expected).
<robert_ancell> The particular case you were concerned about was Mir failed to rebuild (i.e. creating a FTBFS) or it failed on runtime?
<kgunn> robert_ancell: both actually...
<robert_ancell> ok, so we can solve the latter with this. The former will probably require manual testing to catch (as is the case for all packages AFAIK)
<kgunn> robert_ancell: but yes, aiui, there is a way to force the rebuild of rdeps to check for ftbfs
<kgunn> automatically
<robert_ancell> ok, we need to find that
<kgunn> and i think it is in the debian/ files
<kgunn> robert_ancell: this is how stuff gets stuck in proposed migration in excuses sometimes
<robert_ancell> kgunn, do you know of a particular package that has got stuck like this?
<kgunn> robert_ancell: yeah, i'm trying to rack my brain
<kgunn> gimme a bit of digging and i'll try to find an example
<robert_ancell> Mir doesn't trigger a rebuild of u-s-c does it? (it probably should)
<robert_ancell> Seems Mir doesn't have any autopkg tests
<kgunn> robert_ancell: you are right...
<kgunn> well
<kgunn> robert_ancell: i think we are basically always rebuilding u-s-c/qtmir anyhoo b/c we break abi like we change our socks
<robert_ancell> :)
<kgunn> robert_ancell: right, actually...now that my fog has cleared a little...it's the other way round
<kgunn> so u-s-c should have a dep on mir that would trigger a rebuild for any new upload of mir
<kgunn> ...so
<kgunn> likewise, i think we have to add the dep statement to mir for xorg
<kgunn> that would then trigger a rebuild any time a new xorg is uploaded
<robert_ancell> you mean trigger a rebuild of xorg each time Mir is uploaded?
<kgunn> robert_ancell: nope the other way around...which is why i forgot for a moment, it's kind of backward feeling
<robert_ancell> kgunn, I think we need a trigger on mesa to rebuild Mir on an upload, but xorg is the other way around
<kgunn> robert_ancell: actually...can be both ways...we have mir on x and xmir now
<robert_ancell> oh right
<robert_ancell> that makes it more complicated...
<kgunn> robert_ancell: but i think mir has tests for x on mir probably
<kgunn> so you're right xmir would be the thing we'd want to add
<kgunn> robert_ancell: so are you going to add a mir dep to xorg-xmir ?
<robert_ancell> kgunn, If we can
<kgunn> robert_ancell: and do you look after mesa, or is that only timo ?
<robert_ancell> kgunn, it's basically just timo at the moment
<robert_ancell> kgunn, bug 1500634
<ubot5`> bug 1500634 in xorg-server (Ubuntu) "Rebuild Mir on upload" [Medium,Triaged] https://launchpad.net/bugs/1500634
#ubuntu-mir 2015-09-29
<kgunn> robert_ancell: did you want to land that silo 59 xmir ? or is that just for testing....
<kgunn> i guess question is, are you gonna land that using the citrain ?
<robert_ancell> kgunn, I'm waiting bregma and co to confirm it's really better before landing
<kgunn> robert_ancell: we were just discussing
<kgunn> robert_ancell: definitely better aiui
<robert_ancell> kgunn, oh, I was expecting to use the CI train - but I've never got that far with a silo before
<robert_ancell> Good
<robert_ancell> The downside is we can't land it into wily, so it has to go through the CI train to get into the overlay PPA right?
<bregma> I think the strategy need to be to branch so we can land in vivid+overlay while wily is frozen, then backport to "upstream" for X (ie. 16.04 X, not x.org X)
<bregma> otherwise we're blocked
<bregma> and there's a good chance we'll never ship a device with wily (jumping from vivid+overlay to 16.04 LTS + overlay)
<robert_ancell> bregma, the package in the silo is a branched version - we'll update the XMir patch in x-series
<bregma> anyway, robert_ancell, ChrisTownsend says silo 59 is much, much better (does not crash) but still has damaage problems, and I believe duflu has more bugfixes waiting to go in on top
<bregma> landing silo 59 would be a good thing at this point
<robert_ancell> bregma, ok, cool. So we should land that into the overlay PPA
<robert_ancell> And do another silo when it's improved
<duflu> Not more fixes in mind, but I have created three accurate-ish bug lists for Xmir
<duflu> Lots of bugs remain
<robert_ancell> Does anyone know the next step for this silo. Do I just click publish on https://requests.ci-train.ubuntu.com/#/ticket/405 or do I need to ask someone from the CI team.
<robert_ancell> ?
<bregma> robert_ancell, you need to change "No QA Needed" to "Publish without QA"
<robert_ancell> bregma, ok, done. Do I then publish myself?
<bregma> robert_ancell, I think so, robru sent an email last week about that, but it doesn;t hurt to ask on #ubuntu-ci-train for clarification
<bregma> I seem to have deleted the email
<robert_ancell> bregma, there's no-one in #ubuntu-ci-train it seems... What server?
<robert_ancell> ah, #ubuntu-ci-eng
<robert_ancell> bregma, kgunn, OK, it appears to be in the overlay PPA now
<duflu> RAOF: Going for a diff record? :)
<duflu> I see it's gone now
<RAOF> Turns out when you have a full-file conflict with every file in the repository the diff is pretty big!
<duflu> RAOF: Happened again
<duflu> Umm, the mir 0.16.0 tarball is 50MB
<duflu> wtf?
<duflu> Ooh. Cemil included the .bzr repo :)
<RAOF> Hehd.
<RAOF> We should probably work out why linking with ld.gold fails.
<RAOF> gold is much, *much* faster to link.
<RAOF> (Like roughly an order of magnitude)
<duflu> RAOF: What is gold?
<RAOF> The gold linker. It's the replacement...ish for the standard bfd linkerl.
<duflu> Oh  https://en.wikipedia.org/wiki/Gold_(linker)
<RAOF> I think we might be technically underlinking.
<RAOF> Also have multiple wildcards in the symbols.map, which gold dislikes (and *might* be UB)
<duflu> Well, avoiding the wildcards would at least make us think about ABIs more :)
<duflu> Hopefully it would be semi-automated tho
<RAOF> No, I mean we have MIR_CLIENT_9 { global: stuff... local: * } MIR_CLIENT_9.1 { global: stuff... local: *};
<duflu> Oh
<RAOF> The two wildcards overlap, so it's not defined which block matches.
 * duflu thinks he's not the only one who never bothered to learn about local:*
<RAOF> It's a poor-man's -fvisibility=hidden :)
<RAOF> Hm. We should totally use that for mirclient.
<anpok> i guess only the last one should have local:*?
<anpok> or only the first?
<anpok> alan_g, alf_: https://code.launchpad.net/~andreas-pokorny/mir/libinput-platform-pointer-settings/+merge/272501/comments/687606 thoughts?
<alan_g> anpok: on my list
<anpok> the actual answer spans over to comments.. one that was started by a sleepy-me..
<anpok> *two
<tsdgeos> guys, did i do this right?
<tsdgeos> https://code.launchpad.net/~aacid/mir/fix_forward_declarations/+merge/272751
<tsdgeos> proper target branch and stuff?
<alf_> Saviq: Do MPs for unity8 need an explicit changelog change or is the change automatically picked up from the commit messages?
<Saviq> alf_, no changelog, just the commit message on the merge proposal
<alf_> Saviq: thanks
<tjaalton> hi, should unity8 desktop session work in current wily, or did my mesa11 break it?-)
<alan_g> greyback_: CI now happy with https://code.launchpad.net/~alan-griffiths/qtmir/small-refactoring-of-MirWindowManager/+merge/266698
<alan_g> tjaalton: I'm not sure what the state of u8 desktop is, but AFAIK the mesa 11 drop just broke Mir compilation, not runtime.
<guest42315> tjaalton, https://bugs.launchpad.net/ubuntu/+source/mir/+bug/1499425
<ubot5`> Ubuntu bug 1499425 in xorg-server (Ubuntu) "xmir black window (mesa 11.0.0)" [High,New]
<anpok> tjaalton: hm a lot has changed inXmir .. I believe the wily version requires the -damage to workaround lots of redarw issues
<anpok> *parameter
<anpok> oh ok duflu already answered that..
<anpok> s/tjaalton/guest42315
<guest42315> que dice? oh yeah :D -damage doesn't work
 * guest42315 ubuntuonair in 20 min http://ubuntuonair.com/
<tjaalton> ah just compilation, no biggie then :)
<tjaalton> so if the blank screen on login is due to the xmir bug then I guess it's known
<tjaalton> and I did notice that one already, but thought it would be more native than using xmir
<anpok> tjaalton: there is a high probability that those are not related
<tjaalton> ok
<tjaalton> could be I'm hitting a skylake display bug
#ubuntu-mir 2015-09-30
<robert_ancell_> duflu, did you see the resizing issues that Chris and bregma have been getting?
<duflu> robert_ancell_: I know there are still resizing bugs and it's a bit hackish. But I'm not aware of the conversation in question
<duflu> robert_ancell_: Oh I see. Yes I know what that is
<robert_ancell_> duflu, bug 1501039
<ubot5`> bug 1501039 in xorg-server (Ubuntu) "Xmir from overlay PPA no longer tells client about resize events in non-rootless" [Undecided,New] https://launchpad.net/bugs/1501039
<duflu> robert_ancell_: Yeah I half expected that. Although non-rootless is almost dead I know what it is
<robert_ancell_> Non-rootless should not be dead...
<duflu> Woo, Mir 0.16 in vivid+overlay too
<duflu> anpok_: Do we ever bypass android InputReceiver?
<anpok_> duflu: not soon
<anpok_> hm i think replacing it isnt complex at all... apart from the ugly resampling bits
<anpok_> i try to remove the input reading bits today
<anpok_> I still havent looked how good or bad the actual encoding is.. but the times that we measure dont look problematic..
<duflu> anpok_: I'd love to be rid of the resampling bits but even today finding they're very beneficial
<anpok_> well i meant replacing them with something easier to consume
<tsdgeos> alan_g: so it's nullptr what mir expects there?
<tsdgeos> makes much more sense :D
<alan_g> tsdgeos: '0' like 0 and nullptr is a null pointer constant
<alan_g> But the code was confusing
<tsdgeos> agreed, i wasn't thinking and just did a "let's fix the code to compile"
<alan_g> duflu: did you get a chance to try lp:~alan-griffiths/mir/fix-1308133 with your xmir WIP?
<duflu> alan_g: No, sorry. Thought about it then forgot
<duflu> And was busy anyway
<alan_g> np
#ubuntu-mir 2015-10-01
<robert_ancell> duflu, are you getting cursors when running Xmir through mir_demo_server?
<robert_ancell> They seem to disappear when a client appears
<duflu> robert_ancell: Yes, not always visible. Much invisible much less often than before :)
<robert_ancell> duflu, any ideas of the cause?
<duflu> robert_ancell: There's an upstream Mir bug Alan is fixing right now. I need to test how much that helps. As Mir itself is failing to put the cursor on screen
<duflu> robert_ancell: Bug 1308133 but also bug 1498737
<ubot5`> bug 1308133 in Mir "Mir cursor is missing/invisible until the client sets it multiple times" [High,In progress] https://launchpad.net/bugs/1308133
<ubot5`> bug 1498737 in xorg-server (Ubuntu) "Xmir apps sometimes show the wrong mouse cursor" [Medium,New] https://launchpad.net/bugs/1498737
<RAOF> Well, there you go. ld.gold is only twice as fast as ld.bfd at linking Mir (25s vs 50s).
<duflu> RAOF: Unstripped binaries less huge?
<RAOF> Nope. I'm not really sure why you'd expect them to be?
<duflu> RAOF: Just hopeful some of our problems are not our fault... https://bugs.launchpad.net/mir/+bug/1473330
<ubot5`> Ubuntu bug 1473330 in Mir "mir_*_tests binaries are suspiciously large. Up to 248MB before stripping." [Undecided,New]
<anpok_> gold just adds the ability to use lto you then still need to use -flto -fuse-ld=gold .. and replace ar with gcc-ar and ranlib with gcc-ranlib
<anpok_> and then .. fix all the problems on the way..
<duflu> Life is confusing when your tooltips are draggable
<duflu> And resizable. Awseome
<duflu> Awsome
<anpok_> RAOF: were additional changes needed to get gold running?
<RAOF> anpok_: We need to stop putting some extern "C" symbols in an extern "C++" symbols.map, but apart from that... :)
 * RAOF will propose a branch.
<anpok_> here it complained about missing android log stuff in those to be removed parts..
<RAOF> Correct.
<anpok_> ok cool so thats part of it
<RAOF> It's complaining because it can't find those symbols (which are extern "C") because we've marked them as extern "C++" in the symbols.map.
<RAOF> It then goes on to warn that we're sloppy with wildcards in the symbols.map files, but that's only a warning.
<anpok_> :a
<RAOF> Bah!
<RAOF> CachedPtr is a way of turning compile-time errors into runtime segfaults :(
<RAOF> Ok vogons: I've got a cyclic dependency in DefaultServerConfiguration:
<RAOF> the_session_coordinator requires the_mediating_display_changer which requires the_compositor which requires the_shell which requires the_session_coordinator.
<RAOF> How have our salubrious vogons broken such cycles in the past?
<anpok_> plan a) figure out why they need each other.. sometime it turns out, that all you need is a third thing to untangle something..
<anpok_> plan b) set the cycle causing thing after construction
<RAOF> New plan: just expose the_display() further.
<guest56723> No provider of eglCreateSyncKHR found.  Requires one of:
<guest56723>     EGL extension "EGL_KHR_reusable_sync"
<guest56723> i get this with Xmir -egl (am i missing extenstions?)
<RAOF> Would seem to be the case, yes.
<RAOF> What are you running that on, and do you actually have EGL_KHR_reusable_sync there?
<RAOF> (This shouldn't be something that Mir has botched up)
<guest56723> 04:00.0 VGA compatible controller: NVIDIA Corporation G84 [GeForce 8600 GT] (rev a1) (prog-if 00 [VGA controller])
<RAOF> Hm. Well, I don't have that extension on my haswell intel GPU either, so I'm not sure who has tested Xmir -egl :)
<RAOF> It's possible that it only works on android EGL implementations at the moment ;)
<RAOF> EEEEEEEEEEEEEEEoooooooohdeeeeeeeeeeeee!
<guest56723> must be the case :D
<guest56723> i am trying all the args because i get a black window :))
<guest56723> -sw -damage also doesn't work
 * guest56723 such is life on nvidia :(
<guest56723> glmark2-mir goes 100% cpu after 6 sec, and glmark2 segfaults with nvidia driver :/
<anpok_> guest56723: what application are you running inside xmir/
<guest56723> anpok_, geany
<guest56723> anpok_, firefox, chrome, even some 3d games used to run well some (aka long) time ago
<tsdgeos> guys anything for me to do in https://code.launchpad.net/~aacid/mir/fix_forward_declarations/+merge/272751 ?
<tsdgeos> i hope those test failures are not because i changed some struct/class :D
<alan_g> tsdgeos: I'm still catching up, but I think you'll find that was a valgrind bug introduced win the latest version.
<alan_g> It hit several jobs
<tsdgeos> alan_g: you mean as a bug in valgrind? or a bug that you introduced that valgrind found?
<alan_g> tsdgeos: https://code.launchpad.net/~mir-team/mir/workaround-for-valgrind-opcode/+merge/272997
<tsdgeos> interesting
<tsdgeos> alan_g: so just re-top approve?
<alan_g> yep
<anpok_> vogons: is relying on umockdev in acceptance tests something to be avoided/
<alan_g> tsdgeos: I still suspect you'll need to add "-Wno-mismatched-tags" to qtmir at some point.
<tsdgeos> alan_g: why?
<alf_> anpok_: The problem is not so much relying on something that mocks udev, as it is that this adds the requirement of running the tests with umockdev-wrapper
<alan_g> anpok_: Personally, I'd rather the tests that use umockdev were in their own binary
 * alan_g thinks it clear madness that "unit" tests use umockdev
<alan_g> tsdgeos: no-one else cares about this distinction. C.f. https://code.launchpad.net/~aacid/mir/fix_forward_declarations/+merge/272751/comments/687703
<tsdgeos> alan_g: well i do :D
<alan_g> but as soon as you include headers from a 3rd party that doesn't
<alan_g> Of course, There's always "-Dclass=struct"
<tsdgeos> sure of course as we include headers from a 3rd party that doesn't want to fix it
<tsdgeos> we'll have to disable it
<anpok_> alan_g: I know I added some of that madness.. and I think I can undo most or all of that madness..
<alan_g> anpok_: you were not the only one. What's your plan for fixing it?
<anpok_> alan_g: for input related.. convert all code to libevdev and mock libevdev..
<anpok_> then change the interface of udev monitor and enumrator
<anpok_> (^libevdev - code where the device is directly accessed..)
<anpok_> i would probably make device enumeration a part of a generic monitor interface..
<anpok_> i started the second part some time ago.. then lost myself in details ..
<alan_g> LOL
<alan_g> Not really. Our input code is a maze of twisty passages all different. And you got lost.
<anpok_> yeah it was harded when I tried to also change EventHub to that interface
<anpok_> *harder..
<anpok_> but I wouldnt even try this time
<anpok_> but back to acceptance tests.. I think we should have tests that show that input device configuration affects the input events
<anpok_> .. clients would receive
<anpok_> for that I need stubbed graphics but real input on simulated evdev devices..
<alan_g> Of course we need those tests. I just don't want them in the same binary as tests that don't mock udev (because the wrapper is a PITA)
<anpok_> i see
<alan_g> Ideally there's an implementation of your "generic monitor" that gets tested with umockdev in one binary and everything else gets a test double.
<alan_g> But we don't live in an ideal project (yet).
<Saviq> hey all, can someone please help me debug a unity8 desktop session issue? the screen seems to get turned off straight away - I can see the cursor flashing for a split second and then everything goes blank
<Saviq> I can ssh into the machine and see that unity8 & co. are running fine, I ran the demo server and clients successfully, as well as u-s-c and unity8 alone (as root)
<Saviq> but if I launch the session it just goes black :/
<Saviq> I thought for a moment the timeout's kicked in, but pressing power just shut the machine down
<bregma> Saviq, anything suspicious in /var/log/lightdm/* ?
<Saviq> bregma, if I read http://paste.ubuntu.com/12631020/ correctly (lightdm.log.old), it went from starting the compositor to stopping it immediately?
<Saviq> let me clear the folder and try again, brb
<seb128> unsure if that's the driver issue robert_ancell was seeing
<seb128> could be worth asking him tonight when he's online
<duflu> greyback: Hey this should be easy for someone in the know to solve quickly now I've traced the problem down. But EOD... https://bugs.launchpad.net/qtmir/+bug/1497828
<ubot5`> Ubuntu bug 1497828 in unity8 (Ubuntu) "Apps appear to freeze in Unity8, although they are really still rendering (swap interval zero). Need to interact with the shell to unfreeze it." [High,New]
<duflu> Saviq ^
<duflu> And good night
<greyback> duflu: hmm, thanks
<bregma> Saviq, have you explicitly installed the Mesa drivers on your desktop?  That's been a problem in the past.
<Saviq> bregma, I did not, but mir demos work fine, as do unity8 and u-s-c alone
<Saviq> bregma, seb128, here's a collection of logs: https://owncloud.sawicz.net/index.php/s/0afe9e8a599ef8fef2f2a105e9db357d/download?path=%2F&files=logs.tgz
<Saviq> bregma, seb128, I'm almost certain this has something to do with disabling the screen, as when I restarted lightdm (remotely) it was still blank until I disabled and enabled it again
<seb128> seems a bit similar to robert's issue...
<Saviq> i.e. I heard the greeter sound with a black screen, connected an external screen that worked just fine, and had to disable and enable the screen again in the screens panel to bring it back
<Saviq> indeed
<seb128> I think he showed it to alan_g in London
<seb128> alan_g, do you remember what issue robert_ancell was having in london with his screen going blank after the xserver exited
<seb128> alan_g, do you know if he opened a bug?
<alan_g> seb128: I remember he had a problem on startup (which got fixed)
<alan_g> That was about two versions client mesa module behaving badly
<seb128> right
<seb128> that's different
<seb128> he couldn't start an unity8 session then
<seb128> he has his screen going blank after the xserver exited I think
<Saviq> the greeter exiting could cause that... I wonder if I do auto-login will the same happen
<alan_g> Not sure if I even saw that. Certainly I didn't investigate.
<Saviq> seb128, do you know where the user-default session type is stored?
<seb128> Saviq, type?
<Saviq> seb128, I mean ubuntu vs. unity8
<Saviq> seb128, I wanna try auto-login to bypass the greeter altogether
<Saviq> but gotta be able to change the session remotely if it doesn't work
<seb128> Saviq, /etc/lightdm or /usr/share/lightdm/lightdm.conf.d
<seb128> the second one has files from packages like unity8-desktop-session-mir
<seb128> the /etc one is for user changes
<Saviq> seb128, hmm, but where is the user selection stored? like when you log in to a different one, it remembers? AccountsService maybe?
<seb128> oh, yes
<seb128> Saviq, /var/lib/AccountsService/users/<userid>
<Saviq> seb128, thanks
<seb128> yw
<seb128> XSession=ubuntu
<seb128> in there
<Saviq> ok, let's see how that works
<Saviq> brb
<Saviq> seb128, that worked! so indeed the issue seems to be the same, transition between X (greeter) and mir causes the screen to be blanked
<seb128> k
<seb128> can you email robert asking if he filed a bug about the issue/if he has details (maybe Cc me on it)?
<Saviq> will do
<seb128> thansk
<tjaalton> kgunn: hey, so there's a new mesa point-release in ppa:canonical-x/x-staging now
<kgunn> tjaalton: thanks you
<kgunn> vogons just a heads up ^
<kgunn> point release should be less risky
<tjaalton> should I just upload to wily?
<tjaalton> and yeah, no surprise drama to be expected in wily anymore
<kgunn> tjaalton: yeah, just upload - at least we'll be aware if we see an issue on wily ci
<tjaalton> ok
<tjaalton> thx
<greyback__> anyone know if xkbcommon has a debug symbols package available?
<RAOF> I really don't see what âswitch to libevdev but implement all of its API it as a mockâ gains us over âuse libudev and provide mock udev devicesâ
<RAOF> It seems like a significant amount of work for negative gain.
#ubuntu-mir 2015-10-02
<RAOF> Grr.
<RAOF> Why does this test sometimes fail when you send and event on surface creation? Oh, because there's an entirely unnecessary EXPECT_CALL() in there which doesn't match and so is an error.
<RAOF> This is one of the things I don't like about our testing; we routinely overspecify behaivour, so entirely benign changes become testsuite failures.
<duflu> Cosmic rays
<duflu> Quantum fluctuations
<duflu> Or programmer error
<duflu> (not necessarily the present programmer)
<duflu> New wily wallpaper!
<duflu> I just wish we had slightly higher quality jpgs. Like gnome-wallpapers usually does
<duflu> robert_ancell: Cursor fix landed for Mir 0.17. It seems to work even better than the workaround (which still has moments of invisibility)
<robert_ancell> duflu, \o/ awesome
<robert_ancell> duflu, Mir 0.17 will be for x-series?
<duflu> robert_ancell: Ask camako I guess
<duflu> Although he's started the release process for 0.16.1. If it was important then it could go in there
<duflu> We have a bunch of important fixes not released yet actually: https://launchpad.net/mir/+milestone/0.17.0
<RAOF> LOOK ON MY AWK, YE MIGHTY, AND DESPAIR!
<anpok_> RAOF: yeah we should know better..
<duflu>   /awk/ { FTW }
<RAOF> Alright.
<RAOF> While I was waiting for CI, we have, as promised, a new DSO versioning guide proposal: https://code.launchpad.net/~raof/mir/new-dso-versioning-policy/+merge/273186
<anpok_> uh
<sil2100> alf_: ping
<sil2100> alf_: hey! It seems that your recent unity8+u-s-c+powerd landing caused issues on mako
<sil2100> alf_: https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1502093
<ubot5`> Ubuntu bug 1502093 in Canonical System Image "unity8 crash on mako rc-proposed/ubuntu with latest unity8/mir/powerd" [Critical,New]
<Saviq> mzanetti, â
<Saviq> sil2100, I think it might be mir landing, too
<Saviq> just checking which package actually breaks it
<sil2100> Yeah...
<Saviq> u-s-c fine
<Saviq> unity8 fine
<Saviq> did mir 0.16.1 not go through citrain?
<Saviq> ah d'oh
<Saviq> same silo
<Saviq> hum hum
<Saviq> upgraded all mir pkgs, working...
<Saviq> UITK could be the actual problem after all
<Saviq> or restart lightdm not enough to trigger bug
<Saviq> yup
<Saviq> sil2100, UITK culprit
<Saviq> not mir
<Saviq> greyback_, uitk culprit, not mir â https://requests.ci-train.ubuntu.com/#/ticket/433
<kgunn> Saviq: huh
<kgunn> jibel: ^
<Saviq> confirming in a mo
<greyback_> Saviq: +1 that the mir updates had no impact
<greyback_> yeah, just installed UITK, now crashy
<Saviq> wonder if both needed to show problem
<Saviq> reflashing again
<Saviq> actually I got flo clean still
<kgunn> oh and alf_ ^
<Saviq> trying there
<Saviq> yup, uitk enough to make it die
<greyback_> it's crashing in a render thread, which would suggest to me it's a gl error
<sil2100> Saviq: oh my
<greyback_> "[UbuntuShape] Added mipmap based anti-aliasing fallback" would be my first suspicion
<jibel> kgunn, great :/
<kgunn> jibel: lol...yeah
<kgunn> at least we got it surrounded quickly
<alan_g> greyback_: I just noticed that Mir doesn't have the X cursors available on phone and falls back to the famous arrow. I assume that the plan is for pocket desktop is supply its own images?
<greyback_> alan_g: unity8 is using cursors from the old xcursors theme unity7 uses
<greyback_> it's working in our mousePointer stuff
<alan_g> OK. I hope
<dandrader> alan_g, so qtmir calls mir::Server::the_cursor()->hide(). and it works. but once I connect an external monitor to my laptop the mir cursor becomes visible again
<dandrader> alan_g, is that a bug?
<alan_g> dandrader: brb
<alan_g> dandrader: it is hard to say. There very few tests to define the correct behaviour of cursors. And I'm wading through a lot of "obviously wrong" behaviour and adding tests. I deduce that something is calling cursor->show(), but whether it should...
<dandrader> alan_g, my point is: should qtmir call cursor->hide() whenever a new display is connected or should I report a bug?
<dandrader> alan_g, the first option looks like a work around in my opinion....
<alan_g> dandrader: I suspect there's a mechanism missing to tell the cursor controller that the cursor should be off. So file a bug.
<dandrader> alan_g, ok
#ubuntu-mir 2016-10-05
<mterry> Is there a trivial way to get Mir to spew all sorts of debugging info?  (trying to see why QMirServer fails to start)  -- do I still have to set all sorts of MIR_SERVER_XXX_REPORT=log variables?
<kdub> mterry, afaik, there's no 'turn on all the logs' option
<mterry> kdub: is there even an easy way to see the separate options?  u-s-c --help I guess?
<kdub> I think that would work, or else mir_demo_server --help
<mterry> kdub: thx will do -- I don't have concrete suggestions for fixing this, but each time I have to do this, I spend a little figuring out what the names are again and then setting a bunch of options
<mterry> It's not an easy problem, since each debugging case probably wants a separate set of variables
<mterry> But just finding out what to set is a pain
<mterry> And if I didn't know how to translate --help output into a set of variables, I'd be very lost
<alan_g> If only it were up to date: https://unity.ubuntu.com/mir/component_reports.html
#ubuntu-mir 2016-10-06
<alan_g> bschaefer: I can't find it now, but didn't you log a bug about Xmir treating windows from all apps as belonging to the same app? http://voices.canonical.com/alan.griffiths/2016/10/06/run-x11-apps-on-mir/
<bschaefer> alan_g, yeah
 * bschaefer looks for it
<bschaefer> alan_g, https://bugs.launchpad.net/miral/+bug/1625849
<ubot5> Ubuntu bug 1625849 in MirAL "[Xmir] Alt+` switch between different apps not just windows" [Undecided,Opinion]
<alan_g> That's the one. Thanks!
<bschaefer> np!
#ubuntu-mir 2016-10-07
<greyback> alan_g: sorry, I missed your reply to this bug: https://bugs.launchpad.net/miral/+bug/1623954 I've it explained better
<ubot5> Ubuntu bug 1623954 in MirAL "gtk menu surfaces have large boundaries, require input bounds" [Undecided,New]
<greyback> possibly related: https://bugs.launchpad.net/miral/+bug/1631174
<ubot5> Ubuntu bug 1631174 in MirAL "gedit File menu positioned incorrectly" [Undecided,New]
#ubuntu-mir 2016-10-08
<Mastah> Hi, I am facing some trouble with latest protobuf 3.1 and trying to compile Mir's protobuf bindings;
<Mastah> In 3.1 the following change was applied: Moved default_instances to global variables. This allows default_instance addresses to be known at compile time.
<Mastah> and when now trying to compile Mir against 3.1, I get this error:
<Mastah> ./obj-i686-linux-gnu/src/client/./src/client/mir_debug_api.cpp:32: undefined reference to `mir::protobuf::SurfaceId_default_instance_'
<Mastah> I am not acquinted with either protobuf,  and Mir's code, to be honest, so I could use some guidance how to work around this issue and a adapt to new the changed _default_instance_ behaviour
<anpok_> Mastah: ok .. sounds like you might then have to adjust the symbols.map of mirprotobuf..  so that the client debug api can access it..
<anpok_> that would be in src/protovbuf/symbols.map..
<Mastah> ok, I had already tried just removing them, but that didn't work ;)
<Mastah> in what manner do you think they ought to be changed?
<anpok_> i dont know exactly what those globals are user for... but the debug api related code lives outside of mirprotobuf so that symbol would have to be exported
<anpok_> basically you would have to add another line in the symbols.map mentioning that mir::protobuf::SurfaceId_default_instance*;
<Mastah> ok, thank you. I will try to experiment with such lines :)
<Mastah> @anpok, unfortunately that didn't work; I tried with both mir::protobuf::SurfaceId_default_instance*; as mir::protobuf::SurfaceId_default_instance_*; in the symbol.map, but the same error remains :/
<Mastah> @anpok, the build errors can be seen here: https://launchpadlibrarian.net/288864417/buildlog_ubuntu-yakkety-i386.mir_0.24.0+16.10.20160815.3-0ubuntu3+maarten2_BUILDING.txt.gz
<Mastah> @anpok, I gotta go in a moment, I made an issue for it: https://bugs.launchpad.net/mir/+bug/1631597
<ubot5> Ubuntu bug 1631597 in Mir "Protobuf 3.1 compatibility" [Undecided,New]
#ubuntu-mir 2017-10-03
<RAOF> Bah. What a faff.
<Pharaoh_Atem> RAOF: so... mir_demo_server segfaults on launch
#ubuntu-mir 2017-10-08
<hwpplayer1> Hi Team !
<hwpplayer1> Anyone interested in Ubuntu Convergence and SDK project please feel free to contact with me
