#ubuntu-mir 2013-06-24
<robert_ancell> come on jenkins... land those merges
<robert_ancell> kgunn, up for some Sunday Mir fun?
<kgunn> robert_ancell: maybe...just kind of checking in
<robert_ancell> kgunn, did you resolve your system compositor issues?
<kgunn> nope....
<robert_ancell> :(
<kgunn> but realized i'm intel 64bit
<kgunn> and know that was failing build
<kgunn> (honestly i hadn't tried again due to that)
<robert_ancell> kgunn, I'm amd64 here. It was i386 that was failing build, but that shouldn't affect you
<kgunn> robert_ancell: why wouldnt it effect me ?
<robert_ancell> kgunn, you should be using amd64 packages too right?
<kgunn> robert_ancell: i guess i'm lost/my assumptions are wrong
<kgunn> thot i would be on i386 packages
<kgunn> ...e.g. on an intel core you can use amd64  ?
<robert_ancell> kgunn, what does uname -a
<robert_ancell> say?
<robert_ancell> kgunn, yes, amd64 is the name for the 64 bit PC instruction set used in Debian (at least). Since AMD came up with it in the first place
<robert_ancell> Might be the GNU name methinks?
<kgunn> Linux kg-MacBookPro 3.9.0-7-generic #15-Ubuntu SMP Fri Jun 21 12:22:17 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
<robert_ancell> yep, you're using amd64 packages
<robert_ancell> So i386 issues shouldn't affect you
<kgunn> ah...so amd is just a leftover from the fact they did 64bit first
<robert_ancell> yeah, and whoever picked the string for it :)
<robert_ancell> Read amd64 == x86_64
<kgunn> ok....so i386 means 32 bit, and amd64 means 64bit....(doesn;t follow the vendor)
<robert_ancell> yeah
 * kgunn files aways a new learning about ubuntu nomenclature
<robert_ancell> We must have reached the tipping point - traditionally you had more trouble running amd64 Ubuntu, but now it's i386 having the issues :)
<robert_ancell> And then it will be amd64 having the issues and armhf working the best :)
<kgunn> robert_ancell: btw...i did try vt swtiching
<kgunn> and it still complained about libboost...wanting 49 altho i'm on 53 w/ standard saucy
<robert_ancell> so odd
<kgunn> robert_ancell: i basically went thru and dpkg'd -s  every
<kgunn> darn lib in the chain....all the depends...then i checked those depends
<kgunn> none of them were depending on v49 boosts that i could see
<robert_ancell> kgunn, did you try an apt-get remove --purge libmirserver0 and then reinstall?
<kgunn> will try that...
<robert_ancell> (don't think the purge will help but just in case)
<kgunn> i actually wondered....
<kgunn> i only did remove and no --purge
<kgunn> so maybe....will try
 * robert_ancell wishes the arm builders were faster
<kgunn> while we're waiting...how's the kiddo
<robert_ancell> takes 13 minutes just to start building
<robert_ancell> kgunn, good, getting more alert every day
<kgunn> robert_ancell: mom doing ok? recovering....
<robert_ancell> kgunn, yeah, she recovered from the c-section super fast so all good there. A bit sleep deprived but doing ok :)
<kgunn> that's great
<kgunn> ....well the recovery part
<kgunn> not the sleep deprivation part
<RAOF> That bit's just the price of admission :)
<robert_ancell> RAOF, it was in the fine print :)
<robert_ancell> thomi, RAOF, this arm saucy build problem is a known thing right? https://launchpadlibrarian.net/143239191/buildlog_ubuntu-saucy-armhf.lightdm_1.7.3bzr1628saucy0_FAILEDTOBUILD.txt.gz
<thomi> /usr/lib/arm-linux-gnueabihf/libEGL.so.1: undefined reference to `mir_egl_mesa_display_is_valid'
<thomi> robert_ancell: looks to me like something in RAOF's dept. Not a problem I'm aware of
<RAOF> robert_ancell: What PPA is that in? Mir wasn't building on armhf in the PPA for a good long while.
<robert_ancell> RAOF, staging
<RAOF> Awah?
<RAOF> What's happening there?
<RAOF> How has libegl1-mesa failed to pick up a dependency on libmirclient?
<duflu> RAOF: It's blocked by https://code.launchpad.net/~vanvugt/mir/fix-1192908/+merge/170770
<duflu> In fact, most of our PPA builds are blocked by that
<duflu> Someone can unlock the build pipe with https://code.launchpad.net/~vanvugt/mir/fix-1192908/+merge/170770
<duflu> :)
<duflu> -unlock +unblock
<robert_ancell> duflu, reviewing
<robert_ancell> duflu, do we just need that to unlock and then can remove it?
<duflu> robert_ancell, it will be needed so long as we ever intend to bump the soname of mirclient again
<robert_ancell> i.e. once libmirclient.so.0 disappears
<robert_ancell> yeah, just thought of that
<RAOF> We should really split mirclient into a separate source.
<duflu> robert_ancell, if you want a quick-fix then just modify the recipe for building Mir to not use Mir-Mesa
<duflu> but regular Mesa instead
<robert_ancell> RAOF, agreed
<duflu> I totally disagree. There's too much overlap between the projects
<duflu> You would also create a "shared" project, a "demos" project...
<duflu> Too many
<robert_ancell> duflu, well, demos should follow the mirclient source
<robert_ancell> shared is a pita, agreed
<duflu> robert_ancell, and then there's our tests which are client _and_ server in one :)
<RAOF> As long as we can bootstrap from a non-Mir-enabled mesa I guess we don't strictly need a separate source.
<robert_ancell> RAOF, if our changes go upstream we can't do that..
<RAOF> Well, we kindof can.
<duflu> I would actually prefer just going back to libmirclient.so.0 to match the version :)
<RAOF> Everyone already has a mir-less mesa which they can use to build Mir, and then use that Mir to build a mir-full mesa.
<RAOF> The bootstrap sucks a bit, but it's not *too* onerous.
<robert_ancell> duflu, I don't get how the version is involved here
<duflu> robert_ancell, the soname bump in r749 caused this problem
<duflu> If we go back to zero then it is OK
<duflu> But saucy will need a similar bootstrap to go back
<robert_ancell> We need to be able to version our libraries properly
<duflu> OK, and my proposal allows any number of future bumps
<duflu> (with modification when we bump the ABI soname)
<robert_ancell> yeah, we need to make +1 the versions in that case right?
<duflu> Yes, add another symlink for each old version
<duflu> I'm all for finding a nicer EGL-related solution. But can we please land something in the mean time? This FTBFS is holding me up, and the PPAs
<RAOF> But the symlinks are lies, right?
<robert_ancell> yes, me too
 * RAOF is happy to temporarily unblock duflu 
<robert_ancell> RAOF, yes, and there's no guarantee they will work if the ABI has broken majorly
<kgunn> reboot
<duflu> RAOF: Only lies to the binaries we run during build (tests)
<duflu> And even then it's closer to the truth
<RAOF> duflu: Right. But as soon as we change the ABI in a way that affects mesa those binaries will fail to run because of linker errors anyway.
<duflu> They don't have to *work*
<duflu> It just has to build
<duflu> Because we link to the new version that *works*
<duflu> And test cases do work. Because they now link to just one (right) version
<RAOF> I don't see how?
<duflu> RAOF: Mir's tests run against it's local binaries.
<duflu> RAOF: Yes EGL clients will fail, but only until EGL is rebuilt
<RAOF> None of Mir's tests link to EGL?
<duflu> They fail right now
<duflu> RAOF: Yes they do. libmirserver uses it. But not as an EGL client. So the important functionality is never used
<duflu> Not as an EGL Mir client
<robert_ancell> RAOF, damn, now I realise why you rebuild binaries on copy.  I need to rebuild u-s-c, what method are you doing for +build1? Just dput it up?
<RAOF> robert_ancell: Correct, I just dput up a +build1 :)
<RAOF> duflu: But loading EGL is going to cause the linker to try and resolve its symbols, right? If we've broken that ABI, the linker is still going to fail?
<duflu> RAOF: Just to clarify - My fix forces the link to use the correct library (the new one). The symlink just pleases the runtime linker which has old links to version 0 from EGL
<RAOF> ie: even if the tests don't use any Mir client EGL platform code, the Mir client EGL platform code still needs to access the symbols it needs.
<duflu> RAOF: Only clients with indirect links to the old libmirclient.so.0 will fail. Not after Mesa is rebuilt
<RAOF> duflu: Right; a mesa rebuild fixes everything no matter what we do.
<duflu> RAOF: Right, but a Mesa rebuild will fail without my fix
<duflu> And is failing
<duflu> We need Mir to build successfully. And then that allows Mesa to build, finally
<RAOF> I still don't see why a test-full build of Mir wouldn't fail under not-too-unlikely (but not current) circumstances with this hack, but I'm not unhappy to have this hack to unblock you.
<duflu> Another possible solution is to avoid linking our test code to EGL. But that's difficult while libmirserver always needs it
<duflu> RAOF: Look at the PPA build logs to see the errors it avoids
<robert_ancell> kgunn, this message is always fun "No commit message was specified in the merge proposal. Click on the following link and set the commit message (if you want a jenkins rebuild you need to trigger it yourself):"
<robert_ancell> Let me know if you need deciphering
<RAOF> duflu: Right, and I think *this particular* ABI break doesn't break ABI in such a way that diverting the runtime linker from libmirclient0 to libmirclient1 will fail in the tests.
<duflu> RAOF: Correct. Our tests don't need functioning Mir-EGL compatibility.
<RAOF> duflu: But "functioning" is not the barrier we're trying to clear.
<duflu> No. In fact, our tests technically should not depend on having a graphics head
<duflu> So really should not depend on EGL in future
<RAOF> duflu: The barrier we're trying to clear is âthe dynamic linker will load libEGLâ, and I'm pretty sure that we can break ABI in such a way that diverting libmirclient.so.x to libmirclient.so.(x+1) will result in the dynamic linker *not* successfully loading libEGL.
 * robert_ancell -> lunch
<RAOF> duflu: Anyway, I've approved that. Unblock away!
<duflu> RAOF: The runtime linker only every loads the correct (new one). The hack is only to trick build-time linkage. Hence ABI breaks don't matter
<duflu> The important thing is to link to the version of a library that you will use at run time. And we are doing that
<duflu> If our acceptance-tests somehow become more dependent on having a working EGL head in future then we can tweak the tests
<duflu> Though they do get a working EGL server. Only EGL clients fail till Mesa is rebuilt
<RAOF> duflu: I don't the âABI breaks don't matterâ bit is true? What happens when libEGL uses mir_foo_two from libmirclient.so.2, and we remove mir_foo_two in libmirclient.so.3? Getting the runtime linker to load libmrclient.so.3 instead of libmirclient.so.2 doesn't help, because it now fails to resolve mir_foo_two?
<duflu> RAOF: We're not running the code that would refer to that missing symbol.
<RAOF> Unless you're lazily resolving symbols that doesn't matter.
<RAOF> We're not lazily resolving symbols, are we?
<kgunn> robert_ancell: i caught that 2nd reference to ppa a moment ago myself (doh)
<kgunn> i updated
<kgunn> do i have to hit "request another review" or some such ?
<duflu> RAOF: No lazier than the default ld.so behaviour
<duflu> Which is lazy
<kgunn> robert_ancell: back in a bit...family pressure to take an evening walk here...
<RAOF> duflu: That might be the source of my confusion, then!
<duflu> RAOF: ld.so is lazy unless you set LD_BIND_NOW
<duflu> All said, if we can find a way to weaken the Mir/EGL coupling more elegantly then that's awesome
<robert_ancell> no
<duflu> ?
<robert_ancell> no to kgunns last questions
<robert_ancell> Not a general no
<robert_ancell> duflu, though you get a no for running raring - we need to just support saucy. You can still use a raring desktop but your changes wont be tested against raring and packages wont be provided in the PPA
<duflu> robert_ancell: That's fine. I test saucy too
 * duflu wonders why we can't write software that's buildable with existing stable platforms, like the rest of the world does
<duflu> Maybe the deb format is somewhat to blame
<RAOF> duflu: Because we're trying to write the platform at the same time?
<duflu> Yeah, that's a bad plan
<duflu> Despite the fact it kinda works
<duflu> Except when it does not
<robert_ancell> RAOF, I need Mir >= 736 in the system-compositor PPA - what's the process to update?
<RAOF> robert_ancell: I copy-with-binaries Mir from staging to the PPA, then rebuild u-s-c.
<robert_ancell> RAOF, and what about everything else?
<robert_ancell> We need a big lock on the PPA - Lock it; make all the changes; unlock :)
<RAOF> Only things with a dependency on libmirserver0 need rebuilding, and that's just u-s-c.
<robert_ancell> ok, cool
<RAOF> robert_ancell: We can *kind* of do that - copy & build in a temporary PPA, then copy-with-binaries.
<robert_ancell> yeah, I guess
 * RAOF dislikes how adding a private non-virtual function to a class triggers a rebuild of everything :/
<duflu> RAOF: Fair point but do you really want your trigger to try and make intelligent decisions based on code analysis. Relying on such is dangerous if it's wrong
<RAOF> A different language design could remove that need entirely.
<duflu> RAOF: D++? Go? :)
<robert_ancell> RAOF, is this build not going to complete? i.e. should I just cancel it? https://launchpad.net/~mir-team/+archive/system-compositor-testing/+build/4741287
<duflu> RAOF, robert_ancell: What project/package should we target XMir bugs at?
<robert_ancell> duflu, whatever RAOF finds easiest. At the moment they're just against Mir
<duflu> Yeah that's easy. But technically we should only do that where the bug is in lp:mir
<robert_ancell> yep
<RAOF> Indeed.
<robert_ancell> It's kind of hard when we're not the upstream
<RAOF> I don't really care where they end up.
<RAOF> Oh, god. I'm going to need to write MockUdev to land this branch, aren't I?
<RAOF> duflu: D++, Go, C#, whatever :)
<RAOF> duflu: Maybe even C
<RAOF> duflu: Maybe even C
<RAOF> duflu: Maybe even C++-plus-a-module-RFC.
 * RAOF needs an <enter> key not quite so close to â-â
<robert_ancell> RAOF, that "indeed" refers to the i386 build?
 * robert_ancell bets RAOF replies with "indeed"
<RAOF> Incorrect!@
<robert_ancell> RAOF, incorrect on my bet or the i386 build?
<robert_ancell> CONTEXT ERROR CONTEXT ERROR
<RAOF> ERECURSIVECTX
<RAOF> That build is not going to finish.
<RAOF> And the only bugs filed against the Mir project should be bugs in lp:mir.
<RAOF> Also, needing to write MockUdev means that it's an excellent time for lunch!
<duflu> Hmm... OK I'm just going to assume XMir will get fixed (if not already) and the bug is invalid for lp:mir [https://bugs.launchpad.net/bugs/1192957]
<ubot5> Launchpad bug 1192957 in Mir " /usr/lib/xorg/modules/extensions/libxmir.so: undefined symbol: mir_surface_next_buffer" [Undecided,Invalid]
<duflu> RAOF: Would it help in any way to move struct defs like MirMesaEGLNativeSurface into Mesa? I'm not sure it would [MirMesaEGLNativeSurface]
<duflu> [https://bugs.launchpad.net/mir/+bug/1192908/comments/2]
<ubot5> Launchpad bug 1192908 in Mir "Mir/Mesa packaging have a dependency cycle so neither can build" [Critical,In progress]
<RAOF> duflu: That's fixed in Saucy; I haven't built a raring XMir, sorry.
<RAOF> I'll upload one, just for you!
<duflu> RAOF: That's OK I only use XMir on saucy :)
<duflu> RAOF: No raring required there
<duflu> RAOF: Oh, umm, seems I do have it installed. I wonder how necessary that is
<RAOF> duflu: It won't load the xmir module unless you try to use it.
<duflu> RAOF: Yeah I don't need XMir fixed for raring thanks
<RAOF> Why am I not drinking a coffee?
 * RAOF goes to remedy this.
<duflu> ... although the person who logged the bug might be on raring (https://bugs.launchpad.net/mir/+bug/1192957)
<ubot5> Launchpad bug 1192957 in Mir " /usr/lib/xorg/modules/extensions/libxmir.so: undefined symbol: mir_surface_next_buffer" [Undecided,Invalid]
<duflu> RAOF: As XMir is a nice loadable module, can we not make it a nice separate deb package too?
<duflu> Also, can anyone tell me what the changes are that we need in xserver-xorg-video-* ?
<RAOF> duflu: The loadable module, yes. We also need core patches to make it work (such as the option handling, autoload, etc).
<duflu> RAOF: Yeah I expected those core changes. But that's only a small part right?
<RAOF> Yeah.
<robert_ancell> RAOF, those core changes useful for upstream?
<RAOF> duflu: The changes to xf86-video-* are basically 1) Don't open the drm device directly; get it from XMir, 2) Don't do any modesetting, 3) Hook up a couple of callbacks.
<duflu> Ah OK
<RAOF> robert_ancell: A small number, yes.
<robert_ancell> RAOF, Have they been proposed?
<RAOF> Not yet.
<RAOF> Although I think I may have proposed all the bugfixy bits.
<RAOF> I should check.
<robert_ancell> X.org still uses mailing lists for patches right?
<RAOF> Yes.
<robert_ancell> *sigh*
<RAOF> But mostly the patches are âadd the -mir commandline optionâ, âadd the xorgMir global switchâ, âload the XMir module if xorgMirâ, etc.
<RAOF> There'll be a bunch of equivalent patches for XWayland, FWIW.
<robert_ancell> RAOF, are those flags just ignored if the module isn't there?
<RAOF> Not really.
<RAOF> Because it doesn't really make sense to pass -mir but get a non-XMir server.
<RAOF> They're entirely harmless if you don't pass -mir.
<duflu> Great another major compiz/unity regression I need to figure out and report
<robert_ancell> duflu, is this a related bug to the libmirclient one? https://launchpadlibrarian.net/143241855/buildlog_ubuntu-saucy-armhf.lightdm_1.7.3bzr1628saucy0_FAILEDTOBUILD.txt.gz
<robert_ancell> Note in this case nothing is linking to libmirclient
<robert_ancell> it looks almost like libEGL.so.1 is not linked against libmirclient
<robert_ancell> RAOF, where is your mesa branch again?
<RAOF> robert_ancell: github.com/RAOF/mesa
<duflu> robert_ancell, looks like a separate issue sorry
 * duflu runs to the shop
<robert_ancell> RAOF, aha, libegl-mesa-dev doesn't depend on libmirclient-dev
<RAOF> Does it need to?
<robert_ancell> RAOF, it has mir headers in it
<RAOF> Does it? Hm, ok.
<tvoss> good morning :)
<robert_ancell> tvoss, hello
<tvoss> robert_ancell, hey there :) just checked: mir in the ppa for i386 is failing still, right?
<robert_ancell> RAOF, in both lightdm and u-s-c libmirclient is not installed at all
<robert_ancell> tvoss, yes, I was trying to find your branches :)
<RAOF> robert_ancell: But that's right, isn't it? lightdm doesn't use mirclient, and u-s-c doesn't use mirclient.
<robert_ancell> RAOF, yeah, but libEGL links against it
<tvoss> robert_ancell, pushing them now, it's one branch that hopefully fixes the issues
<robert_ancell> tvoss, gimme gimme gimme
<robert_ancell> tvoss, fixed in mir?
<tvoss> robert_ancell, ack, although I have to say that it really only shows up in the weird builder configuration
<RAOF> robert_ancell: Yeah, and libEGL pulls in libmirclient1 *because* it links against it.
<robert_ancell> RAOF, but not on arm it seems?
<RAOF> Right, that's a WTF.
<robert_ancell> Does this normally just get worked around because of the -dev dependency?
<RAOF> Mesa doesn't (by default) have any headers that depend on Mir headers, though, so a dependency on libmirclient-dev is incorrect.
<robert_ancell> RAOF, /usr/include/EGL/eglplatform.h according to my system
<RAOF> robert_ancell: Behind a compile guard that's never defined.
<RAOF> At least in client code.
<RAOF> Although we could reasonably add that dependency.
<robert_ancell> it might solve the immediate problem
<RAOF> Eh, why not.
<RAOF> It's not incorrect.
<RAOF> Let me push that change...
<tvoss> RAOF, duflu, robert_ancell we still have the local gmock version, and I think we are good to remove it
<tvoss> or is there any reason we still carry it?
<RAOF> Because google are crazymad, I think.
<duflu> tvoss: Not sure, but someone should check certainly
<RAOF> And by âcrazymadâ I mean âdo not appreciate the position of a distributionâ.
<duflu> RAOF: What did Google do wrong?
<tvoss> duflu, we have gtest installed in source in /usr/src/gtest
<RAOF> duflu: Their basic stance for gmock (and gtest) is that you must include their source in your project and build them from that source during your build.
<tvoss> RAOF, although we still have gmock as prebuilt package available
<duflu> Hmm, why?
<RAOF> duflu: Because they're paranoid about C++ ABI, #define subtleties, etc.
<duflu> That's a fair point, but it's a problem they should let the distro own
<RAOF> Exactly.
<tvoss> robert_ancell, https://code.launchpad.net/~thomas-voss/mir/add-once-guard-to-gflags-shutdown
<robert_ancell> RAOF, will you run that through the PPAs and make sure all the armhf builds work?
<RAOF> robert_ancell: Sure.
<duflu> Awesome. GPU hang
<RAOF> Woo!
<robert_ancell> RAOF, I checked the .deb for libegl1-mesa using dpkg -I and it does not depend on libmirclient. So shlibs is not working for some reason
<robert_ancell> RAOF, I'll file you a bug
<RAOF> robert_ancell: But only, as far as I can tell, on armhf.
<robert_ancell> RAOF, yes
<RAOF> Which is weird.
<duflu> robert_ancell, https://bugs.launchpad.net/mir/+bug/1192908/comments/5
<ubot5> Launchpad bug 1192908 in mesa (Ubuntu) "Mir/Mesa packaging have a dependency cycle so neither can build" [Medium,Triaged]
<robert_ancell> duflu, but mesa has built, and it has Mir symbols in it. It's just shlibs in the debian packaging that doesn't think so
<duflu> robert_ancell, OK so not directly related
<duflu> But still both real issues
<robert_ancell> yeah
<tvoss> duflu, can you take a look at https://code.launchpad.net/~thomas-voss/mir/add-once-guard-to-gflags-shutdown/+merge/171017 and top-approve if you are fine with the changes?
<robert_ancell> bye all
<duflu> tvoss: Yeah sure. I will look at the transformation stuff this week too
<tvoss> duflu, cool, but let's get started with caching it before we completely move it to the gpu
<duflu> tvoss: Yes that's all I intended
<tvoss> duflu, cool :)
<duflu> Right now though I'm buried in Mir bug triage and testing
<duflu> There shouldn't be this much...
<tvoss> how do you mean?
<tvoss> duflu, ?
<duflu> tvoss: I mean just busy logging new serious bugs as I find them, and testing bugs for robert he wants to know they still exist
<tvoss> duflu, ack
<duflu> Argh! Now LP is broken
 * duflu logs bugs against LP
<tvoss> duflu, I'm encountering timeouts quite regularly with LP these days
<duflu> tvoss: No, it's a really dumb bug: https://bugs.launchpad.net/launchpad/+bug/1194007
<ubot5> Launchpad bug 1194007 in Launchpad itself "Launchpad jumps to invalid page: https://bugs.launchpad.net/baz/+bug/200" [Undecided,New]
<RAOF> Damnit! What the hell is my laptop doing?
<duflu> RAOF: Busy fan? I have that
<duflu> Maybe because https://bugs.launchpad.net/ubuntu-power-consumption/+bug/1194004
<ubot5> Launchpad bug 1194004 in compiz (Ubuntu) "Compiz wakes up 200Hz while the screen is locked" [Undecided,New]
<RAOF> Busy fan, 5 second delay on typing.
<duflu> Also, the compiz config is corrupt. It won't let me enter a valid frame rate
<duflu> RAOF: Mesa rebuild hiccups... configure: error: Package requirements (libdrm_radeon >= 2.4.45) were not met:
<tvoss> duflu, we need https://code.google.com/p/googlemock/issues/detail?id=79 to get rid of the local gmock version
<duflu> tvoss: Can't quite approve yet: https://code.launchpad.net/~thomas-voss/mir/add-once-guard-to-gflags-shutdown/+merge/171017
<RAOF> Aha! Something was swap-thrashing.
<duflu> RAOF: Yes, compiz... ?
<tvoss> duflu, agreed on your comment, however, we are hit by this issue on the buildd's and I don't know any other easy fix to workaround it
<RAOF> I don't *think* it was compiz. It might have been geary.
<duflu> tvoss: "buildd"?
<tvoss> duflu, the builders for ppa and archive
<tvoss> duflu, that's why the i386 build of mir in the system-compositor-testing ppa fails
<duflu> Hmm, kay. I'm just concerned we're not fixing the root cause and it will pop up on some other global
<tvoss> duflu, or better: hangs
<RAOF> The root cause would appear to be âPre 2.6 kernels suckâ :)
<tvoss> RAOF, with Daniel abstaining, would you mind taking a look here: https://code.launchpad.net/~thomas-voss/mir/add-once-guard-to-gflags-shutdown/+merge/171017
<tvoss> ?
<duflu> tvoss: Top approved still
<tvoss> duflu, ah :)
<tvoss> RAOF, cancel my comment then :)
<RAOF> tvoss: Sure. Was doing so before my machine entered swap-hell.
<tvoss> RAOF, ah
<duflu> RAOF: Oooh you mean (memory)-swap-thrashing and not (buffer)-swap-thrashing like I am seeing?.. :)
<RAOF> duflu: Indeed. memory-swap-thrashing.
<duflu> Thrashing of disks, not of framebuffers
<duflu> Hmm is it right that lightdm.conf ignores comments and typos?
<mlankhorst> RAOF: ping, can you accept xxv-intel and mesa in quantal/raring and precise-lts?
<RAOF> mlankhorst: Sure. Could you give me another ping in an hour or so if I haven't done it by then?
<tvoss> RAOF, mind uploading a new mir version to the sys-comp-testing ppa? the gflag fix just landed
<mlankhorst> sure
 * didrocks fights with this pthread issue on google-mockâ¦
<RAOF> tvoss: I'll wait until it's built in the staging PPA and then binary-copy it. That way it's easier to ensure that unity-system-compositor stays in sync.
<tvoss> RAOF, yup :)
<didrocks> RAOF: I'm starting to be out of options right now, did you fix some similar pthread issue regarding gtest? http://paste.ubuntu.com/5794746/
<didrocks> we can see that google-mock defines -pthread twice, one before the .la, one after, so it should be fine
<didrocks> I tried to add -L to standard path (which should be uneeded), using -lpthread in case we regresssed here in GNU gcc, and even adding intermediate -pthread flags
<didrocks> no luckâ¦
<tvoss> didrocks, I think it fails to link the internal gtest version
<didrocks> tvoss: yep, exactly
<tvoss> didrocks, wouldn't it be a better idea to link against our gtest version anyways?
<RAOF> didrocks: Urgh. That doesn't look like fun.
<RAOF> We don't have a gtest binary.
<didrocks> tvoss: what RAOF told ^ :)
<didrocks> (+ the unfun part as well :p)
<RAOF> didrocks: Did I fix that in gtest before? I don't recall if I did :/
<didrocks> RAOF: no, it was just in case you did get that somewhere into saucy by any luck
<RAOF> No, I haven't noticed that before.
<didrocks> ok, I'll continue digging
<RAOF> Baby time!
<didrocks> tvoss: ok, I'm out of any clue TBH, and seb128 spending some time last week on this unsuccessfully compensated a little bit the depressing feeling I started to get :)
<tvoss> didrocks, looking
<mlankhorst> RAOF: ping ;)
<duflu> Me joins the queue to talk to RAOF [https://launchpad.net/~mir-team/+archive/staging/+build/4741584]
 * duflu does too
 * mlankhorst hopes it's a fifo, not a stack
 * duflu push_front
<tvoss> didrocks, is it a good idea to rely on the deprecated autotools setup?
<didrocks> tvoss: can you be more explicit? :)
<tvoss> didrocks, the gmock source package does not use the cmake setup
<tvoss> didrocks, but uses the auto* setup
<didrocks> tvoss: ah, you are calling the whole "autotools" deprecated
<tvoss> didrocks, yeah, the setup is discouraged by google iirc
<didrocks> can we stop using that "deprecated" tool for anything? it's still used by the vast majority of free software
<didrocks> I would like we more concentrate on where we are going than downsiding a bunch of technologiesâ¦
<didrocks> that worked for years
<didrocks> I don't care about autotools vs cmake in particular, just that extra word was uneeded at leastâ¦
<didrocks> tvoss: to come back to the subject, we are using what upstream is using
<didrocks> so we can switch to cmake as they ship both
<seb128> didrocks, they have both in there, I think tvoss was suggesting that the gmock guys recommend using the cmake build
<didrocks> I would appreciate if we switch to them to send the patch to debian as well
<seb128> I pondered trying that to see if that fixes the build the other day
<seb128> but my cmake foo are not that great ;-)
<didrocks> seb128: it still doesn't explain the linking issue, but if by change this is not impacted :)
<didrocks> at least, maybe --enable-external-gtest will be picked
<didrocks> (which isn't the case I guess because of Makefile.am)
<tvoss> didrocks, why do we ship gmock different than gtest btw? gtest installs to /usr/src, which works just fine for us
<tvoss> or am I missing something?
<didrocks> tvoss: because the package comes from debian?
<tvoss> didrocks, does gtest come from debian, too?
<didrocks> IIRC, we did ourselves the gtest package
<didrocks> let me check
<didrocks> hum, it was remerged
<didrocks> tvoss: different maintainers
<didrocks> tvoss: we should standardize in a path and send the patch to debian I guess
<tvoss> didrocks, okay, why not have /usr/src/gmock, then?
<didrocks> tvoss: if it makes things easier, I'm fine with it
<didrocks> you don't want to ship binaries then?
<didrocks> only the sources
<didrocks> like for gtests and othersâ¦
<tvoss> didrocks, it's way easier for cmake based projects, and we have magic to support autotools, too
<tvoss> didrocks, yup
<didrocks> tvoss: we don't have any reverse dependencies for google-mock, let me check for build-reverse-dep before a final ack
<didrocks> tvoss: hum, we do have some though
<didrocks> apart from rlvm, coming from us
<didrocks> tvoss: http://paste.ubuntu.com/5794887/
<didrocks> they need to be converted to rebuild google-mock I guess, and not relying on the .so or .la
<tvoss> didrocks, hmmmm...
<didrocks> rlvm was in sync with debian, so better to ship the patch to them as well
<didrocks> (alongside the google-mock one)
<duflu> tvoss: On the other hand... having gtest/gmock inline makes building on other distros much easier, if they don't have it :)
<duflu> But you can argue that with all dependencies
<tvoss> duflu, yup
<didrocks> duflu: but it means that if there is a bug that you want to get fixed, you have to fix them in a bunch of different places :)
<duflu> didrocks: Yeah, OK, inline is bad
<duflu> Hmm, actually no, that's no a valid argument. Cos any issue that affects Mir will get fixed faster than distro.
<duflu> +t
<duflu> Arguably
<didrocks> duflu: well, let's say that you have a pthread issue
<didrocks> like now
<duflu> We do?
<didrocks> you have to fix it in 7 different projects
<didrocks> yep
<duflu> Fairy nuff
<tvoss> didrocks, just built the source package manually with the autotools toolchain (no dpkg-buildpackage), works fine
<didrocks> tvoss: right, because you don't use --as-needed I guess
<didrocks> tvoss: even without it
<didrocks> tvoss: did you run make check?
<tvoss> trying
<tvoss> RAOF, ping
<mlankhorst> no!
<tvoss> mlankhorst, ?
<tvoss> mlankhorst, oh sorry, I need to go to the queue
<mlankhorst> :D
<tvoss> didrocks, fails in run make check. The interesting thing is that the tests shouldn't link to gtest as they have fused_src compiled in
<tvoss> didrocks, I'm confused now
<didrocks> tvoss: what's this fused_src?
<tvoss> didrocks, it's all src and header files of gmock and gtest fusioned together by some python scripts
<didrocks> copying all src into the same .o?
<didrocks> interestingâ¦
<didrocks> tvoss: we can try to switch to the cmake version if needed
<tvoss> didrocks, let me first try to understand what's going on :)
<didrocks> no make check/make tests though
<didrocks> tvoss: ok, I'll be out for a short bit, will be back later on :)
<tvoss> didrocks, ack, need some breakfast, too
<didrocks> enjoy!
<tvoss> didrocks, thanks :)
<duflu> tvoss: I can't see the magic 18% CPU. Maximum 6%
<duflu> Any hints?
<tvoss> duflu, 18% within that function
<tvoss> duflu, I did a simple run with 1000 buffer swaps
<duflu> tvoss: No, all transformation logic only adds up to 6%. And only 3% in the glm matrix library
<duflu> I wonder what I'm missing
<tvoss> duflu, weird
<duflu> I did >66000 swaps
<tvoss> let me see if I can find my results
 * tvoss thinks that adding the respective callgrind logs to the bug reports would be a good idea
<duflu> Same issue really, just that I get 6% instead of 18%
<tvoss> duflu, do you think it's still worth fixing?
<duflu> tvoss: Yes I think so
<duflu> If we can gain it back easily
<tvoss> duflu, okay, do you have the callgrind trace handy? if so, mind attaching it to the bug report, too?
<didrocks> tvoss: hum, it seems the Mir licenses weren't updated when inlining new components in 3rd_party
<tvoss> didrocks, mind filing a bug?
<didrocks> tvoss: sure :) knowing the time I spent to fix it the first time, I would appreciate upstream then to file debian/copyright this time
<tvoss> didrocks, sure
<duflu> tvoss: Done
<tvoss> duflu, thx
<didrocks> tvoss: https://bugs.launchpad.net/mir/+bug/1194073, this is a prerequisite to have mir in distro
<ubot5> Launchpad bug 1194073 in Mir "debian/copyright is not up to date with latest files included in MIR" [High,Confirmed]
<tvoss> didrocks, ack
<didrocks> tvoss: do you know why we don't use cucumber from distro?
<didrocks> (no cpp bindings?)
<tvoss> didrocks, not sure, need to check with racarr
<tvoss> didrocks, might well be that we are able to pull it out, too
<didrocks> ancillary isn't in distro, so it's fine
<didrocks> let me open bugs for them
<didrocks> (gmock and cucumber)
<tvoss> didrocks, gmock bug should be there
<didrocks> tvoss: ok, let me add a tag to it
<tvoss> didrocks, ack
<didrocks> done
<tvoss> duflu, do we have a performance tag?
<tvoss> duflu, how about performance, performance-cpu, performance-gpu?
<duflu> tvoss: It appears not. Just "performance" is OK
<tvoss> duflu, ack
<didrocks> tvoss: we don't run tests on armhf?
<duflu> didrocks: We do during CI.
<didrocks> duflu: any reason we don't do that in the ppa?
<duflu> didrocks: No idea
<RAOF> duflu: Ah. Mesa is too new to build on raring.
<duflu> Ah dependency madness
<duflu> Though Mir does spend all its time in boost::asio stuff
<duflu> I might have to learn what that is
<tvoss> duflu, where do you see that?
<duflu> tvoss: In kcachegrind
<duflu> The boost/asio call graph is so huge and complex I haven't quite figured it out yet
<didrocks> tvoss_: mir_demo* are just technical demos, right? They can be combined to be used by another applications?
<tvoss_> didrocks, right, only technical demos. we use them for benchmarking purposes, too
<didrocks> tvoss_: I would add them in a examples/ directory rather
<tvoss_> didrocks, we had that discussion before within the team
<tvoss_> didrocks, or do you mean for the packaging?
<didrocks> what was the outcome? do you have anything written you can share?
<didrocks> tvoss_: for the packaging
<didrocks> like usr/lib/<triplet>/mir/examples
<didrocks> (I'm going to multiarch mir as well)
<tvoss_> didrocks, @install: sounds sane, for the discussion: it was informal but I cannot even recall the conclusion
<didrocks> same for mir_stress
<didrocks> ahah :)
<tvoss_> didrocks, so I do not have any strong feelings
<didrocks> tvoss_: yeah, seeing the number of bins, I think have usr/lib/<triplet>/mir makes sense
<didrocks> tvoss_: libmirserverlttng.so being shipped alongside the server is wanted?
<didrocks> it's only for instrumenting it, right?
<tvoss_> didrocks, right
<didrocks> tvoss_: shouldn't that be in the -tools package rather then?
<tvoss_> didrocks, good point
<tvoss_> didrocks, but please check with alf, too
<didrocks> tvoss_: yeah, I'll do a MP anyway
<tvoss_> didrocks, yup
<tvoss_> RAOF, installed from testing ppa, works fine :)
<RAOF> tvoss_: Woot!
<tvoss_> RAOF, a crash in plymouth after login, but that has been reported since 11.10
<didrocks> tvoss_: urgh, lib is hardcoded as a destination in all MIR cmake file, I'm fixing it
<RAOF> GRARGH! Why is my open() only being called _sometimes_?!
<duflu> GMock! Tell me which function is has no default action!
 * RAOF decides that 9pm really isn't the time to play second-guess-the-linker.
<mlankhorst> But it is the perfect time to write your own linker! :-)
<tvoss_> mlankhorst, rofl
<tvoss_> mlankhorst, mind giving ppa:mir-team/system-compositor-testing a spin on some nouveau hw?
<duflu> No, really. If GMock doesn't tell me which function needs fixing and gdb doesn't show it in the call stack, how do you find out?
<mlankhorst> tvoss_: in a bit, need to finish my recompile first :-)
<tvoss_> mlankhorst, I have an amd here
<mlankhorst> oh btw the kernel dma-buf slowness fixes for amd will be in 3.11
<tvoss_> mlankhorst, \o/
<duflu> tvoss_, OK, done
<duflu> https://code.launchpad.net/~vanvugt/mir/fix-1193020/+merge/171070
<tvoss> mlankhorst, finished your rebuild?
<mlankhorst> tvoss: yeah but got preempted by a security update collission with -proposed
<tvoss> mlankhorst, oh
<mlankhorst> I'll check now
<mlankhorst> tvoss: ok i installed it, what do I need to test?
<tvoss> mlankhorst, restart, see if xmir runs and you are annoyed by the additional cursor distracting you permanently :)
<mlankhorst> I only have 1 cursor when testing on radeon, fwiw
<tvoss> mlankhorst, interesting
<mlankhorst> then again might be intel too *checks*
<mlankhorst> tvoss: oh there is a cursor in upper left
<tvoss> mlankhorst, yup :)
<mlankhorst> intel seems to be loaded
<arsson> with nouvea still two cursors
<mlankhorst> tvoss: I forgot that mir doesn't support hybrids yet :/
<tvoss> mlankhorst, yup
<tvoss> arsson, did you install from the system-compositor-testing ppa?
<arsson> yup
<mlankhorst> is it hardcoded to /dev/dri/card0 by any chance?
<tvoss> arsson, the second cursor is meant to be there until we find have a more subtle way to say: you are running a system-compositor :)
<tvoss> mlankhorst, would need to check the source, too
<mlankhorst> oh worse..
<mlankhorst> it just runs through an array with i915, radeon and nouveau and grabs the first one that works
<mlankhorst> which fails when the first one in the array is not boot_vga
<tvoss> mlankhorst, patches are welcome :)
<mlankhorst> tvoss: unfortunately not very easy to do without udev discovery
 * kgunn hoping mlankhorst hangs out here with us alot :)
<mlankhorst> I only have hybrid laptops to test nouveau with atm though ;P
<mlankhorst> not even muxed
<tvoss> mlankhorst, okay
<katie> tvoss ping
<tvoss> katie, pong
<katie> tvoss do you have 15 mins to have a chat with myself and mpt?
<tvoss> katie, not right now, a bit later?
<katie> tvoss, ok, after 4.30 is ok for me
<tvoss> katie, cool, thx
<tvoss_> kdub, ping
<tvoss_> kdub, mind taking a look at: https://code.launchpad.net/~vanvugt/mir/fix-1193020
<tvoss_> ?
<kdub> tvoss_, sure
<kdub> good morning channel
<tvoss_> kdub, good morning, and thx
<racarr> AAMorning
<greyback> racarr: and a happy sober morning to you too
<racarr> greyback: XD
<racarr> keyboard error
<greyback> http://i.imgur.com/lLdt36t.jpg is me after 6 hours of XMir and dual cursors
<racarr> hahahaha
<racarr> hangout? https://plus.google.com/hangouts/_/8015a964c25dbb4a92528d82f94676c27eb14a7a
<greyback> coming
<kdub> is alf around today?
<sil2100> tvoss: hi!
<sil2100> tvoss: how's the PPA-setup going?
<kgunn> kdub: national holiday for alf
<kdub> ah, ok
<kgunn> kdub: you stuck
<kgunn> ?
<kdub> eh, i know that resizing is probably needed for the xmir stuff, might get started on that
<kdub> i tinkered with sf enough to see how it resizes last week while tinkering with driver refcounting :)
<kgunn> kdub: cool
<didrocks> kgunn: hey, FYI, this is my MP for getting MIR almost good to enter the archives (I just need to find a way to fix one additional thing, but need to check with a lttng expert first):  https://code.launchpad.net/~didrocks/mir/packages-fix/+merge/171140
<didrocks> kgunn: https://bugs.launchpad.net/mir/+bugs?field.tag=entering-saucy is the bugs that need to be discussed and fixed before entering saucy. I'll need your team on this
<didrocks> kgunn: especially debian/copyright, as I cleaned it 3 months ago and it's totally out of sync with the new 3rd party librairies that got included, so would be nice to have your team fixing this :)
<racarr> lol...khonos_uint32_t strikes again
<kdub> anyone object to the separate libgraphicsplatform.so? (dlopen'd). its ready to land, last chance to object
<racarr> kdub: Sounds good :)
<kdub> kgunn, is the difference between 'system compositor testing' and 'staging' ppa that the staging is just the latest of everything, and 'testing' should break less often?
<kgunn> kdub: yep that's the idea
<racarr> Lunching while bunches of things download on my phone :)
<racarr> back soon
<racarr> back :)
<kdub> racarr, ping
<racarr> kdub: pong
<racarr> sorry was wrapped up in
<racarr> [       OK ] TestClientInput.clients_do_not_receive_motion_outside_input_region (16 ms)
<racarr> :)
<racarr> you can put holes in windows now
<kdub> oh really?
<racarr> Yeah the shell will be using it
<racarr> its input only now..eventually it would be cool if we could
<racarr> clip to the region
<racarr> as an optimization for the giant ullscreen shell with lots of transparency (which is what is happening now on SF)
<racarr> Aha, the input stack gained support for resizing and moving
<racarr> as a free bonus
<kgunn> racarr: thats kinda cool
<racarr> Just finishing off the "input shape" stuff for the shell
<kgunn> robert_ancell: i painstakingly looked at each version of my libs to make sure the version matched system-comp-testing ppa
<kgunn> just to be sure
<kgunn> when you say i have an old mir....when i see orange arrow
<kgunn> is that simply libmirserver0 ?
<robert_ancell> kgunn, yes
<kgunn> robert_ancell: ta, double check
<robert_ancell> Did you try setting fire to your computer, buying a new one and adding the PPA again?
<kdub> racarr, now just the buffers need resizing :)
<kgunn> robert_ancell: i am close :)
<kgunn> arg...double check...dpkg -s yeilds 0.0.4bzr766saucy0 which is exactly whats in the ppa
<kgunn> i actually want it to be wrong
<kgunn> itd make sense
<kgunn> searching entire fs for libmirserver0
<kgunn> robert_ancell: couple of other oddities...upon boot (not even trying xmir)
<kgunn> i get a race...which i have to hit keys really fast then i boot (otherwise i freeze on cursor screen, no way out)
<kgunn> also...once i boot...i end up on vt8, instead of vt7
<kgunn> which i only discovered in the logs
<kgunn> and then wehn i do try mir_demo_server i see big orange arrow (BOA)
 * kgunn tired of typing big orange arrow
 * kgunn searches internet for best laptop combustion accelerant 
<robert_ancell> kgunn, lightdm.log? It should show why it picked VT8
<kgunn> lightdm.log -> https://pastebin.canonical.com/93333/
<kgunn> and then usc log -> https://pastebin.canonical.com/93334/
<robert_ancell> kgunn, oh, looks like we don't release the VT when the compositor dies, so the fallback X server starts on the next one (8)
<kgunn> btw, there is no other libmirserver0 on my system...just the one fresh w/ todays date, rev matching ppa...but yet still see BOA
<robert_ancell> kgunn, is that the whole usc log? It's truncated
<kgunn> i can repaste the whole thing...that was the interesting bit
<kgunn> https://pastebin.canonical.com/93335/
<kgunn> entire usc log ^
<kgunn> rebooting...
<kgunn> robert_ancell: so now i can't tell if i'm seeing a real error...or a "its just me prob"
<kgunn> i'm pretty sure everything got cleanedup
<robert_ancell> kgunn, so that log shows you do have an out of date libmirserver0 - it doesn't have the --vt option
<kgunn> robert_ancell: but every thing i check says i only have 1 and its from the ppa today...ideas on verifying ?
<kgunn> (btw, i already did ppa purge earlier...and it seemed to work)
<robert_ancell> kgunn, Can you do a find in /usr/local etc, and see if you have some locally build one?
<robert_ancell> kgunn, ok, try the following, and I will confirm on my system
<robert_ancell> dpkg -s unity-system-compositor|grep Version
<robert_ancell> ldd /usr/bin/unity-system-compositor
<robert_ancell> unity-system-compositor --help
<kgunn> Version: 0.0.1bzr29saucy0.79
<robert_ancell> kgunn, same
<kgunn> robert_ancell: ok...fme....this is too weird
<kgunn> from the ldd i have "	libmirserver.so.0 => /usr/local/lib/libmirserver.so.0 (0x00007fb3b5b11000)"
<kgunn> but if i go check...its not there
<kgunn> wtf
<kgunn> oh...nvmd..i lied, typo
<kgunn> damn it...May 20th
<robert_ancell> whoops :)
 * kgunn note to self...don't look for libmirserver0...but libmirserver*
<kgunn> robert_ancell: you have the patience of Job...thanks
<kgunn> robert_ancell: i'll blow those away..purge again....and reinstall
<robert_ancell> kgunn, you should be good to just reboot and try again
<kgunn> reboot
<robert_ancell> hmm, where is kgunn...
#ubuntu-mir 2013-06-25
<robert_ancell> kgunn, how did it go?
<kgunn> robert_ancell: thanks again...vt mir demo working
<robert_ancell> \o/
<kgunn> altho boot was still wonky
<kgunn> let me check logs
<kgunn> ok, symptom first...it hung first time in same way, striking keys like mad 2nd time...got it to boot
<kgunn> so still jumped to vt8
<kgunn> but here's the usc log -> https://pastebin.canonical.com/93337/
<kgunn> at least it was quite diff this time
<kgunn> gotta run...getting yelled at
<RAOF> Ok, what the whatting what?
<RAOF> duflu: Do you have any experience interposing libc symbols? Particularly: I want bin/unit-tests to wrap open()
<duflu> RAOF: Yes, sadly
<RAOF> Or, even more particularly, I want:
<RAOF>         // If directly opening the DRM device is good enough for X it's good enough for us!
<RAOF>         tmp_fd = open(dev_path, O_RDWR, O_CLOEXEC);
<duflu> RAOF: Your new symbols need to be in a new SO
<RAOF> to go through the mock.
<duflu> RAOF: They need to be in a new SO, _and_ LD_PRELOAD'd if they're to override libc
<RAOF> duflu: Really? Urgh. Looking at the LD_DEBUG=binding output, I see that libudev is binding open() to bin/unit-tests, and my open64 wrapper is getting called (by pthreads, apparently), but libmirserver.so.0 never binds open().
<duflu> Cos normally libc gets in before all your SOs
<duflu> RAOF: The SO will use its own, but if you want process-wide wrapping then LD_PRELOAD
<RAOF> I don't suppose -Wl,-z interpose would make this less painful?
<duflu> Hmm, could do
<duflu> Not sure
<duflu> RAOF: If it's not loaded early, properly, then you'll get some libraries using your version and some using libc's, which is bad
<RAOF> Heh
<duflu> And don't forget to call the real open(), which you will find by dlsym(RTLD_NEXT, "open")
<RAOF> Yup.
<RAOF> My wrapper works fine (as demonstrated by open64).
<duflu> RAOF: We're lucky it's easy on Linux. When I did it in Windows I had to edit the binary instructions by hand at the start of each function :)
<RAOF> That sounds like much more fun!
<duflu> Which is not so easy on x86 because instructions vary in size. So you have to interpret them first.
<RAOF> Couldn't you have just padded all your functions with enough noops to make that easier?
<RAOF> Also: boo. -z interpose is not teh win.
<RAOF> ...
<RAOF>  !!!
<duflu> RAOF: Not my functions. They were Microsoft's :)
<RAOF> So, my open() wrapper works, as evidenced by LD_PRELOADING it and gdb spitting out the debug spew I've made it emit.
<RAOF> But, for some reason, tmp_fd = open(dev_path, O_RDWR, O_CLOEXEC); is *not* wrapped.
<RAOF> Oh.
<RAOF> That's not fair.
<RAOF> It's because that line is never called, because of an incorrect â!â further up the function.
<nall> trying to make this work on VMWare still
<nall> mir_demo_client_egltriangle ends on creating a shared ptr for GBMClientBufferFactory and then the server starts executing
<RAOF> nall: It's not going to work in vmware at the moment; we require dma-buf support from the kms driver, and vmware does not have that support.
<nall> K,gotcha.  Thanks
<RAOF> We do *want* to support vmware, and a fallback non-accelerated case if possible.
<RAOF> If you want to write code, there's code to be written :)
<nall> Yeah, I'm just trying to figure out where to start.
<nall> I'd love to run Ubuntu natively on my machine but it's a company computer and the only one I've got.
<tvoss> good morning :9
<duflu> tvoss: Go back to bed you silly man
<duflu> And good morning
<tvoss> duflu, :) all good, today is my early-bird day :)
<duflu> tvoss: Were you by any chance profiling Mir with 3 clients/surfaces? (like multiwin?)
<tvoss> duflu, nope, I started single client
<duflu> tvoss: Which one?
<tvoss> duflu, I think not even an egl one
<duflu> tvoss: Multiwin would create 3 surfaces, hence 18% I guess
<tvoss> duflu, ack
<tvoss> duflu, the shell/mobile guys were quite happy to hear about cpu optimizations, too
<duflu> Though mathematically that does not scale accurately
<tvoss> duflu, yup :)
<duflu> tvoss: Yeah it's quite useful. Re-proposing just now
<tvoss> duflu, did my comment make sense?
<duflu> tvoss: Yes I added refs
<tvoss> duflu, great
<duflu> As usual, spent more time figuring out the gmock errors than making the change
<tvoss> duflu, for the glclear: How about having an interface ScreenClear that is given to the renderer? We could add a null implementation
<tvoss> oops, we made it slashdot :)
<duflu> tvoss: Yes you got slashdotted
<duflu> tvoss: Not sure which class, but the shell should be allowed to override the clear with anything
<duflu> tvoss: But then that may become generalized as I figure out a framework for transitions and animations (my main task)
<tvoss> duflu, ack, I just want to get rid of the glclear in a sane way on a short timescale
<duflu> tvoss: https://code.launchpad.net/~thomas-voss/mir/wait-for-vt-to-become-active-before-setting-mode/+merge/171099/comments/381497
<tvoss> duflu, not entirely sure, I was thinking about a test case, but hard to come up with one
<duflu> tvoss: There is no sane alternative to glClear until the shell renders a background of its own. And even then there's no benefit cos the wallpaper still takes up server CPU time
<duflu> Also, I think it was much less than 19% yesterday
<robert_ancell> RAOF, where is the debian branch for the mesa build?
<RAOF> robert_ancell: In the ppa-somethingorother branch of github.
<tvoss> duflu, fair, but do we really need to clear in the mobile case? the shell will fill the entire display anyways
<tvoss> robert_ancell, RAOF good morning :)
<RAOF> tvoss: Good morning.
<robert_ancell> tvoss,  very early morning to you
<tvoss> robert_ancell, yup, my early bird day such that I can hug you guys :)
<RAOF> tvoss: https://code.launchpad.net/~raof/mir/prober-drm-device-probe/+merge/170765 is ready to roll, and should help us understand where sabdfl's laptop is failing
<tvoss> RAOF, great, let me give it a review
<tvoss> RAOF, sabdfl was hit by an Input/Output error while setting the mode on the vt, which made me look into the X code for setting up shared vt's -> VT_WAITACTIVE
<tvoss> RAOF, fails CI on amd64
<RAOF> tvoss: Ah, it's just finished then.
<duflu> tvoss: The switching animation on mobile still shows black background, briefly, no?
<duflu> As the old surface moves away, it no longer fills the screen
<tvoss> duflu, nope :) that's faked, the shell always paints completely on top and just moves a screenshot of the surface around
<duflu> Hence you need a glClear before that
<duflu> tvoss: I mean when it's done properly. You still need a clear
<duflu> Most frames... but not all
<tvoss> duflu, +1 :9
<duflu> I am trying to avoid any nasty occlusion calculations like compiz does
<duflu> For as long as possible
<duflu> But we'll need it for basic fullscreen testing
<RAOF> tvoss: Boo. That doesn't happen locally, of course.
<tvoss> RAOF, a quick one at first glance: in class UdevHelper: mind making the ctx pointer private? or class -> struct if you only want value-semantics?
<RAOF> It's a failure to interpose the open() wrapper, which I *thought* I could get away with but it looks like duflu is annoyingly correct
<RAOF> âº
<tvoss> robert_ancell, welcome back :)
<robert_ancell> session crash :(
<RAOF> tvoss: Sure. I
<duflu> LD_PRELOAD FTW
<RAOF> tvoss: As the comment mentions, it's going to want to grow into a fully-functional libudev wrapper.
<RAOF> duflu: On *my* system LD_PRELOAD is unnecessary :(
<RAOF> Which is going to make testing the fix rather annoying.
<tvoss> RAOF, fair, but just make the class a struct then :)
<RAOF> tvoss: Ok.
<tvoss> hmmm, how can we check if the kernel supports vt's at runtime? apart from randomly opening the actual vt?
<robert_ancell> tvoss, I have wondered that myself
<tvoss_> back :)
 * tvoss_ notes https://bugs.launchpad.net/mir/+bug/1194210
<ubot5> Launchpad bug 1194210 in Mir "XMir hang during google hangout on intel sandybridge" [Undecided,Incomplete]
<tvoss_> RAOF, but I had those weird hangs w/o xmir, too
<tvoss_> mhall119, ping
<tvoss_> duflu, take it with a grain of salt: but why not leave away the const-qualifier on the transformation and get rid of the mutables? :)
<tvoss_> I see your intention and it's a nice idea, but three members requiring mutable indicates that const might not be appropriate :)
<tvoss_> duflu, apart from that, I'm fine
<duflu> tvoss_: I would prefer all read-only "getters" be const, regardless of the mutables required
<duflu> If they're not const then that creates problems for const callers
<tvoss_> duflu, fair
<mhall119> tvoss_: pong
<tvoss_> mhall119, for your question what XMir: a vanilla Xorg which knows about Mir, credits to RAOF, here is the diffstat:
<tvoss_> <RAOF>  ChangeLog                           |121618 ++++++++++++++++++++++++++++++++++++
<tvoss_> <RAOF>  configure.ac                        |   11
<tvoss_> <RAOF>  hw/xfree86/Makefile.am              |    9
<tvoss_> <RAOF>  hw/xfree86/common/xf86Bus.c         |    2
<tvoss_> <RAOF>  hw/xfree86/common/xf86Config.c      |   12
<tvoss_> <RAOF>  hw/xfree86/common/xf86Globals.c     |    3
<tvoss_> <RAOF>  hw/xfree86/common/xf86Helper.c      |    9
<tvoss_> <RAOF>  hw/xfree86/common/xf86Init.c        |   55
<tvoss_> <RAOF>  hw/xfree86/common/xf86Priv.h        |    3
<tvoss_> <RAOF>  hw/xfree86/xmir/Makefile.am         |   26
<tvoss_> <RAOF>  hw/xfree86/xmir/xmir-output.c       |  225
<tvoss_> <RAOF>  hw/xfree86/xmir/xmir-private.h      |   83
<mhall119> probably should have pastebin'd that
<RAOF> Ignore the ChangeLog addition, that's spurious :)
<tvoss_> mhall119, probably, it's before third coffee here, don't expect me to be that clever
<tvoss_> RAOF, mind pastebinning the diff-stat, then we can link it on G+, too
<mhall119> it's almost 1am here, so I won't likely remember this in the morning anyway :)
<tvoss_> mhall119, \o/
 * tvoss_ tries a sudo apt-get install kubuntu-desktop
<RAOF> tvoss_: http://paste.ubuntu.com/5797514/ enjoy.
<tvoss_> RAOF, thx
<RAOF> tvoss_: Oh, any advance on the client-focus-notification thingies?
<tvoss_> RAOF, nope, you just bumped its priority :)
<RAOF> I would rather like to be able to switch sessions without having all input go to both :)
<tvoss_> RAOF, that's a very sane requirement :)
<tvoss_> RAOF, robert_ancell mind having a final look here and top-approve? https://code.launchpad.net/~vanvugt/mir/fix-1193020
<robert_ancell> tvoss_, duflu, approved
<tvoss_> robert_ancell, thx
<duflu> robert_ancell, ta
 * duflu -> lunch
<tvoss_> duflu, enjoy
<RAOF> robert_ancell: Feel like approving https://code.launchpad.net/~didrocks/mir/packages-fix/+merge/171140 while I'm on a wait-for-CI-review-fest?
<robert_ancell> RAOF, I don't know why he moved the demos to libexec - that doesn't make sense to me
<robert_ancell> But if you installed them, you do want to be easily able to run them
<robert_ancell> it's not like they're in the main package
<didrocks> hey RAOF! I think this is perfect timing :)
<robert_ancell> didrocks, speak of the devil  :)
<robert_ancell> didrocks, why demos into libexec?
<didrocks> robert_ancell: hey! see RAOF's answer! https://code.launchpad.net/~didrocks/mir/packages-fix/+merge/171140/comments/381521
<tvoss_> duflu, you've got a conflict on https://code.launchpad.net/~vanvugt/mir/fix-1193020/+merge/171070
<robert_ancell> didrocks, well, the manpages issue doesn't warrant them moving and if you install the package you expect them to be easily runnable
<didrocks> robert_ancell: and getting 8 demo_mir_ in your path? :)
<robert_ancell> didrocks, yes. The package contains 8 demo applications..
<didrocks> robert_ancell: I think as they are seeing as examples, we should do as for other demos, like the Qt ones and having them in a path that's not polluting the $PATH
<didrocks> seen*
<robert_ancell> didrocks, which qt package is this?
<didrocks> robert_ancell: http://packages.ubuntu.com/raring/i386/qt4-demos/filelist
<robert_ancell> didrocks, you can approve if you want
<tvoss_> hmmmm, kubuntu-desktop seems to be in -proposed. didrocks, any idea when that is going to land?
<didrocks> robert_ancell: thanks!
<didrocks> tvoss_: kubuntu-desktop? did you look at the migration excuses?
<tvoss_> didrocks, nope
<didrocks> tvoss_: are you sure about kubuntu-desktop? https://launchpad.net/ubuntu/+source/kubuntu-meta seems that it wasn't uploaded nor blocked for some days
<tvoss_> didrocks, kubuntu-devel's topic says so :)
<didrocks> robert_ancell: I think kgunn gave to you the bug list we need to check before getting mir into distro?
<didrocks> tvoss_: well, I trust launchpad for facts, they are maybe talking about kde components, not the package
<tvoss_> didrocks, ah okay
<didrocks> tvoss_: did you see my question on lttng* btw?
<didrocks> (yesterday evening)
<robert_ancell> didrocks, yep
<didrocks> Thanks robert_ancell :)
<tvoss_> didrocks, on irc? if so, bear with me, I was doing the session dance
<didrocks> tvoss_: ok, the question that colin and I had was libmirserverlttng.so and libmirclientlttng.so needs to be in system library path
<didrocks> tvoss_: as there is no ABI/soname, they normally should be seen as private lib
<didrocks> so not really sure how lttng picks them, what's the mechanism?
<tvoss_> didrocks, lttng does not pick them, they define and implement lttng probes that feed to the trace if activated
<tvoss_> alf_, ^, mind helping out didrocks?
<tvoss_> didrocks, I think they should have an ABI/soname, though
<didrocks> tvoss_: the question I guess is how are they activated? Do we tell lttng "please use those libs?"
<tvoss_> didrocks, nope, the implementation in the libs tells lttng on activation: here I am
<tvoss_> didrocks, so it's not a "plugin" to lttng
<didrocks> hum, I'm a little bit lost on the activation mecanism :)
<alf_> didrocks: they are dlopened by Mir internally
<alf_> didrocks: right now it's dlopen("limirclientlttng.so"...)
<didrocks> alf_: ah, so we can install them in a private lib, rather?
<didrocks> dir*
<didrocks> alf_: like /usr/lib/x86_64-linux-gnu/mir/tools/ ?
<alf_> didrocks: Yes. In that case will I need to use the path when dlopen-ing or will the path be added to LD_LIBRARY_PATH externally?
<didrocks> alf_: I think on compilation, we set that path in a .h for dlopen-ing, as we can multiarch it
<didrocks> alf_: mind if we look at that together this morning?
<didrocks> (like in a couple of hours)
<alf_> didrocks: sure, ping me
<didrocks> thanks!
<tvoss_> alf_, where does the mir log go to, right now?
<RAOF> tvoss_: You hunted down an âabort in global dtorâ bug in the past, didn't you?
<tvoss_> RAOF, yup, how can I help?
<alf_> tvoss_: In stdout/stderr but it's not visible on the desktop since we put the VT in graphics mode. You can redirect it or use glog with a file output
<RAOF> tvoss_: I'm shared-libbing mir-test-doubles (because I need their implementation of open() to be first in the link order), and the unit-tests fail with an abort in testing::internal::GTestLog::~GTestLog
<robert_ancell> didrocks, please review https://code.launchpad.net/~robert-ancell/mir/copyright-fix/+merge/171215
<tvoss_> RAOF, let me have a look. Why are we hit by those fini issues? I still suspect -Bsymbolic-functions, with the linker unloading so's too early
<tvoss_> RAOF, mind running it through ltrace real quick?
<robert_ancell> bye all
<RAOF> tvoss_: Not at all.
<RAOF> robert_ancell: Night.
<tvoss_> robert_ancell, night
<didrocks> robert_ancell: have a good night!
<RAOF> tvoss_: https://code.launchpad.net/~raof/mir/prober-drm-device-probe/ is the branch.
<RAOF> Wow, ltrace spews a lot of debug output :)
<tvoss_> RAOF, yup, that's how tracked it down last time
<RAOF> Hm. I take it that âltrace bin/unit-testsâ shouldn't deadlock? :)
<tvoss_> RAOF, if that is the case, it's almost surely an issue in a pthread_mutex_destroy
<RAOF> tvoss_: Oh, you mean â[ FATAL ] /home/chris/Canonical/Mir/mir/proper-drm-device-probe/3rd_party/gmock/gtest/include/gtest/internal/gtest-port.h:1486:: pthread_key_delete(key_)failed with error 22â?
<tvoss_> RAOF, something like that :)
<RAOF> Sorry, should have given that output upfront!
<tvoss_> RAOF, no worries
<tvoss_> RAOF, building your branch right now
<tvoss_> alf_, for the log: I would think something like /var/log/mir/mir.0.log makes sense
<tvoss_> glog does log rotation, too
<tvoss_> alf_, but I would expect the shells pulling in mir to be able to adjust that, so unity-system-compositor setting up the logging
<alf_> tvoss_: makes sense
<tvoss_> alf_, let me file a bug on usc
<duflu> tvoss_, and again :)  https://code.launchpad.net/~vanvugt/mir/fix-1193020/+merge/171070
<tvoss_> duflu, didrocks do thread-local storage keys cease to exist on so unload?
<duflu> tvoss_: No, SOs are not tied to threads
<duflu> And they have no automatic destructor
<tvoss_> duflu, hmmm, so in the fini operation of unit-tests, a delete on a pthread key results in an error, although the key was existant before ...
<duflu> tvoss_ : You might have another SO/fini bug if it's an old distro
<tvoss_> duflu, it's saucy
<duflu> Not likely then
<tvoss_> duflu, nope
<duflu> tvoss_: Also pthread_key_delete works by value. It's only an ID. So any error means the key is not a valid one... or you got heap corruption prior
<tvoss_> duflu, right ... just waiting for my debug build to finish
<tvoss_> didrocks, is there a list of changes to low-level userland stuff in saucy?
<didrocks> tvoss_: yeah, I confirm what duflu says, the libs are loaded globally to a process, weird that you have this pthread issue then
<didrocks> tvoss_: saucy-changes ML
<didrocks> it's the only way to track what's in
<duflu> I thought Linux was over these kinds of bugs. It's almost certainly an application bug
<didrocks> still some copyright issues to fix for robert :) https://code.launchpad.net/~robert-ancell/mir/copyright-fix/+merge/171215
<tvoss_> duflu, right, but I wonder what makes it pop up right now
<didrocks> this deserves a coffee I guess now :p
<tvoss_> didrocks, exactly
<didrocks> heh
<tvoss_> duflu, RAOF ah, heap corruptoin :)
<tvoss_> at least gdb says so, valgrind to the rescue then
<tvoss_> okay, there is heap corruption on fini of libmir-test-doubles.so
<tvoss_> arising from a std::string::~string
<RAOF> alf_: How much would you like a UdevEnumerator RAII wrapper? It's on my TODO list anyway.
<alf_> RAOF: I don't consider it urgent enough to block the MP (especially if it's in the queue anyway).
<RAOF> Cool.
<duflu> tvoss_, arising from std::string ?
<duflu> buffer overrun?
<tvoss_> duflu, checking
<tvoss_> RAOF, did you just push an update to the prober branch?
<RAOF> tvoss_: Yeah, but just stylistic changes.
<tvoss_> RAOF, there are some stray characters in there :)
<RAOF> RGARGHUH.
<RAOF> Hurray for stray non-printing characters!
<tvoss_> RAOF, oh, and std::static_cast -> static_cast
<RAOF> Yeah.
<RAOF> Got that one myself :)
<RAOF> tvoss_, duflu: Looks like it's double free()ing the string?
<tvoss_> RAOF, yeah, but it's racy and I'm not able to track down the string location
<duflu> tvoss_: Is it a static global? Those can easily get double freed
<tvoss_> duflu, already searched for static std::string, nothing test-doubles, next is look through source files and see if we have global strings somewhere
<tvoss_> duflu, although fini should be threadsafe, shouldn't it?
<duflu> Bisect!
<RAOF> Happens when having an indirect link of libmirserver0
<duflu> tvoss_: Well, no I don't think so. Fini doesn't have to be thread safe. It's only every called once, in theory
<duflu> tvoss_: Ah linking to client & server libraries?
<RAOF> It does do that, yes.
<duflu> If so then it can happen if there is a global symbol of the same name (as in our input code that's duplicated)
<duflu> The first loaded copy gets destructed twice. And the second, never.
<duflu> Or not global, but a static class member even
<duflu> The solution is to replace it with a static getter function that returns a reference to the real variable (which is static inside the getter function)
<didrocks> is it me or Mir trunk doesn't build anymore?
<tvoss_> duflu, okay, let me scan through the code
<tvoss_> didrocks, it's obviously you ;)
<duflu> tvoss_: See r566 as an example
<didrocks> tvoss_: saucy, right?
<tvoss_> duflu, although it's a question whether this is faulty linker behavior
<duflu> tvoss_, that's a premature and usually naiive argument :)
<tvoss_> didrocks, ack
<tvoss_> duflu, well, my suspicion is that if you remove -Bsymbolic, it wouldn't result in issues
<duflu> tvoss_, Yeah you're probably right. But you can modify statics like in r566 so you don't need to remove Bsymbolic
<tvoss_> duflu, I rarely blame the compiler or the linker, but the exposed behavior contradicts the c++ standard. Not saying that is bad necessarily!
<RAOF> Survey suggests that 3rd_party/gmock/gtest/include/gtest/internal/gtest-death-test-internal.h:  static std::string last_death_test_message_; is a possible culprit.
<duflu> Well, linkage rules are outside the scope of C* languages, unfortunately
<didrocks> tvoss_: let's say I'm blaming ccache and I retry without it
<tvoss_> didrocks, branching trunk now :)
<didrocks> tvoss_: I think it's fine, seems to be ccache + parallel build not playing fine
<duflu> tvoss_, thanks for fixing my bug without even being aware :)
<duflu> https://bugs.launchpad.net/mir/+bug/1194054
<ubot5> Launchpad bug 1194054 in Mir "--vt N option seems to be unreliable/racing" [Medium,Fix committed]
<tvoss_> duflu, \o/
<tvoss_> didrocks, ack
<didrocks> tvoss_: duflu: RAOF: alf_: does mirplatformgraphics really belong to the same binary package than libmirserver0?
<didrocks> (it will follow the same ABI stability I guess?)
<RAOF> Oh, has loadable backends landed?
<duflu> didrocks: They share all their code, and we fully expect parts to move around between them as a driver model materializes
<RAOF> For the moment it's certainly in libmirserver0
<duflu> RAOF: Landed yes, but it's just the old library made dynamic instead of static
<alf_> didrocks: In the future I would expect to have separate packages for the various backends
<didrocks> RAOF: duflu: alf_: ok, let's keep it that way, then, thanks!
 * didrocks remerges his branch and multiarch that one as well before pushing
<tvoss_> duflu, idea for testing vt's: we request the next free vt and do all of the activation magic and modesetting there
<tvoss_> RAOF, duflu any idea how we can get vts back?
<RAOF> ECONTEXT. Back from what?
<duflu> tvoss_: Ctrl+Alt+F7 to regular X, and then back to your VT (https://bugs.launchpad.net/mir/+bug/1189770)
<duflu> ?
<ubot5> Launchpad bug 1189770 in Mir "[regression] Killing Mir with Ctrl+C often leaves the screen blank and difficult to recover " [High,Triaged]
<duflu> tvoss_: I'm not sure any automated tests should be touching real hardware, by default... ?
<tvoss_> duflu, not sure that the trick works. Can we fix that issue somehow?
<duflu> tvoss_: Not sure. Maybe our SIGINT handler needs to do cleaner shutdown
<duflu> Which is simple
<duflu> Haven't looked
<duflu> tvoss_: The trick doesn't work if you're using unity-system-compositor :(
<duflu> tvoss^
<tvoss> okay, found the reason for the double free
<duflu> Woo
<tvoss> but: that still does not solve the issue with the std::string dtor
<tvoss> RAOF, ^
<RAOF> tvoss: How did you find the double-free?
<RAOF> Also, what is it? :)
<tvoss> RAOF, let me pastebin the diff
<RAOF> Hm, or not :)
<tvoss_> RAOF, hold on, compiling :)
<tvoss_> RAOF, http://pastebin.ubuntu.com/5797856/
<tvoss_> RAOF, there is still some issue reported by valgrind about an invalid free in a string
<tvoss_> RAOF, and busid is a std::string now
<hikiko> hi
<hikiko> question :)
<hikiko> http://unity.ubuntu.com/mir/namespacemir_1_1compositor.html I am looking at the classes here, trying to understand the system and the session compositor... but I am a bit confused
<hikiko> the system compositor is the Multithreaded Compositor?
<tvoss_> hikiko, nope, why should it? the system compositor is a process on its own
<hikiko> tvoss_, could you explain me a bit the concept with the 2 compositors or tell me the classes to look at?
<hikiko> system compositor == the whole mir?
<tvoss_> hikiko, no need to look at classes: every compositor is the whole of mir
<tvoss_> hikiko, the session compositor is just another client to the system compositor
<tvoss_> hikiko, both are independent processes
<hikiko> every client == session compositor?
<RAOF> hikiko: Every client of the system compositor is a session compositor.
<tvoss_> hikiko, nope, ordinary apps talk to the session compositor
<hikiko> hmm I think that my problem then is that I didn't get what exactly the compositor does :S
<hikiko> in case of mir server I understand
<RAOF> Ish; we may well have a couple of non-compositor clients of the system compositor (such as a polkit authenticator)
<hikiko> It combines/renders the win to a surface
<tvoss_> hikiko, it takes buffers and assembles a final output
<hikiko> yes
<tvoss_> hikiko, in case of the system comp, that is sent to the display
<tvoss_> hikiko, in case of the session comp, that is sent to the system comp.
<hikiko> so the windows of a client
<hikiko> are assembled before being sent to the server
<hikiko> and the server only displays the buffer with all the windows?
<tvoss_> hikiko, no, the windows of clients are surfaces known to the session comp
<hikiko> so why the session compositor needs the server?
<tvoss_> hikiko, the session compositor is a server in itself. And: it does not know about displays and such and does not have access to the underlying hw
<tvoss_> hikiko, think about user session swithcing: all of these sessions are clients to the system comp
<hikiko> I think I misunderstood what we call session then :s
<tvoss_> hikiko, ?
<hikiko> mm
<hikiko> tvoss_, let's say we have a client (a program that needs to open 2 windows)
<tvoss_> hikiko, what did you consider a session if not a user session?
<tvoss_> hikiko, okay
<hikiko> a client connection
<hikiko> but I am wrong obviously :)
<hikiko> in the example with the 2 windows of a client
<hikiko> the process is:
<RAOF> We do have a concept of "session" in the codebase, don't we.
<tvoss_> RAOF, yup, every application is a session
<hikiko> then I was right?
<tvoss_> hikiko, nope
<RAOF> tvoss_: So, it's not entirely strange to be confused about the overloaded âsessionâ nomenclature :)
<tvoss_> RAOF, it is overloaded for a good reason: all sessions are connections in the end
<hikiko> ok what I am trying to understand is how mir would render the 2 windows of a client step by step
<hikiko> because then everything mir does will be clear
<hikiko> step 1: connection?
<RAOF> hikiko: You can think of it like this - the system compositor is a Mir server that takes the contents of user-sessions (like Unity, GNOME, etc - a user login) and composites them to the hardware.
<hikiko> so all the unity programs
<tvoss_> hikiko, step 1: ack
<hikiko> are part of 1 session?
<RAOF> hikiko: A session compositor is a Mir server that takes all the windows of a user's login and composites them into the user-session.
<tvoss_> hikiko, ack
<hikiko> oh I see :) then I was completely wrong :)
<hikiko> ok so, we composite every unity window on the client
<hikiko> compose*
<hikiko> and then
<hikiko> what we do with the server?
<tvoss_> hikiko, hold on: what do you mean by "On the client"
<tvoss_> ?
<hikiko> I mean
<hikiko> if we start unity on a pc
<hikiko> we have 1 buffer for each window
<hikiko> we combine these buffers on a large buffer
<hikiko> and then we sent it to mir
<hikiko> (server)
<RAOF> Ah, no.
<tvoss_> hikiko, nope
<RAOF> We have one buffer for each window.
<tvoss_> hikiko, the combination of the buffers is done by mir, too
<RAOF> A mir server combines these buffers onto a large buffer.
<RAOF> And sends that large buffer off to a mir server.
<RAOF> Which combines the large buffers onto the framebuffer.
<hikiko> this is the same mir server?
<tvoss_> hikiko, nope, two processes
<RAOF> No, two different mir servers.
<RAOF> The first Mir server - the one that all the user's applications run in - is called the session compositor, because it takes all the windows of the user's session and composites them.
<RAOF> The second Mir server - the one that all the session compositors talk to - is called the system compositor, because it takes the outputs of all the sessions and composites them onto the system's displays.
<hikiko> and why we need to composite once in a buffer and once in the framebuffer?
<RAOF> It makes things easier.
<hikiko> we can't do the composition directly in the framebuffer?
<tvoss_> hikiko, we can, but we don't want for the session compositor in the first place
<RAOF> Specifically - it makes running different users, and handling the transitions between them - easier.
<hikiko> ok :)
<tvoss_> RAOF, plus: suspend/resume etc.
<RAOF> tvoss_: And boot splash â greeter â session, yeah.
<hikiko> actually i thought that we only compose once at the framebuffer and the session compositor was for a program's windows completely different from what we actually do :)
<hikiko> that's why I was so confused
<hikiko> so in my case the nested mir will have 2 server processes as well
<tvoss_> ?
<RAOF> I'm not sure what you mean.
<RAOF> There'll only be one nested server process (per user)
<RAOF> But there'll be a nested server process and the system server process, yes.
<hikiko> yes that's what I mean :) sorry I cant make myself very clear
<hikiko> and RAOF
<hikiko> the nested mir clients
<hikiko> will use the nested mir session compositor
<RAOF> tvoss_: What does that patch fix? I see exactly the same crash and exactly the same valgrind double free?
<RAOF> hikiko: Right.
<hikiko> so I have to change it to use a different socket for the clients
<tvoss_> RAOF, it get's rid of a spurious double free during repeated test execution of bin/unit-tests
<hikiko> isn't it?
<RAOF> hikiko: Yes; there'll be two sockets - the system compositor's socket, and the session compositor (nested) socket.
<hikiko> RAOF, which classes implement the session compositor to get a look at? I guess the directory compositor is for the system compositor isn't it?
<RAOF> hikiko: The session compositors and system compositors live outside mir; there isn't a class to implement.
<RAOF> tvoss_: Ah, ok. So it doesn't do anything about the double free() on shutdown, then.
<tvoss_> RAOF, not yet, still tracking down
<hikiko> so, i guess I have to look at the examples :)
<RAOF> hikiko: What needs to be done for the nested compositor is implementing src/server/graphics/nested-gbm.
<hikiko> and add some code to keep a socket where the nested_gbm accepts connections?
<RAOF> Hm, yes. That too.
<hikiko> cool :) I am going to start this thanks a lot RAOF and tvoss_ :)
<tvoss_> hikiko, would you mind keeping us posted how you come along? I think we can help unblock you in case of questions/issues easily
<tvoss_> raof, it seems like the gpu hang on intel is mostly caused by chrome
<RAOF> Oh.
<RAOF> That's inconvenient.
<tvoss_> RAOF, it is, but it also happens on vanilla x occasionally
<RAOF> Upstream's also not going to be particularly helpful until I finish the SNA xmir implementation, either.
<hikiko> sure tvoss_ atm I have only done a platform/display that compile but do nothing and now I'll try this socket change to test what Ive done using clients :)
<RAOF> Downloading libstdc++ source. Things can only get more awesome.
<hikiko> RAOF, and tvoss_ sorry but I have another question
<RAOF> Go ahead!
<hikiko> I understood it :) I was wondering what happens with the z order if we have 2 compositors but then I remembered that we composite all the user program windows in the buffer compositor (session) so there's no problem
<hikiko> if we have 2 windows*
<hikiko> of the same program
<hikiko> but ok
<hikiko> there's no problem
<RAOF> Right!
<tvoss> RAOF, for chrome/hangouts: if running firefox without using hangouts -> stable. Hangout in Firefox: almost immediate hang
<didrocks> alf: ok, I've now the *ttng* modules installed in <libexecdir>/mir/tools/ for lp:~didrocks/mir/move-lttng-libs
<didrocks> alf: you just need to change the dlopening I guess
<tvoss> RAOF, hah
<RAOF> tvoss: Oh, win?
<tvoss> RAOF, the pthread_key is indeed removed twice, with the second attempt failing
<tvoss> RAOF, it's triggered by GTEST_API_ extern ThreadLocal<Sequence*> g_gmock_implicit_sequence;
<alf> didrocks: thanks, I will take a look a bit later
<mlankhorst> how are hybrid display outputs handled with mir?
<RAOF> mlankhorst: At the moment? They're not.
<mlankhorst> could it be made to work? :p
<RAOF> Absolutely.
<mlankhorst> what pieces are missing atm?
<RAOF> tvoss: valgrind+gdb suggest that testing::FLAGS_gmock_verbose might be the std::string being double-freed.
<tvoss> RAOF, I really don't understand why we are seeing such issues popping up right now
<RAOF> mlankhorst: The gbm platform would need to open both drm devices, rather than just the first. Then we'd need to create an EGL context on both. Then we'd need to handle multiple monitors in a less stupid way ;)
<tvoss> mlankhorst, alf is the right guy to talk to :)
<RAOF> tvoss: I'd guess it's because we don't link both mirclient and mirserver in to anything else?
<RAOF> Or, at least, we don't link against anything that links against both mirclient and mirserver?
<mlankhorst> I could probably use the xorg code as an example for drm device detection, we need to talk to udev anyway for this
<tvoss> mlankhorst, we are having parts of that under review right now :)
<RAOF> mlankhorst: Correct. See lp:~raof/mir/prober-drm-device-probe :)
<RAOF> mlankhorst: For simple proof-of-concept GPU offloading you could probably get away with just opening both devices, handing one drm device to the GBMDisplay and the other to the GBMBufferAllocator.
<RAOF> mlankhorst: Then you'd have display on one device and rendering on the other.
<mlankhorst> RAOF: xorg doesn't like hybrids ;)
<mlankhorst> in mir
<RAOF> mlankhorst: Correct. I disabled gpu-only loading, didn't I?
<RAOF> Or was that only for -radeon?
<mlankhorst> dno
<mlankhorst> the thing has outputs so it works
<mlankhorst> I have one without outputs to test too
<RAOF> The one without outputs will now start Mir on the device that *has* outputs!
<RAOF> 8pm is probably EOD.
<RAOF> So long, chappies!
<mlankhorst> see ya mateQ!
<duflu> RAOF: Bye. And mee too
<duflu> See, I can't even type any more
<mlankhorst> RAOF: btw that code is too difficult, you don't need to use setversion to test
<tvoss> RAOF, so long :)
<mlankhorst> RAOF: use drmModeGetResources(fd); if it returns NULL KMS is not supported on that node, and it should be ignored entirely (nvidia blob for example). After that just check ret->count_connectors and use drmModeFreeResources
<mlankhorst> I only found out after checking with upstream, but it's the cheapest test, no need to traverse udev or anything like that..
<mlankhorst> RAOF: http://paste.debian.net/12543/ .. not even compile time tested :>
<mlankhorst> oh it could be better still
<tvoss> RAOF, okay, for the pthread_key_delete issue: the global initializer is executed twice
<tvoss> didrocks, ^
<mlankhorst> open syspath/boot_vga, read it and if it's == '1' there you go, this one is the primary
<didrocks> tvoss: rings to me like a bell, didn't we get something like that already hard to decipher?
<tvoss> didrocks, yup, look here: http://pastebin.ubuntu.com/5798108/
<tvoss> didrocks, it executes the c'tor for the global object twice, for the same this pointer
<didrocks> tvoss: indeed, good catch!
<tvoss> didrocks, well, at least it's reproducible on my machine
<tvoss> quick lunch
<greyback> racarr: who good to ask these questions to: http://studio.sketchpad.cc/flleQTzi4o
<greyback> they're some Mir comments and questions I've assembled the last day or 2
<kdub> hello
<kgunn> kdub: mornin'
<didrocks> alf: hey, any luck? :)
<alf> didrocks: sorry, not yet (and probably not today), I was caught up in other work. I will take a look first thing tomorrow
<didrocks> alf: ok good :)
<didrocks> alf: should we open a bug for that add the tag so that kgunn can know exactly what's blocking Mir in distro?
<kgunn> didrocks: alf....shoot me the link when there
<didrocks> kgunn: added to https://bugs.launchpad.net/mir/+bugs?field.tag=entering-saucy
<olli> alf, still around
<kgunn> didrocks: thanks....alf i'll try to get alan to look at when he returns...please stay on snapshot/mm
<alf> olli: intermittently :)
<alf> didrocks: thanks
<didrocks> yw :)
<olli> alf, I noticed some variance in 2 consecutive glmark2 runs on the same system
<olli> is this expected/possible
<didrocks> olli: reiterating that if you want me to comment on the google doc, please give me comment rights :)
<olli> or do I need to check my background processes
<olli> didrocks, didn't get to it yet
<didrocks> olli: no worry, just wanted to ensure you read my request ;)
<alf> olli: What kind of environment are you running glmark2 in?
<olli> alf, xmir on intel
<kgunn> olli: cpu load can effect benchmarks...altho, you'd have to have alot of stuff going on
<alf> olli: how much variance do you see?
<olli> didrocks, done
<olli> alf, I got ~900 on saucy stock
<olli> and then ~900 on saucy/xmir
<olli> or 700 saucy xmir
<didrocks> olli: danke schÃ¶n
<olli> I hadn't measured multiple runs on stock saucy though
<kgunn> olli: can you do same for openarena?
<kgunn> olli: btw, my system fixed :)
<olli> alf, I'd assume that in general a small deviation (few %) are anticipated but not ~25%
<alf> olli: right, 700->900 is not normal variance
<kgunn> altho...hit one of the legit bugs that prevented me from running xmir (i can do the client demos tho)
<kgunn> olli: alf  i loathe the nebulous agregate # from benchmarks....fps are best
<kgunn> openarena is sub 60
<kgunn> so it would be a better metric
<olli> kgunn, I am working with chrisGagnon to get some repeatable tests in place
<kgunn> olli: much thanks on that
<didrocks> olli: testing playing openarena? I see :-)
<Guest36302> gpg: skipped "Robert Carr <robert.carr@canonical.com>": secret key not available
<Guest36302> Keep getting this when trying MIR
<kdub> give out your secret key racarr ;-)
<Guest36302> debuild -i -I
<Guest36302> after this command is when I receive the message
<kdub> perhaps the debian/changelog does not have your email as the latest entry?
<Guest36302> ah, probably.  I guess this means I need to be logged into bzr
<Guest36302> I
<racarr> My secret key is 21.
<racarr> Insist on doing RSA in my head.
<racarr> Guest36302: There is some flag you can pass to not sign that I don't remember or you can do dch -i and add an entry for yourself
<racarr> Im going to attempt to refactor
<racarr> the focus bits of the SessionManager
<racarr> and the_focus_mechanism
<racarr> and the_focus_sequence
<racarr> in to something sensible for the shell...probably a single FocusArbitrator
<racarr> does anyone have any thoughts?
<racarr>  on refactoring the focus machinery, not in general :p
<racarr> kdub: Also I was wondering has anything come out of seperating surface state from msh::Surface
<racarr> greyback is asking for API to be notified on surface state change
<racarr> and that's weird at the moment
<racarr> because you don't want to subclass the surface
<kdub> racarr, well, still untangling dependencies a bit
<racarr> but its not clear that
<racarr> EventSink
<racarr> is really the proper interface here.
<kdub> no, probably not :)
<racarr> sometimes I wish we just had signals
<kdub> really, this is that 'interface' that i've been going on about...
<racarr> kdub: Aha. mir::shell::Interface
<racarr> DONE
<kdub> from the shell's perspective, I think that a 'ask-decide-command' (wrt the surfaces) is a good way to go, as opposed to having a notification signal
<racarr> mm
<kdub> this is probably a bit off topic from the 'FocusArbitrator" that you were talking about
<racarr> well, I mean signals can have responses, I guess what I meant by signal
<racarr> is that a subscription
<racarr> pattern is easiest
<racarr> but often gets
<racarr> tangled.
<racarr> whereas we use...
<racarr> I don't know what the opposite of a subscription pattern is XD
<racarr> but explicit listeners, etc.
<kdub> well, the opposite is :) keeping the state in one place
<racarr> hmm sort of
<racarr> I just mean we don't have any APIs like
<kdub> what I mean by that is... if we have a callback signal, we 'im the shell, and the last time mir callbacked me, the position is at x1, y1'
<racarr> add_surface_opened_handler(std::function)
<racarr> etc.
<racarr> they are all through the configuration
<kdub> in addition to 'im mir, and I think the state is at x1, y1'
<kdub> right
<kdub> i like that :)
<racarr> I think it's worthwhile yeah.
<kdub> mir says, 'hey, new surface arrived over ipc, ask me about it'
<racarr> mm
<kdub> instead of saying ' a new surface arrived, here's the details, but... this is just an echo of the state'
<kdub> i guess I just want state to 'flow' into the right components
<kdub> instead of having a gob of state bunched up in a common place
<racarr> mm
<racarr> thomi: Hey!
<thomi> o/
<racarr> now that qtubuntu and platform api mir are packaged and in PPAs
<racarr> I think we should do some sort of
<racarr> integration testing?
<racarr> continuous integration?
<racarr> *waves hands*
<racarr> I dunno, I imagine like, we have the staging PPA, where everything just lands and it's built
<racarr> but then to make it in to the next PPA or some such, i.e. phone-testing-ppa
<racarr> some integration test has to pass that brings up Qt clients, does some autopiloting
<racarr> etc
<thomi> racarr: maybe send me instructions on what I need to do to try this myself?
<thomi> is it as simple as adding the PPA and dist-upgrading? Or is there some manual configuration involved?
<racarr> thomi: Um. well now that I think of it right now the packages are only buitl on arm XD
<racarr> so maybe its too soon
<thomi> racarr: hmm, are there plans to build for other archs?
<racarr> thomi: Yeah, it's just not under CI yet because we are still waiting on the qtubuntu changes to land
<racarr> so it's under ricmm integration ATM
<thomi> racarr: ok
<thomi> probably best to wait a bit then
<racarr> Ok :)
<mterry> racarr, I'm following the mir-with-unity sketchpad instructions again, filling them out to be more fool-proof.  But I ran into a problem building qtubuntu:
<mterry> ../ubuntucommon/libqubuntucommon.a(integration.o): In function `QUbuntuIntegration::createPlatformWindow(QWindow*)':
<mterry> /home/phablet/tmp/qtubuntu/mir-with-packaging/src/platforms/ubuntucommon/integration.cc:140: undefined reference to `ua_ui_session_properties_set_remote_pid'
<mterry> collect2: error: ld returned 1 exit status
<racarr> mterry: https://code.launchpad.net/~robertcarr/platform-api/missing-mir-stub
<racarr> merged with r73 of papi
<mterry> racarr, aweosome
<mterry> racarr, what is the a for in ua_?  api?
<racarr> mterry: application
<robert_ancell> RAOF, did that gbm debugging help>
<robert_ancell> ?
 * kdub enters the swamp
<kdub> racarr, event sinks... are they per-surface, or per-session?
<kdub> or rather, :) they are per-surface at the moment, could they be per-session?
<racarr> kdub: They are per session
<racarr> kdub: Handed by the session to each of it's surfaces
<kdub> ah, yeah
<robert_ancell> mterry, still there?
<RAOF> Gah. What happened to all my beautiful backscroll?
<racarr> RAOF: You missed some pretty juicy stuff.
<racarr> A lot of things were said about you, I'm not sure they are appropriate to repeat.
<racarr> kdub: Kind of out of the blue but you may have an opinion on this as it ties in a bit with the structure of msh::Surface
<racarr> more with Session I guess.
<kdub> racarr, pass one is just to lift these factories out of being so deep
<racarr> kdub: So, in my attempt to refactor focus
<racarr> Err, trying to find the best way to explain, sorry
#ubuntu-mir 2013-06-26
<racarr> Well, just I am trying to get all the focus policy in to one object
<racarr> this object, basically, makes the assosciation, this surface is the focused one (only above this, does "focus" really exist)
<racarr> and, ties up the bits to implement focus
<kdub> racarr, sounds useful (although hard to say for sure...)
<racarr> i.e. raises the surface when it receives focus and targets it for keyboard events. (this could be a seperate mechanism object still, not sure how helpful it really is)
<racarr> mm. still hard to say XD
<kdub> i'm just trying to detangle the surface ownerships
<racarr> so the problem is
<racarr> some surface is focused
<racarr> and it's destroyed
<racarr> how does this object know to choose a new mechanism for focus
<racarr> err
<racarr> a new surface
<racarr> I don't want to
<racarr> pass this object down through the session manager and session like before, and have the those bits contain the logic
<kdub> like, just floating up the factories and untangling the objects ownerships, i'm starting to see how it'll happen
<racarr> "when surface is destroyed, focus the last surface", etc
<kdub> still too early to say though
<racarr> so I am wondering about
<racarr> some sorst of change_callback system
<kdub> it kinda feels like those zelda levels, where if you go in the wrong door, you have start the maze over at this point in time
<racarr> to mirror what we have on the graphics side...
<racarr> Haha. yeah ....
<kdub> racarr, that makes sense
<kdub> the callback for input
<racarr> I guess I am just brought it up because it kind of ties in to the EventSink bits...how do various portions of msh:: notify eachother
<racarr> on shell side state changes
<racarr> I just had a crazy idea
<racarr> the FocusArbitrator/Setter/Whatever
<racarr> could hand out like...
<racarr> surface->receive_focus(std::unique_ptr<FocusToken>)...
<racarr> and the destructor knows what to do
<kdub> well, what if you want to get that token back though
<kdub> like, a manual reassignment of focus
<racarr> kdub: std::move XD
<racarr> I'm not sure...
<racarr> I find a certain appeal to this but may jjust have C++ addiction
<RAOF> Not *every* problem needs to be modelled in the type system :)
<RAOF> But it does have a certain charm. Also parallels desrt's focus-stealing-prevention idea.
<racarr> it's a nice way to be explicit about the signalling needed (surface destroyed)
<racarr> I think without clogging up other listener interfaces, or using generic change callbacks
<racarr> etc
<racarr> which will end up with more coupling
<racarr> but im still not sure
<racarr> I think ill let it stew until tomorrow
<RAOF> So, how close are we to having a "focus-gained" and "focus-lost" signal on our surfaces?
<racarr> well
<racarr> the session_listener has
<racarr> focused and unfocused
<racarr> and the EventSink will probably give them eventually
<racarr> I dunon that's the thing though, we don't really want signals so to speak
<racarr> i.e. this same problem could be solved by having the focus bit do
<RAOF> Let me rephrase: at what point will XMir be able to tell when it's not focused, and give up input?
<racarr> surface.subscribe_to_signal("about_to_close"
<racarr> now!
<racarr> oh
<racarr> I made that up
<RAOF> Woo! How!
<racarr> soon
<RAOF> Oh â¹
<racarr> no I made that up ignore me
<racarr> XD
<racarr> if xmir needs that
<racarr> I can finish it soon
<racarr> well
<racarr> xmir does need that
<RAOF> Only if you'd like to be able to switch sessions without all sessions getting all input :)
<racarr> RAOF: *shrug* I'm not too picky
<thomi> hey guys, what's required to run openarena on mir?
<thomi> is there a custom build somewhere?
<RAOF> Does that just need SDL?
<RAOF> Or do you want to run it in XMir?
<bschaefer> thomi, it should work on Mir with the SDL package in the ppa (I haven't tried yet though)
<bschaefer> tried openarena that is
<thomi> ok, I'll give that a go
<thomi> RAOF: I'll tackle xmir soon
<thomi> just mir right now
<RAOF> duflu: I don't think I can drop the varargs annoyance in the open() wrapper. Or, at least, I don't think I want to.
<duflu> RAOF: Oh? Why not?
<RAOF> If I drop it, it no longer interposes.
<duflu> RAOF: In C/C++, the caller determines how many parameters to pass. It can be any number. So to assume it is 2 or 3 is pretty simple and safe
<RAOF> I suspect it's because it no longer matches the prototype in the libc header, so doesn't get the symbol version applied, so the linker doesn't consider it.
<duflu> RAOF: That's weird. I suggest it's maybe because it's got C++ linkage and needs C. Look at "nm"
<duflu> RAOF: Yeah just do an 'extern "C"', or put it in a C file
<RAOF> I'm pretty sure I checked.
<RAOF> Oh, except that I may have had the âplease demangle my symbolsâ option enabled...
<RAOF> Which would somewhat defeat the purpose of that check :)
<duflu> RAOF: Yeah don't use the -C option. Just nm -D
<RAOF> Why do we make it so hard to set an environment variable in a CMake test?
<duflu> Ahhhh why can't we keep trunk stable enough to build any more?
<duflu> It's a new FTBFS every day
<robert_ancell> duflu, why are you still consuming mir on raring?
<duflu> robert_ancell, because that's my desktop. Hence much faster to do some jobs
<duflu> ... than the suacy laptops
<duflu> *saucy
<robert_ancell> duflu, well, it's just wasting time fixing bugs in raring
<duflu> robert_ancell, It's not a waste if other distros get the same errors, and they are real errors in our code
<duflu> It would be nice to catch them before they land, is all
<robert_ancell> duflu, just require those other distros to use gcc 4.8. It's not a difficult dependency
<duflu> robert_ancell, I think that would be arrogant of us. If the fix to support existing compilers is simple
<robert_ancell> duflu, that's not arrogant - all dependencies have minimum versions. It's not a problem to apply patches if someone else takes the time to find them but we have no need to
<duflu> Supporting multiple platforms/archs/environments is the single easiest way to build code quality, because each new one will show you errors you previously missed
<robert_ancell> disagree
<duflu> I know this from experience. Supporting up to 15 platform combos at once
<duflu> Bah, we can argue about "easiest" forever
<robert_ancell> Can I get a review on https://code.launchpad.net/~robert-ancell/lightdm/unity-sys-comp-release-vt2/+merge/171190?
 * duflu fears the number of code reviews he's now got involved in and needs to chase up today
<robert_ancell> duflu, :)
<RAOF> Um, why do we have a hunk of parsing code to emit CTest test files?
<RAOF> Rather than just using add_test?
<robert_ancell> duflu, in that fix you made for plymouth you call 'plymouth deactivate' every time in the loop - was that intentional?
<duflu> robert_ancell: Yes but now you mention it, it could probably only happen once
<duflu> There's no reason to repeat it
<robert_ancell> ok, cool
<duflu> robert_ancell: That's the result of many iterations. You get leftovers of previous algorithms
<robert_ancell> heh
<duflu> RAOF: Was it feasible to resolve the libdrm_radeon issue? (https://launchpad.net/~mir-team/+archive/staging/+build/4741584)
<RAOF> Eh, screw it. I'll just copy saucy's libdrm into the PPA for you :)
<robert_ancell> duflu, I'm looking at the plymouth source and it does appear to block on deactivate correctly
<robert_ancell> duflu, are you sure that was causing the problem?
<duflu> robert_ancell: Yes, absolutely. The lightdm log shows it has to try twice before success
<duflu> And inserting a sleep works also :)
<robert_ancell> duflu, hmm, I think it only works because of the sleep - the termination condition is !plymouth_has_active_vt() - but that only contacts Plymouth once
<robert_ancell> So effectively all the patch has done is add a sleep(1)
<duflu> robert_ancell, I also clear the cache to force it to contact each time
<robert_ancell> duflu, ah, missed that
<duflu> So that part is working
<duflu> And I get two attempts logged in my lightdm.log
<duflu> So it takes somewhere inside a second to complete
<duflu> robert_ancell: We could enhance plymouth to honour --wait with deactivate, or just not crash. But I figured we in too much hurry to corrdinate fixes across multiple projects and add new ones to the PPA
<duflu> -"not crash" +"not spin"
<robert_ancell> duflu, yeah, I'm just trying to merge it into master, so need to work out the correct fix
<duflu> Well, see previous comment :)
<robert_ancell> duflu, I suspect it's the drm plugin that's not working correctly
<duflu> robert_ancell: Yes, I think I mentioned that. It's about DRM mastership... stuff
<robert_ancell> RAOF, do you know - does drmDropMaster() work immediately?
<duflu> If Mir jumps in too soon it confuses plymouth's drm plugin
<robert_ancell> yeah
<RAOF> robert_ancell: I think it waits before returning. Let me check.
<RAOF> ARGH. How do you specify an environment variable for a cmake test?
<RAOF> Hint: Setting CTEST_ENVIRONMENT does *not* do what you want. Or, as far as I can tell, anything.
<duflu> RAOF: setenv in code?
<RAOF> Too late for LD_PRELOAD!
<duflu> RAOF: I'm not sure the universe wants us to achieve that goal. It's a bit wrong :)
<RAOF> Why are all build systems so ridiculously broken?
<RAOF> Why is there always something that should be trivial but ends up being a huge pain in the arse?
<duflu> RAOF: Well if you mean CMake then yeah... so many things Make can do that CMake prevents you from doing
<thomi> did we stop shipping binaries in the mir-demos package at some point? i.e.- mir_demo_server?
<thomi> or am I going stupid
<thomi> WTF? why are the demo binaries now in /usr/lib/x86-linux-gnu/mir/examples ?
<robert_ancell> thomi, ask didrocks. It seems stupid to me
<thomi> ugh
<thomi> me too
<robert_ancell> Did someone just update mir in the system-compositor PPA? u-s-c has a broken dep now
<robert_ancell> It looks like a RAOF to me
<RAOF> I did indeed.
<robert_ancell> thomi, ^
<thomi> RAOF: any chance you could push the matching libmirserver0 please?
<thomi> otherwise it's uninstallable
<thomi> thanks robert_ancell
<RAOF> thomi: I was waiting for the mir to publish. I've just copied u-s-c; once it's rebuilt, all will be well.
<RAOF> thomi: Are you pulling from system-compositor-testing?
<thomi> RAOF: yes
<RAOF> Should I be bouncing through *another* PPA to ensure atomic updates of system-compositor-testing?
<thomi> RAOF: I don't think the words "atomic" and "PPA" can ever appear within a mile of each other
<thomi> but I might be wrong. I certainly don't know how to push several packages in an atomic fashion
<robert_ancell> RAOF, if you copied u-s-c  0.0.1bzr29saucy0.87  at the same time it should work without rebuilding right
<robert_ancell> then we'd just have a break if the copies are out of sync (assuming they will be)
<RAOF> robert_ancell: That's true. I just don't trust the staging PPA to be in a consistent state at an arbitrary time.
<robert_ancell> thomi, any chance we can get the mir revision number in the u-s-c build so it's easier to tell which ones match
<thomi> robert_ancell: you want the lp:mir revno in the u-s-c package version?
<robert_ancell> thomi, yeah, then you could tell exactly which version of mir u-s-c was compiled against
<thomi> robert_ancell: don't we already do that with the Depends line?
<robert_ancell> thomi, yes, I guess so - though that is harder to read from the list of packages in the PPA
<robert_ancell> (I'm guessing the answer is too hard)
<robert_ancell> This will all get solved by didrocks in the next week or so as it hits universe
<thomi> robert_ancell: I don't know the answer, I'll fire off an email to people who will know though
<thomi> yeah, it's all crazy distro stuff
<robert_ancell> thomi, I don't think it will be worth it in time
<thomi> ok
<RAOF> thomi, robert_ancell: Either of you know how to wrangle an environment variable into our unit-tests?
<robert_ancell> RAOF, no
<thomi> RAOF: how do you mean?
<RAOF> thomi: I want to LD_PRELOAD a library for running the unit-tests (as I'm interposing a libc symbol).
<RAOF> thomi: This is https://code.launchpad.net/~raof/mir/prober-drm-device-probe/+merge/170765 by the way, which passes the tests *just fine* locally.
<tvoss> good morning all :)
<thomi> RAOF: that's some crazy stuff right there O.0
<thomi> hi tvoss
<robert_ancell> tvoss, welcome
<RAOF> Or maybe a wild tvoss knows!
<tvoss> thomi, hey, welcome back :)
<thomi> tvoss: thank
<thomi> s
<tvoss> RAOF, how can I help?
<RAOF> thomi: We're already interposing libdrm and libgbm symbols, it's no more weird than that :P
<RAOF> tvoss: Do you know how to get an environment variable set in our unit-test's environment.
<RAOF> tvoss: Specifically, to set LD_PRELOAD=lib/lib-mir-test-double-platform.so
<tvoss> RAOF, why not alter the env with cmake?
<RAOF> Hm, will that work?
 * RAOF investigates.
<tvoss> RAOF, mind giving me some background?
<robert_ancell> RAOF, Any thoughts on the ARM builds failing due to that broken dep (https://bugs.launchpad.net/mir/+bug/1194002). I did some investigation, but the sticking plaster of just explicitly adding the dependency would solve the immediate problem - can you make that change in your git branch
<ubot5> Launchpad bug 1194002 in Mir "Mesa armhf builds don't depend on libmirclient" [High,Triaged]
<RAOF> robert_ancell: I thought I already had made that change?
<robert_ancell> RAOF, it doesn't appear so
<robert_ancell> RAOF, ok, I see it in git...
<tvoss> RAOF, is that still about the prober-mp?
<RAOF> tvoss: Context is https://code.launchpad.net/~raof/mir/prober-drm-device-probe/+merge/170765 - I've worked around the double-ctor problem, but can't get the open() wrapper to interpose in CI.
<thomi> RAOF: so I guess the problem is the environment in the package build
<tvoss> RAOF, okay :) did my mail help?
<thomi> you're setting it locally when you run the test yourself?
<RAOF> thomi: Actually, I don't *need* to set it locally. Which is another oddity.
<thomi> RAOF: !??
<RAOF> But that's fragile, as it depends on the linker loading the right symbol first.
<thomi> that's a bit strange, isn't it?
<RAOF> Yes.
<RAOF> But not totally outlandish; trying to interpose a libc symbol is fairly niche :)
<veebers> tvoss, racarr: hello, have you had the chance to follow up on the input stack issue I queried about?
<tvoss> veebers, could you remind me real quick, only had one coffee so far :)
<veebers> tvoss: heh :-) This is regarding keyboard mapping entering characters like '$' etc. using uinput on the devices. I can fwd the previous email if that helps
<tvoss> veebers, ah, no that helps. So the question becomes, if we want to do it for the official phone images right now
<veebers> tvoss: ah ok. I might mention that fixing this will fix the bug in autopilot that is blocking gemas work on the memory/power usage tests
<tvoss> veebers, that's only for the browser, right?
<veebers> tvoss: at this stage I believe so (anything that needs to type 'shifted' characters)
<tvoss> veebers, okay, couldn't we add bookmarks for the pages we want to access and then open the bookmarks?
<veebers> tvoss: if the intention of the test is to ensure loading a page works (and measuring usage while that happens) as opposed to testing entering a url and hitting enter etc.
<thomi> tvoss: veebers: that would still leave us without test coverage for a very large part of the app (and other apps too).
<veebers> thomi: agreed
<tvoss> thomi, sure, but: fixing it in the current official images right now would mean touching the ubuntuappmanager, which is going away with Mir
<thomi> tvoss: I see
<tvoss> thomi, trying to find out what we lose by not doing it right now
<thomi> tvoss: what's the timeline for introducing mir?
<tvoss> thomi, asap,we have an alternate image running it
<thomi> veebers: perhaps you could try the alternate image then?
<tvoss> thomi, not recommended right now for quality stuff
<thomi> tvoss: that's with --flipped, right?
<veebers> thomi, tvoss: It would be interesting to run it and ensure the issue we were experiencing are solved
<tvoss> thomi, not only, it's flipped + mir. an alternate alternate image, if you want so
<thomi> haha
<tvoss> veebers, hold on, let's focus on unblocking gema here: if you really can't workaround the keymap issue, I will work with racarr to fix it in the ubuntuappmanager, but: we might try to be create to unblock gema
<tvoss> s/create/creative
<thomi> tvoss: if the flipped & mir image is the way of the future, surely gema can/should be testing that anyway? and if it "just works", wouldn't that be the path of least resistance?
<tvoss> thomi, I'm pretty sure it won't just work, and our timelines on resource measurement are tight.
<tvoss> veebers, do you have a bug open somewhere about the keymapping behavior?
<veebers> veebers: yep, one moment
<veebers> tvoss: https://bugs.launchpad.net/autopilot/+bug/1181216
<ubot5> Launchpad bug 1181216 in Autopilot "Autopilot does not type : (colon) on devices" [Critical,In progress]
<thomi> tvoss: ack
<tvoss> veebers, for the bug: why do you need a : to open a webpage?
<tvoss> www.cnn.com should work, too
<veebers> tvoss: I suspect the test is typing http: . . .
<veebers> tvoss: that is a good point
<tvoss> veebers, well, the short term workaround might be to get rid of the http:
<veebers> tvoss: I'll look into getting those tests update w/ the workaround
<thomi> RAOF: got a sec? the u-s-c package you pushed seems a little broken to me
<tvoss> veebers, thx a lot
<RAOF> thomi: Boo. In what way?
<veebers> tvoss: thanks for pointing that out :-)
<thomi> RAOF: it depends on bzr773 libmirserver0, but 774 is the latest version, and the one that's built in the PPA
<thomi> so I'm not sure how that is possible
<tvoss> veebers, yw
<tvoss> thomi, staging?
<thomi> RAOF: shouldn't it take the package version number from whatever it built against?
<thomi> tvoss: no, the compositor test ppa
<tvoss> thomi, hmmm
<RAOF> Correct.
<thomi> although I note that the package version is the same in both PPAs,except staging has a newer mir
<tvoss> veebers, I will add a comment to the bug report
<veebers> tvoss: awesome, thanks
<RAOF> thomi: amd64 certainly depends on 774.
 * RAOF checks i386
<tvoss> veebers, done
<RAOF> thomi: As does i386.
<RAOF> thomi: You're installing the wrong u-s-c.
<thomi> RAOF: WTF? why does my laptop insist it's 773?
<thomi> maybe I just missed the update or something?
<RAOF> You have both system-compositor-testing and staging PPAs enabled?
<thomi> RAOF: nope
<thomi> RAOF: should I?
<RAOF> No, but that could cause this sort of problem :)
<thomi> hmmm: W: Failed to fetch bzip2:/var/lib/apt/lists/partial/ppa.launchpad.net_mir-team_staging_ubuntu_dists_saucy_main_binary-amd64_Packages  Hash Sum mismatch
<thomi> \o/ works now :)
<RAOF> The plot thickens!
<thomi> it seems I must have apt-get update'd a few minutes too early
<RAOF> :)
<robert_ancell> that hash sum mismatch makes me really wary about our infrastructure  - I see that too often
<thomi> hmmmm
<thomi> I think I may have broken lightdm
<thomi> after changing lightdm.conf to enable u-s-c I seem to be stuck at boot on the 'ubuntu' spinning dots screen
<tvoss> thomi, do we have autopilot integration for udevmock?
<thomi> tvoss: I'm not sure what udevmock is. so probably not :)
<RAOF> thomi: You may have double-enabled it - /etc/lightdm/lightdm.conf.d should have a snippet automatically enabling u-s-c
<RAOF> tvoss: Ooooh, good idea!
<thomi> RAOF: no, it turns out lightdm is not installed because it relies on a newer glib than I have available... FFS
<thomi> nothing seems to be working for me today
<RAOF> Win!
<tvoss> RAOF, trying to address the testing issue
<robert_ancell> thomi, really? That's odd
<RAOF> Are you trying this on saucy?
<thomi> RAOF: yes
<thomi> did a dist upgrade this morning, and I have no pending updates
<robert_ancell> RAOF, duflu, racarr, kdub, tvoss, hikiko meeting reminder
<tvoss> robert_ancell, yup, I'm on a broadband connection, sitting in the tax office :) Mind if I participate via irc?
<robert_ancell> tvoss, np
<duflu> tvoss: Sounds like fun
<tvoss> duflu, totally _not_
<thomi> can someone please link me the hangout link?
<robert_ancell> tvoss, is audio-only not fast enought?
<thomi> for some reason my calendar does not show it
<tvoss> duflu, building a display server is the one thing, german tax is the other :)
<robert_ancell> tvoss, zing!
<alf> thomi: https://plus.google.com/hangouts/_/a9abbc8e84f85360faaab30196768ca2d9129d09
<tvoss> robert_ancell, let me try to find a quiet spot
<robert_ancell> kgunn, if you're actually here (I hope not) ^
<RAOF> Time for another exciting round of "how crap is my internet today?!
<tvoss> robert_ancell, sorry, quiet spot found but only edge :/
<robert_ancell> tvoss, :(
<robert_ancell> tvoss, we're discussing multi-monitor at the moment
<tvoss> robert_ancell, argh ...
<thomi> ugh, internet issues, you all sound like chipmunks every 10 seconds or so
<veebers> thomi: issue or feature :-)
<didrocks> robert_ancell: hey, what happens when someone runs manually unity-system-compsitor?
<robert_ancell> didrocks, it complains you didn't set up the pipes to talk to it
<didrocks> robert_ancell: should it be in libexec rather?
<robert_ancell> didrocks, no
<didrocks> as lightdm and others will only be able to run it?
<robert_ancell> libexec is stupid
<didrocks> well, shipping in /usr/bin when most people can't run it is stupid :)
<robert_ancell> there's loads of stuff in /usr/bin
<didrocks> most of them, people can run them and see a result
<didrocks> but fine, not my project
<robert_ancell> it should be in sbin though
<didrocks> robert_ancell: I'm more ok with this
<robert_ancell> didrocks, it's the same as lightdm
<didrocks> yeah, sbin makes sense
<didrocks> robert_ancell: I'll move it while proposing my fixes
<robert_ancell> didrocks, ok
<didrocks> robert_ancell: do you want me to make MP for lightdm and unity-greeter for daily release as well?
<robert_ancell> didrocks, yes, as long as we have the integration tests to confirm they work together
<didrocks> robert_ancell: do you have them? I think it's like xmir, qtmir and unity-system-compositor, there isn't any?
<didrocks> robert_ancell: I can prepare the package for a ppa then, daily releasing there until you have them
<robert_ancell> didrocks, I sent an email about it
<didrocks> robert_ancell: I answered I guess ;)
<didrocks> I should use https://code.launchpad.net/~lightdm-team/lightdm/mir-packaging I guess
<didrocks> robert_ancell: one part of daily release is to have the packaging inlined, it's not the case for lightdm and unity-greeter I think?
<robert_ancell> didrocks, we're using ~lightdm-team/lightdm/trunk-packaging for the CI
<robert_ancell> didrocks, u-g has inline packaging now
<robert_ancell> didrocks, I'm trying to work out what we can do for lightdm inline packaging that makes sense
<robert_ancell> didrocks, sorry, I have to go - please email me any other questions. I'm here late tomorrow so we'll have overlap then too
<didrocks> robert_ancell: ok, have a good night!
<hikiko> RAOF, and alf sorry:) I thought we are still in the hangout
<tvoss> RAOF, did the vt-fix propagate to the ppa, yet?
<tvoss> cannot switch to vt after an upgrade
<didrocks> alf: hey! do you have time this morning?
<RAOF> tvoss: Should have.
<tvoss> RAOF, so whre do I find the VT? ctrl+alt+?
<RAOF> F1-F12?
<alf> hikiko: You were welcome to stay :)
<tvoss> RAOF, hmmm, that leaves me with the desktop on screen and no login prompt
<alf> didrocks: sure, I will work on top of your branch if that's ok
<RAOF> Hm. So we may have one additional VT bug.
<didrocks> alf: perfect! thanks :)
<mlankhorst> RAOF: will the mir system compositor replace kmscon? :P
<RAOF> mlankhorst: Absolutely@!
<RAOF> #dontcheck
<RAOF> Sorry, in joke.
<mlankhorst> I find your failed attempt at humor amusing. :)
<tvoss> RAOF, mind repinging me the udev mock thingy on google?
<tvoss> s/google/chromium
<RAOF> https://code.google.com/p/chromium/issues/detail?id=248824 ?
<alf> mlankhorst: I think I found a race in the radeon driver cs thread. In particular, if trying to flush from two contexts sometimes one of them may hang.
<alf> mlankhorst: (in Mesa/Gallium)
<alf> mlankhorst: are you the right person to talk to?
<mlankhorst> probably
<mlankhorst> I don't think I've ever tried flushing from 2 threads though
<mlankhorst> but what is it hanging on?
<tvoss> RAOF, thx
<didrocks> alf: should the source be name qtmir or qmir?
<didrocks> also, do you have any packaging somewhere? :)
<didrocks> hey RAOF, do you have a minute to discuss about xmir?
<RAOF> didrocks: Sure.
<alf> mlankhorst: In radeon_drm_cs_flush() the code is waiting for the cs_queue to become empty pipe_condvar_wait(cs->ws->cs_queue_empty,...). In the case that we flush from two different (but shared) contexts sometimes it gets stuck there.
<RAOF> didrocks: Probably not more than 5 minutes, though (I'll be available later, too, if necessary)
<didrocks> RAOF: ok, let's try to be short: how do you want that we treat xmir?
<didrocks> as if it was a canonical upstream for us? with dailies?
<mlankhorst> alf: hm what I thought, change pipe_condvar_signal to pipe_condvar_broadcast in radeon_drm_cs_emit_ioctl ?
<didrocks> or you keep everything in git?
<RAOF> didrocks: I guess as a patch on top of the regular X package?
<didrocks> RAOF: ok, so X source + patch for having an additional binary package
<didrocks> right?
<alf> mlankhorst: I tried that, but it didn't work, although I didn't investigate more
<didrocks> not a separate source, nothingâ¦
<RAOF> didrocks: No extra binary package, although I could create one if we wanted.
<didrocks> RAOF: oh, I don't really, as long as it's part of the same X source, I'm fine (so no dailies for it)
<didrocks> RAOF: the only question is how would you treat mir ABI then?
<didrocks> and it's not stable AFAIK
<RAOF> mirclient ABI *is* stable.
<alf> mlankhorst: I will investigate more and let you now
<alf> mlankhorst: know
<didrocks> RAOF: ah ok, so no biggie I guess :)
<duflu> RAOF: ABI yes, not API ;)
<RAOF> At least, it's stable enough that I bumped the SONAME recently.
<didrocks> RAOF: so, for mesa + xmir, I have nothing to do, nothing to daily release, right?
<RAOF> didrocks: Right.
<didrocks> \o/
<didrocks> thanks RAOF :)
<alf> didrocks: tvoss: Didn'd we abandon qmir/qtmir in favor of qtubuntu with a mir backend?
<didrocks> ah?
<tvoss> alf, I would think so for the time being. We should keep it around, though
<didrocks> tvoss: so qtubuntu binary package contains the mir backend?
<didrocks> and that's what Saviq's team is using?
<tvoss> didrocks, exactly
<mlankhorst> alf: afaict glisse reworked the whole thread code, no wonder it looked a lot more complicated than before ;P
<mlankhorst> I don't see why the ncs member is atomic either, considering it's always protected by cs_stack_lock
<duflu> Out of curiosity, has anyone tried a native GL (not ES) client in Mir? I can't remember seeing anyone having done so
<alf> duflu: yes, glmark2-mir works
<duflu> alf: Cool. I thought that was a port of "-es" ?
<alf> duflu: Not really a port, the glmark2 code can produce binaries for both GL and GLES2.0, depending on the --with-flavors= you pass
<duflu> alf: So you tested both?
<duflu> Which is in the PPA?
 * duflu looks
<mlankhorst> alf: but the whole thread code looks messy to me :/
<alf> mlankhorst: I will try to come up with a minimal example that hangs, so we can investigate (and prove the problem upstream) easier
<mlankhorst> ok
 * duflu realizes no glmark2 is in the testing PPA :/
<mlankhorst> if you have one I'll fix it
<alf> mlankhorst: great, thanks
<tvoss> veebers, mind pinging me the bug number again?
<mlankhorst> alf: but that code looks like a mess, needs more locking :P
<mlankhorst> radeon_drm_cs_flush looks like it could deadlock if called from 2 threads simultaneously, might be by design though..
<alf> mlankhorst: that would be a strange design... :)
<mlankhorst> alf: I'm not sure it's legal to flush the same cs twice, but I'll know more with the reduced testcase
<veebers> tvoss: sure: https://bugs.launchpad.net/autopilot/+bug/1181216
<ubot5> Launchpad bug 1181216 in Autopilot "Autopilot does not type : (colon) on devices" [Critical,In progress]
<tvoss> veebers, thx
<veebers> tvoss: nw
<alf> mlankhorst: is the cs per process or per context?
<mlankhorst> per context
<alf> mlankhorst: and shared contexts also share the cs?
<mlankhorst> I'll wait for the testcase first I guess, then I know if what you're doing is ok or not :p
<alf> mlankhorst: ok
 * tvoss is impressed by the brain to totally ignore the second cursor after some time of painful practice
 * duflu thinks it's still handy to have a "watermark"
<duflu> Because it tells me which display server I'm really using
<duflu> But then so does the absence of VT switching :(
<cking> thomi, ping
<tvoss> duflu, RAOF I thought the vt switching was solved
<duflu> tvoss: Nope. Just retested. Asked Robert if he thinks I'm missing any packages
<duflu> tvoss: https://bugs.launchpad.net/bugs/1192429
<ubot5> Launchpad bug 1192429 in Unity System Compositor "unity-system-compositor is on multiple simultaneous (and random) VTs" [High,New]
<tvoss> duflu, ack, thx for the bug
 * tvoss off to kubuntu-desktop world
<RAOF> BAH!
<RAOF> Of course!
<RAOF> I'm not mocking out enough.
<RAOF> tvoss: Argh! I I realised why the device-probing branch isn't passing CI. There are no devices to probe under CI!
<thomi> cking: hey, I'm kind of here, if it's quick.
<cking> thomi, oh, I sent an email, it may be quick for you, not for me
<RAOF> tvoss: Sending a mock through the GBMPlatform it is :)
 * thomi looks
<tvoss> RAOF, :)
<RAOF> But tomorrow; I'm not going to have time to get that all ready before I need to sleep, so it can wait to tomorrow.
<tvoss> RAOF, ack, I will see if I can get the powerful google udev stuff pulled out in a sane way somehow
<alf> didrocks: https://code.launchpad.net/~afrantzis/mir/move-lttng-libs/+merge/171492
<alf> duflu: @SnapshotStrategy, I tried to avoid verbified nouns, but in essence it is a Snapshotter or SnapshotTaker. Perhaps SnapshotTakingStrategy?
<alf> duflu: oops that's nounified verbs
<duflu> alf: I find *Strategy confusing. If you can communicate better with my feeble brain then I'm sure others might benefit similarly
<alf> duflu: I am open to suggestions, but I couldn't find anything better without going to noun-ified verbs.
<duflu> alf: Not sure about suggestions until I can understand what it is
<alf> duflu: It's an interface (a role) that provides the functionality to take snapshots of surfaces
<duflu> alf: A "camera" takes snapshots. I wonder if there's a good simile of "camera"
<alf> duflu: I thought of "camera", but I found e.g. SessionCamera more confusing in terms of what it really is
<duflu> alf: Yeah agreed it's not a good word. I think we're still in the realm of naming things according to what they do instead of what they are
<duflu> Which sometimes suggests the functionality should not be in that class, but the class that uses it
<duflu> But that might be over-generalizing
<duflu> alf: What varies between different SnapshotStrategies?
<alf> duflu: Many classes, however, are just helper classes that have a very specific role to play (also for TDD). It's hard to describe these in terms of a noun/object.
<duflu> alf: Being more concrete doesn't eliminate TDD. Just makes it harder to think of the right words :)
<duflu> But once you do, many people will benefit
<alf> alf: Right now nothing, since we have only one production SnapshotStrategy. Potentially, everyything. You tell it to take a snapshot, and it can do it any way it likes.
<alf> duflu: ^^
<didrocks> alf: src/shared/lttng/tracepoint_provider.cpp is pre-processed?
<didrocks> ({MIR_TRACEPOINT_LIB_INSTALL_PATH} is replace?)
<alf> didrocks: it's a preprocessor definition (see src/shared/lttng/CMakeLists.txt)
<didrocks> alf: interesting, didn't know that cmake had that! better than manually processing a config.h
<didrocks> alf: approving then, thanks!
<duflu> alf: Abstained. If neither of us can think of better names yet then it's not worth blocking on
<alf> duflu: thanks, perhaps the US has some more suggestions
<katie> tvoss_, time for a catch up in 3 mins?
<tvoss_> katie, yup, let me grab coffee :)
<katie> tvoss_, mpt is joining too
<alf> didrocks: typo in MP, fixing
<didrocks> ok :)
<dholbach> Could anyone brainstorm with me which information we have which could go into fixing these docs bugs? https://bugs.launchpad.net/mir/+bugs?field.tag=docs
<didrocks> michi___: small question on unity-api, from what I see, the .pc files won't be different per archs, right?
<didrocks> ah, you -L the multiarch path in it (shouldn't be needed)
<mterry> racarr, you might want to merge platform-api/mir-with-packaging with trunk for that `ua_ui_session_properties_set_remote_pid' issue I ran into yesterday
<didrocks> mterry: speaking of platform-api, mind having a quick look at https://code.launchpad.net/~didrocks/platform-api/changelog-cleanup/+merge/171476?
<mterry> didrocks, what do you mean you detect the arches we can't build for?
<mterry> didrocks, but we don't change the control file, so we are still uploading to archive and causing dep-wait packages, right?
<didrocks> mterry: detect the arch -> yeah, we don't live in stone age! :)
<didrocks> mterry: basically I'm checking if we build-dep for an unimportant arch in distro
<didrocks> (from last uploda)
<didrocks> upload*
<didrocks> if so, I'm ignoring the arch state in daily release
<didrocks> (right now, "important archs" are i386, amd64, armhf)
<kdub> morning all
<alf> kdub: Hi! Long time no see :P
<kdub> indeed
<kgunn> kdub!
<kdub> hello!
<alf> status: [spike] Investigating how our components (mainly the compositor and friends) react to display configuration changes, and how we can solve the problems that come up.
 * kdub is trying to drain the msh::Surface/ms::Surface swamp a bit :) also investigating how to hook the shell up to a signal to turn the screen off 
<kdub> we should have a moratorium on classes with 'surface' in them for a while :)
<mterry> greyback_, racarr : in compiling unity8-integrate-mir, I get:
<mterry> /usr/include/mirserver/mir/default_server_configuration.h:21:28: fatal error: mir/cached_ptr.h: No such file or directory
<mterry> which looks more like just a mir bug actually, since it's from a mir include
<greyback_> mterry: that should be in /usr/include/mircommon, is that installed?
<mterry> hmm, mirserver.pc requires mircommon.pc which has the right includes
<mterry> greyback_, yes
<greyback_> mterry: I'm not sure so. What's the compiler line "VERBOSE=1 make"
<mterry> greyback_, oh weird.  main.cpp uses "#include <mirserver/mir/run_mir.h>" but I would expect it to use "#include <mir/run_mir.h>" with the appropriate -I cflags
<mterry> and CMakeLists.txt doesn't seem to use the pc files
<mterry> greyback_, but since this is a team branch I can fix myself
<greyback_> mterry: it was hacked together to work, nothing more :)
<greyback_> mterry: please do
<mterry> racarr, it might be convenient if your other mir-packaging branches were team based too
<mterry> greyback_, let's say I get unity8-integrate-mir built and installed on my phone.  How do I use it?  Like, how do I stop surfaceflinger from starting?
<mterry> oh, he's gone
<mterry> greyback_, let's say I get unity8-integrate-mir built and installed on my phone.  How do I use it?  Like, how do I stop surfaceflinger from starting?  Or do I just have to use the ./run -m -i script?
<greyback_> mterry: the script works when you execute it from your PC
<greyback_> mterry: else manually, adb root, "stop" to stop SurfaceFlinger
<greyback_> mterry: make sure unity8 is not running
<greyback_> then in the ubuntu chroot, run "QT_QPA_PLATFORM=ubuntumirserver unity8"
<mterry> greyback_, hmm...  I bet there's a way to install it and modify the upstart jobs to not run surfaceflinger and to use that QT_QPA_PLATFORM variable.  I'll look into that in a bit (I'm trying to actually test final on-phone integration)
<greyback_> mterry: the android side runs surface flinger, it's not upstart
<mterry> guh, hm
<mterry> greyback_, is this where flipped mode comes in?
<greyback_> mterry: ultimately, it will help a lot, yes
<kdub> mterry, i'd advise a stronger, 'make sure that surfaceflinger has never ran'
<mterry> kdub, you mean "never ran this boot", not that surfaceflinger makes some permanent filesystem changes that are bad, right?
<kdub> right
<mterry> k..  I guess I need flip mode for that, and to modify how we start the android side...
 * mterry is in unfamiliar territory
<kdub> its just that sometimes, surfaceflinger hands out resources to the clients that persist after sf's actual death
<kdub> and causes mir problems
<greyback_> yep, I've noticed that. I make sure all UI apps are killed after stopping SF, before I run Mir
<mterry> racarr, heyo.  So I realized that my goals with testing Mir are a little different than yours with that sketchpad.  I'm looking to have a fully installed Mir, rather than the ability to run a branch from your pc on the phone.  So rather than have two sets of instructions on the sketchpad, I started a new in-progress wiki page: https://wiki.ubuntu.com/Touch/Testing/Mir
<racarr> mterry: Yay. Thanks.
<gotwig> hello world
<gotwig> is there a PPA for Unity + Mir ?
<gotwig> oh I found this http://www.phoronix.com/scan.php?page=news_item&px=MTM5Mzc
<racarr> kdub: http://www.phoronix.com/scan.php?page=news_item&px=MTM5NTg
<racarr> congratulations, you've won the official phoronix most revisions award
<racarr> I'll be picking up your trophy at the engraver
<kdub> haha :)
<gotwig> guys have you seen this?
<gotwig> http://www.phoronix.com/scan.php?page=news_item&px=MTM5NDU
<gotwig> racarr, nice
<kgunn> mhall119: ping
<mhall119> kgunn: pong
<kgunn> mhall119: do you happen know why on this automagic site http://unity.ubuntu.com/mir/installing_prebuilt_on_pc.html
<kgunn> that the numbering stays on one ?
<kgunn> when the *.md file source that populates it, is clearly 1,2,3,4, etc
<kgunn> (i'm considering just removing the #s....will that be easier?)
<mhall119> is that doxygen generated?
<kgunn> mhall119: from *.md to wiki...i dunno (i thot you had helped us with this? i'm wrong?)
<mhall119> no, I can publish docs, but I'm not the one who gets them put together
<mhall119> it might have been thomi ?
<gotwig> why havent you talked to the wayland devs, in "the secret development process" of mir?
<thomi> morning guys
<thomi> (and girls)
<gotwig> you should read the "Mir Development Stats Dominated By Canonical comments http://phoronix.com/forums/showthread.php?81653-Mir-Development-Stats-Dominated-By-Canonical&p=338644#post338644 ï»¿
<gotwig> or this http://phoronix.com/forums/showthread.php?81653-Mir-Development-Stats-Dominated-By-Canonical&p=338687#post338687
<gotwig> it would be nice if someone could answer me
<gotwig> mhall119, ?
<racarr> gotwig: I'm not sure what you are asking :)
<gotwig> racarr, well, have you read the posts?
<racarr> We have talked to Wayland devs, and the development process, isn't particular secret
<gotwig> I mean right at the beginning of the development
<gotwig> I know what commit logs are..
<gotwig> racarr, have you read the last post I linked?
<gotwig> he basicly says that in wayland apps can run without a compositor, and can directly talk to GPU
<gotwig> in Mir, however, he states that the concept is similar to Xorg
<racarr> :) I think it's pretty normal to develop some confidence in your ideas before going public with them, espescially when you are a large organization under a lot of scrutinity and with a lot of responsibility to your users.
<racarr> I
<racarr> don't really understand the post sorry
<racarr> it seems to be quibbling about the fact that 'wayland' is just a specification
<racarr> on the other hand, I think anyone can talk about "wayland"
<racarr> and it's understood what they mean ;)
<gotwig> racarr, you really dont understand it?
<racarr> Mir applications can access the frame buffer
<racarr> directly
<racarr> no, I don't. I don't think it makes sense
<racarr> it's setting up a false dichotomy, i.e.
<gotwig> well, I am not such a die hard core level dev, so I just want to find something intressting to read, so I can understand it better
<racarr> Mir is a server, whereas wayland is a specification, therefore mir applications can't access the framebuffer directly
<gotwig> and I found these answers
<racarr> but
<racarr> that's not true
<gotwig> why would apps want to access the framebuffer directly
<racarr> Imagine you have made a video fullscreen, it seems pretty wasteful to wake up the compositor every time
<racarr> the video changes right?
<gotwig> why do you go with this "server" way? Because you want to have something more practical than in theory?
<gotwig> greyback_, howdy =)
<racarr> gotwig: It's not so different, a weston compositor is a 'server' too
<gotwig> racarr, but wayland apps dont have to use a compositor
<greyback_> gotwig: hi there
<racarr> gotwig: Well, yes, if you want to run one at a time from a virtual terminal
<racarr> in any real use cases though, it doesn't make a difference, because you either need to composite, or sometimes you can let apps skip composition (like fullscreen videos)
<gotwig> racarr, he says that its better with the "wayland" way for fullscreen games, which dont need any overload from any system compositor stuff ;X
<racarr> and it's something both wayland, X11, and mir all support pretty easily.
<racarr> gotwig: There's no overhead :)
<racarr> that's why I don't understand the post
<mhall119> gotwig: Weston is the Wayland compositor, IIRC
<gotwig> but as of today compositing can also be disabled on Xorg
<gotwig> what is different here?
<gotwig> as of today I think is the wrong phrase ;D
<gotwig> mhall119, I know =)
<mhall119> gotwig:  I think whomever wrote this doesn't have a clear understanding of what is what
<racarr> in non composited Xorg, rather than having offscreen memory buffers (in GPU of course) for window regions
<mhall119> or at least they didn't do a good job of communicating it
<racarr> the applications all share the framebuffer
<racarr> this is why, in non composited, when you drag a window off from another one, sometimes you can see
<racarr> it takes a while to update.
<racarr> Mir and Wayland only support uncomposited in the case of a single fullscreen surface
<gotwig> are there any major things which are going to be faster/slower in Mir/Wayland?
<gotwig> flaws, from the concept
<kgunn> gotwig: can you make a proposal what might be faster/slower in terms of a concept ?
<kgunn> thomi: just checking...do we have stress as part of CI ?
<gotwig> kgunn, no, that is because I ask this question...
<kgunn> gotwig: surely you could propose something you might consider a potential ?
<gotwig> Mir is going to be the always wanted "System Compositor" for Ubuntu, as far as I understand it
<mhall119> gotwig: both Mir and Wayland are likely to be much faster than X11 because of their design
<mhall119> they will probably be comparable in terms of speed between them
<kgunn> gotwig: keep in mind regardless of a name, any compositor can be "bypassed", this is industry standard practice
<mhall119> so the poster seems more familiar with Wayland, and I think is trying to address inaccurate descriptions of Wayland's features
<mhall119> I don't think he's saying there's anything wrong with Mir
<kgunn> mhall119: sure...just trying to help....because statements like "apps can run without a compositor, and can directly talk to GPU"
<kgunn> just aren't sensible
<kdub> yeah
<mhall119> it seems he's saying that technically you could run a single Wayland client, which wouldn't require a compositor like Weston (or Gnome Shell)
<kgunn> gotta go
<mhall119> but in reality nobody's gonna do that, they're going to have a session compositor and multiple windows
<mhall119> and only bypass the compositor for things like fullscreen games
<mhall119> which is the same in X.org, Mir and Wayland
<racarr> plus you can use libmirserver to run without  compositor ;)
<racarr> like unity does
<racarr> it's compositors all the way up and down
<racarr> :p
<mhall119> gotwig: so tl;dr, there's not that much conceptual difference between Wayland and Mir
<gotwig> thx
<gotwig> you may want to read this http://www.phoronix.com/vr.php?view=MTM5NDU
<gotwig> Xserver integration in the linux kernel for a performance boost
<kdub> racarr, starting to see the light at the end of the tunnel with msh::Surface :)
<racarr> kdub: Yay
<racarr> I am trying to pass the socket credentials up through the frontend...it's pretty mundane :p
<thomi> kgunn: not yet, hoping to get that done this week
<racarr> class that receives (pid, app-id) (desktop file)
<racarr> and says hey you can connect or hey go away
<racarr> SessionAuthorizer, Approver?
<robert_ancell> Hmm, has olli actually gone sailing or is that his standard quit message?
<robert_ancell> kgunn, ^
<racarr> robert_ancell: I think I have seen that before
<racarr> olli went sailing 2/3 times he quit today XD
<robert_ancell> olli, that was a quick sail :)
<olli> :)
<robert_ancell> kgunn, https://code.launchpad.net/~kgunn72/mir/instructional_updates/+merge/171654 updated
<kgunn> robert_ancell: ta!
<thomi> robert_ancell: I finally got all the u-s-c stuff installed, now when I reboot I get the "low graphics mode" dialog box, and my mouse doesn't work. Any ideas?
<robert_ancell> thomi, look at lightdm.log
<robert_ancell> it failed to start X it seems
<kgunn> robert_ancell: approved https://code.launchpad.net/~robert-ancell/mir/instructional_updates/+merge/171677
<robert_ancell> kgunn, you'll have to manually merge it, see the "to merge this branch" line at the top. Then push it to your branch to update your MP
<olli> RAOF, ping
<kgunn> robert_ancell: so "bzr merge lp:~robert-ancell/mir/instructional_updates" merges it locally(on my box) ? or remote as well ?....e.g. then do i have to do a subsequent push ?
<robert_ancell> kgunn, just locally, then bzr commit it, the bzr push it to LP
<kgunn> robert_ancell: thanks again for your patience :)
<robert_ancell> kgunn, I thought it would be a good example of bzr so I did it this way :)
<thomi> robert_ancell: the log looks fine to me: http://paste.ubuntu.com/5803018/
<robert_ancell> thomi, [+16.12s] DEBUG: Process 1423 terminated with signal 6 - that's u-s-c crapping out. Look at unity-system-compositor.log
<robert_ancell> readable error that followed: [+16.12s] DEBUG: Stopping Unity seat, compositor terminated
<robert_ancell> thomi, what hardware btw?
<thomi> robert_ancell: http://paste.ubuntu.com/5803023/
<thomi> robert_ancell: I believe it's a radeon something something
<robert_ancell> terminate called after throwing an instance of 'boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<std::runtime_error> >'
<robert_ancell>   what():  Failed to schedule page flip
<robert_ancell> RAOF, any idea?
<robert_ancell> thomi, that's the problem..
<thomi> robert_ancell: no, I tella  lie, it's an intel i915
<robert_ancell> and it looks like X locked up, because it didn't respond to signal 15, or die when u-s-c died
<robert_ancell> thomi, can you check versions of lightdm, u-s-c, x to confirm?
<thomi> sure
<thomi> lightdm is 1.7.3bzr1628saucy0.71u-s-c is 0.0.1bzr29saucy0.87
<thomi> what package should Ibe looking at for x? 'xorg'?
<robert_ancell> thomi, xserver-xorg-core
<thomi> xserver-xorg-core is 2:1.13.3+xmir1-0
<robert_ancell> thomi, I have an older u-s-c, I'll update and see if I get the problem
<thomi> ok, thanks
<robert_ancell> thomi, I'm 00:02.0 VGA compatible controller: Intel Corporation Core Processor Integrated Graphics Controller (rev 18) for the record
<mterry> kdub, hello!  So let's say I have a unity8 binary that I think should work.  Do I need to start a system compositor first, or will just running that binary autostart all the necessary mir bits?
<olli> robert_ancell, one quick q
<kdub> mterry, i think it should work just like that
<olli> why do we need to pin mir
<olli> to make sure the ppa has always a higher prio?
<robert_ancell> olli, otherwise an update in main might drop the additional features, e.g. lightdm
<olli> ok
<robert_ancell> you would be safe, but you'd stop using Mir every time it would happen
<mterry> kdub, hmm, ok.  It seems to be running, but nothing shows on device screen.  Will dig deeper
<thomi> robert_ancell: any luck upgrading u-s-c?
<robert_ancell> thomi, just in the middle of a mir build, will try once that's complete
<thomi> ok, I'll try and be a bit more patient :)
<kgunn> thomi: so i see above you had issues....
<kgunn> i was about to wade into the deep....were you building
<kgunn> or using staging or using sys-comp-testing
<kgunn>  ?
<thomi> kgunn: I'm running the sys-comp-testing PPA
<kgunn> thomi: eeeewwww, giving me second thots
<thomi> kgunn: heh
<thomi> kgunn: if robert_ancell can reproduce, then I guess we have a problem
<kgunn> thomi: hmmm, think i'll hold off....go do my personal errands and check IRC a bit later :)
<thomi> BTW, why the need for a second PPA?
<robert_ancell> thomi, for the sys-comp-testing ppa over the staging PPA?
<robert_ancell> 92%...
<thomi> robert_ancell: the sys-comp-testing ppa
<thomi> I don't have the staging PPA enabled
<RAOF> olli: Pong.
<robert_ancell> thomi, were you asking why we have both PPAs?
<RAOF> robert_ancell, thomi: That would be what it says on the box - Mir failed to schedule a pageflip (ie: to actually display something), which probably means the GPU hung.
<robert_ancell> RAOF, did we do the correct behaviour in this case, i.e. give up?
<RAOF> I think give up is a perfectly reasonable response.
<thomi> RAOF: why would that be though? the mir_demo_server always works on this machine
<thomi> I don't understand why it would fail now?
<RAOF> thomi: Does dmesg have anything radeonish?
<thomi> RAOF: I was mistakedn about it being radeon, it's an intel i915
<thomi> ...and I would tell you, but I just tried rebooting it, and now it hangs somewhere in the boot phase with a blank screen
<robert_ancell> thomi, you might want to look at https://code.launchpad.net/~robert-ancell/mir/mir-demos-install-path/+merge/171685. In particular I'm not sure how your lttng libs are supposed to work, thought that might be related to bug 1194555?
<ubot5> bug 1194555 in Mir "needs to move the lttng in <libdir>/mir/tools/" [High,In progress] https://launchpad.net/bugs/1194555
<kgunn> thomi: this is weird...but have you tried hitting keys to inject noise/slow down...and see if it boots
<robert_ancell> ok, trying new u-s-c now..
<thomi> ugh. black kscreen hang, no response to any keys, cannot ssh in :-/
<kgunn> i had same boot to hung screen (black)
<kgunn> right....start hitting as soon as its booting....
<kgunn> frighteningly...i have to do this currently to get into my machine on boot now :)
<thomi> kgunn: nope, no difference
<kgunn> thomi: eeewww....now i'm really not gonna try the latest
<thomi> I guess it's time to start downloading a new raring image then
<thomi> good thing it's my testing laptop, not my main
<robert_ancell> thomi, from cold-boot to session with new u-s-c, no problems
<thomi> robert_ancell: I'll reinstall the machine. Kind of worrying that it's possible to brick a laptop with this PPA though :-/
<thomi> well
<thomi> not "brick", but make unrecoverable
<robert_ancell> thomi, couldn't you uninstall u-s-c from low graphics mode?
<thomi> robert_ancell: I have no keyboard or mouse in low graphics mode. The machine is basically frozen
<robert_ancell> we really should have some support to detect if you made it to a shell, but a bit harder to add
<thomi> Ctrl+Alt+F1 does nothing either
<RAOF> Huh.
<RAOF> If you wave your mouse around in low graphics mode you should eventually get a cursor.
<RAOF> The cursor doesn't show up until it's over the dialog box.
<RAOF> Which is silly, yes.
<thomi> well, while I'm downloading the new image I might head into town to run some errands. BBL
<robert_ancell> thomi, bye
<robert_ancell> RAOF, do we have enough info to debug what thomi is seeing? Is there anything else we could add?
<RAOF> robert_ancell: Not really enough info. *Some* sort of log would be handy!
<robert_ancell> RAOF,  from mir?
<RAOF> From anything - mir, dmesg, lightdm. But mir would be an obvious candidate.
<RAOF> Even booting without splash and seeing where it hangs would be good.
<olli> robert_ancell, I was looking at the VT bugs... trying to find one that describes how my password (when entered in Xmir/u7) ends up on console
<olli> is that reported yet?
<robert_ancell> olli, I'll get you the bug
<olli> https://bugs.launchpad.net/unity-system-compositor/+bug/1192429
<ubot5> Launchpad bug 1192429 in Unity System Compositor "unity-system-compositor is on multiple simultaneous (and random) VTs" [High,New]
<olli> https://bugs.launchpad.net/lightdm/+bug/1193207
<ubot5> Launchpad bug 1193207 in Light Display Manager "Issues when swiching sessions when using Unity system compositor" [High,Triaged]
<olli> it's neither of these imho
<robert_ancell> nope
<robert_ancell> olli, bug 1102756
<ubot5> bug 1102756 in Mir "System compositor input events passed to console" [High,Triaged] https://launchpad.net/bugs/1102756
<robert_ancell> bug #4 on the list :)
<ubot5> bug 4 in Launchpad itself "Importing finished po doesn't change progressbar" [Medium,Fix released] https://launchpad.net/bugs/4
<olli> robert_ancell, thx
 * olli adds a "don't try at home" disclaimer
#ubuntu-mir 2013-06-27
 * thomi is back
<RAOF> thomi: Oook.
<duflu> RAOF: No luck with libdrm_radeon/mesa?
<duflu> Hmm, tho it hasn't tried to build since the 24th
<RAOF> duflu: Do you want to hit the rebuild button? Should work now.
<duflu> RAOF: I hit /a? rebuild button. Not sure if it was the right one. Thanks
<duflu> "a"
 * duflu thinks it's awesome that he can click 3 build buttons and all 3 builds start immediately
<duflu> kdub: Jenkins marked this done. Is it really? https://bugs.launchpad.net/mir/+bug/1130553
<ubot5> Launchpad bug 1130553 in Mir "Mir does not support eglSwapInterval(0)" [Medium,Fix committed]
<thomi> does anyone remember the secret key you need to push to stop grub booting?
<RAOF> thomi: Madly mash shift.
 * thomi is still trying to un-brick his laptop :(
<RAOF> thomi: Although we *should* be marking your boot as failed, and automatically bringing up the grub prompt.
<duflu> Mashing escape works too
<thomi> doesnt seem to be shift....
<thomi> and technically speaking, the boot works
<thomi> time to try Escape
<duflu> But you have to be fast with escape. Start mashing at the end of POST
<RAOF> thomi: I believe that we decided that âhas logged in to a session, or does a controlled shutdownâ are the two criteria for determining whether a boot is successful.
<thomi> oh, well that's not workng
<thomi> RAOF: seems you need to hold the shift key, not just press it 0.O
<thomi> robert_ancell: what should I do to disable u-s-c in lightdm.conf?
<robert_ancell> thomi, uninstall u-s-c or edit /etc/lightdm/lightdm.conf.d/10-unity-system-compositor.config and quote out type=unity
<robert_ancell> thomi, also check you don't have an old setting in /etc/lightdm/lightdm.conf - if so just remove it
 * thomi crosses fingers and reboots
 * kgunn waits with anticipation
<thomi> well, I got my laptop back
<thomi> but xmir totally breaks it for me
<kgunn> laptop \o/
<thomi> also, I realise that the mir stress tests break the server again. every time we get closer to enabling them for CI, something else breaks :-/
 * duflu thought lightdm was meant to "fall back to xlocal" if things don't work
<kgunn> olli: i notice you say reboot your system vs restart lightdm....did you experience issues w lightdm restart ?
<robert_ancell> duflu, it did work, then it locked up and lightdm tried to get to failsafe X, but it was locked up by that point
<kgunn> robert_ancell: ^ restart lightdm vs reboot ?
<robert_ancell> kgunn, same difference
<kgunn> robert_ancell: i thot so...just noticed olli referenced it today on irc & in his blog
<RAOF> Hey, what's our idiom on server-side event-callbacks?
<duflu> RAOF: Server side doesn't get callbacks ... ??
<RAOF> duflu: I mean: an event occurs, and some server code needs to react to it. Do we not currently have any of that?
<duflu> RAOF: It will be buried in the server classes (because they do have support for turning events into messages already). But I think what you mean by "server side callback" will be a virtual method to be overridden
 * duflu is not helpful yet; goes to get coffee
<robert_ancell> argh, C++! I copy the demo shell input handling code into u-s-c and it gives me obscure error messages
<duflu> ??
<RAOF> Looks like other parts of our code use a set_foo_callback() idiom.
<kgunn> i just updated to the latest....and verified https://bugs.launchpad.net/mir/+bug/1194039
<ubot5> Launchpad bug 1194039 in Mir "Cannot start any Mir server ... std::exception::what: Failed to set DRM crtc" [High,New]
<thomi> mir_stress causes the mir_demo_server to crash: https://bugs.launchpad.net/mir/+bug/1195089
<ubot5> Launchpad bug 1195089 in Mir "mir_stress suite causes mir_demo_server to crash" [Undecided,New]
<duflu> Reboot. Wish me luck
<duflu> RAOF: Ta. Mir is functional on raring again
<duflu> via staging
<didrocks> hey robert_ancell! around?
<tvoss_> good morning all :)
<didrocks> hey tvoss_
<robert_ancell> didrocks, yep
<didrocks> robert_ancell: was my email I sent yesterday understandable?
<robert_ancell> didrocks, the big ol list of things to be done?
<didrocks> robert_ancell: yep, and particularly the pending questions :)
<thomi> morning tvoss_
<thomi> morning didrocks
<didrocks> hey thomi!
<didrocks> thomi: moving house?
<thomi> didrocks: yeah... have moved. Well, most things are still in boxes
<didrocks> I imagine :)
<didrocks> so you are working from a coffee shop or anything?
<thomi> didrocks: no, working from home, I managed to un-pack my office. But I cannot find anything, so I end up buying new things, then find the box that I was looking for in the first place
<thomi> like, I have no cups....
<thomi> I'm sure they'll turn up somewhere
<robert_ancell> didrocks, can you send me details on how you do integration tests with the unity stack
<didrocks> thomi: argh, but no cups was a priority :-) Anyway, you never have enough of them :)
<thomi> yeah
<didrocks> robert_ancell: doing that now
<didrocks> robert_ancell: on lightdm and ABI, any idea? (meanwhile I'm writing you that)
<robert_ancell> ABI for?
<didrocks> robert_ancell: see, RAOF told that the client ABI is stable, so platform-api and xmir will use that stable ABI, right?
<didrocks> we don't need to worry too much about ABI stability, right?
<robert_ancell> didrocks, yes
<didrocks> so we can put everything in the same stack finally, I guess
<robert_ancell> didrocks, though we want the integration tests to pick up if we stuff that up :)
<didrocks> robert_ancell: sure ;)
<didrocks> platform-api will dep on mir at some near point in the future, right?
<robert_ancell> didrocks, as I understand it, it will depend on libmirclient
<robert_ancell> racarr, correct?
<didrocks> yeah, so, the stacks will be dependant as a whole :)
<robert_ancell> though he's probably asleep :)
<didrocks> robert_ancell: for lightdm/unity-greeter, in that case, do you want them in the mir stack or in another stack?
<didrocks> I guess so :)
<tvoss_> RAOF, good morning :)
<robert_ancell> didrocks, I don't have a strong preference on the stacks. From my perspective you could lump them all into one stack and I'd be happy with that. As long as we don't slow down important bug fixes for one component
<RAOF> tvoss_: Good morning.
<robert_ancell> I have to go, but I'll be back in 2.5-3 hours
<didrocks> robert_ancell: it doesn't slow down anything as long as any of them FTBFS or fail tests :)
<didrocks> robert_ancell: ok, I'll send you about the integration tests then
<robert_ancell> ta
<tvoss> robert_ancell, duflu what are the remaining open vt bugs?
<duflu> tvoss: Might be inaccurate, but https://bugs.launchpad.net/mir/+bugs?field.tag=vt
<duflu> I think the medium one is actually the most annoying right now
<tvoss> duflu, hmmm, I think that's the one making it difficult to fallback easily
<duflu> tvoss: Well not having a terminal to log in to is a risk too
<tvoss> duflu, that's what I mean
<duflu> Right. So "expert fallback" = terminal. As opposed to fallback mode, which is X (when it works?)
<tvoss> duflu, right
<tvoss> duflu, that's what I mean
<duflu> alf: Good morning. Bad news... https://bugs.launchpad.net/bugs/1195105
<ubot5> Launchpad bug 1195105 in Mir "[regression] mir_demo_standalone_render_surfaces no longer works (blank green screen)" [Medium,New]
<alf> duflu: Yeah, I saw that late yesterday, but thankfully it's a simple fix
<duflu> alf: Cool. You saw it before the bug was logged?
<alf> duflu: assigned it to myself
<alf> duflu: (disconnected, may have lost some messages)
<duflu> alf: No nothing missed. Thanks. What's the cause?
<alf> duflu: Surface::flag_for_render() internals changed, so now one call to it is not enough to mark the surface as valid for rendering.
<alf> duflu: if you need a temporary workaround just call it twice in render_surfaces
<duflu> Oh. Server internals...
<tvoss> RAOF, https://github.com/whot/libevdev
<RAOF> Yah.
<RAOF> Also in my G+ stream :)
 * RAOF still needs to check about the libsynaptics situation.
<RAOF> I don't think we're _particularly_ interested in libevdev, right? The Android stack already handles that.
<RAOF> But we *are* interested in having touchpad support âº
<RAOF> Man, I wish C++ had a builtin string class.
<RAOF> Strike that; I wish it had a builtin string *type*.
<duflu> RAOF: You're asking for the C++ spec to grow further? :)
<RAOF> Actually I'm basically asking for typeof("foo") == std::string.
<RAOF> :)
<duflu> RAOF: You can go: char foo[] = "foo"; int len = sizeof(foo) - 1;  :)
<duflu> What more can you want from a string? ;)
<mlankhorst> utf-8
<duflu> mlankhorst: Yeah fair point
<duflu> Though unicode is easier to deal with most of the time... wchat_t foo[] = L"foo";
<duflu> *wchar_t
<RAOF> wcat_t whiskers[]!
<duflu> int longcat = (sizeof(whiskers) / sizeof(whiskers[0])) - 1
<RAOF> Peppa pig!
<didrocks> robert_ancell: once you are back: https://code.launchpad.net/~didrocks/lightdm/packaging-cleanup/+merge/171722
<duflu> Ah, wchar_t can still be multibyte. But C++11 also has char32_t to rule them all
<duflu> (except longcat who cannot be ruled)
<tvoss> robert_ancell, hey there :) searching for the command line that invokes usc from lightdm
<RAOF> src/seat-unity.c is what you want to be looking in.
<tvoss> RAOF, that's lightdm, right?
<RAOF> Right.
<seb128> RAOF, hey
<RAOF> seb128: Ho!
<seb128> RAOF, how are you?
<RAOF> I'm well. Hows about you?
<seb128> I'm good thanks
<seb128> RAOF, quick question for your ... did you guy test the new xorg which is getting ready for upload in saucy? does it has an possible impact on XMir or on work you are doing?
<seb128> it seems like that stack is mostly ready for landing in saucy
<seb128> but I want to make sure it's not going to create issues for you guys first
<RAOF> It shouldn't, although I should check whether the input ABI changed.
<seb128> RAOF, can you check tomorrow and give us a ack/nack?
<mlankhorst> RAOF: just some repacking
<RAOF> mlankhorst: Urgh, again?
<mlankhorst> yeah someone loves their bitfields
<RAOF> Ok. So I'll need to throw xf86-input-* into the Mir PPA until that's moved to 1.14.
<mlankhorst> but a rebuild is enough for that
<RAOF> Right
<RAOF> Or, I guess, move xserver in the Mir PPA to 1.14; that should be fast.
<mlankhorst> indeed :p
<mlankhorst> and then just bump the video drivers to rebuild them
<RAOF> Exactly.
<RAOF> mlankhorst: I guess xf86-input-* built against 1.14 are in a PPA somewhere, right?
 * duflu wonders how the Apple Magic Trackpad would go with Mir
<mlankhorst> RAOF: canonical-x/x-staging is whats going to land
<RAOF> duflu: Reasonably, but no tap-to-click etc.
<RAOF> mlankhorst: Ta.
<duflu> RAOF: I mean Mir android input, not X
<RAOF> duflu: So did I.
<duflu> Oh
<duflu> I recall trying it on a Honeycomb tablet a while ago. Kind of worked...
<RAOF> seb128: I'll move our PPA on to 1.14 tomorrow and give you the goahead.
<seb128> RAOF, thanks
<robert_ancell> RAOF, I put a work item for the 1.14 update in https://blueprints.launchpad.net/ubuntu/+spec/client-1303-mir-system-compositor
<tvoss> robert_ancell, hey, looking at src/seat-unity.c. I would like to add options to enable reporting of the different mir components
<tvoss> robert_ancell, question is: how do I access the settings as read from the per-seat config file?
<robert_ancell> tvoss, not 100% sure what you mean, but you just need to call seat_get_*_property to get a property of a seat as set in the config
<tvoss> robert_ancell, ah cool, so the usc executable has command line options to enable logging of internal operations, either to a log file or to lttng
<tvoss> robert_ancell, for debugging purposes, it would be great if we could enable that functionality via the unity-seat config file, passing over the cl options to usc
<robert_ancell> tvoss, I added "unity-compositor-command" which you can set to "unity-system-compositor --do-blah-blah-blah" to do stuff like that temporarily
<tvoss> robert_ancell, ah cool, even better then :)
<robert_ancell> tvoss, Ideally we should just set u-s-c to log stuff to stderr by default so we have baseline debugging
<tvoss> robert_ancell, and stderr ends up in the usc.log, right?
<robert_ancell> tvoss, ack
<tvoss> robert_ancell, so something like unity-compositor-command="unity-system-compositor --glog --glog-stderrthreshold=0 --display_report_opt=log"
<tvoss> in 10-unity-... .conf should work ...
<robert_ancell> tvoss, yes
<tvoss> robert_ancell, cool, trying now :)
<didrocks> robert_ancell: so, I guess before daily releasing mir and unity-greeter to a PPA (so not blocking on integration tests nor the duplicated libraries in Mir), I just need your lightdm review, did I miss anything?
<didrocks> robert_ancell: then, we can continue discussing with jibel if needed to clear up how to do the integration tests
<robert_ancell> alf, I think the link is too flaky :(
<robert_ancell> didrocks, otp, I'll get back to you.. which is the review? I thought I just did them all
<didrocks> robert_ancell: https://code.launchpad.net/~didrocks/lightdm/packaging-cleanup/+merge/171722
<didrocks> robert_ancell: fresh new one! :)
<tvoss> RAOF, ping
<RAOF> tvoss: pongity pong.
<tvoss> robert_ancell, adding the command line makes the server not start, executable not found
<robert_ancell> tvoss, can you paste me your config?
<robert_ancell> tvoss, there is a nice regression test that tests this case, so it *should* work...
<robert_ancell> didrocks, approved
<didrocks> robert_ancell: thanks! I'm prepping the daily release machinery through the next ppa then!
<robert_ancell> didrocks, I take it the man page change was intentional?
<robert_ancell> You probably know groff better than me :)
<didrocks> robert_ancell: yeah, it was an empty stenza (I saw it through lintian TBH :p)
<tvoss> robert_ancell, unity-compositor-command="unity-system-compositor --glog --glog-stderrthreshold=0 --display_report_opt=log"
<robert_ancell> hah! Your secret is out!
<tvoss> I tried without ", too
<didrocks> it is :)
<robert_ancell> tvoss, no quotes
<tvoss> robert_ancell, tried that, without luck :/
<robert_ancell> tvoss, can I see the lightdm.log?
<didrocks> robert_ancell: tell jibel and I when you want to discuss integration testing, we can do that at a time not too late for you :)
<robert_ancell> didrocks, will do
<tvoss> robert_ancell, don't have it handy, but it said that it tries to invoke the command line and then command not found
<robert_ancell> didrocks, I still can't see where the tests are for unity - can you point me at what files actually do the tests?
<didrocks> robert_ancell: lp:unity tests/autopilot/unity/*
<robert_ancell> didrocks, ta
<didrocks> yw :)
<robert_ancell> tvoss, hmf. I'll try here
<tvoss> that was fast
<robert_ancell> tvoss, works for me - config http://paste.ubuntu.com/5804162/, lightdm log http://paste.ubuntu.com/5804163/
<tvoss> robert_ancell, cool, sorry for the noise then :) mind pasting the usc.log, too?
<robert_ancell> tvoss, there's nothing new in it, but I didn't set --display_report_opt=log - does it need that?
<tvoss> robert_ancell, yup, that allows us to log anything going on with vt's inside the gbm module
<tvoss> iirc
<robert_ancell> tvoss, brb
<tvoss> robert_ancell, win?
<robert_ancell> tvoss, you gave me an invalid command line :)
<robert_ancell> unity-compositor-command=unity-system-compositor --glog --glog-stderrthreshold=0 --display-report=log
<robert_ancell> works
<tvoss> ups :)
<robert_ancell> log output - http://paste.ubuntu.com/5804187/
<robert_ancell> then my VTs went crazy so I was sshing from my phone - real pain to try and type on those keyboards :)
<tvoss> yeah
<robert_ancell> tvoss, that what you expected to see?
<tvoss> looks good, trying to tune the output to get information back to us in case of issues
<tvoss> robert_ancell,
<tvoss> robert_ancell, ^
<robert_ancell> yep, we should have this stuff on by default
<tvoss> robert_ancell, do you think we should enable it in the ppa by default?
<robert_ancell> tvoss, yes, change the defaults in u-s-c to log things that wont affect performance by default
<tvoss> robert_ancell, yup, I think we want display reporting enabled, including info. We can lower that over time
<robert_ancell> yep
<robert_ancell> tvoss, bug 1195227
<ubot5> bug 1195227 in Unity System Compositor "Turn on logging by default" [Medium,Triaged] https://launchpad.net/bugs/1195227
<tvoss> robert_ancell, thx
<didrocks>  ah, mir trunk FTBFS on the ppa
<didrocks> https://launchpadlibrarian.net/143539491/buildlog_ubuntu-saucy-i386.mir_0.0.6%2B13.10.20130627ubuntu.unity.next-0ubuntu1_FAILEDTOBUILD.txt.gz
<didrocks> hum, hard to read with -j8
<didrocks> (can be the parallel build making it failing as well)
<tvoss> didrocks, yup
<didrocks> tvoss: did you see anything else than parallel build which can be the cause here? I don't see any hint in the trace :/
<seb128> didrocks, the error seems to be "cp: cannot create regular file '/build/buildd/mir-0.0.6+13.10.20130627ubuntu.unity.next/obj-i686-linux-gnu/doc/html/cppguide/styleguide.css': No such file or directory"
<didrocks> seb128: waow, you have good eyes, couldn't see that one :p
<tvoss> seb128, o/
<seb128> ;-)
<seb128> tvoss, hey ;-)
<seb128> /usr/bin/cmake -E cmake_progress_report /build/buildd/mir-0.0.6+13.10.20130627ubuntu.unity.next/obj-i686-linux-gnu/CMakeFiles
<seb128> Generating ../doc/html/cppguide/styleguide.css
<seb128> cp /build/buildd/mir-0.0.6+13.10.20130627ubuntu.unity.next/guides/styleguide.css
<seb128>  
<seb128> seems to have a path mismatch there
<didrocks> indeed
 * seb128 let you guys debug the build system ;-)
<didrocks> passing on other archs, I think it's a --parallel mismatch, I'll disable it for now unless some cmake gurus wants to ensure that it works, tvoss, do you know if Satoris would be interested?
<tvoss> didrocks, might be :)
<katie> tvoss, mpt do we have anything to discuss today?
<katie> tvoss, everything on my list was covered yesterday
<didrocks> tvoss: seb128: it passed with this rebuild FYI
<seb128> didrocks, ok, so some sort of race in the build system
<didrocks> yep, let's see once Satoris is around
<tvoss> katie, likewise :)
 * duflu -> dinner
<tvoss> katie, ping
<tvoss> hah!
<katie> tvoss, pong
<didrocks> tvoss: ah, more annoying tests failed on powerpc: https://launchpadlibrarian.net/143542002/buildlog_ubuntu-saucy-powerpc.mir_0.0.6%2B13.10.20130627ubuntu.unity.next-0ubuntu1_FAILEDTOBUILD.txt.gz
<didrocks> tvoss: do you mind having a look?
<tvoss> didrocks, C++ exception with description "GLPixelBuffer doesn't support big endian architectures" thrown in the test body.
<didrocks> tvoss: so this test should be disable on powerpc I guess
<didrocks> or we can declare no Mir on powerpc, but that will make the inclusion by default difficultâ¦
<tvoss> didrocks, can you file a bug please?
<didrocks> tvoss: sure
<didrocks> tvoss: https://bugs.launchpad.net/mir/+bug/1195260
<ubot5> Launchpad bug 1195260 in Mir "Mir tests failed on powerpc" [Undecided,New]
<didrocks> tvoss: other tests failure on armhf: https://launchpadlibrarian.net/143544949/buildlog_ubuntu-saucy-armhf.mir_0.0.6%2B13.10.20130627ubuntu.unity.next-0ubuntu1_FAILEDTOBUILD.txt.gz
 * didrocks opens a bug
<didrocks> it seems no valgrind?
<tvoss> didrocks, why is this passing in the ppa?
<didrocks> tvoss: passing?
<tvoss> didrocks, building
<didrocks> tvoss: daily release?
<didrocks> as it's our goal
<didrocks> and as we don't have integration tests for everything yet, we are using the next ppa first
<didrocks> (and rightly as we need to settle down those issues first)
<didrocks> tvoss: https://bugs.launchpad.net/mir/+bug/1195265 FYI
<ubot5> Launchpad bug 1195265 in Mir "no valgrind makes tests failing on armhf" [Undecided,New]
<tvoss> didrocks, quick check: isn't valgrind in the build-deps?
<didrocks> tvoss: no, I just added it and dput to the ppa
<tvoss> didrocks, thx
<didrocks> for a test build
<didrocks> tvoss: I wonder what is pulling it for the other archs TBH
<didrocks> but anyway, it's needed to be in the build-dep :p
<didrocks> will see this build result
 * 6JTAAX1W6 is incognite
<tvoss> not anymore :)
<cprofitt> hello all
<didrocks> tvoss: do you have a minute? I think we need to check with the launchpad guys. It seems to me that the armhf build is blocked: https://launchpad.net/~ubuntu-unity/+archive/daily-build-next/+build/4751091
<didrocks> (it's like that for 15 minutes)
<didrocks> seems it's taking 0.04 sec on amd64 to pass :p
<tvoss> alf, ping
<alf> tvoss: pong
<tvoss> alf, pm
<kdub> good morning
<hikiko> ssh: Could not resolve hostname bazaar.launchpad.net: No such file or directory
<hikiko> i am getting this error :s
<hikiko> does anyone has problems to push?
<hikiko> fixed
<kdub> reviews piling up!
<racarr> Howdy
<tvoss_> racarr, hey there :)
<tvoss_> how goes?
<tvoss_> kdub, you should have edit rights btw
<kdub> ah, thanks
<racarr> tvoss_: Root canalled about 20 minutes ago
<racarr> so it goes pretty...ow
<racarr> im assuming as some point thoughts will resume
<tvoss_> man, root canal is ouch
<racarr> tvoss_: S'ok. I'll distract myself XD
<racarr> How goes on your end?
<tvoss_> racarr, pretty good, got some stuff to finish for end of month
<tvoss_> racarr, but all good
<tvoss_> racarr, preparing some vegetarian chili :)
<racarr> I should try making that...
<greyback> racarr: owww, root canal, nasty
<racarr> it really is pretty nasty business. I considered just waiting it out until little nano robots could clean my teeth with lasers
<racarr> :p
<racarr> greyback: How goes?
<greyback> racarr: fine. No real time for Mir stuff today. But tomorrow will
<greyback> be on it fully
<greyback> racarr: any update for me?
<racarr> greyback: Not really. will finish the session stuff today
<racarr>  land my other branches
<racarr> err, session authorier stuff
<racarr> I realized today
<greyback> racarr: ok cool. Yep I'd like to see that
<racarr> missed the sync up with Katie.
<racarr> but you should start talking to Katie
<racarr> she did the surface management design
<racarr> and there is lots there, including functional tests (some of which are in mir now)
<greyback> racarr: yep, I've been reading her documents recently
<racarr> which hypothetically one day should run on
<racarr> unity/mir and that would be
<racarr> awesome
<greyback> +1
<greyback> where are the functional tests?
<racarr> letsseee
<racarr> on a page that crashes firefox
<racarr> *waits*
<racarr> greyback: https://docs.google.com/a/canonical.com/document/d/1GtXBxUo1M2ya5-6Um-pJ2bhLM-tXYMXDaZvEgr6edMg/edit
<racarr> I guess they might be out of date to some of the recent
<racarr> design refactoring
<racarr> XD
<greyback> racarr: then we'd best get them updated. These look very useful, and I'll automate them asap
<racarr> there is
<racarr> some cucumber code hanging around in mir...weeeeeeeeeeeeeeeeeeeeee
<racarr> yeah
<racarr> we should both talk to katie next week
<racarr> and then figure out how to get some of them running on unity/mir combined
<greyback> racarr: cucumber? When did ppl start using that?
<greyback> +1
<racarr> greyback: Me and Katie did! in december
<racarr> :p
<racarr> Katie and I *italics*
<racarr> uh
<greyback> stop taking all the credit :)
<greyback> I'm not a big fan of the abstraction of cucumber in general, but for specific use-cases it will do I guess
<greyback> it does make it easier for non-coders to write tests for us
<racarr> I have
<racarr> mixed opinions
<racarr> Cucumber definitely isn't ideal
<racarr> lots of sort of things are difficult to express
<racarr> I havent thought about cucumber in probably 2 months so it's a little difficult to recall exactly which ones :p
<greyback> :)
<greyback> no worries, I was just curious
<greyback> racarr: It's well past my EOD, gotta go
<greyback> hope you have plenty of pain-killers and have a nice easy day :)
<racarr> cya
<thomi> morning all
<racarr> Morning
<bregma> racarr, regarding #1194075 (the, uh, embedded cucumber problem), would be be possible to just rewrite the session_manager_steps.cpp tests to use GTest directly instead, so we could simply drop the cucumber?
<bschaefer> while running xmir, is anyone noticing ~20-30 seconds where everything hangs? Usually brought on by compiling...but sometimes not
<racarr> bregma: There are grand plans for cucumber I guess, the single tet could be rewritten but there is not much point
<racarr> if it is actually blocking anyone I think just remove it from the tree
<bregma> racarr, it's blocking landing in Ubuntu
<racarr> Really?
<racarr> Why can't we land in ubuntu with cucumber-cpp embedded
<racarr> as long as we are following the licensing
<racarr> kdub: Ok I see it is failing, will look around for a bit
<kdub> thanks
<racarr> kdub: Why all this file synchronization stuff
<racarr> isn't it satisfied by
<racarr> InputTestingServerConfiguration::wait_until_client_appearas
<racarr> ?
<kdub> well, that will look on the server side for the client creation
<kdub> but we need to wait until after the client has registered its handler
<racarr> no
<racarr> you can register the handler in the connected callback
<racarr> and the client input thread wont be started until after this finishes
<racarr> the server will send the first event over the pipe, and wait for this to happen before sending any more
<racarr> the thing is the way the handler is being registered now
<racarr> the thread can be started and read an event
<racarr> before the handler is registered, so it just discards it
<racarr> the problem in this test though is on the server side (
<racarr> :(
<racarr> you can see with MIR_SERVER_LEGACY_INPUT_REPORT=log
<kdub> ah... all these secret switches :)
<racarr> well they are in --help to be fair :p
<kdub> haha, yeah
<kdub> well, its somewhere to start then
<racarr> kdub: Is it possible
<racarr> I am still trying to sort out what has happened all in all
<racarr> perhaps because of the way size comes from the buffer stream
<racarr> something has changed there?
<racarr> I dunno...it says it is dropping the vent because there is no touched window (you can see this in InputDispatcher.cpp)
<racarr> but it looks like ms::SurfaceStack::for_each basically works the same way
<racarr> so that it m ust have to do with the handles
<racarr> when I say must I mean maybe
<kdub> hmm, ok
<kdub> new places to look at least :)
<racarr> kdub: ill research some more too
 * robert_ancell -> breakfast
<racarr> robert_ancell: ok. 1-1 later?
<kgunn> racarr: how you feelin' ?
<robert_ancell> racarr, sorry, can do now
<racarr> kgunn: Not so bad :)
<kgunn> racarr: glad to hear it....ironically...my daughter is on the couch, post wisdom teeth removal (she had 6...and yes...the more you have the more you pay)
<robert_ancell> racarr, lp:~robert-ancell/unity-system-compositor/keyboard
<kdub> racarr, any insights on that branch?  i've gotten lost in the input stack
<racarr> kgunn: Oww
<racarr> kdub: Not yet -.-
<kdub> racarr, thanks for looking.. . happily I did this in git, so I'll just bisect until I see what happened
<xnox> Are you interested in dual-screen bugs where output is not mirrored across dvi and hdmi and there are significant differences?
<xnox> also it seems like software rendering + xmir + unity, is faster than hw accel + xmir + unity.
<RAOF> xnox: I'm interested in hearing how you can get into a situation where output is not mirrored!
<thomi> RAOF: got a second?
<thomi> RAOF: I have some more information regarding my xmir i915 issue
<RAOF> Oooh.
<RAOF> I therefore have a second.
<thomi> RAOF: http://paste.ubuntu.com/5806320/
<thomi> that's dmesg
<thomi> look at thge last 3 lines
<thomi> the contents of that file in /sys coming up....
<thomi> RAOF: http://paste.ubuntu.com/5806322/
<RAOF> Right. We've hung the GPU, possibly because of the plymouth segv, possibly *causing* the plymouth segv
<thomi> Talk to me like I'm stupid - what's plymouth?
<RAOF> The boot splash, input multiplexer thing.
<thomi> ahh ok
<thomi> anything else I can grab for you while i'm logged in?
<RAOF> thomi: /var/log/lightdm/* would be nice.
<thomi> lightdm.log: http://paste.ubuntu.com/5806327/
<thomi> u-s-c log: http://paste.ubuntu.com/5806328/
<thomi> RAOF: are the x-* logs of any use?
<RAOF> Not really, no.
<thomi> ok
<thomi> I scanned them and didn't see anything that stood out
<RAOF> Failed to set the current VT mode?
<RAOF> robert_ancell: Hey, how would you feel about using CLOCK_MONOTONIC timestamps in the lightdm logs?
#ubuntu-mir 2013-06-28
<robert_ancell> RAOF, sounds fine - is there some time skew?
<RAOF> robert_ancell: No, but it would make correlating debugging messages much easier when dmesg, Xorg.0.log, and lightdm.log all had the same timestamps.
<robert_ancell> oh, right
<RAOF> Rather than [ +time_since_lightdm_start s] :)
<robert_ancell> yep
<RAOF> thomi: So, I'd try booting, but hitting <esc> when you see the boot splash so it goes into text mode, and see if that boots correctly to xmir.
 * thomi tries that
<thomi> RAOF: nope, It still hangs. The last boot line is something about 'startpar bridge'
<thomi> brb, gotta get more caffeine in me
<RAOF> :)
<thomi> that's better
<thomi> RAOF: so, anything I can do to try and get this working?
<RAOF> thomi: Could you try booting without plymouth splash all together? That would be removing the âquiet splashâ line from the grub boot entry.
<RAOF> thomi: Also, does this only apply at boot? If you boot successfully without XMir, change your lightdm config, and run âsudo restart lightdmâ do you get the same crash?
<thomi> RAOF: I'll try the first thing now. I don't know about the second thing, something to try later perhaps
<thomi> turning off the boot splash all together makes no difference
<thomi> RAOF: also, I get the same crash if I boot normally, enable u-s-c and then restart lightdm
<thomi> RAOF: what should i do next?
<RAOF> Ok. So, we're doing something stupid then.
<RAOF> Or maybe I just need to take a newer mesa snapshot :)
<RAOF> thomi: Do the Mir demos render correctly?
<thomi> I haven't tried them in a while, let me check
<thomi> RAOF: yes, they work perfectly
<RAOF> Hm. Maybe xf86-video-intel damage then?
<thomi> anything I can do to test that hypothesis?
<RAOF> Heh.
<RAOF> Second commit after our Mesa snapshot: Revert "i965: Disable unused pipeline stages once at startup on Gen7+."
<RAOF> Apparently causes GPU hangs.
<thomi> O.0
<RAOF> thomi: Allow me to cut a new mesa snapshot :)
<thomi> yeah, thanks
<thomi> I need to pick my girlfriend up from the airport, so maybe that'll be ready by the time I get back
<RAOF> Hm. The jenkins mesa job doesn't seem to have worked.
<NikTh> Hello everyone
<NikTh> I've just installed 13.10 and I tested Xmir.. (I'm on Xmir now) , pretty good, no major differences , except of the two mouse pointers (LoL).
<thomi> RAOF: no new mesa yet?
<thomi> NikTh: good!
<RAOF> thomi: The jenkins mesa job seems to have failed?
 * thomi looks
<NikTh> I want to ask, is this valid ? (true?) , can be applied in 13.10 ?  I mean the "Run Mir Natively" -> http://unity.ubuntu.com/mir/using_mir_on_pc.html
<RAOF> NikTh: Oh, yes.
<NikTh> RAOF,  please explain .. I want to test this, no matter if I brake the system down :P
<RAOF> Yes, those instructions should work.
<thomi> RAOF: it looks to me like it has not run yet. Is https://github.com/RAOF/mesa.git the correct repo? with the mir-ppa branch?
<RAOF> thomi: Correct.
<NikTh> The commands maybe are only examples or something, because their not exist. :(
<thomi> hmm, the git polling is set to @hourly
<thomi> NikTh: those commands are now in /usr/lib/x86_64-linux-gnu/mir/examples
<thomi> NikTh: or whatever your platform string is :)
<NikTh> Thanks thomi . Thanks. :)
<RAOF> Ah. Documentation update time!
<NikTh> I will test it right now :)
<bschaefer> any reason im getting this with the mir ppa?
<bschaefer> unity-system-compositor : Depends: libmirserver0 (= 0.0.6bzr785saucy0) but 0.0.6bzr786saucy0 is to be installed
<bschaefer> :( no lightdm
<NikTh> thomi,  what client you suggest ? mir demo client or mir demo client accelerated as first hit .
<NikTh> thomi, OK. No worries. I will test it either way. :)
<RAOF> bschaefer: Because unity-system-compositor hasn't been rebuilt against the latest mir (and it requires it because we're making no attempt at a stable mirserver ABI at this point)
<NikTh> Thanks again
<RAOF> bschaefer: This is why we provide the system-compositor-testing PPA :)
<bschaefer> RAOF, i see :), well no worries, I can just force start X for now
 * bschaefer hopes its built by tomorrow morning
<RAOF> It probably will be, but there'll also likely be a new mir to break things again.
<bschaefer> RAOF, o yeah, i also wanted to point you to this stack trace I got yesterday from Xorg.log
<bschaefer> http://paste.ubuntu.com/5802840/
<bschaefer> while running Xmir
<RAOF> Install from system-compositor-testing âº
<RAOF> bschaefer: Looks like Mir has hung?
<bschaefer> RAOF, yeah, I might as well do that at this point :)
<bschaefer> RAOF, yeah, it ended up crashing X though
<RAOF> No, I don't think it did crash X.
<RAOF> Oh! mir_wait_for did eventually return.
<RAOF> Odd.
<bschaefer> RAOF, hm, as a giant error box with that stacktrace appeared, and it didn't seem like X was running
<RAOF> Those backtraces are "whoops, something's blocking the event loop and we're still getting input events"
<RAOF> Your log ends with [   373.614] Server terminated successfully (0). Closing log file.
<RAOF> :)
<RAOF> Something decided to shutdown X, and it did.
<bschaefer> RAOF, well it shut it down nicely :)
<bschaefer> hopefully it isn't a recurring problem! also thanks again for pointing me to that other ppa :)
<RAOF> But there certainly is a bug in there - mir_wait_for shouldn't be blocking the mainloop for so long.
<bschaefer> RAOF, are there any mir logging that would give more info?
<bschaefer> or look at running mir trunk from through gdb to get a better stracktrace if it were to happen again?
<RAOF> bschaefer: I think you can pass --msg-processor-report=log through to unity-system-compositor by editing /etc/lightdm/lightdm.conf.d/10-unity-system-compositor.conf (and adding a unity-compositor-command=unity-system-compositor --msg-processor-report=log key)
 * duflu hopes it's not due to https://bugs.launchpad.net/mir/+bug/1194384
<ubot5> Launchpad bug 1194384 in Mir "Mir client callbacks are not thread-safe" [Medium,In progress]
<RAOF> That should dump a bunch of info relating to IPC.
<bschaefer> RAOF, sweet, ill give that try
<bschaefer> thanks
<bschaefer> duflu, also hello! how was your vacation?
<duflu> bschaefer, was good thanks
<duflu> But I've been back a few weeks
<duflu> So all is "normal" again
<bschaefer> duflu, nice, thats good
<bschaefer> I also see you merge the cursor change :), though Im starting to miss that large orange one haha
<duflu> bschaefer: We can make it anything within 64x64. I suspect we will need an API for changing it too
<bschaefer> duflu, in due time, but that API will be needed at some point :)
<NikTh> I'm back :)
<NikTh> Except mir_demo_client (connection released = nothing happened) and  mir_demo_client_unaccelerated (got stuck) , all other demos ran smoothly. Most FPS = 457 = mir_demo_client_egltriangle. Most amazing =mir_demo_client_eglplasma !
<NikTh> Keep up the good work guys and thank you again for the help :-)
<duflu> NikTh, mir_demo_client actually does nothing by design. How did the unaccelerated one get stuck?
<duflu> NikTh, did you say some client reported 457 FPS? That shouldn't happen right now
<duflu> RAOF ^
<NikTh> duflu, don't know. Just a black screen on mir VT and could not change VT. I rebooted with SysRq. Yes the   mir_demo_client_egltriangle reported almost 457 FPS, but decreased as let it running.
<duflu> NikTh, interesting. Normally it freezes (lower FPS) when a Mir client is not focussed. That shouldn't happen..
<NikTh> duflu, do you want me to record this with an external camera and upload it.. ? (if happens again of course :P )
<duflu> NikTh, that would be great if you could. Just log all bugs at: https://bugs.launchpad.net/mir/+filebug
<NikTh> duflu, is this a bug really ? I thought more FPS are better :P (don't know technical stuff)
<duflu> NikTh: Yes, when something's not in use, it should idle to zero FPS. Also technically, those demos are set to sync to the monitor's refresh rate (make 60 usually)
<NikTh> I think 1 FPS was the mir_demo_client_accelerated only. All other demos was above.. 250 FPS or so.
<NikTh> I will test it again.. and I will try to record it this time. Thanks duflu  :)
<duflu> NikTh, no problem. I think I need to test it for myself again..
<Nikth2> duflu, last question before I leave. Does it matter that when I tested mir natively I was in Xmir on VT7  ?  Perhaps  I  had to run  X only ?
<duflu> Nikth2, yes it could matter. AFAIK you can only have one Mir server running at the moment. And if that was XMir that your native clients were rendering to, then that's something we haven't tested much of
<duflu> Nikth2, to run a basic Mir server you need to disable XMir first
<robert_ancell> duflu, damn, you moved a bug to milestone 0.0.6, but I can't move it back to 0.0.5...
<Nikth2> duflu, OK. I think I got it now.  Thank you.
<duflu> robert_ancell, no problem. Just unlock 0.0.5, fix the bug and relock. I've done it many times. But I think 0.0.6 is correct
<duflu> robert_ancell: Any bug in progress already missed 0.0.5. Hence it's targeted for 0.0.6
<duflu> Right?
<robert_ancell> duflu, it was re-opened, but I'm closing it again and using a new bug for 0.0.6
<duflu> Ah
<duflu> robert_ancell, is it really a different bug?
<duflu> I generally say reopen the old one unless an explicit fix was committed and tested
<robert_ancell> duflu, well, the first bug didn't have detailed information, so it's just confusing - the new bug has a particular symptom
<duflu> robert_ancell: If the old one lacked info, it should either be enhanced or marked incomplete. But not fixed
<robert_ancell> duflu, changes were made that fixed the bug "black screen" for some people, thus it is fixed.
<duflu> I haven't retested staging with system compositor to verify it properly
<duflu> Bah, that's enough time spent arguing
<robert_ancell> duflu, ok, if you still have the problem note it in bug 1195509, or file a new bug with the reason for the failure from the logs
<ubot5> bug 1195509 in Unity System Compositor "System compositor fails to start - Failed to set the current VT mode: Input/output error (5)" [Critical,Triaged] https://launchpad.net/bugs/1195509
<duflu> robert_ancell, I wasn't getting any logs. You expect that situation is better now?
<robert_ancell> duflu, yes
<duflu> cool
<thomi> RAOF: presumably I need to copy the new mesa package into the s-c-testing PPA, right?
<RAOF> thomi: Yes, please.
<thomi> ok, they're building now
<robert_ancell> RAOF, does X handle alt+ctrl+Fn?
<RAOF> robert_ancell: I don't *think* so? Let me check.
<robert_ancell> RAOF, normal X must right?
<RAOF> Not necessarily?
<robert_ancell> I'm just wondering if we need u-s-c to handle any key events at all
<robert_ancell> How else would you switch to VT1
<RAOF> By the kernel handling ctrl-alt-F1, sending X signal saying "I'd like to VT switch", and X replying "sure, go ahead"
<robert_ancell> Really?
<duflu> RAOF: If it's not X then why is the combo different when inside X?
<duflu> Outside of X, you don't need Ctrl
 * robert_ancell -> EOD
<robert_ancell> RAOF, I'll ask you next week :)
<RAOF> Sure!
<RAOF> duflu: Possibly because of X setting the VT mode?
<duflu> RAOF: You're saying X lets something outside of X handle Ctrl+Alt+Fn?
<RAOF> So far I've not been able to find something *inside* X which handles it.
<thomi> RAOF: new mesa built & published for amd64. going to reboot now
 * thomi crosses fingers
<RAOF> Good lucjk!
<thomi> RAOF: :(
<thomi> RAOF: still crashes when booting with u-s-c enabled. Trying a normal boot now
<thomi> RAOF: OK, that works!
<thomi> so, as long as I don't reboot, I'm fine :-/
<RAOF> thomi: So u-s-c works after boot, but not if you boot to it?
<thomi> RAOF: correct
<RAOF> Ok. Have you tried the various "not splash" options of a direct boot?
<thomi> no, I'll try that next
<thomi> running some perf benchmarks at the moment
<RAOF> Cool.
<thomi> RAOF: with the splash screen turned off I get the same hang as before
<RAOF> Ok, some additional crazy on boot, then.
<thomi> yeah
<RAOF> Plausibly I should pull in a newer xf86-video-intel :)
<thomi> go on, do it! :)
<RAOF> Also plausibly switching to SNA...
<RAOF> Hm, no relevant commits to xf86-video-intel.
<RAOF> Mainly because upstream cares only for sna now :/
<thomi> what's sna?
<RAOF> The new acceleration architecture.
<thomi> RAOF: so, what should I do from here?
<RAOF> thomi: It's exactly the same hang? ie: you still have dmesg with an intel gpu hang in it, unity-system-compositor logs "can't set VT mode", etc?
<thomi> RAOF: hmm, the dmesg message is gone, but the u-s-c message is the same
<thomi> u-s-c log is: http://paste.ubuntu.com/5806808/
<RAOF> Ok. So, we've replaced your hang with a different problem; can you VT switch once it's failed to boot?
<thomi> RAOF: nope
<thomi> RAOF: It hasn't even blanked the screen, I see the boot messages still
<RAOF> Hm. If you wait a bit, does the gpu hang message appear in dmesg?
<RAOF> I didn't think we'd be able to get the system into a state where the GPU wasn't hung but you can't VT switch.
<thomi> RAOF: I can't see it - I'm looking at 'dmesg | grep intel' - there are a few messages, but nothing that looks like an error
<RAOF> Hrm.
<RAOF> Can you ssh in and start lightdm?L
<thomi> RAOF: it says lightdm is already running
<thomi> trying to restart lightdm
<tvoss_> good morning all :)
<RAOF> Morning tvoss_!
<thomi> RAOF: when I restart lightdm, it works fine
<thomi> hi tvoss_
<tvoss_> hey guys, how goes?
<thomi> RAOF: so it seems to be a problem with the initial boot only
<RAOF> thomi: Right. This has gone from "I lock your GPU! HAAHAHAHAHAHAAH!"
<RAOF> To "we're still racing with plymouth somewhere, sigh"
<thomi> tvoss_: found some problems with xmir on intel, but slowly fxing them
<thomi> RAOF: yeah
<thomi> RAOF: I might try rebooting a few times to see if it alway fails on boot, or only sometimes
<tvoss_> thomi, problems? a little more detail would help :)
<thomi> RAOF: initially we were hanging the GPU, but an updated mesa fixed that issue. Now there seems to be a race with plymouth where, upon initial boot, you don't get a lightdm, and can't VT switch
<RAOF> tvoss_: Oh, btw I'm pretty sure we can use umockdev for our tests, too.
<thomi> oops, I mean tvoss_ ^^
<tvoss_> thomi, fix it :) if we can get of the gpu hangs, I have hardly any issues with mir on intel
<tvoss_> RAOF, umockdev as in the google version?
<RAOF> tvoss_: As in pitti version.
<RAOF> The google version didn't seem to be super fleshed out.
<tvoss_> RAOF, yeah, came to the same conclusion, it's really only a test helper
<tvoss_> RAOF, thomi is umockdev integrated with autopilot?
<thomi> tvoss_: no
<RAOF> I don't think we'd need to?
<RAOF> We can use it in perfectly normal gtest test cases.
<RAOF> All we need to do is LD_PRELOAD the appropriate library, and it turns out that I've already written code to add that to our test suite.
<tvoss_> RAOF, ah, that's cool :) some tiny wrapper would make me even happier, though :)
<RAOF> What do you mean by a tiny wrapper? Do you mean wrapping the umockdev API up in a class?
<RAOF> That would be a wrapper so tiny that I'd feel it was superfluous :)
<tvoss_> RAOF, then just use it I would say :)
<tvoss_> thomi, RAOF I would think that we should extend the reporting for the LinuxVirtualTerminal implementation
<tvoss_> we will enable reporting for the core components to stderr and thus to the lightdm unity-system-compositor.log
<RAOF> Yeah, that'd be good.
<thomi> tvoss_: sounds good to me
<thomi> I gotta go help with dinner - will be back later
<didrocks> waow, the new sso layout isâ¦ surprising
<didrocks> finished emails before 8, not a bad day \o/
<didrocks> tvoss_: RAOF: do you mind acking that one? at least, it's giving one step closer to have mir building on armhf: https://code.launchpad.net/~didrocks/mir/add-valgrind-build-dep/+merge/171960
<tvoss_> didrocks, looking
 * didrocks is still concerned about bug #1195265
<ubot5> bug 1195265 in Mir "tests stuck on armhf" [High,New] https://launchpad.net/bugs/1195265
<tvoss_> RAOF, did you alter -Bsymbolic-functions to -Bsymbolic, yet?
<RAOF> tvoss_: No. I stopped doing the thing that was triggering that bug.
<tvoss_> didrocks, let me give you a top-approve, too
<tvoss_> didrocks, when jenkins says go for it :)
<tvoss_> didrocks, is that hang only happening on the buildd's?
<didrocks> tvoss_: not sure, I don't have a pbuilder ready, at least, the hang is reproduceable in the buildd's
<tvoss_> didrocks, jenkins is building armhf, too. kinda curious what it has to say about your branch adding valgrind
<didrocks> tvoss_: is it? I don't see armhf results: https://code.launchpad.net/~robert-ancell/mir/xmir-diagnostic-recovery-docs/+merge/171712
<didrocks> i386 and amd64 only
<tvoss_> didrocks, oh, thx for the info
<didrocks> tvoss_: duflu reverted without talking on IRC
<didrocks> duflu: I want the maximum quality before we release a package
<duflu> didrocks: Yes, I have lots of questions. See the MP
<didrocks> duflu: why removing valgrind then?
<didrocks> duflu: and if so, why if vaglgrind is not installed, the package build will fail because of no valgrind?
<duflu> didrocks: That's possibly a CMake bug. It's meant to (and does for me) elegantly skip valgrind if it's not installed
<didrocks> duflu: Recommends: doesn't change anything for building the package
<didrocks> duflu: I would prefer we have all available tests executed
<duflu> didrocks: Absolutely. But that's not a requirement for other people building Mir
<didrocks> duflu: in that case, don't build the package
<didrocks> but the upstream source
<didrocks> duflu: OTOH, on the other archs, valgrind is already pulled during package build due to some other requirements
<didrocks> so you are not fixing anything here
<tvoss_> duflu, trying to understand your concern. Mind elaborating a bit?
<duflu> didrocks: OK, I give in. Approved. I think we're limited by our tools and deb
<duflu> tvoss_, all explained in the MP
<didrocks> duflu: I don't see the concern TBHâ¦ but thanks :)
<duflu> tvoss_, normally you should never declare something a requirement unless it's required
<didrocks> it is required by our quality standards I would say
<didrocks> as we are build-dep on stuff to run tests
<didrocks> you can argue it's not a requirement per see
<RAOF> But it is a requirement - we require to run the valgrind tests?
<didrocks> but it's one by our stadnards :)
<RAOF> When we're building in the archive.
<duflu> didrocks: Yeah debian needs more levels of grey
<didrocks> duflu: but I agree there is a bug in MirCommon
<didrocks> duflu: how so? we don't provide multiple "build level", not sure what you meant? :)
<didrocks> we can have something like an alternative
<RAOF> duflu: Build-depends in Debian are almost always a super-set of the minimum possible. They're also not something that anyone normally objects to?
<duflu> RAOF: OK. I guess it doesn't matter if we're working toward distro-agnostic build instructions anyway
<tvoss_> didrocks, do you want to file the bug or shall I?
<didrocks> tvoss_: for the valgrind detection? please do
<didrocks> tvoss_: it's weird, it's working well on other archs
<didrocks> like https://launchpadlibrarian.net/143541061/buildlog_ubuntu-saucy-i386.mir_0.0.6%2B13.10.20130627ubuntu.unity.next-0ubuntu1_UPLOADING.txt.gz
<didrocks> not on armhf
<didrocks> https://launchpadlibrarian.net/143544949/buildlog_ubuntu-saucy-armhf.mir_0.0.6%2B13.10.20130627ubuntu.unity.next-0ubuntu1_FAILEDTOBUILD.txt.gz
<didrocks> tvoss_: but OTOH, the stuck armhf tests are more important IMHO
<tvoss_> didrocks, fair, medium priority then
<didrocks> RAOF: do you have any idea of what can stuck the tests?
<didrocks> tvoss_: yep :)
<tvoss_> didrocks, how can I get access to the buildd setup to try and reproduce locally?
<didrocks> tvoss_: I tried on pbuilder with cross-compile, didn't succeed
<RAOF> didrocks: tvoss is the expert in debugging stupid PPA buildds and their stupid 30-year-old kernel bugs :)
<didrocks> ahah :p
<didrocks> RAOF: you infer that he loves that too? :p
<tvoss_> didrocks, I spent 4 days in lala-land, I'm a bit hesitant to go their again
<didrocks> tvoss_: the thing is that we have a build stuck now
<didrocks> tvoss_: so #webops can help knowing the current state I guess
<didrocks> tvoss_: https://launchpad.net/~ubuntu-unity/+archive/daily-build-next/+build/4751091
<didrocks> tell me we're taking the builder in hostage :p
<tvoss_> didrocks, that one is terminated isn't it?
<didrocks> I see this Session terminated, terminating shell... ...terminated.
<didrocks> but the build is in that state for at least 12h
<tvoss_> argh ...
<didrocks> (I think it started at 6PM)
<didrocks> tvoss_: I can relaunch the build if they kill it
<tvoss_> didrocks, mind talking to them?
<didrocks> sure
<didrocks> tvoss_: ask done, but I see no Vanguard
<tvoss_> didrocks, \o/
<tvoss_> yell at someone
<didrocks> :)
 * duflu would be keep to see said 30yo kernel bugs RAOF mentions ;)
<duflu> -keep +keen
<tvoss_> duflu, it's a hardy kernel running a saucy chroot
<didrocks> duflu: "I'm using Linux for at least 40 years" :)
<didrocks> "and ubuntu for even more"
<duflu> Yeah, me too. 50 if you count when it was just cogs and pulleys
<didrocks> ;)
<tvoss_> didrocks, https://bugs.launchpad.net/mir/+bug/1195590
<ubot5> Launchpad bug 1195590 in Mir "cmake/MirCommon.cmake fails in detecting that valgrind is not installed" [Medium,New]
<didrocks> tvoss_: confirmed
<tvoss_> didrocks, ack
<RAOF> mlankhorst: Where did the PPA with xserver 1.14 go?
<mlankhorst> canonical-x/x-staging?
<RAOF> Ah, of course!
<tvoss_> RAOF, want to have a quick glance at https://code.launchpad.net/~afrantzis/mir/fix-render-surfaces-vt-switch/+merge/171755
<tvoss_> RAOF, lgtm and I would top-approve
<tvoss_> duflu, ^
<tvoss_> okay guys, taking another screencast :)
<tvoss_> back in a few
<RAOF> duflu is too fast
<duflu> If that were true I would have started on VESA already :P
<RAOF> By "vesa" I assume we mean "fbdev", right?
<duflu> RAOF: Yeah whatever it ends up being
<duflu> I have lots of testing and research to do yet
<duflu> RAOF: Looks like I will be pushing it to finish my new proposal for thread safety this week. So no fbdev work
<duflu> Does anyone else think Mir's default glClear colour should be not-black? Black makes it less obvious that something like a Mir server owns the screen
<duflu> ... kind of like X with its default root pattern
<duflu> ... and not aubergine either ;)
<didrocks> duflu: orange? :)
<didrocks> would be ubuntuish :p
<duflu> didrocks: I thought Orange was an obvious no :)
<duflu> obvious "No"
<duflu> RAOF: Oh, now that raring support is back, I can test various graphics cards if need be
<sgx1> hi, i'm an ubuntu user. when will we test mir in Saucy without adding the mir ppa ?
<tvoss_> sgx1, hey there, didrocks would be the best person to answer that question ^
<didrocks> sgx1: there is a build issue on armhf, and some bugs to fix before entering the distro
<didrocks> so once https://bugs.launchpad.net/mir/+bugs?field.tag=entering-saucy is fixed and we have the integration tests in autopilot form (robert is working on that), we are good for distro
<didrocks> this is something the mir team here can answer and tvoss_ (back to you dude! :p)
<didrocks> tvoss_: grrr, I went out of battery once again even if I shutted down ubuntu touch, with the power button, is it really shutting it down? I'm wondering
<didrocks> tvoss_: I'm recharging it and will try an armhf build on that just to ensure we don't reproduce it locally
<tvoss_> sgx1, helps?
<duflu> didrocks: AFAIK it never shuts down. You have to: adb root ; adb shell ; poweroff
<didrocks> duflu: even if I long press the button? I see no screen then, like if it was shut down
<didrocks> but by experience it seems to clearly shows it's a wrong assumption :)
<duflu> didrocks: That should work. But it will be an unclean power off.  Once it is off, the screen will show the battery charging icon only
<didrocks> duflu: right, that's what I'm pretty sure I saw last time, but this morning, no battery :/
<duflu> But maybe phablet has a shutdown option now. I haven't checked in a while
<didrocks> hence this "I'm totally puzzle" :)
<duflu> didrocks: Can you adb shell? If not then it's off. Totally user friendly
<didrocks> duflu: oh nice tip! I'll definitively give it a try :)
<tvoss> RAOF, any chance we can land https://code.launchpad.net/~raof/mir/prober-drm-device-probe/+merge/170765 today?
<ogra_> is XMir supposed to run on arm already ?
<ogra_> (and if yes, what happens on devices that casn only use xfbdev because they are lacking an xserver)
<tvoss> ogra_, nope, not yet. We are looking into vesa/fbdev support right now
<tvoss> duflu, ping
<ogra_> ok
<ogra_> if you have something i'll happily test on my chromebook ... Mir should be fine if it is working on nexus10 (same driver and GPU)
<tvoss> ogra_, https://bugs.launchpad.net/mir/+bug/1118903
<ubot5> Launchpad bug 1118903 in Mir "System compositor lacks a software rendering backend" [High,Triaged]
<tvoss> ogra_, sure, I'll let you know
<ogra_> yeah, that bug isnt exactly the same thing i mean :)
<ogra_> i was talking about setups where you actually have drivers to have composite but there is no Xserver (i would assume thats the majority of arm devices)... would it be possible to have Mir use the driver to have composite and an fbdev implementation for XMir
<ogra_> ?
<duflu> tvoss: pong
<duflu> ogra_: I am about to begin fbdev exploration on Monday, hopefully
<ogra_> great
<didrocks> simple and kind small MP: https://code.launchpad.net/~didrocks/unity-system-compositor/correct-copyright-url/+merge/171970 :)
<xnox> RAOF: =)))) ok. i'll file bugs about it not being mirrored. my setup is "interesting".
<hikiko> https://www.youtube.com/watch?v=AiL6XQQc_4Y the nested gbm display worked :)
<hikiko> I am moving to the buffer allocation now
<tvoss> hikiko, \o/
<alf> hikiko: great!
<hikiko> :D
<tvoss> RAOF, if still about: the updated mesa in the system-compositor testing ppa fixes the gpu hang, right?
<RAOF> Fixes *an* intel GPU hang, yes.
<tvoss> RAOF, :)
<greyback> tvoss: ROAF: need a tester? I was getting that hang quite frequently, so switched back to normal X
<tvoss> RAOF, is the ppa in a good state?
<tvoss> greyback, not using chrome helps a lot :)
<greyback> tvoss: hmm, will give it a try anyway
<RAOF> tvoss: The PPA is indeed in a good state.
<tvoss> RAOF, cool, thx
<RAOF> Dear internet: *faster*
<tvoss> RAOF, rofl
<RAOF> If someone with a pipe fatter than 30kbit/sec to launchpad felt like it they could test xserver 1.14 from ppa:raof/aubergine.
<tvoss> RAOF, what do you want me to test?
<RAOF> That xmir works, basically.
<tvoss> RAOF,  do I just need that ppa?
<RAOF> Yeah.
<tvoss> but I can stay on system-compositor-testing?
 * tvoss has started download and upgrade
<RAOF> Yes
 * tvoss grabs coffee, should be there in 3
<tvoss> RAOF, see you in a bit, hopefully :)
<tvoss_> RAOF, back
<tvoss_> RAOF, all good as far as I can tell
 * duflu -> dinner, weekend
<bregma> tvoss_, are you going to propose a merge for your branch fixing #1194017 (embedded gmock removal)?
<tvoss_> bregma, sure, but we need a newer gmock
<tvoss_> in the archive, not sure what the status is there
<bregma> is there a bug open for that work item?
<tvoss_> bregma, let me find it
<tvoss_> or better: didrocks, do you have the bug for ftbfs for gmock handy?
<bregma> google-mock in raring and saucy is the latest upstream release
<didrocks> tvoss_: there is a fixed version, syncing with debian, but we need all rdepends to use the source and rebuild there mock instead of relying on the shared librairie
<tvoss_> didrocks, thx for the update
<tvoss_> bregma, in that case it should be a matter of adjusting the add_subdirectory in Mir's top-level cmake
<didrocks> tvoss_: if someone has time to deal with it, would be great to open a bug and list all components, I'll take care of that next one :)
<tvoss_> didrocks, ;)
<didrocks> bregma: you are debugging the hung and the MirCommon.cmake issue then?
<bregma> didrocks, yeah, but arm builds take a looooong time
<didrocks> bregma: tvoss_: I'm almost done building Mir on the nexus4, I will be able to tell you if the test issue is a buildd one or something else
<didrocks> bregma: don't tell me, I started it 1h30 ago :p
<didrocks> 90%
<bregma> samesies, except I'm using qemu
<bregma> haven't got to the tests yet
 * didrocks makes some useless support noise for his phone, before thinking it's useless :p
<didrocks> bregma: I cross fingers we can reproduce and it's not a stupid buildd-only issue
<bregma> I suspect there is an issue running tests through valgrind on arm, and if we avoid that everything will be shiny
<didrocks> bregma: yeah, but not sure it's wise to avoid valgrinding in our main target arch
<didrocks> bregma: either my phone is really really slow
<didrocks> bregma: or I'm confirmining the hang on my nexus 4
<didrocks> tvoss_: FYI ^
<didrocks> (the tests takes few milliseconds normally and it's been 30s)
<tvoss_> didrocks, ack and thanks
<tvoss_> didrocks, mind running ctest -V?
<didrocks> tvoss_: sure
<didrocks> and installs pastebinit :p
<didrocks> tvoss_: http://paste.ubuntu.com/5807793/
<didrocks> oh
<didrocks> this time, it passed
<didrocks> let me retry this run
<didrocks> ok, maybe I didn't wait enough, after 30s, now every time, I see the tests progressing
<didrocks> so, let's see until where it's going (I | tee anyway)
<didrocks> tvoss_: ok, lot of failures, but things moved
<didrocks> and finished with integration-tests ................***Exception: SegFault107.32 sec
<didrocks> http://paste.ubuntu.com/5807816/
 * didrocks now retries without -v and time it
<tvoss_> didrocks,here is the point: it tries to build for the android graphics backend
<bregma> didrocks, tvoss_ , the problem didrocks is seeing is a combination of running the test on an actual running phone and http://code.google.com/p/googletest/issues/detail?id=247
<bregma> the test is designed to fail if it's run on a real live android system, but  a flaw in gtest means the test gets run without proper initialization
#ubuntu-mir 2013-06-29
<kdub> yay, found a way to break ms::Surface : public renderable, public surfacetarget
<JoseeAntonioR> hey guys, anyone around?
<tvoss_> JoseeAntonioR, ping
#ubuntu-mir 2013-06-30
<JoseeAntonioR> tvoss_: pong, got it sorted, thanks!
<arsson> Any progress? Does Mir fall like a Mir? :)
#ubuntu-mir 2014-06-23
<RAOF> Oh, _that_ makes more sense.
<RAOF> Ohhai std::system_error. You're like boost::errinfo(errno), except actually useful!
<anpok> hi
<alan_g> alf__: do you want to wait for greyback's vote on https://code.launchpad.net/~afrantzis/mir/scene-elements/+merge/223822?
<anpok> alan_g: https://code.launchpad.net/~andreas-pokorny/mir/split-main-loop-and-fix-races/+merge/220571/comments/537389
<alan_g> anpok: looking...
<anpok> what do you refer to in the last paragrah
<anpok> +p
<alan_g> Splitting our event dispatching into two classes
<anpok> alan_g: because we get another thread?
<anpok> or because those things should all be treated as "events" and hence handlers of those should all be registered at the same instance?
<anpok> the reason for splitting was about only doing those things in the main loop that need to be handled sequentially
<anpok> but it isnt about EventLoop then - ok
<anpok> alan_g: will renaming to EventLoop resolve the issues for the first MP, then we could discuss scheduler being the right pick for the second mp?
<alan_g> anpok: I'm not saying it is wrong. Just that I've not been convinced by the approach. But that could be that I'm still tying to work out why any of it is needed.
<anpok> understood.. I think a better (in terms of flexibility) approach would be to have all (apart from signals I guess) scheduling capability in a single class and deciding which component gets access to which thread event dispatcher..
<anpok> .. deciding insider default server configuration ..
<anpok> *inside
<anpok> args
<anpok> but I dont think that is needed yet
<anpok> the split addresses the concern that we do to much within main loop and might delay timers..
<anpok> alan_g: I am still unsure if renaming it to EventLoop really satifies you here
<anpok> no objections against the name
<alf__> alan_g: (@Gerry's feedback: no, we discussed the approach on Friday in IRC)
<alan_g> anpok: there's a lot of code churn over this series of MPs and that leads to e.g. questions about the names. Better names make it easier to work out what's going on. I don't know if my suggestions are better names as I'm suggesting names in the hope of figuring out what motivates all this work. Somewhere, several MPs away is an interface that dandrader wants to use but the path getting there doesn't seem clear to me.
<alan_g> anpok: I'm just finishing off the easier MS to review and I'll come back to this.
<anpok> I could make that path shorter - the only thing I needed whas unregistering fd handlers. The rest was to address concerns along the path..
<dandrader> anpok, so you're working on making an mp that keeps input_sender API but that has "minimal" changes to mir bowels?
<anpok> hm no not at the moment .. my wifi was flaky.. I just wanted to say that the stack of MPs got bigger while addressing concerns/findings
<anpok> or rather because of
<alan_g> anpok: you're saying that you don't need split-main-loop-and-fix-races and move-loops-to-scheduler-namespace to land for something functionally equivalent to input-sender?
<anpok> alan_g: I only need the unregister fd part
<alf__> anpok: alan_g: Aren't some of the other changes needed for correctness of unregistering fds?
<alan_g> anpok: "the unregister fd part" (wherever that ends alf__) sounds like a sensible size for an MP. ;)
<anpok> alf__: yes but splitting caused naming discussions..
<alan_g> Why is splitting needed for correctness?
<anpok> alan_g: they are not - I wanted to say that I did not expect those to happen hence added them
<Nothing_Much> Hi, how do I report a bug for XMir?
<alan_g> Nothing_Much: https://bugs.launchpad.net/xmir
<Nothing_Much> Sorry, had a kernel panic
<Nothing_Much> How do I report a bug for XMir?
<alan_g> Nothing_Much: https://bugs.launchpad.net/xmir
<kgunn> AlbertA: so davmor2 is gonna test the powerd/usc display blank silo
<AlbertA> kgunn: cool
<davmor2> kgunn, AlbertA: Any preference on device?
<AlbertA> davmor2: I've been testing on nexus4, so I guess nexus7 should be good
<davmor2> no worries
<davmor2> kgunn: shouldn't there be a brightness slider in the battery indicator?
<AlbertA> davmor2: yes above the wifi control
<davmor2> AlbertA: I meant in the indicator not in the settings app
<kgunn> davmor2: interesting...i thot there used to be as well
<kgunn> i mean it is there in settings tho
<AlbertA> davmor2: in doesn't show there for me on a virgin image
<davmor2> kgunn: yeap I see it in the settings app for brightness and in the battery indicator.
<davmor2> AlbertA: Yeah I'm not saying it is a fault with the ppa it was more just a question as to whether it should be there
<kgunn> davmor2: the ui is driven by the "data from the backend" so wondering if maybe thostr's team dropped that
<kgunn> ...and its possible design said to do so
<kgunn> i'll poke around
<davmor2> could be
<davmor2> thanks
<kgunn> AlbertA: btw, n4 looked really good...i focused on phone calls/proximity sensor mainly
<kgunn> i'll do n10 after lunch
<AlbertA> kgunn: thanks for testing!
<kgunn> davmor2: fix on its way for that
<kgunn> http://bazaar.launchpad.net/~indicator-applet-developers/indicator-power/trunk.14.10/revision/244
<davmor2> AlbertA, kgunn: So far music from the scope stops on screen blank and dim occurs before that, Music from the music player continues past screen blank and there is a dim before screen blank, Music video doesn't dim or screen blank while playing it does however on completion.  Need to test paused
<davmor2> excellent so dims and blanks on pause too :)
<kgunn> davmor2: right so music from scope is grooveshark right ?
<kgunn> so its all behaving as expected
<kgunn> e.g. groovesharked isn't white listed but music player is
<davmor2> kgunn: no,  if you click on music from the carousel there is a play button on the scope
<kgunn> going for run bbiab
<davmor2> kgunn: currently I think it isn't whitelisted either so it's expected but I think it should be whitelisted as it is a nice way to play a single track
<davmor2> screen reblanks on sms and calls and unblanks to display them \o/
<AlbertA> davmor2: cool, so everything fine so far?
<davmor2> AlbertA: seems to be so far yeap
<kdub_> just fyi, usc has a medium-sized abi break with the SceneElement change
<AlbertA> kdub_: I guess we should bump ABI now
<AlbertA> camako: ^
<kdub_> AlbertA, yep
<davmor2> AlbertA, kgunn: okay so I've tested everything I can think of to do with time outs on n4 and n7 both look good
<kdub_> AlbertA, with the power changes, will powerd-cli still work?
<AlbertA> kdub_: yes
<kdub_> great
<AlbertA> only the keep display on part
<AlbertA> davmor2: great thanks!
<kdub_> AlbertA, meaning, 'powerd-cli display bright' won't work?
<AlbertA> kdub_: yeah it will, it ignores everything after display basically
<AlbertA> kdub_: so it will just keep the display on
<kdub_> okay
<Nothing_Much> Question, would Source engine games from Steam having problems with XMir have to be reported to launchpad?
<kgunn> Nothing_Much: question for you, did you "disable" xmir and see if the same problem existed ?
<kgunn> steam games should run in the traditional xstack unawares of the xmir config
<kgunn> think x stack is your user session running on top of the system compositor xmir
<Nothing_Much> kgunn: Yes I did, I removed xmir from my system and all was running well back on standard xorg
<kgunn> Nothing_Much: in that instance, yeah, you could log a bug
<Nothing_Much> By the way, I got a 10fps boost in the games :)
<kgunn> cool
<Nothing_Much> It just stutters every 5~20 seconds making the game annoying to play
<kgunn> kdub_: so you gonna bump the server so name ?
<kgunn> you could had an mp for that, make it a prereq to sceneelement changes
<kdub_> I can, although I'm just the one who noticed :)
<kgunn> kdub_: who's changes are they ?
<kgunn> e.g. who's breaking abi ?
<kgunn> ...i think camako wanted folks who break abi to take care of the bump when it happens
 * kdub_ digs around
<kgunn> which i agree with actually
<kdub_> although in practice, that's trickier to know when ABI is broken
<kgunn> kdub_: granted, builds will continue...but people should realize/know when they touch a public header...and just ask themselves, could i have possibly broken abi ?
<kgunn> imho
<kdub_> kgunn, yeah, I agree, but it would be nice if jenkins whined about it when we fail to notice :)
<kgunn> true
<AlbertA> kgunn: kdub_: yeah I was thinking about this the other day....
<AlbertA> to have an automated abi check, kinda like android does with checkapi for the java apis
<kgunn> AlbertA: mmm, not a bad idea...
<AlbertA> kgunn: we could possibly generate a manifest as it its stand currently
<kgunn> AlbertA:  a simple library that tests every func....
<AlbertA> kgunn: maybe with some llvm tools...but in the worst case, manually
<kdub_> kgunn, I think the new functions are racarr_'s and alf__'s on ms::Scene?
<kgunn> kdub_: thanks...
<kgunn> hey racarr_ ^ mind bumping server so for the abi break ?
<AlbertA> basically have a map of interfaces that will need abi bumps
<AlbertA> and a map of public apis
<AlbertA> then with some script/tool magic diff that against the current mp/mr
<kgunn> AlbertA: ...and make it part of CI ? ...to catch it in the mp submission ?
<AlbertA> or for start it could at least be a script we can run manually
<kgunn> i'd like that
<AlbertA> but eventually yeah, in CI
<AlbertA> I keep thinking there must be some tooling in llvm that can allows us to automate this
<kdub_> oh kgunn, racarr_ sorry, misread, looks like its just the looks like alf__'s change
<kgunn> racarr_: nevermind....we'll ask alf__ to do it :)
<AlbertA> oh cool an abi/api checker: http://ispras.linuxbase.org/index.php/ABI_compliance_checker
<kdub_> AlbertA, yeah I feel like I'm pretty prone to mis-step on 'bump the abi', a tool would help
<kdub_> I guess I can build the stack semi-quickly now, maybe i'll just check with that
<kgunn> kdub_: yeah!...give that tool a go
<AlbertA> and it's already a debian package: pt-get install abi-compliance-checker
<racarr_> kgunn: I dont mind doing it...I guess I break abi with cursor spike phase 4 too
<racarr_> for now lunch during chromium build!
<kgunn> racarr_: ok, just let me know...or let alf__ know :)
<kgunn> alberto_: any idea what i need to make this complaint go away ?
<kgunn> CMake Error at /usr/share/cmake-2.8/Modules/FindPackageHandleStandardArgs.cmake:108 (message):
<kgunn>   Could NOT find PkgConfig (missing: PKG_CONFIG_EXECUTABLE)
<kgunn> i assume i'm missing some install
<kgunn> ....i'm on the phone trying to build a demo app
<kdub_> pkg-config
<kdub_> kgunn^^
<kdub_> is this one good to go? https://code.launchpad.net/~kdub/mir/hwc-device-test-cleanup/+merge/223978
<racarr_> ok...over the main fix all the direct conflicts and understand the changes hump with chromium :)
<racarr_> should be able to finish today and add touch/cursor support
<kdub_> racarr_, the touch/cursor support isn't on by default, right?
<racarr_> kdub_: Oh I meant touch and cursor support as
<racarr_> in for chromium
<racarr_> while I am working on it
<racarr_> not
<racarr_> cursor spots for touches
<kdub_> ah, okay
<racarr_> which...I will be returning too after chromium lol
<kdub_> yeah, I just want to make sure its off by default (and no invisible layers sneak in)
<racarr_> mm definitely
<kgunn> kdub_: thanks!...its just a junk branch so doesn't have proper debian control and all that
<kdub_> kgunn, yep, no problem
<Nothing_Much> Woo, bug reported!
#ubuntu-mir 2014-06-24
<RAOF> I am going to be most displeased when I discover that boost::asio is the thing that's broken here...
<RAOF> But for the moment, EOD.
<anpok> alan_g: do you want to have a last look at just-unregister-fd? Applied your suggestion. I would like to approve it now.
<alan_g> anpok: looking
<alan_g> anpok: approved
<anpok> thx
<DonkeyHotei> anpok: how's the mesa work going?
<anpok> DonkeyHotei: I was gone for a week and not much progress since then. I only discovered that mir server with demo shell works really fine
<anpok> so mesa directly works flawless
<anpok> so there must be some kind of initialization issue when mesa runs with mir platform, that causes a corrupt driver state..
<anpok> which then causes egl/mir clients to fail
<DonkeyHotei> would be nice to get a trusty SRU when you fix that
<kdub_> alf__, remove the stub from hwc-device-test-cleanup
<alf__> kdub_: great, (top) approved
<kdub_> alf__, thanks! i think track-visibility-in-default-compositor is good to go
<kgunn> alf__: so racarr_ thot he might bump server, but he didn't....but i understand some recent "scene" stuff you landed most likely broke abi
<kgunn> i assume related to visibility prep
<kgunn> can you mp the bump ?
<alf__> kgunn: sure
<kgunn> ...note, if you do, need to also update build dep for the rdeps (unity-mir, usc, papi)
<kgunn> at
<alf__> kgunn: where do I find these?
<alf__> kgunn: I mean the updated values
<kgunn> alf__: so in mir, its the top most cmake, the debian/control...and changelog of course
<alf__> kgunn: ah, nevermind, thought you meant it the other way around
<kgunn> camako: ^ we're spreading the pain right? you break abi you buy it :)
<kgunn> alf__: we have been using https://code.launchpad.net/~mir-team/platform-api/development-branch & https://code.launchpad.net/~mir-team/unity-mir/development-branch
<kgunn> to stage the rdep bumps
<alf__> kgunn: ok
<alf__> kgunn: it sounds like we need a script for this... update_mir_abi.sh :)
<kgunn> alf__: i have one :)
<kgunn> 2 secs
<kgunn> alf__: https://pastebin.canonical.com/112279/
<kgunn> doesn't address the debian/changelog obviously
<alf__> kgunn: excellent, thanks
<alf__> kgunn: camako: Should I also update the minor version number 0.3.0 -> 0.4.0?
<kgunn> alf__: looks like if you need an updated u-s-c branch...you'll need to create one...
<kgunn> something like ~mir-team/unity-system-compositor/devel-mir-next would be handy
<kgunn> then we can make it a semi-permanent vehicle
<Nothing_Much> I think there's a problem with the lock screen with XMir
<Nothing_Much> As in
<Nothing_Much> It logs out instead of locks
<alf__> kgunn: camako: why not unity-system-compositor/development-branch so that we are consistent in all projects?
<kgunn> alf__: only because its not really a "devel only"...its "devel for mir server abi breaks" :)
<kgunn> and i have an outstanding action to go rename those others
<kgunn> unity-mir/devel-mir-next, papi/devel-mir-next
<kgunn> this way people can continue with trunk landings not having to "wait" on mir
<alf__> kgunn: OK. Is the policy to bump dependencies in all rdeps or only those that really need it?
<kgunn> alf__: really only those that need it.... by that i assume you mean like, xmir uses client only..so this is a no hit to xmir
<alf__> kgunn: created usc/devel-mir-next
<kgunn> awesome
<greyback> +1 on the branch renames
<kdub_> so the policy is to scan papi, usc, unity-mir, powerd, qtsg stuff, etc for abi breaks and update them?
<alf__> kgunn: hmm, should devel-mir-next be based off each project's development-branch or each trunk?
<kgunn> alf__: you can base it off of trunk...the way i have the recipe set up it will merge trunk before building
<kgunn> so you keep getting the goodness of other landings
<kgunn> if it fails, we get a mail
<kgunn> (or we should)
<kgunn> only thing is it does require merging trunk before going for a landing of the whole nut (which is what cemil or i would do)
<kgunn> hopefully we keep rolling fast enough
<kgunn> alf__:  that its not too much headache....
<kgunn> headache only really comes when we "wait" for releases
<alf__> kgunn: camako: I am confused about the flow... when we break ABI we should propose a dependency bump MP against each affected project's devel-mir-next?
 * kdub_ is too
<alf__> kgunn: camako: and then what happens?
<kgunn> alf__: so if its strictly an abi break...that mp just sits there until its landed
<kgunn> alf__: so, after you do this... camako will collect those 3 rdep branches (which bump debian dep on mir)
<kgunn> along with the mir-devel branched to 0.4.0...and attempt to land it
<kgunn> alf__: kdub_ is it still confusing ?
<kdub_> I have some misgivings about this approach
<alf__> kgunn: so the MP against devel-mir-next should also contain fixes for any code broken by Mir changes?
<kgunn> don't we all
<kdub_> like, if we do something that changes api, it might require significant changes to the downstreams
<kdub_> and we'd go stepping on the downstreams toes potentially in fixing the solution
<kgunn> alf__: yes... so if you break api you should have _more_ than just a debian/dep bump on mir...you would have acutal code changes cooresponding to the mir api that you changed
<kgunn> kdub_: this is why google hangouts/irc/launchpad were create :P
<kgunn> anyone who's breaking _api_ (not abi) should have a reason, and they should work with the rdeps owners as to why...
<kdub_> kgunn, sure, but we don't know who's responsibility it is to fix the downstreams in the case of a larger change
<kgunn> but...abi's are less disruptive in that regard
<alf__> kgunn: will other projects continue to develop in a development-branch or move back to trunk?
<alf__> kgunn: (I mean mir rdep projects)
<kgunn> kdub_: name a downstream please ?
<kdub_> like, usc
<kgunn> kdub_: u-s-c alberto or mterry
<kdub_> sure, I know who to talk to for the projects, roughly
<kdub_> or at least the irc channels to bother people on
<kgunn> kdub_: any mp must be reviewed and approved...so even if you tried to take a stab at it, you wouldn't get through until someone approved
<alf__> kgunn: will other mir rdep downstreams continue to develop in a development-branch or move back to trunk?
<kgunn> alf__: tldr version of events, i couldn't get papi to agree to work in a dev mode...so they are on trunk...they told me to create a mir-next branch to stage
<alf__> kgunn: ok
<alf__> kgunn: thanks
<kgunn> so if you do that with 1 you do it with all
<kdub_> kgunn, sure, but like from an actual 'getting that approval' standpoint, its sometimes tricky to jump into a downstream project and comply with all the team-rules and understand the scope of the project that they're trying to solve
<kdub_> I'm not saying that I can't do it, it just seems  like a recipe for headaches for the mir team coders
<kdub_> and headaches == regressions or long roundabout reviews
<kgunn> kdub_: think of it this way wrt dealing with "downstreams"...what do you do when android changes?
<kgunn> you update
<alf__> kgunn: One potential problem is that by the time we try to merge devel-mir-next (which is when we try release if I understood correctly) 1. our patches may be out of sync 2. They will not have been tested
<kdub_> kgunn, right, i'm the downstream... in this scenario, the upstream goes to all the downstreams and updates
<kdub_> so the analogy would be google coming in and updating mir for us when hwcomposer.h changes
<kgunn> alf__: 1) & 2) are solved by the ci-train process locking the project
<alf__> kgunn: I am not sure, let's say I propose an MP with a bump and changes to USC. When will this be merged to trunk and tested?
<kgunn> kdub_: if google proactively submitted an mp to your project before they released an api change...would that not be helpful to you ?
<kgunn> camako: i am remembering now why i never asked anyone to do this and just did it
<alf__> kgunn: lol
<kdub_> kgunn, sure, it would be helpful for me in the analogy, but a moderately large burden for the upstream
<kgunn> right...the idea is for it to be a pita
<kgunn> in order to incentivize ourselves towards getting the server api under control
<alf__> kgunn: I think that will come naturally as we stop getting feature requests :)
<kgunn> alf__: kdub_ note...i am not saying that _you_must_ make an MP with code changes for api changes....
<kgunn> however, you just need to make sure it does exist...no matter who does it
<kgunn> right?
<kgunn> i mean you can't release until that gets sorted
<kgunn> and we want to build testable packages off our devel-branch...
<kgunn> that's where this "need" comes from
<kgunn> otherwise, you have a devel-branch you cannot system test
<kdub_> sure, I appreciate the need
<kgunn> does that make sense ?
<kdub_> I'm just surprised that we're at 1.0 so suddenly I guess
<kgunn> and hopefully you are working with _all_ the downstreams close enough that you can determine who is best to make a change (or at least get a spike in place)
<kgunn> kdub_:  ?...what do you mean ?
<kdub_> like, this approach limits the development of the server api/abi quite a bit in terms of time-to-land-a-change
<kdub_> which, given the projects, might just be appropriate
<kgunn> kdub_: i would say this....for ABI...we break like every 3 days it feels...updating for it is like a couple of debian control file changes & a build
<alf__> kgunn: My concern is this: let's say that today I propose an MP against devel-mir-next for platform-api. Platform-api developers will continue working on trunk for a while (let's say a week) unaware of the changes. At the end of that week we decide it's time to release, so camako will try to merge platform-api/devel-mir-next into lp:platform-api, but lp:platform-api may have changed enough for the devel-mir-next changes to not apply. Have I mi
<kgunn> for API....we actually don't change too much...maybe 1 or 2 times a month,
<kgunn> and the updates for those, really havne't been much
<kgunn> b/c 9 times outta 10, its the downstream asking for it
<kgunn> so...while this is all interesting irc discussion, the reality hasn't mete out that its headache/hard etc...all we're trying to solve is being able to get features from mir-devel into hands of other developers sooner than the monkey-race that is landing in trunk
<kdub_> kgunn, I agree about the frequency of the abi/api stuff
<kgunn> alf__: sure...might happen, conflicts...resolve the conflicts, go for landing done
<kdub_> but am still concerned that we're just benefiting from a big chunk of our 'public' api going unused
<kgunn> kdub_: benefiting how ?
<kgunn> oh you mean...we have only a couple of shells
<kgunn> so server api hasn't seen every single thing someone might ask for ?
<Nothing_Much> Is there a bug with XMir that causes a crash when I lock the screen?
<kdub_> like, if we add a function to Scene, its just a simple pass-through function that we have to usc to get the wrapper class to compile
<kdub_> but then, say usc starts to use that function somehow
<kgunn> Nothing_Much: sorry, i couldn't tell you
<kgunn> kdub_: ok...i'm tracking...
<kdub_> and then the kicker (in terms of headache-time) is that we figure out that this added function is a strange function for an interface
<kdub_> and we have to reshuffle the usc code that we're somewhat unfamiliar with the requirements
<kdub_> the summary is I guess, it'll drive more feature-branch style development in mir
<kdub_> which... might not be that bad of a thing
<kdub_> because if I'm driving at a new feature or a 'structural bugfix' that requires dabbling in the public headers, we shouldn't be releasing those intermediate steps publically
<kgunn> kdub_: right, so you say ...hey, i hate that method...change it....compile usc, it won't...uh-oh, i have to talk to somone/proposeMP/not change it
<kdub_> right, which is okay because if they're using it, they have some requirement that needs satisfying
<kgunn> _exactly_
<kgunn> there's a reason behind everything....
<kdub_> but in terms of landing things in mir, development happens in 1000 line chunks to devel these days
<kgunn> reason behind you trying to change it...and a reason they're using it....
<kgunn> kdub_: are all 1000 lines in include/ ?
<kgunn> :)
<kgunn> typically not
<kdub_> no, 2 lines in include, and other stuff
<kdub_> but in terms of the mir team and reviewing, if its more than 1000-1800 lines, it lingers in review
<kgunn> right...i guess i'm kind of sitting here thinking, i've been doing exactly what we're talking about for last ~1.5 yrs
<kgunn> and hadn't seen any real issue...
<kgunn> sure it takes a day or 2 every now and then to sort a bigger change...but mostly
<kgunn> its really simple
<kgunn> kdub_: if its in review...and not landed on devel...then devel still builds for the downstreams
<kgunn> see what i mean
<kdub_> kgunn, sure, I do
<kgunn> think of it as 1000 line mp...you're now adding a few pre-req branches & few more loc changes to make it all happy from a  build perspective
 * kgunn notes this irc chat probably took more time than most abi bump cycles :D
<kdub_> kgunn, right, I mean, I think we're on the same page that we have to be more conscious of having the downstreams compile
 * alan_g is about to go but noticed chat for the 1st time. The main thing that would be nice is a CI that says "if this lands on devel then usc breaks".
<racarr_> +1
<kgunn> ++
<alan_g> I've set these things up in the past. It isn't hard.
<kgunn> alan_g: alberto_ pointed out a tool y'day...i think kdub_ even toyed with it ?
 * kdub_ feels 'violent agreement' feelings
<racarr_> Really? I just feel food poisioning sort of feelings.
<racarr_> :p
<racarr_> <- Mildly sick.
<kdub_> hah, my suggestion I guess is that we have to shift the status quo for how we review things, and the branching strategies while we're coding
<alberto_> abi-compliance-checker it's already a debian package you can install with apt-get
<kdub_> and... also improve the tooling so that we know when we're breaking things
<alberto_> I haven't tried to use it yet
<alberto_> but from what I read it basically does what we want
<alberto_> it generates abi and api information for a release
<kgunn> kdub_: right...i don't think camako (or i) are asking for the world...just at least a check from every engineer "did i break abi"...we'll catch it on promotion to trunk , but engineers addressing it
<alberto_> and you can then compare against another release version
<kgunn> when they do it, would go a long way to helping to keep ppa's building, other teams using mir-devel when they need to
<kgunn> e.g. trusted session was a good example
<kdub_> kgunn, right, I mean, I agree that we have to have to have the stack buildable without jumping through a lot of hoops or having to learn a lot of internals
 * kdub_ has been whining about that for a long time :)
<kgunn> help me help you :)
<alberto_> I was in my TODO list to try that tool...but the powerd/usc stuff keeps being a timesink hole
<kdub_> kgunn, I'm just trying to come to terms with 'diff size' vs 'get the stack to compile' in terms of like, actually working on the mir code
<kdub_> and the suggestion is to review things as feature branches
<kdub_> and once the line of work is done, get the completed feature branch out to devel along with all the 'get the stack to compile' stuff
<kgunn> kdub_: it can be 2 diff steps
<kgunn> kdub_: problem is in the past...we've broken abi, and let it sit
<kdub_> right, I'm on the same page with that being very bad for a lot of reasons :)
<alberto_> there seems to be 2 issues here
<dandrader> kgunn, anpok, alan_g|EOD - the fallback approach is ready  https://code.launchpad.net/~dandrader/mir/expose-android-input/+merge/224335
<alberto_> one is the abi in mir should be bumped with the MR/MP that breaks it
<kgunn> alberto_: eh..i could live with, bumping right after
<alberto_> the other is once we break the abi/api in mir - who is reponsible for making changes
<alberto_> to the other immediate dependencies
<alberto_> umir/usc/papi
<alberto_> I think that's one reason why asac wants all those in the same repo
<dandrader> racarr_, https://code.launchpad.net/~dandrader/mir/expose-android-input/+merge/224335
<kgunn> alberto_: in my mind, answer to who is only relevant for api... and usually the rdep owner b/c most of the time they're asking for it
<alberto_> kgunn: right sorry api breaks
<alberto_> abi is just rebuilds
<kgunn> in case where they didn't, i'd like to see people at least provide an mp and then pick up the phone and work with the owner
<kgunn> but...i can live with just "owning" making sure something gets changed soon to "make the stack workie"
<kgunn> dandrader: thanks
<kgunn> ok, lunch....
<kdub_> right, we all agree that we need a buildable/releasable stack people can go to
<kdub_> I'm still just chewing on how to best do that within the mir team, because there's pressure to have small diffs for review, and pressure to have everything tested with decent public headers in devel
<kdub_> If we bump api, we need to review the c++ interfaces on the server as closely as if we break the c client api
<kdub_> and a review that says 'this interface has some smell to it' tends to snowball a 1000 line review to a 4000 line review
<racarr_> dandrader: :D will review after I finish implementing this strange new class in Ozone.
<kgunn> racarr_: strange ?
<racarr_> strange?
<racarr_> Oh
<racarr_> Yeah its just....they have a new refactoring
<racarr_> in which um...something called a window creates something called a surface lol
<racarr_> which isn't really even wayland terminology either
<racarr_> so I'm calling that a strange choice :p
<racarr_> Also I now have to implement a "SurfaceFactory" class which among other things is responsible for
<racarr_> dlsyming eglGetProcAddress
<racarr_> so I'm also gonna call thesurface factory "strange"
<racarr_> lol
<kgunn> lol
<racarr_> Also there is this vsync provider whichI don't totally understand because wayland hasnt implemented it all yet but
<racarr_> it may expose an interesting sort of new mirclient requirement
<racarr_> it seems...to call this function at...some sort of interval (not yet clear to me)
<racarr_> and then it wants you to fill in a struct
<racarr_> with timing information about the last vsync/swap
<kdub_> racarr_, and who uses that?
<racarr_> That's whatI don't know yet :p
<kdub_> racarr_, sounds sort of android-ish
<racarr_> I mean, roughly it seems like its sent back to the host process
<racarr_> at which point they presumably do something clever with it
<racarr_> yeah
<racarr_> android has that last frame input
<racarr_> resampling
<racarr_> thingy
<kdub_> I think its used in android to sync input processing and frame timing
<racarr_> it could be something like that.
<racarr_> yeah
<kdub_> well, more like, 'when to best fire off new frames'  as opposed to 'ensuring no tearing'
<racarr_> Yes
<racarr_> Anyway we may need to expose this frame timing somehow...because afaik I see now with them justcalling eglSwapBuffers there is no good way to get at it
<kdub_> racarr_, well, we can kick out the signal from the android platform, although I don't know if mesa can do that as easily
<kdub_> but also, I know that the android system can work off of a fake vsync signal, so that seems easier/more flexible for all platforms
<kdub_> like, query display, 'oh you're 120 hz? i'll make a 120hz heartbeat thread'
<racarr_> Hmm maybe...I think we should be able to get a better number on any platform though
<racarr_> not 100% sure but I think what you want this number to converge to is the time the buffer first appears on screen
<kdub_> yeah, we could at least sync to the last-known vsync
<racarr_> so if there is nothing better, at least the page flip
<racarr_> callback for mesa
<racarr_> is pretty good
<racarr_> yeah
<kdub_> ilke, if its within i dunno (guesstimate coming up) 10% of the phase of the actual vsync signal, its probably good enough
<racarr_> haha right. this is the part that I don't entirely understand...what that% is
<racarr_> I guess need to look at the details
<racarr_> of theinput resampling algorithm
<racarr_> and
<racarr_> potentially what chromium is doing
<racarr_> :( my laptop screen just shattered in perhaps the most spectacular fashion ive ever seen
<racarr_> also wifi broke and keyboard is failing lol
<racarr_> luckily emergency backup of chromium tree to nexus 7 succeeded.
<dandrader> what does mir_surface_state_restored  mean?
<racarr_> dandrader: normal
<racarr_> lol
<racarr_> as opposed to maximized or minimized, etc
<racarr_> in particular, when you go from maximized/minimized, etc
<racarr_> your old "floating state" is"restored"
<racarr_> notthebest name
<dandrader> racarr_, ah ok.
<dandrader> racarr_, yeah, I would have understood normal
<racarr_> or floating even
<dandrader> as well
<racarr_> theres an item somewhereto update themto the design language
#ubuntu-mir 2014-06-25
<racarr_> wow new chromium worked on the first try
<racarr_> that never happens :p
<racarr_> it seems a little more responsivice perhaps...but it was never bad
<RAOF> Oh, great.
<RAOF> Looks like glibc's now using Haswell's fancy lock elision instructions.
<RAOF> Making valgrind confusinated.
<racarr_> just read alittle about the implementation
<racarr_> that is really...fancy
<racarr_> if someone told me to implement that I would probably just cry
<RAOF> racarr_: Oh, re: vsync conversation above - we can pull whatever vsync related information you need out of drm.
<racarr_> :) cool
<racarr_> ill doa littlestudy of how chromiumis usingit and see what we should expose
<RAOF> racarr_: Specifically, the infrastructure to support GLX_sync_control is there, so we can get the frame time and such.
 * RAOF goes babywards
<racarr_> :) ttyl
<RAOF> So, um... how does this _ever_ fail to leak?
<RAOF> Ok, new question.
<RAOF> Why does is the leak only *fatal* on *some* of the CI infrastructure?
<RAOF> tvoss: Good morning!
<tvoss> RAOF, good morning :)
<anpok> alf__: will you have time to look at the input-sender again today?
<alf__> anpok: sure
<anpok> not urgent, but is anybody else also affected by: https://bugs.launchpad.net/mir/+bug/1294610
<ubot5> Ubuntu bug 1294610 in Mir "client attaching to nested server seems to freeze the VT" [Undecided,New]
<greyback> Hi folks, a preliminary review for https://code.launchpad.net/~dandrader/mir/expose-android-input/+merge/224335 would be appreciated
<anpok> oh the ci failure looks interesting - will propose a synchronous timer destruction then.
<alan_g> In other news: "The Library Evolution Working Group (LEWG) voted to base the Networking TS on Boost.ASIO."
<anpok> good timing
<anpok> but there wasnt really an alternative, was there?
<alan_g> It is a massive change in direction. (But probably a rational one.)
<anpok> alan_g: wrt to https://code.launchpad.net/~alan-griffiths/mir/fix-1334287/+merge/224457/comments/538943 I want to use the action queue to sequentialize the timer callbacks and the canceling operations.. then either cancel happens before asio decides to schedule the timer or the other way round, and synchronous_server_action waits till the canceling completes..
<anpok> so in the bad case, the callback is called during cancel waits that the server action queue executes the actual cancel operation
<anpok> but i just messed up my solution .. need to clear my head .. and look again what I missed.. or if you want to look I could push it somewhere..
<alan_g> anpok: ack - I'm halfway through fixing my fix, so I won't look right now. Tomorrow am?
<anpok> yes
<kgunn> davmor2: is there any way you could perform some smoke testing on silo20 ? this is the same silo you tested 2 days ago....
<kgunn> we had some packaging isssues, so mostly just a rebuild
<kgunn> but we'd like to get some external eyes on it
<davmor2> kgunn: I can have a look after I'm just trying to trace an issue currently.
<kgunn> rsalveti: ^ if you would like to help with testing silo20 that'd be awesome (its the display blank policy move from powerd to usc)
<dandrader> is anyone working on getting unity-system-compositor updated against latest lp:mir/devel?
<dandrader> I mean unity-system-compositor/devel-mir-next
<rsalveti> kgunn: I tested it already, also replied to that thread giving +1
<kgunn> rsalveti: thanks!
<kgunn> dandrader|lunch: i think alf__ might have been, but got sucked into a regression/critical bug investigation
<alf__> kgunn: dandrader|lunch: exactly
<davmor2> kgunn: I'm off early today but when I get back I'll give you a ping with my results
<kgunn> dandrader|lunch: dednick needs it too...if i can get someone on it today i will
<kgunn> alf__: btw, any update on that bug ?
<alf__> kgunn: not yet, I am trying to track what is going through all the layers
<kdub_> which bug?
<alf__> kdub_: https://bugs.launchpad.net/mir/+bug/1332632
<ubot5> Ubuntu bug 1332632 in gallery-app "can't display toolbar after dismissing it" [Critical,In progress]
<kdub_> kgunn, I've fixed up usc locally here for my overlay work, maybe I s hould dust it up and propose
<kgunn> kdub_: yeah, please do
<alf__> kdub_: problem with usc is that it overrides the scene and returns renderables manually. However with the new changes it can't do that (it doesn't know how to create a SceneElement)
<kdub_> alf__, i just wrote a SceneElement impl there
<kdub_> that forwards the renderable along
<alf__> kdub_: For some reason it wants to only expose surfaces from two sessions (current and next). I was thinking that instead of customizing the scene it could hide the unneeded session.
<kdub_> alf__, yes, that seems the better approach
<alf__> kdub_: problem is that the new SceneElement doesn't properly handle visibility events
<alf__> kdub_: (i guess, unless you managed to do it somehow :))
<kdub_> right, I was just realizing the visibility events in my branch wouldn't work
<alf__> kdub_: well, if you have cycles to work on it great, otherwise I am going to pick it up again after I am done with this bug
<kdub_> alf__, okay
<kdub_> kgunn, so it seems my usc branch was only sufficient for testing out overlay stuff, not for landing
<kgunn> alf__: kdub_ ack
<AlbertA> alf__: I believe it does the current and next
<AlbertA> alf__: so that with the split greeter
<AlbertA> alf__: alpha transitions can be done
<AlbertA> alf__: if you hide it, then it will just show a black screen as you slide off the greeter
<kdub_> AlbertA, is the sliding not moving the surface?
<alf__> AlbertA: I was thinking of hiding every other surface/session besides current and next
<AlbertA> kdub_: no because this is under nested, they are essentially fullscreen sessions
<kdub_> oh, and alpha channel is just arranged to look like its moving
<AlbertA> kdub_: right
<AlbertA> alf__: oh ok
<kdub_> so... potential optimization
<alf__> AlbertA: ...so then the default SceneElementSequence would be what USC wants (hopefully)
<kgunn> mterry: ^
<mterry> mmm, ok...
<AlbertA> kdub_: right I mean for performance reasons... if the animation could be done in USC then that would be better since you wouldn't need alpha blending then
<AlbertA> kdub_: it would just be surface movement
<kdub_> right
 * alan_g thinks it is time to get "nested" back under test
<kdub_> indeed
<alan_g> Something to do tomorrow.
<Davmor3> kgunn: So this working okay
<AlbertA> Davmor3: you mean landing-020 looks ok?
<racarr_> im still stuck on how to get change notifications to the compositor for cursor-is-a-renderable
<racarr_> and I am starting to wonder if maybe cursor is a surface
<racarr_> but NOT a frontend::Surface
<racarr_> the thing is scene::Surface would have to lose inheritance of frontend::Surface
<racarr_> then you add like a
<racarr_> ...ClientSurface : scene::Surface, frontend::Surface
<racarr_> BasicSurface : ClientSurface (:/, basic surface is really just like clientsurfaceimpl)
<racarr_> scene::Surface : input::Surface, SurfaceBufferAccess
<racarr_> CursorSurface : scene::Surface
<racarr_> the problem with Cursor : Renderable
<racarr_> is you need an add_observer API
<racarr_> but its desirable not to have RenderableObserver as...basically a parallel class to
<anpok> racarr_:  a SceneElement maybe?
<racarr_> SurfaceObserver
<anpok> with a Renderable inside?
<racarr_> but you cant just promote surfaceobserver to renderableobserver
<racarr_> because
<racarr_> ms::Surface is NOT
<racarr_> a renderable
<racarr_> so then the shell wouldn't have add_observer
<racarr_> anpok: Yes, that part is fine
<racarr_> the problem is, the way the compositor gets
<racarr_> notifications is by seeing
<anpok> if the scene changed
<racarr_> Observer::surface_added(ms::Surface)
<anpok> i see
<racarr_> and calling ms::Surface->add_observer
<racarr_> so if its not a surface observers wont work
<anpok> that is correct as long as there are only surfaces in a scene
<anpok> scene::Surface that is
<racarr_> but surface is NOT a renderable (it produces renderable snapshots)
<racarr_> so you cant just make it Renderable::add_observer
<racarr_> yes
<racarr_> so either somehow I need to untangle that
<anpok> yes
<racarr_> or! make
<racarr_> the Cursor a surface.
<racarr_> but its pretty clearly NOT a frontend::Surface
<racarr_> so that hierarchy would have to be untangled
<anpok> and untangling the hierachy is close to untangling scene / surface / renderable
<racarr_> Mm
<anpok> and i think the latter is the one we are aiming for in the long run?
<anpok> but dont listen to me i am prone to prefere big changes
<racarr_> i am just worried it will get so big
<racarr_> that I will spend a week
<racarr_> porting all the client code and test code and stuff
<racarr_> to new interfaces
<racarr_> and then...um
<racarr_> it will be wrong for some reason lol
<racarr_> because im still not confident
<racarr_> I kind of like this
<racarr_> um
<racarr_> scene::Surface : input::Surface, SurfaceBufferAccess { ... add/remove_observer... }
<racarr_> i.e. what the two views of the scene require.
<racarr_> and Client(/Application?)Surface : scene::Surface, frontend::Surface
<racarr_> trying to figure out how much churn its going to cause...who uses implicit cast...from scene::Surface to frontend::Surface or uses the frontend::Surface methods in scene::Surface.
<racarr_> i.e. the shell primarily deals with scene::Surface...
<racarr_> and you dont want the shell to have to dynamic_cast<frontend::Surface>
<racarr_> but the shell does want to call things like mf::Surface::configure(attrib, val)
<racarr_> so you end up needing those methods on scene::Surface anyway
<racarr_> which. means the cursor has to implement them, but shouldn't
<racarr_> potentially the shell could work in terms of
<racarr_> ClientSurface.
<racarr_> Window : scene::Surface, frontend::Surface?
<anpok> the shell might want to add other things to the scene
<racarr_> ...just throwing that one out there :p
<anpok> not just the cursor.. or surfaces.. i think some form of type detection will be necessary as soon as it turns into a tree
<racarr_> maybe on the view sides
<racarr_> but if on the client side, i.e. shell code manipulating surfaces
<racarr_> all the code looks like
<racarr_> i.e. the wm code
<racarr_> "cast to frontend surface/cient surface/whatever, if it is one do stuff, if not return"
<racarr_> then that cant be right
<anpok> hm what is wm code?
<racarr_> ill be honest I kind of miss mir::shell::Surface
<racarr_> anpok: Wiondow management code
<anpok> yeah, but what is it? Raof mentioned in malta ... that you would probably have the tree of things that you want to traverse to insert new items or manipulate them.. dispatch input .. draw.. and another set of things which represents the clients and the attached surfaces..
<racarr_> what is it in what sense?
<racarr_> I mean its unity-mir
<racarr_> but I feel like thats not what you are asking lol
<anpok> :)
<racarr_> but right there is this
<racarr_> well there could be
<racarr_> this shell side view of the scene v.
<racarr_> the compositor side view.
<racarr_> but I guess we sort of had something like that and it was wildly unpopular and took a lot of time to consolidate
<anpok> I think that the view part looks like what you said above .. traverse and figure out the type of elements.. and I think the WM code will interact with actual windows/surfaces partially ignoring the graph  in many cases
<anpok> ah
<racarr_> hmm..
<racarr_> I have a whole other tree of thought
<racarr_> as a potential fix for the cursor...but im not sure
<racarr_> how promising it is
<racarr_> that maybe, rather than the compositor observe and then ask for renderable lists on changes
<racarr_> the compositor is given the renderable list.
<greyback> does cursor really have to be part of scene? It might better belong in a layer on top all for itself
<AlbertA> ummm I seem to remember alan pragmatically suggesting just sending the renderables + cursor
<AlbertA> a while ago
<racarr_> sending the renderables + cursor?
<racarr_> greyback: In this branch so far it is in a special layer in the surface stack
<AlbertA> right to the compositor
<racarr_> greyback: The point is its in the "RenderableList" that the compositor sees
<AlbertA> which can then always put it on top, etc...
<racarr_> Oh in the sense of sending them v. the surface stack asking for them
<greyback> racarr_: sure I get that. But since you're struggling to incorporate cursor into the scene, perhaps it doesn't belong there at all
<AlbertA> racarr_: basically cursor would not be in RenderableList
<AlbertA> but separate
<AlbertA> it seemed to make sense at the time (a few months ago)
<racarr_> but then how do you know
<racarr_> when to ask for it?
<racarr_> when its changed
<AlbertA> at the same time as when the renderables are obtained
<racarr_> but thats in response to callbacks from SurfaceObserver
<racarr_> you could add like
<racarr_> ms::Observer::cursor_moved()
<AlbertA> yeah that would make sense to me
<racarr_> but its starting to feel kind of clumsy at that point I think...why am I dealing with the cursor so seperately?
<AlbertA> because it's not a surface? lol
<racarr_> everything except mesa with hardware cursor, literally just treats it like any other renderable
<racarr_> but
<racarr_> the compositor doesnt consume surfaces
<racarr_> it consumes
<racarr_> renderables
<racarr_> it just uses surfaces to know when
<racarr_> renderables are ready to be consumed
<racarr_> is the problem
<AlbertA> true...I guess it depends on who is in charge
<AlbertA> of the z-policy
<AlbertA> I guess scene is
<AlbertA> not compositor
<AlbertA> so yeah it would make sense for it to be in the renderablesList
<racarr_> render list generalizes nicer to
<racarr_> touch spot visualization as well
<racarr_> than cursor_moved() which starts to become
<racarr_> increasingly nebulous
<AlbertA> yep yep
<racarr_> maybe...ms::Observer is the wrong interface for the compositor
<AlbertA> so is the issue that right now you would have to work the cursor into surfacestack?
<racarr_> well, that part isn't so bad
<racarr_> there I am specializing it, the surface stack has a cursor built in (or perhaps you add/remove_input_visualization(mg::Renderable))
<racarr_> and they show up in generate_renderable_list
<racarr_> but not input::for_each, etc
<racarr_> the problem is just about the notifications really
<racarr_> because, the compositor receives surface_added(ms::Surface) and uses that to install
<AlbertA> oh I see...
<AlbertA> like if only the cursor moves
<racarr_> a SurfaceObserver
<racarr_> yeah
<racarr_> and then. the SurfaceObserver interface cant be changed
<racarr_> to RenderableObserver i.e. renderable_added(mg::Renderable), etc
<racarr_> because Unity-Mir uses it
<racarr_> and mir::scene::Surface is NOT a renderable
<racarr_> it just generates one
<AlbertA> so what about a generic notification in Scene::Observer
<AlbertA> like scene_changed...
<AlbertA> so that it's just opaque enough
<racarr_> AlbertA: That's kind of...what im close to giving up and trying...but thats going to make it really hard to implement
<racarr_> partial updates right
<racarr_> because...what could you do
<racarr_> keep around a copy of the old render list
<racarr_> then generate a new one
<racarr_> and diff them?!
<racarr_> it's kind of painful
<AlbertA> you mean partial updates by the compositor? or just a general observer
<racarr_> by the compositor
<racarr_> i.e. the cursor is moving around just paint
<racarr_> tiny regions
<AlbertA> ummm but that's not our compositor architecture
<AlbertA> we do full frame updates
<AlbertA> I mean I envision
<racarr_> I guess I thought we were going to make it smarter and that was part of hte motivation
<AlbertA> once we have a tree
<racarr_> behind
<racarr_> ms::Observer
<racarr_> vs the old
<racarr_> std::function<void()> notify_change
<AlbertA> every change we optimize drawing on the current tree...
<AlbertA> but not damage based composition
<racarr_> maybe...
<racarr_> hmm so with the generic notification
<racarr_> how do prevent double draw.
<racarr_> i.e. surface_changed also generates scene_changed
<racarr_> or is it not really a
<racarr_> "generic" notification but rather like
<racarr_> "scene_changed_in_a_way_the_other_callbacks_dont_represent"
<racarr_> or
<AlbertA> right
<racarr_> does the
<racarr_> compositor just use
<racarr_> scene_changed
<racarr_> and ignore the
<racarr_> sort of damaged based ones
<racarr_> SO MANY OPTIONS SO LOW BLOOD SUGAR
<AlbertA> yeah...good points
<racarr_> haha ok lunch...then I think I am going to come back and get something pumped out with the generic callback..
<AlbertA> but doesn't SurfaceObserver kinda have the same issue right now? I mean if an observer was listening to say orientation_set_to and transformation_set_to
<racarr_> thanks AlbertA anpok :)
<racarr_> AlbertA: ?
<racarr_> oh
<racarr_> yes
<AlbertA> I mean right now they all get collapsed to one notification
<racarr_> but they should be intelligent
<racarr_> for example the cursor controller one is
<racarr_> and doesnt
<racarr_> collapse on
<racarr_> surface attribc change, orientation, etc
<racarr_> because those by themselves
<racarr_> arent enough to
<racarr_> change the actual position
<dandrader> kgunn, alf__: FYI: I've started updating unity-system-compositor/devel-mir-next to latest lp:mir/devel myself as this is blocking me anyway
<kgunn> ack
<racarr_> [       OK ] TestTouchspotVisualizations.touch_is_given_to_touchspot_visualizer (12 ms)
<racarr_> whee
<racarr_> I made...a dumb mistake in all of this
<RAOF> Heh
<racarr_> in that...once I figured out cursor is a renderable...I started thinking about the interface
<racarr_> I would want for touchspots
<racarr_> and realized that
<racarr_> it was exactly the same as the interface that I thought of exposing
<racarr_> as a temporary solution
<racarr_> tounblock thomi
#ubuntu-mir 2014-06-26
<racarr_> but then decided to try and do the right way
<racarr_> but the right and wrong way were actually the same. cest la vie.
<thomi> racarr_: so... you're doing the wrong way? :P
<racarr_> thomi: RAther what I assumed was the wrong way because it was a shortcut of sorts
<racarr_> ...I think is actually the right way :p
<racarr_> and it doesnt matter what order
<racarr_> they go in
<racarr_> ...all shall become clear in MP
<thomi> I look forward to testing it
<racarr_> thomi: Of course part of the mp involves renaming "Surface" to "NotACursor" so it may take a while to land...
<racarr_> kidding :p
<thomi> racarr_: that's ok, the "I'll finish it the week after I get back from Malta" window has well and truly passed by now :P
<racarr_> lol
<racarr_> sorry
<Saviq> AlbertA, hey
<Saviq> AlbertA, we'll need you to run http://people.canonical.com/~msawicz/unity8/strip-u8-tags.sh on your branch (local and remote)
<Saviq> AlbertA, so ./strip-u8-tags.sh lp:~albaguirre/unity8/use-new-display-power-state-interface: /path/to/checkout /path/to/another/checkout
<Saviq> drop the :
<Saviq> AlbertA, the remote one will take quite a while
<Saviq> like 10 minutes
<Nothing_Much> Are there known problems with XMir and radeonSI?
<Nothing_Much> Anybody?
<Nothing_Much> https://bugs.launchpad.net/xmir/+bug/1334050 I'm having stuttering problems with the radeosi driver, just thought I'd let people know about this.
<ubot5> Ubuntu bug 1334050 in XMir "XMir logs out when locking the screen on Ubuntu 14.04 with radeon" [Undecided,New]
<Nothing_Much> *radeonsi
<greyback> Nothing_Much: hey, I don't think we've tested XMir with radeon in a while now (are more focused on mobile at the momemt)
<greyback> thanks for the bug report though
<Nothing_Much> greyback: Oh okay
<Nothing_Much> What kind of mobile chips are you testing on, Qualcomm?
<kgunn> Nothing_Much: iirc, radeon had issues but we corrected them...but it was one of those tail wag the dog...the radeon driver stack changes can effect xmir
<greyback> Nothing_Much: anything that runs with android :) So yeah Qualcomm & Tegra
<kgunn> and like greyback said we've not focused much on xmir lately
<Nothing_Much> oh why not?
<Nothing_Much> kgunn: ^
<Nothing_Much> oh, xmir isn't on mobile so you're just testing out Mir?
<kgunn> Nothing_Much: precisely
<kgunn> Nothing_Much: xmir will feed the rootless X concept...but even that is some distance out on our roadmap from where we are
<Nothing_Much> 16.04?
<Nothing_Much> Or are you saying something else?
<Nothing_Much> kgunn: ^
<kgunn> Nothing_Much: well we still have part of a person looking at rootless x even in the midst of our mobile push...
<kgunn> it would be more of a 15.04-ish target...
<dandrader> alf__, hey
<Nothing_Much> nice
<AlbertA> Saviq: ok I'm running sript-u8-tags.sh
<Nothing_Much> I really would want an Ubuntu Phone that can play Steam games, but that would be only if there's an x86 chip OR if Valve decides to port Steam over to ARM, which the latter would be so much bettter IMO.
<dandrader> alf__, I'm in the way of updating unity-system-compositor/devel-mir-next to latest mir/devel. And I'm finding myself duplicating the code from SurfaceStack. i.e. creating my own SurfaceSceneElement and RenderingTracker equivalents. So I wonder if at least the RenderingTracker shouldn't be a public class...
<dandrader> alf__,  and speaking of RenderingTracker, RenderingTracker::active_compositors is named as a getter IMHO, but it's actually a setter
<Saviq> AlbertA, thanks ideally we'd rebuild u8 to get rid of them in the silo, too, but I can just strip them off trunk again after you land
<alf__> dandrader: One approach to consider is to not mess with scene at all, but just hide the sessions/surfaces that are not needed by USC (i.e., everything but current and next)
<dandrader> SceneElement's rendered_in and occluded_in also sound more like getters...
<alf__> dandrader: If I undestand correctly, USC just wants to show the two sessions
<dandrader> alf__, another thing: Is Scene::scene_elements_for called for every rendered frame?
<alf__> dandrader: yes
<AlbertA> dandrader: alf__: FYI, I don't think that is being used right now since the split greeter is disabled...maybe we can revert the USC scene wrapper for now
<AlbertA> mterry: ^
<dandrader> because in the SurfaceStack implementation it allocates SceneElements on every call. And I always heard that it's a bad thing to allocate memory on every frame (because of the memory allocation overhead). that you should instead reuse it, like in a pool
<dandrader> or is it insignificant as SceneElement is a pretty small class...
<mterry> AlbertA, I'd like to not dismantle that infrastructure.  USC still needs to handle multiple sessions (at least for the boot animation -- and for the desktop use case)
<alf__> mterry: Would hiding sessions other than current and next achieve what you need?
<AlbertA> mterry: ok
<mterry> alf__, we already don't include anything but those in the renderable_list
<mterry> alf__, wouldn't hurt to hide as well...
<mterry> But I'm not sure of the difference between not being in the renderable list and hiding.  Does hiding do extra goodness?
<alf__> mterry: that's the point, instead of explicitly managing the renderable_list (which has become harder due to recent changes), we can hide and achieve the same (with some care ensuring active session is on top)
<alf__> mterry: i.e., we wouldn't need to override Scene at all
<mterry> alf__, got it.  I can't recall a specific reason it wouldn't work to hide instead.
<dandrader> mterry,  ah, ok. so I guess I can just ignore setting the surface visibility then as that's being taken care of by the selecting of who get in the renderable_list, right?
<alf__> dandrader: SceneElement is a lightweight class (and we usually only have a small number of them). Your concern is valid in general, but for now I don't think it causes us any issues (allocators are quite fast). Of course we need to benchmark to really find out if it's worth having a pool.
<mterry> dandrader, sure, I think USC only cares about session visibility, not surface
<AlbertA> Saviq: ok it's done... so do you want me to rebuild the package in silo?
<Saviq> AlbertA, not necessary, depends on how close you are to landing? is there anything missing from you just pressing merge?
<Saviq> AlbertA, ah, it's to-be-published already
<Saviq> AlbertA, then no, I'll just add myself to the landing line so I get notified when it's merged
<AlbertA> Saviq: ok, thanks sorry I didn't now we had to strip tags...
<Saviq> AlbertA, in general we don't...
<Saviq> AlbertA, but there comes a time when someone digs out an old branch that got infected with old lp:unity tags..
<AlbertA> Saviq: so I pull lp:unity from scratch right now..it won't have those old tags?
<Saviq> AlbertA, yup
<Saviq> AlbertA, well, it's enough to just run the script on your local branches
<dandrader> input_sender branch doesn't seem to be working well
<dandrader> I'm getting "terminate called after throwing an instance of 'boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<std::runtime_error> >'
<dandrader>   what():  Failure sending input event :
<dandrader> "
<alan_g> anpok_: ^
<anpok_> i am here
<anpok_> dandrader: when do you get that?
<kdub_> alf__, maybe we could rid of Renderable::id by having the SceneElement remain the same on different calls to generate the scene
 * kdub_ has a different renderable cleanup and was just thinking about it
<dandrader> anpok_, when unity8 calls surface->consume()
<dandrader> anpok_, but apps are also not rendering correctly as well and maliit-server keeps crashing. so there might be some other issue there
<dandrader> anpok_, so *right now* I cannot guarantee that I didn't mess up something on  my side. but it does raise a concern
<dandrader> because yesterday, lp:mir/devel + expose_android_input was working fine...
<dandrader> and I'm getting those issues with lp:mir/devel + input_sender
<dandrader> I will dig more into this to be certain
<anpok_> hm, ok. odd that there is no errno string in the exception
<anpok_> can you tell me which of unity8 I have to look at?
<dandrader> anpok_, it's a whole bunch of branches you have to build, not just unity8. so it takes a while to have the whole everything built :(
<dandrader> ie: qtmir, qtubuntu, platform-api, unity8, unity-system-compositor
<dandrader> besides mir, of course :)
<alf__> kdub_: it's plausible, depends on what the id() is used for
<kdub_> alf__, yeah, maybe? part of the getting the demo shell to play nicely with hwc? still assessing
<kdub_> josharenson, I'm starting a performance improvement that might be a good thing to measure/test out the client ui performance stuff
<kdub_> are those ui performance examples/tests in CI or some branch?
<josharenson> kdub_ explain?
<kdub_> I heard that there are some UI benchmarks floating around, which would be good for me to measure the branch... and perhaps good for improving or testing those benchmarks
<dandrader> anpok, this is what we're getting http://pastebin.ubuntu.com/7707082/
<dandrader> and the locals on frame #10 http://pastebin.ubuntu.com/7707086/
<anpok> error_status
<greyback> -9
<greyback> whatever that is
<anpok> could be EBADF
<greyback> I don't see that in 3rd_party/android-deps/std/Errors.h tho
<anpok> it reads errno .. and if it is one of the errors it does not handle it retuns -errno
<anpok> (it == android::InputChannel)
<Saviq> AlbertA, kgunn, any reason why I should not merge&clean silo 20?
<AlbertA> Saviq: I was about to...:)
<AlbertA> Saviq: but go ahead
<Saviq> AlbertA, doing
<Saviq> AlbertA, don't pull from unity8 for a few mins, stripping the tags
<AlbertA> Saviq: sure, thanks
<Saviq> AlbertA, sorry for not being more involved with that work, you've done a grand job there!
<AlbertA> Saviq: np, cheers!
#ubuntu-mir 2014-06-27
<RAOF> Urgh.
<anpok> hi
<RAOF> gcc, I'm *pretty* sure 1024 * 256 is not a narrowing conversion from int to unsigned long.
<anpok> RAOF: btw gave up on i915 for a while now - the code we added is never used by that driver..
<RAOF> ...!
<RAOF> Bargh. Why did they copy it when they forked it then?!
<anpok> havent looked at the details it goes through a few calls marked as "old.."..
<anpok> at some point i want it to be fixed - that netbook I have should run mir in the end..
<anpok> so maybe a weekend project
<greyback> anpok: hey, have you time to investigate our crasher with the input sender?
<anpok> greyback: yes
<anpok> -> https://code.launchpad.net/~andreas-pokorny/mir/main-loop-should-not-claim-ownership-of-fds/+merge/224751
<greyback> anpok: ah cool, will pull and test
<anpok> i forgot to change that part of mainloop within just-unregister-fd
<tvoss> greyback, is your launchpad nick greyback, too?
<alan_g> anpok: fix typo and you're goo to go
<alan_g> *good
<greyback> tvoss: nope 'gerboland'
<greyback> anpok: fix confirmed
<greyback> thank you!
<anpok> oh great typo that is
<alan_g> tvoss|food: wrong target or need to rebase? https://code.launchpad.net/~thomas-voss/mir/explicit-gcc-version/+merge/224773
<greyback> alf__: lp:~afrantzis/unity-mir/fix-1332624-input-area <- approved
<alan_g> The following tests FAILED:
<alan_g> 	  7 - mir_acceptance_tests.ClientSurfaceEvents.* (SEGFAULT)
<alan_g> Rats! I had an old core file. :(
<anpok> re
#ubuntu-mir 2015-06-22
<bschaefer> hello, so im running into an interesting issue.
<bschaefer> on a barebone system, i've set up a lightdm session that runs unity-system-compositor, the mir server starts up just fine
<bschaefer> but when i attempt to run a demo on it by (export MIR_SOCKET=/run/lightdm-mir-0) it only renders the first frame
<bschaefer> then goes black
<bschaefer> soo things that take a second to swap buffers last longer such as the eglflash
<bschaefer> so after the first swap buffers nothing else renders
<alan_g> bschaefer: a Mir server connects to USC and a client to that server? Or you're connecting the client direct to USC?
<bschaefer> alan_g, hmm im connecting directly the socket that was produced by USC
<bschaefer> /usr/sbin/unity-system-compositor.sleep --file '/run/lightdm-mir-0' --from-dm-fd 12 --to-dm-fd 15 --vt 7 --enable-hardware-cursor=true
<alan_g> bschaefer: I can't remember the details but USC gets instructions what to display over dbus
<bschaefer> alan_g, i suppose i dont see a mir server it self running processes wise, but i kind of though USC was a server? (Since it had a cursor)
<alan_g> bschaefer: it is
<bschaefer> alan_g, o .. hmm who would be good to poke about that?
<bschaefer> As it would be nice to connect directly, but if i need to go through dbus
<alan_g> bschaefer: on recent versions of USC you can "bypass" the dbuss stuff with --debug-without-dm & --debug-active-session-name <name client connects with>
<alan_g> But that's not intended for production scenarios
<bschaefer> alan_g, name client connects with being the username?
<bschaefer> alan_g, well shots, as this would be for a kiosk type system
<bschaefer> where we have no unity8
<alan_g> bschaefer: No, the name it gives in the connection call
<bschaefer> o i see, i can give that a try to figure out if thats the issue
<bschaefer> thanks!
<AlbertA> vogons: I think we'll have to merge this one manually: https://code.launchpad.net/~michael.nelson/mir/snappy-packaging-fix-makefile/+merge/262415
<alan_g> AlbertA: +1
<camako> AlbertA, because the dest (sanppy-packaging branch) is not configured for autolanding? Makes sense.
<bschaefer> alan_g, USC doesn't seem to know those args
<alan_g> bschaefer: I guess they haven't hit archive yet
<bschaefer> alan_g, yeah thats what i was thinking shoot
<bschaefer> yeah im running 15.04
<bschaefer> (in the VM)
<bschaefer> alan_g, i just find it strange i get 1 frame (which would be a poor security authenticator)
<bschaefer> if 1 frame keeps leaking
<alan_g> Yes, that would be a bug
<alan_g> Could you use mir_demo_server instead of USC? (Although the 0.14 series would be more useful)
<alan_g> Or do you need e.g. the display manager support
<alan_g> ?
<bschaefer> alan_g, i need the ... upstart session
<bschaefer> from lightd
<bschaefer> lightdm ---> usc
<bschaefer> IIRC
<bschaefer> as i need the dbus session for the ubuntu SDK
<alan_g> In that case you need to get the display manager to tell USC to show your client.
<bschaefer> alan_g, how does one do that? dbus?
<alan_g> AlbertA: have you looked at how that^ happens?
<bregma> what is the difference between the display manager and USC?
<bschaefer> AlbertA, i have an entire ubuntu 15.04 image with the issue on it :) (reproducible)
<alan_g> bregma: I think that's what the --from-dm-fd  --to-dm-fd sockets given to USC connect to
<bschaefer> what is the display manager then? Do i even have one?
<bschaefer> or the USC is doing that, and passes that to the mir server?
<bregma> LightDM is the display manager
 * alan_g thinks it is intended (by someone long ago) behaviour
<bschaefer> i see
<bregma> LightDM == "light display manager"
<bschaefer> duh
<bregma> but all LightDM should do is fork off USC and pass its socket name into the session
<bregma> USC should be the display server
<bschaefer> right, but something has to be *actively* causing the demos to render black (or render over the client)
 * bschaefer assumes the background could be rendering over the client
<bregma> but if it's been too intimate with its first cousin Unity8 there may be a problem
<bschaefer> yeah
 * bregma cues up some banjo music
<bschaefer> haha
<bschaefer> bregma, maybe theres some argument i can add to lightdm
<alan_g> So USC gets told (over dbus I think) "active-session-name='something'" and then 'something' is allowed to show
<bschaefer> to idk...something
<bschaefer> alan_g, i see
<bschaefer> i could attempt to figure out how to send dbus message to USC
<alan_g> But I've only seen the USC end of the code
<alan_g> (And stubbed it out for debugging)
<bschaefer> alan_g, would that be RAOF department? I could always poke him later today
<AlbertA> alan_g: I don't remember at the moment....
<AlbertA> bschaefer: yeah he'll most likely point you in the right direction :)
<alan_g> I'm not sure. I know alf_ reworked some of the dbus internals and AlbertA looked at some related parts of the stack.
<bschaefer> AlbertA, cool thanks!
<bschaefer> yeah... ill try to send some dbus stuff through to test around
<AlbertA> bschaefer: or mterry may also know
<bschaefer> alan_g, were those args you gave before for dbus or the command line args when starting the server
<bschaefer> i think seb was also working with lightdm/unity-next stuff
<alan_g> They're USC command line (to bypass all the dbus stuff so I could run the damn thing as  Mir server)
<bschaefer> alan_g, yeah they must not be in main yet :(
<bschaefer> thanks again!
<alan_g> yw
<AlbertA> bschaefer: well in touch - it is whoever calls usc-wrapper in /usr/share/ubuntu-touch-session....
<bschaefer> AlbertA, for .. the dbus stuff?
<bschaefer> AlbertA, i wont have that though since im not using unity8
<AlbertA> bschaefer: no I mean the --from-dm-fd --to-dm-fd options
<bregma> or ubuntu-touch
<bschaefer> i think at this point i just need to figure out ... what unity8 is doing
<bschaefer> that it no longer is doing that is required for rendering
<bschaefer> as i need to fill in those roles if needed
<bregma> does USC only work if it's hosting a nested Mir server maybe?
<bschaefer> AlbertA, bregma those folders dont exists on my VM
<bschaefer> bregma, maybe i need to start a "session" server?
<bschaefer> ie. nested...
<alan_g> bregma: it works as long as something supplied  "active-session-name='something'" and it gets a session called 'something'
<bschaefer> the session is named session-0
<bschaefer> i get that from logs
<bregma> too much mystery here
<bschaefer> maybe the active session isn't being set
<bschaefer> haha yeah...
<AlbertA> bschaefer: maybe you can reverse engineer from here :)
<AlbertA> http://bazaar.launchpad.net/~phablet-team/ubuntu-touch-session/trunk/files
<bschaefer> AlbertA, ill see what i can find! Thanks!
<bschaefer> http://bazaar.launchpad.net/~phablet-team/ubuntu-touch-session/trunk/view/head:/52-ubuntu-touch.conf
<bschaefer> looks like thats doing something lightdm related
<bschaefer> seb128, heeey, soo did you have any issues with lightdm/USC and rending?
<bschaefer> rendering*
<seb128> bschaefer, ECONTEXT
<seb128> when?
<bschaefer> seb128, :), soo
<seb128> using what?
<bschaefer> right, let me fill you in
<seb128> :-)
<bschaefer> so, i've a 15.04 system. I've install lightdm/USC and configured it such that USC is running on boot (and auto logins)
<bschaefer> i see the hardware cursor
<bschaefer> seb128, from there when i run a demo client i only see 1 frame rendered before it goes black
<bschaefer> seb128, my guess is you didnt run into this since you're using unity8 which fills in those holes
<seb128> right
<bschaefer> but wanted to double check :)
<bschaefer> cool, soo it has to be something unity8 is doing
<bschaefer> ill dig through what AlbertA gave me
<bschaefer> AlbertA, so interestingly if i set the spinner to a mir demo client it renders fine
<bschaefer> soo im assuming the USC is rendering its own surface that is being forced to the top
<bschaefer> drawing over the demos when they are first asked to render on the USC
<AlbertA> bschaefer: yeah USC has logic to either show "the spinner" when there's no session active
<AlbertA> or hide it
<AlbertA> once a session name arrives and its activated
<bschaefer> AlbertA, soo i think thats the issue then... how do we "start the session"
<bschaefer> alan_g|EOD, was talking about it
<AlbertA> bschaefer: that's the part I'm not familiar with...it's a message that arrives through that dm socket
<AlbertA> specified when usc is started....
<AlbertA> but I'm not sure who sends it
<bschaefer> AlbertA, cool, thanks! (slowly making progress haha)
<AlbertA> bschaefer: so examining processes in ubuntu-touch phone device
<AlbertA> it's a pipe,
<AlbertA> with lightdmroot at one end
<AlbertA> lightdm...sorry
<AlbertA> not sure if that helps :)
<bschaefer> AlbertA, all info is helpful :)
<bschaefer> soo a pipe from lightdm ... so bregma was thinking it was a rasied signal
<bschaefer> that USC was waiting for
<bschaefer> that unity8 usually does when its up and running
<AlbertA> bschaefer: no a message containing the expected session name is received..
<AlbertA> and the session name is "session-0"
<AlbertA> through that pipe...
<bschaefer> hmm bregma is talking about logind now
<bschaefer> which would
<bschaefer> write to that FD
<bregma> bschaefer, it's LightDM that writes the sessionId
<bregma> I dunno where LightDM gets it from yet, but I'm assuming it;s related to logind or similar
<bschaefer> well i have:
<bschaefer> [+0.14s] DEBUG: Session pid=803: Started with service 'lightdm-autologin', username 'ubuntu'
<bschaefer> [+0.17s] DEBUG: Seat seat0: Session authenticated, running command
<bschaefer> [+0.17s] DEBUG: Registering session with bus path /org/freedesktop/DisplayManager/Session0
<bschaefer> things like that
<bschaefer> im not sure if...
<bschaefer> the session starting from lightdm "means" the session we want
<bregma> bschaefer, is that from /var/log/lightdm?
<bschaefer> bregma, yeah
 * bschaefer pastes the whole log
<bschaefer> http://paste.ubuntu.com/11758128/
<bregma> bschaefer, what does /usr/bin/mir-barebone-session do?
<bschaefer> bregma, simple: http://paste.ubuntu.com/11744099/
<bschaefer> starts upstart
<bschaefer> and set a couple ENV vars
<bregma> the log in the pastebin shows LightDM activates session c1, which means it sends the required stuff to USC over the aforementioned socket of love
<bschaefer> http://bazaar.launchpad.net/~phablet-team/ubuntu-touch-session/trunk/view/head:/ubuntu-touch-session
<bschaefer> which does a few more things but nothing i saw we needed needed
<bschaefer> bregma, this is the USC log: http://paste.ubuntu.com/11758157/
<bschaefer> the biggest thing i see is: set_active_session 'session-0'
<bschaefer> which means ... i seems to be getting set the active session
<bschaefer> AlbertA, ^
<bschaefer> it seems*
<bschaefer> which means the spinner should stop but hmm
<bschaefer> maybe something else is missing
<bregma> I'm wondering if something needs to tell USC to switch to the next session, since the spinner is the first session?
<bschaefer> that makes sense
 * bschaefer looks at unity8
<AlbertA> bschaefer: right, so once the mir client connects...it checks if the name matches the given session name...and shows that....
<AlbertA> hides the spinner...
<bschaefer> AlbertA, this would be done in lp:unity8? most likely?
 * bschaefer hopes
<AlbertA> bschaefer: probably qtmir
<bschaefer> it could be done when it creates its nested server...
<bschaefer> AlbertA, o right, cool thanks ill look through there
<AlbertA> probably names it session-0
 * bschaefer hopes it gets grepped
<bregma> the term 'session' seems to be woefully overloaded here
<bschaefer> AlbertA, no hard coded "session-0"
<bschaefer> very
<bregma> we should call everything a 'thing'
<bregma> Thing 1 and Thing 2
<bschaefer> that would make more sense, since thing doesnt mean anything explicitly...
<bregma> neither does 'session' at this point
<bschaefer> yeah
<ogra_> bregma, that has a nice ring to it ! i'm all for it ... espectially shine everything will then have an internet too :)
<ogra_> *since
<AlbertA> bschaefer: so probably an upstart configuration?
<bschaefer> 1188 results found for session
<bschaefer> AlbertA, oo good idea, i can check around
<bregma> http://www.cliparthut.com/clip-arts/350/thing-1-2-350883.jpg
<ogra_> haha
<bschaefer> haha
<AlbertA> hehe...
<ogra_> though i think we should namespace them "that thing", "other thing" ... istead of just numbering ... thats so unpersonal
<davmor2> bregma: there are always 2 things
<bschaefer>         gdbus call --session --dest org.freedesktop.DBus --object-path /org/freedesktop/DBus --method org.freedesktop.DBus.UpdateActivationEnvironment "@a{ss} {'MIR_SOCKET': '$MIR_SERVER_FILE'}"
<bschaefer> looks somewhat ...
<bschaefer> o nm
<bschaefer> thats to point to a different mir socket
<davmor2> bregma: https://www.youtube.com/watch?v=biW9BbWJtQU
 * bregma raised a passel of kids and is only too familiar with the trouble caused by Things
<bschaefer> bregma, if you look at /usr/share/upstart/unity8.conf
<bschaefer> we might need something like this
<bschaefer> it raises the signal
<bschaefer> im not 100% sure if that dbus signal is needed
<bschaefer> USC could wait for that dbus call
<bschaefer> for all we know :(
<bschaefer> bregma, i could try to ... make a eglplasma upstart conf
<bschaefer> where it exec a mir demo instead of unity8 and see what happens...
<bschaefer> (hopefully it'll stop the demo)
<bregma> I see no signal in that file?
<bschaefer> bregma, o duh i mean:
<bschaefer>     # Tell unity-mir to raise SIGSTOP after we start
<bschaefer>     initctl set-env UNITY_MIR_EMITS_SIGSTOP=1
<bschaefer> soo we'll have to create a program that
<bschaefer> does that...
<bregma> bschaefer, you can try sending a SIGSTOP from the command line, but I suspect that whole SIGSTOP thing is at a higher level than running a Mir demo on USC
<bschaefer> if its even needed... i suppose i should look at USC
<bschaefer> bregma, possibly
<bschaefer> never hurts to try...
<bschaefer> bregma, you send the signal at USC right?
<bregma> bschaefer, I do no such thing
<bschaefer> bregma, haha...
<bschaefer> i mean the signal needs to be sent to USC?
<bregma> I do not believe so
<bregma> I see nothing in the code that catches SIGSTOP
<bregma> I think the whole SIGSTOP thing is a u-a-l thing
<bregma> we're trying to avoid that level
<bschaefer> yeah
<bschaefer> and sending a sigstop at UCS... (i cant believe it does this) but stops the spinner anything else trying to render :(
 * bschaefer inserts sarcasm above
<bschaefer> bregma, im just going to look at USC to see if see a wait
<bschaefer> or see something talks to it to ... idk stop the spinner stuff
<bschaefer> onces the spinner hides everything shuld work
<AlbertA> bschaefer: USC receives a session name, stores it internally
<AlbertA> then when somebody connects to USC (i.e. mir_connect(...) )
<AlbertA> that connection api takes a name...
<AlbertA> when it makes it to the server...USC checks if that session name is the active session or not...
<AlbertA> if it's not then it's not shown
<bschaefer> AlbertA, shouldnt i be getting a denied somewhere then?
<bschaefer> it continues to run that app just fine
<AlbertA> bschaefer: it probably should be denied...but it's just simply not shown
<bschaefer> yeah
<AlbertA> http://bazaar.launchpad.net/~unity-system-compositor-team/unity-system-compositor/trunk/view/head:/src/session_switcher.cpp
<AlbertA> http://bazaar.launchpad.net/~unity-system-compositor-team/unity-system-compositor/trunk/view/head:/src/session_switcher.cpp#L95
<bschaefer> AlbertA, i was just looking through that file
<bschaefer> i just dont know how to "add" a sesssion to it
<bschaefer> AlbertA, and it looks like session-0 is being added (which could just be the spinner it self)
 * bschaefer tracks down how something would actually add
<AlbertA> bschaefer: right so that part is ok...
<AlbertA> the part that you will be missing is when your client connects to usc...
<AlbertA> that session name
<AlbertA> should match the session name given by lightdm
<bschaefer> AlbertA, is there something you can add to clients like --session-name? haha
<bschaefer> AlbertA, so if i run a client on the command line, what session name would it have?
 * bschaefer assumes undefined i suppose
<AlbertA> bschaefer: right...currently
<AlbertA> it's mir_connect(..., app_name)
<AlbertA> app_name = "egldemo"
<bschaefer> and the ... is the socket path
<bschaefer> but theres no session name
<AlbertA> so you should probably be able to see that in the unity system-compositor log
<bschaefer> ooo
<bschaefer> AlbertA, that makes sense: Opening session egldemo
<bschaefer> i've been seeing that
<bschaefer> soo i need to add egldemo to the session list
<bschaefer> (somehow)
<AlbertA> either that...or change the name in the examples.... :)
<bschaefer> haha true :)
<bschaefer> AlbertA, but ideally, there would be some sort of dispatcher that would run any client and add each session name
<bschaefer> to the USC session list
<bschaefer> ./launcher_app <mir_client>
<bschaefer> but then...
<bschaefer> thats pretty much what unity8 does with UAP
<AlbertA> bschaefer: yeah...just don't know what that is....
<AlbertA> :)
<bschaefer> IIRC
<bschaefer> AlbertA, cool, thanks for the help!
<AlbertA> bschaefer: np
<AlbertA> bschaefer: oh BTW...the name used for nested...is configurable through --name or I suppose also MIR_NAME
<AlbertA> so somewhere, there should be a MIR_NAME=session-0
<bschaefer> AlbertA, but we dont have a nested server atm... do we NEED a nested server?
<AlbertA> the nested configuration will use that to specify the connection name to the host server
<AlbertA> bschaefer: no...just in case you want to figure who is setting that connection name in the case of unity8
<bschaefer> AlbertA, oo right, thanks!
 * AlbertA heads out to late lunch
<bschaefer> AlbertA, after further looking into things... we are just going to use the mir_demo_server for the server (for now)
<bschaefer> until we look at re-making the USC (as we need a super basic server)
<bschaefer> the only issue i can see is the mir socket needs permissions for a user to run a demo on it
<bschaefer> (ie. i need to do chmod 777 /run/mir_socket)
<bschaefer> robert_ancell, hey, i've got a lightdm question. Try to create a bar minimal mir server (right now just attempting with the mir_demo_server). The only
<bschaefer> issue is its not getting to the session part, where upstart get started
<robert_ancell> bschaefer, what does lightdm.log say?
<bschaefer> if i use a config to start USC its fine and the session script starts
<bschaefer> robert_ancell, its loads the mir server fine
 * bschaefer looks again
<bschaefer> just not the session script
<robert_ancell> bschaefer, what is the contents of the session .desktop file?
<robert_ancell> And using autologin?
<bschaefer> robert_ancell, http://paste.ubuntu.com/11744105/
<bschaefer> robert_ancell, yup autologin
<robert_ancell> That looks good
<bschaefer> robert_ancell, http://paste.ubuntu.com/11759515/
<bschaefer> robert_ancell, nothing to crazy, and the mir server did start
<bschaefer> the only difference is i skip the $@ arguments when i run the mir_server
<bschaefer> vs USC
 * bschaefer pastebins the lightdm conf
<bschaefer> robert_ancell, http://paste.ubuntu.com/11759518/
<bschaefer> if i do the run-mir-* it does no run the session script
<bschaefer> if i run the USC wrapper the session script runs
<bschaefer> (big issue being that upstart doesnt start)
<robert_ancell> bschaefer, oh, you don't want to run a compositor at all, i.e. just a single Mir server?
<bschaefer> robert_ancell, yup!
<robert_ancell> bschaefer, have you set up permissions so a user can run mir_demo_server fine?
<bschaefer> robert_ancell, thats an issue, and we were thinking of creating a small USC type program
<bschaefer> that will manually 777 the socket (like USC does)
<bschaefer> robert_ancell, is that the issue?
<robert_ancell> bschaefer, the main issue is getting access to /dev/input
<bschaefer> robert_ancell, the server works besides the mir socket it self needing 777 manually
<bschaefer> cursor input (this is in a VM as well)
<robert_ancell> ok, should be all set up then I guess
<bschaefer> robert_ancell, the only issue is i cant get upstart --user to run
<robert_ancell> bschaefer, why do you need upstart?
<bschaefer> since the session script doesn't work with i just run my mir demo (which upstart is needed for the dbus session for the ubuntu SDK)
<robert_ancell> ah
<bschaefer> fun stuff going against everything mir is atm :)
<bschaefer> USC depends on unity8 to do stuff soo figured it might be easier to do a simple server
<bschaefer> but now ... im not 100% sure why the session script ie. mir-barebone-session doesn't run
<bschaefer> if and only if i run the mir-demo-server, if i run USC the session script runs fine
<robert_ancell> bschaefer, it might be easiest to make a simple compositor (i.e. mir-barebone-compositor)
<bschaefer> robert_ancell, well what does lightdm need? The umm
<robert_ancell> It wouldn't have to do much, just take USC and gut out everything
<bschaefer> --from-dm-fd 12 --to-dm-fd 15
<robert_ancell> bschaefer, LightDM just needs to be able to tell the compositor which session to set as active
<robert_ancell> yeah, and theres a small binary protocol that runs over that
<bschaefer> robert_ancell, hmm i see, and with out that, it wouldn't know that the session is set as active?
<bschaefer> meaning it never runs the session script?
<bschaefer> (since its not active?)
 * robert_ancell looks
<robert_ancell> but yes, there is some signalling across that
<bschaefer> robert_ancell, what would be required for a barebone compositor?
<bschaefer> err rather what library/dbus interface do i need to hook up with
 * bschaefer guess USC has all that is needed
<robert_ancell> ah, yes. LightDM waits for the compositor to say it is "ready"
<bschaefer> robert_ancell, i see, thats all i really need?
<bschaefer> to get the session to be active?
<robert_ancell> bschaefer, The compositor has two messages to send to LightDM - READY (i.e. started) and SESSION_CONNECTED (i.e. the child Mir server has connected to the compositor)
 * bschaefer is trying to avoid the whole USC session list/accept stuff
<bschaefer> robert_ancell, hmm so if i only use 1 mir server.. i suppose once lightdm starts up the mir server i can just send both
<bschaefer> since i dont need a nested server
<robert_ancell> A barebone compositor would just have to accept all connections, make their surfaces fullscreen and switch between them on request of LightDM
<robert_ancell> Yes, you could just fake it and LightDM would be fairly happy
<bschaefer> robert_ancell, cool thanks ill look into making that :)
<bschaefer> robert_ancell, i mean ... i dont think i need i need a nest server?
 * bschaefer doesn't 100% understand why i would need one
<bschaefer> robert_ancell, mainly my goal is to create a snappy image such that a bare bone mir server is running
<bschaefer> and the ubuntu SDK works on it
<robert_ancell> You can use one server in theory, but that requires LightDM to be more aware of how that would work.
<bschaefer> allowing for a kiosk type system to be set up
<robert_ancell> Sure
<bschaefer> robert_ancell, as long as i can fake it atm
<bschaefer> i think that'll be good
<bschaefer> just need to send the right signals off
<robert_ancell> My guess is based on the current setup a simplistic compositor will be the easiest path
<bschaefer> robert_ancell, yeah sounds reasonable, it would start the mir server it self?
<bschaefer> vs the mir_demo_server
<bschaefer> just like USC?
 * bschaefer would prefer that anyway
<bschaefer> so i can change the socket to 777
<robert_ancell> The sockets would all be set up correctly so you wouldn't have to do any hacks there
<bschaefer> robert_ancell, USC set the socket to 777 it self :)
<robert_ancell> Yes, there's an open bug about doing it properly :)
<bschaefer>  system_compositor.cpp:111:            if (server->public_socket() && chmod(server->get_socket_file().c_str(), 0777) == -1)
<bschaefer> :)
<bschaefer> robert_ancell, but cool i can dig through that and rip out everything that is not needed
<bschaefer> thanks!
<robert_ancell> np, let me know how you go
<bschaefer> will do, ill most likely get stuck somewhere along the way
#ubuntu-mir 2015-06-23
<seb128> hey there
<seb128> where would I find details about mir not starting in an unity8 session?
<seb128> .cache/upstart/unity8.log states "ERROR: QMirServer - Mir failed to start"
<seb128> but no detail
<olli> camako, ^
<seb128> olli, thanks ;-)
<olli> also got a question... is there a mini pc system you guys would recommend that works oob w/ Mir
<seb128> log on http://paste.ubuntu.com/11763124/
<kdub> olli, not sure about the system... if its supported by mesa well and has been around a while, i'd say that increases the chances
<kdub> seb128, it does look like a problem with input_stub.so... don't know if that's changed recently, or if its an installation thing
<seb128> kdub, that line is only a warning though?
<seb128> the error looks like https://bugs.launchpad.net/ubuntu/+source/mir/+bug/1458689
<ubot5> Launchpad bug 1458689 in mir (Ubuntu) "[vivid-overlay] input-stub.so fails to load on i386" [Undecided,Confirmed]
<kdub> hmm, maybe whatever fixed it isn't in overlay... (not familiar with the problem)
<kdub> anpok, any ideas?
<seb128> kdub, I'm using wily
<alan_g> That looks like a problem I've seen when "server-platform" has drivers from Mir 0.12 while the executable is from Mir 0.14
<seb128> so I guess it's just > vivid
<seb128> that seems a redherring
<seb128> I've moved input-stub.so away, same error abotu mir failed to start
<seb128> olli, I'm a bit stuck on snappy personnal/unity8 and that mir not starting, if you can suggest/find somebody to help debugging that would be useful ;-)
<seb128> it's probably a topic for tomorrow rather than today now though
<olli> seb128, it's kind of getting late over therr
<olli> there
<seb128> olli, yeah, as said, a tomorrow topic
<olli> camako, kdub, alan_g|EOD, dandrader, greyback all should be in a position to help
<seb128> I can try in the morning, maybe some of the .au guys are still around and have a debug idea then
<seb128> k
<seb128> let's see if I've more luck tomorrow then
<seb128> olli, thanks
<olli> seb128, sorry, no idea why this channel went dark
<seb128> likely people busy and not watching IRC ;-)
<camako> seb128, Sorry I thought discussion was ongoing
<camako> I see it's stalled..
<dandrader> not sure I can help. I know pretty much nothing about snappy
<seb128> dandrader, it's not really a snappy issue
<kdub> has usc started?
<seb128> dandrader, it's just that unity8 fails to start with the pastebin I gave earlier
<camako> seb128, try to catch anpok tomorrow. He recently fixed it in the devel branch
<seb128> I can start the demo shell from ssh and use gtk apps in it
<dandrader> seb128, think I missed the pastebin url
<seb128> unsure if I can start unity8 manually and how
<seb128> <seb128> log on http://paste.ubuntu.com/11763124/
<seb128> dandrader, ^
<dandrader> "undefined symbol: _ZN3mir6events10make_eventEll17MirKeyboardActionjij"
<seb128> yeah, I moved that .so away
<seb128> same issue
<seb128> and the demo shell is starting
<seb128> so I think it's not blocking the server to start
<seb128> that's wily btw
<seb128> I should maybe try if unity8 works on a normal deb system atm or if mir/unity8 are just busted on desktop for everyone
<dandrader> hmm... it's been a while since I last tried running unity8 on the desktop. Gerry (greyback) would be the best person to ask, as I think he has done a lot of "unity8 on desktop" work recently but he's on holidays this week.
<seb128> k
<kdub> also, if you look at the --help for a demo server
<kdub> any of those debug options can be prepended with MIR_SERVER_<option>=<value> in the environment variable
<kdub> to get more info
<seb128> the demo server work
<seb128> I can start it fine and start a gtk application
<seb128> and use it
<seb128> it's unity8 which fails
<seb128> and I'm unsure how to debug that
<seb128> starting it from a vt like the server doesn't work
<seb128> and starting it as a client with the demo server socket exported either
<kdub> well, something like MIR_SERVER_DEBUG=true might give more clues
<anpok> oh input-stub not linking to mir client
<seb128> https://bugs.launchpad.net/ubuntu/+source/mir/+bug/1458689 suggests it has a fix
<ubot5> Launchpad bug 1458689 in mir (Ubuntu) "[vivid-overlay] input-stub.so fails to load on i386" [Undecided,Confirmed]
<anpok> could input-stub be outdated?
<seb128> but maybe that didn't land in wily yet
<anpok> ah right alan fixed that
<anpok> yeah time for a release
<anpok> seb128: on which hardware do you try to start?
<seb128> anpok, dell inspiron 11 3000
<seb128> but that's my test machine for unity8 for some cycles, works fine usually
<seb128> and the mir demo server works fine as well atm
<seb128> so I think it's not a driver/mir compat issue
<seb128> I'm just trying to get the new snappy personal image working
<seb128> it could be an issue in the image or some missing permissions/files, but not sure how to debug it
<anpok> but you dont run it through kvm?
<anpok> oh ok you do
<seb128> no, I don't, it's a real machine booting on an usb key
<olli> how good or bad is Intel Iris 6100 supported atm?
<anpok> hm
<anpok> seb128: do you see anything interesting in ~/.cache/upstart/unity8.log*?
<anpok> I just tried to launch it non-nested: and I got what():  Nested Mir Display Error: Failed to update EGL surface: EGL_BAD_DISPLAY (0x3008)
<anpok> which should not happen
<anpok> is qtmir somehow requiring to be stared nested?
<anpok> seb128: do debug the startup - you could try what /usr/bin/ligthdm-unity8-session does .. but for that you first need to start some mir server.. mir_demo_server ... or usc (with --from-dm 0 --to-dm 1) and --file something ..
<anpok> s/do/to
<seb128> anpok, http://paste.ubuntu.com/11763124/ is the unity8.log
<anpok> oh
<seb128> starting the mir server and then a gtk application works
<seb128> unsure how to start unity8 saying to use the mir server
<seb128> unity8 is a mir compositor no?
<anpok> yes a nested one, the shell script /usr/bin/lightdm-unity8-session shows which environment variables to set..+ you need to set MIR_SERVER_HOST_SOCKET and set it to the socket path specified as --file  param to the mir server.
<anpok> seb128: or..
<anpok> add the environment variables: MIR_SERVER_{DISPLAY_REPORT,COMPOSITOR_REPORT,CONNECTOR_REPORT,MSG_PROCESSOR_REPORT,SESSION_MEDIATOR_REPORT}=log to that ligthdm session script
<bschaefer> hello, does qtmir talk to USC, or does qtmir do the entire compositing thing?
<bschaefer> as it seems to create a platform/mirserver (not sure if it ends up talking to USC or its just the actual nested server unity8 starts up)
<anpok> the nested server talks to the mirserver in usc
<bschaefer> anpok, cool thanks!
 * bschaefer trying to understand the USC/nested server stack...
<anpok> but the plan is of course to delay the composition as much as possible and offload as much as possible onto android overlays/hardware planes
<anpok> but right now a nested server just emits a single buffer for its surface
<bschaefer> yeah it looks pretty simple mir server wise
<bschaefer> as the USC does a lllot more
<racarr> AlbertA: Please do. Thanks :)
<racarr> re papi pushing
<AlbertA> racarr: thanks
<bschaefer> robert_ancell, soo looking at making a barebone compositor ... leads me to wondering where/who does the actual setting of a session?
<bschaefer> ie. i see asio handling it, but who sends it the messages?
<robert_ancell> bschaefer, setting of the active session?
<bschaefer> robert_ancell, right, as ... i see this "opening session mirdemo"
<bschaefer> but i only 1 see frame
<bschaefer> then it goes back to the spinner/black
<bschaefer> robert_ancell, if im using USC
 * robert_ancell looks at the u-s-c repo
<bschaefer> robert_ancell, as i cant seem to get the session handler to allow the mirdemos to render (for more then 1 frame)
<bschaefer> do i just need to send SESSION_CONNECTED? (I also dont see that message doing anything in lp:lightdm expect log it)
<robert_ancell> hmm, I don't know how the WindowManager stuff works. That's all new since I last worked on USC.
<bschaefer> i see, shoots, as it would be nice to get USC working in a standalone way
<bschaefer> vs creating a barebone which shares a lot of the same code
<robert_ancell> bschaefer, right, we're not waiting for the session to connect in LightDM, so you shouldn't need that (at the current time)
<bschaefer> robert_ancell, the over difference i see is mir remove the default config that was once ued
<bschaefer> robert_ancell, right, soo i hacked it so it ensures the spinner to hide
<bschaefer> but it still only renders 1 frame then goes black
<bschaefer> robert_ancell, cool, thanks ill have to dig around some more!
<robert_ancell> bschaefer, if you pull in an old version of u-s-c it didn't have a spinner. So all that extra UI might be complicating things
<bschaefer> robert_ancell, true, i should find a version that was after the mir/default_server_config was remove
 * bschaefer tries
<bschaefer> robert_ancell, shoot, the spinner was added back when  #include <mir/default_server_configuration.h>
<bschaefer> still existed
 * bschaefer tries a newer version
<bschaefer> robert_ancell, soo looking at the USC code some more, it seems that the message set active session is sent from lightdm? (or the DM fd)
<bschaefer> from_dm_pipe is what is hooked into for on_read_payload, which then it can receive events such as
<bschaefer>  USCMessageID::set_next_session
<bschaefer> robert_ancell, is that just done simply when reading the seat default config files?
#ubuntu-mir 2015-06-24
<u_glide> Hello folks! How I can join to alpha testing of https://www.youtube.com/watch?v=c3PUYoa1c9M&feature=youtu.be&t=2m45s ?
<mcphail> Hi. I'm trying to force landscape orientation in an SDL2 game on Ubuntu Phone. I've found I can obtain a MirConnection* and a MirSurface*, and was wondering if either of those pointers are worth investigating to force a change in orientation? I don't know much about Mir and don't want to be chasing a dead-end
<duflu> mcphail: Yes, I believe we added APIs that will help you. Let me check
<mcphail> duflu: great!
<duflu> mcphail: I think it is:   mir_surface_set_preferred_orientation(MirSurface *surface, MirOrientationMode orientation);
<duflu> Although never used it myself so don't know if it's fully wired up
<mcphail> duflu: ooh - that sounds like it. Do you happen to know which version of Mir that first appears? Is it available on the Mir running on vivid phones?
<duflu> mcphail: It will take a minute to check
<mcphail> duflu: cheers. I greatly appreciate this
<duflu> (bzr is far too slow)
<alan_g> mcphail: you could look in mir_toolkit/mir_surface.h to see what's available
<mcphail> alan_g: I'll do that. Thanks for the hint
<duflu> mcphail: Yes it is in Mir 0.12 (vivid)
<duflu> But also relies on the server to honour it. Which Unity8 should by now
<mcphail> duflu: that's brilliant news! Look forward to trying this out this evening
<duflu> No problem.... 'night...
<mcphail> Thanks duflu, alan_g et al
<alan_g> u_glide: I know there were a lot of experimental branches to different components in that proof-of-concept - while some of that has landed I think I don't think there's yet a version with it all integrated.
<seb128> hey there
<seb128> is there any documentation on starting unity8 manually/in  debug mode?
<seb128> trying to debug http://paste.ubuntu.com/11763124/
<seb128> "ERROR: QMirServer - Mir failed to start"
<seb128> on a snappy personal image
<seb128> the mir demo server works on the same machine and I can start a gtk application and use it
<alan_g> seb128: normally I'd suggest asking greyback but I've not seen him around recently
<seb128> alan_g, right, seems he's on vac this week
<alan_g> seb128: may no longer be current but... "Aug 27 17:44:04 <greyback>	camako: MIR_SERVER_NAME=session-0 MIR_SOCKET=/run/mir_socket QT_QPA_PLATFORM=mirserver  /usr/bin/unity8"
<alan_g> Aug 27 17:46:17 <greyback>	camako: it's started by upstart usually. "start unity8" does the job. /usr/share/upstart/sessions/unity8.conf the config file
<alan_g> HTH
<seb128> alan_g, thanks
<racarr> Mornng
<alan_g> Afternoon
<bregma> dandrader, can you tells us anything about how the Mir server nested in Unity 8 connects with the system compositor?
<dandrader> bregma, that's quite a vague question. but the unity-system-compositor puts a socket file that unity8 connects to
<dandrader> bregma, I think mir guys are better suited to answer that
<bregma> dandrader, yeah, that much is clear
<dandrader> bregma, when it comes to mir details, I know very little.
<bregma> dandrader, we're trying to connect a client directly to the system compositor witout Unity 8, we're just having trouble finding where in the whole Unity 8 stack the mir_connect gets called
<dandrader> bregma, it's in qtmir
<bregma> there is no mir_connect call in qtmir
<bregma> or mir_connect_*
<dandrader> bregma, but it's all done there, one way or another
 * dandrader checks
<dandrader> somewhere in src/platforms/mirserver
<kdub> bregma, so, on startup, mir will try to connect as a nested server from options given to it
<kdub> havent looked into how that's negotiated, let me poke around qtmir quickly
<bregma> the trick is somehow it gets the environment variable MIR_SERVER_NAME and passes that to mir_connect(), but neither the enviroment variable nor the mir_connect call appear in the qtmir code
<kdub> right mir can process that from the environment
<kdub> or the command line
<kdub> I don't see qtmir forcing nested mode either
<dandrader> maybe it's in the upstart session
<bregma> naturally obfiscated code
<kdub> eh, just too many ways to pass in options :)
<bregma> the obfuscation is that most of the functionality is implicit and elsewhere rather than explicit and readable by humans with the code in front of them
<bregma> zen coding
<dandrader> bregma, I think magic is in the env vars set by /usr/share/upstart/sessions/unity8.conf
<bregma> dandrader, no, the env vars are set by LightDM, but it's how they're used that stymies us
<racarr> It's not obfuscated it's intentionally abstracted
<racarr> because unity8 doesn't know if its running nested or on
<racarr> a real hardware platform or on
<racarr> an offscreen platform
<racarr> or whatever
<kdub> mir_demo_server_minimal --help has all the default mir options with a description
<AlbertA> bregma, the connect code is in the nested code within mir...specifically src/server/graphics/nested/mir_client_host_connection.cpp
<AlbertA> the connection name can either come from a --name cmd line option
<AlbertA> or a MIR_NAME env variable
<kdub> MIR_SERVER_NAME
<AlbertA> kdub: oh right the prefix is MIR_SERVER...
<bschaefer> soo in a sense we'll need a nest server to render into mir? Or change how USC works (which doesnt seem like a small task)
<bschaefer> nested*
<bschaefer> as it just sits there waiting for "next_name" (which seems to be waiting for a session name of "session-0")
<bschaefer> to say its ready to display, and no longer booting
<bschaefer> if, instead of a mir_server I attempted just a mir client with the same session name/app name....
<bschaefer> how problematic would that be haha...
<AlbertA> a mir client with a connection name of "session-0" would work assuming you have permissions to the socket
<bschaefer> AlbertA, it has to push a frame correct? As i made a very simple client that just connected and waited for ever
<bschaefer> and didnt do anything :(
<AlbertA> bschaefer: why wouldn't you draw?
<bschaefer> AlbertA, well mainly ... we just want to boot process to be over
<bschaefer> ie. we want freedom to do w/e we want on the socket :)
 * bschaefer just renames the spinner app the session-0
<bschaefer> and sees what happens
<AlbertA> bscahefer: oh...does USC wait to pong lightdm until the first frame?
<bschaefer> AlbertA, it looks like theres a hackish stuff in umm shell? Or surface observeer
<bschaefer> where it waits for 2 frames to post
<AlbertA> bschaefer: the archive version waits until a couple of frames
<bschaefer> to say the surface is ready
<bschaefer> yeah
<AlbertA> yeah to work around a black frame bug....
<bschaefer> AlbertA, i've to use an older version 15.04
<bschaefer> yeah, but ill try renaming the spinner to session-0 and see what happens :)
<AlbertA> you could try just swapping buffers without drawing at all
<bschaefer> AlbertA, well i would need to set up egl etc
<bschaefer> thats what i was avoiding, set egl, pick the correct pf create the surface
 * bschaefer was being lazy
<kdub> there's a mir_buffer_stream_swap_buffers()
<bschaefer> not in 15.04 :(
<bschaefer> no 0.13
<bschaefer> mir
 * bschaefer should just move this dang snappy image to 15.10
<AlbertA> in 0.12: mir_surface_swap_buffers_sync
<bschaefer> right, but i still need egl set up
<bschaefer> otherwise it'll do nothing (in the driver, i would think)
<kdub> nah, it'll just think you're a software client
<bschaefer> o
<bschaefer> true, i was thinking i needed at lease a created mir surface
 * bschaefer tries that
<bschaefer> kdub, AlbertA thanks!
<bschaefer> o no... i guess next_name is "" for me... meaning ... im never getting set_next_session ... which is what it looks like session switcher is using to figure out if
<bschaefer> is_session_ready_for_display(next_name)
<AlbertA> bschaefer: ummm...that comes from lightdm right?
<bschaefer> AlbertA, yeah
<bschaefer> now im just thinking...do i have something messed up in the confs hmm
<AlbertA> racarr: can I get a review for https://code.launchpad.net/~mir-team/platform-api/remove-mirserver/+merge/262284 ?
<bschaefer> thing is this is bregma USC log http://paste.ubuntu.com/11765460/
<AlbertA> racarr: it's on top of your delete-deprecations branch
<bschaefer> and i dont see any mention of a next session setup
<bschaefer> but unity8 is working hmm well ill try just making a client with session-0 and go from there
<bschaefer> maybe i've been looking at the wrong code... ... i mean ... session switch makes sense since it talks about booting
<racarr> AlbertA: On it
<bschaefer> ooo nm
<bschaefer>     if (allowed_to_display_active && is_session_ready_for_display(active_name))
 * bschaefer missed that part
<bschaefer> soo i have the session setup in such as way that
<bschaefer> is_session_ready_for_display == true
<bschaefer> Allowed to display active == true
<bschaefer> booting == false
<bschaefer> show_spinner == false
<bschaefer> but still only 1 frame of my demos are renderering :(
<bschaefer> 1 frame renderers then goes back to a black mir server
 * bschaefer doesn't really under stand why only 1 frames renders ... if the session is active and ready for display
<AlbertA> bschaefer: it will only composite the session/connection named "session-0"
<AlbertA> any surfaces created over that connection (well probably only the first) will be rendered
<bschaefer> AlbertA, that make sense... so i've to create a launcher in a sense
<bschaefer> dang
<bschaefer> soo now i need to create a new mir server to render w/e i want haha
<bregma> bschaefer, surely all you need to do is make sure your client connects as session-0?
<bschaefer> bregma, yeah
<bschaefer> but ... that would mean w/e app we now connect we need to make sure its name is "session-0"
<bschaefer> i suppose ... that is hackable...
<bregma> bschaefer, yeah, that's "all"
<bschaefer> will there be issues if more then 1 app shares the same appname?
 * bschaefer doesn't think so
<bschaefer> since all demos share the same name
<bregma> bschaefer, we do not expect that to ever happen with what we're doing
<bschaefer> bregma, true
<bschaefer> but just a thought
 * bschaefer should have thought about doing this earlier
<bschaefer> though the spinner will be an issue since it'll keep opening/closing (since once the session-0 goes down it opens the spinner up)
<bschaefer> bregma, so im just going to do, once a session is opened and the shell/window manager sees it
<bschaefer> im going to change its name to "session-0" ... should give a free pass to all
<bschaefer> or w/e app we write
<bschaefer> will need the app name "session-0"
<bregma> bschaefer, (1) there is no shell or window managers and (2) a free pass for all is a security hole bigger than Windows itself
<bschaefer> bregma, thats what USC does
<bschaefer> err
<bschaefer> USC is the simple shell/window manager
<bschaefer> (or attempts to be)
<bregma> USC is just a compositor
<bregma> Unity8 is a shell and window manager
<bschaefer> but to make a server you need to add the shell/window manger bits (from what im reading)
<bschaefer> bregma,
<bschaefer> http://bazaar.launchpad.net/~unity-system-compositor-team/unity-system-compositor/trunk/view/head:/src/window_manager.cpp
<bschaefer> though i think thats just basic compositing....
<bregma> bschaefer, all we want is an app running full screen:  no shell, no window management
<bschaefer> right
<bschaefer> bregma, i think we can make USC do that
<bschaefer> bregma, yup (hacking the session-0 as the name for all new session opening works but thats just to test thats the real issue...)
<bschaefer> soo from here...
<bschaefer> get the SDK working
 * bschaefer goes back a week
<mcphail> bschaefer: Hi. I'm still trying to be able to set the orientation to landscape for an SDL2 game on the phone. I can use the SDL_SysWMinfo to get a MirConnection* and MirSurface*, but mir_surface_set_preferred_orientation() doesn't seem to do anything useful. Any hints on what else I can try?
<bschaefer> mcphail, not sure if thats really working on pure mir
<bschaefer> IIRC its done in qtmir but not yet done for pure mir surfaces
<mcphail> bschaefer: the Neverball game in the store sets orientation, but I'm not sure how it does it. That is SDL2 rather than qt
<bschaefer> hmm it must be doing something... unless it was forced in qml
<bschaefer> (somehow)
<bschaefer> if you force all surfaces in qml to be landscape
 * bschaefer isnt 100% sure how its getting landscaped through neverball
<bschaefer> racarr, would you happen to know about landscapes and surfaces?
<mcphail> bschaefer: it doesn't seem to have any Qt/QML at all. Just a pure SDL app
<bschaefer> popey, you run neverball on unity8 right?
<bschaefer> mcphail, i know it works on pure mir, not sure if you tested it out your self or if you watched popey video
<mcphail> bschaefer: tested neverball? I have it installed on the phone
<bschaefer> hmm and on your phone you're just running a bare mir_demo_server?
<bschaefer> or through a *.desktop file?
<mcphail> bschaefer: I launches through a .desktop file hook
<mcphail> it
<bschaefer> mcphail, when i say running through qtmir/qml i mean if you're running it on the phone it goes through our qt compositor
<mcphail> aah
<bschaefer> so on the phone when you get a surface its composited by qtmir
<mcphail> the layers of abstarction are confusing
<bschaefer> very hahaha
<mcphail> *abstraction
 * bschaefer gets lost all the time
<popey> heh
<mcphail> so I need to poke qtmir in some way?
<popey> (yes, I run it on the phone)
<bschaefer> that im not sure, i think ... *think* qtmir/qml handles the rotation
<bschaefer> which then you would request a surface for that rotation (not sure how to) or how thats handled
<bschaefer> so when you grab the surface from SDL2
<bschaefer> the unity8 doesnt like you messing with the "orientation"
<bschaefer> since unity8 is what reallly controls things, all you can do is merely suggest what you want
<mcphail> so by the time SDL2 gets the surface, the orientation is already a fait accompli?
<bschaefer> through the mir API
<bschaefer> mcphail, sdl2 requests a surface from the mir server
<bschaefer> from there it gets generated by the server and handed back, the W/H might be differnet as well IIRC
<bschaefer> its all confusing :(
<mcphail> bschaefer: you're not wrong there
<bschaefer> i had an issue with the title eating up space
<bschaefer> etc, but that should be handled correctly now
<bschaefer> as far as actually getting things to rotate im not sure, and ... someone who is better versed at unity8/qtmir would be more helpful ... possibly
<bschaefer> ie. greyback would know this answer (but hes not here)
<mcphail> bschaefer: Ha! thanks anyway. I'll lurk and post if I see him
<bschaefer> mcphail, good luck!
<mcphail> Cheers. Thanks for your advice
<bschaefer> mcphail, also if you figure your question out let me know! (would like to know how to do that as well :)
<mcphail> Will do :). Really need to track down the neverball dev
<bschaefer> you can always dig through the source :)
<bschaefer> and check the SDL calls
<bschaefer> mcphail, what it could do it do landscape on its own
<bschaefer> ie. it renders based on H/W
<bschaefer> soo it could do that internally
 * bschaefer hasn't tried neverball
<mcphail> bschaefer: from what I've made out from the source on github, there isn't anmything fancy done to force orientation. I'm not sure if that source matches the finished product, though
<bschaefer> you can always try apt-get source neverball to see what its like in main
<bschaefer> (could be different)
<mcphail> there is a separate touch branch from the main trunck. I've had a look through the git diff for that
<mcphail> *trunk
<mcphail> I think I'm going to have to look again
<popey> mcphail: good spot on the swiping in that bug
<mcphail> popey: does that clear up neverball for you?
<mcphail> bschaefer: looks as if you are right about neverball. I think it is hard coded to render "fake" landscape orientation, so it isn't a general solution for all sdl apps
<bschaefer> mcphail, yeeah was afraid of that :(
<popey> aww
<popey> mcphail: no, not tried, just impressed you stumbled upon that "fix"
<mcphail> popey: it only fixes it until you release your finger :)
<popey> get more fingers
<bschaefer> MAX_FINGERS=11
<mcphail> ha!
<bschaefer> thats bregma joke...but i think it was actually true
#ubuntu-mir 2015-06-25
<RAOF> racarr: If you're still in, I've responded to your ANR review.
<alan_g> alf_: anpok should I MP mir_*_event_input_event(), mir_*_event_get_base_event() or ...? @https://code.launchpad.net/~alan-griffiths/mir/event-timestamps/+merge/262879/comments/658874
<duflu> alan_g: IIRC the more modern format has no "get"
<duflu> Although we have plenty of gets
<duflu> Oh, I think the event casting functions do have gets
<duflu> Just field accessors don't use get
<alan_g> duflu: I'm trying to find out what the team thinks is consistent. (My preference is to avoid this dilemma but review comment...)
<duflu> alan_g: We are inconsistent right now, using both. But I think my new event functions are still the newest ones, and they dropped the "get"
<duflu> But not for the casting functions
<alf_> duflu: Unfortunately we are not as consistent as that, all accessors and casting functions for MirEvent and MirInputEvent use 'get', accessors for MirKeyboardEvent, MirPointerEvent etc do not use 'get'
<duflu> alf_: Correct. The clean-up isn't really complete
<anpok> and input_configuration_event too uses _get_
<duflu> I didn't want to break too many APIs. It was a large effort already
<anpok> hm and time instead of timestamp
<anpok> so we haveni used timestamp yet in that part of the api.. i am happy with sticking to 'time', even when it is less clear than timestamp.
<seb128> does anyone has hints on how to start an unity8/mir session without using lightdm?
<alan_g> duflu: mir_keyboard_event_timestamp(kev) or mir_input_event_get_time(mir_keyboard_event_get_base_event(kev));
<seb128> or to get debug input from Mir server when it fails to start?
<seb128> still having http://paste.ubuntu.com/11763124/ and trying to figure out how to get info
<seb128> "ERROR: QMirServer - Mir failed to start"
<duflu> seb128: I saw that error last time I tried it too. Safe to say it's a Unity8/QtMir error, not part of Mir
<alf_> alan_g: duflu: Although I don't like it much (it doesn't read well), as things stand, the most consistent option would be mir_keyboard_event_input_event() or _base_event()
<seb128> duflu, what did you try? unity8 on wily? on snappy? ... ;-)
<duflu> Agreed. I would prefer to keep on the path of removing "get" but there are a lot to remove yet
<duflu> seb128: On wily desktop
<seb128> duflu, oh, so wily issue?
<seb128> duflu, thanks
<seb128> need to try that later on
<seb128> I'm trying on snappy images and I assumed the issue had to do with that
<duflu> seb128: Any error in Mir and you'll see a detailed multi-line exception thrown
<seb128> k
<duflu> That error is outside of Mir
<duflu> Although possibly related to Mir, obviously
<seb128> I see, going to try to downgrade qtubuntu and other things after lunch then
<alf_> duflu: There is an error when loading input_stub Undefined symbol: _ZN3mir6events10make_eventEll17MirKeyboardActi
<seb128> duflu, thanks for the hint ;-)
<seb128> I tried to move that .so away but it doesn't make the session start
<duflu> alf_: Sorry to hear. I haven't touched it for a couple of releases and need to EOD in a minute. Not sure how to help
<seb128> that's bug #1458689
<ubot5> bug 1458689 in mir (Ubuntu) "[vivid-overlay] input-stub.so fails to load on i386" [Undecided,Confirmed] https://launchpad.net/bugs/1458689
<seb128> which is fix commited it seems
<seb128> k, need to go for lunch, bbiab
<alf_> duflu: I just wanted to draw your attention to it, because you said you had seen the same error
<duflu> alf_: Seb is right --> bug 1458689
<duflu> Which we claimed fixed
<anpok> and sits in 0.14.0
<alan_g> alf_: that sounds like conflicting versions of libmircommon8
<duflu> Umm, 5 is the latest (!?)
<alan_g> s/libmircommon/libmirclient/
<anpok> ah yes the error was that input-stub did not link libmirclient and hence this is an old mir-test-tools package?
<anpok> that did not get updated..
<alan_g> seb128: try deleting  input-stub.so
<alan_g> I don't think U8 needs it (but I don't think it causes the real error either)
<duflu> alan_g: Unfortunately I expect that's fatal (like in bug 1439078)
<ubot5> bug 1439078 in Mir "[regression] Demo servers crash on start-up if MIR_ENABLE_TESTS=OFF - std::exception::what: bin/../lib/server-modules/input-stub.so: cannot open shared object file: No such file or directory" [Medium,Triaged] https://launchpad.net/bugs/1439078
<anpok> that message should be generated by the graphics module prober
<anpok> the one in the log
<anpok> because input-platfor-lib is only set for tests..
<anpok> *platform
 * duflu slides out of sight
<anpok> (through the wrapper)
<alf_> seb128: Could you please pastebin the output of "dpkg-query -l '*mir*'"
<alan_g> anpok: you're saying lp:1439078 is another "feature" of wrapper?
<alan_g> alf_: anpok so the least bad option is "mir_keyboard_event_input_event()"?
<alf_> alan_g: I see three naming options across the event API: 1. everything uses get 2. nothing uses get 3. Only up/down casting functions use get (or perhaps mir_keyboard_event_as_input_event())?
<alf_> alan_g: We messed up naming consistency, this is not the right time to fix it as a whole... so choose anything you like, probably less intrusive is mir_keyboard_event_input_event()
<alf_> alan_g: (although as I mentioned it doesn't read very well)
<alan_g> FWIW My original proposal avoids this pain.
<anpok> alan_g: or my abuse of it .. yes!
<alf_> alan_g: but introduces new pains :)
<anpok> alan_g: i could avoid it with two wrappers - one for tests and one for demo clients/servers (or disable MIR_ENABLE_TESTS=OFF) .. but actually all of that will become inrelevant as soon as I cleanup the platform loading for input
<anpok> which we should do right after mir on x
<alan_g> anpok: agreed
<anpok> or maybe not .. because it might then always pick the x version.. hmm
<alan_g> Not if it is done right. ;)
<anpok> oh need to run.. I am offline now..
<anpok> need to pick my daugther..
<alan_g> alf_: writing a few trivial functions once isn't a big pain.
<alf_> alan_g: the pain is that we are duplicating functionality in our API
<alan_g> alf_: I'd happily deprecate mir_input_event_get_time() - I don't think the timestamp is useful without deciding the event type.
<alf_> alan_g: We have an implicit hierarchy of input events (implicit because C cannot express this very well), e.g., MirKeyboardEvent is-a MirInputEvent. I understand the convenience of being able to access properties of the base type through direct accessors of the derived, but at the same time it feels less elegant and more wasteful to do so.
<alf_> alan_g: Plus if we choose to have the direct accessors, we might as well remove the base type.
<alan_g> I'd happily deprecate MirInputEvent too and not try for commonality.
<mcphail> Can anyone point me to a good introductory document detailing the interactions between upstart, dbus, unity8, mir and qtmir on the phone? I'm keen to know how an app is launched, gets a surface for display and has its lifecycle controlled. Thanks
<alf_> alan_g: I would be more amenable to a complete MirInputEvent removal/deprecation vs having direct accessors for base type properties, but I think this warrants a wider discussion
<alf_> mcphail: Unfortunately I am not aware of a comprehensive document, perhaps someone from the unity8 team has more info
<alf_> mzanetti: ^^ ?
<mcphail> thanks alf_ - I find this very confusing
<seb128> alf_, http://paste.ubuntu.com/11772977/
<alf_> seb128: thanks, everything looks in order
<olli> mzanetti, seb128 says u8 doesn't work on willy - are you guys aware?
<olli> dandrader, ^
<dandrader> olli, mzanetti is on holidays today and tomorrow
<seb128> I'm seeing the same issue than I was describing yesterday on my test laptop, it worked on vivid, I added the wily source and did an apt-get install unity8 (which upgraded unity8/mir/qtmir/some other things and now unity8 session doesn't work anymore)
<seb128> duflu mentioned a similar issue earlier
<dandrader> olli, no, I'm not aware of that
<seb128>  "ERROR: QMirServer - Mir failed to start"
<seb128> <duflu> seb128: I saw that error last time I tried it too. Safe to say it's a Unity8/QtMir error, not part of Mir
<seb128> <duflu> seb128: On wily desktop
<seb128> dandrader, ^
<seb128> any idea how to debug?
<olli> dandrader, ah, didn't realize
<dandrader> olli, it's just that he never logs off irc, so you never can tell if he's really there :)
<olli> dandrader, would be good if you could give seb128 a hand for a bit or help find the right person who could help unblock seb
<ogra_> yeah, else he might port unity7 to the phone instead :)
<dandrader> seb128, I'm still on vivid+overlay-ppa
<dandrader> seb128, but let me think....
<ogra_> seb128, i assume you are on an x86 arch with that ... did you by accident get some -gles packages installed ?
<seb128> dandrader, do you have any debugging hint/any way to get a log from qmirserver?
<seb128> out of "failed to start"
<ogra_> (thats solely for x86 the emulator i think)
<seb128> ogra_, it is amd64 a&n
<ogra_> -the
<seb128> ogra_, it is amd64 and no
<ogra_> ok
<seb128>  I also had that system working before I updated those packages
<dandrader> seb128, well, qtmir doesn't do much. it just tries to run its mir::Server instance and if it doesn't work it spills out this error
<seb128> which include basically new qt/qtmir/mir/unity8/uitk
<seb128> dandrader, can I try to start mir::Server by hand in some way to see what's going on?
<seb128> or do we have a debug log that may include details on the error?
<dandrader> seb128, you might turn on some mir logging to see what's going on inside mir...
<seb128> how?
<dandrader> seb128, through setting some environment variables. It's been a while since I last did it. Mir guys should know the exact var names
<seb128> Mir guys ^ ;-)
<dandrader> :)
<dandrader> seb128, thing is, you can't find the env var names just by grepping mir code as they are generated procedurally. the way to get them, if I recall correctly, is running a mir binary with --help or something
<dandrader> seb128, like one of those sample mir clients or servers
<dandrader> alan_g, ^
<alan_g> dandrader: seb128 http://unity.ubuntu.com/mir/component_reports.html
<dandrader> seb128, if you check qtmir code you will see it doesn't do much tweaking. it just runs a mir::Server and let's the magic happen
<seb128> well, the magic doesn't happen on wily :p
<dandrader> seb128, it doesn't even know whether it's running as a nested server (under unity-system-compositor) or standalone
<dandrader> alan_g, thanks
<seb128> alan_g, dandrader, so any idea which of those variables would be useful with that error? and where to set it?
<alan_g> seb128: I doubt that any will help your problem
<dandrader> :(
<seb128> in fact that system seems to have a different issue
<seb128> http://paste.ubuntu.com/11773504/
<seb128> std::exception::what: Failed to find platform for current system
<dandrader> seb128, oh, that's a good lead
<seb128> the u-s-c log is http://paste.ubuntu.com/11773552/
<seb128> in case that's useful
<seb128> bah, usc was outdated on that box, upgrading
<seb128> hum, now it does the same as unity8
<seb128> "std::exception::what: Failed to find platform for current system"
<seb128> dandrader, alan_g, ^ any idea how to debug that?
<alan_g> seb128: you on a mesa or android stack?
<seb128> mesa
<seb128> it's an amd64 desktop
<dandrader> seb128, that's mir stuff. sorry, can't help with that. out of my turf
<alan_g> seb128: install mir-graphics-drivers-desktop
<alan_g> I'm not sure of the full story but that's missing from the seed
<seb128> is that a new package?
<alan_g> Mir used to pull in both sets of drivers, but that's bad as it install X on the phone
<AlbertA> seb128: try apt-get install mir-graphics-drivers-desktop
<seb128> alan_g, that worked!
<alan_g> So we're in a partly fixed state now
<seb128> AlbertA, ^
<seb128> alan_g, AlbertA, dandrader, thanks ;-)
<alan_g> seb128: we should figure out how it could be made easier
<seb128> alan_g, mir should probably pull the android drivers on armhf and the desktop ones on i386/amd64
<seb128> though I know it's not a right approximation
<seb128> we might do standard desktop on armhf or android on i386
<alan_g> seb128: RAOF "owns" this issue
<seb128> good to know
<ogra_> seb128, we do the latter in the emulator
<ogra_> (and yeah, snappy will hopefully bring desktop to armhf)
<seb128> ogra_, do we have any way to have a Depends: something (android) | somethingelse (desktop)?
<ogra_> not really, no
<ogra_> livecd-rootfs hacks ...
<AlbertA> seb128: right, it's just than Debian depends is not rich enough to describe "platforms"
<seb128> shrug, so that was the issue on my test laptop
<AlbertA> we do have in the seeds for desktop-next and ubuntu-touch
<seb128> the snappy image has mir-graphics-drivers-desktop though
<seb128> so here it's something else :-/
<ogra_> this will become super tricky WRT convergence :/
<ogra_> (where we need both seeds but device specific backend selection)
<seb128> alan_g, AlbertA, is Mir supposed to work on stock ubuntu wily under virt-manager with spice/qxl enabled?
<seb128> (like described on http://unity.ubuntu.com/mir/setup_kvm_for_mir.html)
<alan_g> seb128: I think anpok had that working on V+O so I'd expect it to work on wily
<seb128> is the build a new kernel still needed with the newer version is ubuntu?
<alan_g> anpok: ^?
<anpok> hm
<anpok> seb128: yes
<anpok> i use that for testing usually
<seb128> anpok, does one need to build a new kernel?
<anpok> seb128: the stock vivid and wily kernel is fine..
<seb128> k
<alan_g> seb128: try the latest docs: http://bazaar.launchpad.net/~mir-team/mir/development-branch/view/head:/doc/setup_kvm_for_mir.md
<seb128> alan_g, anpok, thanks
<seb128> bah
<seb128> back to "ERROR: QMirServer - Mir failed to start"
<seb128> is there any way to start that QMirServer by hand to know why it fails to start?
<seb128> alan_g, anpok, "With that we have enough support for EGL and GLESv2 to run Mir."
<seb128> does it mean that we need to use gles rather than gl under the vm? so different set of driverS?
<anpok> no the GL support of llvmpipe is good enough for unity8
<seb128> k, I've mir_demo_server working in the vm
<seb128> so it's just unity8 failing on that v
<seb128> "ERROR: QMirServer - Mir failed to start"
<seb128> which I'm clueless on debugging :/
<seb128> need help there...
<seb128> dandrader, I can't run unity8 as an app under a mir demo server, right?
<seb128> unity8 is a mir compositor/server by itself?
<alan_g> seb128: unity8 normally runs under a mir compositor (USC)
<seb128> alan_g, can I start that manually?
<seb128> not sure what magic is lightdm doing
<dandrader> seb128, I don't know. but that would be similar to unity8 running under unity-system-compositor, which is what we have on the phones. so maybe you can?
<alan_g> seb128: you'd have to ask one of the U8 guys
<seb128> alan_g, that's what I'm trying, it seems only dandrader is around from u8 ;-)
<dandrader> seb128, start what, unity-system-compositor?
<dandrader> seb128, if I'm not mistaken there's a "unity8-mir lightdm session" package you can install on your desktop. do you have it?
<dandrader> seb128, which will show unity8-mir as a login option on the regular lightdm
<seb128> dandrader, right, login into unity8 session gives me a
<seb128>  "ERROR: QMirServer - Mir failed to start"
<seb128> in .cache/upstart/unity8.log
<seb128> which I'm trying to debug
<seb128> so I'm trying to start things by hand in case there is some more info on stdout
<seb128> doing "sudo unity-system-compositor" gives me a "Bad file descriptor" error :-/
<anpok> alan_g: that error seb128 sees indicates that the main_loop never 'runs'
<seb128> the u-s-c.log from lightdm indicates "pause"
<seb128> which I guess it means it never gets frames from unity8
<AlbertA> seb128: try initctl list-env | grep MIR
<AlbertA> set those env variables and start unity8 manually
<seb128> AlbertA, that assume a working session to run the command?
<AlbertA> seb128: oh..maybe...:)
<AlbertA> seb128: so usc is running?
<AlbertA> the vars are usually:
<AlbertA> MIR_SERVER_NAME=session-0
<seb128> no it's not atm, but I can have it up by trying to log into unity8, which fails
<AlbertA> UNITY_MIR_SOCKET=/run/mir_socket
<AlbertA> MIR_SERVER_PROMPT_FILE=<some fd>
<AlbertA> MIR_SOCKET=/run/user/< id >/mir_socket
<seb128> AlbertA, I tried http://paste.ubuntu.com/11773756/ which alan_g shared yesterday from an old irc discussion
<seb128> but I get a "Exiting Mir! Reason: Nested Mir and Host Mir cannot use the same socket file to accept connections!"
<AlbertA> seb128: ok so you have a mir_demo_server running ?
<AlbertA> which uses /tmp/mir_socket
<AlbertA> you shouldn't need sudo permissions for unity8
<seb128> same error as an user
<AlbertA> set UNITY_MIR_SOCKET
<AlbertA> that should point to the root compositor
<alan_g> "Nested Mir and Host Mir cannot use the same socket file to accept connections!" indicates that --host and --file are the same (It could be defaulted)
<AlbertA> and MIR_SOCKET should be something different than the socket used by the root compositor
<seb128> how do I start the root compositor?
<seb128>  doing "sudo unity-system-compositor" gives me a "Bad file descriptor" error
<AlbertA> seb128: so unity-system-compositor is not currently running?
<seb128> no
<josharenson> seb128: I'm a bit late to this party, but the 2 things that made it work for me were changing my lightdm.conf to use type=unity and enabling the hadware cursor in unity system compositor
<josharenson> seb128: lightdm should be starting u-s-c
<seb128> josharenson, when on the greeter? or on session login?
 * josharenson gets out spare laptop w/ unity8
<josharenson> seb128: it looks like its running before starting the unity8 session
<seb128> josharenson, let me reboot that machine, I tried to log in unity8 which fails, several time
<seb128> and started mir servers by hand
<seb128> so maybe something made the usc instance go away
<josharenson> seb128: I can send you the exact steps that worked for me (was fairly straight forward), but as a disclaimer, my machine is maybe a month or more out of date
<seb128> josharenson, step for what? starting unity8 by hand?
<seb128> ok, so booting doesn't give me a system compositor
<AlbertA> seb128: for starting things manually.... you could try something like this: http://pastebin.ubuntu.com/11773818/
<seb128> oh, sorry, it does
<josharenson> seb128: installing/starting unity8-desktop-session-mir
<seb128> AlbertA, thanks, trying
<seb128> AlbertA, I get a "Failed to connect to server socket: No such file or directory"
<seb128> Nested Mir Platform Connection Error
<seb128> josharenson, yeah, installing/getting unity8 to work is usually fine, I'm trying to figure why mir fails to start on that snappy personal debugging image though, so it's more "how to figure out what it doesn't like" rather than user "get system working" ;-)
<AlbertA> seb128: ll /tmp/mir_socket?
<josharenson> seb128: ah ok
<seb128> AlbertA, srw-rw-rw- 1 root root 0 juin  25 15:23 /tmp/mir_socket=
<AlbertA> seb128: then specify MIR_SERVER_HOST_SOCKET=/tmp/mir_socket instead then...
<seb128> AlbertA, instead of which one? UNITY_MIR_SOCKET?
<AlbertA> right
<seb128> AlbertA, wooot, unity8 working
<seb128> which is nice
<seb128> but doesn't help me debugging why the normal session hits a "ERROR: QMirServer - Mir failed to start"
<AlbertA> seb128: bummer
<AlbertA> seb128: so you do have a unity-system-compositor running? do you have a /run/mir_socket?
<seb128> I have one running
<AlbertA> so try MIR_SERVER_HOST_SOCKET=/run/mir_socket now...
<seb128> from the ps command line I guess the socket is /run/lightdm-mir-0
<AlbertA> or that...
<AlbertA> :)
<seb128> should I try to use that azs MIR_SERVER_HOST_SOCKET?
<seb128> oh, get the same error that the unity8.log then
<seb128> "ERROR: QMirServer - Mir failed to start"
<seb128> no more details though :-/
<seb128> works if I use the demo shell though
<seb128> so I guess an issue with usc?
<AlbertA> look at /var/log/lightdm/unity-system-compositor.log
<seb128> AlbertA, http://paste.ubuntu.com/11773781/
<seb128> it acts like if it was waiting for u8
<AlbertA> pause....
<AlbertA> ummm
<racarr> Morning!
<AlbertA> racarr: morning!
<AlbertA> vogons: when are the pause handlers called?
<AlbertA> seb128: so from what I can see, pause would be called when you switch away from the VT
<seb128> AlbertA, oh, on those systems I get warnings like
<seb128> "Error using VT_ACTIVATE 7 on /dev/console: Inappropriate ioctl for
<seb128> device""
<seb128> I wonder if that's the issue...
<AlbertA> seb128: sounds plausible
<AlbertA> seb128: oh...somebody kgunnn or mterry were saying there was a race between agettty and mir getting the vt....but I think that was snappy?
<AlbertA> but it may explain why you can start a mir_demo_server after without issues
<mterry> AlbertA, that was on snappy yeah
<bschaefer> seb128, i've gotten that and didnt have a pause (though im not using unity8)
<bschaefer> wasnt that the point of USC.sleep?
<seb128> AlbertA, I'm trying to get unity8 session to work on snappy, so that's a snappy system I'm on
<seb128> AlbertA, thanks for the help/hints
<AlbertA> seb128: ah...ok
<seb128> I need to go but I'm going to follow up on that tomorrow
<seb128> mterry, can you bounce me info on that/workaround if you have some?
<seb128> bye
#ubuntu-mir 2015-06-26
<alan_g> alf_: Happy? https://code.launchpad.net/~alan-griffiths/mir/introducing-mir_test_framework-main/+merge/262998
<alf_> alan_g: +1
 * alan_g wonders if he can "fix" test_client_cursor_api.cpp before vacation
<alf_> anpok: Anything more for nested-client-to-display-buffer-latency-benchmark?
<anpok> alf_: ok
<alf_> anpok: thanks
<seb128> AlbertA, hey, thanks for the help yesterday, I'm still looking at the issue ... do you know why the vt change ioctl wouldn't work
<AlbertA> seb128: no prob
<AlbertA> seb128: I thought it was the race where agettty got the VT before mir
<seb128_> re
<seb128_> AlbertA, sorry, I disconnect
<seb128_> so making progress
<seb128_> in fact unity8 does start on the usc instance on vt8
<seb128_> it's only that vt switch fails
<seb128_> so vt7 goes back to lightdm making it look like the session failed
<seb128_> also the usc.log is on "pause"
<seb128_> but going to vt8 make unity8 load and usc
<AlbertA> seb128_: is it possible to change the VT agetty  uses?
<seb128_> AlbertA, do you think it's also a case of agetty conflict?
<seb128_> lightdm log has warnings about the vt console switch ioctl not handled
<AlbertA> seb128_: yeah I'm wondering if that's because agetty got the VT first
<seb128_> is there any way to change agetty?
<seb128_> need to go for half an hour, going to read backlog and look a bit more then
<seb128_> thanks!
<racarr> GOod morning!
<SturmFlut> Is Mir-on-X what I think it is?
<anpok> let me read your mind..
<anpok> ... yes
<conyoo> hmm... let's try Mir on X on XMir
<anpok> if you are on intel you might need a new mesa
#ubuntu-mir 2016-06-28
<drguell> Hi
