#ubuntu-mir 2013-08-19
<thomi> robert_ancell: I'll email francis and see what he thinks
<robert_ancell> RAOF, I think I saw you had some bzr magic that tells you if you have merged branches that can now be pruned - is that right?
<RAOF> robert_ancell: Correct.
<RAOF> robert_ancell: You're looking for the bzr-removable plugin.
<RAOF> cd ~/.bazaar/plugins; bzr branch lp:bzr-removable removable
<robert_ancell> RAOF, ta
<RAOF> for I in $(bzr removable trunk) ; do rm -r $I ; done
<RAOF> (Obviously in the repository)
<robert_ancell> so handy
<RAOF> You'll likely find that it misses a number of branches that are actually removable - it's quite conservative. So if you've got any untracked files or uncommitted changes, the branch will not be marked as removable.
<RAOF> âbzr unremovable trunkâ will tell you why things aren't removable.
<thomi> duflu: you around?
<duflu> thomi: Maybe
<thomi> duflu: any idea how I can narrow down the reason why, as of this morning, compiz is using 80% of my CPU, and Xorg the other 20%?
<thomi> even when I have no windows open :(
<duflu> thomi: Wow. What driver/GPU?
<thomi> well, other than a terminal
<thomi> duflu: it's an nvidia GF116M  [GeForce GT 560M]
<duflu> thomi: Yeah Nvidia's the worst for CPU usage on a good day...
<thomi> it's never been this bad
<thomi> I also have a bangin' CPU, so 80% is quite a lot :)
<duflu> thomi: It's probably some hidden(?) window generating damage
<thomi> hmmmm
<duflu> thomi: Try the compiz plugin CCSM>Utility>Show Repaint
<thomi> duflu: I don't see that plugin in ccsm - is there a separate package I need to install?
<duflu> thomi: Yes, the compiz-plugins package
<thomi> gotchya
<duflu> thomi: Also, some snapshots of the compiz threads using a script I will email you...
<thomi> duflu: hmm, interesting. I now have a very colorful desktop
<duflu> thomi: That's showing the windows generating damage/redraws
<thomi> duflu: also, it seems like when I enabled that plugin the CPU usage dropped down to 30%
<duflu> thomi: Perhaps it's the root window; nautilus misbehaving?
<duflu> Or the unityshell plugin
<thomi> wow, there we go...
<duflu> ?
<thomi> epileptic fit time :-/
<thomi> back up to 80% :-/
<duflu> thomi: sudo dstack compiz    # a few times
<duflu> https://launchpadlibrarian.net/106890342/dstack
<thomi> it seems to be repainting both monitors every frame :-/
<duflu> And then send me the output somehow. In a bug?
<duflu> I'm not going to *fix* compiz but might be able to tell you what the issue is
<duflu> thomi: Also try unloading the unityshell plugin. It has a history of doing such things
<thomi> duflu: http://paste.ubuntu.com/6001417/
<duflu> thomi: Yep, that confirms something is triggering rendering constantly. And unityshell being slow at rendering makes that 100% CPU
<duflu> thomi: But unityshell is not always the trigger. Can you try disabling it in CCSM, briefly?
<thomi> sure
<thomi> duflu: with unityshell disabled, CPU usage drops to 63%
<duflu> thomi: Still busy tho?
<duflu> thomi: OK, try killall nautilus :)
<thomi> hmmm, I don't see the repaint plugin flashing me anymore
 * thomi tries re-enabling unity
<thomi> hmm, seems to be better... so far
<duflu> thomi: Yeah I think I've seen that before. Nautilus randomly goes nuts and since it draws the desktop, that means everything gets repainted
<thomi> interestingly, this happened after a reboot as well
<thomi> it's interesting to see just how often we repaint things, sometimes for no discernable reason
<thomi> for example, as I type this on the RHS monitor, chromioum is busy repainting all sorts of things on the LHS monitor
<duflu> thomi: Yes, we browsers will repaint constantly due to animations, somehere, on some tab
<duflu> -we +web
<thomi> well, it seems to be sitting at 60%, which is at least somewhat usable - thanks for your help
<duflu> thomi: 60% is bad. Is the flashing at least limited to a window now?
<duflu> I mean, Show Repaint no longer shows the whole screen repainting, right?
<duflu> ... You have to treat the root cause, which sounds like nautilus in this case. Unfortunately using unityshell (< 8.0) and Nvidia drivers will make performance worse
 * duflu vanishes to test some ISOs briefly
<duflu> thomi: I'm curious and concerned... Still 60%? Is showrepaint showing the whole screen repainting or just some windows?
<thomi> duflu: hey, yeah, still %64
<thomi> but showrepaint no longer shows whole screens being redrawn
<thomi> so I think we're one step better than we were
<thomi> ahaaaaa
<duflu> thomi: Without a browser?
<thomi> duflu: one of my chromium tabs had a notification, which makes chromium fade the tab colour in and out endlessly. if I get rid of the notification, it drops down to 19%
<duflu> thomi: Also, I think some hacks in unityshell means compiz will get damage events from minimized windows. Which is not ideal.
<thomi> :-/
<thomi> man, I can't wait until we have mir - I'm sure then we won't see these sorts of problem.... RIGHT GUYS!??
<thomi> :P
<duflu> thomi: Yeah Mir has a simpler and more sensible damage model. It also doesn't have Unity7/Nux sitting on top of it to consume yet more CPU/GPU
<thomi> yup
<thomi> by then hopefully we'll have better graphics driver support as well
<duflu> thomi: Tho we can't "fix" browsers or make Nvidia's proprietary drivers any less CPU hungry
<thomi> :-/
<duflu> By "fix" I mean stopping them from repainting when they actually need to
<duflu> You could "fix" /all/ the web pages to make them more efficient for idle desktops
<duflu> There can't be that many web pages
<duflu> thomi: CPU usage is really an equation with many coefficients. So we don't need to "fix" browsers or drivers if we can lower enough of the coefficients using Mir/Unity8
<thomi> sure
<robert_ancell> thomi, I'm going to merge in the Ubuntu packaging into LightDM - https://code.launchpad.net/~robert-ancell/lightdm/debian-packaging/+merge/180766. Can you make the appropriate changes to CI / autolanding so it doesn't try and use the obsolete lp:~lightdm-team/lightdm/trunk-packaging?
<thomi> robert_ancell: yes, but we cannot redeploy those changes until tomorrow
<robert_ancell> thomi, that's fine
<thomi> ok, cool
<thomi> robert_ancell: while I'm in here, do you still need/want autolanding & CI for lp:~mir-team/lightdm/unity ?
<robert_ancell> thomi, nope, that branch is dead
<thomi> cool
<robert_ancell> Mir support is in trunk now, and in the archive
<robert_ancell> thomi, oh, did the raring builds get turned off for the staging PPA?
<robert_ancell> they seem to still be building
<thomi> robert_ancell: hmm, I could have sworn I'd landed that change, but it seems they're still configured
<thomi> removing them now as well
<thomi> robert_ancell: FYI: https://code.launchpad.net/~autopilot/cupstream2distro-config/lightdm-config-tweaks/+merge/180768
<robert_ancell> thomi, does the staging PPA still get lightdm built from trunk? Is that done from somewhere else?
<tvoss_> good morning
<robert_ancell> tvoss_, hello
<thomi> robert_ancell: no, it looks like lightdm trunk gets built into ppa:lightdm-team/daily
<tvoss_> robert_ancell, hey there :) happy new week
<thomi> hi tvoss_, how's it going?
<robert_ancell> thomi, ah, ok
<tvoss_> thomi, good, but my week is roughly 13 minutes old :)
<thomi> robert_ancell: and in that PPA we build for precise<->saucy and everything inbetyween
<tvoss_> thomi, how are you?
<thomi> tvoss_: so far so good :)
<thomi> enjoying a quiet monday without all you europeans asking me for things :P
<robert_ancell> thomi, cool. So I'll delete lightdm from the staging PPA and point people at the lightdm-team/daily PPA if they need to test new changes
<robert_ancell> thomi, so does the config need updating for the daily PPA to change the packaging?
<thomi> robert_ancell: yeah. If we want it built into two places we may be able to accomodate that, but TBH that sounds like a bad idea to me
<robert_ancell> thomi, shouldn't be any need
<thomi> robert_ancell: that's what I just changed
<thomi> robert_ancell: diff line 17 from that MP
<robert_ancell> ah, ok
<robert_ancell> awesome!
<thomi> although, the diff is kind of hard to read, since LP doesn't give us much context around changes :-/
<robert_ancell> yeah, that's what go me
<robert_ancell> RAOF, can haz review plz? https://code.launchpad.net/~robert-ancell/unity-system-compositor/apport-pci-info/+merge/180771
<robert_ancell> stolen shamelessly from xorg packaging
 * robert_ancell -> EOD
<RAOF> didrocks: Are we able to reproduce the ATI bug on the jenkins machine with the most recent mir?
<didrocks> RAOF: not sure, as we stopped building it
<didrocks> RAOF: do you think there is hope?
<RAOF> didrocks: Well, https://bugs.launchpad.net/mir/+bug/1212516 is maybe related and might be fixed...
<ubot5> Launchpad bug 1212516 in Mir "valgrind integration-tests: [ FAILED ] BespokeDisplayServerTestFixture.*" [Undecided,In progress]
<didrocks> RAOF: ok, I'll ask to have a try later today
<dholbach> good morning
<tvoss_> dholbach, salut
<dholbach> hi tvoss_
<Saviq> morning all
<RAOF> Ah, yes. When changing XMir ABI it's important to actually update the driversâ¦
 * duflu is still impressed every time he sees Mir smoothly and reliably use multiple monitors
<RAOF> Then prepare to be amazed by XMir smoothly and reliably using multiple monitors!
<RAOF> *: FSVO âsmoothlyâ
<RAOF> *: FSVO âreliablyâ âº
<duflu> FSVO?
<RAOF> For Some Values Of.
<duflu> Ah, my math terminology is rusty
<dholbach> sudo apt-get install bsdgames; wtf fsvo      :)
<RAOF> Woot!
<RAOF> Gone from no output to infinite loop after presenting the first frame!
<duflu> It's /a step/
<duflu> One small step for correctness, one giant leap for fan noise
<RAOF> Gah. Stupid closures in C and their stupid type-erasing void *ctx.
<tvoss_> RAOF, https://code.launchpad.net/~thomas-voss/mir/fix-fd-sharing/+merge/180801
<tvoss_> mzanetti, good morning :)
<mzanetti> good morning tvoss_
<tvoss_> mzanetti, hey :) so can you check if our friend the upstream merger is still alive?
<mzanetti> hehe, sure
<mzanetti> tvoss_: what makes you think it isn't?
<tvoss_> mzanetti, I pushed to https://code.launchpad.net/~thomas-voss/platform-api/location-service/+merge/180692
<tvoss_> mzanetti, an hour ago, and still no vote
<mzanetti> tvoss_: right. I'll check
<mzanetti> tvoss_: otherwise it seems to do stuff. not sure why this one wasn't picked up
<tvoss_> mzanetti, thx :)
<didrocks> tvoss_: "no vote" -> maybe he's undecided and wants to vote blank ;)
<tvoss_> didrocks, well, I always figured that our jenkins setup might evolve to become skynet, but I haven't expected it that early
<mzanetti> tvoss_: oh... the build queue holds like 50 jobs :/
<tvoss_> mzanetti, oops
<mzanetti> this is not looking good.
<didrocks> tvoss_: ahah ;)
<alf__> duflu: Hi! Bypass question: why do we care about transformations of non-fullscreen windows in the bypass filter?
<duflu> alf__: Because no one uses the fullscreen state yet. It's not "wired up"
<duflu> When it is, the certainly we'll use it
<alf__> duflu: no, I mean we are checking for orthogonality of all windows, why is that?
<duflu> alf__: Because a rotated window should not get bypassed. It would lose transformation
<duflu> Oh, I see
<duflu> Hang on
<duflu> That was to fix a bug, let me find it
<duflu> alf__: It's to reliably detect overlaps. If a window overlaps a fullscreen window then the fullscreen window can't be bypassed. And I do calculate the overlap for "orthogonal" windows, but for rotated windows it's too hard/unreliable. Safer to assume if anything is rotated (not orthogonal) then some fullscreen window "might" be overlapped.
<duflu> And there are test cases which will fail otherwise...
<alf__> duflu: ok, thanks
<duflu> alf__: Also, I suspect in future that rotation will not be an attribute of a surface, but rather a function of an effect or animation that's in progress. If that changes then we will test for "any effects in progress" instead
<duflu> alf__: I now see however that I shouldn't be caring about rotated windows that are underneath
<duflu> Unless we start using Z-buffers
<alf__> duflu: I think that's ok for now (for the XMir use case)
<duflu> alf__: I think it may even become preferable to be "less correct" in future to stop more edge cases from accidentally un-bypassing a fullscreen window
<duflu> Although that's less important for Mir where bypass can be switched on/off between frames. It was important in Compiz where there's a 2-frame lag
<duflu> alf__: Actually that's a fun multimonitor test for bypass: Run egl{plasma,triagnle} -n -f, and then a second smaller windowed client. See how the first fullscreen client speeds up when there's nothing overlapping it
<alf__> duflu: ack, will try it out
<Saviq> tsdgeos, so it's not looking like racarr got anywhere on Friday? :/
<tsdgeos> i think not :_/
<tvoss_> Saviq, is ogra_ back?
<tvoss_> ogra_, ping
<Saviq> tvoss_, was he away?
<tvoss_> Saviq, ah no, that was rsalveti
<Saviq> tvoss_, canonicaladmin.com says he should be back today
<tvoss_> Saviq, ah
<Saviq> greyback, tsdgeos let me know what I can halp with, will try the app auth out now
<ogra_> tvoss_, yup
<greyback> Saviq: thanks
<tvoss_> ogra_, hey, did something change in the lxc-android-container configuration in terms of memory limits?
<ogra_> tvoss_, nope, not that i'm aware of
<ogra_> hmm ... unless ...
<ogra_> ask the security team, they might have tightened apparmor rules
<ogra_> thats the only thing that comes to mind
<tvoss_> ogra_, for some weird reason, when Mir tries to access the framebuffer, we see ENOMEM in ptrace
<tvoss_> ogra_, thanks for the hint
<ogra_> tvoss_, oh, there were also apparmor kernel changes now that i think of it, but i dont think xnox has rebuilt the android package for them yet
<ogra_> might be that something is out of sync there
<xnox> ogra_: ack.
<tvoss_> ogra_, thanks
<mzanetti> tvoss_: jenkins doesn't come up again after a restart. I fear we need to live without it for the next couple of hours until some of our jenkins experts are online
<tvoss_> mzanetti, thx
<didrocks> tvoss_: maybe ask gema? her team should have some people for this kind of production issue?
<alan_g> hikiko: welcome back. Good break?
<hikiko> hi alan_g :) yes it was nice!
<alan_g> hikiko: Are you caught up yet? We landed some nested mir stuff while you were away and more is waiting for review: https://code.launchpad.net/~alan-griffiths/mir/native-platform/+merge/180618
<hikiko> let me get a look at it :)
<alan_g> hikiko: Once you've done that we should plan the next steps together.
<hikiko> alan_g, you merged the nested-display branch and you added the NestedGbmPlatform isn't it?
<Saviq> tvoss_, oh, interesting find (re ENOMEM)
<alan_g> hikiko: *Native*GbmPlatform (and NativeAndroidPlatform)
<tvoss_> Saviq, yup, that was the only thing that was hinting to an issue
<hikiko> sorry that's what I meant I am pulling :)
<tvoss_> didrocks, can you give https://code.launchpad.net/~thomas-voss/mir/fix-fd-sharing a try on the ati machine
<didrocks> sil2100: ^
<didrocks> tvoss_: weird that RAOF told me that latest trunk may fix it
<didrocks> as it's not merged yet
<sil2100> ;/
<didrocks> so we will need a ppa + rebuild
<sil2100> ;\
<RAOF> didrocks: That's another possible fix.
<didrocks> sil2100: handling that?
<didrocks> sil2100: maybe take latest mir trunk + merge that
<didrocks> and push to a ppa
<didrocks> once built, push u-s-c there
<didrocks> and we can then just test installing from the ppa?
<sil2100> Ok
<duflu> Hmm, I could return to trying to figure out test case side-effects and whether they're important...
<duflu> ... or I could finish early and work on preparing a healthy meal
<duflu> Right then
<hikiko> alan_g, when I build trunk
<hikiko> I get this:
<hikiko> make[2]: *** No rule to make target `/usr/lib/libboost_chrono.so', needed by `lib/libmirclient.so.1'.  Stop.
<hikiko> although I have libboost-chrono-dev installed
<alan_g> hikiko: your cmake cache is out of date with saucy
<alan_g> delete it and run cmake again
<hikiko> but I just did bzr branch lp:mir :s
<hikiko> ok
<hikiko> I will try
<alan_g> hikiko: that's odd then
<alan_g> hikiko: are you using any ppas?
<Saviq> greyback, oh, tricky... webbrowser creates a separate surface it seems
<Saviq> greyback, and it gets rejected
<greyback> Saviq: quite likely, as the webprocess separate. Good catch...wonder how to work-around
<Saviq> greyback, indeed
<hikiko> alan_g, mir-team/staging/ubuntu and http://ppa.launchpad.net/phablet-team/ppa/ubuntu
<Saviq> greyback, it feels like unity8 starts faster with Mir, are you seeing the same?
<greyback> Saviq: hud is disabled :)
<Saviq> lol
<greyback> must re-enable it
<hikiko> alan_g, I am dist-upgrading maybe that will solve the problem, I didn't upgrade for 10 days or more
<Saviq> greyback, desktop hint â happroved
<greyback> Saviq: thanks.
<alan_g> hikiko: you shouldn't need the ppas as everything ought to be in the distro
<hikiko> ok, I ll remove them and try again, thanks!
<hikiko> alan_g, the branch looks good but shouldn't we call the NativeGbmPlatform NativeGBMPlatform to match the GBMPlatform? could I rename it?
<alan_g> hikiko: we should, but as alf__ top-approved without that tweak we can do it in a future MP (it only affects a couple of lines in a .cpp we need to change anyway)
<alan_g> hikiko: you building OK now?
<hikiko> yes alan_g
<hikiko> after upgrading everything is fine
<Saviq> tsdgeos, hey, I might take over QDesktopServices::openUrl from you, interested?
<tsdgeos> Saviq: all yours, i'm doing some unit/auto/something-tests for greyback
<Saviq> tsdgeos, yup, know that
<Saviq> tsdgeos, any quick pointers where I should put that in (e.g. the DBus service backing it)?
<tsdgeos> Saviq: tbh not sure what's needed, so we want QDesktopServices::openUrl to do what? open the appropiate app for that url? do we have such system in place?
<Saviq> tsdgeos, a preliminary one, yes
<tsdgeos> and that's going to call ApplicationManager::startProcess or something unrelated to start the app?
<Saviq> tsdgeos, https://launchpad.net/url-dispatcher
<Saviq> tsdgeos, upstart
<tsdgeos> Saviq: ok, why not ApplicationManager::startProcess? it needs to have upstart support afaics from the comments
<tsdgeos> may as well have the upstart code only once?
<Saviq> tsdgeos, yeah, it seems url-dispatcher is a self-contained thing now
<Saviq> tsdgeos, will talk to tedg on that later
<tsdgeos> Saviq: i would understand that it should go in unity-mir, probably
<Saviq> tsdgeos, yeah, that's for sure
<tsdgeos> not sure which class exactly
<tsdgeos> i don't think ApplicationManager is a bad place
<tsdgeos> but gerry may disagree
<Saviq> tsdgeos, we agreed on that before already
<greyback_> fine with me
<tsdgeos> ah, did we?
<tsdgeos> :D
 * tsdgeos can't read lately
 * greyback_ rebooting as Mir seems to freeze his machine
<greyback_> alan_g: ping
<alan_g> greyback_: hello
<greyback_> alan_g: hey there, I need some advice from you
<greyback_> alan_g: I am trying a simple unity-mir server on my desktop. Something is not happy, as when running it, my machine's graphics completely hangs. I can ssh in, but could you give me tips on how to debug?
<mlankhorst> does ssh work?
<greyback_> mlankhorst: yes
<greyback_> I suppose catching output into a file is necessary for a start
<greyback_> alan_g: also, if using XMir, would my Mir instance with XMir collide? (I've disabled xmir)
<alan_g> greyback_: I usually try running from an ssh session so that I can see errors. (and maybe turning on some logging)
<alan_g> greyback_: yes, we don't have nested mir sessions working yet
<greyback_> alan_g: ack
<greyback_> alan_g: any way to confirm xmir not running?
<alan_g> greyback_: I'm the wrong one to ask (I have never enabled it)
<greyback_> alan_g: ok, thanks
<alan_g> greyback_: I'd guess there's be a u-s-c process running (but I don't actually know)
<Saviq> greyback|unstabl,  lp:platform-api/mir is merged into lp:platform-api already?
<greyback|unstabl> Saviq: yes
<Saviq> greyback|unstabl, good, thanks
<greyback|unstabl> Saviq: same with qtubuntu
<greyback|unstabl> alan_g: ever got this exception: "Failed to mute keyboard" when launching over ssh? Would it be that I'm sshing into my primary machine (that I'm typing this on)
<alan_g> greyback|unstabl: yeah, sounds like X owns the keyboard. You need to be in a VT (and tell your server which one with --vt)
<greyback|unstabl> alan_g: aha, --vt! Thanks
<alan_g> greyback|unstabl: ./mir_demo_server --help is wonderful
<tsdgeos> greyback|unstabl: how do i "stop" a QMirServer?
<tsdgeos> it seems that returning from the function i pass to runWithClient is not enough
<kgunn> alf__: hey...nice job on mm...
<alf__> kgunn: thanks, did you try it out?
<kgunn> alf__: not yet....was just looking at what landed while i was out....
<kgunn> alf__: and what new problems we have :)
<kgunn> tvoss|lunch: so are we able to pilot https://code.launchpad.net/~thomas-voss/mir/fix-fd-sharing/+merge/180801 on didrocks machine? (sorry if this is old news)
<tvoss|lunch> kgunn, I think sil2100 did
<kgunn> sil2100: how many successful runs? i only ask because this is a heisenbug....i know didrocks got 10 in a row once
<kgunn> with the "current failing config"
<tvoss_> didrocks, got an update on https://code.launchpad.net/~thomas-voss/mir/fix-fd-sharing/+merge/180801
<didrocks> tvoss_: as you told, sil2100 is on it
<didrocks> I didn't got any update since, he had some issue with his ppa, then I think he copied to another one but didn't get feedback
<didrocks> let's wait for him :)
<sil2100> didrocks: running the tests, but so far no failures - but no many tests have passed yet
<didrocks> if 2 tests pass, we're fine TBH
<didrocks> sil2100: you will rerun it then?
<didrocks> (hum, aren't we at next tick though?)
<didrocks> still 30 minutes until the first stack starts I guess
<sil2100> I know ;p
<sil2100> uuuu
<sil2100> didrocks: hmmm
<sil2100> didrocks: http://10.97.0.1:8080/job/autopilot-saucy-daily_release/1104/label=autopilot-ati/console
<sil2100> didrocks: looks to me like 'it' ;/
<sil2100> didrocks: since it seems that it stopped on the opengl
<sil2100> kgunn: ^
<didrocks> right
<didrocks> tvoss_: ^
<didrocks> sil2100: we'll need to free it for production in some minutes (reboot electrically directly the machines to avoid having next test failing)
<didrocks> sil2100: let's wait a little bit to see if kgunn/tvoss have a chance to get to it
<sil2100> Ok
<sil2100> tvoss_: ?
<sil2100> didrocks: I guess we might have to reset the machine?
<kgunn> sil2100: didrocks ...can we get another opportunity to build in the patch
<didrocks> sil2100: agreed
<kgunn> from RAOF http://paste.ubuntu.com/5983202/
<kgunn> understanding this might be a while
<didrocks> kgunn: IIRC, this one was already tried
<didrocks> kgunn: without any success
<kgunn> didrocks: its not a solution...
<kgunn> its debug
<didrocks> yeah, we tried it
<didrocks> and couldn't get any blocking situation
<didrocks> (after 20 runs)
<didrocks> damn heisenbergâ¦ :p
<kgunn> didrocks: oh...the debug patch changes timing...
<kgunn> ug
<didrocks> right :/
<kgunn> didrocks: sil2100 ...can you at least grab the logs off it before rebooting
<didrocks> sil2100: mind doing that? see the logs I attached to the bug and paste the same
<didrocks> sil2100: just log into the container and installs pastebinit
<didrocks> it's the easiest
<didrocks> sil2100: can help you if needed (but in meetings)
<sil2100> Doing ;)
<sil2100> Looking at the bug first
<sil2100> kgunn, tvoss_: attached the logs to the bug as a comment
<kgunn> sil2100: thank alot
<sil2100> didrocks: would it be enough if I just restart the machine through ssh?
<tvoss_> sil2100, thx
<didrocks> sil2100: yeah
<sil2100> didrocks: do I have to detach the lxc containers first or nothing needed ;p ?
<didrocks> sil2100: no no, it's fine
<didrocks> sil2100: just reboot outside the container though :p
<didrocks> or you just shut down the container then :p
<sil2100> Rebooting normally then, thanks ;) I prefer to double-ask with fragile things
<tvoss_> sil2100, does not look like anything failed judging from the logs
<sil2100> tvoss_: didn't paste in compiz logs, but it's the same as before - it's stopping on loading the opengl plugin
<tvoss_> sil2100, ah, what was the error message again?
<sil2100> tvoss_: no error message really, just this from compiz, as seen in this comment: https://bugs.launchpad.net/mir/+bug/1204939/comments/11
<ubot5> Launchpad bug 1204939 in Mir "Unity doesn't start on ATI test machine (Mir fails to respond to drm_auth_magic request)" [Critical,Triaged]
<kgunn> Saviq: confirmed with alan_g ....current mir worked on old image....so, makes me wonder if we updated android trees or move kernel
<kgunn> more so than i did
<Saviq> kgunn, right
<kgunn> Saviq: even better...alan_g says old mir fails on new image
<Saviq> ricmm, hey, wanted to ask, where should put the platform api part of QDesktopServices::openUrl()?
<ricmm> Saviq: I need more context
<Saviq> ricmm, it'll effectively be just a DBus call to AppManager
<tvoss_> sil2100, so it segfaults?
<Saviq> ricmm, that will ask it to open the url provided
<alan_g> kgunn: Saviq - alf__ tried an old mir on the new image
<sil2100> tvoss_: hm, hard to say this time, I would assume yes but it says nothing in the logs: jenkins.qa.ubuntu.com/job/autopilot-saucy-daily_release/1104/label=autopilot-ati/console
<sil2100> tvoss_: scroll down to the bottom and try finding compiz init phase
<tvoss_> sil2100, I get an error accessing https://jenkins.qa.ubuntu.com/job/autopilot-saucy-daily_release/1104/label=autopilot-ati/console
<sil2100> hm, then maybe http://10.97.0.1:8080/job/autopilot-saucy-daily_release/1104/label=autopilot-ati/console <- with VPN access
<racarr_> Morning
<alan_g> afternoon
<kgunn> racarr_: ping
<kgunn> so wrt "mir doesn't  work on n4"...the current belief is that its a um/km out of sync issue....
<kgunn> looks like at ~1:30 today there will be a 19.2 image available (where all will be resync'd)
<kgunn> racarr_: so basically....save beating your head on the n4 mir thing until then....&
<kgunn> hopefully it will just be corrected by the image creation...can you test that this afternoon ??
<racarr_> kgunn: um/km?
<racarr_> I definitely can! and that's
<kgunn> user mode/kernel mode
<racarr_> good to hear
<racarr_> oh ok
<racarr_> yes that
<racarr_> seems really feasible
<racarr_> it was getting absurd on friday when I was trying to figure it out :p
<kgunn> racarr_: yeah...sounds like it was android um as well as ubuntu um code that was outta whack
<kgunn> at least ogra seems to be strongly thinking the same
<ogra_> err, not exactly :)
<ogra_> apparmor userspace and kernel got updated ... but the kernel didnt make it into the images yet, so something *could* be out of sync
 * ogra_ never said "strongly" ... it was just the best guess i could make on the situation you guys hit 
<racarr_> ogra_: It might not be possible for it to be that...I think I tried
<racarr_> to unload apparmor
<racarr_> but im not confident I did it correctly so or the mismatch could have made that
<racarr_> incorrect
<racarr_> so I will test the image
<ogra_> with luck the fix made it into 19.1
<ogra_> it will definitely make 19.2 though
<ogra_> (which starts building at 20:00 UTC ... so should be available in a few hours)
<ogra_> racarr, to do it right you need to disable apparmor on the kernel cmdline
<ogra_> (apparmor=0 iirc)
<racarr> ogra_: Ah ok
<racarr> It sounds pretty feasible
<racarr> :)
<kgunn> ogra_: "updated kernel"....so besides apparmor...there are other updates to the kernel ?
<ogra_> kgunn, https://launchpad.net/ubuntu/saucy/+source/linux-mako/3.4.0-3.20
<ogra_> and as i said above ... i was only guessing, not sure it is actually your issue
<ogra_> kgunn, racarr: http://paste.ubuntu.com/6003505/ these are two scripts that help with manipulating the kernel cmdline on touch images
<ogra_> so just try appending the apparmor=0 and see if it helps
<robotfuel> it looks like 3d acceleration broke on nouveau starting on friday, for regular x as well.
<racarr> finally have time to do powermangement
<racarr> it seems maybe dpms_mode is a member of
<racarr> MirDisplayOutput
<racarr> ?
<tvoss> racarr, ping
<racarr> tvoss: pong
<racarr> Was lunching :)
<tvoss> racarr, cool, just wanted to say that I'm around to help out with the nexus 4 issue
<racarr> tvoss: The rumor is that it could be a kernel space userspace mismatch for apparmor
<racarr> so waiting on new images to build
<racarr> where the rumor was they would build around 1:30 today
<tvoss> ack, in ~1.5 hours from now, right?
<racarr> Yeah
<racarr> ill try ith apparmor=0 right now :)
<racarr> Hmm it doesn't work :(
<racarr> ogra_: ^ :(
<racarr> I think I ill wait for the new images though to do anything more here
<kgunn> racarr: can you elaborate on "doesn't work" ??
<racarr> kgunn: I mean with apparmor=0 nothing changes
<kgunn> racarr: meaning our theory is busted ?
<racarr> kgunn: Probably!
<racarr> but it could be something else with the kernel
<racarr> or maybe something can someho load apparmor later, and something fishy
<racarr> so I have decided to work on DPMS and wait for the new image
<racarr> to know for sure
<kgunn> racarr: for your next attempt...could you add a report of the egl error like so
<kgunn> https://pastebin.canonical.com/96033/
<kgunn> in android_framebuffer_window.cpp
<kgunn> ...or something like that
<racarr> kgunn: ok
<kgunn> racarr: thanks...
<racarr> Based on some other errors I think either the framebufer isnt' allocating
<racarr> or some ioctl inside the driver to reference it is failing
<racarr> so this might be useful
<racarr> I may need to talk to alf before I can finish this DPMS stuff
<racarr> I'm not sure we have theinfrastructure in place to apply display configuration changes without reallocating the scanout buffers
<racarr> and don't want to step on things
<racarr> That could also just be what happens in the first implementation of DPMS but that kind of
<racarr> defeats the point I think
<kgunn> racarr: kinda weird...i would
<kgunn> 've thot that
<kgunn> dps would've been more about cutting clocks to the display/gpu
<kgunn> rather than messing with mem allocations....altho...maybe the system could save power on mem rails if it frees enoug ?
<racarr> kgunn: Right, I just mean the way mir is set up
<racarr> I was encoding the DPMS mode as part of the display configuration
<racarr> which seems kind of correct
<racarr> but when you apply a display configuration it rebuilds everything
<racarr> which is correct for most other things you might ant to change.
<racarr> but the DPMS settings dont change the layout or anything
<racarr> so it just requires some reworking of the existing code
<racarr> maybe I can figure it out today :)it's almost done though so I think syncing iwth alf in the morning might be a good plan
<racarr> and back to nexus 4 soon
<kgunn> racarr: gotcha....you're just trying to avoid triggering an unnecessary tear down
<kgunn> alf__: ^ in case you read scrollback :)
<racarr> kgunn: Yeah :)
<racarr> I feel like today is the day for client focus notifications.
<racarr> Back in 20 to switch to nexus 4
<racarr> Nexus time
<kgunn> bregma: robert_ancell ....well...gooogle....that was rude
<robert_ancell> indeed!
<robert_ancell> we're back
<racarr> http://cdimages.ubuntu.com/ubuntu-touch/daily-preinstalled/pending/ hot of the press ;)
<robert_ancell> olli_, do we have a hangout for the CFT meeting?
 * kgunn waits for word from racarr 
<racarr> kgunn: Flash is alllmost done then takes a bit to install mir
<racarr> fingers crossed
<racarr> wow surface flinger took like 30 seconds to come up
<olli_> robert_ancell, will add
<olli_> robert_ancell, kgunn https://plus.google.com/hangouts/_/calendar/b2xpdmVyLnJpZXNAY2Fub25pY2FsLmNvbQ.miib2j0d57b9590jbd8dufi79c
<tvoss> racarr, any new insights?
<kgunn> tvoss: apparmor=0 didn't change the result
<racarr> Also it's still broken on the new image :(
<tvoss> racarr, okay, and you said that surfaceflinger is slow to start?
<racarr> yes that's true it was really slow to start. I haven't tested that again
<racarr> > 30 seconds to the point where I started trying to  investigate if it was broken
<racarr> then it came up
<racarr> Im building mir again now (actuallyd onloading 391mb of build dependencies to the phone woohoo)
<racarr> then probing the egl errors
<racarr> sometimes there have been errors about not being able to find an egl config
<racarr> kgunn: Wait where did that
<racarr> exception come from
<racarr> I saw it once and was never able to get it again (went away after reboot)
<kgunn> racarr: its the exception that alan documented in the bug
<kgunn> my assumption was it was repeatable
<kgunn> (or consistent)
<racarr> kgunn:  not exactly I got that once
<racarr> well
<racarr> many times ina  row
<racarr> but then when I rebooted it went back
<racarr> to th same no errors except for the ioctl failures in strace
<racarr> maybe once I build mir I will get that exception this time? :/
<racarr> I dont get it from running mir_demo_server on the fresh image
<racarr> also for me/tmp/mir_socket is created
<racarr> clients
<racarr> are stuck at half FPS
<racarr> 1 FPS
<racarr> 7 FPS
<racarr> 26 FPS
<racarr> 28 FPS
<racarr> 29 FPS
<racarr> 30 FPS
<racarr> 30 FPS
<racarr> not that anything shows up
<racarr> oh wo I left one open for a while
<racarr> terminate called after throwing an instance of 'boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<std::runtime_error> >' what():  error posting with fb device
<robert_ancell> robotfuel, oh you are here already :)
<robotfuel> :)
<robert_ancell> robotfuel, we'd like to verify https://code.launchpad.net/~vanvugt/mir/bypass/+merge/180503 against the test machines before landing it - what is the best way to do that?
<robotfuel> robert_ancell: how do I test it?
<robert_ancell> robotfuel, Would a PPA fit in with the test system?
<robert_ancell> Otherwise it's just building from source
<robert_ancell> The tests are the same as before - if you can run a session and run a GL app then it's good to go
<robotfuel> robert_ancell: yes ppa's fit as long as ps-jenkins can see them.
<robotfuel> robert_ancell: what ppa is it in?
<robert_ancell> robotfuel, I'll set one up and email you the details
<tvoss> racarr, kgunn which image is the latest that Mir is working with?
<kgunn> tvoss: unsure...i'm guessing circa 2 weeks ago (based on the bug info)
<kgunn> meaning 2 week old image
<racarr> tvoss: Seems about right
<racarr> maybe even ~1 week
<kgunn> racarr: should we bisect ?
<kgunn> images
<racarr> kgunn: seems so...:(
<racarr> ^Cphablet@ubuntu-phablet:~/src/trunk/build/bin$ sudo ./mir_demo_standalone_rendeto_fb
<racarr> __pthread_gettid -2
<racarr> terminate called after throwing an instance of 'boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<std::runtime_error> >' what():  Could not unblank display
<racarr> why does
<racarr> it keep moving
<racarr> phablet@ubuntu-phablet:~/src/trunk/build/bin$ sudo ./mir_demo_standalone_render_surfaces
<racarr> __pthread_gettid -2
<racarr> ERROR: /home/phablet/src/trunk/src/server/graphics/android/hwc_common_device.cpp(64): Throw in function mir::graphics::android::HWCCommonDevice::HWCCommonDevice(const std::shared_ptr<hwc_composer_device_1>&, const std::shared_ptr<mir::graphics::android::HWCVsyncCoordinator>&)
<racarr> Dynamic exception type: boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<std::runtime_error> >
<racarr> std::exception::what: Could not unblank display
<racarr> [boost::errinfo_errno_*] = 1, "Operation not permitted"
<racarr> even
<racarr> more fascinating
<kgunn> racarr: so basically new error code every time
<kgunn> ?
<racarr> well
<racarr> it seems like new error code with new image
<racarr> on this image so far it's consistent
<racarr> well
<racarr> ok so the mir from the archive ust silently fails
<racarr> when I build mir it always fails with
<racarr> "Could not unblank display"
<racarr> operation not permitted
<racarr> the first demo ust doesnt print the errno
<racarr> always = always on this image
<racarr> why
<racarr> is root
<racarr> not root
<racarr> :p
<racarr> of course now I reboot and its back to silently failing
<racarr> kgunn: After reboot that error is now gone forever seemingly and it's back to failing silently
<kgunn> racarr: what the what?...so consistently fails with no permission to blank display ....then fails silent ? (meaning just a hang, no exception thrown)
<kgunn> racarr: well...bisecting will likely be better use of cycles i think
<racarr> no hang
<racarr> just nothing on screen
<kgunn> racarr: got it...(sorry misuse of the word hang)
<kgunn> racarr: what happens if you try a demo client in that state ?
<racarr> nothing
<racarr> just the same half FPS stuff as before
<racarr> the files in /usr/include/android/hardware
<racarr> the headers
<racarr> are significantly different than the files in 3rd-party/android-deps
<kgunn> racarr: but at least, the client can get an egl context and render to the fb
<kgunn> ?
<racarr> kgunn: Seemingly it can
<racarr> but nothing happens
<racarr> I assume there are the same strace errors there were on the last image with the ioctl failing
<kgunn> eeeewwww....header changes huh
<racarr> maybe
<racarr> maybe libhardware itself changed
<racarr> or maybe this is normal and the files in android-deps are magical I don't really know the
<racarr> story around them
<racarr> digging
<kgunn> racarr: actually this is what i was fearing...that egl/hwc/fb glue we can't see possibly changes
<kgunn> changed
<tvoss> kgunn, we can see all of the glue
<kgunn> tvoss: you have egl & hwc implementations ?
<racarr> libhardware itself is open afaik
<tvoss> kgunn, racarr exactly
<robotfuel> robert_ancell: this is blocking nexuiz from running on nvidia and radeon https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1214030
<ubot5> Error: launchpad bug 1214030 not found
<racarr> I'm not sure im interpreting things right
<robert_ancell> robotfuel, ta
<racarr> but it seems like if these headers are out of sync, they have been for ages
<racarr> so it seems to not matter
<racarr> what do the different headers mean then
<tvoss> racarr, are we building against libhardware?
<robotfuel> robert_ancell: do I need to make that bug public or can you see it?
<robert_ancell> robotfuel, I can see it - any reason not to make it public?
<racarr> tvoss: Oi, mir is
<racarr> but it has it's own headers in 3rd-party/android-deps
<kgunn> tvoss: racarr ....sure, there is an open source impl...but what about vendor blobs ?
<robotfuel> robert_ancell: not that I am aware of, I guess apport does that by default.
<tvoss> racarr, so which headers do we pull into the build?
<racarr> tvoss: For mir we use the headers in 3rd-party/android-deps
<kgunn> most vendors replace hwcomposer.cpp
<racarr> seemingly, because I just copied the headers from /usr/include in to there
<racarr> and it doesn't build anymore ;)
<tvoss> kgunn, no worries, all good. It's only about symbols
<tvoss> racarr, okay, and then we link against what? libhardware?
<racarr> oi
<tvoss> racarr, is that yes or no?
<tvoss> :)
<robotfuel> robert_ancell: there is also this bug that is blocking us from getting results on nvidia
<robotfuel> https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/1214066
<ubot5> Launchpad bug 1214066 in xorg (Ubuntu) "phoronix benchmarks on nouveau is 4 times slower today than it was last thursday" [Undecided,New]
<robotfuel> robert_ancell: it's a regression in regular x as well
<racarr> tvoss: Yes
<racarr> tvoss: We link against system libhardware but explicitly use the
<racarr> in tree headers
<tvoss> racarr, here we go ...
<robotfuel> robert_ancell: benchmarks are timing out on nvidia because acceleration is non-existent or slow
<tvoss> racarr, do we _link_ against libhardware on the ubuntu side or are we using hybris?
<racarr> tvoss: Err,as far as I can see we are linking against the
<racarr> hybris libhardware
<tvoss> racarr, okay, even worse than
<racarr> there is no hwcomposter.h in /usr/include
<tvoss> kgunn, when is kdub back?
<racarr> there is some series of macros preventing me from immediately seeing why this compile is faling XD but it's something about version defines/compatibility macros
<racarr> this compile is when I tried to use the system headers
<racarr> I think
<racarr> if I could get a new
<racarr> hwcomposer.h
<racarr> it would work
<kgunn> tvoss: sept2
<tvoss> kgunn, really?
<kgunn> really
<rsalveti> racarr: which version of hwcomposer.h are you originally using?
<rsalveti> tvoss: indeed, that's not part of the android-platform-headers
<rsalveti> I can add it there, but I first want to check how different it is from our current hwcomposer.h from 4.2.2
<tvoss> racarr, ^
<racarr> rsalveti: see in lp:mir 3rd-party/android-deps/hardware
<racarr> Phone sorry, will be back in 5 min with more info XD
<racarr> ok
<racarr> so...um. I guess I dont know
<racarr> how to identify what version of hwcomposer.h it is
<racarr> or why we use these in tree headers
<racarr> is it legacy only? or is there another reason
<rsalveti> racarr: http://phablet.ubuntu.com/gitweb?p=CyanogenMod/android_hardware_libhardware.git;a=tree;f=include/hardware;h=139b8bb682030607ffea03beca691ef877a5e794;hb=refs/heads/phablet-saucy
<rsalveti> this is the one we're using at our android images now
<kgunn> hwcomposer_defs.h changed as well
<kgunn> racarr: ^
<racarr> yeah
<racarr> rsalveti: Ok thanks. I am going to see if I can get mir to compile
<racarr> against these headers
<rsalveti> racarr: tvoss: http://paste.ubuntu.com/6004566/
<rsalveti> comparing the headers, nothing really critical
<rsalveti> only difference is removal of HWC_BLIT
<racarr> rsalveti: Err, ok so these
<racarr> aren't the headers
<racarr> that are in /usr/include/android
<racarr> on the device
<racarr> the diff there is much larger
<rsalveti> racarr: there's no hwcomposer.h in there
<rsalveti> that's why I'm comparing with what got changed in the android side
<rsalveti> to see if the headers inside mir would need any sort of update
<rsalveti> racarr: what was the last known working image?
<racarr> err
<racarr> I had a hardware.h with a much larger difference
<racarr> and no it wont build
<racarr> rsalveti: No one knows. 2 weeks ago should be safe though
<kgunn> rsalveti: yeah...but that addition of ifdef qcom hw adds an int right in the middle of a hwc struct
<kgunn> that's used for hwframebuffer
<rsalveti> right, can't we get someone to trace that based on the ones available in http://cdimage.ubuntu.com/ubuntu-touch/ ?
<rsalveti> we got one from 12 there, would be nice to see if it works there
<kgunn> racarr: can you test http://cdimage.ubuntu.com/ubuntu-touch/daily-preinstalled/20130812/
<rsalveti> kgunn: right, but I don't think QCOM_HARDWARE is defined at all for nexus 4
<rsalveti> iirc
<tvoss> racarr, rsalveti off now, quite late here. kgunn, racarr can you guys send me a handover mail?
<kgunn> tvoss: you bet
<kgunn> rsalveti: really...? that would surprise me...isn't n4 qcom ?
<racarr> tvoss: Ok
<rsalveti> kgunn: it is, but iirc that define was cm specific for other qcom based devices
<racarr> rsalveti: http://pastebin.ubuntu.com/6004587/
<rsalveti> but would need to double check, and you can easily rebuild against the updated header to test as well
<racarr> this is the diff I get when copying /usr/include/android
<racarr> in to the android-deps
<racarr> so where are
<racarr> THESE files coming from?
<racarr> using the files from github with the small diff didnt ork
<racarr> interesting trivia: Cmake does not detect changes to the android-deps folder ;)
<rsalveti> racarr: these are from libhybris, which originally came from our phablet git repos
<rsalveti> but they were always different, that's why I'm not sure if this is indeed the cause
<racarr> yes
<racarr> thats hat the changelogs seemed to say to me too
<rsalveti> tracing the last working image would be a better idea I guess
<racarr> but I am double checking because hat else could it be
<racarr> yeah...
<racarr> kgunn: http://cdimage.ubuntu.com/ubuntu-touch/daily-preinstalled/20130812/
<racarr> still ant me to test that one?
<kgunn> racarr: i think that would help
<racarr> ok
<racarr> ok the thing is installing the PPA on this image will bring in other updates I guess so I have to
<racarr> build mir again..
<racarr> at this rate it will take like 1 hour per image
<racarr> sigh
<RAOF> Ah, vgdb. You're the best.
<kgunn> racarr: sorry dude
<kgunn> racarr: i do think you're on to something with the header deltas....
<kgunn> gonna hop off to eat dinner..
#ubuntu-mir 2013-08-20
<racarr> kgunn: image fails
<racarr> are there older images
<kgunn> racarr: thanks... rsalveti how far back can we go ? ^
<racarr> I have a copy of
<racarr> july 26th
<racarr> on my desktop it seems
<racarr> thats kind of far though XD
<kgunn> so 12th would be 1 week...and the bug describes it popping up ~2 weeks ago
<kgunn> racarr: question...is the hwcomposer.h etc matching from the 12th to current  ?
<racarr> no hwcomposer.h on the image
<racarr> lets check hardare.h though
<kgunn> racarr: yeah...that's what i meant
<kgunn> gralloc and fb as well
<racarr> yep
<racarr> the same
<racarr> ok im going to september 26th because
<racarr> err
<racarr> uly 26th
<racarr> because I dont have anything else to do :p
<racarr> kgunn: maybe check your ~/Downloads/phablet-flash
<racarr> for images?
<racarr> though
<racarr> i e dont have the images elsewhere
<kgunn> racarr: will do
<racarr> then bisecting probably ont help much
<kgunn> also...as you're building, check the ubuntu/hybris/hybris/include/android/hardware/ and see how those headers compare
<kgunn> 26th vs current
<racarr> ubuntu/hybrys/hybris/hat
<racarr>  /what?
<kgunn> racarr: i have a jul 25th :)
<racarr> I have been looking in /usr/include/android
<kgunn> oops...nvmd...i was looking in source i downloaded
<kgunn> that's where they are before image creation
<racarr> XD
<kgunn> ./ubuntu/hybris/hybris/include/android/hardware/fb.h
<kgunn> etc
<racarr> thats a hell of a path
<racarr> I realized
<racarr> e can rule in our out the headers
<racarr> in an easy ay
<racarr> well that whole theory
<racarr> did surface flinger change?
<racarr> I guess that doesnt necessarily rule it out
<kgunn> whathcya mean?
<racarr> I mean we have this theory that libhardware changed
<racarr> and it broke mir because mir has the static in tree headers
<racarr> but if surface flinger didn't change
<racarr> that seems unlikely
<kgunn> racarr: right...but isn't it truly in tree for surface flinger (e.g. he's not gonna get headers outta sync)
<kgunn> since its all just part of android
<racarr> kgunn: Right I am just saying if e literally haven't updated
<racarr> the surfaceflinger binary
<racarr> havent tested this image yet but want to go get pizza before the bakery closes
<racarr> back soon
<kgunn> racarr: actually....i think i just found a jul 29 & aug 9 images
<racarr> I am trying to build mir on this image...but
<racarr> build deps are pulling in a hybris upgrade
<racarr> so it would be not so surprising if it didn't work?
<racarr> ghsdflKSDfljLKsdgjldkfjglkdjglkejrg;lakerjgl;kejrgt
<racarr> just a little keyboard mashing :p
<racarr> brb pizza
<RAOF> Ah, yes.
<RAOF> It's important not to leak fds.
<RAOF> Huh. Something's broken in our resource cache it seems.
<racarr> back
<kgunn> racarr: dont we  rebuild surfaceflinger from source everytime ? (i thot we built the whole android file system...for what we have source for)
<kgunn> stepping out...biab
<racarr> kgunn: yeah I guess its probably never the same
<kgunn> racarr: just comparing bins of libsurfflinger they are diff between jul 25 & latest
<kgunn> but not surprising
<kgunn> ok...really stepping out
<duflu> racarr: is surface flinger relevant to the Nexus4 bug? We intentionally disable it to run Mir (usually)
<racarr> kgunn: july 26th works!
<racarr> duflu: No but one of the theories is that there is a libhardware mismatch
<racarr> but I didn't relize we rebuilt surface flinger everytime
<duflu> I see
<racarr> duflu: Want to check your ~/Downloads/phablet-flash and see if you have any images beteen
<racarr> july 26th and august 18th
<racarr> and can verify mir orks/doesn't work on them
<racarr> bisecting ;)
<racarr> but I am out of images
<racarr> err august 12th sorry
<racarr> ricmm: rsalveti: Any way we can get images from before august 12th
<duflu> racarr: Only July 26th (works for me I think) and August 8th (broken)
<racarr> August 8th broken. Awesome
<racarr> kgunn: ^
<duflu> racarr: At least that appears to be the latest one I have. And the latest broke my N4
<duflu> Though surely we can get image dates/versions from the devices?
<racarr> duflu: The problem right now is cdimages.ubuntu.com
<racarr> only has back to august 12th :p
<racarr> so I am trying to bisect
<duflu> racarr: Yeah Albert logged the bug on 13th a few days after he first mentioned it. Because it took me a few days to upgrade and confirm
<racarr> but the range is uly 26th to august 8th now
<racarr> but there are no images
<racarr> inbeteen
<racarr> ween
<racarr> Spill on keyboard:(
<duflu> Pork and beans?
<duflu> Argh
<duflu> That would be weezer
<duflu> I suck
<racarr> I guess I will start
<racarr> reading changeloads
<duflu> racarr: Actually 20130808 may not be accurate. The download date for that was 20130813 and I remember I did an update immediately after
<duflu> Will have to reflash it without updates to confirm
<racarr> Ah! thanks.
<racarr> lxc-android-config (0.67) saucy; urgency=low
<racarr>   * allow devices that use EFS as label for the factory partition to mount it
<racarr>     under /efs instead of /factory
<racarr> that means anything
<racarr>  -- Oliver Grawert <ogra@ubuntu.com>  Sun, 04 Aug 2013 12:24:23 +0200
<racarr> I wonder if
<racarr> I have nothing in /factory on the working image so probably not
<racarr> I dont know what a /factory is though
<racarr> im going to bisect
<racarr> lxc-android-config
<racarr> because permissions are suspect
<racarr> oh I can't really do that as easily as I want to
<racarr> ok I upgraded lxc-android-config
<racarr> and it still works
<racarr> im going to upgrade packages one at a time lol
<racarr> that was kind of silly :p not even sure what to try next
<racarr> no hybris updates
<duflu> N4 sez: Not enough charge to turn on yet. This seems to happen a lot
<racarr> lets upgrade lxc
<racarr> duflu: Happens to me a lot too :( and you can
<racarr> use more poer than you get off low power USB compiling
<racarr> mir
<duflu> racarr: Yeah I put it on mains for a while
 * duflu wonders if the USB 3 port would have more power than USB 2
<racarr> Maybe
<racarr> not lxc! let's upgrade apparmor
<racarr> im staring at a list of like 200 packages trying to pick ones that could be relevant lol
<duflu> racarr: Maybe consider those that Mir depends on
<racarr> duflu: Mm. should just start with that
<racarr> all the build deps
<racarr> are newest version
<racarr> as are the dependencies
<racarr> except or
<racarr> multiarch support
<racarr> *tests*
<duflu> racarr: phablet-flash has no options to specify an image file(s) any more. Any clue?
<racarr> duflu: You have to use clockwork mod
<racarr> duflu: You flash the armel+dev first then the armhf
<duflu> Great. Later then
<racarr> you have to use adb push file /sdcard/
<racarr> instead of
<racarr>  /sdcard
<racarr> or it ust silently fails ater taking
<racarr> forever
<racarr> lol
<racarr> aw not multiarch support either
<RAOF> Grr overlapping outputs.
<racarr> ok I think I narrowed it don to a set of 20 packages
<racarr> is there an easy way to reverse my last
<racarr> apt transaction
<racarr> http://pastebin.ubuntu.com/6004993/
<racarr> something in here killed it'
<racarr> http://pastebin.ubuntu.com/6004994/
<racarr> this is suspiscious
<racarr> reverting back to working image to narrow the list
<racarr> Setting up initramfs-tools-ubuntu-touch (0.34) ...
<racarr> seems sort of sketchy
<racarr> compared to everything else at least
<smspillaz> racarr: arrrround?
<racarr> smspillaz: Enthusiastically!
<kgunn> racarr: you're awsome...so down to 20 packages, somewhere between jul 26 & aug 8
<racarr> kgunn: Actually just got a working system again and clicking, so more like 19 packages lol
<racarr> really only like 4 or 5 that seem reasonable we should know super soon
<kgunn> racarr: cool
<smspillaz> duflu: so I don't know if something I'm seeing is a bug in the mir buffer swapper or a bug in my code
<kgunn> duflu: ping
<smspillaz> duflu: basically if I do draw1 -> swap1 -> draw2 -> swap2 -> draw3 -> swap3
<smspillaz> I seem to see something like
<smspillaz> after swap1 : nothing after swap2 : draw1 after swap3: draw2
<smspillaz> (using mir_surface_swap_buffers directly)
<duflu> smspillaz: Do you have a very recent server? That was probably fixed in lp:mir r955
<smspillaz> duflu: bzr pulled as of yesterday
<duflu> kgunn: Hi
<duflu> smspillaz: Yeah that's new enough
<smspillaz> hmm ok I'll try again
<smspillaz> maybe I was just an idiot and forgot to set my path right or something last night
<duflu> smspillaz: For manual testing that kind of thing I use fingerpaint (in which single clicks generate single swaps and should generate immediate output)
<duflu> Though we have automated tests for it of course
<smspillaz> ah you know what
<smspillaz> it could be that stupid thing with sudo not working with LD_LIBRARY_PATH
<duflu> kgunn: pong?
<smspillaz> well not stupid, but a gotcha nonetheless
<smspillaz> so I was probably still running the one in /usr/bin
<duflu> smspillaz: Yeah you have to set it after sudo
<smspillaz> you guys really need something like weston-launch
<duflu> smspillaz: You mean a dumb and simple shell?
<smspillaz> duflu: not really. Its a setuid thing that talks to pam to get the invoking env, handles all of the vt switching and drmSetMaster/drmDropMaster stuff and then runs weston as user
<duflu> smspillaz: Oh right. I have thought about similar
<duflu> Someone just has to do it
<smspillaz> lol
<smspillaz> it makes life a lot easier :)
<racarr> smspillaz: Ill take care of it on Yotday, the imaginary day I just invented inbetween
<racarr> now and featufre  freeze
<racarr> :p
<smspillaz> though admittedly not as useful anymore because logind no longer allows arbitrary processes other than init to spawn new sessions
<smspillaz> so it has to start on the same vt you launched it on as opposed to starting on a new one
<RAOF> As long as you don't want VT switching you should be able to run mir_demo_server_shell as your user directly.
<smspillaz> RAOF: don't you need root for input?
<smspillaz> I seem to recall that's what half of what weston-launch was about
<RAOF> sudo chown smspillaz /dev/input/**/*
<smspillaz> or maybe that was to do with vt-switching and input
<smspillaz> RAOF: :/
<RAOF> smspillaz: Hey, it's harmlessÂ¹
<RAOF> Â¹: As long as you trust everything on your box
<smspillaz> I guess my alternative solution of doing source /home/smspillaz/.bashrc was probably not better
<smspillaz> (so that I didn't have to re-type every bloody path again)
<racarr> Nooooooooooooooooooooooooooooooooo
<racarr> bisection failed
<racarr> life
<racarr> no
<racarr> just bisection
<smspillaz> duflu: :/ I'm still getting the one-frame lag
<smspillaz> (correct paths and all)
<racarr> err
<racarr> ...I retract my err
<smspillaz> though oddly its not happening on the demo clients which use mir_surface_swap_buffers_sync!?!
<RAOF> Hrm
<smspillaz> attack of the threads!
<duflu> smspillaz: Not sure then. We have automated and easily manual testing of this issue. If you can figure out the scenario exactly that would be helpful
<smspillaz> duflu: I'm just doing a dump of the image surface to a png to figure out what's going on for now
<smspillaz> reeeeecompiling
<kgunn> racarr: bisection failed as in ...you added everything back one by one to a failing image that no longer fails but actually boots with unity-mir ?
<racarr> kgunn: I think I made a istake in thinking I hd found a broken set of packges
<racarr> in that it just didnt ork once
<racarr> maybe I didnt use sudo and forgot because adb history was fucked up or something
<racarr> I dunno
<racarr> no I am still on a orking images
<racarr> and adding more and more packages
<racarr> about 20 at a time then rebooting and testing
<racarr> lol
<racarr> this last one pulls in a bunch of stuff so I have a feeling this will break it but then to bisect this smaller list I need to go all the way back
<racarr> and reflash
<racarr>   ubuntu-touch-generic-initrd ubuntu-touch-session
<racarr> these are the most suspsicious packages that I havent ruled out yet
<racarr> all the mir dependencies and build dependencies
<racarr> are ruled out
<kgunn> racarr: can you pastebin the remaining packages ?
<kgunn> just updating the bug
<robert_ancell> thomi, is jenkins screwed up again? (https://jenkins.qa.ubuntu.com/job/lightdm-saucy-amd64-ci/85/console)
<robert_ancell> and http://s-jenkins:8080/job/lightdm-ci/168/
<kgunn> just in case you don't find the offender
<thomi> it wouldn't surprise me, let me see
<racarr> kgunn: http://pastebin.ubuntu.com/6005189/
<racarr> almost through a bunch though
<thomi> robert_ancell: the public jenkins has been up and down all day today
<thomi> robert_ancell: private jenkins should be working though
<robert_ancell> thomi, also, do you happen to know who I can poke to make a PPA have a high priority?
<thomi> robert_ancell: #launchpad-ops
<olli_> robert_ancell, rcimm & rsalveti
<racarr> kgunn: http://pastebin.ubuntu.com/6005191/
<racarr> I ust ran mir succesfully
<racarr> after a reboot
<racarr> and those are the only remaining packages
<racarr> in upgrade
<racarr> going to eat some ice cream then come back to it
<robert_ancell> ricmm, rsalveti, you can bump PPA priorities? Can you set ppa:mir-team/qa-testing to the same priority as ppa:mir-team/staging?
<thomi> robert_ancell: you mean build priority in the lp build queue, right?
<racarr> going to eat icecream and revisit
<racarr> oh
<racarr> wow
<robert_ancell> thomi, yeah
<racarr> im going around in workspace switching loops
<thomi> robert_ancell: I thought so, I've always had to ask launchpad people to tweak that for me, but maybe others have more permissons than I do
<kgunn> racarr: icecream can only help
<smspillaz> kgunn: so I'm working at the australian election and our counting how-to guide give the example of replacing the candidates name with "ice cream"
<smspillaz> as an example of an informal vote
<smspillaz> I really don't know who or why somebody would want to vote for ice cream
<racarr> so close
<racarr> ps daily show had coverage of australlian elections it as hilarious
<smspillaz> racarr: I saw that!
<smspillaz> ahh good ol' cameron diaz
<racarr> does anyone have time to revie client-focus-notifications while I am still awake?
<racarr> libopenobex1 libpam-systemd libpixman-1-0 libplymouth2 libpolkit-agent-1-0 libpolkit-backend-1-0 libpolkit-gobject-1-0 libsystemd-daemon0 libsystemd-login0 libupower-glib1 libusb-1.0-0 libwaudio1 login multiarch-support packagekit-plugin-click plymouth policykit-1 powerd systemd-services telepathy-gabble telepathy-ofono tzdata
<racarr> one is evil
<RAOF> racarr: Sure. I want that branch landed :)
<racarr> RAOF: It feels like today is the day
<RAOF> https://code.launchpad.net/~robertcarr/mir/client-focus-notifications/+merge/179801 is the current one, right?
<racarr> I'm looking for the words to say...I don't think I can hide...what I'm feeling inside...
<racarr> RAOF: https://code.launchpad.net/~robertcarr/mir/client-focus-notifications/+merge/180903
<racarr> didn't you check the moon charts?
<racarr>   libpam-systemd libplymouth2 libpolkit-agent-1-0 libpolkit-backend-1-0
<racarr>   libpolkit-gobject-1-0 libsystemd-daemon0 libusb-1.0-0 libwaudio1
<racarr>   multiarch-support packagekit-plugin-click plymouth policykit-1 powerd
<racarr>   systemd-services
<racarr> hmmm
<racarr> im trying to eliminate ones which seem really unlikely to break mir
<racarr> first so when I finally break it (and have to start the whole thing over again)
<racarr> the pool is super small and I can just guess
<racarr> libpam-systemd libplymouth2 libsystemd-daemon0 plymouth policykit-1 powerd systemd-services
<racarr> any bets? :p
<racarr> systemd plymouth policykit or powerd one of them broke mir on the nexus 4
 * RAOF lays a bet on "systemd"
<racarr> seems likely
<racarr> it wasn't powerd
<racarr> seeing if plymouth is the surprise offender now
<racarr> damnit, ran demo ithout root, 30 second penalty as phone hangs.
<racarr> :p
 * RAOF should really get around to submitting a branch that fixes the build with clang 3.4
<racarr> plymouth, hitelisted
<racarr> what
<racarr> I am fully upgraded
<racarr> and just ran mir
<racarr> ufahsufashfasha
<RAOF> Huzzah!
<RAOF> You've fixed it!
<racarr> what if it fixed itself in the archive
<racarr> while ive been doing this all day
<racarr> ive been using
<racarr> the same mir
<racarr> binary
<racarr> ...maybe a header changed
<racarr> ugh
<racarr> ok literally no headers changed
<racarr> im flashing a latest image and upgrading to see if it really did just
<racarr> ...fix itself
<tvoss> good morning
<tvoss> RAOF, we have exclusive access to the ati machine :)
<RAOF> Excellent.
 * RAOF is making coffee for a moment.
<tvoss> RAOF, I'm back in ~1 hour
<racarr> tvoss: So I've been bisecting images, until I got to august 12th broken july 26th orks then I ran out of images so I started
<racarr> installing packages to upgrade, about 10 at a time
<racarr> and rebooting and testing
<racarr> at one point it seemed to break, so I bisected those packages from the working image
<racarr> but then it always orked so I started over
<racarr> over about 30 reboots I saw maybe 2 failures here I had to reboot, but then it alays worked until I was
<racarr> fully ugpraded, and it still worked!
<tvoss> racarr, wtf
<racarr> and then I verified I asn't crazy, and the fully upgraded binary was working
<racarr> and cmake, didn't detect any thing as touched, i.e. mir needing rebuild, in fact none of the mir
<tvoss> racarr, could you reboot like 20 times to rule out a race?
<racarr> build depdencies were ever upgraded
<racarr> tvoss: I have, it seems either it always fails, or
<racarr> just occasionally it fails in this one way that a reboot fix
<racarr> but always works otherwise
<racarr> what I am doing now is a clean image to see i it was
<racarr> magically fixed in the archive
<tvoss> okay
<tvoss> racarr, can you compile that into an email?
<racarr> tvoss: Yeah I am about 5 minutes away from the result on the
<racarr> clean image then I will write things up
<racarr> it doesn't really make any sense as far as I can see, but I was pretty careful
<racarr> but I dunno, I haven't really zoomed back out yet
<racarr> ive just been...in robot mode
<racarr> ugh
<racarr> it didn't work
<didrocks> hey robert_ancell! Just a quick note on lightdm packaging, you took my cleanup branch, right? (https://code.launchpad.net/~didrocks/lightdm/packaging-cleanup)
<didrocks> it was merged in the /unity one, not sure you took it for trunk
<robert_ancell> didrocks, yeah, it's a mix of a few different packaging branches :)
<robert_ancell> i.e. what was in the archive + the changes you made + the test changes made for CI
<robert_ancell> will be nice to be down to one branch :)
<didrocks> robert_ancell: indeed ;) thanks!
 * didrocks can close a tab then \o/
<racarr> tvoss: OK I commented on the bug
<racarr> brain basically off now
<RAOF> didrocks: Yo!
<didrocks>  RAOF hey!
<RAOF> Bah. Why aren't all the rdeps of xmir magically rebuilt when I break the ABI? :)
<RAOF> didrocks: By the way, this patch http://paste.ubuntu.com/5983202/ worked fine; it was when we turned on logging for the msg-processor and frontend that the race disappeared.
<RAOF> And by âworked fineâ I obviously mean âhung like a bastardâ
<didrocks> RAOF: was the rdepends a question for me?
<didrocks> RAOF: ah, so you got all the info you needed?
<RAOF> No :)
<RAOF> didrocks: Well, we got all the information that patch provided. :)
<didrocks> heh
<RAOF> Which was "yes, XMir really is writing the request to the socket and is not receiving a reply"
<didrocks> RAOF: the ATI machine is completely deprovisionned btw
<RAOF> So I hear.
<didrocks> (just done)
<didrocks> if you need help to setup the environment, do not hesitate
<RAOF> I think others are taking the lead on this bug for a while, while I get multihead for XMir done.
<didrocks> ok
<alf__> racarr: dpms ping
<RAOF> I seem to be leaking ALL THE FDs
<RAOF> But I don't think that's my fault.
<smspillaz> the awkward moment when you have been writing C++ for so long that you forgot how to write GObjects
<RAOF> I hear the correct way to do that is to write a DSL.
<smspillaz> RAOF: DSL?
<RAOF> Domain Specific Language; ie: Vala
<smspillaz> lol
<smspillaz> actually
<smspillaz> I think this marks the first time this year
<smspillaz> I will have written a GObject
<duflu> \o/
<smspillaz> not a cause for celebration
<duflu> or /o\ depending on how you look at it
<smspillaz> /o\ most certainly
<duflu> gcc. How I hate you and your insane C++ error messages
<RAOF> Yes
<dholbach> good morning
<RAOF> Hrm.
<tvoss> RAOF, ?
<RAOF> I think we might leak fds for clients with more than one window
<RAOF> Or, at least, we leak ALL THE FDs when XMir has two surfaces, one for each of my displays, and we don't leak fds when XMir is only driving one display.
<RAOF> The problem could be in the XMir code, but I thought that mirclient should handle the fds sent over the wire.
<duflu> RAOF: Is this related?... 1194534
<duflu> bug 1194534
<ubot5> bug 1194534 in Mir "mir_connection_release does not free associated surfaces" [Medium,Triaged] https://launchpad.net/bugs/1194534
<RAOF> duflu: I don't think so; I don't call mir_connection_release
<duflu> Ever?
<RAOF> Ever
<RAOF> At the moment. I guess I should at some point, but it's not hugely important.
<duflu> RAOF: So you *should* get leaks of some sort anyway :)
<RAOF> What *is* important is that Mir doesn't leave in excess of 1024 file descriptors open, causing X to fail to accept any new clients.
<RAOF> duflu: Oh, sure. It just shouldn't be âthere are more than 1024 file descriptors leaked by the RPC codeâ
<duflu> That is indeed a lot
<tvoss> alf__, ping
<alf__> tvoss: pong
<alan_g> hikiko: how is it going?
<hikiko> hi alan_g
<hikiko> I started a new branch here: https://code.launchpad.net/~hikiko/mir/mir.native-platform-functions and I am now replacing the functions in native platform
<alan_g> hikiko: by "native platform" you mean *nested* platform?
<hikiko> no
<hikiko> I started filling the:
<hikiko> get_ipc_package, create_internal_client, create_buffer_allocator
<alan_g> for android and gbm?
<alan_g> Let's first rewrite the nested functions that can be written "return native_platform->xxxxxxx();" and get that onto trunk.
<hikiko> without implementing the xxxx() you mean?
<alan_g> https://code.launchpad.net/~hikiko/mir/mir.native-platform-functions already has implementations (stubs)
<hikiko> yes
<hikiko> so I ll just call the stub functions
<hikiko> you don't want me to implement the stubs as well
<alan_g> If we get the nested code landed (with stubs) then we can separate work on the GBM and Android support
<hikiko> cool
 * alan_g likes to keep as much code on trunk as possible. (I.e. small incremental merges)
<alan_g> hikiko: like: https://code.launchpad.net/~alan-griffiths/mir/display-is-not-output/+merge/180914 (which you could review once you've MP'd the above)
<RAOF> Oh, that's right. Callbacks are non-optional.
<duflu> That sucks. My thinkpad has pinned itself to 800MHz even though I'm building on both cores
<duflu> Usually that only happens on low battery or high temperature...
<RAOF> Is there some philosophical reason why all our async functions *require* valid callbacks to be passed in?
<duflu> RAOF: I was wondering that at the start of the year. I think I proposed making them optional and it was rejected. Can't remember
<hikiko> alan_g, https://code.launchpad.net/~hikiko/mir/mir.nested-platform-functions/+merge/181001
<hikiko> I'll review the display-is-not-output now
<RAOF> duflu: I guess we could have a no-op callback in mirclient?
<alan_g> hikiko: OK (I'll review yours after I finish on session_lifecycle)
<RAOF> Because I really *don't care* when this surface gets released
<duflu> RAOF: It's a bit ugly and definitely suboptimal
<duflu> RAOF: I'd prefer support for NULL
<duflu> NULL is definitely a valid callback in some cases
<RAOF> An explicit no-op callback is probably more self-documenting, but NULL is more idiomatic.
<duflu> RAOF: Then to solve both: const CallbackType *noop = NULL;
<hikiko> sure alan_g take your time
<duflu> RAOF: Or just #define NO_CALLBACK NULL
<RAOF> But now you need to explicitly handle NULL in mirclient!
<duflu> RAOF: So...?
 * RAOF is not really arguing against NULL
<mpt> tvoss, katie: When we say surfaces aren't aware of their absolute position, what's the one-sentence reason why?
<hikiko> alan_g, what does the POC mean here? // TODO as a POC just use the first active display
<alan_g> "Proof Of Concept" (note to self: don't abbreviate)
<tvoss> mpt, as seen in the past, it leads to assumptions regarding the phyiscal layout of screens for example.
<hikiko> so, alan_g this branch just modifies the display to match the new Display interface with the multimonitor support or I am missing something?
<hikiko> no, there's the displayoutput as well
<alan_g> hikiko: yep
<mpt> tvoss, when there are multiple displays, do apps know even what display each surface is on?
<tvoss> mpt, the plan is to only communicate dpi changes
<mpt> tvoss, thanks. Next question: If an app has three windows open, A, B, and C, and A is focused, does the app have knowledge that B is above C or vice versa?
<tvoss> mpt, the app knows which surface is focused
<mpt> Yes, but that's A. :-)
<tvoss> mpt, sure :) but under the constraint that stacking only changes when focus changes, an app knows if B is over C or vice versa
<mpt> ah, right
<mpt> So it couldn't interrogate, but it could remember
<hikiko> alan_g, output == context?
<alan_g> hikiko: ?
<tvoss> mpt, exactly. our focus policy makes sure that stacking per app only ever changes if focus changes (at least for regular surfaces)
<mpt> tvoss, unless a window manager decides to go Amiga Intuition 1.x style and add a "Send to Back" button to every title bar. :-)
<hikiko> I mean, a display's output (eg the nested display's output) is the sum of variables that describe the context we render in the display (the state)?
<tvoss> mpt, hmmm, good point ;)
<hikiko> and we ll have a different context for every display and a different display for every monitor?
<alan_g> hikiko: there's one Display and an output for each active monitor. (At least that's what's in the native GBM code)
<alan_g> But that's not what I've implemented for nested (yet)
<hikiko> so each monitor is a different "buffer"/window?
<alan_g> ack
<hikiko> yes, I understand what you did and it looks good to me, I am just trying to get sure I understand the whole concept
<hikiko> +can I top approve? it has 4 positive reviews
<alan_g> hikiko: I think it should be a customization point - and am still thinking. (E.g. I may want a nested mir with a single window that doesn't match a monitor)
<alan_g> hikiko: you can top approve
<alan_g> (And you don't need to ask permission)
<katie> tvoss, another question for you.. is it Mir or the application that should remember whether a surface is fullscreen/maximised etc?
<tvoss> katie, for the surface state, it should be the application
<hikiko> alan_g, if this 1 window can be splitted to as many buffers as the monitors and can have the size of the virt. screen size there shouldn't be a problem (I am not 100% sure though)
<mpt> tvoss, katie: If Mir can remember its absolute position, why can't Mir remember its state too?
<tvoss> mpt, fair question: we could add a function: restore previous state
<mpt> tvoss, katie: I think we're missing a description of how an app tells Mir the identity of a surface it's reopening. That would be the place to describe that Mir restores not just the previous position and size but the previous state too.
<alan_g> hikiko: it isn't a problem for now - but I was thinking more of a window smaller than a monitor. (So I could run up a server as a "normal" application)
<tvoss> mpt, ah, that's a good point. so the app is responsible for "tagging" a surface
<mpt> tvoss, when an app opens a surface, does it have to provide a preferred size?
<tvoss> mpt, yup, an initial one at least
<mpt> tvoss, but what if I develop a word processor, and the preferred size for new document windows depends on the physical size of the current display, up to a reasonable limit? Should all apps contain that kind of logic?
<tvoss> mpt, why would it depend on the physical size? you mean in terms of percentage?
<mpt> tvoss, katie suggests that in that case, an app could just ask for a preferred size of, say, 8" by 12". On any screen smaller than that (e.g. phone, tablet), it would take up full screen. On any screen larger (e.g. Cinema Display), I'd get that actual size.
<tvoss> mpt, yup, that sounds like a good idea. How do you want to handle aspect ratios?
<mpt> tvoss, if you reopened a surface on a display that was still wide enough but not tall enough, katie and I think it would only get shorter, not narrower.
<tvoss> mpt, so we do not preserve aspect ratio?
<mpt> tvoss, right
<tvoss> mpt, okay. What if an app needs that functionality?
<mpt> tvoss, unless you want to back that into window management (it seems a bit niche), the app would need to notice its new height and narrow itself proportionately.
<mpt> *back -> bake
<tvoss> mpt, the one thing that concerns me is the feedback cycle required ...
<tvoss> mpt, user resizes window, app receives resize notification, resizes its frame
<mpt> tvoss, well there are other cases where a window wants to set strict limits on how it can be resized ... The most complicated example I've seen is floating toolbars, where the exact combination of width and height depends on what buttons and other controls are present.
<mpt> Palettes is an even better example.
<tvoss> mpt, ack, so why don't we say an app can request the following flow: about-to-be-resized(old_size, newly_requested_size) -> new_size_as_calculated_by_app
<tvoss> and only then we resize
<mpt> Hmm, I thought the Gimp toolbox would be an example, but it isn't, because of that dire "You can drop dockable dialogues [sic] here"
<mpt> tvoss, what use is old_size there?
<tvoss> mpt, hmmm, to express the user requested change ... although the application should know that anyways
<mpt> tvoss, ideally the app would animate internal reshuffling of a window's contents, but that isn't helped by knowing the old size of the entire window.
<mpt> For that it needs to know the old position of individual elements inside.
<tvoss> mpt, which it does anyway
<Saviq> greyback, any idea how do we stand on screen blanking in unity8@Mir?
<greyback> Saviq: I've not attempted it. Right now it doesn't blank.
<Saviq> greyback, right, another one to the list of regressions
<Saviq> greyback, did you write it in the end or shall I?
<greyback> Saviq: http://sketchpad.cc/zYRXs1hnWu
<Saviq> greyback, added some more and their blueprint-like status, how's it look?
<greyback> Saviq: looks ok
<tvoss> alan_g, got a nexus 4 handy?
<alan_g> yes (but lunch is calling)
<tvoss> alan_g, can you ping me after lunch then?
<alan_g> tvoss: Sure. Should I leave it installing anything?
<tvoss> alan_g, would be cool if you could phablet flash the latest image
<alan_g> tvoss: ack
<alan_g> Rats!! (It is in "I don't have enough charge to charge mode" again.)
<tvoss> olli_, ping
<olli_> tvoss, pong
<alan_g> tvoss: back (but flashing failed) "ERROR:phablet-flash:Command 'adb shell mount /sdcard/' returned non-zero exit status 255"
<tvoss> alan_g, please ask in #ubuntu-touch for help
<alan_g> tvoss: I'll ping you when I've got it working again
<tvoss> alan_g, ack
<alan_g> hikiko: how are you doing?
<tvoss> sil2100, didrocks lxc-start on the ati machine fails, I can briefly see the login prompt, then the container shuts down
<tvoss> sil2100, didrocks lxc-attach fails with lxc-attach: failed to get the init pid
<didrocks> tvoss: do you restart the Mir environment?
<didrocks> the right run?
<alan_g> tvoss: OK I've got a newly flashed N4
<ricmm> thomi: did you guys get the prio sorted?
<ricmm> I obv cant push it, I just ask whoever is on vanguard in webops
<tvoss> ricmm, thomi is unlikely to be online
<ricmm> right
<tvoss> didrocks, how do I do that?
<didrocks> tvoss: that's what I told, we need to reset the Mir environment
<tvoss> didrocks, mind telling me how? :)
<didrocks> but I don't have time for that (taking 15 minutes and hoping on meetings)
<didrocks> tvoss: I can recreate quickly a blank one rather
<tvoss> didrocks, ack
<didrocks> where you have a persistency daily image
<didrocks> then you add the ppa
<didrocks> and the packages
<didrocks> sounds ok?
<hikiko> alan_g, in this case the window could be resized to be fullscreen when necessary
<hikiko> so, why not
<didrocks> let's take that as a yes :)
<alan_g> hikiko: Don't worry about that use case yet
<alan_g> hikiko: what are you doing currently?
<hikiko> I am looking at the display
<didrocks> tvoss: ok done
<didrocks> let me pm the instructions
<hikiko> there are at about 8 functions with todo
<hikiko> I think that maybe I should start from there
<hikiko> if you agree
<hikiko> (alan_g)
<alan_g> hikiko: Don't try to do too much at once.  I'm looking at the mulit-monitor interactions for NestedDisplay (I think alf__  is busy writing the stuff I need for it)
<hikiko> alan_g, what do you suggest I do as a next step then?
<alan_g> so maybe the best place to for you to start is in the NativeGBMPlatform
<alan_g> BTW Don't worry about duplicating code with GBMPlatform - we can refactor that after we have things working.
<alan_g> hikiko: ^^
<hikiko> ok then :) I ll start adding the functions there!
<alan_g> hikiko: don't go too fast - just get the test to get through one more function call
<alan_g> (Before an exception gets thrown)
<hikiko> alan_g, what do you mean get the test?
<rsalveti> tvoss: racarr: can start mir_demo_server successfully with aug 5th
<rsalveti> tvoss: which other test can I run?
<rsalveti> hm, seems it crashed now
<rsalveti> E/Adreno200-GSL( 1724): <ioctl_kgsl_driver_entry:269>: open(/dev/kgsl-3d0) failed: errno 2. No such file or directory
<alan_g> hikiko: there's only one TestNestedMir test currently - I mean that one
<hikiko> you mean to run this test each time I add a new function?
<alan_g> hikiko: I mean change the system so that the exception caught comes from the next not-implemented function that gets called, update the test for the new exception and MP those changes.
<hikiko> alan_g, ok :) I might bother you when I have to modify the test because it will be my first one... but ok, I'll do the change first :)
<alan_g> alf__: @place-surface-in-output - how does a client select an output? I don't see any client-side API for it - what have I missed.
<alf__> alan_g: it's a new field in surface creation parameters .output_id
<alan_g> alf__: thanks
<tvoss> racarr, ping
<hikiko> bye!
<tsdgeos> olli_: is it ok if instead of 19.2 I test image 20?
<tsdgeos> phablet-flash cdimage-touch --pending is giving me 20 instead of 19.2
<tvoss> tsdgeos, please do 19.2
<tsdgeos> tvoss: then i'm going to need help on how to get it
<tvoss> ogra_, how to get 19.2 with phablet-flash?
<ogra_> tvoss, dunno, i never use phablet-flash ... i think you need to give it a --url parameter
<ogra_> tvoss, reading teeh help i would guess: phablet-flash cdimage-touch -d mako --ubuntu-path=http://cdimage.ubuntu.com/ubuntu-touch/daily-preinstalled/20130819.2/
<tvoss> tsdgeos, ^
<tsdgeos> ogra_: the help confuses me
<ogra_>  phablet-flash cdimage-touch -h
<tsdgeos> what's the difference between --device-path and --ubuntu-path
<tsdgeos> ogra_: that is what is confusing me, yes i can get there ;-)
<ogra_> dunno, ask sergiuiens :)
<ogra_> he invents those options all the time :)
<rsalveti> device-path is the android zip file
<rsalveti> ubuntu-path is the ubuntu zip file
<rsalveti> you need both
<ogra_> oh ?
<tsdgeos> can't i just say "i want 20130819.2" easily?
<ogra_> i thought there was a patch that you only need one with the latest phablet-flash
<ogra_> tsdgeos, depends how well your voice input works
<ogra_> :P
<bschaefer> tvoss, ping
<tvoss> bschaefer, otp
<bschaefer> tvoss, alright
<alan_g> Have a good day everybody!
<kgunn> racarr: you on?
<racarr> kgunn: Yeah just recently
<kgunn> np...feel free to coffee up
<kgunn> basically....the current request is to retest using 19.2 with -b (to make it completely fresh)
<kgunn> rsalveti was able to get it working
<kgunn> in case the image moved....use this command line
<rsalveti> I didn't get the crash, but just noticed I'm also getting a black screen
<rsalveti> the issue when allocating memory is due a race in udev/ueventd, which I'm working on atm
<kgunn> phablet-flash cdimage-touch --ubuntu-path http://cdimages.ubuntu.com/ubuntu-touch/daily-preinstalled/20130819.2/saucy-preinstalled-touch-armhf.zip --device-path http://cdimages.ubuntu.com/ubuntu-touch/daily-preinstalled/20130819.2/saucy-preinstalled-touch-armel+[device].zip -b
<racarr> 19.2?
<rsalveti> racarr: which was the latest issue that you were having? a crash or just a black screen?
<racarr> rsalveti: Ah yeah black screen is all I get
<racarr> crash is rare
<racarr> any time I have ever seen the crash
<racarr> a reboot has made it go aay and it
<racarr> reverted to black screen
<rsalveti> right, then let me flash the older image again, which was working without black screen
<racarr> err so wait should I try this
<racarr> phblet-flash kgunn gave me?
<rsalveti> please try
<rsalveti> seems it worked fine for ev
<kgunn> rsalveti: "worked fine" means unity8 came up on mir ? & no black screen ?
<racarr> Err
<rsalveti> unity coming afaik
<racarr> flashing
<racarr> ok installing mir ppa on image
<bschaefer> kgunn, hey, sooo Im suppose to help work on an ATI bug? Would you happen to know something about that?
<kgunn> bschaefer: ok....so, it seems to be corrected by the latest kernel (updated to 3.11 y'day ~2pm my time)
<bschaefer> through didrocks machine, and I missed tvoss a bit ago...soo I figured you might know something!
<bschaefer> kgunn, o really?
<bschaefer> kgunn, soo do we need to confirm this, or is it already?
<kgunn> tvoss|afk: & didrocks rebuilt and tried reboot ad-nauseum
<kgunn> it never failed
<kgunn> there were some kernel changes (e.g. mutex related) that certainly could've effected
<kgunn> so anyway...result was to place didrocks machine back "on the line"
<bschaefer> sweet, well lets hope it stays fixed :)
<kgunn> he will start pushing updates tomorrow morning his tmie
<kgunn> time
<kgunn> yep
<bschaefer> cool! Well that was fun to work on :)
<kgunn> we are going to pull his machine again in a couple of weeks during bug squash week to root cause
<kgunn> seriously the pressure is off....but if you wanted to attempt some root cause effort that would be great
<bschaefer> that would be a good idea, don't want this coming up later on
<kgunn> altho you'd need to coordinate with him....as its back in service
<kgunn> painful part will be trying to stay on 3.10 kernel to test
<bschaefer> kgunn, I can try, I think i remember trying to reproduce this last week on my ati machine
<kgunn> bschaefer: were you ever successful ?
<bschaefer> right, yeah if he comes back and wants some more testing i my time zone Ill go with it!
<bschaefer> kgunn, nope :(
<bschaefer> kgunn, it was only didrocks machine
<kgunn> bschaefer: yeah...that's the thing....his machine was kinda golden
<kgunn> even raof's debug add ons changed timing and bug disappeared....
<bschaefer> yeeah, didrocks should get a new machine :)
<kgunn> like i say mutex changes coming in 3.11 kernel make me wonder
<bschaefer> but it is nice it did catch something like that, would have been hard to figure out later on...
<bschaefer> kgunn, in a bad way?
<bschaefer> or rather the mutex fixes are the fix?
<kgunn> b/c xmir would always start ok...it only ever stalled when compiz was trying to init gl for unity
<kgunn> in a good way
<kgunn> yes...mutex fixes
<bschaefer> right, I ran into that on my intel machine
<bschaefer> but then i purged all of my libegl* stuff and it never came back...
<kgunn> <mlankhorst> mir fixes, ww_mutex changes, dpm support
<bschaefer> kgunn, then my laptop died :(...
<kgunn> <mlankhorst> maybe uvd fixes
<bschaefer> awesome
<kgunn> that was the response i got for kernel changes that might've effected this
<bschaefer> well IIRC it was thought to be a deadlock right?
<bschaefer> or a race for this ATI problem?
<racarr> back on DPMS mode :)
<racarr> phone almost upgraded
<kgunn> racarr: so did 19.2 work for you ?
<kgunn> bschaefer: well...deadlock only occured when they tried subsequent start of x after the compiz stall on gl load
<kgunn> bschaefer: so the 1st symptom was always failure to load gl from compiz (even tho mir was fine)
<bschaefer> kgunn, oo interesting, well when tvoss|afk gets back I can play around on the machine again to try and get the issue or dig some more into it
<racarr> kgunn: It's installing mir ppa
<racarr> it takes me 5-6 minutes to run apt-get update alone :(
<racarr> phablet is so slo on my wireless
<rsalveti> racarr: 19.2 always gives black screen here, but aug 5th works fine, will test some other images
<rsalveti> doesn't crash, but gets a black screen
<kgunn> racarr: rsalveti ....ok, i tried earlier, got black screen....just reflashed and _only_ installed the mir ppa (e.g. didn;t do a dist-upgrade rather install 1by1)
<kgunn> and still got a black screen
<racarr> Wait then why am I trying
<racarr> because isnt this hat I did
<racarr> yesterday
<rsalveti> right, I first thought the issue was related with the crash that happens sometimes
<racarr> no
<racarr> the crash just happens XD
<rsalveti> hahah, right
<racarr> I think it's different
<racarr> rsalveti: Ok so yesterday
<rsalveti> let me try to isolate the black screen then
<racarr> I started from a working image
<racarr> july 26th
<racarr> and started upgrading packages in groups of 10
<kgunn> rsalveti: also...for racarr's sanity....didn't you see unity boot (no black screen) when apparmor=0 ?
<racarr> a few times I saw the crash, but reboot always fixed it and it orks multiple times over
<racarr> eventually I ully ugpraded
<kgunn> or was that just a red herring
<racarr> and it worked too!
<rsalveti> apparmor=0 doesn't have any effect here
<racarr> Never had any effect here either:(
<kgunn> rsalveti: thanks...i'll stop saying that then :)
<racarr> rsalveti: Anyay what this means (i.e. if someone can confirm that upgrading uly 26th works while installing the latest image fails)
<rsalveti> racarr: right, will try with some other images here, if it's android related I should be able to see what changed easily
<racarr> then we can narrow it down to things in the image process
<racarr> great
<racarr> I was wondering if it could have to do
<racarr> didn't the images change
<rsalveti> racarr: just tested from aug 5th, and worked fine
<racarr> to multiuser
<rsalveti> but didn't dist-upgrade
<rsalveti> let me do that now
<rsalveti> will download 100mb =\
<racarr> tested what?
<racarr> i.e. mir/unity, etc all run fine (from which source)
<rsalveti> image from aug5th
<racarr> on august 5th image?
<rsalveti> yup
<racarr> the mir image? or
<racarr> image + mir ppa or whatever
<racarr> what*
<rsalveti> default image, and default mir from ppa (just testing the egltriangle client example)_
<rsalveti> for now
<rsalveti> which is already enough to reproduce the black screen issue
<rsalveti> sorry, default mir from archive
<rsalveti> let me dist-upgrade now to check
<kgunn> rsalveti: you sure about that?...i thot racarr was getting black screen , but then could subsequently run mir demo client fine
<kgunn> racarr: ^ ?
<rsalveti> lol, so many issues at the same time it seems :-)
<rsalveti> but I'm getting black screen with mir_demo_client_egltriangle
<kgunn> :)~
<racarr> Yes I can run the client
<racarr> fine
<racarr> and it reports getting FPS, etc
<racarr> (frequently it gets stuck at half FPS though not always)
<racarr> but there is never anything on the screen
<rsalveti> then why the hell even the client is getting a black screen here
<racarr> rsalveti: No, black screen
<rsalveti> showing fps and such, but black screen
<racarr> it ust reports working
<racarr> yes
<rsalveti> right
<rsalveti> then it's the same behavior here
<racarr> On any image where I have ever seen that
<racarr> I have never seen
<racarr> anything on screen  from mir :)
<racarr> but occasionally have seen the crash
<racarr> on any image where I have seen things on screen from mir
<racarr> I have also occasionally seen the crash
<racarr> but never seen
<racarr> just black screen
<racarr> so I think it's really just two issues
<rsalveti> right
<rsalveti> the crash is something that should be fixed once I fix the udev/ueventd races
<rsalveti> now we need to isolate this black screen one, got quite a few images to test here
<rsalveti> after doing dist-upgrade
<racarr> ok makes sense that the crash is a race
<racarr> im glad you hve the images :)
<racarr> 19.2 is still broken for me
<racarr> ust for the record
<rsalveti> ok, should have enough to keep me busy for the next hour
<racarr> Ok. Let me know if I can help
<kgunn> rsalveti: let me know if i can be of help as well....
<rsalveti> sure
<racarr> kgunn: I am considering that maybe I should try and land dpms with the ineffeciency that I was talking about yesterday
<racarr> because it will be easy to fix after FF
<kgunn> i'm not the fastest....but i follow instructions well
<kgunn> racarr: yes
<kgunn> agreed...
<rsalveti> racarr: worked fine after dist-upgrade
<rsalveti> now to try some other images
<racarr> So sstrange
<racarr> its going to be something awfully small in the end haha
<rsalveti> could be on the android side
<rsalveti> like the migration to 4.2.2
<racarr> oh didnt realize that happened
<rsalveti> but the interesting thing is that the binaries we were using were already from 4.2.2
<racarr> so strange :/
<rsalveti> yeah, image from 07 already gives me a black screen
<rsalveti> now let me revert the android side
<rsalveti> yeah, just flashing the android zip from 05 made 07 to work again
<rsalveti> so the different is on the android side, will investigate that a bit more
<racarr> Aha! close
 * rsalveti takes a break, late lunch
<racarr> :) enoy
<racarr> Lunch for me
<tvoss_> racarr, ping
<kgunn> rsalveti: so 07 vs 05...that's android config as of August 7 and August 5 respectively ?
<rsalveti> kgunn: yes
<rsalveti> august 5 was still based on 4.2.1, >= august 6 is based on 4.2.2
<kgunn> rsalveti: got it...
<racarr> hoops back
<racarr> whoops*
<racarr> tvoss_: pong
<thomi> morning
<racarr> dpms is almost done :)
<racarr> all done except the GBM impl hich looks really simple
<racarr> im a little concerned about backlight control
<racarr>                 if (drmIoctl(sna->kgem.fd, DRM_IOCTL_MODE_GETPROPERTY, &prop))
<racarr> drm API is a pain to mock
<racarr> not sure how to mock the
<racarr> DPMS property index id integer:p
<rsalveti> racarr: ok, so the change is part of the updated display stack for qcom (for 4.2.2)
<rsalveti> reverted it and was able to get that to work with the latest image, now to find out the right commit :-)
<kgunn> rsalveti: can you share the android git tree & relative history (if easily at hand)
<kgunn> rsalveti: just curious...i mean, we're likely going to have to update to "new android stack model"
<kgunn> would be my guess
<kgunn> rsalveti: p.s. thanks for the bisecting help
<racarr> rsalveti: Great to hear :)
<rsalveti> kgunn: http://phablet.ubuntu.com/gitweb?p=CyanogenMod/android_hardware_qcom_display.git;a=summary
<rsalveti> this is what I reverted, basically
<rsalveti> from the phablet-saucy branch to phablet-10.1
<rsalveti> now will try to bisect in more details
<racarr> Implemented durning off the display but turning it back on
<racarr> is having some issues
<racarr> revno: 982 [merge]
<racarr> what does this do
<racarr> or is it just refactoring
<racarr> it breaks unity 8
<racarr> and the easy answer is revert it :p
<racarr> ...lol at xf86-video-modesetting
<racarr>         /* bonghits in the randr 1.2 - uses dpms to disable crtc - bad buzz */
<racarr>         if (mode == DPMSModeOff) {
<racarr>         }
<racarr> ...bad buzz indeed.
<bschaefer> anyone else getting this error with only this mir demo: http://paste.ubuntu.com/6008072/
<bschaefer> the multiwin, it seems when ever I try to do any kind of "get mir region" it fails :(
<racarr> bschaefer: THERE ARE NO MORE B UGS LALALALALALALALA
<racarr> No I have not seen that
<bschaefer> racarr, :)
<bschaefer> haha
<racarr> and actually just built and tested trunk like 30 seconds ago
<racarr> on radeon
<racarr> my distribution
<racarr> is not entirely up to date
<bschaefer> racarr, yeah im on ati...maybe I should update mir
 * bschaefer goes to rebuild trunk
<bschaefer> all other demos work though :)
<robert_ancell> robotfuel, ack on the bypass testing - that seems to be the same behaviour others are getting. duflu has made some more changes so I'll update the PPA now
 * bschaefer notices the nice grey background of the mir server now
<bschaefer> racarr, stack trace if you're interested: http://paste.ubuntu.com/6008119/
<bschaefer> full trace: http://paste.ubuntu.com/6008126/
<bschaefer> racarr, i also just realized was getting that cursor problem as well that I commented out...
<bschaefer> as im not even able to load the server without it complaining about the gbm not able to open ...
 * bschaefer goes to try that out again
<racarr> ill check it out soon
<racarr> second lunch :p
<bschaefer> yuup getting that gbm cursor error just when trying to start the mir server on normal X... http://paste.ubuntu.com/6008137/
<bschaefer> racarr, :), well I really should ping RAOF about it
<bschaefer> as IIRC the fix the u-s-c was to disable input but this was only for u-s-c, not the mir server...
<racarr> No I get RAOF
<racarr> :p ok maybe I can figure out my dpms thing myself
<racarr> and you can hve RAOF
<bschaefer> racarr, haha, well yours is a bit more important :)
<bschaefer> i think my issue is only on a few ATI cards...
<bschaefer> racarr, i can also bug him tomorrow about it
<racarr> ok ill give you RAOF for
<racarr> 1 bitcoin
<racarr> insted
<bschaefer> haha
<racarr> :p haha sorry im just teasing
<racarr> dont orry about it
 * bschaefer doesn't have any bitcoins
<racarr> I probably cant look hard at this right aay though, need to poke at
<racarr> DPMS a little
<racarr> should be super close
<racarr> haha me either
<bschaefer> cool, i don't actually know what DPMS is
<bschaefer> sounds like a long word though
<kgunn> rsalveti: so what's the current thot....should you simply revert that one commit to unblock ? or what's your recommendation ?
<bschaefer> Display Power Management Signaling? Eww...
<rsalveti> kgunn: there's not single commit to revert yet, still looking
<kgunn> rsalveti: got it...i'll try to be patient
<rsalveti> haha :-)
<kgunn> rsalveti: i get a lot of questions about it....as you can imagine :)
<rsalveti> yup, no worries
<racarr> bschaefer: Its pretty ew
<racarr> so ar I can turn the display off
<racarr> but then never back on :p
<bschaefer> haha, well who needs a working display anyway!
<racarr> then I tried looking in xf86-video-modesetting for examples
<racarr> hich is where
<racarr> 21:44 < racarr>         /* bonghits in the randr 1.2 - uses dpms to disable crtc - bad buzz */
<racarr> comes from
<racarr> lol
<bschaefer> hahaha
<racarr> RAOF: Around?
<RAOF> racarr: Yo!
<racarr> RAOF: Was hoping you might have some insight on my DPMS difficulties
<racarr> essentially, I am setting the DPMS property on the connector
<RAOF> Sure. Let's see if I've drunk from that particular fountain of madness.
<racarr> with the DPMS mode, and DPMSModeOff works kind of as you ould expect
<racarr> the display turns off
<racarr> unforunately I can't verify hat happens next because
<racarr> I can never turn the display back on
<RAOF> Heh.
<racarr> and if I write mir_demo_server to
<racarr> some output the file ends up empty
<racarr> I guess I can use a second machine to
<racarr> get that but
<racarr> lol I guess I am just wondering if there is anything off the top of your head
<racarr> that should obviously have to be done as well, etc
<racarr> maybe I can use xset dpms force on
<racarr> to recover
<RAOF> I think possibly the answer might be "don't bother trying to use the dpms properties; just modeset a null fb"?
<RAOF> racarr: That's what the intel driver does, at least.
<RAOF> DPMSOff == SET_CRTC to 0; DPMSOn == set_mode_major (ie: full modeset)
<RAOF> racarr: This is different to just removing the display from the DisplayConfig because the display is still logically connected (and so you can put windows on it, we probably still have its DisplayBuffers allocated, etc). But as far as KMS is concerned, just remove it from the config.
<racarr> he intel driver also sets the property
<racarr> the modesetting driver ignores the crt and just messes ith the property
<racarr> complaining of "bonghits in the randr"
<racarr> Ill try ith the crtc...and make sure I redo things properly on ModeON
<RAOF> Ah, right. You might want to set the DPMS property in addition to doing the modeset to turn off/on the backlight.
<RAOF> (Which we might have to do manually anyway)
<racarr> sounds promising
<racarr> yes backlight
<racarr> is a mild concern
<racarr> intel driver seems to do special things
<RAOF> Yeah, backlight is a swamp of madness.
<racarr> attempts test again...*crosses fingers*
<RAOF> Because it's all âas an OEM I can add value by having a different backlight interface!â
<RAOF> (Spoiler: no, you can't)
<RAOF> Hm. So XMir XRandR appears to work, except for the bit where Mir actually changes any modes.
<racarr> Doo doo :(
<racarr> also that doesnt sound great
<bschaefer> RAOF, hey, guess what happens when I try to start the mir server on my ATI machine? http://paste.ubuntu.com/6008137/
<RAOF> bschaefer: What ATI card do you have, again?
<bschaefer>  VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Redwood XT [Radeon HD 5670/5690/5730]
<bschaefer> 5670
<bschaefer> is the one I have
<bschaefer> and if i comment out the creation of the cursor it works fine until I try to do software renderering (multiwin example)
<bschaefer> everything else works if I comment that out...
<bschaefer> (comment out the creation of the cursor)
<RAOF> Right. This suggests that we're failing to allocate software-renderable gbm buffers.
<bschaefer> right, which this is what I get when I run the mutli win when I turn the cursor off: http://paste.ubuntu.com/6008119/
<RAOF> Does the server also die?
<RAOF> Or spew any error messages?
<bschaefer> well right from my perspective of it not working :)
<bschaefer> RAOF, nope, it just fails to run the application and it dies
<bschaefer> it spews out:
<bschaefer> terminate called after throwing an instance of 'boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<std::runtime_error> >'
<bschaefer>   what():  Failed to import PRIME fd for DRM buffer
<bschaefer> also this is me running mir natively on normal X
<RAOF> By "on normal X" you mean "With an X server running on another VT", right?
<bschaefer> RAOF, hmm normal X meaning i've turned off xmir
<kgunn> hey...anyone got phoronix installed running standalone x (not xmir)....updated like today...want to give it a shot
<bschaefer> but yes
<kgunn> specifically openarena
<bschaefer> kgunn, i don't have phronoix installed but I can install it
<bschaefer> and im on standalone x
<kgunn> its pretty dead easy
<bschaefer> yeah, it just take a while to download the games :(
<kgunn> i just ran it on a recent update and it was ~10fps
<bschaefer> RAOF, i can try to take a better look into it since I can reproduce it well
<bschaefer> well at lease figure out what function is failing...
<bschaefer> kgunn, im also on ati
<RAOF> bschaefer: To debug you'd want to stick a breakpoint in gbm_dri_bo_create, matching width == 64 and height == 64.
<bschaefer> RAOF, to match the size of the cursor?
<bschaefer> RAOF, and ill give that a try after running this phoronix test
<RAOF> bschaefer: Correct. That way you won't catch the other allocations
<bschaefer> o cool, but it seems to be the the only one, as commenting out the creation of the cursor and the server works
<bschaefer> all egl apps work fine on it
<kgunn> bschaefer: that's cool...its a good data point
<bschaefer> kgunn, cool, just downloading openarea...then it should run!
<RAOF> bschaefer: Yeah; all those other allocations will succeed, so they're uninteresting. That's why you should âbreak gbm_dri_bo_create if ((width == 64) && (height == 64))â âº
<bschaefer> ooo i see, I was thinking all gbm buffer calls were failing, because running the example mulitwin was having problems getting a mir region
<bschaefer> which seemed related...
<bschaefer> thanks!
<RAOF> I'd suspect it's just calls with GBM_BO_USE_WRITE set
<RAOF> Which the cursor will have, but also any buffer we allocate for software rendering.
<RAOF> And it's easier to catch the cursor :)
#ubuntu-mir 2013-08-21
<kgunn> robert_ancell: yep...i'm getting the same change in perf you see with glmark2
<bschaefer> oo i see, yup :), i've still a lot to learn the graphics stack....
<robert_ancell> kgunn, cool, hopefully duflu can also reproduce
<RAOF>  !!!
<RAOF> Ok, it's really mirclient leaking.
<RAOF> racarr: Can you see anything obviously wrong with http://paste.ubuntu.com/6008432/ ?
<RAOF> Or, alternatively, bschaefer - can *you* see anything obviously wrong with http://paste.ubuntu.com/6008432/ ?
 * bschaefer looks
<bschaefer> RAOF, well I don't see the surfaces getting cleaned up, but it could happen after the while loop
<bschaefer> + line 53-54 has a small tabbing issue
<RAOF> There's nothing obviously crazy about the EGL usage, though?
<RAOF> Because with that patch, mir_demo_client_accelerated quickly runs out of fds.
<bschaefer> lots of make current calls
<RAOF> If I was aiming for efficiency I'd have spun off a pair of render threads ;)
<racarr> RAOF:      gl_animation.init_gl();
<racarr> doesn't make sense anymore
<racarr> or does it
<RAOF> I think it does; AFAIK it only affects the current context.
<RAOF> And both surfaces are on rendered to from that context
<bschaefer> RAOF, that would speed thing up ... but cant you just swap surfaces?
 * bschaefer isn't to familiar with egl apps
<racarr> RAOF: Yeah
<racarr> ok nothing obviously rong
<racarr> hats happening?
<RAOF> It leaks the fds received from Mir.
<RAOF> So, if you kill it after a while, it's got > 1024 open fds.
<racarr> agh
<RAOF> This only happens for clients with multiple surfaces.
<bschaefer> o yeah its in an infinite loop...
<RAOF> Such as... XMir with two heads.
<bschaefer> err I don't see anything being cleaned up
<rsalveti> let me past again as it seems I got disconnected
<rsalveti> <rsalveti> kgunn: so there are quite many intrusive changes comparing 4.2.2 with 4.2.1, not trivial to find what is the issue in there
<rsalveti> <rsalveti> I noticed it was also giving a enomem in logcat, which is fixed with the latest kernel driver (which I tested locally)
<rsalveti> <rsalveti> but unfortunately still getting a black screen
<rsalveti> <rsalveti> I suspect it's something mir is not yet doing by default when handling the hwcompositor from android
<RAOF> bschaefer: eglSwapBuffers will call mir_surface_swap_buffers internally, which should clean up the fds.
<rsalveti> <rsalveti> as it works just fine with surfaceflinger, even when it gives the enomem error (which seems to happen when setting up the overlay for fb2)
<rsalveti> <rsalveti> as this seems a bit critical, I'd vote to just change the branch of the qcom display git repo to be based on phablet-10.1, which was the previous branch used
<rsalveti> <rsalveti> that would get it to work again, but it'd be good to get someone involved at this later on as well, so we can use the right branch
<rsalveti> <rsalveti> guess kdub would probably have a better idea about what is going on there
<rsalveti> <rsalveti> what do you think?
<rsalveti> <rsalveti> racarr: ^?
<bschaefer> RAOF, oo i see, but if it get cleaned up on eglSwapBuffers, shouldn't it be getting cleaned up each time?
<RAOF> bschaefer: Yes indeed; this is the bug âº
<bschaefer> RAOF, o :), I remember those memory leaks that were dealing with multiple surfaces but I was thinking it was something else :)
<RAOF> :)
<bschaefer> rather, I was looking for what was wrong with the egl calls
<RAOF> Yeah, I just wanted a quick sanity check that the test wasn't doing something that's not meant to work.
<racarr> rsalveti: I agree
<rsalveti> racarr: will do a clean build and will update the bug
<racarr> It ould be good to get it working, land unity 8, and we can investigate after FF
<racarr> we even have a sprint coming up :)
<kgunn> rsalveti: totally...and kdub will be back Sept 2
<robert_ancell> kgunn, what resolution did you do the openarena benchmarks on? I'm not getting any significant change at 800x600
<bschaefer> kgunn, i get 30-60 fps on ATI
<bschaefer> RAOF, also just realized I cant gdb the mir ... my laptop has a fried gpu/motherboard soo i don't have a second machine to ssh in...
<bschaefer> yay
<RAOF> bschaefer: :(
<bschaefer> RAOF, ill try to barrow the ATI machine from QA tomorrow and dig into it
<bschaefer> as hopefully I can get a card that can reproduce this problem...
<bschaefer> or if thomi has one I can use right now...
<bschaefer> thomi, ping :)
<bschaefer> duflu, i also have a question for you about a problem im running into when trying to do software rendering with SDL 1.2
<duflu> bschaefer, yes?
<bschaefer> duflu, sooo something strange is happening only for 1.2 framebuffers: http://imgur.com/a/0S012#0
<bschaefer> duflu, each time it attempts to draw more then 1 rectangle, it starts hmm
<bschaefer> its hard to explain, but each from it doesn't seem be apply the mask when its bliting?
<bschaefer> (if that makes sense), so when im redrawing an the smily face it draws it with the black screen, then the gradient and the 2nd redraw
<bschaefer> causing a bunch of flashing
<bschaefer> duflu, and the only way around it is to redraw the entire screen vs just the place that is being updated
<bschaefer> redrawing the entire screen == copying the entire SDL screen over to mirs region
<RAOF> bschaefer: Are you taking into account the age of the buffer?
<bschaefer> RAOF, hmm im not sure how you would take that into account?
<RAOF> bschaefer: Well, if you try to only copy updates you'll need to track what is in the buffer you get (ie: via the .age field).
<RAOF> bschaefer: Because what you drew last frame *will not* be in the buffer you receive.
<bschaefer> RAOF, oo...but whats strange this same logic works with SDL 2.0...but I think things could be handled differently...
 * bschaefer pastebins the function
<bschaefer> http://paste.ubuntu.com/6008647/
<duflu> bschaefer: Yes what RAOF said. You _can_not_ make assumptions that your previous frame, or even n-2 is the one you get back. You either have to redraw everything or use the "age" field to calculate how old the buffer you're updating is
<bschaefer> RAOF, as that could be the problem, as it seems like its missing what was put into the last frame
<bschaefer> that is very interesting! I didn't actually know about the age of buffers...so there could well very be a bug in my 2.0 code as well
<duflu> bschaefer: The assumption probably broke recently as Mir now defaults to triple buffering
<RAOF> Although even with double buffering you'd get incorrect rendering.
<RAOF> But differently incorrect rendering :)
<bschaefer> duflu, well i haven't tested it in a bit, i need to test it with new mir (ie. look at the cursor)
<duflu> Yes, unless you consider "age"
<duflu> bschaefer: Yeah your Mir is clearly very old from that cursor. Much has changed
<bschaefer> im assuming its fairly simple to calculate how old the buffer is?
<duflu> bschaefer: It's an integer :)
<bschaefer> duflu, yup, I just haven't found time to poke someone about it
<bschaefer> duflu, haha
<bschaefer> well
<RAOF> You don't need to (and cannot) calculate it. You pull it out of MirNativeBuffer
<bschaefer> RAOF, i've not looked over the new API changes, but IIRC all I could get was a MirGraphicsRegion?
<duflu> Right. You don't calculate age. But based on age you will need to calculate your changes
<RAOF> See http://www.khronos.org/registry/egl/extensions/EXT/EGL_EXT_buffer_age.txt for the semantics.
<bschaefer> awesome, so if the age is to old, i my need to do a redraw
<duflu> I think in many cases calculating age-based changes is infeasibly complex. Better to redraw everything.
 * bschaefer reads link
<bschaefer> duflu, i've noticed no problems with redrawing the screen (performance wise)
<bschaefer> vs redrawing rectangles around the screen
<bschaefer> im sure there are cause... i mean you have to touch all the pixels vs just select few
<duflu> bschaefer: Yeah, though "copies" are slow. And should usually be avoided
<duflu> bschaefer: Though if you're using software buffers and Mir, then you have little choice but to copy. See: demo_client_fingerpaint
<bschaefer> duflu, o awesome, yeah, i have to copy all the changes over to a mir region ie. the whole screen :(
<bschaefer> (awesome about the example)
<bschaefer> you always seem to have so many useful ones!
<duflu> bschaefer: That's the intention. Though the practical use isn't obvious to everyone when I propose a new example :)
<bschaefer> duflu, haha, its practical time seems to always show up :)
<bschaefer> RAOF, thanks for the link! Age now makes more sense :)
<bschaefer> 0 == no back buffer so that'll be a good thing to check
<RAOF> 0 == no current buffer content
<bschaefer> duflu, RAOF thanks! I think I can actually make some progress on that problem now...
 * duflu wonders if age is still accurate. Where do we set it?
<bschaefer> RAOF, which means the last buffer has been drawn and freed?
<RAOF> duflu: In ClientBufferDepository
<duflu> bschaefer: We don't free buffers right now. They get recycled eventually. But they could be freed in theory
<RAOF> bschaefer: Which means you've got a shiny new buffer; it doesn't really imply anything more than that. Mir is free to send you a new buffer each frame, or to recycle.
<RAOF> In practice your first 3 swaps will return buffers with age == 0, as we're triple-buffeering.
<bschaefer> cool, I was think if the age was > 0 then we should redraw the screen
<duflu> RAOF: Right so not affected by SwitchingBundle changes?
<bschaefer> thinking*
<bschaefer> err...well in this case redraw, as something odd is happing in sdl 1.2 as far as I can tell...
<bschaefer> as the some logic I had is handle fine in 2.0, but ill need to look some more
<thomi> bschaefer: hey
<thomi> bschaefer: you're looking for a machine?
<bschaefer> thomi, correct! An ati one preferable one with a card  less then 7000
<bschaefer> thomi, I can also poke Chris about it tomorrow morning
<thomi> bschaefer: how about a radeon 5750?
<bschaefer> as its near my EOD (or a bit over)
<bschaefer> thomi, that would be perfect
<thomi> bschaefer: well, if you'd rather do it tomorrow....
<bschaefer> thomi, yeah, Ill wait till tomorrow, i really should eat something :)
<thomi> bschaefer: OK
<thomi> bschaefer: well, we have a 5750 in the mir test pool
<bschaefer> thomi, thanks!
<thomi> so speak with Chris Gagnon and I'm sure he can hook you up
<bschaefer> cool, that should be easy to snag tomorrow then
<bschaefer> hopefully :)
<thomi> heh
 * bschaefer heads out for the night
<bschaefer> RAOF, duflu thanks again!
<duflu> RAOF: What swapinterval does XMir use?
<duflu> bschaefer, no problem
<RAOF> duflu: Whatever's the default. Presumably 1?
<duflu> RAOF: Yep
 * RAOF goes to make coffee, then will finish augmenting the acceptance tests so that they can expose fd leaks.
<duflu> Coffee instead of lunch? Almost as good as coffee instead of dinner
<robert_ancell> duflu, have you seen the testing results for bypass?
<duflu> robert_ancell: Only one brief email
<robert_ancell> duflu, can you try glmark2 and see if you get the ~50% framerate when using bypass?
<RAOF> Coffee *before* lunch :)
<duflu> robert_ancell: That sounds very wrong... Umm it will take me a while to get to a point where I have glmark2 and Mir and bypass on the same machine again
<duflu> robert_ancell: For what driver?
<robert_ancell> duflu, there is a PPA - ppa:mir-team/qa-testing
<robert_ancell> duflu, intel for me, I think kgunn is intel too
<duflu> robert_ancell: That's really wrong. Intel has been nothing but sped up for me
<duflu> Hmm
<robert_ancell> duflu, kgunn is also getting a slowdown with openarena, but I can't reproduce that
<duflu> robert_ancell: You're using XMir though? I have only tested native Mir clients so far
<robert_ancell> duflu, I tested XMir and vanilla X
<robert_ancell> for phoronix. For glmark2 I tested XMir from archive vs XMir with bypass
<robert_ancell> I'm going to run phoronix with XMir from archive now
<robert_ancell> brb
<duflu> robert_ancell: What Mir revision is this all based on. Obviously it *requires* the switch branch to be in there too
<duflu> ?
<robert_ancell> duflu, this is lp:~vanvugt/mir/bypass
<duflu> robert_ancell: You used it as is or did some merging?
<robert_ancell> as is
<duflu> Cool
<robert_ancell> The first build last night seemed to do bad things (TM) but since rebuilding this morning with the switch branch changes it seems to be working better
 * robert_ancell runs a benchmark, be back soon
<duflu> robert_ancell: I don't understand. How is the switch branch optional? It's been merged into the bypass branch for a long time.
<RAOF> Woot! Acceptance test now fails, and for the right reason!
<robert_ancell> duflu, the switch branch isn't optional
<duflu> robert_ancell: Right. Just trying to verify that we're not trying to merge bypass into a slightly old mir branch. Which will succeed, but with stuttuer/freeze bugs
<robert_ancell> duflu, oh, I mean the old package was lp:~vanvugt/mir/bypass rev 927, the one this morning is lp:~vanvugt/mir/bypass rev 930
<robert_ancell> I'm not doing any merging, just debuild from the branch
 * robert_ancell -> more benchmarking
<duflu> robert_ancell: Functionally that should be OK. It's been feature complete without known bugs for at least 7 days
<duflu> I just lost a few days panicking about nouveau and radeon, which turned out are slightly broken but OK in kernel 3.11
<duflu> RAOF: Right, so XMir is an EGL/GLES client with default swap interval?
<RAOF> It's a raw gbm client with default swap interval.
 * duflu wonders if that matters
<RAOF> You keep asking if it's an EGL client, and it keeps not being one :)
<duflu> RAOF: I forget. I also thought you had made changes....
<RAOF> XMir is not going to be an EGL client for the forseeable future.
<duflu> RAOF: Right, but even as a GBM client it never uses buffers outside of the standard swapping semantics, surely?
<RAOF> Correct.
<RAOF> Certainly not before 13.10, and it'll probably keep a not-EGL-client mode indefinitely.
<duflu> RAOF: Yeah, it's only important that it's a hardware surface
<RAOF> And it only interacts with Mir through mir_surface_swap_buffers
 * duflu also wonders if and how X unredirected windows might conflict with bypass
<kgunn> robert_ancell: so when you run phoronix on standalone X (but with xmir bypass "in the system") what kind of fps you get with open arena ?
<duflu> All - If you know how to build lp:mir then please test bypass that way without X first. It sounds like the issue is XMir-specific
<duflu> Although if you're using nouveau/radeon then the drivers have issues too
<kgunn> duflu: do you mean using some libmirclient ? or do you mean build it as the base for my running xmir ?
<duflu> kgunn: I mean native Mir clients. Test without X/XMir first
<duflu> So we can focus on "why is XMir different"?
<duflu> -"?  +?"
<duflu> I'm mostly concerned about intel. Intel should be flawless and if not then there's definitely a bug
<kgunn> duflu: sure...so i'm gonna branch trunk, then merge vanvugt/mir/bypass on top...then build
<kgunn> which mir demo client to run ?
<duflu> kgunn: Needs to be a hardware surface and fullscreen, so eglplasma/egltriangle with: -f
<duflu> And "-n" to test maximum frame rates
<kgunn> ack
<kgunn> RAOF: dare i ask...how are you feeling about xmir multimon ? like...ready to build a ppa? or close ? or days away ?
<duflu> It could also be "what's different about unredirected X windows inside XMir?"
<duflu> RAOF: Unredirected fullscreen windows in Compiz will generate zero damage. I imagine that could be a problem?...
<RAOF> kgunn: Ish
<RAOF> baby annacx!
<kgunn> good greif...i'm hating verizon fios today....kb/s what the hell
<rsalveti> racarr: kgunn: tvoss_: updated bug 1211694
<ubot5> bug 1211694 in Mir "Black screen on Nexus4" [High,Confirmed] https://launchpad.net/bugs/1211694
<duflu> rsalveti: Can you add package details and a Fix Committed to the top?
<rsalveti> duflu: there's no package involved, just part of the android build
<rsalveti> didn't want to add as fix commited because this is actually just a workaround
<rsalveti> let me update the title
<duflu> rsalveti: Maybe also affects "phablet project" whatever that is?
<rsalveti> duflu: I'm not sure this is an android issue, as surface flinger works just fine
<rsalveti> could be something missing in mir itself
<duflu> rsalveti: Yeah fair point. But even a workaround being committed somewhere should show up as Fix Committed to /some/ project
<rsalveti> yup, agreed, but we're not yet using the android package in ubuntu
<rsalveti> which we should hopefully move later this week
<rsalveti> that would have the LP:# link and fix commited
<rsalveti> but I can add a bugtask to our touch-images at least
<rsalveti> so we can have it recorded someshow
<rsalveti> *somehow
<RAOF> duflu: Unredirected fullscreen windows will generate fullscreen damage on SwapBuffers
<rsalveti> duflu: done
<RAOF> kgunn: The read side of xmir multimon works, the write side exposes a bug in mirclient when a client has multiple surfaces, the write side needs alf's surface bind-to-output branch to land before it'll work properly, and I need to work out why the write side doesn't cause Mir to actually change modes.
<RAOF> kgunn: All in all, reasonably close, at least for a first test.
<RAOF> kgunn: PPA-able by my EOD tomorrow would seem like a reasonable prediction.
<duflu> rsalveti: Cool thanks
<duflu> RAOF: Sounds right. you mean on "glXSwapBuffers"?
<RAOF> duflu: Yes, ish. Actually I mean âon DRI2SwapBuffersâ, but that's how the client would call it.
<duflu> RAOF: Sounds good in theory. I need to set up for more practical XMir testing...
<kgunn> rsalveti: thanks for the work...and to me, yes its a workaround & effectively they broke behavioral compatibility
<kgunn> rsalveti: as you say, its a matter of bug fixing when kdub returns to "update" to the new changes from android
<kgunn> we're effectively the client they don't know they have...and don't care :)
<kgunn> they being google
<kgunn> RAOF: that's an exciting prediction (i hope it holds better than other predictions we've been making ;)
<RAOF> âº
 * duflu struggles to remember everything he used to use every day to test compiz
<kgunn> um...sorry for the lag, so branched trunk, merged bypass branch on top...went to build, but fails looking for egl/egl.h ?
<kgunn> ring any bells
<duflu> kgunn: doc/building_source_for_pc.md
<duflu> kgunn: AKA http://unity.ubuntu.com/mir/building_source_for_pc.html
<kgunn> following that....but might've f'd up my system from ealier (like mesa-dev uninstalled...)
<RAOF> Oh, yeah. That's why. The server side of ClientBufferTracker is session-local, rather than surface-local.
<duflu> robert_ancell: I get nothing but /more speed/ from glmark2 using the bypass PPA. It just works. And this is a machine I haven't tested it on before
 * duflu will have to install openarena
<duflu> Fragging for science, once again
<duflu> Annoying and satisfying. OpenArena under bypass works flawlessly
<kgunn> duflu: which ppa ? qa-testing ?
<duflu> kgunn: Yep. Boosts performance in everything for me
<duflu> And that's on a machine I've never tested bypass on
<duflu> Roughly speaking, the bypass PPA puts performance halfway between standard saucy/XMir and legacy X
<duflu> Which is what we expected, pending more optimizations in XMir
<duflu> But in the grand scheme of things, it's unimportant. Native mir clients on a native Mir server are a whole new ballgame
<kgunn> duflu: sure....just wondering aloud, possible diff it works well for you but no one else...got any funky xorg.conf there ?
<kgunn> sorry my simple test taking so long...un-f'ing my machine...
<duflu> kgunn: It's just a thinkpad with saucy I'm testing no customizations
<duflu> Oh, wait. I do have a xorg.conf. Will have to delete that and retest :/
<kgunn> duflu: hmm...considering reimaging my machien
<kgunn> wondering is robert, olli and i were totally clean now...
<kgunn> but gagnon would've definitely been clean on the lexington machines...hmm
<robert_ancell> kgunn, openarena is showing no performance hit on my system and an improvement over XMir without bypass. It just seems to be glmark
<robert_ancell> results in https://code.launchpad.net/~vanvugt/mir/bypass/+merge/181003
<kgunn> robert_ancell: that sounds good
<kgunn> ok..i'm building successfully now...officially un-f'd
<duflu> That's odd. I get a significant improvement in glmark2.
<kgunn> robert_ancell: i'm gonna try qa-testing on this machine...i know its state very well....not sure i completely trust where my 2nd one was when i started...
<robert_ancell> duflu, I'll retest to confirm
<robert_ancell> thomi, do you know what jenkins job is building unity-greeter into ppa:mir-team/staging?
<duflu> robert_ancell: Also remember bypass can only work at your *native* monitor resolution
<robert_ancell> duflu, for XMir you're always at the native resolution right?
<thomi> robert_ancell: I can check, one second
<duflu> robert_ancell: Yeah should be actually
<robert_ancell> brb
<robert_ancell> duflu, yeah, re-running glmark tests doesn't show such a significant change. Though the numbers are all over the place so I don't know how reliable a benchmark it is
<kgunn> robert_ancell: ok...so i'm on qa-testing on my well known machine....glmark2 numbers look insane like 2K fps
<kgunn> openarena....looks pretty sane
<kgunn> haven't compared in detail...but its not crawling at 10fps
<robert_ancell> kgunn, ok, so we're just seeing bad numbers from olli and robotfuel now?
<kgunn> robotfuel never tried the second ppa
<kgunn> unsure about olli
<kgunn> ...altho he had kernel stuff going on
<kgunn> on a side note...i'm seeing some visual artifacts that looks like cache management sync issues
<thomi> robert_ancell: to answer your question, unity-greeter is configured for autolanding, so there's a bunch of jobs that dput to the PPA
<thomi> robert_ancell: not sure why you were asking?
<robert_ancell> thomi, just looking at broken builds and builds for raring
<robert_ancell> thomi, unless there was a particular reason for that it should probably only do saucy builds
<thomi> robert_ancell: hmm, i agree
<duflu> robert_ancell: glmark2 results are very stable. I have used them for long term comparisons over months and now years
<thomi> robert_ancell: I can't see why it would be doing raring builds
 * duflu heads off to lunch
<robert_ancell> thomi, the package is old, I'll just delete the raring one and perhaps nothing will repopulate it
<thomi> robert_ancell: yeah, that would be my guess
<robert_ancell> thomi, the other thing is the saucy version is out of date - so perhaps the autolanding config was removed entirely?
<thomi> robert_ancell: we're still talking about unity-greeter?
<robert_ancell> thomi, yes
<robert_ancell> https://launchpad.net/~mir-team/+archive/staging/+packages
<thomi> robert_ancell: it's still configured, let me check the jenkins jobs
<robert_ancell> because trunk says 13.10.2
<thomi> robert_ancell: in debian/changelog?
<robert_ancell> thomi, yes
<thomi> that's a separate process
<thomi> landing into the PPA is one thing, landing into distro is another
<thomi> debian/changelog only gets updated when you land into distro
<thomi> the last landing into the PPA was on the 13th of aug, and was to land this branch: bzr+ssh://ps-jenkins@bazaar.launchpad.net/~dbarth/unity-greeter/remote-login-only
<robert_ancell> thomi, but it should have been rebuilt once the bzr branch was updated to rev 950
<robert_ancell> staging is rev 941
<thomi> robert_ancell: hmmm, I just noticed this: http://10.97.2.10:8080/job/unity-greeter-autolanding/3/console
<thomi> robert_ancell: does debian/changelog have UNRELEASED perhaps?
<robert_ancell> nope
<thomi> hmmm
<RAOF> Why doesn't C++ do automatic tuple unpacking?
<robert_ancell> thomi, the thing is there's packages like unity-greeter, unity-greeter-session-broadcast, unity-notifications that have nothing to do with Mir in there. They probably should be going to another PPA
<thomi> so both unity-greeter and unity-greeter-session-broadcast are currently configured to land in that PPA
<thomi> if you have a different PPA you'd like to nominate, I can configure that
<robert_ancell> I'd say make a unity-greeter staging PPA
<robert_ancell> I'll do that
<robert_ancell> thomi, redirect them to ppa:unity-greeter-team/staging
<kgunn> duflu: ok...finally...in addition...i tested trunk+bypass native mir, eglplasma demo getting ~70fps
<thomi> ok, will CC you in the email to francis
<robert_ancell> kgunn, is that good?
<kgunn> dunno
<robert_ancell> kgunn, is eglplasma from glmark or phoronix?
<kgunn> mir demo client (full screen, unlocked from vsync)
<kgunn> guess i need a baseline...which means a rebuild...ug
<kgunn> oh...wait...nvmd...its in main, yea!
<robert_ancell> kgunn, why are you rebuilding? Why not use PPA versions?
<kgunn> at duflu 's request
<robert_ancell> kgunn, are you trying a variation on lp:vanvugt/mir/bypass?
<kgunn> just native client vs xmir
<robert_ancell> thomi, one last thing - do you know why/how unity-notifications is getting into the staging PPA?
<robert_ancell> thomi, it also seems out of date
<robert_ancell> I might just delete it and see if anyone makes a noise
<RAOF> Man, how many _Surface_ classes do we have?
<thomi> robert_ancell: it's not configured to autoland there
<thomi> perhaps it once awas
<kgunn> yo dawg i heard you like surfaces
<thomi> *was
<robert_ancell> RAOF, would you like some more?
<robert_ancell> thomi, ok, it's gone now.
 * RAOF is indeed adding one more.
<kgunn> oh the irony
<robert_ancell> thomi, do you want/need the raring and quantal versions of runbench in there?
<thomi> robert_ancell: not any more
<robert_ancell> thomi, gone
<robert_ancell> I'm also going to delete the raring version of glmark
<robert_ancell> hope no-one wanted that
<kgunn> dude raring's dead
<robert_ancell> staging PPA actually looks useful again - latest versions of mir and u-s-c, experimental builds of SDL and runbench
<robert_ancell> you could almost actually use if IF we had a stable ABI between u-s-c and mir
<thomi> robert_ancell: erp, forgot to CC you in, but I've sent those upstream-merger configuration tweaks off to francis
<tvoss_> robert_ancell, kgunn good morning
<robert_ancell> and it's all saucy
<robert_ancell> tvoss_, hello
<thomi> hello tvoss_
<tvoss_> robert_ancell, kgunn so what is the status on bypass?
<kgunn> tvoss_: so it is
<robert_ancell> thomi, ok, cool. I'll just stomp on any packages that end up in the PPA in the meantime :)
<kgunn> tvoss_: can you try ppa:mir-team/qa-testing ?
<kgunn> first we had some bumps...i think i had a dodgey setup
<kgunn> and not sure what robert's story is
<kgunn> both of us seeing good perf now
<kgunn> duflu worked right off the bat
<tvoss_> robert_ancell, what is the qa testing ppa build against?
<kgunn> we missed gagnon before robert rebuilt it
<robert_ancell> tvoss_, it's lp:~vanvugt/mir/bypass + u-s-c trunk
<kgunn> olli has a naff kernel situtation....
<robert_ancell> I rebuilt it with the changes duflu made while I was sleeping
<tvoss_> robert_ancell, kgunn I tested it yesterday on the ati machine with expected results and all being fine
<tvoss_> kgunn, what means a naff kernel situation?
<robert_ancell> I was seeing bad glmark2 numbers, but good phoronix numbers. The glmark2 tests are working now, so I'm not putting too much faith in them being valid
<kgunn> tvoss_: from his conversation with leann ", I am on a x220 and have experienced hard locks when running >3.10.0-6."
<kgunn> so 3.11 is kind of a prob for him..
<tvoss_> kgunn, true but I wouldn't think that that is the actual issue
<tvoss_> robert_ancell, bad numbers in terms of?
<robert_ancell> tvoss_, ftp
<robert_ancell> fps
<robert_ancell> rather
<tvoss_> robert_ancell, I think it's not bypass causing those numbers, glmark2 is slower without bypass, at least for me
<robert_ancell> tvoss_, yeah, that's what duflu was seeing too
<tvoss_> robert_ancell, kgunn so which ppa has the bypass mir and usc now?
<robert_ancell> tvoss_, ppa:mir-team/qa-testing
<kgunn> duflu: just last bit o' data...mir native egl plasma was 50fps w/o bypass...bypass was 70fps...so bueno
<kgunn> which is kinda irrelevant now...but...anyway
<duflu> kgunn, I've come to realize eglplasma is a bad test for /some/ GPUs because the excessive shader calculations often limit the framerate before anything else
<duflu> So best test is: egltriangle -n -f
<duflu> Why am I the only one in the hangout?
<robert_ancell> racarr, tvoss, kgunn, meeting
<robert_ancell> hikiko, meeting
<kgunn> robert_ancell: grabbing a water....
<robert_ancell> kgunn, wasn't actually expecting you to make it!
<tvoss> robert_ancell, kgunn coming
<kgunn> duflu: egltriangle w/o bypass ~173 fps, w/bypass 264 fps
<duflu> Woo
<duflu> 50% increase is better than my best observed benefit of 25% so far
<duflu> Everyone always seems so down when we say goodbye
<duflu> I'm sure there's a song about that
<racarr> duflu: I was thinking the same thing!
<racarr> very somber feeling ending
<alf__> RAOF: MirConnection::validate_user_display_config() is the function I was referring to
<hikiko> I have a completely irrelevant question: where is lexington? I found at about 4 lexingtons...
<duflu> hikiko: Boston
<RAOF> alf__: Ta.
<duflu> (?)
<alf__> hikiko: Lexington, MA
<racarr> Does anyone
<racarr> need help with anything
<racarr> I am pretty aake
<hikiko> :D
<racarr> awake*
<RAOF> :)
<racarr> lol
<duflu> racarr: Go sleep. It's the right time :)
<RAOF> racarr: I'll soon have something for you to review if you want.
<racarr> RAOF: okk we will see if I get tired :)
<robert_ancell> RAOF, You said there were two Mir patches needing to land for XMir+MM right? https://code.launchpad.net/~afrantzis/mir/place-surface-in-output/+merge/181051 and ?
<RAOF> robert_ancell: And this "don't leak fds" branch that I'm just finishing.
<robert_ancell> RAOF, is it pushed yet?
<RAOF> No
<robert_ancell> RAOF, then with git branch of xserver we're done?
<RAOF> And the various drivers, yes. Modulo fixes.
<robert_ancell> RAOF, but the drivers are all in saucy right?
<RAOF> No, not that work with the git branch of xserver.
<duflu> kgunn: You commented in the wrong MP :)
<robert_ancell> RAOF, ah, which drivers?
<kgunn> duflu: oh crap....too many tabs
<robert_ancell> RAOF, I'm thinking I'm going to stuff this up uploading to a PPA... Perhaps you'll have to do it
<RAOF> robert_ancell: The ones that I haven't pushed yet, because I was still testing & ensuring I don't need to break XMir API again ;)
<RAOF> robert_ancell: Yeah, I'm happy to do the push to a PPA.
<duflu> kgunn, robert_ancel: I notice that OpenArena is very erratic with its results. Better to use glmark2
<duflu> robert_ancell ^
<robert_ancell> duflu, the opposite of me!
<RAOF> alf__: I kind of feel like the place-surface-in-output could do with having the last entry of MirSurfaceParameters be a variable-length array of optional attributes. Having every client set the "I don't care where this goes" flag seems smelly.
<duflu> Hmm
<kgunn> duflu: i've noticd the opposite
<duflu> Maybe I need to use a longer timedem
<duflu> +o
<alf__> RAOF: well, ideally the whole surface parameter list would be a variable-lenght array ala EGL
 * duflu votes for that
<duflu> or va_list even
<RAOF> alf__, duflu: Almost. I think it's reasonable to mandate width, height.
<duflu> RAOF: Not when things are resizable later
<duflu> RAOF: Perhaps just buffer_usage
<RAOF> That is truly immutable.
<RAOF> But still, reasonable defaults say "hardware"
<duflu> Oh, actually, resizable means we could vary buffer usage too :)
<duflu> Heh. You /could/ switch between software and hardware rendering between frames once we have buffer resize/reallocation
<robert_ancell> RAOF, ok, you can push XMir+MM changes to ppa:mir-team/qa-testing2. Then we need to merge the bypass stuff into that, then we can copy to ppa:mir-team/system-compositor-testing
<dholbach> good morning
<RAOF> robert_ancell: And that should be the XMir stuff that's actually expected to work, right?
<robert_ancell> RAOF, I think ideally we'd just push in what we have now, then update it when it's ready for testing
<RAOF> Ok.
<robert_ancell> No-one should be pulling from that PPA until we give the signal
<RAOF> Ok. I'll do so shortly.
<alf__> RAOF: if you feel strongly about changing surface params to be a variable-length array now (or perhaps the last element) I have no objections, and I actually prefer it, but no time to do it :/
<duflu> Morning dholbach
<dholbach> hi duflu
<RAOF> alf__: Yeah, FF sucks :)
<duflu> Add it to the list of things we would like to do "next ABI"
<RAOF> alf__: I think I'll see how much effort it is. While we're breaking ABI...
 * robert_ancell hears the ABI floodgates open
 * RAOF dislikes the way mock testing makes tests sensitive to internal details they shouldn't be insensitive to.
<duflu> robert_ancell: If and when we branch, and it's clear which branch we can safely change such things in, it will be easier for everyone
<duflu> RAOF: +1
<robert_ancell> RAOF, +1
<duflu> Mocking is useful definitely, but that's a big disadvantage
<robert_ancell> duflu, branch?
<duflu> robert_ancell: I mean, when we branch Mir for 14.04 then we can break ABIs (for a while)
<alf__> robert_ancell: What's the process for breaking ABI after FF? Is it allowed? More difficult?
<duflu> Or rather, when a maintenance branch for 13.10 slits from lp:mir
<duflu> *splits
<robert_ancell> duflu, well, unfortunately there's not really any good time to break ABI - because each Ubuntu development release is meant to be stable we can't break anything linking against libmirserver
<duflu> robert_ancell: I know. But the goal is to make changes which then lead to fewer changes in future
<RAOF> We can reasonably break A*B*I pretty frequently before feature freeze.
<duflu> "one" goal...
<RAOF> It's more troublesome to break API.
<robert_ancell> RAOF, only because we're carefully rebuilding everything that depends on libmirserver
<robert_ancell> We wont have that luxury forever
<RAOF> Oh, that's because we don't currently ensure libmirserver's ABI *at all*
<RAOF> Once we ensure that *each upload* doesn't change ABI we could pretty happily change ABI once a month or so.
<RAOF> For the first couple of months of Ubuntu development, at least :)
<duflu> Surely we can always make ABI/API changes somewhere. It just might be in a branch that doesn't get released for multiple cycles :/
<robert_ancell> RAOF, oh yes, exactly. As long as we bump the SONAME when we do
<RAOF> Right.
<didrocks> as long as you bump SONAME and handle the transition, no issue from here :)
<robert_ancell> RAOF, so as I see it we can't *break* ABI, but we can *change* ABI.
<RAOF> We can *add* ABI at will, yes.
<robert_ancell> To me breaking ABI means changing it without changing the soname thus potentially breaking all the dependent applications
<RAOF> We could also *break* ABI at reasonable intervals; once a month isn't too excessive. But that is once our SONAME actually means something.
<robert_ancell> I think we have different breaks
<RAOF> robert_ancell: Ah, whereas I'm going from "you increment the SOVERSION each time you break ABI"
<robert_ancell> yep :)
<RAOF> Yeah, you can never break ABI without also changing SONAME
<duflu> tsdgeos: Morning. Nexus4 is fixed, apparently. Or worked around.
<RAOF> s/can never/should never/
<robert_ancell> RAOF, I think you have the correct lingo
<robert_ancell> alf__, does that answer your question?
<robert_ancell> alf__, in short, it's much the same as now, except we need to bump soname if MPs change the interface
<alf__> robert_ancell: ok
<didrocks> and you need to rebuild the rdepends
<mlankhorst> g'morning!
<RAOF> mlankhorst: g'day
<didrocks> (so making a MP bumping the build-dep version normally)
<robert_ancell> alf__, and what didrocks said
<RAOF> But the rebuilding-the-rdepends step is not time-critical.
<didrocks> RAOF: well, it needs to be done in the following hours
<didrocks> RAOF: as Mir is on top of the stack, everything will be blocked in proposed
<didrocks> because Mir won't go from proposed -> release pocket
<didrocks> (as long as all rdepends are not rebuilt)
<RAOF> didrocks: Really? That seems unnecessarily aggressive.
<didrocks> RAOF: it's what britney is forcing us
<didrocks> we don't create NBS package
<didrocks> (which is the package with the previous ABI)
<RAOF> Ah, ok. That's quite agressive :)
<didrocks> RAOF: yeah, basically we don't have anymore libfoo1 and libfoo2
<didrocks> in the release pocket together
<mlankhorst> well mesa 9.2 is ready for testing :P
<didrocks> (apart if we have 2 sources of course)
<mlankhorst> I should probably kill off the xorg-server in the ppa now
<RAOF> didrocks: Including *all* rdepends, such as things in universe?
<RAOF> That's going to get really annoying should things start supporting Mir.
<didrocks> RAOF: yeah, everything in the archive
<didrocks> RAOF: I guess the fundation team got fed up to ping people to help cleaning NBS
<didrocks> at least, for dailies, it's quite easy, we can "force rebuild" some components
<didrocks> it will prepare the changelog
<didrocks> rebuild it
<didrocks> test it and upload it
<didrocks> so it's just some "push button"
<alf__> RAOF: so, I guess having non-API/ABI breaking mechanisms (like the variable parameter list) becomes even more important...
<didrocks> more annoying for things outside dailies, indeed
<didrocks> yeah, padding and so on is useful
<RAOF> alf__: Yeah :)
<didrocks> I guess you all know the KDE C++ ABI handling page :)
<duflu> ?
 * RAOF doesn't
<RAOF> My working assumption is âC++ does not have a stable ABIâ
<didrocks> http://techbase.kde.org/Policies/Binary_Compatibility_Issues_With_C++
<didrocks> there are various links and pages with technics on their wiki
<duflu> didrocks: Oh, I knew the details. Just never seen that page
<didrocks> duflu: it's a good reference, didn't find anything more concise (if you have a link, that would be helpful ;))
<didrocks> ABI in C++ is so easy to break contrary to C
<duflu> didrocks: No, it's all learned from experience, supporting C++ ABIs over many years
<didrocks> duflu: just the way you are telling it make sound painful ;)
<tsdgeos> duflu: yeah saw that, going to flash the phone now and see if it hit the reease yet
<duflu> tsdgeos: Not sure what image if any has the fix yet
<didrocks> fix in Mir?
<duflu> -fix +workaround
<duflu> didrocks: No workaround/fix to the phablet image
<tsdgeos> didrocks: in the android side
<didrocks> ah ok
<tsdgeos> duflu: nothing is lost by trying :D
<didrocks> kgunn: come on!
<didrocks> robert_ancell: kgunn: first run on ati -> fail :/
<didrocks> Mirv: FYI ^
<didrocks> Mirv: deprovisionning ati as wellâ¦
<didrocks> let's freeze the state of this fdfdsoifdsjfs machine
<duflu> mlankhorst: I have noticed with nouveau (and radeon) that flooding one GL client starves others. This is a big problem when "others" includes the display server. Are you aware of such problems?
<mlankhorst> duflu: sync to vblank helps :-)
<duflu> mlankhorst: Yes it certainly does help. But many people run benchmarks without sync
<mlankhorst> and a bit of frame throttling
<duflu> In fact, sleep(10ms) helps too
<duflu> mlankhorst: Just seems like nouveau and radeon might have very conservative locking
<duflu> Which limits concurrency
<mlankhorst> duflu: well benchmarks are weird, card just wants to execute things as fast as possible and has set up some time slices, but it cannot context switch during execution
<duflu> Oh. I didn't think about the GPU being a platform with its own timeslices
<didrocks> tvoss_: around?
<tvoss_> didrocks, ack
<duflu> mlankhorst: Not sure how intel avoids such things. Strategic yields?
<mlankhorst> usually command buffers are all about setting up state and then firing it off by flipping the switch. during the execution of  that switch it cannot switch, and it tries to be 'fair', but if there are no other commands running most of the time it will just dedicate itself entirely to that single command stream :P
<mlankhorst> duflu: single command buffer I guess
 * duflu didn't think to try std::this_thread::yield() when testing GPUs
<mlankhorst> there's some stuff not figured out, it might be possible to give certain command buffers higher priority but that requires an abi change
<RAOF> mlankhorst: Not thinking of writing a deadline scheduler for nouveau? :)
<duflu> mlankhorst: Is process priority used?
<mlankhorst> duflu: nah it's dark magic :P
<duflu> Excellent
<mlankhorst> Not sure how it works tbh
<Mirv> ouch :(
<mlankhorst> there's a lot of nvidia hw not understood yet
<mlankhorst> but as kepler support has shown  you don't really need to for rendering basic 3d :P
<mlankhorst> (3d support was working before 2d was)
 * robert_ancell -> EOD
<duflu> Dear Nvidia: Where are your docs?
<tvoss_> duflu, RAOF mlankhorst need your help
<duflu> tvoss_?
<RAOF> What's up?
<mlankhorst> nah lol
<duflu> mlankhorst: Surely life would be less exciting if it was as simple as being documented
<mlankhorst> I don't even think there is a per fifo time slice adjustment
<mlankhorst> besides bypass will support a lot of issues
<duflu> mlankhorst: I will try inserting some strategic yield calls next time I'm playing with nouveau or radeon. Since I found success with sleeping a few millisec
<duflu> tvoss_: On it now, in fact
<tvoss_> duflu, we have unity not starting with compiz trying to load the core plugin
<tvoss_> didrocks, ^
<didrocks> the first run stuck on opengl though
<duflu> tvoss_: "core" is not a real plugin. "core" is unity's main really. It can't fail to load
<duflu> Sorry, "core" is compiz's main
<alan_g> hikiko: how's it coming along?
<duflu> RAOF: drm_auth_magic... is that called repeatedly or only once?
<hikiko> hi alan_g
<hikiko> I just started :) didn't do much, I was arranging my trip, no problems yet :)
<duflu> hikiko: At least I *hope* it's the one near Boston :)
<alan_g> hikiko: as you're not in deep yet could you review https://code.launchpad.net/~alan-griffiths/mir/a-surface-for-each-output/+merge/181095?
<alan_g> alf__: @place-surface-in-output do you want to react to ra's comment, or shall I top-approve?
<alan_g> duflu: +1
<hikiko> sure alan_g! (pulling)
<duflu> RAOF: Never mind. Logs answered that question
<alf__> alan_g: looking
<duflu> ping RAOF
<duflu> alf__, do you have any understanding of xmir_auth_drm_magic ?
<alf__> duflu: some
<alf__> duflu: oh, do you mean the specific xmir implementation?
<duflu> alf__: I mean the context in which it is called, not the Mir implementation
<duflu> alf__: Is it called for multiple screens/threads?
<duflu> Because it looks like it... and also the client API looks unsafe to use in such a way
<alf__> duflu: I don't know the context details, sorry
<duflu> alf__, Can you explain the high-level purpose for me?
<alf__> duflu: It is a mechanism to allow clients to perform some privileged DRM operations (to authenticate them).
<duflu> alf__, OK thanks. Any idea which project/branch calls the function? I can't find it yet
<duflu> alf__, Nevermind. Found it in the hardware-specific xorg drivers
 * RAOF spots the blatantly obvious logic error in his patch.
<RAOF> duflu: Pong.
<RAOF> duflu: X is resolutely single-threaded.
<duflu> RAOF: Hmm, I'm suspicious of the reuse/concurrency of xmir_auth_drm_magic. Is it once per screen/monitor/GPU?
<RAOF> duflu: There *is* some SIGIO madness possible, but that will never cause DRI2Authenticate, which is the only place that calls xmir_auth_drm_magic, to be reentrant.
<RAOF> We call xmir_auth_drm_magic once per client DRI2Authenticate request.
<alf__> duflu: (for some background: the idea is that the client asks DRM for a magic cookie with drmGetMagic(), and then sends it to the DRM master, which marks it as authenticated with drmAuthMagic(). After this, the client is considered authenticated by DRM and can perform some privileged ops.)
<duflu> RAOF: I mean MirConnection::drm_auth_magic() looks very un-threadsafe. And we seem to be requiring that multiple calls to it work in close succession
<RAOF> duflu: But never twice at once, because we mir_wait_for() it.
<duflu> RAOF: OK, so in theory only one thread
<RAOF> The only threads in the X server are the ones libmirclient imposes.
<RAOF> And xmir proxies all of those callbacks to the X mainloop, via the madness of xmir_thread_proxy.
<smspillaz> RAOF: this design pattern feels very ... familiar
 * smspillaz looks at GdkMirEventListener
<smspillaz> yep, familiar
<smspillaz> just dealing with the pain that is the gmain.c
<RAOF> Yeah, we should totally have a generic to-event-loop-fd handler.
<smspillaz> RAOF: I think what there really needs to be is some kind of kernel system call that can listener on fds and pthread conditions at the same time
<smspillaz> kevents doesn't count
<smspillaz> wakeup pipes are just ... awkward
<alan_g> alf__: Quick Q: as  client I request a change to the display config...when the change succeeds do I get a change notification?
<katie> tvoss_, or anyone else, I'm writing up the bit about focus stealing, and want to know how Mir handles the focus queue.. is there still an idea of a focus queue?
<katie> tvoss_, mpt has another idea, of a  probably-opening-a-window flag
<tvoss_> katie, haven't heard of that before
<katie> the example is slow opening attachments in  Thunderbird
<katie> tvoss_, the attachment can request to be focussed, but if it takes a long time, and the user focusses something else, the attachment can't steal focus
<RAOF> katie: That was roughly equivalent to desrt's âYou hand out an obfuscated timestamp on startâ idea, right? I remember mpt and him being in violent agreement in Bluefin.
<katie> RAOF, yes, that was the discussion
<RAOF> We should totally get desrt to implement that. 'Twas a good idea.
<katie> RAOF, have you heard any discussion since?
<RAOF> katie: No
<RAOF> That's likely to be the shell's purview. Although maybe it should be ours.
<tvoss_> katie, RAOF I think we need something on two levels
<tvoss_> katie, will have lunch, with you after that
<katie> tvoss_, ok :)
<duflu> RAOF: Is it normal to xmir_auth_drm_magic multiple times per Screen?
<RAOF> Yes.
<RAOF> duflu: It will be called each time a client calls DRI2Authenticate, which every GL client will call at startup.
<alf__> alan_g: sorry, missed the ping... no because you change only your session's config as things are now. You only receive events for hardware changes.
<tvoss|lunch> RAOF, duflu ping
<duflu> tvoss|lunch: pong
<tvoss_> duflu, RAOF I'm pretty sure the issue arises from the radeon kernel module giving up after some time
<tvoss_> duflu, RAOF at least on the daily release machine
<duflu> tvoss_: Sounds like it. But I don't know why that would make the Mir socket code suddenly fail; message goes in one end and never received at the other
<alan_g> alf__: thanks (the answer was quick enough - I haven't started on that bit yet)
<tvoss_> duflu, are we really sure that the message goes in? I'm unsure that that is the case
<tvoss_> duflu, plus: didrocks and me have seen some weird behavior for waitpid as well
<tvoss_> duflu, which hints towards a deeper issue somewhere
<duflu> tvoss_: Yes, line 65: http://paste.ubuntu.com/5981035/
<duflu> tvoss_: waitpid?!
<tvoss_> duflu, not related to mir, but when compiz is started
<tvoss_> duflu, that only indicates that the request is sent @pastebin
<duflu> tvoss_: Oh, yes, I gave didrocks a fix for that.
<didrocks> duflu: a fix?
<didrocks> duflu: you mean the unity_support_test?
<didrocks> (to remove from compiz)
<duflu> didrocks: Yes, externalizing the script
<didrocks> duflu: already done for 2 weeks
<didrocks> duflu: as pinged you back, didn't change a thing
<duflu> didrocks: Cool
<didrocks> so not what tvoss_ saw
<duflu> didrocks: But that should also involve removing any waitpid call from compiz
<didrocks> just told, the code which stuck on waitpid didn't invoke unity_support_test as we don't have the call anymore
<duflu> tvoss_: didrocks says the waitpid call does not exist any more... ?
<didrocks> duflu: I did say that we saw a waitpid
<didrocks> but it's not on unity_support_test
<duflu> Oh. Strange
<didrocks> as this code is removed
<tvoss_> duflu, yeah, I think we are seeing symptoms of the kernel being in a weird state ... cannot prove that, though
<duflu> I think it will take me some days yet to understand the Mir socket code. And it's not definitely clear that's the problem.... I'm debugging from heresay still
<tvoss_> duflu, I really don't think we have a problem there
<tvoss_> anyway, let's just make sure we keep releasing
<duflu> OK, I'm out of ideas. The mind is fried and the stomach empty. Till next time...
<RAOF> If anyone is in the mood for a review, https://code.launchpad.net/~raof/mir/fix-multi-surface-buffer-tracking/+merge/181259
<alan_g> RAOF: alf__ - I've a couple of MPs depending on place-surface-in-output - are you still discussing changes? Or can we land it?
<alf__> alan_g: RAOF: I am OK with it landing as is and changing the API again in a future MP (hopefully before the freeze).
<alan_g> alf__: RAOF - then I'll top approve
<smspillaz> hmm
<smspillaz> mir seems to be sending mir_surface_hover_leave and mir_surface_hover_enter whenver a button is pressed or released respectively
<smspillaz> is that a bug or a feature?
<smspillaz> sending such events confuses gtk
<smspillaz> (which think that the pointer is no longer over the surface once a button is pressed)
<smspillaz> but we have to track enter and leave event to figure out which surface the pointer actually *is* over
<smspillaz> s/leave/exit/
<alan_g> smspillaz: that sounds like a bug - but I'm surprised that RAOF hasn't come across it.
<kgunn> tvoss_: you've got to be kidding... :-|
<tvoss_> kgunn, why is that?
<kgunn> tvoss_: ati back...
<tvoss_> kgunn, well, didrocks and me have been looking into it for hours, it turns out rebooting the physical machine fixes it. I'm still inclined to push it towards the driver/kernel as we were seeing a massive slow-down even for vanilla x
<didrocks> kgunn: look at the emails on ue-leads
<kgunn> tvoss_: is that vanilla x (meaning w/o u-s-c ever being installed once ?)
<kgunn> tvoss_: ack...will get coffee and read mail
<tvoss_> kgunn, yeah, all good, so have a coffee
<kgunn> ;)
 * kgunn won't really understand anything until he has coffee
<hikiko> alan_g: ping
<alan_g> hikiko: how's it coming along?
<hikiko> well, I have some issuesd
<hikiko> I started from create_buffer_allocator which is the exception called right now
<alan_g> yes?
<hikiko> but it seems that I have to do more than this because atm if I run nested mir
<hikiko> I
<hikiko> "grab"
<hikiko> the drm device
<hikiko> and then even if I kill all mir instances
<hikiko> I can't switch tty, go to X etc
<hikiko> I can only reboot using ssh
<hikiko> I guess I have to do some trick at the drm initialization but I am still looking at it
<hikiko> if you have any ideas...
<alan_g> hikiko: what did you do in the original spike?
<hikiko> you mean the very first branch?
<alan_g> I mean lp:~hikiko/mir/mir.nested-gbm
<hikiko> I didn't have that problem there
<hikiko> because the nested platform
<katie_> hi tvoss_
<alan_g> hikiko: are there not two issues? drm and keyboard input?
<hikiko> wasn't dependant of the native gbm platform, it was implementing the Platform and it was just using the gbm buffers instead of the mir buffers
<hikiko> I don't know alan_g
<hikiko> I don't know how to debug actually because I don't have a tty, what do you do in a similar case?
<hikiko> maybe I have to start gdb on a screen
<hikiko> and grab it when I ssh
<hikiko> resume*
<alan_g> hikiko: you can stop the nested Mir grabbing input with "--enable-input off" (like it does in the test)
<alan_g> That should avoid problems with VT switching
<alan_g> I don't know what's needed for drm
<tvoss_> didrocks, got a daily-realease question fo ryou
<hikiko> I'll try alan_g thanks
<didrocks> tvoss_: sure
<tvoss_> didrocks, let's assume the platform api links in something like boost, then the symbols are picked up by the dh machinery, but I don't want to expose them ... what is the default approach?
<didrocks> tvoss_: it's more a gcc question in fact :) normally the boost symbols are not exposed but your API
<didrocks> you don't leak them, right?
<tvoss_> didrocks, nope, but they show up when compiling the package
<alan_g> hikiko: why are you trying to run a nested mir and not using the test framework?
<didrocks> tvoss_: do you use -fvisibility=hidden?
<tvoss_> didrocks, nope
<tvoss_> could do that ...
<didrocks> tvoss_: there was a good gcc wiki page, hold on
<didrocks> tvoss_: here is it: http://gcc.gnu.org/wiki/Visibility
<hikiko> alan_g: --enable-input off didn't help
<tvoss_> didrocks, I know -fvisibility,will tackle in then in lp:~thomas-voss/platform-api/location-service
<didrocks> great :)
<hikiko> but ok I'll find something :)
<alan_g> hikiko: The current "nested" code doesn't do anything with drm does it? This is something you're adding?
<smspillaz> alan_g: tvoss_: know where I'd go to find the code responsible for sending button down events ?
<tvoss_> smspillaz, with you in a few ...
<tvoss_> smspillaz, you interested in the actual handover to clients?
<smspillaz> tvoss_: just where button down events are generated in the server
<smspillaz> I imagine that's probably where the problem I'm having lies
<hikiko> alan_g: I think it does
<smspillaz> tvoss_: context: the server sends surface_hover_enter and surface_hover_leave on button up / down events which tends to confuse gtk+ a lot
<smspillaz> (because it thinks the pointer is no longer in the surface at the time of the button event)
<tvoss_> smspillaz, let me have a look
<smspillaz> cheers
<smspillaz> I'll keep poking around too, though I've not found anything yet
<tvoss_> cheers katie :)
<hikiko> alan_g: http://bazaar.launchpad.net/~hikiko/mir/mir.create-buffer-allocator/revision/990
<hikiko> here is what I did
<hikiko> to have it working
<hikiko> so now it initializes the drm/gbm in the gbmplatform constructor
<hikiko> what I can do is to pass an option in case we are nested and change <something I don't know yet> to not grab the devic
<hikiko> e
<alan_g> hikiko: This is code you've added. The current code doesn't do anything with drm.
<alan_g> By including GBMPlatform in NativeGBMPlatform you're trying to be the host system
<smspillaz> tvoss_: ah, I think the problem is in the android input stack
<smspillaz> tvoss_: hover_enter/hover_exit doesn't really map completely to the traditional X11 EnterNotify/LeaveNotify
<tvoss_> smspillaz, that might well be, it is the entity doing the actuall processing
<smspillaz> the latter is to do with the cursor position, the former is probably to do with the touch "clicking" state
<tvoss_> smspillaz, ah, got it: so hover_leave on button click actually makes sense
<alan_g> hikiko: I don't think you should be implementing NativeGBMPlatform using GBMPlatform
<smspillaz> tvoss_: except not for gtk+ ;-)
<tvoss_> smspillaz, as it actually leaves hovering state when clicking the button ...
<hikiko> alan_g: the problem is that I cant use the enable_shared_from_this otherwise
<hikiko> I have to either inherit Platform
<hikiko> or GBMPlatform
<smspillaz> tvoss_: are mouse events handled like touch events at the moment ?
<tvoss_> smspillaz, hmmm ... let me think ... so what you want is. hover_enter and then button_clicked?
<tvoss_> smspillaz, I'm pretty sure, yes
<smspillaz> tvoss_: no, what I need is something similar to X11's EnterNotify/LeaveNotify
<tvoss_> smspillaz, we run qt with a special "translate touch to mouse events"
<alan_g> enable_shared_from_this is evil - why would you want to use it?
<smspillaz> which is generated whenever a cursor enters and leaves a surface (geometrically)
<hikiko> because we have it in every create_buffer_allocator so I guessed that it does some sort of magic we need :)
<hikiko> do you think I should remove it alan_g ?
<tvoss_> smspillaz, okay ... so you don't receive these events right now? or what is the actual problem? sorry, if I missed the description :/
<smspillaz> tvoss_: so at the moment in gtk+ I'm treating hover_enter/hover_exit as if it had exactly the same semantics as EnterNotify/LeaveNotify
<smspillaz> eg, whenever some "input device" is hovering over a surface (in this case, the cursor)
<alan_g> hikiko: Well, I've not looked in detail at that code - so it might be useful.
<smspillaz> gtk+ uses that to determine which window the pointer is currently in side of
<smspillaz> *inside of
<smspillaz> on button press mir does something like
<smspillaz> hover_exit -> button_down -> button_up -> hover_enter
<smspillaz> which confuses gtk+ because by the time it gets button_down it thinks there is no longer a cursor in the surface
<smspillaz> (arguably, this is something stupid about gtk+ and I had to work around it in compiz too for a different reason)
<tvoss_> smspillaz, okay, so I think it is actually correct to send hover_exit in case of a button click ... as it really indicates that the hover state ended ;)
<hikiko> alan_g: no prob I ll try a few tricks and tell yu if I made any progress at the meeting
<alan_g> But, even if it is needed, I don't see why you'd use the GBMPlatform implementation. As I said yesterday, copy the code you need from there and we can refactor later.
<tvoss_> smspillaz, for a work-around: why not ignore hover_exit?
<smspillaz> tvoss_: I can't
<smspillaz> tvoss_: gtk+ needs that in order to determine when a cursor is no longer inside a surface
<smspillaz> well ... I'll revise that statement. Maybe I can just ignore hover_exit. But I'm not so sure what it'll break subtly
<alan_g> hikiko: this is what kills your VT switching: 216    auto vt = std::make_shared<mgg::LinuxVirtualTerminal>(real_fops, options->get("vt", 0), report);
<tvoss_> smspillaz, hmm, I'm thinking, that means you only want to pass on LeaveNotify to gtk iff hover_exit has happened and a subsequent event is not button clicked, right?
<hikiko> alan_g: then I need to have the Platform
<smspillaz> tvoss_: yes (although implementing it like that would be very clunky)
<tvoss_> smspillaz, agreed
<smspillaz> tvoss_: what I really need is for the server to send me something like EnterNotify and LeaveNotify, and only when the actual cursor itself goes into and out of a surface (geometrically)
<alan_g> hikiko: only because GBMBufferAllocator isn't quite as you need it
<smspillaz> tvoss_: though I think the broader problem here is that pointer input and touch input are amalgamated into a "motion" concept and it doesn't really work all that well
<smspillaz> (which was probably inherented from android)
<alan_g> hikiko: AFAICS all it really needs is a GBMDevice - but it takes a std::shared_ptr<GBMPlatform> to have access to it
<hikiko> then I have to do it exactly like in the first spike (there wasnt vt etc there)
<hikiko> but in that case
<hikiko> I still need to have a public Platform
<alan_g> hikiko: Could you check that GBMBufferAllocator doesn't really need the GBMPlatform? And if I'm right MP a change that just gives it the device?
<alan_g> Why do you need a public Platform?
<hikiko> it doesnt
<hikiko> alan_g: only to use enable_shared_from_this
<hikiko> if we don't need it
<hikiko> then I don
<hikiko> t need the platform
<alan_g> hikiko: If you can first change GBMBufferAllocator to just take the device then the rest becomes easy.
<tvoss_> smspillaz, I have put it on the list
<hikiko> that shouldn't be difficult alan_g I ll try
<alan_g> hikiko: If GBMBufferAllocator doesn't really need the GBMPlatform MP a change that just gives it the device.
<smspillaz> tvoss_: cheers :)
<hikiko> alan_g it doesn't I didn't use the GBMPlatform in my first branch
<hikiko> so, I will try it
<alan_g> hikiko: :)
<ricmm> tvoss_:
<tvoss_> ricmm, ?
<ricmm> alan_g: greyback
<ricmm> we believe there is a problem with commit 982, it breaks some behaviour we were using before
<ricmm> two issues:
<ricmm> 1. the_input_configurator() is called many times in the_surface_stack_model() before we hold a ref to it in displayServer
<ricmm> this results in many objects, and a wrong input initialization later due to that
<hikiko> bye people :)
<ricmm> http://paste.ubuntu.com/6008216/ sorts that issue, with help from racarr
<ricmm> 2. client apps stopped working in our shell after 982, the we were failing to create a eglSurfaceWindow on the nativeWindow returned by mir
<ricmm> moving the_graphics_platform() around shows breakage in the creation of native windows, makes me think we are perhaps hitting a similar thing as with the input configurator? spurious instantiations
<ricmm> and therefore different objects used to create other configs, in contrast with the one stored in the DisplayServer itself
<ricmm> we create stuff in this order in unity-mir http://paste.ubuntu.com/6010579/
<ricmm> both the stack() and the builder() poke into the_graphics_platform() before it has been stored in the DisplayServer, perhaps theres a hole there somewhere
<ricmm> ok thats it :) ping me when you are around
<alan_g> ricmm: looking...
<alan_g> ricmm: OK, so the problem stems from your ShellServerConfiguration holding state for itself rather than reacting as a builder for DisplayServer. Which means that it relies on the DefaultServerConfiguration holding state.
<alan_g> And -c 982 broke that assumption
<ricmm> so, not hold refs to anything but instead dynamically return out objects in the overriden methods?
<ricmm> our*
<ricmm> alan_g: maybe this is right for the_graphics_platform(), but is it also right for the_surface_stack_model()? the spurious objects are only valid within the lambda's context
<ricmm> it happens even if I dont manually call into it
<ricmm> so perhaps that one does need to hold an internal ref to *one* the_input_configuration()
<alan_g> ricmm: If that makes sense in the rest of your code. Otherwise, you could hold your own std::shared_ptr<input::InputConfiguration> input_configuration;
<greyback> alan_g: in order to use Qt signal/slot mechanism,  the receiver needs a pointer to the object emitting the signal. I don't see how I can get that through this design
<alan_g> The way DefaultServerConfiguration works is that it keeps a weak pointer to objects it constructs - so if anyone is holding them the same one is returned
<alan_g> But if no-one holds it then it can be destoyed.
<alan_g> greyback: I understand that you need to control object lifetime - it is just that DefaultServerConfiguration shouldn't have been doing that.
<ricmm> alan_g: so a quick solution would be to store std::shared_ptr<> for the_graphics_platform()
<alan_g> I'd guess that the minimal fix would be to have a std::shared_ptr<input::InputConfiguration> input_configuration; member in ShellServerConfiguration and initialize it first. But that would extend its life beyond that of the server object (which can also cause problems).
<ricmm> and that should ensure consistency in the ones returned across all config and then in the DisplayServer builder
<ricmm> right, for the input_config I was using the ref internal to the_input_configuration() lambda
<ricmm> but it should be the same result
<alan_g> Oops I meant virtual std::shared_ptr<graphics::Platform>  graphics_platform;
<alan_g> ricmm: yeah, but that one goes out of scope - so if nothing holds it...
<ricmm> true, but for some reason it works
<ricmm> I'll try holding both objects
<ricmm> how dangerous is it to hold these beyond the lifetime of the DisplayServer object?
<ricmm> I dont think we do any direct access to them
<ricmm> only during construction of the config, so should be fine
<ricmm> will use the config methods to get the objects anyways, not really our refs
<ricmm> greyback: sounds good for a try?
<alan_g> ricmm: I was finding problems when an exception was propagated from the DisplayServer constructor.
<greyback> alan_g: so objects constructed by DefaultServerConfiguration can be destroyed at any time. Can those objects be created & destroyed repeatedly?
<greyback> ricmm: should do yes.
<ricmm> I think they wont be destroyed *before* the DisplayServer's life ends
<ricmm> as long as we hold the refs
<alan_g> greyback: What should be happening is they exist for as long as the DisplayServer is using them
<ricmm> after, I dont know. but we dont really need any direct access on input_config and graphics_plat
<ricmm> I think the question here is does the DisplayServer exist until the compositor/server process dies?
<alan_g> But before -c 982 the input_configuration was held on the configuration object instead
<greyback> ricmm: exactly my question
<alan_g> When the DisplayServer is destroyed everything should be closed down
<alan_g> (But you could write a program that then created a new one)
<tsdgeos> ricmm: when you have a minute i have a question regarding how/where to wrap url-dispatcher in platform api. I'll be eod'ing soon though, so maybe you prefer me to send an email?
<ricmm> alan_g: sounds good enough for a normal shell
<ricmm> tsdgeos: please send an email, sorry if I'm unresponsive
<ricmm> really busy
<tsdgeos> ricmm: ok, will do
<ricmm> thanks
<tsdgeos> ricmm: also commented on your unity-mir MR
<tsdgeos> ricmm: there's a few nitpicks you are free to ignore, but the singleshot signal seemed a bit dangerous
<tsdgeos> s/signal/timer
<alan_g> ricmm: have you got what you need? (For now)
<ricmm> looks like, we'll do a test and let you know
<ricmm> alan_g: thanks for the help
<alan_g> sorry for breaking your code
<smspillaz> does mir have an inbuilt screenshot functionality?
<smspillaz> eg, a keybinding to dump an image to the disk?
<greyback> smspillaz: it has API for screenshotting, not tied into anything tho
<smspillaz> lol
<olli> kgunn, alan_g do you guys know if the fix for input showing up on VTs has hit trunk yet? (iirc it's the switch branch)
<olli> tvoss_, ^
<alan_g> olli: the switch branch has landed. Do you have a bug id?
<olli> alan_g, xubuntu is just curious if it's in archive yet
<olli> alan_g, is that part of the 0.0.9+13.10.20130821-0ubuntu1 release from today
<racarr> Morning
<alan_g> olli: switch was in -c 948 - today's release was 989. But I don't know if it has anything to do with input on VTs
<olli> alan_g, ok, so maybe I am wrong
<olli> let me rephrase
<olli> do we still see input on VTs in todays release or is that fixed meanwhile
<alan_g> olli: I can't find the bug you mean, I don't know if it is fixed
<olli> alan_g, ok, don't have a bug id
<olli> was one of the prominent ones... where a password entered in U7 would show up in clear text on VT
<olli> password and other text
<kgunn> olli: i saw it 100% before...i think it got fixed early last week...let me test (after our meeting :)
<racarr> I think the same thing but don't have time to test at this exact instantg
<forestpiskie> olli: this is what I'm seeing - not that bug http://imgur.com/cPAmyNC,irF8k6K,DCfJ9j0#0
<forestpiskie> olli - forestpiskie is elfy
<olli> forestpiskie, ack
<olli> kgunn, tvoss_^
<racarr> So what's going on with n4?
<racarr> olli: Do you still need someone to test this VT input thing?
<olli> racarr, no
<racarr> Oh :p
<racarr> well I did anyway it's totally fixed
<robert_ancell> racarr, Just waiting on duflu for https://code.launchpad.net/~robertcarr/mir/client-focus-notifications/+merge/180903?
<robert_ancell> I asked alf yesterday, so if he hasn't said anything to you I think we take him as abstain
<racarr> robert_ancell: He is only listed as pending because
<racarr> he reviewed it like a month ago
<racarr> and it was resubmitted
<racarr> ...4 times
<robert_ancell> racarr, do you know if duflu has any remaining concerns? Otherwise you should just land it
<racarr> robert_ancell: I don't know.
<racarr> I think there are some things he doesn't like which range from "unclear to adress" to "likely to lead to more needs fixing from Alan" :p
<racarr> robert_ancell: I'm landing it :p
<thomi> robert_ancell: the upstream-merger changes you requested were deployed earlier today, just FYI
<robert_ancell> thomi, awesome, thanks
<robert_ancell> thomi, I notice there's a u-s-c raring build from 47 mins ago - was that change missed or did it happen just after that build?
<robert_ancell> https://launchpad.net/~mir-team/+archive/staging
<thomi> robert_ancell: that shouldn't have happenbed, WTF is going on !?
<thomi> robert_ancell: ahhhh, I see
<thomi> it's landing from a totally different stack
<thomi> I'll talk to Francis about that now
<thomi> robert_ancell: we still want it built, but just for saucy, right?
<robert_ancell> thomi, yes
<thomi> robert_ancell: ok, config change made: https://code.launchpad.net/~thomir/cupstream2distro-config/u-s-c-saucy/+merge/181420
<robert_ancell> thomi, thanks!
<thomi> any time
<robert_ancell> racarr, did you notice the autolanding failed for the client focus notification branch?
<thomi> robert_ancell: change deployed, shouldn't get any more darn raring builds
<robert_ancell> RAOF, are you still working on that fd MP for mir?
<RAOF> robert_ancell: Yeah; looks like it failed jenkins.
<robert_ancell> RAOF, which branch?  lp:~raof/mir/fix-multi-surface-buffer-tracking?
<RAOF> robert_ancell: Yeah, that one.
#ubuntu-mir 2013-08-22
<bschaefer> RAOF, hey, soo since I can use gdb on mir server, i've compiled it my self and found where its failing (but I need to dig some more)
<bschaefer>    bo->map = mmap(0, bo->size, PROT_WRITE, MAP_SHARED, dri->base.base.fd, map_arg.offset);
<bschaefer> its returning a MAP_FAILED
<bschaefer> in the function: create_dumb
<RAOF> Huh.
<bschaefer> RAOF, umm for this problem:
 * bschaefer finds pastebin
<bschaefer> RAOF, http://paste.ubuntu.com/6008137/
<bschaefer> when it tries to create the cursor, and its failing to get a gbm buffer
<RAOF> Yeah.
<RAOF> That's just an odd thing to have fail.
<bschaefer> oo, I thought you were confused on what i was pinging you about :)
<bschaefer> RAOF, it takes a while to recompile, but im just about to check the params that are being sent in
<bschaefer> then ill dig through what that functions does, and where its failing there...
 * bschaefer gets the errno
<bschaefer> RAOF, hmm errno is saying invalid argument
<bschaefer> which could be my fault in reporting the error...
<RAOF> So, your choice of "length was 0" or "addr, length, or offset looked at us funny'
<bschaefer> the bo.size  ~= 16k
 * bschaefer needs to print out the offset
<bschaefer> and the fd was 9? Which seems reasonable to me
<RAOF> Yeah, that's a reasonable number.
<bschaefer> soo I suppose it has to be the offset... as the void* addr is just 0, length seems reasonable, prot/flags/fd all seem reasonable...
<bschaefer> time to recompile ...
<bschaefer> hmm the length is perfect: 64 * 64 * 4 for the cursor, unless the addr needs to be something besides 0
 * bschaefer waits patiently for the results of the offset...
 * robert_ancell -> lunch
<bschaefer> RAOF, hmm the offset seems a bit large: 765247488
 * bschaefer isn't sure what the expect offset would look like
<RAOF> Hm. It's ~700Mb
<bschaefer> which its getting it from drmIoctl...soo the kernel is giving a large offset?
<duflu> Joy. My N4 seems to be completely dead. Not charging, not powering on.
<bschaefer> duflu, it'll work as a nice paper weight now!
<duflu> Not heavy enough... which is related to its running out of charge issues all the time :)
<bschaefer> haha, well thats no fun!
 * bschaefer was printing off_t with a %i ... opps
<kgunn> duflu: is your n4 back in service ?...curious....
<kgunn> i just flashed the "pending" image + latest mir ppa....and ui comes up
<duflu> kgunn: Not yet. Also OTP
<kgunn> only when i touch it....screen blanks not a reboot...ui comes back
<kgunn> racarr: ^ in case you're on....
<kgunn> looking for a victim to try it too...
<robert_ancell> RAOF, how is lp:~raof/mir/fix-multi-surface-buffer-tracking going?
<RAOF> need to fix it for android
<bschaefer> RAOF, I don't want to poke you much more, but the real offset i get is: 9,637,617,664
<bschaefer> soo ill take a look more tomorrow to see if I can figure out what the expected offset would be
<bschaefer> and figure out why my ATI machine wants to do this, and not others
<RAOF> That seems excessive, so is probably wrong :)
<bschaefer> 6580879360, 9725997056, hmm should it be changing?
<bschaefer> cool, well I also tried the default value for offset = 0, but its still MAP_FAILED...soo more to look into tomorrow :)
<RAOF> Ta
<bschaefer> np! Its fun digging this low...well im off for the night
<duflu> robert_ancell: Hangout? Skype?
<robert_ancell> duflu, hangout is best
<robert_ancell> duflu, https://code.launchpad.net/~raof/mir/fix-multi-surface-buffer-tracking/+merge/181259
<RAOF> Yeah, android is silly. :/
<robert_ancell> RAOF, actually, we can test this without waiting for android right?
<RAOF> Oh, sure. I could push to the testing PPA.
<robert_ancell> RAOF, I'll do take that and the bypass and push to the PPA
<RAOF> Aces
<duflu> robert_ancell: Just merging trunk into bypass now. In a sec
<duflu> And done
<robert_ancell> RAOF, are the drivers the last major component?
<RAOF> Yes
<robert_ancell> Mir is building... will test once ready
<robert_ancell> kgunn, did you just create the mir-testing list?
<RAOF> Grah. Why is xorg hanging in its (minimal) test suite?
<robert_ancell> olli, or you?
<olli> robert_ancell, that was me
<olli> I'll send some more information in a sec
<robert_ancell> olli, did you mean for the list password to go to mircosmonauts?
<olli> robert_ancell, wow, how did I do that?
<robert_ancell> also, making more mailing lists is just bad practise, what was wrong with mir-devel?
<robert_ancell> it's blocked in the queue so I can delete it if you don't need it
<olli> robert_ancell, I meant to subscribe microscosmonauts
<olli> but not fwd the passwd
<olli> robert_ancell, in some ppls mind, there is value in separating -devel type of information and -testing information
<olli> and I think we have more important things to do to argue with "some ppl"
<robert_ancell> *sigh*
<olli> the more important q is... how is the PPA looking, will we soon have something to actually post to -testing
<robert_ancell> olli, mir just finished building, still building X drivers
<olli> whoa
<olli> with MM & bypass and everything?
<robert_ancell> RAOF,  Is xserver-xorg-video-intel the only driver required for MM or are there also ati/nouveau versions?
<robert_ancell> olli, yes, but UNTESTED
<olli> robert_ancell, :)
<RAOF> robert_ancell: ati & nouveau versions are coming.
<olli> robert_ancell, cool, I'll stick around for a bit, happy to lend a hand if I can
<RAOF> robert_ancell: Pending xorg-server finishing its build.
<robert_ancell> RAOF, you saw the intel build failure right?
<RAOF> Yeah.
<RAOF> Should probably put an appropriate versioned build-dep on it :)
<olli> RAOF, do I need a recent kernel for recent mir to work? or will my 3.10.0-6 work?
<olli> mir/usc that is
<RAOF> Intel should work. duflu found that radeon and nouveau wanted some of the dma-buf patches that are in 3.11
<olli> RAOF, good thing I am on intel ;)
<olli> cool
<olli> I am going to move kgunn's test cases to a wiki, can you guys ping me when the PPA is done building?
<robert_ancell> olli, yep
<robert_ancell> RAOF, how long does an X build take on average?
<RAOF> Depends on whether or not the xvfb-run test hangs or not :/
<robert_ancell> RAOF, xorg failes amd64 :(
<RAOF> Yeah, I've just cancelled it.
 * robert_ancell heading out to get pick up daughter, be back afterwards
<RAOF> Trying another xmir build, updated for what's in the archive.
<olli> RAOF, will the libmirserver1 -> 2 rename bite us?
<olli> oops
<olli> libmirclient1 -> 2
<RAOF> olli: No; we'll be building against libmirclient2 anyway.
<olli> k
<RAOF> Good. All the drivers are in the PPA, waiting for xserver to build.
 * duflu goes to lunch and to send the N4 to LG service :(
 * Mirv sees grey borders instead of black borders!
<Mirv> I'm using my external monitor which has slightly higher resolution than my laptop. there used to be black borders at the bottom and right, now after the upgrades that went into saucy they are grey. I see progress! :)
<Mirv> it's been rock-solid for 1.5 weeks now other than the fact that no real multimonitor support exists (yet)
<Mirv> only the "XMIR mode of death"
<duflu> Mirv: Yes grey is the new default fill colour to show where the shell/XMir is failing to paint
 * duflu really goes to lunch now
<robert_ancell> RAOF, anything I can do to help the xorg-server package build?
<RAOF> I just needed to be less trusting of the docs.
<tvoss_> good morning :)
<tvoss_> RAOF, can I trick you into your voip lair?
<RAOF> tvoss_: Sure.
<tvoss_> cool, let me grab coffee
<olli> RAOF, still building
<olli> ?
<didrocks> oh a olli around :)
<olli> didrocks, of course
<RAOF> olli: I'm just being confused by our documentation lying to me. Should build soon :)
<didrocks> olli: seems we continue having fun with the QA machines this week (I think you saw the thread on intel and kernel panic)
<robert_ancell> thomi, did we end up running the stress test on those 9 machines?
<olli> didrocks, ah
<olli> I have a panic myself on intel
<thomi> robert_ancell: yes, and it fails on radeon machines
<olli> on the latest kernel
<thomi> robert_ancell: which is interesting (my testing laptop is radeon as well)
<robert_ancell> thomi, but passes on intel?
<olli> didrocks, w/ & w/o xmir though
<thomi> robert_ancell: I think so - Chris said is "mostly failed on radeon machines", but that's a rather imprecise statement
<didrocks> olli: yeah, I don't think this one is linked to xmir, just to newer kernel. (we can't blame robert_ancell and kgunn for everything yet :p)
<olli> _yet_
<didrocks> ;)
<didrocks> olli: I didn't get any kernel panic (rebooting just once a day on my x220), you have the same machine, right?
<thomi> robert_ancell: what's curious is that I'm not actually rendering anything in the stress tests yet - although it does allocate surfaces, which I guess must touch the graphics driver
<olli> didrocks, https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1214931
<ubot5> Launchpad bug 1214931 in linux (Ubuntu) "kernel oops in free_task" [High,In progress]
<thomi> but I freely admit I have no idea how that stuff works
 * didrocks looks at our logs and compare
<thomi> robert_ancell: so the question is: does racarr have a radeon chipset handy?
 * RAOF does
<robert_ancell> thomi, don't know
<robert_ancell> thomi, duflu was also looking into the issue
<robert_ancell> thomi, because it sounds similar to didrocks ATI issue
<thomi> ok
<didrocks> olli: no, the machine is stuck for us on  [drm:i915_hangcheck_elapsed] *ERROR* stuck on render ring
<robert_ancell> ok, heading off for dinner and baths and things. Will be back later
<RAOF> Ok. You guys, this time it's totally going to work :/
<olli> heh
<olli> was just about to ask
 * olli is getting sleepy
<tvoss_> RAOF, how many rebuilds? :)
<RAOF> I think this is the fourth?
<RAOF> But this time it built locally, because I managed to figure out what part of my sbuild config was wrong and confusing me.
<RAOF> tvoss_: Did you want the VoIP lair to remain inhabited?
<tvoss_> RAOF, indeed, found coffee, now happy to talk
<olli> smspillaz, I have this urge to hug you... however as this would be awkward I will just say you rock
<olli> RAOF, how is the PPA doing? I am about 10min from bed, worth waiting?
<RAOF> olli: The drivers should be in the process of building; just gave them a prod. I'm going to reboot and test with it soon
 * tvoss_ is not afraid and hugs smspillaz 
<tvoss_> didrocks, ping
<didrocks> tvoss_: pong
<tvoss_> didrocks, need your help with symbols in lp:~thomas-voss/platform-api/location-service
<tvoss_> didrocks, can you try building the package and advice me on the symbols suddenly being reported as added
<tvoss_> didrocks, I tried -fvisibility=hidden and that does not help
<didrocks> tvoss_: later today, I really need to deliver the system update first
<tvoss_> didrocks, ack
<didrocks> (and barry's mock is buggy, so making it more painful :/)
<olli> RAOF, robert_ancell, I will head out - good luck with the PPA. Pls ping everybody and tvoss about it, he will then coordinate further testing once we have validated it
<olli> appreciate your work there guys
<olli> it's so close...
<RAOF> Oh, wow. Commits to the xwayland branch of xf86-video-intel!
<olli> RAOF, URL?
<RAOF> http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/log/?h=xwayland
<olli> thx
<duflu> Why are the boost docs as incomprehensible as boost itself? Docs should be readable somehow... :(
<RAOF> Yeah, the boost docs appear to be almost deliberately useless.
 * RAOF starts the bathing cycle.
 * duflu assumes all this talk of bathing involves children and people are not just sharing too much about themselves
<tvoss_> Saviq, ping
<dholbach> good morning
<Saviq> tvoss_, pong
<robert_ancell> anyone tried the PPA yet? Just installing now
<tvoss_> RAOF, robert_ancell is the ppa finished, yet?
<robert_ancell> Everything is built except for ati it seems
<robert_ancell> Luckily I'm intel here
<tvoss_> robert_ancell, so which ppa should I be looking at? qa-testing?
<robert_ancell> tvoss_, yes
<robert_ancell> https://launchpad.net/~mir-team/+archive/qa-testing/+packages
<tvoss_> robert_ancell, okay, need to pin that ppa then
<tvoss_> robert_ancell, do we have instructions for the testers to do that?
<robert_ancell> tvoss_, olli has some
<tvoss_> robert_ancell, olli's instructions point to system-compositor-testing
<robert_ancell> tvoss_, right, we copy the packages there when we're ready for public testing
<robert_ancell> tvoss_, we don't want partially built packages in that PPA
<tvoss_> robert_ancell, okay
<robert_ancell> hmm, that didn't work. XMir crash
<robert_ancell> http://paste.ubuntu.com/6013192/
<robert_ancell> RAOF, ^
<alan_g> hikiko: is it going any better this morning?
<hikiko> hi alan_g yes I started some changes
<hikiko> added a second constructor in GBMBufferAllocator that doesn't take the platform
<hikiko> +now I am trying to modify the rest functions to be platform independent
<hikiko> I ll add the changes to the branch and MP if it works
<alan_g> hikiko: why not just change the constructor and existing call site? (And MP that on its own)
<hikiko> sure alan_g I can do this as a first step
<hikiko> I ll push in a while
<tvoss> robert_ancell, RAOF so the testing ppa is not working for me, I only see mir's grey background, here the greeter jingle, but don't see it
<robert_ancell> tvoss, same here - I get an X crash http://paste.ubuntu.com/6013192/
<robert_ancell> tvoss, can you confirm the same thing in your logs?
<arsson> i use synaptic and that ppa want's to remove u-s-c
<tvoss> robert_ancell, yup
<robert_ancell> arsson, it probably wants to downgrade it, not remove it?
<arsson> well it talk about removing
<duflu> alan_g: Can you explain the rationale for having a side channel in the protocol, and how we ensure synchronization (or don't need it)?
<robert_ancell> arsson, try apt-get from the command line
<arsson> ok
<alan_g> duflu: AFAIK we don't ensure synchronization
<duflu> alan_g: OK, I assume we don't /need/ it then. But still, why isn't everything in the same protocol?
<duflu> Or same "channel"
<alan_g> duflu: As I remember the discussion "this is what android does; it is simpler (for some value of simpler); and we can't say it doesn't work"
<duflu> alan_g: OK. I guess kdub will know, if I don't figure it out in the next few weeks
<alan_g> duflu: you and I both discussed this with tvoss at length back in the London sprint
<tvoss> duflu, we have had that conversation before: having input events separate from control messages prevents one blocking the other
<arsson> do i need to upgrade or dist-upgrade?
<duflu> tvoss: No, nothing to do with input, AFAIK
<tvoss> duflu, well, the side-channel transports input events as far as I can tell
<duflu> tvoss: OK, I couldn't tell. It's a bit difficult to decipher. Just doesn't look anything like it's related to input because it's used on all sorts of non-input-related protocol messages
<duflu> tvoss: Also, just because I've argued for a particular design does not mean I've ever had to look at the related code as yet :)
<arsson> robert_ancell: from command line it's still wants to remove u-s-c
<tvoss> duflu, :) now that statement is a great one ;)
<tvoss> RAOF, any other information we can provide to you?
<mpt> tvoss, hi, in 15 minutes or so katie and I will start peppering you with questions to finalize the surface management spec. :-)
<tvoss> mpt, sure
<duflu> tvoss: I don't understand. Design and implementation are different things. We talk at a high level about features we've never seen the code for all the time...
<tvoss> duflu, fully agreed, I actually found your statement to be quite true :)
<dholbach> hi guys
<dholbach> so I just added the ppa:mir-team/system-compositor-testing ppa, but an update/dist-upgrade doesn't give me anything new to play with?
<Mirv> dholbach: that's because it's empty, and unity-system-compositor is in saucy
<dholbach> aha
<Mirv> just not in the default install
<Mirv> I've been running it now for 1.5 weeks
<robert_ancell> arsson, can you paste the log?
<dholbach> yeah, me too - I just thought I'd get something new to play with ;-)
<dholbach> thanks Mirv
<arsson> robert_ancell: form where to where?
<robert_ancell> arsson, the apt output to paste.ubuntu.com or similar
<robert_ancell> you can use pastebinit to make it easier
<arsson> robert_ancell: it's finnish http://paste.ubuntu.com/6013304/
<robert_ancell> arsson, hm, what PPAs are you using? Are they pinned?
<arsson> robert_ancell: this https://launchpad.net/~mir-team/+archive/qa-testing
<duflu> robert_ancell: You said mir_stress can cause bugs... How? I haven't reproduced any yet
<duflu> greyback: If the grey background is intrusive, I can undo it while we don't have seemless startup... ?
<duflu> Heh "grey back"
<greyback> duflu: hello :)
<duflu> *seamless
<duflu> Hi greyback
<greyback> duflu: I can see it's use on desktop tho. Hence the idea to make it configurable
<duflu> greyback: It's a debugging tool to tell you where to fix your shell. Unfortunately it's a little too "loud" right now
<robert_ancell> duflu, just running it used to trigger it after a few seconds for me and thomi
<robert_ancell> duflu, but it seems to be less likely now so perhaps you're not getting it
<duflu> robert_ancell: Seems?
<robert_ancell> arsson, do you have a pin in /etc/apt/preferences.d?
<robert_ancell> duflu, according to robotfuel who ran it on  the 9 machines
<duflu> robert_ancell: OK, I'll ask thomi tomorrow
<robert_ancell> thomi said he was still getting it, I haven't tried it in a while
<arsson> robert_ancell: no. how to do that?
<greyback> duflu: yep exactly. Useful. So if it was configurable, I wouldn't mind.
<duflu> greyback: I think that hinges on the shell getting some composting hooks to override. While that's cool and exciting, it might not happen soon though
<robert_ancell> arsson, ok, you need to pin using https://help.ubuntu.com/community/PinningHowto otherwise you'll get a mix of archive and PPA packages depending on which has the higher version number
<duflu> *compositing not composting :)
<arsson> robert_ancell: thanks!
<robert_ancell> arsson, however I recommend waiting until ppa:mir-team/system-compositor-testing is populated and there are instructions for that. ppa:mir-team/qa-testing is currently a work in progress and is broken
<greyback> duflu: lol
<greyback> I see
<duflu> composting hooks, less useful
<duflu> Especially at 60Hz
<robert_ancell> arsson, if you do use those instructions I found that Pin-Priority of 400 wasn't high enough for some reason and I used 1002 instead
<hikiko> alan_g, https://code.launchpad.net/~hikiko/mir/mir.create_buffer_allocator/+merge/181502 could you please review it when you have some time?
<alan_g> hikiko: sure. And https://code.launchpad.net/~alan-griffiths/mir/another-interation-over-NestedDisplay/+merge/181263 could you please review it when you have some time?
<hikiko> sure :) I'll do this right away actually
<robert_ancell> RAOF, this new driver might fix the crash I saw?
<tvoss> robert_ancell, I tried MM3
<robert_ancell> tvoss, 2+MM1 is building right now
<robert_ancell> Or fully: 2:2.21.14-4ubuntu2+xmirMM1
<robert_ancell> Ever feel like our version numbering has got out of control?
<robert_ancell> 8 levels of numbering... mmmmm
<robert_ancell> epoch:major.minor.patch-debian_ubuntu+feature_ppa
<tvoss> \o/
<tvoss> dear ppa-builder: faster
<robert_ancell> it's the dreaded slow publishing stage
<robert_ancell> well, the nice thing about slow builds is you can clear your inbox
<katie> tvoss, hello
<tvoss> katie, hey there
<katie> tvoss, mpt and I are just discussing your email and focus stealing
<tvoss> katie, shoot :)
<tvoss> katie, can I quickly restart?
<katie> tvoss, sure
<tvoss> RAOF, no luck with the new intel driver in the ppa
<tvoss> RAOF, still the same exception
<tvoss> katie, ping
<tvoss> RAOF, wouldn't the xserver need upgrade, too? especially for xserver-xorg-xmir?
<katie> tvoss, hi, just drawing some diagrams.. i'll come back to you with a question
<katie> :)
<tvoss> katie, sure :)
<robert_ancell> tvoss, are you getting no crash but just a gray screen now?
<tvoss> robert_ancell, had that before, yeah
<robert_ancell> tvoss, so you didn't have the crash?
<tvoss> robert_ancell, no, although I think X was not coming up, I have always seen the grey Mir background
<robert_ancell> tvoss, oh, I was getting the gray and a crash
<robert_ancell> Now I just get gray, but the greeter is definitely there so it looks like X not rendering
<tvoss> robert_ancell, well, I hear the greeter being started, at least the jingle :)
<robert_ancell> tvoss, for some reason orca randomly turned on, so I could hear when I scrolled
<robert_ancell> tvoss, you could also see authentication attempts in lightdm.log
<tvoss> robert_ancell, and I see an exception from mir in the Xorg log saying that the surface coulnd't be associated to the output
<robert_ancell> tvoss, I had that when X crashed, but I don't get that now
<robert_ancell> RAOF, around?
<duflu> robert_ancell: Do you mind if I log off or is there something you need immediate help with?
<robert_ancell> duflu, I don't think there is anything more we can do at the moment. Not sure if RAOF is coming back online. I need to log off to. Good night!
<duflu> robert_ancell: 'night
<robert_ancell> tvoss, do you know of anyone in the European timezone who can help out with XMir?
<tvoss> robert_ancell, not really, mlankhorst perhaps
<tvoss> robert_ancell, which version of mir is in the ppa?
<tvoss> robert_ancell, I do see a libmirclient2 library? what if x and xmir are not linked against that?
<robert_ancell> tvoss, lp:mir+lp:~vanvugt/mir/bypass+lp:~raof/mir/fix-multi-surface-buffer-tracking
<robert_ancell> tvoss, everything is correctly linked against libmirclient2
<mlankhorst> erm what about xmir?
<tvoss> mlankhorst, do you have a machine with an intel gpu around?
<tvoss> robert_ancell, did you try it with a local build?
<robert_ancell> tvoss, nope
<tvoss> robert_ancell, will do that now
<tvoss> mlankhorst, if so, can oyu give ppa:mir-team/qa-staging a spin?
<mlankhorst> enough intel, mostly SNB though :P
<mlankhorst> sec let me try
<katie> tvoss, another question for you
<tvoss> mlankhorst, cool, thanks
<tvoss> mlankhorst, expect an error
<tvoss> katie, shoot
<tvoss> katie, can I ask you to setup a meeting with greyback, you, Saviq and me tomorrow morning?
<katie> tvoss, is the bottom toolbar (on the phone) just another surface that the app can render to? treated in the same way as the titlebar
<katie> tvoss, i'm not in tomorrow
<mlankhorst> tvoss: invalid ppa?
<robert_ancell> tvoss, I'm EOD here. I've emailed an update - can you read over it and check if there's anything else I might have missed
<tvoss> robert_ancell, reading right now
<mlankhorst> there's qa-testing, qa-testing2 and staging, but no qa-staging..
<tvoss> mlankhorst, ppa:mir-team/qa-testing
<tvoss> my bad
<katie> tvoss, I'm back next week tuesday
<tvoss> katie, ack, Monday then
<katie> :)
<tvoss> katie, Tuesday then, or today
<tvoss> katie, @bottom toolbar: not a surface, but an sdk component
<katie> ok
<katie> ta
<Saviq> tvoss, I'm out starting Saturday
<Saviq> katie, â
<Saviq> tvoss, so if I'm essential, today is the only day
<robert_ancell> bye all
<katie> tvoss, so today .. is half an hour enough?
<Saviq> robert_ancell, g'night
<alan_g> bye robert_ancell
<tvoss> robert_ancell, bye
<tvoss> Saviq, you are going onto vacation?
<Saviq> tvoss, onto, yes ;) back to work Sep 9th
<katie> tvoss, what's the meeting about?
<tvoss> Saviq, wtf? who approved that? ;)
<tvoss> katie, you updating the guys on wm :)
<katie> is 30 mins enough?
<katie> i think so
<Saviq> tvoss, I have a sucker of a manager
<tvoss> katie, awesome, thank you
<kgunn> Saviq: he is a sucker for sure
<Saviq> kgunn, ;)
<tvoss> kgunn, hey there
<kgunn> tvoss: hey so...safe to try the ppa ?
<tvoss> kgunn, nope, not working
<kgunn> :(
<mlankhorst> tvoss: meh fails to install unity-system-compositor
<tvoss> mlankhorst, can you pastebin the error message? please note that the archive has a more recent version of it
<tvoss> mlankhorst, you should specify the exact version
<mlankhorst> hmz :/
<mlankhorst> interesting failures
<mlankhorst> (EE) [xmir] Failed to create surface for 1440x900 mode: /build/buildd/mir-0.0.9+13.10.20130821.1/src/server/shell/graphics_display_layout.cpp(91): Throw in function virtual void mir::shell::GraphicsDisplayLayout::place_in_output(mir::graphics::DisplayConfigurationOutputId, mir::geometry::Rectangle&)
<mlankhorst> Dynamic exception type: boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<std::runtime_error> >
<mlankhorst> std::exception::what: Failed to place surface in requested output
<mlankhorst> (WW) intel(0): failed to restore desired modes on VT switch
<tvoss> mlankhorst, yup, will do a restart, hold on
<mlankhorst> ..?
<tvoss> back again :)
<tvoss> mlankhorst, sorry, quick reboot
<mlankhorst> but you did get the error right?
<tvoss> mlankhorst, yeah
<tvoss> mlankhorst, I do see the same error
<mlankhorst> testing complete then :p
<tvoss> mlankhorst, indeed
<RAOF> Sorry, fell asleep while putting ZoÃ« to sleep
<tvoss> RAOF, no worries :)
 * alan_g wishes we'd made the mir "toolkit" API easily mockable.
<tvoss> RAOF, so we see an exception in X.org.log with the qa-testing ppa
<RAOF> tvoss: Right, I see the backscroll.
<tvoss> RAOF, let me know how I can help tracking this down
<RAOF> I see the same exception, but curiously only when X is started by lightdm
<RAOF> tvoss: I've got a build of XMir going that'll print some debug information about what it's trying to do.
<tvoss> RAOF, ack, I'm trying mir with multi-monitor and wihtout bypass now
<kgunn> RAOF: likewise...if you need me to try something i'm here
<tvoss> RAOF, same issue with your branch
<RAOF> tvoss: Try again with xorg-server - 2:1.14.2.901-2ubuntu3+xmirMM3 (once it's finished building)
<tvoss> RAOF, ack
<tvoss> RAOF, what is the underlying issue?
<RAOF> The crash appears to be me failing to handle failure properly at some point.
<kgunn> that's a double failure :)
<RAOF> The underlying issue appears to be that mirclient refuses to place the second surface.
<tvoss> RAOF, happens with only one surface, too
<RAOF> I'm going to go to sleep; I don't think I'll be particularly productive now.
<tvoss> RAOF, ack
<RAOF> xmirMM3 doesn't fail with one surface for me. Except sometimes when lightdm start X, and I don't know what that's about.
<RAOF> I'll pick this up in the morning.
<tvoss> RAOF, ack, good night :)
<mlankhorst> hm back to piglit testing then
<tvoss> mlankhorst, ack
<tvoss_> okay, ppa starts on one monitor as confirmed by rao, but mm not working
<tvoss_> kgunn, ^
<kgunn> tvoss|lunch: ack
<smartboyhw> Is http://www.phoronix.com/scan.php?page=news_item&px=MTQ0MjA fixed?
<tvoss|lunch> smartboyhw, infrastructure and fix ligned up here: https://code.launchpad.net/~robertcarr/mir/client-focus-notifications
<smartboyhw> tvoss|lunch, thank you:)
<tvoss|lunch> smartboyhw, quite a big change and as it is so crucial, we have given it extra attention and reviews
<smartboyhw> tvoss|lunch, :)
 * olli now has a phoronix.com account
<olli> kgunn, tvoss|lunch ^
<tvoss|lunch> olli, :)
<kgunn> tvoss|lunch: finally caught up...so you get "failed to place surface in requested output" ?
<tvoss|lunch> kgunn, not anymore with the most recent changes to the ppa
<tvoss|lunch> kgunn, but when connecting a monitor
<olli> on that post: it's good to see how people actually start to stand up for mir can call post like that BS
<kgunn> tvoss|lunch: ok...so fully verified i'm on the current ppa....made sure i had no logs prior...boot to unity single screen fine
<kgunn> but i am definitely getting "failed to place surface in requested output"
<kgunn> xmir failed to create surface...
<kgunn> RAOF: ^
<tvoss|lunch> olli, +1
<mamenyaka> hello! is there a mali specialist here?
<om26er_> How do I check if my phone is running mir from terminal ?
<ogra_> ps ax| grep -q surfaceflinger && echo "i'm not running Mir !"
<ogra_> or some such :)
<om26er_> ogra_, bash: !": event not found :p
<om26er_> on the other side I am not running running Mir it seems
<ogra_> oh, wow, seems i suck at quoting
<ogra_> (bash dislikes exclamation marks in strings)
<kgunn> racarr: ping
<racarr> kgunn: pong
<kgunn> racarr: hey dude...so...i know you've been working on dpms
<kgunn> curious....were you spending any time on stress test ?
<kgunn> (got brot up y'day with thomi/robertA)
<racarr> kgunn: Very little
<racarr> probably tomorrow
<kgunn> racarr: thanks...i know...everyone's got plenty to do...just curious
<kgunn> btw....do the screens come back on now ? :)
<kgunn> racarr: ^
<racarr> kgunn: ...no :(
<racarr> kgunn: Im trying to save the environment
<sam113101> how do IÂ know for sure I'm running mir?
<TheDrums> sam113101: ps ax | grep unity-sys    and see what pulls up.
<sam113101> only the grep itself, crap
<sam113101> what did IÂ do wrong
<TheDrums> You follow http://unity.ubuntu.com/mir/installing_prebuilt_on_pc.html ?
<sam113101> yup
<sam113101> and IÂ restarted the computer (well, it's in a VM)
<kgunn> sam113101: ...as TheDrums says those instructions are good....but i do the poor man...after boot, just run top
<kgunn> if you see unity-system-comp in there...then your good
<kgunn> good=running mir
<TheDrums> Xmir doesn't work in a vm, sam113101.
<kgunn> if ur grep is crap
<kgunn> sam113101: are you trying vm for fear of screwing your machine ?
<kgunn> sam113101: just wanted to say...if for some reason you don't like xmir, then apt-get remove unity-system-compositor will put you back on standalone X
<sam113101> kgunn: no, IÂ just don't want to use saucy
<sam113101> TheDrums: why?
<TheDrums> (I'm not part of the team/canonical, just a useless minion.)
<sam113101> where did you hear that, though?
<kgunn> sam113101: it is a known bug https://bugs.launchpad.net/mir/+bug/1157196
<ubot5> Launchpad bug 1157196 in Mir "Mir does not work in vmware virtual machine due to drm open failure" [Medium,Triaged]
<kgunn> on our balance sheet of todo's
<thomi> morning
<kgunn> there's actually some interesing reading there
<kgunn> mornin thomi
<thomi> o/
<TheDrums> sam113101: If you don't want to run saucy, you can download a daily and install xmir onto it (restarting lightdm) or try the Xubuntu xmir testing ISO.
<xnox> how is the progress on non-mirrored dual screen setup?
<xnox> can I start testing / using it?
<TheDrums> xnox: They're working on getting it in the system-compositor-testing ppa, but having a couple problems.
<sam113101> TheDrums: "xubuntu xmir testing ISO", where can IÂ find it?
<TheDrums> It's not an official build, but http://vanir.unit193.tk/mir/
<sam113101> well
<sam113101> that was sluggish
<racarr> robert_ancell: Want to do our 1~1 in 1 hour?Back now but am expecting someone to show up and interrupt for 10 minutes (I have their burning man ticket) at any minute now
<robert_ancell> racarr, sure
<robert_ancell> RAOF, hey
<RAOF> Yo
<robert_ancell> RAOF, anything I can do to test the multi-monitor stuff?
<RAOF> robert_ancell: I'm adding yet more debug output to see why the surface for the second head doesn't get placed correctly. Once I've given that a whirl, I'll know more about where the problem is.
<RAOF> Aha. Fails to bind the surface on the second output because the second output has the wrong display mode.
#ubuntu-mir 2013-08-23
<RAOF> Hm. Dear Mir: I'm *pretty* sure that I don't want to drive my external panel at 23.91Hz.
<kgunn> :))
<RAOF> Sweet. That seems to work.
 * robert_ancell -> lunch
<RAOF> robert_ancell: Please test xorg-server_1.14.2.901-2ubuntu3+xmirMM4 once it's built; that works for me.
<robert_ancell> RAOF, will do
<duflu> robert_ancell: Is it still qa-testing to use?
<robert_ancell> duflu, yes
<duflu> RAOF: Is there a tool for visually tweaking colour profiles?
<RAOF> duflu: Not to my knowledge.
<RAOF> Also worth noting that u-s-c won't apply any colour profile you might set, anyway.
<duflu> RAOF: Yeah, wasn't for any test machine. Was just wondering in general.
<duflu> RAOF: Is it possible to go above D65? I found profiles from Lenovo which claim to, but provided no visual change (not using Mir)
<RAOF> duflu: As the target colour temperature? Sure.
 * RAOF 's old CRT had two colour temperature presets: 6500K & 9000K
<duflu> RAOF: Yeah, this particular display just seems to not change anything for the Lenovo profiles which claim to be higher
<RAOF> Possibly it's not actually a display-correction capable profile?
<RAOF> Stupid bloody flaky xvfb-run test!
<duflu> RAOF: Fair point. Copied from Windows drivers...
<RAOF> duflu, robert_ancell: amd64 packages have built in qa-testing, but you'll need to force install them as the i386 build that produces xserver-common has hung again.
<robert_ancell> RAOF, yeah, watching that
<olli> RAOF, is there something worth giving a shot?
<robert_ancell> RAOF, did you just restart i386?
<olli> or are you still building the xorg-server
<RAOF> robert_ancell: I did indeed.
<RAOF> olli: Yeah, this works for meÂ¹
<RAOF> Â¹: Although I wasn't testing against a unity-system-compositor with multi-surface leak fix, so X rapidly became useless.
<olli> RAOF, ok, I am about ready for bath & bedtime duty
<olli> but will check back in ~1.5h
<olli> exciting
<RAOF> Everything should have built by then :)
<kgunn> robert_ancell: RAOF ....so can't download amd64 until i386 finished either
<robert_ancell> kgunn, you can, but you have to do it manually
<robert_ancell> it's not published until both are built
<robert_ancell> kgunn, i.e. click on each .deb and install them that way
<RAOF> No, it's published, but apt will refuse to install it (as there's a strict dependency on xserver-common, which is only built by the i386 build)
<kgunn> RAOF: right...that's what i experienced
<kgunn> and there is no xserver-common yet
<kgunn> scary...i am smart enough that i actually checked cache policy on boot...saw mm3 was installed, but mm4 was candidate
<robert_ancell> RAOF, ah, that's annoying...
<kgunn> tried to manually install then saw the complaining about common
<robert_ancell> we really should build 'any ' packages on amd64 now
<RAOF> kgunn: So, just downloading xserver-xorg-core, xserver-xorg-xmir .debs and dpkg --install --force-depends will work.
<RAOF> Â¹: Should âº
<kgunn> RAOF: mmmm...thanks...i'll just wait...would hate a false negative
<kgunn> so curious...has anyone had any success with lttng on arm ?
<kgunn> its installed and i can query kernel hooks...
<kgunn> and i can create a log for mir..but it immediately throws an error for every command after that
<robert_ancell> i386 built...
<robert_ancell> and published!
<RAOF> Hah. Seems like bypass might have broken it.
<ricmm> kgunn: hey, still around?
<kgunn> ricmm: yes
<kgunn> RAOF: please tell me that's your crazy aussie humor :-/
<kgunn> robert_ancell: RAOF ...i booted into X it seems
<RAOF> kgunn: Well, on my dual-head test it âworksâ, but u-s-c only updates the display when I VT switch to it.
 * RAOF is building the multi-surface fix branch minus bypass to see if that's a fix.
<kgunn> hmmm....wait a minute...u-s-c not installed?
<kgunn> oh...that's weird...updates on vt switch
<robert_ancell> RAOF, the X package seems to have built against the system mir, not the one in the PPA - is that because the PPA is now behind the archive?
<robert_ancell> Do PPAs not pin to themselves?
<RAOF> robert_ancell: No, they do not.
<robert_ancell> damn
<kgunn> right....
<robert_ancell> I'll update Mir, and we'll have to rebuild before main updates...
<robert_ancell> kgunn, that  was blocking me from installing u-s-c - you probably have the same issue
<kgunn> wait...so instead of waiting...i could try the --force-depends method right ??
<RAOF> Oh, *that's* why it's broken!
<robert_ancell> kgunn, maybe? It will still have built against the wrong Mir and without a stable ABI that's very dangerous
<RAOF> Oh, actually, no, that's not it.
<kgunn> robert_ancell used the word dangerous...i think i'll wait
<RAOF> kgunn, robert_ancell: We *have* a stable ABI for mirclient, so it's harmless.
<kgunn> dang it...i'm really running out of energy...
<RAOF> We don't need to build XMir against the exact mir version.
<robert_ancell> RAOF, oh, true. It just has a depends with a higher number than the one provided
<robert_ancell> RAOF, what version of u-s-c are you running? The -cft one?
<RAOF> yes
<robert_ancell> So once we recompile Mir, we wont have to recompile X
<RAOF> Oh, no. Sorry. Not using cft
<RAOF> bah
<robert_ancell> new mir uploaded...
<kgunn> dude...how do we change the script to rid the i386 run for the time we're iterating
<robert_ancell> I'm just asking the launchpad guys...
<robert_ancell> previous builds indicate this will take ~45 mins
<robert_ancell> Apparently that's the time to build all of android :)
 * duflu wonders why apt-get upgrade wants to remove USC and xmir
<robert_ancell> duflu, because it's built against libmirclient2 from the archive which is greater than the PPA version
<robert_ancell> StevenK confirms it - i386 is hardcoded to be the "any" architecture so you can't drop it from a PPA
<robert_ancell> duflu, we're rebuilding mir now..
 * duflu now wonders why i915 is stuck around 90 wakeups/sec when compiz is less around 15
<RAOF> The base-rate for i915 is going to be ~60Hz when there's been some form of activity.
<duflu> And my fan/temperature is quite bad... This is with Mir though
<duflu> *This is without Mir
<duflu> RAOF: AFAIK, Intel will still clock down to 40Hz when it can
<duflu> ... Just that you can't configure 40Hz modes any more. Is that intentional?
<RAOF> duflu: Really? What monitors support a 40Hz refresh rate *and* support seamlessly changing between 40Hz and 60Hz?
<duflu> RAOF: I haven't seen a physical 40Hz for a few years (Dell E4200 could do it). But the number of wakeups for i915 still drops to 40Hz when it can
<RAOF> It *should* drop to 0 under conditions of no-load, but whenever output has occurred it'll pop back up to $REFRESH_RATE Hz as the vblank interrupts keep coming.
<duflu> I remember that used to be a *feature* of Intel graphics, dynamically switching between 40/60Hz and Ubuntu did it no problem. Maybe intel dropped it in more recent chips
<RAOF> Deliberately missing every third vsync?
<duflu> RAOF: Something like that. Showed up as a mode you could fix in xrandr too
<duflu> It appears i915 staying at 90 wakeups/sec is side-effect of multiple monitors. User processes are behaving though
<RAOF> Oh, yeah. It'll be vsync interrupts.
<robert_ancell> duflu, you got revision 1000!
<duflu> Woo, I win, nothing
<duflu> Weird, i915 seems to scale in multiples of 40/45 wakeups per second.
<olli> is there anything to test
<olli> RAOF, robert_ancell?
<robert_ancell> olli, in progress..
<olli> oki
<robert_ancell> olli, just need u-s-c to rebuild
<olli> ok, I guess I will bisect my kernel then for a while ;)
<olli> also fun
<kgunn> for the love of it all...even the publishing takes an eternity
<RAOF> Hm. So, r985 + the client buffer tracking fix gets me something that's mostly working, but needs some damage region fixing in xmir
<robert_ancell> published
<duflu> Cool. Except I'll go to lunch first.
<kgunn> rebooting...
<robert_ancell> brb
<kgunn> so i chose to hotplug, vga cable...looks like x crashed
<kgunn> when i disconnected, it punted me back out ot the greeter
<robert_ancell> hmm, not so good. Works fine without the second monitor, then flickers, mirrors for a bit (in greeter) then everything crashes
<kgunn> hdmi - same computer...ends up with nothing on second...but "low gfx mode" on built-in
<kgunn> altho...it has already crashed once...i should reboot to be fair
<robert_ancell> this is VGA for me
<kgunn> ok...i rebooted for hdmi, it does exact same thing as vga....which is 1st & second screen flicker & shows up (w/ purple feild...no unity....but a mouse cursor on both)
<kgunn> and when i diconnect (both hdmi/vga) it flickers...punts me out to greeter
<robert_ancell> RAOF, does this sound like the damage region issue you mentioned earlier?
<RAOF> No; that didn't crash for me, it just only updated the display on VT switch.
<robert_ancell> RAOF, it seems to be updating fine here, but unstable
<RAOF> So, unity-greeter would come up and I'd see purple on each monitor ('cause that's the first thing that unity-greeter draws)
<RAOF> Seems to work fine here in cloned mode, but not draw properly in non-cloned mode.
<RAOF> And, yeah, a bit unstable on xrandr changes.
<kgunn> RAOF: robert_ancell ...how to set mirror mode before connecting (at least the setting ui is greyed out until you connect the monitor)
<RAOF> I started with both monitors attached :)
<RAOF> So that defaults to clone on X startup.
<robert_ancell> kgunn, X has a default that is hard-coded / set in the X config
<robert_ancell> then an XRANDR client (e.g. gnome-setting-daemon) picks up the event and applies what it wants
<kgunn> hmmm - i just booted with both monitors connected and it showed two purple fields/with 2 mice....but no ui after greeter login
<kgunn> greeter login cloned just fine
<robert_ancell> kgunn, no glitches while cloning?
<kgunn> i should say my second screen is larger than my built in....
<kgunn> don't know if that makes a diff
<robert_ancell> I got flickering, especially in the top of the built-in and corruption on the bottom of the external
<robert_ancell> same setup
<kgunn> robert_ancell: i can't see a ui no matter how i connect the 2nd monitor vga/hdmi/boot/post-boot
<robert_ancell> kgunn, oh, just purple?
<kgunn> yep
<robert_ancell> RAOF, what info can we get for debugging?
<RAOF> kgunn: *That's* what I was seeing, and I'm pretty sure that's related to bypass.
<RAOF> kgunn: If you get to all purple, VT switch away, then VT switch back, you should be able to see unity-greeter.
<RAOF> duflu: What would be causing that ^^^
<kgunn> RAOF: freaky....yes
<duflu> RAOF: Never seen that
<duflu> robert_ancell: What GPU?
<RAOF> duflu: How much bypass testing did you do with multi-surface clients?
<robert_ancell> duflu, Intel Corporation Core Processor Integrated Graphics Controller (rev 18)
 * RAOF is likewise intel.
<duflu> RAOF: None. We only have one multi-surface client and it doesn't trigger bypass. But shouldn't matter.
<RAOF> We now have a second multi-surface client )
<RAOF> :)
<duflu> Yep
<duflu> RAOF: Bypass has no visibility to clients. It only deals on a per surface basis
<RAOF> *Something* between r985 and what's in the PPA broke updates on multi-head xmir.
<duflu> I'm actually more concerned it sounds like no one has XMir+saucy+radeon/nouveau on a single machine. I know I don't.
<kgunn> i don't get flickering...it like updates a frame or 2...then appears frozen (but its actually rendering...somwhere)
<kgunn> if i keep vt switching back and forth....i see i've moved the mouse or launched an app....in the steady state i expect it
<duflu> kgunn: What GPU?
<RAOF> kgunn: Yeah. X clients are rendering, but it's not getting displayed by something in the XMir/unity-system-compositor stack.
<duflu> Eventually my USC died with exception: Output has not associated crts
<duflu> *crtc
<duflu> That's after getting nowhere on login
<kgunn> duflu: intel
<robert_ancell> RAOF, should we expect improvement in MM5?
<kgunn> this is freaky...i got youtube up...seeing if i can start a video
<duflu> kgunn: If you can recover without rebooting or ssh in then check /var/log/lightdm/unity-system-compositor.log
<robert_ancell> duflu, I have a fix to keep the old log on trunk, just don't want to make a lightdm release on a Friday...
<kgunn> duflu: looks normal...dm_connection_start, set_active_session '0', set_active_session
<RAOF> robert_ancell: Yes; it might be more stable, and in conjunction with the new xf86-video-intel it should render *both* heads in a non-cloned setup.
<robert_ancell> RAOF, there's a new -intel MM4?
<kgunn> wild...i got a youtube video playing (well i hear the audio...but obviously not playing on screen)
<kgunn> ooo, and can vt switch really fast for stop motion video :)
<RAOF> :)
<RAOF> robert_ancell: Indeed there is.
<RAOF> kgunn: Yeah. The problem is in the copying to Mir, not in the X client rendering.
<kgunn> RAOF: so you gonna kick off the intel mm5 ?
<kgunn> i'll stay up for one more round if so....but after that i'm cooked
<duflu> That's annoying. We use the same exception message in multiple locations so I can't tell what really failed
<duflu> robert_ancell: I'm going to try and do some more integration testing of bypass + MM. Where is the new MM stuff not on trunk yet? Any?
<robert_ancell> duflu, it's the stuff in the ppa basically
<duflu> robert_ancell: Yeah, but is there any MM functionality we're using not in lp:mir yet?
<robert_ancell> duflu, the only unmerged branch is lp:~raof/mir/fix-multi-surface-buffer-tracking
<duflu> ... there's none awaiting review
<robert_ancell> it fails the tests on android
<robert_ancell> but we don't care about that for this testng
<duflu> OK, I'm going to take XMir out of the equation and try some integration testing of the constituent branches not on trunk yet
<RAOF> https://code.launchpad.net/~raof/mir/fix-multi-surface-buffer-tracking/+merge/181259 is known-good
<RAOF> In the sense that this is what I'm running now, and it fails in ways that should be fixed in xserver MM6 & xf86-video-intel MM4
<duflu> RAOF: Yeah feels like integration issues, where each branch works fine by itself
<RAOF> Entirely plausible.
<duflu> If nothing else, bug 1211700 still scares me. And I do know that bypass makes that one worse.
<ubot5> bug 1211700 in Mir "Unthrottled EGL clients cause Mir to slow, sometimes to a halt" [Undecided,New] https://launchpad.net/bugs/1211700
<tvoss_> good morning
<duflu> Morning tvoss_
<duflu> Note to self: Don't trust benchmarks while building on all cores
<tvoss_> duflu, :)
<robert_ancell> RAOF, are you building these changes locally before uploading? :)
<RAOF> robert_ancell: I am now :)
 * robert_ancell reads the debian/changelog entries
<RAOF> The last couple were "obvious" changes :)
<robert_ancell> btw the Mir build in ppa:mir-team/qa-testing2 is merged with trunk, because we need the version number bumped to be greater than archive. Do you think that would cause any issues?
<robert_ancell> RAOF, ^
<robert_ancell> I've got to do family jobs and dinner now so will keep popping back here to update builds and test things
<duflu> Having per-session(client) monitor layouts is very confusing when I Alt-tab between clients :)
<duflu> I Alt+Tab to a client and it's not there any more, it moves!
<robert_ancell> duflu, heh, I think that's only meant to be allowed by the shell when they're full-screen
<duflu> robert_ancell: Or rather "when the session is a login". We don't distinguish between client as a session, and login as a session
<RAOF> robert_ancell: I don't think that will cause issues.
<RAOF> Lets see if this does indeed give me multiple outputs...
<duflu> I suspect Mir's hyper-sensitivity to the DRM state could become a problem. The slightest imperfection and it will die with an exception. We have managed to avoid such issues till now, but I wonder if XMir changing output configurations dynamically could affect that
<RAOF> Woot.
<duflu> ?
<RAOF> Ok, so this mostly works; unity just doesnt' get the memon that the display config changed.
<RAOF> Also there's some weird off-by-one-frame problem in the bit of the 2nd monitor that's not covered by both monitors.
 * duflu thinks mir_demo_server_shell needs some key combos for manual testing of layout changes
<RAOF> Yeah, that'd be fun.
<duflu> RAOF: Merging both our branches with trunk and using two monitors works flawlessly. XMir must be doing something we don't or can't test yet. See previous comment
<RAOF> Two fullscreen surfaces from one client?
<duflu> RAOF: I shall hack together some testing for that
<RAOF> I fiddled with mir_demo_client_accelerated to do that  recently. The patch should still be in backscroll
<robert_ancell> RAOF, ppa:mir-team/qa-testing2 has mir+u-s-c ready - copy over the X packages when ready
<duflu> RAOF: Actually I'm seeing a new regression with multi-win clients using plain old trunk :/
<RAOF> duflu: :(
<duflu> RAOF: Does demo_client_multiwin work for you any more?
<kgunn> robert_ancell: RAOF amd64 xorg-intel failed due to wanting a new xmir...so i restarted it (guessing it was going out of order)
<kgunn> i loaded the usc/mir on top of the last xorg....clone was ok-ish (still got punted to greeter)....and extended desktop was gnarly (eventual punt to greeter)
<kgunn> i'm gonna head of to sleep...good luck guys
<duflu> kgunn: OK bye
<duflu> RAOF: There looks like a related issue on trunk, before either of the new branches: https://bugs.launchpad.net/mir/+bug/1215754
<ubot5> Launchpad bug 1215754 in Mir "[regression] mir_demo_client_multiwin crashes immediately with runtime_error: Failed to import PRIME fd for DRM buffer" [Undecided,New]
<RAOF> duflu: Yup, confirmed.
<duflu> Almost bisected...
<duflu> RAOF: Bisected. Could bug 1215754 be relevant?
<ubot5> bug 1215754 in Mir "[regression] mir_demo_client_multiwin crashes immediately with runtime_error: Failed to import PRIME fd for DRM buffer" [Undecided,New] https://launchpad.net/bugs/1215754
 * duflu is presently rebuilding on a revision that *works* to try bypass with multi-surface clients
<RAOF> duflu: Maybe? The symptoms are quite different.
 * duflu is not aware of any symptoms with the PPA other than USC logging runtime_errors thrown about DRM
<arsson> My both saucy installations is broke after todays updates, anyone else?
<duflu> arsson: With PPAs or vanilla?
<RAOF> v
 * duflu goes back to no-PPAs for a sanity check of sauncy
<duflu> *saucy
<arsson> duflu: well i was having QA-testing on another ubuntu
<duflu> arsson: Yes qa-testing is broken
<arsson> But what happens to the other? There i was having xorg edgers, but i don't remember if it was enabled because i just needed that to take nvidia-325 driver.
<dholbach> good morning
<robert_ancell> RAOF, qa-testing2 is good to go now?
<robert_ancell> RAOF, though I notice mir got out of date at some point
<tvoss_> robert_ancell, which launchpad branch should I build?
<robert_ancell> tvoss_, for multi-monitor?
<tvoss_> robert_ancell, ack
<robert_ancell> tvoss_, lp:mir + lp:~raof/mir/fix-multi-surface-buffer-tracking merged in
<robert_ancell> tvoss_, or just use lp:~robert-ancell/mir/multi-monitor which is just that (and what is going into the PPA)
<tvoss_> robert_ancell, ack
<RAOF> robert_ancell: Yeah, it's got everything in it. It's more working, but still not all the way there.
<duflu> OK, I think I might have found a bypass bug. But only reproducable with software surfaces, and lp:mir <=990 (because 991 and later is broken for other reasons)
<duflu> RAOF: What's the pixelformat of XMir?
<RAOF> rgbx_8888
<RAOF> Or some permutation of that.
<duflu> RAOF: How does XMir choose it? Or hardcoded?
<RAOF> Hardcoded.
<RAOF> It should expose the available formats to the XMir driver and then have that choose, but for the moment it's hardcoded.
<RAOF> Aha!
<RAOF> (Maybe)
 * RAOF is the man who Creates all the Pixmaps!
<duflu> Too many ideas, no time left.
<asac> hi!
<asac> so i am using unity-system-compository/xmir
<asac> and it works great :)
<asac> however, i have my x220 in a dock with external monitor and the resolution is not correct
<asac> can i force this thing to use 1080p?
<robert_ancell> asac, not yet, we're just testing multimonitor support
<asac> robert_ancell: yeah... thought i might be able to force this thing somehow to take the resolution from this screen
<asac> rather than automagic
<robert_ancell> asac, at the moment it just uses the native resolution of the primary monitor
<asac> yeah thats what i experience
<asac> there is no brute-force way?
<asac> :)
<asac> no trick?
<asac> :-P
<robert_ancell> asac, the trick is to apt-get source, add support and recompile :)
<robert_ancell> brb
<asac> sounds eaasy
 * asac doesa that
<asac> wonder if thats the xorg mir thing or the compositor
<asac> guess the former
<robert_ancell> RAOF, I'm getting the same behaviour in ppa:mir-team/ppa-testing2 as I was in ppa:mir-team/ppa-testing
<alan_g> ricmm: re session_lifecycle - you seem to have incorporated reverting recent changes into the MP.
<RAOF> robert_ancell: Which behaviour was that again?
<robert_ancell> RAOF, flickering, corruption on second screen
<robert_ancell> RAOF, also, it appears unity crashes out when logging in
<RAOF> robert_ancell: Ah, that's likely to be my "acutally resize the screen pixmap" bug that I'm fixing now.
<RAOF> In other news: I've said this before, but ALWAYS #include <xorg-config.h> IN YOUR FILES, LEST YOUR STRUCTURES MAGICALLY HAVE A DIFFERENT LAYOUT THAN YOU EXPECT
<pete-woods> tvoss: hi, do you have any time today to talk about the music hub / service? I've been asked to hook the sound indicator up to it
<tvoss> pete-woods, sure, let me grab coffee real quick
<pete-woods> cool
<tvoss> pete-woods, can you open a hangout?
<pete-woods> tvoss:sure
<tvoss> pete-woods, thx
<pete-woods> tvoss: https://plus.google.com/hangouts/_/453d38c0debd30d880901eef7114cd0241ef2f8e?authuser=1&hl=en
<robert_ancell> RAOF, Will MM8 come in the next half hour or so?
<robert_ancell> ok, my battery is telling me to call it a night. See you tomorrow
<RAOF> robert_ancell: Should do.
<RAOF> robert_ancell: 'gnight.
<ricmm> alan_g: not sure what happened there, pushing fixed branch in a sec
<ricmm> my bad
<alan_g> ricmm: np
<ricmm> alan_g: seems to be fine now
<alan_g> ricmm: I will have another look...
<ricmm> thanks
<kgunn> RAOF hey...so will MM8 be worthy ? or is MM7 already worthy?
<tvoss> kgunn, nope, better, but there is a stray Damage event killing us potentially
<kgunn> updating now...i'm supposing we get punted to the greeter?
<tvoss> kgunn, on monitor connect, yes
<ricmm> alan_g|lunch: MR updated, last comment I dont think it warrants a change
<ricmm> its just a trigger for the communication, which is what I'm testing
<ricmm> and it guarantees arrival when expected if done that way
 * ricmm coffee
<ricmm> alan_g|lunch: went ahead and changed it too
<alan_g> ricmm: ok
<ricmm> alan_g: thanks for approving
<ricmm> last jenkins just ran for the final rev
<ricmm> if you want to top-approve at some point
 * ricmm off to the doc
<alan_g> ricmm: sure - but I like to give other team members a chance to review first
<tvoss> racarr, you around?
<tvoss> alan_g, I'm inclined to approve ricmm's mp
<alan_g> tvoss: too late - I already did
<tvoss> alan_g, ah :)
<alan_g> ricmm: your MP failed to land - looks like a merge conflict
<alan_g> tvoss: we were sabotaged by racarr and ricmm both adding an enum at the same place in the file
<tvoss> alan_g, \o/
<ricmm> sabotages
<ricmm> :(
<ricmm> alan_g: ok, conflict solved and pushed
<alan_g> ricmm: top approved
<ricmm> thanks
<alan_g> yw
<ricmm> alan_g: still around? same branch from robert added a test that was missing a method on my modified event sink
<ricmm> so, need to top approve again :(
<alan_g> ricmm: you've updated?
<ricmm> yes
<ricmm> test_surface.cpp builds fine now
<alan_g> ricmm: top approved
<ricmm> cheers
<racarr> tvoss: Pong?
<racarr> kgunn: So, DPMS coming back on still isn't cracking
<racarr> talked about it with robert_ancell yesterday, and made the plan to land the API changes, etc
<racarr> so we can update XMir
<racarr> and finish the GBM impl as a bug
<racarr> Make sense?
<kgunn> racarr: so...does that mean android is happy? but gbm "no workie" ?
<kgunn> racarr: if so, yes, plan makes sense
<racarr> kgunn: No android isn't happy either
<racarr> becuse android doesn't have display configuration yet
<racarr> the deal is the clients can happily set DPMS but nothing happens yet :/
<kgunn> racarr: ok...so this is simply about updating needed api's
<racarr> yes
<kgunn> racarr: makes sense....who will this break ? e.g. do we need to shout it out ?
<racarr> Yeah mirclient API
<racarr> I bumped ABI
<racarr> :(
<racarr> I wonder if its worth adding some padding to some of the structs at the same time
<racarr> so i we need to change display configuration again can do it without breaking ABI
<ricmm> https://launchpadlibrarian.net/148264842/buildlog_ubuntu-saucy-i386.mir_0.0.9%2B13.10.20130823.2-0ubuntu1_FAILEDTOBUILD.txt.gz
<ricmm> :( ??
<mlankhorst> racarr: .. or just a version in the struct :p
<tvoss> ricmm, flaky, try again
<ricmm> yea, already done
<racarr> kgunn: Hey we got lucky for once!
<racarr> I finally got to the stress test
<racarr> so I decided to test if it still crashed in the same way
<racarr> and just ran it for about 5 minutes while moving the mouse around and no crash
<racarr> thomi: ^
<racarr> When was the last time you tried XD
<racarr> I think the create_surface_for changes may have made it so that the invalid surface exception you could get out of focus/input from the get_surface 'race'
<racarr> is handled non fatally now
<racarr> the only thing is its notabbly slower than it was when I had the test running a few weeks ago
<racarr> i.e. I used to be able to run it and move the cursor with no noticeable lag
<racarr> now there is definitely lag
<racarr> seems too good to be true
<tvoss> racarr, that there is a lag?
<racarr> tvoss: No that the stress test fixed itself
<racarr> and I don't have to
<racarr> stress about it
<tvoss> racarr, well, if there is a lag, we might want to investigate where :)
<racarr> True
<racarr> but its still nice to have part of it done
<racarr> Going to let it run for the full 10 minutes no
<tvoss> racarr, yeah, was just about to say that it's nice that it is working
<racarr> tvoss: Except it was too good to be true
<racarr> and almost immediately brought my hole system down this time
<racarr> :p
<racarr> back to the fun
<tvoss> racarr, enjoy :)
<racarr> tvoss: definitely :p
<racarr> SessionMediator should only have a weak reference
<racarr> to session
<racarr> if its going to use
<racarr> close/open session
<racarr> and the session container is going to have ownership
<racarr> can fix one of the races this way but I dont even know if this one is still exhibiting because I can't get backtraces or recover my system anymore
<racarr> strange, that fixes the lag
<racarr> maybe the lag was a bunch of handled exceptions
<racarr> frontend handles some exceptions silently
<racarr> Giving it a ten minute run again cross your fingers
<kgunn> fingers crossed
<racarr> Lag is intermittent
<racarr> got two ten minute runs
<racarr> with no crash though
<racarr> ok another ten minute stress brb
<racarr> :)
<robert_ancell> RAOF, let me know when you're online
<racarr> robert_ancell: So if the stress test is fixed (I think it is!) is there something I should be doing more important than trying to make DPMS impl ork?
<robert_ancell> racarr, I think DPMS is a good goal
<racarr> Ok ill work on it today, ill be around tomorrow too, and write up a hand over email/potentially finish it depending on how things go
<racarr> sunday morning am gone though
<RAOF> Alright. Where's that damageptr going wrong.
<RAOF> robert_ancell: Good morning.
<robert_ancell> RAOF, hi
<RAOF> You were up early!
<robert_ancell> normal time
<RAOF> Or are you 2 hours ahead of me?
<robert_ancell> yes
 * RAOF always forgets that
<robert_ancell> there's a merge conflict with  lp:~raof/mir/fix-multi-surface-buffer-tracking - I've fixed it in lp:~robert-ancell/mir/multi-monitor but you probably want to update your branch
<RAOF> Urgh, ok.
<robert_ancell> some whitespace changes around your change
<RAOF> Will do while this server builds with -DDAMAGE_VALIDATE_ENABLE
<robert_ancell> RAOF, also, I tried testing by running mir_demo_server then X -mir and I can reproduce the issues (flickering, X crash when plugging in monitor)
<RAOF> There are two problems there; one mispassed pointer and then the stray damageptr
<robert_ancell> RAOF, is there an easy way to build your branch locally so I can try it? Does it need all of debian/patches/*
<robert_ancell> fixed in MM8?
<RAOF> robert_ancell: I've pushed qa-testing-ppa to github.com/RAOF/xserver
<robert_ancell> cool
<robert_ancell> RAOF, also tvoss said he still had issues with MM8
<RAOF> Yeah, the mispassed pointer should be fixed in MM8. The damage issue is still pending.
<robert_ancell> X has a scary number of compile warnings
<RAOF> It comes of being a codebase that still contains some honest-to-got K&R C
<robert_ancell> RAOF, btw, did you find time to write that blog post?
<RAOF> No
<robert_ancell> k
#ubuntu-mir 2013-08-24
<robert_ancell> brb
<robert_ancell> RAOF, MM8 seems to run better for some simple test cases with mir_demo_server
<robert_ancell> still falls apart if I plug a monitor while running unity or from the greeter though
<RAOF> Ah, good. Valgrind sees all!
<robert_ancell> :)
<RAOF> Mir doesn't handle monitor unplug, apparently.
<RAOF> Unplugging my HDMI monitor and then querying the display config crashes u-s-c
<robert_ancell> ah
 * robert_ancell -> lunch
<robert_ancell> RAOF, any thoughts on that unplug issue? Are you working towards a MM9?
<robert_ancell> RAOF, Is there anything I can do to help here - multi-monitor isn't working on my system at all and I don't know of any specific bugs I can fix. If there's no new packages coming I
<robert_ancell> 'm not doing anything useful here
<RAOF> robert_ancell: I don't think there's anything to test that can't be more easily done by me locally at the moment.
<robert_ancell> ok, any idea when something will be testable?
<RAOF> I don't think I can give a useful estimate.
<RAOF> Should be soonish, but that depends on my understanding of the current problems.
<kgunn> what' s up fella's i'm back
<kgunn> anything to test ?
<robert_ancell> kgunn, nothing at the moment
 * RAOF tries with the next set of debug spew.
<RAOF> That's *better*; now I merely need to find out where I'm setting the stride incorrectly.
<RAOF> Ah!
<RAOF> And that's where the pitch is wrong.
<duflu> Erm, both testing PPAs populated? Which one should I use?
<RAOF> qa-testing2
<robert_ancell> duflu, qa-testing is MM+bypass, qa-testing2 is just MM
<duflu> Okee
<kgunn> duflu: ....just to add, qa-testing2 is a non-starter atm
<duflu> Argh.
 * duflu cancels upgrade
<RAOF> But might soon start & win!
<kgunn> RAOF: curious...why is qa-testing xorg mm8 & qa-testing2 mm7 ?
<RAOF> kgunn: Because I uploaded mm8 to the wrong PPA
<kgunn> :))
<duflu> This could cause some pinning confusion...
<kgunn> i love you guys....make me feel normal :)
<kgunn> duflu: how so ?
<duflu> kgunn: My system was pinned for qa-testing. So switching to qa-testing2 might not get all the packages from it
<kgunn> duflu: right...you'd have to purge first
<robert_ancell> yep, always do a purge
<duflu> Hmm, the pointer lag that I previously attributed to software cursors is mostly gone when using a PPA with bypass enabled
<kgunn> robert_ancell: you updated qt-testing2 from archive basically ?...thanks for that
<duflu> ... mostly
<robert_ancell> kgunn, no, just rebasing on archive when it changes
<kgunn> robert_ancell: yeah...what i meant...thanks for that
<robert_ancell> np
<kgunn> i was semi worrying about that
<kgunn> btw...did you see olli's ping earlier about u-s-c crashing on him ?
<RAOF> When he removes a monitor?
<kgunn> no it was just random use of xmir (i think)
<kgunn> but then apport said something like...can't report because
<kgunn> version of u-s-c changed ?
<robert_ancell> kgunn, was he using a PPA?
<kgunn> <olli> kgunn, tvoss|dinner_and_benchmarking seeing something weird
<kgunn> <olli> while working on my kernel issue, I got an apport report of u-s-c crashing
<kgunn> <olli> which in iteself sucks but is no surprise
<kgunn> <olli> however I have #seat=unity
<kgunn> <olli> and when proceeding to file the bug through apport, it complains that the bug can't be filed since u-s-c has changed since the crash occured
<robert_ancell> might be an old crash report
<RAOF> Ok. Lets see if mm9 + a new intel driver gets us all the way to spanned displays.
<duflu> Is anyone testing non-intel? I can't with saucy :(
<RAOF> It almost certainly won't work with !intel at the moment; I'll get to that after intel works.
<duflu> I can test radeon and nouveau on raring tho... Need to build everything by hand
<RAOF> Hm. Might be lunch time.
<duflu> Hm. Might be breakfast time
<robert_ancell> Hm. Might be dinner time
<olli> Hm. Might be bed time
<olli> is there anything worth testing?
<tvoss> good morning :)
<olli> kgunn, I was bisecting kernels and it might have been just a weird side effect
<olli>  tvoss says: Hm. Might be breakfast time
 * duflu concurs. 
<duflu> Brunch even
<tvoss> olli, indeed :)
<olli> well, it's beer o'clock somewhere
<kgunn> olli: i thot you were in some remote forest or canyon or something
<olli> kgunn, I will be in 12h
<olli> right now though I am having ice cream and redwine
<olli> waiting for the miracle in #ubuntu-mir street
<olli> duflu, anything worth giving a shot?
<kgunn> i think waiting on a mir-acle makes you gain weight...waffling between beer & choc chip cookies
<olli> hah, kgunn just inspired me for the blog post once everything has landed
<olli> +title
 * tvoss hands coffee to RAOF :)
<duflu> olli: I know as much as you. RAOF and robert_ancell are in control of PPAs
<robert_ancell> olli, there's no changes worth testing. RAOF is working on X changes and the PPAs are ready for that when available
<RAOF> Xserver MM9 should be in qa-testing2, but that's not going to work properly until xf86-video-intel mm5
<RAOF> Which, assuming I've fixed the build properly this time, should be uploaded soon.
 * tvoss hugs RAOF 
<olli> alrighty, will keep my fingers crossed
<olli> (start getting calluses though)
<RAOF> Ok. Let's see if this works?
<kgunn> RAOF: amd64 failed
<tvoss> kgunn, in qa-testing2?
<kgunn> tvoss: my bad
<kgunn> too many tabs
<tvoss> RAOF, did you upload mm5, yet?
<olli> RAOF, qa-testing2?
<RAOF> Yeah, that's where it'll end up
<RAOF> Just testing it locally.
<tvoss> duflu, did you see https://code.launchpad.net/~robertcarr/mir/weak-session-for-session-mediator/+merge/181924
<tvoss> ?
<olli> RAOF, ok
<RAOF> Just worked out why it tends to turn my HDMI output off, too, which once fixed will make it easier to test :)
<duflu> tvoss: I intentionally don't look at code reviews until I have a longer stretch of hours to fuss over them. So... soon
<tvoss> duflu, ack :)
<RAOF> Win!
<duflu> Where?
<RAOF> qa-testing2, xorg-server MM10, xf86-video-intel MM5
<duflu> Righto
<RAOF> You'll need to wait for them to build, obviously.
<RAOF> Well, not obviously. But you will need to wait for them to build :)
<duflu> Now obvious
<kgunn> in the words of tom petty "the waiting is the hardest part"
 * kgunn subscribes to the theory there's a song lyric for every situation
<duflu> RAOF: You silently switched from qa-testing to qa-testing2 ... is that because bypass is still suspicious? or you want to keep it simple testing one thing at a time?
<RAOF> Oh, because bypass is still suspicious.
<duflu> kgunn: Generally true.
<duflu> RAOF: Suspected of ... (something I can test for?)
<RAOF> Suspected of failing to send buffers appropriately.
<RAOF> Now that MM works I can dig deeper there.
<duflu> RAOF: How so?
<robert_ancell> I have to go, I'll try and hop on later tonight and check in
<kgunn> or duflu could dig there...while you dig on ati :)
<kgunn> robert_ancell: o/
<RAOF> duflu: Because, when XMir is driving multiple displays, unity-system-compositor only shows the first frame since it was VT switched to.
<RAOF> robert_ancell: Have fun wherever :)
<duflu> kgunn: Due to multiple kernel bugs, I cannot test bypass on radeon. Only alf could
<kgunn> duflu: even after the 3.11 arrival ?
<duflu> kgunn: Because of 3.11. Booting 3.11 on raring broke too much, and booting saucy on my radeon machine fails to boot at all for unknown reasons
<tvoss> RAOF, did you upload mm5 for the intel driver, yet?
<duflu> kgunn: So I was going to call that a blocker till alf tested it for me
<kgunn> yeah
<duflu> RAOF: I got exceptions from USC yesterday suggesting bypass might fail due to outputs not having CRTCs assigned at times. Is that meant to be possible?
<duflu> It's not possible to reproduce with plain Mir. Only saw it with XMir + MM setup
<duflu> Which reminds me. I need to beef up our exceptions if it happens again
<RAOF> tvoss: Yeah, I've uploaded MM5 of -intel
<tvoss> RAOF, in qa-testing2?
<RAOF> ...but I don't see it in the PPA, so I'll check my email.
<tvoss> yup :)
<RAOF> Hah! Which says âyou sent it to qa-testing, dufusâ
<kgunn> tvoss: so i was playing with lttng....trying to follow the http://unity.ubuntu.com/mir/component_reports.html
<kgunn> so when i cd into /tmp/ i don't mirsession
<RAOF> Why is everything terrible?
<kgunn> or rather...if i follow those instructions...what is substituted for <sub dir> in ....babeltrace /tmp/mirsession/<trace-subdir>
 * RAOF cancels the amd64 xserver build that hung in the xvfb-run test
<tvoss> RAOF, kgunn moving over to the new house with a second monitor with me :) back in ~20
<RAOF> Hm. Damage is slightly off.
<RAOF> But mostly ok.
<RAOF> i386 build, take 2, is done.
<RAOF> amd64 build is nearly done.
<RAOF> Happy testing, gentlemen.
<RAOF> I'm off to get groceries.
<tvoss> back again
<tvoss> RAOF, dist-upgrading
<tvoss> kgunn, can you check your lttng version? please see the remark at the bottom of the page
<kgunn> tvoss: hmm, says 2.1.1...
<kgunn> but thanks for that...that pointer to the 2.2+ might be an issue on my android effort
<olli> kgunn, which PPA did RAOF suggest
<kgunn> https://launchpad.net/~mir-team/+archive/qa-testing2/+packages
<kgunn> olli: ^
<kgunn> olli: don't forget to purge first (if you had been using qa-testing....not qa-testing2)
<kgunn> and of course updaet your pinning pref file
<olli> kgunn, on it
<tvoss> kgunn, did you try the ppa, yet?
<kgunn> tvoss: yep...just incessant punting to the greeter
<kgunn> i wanna double check all my packages first thos
<kgunn> just in case
 * olli finishes the install of qa-testing2
<olli> what do we expect to work?
<kgunn> tvoss: you ?
<kgunn> olli: i would just try vga hotplug
<kgunn> all my packages match :(
<olli> kgunn, should I refrain from testing?
<olli> or are you talking lttng?
<kgunn> second data point can't hurt
<kgunn> unfortunately....i'm talkin' bout qa-testing2
<olli> brb
<kgunn> hmmmm....hdmi worked....after 1 punting to greeter
<kgunn> all the sizes even look proper (mirrored)
<kgunn> ooo, it's pissed...did not like me unchecking mirrored
<kgunn> just hung
<olli> arg
<olli> can't find the vga cable
<olli> am on dvi via dock
<olli> so far it's just mirrored
<olli> doesn't detect 2nd display
<duflu> Are we meant to having working hotplugging yet? Even when I had two monitors working this morning, I had to reboot before xrandr detected the second one
 * tvoss reboots
<kgunn> hotplugging works on standalone X
<kgunn> and at least that was the goal...to have parity
<duflu> kgunn: Yeah. But I mean have we implemented it yet?
 * duflu isn't sure
<kgunn> at least mir mm (demo clients) was ok with this (i think...)
 * kgunn now doubts self
<tvoss_> RAOF, are we supposed to have hotplugging working?
<kgunn> ok...so hotplug on vga (1 test) didn't work, hdmi hotplug punted me to greeter but then on login worked...
<kgunn> from boot both vga & hdmi work in mirror mode
<kgunn> ooo, take that back hdmi worked in mirror mode, vga does not
<kgunn> hdmi also worked when in mirror mode...deselect mirror + built in display off.....it went to 2nd monitor only
<kgunn> (which is a lot like hotplug)
<kgunn> and hdmi was ok, with switching mirror mode on (from the state of built in display off)
<kgunn> ok....that does it for me...i'm totally crashing (i feel asleep mid reboot)
<kgunn> vga no good...hdmi seems pretty ok (mirror & going to second display only)
<kgunn> hotplug wonky on hdmi, no good on vga
<duflu> RAOF: Looks like XMir is honouring the desktop's alpha channel. I can "see through" the unity launcher when dragged
<olli> well, that didn't work so well
<olli> I am off for today
<olli> good luck gentlemen
<olli> appreciate your work on the weekend
<duflu> Alright. Later olli
<RAOF> See you.
<duflu> Hmm, X died and took me back to lightdm. But no logs show a crash... ?
<tvoss_> duflu, RAOF hotplug with vga not working for me
<tvoss_> I'm afk for some 30 minutes now, with you later
<RAOF> Hm.
<RAOF> duflu: What do you mean by "see through"?
<RAOF> Well, HDMI hotplug worksish for me, although X doesn't seem to notice when its connected.
<duflu> RAOF: Drag the launcher down and you can see a stationary one underneath. Perhaps an old frame or intended for a different screen
<duflu> It seems Compiz/Unity has some pixels with alpha < 1.0, which never used to matter but now they're translucent
<RAOF> They *shouldn't* be translucent. If they are it's a Mir bug, as Xmir chooses an xrgb pixel format.
<duflu> Hmm, well that's the least severe issue right now
<RAOF> Resolution changing seems to be working pretty well here.
<RAOF> Turning the hdmi off, turning it on, changing the mode, moving it, all work.
 * duflu restarts with a more sane single output setup
<RAOF> Although I *am* ussing the locally built packages
 * RAOF upgrades from the PPA
<duflu> Hmm, I don't get any resolution choices for LVDS. Only DisplayPort
<RAOF> Yup.
<RAOF> We only pass on the modes the monitor supports.
<RAOF> Internal panels almost uniformly lack scalers, so they only support their native mode.
<duflu> Really? Every laptop I've tried had reasonable scaling for low-res modes
<RAOF> No, it's had faked scaling for low-res modes :)
<RAOF> Or, rather, the scaling has been done on the GPU rather than by the panel.
<duflu> RAOF: Yeah. For many people trying to run Unity on full-HD laptops, that feature is rather important
<tvoss_> back
<tvoss_> RAOF, duflu anything you want me to test?
<duflu> tvoss_: Can you confirm any of my bugs? https://bugs.launchpad.net/xmir/+bugs?field.tag=multimonitor
<tvoss_> duflu, walking through them
<duflu> It's rather cool that you can still start native Mir clients inside unity-system-compositor and XMir just (correctly) gets out the way
<duflu> Oh wow, my translucent desktops are responding separately. It really is two launchers
<RAOF> duflu: Can you modeset/change layouts with the xrandr tool?
<tvoss_> duflu, you might want to give https://code.launchpad.net/~thomas-voss/glmark2/mir-no-deprecated-functions a spin
<duflu> RAOF: I was just about to. Got side-tracked taking awesome blurry-cam video
<RAOF> :)
<duflu> RAOF: I suspect the blending issue is just "normal" for Compiz/Unity when you have two different displaybuffers physically overlapping
<RAOF> Likely, yes.
<duflu> Hence, it's "pre-blended" before it hits Mir
<duflu> RAOF: Yes, xrandr layout changes work.
<duflu> Only crashes with Control Center
<RAOF> Yeah. I suspect that it's actually broken with xrandr too, but we mostly don't hit it, whereas the little labels gnome-control-centre has makes it hit.
<duflu> RAOF: Kinda. I tried some --off and then on again. And eventually broke it with xrandr
<duflu> RAOF: Do the labels cause immediate damage or something strange?
<duflu> tvoss_: Cool. But I've never built glmark2 and might not get to it today
<tvoss_> duflu, I will produce some numbers over the weekend for intel and amd
<duflu> tvoss_: Excellent. Can you see if a single build can support X and native Mir? Because glmark2 does. Then we can compare them directly. Even both running on the same USC instance :)
<tvoss_> duflu, yup, you can build multiple flavors
<duflu> tvoss_: I mean build once, run anywhere
<tvoss_> duflu, yup, that's what I mean, too :)
<duflu> tvoss: Nice. You could even run an X glmark2 and Mir glmark2 simultaneously on USC :)
<tvoss_> duflu, exactly ;)
<tvoss_> duflu, makes for nice blurry cam videos, too
<duflu> Though they would fight for GPU
<tvoss_> duflu, right, not so interesting for producing numbers
<tvoss_> duflu, walked through the multi-monitor bugs and tagged them with affects me
<duflu> tvoss_, New --> Confirmed ?
<tvoss_> duflu, nope, only affects me. Can set to confirmed
<duflu> Please
<tvoss_> duflu, I will confirm against xmir
<tvoss_> duflu, cannot check on displayport, though
<duflu> tvoss_: In theory the connector doesn't matter. Mir has no connector-specific code
<duflu> Anyway, this is Intel, which means DisplayPort + DVI adapter = "HDMI" :)
<duflu> That's an old bug
<tvoss_> duflu, ack
 * duflu wonders why we don't have an xrandr equivalent for Mir yet
<duflu> We have a demo client which shows it's possible. But that's just a toy
<robert_ancell> RAOF, what's the state of MM10?
<duflu> robert_ancell: Unchanged for a while. Bugs are against mir/xmir projects with "multimonitor" tag
<robert_ancell> duflu, is MM10 considered mostly working?
<duflu> robert_ancell: Hard to judge what mostly would be. I think maybe 30%
<robert_ancell> ok
<duflu> robert_ancell: The strangest one is X crashes if you use Control Center to change settings. xrandr works much better, but not 100%
<duflu> Going
<duflu> Going
<duflu> Gone
<tvoss_> RAOF, ping
<RAOF> tvoss_: Pong
<tvoss_> olli, ping
<olli> tvoss|test, pong
<kgunn> RAOF: vga connected at boot, just checked the xorg log its shows EE backtrace but nothing under it (like crashed before write out)
<kgunn> right at "updated configuration" where it has output5/12 connected..then post-modeset config
<kgunn> https://pastebin.canonical.com/96336/
<kgunn> to be clear that was pre-boot vga connected....never got past greeter (greeter cycling)
<kgunn> ok...then i retested vga hotplug and got this https://pastebin.canonical.com/96336/
<kgunn> seems different...like it almost reconfigured, but then went thru a bunch of keyboard/trackpad setup then bailed
<kgunn> huh...hotplug on hdmi worked (with adjusted res) but upon second connect/disconnect....its not alter the second screen res properly to fit it
<kgunn> but hdmi hotplug seems robust enough to have repeated connect/disconnect
<kgunn> oh...and on hdmi hotplug...let it sit...not its frozen, can't even vtswitch
<kgunn> corraction vga hotplug > https://pastebin.canonical.com/96337/
<kgunn> seems hdmi hotplug will eventually fail in the same way
<rigved> hi everyone.
<rigved> i am running xmir on my 13.10 laptop.
<rigved> everytime i try to open the dash or click on the shutdown menu item, my system freezes for a 2-3 minutes and then comes back to normal.
<rigved> everything else seems to be running fine.
<rigved> can someone help me diagnose the problem?
<robert_ancell> RAOF, morning
<robert_ancell> kgunn, around?
<kgunn> robert_ancell: hey kinda
<kgunn> robert_ancell: i was actually thinking about going to bed early and getting up around 4....since images don't usually show up until 1 -ish
<kgunn> my time...
<robert_ancell> kgunn, I get slight improvements with MM10, looking at logs I don't think there's been any improvement until then
<robert_ancell> right
<robert_ancell> Chris said he'd be here in ~1:15, which means an image in ~2hrs perhaps?
<kgunn> robert_ancell: what are your results for hot plug?
<robert_ancell> kgunn, I got it spanning on the greeter once, but it seems a bit random
<kgunn> robert_ancell: right...but you can't ever get past greeter?
<robert_ancell> most of the time it mirrors and u-g/XMir restarts quite a bit
<robert_ancell> I can without the external monitor
<robert_ancell> otherwise it's a bit random, sometimes it works, sometimes it doesn't
<robert_ancell> I've only seen mirroring inside Unity
<kgunn> robert_ancell: right...i roughly see the same...
<kgunn> altho hdmi more stable than vga....
<kgunn> which i never would've bet on
<robert_ancell> yeah!
<robert_ancell> I'm just testing VGA here
#ubuntu-mir 2013-08-25
<kgunn> robert_ancell: on the reporting stuff...here http://unity.ubuntu.com/mir/component_reports.html
<kgunn> so lttng obviously needs lttng
<kgunn> but for handlers "log"
<kgunn> does that just get written out to a file ?
<robert_ancell> kgunn, I think you need to run it with --glog for the logs to go to glog then you can set --glog-stderrthreshold to have them go to stderr or --glog-log-dir to change where the log files go
<robert_ancell> I haven't mastered the logging commands yet though
<kgunn> robert_ancell: yeah...it says you can define an envrion variable
<kgunn> to turn it on...which i assume means like "export MIR_SERVER_DISPLAY_REPORT=log"
<robert_ancell> kgunn, you can set any of the flags to mir by using MIR_SERVER_* environment variables, e.g. MIR_SERVER_GLOG_LOG_DIR=/tmp/logs
<robert_ancell> yep, that would be the equivalent of --display-report=log
<kgunn> robert_ancell: can that be post server launch ?...or will i need to reboot ?
<robert_ancell> kgunn, env variables need to be defined before server launch
<robert_ancell> kgunn, you can set them in /etc/environment if you want them universally applied
<kgunn> like in a pref file ?
<kgunn> oh...
<robert_ancell> kgunn, or edit /etc/lightdm/lightdm.conf.d/10-unity-system-compositor.conf and set unity-compositor-command as you like if you're testing the whole stack
<kgunn> robert_ancell: huh...so i tried to alter envirnonment on the nexus4...but no matter what nano just won't write out the change
<kgunn> ever experienced anything like that on n4 ?
<kgunn> i root shell...
<kgunn> oops/i/i am
<robert_ancell> write out what change?
<robert_ancell> oh, editing the file?
<robert_ancell> what does mount say?
<kgunn> robert_ancell: correct...trying to add GLOG.... & MIR_....
<kgunn> robert_ancell: mount says a bunch...so i guess it depends...
<robert_ancell> try 'touch /etc/blah' and see if it throws an error
<kgunn> alot of "rw"'s
<kgunn> robert_ancell: touch worked...chmod worked....
<robert_ancell> kgunn, nano fail?
<robert_ancell> try cat > /etc/...
<robert_ancell> :)
<kgunn> weird...so "cat > /etc/environment" just sat there...
<kgunn> no output
<kgunn> but i definitely see the file when i open with nano
<robert_ancell> kgunn, that overwrites the file
<kgunn> and i can ctl-O to write out...but then, it prompts what file name to save under...and it simply won't accept "enter"
<robert_ancell> then type the contents and press ctrl+d to end
<RAOF> robert_ancell: Morning.
<robert_ancell> RAOF, hey
<RAOF> Hrm. Why doesn't that hit the assert()
<kgunn> RAOF: hope bkfst was good (something unhealthy like eggs and bacon)
<RAOF> It did include bacon, yes :)
<RAOF> Pan-baked eggs with bacon and sausage and onion and such.
<kgunn> yum
<robert_ancell> RAOF, so what's the plan? Are there some specific bugs you are working on?
<RAOF> So, at least one of the bugs is that we're not updating what Intel thinks the front buffer is.
<RAOF> That's causing at least *some* of the crashes after resolution change.
<robert_ancell> RAOF, this is in Mir?
<RAOF> This is in XMir.
<RAOF> My plan is to work on XMir + Intel until I can do resolution & layout changes and it doesn't crash.
<robert_ancell> ok
<kgunn> robert_ancell: well...i added MIR_SERVER_GLOG_LOG_DIR=/tmp/logs & MIR_SERVER_DISPLAY_REPORT=log....but nothing showing up in /tmp/ ?
<robert_ancell> kgunn, did you do MIR_SERVER_ENABLE_GLOG=1?
<robert_ancell> kgunn, rather MIR_SERVER_GLOG=1?
<kgunn> doh!
<duflu> That sounds quite overcomplicated to me
<kgunn> hmm  still no joy
<kgunn> robert_ancell: actually would it be MIR_SERVER_GLOG_LOG=1 ?
<robert_ancell> kgunn, mir_demo_server --help shows it is '--glog', so it should be MIR_SERVER_GLOG
<robert_ancell> kgunn, have you tried setting MIR_SERVER_GLOG_MINLOGLEVEL?
<robert_ancell> I had the same frustrations using the logging myself
<kgunn> robert_ancell: actually...that's a good idea...i should get familiar on pc first before phone
<robert_ancell> though --help seems to imply minloglevel is set to a valid default
<duflu> Hmm, if Mir is logged to unity-system-compositor.log already, why don't we start logging useful stuff by default?
<duflu> ... I mean at least "Mir has started successfully and is using these monitors with resolutions... Listening on socket /tmp/mir_socket"
<RAOF> That would be moderately useful, yes.
<kgunn> robert_ancell: duflu RAOF ....i think i'm gonna go to bed early...and get up really early...like 4 or 5 am
<robert_ancell> kgunn, later
<robert_ancell> duflu, that would be super useful
<kgunn> just not sure when everyone plans to eod...but if it all ends before i get on...can the last man standing write a handoff email....where we're at, what's worthy to test, what the balance of problems is etc.
<duflu> kgunn: OK, later
<robert_ancell> kgunn, sure
<RAOF> kgunn: See you later.
<duflu> Wow, qa-testing is better now. Just with ugly frame scheduling/damage glitches
<duflu> I'm not even sure how it's possible to get the kind of small horizontal line artefacts I see though
<duflu> Actually there seem to be some frame scheduling problems in qa-testing2, just much less often
<robert_ancell> duflu, have you found anything in the bypass branch that may be causing problems?
<duflu> robert_ancell: Nothing bypass-specific yet. All the bugs I've seen happen on qa-testing2 (just take longer)
<duflu> robert_ancell: It's extra hard to test things when a recent MM commit broke fingerpaint :/
<duflu> Maybe fingerpaint is to blame. Don't know
<RAOF> Bah. The xf86 cursor code would really like HW cursor stuff.
<duflu> Why does MM look so flawless for demo_server_client? Where are the bugs that XMir triggers?... :(
<duflu> *demo_server_shell
<robert_ancell> ok, I'm calling it a night - duflu, RAOF, please remember last one here to send out an email update. Thanks!
<duflu> RAOF: When you talk about receiving buffer fd's from the server, that's in-protocol, right? Not on the side channel...
<RAOF> duflu: Correct
<tvoss_> duflu, ping
<duflu> tvoss_, pong
<duflu> RAOF: Sanity check: qa-testing{,2} are different in that "2" has no bypass, right?
<RAOF> duflu: qa-testing might be a couple of Xserver revisions behind, too.
<RAOF> I've only been pushing to qa-testing2
<duflu> Except this morning, which is why I tested qa-testing
<RAOF> Yeah, accidentally :)
<tvoss_> RAOF, are you using swap_buffer_sync or swap_buffer nakedly?
<RAOF> tvoss_: swap_buffer nakedly.
<tvoss_> interesting, sam reports issues with that
<RAOF> Oh, really? What issues?
<duflu> RAOF: https://bugs.launchpad.net/bugs/1216337
<ubot5> Launchpad bug 1216337 in Mir "Client buffers eventually display one frame behind client swap requests" [Undecided,New]
<RAOF> Ah, that one.
<duflu> RAOF: Ooooh, doing native GBM you have a hardware buffer being swapped using the software swap_buffers call I guess. I wonder if we handle that correctly
<RAOF> Oh, no. A new appearance of the same symptom.
<RAOF> software swap_buffers call?
<duflu> RAOF: Yes mir_surface_swap_buffers* is usually for software only surfaces
<RAOF> It's also what EGL uses to implement eglSwapBuffers, though.
<RAOF> It's the only way to get a frame to Mir.
<duflu> RAOF: Yeah should be. Just theorizing
<RAOF> Woot!
<RAOF> We have a successful layout change with gnome-control-centre
<duflu> RAOF: "We" ? :)
<RAOF> I
<RAOF> Ok, that's really weird.
<RAOF> Mir has stuck the surface in the wrong place :)
<RAOF> tvoss_: Huh. Looks like it was indeed just the software cursor code being hateful.
<duflu> OK, my brain is fried and I'm also out of essentials such as... food. So I'm off to the supermarket for a while.
<RAOF> duflu: Have fun.
<RAOF> You might be able to test something that works when you return.
<RAOF> At least on the XMir side.
<RAOF> And for values of "works" equal to "doesn't crash horribly as soon as you touch the layout"
<tvoss_> RAOF, \o/, uploaded to the ppa, yet?
<RAOF> xserver MM11 just uploaded.
<tvoss_> RAOF, does that require an updated intel driver?
<RAOF> Yes, if you want it to work.
<tvoss_> RAOF, ack, I guess mm11 needs to finish compiling first
 * tvoss_ grabs a quick breakfast
<RAOF> Yup.
<tvoss_> RAOF, the xserver build for i386 hangs on xfvb
<RAOF> Grr.
<RAOF> Someone's going to have to work out what's happening there.
<RAOF> tvoss_: Build retried.
<tvoss_> RAOF, the 64bit build in the ppa hangs again
<tvoss_> quick restart
<tvoss_> RAOF, would it make sense to just disable the xvfb test in the ppa for now?
<RAOF> Yeah, it probably would.
<tvoss_> RAOF, hitting refresh to check the build is a bit tedious
<tvoss_> RAOF, does mm12 require a new intel driver?
<RAOF> Nope.
<RAOF> It just fixes the crash on startup in mm11 that I introduced by testing a subtly different change locally.
 * RAOF prepares to crash his unity-system-compositor by unplugging his HDMI output
<RAOF> Huh. Didn't crash (yet)
<duflu> RAOF: Yeah the Mir server seems to survive hotplugging fine. Even if you don't get to use the new monitors
<RAOF> mlankhorst: I don't suppose you're seeing the xvfb-run test hang all the goddamned time in the xserver builds you're doing?
<tvoss_> RAOF, just remove it from the ppa version for now
<RAOF> Yeah, done in mm13
<tvoss_> RAOF, ack, moving over to the new house, back in a few minutes
<duflu> RAOF: Does XMir use buffer age?
<RAOF> Yes
<duflu> I wonder if we're messing that up somehow
<duflu> ... in the server
<mlankhorst> RAOF: only 50% of the time
<RAOF> mlankhorst: Yeah :/
<kgunn> hey fellas
<mlankhorst> RAOF: might fail on virt only though
<RAOF> kgunn: Good morning. Sleep well?
<RAOF> mlankhorst: Yeah, maybe. I haven't been tracking that.
<duflu> kgunn: Hi. You could sleep more :)
<kgunn> uh-oh
<RAOF> Well, until https://launchpad.net/~mir-team/+archive/qa-testing2/+build/4904608 finishes building.
<kgunn> :)
<kgunn> time enough to make a coffee
<duflu> I have real food I can cook tonight. Wonder if I will get to...
 * RAOF is just eating some real food.
<duflu> Oooh, Sam reports similar lag issues and apparently also relies on buffer age
<duflu> RAOF: If we get as far is the frame scheduling being the _only_ problem, can you try ignoring buffer age?
<duflu> *as far as
<RAOF> Yes
<RAOF> (radeon and nouveau already do)
<RAOF> Or, rather, fail to act on it.
<duflu> ... because the only two clients which use buffer age are the only two clients reporting lag/ordering problems
<RAOF> Heh.
<RAOF> Huzzah!
<duflu> Maybe
<RAOF> qa-testing2 now has all the things!
<duflu> Cool
<kgunn> cool....
<duflu> Oooh, gnome-control-centre multi-monitor joy without crashes :)
<RAOF> Yay!
<RAOF> I shall now do some much-delayed housework in the form of some washing up.
<tvoss_> RAOF, duflu back
<kgunn> hey tvoss_
<kgunn> RAOF: sweet....i just hdmi hotplugged/connect-disconnect 8 times....survived all....just once it didn't scale right
<kgunn> getting somewhere :)
<tvoss_> kgunn, please try layout changes, too
<tvoss_> via the control center
<duflu> It seemed to work, but then bug 1216522
<ubot5> bug 1216522 in XMir "XMir hung in xf86CrtcSetModeTransform()" [Critical,New] https://launchpad.net/bugs/1216522
<kgunn> woooo-hoooo!!! was just doing that...hdmi extended desktop working & hotplugged
<kgunn> wooohoo....and dropping the built-in display  off works!
<tvoss_> duflu, for https://code.launchpad.net/~vanvugt/mir/distinguish-crtc-exceptions/+merge/181947
<tvoss_> duflu, are we sure that the type is usable as an array index? cannot tell from the mp
<duflu> tvoss_: Yes copied from the header where they are #defined 0 .. 14
<tvoss_> duflu, ack
<tvoss_> duflu, which header is that?
<tvoss_> want to note it down in my review comment
<duflu> tvoss_: It's mentioned in the proposal diff , but /usr/include/xf86drmMode.h
<tvoss_> duflu, top-approved
<kgunn> tvoss_: RAOF duflu ok...this is really robust...i've not been punted t to the greeter at all....i used hdmi, then i switched to vga, hotplugging all the way, mirror/extended/dropped builtin display....all of works
<kgunn> even moved the 2nd display virtually
<duflu> kgunn: Yeah it's better but I hung X pretty quickly. Meanwhile USC kept running smoothly
<kgunn> duflu: :(
<RAOF> duflu: Stop trying to rotate :)
<duflu> RAOF: I did no such thing
<kgunn> RAOF: i tried to rotate actually....didn't work...but x did not crash
<kgunn> trying reboot scenarios now
<RAOF> Yeah, I haven't hooked up any of the shadow alloc stuff that's necessary for rotation.
<RAOF> If I understand it correctly that *shouldn't* be hard.
<kgunn> RAOF: we can survive CFT w/o that...i'm sure some one somewhere relies on it...but hey..this is prebeta baby
<RAOF> â¦having just spent a weekend finding that the goddamned software cursor code dies if you don't dance around it perfectly.
<kgunn> RAOF: yeah...now i see how folks like you become experts in x...lots..& lots of scar tissue
<duflu> OK, I need to get some proper food sorted. Till tomorrow...
<kgunn> duflu: later
<RAOF> duflu: Eat well!
<tvoss_> duflu, till tomorrow
<kgunn> RAOF: tvoss_ nice work guys....this is so robust...i'm gonna upgrade on my primary machine...
<kgunn> it has display port...so technically one more phys connector type
<kgunn> was just telling voss....i've only managed  to crash x one time....and i'm being pretty damn mean to it
<kgunn> probably would've crashed in standalone x
<kgunn> robotfuel: there's no way your on...but if you're gonna do some work on sunday afternoon, qa-testing2 worthy of a run on the anointed 8 or 9
<RAOF> As long as they're all intel - patches for nouveau & ati are pending :)
<kgunn> RAOF: i'm all intel....all the time baby
<kgunn> RAOF: so was duflu on nouveau (when he managed to "crash his x pretty quickly")
<kgunn> ...having a hard time seeing crashing it quickly...
<kgunn> ok...bbiab/rebooting to mm
<mlankhorst> kgunn: might depend on graphcis card
<kgunn> mlankhorst: ack that
<kgunn> RAOF: tvoss_ ...so this is intersting....i'm on displayport/hdmi...extended desktop, i put my console in 2nd display...i run openarena...
<RAOF> ...and?
<kgunn> first i noticed...its totally unhinged...both high & low res going about 100fps
<kgunn> i'm guessing its cpu or shader limited (obviously not pixels:)
<kgunn> second thing....it takes me out of extended mode....but correctly changes the settings too....i need to test on standalone X
<kgunn> maybe this is correct behavior
<RAOF> Yeah, openarena is going to try and set the mode (if you're running it fullscreen)
<RAOF> Nice that it works :)
<kgunn> what was nice...after loading qa-testing2...i had some old display settings (extended & 2nd screen on left hand side instead of right)
<kgunn> and it just worked!
<kgunn> i can't wait for ancell to load this into the anointed machines in lexington
<kgunn> RAOF: why does openarena become unhinged from vsync here ?
<RAOF> kgunn: Because that's unimplemented; it's always been unhinged from vsync
<kgunn> RAOF: not so my friend....when i disconnect the cable...i drop back down to ~60fps
<kgunn> i just did it
<RAOF> And you're running XMir?
<kgunn> RAOF: hmmm....could it be in mirror mode...
<RAOF> Are you sure?
<kgunn> that the game has 2 buffers to draw into...so for ~every frame in single screen mode...he's counting 2 ?
<kgunn> RAOF: damn it...rookie...i know for sure it was xmir on the second machine...i just took it for granted on this one...
<kgunn> RAOF: even tho its X....that's still weird
<kgunn> unless my theory of 2 fb being available in one frame render is why...
<kgunn> RAOF: at least i know how X should behave :)
<RAOF> Hm, don't know :)
<tvoss_> kgunn, details, perhaps we can file a bug about it
<kgunn> tvoss_: yep..something to chase up with michael
<tvoss_> kgunn, michael?
<kgunn> ok...rebooting to mm for reals (michael=phoronix)
<kgunn> RAOF: tvoss_ ...any of you see the return of the lag?... or kind of, its not global... extended desktop irc in one display..terminal in the other
<kgunn> irc has no lag...but terminal does
<kgunn> lag=typing letter showing up
<RAOF> kgunn: Yeah, duflu was also seeing that (as am I) - https://bugs.launchpad.net/bugs/1216337
<ubot5> Launchpad bug 1216337 in Mir "Client buffers eventually display one frame behind client swap requests" [Undecided,New]
<tvoss_> kgunn, RAOF duflu had the idea that it might be related to buffer age
<kgunn> ok...so for sure i'm xmir-mm...re-ran openarena....
<kgunn> if i'm extended desktop...it treats the 2 displays like 1 surface (i see some render no one screen and some of the other)
<kgunn> and it runs at like 25 fps
<kgunn> if i go to mirror mode....it runs at like 125 fps
<kgunn> and if i turn off one monitor....the benchmark tries to run, but complains about the video mode and "ends prematurely"
<kgunn> RAOF: pastebin.canonical.com/96338/....x crash while turning off second display & going between mirror/extended
<kgunn> EQ overflow (event queue ?)
<kgunn> actually this is consistent...have hdmi connected, extended desktop, turn off the second display via settings...x crash
<robotfuel> kgunn: are you around? did you want me to start a test run on qa ppa2 now?
<xnox> I am using intel graphics, yet when switching to mir, lightdm crashes and I have to comment out "#type=unity"
<xnox> is there any way i can fix that?
<robert_ancell> thomi, is there a way to know who started a jenkins job?
<thomi> robert_ancell: in the job run page, it says "started by <username>"
<thomi> robert_ancell: in the private server anyway, I think that information is stripped on the public instance
<robert_ancell> thomi, right, so on http://10.97.2.12:8080/view/qa-ppa2/job/qa-ppa2-openarena-ps-intel-2500-le/1/ where would I see that?
 * thomi looks
<robert_ancell> thomi, ah I got it
<thomi> yeah, it was started by an upstream job
<robert_ancell> because that job was started by the main job I needed to click that
<robert_ancell> It was started by Chris
<thomi> right, was started by chris
<robert_ancell> They all failed, I'm just wondering if I should be worried by that or it was some sort of test run to check the config was working
<RAOF> kgunn: Hm. Your âEQ overflowâ crash is because Mir isn't responding to a message (again â¹)
<RAOF> Has anyone tested qa-testing2 against nouveau or radeon? I'm just interested to know if my patches work :)
<robert_ancell> RAOF, what's the focus next? ati/nouveu or the lag issue?
<RAOF> Fixing the client-buffer-tracker MP, then probably lag. I don't have the hardware available to test MM on ati or nouveau.
<kgunn> RAOF: robert_ancell can run it against the boston 8
<robert_ancell> kgunn, it's running qa-testing2 now
<kgunn> RAOF:also that EQ overflow only happened once that i caught
<kgunn> every other time....the xorg log just ends....are post-config
<kgunn> but no error complaint
<kgunn> robert_ancell: ack
<kgunn> fingers crossed
<robert_ancell> thomi, it looks like a failure, but I'm not deciphering the build log - http://10.97.2.12:8080/view/qa-ppa2/job/qa-ppa2-openarena-ps-intel-2500-le/2/console
<RAOF> In my experience the Xorg log just ending tends to be unity-system-compositor dying, and one of the mirclient threads noticing then throwing an exception.
 * thomi looks
<RAOF> Of course, because it's on a thread it gets logged nowhere.
<robert_ancell> "Build step 'Execute shell' marked build as failure"
<robert_ancell> 2013-08-25 23:18:32,372 ssh DEBUG: SSH command (/usr/share/utah/client/utah-done.py) failed with return code: 4
<robert_ancell> this might be it
<thomi> robert_ancell: right, it looks to me like the actual test failed
<thomi> no
 * thomi curses utah
<robert_ancell> oh, is it just polling utah - nasty!
<thomi> robert_ancell: if you look at how it's configured, it runs:
<thomi> run_utah_tests.py -d -m physical --name "$machine" -i "$ISO" -p "$PRESEED_FILE" -l $WORKSPACE master.run || RETCODE=1
<thomi> in the log you can see "RETCODE=1"
<thomi> so run_utah failed
 * thomi tries to find out why
<thomi> robert_ancell: it's odd - it looks like the tests are running, because I can see FPS results from the openarena run, but something else is failing
<thomi> but utah is frustratingly useless - gah
<thomi> robert_ancell: the nearest I can make out, the final command in the test script is failing, that is:
<thomi> xrandr | grep -i xmir
<thomi> which I assume is there to make sure we're running xmir
<thomi> so possibly that's the issue here
#ubuntu-mir 2014-08-18
<RAOF> mibofra: Yo!
<RAOF> You are in a twisty maze of classes, all named Surfaceâ¦
<anpok_> Look at implementation
<anpok_> nick anpok
<anpok_> oops
<RAOF> Victory!
<anpok> good that was a short one
<RAOF> In slightly less winning news it seems that my N10 doesn't have enough RAM to build Mir :/
<anpok> we could try gold linker
<anpok> where we means you
<RAOF> Nope; cc1plus gets OOMed.
<anpok> oh
<RAOF> I'll add a bunch of swap, but tomorrow.
<duflu> RAOF: That maze is actually much smaller than it used to be :S
<alan_g> duflu: @"...MIRCOMMON_2. Actually, that's a mistake..." as we've not branched a release why not revert?
<duflu> alan_g: Because it's harmless to keep. Both mirplatform and mirserver are getting correctly bumped in 0.7 anyway
<alan_g> /shrug OK. (It just makes mircommon look less stable than it is)
<duflu> alan_g: Yeah I know but doesn't matter. Users of libmirclient for example (/usr/lib/x86_64-linux-gnu/libgdk-3.so.0) only have linkage to libmirclient.so.* and not its dependencies. So only servers are affected and they need rebuilding anyway
 * duflu tries forcing double buffering on to Unity8 to see what happens
<Chipaca> is mirping/mirscreencast segfaulting known, or should I file a bug?
<Chipaca> this is on mako, image 195
<duflu> Chipaca: Doesn't sound familiar. If in doubt then log a bug
<Chipaca> https://bugs.launchpad.net/mir/+bug/1358191
<ubot5> Ubuntu bug 1358191 in Mir "mirping, mirscreencast segfault" [Undecided,New]
 * alan_g wonders why he suddenly sees a load of signed/unsigned comparison errors in test_stream_transport.cpp when cross-compiling
<anpok> alan_g: hm wrong/outdated gtest headers
<anpok> in partial chroot
<anpok> in chrott/usr/src/gtest or gmock sth..
<alan_g> anpok: Hmm. Thanks for the suggestion (I thought I'd updated but...)
<anpok> yes but the old one might not have been removed
<anpok> at least that was my mileage
<alan_g> anpok: my mileage too. :)
<kdub> anyone seeing anything like [libprotobuf ERROR google/protobuf/descriptor_database.cc:57] File already exists in database: mir_protobuf_wire.proto
<kdub> in the demo servers?
<alan_g> kdub: I've seen it in an MP - not reproduced yet
<alan_g> https://jenkins.qa.ubuntu.com/job/mir-team-mir-development-branch-utopic-amd64-ci/937/console
<kdub> yeah, I'm seeing it when starting a demo server, let me see if I can reproduce that test failure
<kdub> yeah, I see it there too
 * alan_g wonders why he can't reproduce
<kdub> I'm kinda suspecting a protobuf upgrade happened? still chasing that theory though
<kdub> oh, nvm, an older revision of mir was okay
<kdub> robotfuel, is ~chris.gagnon/+junk/mir-demo-runner the python script that runs the demo programs in CI?
<robotfuel> kdub: no that is the old script
<kdub> robotfuel, ah, where's the new one?
<robotfuel> kdub: lp:~mir-team/+junk/mir-medium-test-runner-for-jenkins
<kdub> robotfuel, ah, thanks
<robotfuel>  I was hunting before you asked :D
<kdub> robotfuel, right, but that installs a mir-demo-tester
<robotfuel> kdub: http://bazaar.launchpad.net/~mir-team/+junk/mir-medium-test-runner-for-jenkins/view/head:/mir_install_packages.sh has the distupgrade you don't want ?
<kdub> robotfuel, no, I'm just trying to do a post-mortem on a regression bug, and want to know which of the demo servers the jenkins job runs
<robotfuel> kdub: mir_integration_tests mir_acceptance_tests mir_demo_client_basic mir_demo_client_fingerpaint mir_demo_client_eglflash mir_demo_client_eglplasma mir_demo_client_multiwin mir_demo_client_egltriangle mir_performance_tests
<robotfuel> kdub: that's part of the jenkins job
<kdub> robotfuel, right, but the mir_demo_client_* surely run against one of the demo servers
<kdub> http://bazaar.launchpad.net/~chris.gagnon/+junk/mir-medium-test-runner-for-jenkins/view/head:/mir_install_packages.sh
<robotfuel> kdub: http://bazaar.launchpad.net/~mir-team/+junk/mir-medium-test-runner-for-jenkins/view/head:/mir-mediumtest-runner.sh line 194
<kdub> like, it runs phablet-test-run against a 'mir-demo-tester' http://bazaar.launchpad.net/~chris.gagnon/+junk/mir-medium-test-runner-for-jenkins/view/head:/mir-mediumtest-runner.sh#L178
<kdub> oh, so switching to the same repo :)
<robotfuel> kdub: phablet-test-run -x just executes a command on the phone and gets the return code.
<kdub> sure, and the command it runs is this mir-demo-tester
<kdub> which isnt part of the mir scripts
<robotfuel> kdub:  ah http://bazaar.launchpad.net/~chris.gagnon/+junk/mir-demo-runner/files
<robotfuel> http://bazaar.launchpad.net/~chris.gagnon/+junk/mir-demo-runner/view/head:/bin/mir-demo-tester
<kdub> robotfuel, ah, yes
<kdub> looks like what I was looking for, thanks
<alan_g> kdub: the protobuf error -  do you get that on mesa or android? (Or both) Default build options?
<kdub> alan_g, i got it on android, but interestingly the process of bisecting fixed it even on tip
<kdub> so maybe some sort of problem mixing-and-matching libraries
<alan_g> kdub: that was my growing suspicion - but CI ought to be a clean env
<kdub> yeah, it should be...
<alan_g> quite...
<racarr_> morning
<mibofra> hi kdub
<tedg> So it's looking like there's an error in qtmir when a prompt session is put on top of another prompt session.
<tedg> qtmir.surfaces: MirSurfaceManager::refreshPromptSessionSurfaces - No Application for prompt session
<tedg> greyback_, Any ideas there? ^
<tedg> Or perhaps dednick ^
<greyback_> tedg: dednick would be better
<dednick> tedg: what are you doing in the trust helper? what does trust session on trust session mean?
<tedg> dednick, Dash â Pay UI â Online Accounts
<tedg> dednick, So someone purchases something, and before we can process they need to login to Ubuntu One.
<tedg> dednick, So the OA trusted prompt session needs to overlay on Pay UI.
<tedg> dednick, Which is, itself a trusted prompt over the dash.
<dednick> tedg: is it multiple prompt providers or multiple prompt sessions?
<tedg> dednick, both
<dednick> tedg: we don't support multiple prompt sessions.
<dednick> yet
<tedg> dednick, When do you expect to?
<dednick> tedg: there is no eta on it. there wasn't supposed to be a requirement for it yet.
<dednick> tvoss: ^
<tvoss> dednick, you mentioned multiple prompt sessions could easily be supported, modulo trust-store support for that
<tvoss> dednick, as ted's part does not use the trust-store, we could easily unblock him here and I'll take care of the trust-store side of things
<tvoss> greyback_, thoughts?
<dednick> tvoss: yeah, we can remove the guard against it easily enough
<greyback_> tvoss: sounds do-able, just requires more careful book-keeping in qtmir
<tvoss> tedg, so: do you need this?
<dednick> tedg: what pid are you providing the online ui?
<dednick> OA ui i mean
<tedg> tvoss, Yes, we kinda do.
<tedg> dednick, I'd have to check with mardy, but the request he's getting is from Pay UI, so I imagine that's the PID he's giving.
<tvoss> dednick, greyback_ with that: go :)
<tvoss> dednick, greyback_ obviously, if we find an easier way: even better
<greyback_> could someone please log a bug against qtmir with the exact requirements? Just to track the task
<tedg> K, I can do that.
<dednick> tedg, mardy: a prompt session will only be overlayed on a application in unity8.
<tedg> dednick, Okay, so we need to add a unity8 task as well then?
<dednick> tedg: presumably there's no application related to the OA? it's just the prompt you want?
<tedg> dednick, In this case, yes.
<dednick> tedg: then the prompt session must be given the pid of the dash in this case (same as the payment prompt session)
<tedg> dednick, That's going to be difficultâ¦ can you just go up the tree in Mir until you hit an application?
<dednick> tedg: if you want something overlayed on an app, we need the pid of the app.
<tedg> dednick, I want it overlayed on the prompt provider.
<tedg> dednick, greyback_, bug 1358388
<ubot5> bug 1358388 in QtMir "Trusted Prompt Sessions should be able to be on a Trusted Prompt Provider" [Undecided,New] https://launchpad.net/bugs/1358388
<mibofra> kgunn, hi
<kgunn> mibofra: hi
<mibofra> kgunn, after Friday I've done some more debug, and I've found what's of the mir's setup goes in segfault
<mibofra> kgunn, it seems the spinner
<kgunn> damn the spinner :)
<kgunn> mibofra: i think there's a fix for that working its way through the wickets
<mibofra> uhm
<kgunn> if you take the devel-proposed image it should most likely be in that
<kgunn> AlbertA: ^ i'm not making that up am i?
<mibofra> kgunn, and it seems to be the same reason of the segfault of some of the egl tests
<mibofra> *the not working ones
<mibofra> I'm retuning (one second that I put an antenna on the 3G modem)
<mibofra> ok now I've a connection that can be called a connection
<mibofra> kgunn, anyway that's the log: http://paste.ubuntu.com/8082137/
<kgunn> camako: ^ check that out
<kgunn> seems like a race
 * camako looks
<kgunn> mibofra: so tell me again, what hw & sw configuration are you on ?
<mibofra> (lol, anyway ok)
<mibofra> kgunn, the hw is a samsung galaxy s3 phone (gt-i9300), the host system is android (cyanogenmod 11). Ubuntu touch is in chroot. The systems shares the hw on the phone. So simply I kill the services (such as surfaceflinger, or wpa_supplicant on the host system) and load the ones in ubuntu, so I route the functions to it.
<mibofra> In fact, network manager and pulse for example work. When I've to use android simply I do the opposite (kill the services on ubuntu and restart the on android)
<mibofra> anyway, because the devices are shared, for example, if I setup the connectivity on andorid or ubuntu, I can use the iface with the same ip and setup on both the systems
<mibofra> Example: android setups a connection to my ap with ip 192.168.1.4, if I do an ifconfig on the chroot system (ubuntu) I see the iface with that ip and I can use ping, wget and more
<mibofra> Ex. of the opposite: if I run xboxdrv for my wireless xbox controller, under the chroot system, I can use it on android too
<mibofra> kgunn, was I clear or do you need other informations :) ?
<mibofra> Simply I'm trying this solution to don't do a porting of ubuntu touch. If this works, more or less also my tablet and other arm7 devices should run ubuntu touch in the same way
<AlbertA> kgunn: umm I
<AlbertA> I'm not sure I don't recall a fix for setup
<mibofra> AlbertA, just if you're curios to see my problem: http://paste.ubuntu.com/8082137/
<AlbertA> what's the stack trace for the segfault?
<mibofra> AlbertA, that's the only output form logcat http://paste.ubuntu.com/8082278/
<AlbertA> mibofra: I mean run the client with gdb
<mibofra> ah ok
<AlbertA> then do bt for the stack trace after segfault
<mibofra> AlbertA, I've to install the debug symbols, just a minute
<mibofra> AlbertA, I can't find a package for the debugging symbols of the spinner, I've to recompile all the compositor+spinner to get a copy with the debug symbols?
<AlbertA2> mibofra: https://wiki.ubuntu.com/DebuggingProgramCrash#Debug_Symbol_Packages
<mibofra> thanks
<mibofra> AlbertA2, I'm pass to the shell gdb /usr/bin/unity-system-compositor-spinner, run with run -m /run/mir_socket because I've the socket there, but I get: Cannot exec /usr/bin/unity-system-compositor-spinner -c exec /usr/bin/unity-system-compositor-spinner -m /run/mir_socket.
<AlbertA2> mibrofra: what about just the demo server and clients?
<AlbertA2> mibofra: apt-get install mir-demos
<AlbertA2> then stop lightdm
<AlbertA2> and do a mir_demo_server_basic on one terminal
<AlbertA2> and mir_demo_server_egltriangle in another
<AlbertA2> started with gdb
<mibofra> AlbertA2, I've the demos and the clients, lightdm is stopped already. The only client that works is the render_to_fb. The egltriangle and similar go as the spinner in segfault.
<mibofra> anyway I'll try to debug them
<AlbertA2> right,
<AlbertA2> so I'm trying to get at the stack trace
<AlbertA2> with egltriangle
<AlbertA2> just to see what's failing
<AlbertA2> there
<mibofra> ok
<mibofra> let's try
<mibofra> AlbertA, Cannot exec /usr/bin/mir_demo_client_egltriangle -c exec /usr/bin/mir_demo_client_egltriangle .
<mibofra> Error: No such file or directory
<mibofra> with a gdb /usr/bin/mir_demo_client_egltriangle and into gdb a run
<mibofra> AlbertA2
<AlbertA2> try without the full path
<mibofra> ok I saw netsplitted, fantastic
<mibofra> *was
<mibofra> uhm AlbertA2 maybe I can solve the gdb problem
<AlbertA2> ok
<mibofra> ok AlbertA2 I've solved it
<mibofra> so I've debugged the spinner
<mibofra> AlbertA2 the stack: http://paste.ubuntu.com/8082638/
<AlbertA2> how about egltriangle?
<mibofra> AlbertA, that's all the out for the spinner, http://paste.ubuntu.com/8082645/. Ok now I'll try with the egltriangle
<mibofra> AlbertA2, http://paste.ubuntu.com/8082652/ the same
<AlbertA2> umm so it doesnt say who is calling strerror
<AlbertA2> I guess then can you try running the client with valgrind?
<mibofra> I think yes
<mibofra> AlbertA, the spinner http://paste.ubuntu.com/8082700/ the egltriangle http://paste.ubuntu.com/8082704/, in all this think that the only demo that I can see an output on the screen is the render_to_fb
<AlbertA2> mibofra: so you installed the dbg symbols for libmirclient8?
<mibofra> AlbertA2, I think so
<mibofra> let's see
<mibofra> AlbertA2, installed
<AlbertA2> well it offers no real clues...:)
<AlbertA2> other than maybe the android driver blob is failing
<AlbertA2> and it hitting a code path that has bugs in it
<AlbertA2> :)
<AlbertA2> I mean the sig fault is originated by libcutils which is an android library
<mibofra> AlbertA2, I've installed them after I've written installed XD
<AlbertA2> oh
<AlbertA2> and do you get a fuller stack trace?
<mibofra> the debug symbols for libmirclient8
<mibofra> let's see
<mibofra> AlbertA2, I'm trying with the spinner, from gdb I've the same output as before.
<mibofra> AlbertA2, valgrind for the spinner but I think it's the same as before too: http://paste.ubuntu.com/8082787/
<mibofra> AlbertA2, but I wonder why the render_to_fb demo works
<mibofra> :D
<AlbertA2> well its not going through the client for one
<AlbertA2> the client driver context may be having the failure
<AlbertA2> what does dmesg say?
<AlbertA2> anything related to the display driver or gpu driver?
<mibofra> AlbertA2, http://paste.ubuntu.com/8082851/ that's the dmesg
<mibofra> try grepping something
<mibofra> maybe it will seem more useful for you than me
<mibofra> AlbertA2, anyway I think, I've xorg working fine, if I use mir as sys compositor with x as described here: http://unity.ubuntu.com/mir/using_mir_on_pc.html can I use unity8 on it?
<mibofra> (only a curiosity)
<AlbertA2> mibofra
<AlbertA2> mibofra: if you get the examples working
<AlbertA2> then most likely unity8 will run fine
<mibofra> AlbertA, can they be executed with mir working as compositor of X?
<AlbertA2> mibofra: well unity8 acts as a client of mir
<mibofra> so ok
<AlbertA2> well technically a nested server
<mibofra> ah
<AlbertA2> a server that is actually a client of the main system compositor mir
<AlbertA2> mibofra: well nothing stands out in the dmesg output...
<mibofra> ok
<AlbertA2> mibofra: I guess the next thing you could do is step through the egltriangle client... to see if you can narrow down where it crashes
<mibofra> ok
<mibofra> AlbertA, anyway thank for the time you spend with me :)
<mibofra> (maybe you had something more interesting/important to do)
#ubuntu-mir 2014-08-19
<alan_g> https://isocpp.org/blog/2014/08/we-have-cpp14
<duflu> alan_g: I shall contain my enthusiasm :)
<alan_g> duflu: the thing I want most is a sensible "modules" proposal - and that's targeting C++17
<duflu> Heh
<duflu> I hope by then people wanting a very high level complex language will have even more options than today
<alan_g> I fear you're right. (But think there are too many wheels of slightly different colours and shapes already)
<duflu> OK, running out of time in the day, so maybe another smallish bug fix
<duflu> Has anyone talked about getting newer kernels for our devices? (e.g. Nexus 4 is kernel 3.4). These older kernels have much higher latency than what's in the distro
<RAOF> Also interesting: https://isocpp.org/blog/2014/05/n4028
<mibofra> AlbertA2, hi :), today I'll try recompiling mir and compositor
<AlbertA2> mibofra: ok
<bschaefer> is mir_demo_server_shell broken/changed in mir/devel recently? It just ends right after starting it now.
<bschaefer> All gdb says is "Got object file from memory but cant read symbols: File truncated."
<bschaefer> this is on a fresh rebuild from trunk mir/devel on a recent upgrade in utopic
<bschaefer> server_basic works though
#ubuntu-mir 2014-08-20
<RAOF> Huh.
<RAOF> ProtobufMessageProcessor really is entirely untested.
<duflu> Why is it "bzr log FILE" often shows revisions that have nothing to do with FILE?
<RAOF> It does?
<duflu> RAOF: Yes, more often than not. So bzr log FILE is mostly useless
<duflu> Seems like a bug
<duflu> If I analyse the revisions it gives me then FILE is not in them
<RAOF> Huh. Do you have an example file? I've never seen that.
<RAOF> (And I do occasionally do bzr log FILE)
<duflu> RAOF:  bzr log src/shared/protobuf/mir_protobuf_wire.proto
<RAOF> Hm, quite true.
<RAOF> Odd.
 * duflu experienced git again for the first time in a long time last night. It was nice :)
<tkamppeter> I have submitted a MIR for the "brlaser" printer driver package (bug 1359137). I would like to get it in before FF. The package is super simple and small. Could this be done? I have already posted on #ubuntu-release but did not get any answer.
<ubot5> bug 1359137 in brlaser (Ubuntu) "[MIR] brlaser" [High,New] https://launchpad.net/bugs/1359137
<tkamppeter> I hope this is about "Main Inclusion Request", if not, tell me which channel is the correct one.
<greyback> tkamppeter: this channel is about Mir, the display server, not MIRs
<greyback> tkamppeter: #ubuntu-devel probably better channel
<alan_g> kdub: when you could reproduce lp:1358698 - was it on desktop or phone?
<kdub> alan_g, it was on phone
<kdub> and I tried bisecting, but at some point the process of updating binaries fixed the problem for me
<kdub> i can see if i can reproduce again, seems its giving us a headache
<alan_g> kdub: I remember that - just wasn't sure where you were running it
<alan_g> kdub: BTW welcome back - I trust you're fully recovered>?
<kdub> alan_g,  yeah, enough that cold/flu medicine takes care of the remaining symptoms
<tkamppeter> greyback, OK.
<alan_g> does anyone know why we dlopen our platform plugins with RTLD_GLOBAL when we're going to use dlsym to resolve the symbols?
 * alan_g sees that bzr says alf_ wrote that.
<AlbertA2> alan_g: I think I tried removing it once
<AlbertA2> and I got loading errors in unity8
<AlbertA2> but I can't remember for sure
<AlbertA2> I vaguely remember something to do with the fact that unity-mir is also loaded at runtime
<alan_g> AlbertA2: It seems strange, but I can wait for an explanation (as it isn't causing the problem).
<alan_g> I hope
 * alan_g is glad he's not the only one to ever wonder
<greyback> AlbertA: unity-mir dead. Qtmir (its replacement) is not dl-loaded
<AlbertA2> greyback: right...I was just recalling some months ago when I tried removing RTLD_GLOBAL
<AlbertA2> but there may be some other reason it's there
<AlbertA2> racarr_: thanks for the help, worked like a charm :) https://code.launchpad.net/~albaguirre/mir/fix-1359264/+merge/231584
<greyback> AlbertA: gotcha
<AlbertA2> greyback: oh I wanted to ask you where in qtmir is the wait for first frame? curious...
<greyback> AlbertA: http://bazaar.launchpad.net/~mir-team/qtmir/trunk/view/head:/src/modules/Unity/Application/mirsurfaceitem.cpp#L384
<greyback> AlbertA: which is called by a Mir SurfaceObserver::frame_posted
<greyback> http://bazaar.launchpad.net/~mir-team/qtmir/trunk/view/head:/src/modules/Unity/Application/mirsurfaceitem.cpp#L226
<AlbertA2> thanks!
<greyback> we then have code in MirSurfaceManager to only add the surface to the scene once the first frame is posted
<AlbertA2> greyback: and is there an easy way to cross-compile qtmir?
<greyback> AlbertA: I sbuild it usually
<greyback> or else develop on device, since it's pretty small :)
<AlbertA2> so qmake and then make?
<greyback> hang on, you need to be careful to use gcc4.9
<greyback> qmake "QMAKE_CXX=arm-linux-gnueabihf-g++-4.9" "QMAKE_LINK=arm-linux-gnueabihf-g++-4.9" "QMAKE_LINK_SHLIB=arm-linux-gnueabihf-g++-4.9"
<greyback> then make
<greyback> make install
<AlbertA2> ahh thanks!
 * alan_g has managed to reproduce bug 1358698 (and it's only Wednesday!)
<ubot5> bug 1358698 in Mir "[regression] Test failure holding up all merge proposals: File already exists in database: mir_protobuf_wire.proto" [Critical,In progress] https://launchpad.net/bugs/1358698
<kdub> alan_g, yay
<alan_g> kdub: I got excited too soon. It happened twice - now with the same *binaries* I can't reproduce.
<kdub> hmm, so a fun transient problem
 * kdub goes on the case too
<alan_g> kdub: I have a theory about the time I got it...
<alan_g> The test discovery code died with it
<alan_g> and that ran *before* the libmirplatformgraphics library was created
<kdub> missed something, before the library was created?
<alan_g> so if we load a libmirplatformgraphics which depends upon a *different* version of libmircommon
<alan_g> yes
<alan_g> There's no dependency in cmake on the platformgraphics library
<alan_g> Because that is dlopened
<alan_g> and no-one added a rule
<alan_g> so if we load a libmirplatformgraphics which depends upon a *different* version of libmircommon
<alan_g> then we could be getting two versions of libmircommon in memory
<alan_g> *BOOM*
<alan_g> But that timing doesn't explain all the CI failures
<kdub> yeah, its a reasonable explanation, but I don't see how the problem could be transient
<alan_g> Once the libmirplatformgraphics has been built the problem goes away
<alan_g> as we pick up the right one
<alan_g> Anyway, if that is actually the cause then the latest rev of this ought to pass CI: https://code.launchpad.net/~alan-griffiths/mir/integration-and-unit-tests-link-against-internals/+merge/230810
<racarr_> AlbertA2: Yay :) will review
<racarr_> *
<racarr_> whoops
<alan_g> But it doesn't (yet) explain why CI consistently goes wrong and we have a rare intermittent.
<kdub> maybe its a fresh install everytime? (trying to think what that could change)
 * alan_g is tempted to revert -c1846 just to see if that masks the problem
<alan_g> kdub: another MP may shed light (but I expect it to eliminate an idea, not provide a solution): https://code.launchpad.net/~alan-griffiths/mir/fix-1358698/+merge/231423
<alan_g> but I'm hitting EOD and hope it to be solved when I get into work tomorrow. ;)
<AlbertA2> greyback: what's your incantantion for sbuild - it keeps failing here on getting the dependencies
<greyback> AlbertA: hmm let me check here first. I usually do "sbuild -c utopic-amd64-armhf --host=armhf -j3" ut it's been a while
<greyback> AlbertA: failed for me on g++4.9 - same for you? I had hoped that was fixed by now.
<AlbertA2> greayback: yeah
<greyback> https://bugs.launchpad.net/ubuntu/+source/mir/+bug/1353855
<ubot5> Ubuntu bug 1353855 in unity8 (Ubuntu) "Explicit g++ 4.9 dependency breaks cross-building" [Undecided,New]
<greyback> I can't recommend anything else except working on device, sorry
<AlbertA2> greyback: thanks...
<AlbertA2> greyback: though for me is failing on mor than just g++4.9: http://paste.ubuntu.com/8099543/
<AlbertA2> which makes me think I'm missing something else as well
<racarr_> you could install the needed dependencies
<greyback> hmm. My output for comparison, in case it helps: http://pastebin.ubuntu.com/8099553/
<racarr_> in a prepopulated sbuild
<racarr_> and then remove all the build-deps from debian/rules before running sbuild
<racarr_> lol...
<racarr_> ridiculous of course but its become
<greyback> back in your cage you!
<racarr_> really hard to build on device imo
<racarr_> there is barely enough space
<racarr_> for mir/qtmir build deps
<racarr_> anymore
<greyback> true, I just about squeeze it in these days
<racarr_> and last time I actually only managed to do it by manually deleting a bunch of stuff from /usr/lib lol
<racarr_> but I think I had some stuff
<racarr_> left over too
<greyback> apt-get clean if your friend
<racarr_> lol
<racarr_> I know even with rming /var/cache/apt/archives
<racarr_> though
<racarr_> unless apt-get clean does more
<greyback> think it's the same
<racarr_> lol, anyway, I hope we can make sbuild work...
<greyback> it's been like that for >1 month now
<greyback> it'll probably go away if 4.9 made default
<AlbertA2> umm the weird part is g++-4.9 is already installed in the chroot
<racarr_> it's the cross compile chain v. armhf binary or some such right?
<racarr_> (it's->the problem is)
<mibofra> AlbertA2, hi :D, recompiling mir wasn't successful xD. And I think you (you as the developers/engineers of the mir's team) do not want to support a chroot environment XD .
<AlbertA2> mibofra: log?
<AlbertA2> racarr_: oh yeah...
<mibofra> AlbertA, the same results of the demos provided by executables on the packages, do you remember them?
<AlbertA2> mibofra: oh so you were able to compile fine, just failure at run time again?
<greyback> AlbertA: the amd64 g++ is installed, but it's trying to install the armhf one. I tried this cheeky patch: http://pastebin.ubuntu.com/8099582/ but it failed further on with qmake not being found (wrong arch installed)
<mibofra> yeah AlbertA2, apart from a compiling issue that I had to fix (the system was an make's assassin xD, so I've free other sources for make and it (make) ran fine).
<AlbertA2> mibofra: well if you can step through the egltriangle example with gdb
<AlbertA2> mibofra: since the stack trace was pretty useless
<AlbertA2> mibofra: it could help us narrow down the issue...
<mibofra> yeah it was, let's see
<AlbertA2> kgunn_: was there a bug# for the dash flash when opening apps?
<kgunn_> uh yeah, i know daniel logged one....lemme look
<mibofra> AlbertA2, apart form the stacks what do you find useful/ do you need/ do you debug usually?
<AlbertA2> logcat and dmesg...specially if it's a driver issue...
<AlbertA2> but in your case it's a client side issue...
<mibofra> AlbertA2, we've seen the dmesg, the output of logcat it's regular http://paste.ubuntu.com/8100365/
<AlbertA2> right...
<AlbertA2> so stepping through does not help?
<kdub> our mp's are outta control
<AlbertA2> kdub: only 24... ;)
<AlbertA2> greyback: so it was indeed the first blank frame causing the dash flash
<AlbertA2> greyback: https://code.launchpad.net/~albaguirre/qtmir/ignore-first-frame/+merge/231612
<greyback> AlbertA2: yep saw that, but I'm very curious why Mir gives us a "frame drawn" notification, and the first frame we pull is not drawn to
<AlbertA2> greyback: I seem to recall, but not entirely sure
<AlbertA2> that we are getting a swap buffers from qt...without actual content...so the framework just goes through the motions...
<AlbertA2> but I have to check again...so much has changed
<racarr_> lol CI went on a crazy run through everytrhing
<mibofra> AlbertA2, I've to try every option of gdb xD but if you want I can setup an ssh access so you can try other things (if you want).
<AlbertA2> greyback: or it could just be the driver doing that as well...
<greyback> AlbertA2: it's Mir's job to try isolate me from driver quirks :)
<AlbertA2> mibofra: well if you could narrow it down to a top level call at least, to see if it's just driver setup or a call in mir
<greyback> AlbertA2: I'm not against the patch, but IMO it needs a big FIXME/HACK comment and an associated Mir bug
<AlbertA2> greyback:  :)=
<greyback> AlbertA2: you're sure skipping just 1 frame is enough?
<AlbertA2> greyback: yeah I'll dig deeper but for now that should do...
<AlbertA2> greyback: yeah it's only the first frame... I tested on n10 and others
<AlbertA2> greyback: well the thing I'm not sure it's a mir bug yet, like I said, I think alan or alf suspected Qt calling swap_buffers
<AlbertA2> before rendering any content at the begninning
<AlbertA2> but this was some months ago
<greyback> AlbertA2: hmm first I've heard of that. Is possible
<mibofra> AlbertA2, a thing, if you want I can say to you how I've setup my chroot (enviroment)
<AlbertA2> mibofra: sure
<mibofra> *environment
<mibofra> AlbertA2, so you can maybe reproduce it and test it yourself
<mibofra> AlbertA2, initially I've used this project: http://botbrew.com/ , and this app https://play.google.com/store/apps/details?id=com.botbrew.basil (with source on https://github.com/jyio/botbrew-gui). Basically it bootstrap a copy of emdebian (not even developed form july), and automatize the chroot process, binding /dev /sys /proc ecc.., so it's simple to replace emdebian with ubuntu touch or other systems.
<mibofra> I had some issues with use some functions of the app, like install some parts of emdebian, some parts required some manual interventions that couldn't be done except from an shell with adb or a terminal emulator.
<AlbertA2> greyback: so yeah it was a bug in mir: https://bugs.launchpad.net/mir/+bug/1359406
<ubot5> Ubuntu bug 1359406 in Mir "mir should not composite/display buffers when an android driver calls ANativeWindow::cancelBuffer" [Critical,Triaged]
<AlbertA2> mibofra: ok... but what is the initial platform?
<mibofra> but ubuntu touch it's basically complete for use, so you don't need to fix nothing apart from manually replace the emdebian with ubuntu touch
<mibofra> AlbertA2, I really didn't understand you with this question lol
<mibofra> what do you mean?
<AlbertA2> mibofra: is it a rooted android phone? or you already have ubuntu touch running on it? or something else?
<mibofra> AlbertA2, I've said it before, it's an android (cyanogenmod 11) rooted phone.
<AlbertA2> oh I see...and android app
<AlbertA2> ok...
<AlbertA2> mibofra: so the app does all the setup for you?
<AlbertA2> mibofra: nothing else needed?
<mibofra> AlbertA2, anyway basically only mir doesn't work, pulse works, network manager too, dbus too
<mibofra> AlbertA2, yeah it's much less work to do. You've only to use the first option of the app
<racarr_> Your problem could relate to...well...
<racarr_> if the app is for running debian
<racarr_> I dont see why it would bother setting up the appropriate
<racarr_> symlinks for /system
<racarr_> to the androit root...
<AlbertA2> racarr__: but render_to_fb is working though
<racarr_> ah damnit
<AlbertA2> racarr__: so the server seems ok
<racarr_> lol
<AlbertA2> it's the client driver context
<mibofra> AlbertA2, the deployed system will be under /data/botbrew-basil in default
<racarr_> I was going to guess wrong libGL
<racarr_> :(
<racarr_> hmm
<AlbertA2> that crashes
<racarr_> I wonder if ubuntu touch runs natively on the device
<racarr_> e.g. community port
<AlbertA2> mibofra: have you tried runing the egltriangle example with sudo?
<AlbertA2> just to rule out permission issues
<racarr_> ohhh there isa theory
<AlbertA2> mibrofra: ok and then you chroot into that dir?
<mibofra> racarr_, the server can load the necessary libraries, http://paste.ubuntu.com/8101160/ and the demo render_to_fb works and I can see the output on the screen.
<mibofra> AlbertA2, basically I work with root only at the moment
<AlbertA2> mibofra: ok..
<mibofra> even if I can add and login with normal users
<mibofra> racarr_, there is a port of utouch for my phone (the gt-i9300), without ril support but there is. Anyway the logic is that if I can run ubuntu touch in this way, every user of an arm7 phone/tablet will be able to use ubuntu touch without porting it.
<racarr_> mm would be neat
<mibofra> (anyway the porting for my phone it's discontinued xD )
<mibofra> racarr_, and I like the concept to put an hdmi adaptor, a pair of bluetooth keyboard and mouse and see unity on the screen of my lcd hd TV and use my phone as my desktop pc xD
<mibofra> racarr_, yeah think about this, you deploy ubuntu touch under android, and use it without porting and maybe switch between the os by a script that route the hw (start/stop the services on both the os) and you can "dualboot" without rebooting the phone
<AlbertA2> mibofra: motorola did that actually a few years ago :)
<mibofra> racarr_, and the devices are shared with both the so, so for example, I've used xboxdrv to use the wireless xbox receiver and controller and android seen it and I can use it on android. Or ubuntu touch can use the fm receiver or the nfc chip without developing the support for each device.
<mibofra> AlbertA2, yeah and I think it's an intelligent thing
<mibofra> AlbertA2, an maybe less pain for you devs/engineers, basically with this approach every arm7 device that runs andorid it's virtually supported
<mibofra> :)
<AlbertA2> mibofra: well that's the approach we take already...we use the android binary blobs
<AlbertA2> for modem, display, etc...
<AlbertA2> but the devil is on the details...
<AlbertA2> specially display drivers
<AlbertA2> they all have different caveats/bugs...
<mibofra> AlbertA2, yeah xD . And I hate a thing
<mibofra> Basically every linux system can mange the modules with modprobe and the other tools
<mibofra> on /system/lib there are the libs ok but there isn't the index lib as on every linux system
<mibofra> so if you try a modprobe module that's the response: modprobe: ERROR: ../libkmod/libkmod.c:557 kmod_search_moddep() could not open moddep file '/lib/modules/3.0.64-CM-g8245168/modules.dep.bin'
<AlbertA2> well that's an android thing
<mibofra> ok AlbertA2 but why don't use an "tested" approach of the modules managing?
<AlbertA2> I guess that's a google question :)
<mibofra> AlbertA2, I think they have fun to see the devs imprecate porting android on other devices that aren't the nexus series xD.
<mibofra> AlbertA2, just a thing I've remembered, where is gone ubuntu for TVs?
<mibofra> just to curiosity (yes I'm curious)
<AlbertA2> mibofra: I don't know...that's more of a roadmap question...
<mibofra> *for
<mibofra> ok
<mibofra> AlbertA2, anyway I'm here if you have any ideas.
#ubuntu-mir 2014-08-21
<duflu> RAOF: I've landed as much as I safely can, manually. But there's reasonable evidence people stop doing reviews when Jenkins gives spurious "Needs fixing"... https://code.launchpad.net/mir/+activereviews
<RAOF> duflu: Yeah, I'm on it.
<duflu> Although presently the problem might not be spurious. It might be our fault
<rsalveti> AlbertA: https://bugs.launchpad.net/ubuntu/+source/unity-system-compositor/+bug/1359530
<ubot5> Ubuntu bug 1359530 in unity-system-compositor (Ubuntu) "Device trying to suspend when screen is turned off by proximity sensor (during a call)" [High,Confirmed]
<RAOF> BAH!
<RAOF> Commit before pushing, push before rerunning the tests!
 * RAOF does his bit to ensure that the mako test devices stay nice and warm
 * RAOF decides that actually landing privatise-all-the-things so that libmirserver25 is coinstallable with libmirserver24 is a better use of time than futzing with mir_install_packages.sh to work around that problem.
<alan_g> duflu: @~vanvugt/mir/revert-to-r1831 we think alike - that was the next thing I was going to try. Bisecting via CI is going to be slow though.
<duflu> alan_g: Faster than not doing it I guess
<alan_g> yeah
<duflu> Huh. We release Mir debs for arm64. Is there any hardware other than the build machine we could run these on?
<alan_g> Not in my office but I get the impression that we default to releasing for any platform that exists in archive.
<alan_g> duflu: I've worked out a way to replicate the symptoms. Just not sure how it can be affecting CI. Got headspace to listen?
<alan_g> I start by removing the libmirplatformgraphics.so in lib
<alan_g> Then when running e.g. mir_integration_tests the ambient version of libmirplatformgraphics.so is picked up.
<alan_g> So mir_integration_tests links to a local libmircommon.so.2
<alan_g> But the ambient version of libmirplatformgraphics.so links to a global libmircommon.so.1
<alan_g> And and two different libmircommon.so.* both tryt to register wit libprotobuf
<alan_g> And that gives us "libprotobuf ERROR..."
<alan_g> The question therefore is: could we pick up the wrong libmirplatformgraphics.so in CI?
<duflu> alan_g: Sounds obvious then if there are two libmircommon.so*
<duflu> alan_g: Oh, ambient means system installed?
<alan_g> yea
<duflu> alan_g: This sounds like a continuation of that "how did USC build when it should have failed" discussion. The CI system is probably using too much of the installed system over the new Mir being built and tested.
<alan_g> I'm tempted to revert -c 1846 to see if that picks up the new libmircommon
<duflu> Can we force the environment of phablet-test-thingy to look in the newly built lib/ first?
<duflu> Because it really should
 * duflu is distracted exploring the bleeding edge phone image
<alan_g> I'm sure we can. (Might need to bully ci-eng)
<duflu> alan_g: Similarly, teach them to set up PKG_CONFIG_PATH environment correctly for USC/qtmir silo builds
<duflu> If that is them
 * alan_g isn't sure if there is a "them" and not loads of well meaning passers by
 * duflu assumes there are CI Gnomes somewhere who know how things work
 * alan_g used to think that until he went spelunking through some build problems
<alan_g> Anyway, I've got my day ahead to pursue this idea. Thanks for listening
 * alan_g decides trying to dlopen "libmirplatformgraphics.so" is probably a bad idea when we ought to care about getting the one we're testing.
<anpok_> alan_g: i was just able to reproduce the issue
<anpok_> .. well .. i did not try to ..
<anpok_> and in my case it is caused by broken relative link support.. so it cannot pick libmirplatformgraphics.so so i guess it takes the older one in /usr/lib ..
<anpok_> alan_g: just as you said because it opens libmirplatformgraphics.so and failes to do because of the broken link it pulls in the systems libmircommon: http://paste.ubuntu.com/8105879/
<alan_g> anpok_: That gives the same symptoms - I've yet to prove it is the same thing as happens in CI.
<anpok_> hmm yes .. it could be because, as you said link against the system mircommon .. or like in the vm load the wrong platformgraphics.so hmm
<alan_g> anpok_: it is a very plausible theory. (And I believe it.) But I'm awaiting proof from CI before claiming it as a solution.
<alan_g> anpok_: this "broken relative link support" - is that specific to the emulator, or could it be affecting phone images?
<alan_g> Specifically the makos in CI
<anpok_> alan_g: special to the 9p virtual file system.. it seems to fail exposing links to the virtual machine
<alan_g> Thanks. I'm still trying to understand the exact failure mechanism in CI.
<robotfuel> kgunn: can you have someone look at this mir bug, I am not sure if it's qtubuntu, mir, or platform api https://bugs.launchpad.net/mir/+bug/1358874
<ubot5> Ubuntu bug 1358874 in mir (Ubuntu) "/usr/bin/system-settings:11:_M_weak_release:~__weak_count:~__weak_ptr:~weak_ptr:~CachedPtr" [Undecided,New]
<kgunn> AlbertA2: camako either of you wanna have some pointer tracking "fun" :)
<kgunn> or anpok_ even ^
<kgunn> volunteers ?
<kgunn> robotfuel: so that error report says ubuntu-system-settings, but do we know anything more ? like what was happening? opening or closing or just using settings at the time ?
<camako> kgunn, sure
<kgunn> camako: looks like the startup phase of u-s-s....
<robotfuel> kgunn: no I'll get video of it today
<kgunn> robotfuel: cool...the trace suggests startup of settings...but video would be awesome
<robotfuel> kgunn: I also have this one that needs someone assigned to it. I am not sure who it should be. https://bugs.launchpad.net/barajas/+bug/1359270
<ubot5> Error: ubuntu bug 1359270 not found
<AlbertA2> robotfuel: I can take a look at that
<robotfuel> AlbertA2: what's your launchpad id?
<AlbertA2> albaguirre
<mibofra> AlbertA2, hi. I think that more or less my setup it's like an unflipped image of utouch, so everything have to work ok. At this point I think it's a driver issue.
<AlbertA2> mibofra: umm any idea which driver call maybe causing the segfault?
<AlbertA2> or which opengl/egl call?
<mibofra> no I've to debug it AlbertA2. Think about that I'm on the cm11, as I can see on the porting guide the android base used it's an essential cm10.1
<AlbertA2> mibofra: which android version do you have?
<AlbertA2> 4.4.1? 4.2?
<mibofra> 4.4.4
<mibofra> yeah the 4.4.4 I've checked
<AlbertA2> I wonder if they have changed the opengl dispatcher table again...
<AlbertA2> there could be subtle TLS bugs
<AlbertA2> when using gnulibc vs bionic
<mibofra> AlbertA2, it's to be checked
<kgunn> thanks AlbertA2 for diving in on that one
<mibofra> AlbertA2, I've an idea, or well I think it was activated but It's deactivated every reboot of the phone
<mibofra> the trace of opengl on logcat on the dev options
<mibofra> ok AlbertA2 there is anything new
<mibofra> ok AlbertA2 I've asked, maybe you're write, there is the probability that the table from cm10.1 to 11 was changed
<mibofra> AlbertA2, (I'm controlling the code on github) if the problem is the opengl dispatcher table, do you (the devs/engineers of the mir team) can do anything or do you can do nothing because officially you're using as base cm10.1?
<anpok_> re
<anpok_> kgunn: saw my nick hilighted, have I been volunteered?
<AlbertA2> mibofra: we are officially using 4.4.1 now
<mibofra> ok
<mibofra> anyway AlbertA2 if the dispatcher table of opengl?
<AlbertA2> the main thing there is the optimization
<AlbertA2> where they use TLS to store the pointer and hardcode it
<AlbertA2> you can check
<AlbertA2> if the TLS is being corrupted
<AlbertA2> but I doubt it, since you can get the driver working on the server side...
<AlbertA2> but I don't know if there's some interplay in the client thread context with TLS that we are missing
<camako> anpok, it was about https://bugs.launchpad.net/mir/+bug/1358874 ... I took it on. No action on your part.
<ubot5> Ubuntu bug 1358874 in mir (Ubuntu) "/usr/bin/system-settings:11:_M_weak_release:~__weak_count:~__weak_ptr:~weak_ptr:~CachedPtr" [Undecided,New]
<mibofra> AlbertA2, I'm going to have dinner, cm10.1 https://github.com/CyanogenMod/android_frameworks_native/blob/cm-10.1/opengl/libs/EGL/egl_tls.h https://github.com/CyanogenMod/android_frameworks_native/blob/cm-10.1/opengl/libs/EGL/egl_tls.cpp , cm11 https://github.com/CyanogenMod/android_frameworks_native/blob/cm-11.0/opengl/libs/EGL/egl_tls.h https://github.com/CyanogenMod/android_frameworks_native/blob/cm-11.0/opengl/libs/EGL/egl_tls.cpp I've made
<mibofra> 2 diffs: egl_tls.cpp diff http://paste.ubuntu.com/8108125/ egl_tls.h diff http://paste.ubuntu.com/8108127/ . See you after dinner.
<kgunn> anpok_: nah, you're good
<AlbertA2> mibofra: https://code-review.phablet.ubuntu.com/gitweb?p=aosp/platform/frameworks/native.git;a=blob;f=opengl/libs/GLES2/gl2.cpp;h=3134e568fe984315dae7bf3c1fd4714359b7b7ba;hb=refs/heads/phablet-4.4.1_r1
<AlbertA2> mibofra: we are using aosp: https://code-review.phablet.ubuntu.com/#/admin/projects/
<AlbertA2> mibofra: https://wiki.ubuntu.com/Touch/AndroidDevel
<AlbertA2> basically this is the android base we use:
<AlbertA2> "repo init -u https://code-review.phablet.ubuntu.com/p/aosp/platform/manifest.git -b phablet-4.4.2_r1"
<AlbertA2> that's for the dev version of ubuntu touch
<mibofra> AlbertA2, I've to confront. So maybe it's the different base the problem
<mibofra> AlbertA2, from the source you're using and cm11 I've only this diff: http://paste.ubuntu.com/8108505/
<mibofra> for gl2.cpp
<AlbertA2> interesting...
<mibofra> let's try the egl_tls
<mibofra> uhm AlbertA2 there are no differences for egl_tls
#ubuntu-mir 2014-08-22
<RAOF> Bah! Test the new code, not a copy of the old code somewhere else!
 * duflu takes notes
<racarr_> namespace mb = mir::benchmarks
<racarr_> WHYA NOT
<duflu> racarr_: Because it's 9:30pm?
<racarr_> duflu: Oh im migrating to burning man time.
<racarr_> which is at least 3 time zones east of west coast
<RAOF> Hm. RPATH!!!!!
<RAOF> Alright. So, stripping out the rpath from our binaries fixes the doubly-included protobuf issue.
<duflu> RAOF: Propose away
<RAOF> I'm currently testing it manually :(
<duflu> RAOF: Oh we have an rpath in released binaries? To /usr ?
<duflu> Or rather non-released binaries
<RAOF> CMake is all about the rpath.
<RAOF> It embeds a lot of them.
<duflu> I know :P
<duflu> make install strips them
<duflu> But that doesn't help CI much
<RAOF> For example: lib/libmirclient.so: RPATH=/home/chris/Canonical/Mir/mir/private-library-loading/partial-armhf-chroot/lib:/home/chris/Canonical/Mir/mir/private-library-loading/partial-armhf-chroot/lib/arm-linux-gnueabihf:/home/chris/Canonical/Mir/mir/private-library-loading/partial-armhf-chroot/usr/lib:/home/chris/Canonical/Mir/mir/private-library-loading/partial-armhf-chroot/usr/lib/arm-linux-gnueabihf
<RAOF> And rpath conveniently preempts basically all other ld behaviour.
<duflu> RAOF: Except LD_LIBRARY_PATH I think
<RAOF> Nope, preempts that too.
<RAOF> At least empirically. I've got LD_LIBRARY_PATH exported, and the tests fail until I strip the rpath.
<RAOF> Let's try to unrpath the CMake!
<duflu> RAOF: CMake uses it for basic stuff like "make test". It might be hard to avoid completely
<RAOF> Nope, that'll be easy to handle.
<duflu> Kay
<RAOF> We've already got the infrastructure required to set LD_LIBRARY_PATH
<RAOF> Alright. And with that, EOW!
<alan_g> Have a good weekend
#ubuntu-mir 2014-08-24
<eanyx> hi
<eanyx> What is the status of ubuntu Xmir/mir?
<eanyx> I'm wanting to write game, and wanting to know what is the overall performance of Xmir/mir compared to legacy X?
<Nothing_Much> eanyx: as far as I know on radeonsi
<Nothing_Much> it's okayish
<Nothing_Much> but what kind of game are you making eanyx?
<Nothing_Much> :)
<eanyx> I've to leave now. contact you later :)
#ubuntu-mir 2015-08-17
<duflu> robert_ancell: I notice USC is started by lightdm. Is there a way I can give USC extra env vars?
<duflu> ... on a phone
<robert_ancell> duflu, the easiest way is to make a script and set lightdm to load that. I think the phone is already doing that
<robert_ancell> i.e. /usr/sbin/unity-system-compositor is a shell script to /usr/sbin/unity-system-compositor.real
<duflu> robert_ancell: Can you tell me where lightdm actually loads the thing called "unity-system-compositor"? I never found that bit
<robert_ancell> duflu, what do you mean where, i.e. the code location or the configuration?
<duflu> robert_ancell: Configuration. How does lightdm know it must start a system compositor and what it's called?
<robert_ancell> duflu, the default is hard-coded to unity-system-compositor but it can be configured by setting unity-compositor-command in [Seat:*]
<duflu> robert_ancell: Surprising but glad to see I never would have found it then. :)
<robert_ancell> duflu, /usr/share/doc/lightdm/lightdm.conf.gz contains all the configuration options and their defaults
<duflu> robert_ancell: Oh nice, thanks
<duflu> RAOF: Could you refresh your MP(s), so we can confirm CI is happy with the completed transition?
<duflu> Seems OK when I build things by hand
<duflu> Oh, except cross compiling still fails
<duflu> Maybe too early
<duflu> Maybe not. Seems to just be a bug in the xcompile script. Fixing that now
<RAOF> If Jenkins is building against proposed I think things should be working...
 * RAOF presses the try again button.
<RAOF> Although those previous builds look pretty ominous :)
<duflu> RAOF: I suspect vivid builds are somehow broken now which might hold up CI. Discovered by: https://code.launchpad.net/~vanvugt/mir/xcompile-wily/+merge/268183
<RAOF> Oh, hm.
<duflu> Still haven't seen any fresh Jenkins runs this week
<duflu> But should do within hours
<RAOF> Yeah, that'd be the gcc-5 cross-compiler VS gcc-4.9 libstdc++ on wily.
<RAOF> duflu: Have you tried running your crossbuilt packages on a mako?
<duflu> RAOF: Nope
<RAOF> I'm reasonably certain they'll fail, for roughly the same reason that they don't *build* if you use gcc-5 :)
<duflu> RAOF: Even with devel-proposed on mako?
<duflu> I'd have thought it should work
<RAOF> I guess it depends on precisely how the jenkins makos are configured.
<duflu> RAOF: Jenkins is back. And with more failures than ever. Seems in the least it's not using the latest archive contents yet on wily
<RAOF> It quite possibly doesn't build against wily-proposed.
<RAOF> Which is silly, but there you go.
<RAOF> Where's our self-serve Jenkins? :)
<duflu> RAOF: proposed is not required. Just the latest wily archive as of a few hours ago
<RAOF> Ah, good.
 * duflu wonders how far behind Jenkins lags the archive contents
<RAOF> It shouldn't lag at all; it pulls the packages in at build-time.
<duflu> Weird
<RAOF> Hm. Is std::function<> not a standard layout type?
<RAOF> How bothersome.
<RAOF> Woot! And with that doing the vague thing it's meant to do, it's EOD.
<duflu> Wow Mir has a lot of compositor implementations built in now. I find myself accidentally testing the wrong one
 * alan_g sees another opportunity for the delete key
<duflu> alan_g: Unfortunately they all exist for different reasons
<alan_g> ;)
<alan_g> greyback_: I'm just looking at qtmir again. cmake reports "--   package 'unity-shell-application=7' not found" - I don't see that package (in wily), is it specific to overlay?
<greyback_> alan_g: yep. unity-api in wily is behind currently
<alan_g> Thanks. I'll not expect it to work (for now).
<kenvandine> kgunn, silo 0 was dirty so i kicked a rebuild, but it fails
<kenvandine> Silo config is missing these packages: qtmir-gles
<kenvandine> i was going to update my device this morning, but worried i'd end up with a unity8 that didn't work :)
<kgunn> kenvandine: ah...i don't kick builds there since greyback_ has his ways :)
<kenvandine> i don't know what causes the silo config error
<kenvandine> maybe the silo was reconfigured or something?
<kgunn> kenvandine: actually in that instance, you have to tick the box
<kgunn> ignore missing gles twins
<kenvandine> ah
<kenvandine> mind if i do that?
<kenvandine> so users of the silo don't get the wrong unity8 :)
<kgunn> it's a weird sync thing to make gles/gl all happy on deskotp
<kgunn> greyback_: ^ that ok ?
<kgunn> to build a new unity8 ?
<greyback_> kenvandine: please don't kick off builds in silo0, ask me first. Being dirty doens't mean it won't work, as citrain script pins the packages from that silo so they still install over the newer versions
<kenvandine> ok
<kenvandine> RAOF, my magic trackpad doesn't move the pointer, i think this branch might fix that
<kenvandine> https://code.launchpad.net/~ken-vandine/mir/touchpad_pointer/+merge/268274
<kenvandine> RAOF, but i haven't been able to build that for the device, so not tested :)
<kenvandine> what do you think?
<RAOF> kenvandine: My magic trackpad moves the pointer fine, in mir_demo_server?
#ubuntu-mir 2015-08-18
<kenvandine> RAOF, hmm... i'm testing it on mako with silo 0
<kenvandine> not mir_demo_server
<RAOF> Hm.
<RAOF> I don't know what input changes are in silo 0.
<bschaefer> RAOF, would you know how trunk could possibly mess up reading umockdev recordings?
<bschaefer> as ... once i merged from trunk the recordings no longer generate events in mir
<bschaefer> soo either somehow trunk messed up new code you put in or the under the hood mir is different for handling events?
<RAOF> bschaefer: I don't know. I'll pull your branch and investigate.
<bschaefer> RAOF, alright, ill spend more time on it tomorrow if you've other things to get done
 * bschaefer slightly assumes he might have messed up fixing merge conflicts
<bschaefer> but i dont think so
<bschaefer> RAOF, also i dont think we need the mir cookie for the basic surface validation meaning we can reduce a lot of code changing
<bschaefer> (since a 0 should be a find value). Though i want to check if i even need to edit that make_event to begin with
<RAOF> Right. You can certainly get part of the way through without actually plumbing in the real cookie.
<RAOF> It'll just be useless :)
<bschaefer> yup, i was slightly lost when doing it at first and am trying to refine a lot of my changes
<bschaefer> mainly wanted to get all touch/keyboard/pointer to get cookies, but really only keyboard events + up/down events *need*
<bschaefer> cookies
<RAOF> Right.
<RAOF> Well, mostly.
<RAOF> Touch begin/end probably need cookies, too. (As that's how âclicksâ happen on touchscreens)
<bschaefer> well hmm right from what i can tell the validator does a very small touch event
<bschaefer> only 3 args
 * bschaefer needs to figure out the best way for that
<duflu> greyback: On my way to EOD, but was wondering... Do you have any idea why scrolling with a constant finger touch in Qt feels like it's missing frames? Significantly less smooth than a fling...
<greyback> duflu: it's something I've also observed, but thus far I've no good explanation
<duflu> I would have said it's just keeping up with the finger by jumping. But then noticed Android doesn't have the problem and neither to mir-demos
<duflu> neither do
<greyback> I investigated if the input events received by the client were smooth - and they are
<duflu> greyback: I know... we have some roughly equivalent mir-demos and they are smooth
<greyback> duflu: yeah but I'm testing using unity8 here
<duflu> greyback: On that note, does the --desktopfile trick still work?
<greyback> duflu: yep
<duflu> Hmm, OK. Another day.
<greyback> I want to improve qtmir's releasing buffer after swap, which might help
<duflu> greyback: Yeah I've got it "done". Just held up by the related Mir fix waiting to land. Then I need to recombine and retest them
<greyback> duflu: really? care to share?
<duflu> greyback: Work in progress, and don't expect to see any benefit without the Mir fix coming in 0.16... https://code.launchpad.net/~vanvugt/qtmir/supersmooth
<greyback> duflu: ok cool
<duflu> greyback: Hmm, actually that looks old
<duflu> I think I had a newer one
<greyback> well you're doing the right things
<duflu> greyback: Oh, that is the latest
<ogra_> duflu, fyi, i'm running my arale with GPU at full speed (using the sysfs hack from the mail thread) ... it ois a lot smoother and less stuttery ... but i'D guess it also eats about 10% more battery over time
<ogra_> (i dont think we have any GPU scaling at all on the other phones)
<duflu> ogra_: Yeah I noticed raising the minimum frequency helped, but not as much as having the extra cores enabled
<ogra_> we need ToyKeeper to measure the different scenarios for us ;) she has accurate power measurement tools
<greyback> duflu: what mir commit would I need to test?
<duflu> greyback: The current MP "earlier release"
<duflu> greyback: https://code.launchpad.net/~vanvugt/mir/earlier-release/+merge/267321
 * duflu wanders off
<greyback> duflu: thanks!
<alan_g> alf_: got headspace to discuss the remaining test failure I've got?
<alf_> alan_g: sure
<alan_g> I'm seeing an FD leak in some of the VariousDevices/EventHubDeviceEnumerationTest* tests. Specifically, those that call add_standard_device()
<alan_g> That allocates FDs in umockdev_testbed_load_ioctl() - which are never released
<alan_g> But none of this is new code - so how did it ever pass?
<alf_> alan_g: Can you point me to a failure backtrace?
<alan_g> http://paste.ubuntu.com/12117630/
<alan_g> alf_: ^ any thoughts?
<alf_> alan_g: Yes. I had put an exception for this case in detect_fd_leaks (checking for "g_dbus" in the backtrace), but in the new backtrace there is "bin doc src lib" instead of the g_dbus_* function names
<alf_> alan_g: That's a thought, let me confirm this
<alan_g> alf_: that makes sense.
<alan_g> (although the backtrace doesn't)
<alan_g> I guess another exception for "mir_test_framework::UdevEnvironment::add_standard_device" would be specific enough
<alf_> alan_g: So, yes, I remembered that I was getting the g_dbus related errors locally, not in CI (probably because dbus is not running in the CI chroot?).
<alf_> alan_g|lunch: ^^
<alan_g|lunch> alf_: yep. I've MP'd the above (to see if anything remains that I haven't got locally)
<mterry> alf_, hello!  Thanks for taking over that timeout branch for me.  I added a comment in your MP
<alf_> mterry: No problem, thanks for the original fix :)
<alf_> mterry: Let me try your idea...
<alf_> mterry: Your idea looks good. Would you like to incorporate the tests in your branch (+the max() idea)?
<mterry> alf_, I'm in a meeting right now, so you can run with it
<alf_> mterry: ok
<alf_> mterry: Change applied. Thanks!
<alf_> mterry: (and tested on arale)
<mterry> alf_, sweet, I approved the branch from my side.  But maybe get a real mir folk to also look at it
<bschaefer> RAOF, for when you get on, thanks for fixing that test (had no idea i had to include that...)
<bschaefer> now for the basic_suface validator
<bschaefer> i would love to remove the need for the cookie factory, the only issue is the default event that is needed
<bschaefer> if theres no prev events
<bschaefer> now... i've clue when a default event would ever happen, or if its save enough to ignore the mac for a default event that we needed to generate
<bschaefer> (im assuming yes its ok to ignore a mac for it since its just a bare bone vent)
<bschaefer> evet*
<bschaefer> soo now im starting to think the default touch event will have 0 pointer count meaning it will not have a down/up action
<bschaefer> meaning we can remove the need to generate a valid mac for that
 * bschaefer double checks the default value for a make_event for a touch event
<bschaefer> hmm  and now looking at that, the pointer_count variable for the new motion event is not being defined and everything is memset to 0
<bschaefer> soo yay no need for a cookie there since there will never be a up/down event or a default event if theres no prev touch event
<bschaefer> RAOF, IGNORE MY PING
#ubuntu-mir 2015-08-19
<bschaefer> RAOF, o looks like cookie factory inst installing correctly?
<RAOF> Hah! Indeed.
<bschaefer> more protobuf issues for amd64
<bschaefer> sad face until that gets fixes
<bschaefer> fixed*
<RAOF> We haven't added a libmircookie package to debian/control :)
<bschaefer> RAOF, o duh, i added the nettle-dev to control
<AlbertA> bschaefer: more? like what?
<AlbertA> bschaefer: it's compiling and passing here with GCC (lp:mir)
<bschaefer> AlbertA, more?
<bschaefer> oo
<bschaefer> AlbertA, umm in jenkins
<bschaefer> lp:mir compiles fine for me locally
<bschaefer> though its failing in clang
 * bschaefer should try that
<RAOF> Yeah, clang is known-broken with gcc-5 built stuff.
<bschaefer> well at lease its not my fault haha
<bschaefer> RAOF, so we need to create a cookie factory package?
<bschaefer> ie library?
<RAOF> Yup.
<RAOF> libmircookie1
<RAOF> + libmircookie-dev
 * bschaefer attempts
 * RAOF originally had this as an external project called libspoofless, but that was just soooooo much annoying overhead.
<bschaefer> haha
<bschaefer> RAOF, might need to be worded a bit better :)
<bschaefer> http://paste.ubuntu.com/12121500/
<RAOF> I can probably update the description in the branch if you like :)
<bschaefer> RAOF, pushed if you want to change it
<bschaefer> haha yeah
<bschaefer> install files there
<Mirv> RAOF: are you still about? can I get a core dev ack on Mir https://ci-train.ubuntu.com/job/ubuntu-landing-028-2-publish/lastSuccessfulBuild/artifact/mir_packaging_changes.diff ? (the debian/ files, the rest are just for information)
<Mirv> seems ok changes and cleanups for me
<RAOF> Mirv: Yeah, seems sensible to me.
<Mirv> RAOF: thanks! I still need archive admin preNEW review though to ack the adding of binary packages, but 1/2 completed.
<duflu> tvoss: Hey I found Jolla are to blame for our smoothness issues, kind of :)  https://bugs.launchpad.net/qtmir/+bug/1486341
<ubot5> Ubuntu bug 1486341 in unity8 (Ubuntu) "Touch scrolling is stuttery under Unity8 (but only while you're touching it)" [Undecided,New]
<RAOF> Oh, goody. That kernel panic corrupted my bzr working tree.
<Mirv> duflu: it'd look to me that at least the MP linked to from QTBUG is only found in Qt 5.5 while the 5.4 branch has a crash fix that mentions it but apparently not the touch compression feature itself (looking at git logs at git://code.qt.io/qt/qtdeclarative.git)
<duflu> Mirv: Yeah the QTBUG might not be related. But the introduction of the feature occurred in 5.4 AFAIK
<Mirv> ok
<duflu> I know because Gerry told me about it early last year
<duflu> And it was about to be released then
<Mirv> yeah I also think I remember some earlier discussions, it's probably an earlier feature that has been later refined
<duflu> Mirv: Even if it worked properly, it would be redundant with what Mir already does
<RAOF> Not quite; it can align event processing with Qt's renderloop, which Mir doesn't do.
<duflu> RAOF: Nice in theory. In practice it's broken and everything works better without it :)
<greyback> duflu: interesting findings on the touch scrolling, could it be the combination of the 2 input resampling engines being the problem, more than Qt's one alone?
<duflu> greyback: Thought of that and apparently no. Turning off Mir's and just leaving Qt's the problem remains
<greyback> duflu: ok
<duflu> greyback: But please do try for yourself
<greyback> will do
<duflu> alf: OK, remind me who to ask to fix up the CI scripts?
<duflu> greyback: Where in the architecture is it? Would apps have run though the compression twice or just once?
<greyback> duflu: touch compression happens in each QQuickWindow. So the unty8 window will do compression before dispatching events to the qml scene.
<duflu> greyback: I mean full stack. Just once then?
<greyback> apps also have a QQuickWindow, and will use same compression logic
<greyback> so no, multiple times
<duflu> Hmm
<duflu> That's great news. We might be able to go one better still
<alf> duflu: it's usually fginther
<alf> duflu: that fixes things for us
<duflu> alf: OK, thanks
<duflu> greyback: Is there a way to use desktop_file_hint without having a valid file?
<greyback> duflu: having a valid file is the point :)
<greyback> just point it to any existing file
<duflu> greyback: Hmm, doesn't work. I might be using an incompatible Mir version or something
<greyback> is unity8.log printing anything?
<greyback> if client connection rejected, unity8 prints a REJECTED notice
<greyback> just use something like /usr/share/applications/gedit.desktop
<duflu> greyback: I get the app starting animation indefinitely
<greyback> duflu: something else wrong so, that means the client has connected, but not drawn its first frame
<duflu> greyback: Arg. We might have broken protocol compatibility
<greyback> I think we've a bug where actually a couple of frames need to be drawn
<duflu> alf: How do you feel about it landing (by hand) and then CI getting fixed?
<duflu> It would have to be in that order
<duflu> alf: Oh umm, or I could just hack the script to work
<duflu> I might do that
<alf> duflu: I wouldn't mind landing it first as long as CI gets fixed soon after (and CI is broken anyway so...)
<duflu> alf: Never mind. I have a solution that won't need CI changes now
<duflu> greyback: Confirmed, we broke protocol compatibility in lp:mir (clients don't talk to existing servers any more)
<duflu> Need to bisect that
<greyback> duflu: uh oh
<greyback> recent?
<duflu> greyback: Yeah, it was working at least a week or two ago
<alf> duflu: seems like a good candidate for automated testing, something to consider for our new jenkins instance
<duflu> alf: Kind of the reverse of what we have in glmark2. That tests the previous release client against the newer server (I think?)
<alf> duflu: only if there is an ABI bump, otherwise glmark2 just uses the update library of the same ABI
<duflu> How very predictable
<kdub> alf, with lp:~afrantzis/mir/buffer-bind-to-render-image how does a mgm/mga::Buffer switch between gl binding and another sort of binding?
<alf> kdub: In a future MP, we will have a Platform::create_buffer_allocator(RendererType const& renderer_type), so the buffer allocator will know to create buffers supporting the renderer
<kdub> and, just guessing, will have something like: mgm/mga::Buffer::Buffer(..., std::shared_ptr<RenderTypeBinder> const&) ?
<alf> kdub: Each platform can handle this as it sees fit internally, but what you propose is a reasonable approach if a platform supports multiple renderers. For the first step it's not needed since the existing platforms will just support "gles2".
<kenvandine> kgunn, i don't know how to get debs of mir built that i can test on my device, how would you guys feel about adding my branch to silo 0 to so i can test it with my touchpad?
<kenvandine> https://code.launchpad.net/~ken-vandine/mir/touchpad_pointer/+merge/268274
<kenvandine> sound only affect touchpads, if it doesn't work we can reconfigure it again :)
<kgunn> greyback_: ^ ?
<kgunn> kenvandine: in general i don't mind
<kgunn> i suppose we'd prefer to merge that into the silo0 branch for mir
<kenvandine> sure, if it fixes it
<kenvandine> but i haven't actually been able to test it :)
#ubuntu-mir 2015-08-20
<bschaefer> RAOF, hey, soo digging through libinput today, looks like minimal work to add a function to get an FD from a libinput_device
<bschaefer> though the other way around will be a bit trickier
<RAOF> Right.
 * bschaefer assumes passing in the libinput struct
<bschaefer> and fd
<bschaefer> and going through all the event devices
<bschaefer> and checking if the FD == FD
<bschaefer> RAOF, cant imagine that taking to much time either
<bschaefer> RAOF, which from there... i should be digging around the libinput-platform in mir to figure out where we can collect said FDs
<RAOF> At worst we'd need to pass in the path and the fd; libinput does need a way to probe the udev properties for the device, and I don't think it'd be able to do that given just an fd.
<bschaefer> per surface, and figure out where to send that info on the callback (if its setup for the surface)?
<bschaefer> RAOF, o i see, the only function i saw that did that was a add_device
<bschaefer> from a path
<bschaefer> which im not sure if that what we *really* want
<RAOF> Hm, why not?
<bschaefer> RAOF, well wouldnt that add a device that is already added?
<RAOF> Why would it be already added?
<bschaefer> hmm well since we would be passing the FD?
<bschaefer> to unity8
<bschaefer> we would need that FD to get a libinput_device struct
 * bschaefer assumes at that point we already have added the device
<bschaefer> RAOF, cause the over issue is unity8 getting a libinput_device struct from a list of FDs we send it
<RAOF> Yeah, Unity8 has its own libinput context.
<bschaefer> ooo i see
<bschaefer> so yeah... we'll need to pass and FD + path?
<bschaefer> with this function?
<bschaefer> so it can open it, it self?
<RAOF> Yeah. We might be able to get away with just the fd, but I'm not sure.
<bschaefer> yeah thats something that should be checked
<RAOF> Well, we don't want it to open it itself (indeed, we want it to be *impossible* for it to open it itself)
 * bschaefer is new to udev/evdev/libinput
<bschaefer> RAOF, we just want it to have a handled on the device that libinput_platform has right?
<bschaefer> though if it has its own libinput context...
<bschaefer> not 100% sure how that'll work out
<RAOF> bschaefer: Unity8 will have a libinput_platform itself.
<RAOF> ie: *both* USC and U8 will have a fully armed and operational input platform.
<bschaefer> ooo ... ok that confuses things a bit :), since i thought the platform would set under USC
<bschaefer> o geez yeah
<bschaefer> so platform --> USC --> (platform --> U8)?
<RAOF> The only difference being that USC populates its platform from udev + open(), and U8 populates its platform from the fds it receives.
<RAOF> Right. platform â USC â platform â U8.
<bschaefer> RAOF, they would both get events at the same time thougH?
<bschaefer> from the same events
 * bschaefer finds that strange
<bschaefer> does U8 just filter out the extra events?
<bschaefer> or listens to what it wants and ignore USC events?
<bschaefer> im now imagining, USC handles its events
<bschaefer> and U8 handles its events
<RAOF> We can either (a) have U8 not register a surface event handler, or (b) send no surface events when a client has subscribed to raw mode.
<bschaefer> with out much talk
 * bschaefer finds nested servers strange
<bschaefer> RAOF, i think im slowly getting the idea though
<RAOF> This is also not very different from the status quo - it's platform â USC â (nested) platform â U8.
<bschaefer> right but theres
<RAOF> We'd just be changing (a) what gets sent from USC â U8 and how the nested platform works.
<bschaefer> USC --> (platform) --> U8 (server) --> U8 client
<bschaefer> i see, i didnt think there was 2 platforms
<bschaefer> so we just need to in a sense clone the platform layer
<bschaefer> that sits below USC
<bschaefer> to the nested platform?
<RAOF> Pretty much, yeah.
<bschaefer> now how will U8 change configurations then?
<RAOF> By interacting with the input platform directly.
<bschaefer> form the client?
<bschaefer> or its nested server bit?
<bschaefer> ie. its created server will have to talk to the 'cloned' platform
<bschaefer> and then configure it, which will then configure the fds opened by udev in USC?
<RAOF> The nested server bit; U8 is getting its input from its own input platform (as is currently the case) - if we send the fds over, U8's input platform can have full control over how to interpret the bits.
<bschaefer> i see that makes much more sense
<RAOF> There's no configuration of the fds opened in USC.
<RAOF> The only configuration in the input platform is how the input platform interprets the events it gets on the fds.
 * bschaefer wonders how handling saved configurations will be hanlded
<RAOF> So if U8's input platform is reading the events from the fds, it gets to do whatever it wants with them.
<bschaefer> thats to far up
<RAOF> Saved configurations is *definitely* U8's job.
<bschaefer> RAOF, so we pretty much just need to tell U8 what devices to add
<bschaefer> to its input context
<bschaefer> RAOF, then whats the point of sending the FD it self if we arent planning on changing the input context in USC?
 * bschaefer thinks a device path would be better then an FD at this poin
<bschaefer> point
<bschaefer> RAOF, but i think im missing something :)
<RAOF> bschaefer: Because U8 can't open the device itself - if it *could* open the device itself then it can read input.
<bschaefer> o i see
<RAOF> Even when (a) USC wants to eat that input, and more importantly (b) even when there's another session active.
<bschaefer> RAOF, so .. the only thing im stuck on is how do we add a device to the input context with an FD :)
 * bschaefer will have to dig into that
<bschaefer> which you were saying might not be possible
<RAOF> If you pass in the device path as well it'll be easy.
<bschaefer> with out a path, but reading libinput API it looks like add_device just needs a lib input context
<bschaefer> right
<bschaefer> it doesnt 'open' the device
<bschaefer> it just adds it to the internal list of devices
<bschaefer> which is what we want
<bschaefer> RAOF, so yeah, i think we just need to pass a path vs needing an FD at all
<bschaefer> libinput_path_add_device(struct libinput *libinput,
<bschaefer>        const char *path);
<RAOF> Right, but that's not going to work because libinput won't be able to open the device :)
<RAOF> That's why we're passing in an fd.
<bschaefer> If the device was successfully initialized... hmm
<RAOF> If you do exactly that but *also* pass in an fd and use it instead of wherever libinput calls open() on that device...
<bschaefer> yeah i need to take at look at what that means
<bschaefer> so we'll have to figure out how to add a device with an FD and a path (which is unsupported atm)
<bschaefer> from what i see
<RAOF> At some point in libinput_path_add_device there's going to be a call to open(/the/path) to get the fd libinput will poll on.
<RAOF> Exactly.
<bschaefer> right, which i was missing
<bschaefer> but yeah we'll have to add our own function to then use the FD
 * bschaefer checks what else it uses that path for
 * bschaefer needs to re-read the backlog
<bschaefer> as i think we covered this, but if we dont need to 'open' the device then we shouldnt need the path :)
<bschaefer> we just need to create a libinput_device based on that FD
<bschaefer> vs going through evdev to create a device with the path
<bschaefer> 'libinput does need a way to probe the udev properties for the device'
<bschaefer> right which i uses the path for that
<bschaefer> ok
<bschaefer> that makes more sense now
<bschaefer> that is... if it really needs to probe for those and if it uses the path or fd (ill have to check)
<bschaefer> RAOF, so after that, ill need to look at adding a new function in toolkit for a mir surface to add a raw input handler
<bschaefer> (that should be less then a day of work)
<bschaefer> RAOF, after that... its mainly just U8 doing the rest of the work?
<bschaefer> in qtmir?
<RAOF> We then need to make the appropriate changes to the nested input platform.
<RAOF> And expose the relevant configuration points out of the input platform.
<bschaefer> that sits in qtmir right?
<RAOF> Nah, Mir.
<bschaefer> o hmm i thought qtmir was the nested server it self
<bschaefer> or i need to look at the nested bits that are in mir it self?
<RAOF> qtmir uses libmirserver...
<bschaefer> i see yeah
<RAOF> Yeah, the nested bits that are in Mir itself.
<bschaefer> but we have to fix the functions it uses :)
<bschaefer> RAOF, so, ill try to focus on figuring out as much as i can with the libinput part (mainly just try to make a function that create a device based on the FD passed)
<RAOF> qtmir (should) run fine on the bare-metal, too. The choice of platform is contained within libmirserver, not in qtmir.
<bschaefer> and populate a valid struct
<RAOF> Yeah, that'd be a reasonable first step.
<bschaefer> cool thanks that should be fun!
<RAOF> Because most of the rest of this is going to be the same whether or not we do the input-bypass trick.
<RAOF> Well, maybe not most. But we certainly need to provide the relevant configuration points from the input platform regardless.
<bschaefer> yeah, the libinput stuff seems needed no matter way for the nested server stuff
 * bschaefer cant english
<bschaefer> and its my only language :(
<bschaefer> no matter what* for the nested server
<bschaefer> but ... really im not sure
<RAOF> We certainly need configuration points in the input platform; they'll basically just forward to the relevant libinput thing.
<bschaefer> RAOF, this will be the API that is needed overall?
<bschaefer> so we'll just need to forward set_cursor_accel suff?
<bschaefer> etc*
<RAOF> Yeah, that's roughly it.
<bschaefer> cool that should just be a simple 1to1 mapping
<bschaefer> which would be very nice
<RAOF> If we do the input-bypass, then the nested input platform can expose those easily. If we don't do input-bypass, then USC needs to expose those over DBus (or whatever).
<bschaefer> so either or we'll need those functions
<RAOF> I think you mean âso either way we'll need those functionsâ?
<RAOF> And, yes :)
<bschaefer> RAOF, that is what i mean
<bschaefer> :)
 * bschaefer think 'either or' means if we pick 1 or the other
 * bschaefer should work on english
<bschaefer> its an xor haha
<bschaefer> RAOF, would there be a benefit of having both implemented?
<RAOF> Vaguely?
<RAOF> Kinda, maybe.
<bschaefer> just a thought is all (need to get more context on everything really)
 * RAOF luncheons
<RAOF> Woot! My branch fails for actual reasons!
<duflu> RAOF: Yes, we have real sensible failures now :)
 * guest42315 ð ðððð ððððð!
<alf> greyback: I noticed that on meizu with rc.proposed a long press of the power button doesn't show the power-off dialog if the screen is off when the press starts. Is this expected?
<greyback> alf: I just tried and it worked
<greyback> oh hang, let me try exactly what you said
 * greyback 's phone rebooted, suspects a trap
<greyback> alf: I think that's a bug indeed
<alf> greyback: ... happened to me too, I assumed it's because I pressed the power button for too long (waiting for the dialog to appear but never did)
<alf> greyback: ok, I will file a bug in unity8, but I will also investigate USC in case something is going wrong there
<greyback> alf: ok, thanks
<greyback> note if you're looking for stuff to do, the display configuration api for system settings would be nice ;)
<alf> greyback: Not actively looking, my plate is full (unless priorities change and move me to a different plate)... This bug just caught my attention and just wanted to ensure we haven't messed up USC somehow :)
<greyback> alf: yeah understood, was just being cheeky :)
<alf> greyback: https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1486953 , I'll check USC and if I find anything suspicious I will add the project to the bug
<ubot5> Ubuntu bug 1486953 in unity8 (Ubuntu) "Power-off dialog doesn't show if power key press begins when screen is off" [High,New]
<greyback> alf: ack
<alf> greyback: how does unity8 detect a long power-key press?
<greyback> alf: is in unity8, qml/Components/PhysicalKeysMapper.qml - nothing too special, listens for key events, uses timer
<alf> greyback: ok, so it doesn't depend on USC (which makes sense, since I don't see anything in use to notify of it), which I guess rules out USC being the problem.
<greyback> alf: probably, unless USC takes focus from the unity8 surface while display blanked
<alf> greyback: interesting
<greyback> but I do see evidence of unity8 reading display state while figuring out key long press, so that's more likely the culprit
<alf> greyback: yes, so // FIXME: We only consider power key presses if the screen is 74             // on because of bugs 1410830/1409003.
<ubot5> bug 1410830 in Canonical System Image "Shutdown dialog appears on resume, after a long delay in screen turning on" [Critical,Fix released] https://launchpad.net/bugs/1410830
<alf> greyback: "... we simply won't
<greyback> alf: which is lame
<alf>  initiate any dialogs when the screen is off
<alf> "
<greyback> we can do that better
<greyback> surely
<alan_g> AlbertA: I just spotted a 0.15 bug: there's a 9.1 stanza in client/symbols.map, but include/client/mir_toolkit/version.h has #define MIR_CLIENT_MINOR_VERSION (0) - that ought to be #define MIR_CLIENT_MINOR_VERSION (1)
<AlbertA> alan_g: ack...will updated 0.15
<AlbertA> update
<alan_g> AlbertA: thanks
<bschaefer> RAOF, just an update, it looks like we will need the path, mainly for properties and asserting we arent a test device
<bschaefer> as well as checking our fd opened is the same as our devnode
<bschaefer> so far its a pretty length path down to a evdev_create (where the open happens)
 * bschaefer tries to figure out the smallest amount of changes needed for a libinput_device add_device_from_fd_and_path
<bschaefer> also the other issue i need to consider.... when our libinput context gets cleaned up
<bschaefer> we need to make sure not to close on the FD
<bschaefer> since we didnt open it
 * bschaefer will probably just add something to a struct to check if we own it or not
<RAOF> bschaefer: Actually, it should be fine to close the fd on cleanup.
<RAOF> It'll only close the local handle, and since in the case where we're cleaning up the libinput context we clearly don't expect to receive any more input, that should be fine :)
<bschaefer> RAOF, well i was seeing suspend/resume
<RAOF> Aaah, yeah.
<RAOF> Sure.
<bschaefer> RAOF, o i see right on that part
<bschaefer> was just worried about doing a close restricted on the fd it self :)
<bschaefer> RAOF, ill just have to work with that (and be aware of that)
<bschaefer> since we skip open when we get the fd/path
<RAOF> Even there we might be able to get away with it, as suspend will (probably?) happen when U8 loses focus and hence has its input fds revoked anyway?
<bschaefer> RAOF, i think ill make note of it to check
<bschaefer> but go with seeing what happens first :)
<RAOF> Yeah, sounds sensible :)
<bschaefer> RAOF, other then that... just trying to make more head way, trying to make just 1 function init  the struct it self
<bschaefer> but just reading code at this point
<bschaefer> also fixed up the attestable branch, was missing the ABI check in tools/update_package_abis.sh
<bschaefer> and once this lands: https://code.launchpad.net/~brandontschaefer/mir/msg-auth-code-field-added/+merge/268383
<bschaefer> i can clean up attestable and get it ready for an actual merge
<RAOF> Woot!
<bschaefer> would be nice :) (i would like to get RaiseWindow working once thats landed :)
<bschaefer> for sdl
<RAOF> Yeah, that'd be good.
 * bschaefer wants to get as much SDL stuff done by 16.04
<bschaefer> since SDL2 only stays with LTS :(
<bschaefer> upstream
#ubuntu-mir 2015-08-21
<bschaefer> RAOF, alright, merged trunk and fixed some minor things
<bschaefer> i think its ready... but you never know :)
<bschaefer> passing locally for me
<RAOF> SHIP IT!
<RAOF> Or at least run CI against it :)
<bschaefer> RAOF, :)
 * bschaefer wonders how that wasnt caught
<duflu> bschaefer: If you mean that CI failure... it only fails sometimes. And even then only in CI. Never when you run it manually :/
<duflu> Annoyingly difficult to fix
<duflu> Something about our CI machines is very different to the team's own machines
<bschaefer> duflu, well i guess it compiled somehow on my end
<bschaefer> but shouldnt have :)
 * bschaefer started getting errors
<bschaefer> and idk how it happened haha
<duflu> bschaefer: Yeah it compiles and passes tests for everyone. Except sometimes fails that test only in CI
<bschaefer> duflu, haha... well i think this case it was my fault :)
 * bschaefer would not like that
<duflu> OK, different topic then
<bschaefer> yeah
<bschaefer> duflu, but i've seen that
<duflu> Heh. If you want something to land quickly just get me to not like it. Then a large number of people will argue the opposite and your branch gets rapid approval
<duflu> Works every time
 * bschaefer wonders why CI seems to hate me
<bschaefer> i think it just blew up...
<duflu> bschaefer: I only just fixed that failure you reported. Any CI jobs started in the past few hours will fail with that error that's already fixed. Try again.
<bschaefer> duflu, Well it failed by saying the nodes went off line :(
<bschaefer> https://jenkins.qa.ubuntu.com/job/mir-mediumtests-builder-vivid-armhf/3569/console
<duflu> Woo. No that's not me
 * bschaefer hasnt ever seen that
<bschaefer> haha
 * bschaefer hopes it turns back on
<duflu> bschaefer: The universe is telling you to EOD
<bschaefer> haha
<bschaefer> duflu, just wanted to see the SUCCESS
<bschaefer> before i headed off
<duflu> I know. It's a trap. But having the self control to log off is a good way to stay sane
<bschaefer> true, just watching tv and checking my email every now and then
<bschaefer> not much working going on :)
<duflu> Such is the way in this always connected world.
<bschaefer> true, hard to log off irc
<duflu> bschaefer: Yeah other branches are dying in CI too. Not something likely to be fixed quickly
<bschaefer> yeah o well, its all passing locally now (double checked) soo
<bschaefer> im like 99% sure its done
<RAOF> Yeeeeeeeeeees!
<RAOF> Finally CI passes!
<duflu> greyback: Are you aware of any touch test case that has stretchy resize still?
<duflu> Or is it only desktop?
<duflu> Never mind. Found one bug at least
<greyback> duflu: it's all qml/qtmir's fault, where they don't wait for a resized buffer before drawing it at the new size.
<duflu> greyback: Yeah I know what to fix, just wanted a manual test case
<duflu> Found them
<duflu> Crap. Except I lost my phone build environment and may not have enough time to rebuild it this week
<greyback> duflu: hey, will you have that early buffer release in qtmir work ready to propose any time soon?
<duflu> greyback: It's painfully slow. The Mir fix landed yesterday and then I had to revert it today. Now waiting on CI to get fixed again so I can find out why it fails only in CI
<greyback> duflu: ah ok. I noticed your fix landed, didn't see it had to be reverted.
<duflu> So I'm now donating my Friday evening to an unrelated QtMir fix
<greyback> the stretched frames issue?
<duflu> greyback: Yeah generally "never stretch"
<greyback> duflu: ok. Your thoughts are welcome
<greyback> mainly shell needs to not animate towards a resized-frame, until a frame with that size has been swapped by the client
<greyback> right now we fire resize, do our animation on the previous frame, then hope the resized frame is ready at the end of the animation
<duflu> greyback: Happy Friday. I'm off to make dinner... https://code.launchpad.net/~vanvugt/qtmir/unstretch/+merge/268724
 * alan_g discovers the diagnostics from connection failures get eaten in the client callstack.
<alan_g> Actually, they don't even reach the client
<kgunn> is it worse to be lost or eaten
<Mirv> I finally got archive admin approval, meaning Mir 0.15 is now in wily
<Mirv> (-proposed)
<Mirv> AlbertA: ^
<kgunn> mmm
<alan_g> kgunn: the reporting is misleading and confused me. (And I have touched most of this code.) Going to MP a small cleanup.
<kgunn> alf: just in case, so you know, silo 9 where you delivered that hot fix for the emulator - is a dual landing, since mir15 landed....i'm gonna pull it out of there
<kgunn> and land that thing in isolation to vivid+
<kgunn> does that make sense
<alf> kgunn: ok, so we will eventually need to include the fix in 0.15.x (or 0.16 if we get to it)
<kgunn> alf: +1 we should just have 2 silos, one for vivid+o hotfix to 14, then wily for 15
<kgunn> i can take care of "paperwork"
<kgunn> just wanted you to know
<alf> kgunn: ack, thanks
<kgunn> alf: but thanks for the reminder it wasn't naturally in 15 ;)
<kgunn> i forgot
<kgunn> we haven't taken a cut off for 16 yet have we ?
<kgunn> and is this change already on trunk ?
<alf> kgunn: we haven't cut off for 16, change is in trunk
<kgunn> cool
<AlbertA> Mirv: ummm I acutally parked that because
<AlbertA> we wanted 0.14.1 to land first....
<AlbertA> oh gosh....what a mess
<AlbertA> Mirv: can we revert mir 0.15 from wily-proposed?
<Mirv> AlbertA: oh, I parsed your message wrongly in that case. but it was FF yesterday, if you'd cancel 0.15 now you wouldn't get it in without FFe. isn't it easier to do a maintenance release of 0.15 with 0.14.1 changes added on top of it?
<AlbertA> Mirv: the problem is sync to vivid+overlay.... but we'll figure it out thanks
<Mirv> AlbertA: yes it was already discussed a bit so that silo 9 would be vivid+overlay only and you'd sort it out
<Mirv> since silo 9 also has a small mir fix
<alan_g> camako: did you intend to approve https://code.launchpad.net/~alan-griffiths/mir/simplify-connect-code/+merge/268740?
<camako> alan_g, yes... reapproved
#ubuntu-mir 2015-08-23
<anpok> bschaefer: you are probably on the flight already..
<anpok> bschaefer: btw there is a way in libinput already to inject an fd.. the actual problem with that approach will be dealing with revoking the fds and applying stuff like relative coordinates..
<anpok> RAOF: ^..
<anpok> bschaefer: libinput gets a function pointer struct on init.. that can be used to inject fds..
<anpok> so we could totally load the libinput platform in nested and non-nested mode.. and I guess apart from the device monitor everything stays the same..
<anpok> i am off..
<anpok> RAOF: but how would we ensure the raw device fd is revoked on focus lost..
<RAOF> anpok: EVIOCREVOKE!
<RAOF> anpok: Specifically - there's an evdev ioctl to revoke access to the evdev fd; we'd need to hook focus up to that.
<RAOF> And we don't want relative coordinates, anyway.
#ubuntu-mir 2016-08-22
<duflu> RAOF: Would it make sense for us to clarify to API users that subpixel order is only valid for the native resolution? (ie. all modes with resolution == the preferred mode)
<duflu> I have seen enough buggy code that keeps subpixel rendering even when not at the native pixel size
<duflu> Although that's a function you could write in the client/toolkit
<RAOF> Yeah.
<RAOF> I'm ambivalent about adding that to the comments.
<duflu> Comments would suffice. Don't hold it wrong
<duflu> ... unless we encountered the situation where a large number of backends attached subpixel information to the mode instead of the output
<RAOF> Which would seem to be bonkers, but whatever.
<duflu> RAOF: True. It's an attribute of the output. But only valid in a small number of modes
<duflu> which is 100% of modes while we don't let Unity8 users change it :)
<alan_g> greyback: got time to review two easy ones? https://code.launchpad.net/miral/+activereviews lp:~alan-griffiths/miral/fix*
<alan_g> Would be good to land them
<greyback> alan_g: yep. And thanks for spotting my error with qtmir/use-mir-test-dev
<alan_g> yw
<alan_g> greyback_: ready for another look: https://code.launchpad.net/~alan-griffiths/miral/fix-for-clang/+merge/303535
<greyback_> alan_g: ack
<alan_g> greyback__: is "Ok for me." a vote for abort()?
<greyback__> alan_g: nah, I'm happy with the current code
<greyback__> ok to "land this and discuss later"
 * greyback__ actually approves the branch
 * alan_g makes it happen
#ubuntu-mir 2016-08-24
<sil2100> Hey guys! I'll be pushing a manual no-change rebuild of mir for xenial-overlay, please ignore it during the next release you do
<duflu> sil2100: Umkay
<duflu> sil2100: What did kdub say about the test failure?
<sil2100> duflu: he said that it might be the more an issue with the test suite than anything else
<duflu> sil2100: OK, well so long as no one is weakening the test suite and there's no evidence that it used to work on the given device that's probably fine
<bneo99__> hi, im getting problems when running mir_demo_standalone_render_to_fb
<bneo99__> logcat output http://pastebin.com/5SJ5s3Rs
<bneo99__> my device's screen stays black when i tired executing the command
<alan_g> bneo99__: what's the device? Have you run mirbacklight to force the screen on? Does mir_demo_standalone_render_to_fb report anything (to console)?
<bneo99__> device is i9100g (samsung galaxy s2), just tried mirbacklight but screen still black even thought the console telles me its set to 100 percent
<bneo99__> output from mir demo standalone render to fb http://pastebin.com/dgPdN3iu
<alan_g> I've not see all those linker diagnostics before. kdub does this ^^ mean something to you?
<kdub> bneo99__, you might want to try rev3650 which included a fix for older ti devices
<kdub> the patch need unreverting, as it was backed out in rev 3662 due to issues it caused on powervr
<kdub> but it might help
<bneo99__> okay ill have a look at that
<NeKit> but that ti device also have powervr, it's not a problem, right?
<kdub> should have said 'on mtk'
<bneo99__> tried rev3661, backlight control seems to work now but its only showing the samsung screen
<bneo99__> http://pastebin.com/re59YA9u
<bneo99__> logcat http://pastebin.com/aYu1kBkj
<mterry> What's the story with unity-system-compositor's code branches?  Trunk seems behind 0.7, should I base MPs off of 0.7 and propose them merged into 0.7?
<mterry> alf ^?
<alf_> mterry: You should ideally base them on trunk, and if needed we can cherrypick into latest stable (0.7 in this case)
<alf_> mterry: Note that trunk needs mir trunk to build and run
<mterry> alf_: you make it sound like trunk is a head of 0.7, but that doesn't seem to be the cae
<mterry> case
<alf_> mterry: trunk and 0.7 should be treated as completely independent (but of course 0.7 was branched off trunk at some point). Not sure how I implied "trunk is a head of 0.7"?
<alf_> mterry: What I meant is that MPs should always target trunk first (that's our focus of development), and can be also cherrypicked into the current stable if needed urgently.
<mterry> alf_: well you implied that trunk was dev and 0.7 was stable branch.  But in most projects I'm familiar with, dev is typically a superset of the stable
<mterry> alf_: for example, it's tough to use my MP in a silo because trunk's version is < 0.
<mterry> 7
<mterry> Also tough because I need mir trunk I guess, but that's more expected
<alf_> mterry: Oh, that's because we haven't merged back the changes from the released version. I can do that for you if it makes your life easier.
<mterry> Maybe I should make a fake MP against 0.7 just for silo testing purposes
<mterry> alf_: well that's all I was saying about trunk being behind
<mterry> alf_: but I can work around it for now by making a new 0.7 MP for testing.  That will be easier anyway cause I won't need new mir
<alf_> mterry: ok, in any case I will merge back soon anyway after https://requests.ci-train.ubuntu.com/#/ticket/1845 lands to get the latest changelog
<alf_> mterry: btw, https://requests.ci-train.ubuntu.com/#/ticket/1845 contains the MIR fixes
<mterry> alf_: cool thx
<mterry> alf_: the MP I'm talking about is https://code.launchpad.net/~mterry/unity-system-compositor/default-wallpaper/+merge/297791 which has sat there for two months...  is there something I should do to get that reviewed?
<alf_> mterry: I guess poking me is the best thing you could have done, I will take a look tomorrow
<mterry> alf_: :)  thanks
#ubuntu-mir 2016-08-25
<duflu> RAOF: Is the other IRC server down?
<RAOF> I was just about to ask.
<RAOF> I think the answer is yes :)
<RAOF> I noticed IS was fiddling with firewalls recently. They may not have been as successful as they hoped :)
<alf_> duflu: Hi! Just FYI there was no need to explicitly add a new changelog entry for 0.24 no change rebuild, ci-train automatically adds one using the MP commit message. Plus now we need to rebuild the silo...
<alf_> RAOF: duflu: internal IRC is back on-line
<duflu> alf_: Never mind. Only need to learn that once. I'm still concerned about the assertion that changing headers in order to product different binaries is "no change"
<alf_> duflu: no change doesn't mean no test
<duflu> alf_: No but it does mean the binaries are changing. That's the point. So it carries risk still
<RAOF> âno change rebuildâ is the term of art used in distro.
<alf_> duflu: RAOF: Plus something changes in the binary output of the process otherwise we wouldn't need the rebuild. The "no change" is just for our source, and people are familiar with the implications I think
<duflu> It's sufficiently risky and insufficiently expressed that it's worth mentioning, and now we have...
<RAOF> That reminds me. We should check if the Mir build is reproducible...
<duflu> RAOF: I've been doing that for the past day and this morning. Final workaround landing soon
<duflu> Oh, you mean something different
<duflu> Yeah that too
<RAOF> duflu: Sorry, another term of art. By âreproducibleâ I mean âproduces binary identical output each buildâ.
 * duflu always assumes there is entropy instead of such proof that there shouldn't be...
<duflu> Cosmic rays...
<duflu> alf_: It should also be mentioned to the powers that be that such non-ABI breaking changes shouldn't need be in a silo. We have proposed for that.
<duflu> Hmm, 1 hour for CI and an additional 2+ hours for autolanding?
<duflu> Is something new broken?
<RAOF> Or just oversubscribed?
<duflu> RAOF: Yep. And guess what? CI now passes but autolanding fails for new reasons
<RAOF> Huzzah!
<duflu> So what's different about autolanding's build environment?
<duflu> Different to CI
<duflu> alf_: Any idea why autolanding would fail to build but CI passes?... https://bugs.launchpad.net/mir/+bug/1616291
<ubot5> Launchpad bug 1616291 in Mir "Autolanding is failing to build libmirserver.so.41 with error: undefined reference to '_Unwind_Resume'" [Critical,New]
<duflu> Google says that error is a depenendcy on some lib built with a different C++ compiler/version
<alf_> duflu: one main difference between autolanding and CI is LTO
<duflu> Hmm
<alf_> duflu: but also optimizations in general
<alf_> duflu: CI builds are built with 'noopt' debflag
<duflu> alf_: Cool. So plausible reasons exist. Unfortunately we're at a stage where CI is passing and only autolanding fails
<duflu> .. to build
<bneo99> getting error when doing mir_proving_server --hwc-report log
<bneo99> http://pastebin.com/HCZSLSG3
<bneo99> logcat http://pastebin.com/nibGtxV2
<duflu> bneo99: You might have to wait for kdub to come online (USA central time?)
<bneo99> ok
<sil2100> Hey!
<sil2100> duflu, alf_: https://requests.ci-train.ubuntu.com/#/ticket/1846 <- this doesn't look to be needed
<sil2100> I poked here about a manual no-change rebuild already, no need to do the same twice ;)
<sil2100> (especially that we only needed a rebuild on xenial)
<sil2100> duflu, alf_: are there other reasons for this no-change rebuild?
<duflu> sil2100: Sorry, preparing food :) ... Yeah we don't need any more builds than you need
<duflu> sil2100: I just thought some accuracy in changelogs would be nice. Our robots always do a terrible job of writing documentation
<duflu> And back to the kitchen
<alf_> sil2100: Was the xenial upload to rebuild with the updated android-headers?
<sil2100> alf_: yes
<sil2100> alf_: a no change rebuild here: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/stable-phone-overlay/+sourcepub/6828563/+listing-archive-extra
<alf_> sil2100: thanks, had a chat with vicamo (in phablet channel) and have abandoned the silo
<greyback> alan_g: would you mind giving this a quick glance, just to fully sign it off: https://code.launchpad.net/~gerboland/qtmir/use-mir-test-dev/+merge/303537 (build issue fixed)
<alan_g> greyback: sure
<greyback> thanks
<bneo99> @kdub getting error when doing mir_proving_server --hwc-report log
<bneo99> http://pastebin.com/HCZSLSG3
<bneo99> logcat http://pastebin.com/nibGtxV2
<kdub> i'd guess "E/ti_hwc  (    0): Post2 error" means that the fb module posting is perhaps returning an error rc
<bneo99> how about the egl errors before
<bneo99> E/libEGL  (    0): validate_display:262 error 3008 (EGL_BAD_DISPLAY)
<kdub> eh, yeah, might be a pixel format selection problem perhaps
<greyback> alan_g: a warning in case you hit it: some Qt apps like to create one or several transparent 640x480 surfaces under the main window
 * greyback discovered the reason why his window raise stuff wasn't working with some Qt apps
<alan_g> greyback: that's just weird
<anpok> greyback: qtubuntu question - If I need a mir connection inside a qt plugin..
<anpok> but there is not QGuiApllication yet..
<anpok> or might never have one..
<greyback> alan_g: yep. I had the misfortune to choose QT_QPA_PLATFORM=ubuntumirclient /usr/lib/x86_64-linux-gnu/qt5/examples/widgets/mainwindows/application/application as a test Qt app (from qtbase5-examples)
<alan_g> better to find these corners now than later
<greyback> anpok: good question, am reading code to see
<anpok> hm I do wonder if thats a valid scenario.. stumbled over that issue in the qtsysteminfo plugin
<greyback> afaics qt only loads the platform plugin for a QGuiApplication
<greyback> as the assumption was only GUI apps would want to talk to mir
<greyback> ofc you can create a QGuiApp, and just not create a qwindow
<greyback> so it can be command line, but still have a mir connection
<anpok> greyback: and not pass any argc/argv to it... is this a bad thing for a plugin to do *conditionally*?
<greyback> anpok: please rephrase, I'm not following you
<anpok> greyback: creating a QGuiApplication object to obtain a nativeinterface/MirConnection when none is available because the calling application is not a gui application
<anpok> or better fail.. in a friendly way.
<greyback> anpok: plugin should not create QApplication instance, just to get the mir connection
<greyback> unfortunately Qt not really designed to do what you ask, talking to mir without having a GUI isn't a typical use-case for an app author
<greyback> you'll have to create the mir connection yourself
<TheKit> is there any test that would use OpenGL ES on Android to render to buffer instead of HWC backend?
<TheKit> mir_android_diagnostics --gtest_filter="AndroidMirDiagnostics.client_can_draw_with_gpu" should be this one according to the description
<kdub> TheKit, yes, that should be one
<kdub> the thing is, you have to go with HWC to post to framebuffer with OpenGL on hwc 1.1 or later
#ubuntu-mir 2016-08-26
<duflu> RAOF: This is almost landable except for a conflict: https://code.launchpad.net/~raof/mir/fix-clang-detection/+merge/303364
<duflu> (landable by hand anyway)
<RAOF> Yeah, I'll get on to that this afternoon.
<duflu> RAOF: This is a fun/curious little bug too :)  https://bugs.launchpad.net/mir/+bug/1563210
<ubot5> Launchpad bug 1563210 in Mir "CI Failure in DisplayConfiguration/DisplayFormatSetting.can_get_all_output_format/{6,2}" [High,Triaged]
<duflu> Valgrind says: Your Android code is full of errors :(
<duflu> "Your" meaning not ours, but Android's
<RAOF> WTF?
<RAOF>            [this] { return configure_display(); });
<RAOF> ...
<RAOF>     void configure_display()
<TheKit> what is the way to go to debug "E/ti_hwc  (    0): Post2 error" (http://pastebin.com/nibGtxV2) with error code fffffff2 (-EFAULT)?
<TheKit> I found HWC source code for the device, but Post2 comes either from FB hal or gralloc module, which is probably binary blob
<anpok> usually guessing
<anpok> try to find a working set_list / post configuration..
<TheKit> you mean the arguments to Post2, or?
<anpok> oh
<anpok> I would rather first figure out why you get EGL_BAD_DISPLAY
<TheKit> from what I could find, it can happen if eglTerminate() is called without assigned display
<anpok> TheKit: hm I guess first look which call emits that error log..
<anpok> then figure out what special behavior might work around that issue on that device
<TheKit> ok, thanks
