#ubuntu-mir 2013-06-17
<robert_ancell> RAOF, my bzr productivity has gone up so much since you showed me init-repo - thanks!
<RAOF> :)
<tvoss_> RAOF, robert_ancell good morning :)
<RAOF> tvoss_: Good morning!
<robert_ancell> tvoss_, hello
<tvoss_> robert_ancell, hey there :) How is it going?
<tvoss_> robert_ancell, for the brittle dep on libmirserver: could we increase the patch version of mir at least? trying to parse bzr743 vs. bzr 745 is a little annoying :)
<robert_ancell> tvoss_, what does that acheive?
<RAOF> And isn't that going to be pretty much bumping the patch level for each bzr commit anyway?
<tvoss_> RAOF, sure, it's just more readable :) which is the only benefit robert_ancell :)
<robert_ancell> tvoss_, how is it more readable?
<tvoss_> robert_ancell, 0.0.4 is more readable to me than 0.0.3bzr{revision}, but that's admittedly quite subjective
<RAOF> I think it sounds more readable to you because you're thinking it'll be mir 0.0.6, mir 0.0.7, â¦ Pretty quickly it's going to be mir 0.0.743 and mir 0.0.745, and I don't think you'll find that too much more readable :)
<robert_ancell> tvoss_, yeah, there's a conflict between "old naming" and "new naming". Really the bzr number is the only one that matters. We just bump the main version number to close out bugs at the moment
<tvoss_> robert_ancell, okay, cool
<robert_ancell> It should be set to what RAOF said, but no-one has done the work afaik
<RAOF> Oooh, that reminds me.
<RAOF> Time to construct a symbols file for libmirclient!
<duflu> RAOF: Umm, "make" ? :)
<duflu> A symbols file is usually just a binary that's not stripped :)
<duflu> Or you mean symbols deb? (!)
<RAOF> I mean a file listing the exported symbols.
<RAOF> That gets compared to the *actual* exported symbols when the package is built, and causes the build to fail if you've changed the ABI (in that way).
<tvoss_> robert_ancell, still about?
<tvoss_> damn :)
<tvoss_> thomi, ping
<tvoss_> RAOF, unity-system-compositor fails to install right now due to unity-system-compositor : Depends: libmirserver0 (= 0.0.3bzr743saucy0) but 0.0.3bzr745saucy0 is to be installed
<RAOF> Yeah, just noticed.
<tvoss_> RAOF, how can I help in pushing the correct version to the ppa?
<RAOF> Hm. And the last Mir build was 2013/06/15. The autorebuilder should have rebuilt unity-system-compositor.
<RAOF> tvoss_: I think we need to prod the autobuilder, but I have no idea how to do that.
<RAOF> tvoss_: I'm leary of manually uploading because I'm not sure that I can chose a version later than what's currently in there that won't confuse the autobuilder.
<tvoss_> RAOF, ack, by autobuilder, you are referring to good ol' jenkins?
<RAOF> tvoss_: I believe so, but it's not quite the usual CI infrastructure - each Mir build *should* provoke a new unity-system-compositor build.
<tvoss_> RAOF, I think that's the issue, forward build dep propagation seems not to be working as expected
<RAOF> Once I've checked that it works I'll push a change to unity-system-compositor to disable the cursor, which should cause a rebuild.
<tvoss_> RAOF, \o/
<tvoss_> RAOF, how can people see that they are running XMir then?
<RAOF> By grepping /var/log/Xorg.0.log
<tvoss_> RAOF, okay, something more user-friendly might be a good idea, but we can leave that for later :)
<tvoss_> RAOF, can you ping me once the changes land? if that is eta today
<RAOF> It should be, but that does depend on my understanding of the code being correct :)
<RAOF> And this stupid laptop being less slow. Argh!
 * tvoss_ remembers RAOF posts about a laptop refresh :)
<RAOF> Indeed.
<RAOF> A 240 GB SSD + a Haswell i7 should make things much more fun.
<tvoss_> RAOF, I can only recommend that setup, although I don't have a Haswell, it's a core i7 vpro and an ssd in my x220
<tvoss_> RAOF, quite fast it is :)
<RAOF> Plus a terabyte of rotating rust to store all the other things.
<tvoss_> RAOF, yup :9
<tvoss_> mlankhorst, ping
<tvoss_> mmrazik, ping
<mmrazik> tvoss_: pong
<tvoss_> mmrazik, good morning :) quick question: Do we have a solution for forward-build-dep propagation, yet?
<tvoss_> mmrazik, aka the meta-build-system?
<mmrazik> tvoss_: should be there
<mmrazik> tvoss_: do you miss something in particular?
<mmrazik> I think thomi/fginther were enabling something for mit
<mmrazik> s/mit/mir/
<tvoss_> mmrazik, installing unity-system-compositor from the mir staging ppa fails right now due to unity-system-compositor : Depends: libmirserver0 (= 0.0.3bzr743saucy0) but 0.0.3bzr745saucy0 is to be installed
<tvoss_> mmrazik, seems like unity-system-compositor has not been rebuild
<mmrazik> tvoss_: oh. I think its not dputing into PPA. It only rebuilds in jenkins to check for build failures I believe
<mmrazik> the PPA should go away fairly soon anyway
<mmrazik> or not?
<tvoss_> mmrazik, hm, any eta when we will land in universe?
<mmrazik> don't know
<mmrazik> I guess didrocks knows more
<tvoss_> mmrazik, just pinged him
<didrocks> tvoss_: mmrazik: I'm waiting kgunn to be back (which should be today, right?) to discuss about it with him
<didrocks> I want Unity 8 (without indicators) + Mir to be in the next couple of weeks into distro
<tvoss_> didrocks, right, should be back today
<tvoss_> mmrazik, seems like the ppa will be with us for some time then :)
<mmrazik> tvoss_: I'll drop francis an e-mail. It might be that the answer will be to use an archive located on private API
<mmrazik> since copenhagen (I believe) there was a push towards killing staging PPAs
<mmrazik> s/private API/private IP?
<tvoss_> mmrazik, okay, my goal is to make installation from the ppa as straightforward as possible
<mmrazik> tvoss_: ok. so not just for canonical people...
<tvoss_> mmrazik, right
<mmrazik> then the private archive is not an option
<mmrazik> tvoss_: sent an e-mail to francis. I think it should not be very hard
<tvoss_> mmrazik, ack
<RAOF> didrocks: Is our autolanding infrastructure robust enough to handle âeach Mir upload breaks unity-system-compositor, so don't publish it until unity-system-compositor has built against -proposedâ?
<didrocks> RAOF: we don't build enough into -proposed. For detecting ABI break and upstream not following the guide in such a case, you should provide some integration tests (those are run, and so, when failed, block the publishing)
<didrocks> RAOF: FYI, this is what needs to get done when you are breaking the ABI: https://wiki.ubuntu.com/DailyRelease/FAQ#I_need_to_break_an_API.2BAC8-ABI
<didrocks> basically, it's about "bump the version in debian/changelog" and bump the build-dep on the project dep on this one
<didrocks> (just to trigger the 2 rebuilds)
<didrocks> this in a coherent piece, before 00 UTC
<RAOF> Bah.
<RAOF> We can't just have Depends: libmirserver0 (= $THE_VERSION_BUILT_AGAINST_INCLUDING_DEBIAN_REVISION)?
<RAOF> Because we bump ABI (for mirserver) approximately each commit, and don't intend to stop doing that for a while.
<RAOF> I thought the -proposed â archive transition checked that it didn't make the archive uninstallable.
<didrocks> RAOF: -proposed -> archive does, but you don't want to break proposed everyday as well I think :)
<didrocks> RAOF: what does mirserver has as build-deps?
<RAOF> It's built by mir
<RAOF> I thought we could happily break -proposed every day?
<RAOF> :)
<didrocks> RAOF: well, everything that will dep on MIR will break then
<RAOF> Is that a problem?
<RAOF> There's not that much that depends on mir.
<didrocks> RAOF: in fact, thinking about it, if the packaging forces latest version, we won't be able to install all MIR-related package
<didrocks> RAOF: this can even be a test!
<didrocks> and so we block the upload to -proposed
<didrocks> RAOF: unity8 will I guess, isn't it?
<RAOF> Yeah, once it's rebased on Mir.
<RAOF> But it, too, will be broken by every Mir commit :)
<didrocks> RAOF: when do you plan to stabilize the ABI?
<RAOF> Once Unity 8 is substantially complete, I believe
<didrocks> RAOF: if MIR is going to be broken everyday, there is no real point to push it to distro :p
<RAOF> I thought that was the decision, yes :)
<didrocks> any rough date idea?
<didrocks> the decision to not push it or to push it?
<RAOF> You'd need to talk to the shell team for that.
<RAOF> The decision *not* to push it.
<didrocks> hum, interesting, last time, the decision was to push it :)
<didrocks> RAOF: anyway, I think the best to block publishing would be to have an integration test with a dep
<didrocks> and this will block the publication as the test will fail
<didrocks> (an autopilot tests as we standardized on it)
<RAOF> Ok
<tvoss_> alf_, ping
<alf_> tvoss_: pong
<duflu> mmrazik: Is there a bug for "Fix committed at revision None..." ? As in: https://bugs.launchpad.net/mir/+bug/1191636/comments/2
<ubot5> Launchpad bug 1191636 in Mir "setup-android-dependencies.sh hung at "Do you want to continue [Y/n]?"" [Medium,Fix committed]
<duflu> I keep seeing various bugs say "at revision None"
<mmrazik> duflu: yes. I've seen it before but was too lazy too look it up. Let me check now.
<duflu> I was too lazy too :)
<mmrazik> duflu: mhm. Might be difficult to fix. It looks like some timing issue. The branch is already merged but launchpad seems to be reporting it is not (for a while).
<mmrazik> The only fix I can think of is sleep
<mmrazik> but obviously I'm not too excited about it
<duflu> mmrazik: Yeah suspected as much. Thanks anyway
<duflu> mmrazik: Is the a bug for it yet?
<mmrazik> I'll create one
 * tvoss_ reboots :) 
<tvoss> RAOF, ping
<RAOF> tvoss: Pong.
<tvoss> RAOF, did you push the update removing the orange pointer?
<RAOF> Not yet. Turns out that it really wants a little bit more mir infrastructure, and I'm just doing that.
<tvoss> mmrazik, seems like psjenkins has just dput'ed to the ppa, leaving it in a broken state right now
<RAOF> I should really file a âbtrfs snapshots cause catastrophic performance degredation over timeâ bug
<mmrazik> tvoss: what was dputed? I can dput something manually to trigger a rebuild in PPA if you want (unity-system-compositor ?)
<tvoss> mmrazik, nope, ignore that
<mmrazik> ok
<xnox> RAOF: there are a couple, I believe..... known upstream issue as well
<alf_> tvoss: https://code.launchpad.net/~afrantzis/mir/platform-enablement-docs/+merge/169754 , let me know if you need more information or any refinements
<tvoss> alf_, thanks, looking
<arsson> unity-system-compositor : Riippuvuudet: libmirserver0 (= 0.0.3bzr745saucy0) mutta 0.0.3bzr746saucy0 on merkitty asennettavaksi
<arsson> ?
<tvoss> katie, ping
<kgunn> didrocks: i'm in today ;)
 * alf_ upgraded to saucy and is not happy about the tedious gmock related warnings that g++-4.8 spits out
<tvoss> mmrazik_, any idea where this issue originates from: https://launchpadlibrarian.net/142643349/buildlog_ubuntu-saucy-i386.xorg-server_2%3A1.13.3%2Bxmir1-0_FAILEDTOBUILD.txt.gz
<tvoss> =
<tvoss> ?
<tvoss> didrocks, ping
<tvoss> seb128, ping
<didrocks> tvoss: pong
<tvoss> didrocks, hey there :) I'm looking at https://launchpad.net/~mir-team/+archive/system-compositor-testing/+packages
<tvoss> didrocks, trying to understand why the build failed for 386
<mlankhorst> tvoss: looks like a broken builder tbh
<didrocks> kgunn: tell me once you have some time for a short meeting around mir and unity 8 in saucy
<didrocks> tvoss: what mlankhorst says
<didrocks> tvoss: did you ask the launchpad guys?
<seb128> tvoss, hey
<tvoss> didrocks, nope
<seb128> tvoss, just retry the builds
<kgunn> didrocks: got 30 min right now
<didrocks> kgunn: if you don't care seeing me with wet air (just back from some exercice), let me starts a hangout :)
<didrocks> start*
<kgunn> sure
<didrocks> kgunn: https://plus.google.com/hangouts/_/3c9650ce706154e7b24b272d2c14df4d5bc36fff
<alf_> alan_g: Is there a reason TemporaryBuffers (in compositor/) assume that their buffer bundles may be destroyed while they are still alive? Which scenario does this assumption support?
<alan_g> alf_: sorry, not sufficiently familiar with the current code to answer OTTOMH
<alf_> alan_g: np, for now I will assume that we don't need this scenario, and let Kevin prove me wrong :)
<alan_g> alf_: OK. FWIW I'd expect the bundle to outlive the buffers too
<tvoss> mlankhorst, ping
<mlankhorst> pong
<tvoss> mlankhorst, hey :) not sure you are the right person to ask, but does fglrx support radeon 8xxx series?
<mlankhorst> radeonhd or the ancient ones?
<tvoss> mlankhorst, the binary driver that is
<mlankhorst> i know but https://en.wikipedia.org/wiki/Radeon_8000_Series or https://en.wikipedia.org/wiki/Radeon_HD_8000_Series :P
<katie> tvoss pong
<tvoss> mlankhorst, http://www.amd.com/us/products/desktop/graphics/8000/Pages/8000-series.aspx#2
<mlankhorst> i dont see it in their official notes, so perhaps not
<mlankhorst> http://support.amd.com/us/kbarticles/Pages/AMDCatalyst13-6LINBetaDriver.aspx
<tvoss> katie, hey there. did you see my comments on the surface mgmt doc?
<katie> tvoss, hi. no, haven't looked at that doc today
<katie> tvoss, but now you mention it, I will have a look later on :)
<tvoss> katie, first wave of feedback, stay tuned :)
<katie> tvoss, cool, thanks
<tvoss> didrocks, can we have apport integration for packages not in main?
<didrocks> tvoss: sure, this has nothing to do with main or not main
<tvoss> didrocks, great :)
<didrocks> tvoss: what do you mean by apport integration? additional questions/files to grab?
<tvoss> didrocks, yup, like being able to say ubuntu-bug xmir
<didrocks> tvoss: ah, so you mean apport integration for packages not even in distro
<didrocks> but in a ppa
<tvoss> didrocks, for example, yes
<didrocks> tvoss: by "main", you could have infer "in universe"
<didrocks> tvoss: however, I think you want stacktrace retracing?
<tvoss> didrocks, yup, it should mostly be a convenient way for users/early adopters to report issues
<didrocks> tvoss: they won't be able to retrace automatically though
<didrocks> tvoss: as the dbgsym are not published in ddebs.ubuntu.com
<tvoss> didrocks, can we get them there somehow for ppa packages?
<didrocks> tvoss: that would be a question for pitti I guess, not sure
<didrocks> tvoss: having dailies will enables to push stuff quickly and have this kind of feedback loop
<tvoss> didrocks, ack
<tvoss_> alf_, ping
<alf_> tvoss_: pong
<kdub_> good morning
<racarr> Morning!
<kdub_> oh, so android/mir users, you should upgrade to the latest saucy-based images, the mir fixes for saucy have landed :)
<kdub_>  ^ricmm
<alan_g> \o/
 * alan_g is not so happy about the compiler diagnostics when compiling on saucy
<kdub_> yeah :/
<racarr> kgunn: unity mir sync? https://plus.google.com/hangouts/_/8015a964c25dbb4a92528d82f94676c27eb14a7a?authuser=1
<kgunn> racarr: greyback go for it...
<kgunn> i'm gpu boy today
<greyback> yep, fighting with SSO
<racarr> fun fun
<kgunn> ricmm: ^
<racarr> kdub_: I only saw your mouth moving XD
<kdub_> racarr, greyback yeah, was muted, just trying to see how the qt bits tie into the compositor
<racarr> kdub_: Oh you know, with an API
<racarr> ;)
<alan_g> kdub_: my by definition of "precondition" there's no promise about behavior - conversely if you promise behavior then you've not got a precondition
<alan_g> And a test is for promised behaviour
 * alan_g prepares to move desktop to saucy
<kdub_> alan_g, good luck! made for an interesting friday afternoon for me
<kdub_> alan_g, yeah, i guess its just about the definition of 'precondition'
<alan_g> kdub_: my netbook finally looks stable on saucy, so I'm risking it (my laptop however is staying or raring)
<alan_g> http://en.wikipedia.org/wiki/Precondition
<alan_g> I guess I've been hanging around the DBC crowd.
<kdub_> alan_g, so i guess if there's a test that will throw under certain conditons, thats not a 'precondition' its just behavior
<ricmm> kdub_: racarr hey guys, trying out the XMir dogfooding guide
<racarr> https://github.com/eMir-server/eMir
<racarr> oO
<racarr> eMir was forked from http://launchpad.net/mir as the '-ng' version of Canonical's Mir.
<kdub_> hah :P
<kdub_> ricmm, hopefully going well
<racarr> apparently my consumption of thai food from the place downstairs is high enough it motivated them to switch from plastic containers to compostable cardboard
<racarr> killing the planet one curry at a time :(
<robert_ancell> racarr, hey, do you think it's likely we'll have u8 on Mir usable by the end of the month? At least from our side?
<racarr> robert_ancell: Yes!
<robert_ancell> \o/ :)
<racarr> extremely
<racarr> robert_ancell: we should have images in parallel CI today. then this morning gerry and I came up with a plan to keep all of the shell
<racarr> in one surface, like they are doing now
<racarr> that is just on top of application surfaces
<robert_ancell> ah, cool
<racarr> which means they can implement the existing applicationmanager API they are exposing out to QML (what gerry is working on now)
<racarr> on top of libmirserver
<racarr> and
<racarr> BOOM!
<racarr> I am adding support for shaped surfaces today to mir (at leat on the the input side, for output they can just use transparency and clipping is an optimization later)
<racarr> this is kind of how they handle it on the phone images so will be easy
<racarr> oh I wanted to ask you, i heard some stuff about
<racarr> lightdm on the phone, and upstart, and launching applications
<racarr> and...
<racarr> well, that's basically what I heard XD. what does it all mean? I know there is an upstart job for launching applications
<racarr> where does lightdm come in to the picture?
<robert_ancell> racarr, otp, will get back to you on that. In short we're not involved
<racarr> ok
<racarr> I didn't think so much, just trying to get an idea of when the pieces
<racarr> will fall in to place
<mterry> racarr, so upstart will start lightdm; lightdm will start a greeter, and then once user is authenticated, lightdm will start the session
<racarr> and you use the session with upstart to launch application?
<racarr> s?
<mterry> racarr, you could yeah.  I think that's the plan, that the launcher could use upstart to launch apps
<mterry> racarr, that could happen today though, eh?  That's not a lightdm thing
<mterry> racarr, although maybe there isn't a user upstart session today?
<mterry> I think unity8 is launched via a system upstart session
<mterry> But I haven't read it closely to see whether it also starts a user upstart session
<racarr> mterry: I guess. I'm just confused because I heard it connected to lightdm
<racarr> and don't want to confuse you with my confusion XD
<racarr> I find
<racarr> std::chrono to be the most infuriating API
<mterry> racarr, well, lightdm will definitely have user sessions
<mterry> racarr, there may not be user upstart sessions today, I don't know.  They *could* exist, just depends on how the session-starter script is written
<robert_ancell> kgunn, reuse same hangout?
<kgunn> https://plus.google.com/hangouts/_/3d242d63010d29a68a15623903d47cd73b7e85a1
<kdub_> RAOF, ping
<robert_ancell> kgunn, sorry, was mixed up about which bug you meant - I've assigned the plymouth one back to me
<kgunn> robert_ancell: np
<kgunn> so should chris get the other ?
#ubuntu-mir 2013-06-18
<RAOF> kdub_: Pong
<RAOF> Yay! I can boot all the way to X again!
<kdub_> RAOF, so, the gbm-cleanup branch is ready to go from the mir side
<RAOF> And you'd like a review?
<kdub_> i guess I'm just trying to figure out how to land the mesa cleanup without disrupting too many people :)
<RAOF> Which mesa cleanup? Have I accidentally merged something that breaks the world?
<kdub_> well, that mp for mesa probably will break things if its pushed to the package
<RAOF> Oh, really? It didn't look like it, but I didn't actually test that :)
<kdub_> ah, well then I should just land ~kdub/mir/gbm-cleanup and everything will be ok then
<RAOF> It probably isn't in the mesa packaging yet, though; it got merged to egl-platform-mir, which requires an extra step.
<kdub_> RAOF, right, i suspect that the packaging hasn't picked up the change
<RAOF> I can make it so that the packages will do the right thing though.
<kdub_> RAOF, well, i guess lets do that
<RAOF> Yeah.
<kdub_> and then land gbm-cleanup right after they hit the ppa
<kdub_> really, i think "native_display.h" should probably be 'upstreamed' out of mir at some point
<kdub_> RAOF, close to my eod, should we do the transition tomorrow?
<RAOF> kdub_: I can probably walk it through myself.
<RAOF> It's just landing gbm-cleanup and the mesa changes at the same time, right?
<kdub_> right
<RAOF> Yeah, I can do that.
<RAOF> Oh.
<RAOF> Can you push a commit to gbm-cleanup bumping the version to 0.0.4? If not, I'll do that.
<kdub_> ah, sure
<kdub_> RAOF, done
<RAOF> bitchn.
<duflu> kgunn: Got more details for https://bugs.launchpad.net/mir/+bug/1191937 ?
<ubot5> Launchpad bug 1191937 in Mir "loss of x acceleration when xmir is loaded" [Critical,Triaged]
<kgunn> duflu: only details i have are...bregma was able to run xmir on an intel core w/ amd gpu
<kgunn> it was super slow, and dash is opaque
<kgunn> i believe he's still running it....if you needed debug/log info
<duflu> kgunn: Erm, sounds like Unity falling back rather than Mir. Maybe like https://bugs.launchpad.net/nux/+bug/1066764
<ubot5> Launchpad bug 1066764 in Nux "Unity fails to load on old hardware (compiz enabling LLVMpipe has no effect and Mesa tries to use hardware still)" [High,In progress]
<kgunn> duflu: could be....altho (this may be a bad assumption on my part) gpu acceleration was there
<kgunn> prior to loading xmir
<kgunn> bregma ? ^
<duflu> bregma? If you have details please add to https://bugs.launchpad.net/mir/+bug/1191937
<ubot5> Launchpad bug 1191937 in Mir "loss of x acceleration when xmir is loaded" [Critical,Triaged]
<bregma> I do not have an AMD GPU
<duflu> That's good news for me :)
<kgunn> bregma: my bad
<robert_ancell> RAOF, are you just copying the lightdm package into the system-compositor PPA?
<RAOF> robert_ancell: Yes.
<RAOF> bregma: Can you add the output of âLIBGL_DEBUG=verbose glxinfoâ to that bug - that'll give some idea of what's failing. (My guess is that it's lightdm failing to set permissions on the dri device properly)
<bregma> hmm, if I close the lid on this laptop networking goes away and never comes back, that's new...  unrelated to Mir, but new in the last couple of days...
<RAOF> Not super useful :)
<bregma> done and attached
<bregma> opening a terminal and using the Unity switcher are painfully slow, more signs of missing hardware acceletration
<bregma> but flash games run OK in the browser :)
<RAOF> Right. As I suspected, it's a permissions issue on /dev/dri/*
<RAOF> robert_ancell: https://bugs.launchpad.net/mir/+bug/1191937 is a âlightdm failed to set permissions to /dev/dri/* correctlyâ bug. I remember this happening before, and you fixed it. Do you happen to remember how? :)
<ubot5> Launchpad bug 1191937 in Mir "loss of x acceleration when xmir is loaded" [Critical,Triaged]
<robert_ancell> RAOF, lightdm doesn't set any permissions - we did see similar issues when console kit support wasn't working
<RAOF> I guess that's what I mean.
<robert_ancell> and the sympton for that was random session behaviour and erorrs in .xsession-errors
<RAOF> ConsoleKit would also be setting up the permissions for /dev/dri; they're meant to be rw- for the active session, and --- for everyone else.
<robert_ancell> RAOF, so it changes permissions on VT switch?
<RAOF> Correct.
<RAOF> Oh.
<RAOF> I see where you're going here :)
<robert_ancell> RAOF, well, that shouldn't matter for the single login case because there is no VT switch
<RAOF> Except that it might not set the permissions *at all* if you don't VT switch?
<robert_ancell> and it's normal for the session to be run by the lightdm user, then the user of the session logged into
<RAOF> Actually, I don't know whether it changes permissions on VT switch, or whether you can tell it that the current VT is where the logged in user is.
<robert_ancell> RAOF, so my current /dev/dri is root.video after booting using xmir
<robert_ancell> Is that what you expect?
<RAOF> robert_ancell: How about getfacl /dev/dri/card0?
<RAOF> Because *that's* got user:chris:rw-
<robert_ancell> # file: dev/dri/card0
<robert_ancell> # owner: root
<robert_ancell> # group: video
<robert_ancell> user::rw-
<robert_ancell> group::rw-
<robert_ancell> other::---
<RAOF> Hm. Ok.
<RAOF> And you presumably don't have any acceleration.
<robert_ancell> It seems laggily so
<robert_ancell> What is it on a normal boot?
<RAOF> I'm in a normal boot, and mine contains user:chris:rw-
<robert_ancell> RAOF, I can't see anything in the consolekit source that might change this
<robert_ancell> or GDM
<RAOF> I know that *something* applies the correct ACL for the user of the active VT.
<robert_ancell> udev?
<RAOF> I'm pretty sure that's consolekit (when we're using consolekit, obviously)
<RAOF> udev doesn't know anything about VT switching.
<robert_ancell> which we aren't anymore
<RAOF> Right. Which would presumably be why XMir works for me; I'm on Saucy.
<robert_ancell> RAOF, but how would the ownership changes be synchronised?
<RAOF> Oh, are you on saucy now?
<robert_ancell> yes
<RAOF> Hm. And it still doesn't work. Odd.
<robert_ancell> RAOF, this is from a fresh boot, It seems accelerated if I stop lightdm, then start it with xmir
<robert_ancell> kgunn, are you restarting lightdm from a console or changing lightdm.conf and restarting your machine?
<kgunn> robert_ancell: so first i try restart lightdm from the console....which just results in the blinking cursor (x console? )
<kgunn> then i restart
<kgunn> (hard boot)
<kgunn> note, i'm on saucy as well
<kgunn> when i say "first i try"...meaning right after i change lightdm.conf
<kgunn> and the hard boot results in the "you're running in low gfx mode"
<RAOF> Hm, ok.
<RAOF> I'll let these builds finish and then see if I can reproduce.
<kgunn> not sure if i said this...but i'm only toggling the lightdm.conf type=unity
<RAOF> kgunn: Are you running from ppa:mir-team/staging or from ppa:mir-team/system-compositor-testing?
<kgunn> RAOF: today...changed to the system-compositor-testing
<kgunn> (which i understand is supposed to be a stable collection)
<kgunn> (vs the staging that is)
<RAOF> Correct.
<RAOF> Ok. I'll pull from there, and see what falls out.
<RAOF> robert_ancell: Does the lightdm in the archive handle type=unity?
<robert_ancell> RAOF, no
<RAOF> Ok. So we need to bump the version of lightdm in the PPAs so that it supersedes the archive version.
<RAOF> kgunn: What does âapt-cache policy lightdmâ say+
<RAOF> ?
<kgunn> RAOF: 1.7.2-0ubuntu1
<RAOF> Right. That's why yours isn't working. That version of lightdm doesn't know how to XMir.
<kgunn> is 1.7.0 the only version?
<kgunn> RAOF: so i'm confused....shouldn't the system-compositor-testing ppa be dictating my lightdm version?
<RAOF> Only if you've done the apt-pinning dance.
<RAOF> I've made it so that all the XMir bits have a higher version than what's in the archive, but I don't have the ability to do the same for lightdm.
<robert_ancell> kgunn, we should be on 1.7.2 but it looks like jenkins is not CI/autolanding LightDM at the moment
<kgunn> robert_ancell: confused by your statement....i am on 1.7.2....
<robert_ancell> kgunn, you said " is 1.7.0 the only version"
<RAOF> Right, but the autolanding infrastructure should be autolanding 1.7.2+mir bits into the staging PPA.
<robert_ancell> RAOF, yeah, but it appears it's not anymore
<robert_ancell> duflu, have you ever checked the lightdm logs after it fails to start?
<kgunn> RAOF: robert_ancell ...when you say "1.7.2+mir bits"....do you mean lightdm trunk + lightdm patches just for mir ? or something else ?
<duflu> robert_ancell: Working through morning jobs and getting xmir on saucy yet
<duflu> I haven't used xmir for some... months :)
<RAOF> kgunn: lightdm trunk + lightdm patches for mir.
<robert_ancell> kgunn, more specifically - lp:~mir-team/lightdm/unity is the branch that has the unity (i.e. mir) support
<kgunn> RAOF: robert_ancell: thanks...making sense
<kgunn> robert_ancell: hence your point, ci not picking it up...so whatever is in the ppa is probably old (?)
<robert_ancell> duflu, ok. That bug has quickly become a "me to" bug for any issue in plymouth/lightdm/xmir/unity-system-compositor
<robert_ancell> not starting
<robert_ancell> kgunn, it's one version old
<robert_ancell> RAOF, do you get a purple box where the launcher should be (if launcher set to autohide) that redraws if you move the mouse over it?
<RAOF> robert_ancell: In XMir?
<robert_ancell> yes
<RAOF> Not last time I tried, but all my builds have now finished and I'm in the process of switching to XMir. So, I can give you an answer soon :)
<RAOF> However that sounds a lot like the launcher misrendering that I've experienced with llvmpipe.
<robert_ancell> RAOF, http://imgur.com/S7Ei9iK
<RAOF> Yup, that's some crazy interaction between llvmpipe, compiz, and damage.
<RAOF> robert_ancell: Care to review/approve https://code.launchpad.net/~raof/mir/gbm-cleanup-extra/+merge/169972 ? It's a couple of packaging commits on top of https://code.launchpad.net/~kdub/mir/gbm-cleanup/+merge/169306, which has already been approved.
<robert_ancell> ok
<robert_ancell> RAOF, why is llvmpipe running? I guess I'm not accelerated?
<RAOF> Yeah, that would be why.
<robert_ancell> RAOF, approved - you better land it before the existing trunk is built otherwise it wont make any difference...
<RAOF> robert_ancell: Whyso? Oh.
 * RAOF hadn't noticed duflu approving the old branch.
<RAOF> Ok. I've un-approved kdub's gbm-cleanup, and it looks like I've done that before the autolander kicked in.
<kgunn> see you guys tomorrow
<duflu> Bye kgunn
<duflu> robert_ancell: I assume that's an important branch if only one reviewer :)
<RAOF> duflu: It's the branch that got previously reviewed, plus 2 trivial commits.
<duflu> RAOF: Oh. I recommend setting the prerequisite field in future to clarify that in LP
<RAOF> Ok. Does that tell everyone âthis should land *in stead of* the prerequisite branchâ?
<duflu> RAOF: Nah, no such option :/
<duflu> But mebbe at least reject the old one first :)
<duflu> Otherwise some idiot like me might review and approve it
<RAOF> :)
<robert_ancell> RAOF, those dri permissions are very weird. I can confirm it doesn't have 'bob' when I'm using xmir, but it does when I'm using vanilla X. However - if I log in as 'belinda' it still only has 'bob' explicitly listed in the permissions
<robert_ancell> And it never lists 'lightdm' but the greeter still works
<RAOF> Does the greeter try to open /dev/dri?
<RAOF> I wouldn't expect so.
<robert_ancell> RAOF, so it's only once you try and open a GL app basically?
<robert_ancell> also, note it added me even though I hadn't logged in
<RAOF> It only *matters* once you try to open a GL app (as non-root)
<RAOF> It should be correctly set up first, though.
 * RAOF goes to see how u-s-c is broken on his system, now that everything's built and installed!
<RAOF> Ok. Without rebooting, everything works fine.
<RAOF> But then again, I still have the correct acl set.
<RAOF> Somehow.
<RAOF> Hm. And XMir works fine for me!
<RAOF> (Modulo the not-starting-on-boot-correctly bit, which I can now reproduce)
<RAOF> Huh. Possibly because I still have consolekit installed.
<RAOF> robert_ancell: There's no way to change the parameters given to unity-system-compositor by lightdm without changing the code, is there?
<robert_ancell> RAOF, no, what would you like to send?
<RAOF> I'd like to enable error reporting :)
<RAOF> Because the default appears to be "log nothing"
<RAOF> I was wondering why /var/log/lightdm/unity-system-compositor.log always seemed to be empty!
<RAOF> Oh, that's right. There's no autolanding happening for lightdm/unity.
<RAOF> Huh.
<robert_ancell> RAOF, I've pinged QA about that, hopefully will be sorted when Martin awakes
<robert_ancell> RAOF, please do enable reporting!
<robert_ancell> RAOF, did you see what happened when it wasn't starting on boot?)
<RAOF> I haven't enabled the reporting yet, I was trying to reproduce the no-permissions problem.
<robert_ancell> laters
<tvoss> good morning :)
<tvoss> RAOF, ping
<RAOF> tvoss: Pong
<tvoss> RAOF, hey there :) how is it going?
<RAOF> Pretty well.
<tvoss> RAOF, I retriggered builds for some of the packages in system-compositor-testing yesterday, we were hitting a broken builder
<RAOF> Ah, ok. That's why i386 was built this morning :)
<RAOF> Thanks!
<tvoss> RAOF, yw :) however, I'm hitting the plymouth issue with both ppas and unity is running unaccelerated
<tvoss> RAOF, I can, however, get an accelerated variant in some hackish way
<RAOF> So, I'm reproducing the unaccelerated bit.
<RAOF> Which is really odd.
<RAOF> *Sometimes* when starting lightdm it'll remove you from the acl on /dev/dri/*, which breaks acceleration.
<tvoss> RAOF, I love these issues
 * duflu thinks tvoss loves the wrong things about life
<RAOF> The first couple of times everything worked!
<tvoss> RAOF, so the point is: my hackish way to get acceleration is by _not_ restarting after installation but just restarting lightdm
<duflu> tvoss: Yep that's what I've been doing since January :/
<RAOF> Yeah, that should work. Also logging in to a VT and starting lightdm should *sometimes* work.
<tvoss> RAOF, I *think* lightdm tries to signal plymouthd in some way and does not succeed
<RAOF> I'm not sure what conditions are required for that to work. Maybe having an ssh connection?
<tvoss> RAOF, nope, I'm switching to a VT and call sudo service lightdm restart
<RAOF> Even after a reboot that should sometimes work.
<RAOF> But sometimes not!
<tvoss> RAOF, where is the race then?
<tvoss> RAOF, any gut feeling?
<RAOF> Oh, you're talking about the possibly plymouth race. I guess that's going to be plymouth not dropping DRM master soon enough, but I'm rebuilding lightdm so that I can get some actual debug logs.
<RAOF> I was talking about the unaccelerated bits.
<tvoss> RAOF, let me know if I can help :) I'm pretty fluent in resurrecting my system now
<tvoss> @unaccelerated: that's weird, why could that even happen? lightdm is setting us up for accel, right?
<RAOF> No, ish.
 * tvoss branches kwin
<tvoss> RAOF, ish :)
<RAOF> What *should* be happening is the login process thingy (consolekit or logind) should be setting the correct ACL on /dev/dri/* (ie: the user of the current VT should have access).
<RAOF> at interacts with lightdm, obviously, as lightdm is doing the login bity.
<tvoss> RAOF, hmmm ...
<duflu> Is it right that unity-system-compositor depends on an exact version of libmirserver0? This means whenever the former fails to build, the previous build is uninstallable because libmirserver0's build number has incremented
<RAOF> (if you run getfacl /dev/dri/card0 you'll get user:tvoss:rw- in the output if everything's working)
<RAOF> duflu: Yes. Because the alternative is that unity-system-compositor inexplicably segfaults whenever libmirserver changes ABI, which is frequently.
<tvoss> duflu, that's why we have system-compositor-testing, which is a "snapshot" of staging that avoids that problem
<duflu> RAOF: Oh yes. I forgot it depends on the less-settled libmirserver rather than client
 * duflu changes PPAs then
<duflu> RAOF: Umm, Jenkins just marked this as complete. 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]
<RAOF> Once the corresponding mesa has built, yes.
<tvoss> RAOF, can you give me a status of buffer_age, that is, take a look to what degree we have it wired up?
<RAOF> tvoss: Looks like it's not exposed to EGL.
<tvoss> RAOF, okay, thanks
<duflu> That reminds me... When I wrote fingerpaint and needed single-buffering, I thought a nice alternative might be to have some client-side visibility of aging buffers. It would have been much more efficient if I knew the API would guarantee persistence of some sort...?
<tvoss> RAOF, is it a huge benefit to wire it up now?
<duflu> ... that is after-all the intention of buffer_age (http://www.khronos.org/registry/egl/extensions/EXT/EGL_EXT_buffer_age.txt)
<duflu> RAOF: I can deduce that X-something is meant to update the DRI device perms. But what?
<duflu> It can only know to do that after a user as logged in. So maybe it's a hook in the X graphics driver we broke?
<duflu> RAOF: I can deduce that X-something is meant to update the DRI device perms. But what?
<duflu> It can only know to do that after a user as logged in. So maybe it's a hook in the X graphics driver we broke?
<RAOF> No, it's something to do with our login-tracking infrastructure.
<RAOF> Because logging in to a VT sets the acl correctly.
<duflu> RAOF: Where does such infrastructure live?
<RAOF> logind or consolekit, I believe.
<duflu> libck-connector0?
<RAOF> On Saucy we shouldn't be using consolekit, so logind.
<RAOF> Wooo!
<RAOF> loginctl is the command to check, I think.
<RAOF> Hm3.
<RAOF> I seem to have three login sessions, one of which does not have a SEAT attached.
<RAOF> So, now that I've got unity-system-compositor doing some loging, I'm going to reboot and see what's happening when it doesn't work on boot.
<RAOF> Ok. So, unity-system-compositor dies with no output before âI0618 16:52:50.382107  2032 glog_logger.cpp:80] [graphics] Successfully setup native resources.â
<RAOF> Also, it looks like XMir sessions get registered with logind but not associated with a seat, which is plausibly the reason for the permission problem.
<RAOF> It's ZoÃ«
<RAOF> -time, but I'll come back and see what's what when that's done.
<tvoss> RAOF, thx for the feedback :) can you ping me once back?
<RAOF> tvoss: Back for 20 minutes or so before the next round of Zoination.
<tvoss> RAOF, how can we move ahead while you are offline? Trying to get a quick tasklisk down
<RAOF> tvoss: For the plymouth-doesn't-die-on-boot thing, tracing the code to see what could cause unity-system-compositor to bail *before* it would normally log â[graphics] Successfully setup native resourcesâ would be the way to go.
<tvoss> RAOF, noted down
<tvoss> RAOF, got a  branch up that people can get started with or is this in trunk?
<RAOF> For the âNo accel in XMirâ problem, checking the logind documentation/source to see how/where/why it doesn't set the /dev/dri/* acl.
<RAOF> Hm, no branch yet. Let me push those up.
<tvoss> RAOF, ack
<RAOF> So, getting debugging info out of unity-system-compositor requires lp:~raof/mir/unity-system-compositor-commandline-passing
<tvoss> RAOF, cool, thanks
<duflu> tvoss: No accel: https://bugs.launchpad.net/mir/+bug/1191937
<ubot5> Launchpad bug 1191937 in Mir "loss of x acceleration when xmir is loaded" [Critical,In progress]
<duflu> Plymouth CPU: https://bugs.launchpad.net/ubuntu/+source/plymouth/+bug/1192051
<ubot5> Launchpad bug 1192051 in plymouth (Ubuntu) "plymouthd spinning at 100% CPU" [High,New]
<RAOF> tvoss: Also needs lp:~raof/mir/lightdm-enable-u-s-c-logging
<tvoss> duflu, great, thx
<RAOF> So, it looks like pam-systemd is responsible for setting up the seat thingies.
<RAOF> Hm. Or maybe not?
<tvoss> RAOF, who might be able to clarify here?
<RAOF> pitti knows systemd best, I think.
<RAOF> So, I think dumping the dbus traffic to org.freedesktop.login1 would be instructive.
<tvoss> RAOF, cool
<tvoss> alan_g, ping
<RAOF> Gargh, logind.
<RAOF> VT != session.
<alf> RAOF: tvoss: duflu: Have you seen any problems with VT switching with Mir in saucy? Every time I try to VT switch my graphics hang... (everything worked fine in raring) :/
<duflu> alf: I did have that bug Alan fixed but haven't tested the fix since it landed(?)
<duflu> alf: Also I logged: https://bugs.launchpad.net/mir/+bug/1189770
<ubot5> Launchpad bug 1189770 in Mir "[regression] Killing Mir with Ctrl+C often leaves the screen blank and difficult to recover " [High,New]
<duflu> alf: The client's meant to hang right? So you mean your host hangs?
<alf> duflu: my whole system hangs, sometimes I can't even ssh :/
<duflu> alf: I did see one intel GPU hang kernel message (and actual hang) today
<duflu> But only one
<duflu> on saucy
<alan_g> tvoss: pong (sorry missed you)
 * duflu wonders why we're not considering the bug to be in lightdm as he looks at the lightdm source (seating logic)
<duflu> or src/seat-unity.c ;)
<hikiko> question:
<Stskeeps> g 21
<hikiko> (hello!)
<hikiko> I am checking the demo_client_accelerated.cpp
<hikiko> there's no MirDisplay or something? you create windows using egl (EGLDisplay) and pass the egl surface to mir?
<hikiko> it seems that the client does the rendering using EGL :s but I might be wrong
<duflu> hikiko: "Window" creation:     surface = mir_connection_create_surface_sync(connection, &request_params);
<hikiko> oh yes there's MirSurface :) sorry!
<RAOF> Aha!
<RAOF> get_seat_from_display in systemd/login/pam-module.c
<tvoss> alan_g, RAOF is looking into the issue, too
 * alf just recovered from another saucy graphics crash...
<alan_g> tvoss: should be move discussion where he can see it?
<alan_g> *we
<tvoss> alan_g, sure
<duflu> alf: Just saw: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/761065/comments/86
<ubot5> Launchpad bug 761065 in linux (Ubuntu Natty) "[Sandybridge] Spurious "*ERROR* Hangcheck timer elapsed... blt ring idle" messages in dmesg when using compiz" [Medium,Fix released]
<duflu> RAOF: Oh good. I was trying to learn about "seats" and systemd
<duflu> alan_g, the discussion is open here: https://bugs.launchpad.net/lightdm/+bug/1191937
<ubot5> Launchpad bug 1191937 in Light Display Manager "loss of x acceleration when xmir is loaded" [Undecided,Confirmed]
<alf> duflu: Thanks, but this happens on radeon. This time I just tried to stop a mir client and server and the whole system froze :(, plus I can't get find any useful log messages about what happened...
<duflu> Hurray for new kernels and alpha distros
<RAOF> So, I think I see where it's going wrong. pam-systemd tries to do a reverse-lookup from the DISPLAY socket to the VT, and hence the seat. It does this by looking up the controlling tty of the xserver process. I don't _think_ that will be a VT in the nested case, so this fails.
<RAOF> And now, dinner.
<alan_g> RAOF: just been looking at failures in EGLHelper::setup (i.e. before the "Sucessfully setup" log) - the exceptions would be caught in main() and reported to std::cerr. Am I right in thinking this won't be captured?
 * tvoss is compiling piglit :)
 * tvoss notes: running piglits sanity tests results in unity crashing :)
<pitti> tvoss: hello
<tvoss> hey pitti :)
<tvoss> pitti, we are running into an issue where hardware accel for mir as the system compositor is not working due to the acl for /dev/dri* not being setup correctly
<tvoss> pitti, RAOF had tracked it down to: <RAOF> So, I think I see where it's going wrong. pam-systemd tries to do a reverse-lookup from the DISPLAY socket to the VT, and hence the seat. It does this by looking up the controlling tty of the xserver process. I don't _think_ that will be a VT in the nested case, so this fails.
<tvoss> systemd/login/pam-module.c
<pitti> tvoss: so that's the per-user-session MIR instance? that runs as the user?
<pitti> or is that the system-wide compositor?
<tvoss> pitti, nope, that's the system-wide Mir session, being started by ligthdm
<pitti> which runs as some system user?
<tvoss> pitti, yup
<pitti> by lightdm? that sounds strange
<pitti> I thought we'd have MIR running right from the start, for booting and lightdm
<tvoss> pitti, that's the goal, right now, it's lightdm starting Mir
<tvoss> pitti, for that, we have https://launchpad.net/unity-system-compositor
<tvoss> pitti, which takes over the seat essentially
<pitti> tvoss: which user is that running as?
<tvoss> pitti, checking ...
<pitti> tvoss: i. e. not "root" and not "martin", but it would be a system user like "lightdm" or "mir"?
<tvoss> pitti, yup
<pitti> ok, this most likely doesn't have a PAM session
<RAOF> alan_g: No, stderr should be captured by the log.
<pitti> and also, session tracking wouldn't really apply to this AFAICS
<pitti> so it seems to me that it would be prudent to put this system user into the video group?
<RAOF> http://paste.ubuntu.com/5776654/
<RAOF> pitti: c3 is my user XMir session, as started by lightdm. c1 is a VT login.
<RAOF> pitti: And the problem is that - if I don't have a VT session logged in - my user isn't added to the /dev/dri/* acl, because logind doesn't have it associated with a seat, and logind only sets the acls for seated-things.
<pitti> right; we don't want ACLs for non-seat logins such as cron or ssh
<pitti> RAOF: so lightdm starts a session which is basically xmir, which then starts the "real" session (like unity)?
<RAOF> pitti: lightdm basically starts Xservers as normal.
<RAOF> pitti: It's just that lightdm *first* starts the system-compositor, doesn't VT switch, and hooks all the Xservers up with unity-system-compositor.
<pitti> RAOF: ah, so the concept of session tracking via observing VT switches doesn't work any more
<RAOF> pitti: Correct.
<RAOF> All the sessions run on the same VT.
<tvoss> mlankhorst, ping
<pitti> RAOF: so I guess ATM all sessions are "active" at the same time
<RAOF> pitti: Correct - as you can see, both my VT session and XMir session are active, because they both happen to be on VT 1.
<pitti> RAOF: is there an equivalent of $DISPLAY, i. e. how does a Mir-aware program know which session it belongs to?
<mlankhorst> tvoss: pong
<pitti> RAOF: I guess we'd need to teach logind about that method then, unless we still have $DISPLAY (that might even be enough for the XMir case)
<RAOF> pitti: We still have $DISPLAY (as you can see from my output), but I *don't* think you can reverse map $DISPLAY to the VT it's running on.
<RAOF> pitti: At least, it looks a lot like pam-systemd as it currently stands cannot do that.
<pitti> right, that's where things go wrong
<pitti> RAOF: are you sure the problem is in the PAM module?
<pitti> RAOF: that just tries to separate the cases of "VT given" from "display given", and passes it as two separate arguments to CreateSession
<mlankhorst> RAOF: can you accept the packages still in new? https://launchpad.net/ubuntu/precise/+queue?queue_state=0
<RAOF> pitti: No, but the output of loginctl suggests that the session was set up without a VT set.
<pitti> RAOF: I had thought the problem is in logind.c itself, in the actual session/seat tracking
<RAOF> mlankhorst: Do they need to be in main, or universe?
<mlankhorst> main
<RAOF> mlankhorst: They need to be in main, don't they. Cool.
<duflu> pitti: We have hidden the information (clients should pass path NULL) but it is always using /tmp/mir_socket for now
<duflu> No environment is used
<RAOF> mlankhorst: Done.
<mlankhorst> thanks!
<RAOF> We're likely to end up either with an environment variable or just a well-known path. I think we're more likely to end up with the latter.
<pitti> RAOF: hm, so we are only ever going to have one VT for everything, we can't use the VT number to track sessions
<duflu> Possibly both eventually. But I was trying to keep the path a secret to avoid hard-coded chaos
<RAOF> Indeed.
<pitti> RAOF: hence my feeling that this needs to be changed in the active session tracking
<RAOF> Oh, we *also* need to change the active session tracking.
<RAOF> But we need that to support multi-user.
<RAOF> We need "actually associate with a seat" for it to work at all ;)
<pitti> for seat, yes
<pitti> RAOF: that will only cover devices which have per-seat ACLs though, like /dev/dri
<pitti> not the per-session ones like audio
<pitti> (or usb)
<RAOF> But that's ok because all sessions are treated as active :)
<pitti> not really
<pitti> we only want the active session to have access to audio devices, USB sticks, scanners, cameras and the like
<RAOF> Oh, yes.
<pitti> otherwise there wouldn't be a clear "owner" of them, and concurrent access
<RAOF> But for a first go, having a single user have access to those things is nice!
 * duflu thinks these guys have it under control and goes to make dinner
<pitti> yes
<pitti> RAOF: so the problem there is that the xmir process doesn't have any tty associated to it?
<RAOF> That is my suspicion. I haven't checked that (and it's 8:30 here, so I'm not likely to tonight :))
<pitti> RAOF: you can check the xmir process' /proc/pid/stat
<pitti> the TTY is the 4th number after the state ('R')
<RAOF> 0, apparently.
<RAOF> Which should be a valid TTY.
<pitti> no, it's "nothing"
<pitti> that's a device number
<pitti> i. e. a major/minor in one int
<pitti> e. g. my bash has 34825, which is major 136, minor 9
<pitti> i. e. /dev/pts/9
<pitti> tty would be major 4, i. e. 1024+ttynumber
<RAOF> Ah, right.
<pitti> my X process has 1031, i. e. tty7
<RAOF> Yeah, no tty for xmir.
<pitti> ok, that's a bit odd
<pitti> RAOF, tvoss ^ so that seems strange for a process not not have any tty/pty; is that deliberate?
<pitti> phone, brb
<tvoss> pitti, wrong person to ask
 * tvoss that is
<RAOF> pitti: No, that actually seems perfectly sane - XMir doesn't open a tty, so it won't have a controlling tty.
<RAOF> X would normally open a tty in order to do VT switching, but XMir can't do that.
<pitti> ok, RAOF is gone
<pitti> so, I'll make some investigations how that could happen; I'm not that proficient in that tty/pty area
<didrocks> (told the guy knowing on which major block device numbers are using the ttys)
<didrocks> apart if you cheater with ls -l /dev/tty7, but I would be disappointed :)
<ogra_> note that the ubuntu touch kernels largely dont have VT support enabled
<ogra_> (there are no /dev/yyz[0-9] at all
<ogra_> )
<ogra_> err
<ogra_> tty
<alan_g> \o/ My desktop finally booted a saucy image
<alf> alan_g: Have you tried using clang on saucy?
<alan_g> alf not yet
<alf> alan_g: ok, I am getting stddef.h cannot be found errors
<alan_g> alf: I've just got to the point of being able to build g++/naive on my desktop - will try clang next if it helps
<alan_g> alf: just a thought - you did vape the cmake cache first?
<alan_g> Hmm - "4 tests failed"
<alf> alan_g: no haste, it's not blocking me, just wondering if you had seen it. I did a build in a clean dir, plus just compiling a trivial .c file fails with clang
<alan_g> sounds like clang isn't installed correctly
<alan_g> alf: FWIW clang compiles fine for me (tests hang of course)
<alf> alan_g: thanks, so I guess something went wrong during the upgrade
<alan_g> alf: I ended up repartitioning my system disk before I got saucy to boot
<alan_g> So, for once, I've a pretty clean install
<alf> alan_g: do you have clang 3.2 or 3.3?
<alan_g> 3.2
<alf> alan_g: can you please try and pastebin the output of "clang -v bla.c" (where bla.c includes eg. stdio.h)
<alan_g> alf: https://pastebin.canonical.com/93010/
<alf> alan_g: thanks
<alf> alan_g: heh, just removing and reinstalling clang fixed things...
<alan_g> alf: of course. (That's the fun of upgrades)
<racarr> tMorning
<kdub_> morning
<alan_g> afternoon
<racarr> ** DONE Land platform API...
<racarr> that was a todo for...too long
<tvoss> racarr, it's in? :)
<racarr> yep, qtubuntu or today
<racarr> for*
<tvoss> racarr, not bad :) not bad :)
<alf> kdub_: IIRC, at some point you proposed some noexcept changes for NiceMock/StrickMock. Any update? (I updated our internal gmock and have come across the same issues again with 4.7... 4.8 works fine without any change)
<kdub_> alf, no, not a lot of movement upstream https://groups.google.com/forum/?fromgroups#!topic/googlemock/ZO4Q1vR7XfM
<alf> kdub_: ok, I will apply the patch manually then
<racarr> alan_g: Applied your suggestion (misread them the first time ;)) to https://code.launchpad.net/~robertcarr/mir/improve-input-acceptance/+merge/169483
<racarr> if you have time for another review before EOD
<racarr> I have to write some acceptance tests today and was hoping to use it :D
<alan_g> racarr: sure
<racarr> thanks :)
<racarr> I feel like oprah on launchpad today
<racarr> and you get an approve! and you get an approve! and you get an approve!
<racarr> kdub_: Is there any trick for adb shell just...working weird in terms of terminal functionality? i.e. every text editor has some weird glitches
<racarr> that make it super hard for me to edit files on the phone
<kdub_> no, not really... unless i'm investigating kernel crashes or something, i usually ssh in
<mterry> racarr, I'm trying to follow http://studio.sketchpad.cc/gmY0M6iqeh but ran into a problem with boost
<racarr> mterry: Of what sort?
<mterry> racarr, I know!  Like nano doesn't like Enter
<mterry> racarr, I am at the ./build -s step of unity
<mterry> racarr, and it wants to install libboost1.49-dev, which conflicts with libboost1.53-dev
<racarr> mterry: hmm
<racarr> I don't have an immediate guess as to why that happened...but I think
<racarr> you could find the explicit 1.49 dependency and just make it
<racarr> non explicit or 1.53
<mterry> racarr, I see your platform-api change landed in trunk, but not yet the packaging changes to build with mir?
<racarr> mterry: Thoe live in lp:~robertcarr/platform-api/mir-with-packaging
<racarr> we are doing parallel CI
<racarr> also you can use bzr branch lp:~unity-team/unity/phablet-integrate-mir
<racarr> instead of phablet-tuesday now
<racarr> XD
<racarr> mterry: Im in the process of testing out the qtubuntu packaging build on the phone
<racarr> but um. had to reimage my phone
<racarr> and building everything takes a long time
<racarr> I really enjoy this sketchpad thing
<racarr> XD
<mterry> racarr, ah, looks like phablet-integrate-mir needs to merge from trunk.  It has boost1.49 in its ./build script, but trunk has fixed that
<mterry> and by trunk, I mean unity/8.0
<racarr> ah probably
<racarr> I dont think I am in unity-team so you will have to do it locally for now
<racarr> mterry: ^
<racarr> oh
<racarr> I definitely am
<racarr> merging and what not
<racarr> hmm
<racarr> I need to find a base revision manually apparently
<racarr> hmm
<racarr> 91 conflict
<racarr> all time record
<racarr> I think I don't understand bzr
<racarr> I found a base revision but then apparently it becomes a 'reverse cherry pick' and loses branch history
<racarr> and also I cant use weave merge
<racarr> oh
<racarr> I see
<racarr> they literally have no common ancestory because its
<racarr> a new repo
<racarr> -.-
<kdub_> android drivers don't like us shuffling the buffers out from underneath them while we ignore their reference requests...
<arsson> just manage to install unity-system-compositor and unity was gone but i have two cursors
<arsson> you do some strange thing in there :)
<tvoss> arsson, that's expected :)
<tvoss> arsson, raof is working on getting rid of that, it's only the hw cursor not being wired up to the X side completely, yet
<tvoss> arsson, please note that you might be running unaccelerated X right now, too, as the acl on /dev/dri* are not setup correctly (being worked upon, too) :)
<tvoss> arsson, which ppa did you use?
<arsson> stagein
<arsson> Mir staging ppa
<tvoss> arsson, cool, thx
<arsson> well unity-system-compositor is not installable anymore
<arsson> that was quik
<tvoss> arsson, yup, the components in there rev too fast, that's why we have system-compositor-testing ppa, same team
<arsson> do i dare to try that?
<tvoss> arsson, not yet, you should wait for the permission issue to be fixed
<tvoss> arsson, I'm waiting for that, too :))
<arsson> ok. lets watch porn then! :)
<tvoss> arsson, I'd rather prefer wine, but have fun :)
<kgunn> :)
<kgunn> robert_ancell: anything i can do here to help debug or try
<robert_ancell> kgunn, you get the lock up on boot right?
<kgunn> robert_ancell: depends on definition of lock up....
<robert_ancell> fails to get to greeter?
<kgunn> i was getting to the little gui...."you are running in low gfx mode".....but effectively stuck there
<kgunn> robert_ancell: for sure...fails to get greeter
<robert_ancell> kgunn, ugh, I haven't seen that
<robert_ancell> I'm trying to track down plymouthd using 100% CPU and the system-compositor failing to start
<kgunn> robert_ancell: yeah...but didn't we determine i had an incompat lightdm mismatched
<kgunn> robert_ancell: wonder if i need to ppa-purge....start fresh
 * kdub_ was hoping we didn't have to give android drivers strong refs to their buffers... looks we do though
<kdub_> will get rid of that weird "ensure_no_live_buffers_are_bound()" interface on mg::GLRenderer
<kdub_> the whole 'dynamic buffers!' has been good for polishing out some rough edges of the android system
<kdub_> maybe even one day, we'll be able to resize ;-)
<kgunn> kdub_: don't tease
<racarr> Hmm
<racarr> so now when I try and build trunk I get warnings that libEGL.so may conlict withw
<racarr> libmirclient.so
<racarr> and then check-discover-acceptance-tests
<racarr> crashes
<racarr> any ideas?
<racarr> I guess my mesa needs updating
<kdub_> racarr, yep
<RAOF> Mornin' all.
<racarr> kdub_: is the mesa I need int he PPA?
<racarr> I am having series of strange link errors
<racarr> Morning RAOF :)
<RAOF> racarr: Grr. Let's have a butchers.
<racarr> blerp?
<RAOF> âbutcher's hookâ â âlookâ
<racarr> this seems like
<racarr> some pretty advanced rhyming slang
<kdub_> lets see...
<RAOF> It's the standard double-indirect cockney rhyming slang!
<RAOF> racarr: The mesa you need is *not* in the PPA, apparently because Launchpad hasn't noticed that libmirclient-dev 0.0.4 has built.
<racarr> oh
<racarr> that sounds suspiciously similar to something that would cause the link errors
<RAOF> Stupid launchpad. It's meant to trigger when the dependencies of a dep-wait package are built!
<racarr> I am getting
<RAOF> Anyway, amd64 is now appears to be building, so everything should be peachy soon.
<RAOF> racarr: What do I have to do to get unity-system-compositor to *not* appear to freeze when pressing <alt>+<left>?
<RAOF> (Because that's going to the kernel VT subsystem, which is switching VTs, so unity-system-compositor is suspended)
<racarr> RAOF: I think something like this
<racarr> https://code.launchpad.net/~robertcarr/mir/disable-sequences-and-add-terminate-handler/+merge/164014
<racarr> in particular around here
<racarr> + int make_raw(int vt_fd)
<RAOF> Oooh, of course.
<RAOF> I could totally do that in u-s-c.
<kdub_> RAOF, thanks for handling the driver bump, btw
<RAOF> No probelm.
<RAOF> Oh, *arse*.
<RAOF> 0.4 â  0.0.4
<RAOF> *That's* why!
#ubuntu-mir 2013-06-19
<RAOF> racarr: When jenkins picks up the new commits to mesa you'll have a mesa that actually builds in the PPA.
<racarr> RAOF: Yay, thanks, in the interim I justs purged the ppa
<racarr> dont need to run mir right now just build it XD
<RAOF> :)
<RAOF> What the what, launchpad?
<RAOF> In what way is 0.0.4bzr756saucy0 not >= 0.0.4?
<RAOF> ??? And mesa is building on armhf for some reason?
<robert_ancell> RAOF, can you clarify the purpose of the system-compositor-testing PPA? What is different over the testing PPA (just that the packages are manually synchronized?)
<RAOF> robert_ancell: That is exactly the difference, yes.
<robert_ancell> ok
<duflu> robert_ancell: It's to avoid https://bugs.launchpad.net/unity-system-compositor/+bug/1191338
<ubot5> Launchpad bug 1191338 in Unity System Compositor "Dependency on libmirserver is brittle" [Undecided,Confirmed]
 * duflu reboots
<robert_ancell> yeah, thought so
<robert_ancell> RAOF any more info on the dri permissions? I was wondering if it might be a side-effect of the DRM going via the system compositor (wild speculation here)
<RAOF> robert_ancell: logind doesn't associate XMir sessions with a seat, so doesn't set up the dri permissions.
<robert_ancell> RAOF, ok cool. So I need to track down why logind isn't happy
<RAOF> And it fails to associate the XMir session with a seat because the XMir server doesn't have a controlling tty.
<RAOF> We could set XDG_SEAT="seat0" in the pam environment.
<robert_ancell> RAOF, but we don't do that for the VT+X case and that works
<robert_ancell> right?
<RAOF> Correct, but in that case X is opening a tty (because it needs to do VT manipulation) and so logind can do a reverse-lookup from $DISPLAY to seat.
<robert_ancell> ah
<robert_ancell> yay for hacks behind the scene
<RAOF> Ding!
<robert_ancell> Is that info in the bug report?
<RAOF> Yes
<duflu> Further to my last point it's then ironic that ppa:mir-team/staging just broke my system :/
<RAOF> Hah!
<duflu> robert_ancell: Can we please make sure type!=unity for the staging PPA by default? It means our dev environments could become unusable at the first sign of any system compositor/lightdm problems
<RAOF> duflu: I can flip the default.
<robert_ancell> duflu, yeah, that seems fair
<duflu> robert_ancell: Also, when I went back to vanilla lightdm... it just does nothing on type=unity instead of defaulting to something that works. Is that intentional?
<robert_ancell> duflu, correct - if the seat type is unknown it stops (and failsafe X should work)
<RAOF> duflu: You can run âdpkg-reconfigure unity-system-compositorâ and select ânoâ to undefault.
<duflu> No failsafe. Just VT console
<duflu> Ta RAOF
<duflu> Try again...
<RAOF> duflu: That worked, right?
<duflu> RAOF: Didn't have to. After I reinstalled I have lightdm being kept back again ;)
<RAOF> Heh.
<duflu> Hence no unity-system-compositor to reconfigure
<RAOF> thomi: Are you here? What's happening with mesa autolanding?
<duflu> RAOF: Where did the discussion end with pitti last night?
<RAOF> That logind needs to learn that VTs are not the same as sessions, and that he'll look into that.
<duflu> RAOF: Hmm, might be dangerous to assume there's nothing we need to do. Are you sure he's doing it? Should we?
<RAOF> Oh, we *also* need to tell logind about the seat.
<duflu> RAOF: I tried a system-wide XDG_SEAT=seat0 last night but obviously that was too wishful
<duflu> Or the environment got clobbered
<RAOF> It needs to be in the pam environment; I'm not sure if you can influence that with /etc/environment.
<RAOF> I'm heading out for lunch; back in an hour or so, whereupon I shall investimigate further.
<duflu> RAOF: Tell logind precisely in what form?
<duflu> OK, bye
<duflu> That's weird. My xmir login on top of unity-system-compositor appears on every second (even) VT... F2, F4, F6
<duflu> robert_ancell, ^
<robert_ancell> duflu, odd
<robert_ancell> RAOF, aw yeah, that XDG_SEAT does the trick!
<92AAAUIMO> robert_ancell: Woo! One down.
<robert_ancell> 92AAAUIMO, new nick?
<92AAAUIMO> â¦I did not notice that.
<tvoss> god morning gentlemen :)
<tvoss> +o, obviously
<tvoss> RAOF, ping
<RAOF> tvoss: Pong.
<tvoss> RAOF, any luck with the dri permissions?
<RAOF> Yes; Robert's setting XDG_SEAT from lightdm, and that unconfuses logind.
<tvoss> \o/
<tvoss> RAOF, does that solve the plymouth issue, too?
<RAOF> No.
<tvoss> RAOF, hmmm, do we have any idea for the plymouth issue, then?
<RAOF> Alan was looking at that last night. I don't know if he found anything because my IRC bouncer died.
<tvoss> RAOF, ah okay, will grab alan then
<tvoss> RAOF, piglit running in the lab: https://jenkins.qa.ubuntu.com/view/All/job/piglit-nvidia-gt440-le-daily/1/artifact/results/html/index.html
<tvoss> https://jenkins.qa.ubuntu.com/view/All/job/piglit-intel-2500-le-daily/15/artifact/results/html/index.html
<tvoss> https://jenkins.qa.ubuntu.com/view/All/job/piglit-radeon-hd7450-le-daily/1/artifact/results/html/index.html
<tvoss> running a daily cadence
<tvoss> I thought about running selected phoronix tests on the infrastructure against XMir, too
<tvoss> makes sense?
<RAOF> Yeah, that could work.
<duflu> tvoss: I was going to investigate the plymouth spin momentarily
 * duflu wishes people would mark things as in progress so we don't all work on the same bugs
<tvoss> duflu, +1
<tvoss> duflu, might make sense to sync with alan
<tvoss> duflu, with the plymouth out of the way, we would have something dogfoodable and runnable in the lab at scale
<tvoss> robert_ancell, good morning/evening :)
<robert_ancell> tvoss, hello
<tvoss> robert_ancell, how goes?
<robert_ancell> RAOF, does XMir definitely not use any VTs? I seem to have the compositor running on 7 but XMir was on 8
<robert_ancell> tvoss, busy with change in priorities
<tvoss> robert_ancell, I can imagine :)
<RAOF> robert_ancell: I'm pretty sure XMir doesn't do any VT things; let me check again.
<robert_ancell> RAOF, I notice I'm actually setting 'vt7' as an arg to the X server, not sure if that would have any effect
<RAOF> I believe that it won't.
<RAOF> robert_ancell: Yeah, xorgMir => xorgHWOpenConsole == FALSE => dontVTSwitch == TRUE.
<robert_ancell> RAOF, but does it allocate a VT?
<robert_ancell> There is a -novtswitch option that will stop it automatically switching to a VT, but that doesn't stop it running on one
<RAOF> robert_ancell: It doesn't call xf86OpenConsole, so it shouldn't allocate a VT.
<robert_ancell> ok
<kgunn> tvoss: phoronix does make sense, got to thinking late yesterday....we need something sub 60fps specifically for xmir
<kgunn> i added a work item for it in the xorg bp for when we have accel x back
<tvoss> kgunn, yup, that's what I'm thinking, and I think that we should get started broadly and focus on specific benchmarks as we see issues arising
<kgunn> tvoss: the nexuiz wasn't too long in terms of run time (at least shorter than openarena)
<kgunn> and it was 21fps avg
<tvoss> kgunn, on what kind of system?
<kgunn> on my i5 w/ sandybridge
<tvoss> kgunn, let's leave runtime considerations aside for the moment, that's a luxury issue to solve/optimize when we have the stuff running on a cadence
<RAOF> kgunn: Actually, we don't need < 60 fps for xmir, because xmir doesn't support vblankd swapbuffers.
<kgunn> RAOF: it is 1am...do you mean its not vsync'd (it tears) ?
<RAOF> kgunn: Correct. Plus, because of this, it's not capped to 60fps.
<RAOF> Although the *output* is, because unity-system-compositor is locked to 60fps.
<RAOF> glxgears: 11785 frames in 5.0 seconds = 2356.963 FPS
<kgunn> RAOF: actually that's perfect....and still what we want
<kgunn> technically, if there is any overhead to xmir, it would still show up
<RAOF> It would indeed.
<kgunn> in a benchmark that's already running sub 60fps due to load
<kgunn> and i think that would answer the faq that will come from people
<kgunn> "how much will xmir cost me in perf"
<racarr> I accidently awake. Happy almost weekly meeting :)
<kgunn> racarr: happy almost weekly meeting to you too....you shouldn't have :)
 * kgunn set alarm for 12:30....worried he might be in semi dream state
<tvoss> kgunn, couldn't we adjust the cadence on a bi-weekly basis to make it mutually less painful for the different timezones?
<racarr> kgunn: I lost track of time reading
<kgunn> tvoss: spent time looking at this once...and basically not realistically....pretty well the only time if
<tvoss> kgunn, ah okay
<racarr> I had the idea the other day that maybe there are two parts to the benefits of the weekly meeting
<racarr> 1. High bandwidth communication
<kgunn> you want west coast, aus, nz, euro
<racarr> but also 2. Cadence
<racarr> so maybe having some sort of document
<racarr> that we try and like do a "rolling" weekly meeting in (raising issues and people respond, etc) then we try and wrap up in to a consensus once a week
<robert_ancell> racarr, kdub_, alf, RAOF, duflu, meeting
<robert_ancell> hikiko, meeting
<robert_ancell> and kgunn too today :)
<hikiko> robert_ancell, joining in a minute
<RAOF> We take this opportunity for unity-system-compositor to lock up the GPU.
<tvoss> RAOF, :)
<racarr> I dropped
<racarr> rejoining isnt working
<robert_ancell> kgunn, alan_g might be a good match for the multi-monitor now
 * duflu dropped too
<duflu> Only the hangout died
<duflu> Gah. The hangout is just silent
<duflu> What's going on?
<racarr> duflu: Thats all I can see too
<RAOF> duflu: INTERNETS!
<duflu> I has internets
<duflu> I give up. I have no video or audio now. I only see the chat
<alf> http://unity.ubuntu.com/mir/modules.html
<racarr> good nightmorning :)
<racarr> alan_g: You just missed the xmir party of the century
<duflu> So good we broke the hangout
<duflu> Someone please let me know if I missed anything important from the end of the hangout. It refuses to work now
 * duflu runs to the post office
<tvoss> kgunn, ping...still around?
<tvoss> alan_g, duflu is anyone of you looking into profiling mir with callgrind right now?
<duflu> tvoss: I did so just before Oakland. I will email you the results as a reminder
<tvoss> duflu, thanks, got the full call tree around?
<duflu> tvoss: No. Those things go out of date within hours
<tvoss> duflu, agreed :)
<tvoss> duflu, do you think it makes sense for the both of us to look into that deeply?
<duflu> tvoss: I was, and would like to again. But have been given different tasks for now
<tvoss> duflu, okay
<tvoss> duflu, if you can hand over your setup to me, I'm happy to have a look
<duflu> tvoss: Email sent. I can't remember any specific setup other than callgrind a mir server while a client is rendering at a full 60 FPS
<tvoss> duflu, cool, thx
<RAOF> Gah!
<RAOF> Who knows how the saucy autolanding stuff for mesa is supposed to work? Also, why isn't it?
<RAOF> Or, rather, why did it work yesterday but not today?
<duflu> RAOF: Didn't someone say they kicked it off manually yesterday?
<alan_g> tvoss: I did some callgrind a few weeks ago, but none ATM.
<tvoss> alan_g, ack
<RAOF> It kicked off automatically this morning, but only for raring.
<tvoss> mmrazik, ping
<tvoss> mmrazik, can you help us figuring out why the mesa autolanding for saucy has issues?
<mmrazik> tvoss: do we have autolanding for mesa?
<mmrazik> or you mean the job that just polls the git repo and dputs the newest version?
<tvoss> RAOF, ^? I assume the latter?
<mmrazik> RAOF: you say it used to work?
<RAOF> mmrazik: I mean the latter.
<mmrazik> well.. actually you are right
<mmrazik> it worked
<RAOF> For Raring; not for saucy.
<RAOF> Raring pulled -mir3 (which would build if mir wasn't FTBFS on raring), but Saucy hasn't.
<mmrazik> I think the job is broken. There is some conflict in the naming and saucy was rejected from the ppa
<mmrazik> File mesa_9.2~git20130611.761320b1-0ubuntu0+mir3-jenkins76.tar.gz already exists in Mir staging ppa, but uploaded version has different contents. See more information about this error in https://help.launchpad.net/Packaging/UploadErrors.
<RAOF> Oh, right!
<mmrazik> I think I just need to append saucy/raring to the version string
<RAOF> There's no release-specific string in the version.
<RAOF> Yeah.
<mmrazik> uh oh
<mmrazik> thomi was creative (if it was he) in the job :)
<mmrazik> RAOF: the source for raring and mesa is exactly the same, right?
<mmrazik> i.e. the same repo and everything
<tvoss> RAOF, mmrazik why don't we use https://launchpad.net/mesa
<tvoss> ?
<tvoss> it is synced frequently to the mesa git, too
<mmrazik> tvoss: I don't know
<mmrazik> I was told to use the git
<tvoss> mmrazik, okay
<RAOF> mmrazik: Yes, exactly the same for raring and saucy.
<RAOF> tvoss: I don't use lp:mesa because we don't have any tooling to handle git branches in bzr, and it's a huge impedence mismatch if I try.
<tvoss> RAOF, cool, thx for clarifying
<mmrazik> RAOF, tvoss: I believe I fixed the mesa issues and triggered a new dput to both raring and saucy
<tvoss> mmrazik, awesome, thank you
<alf> mmrazik: btw, would it be possible to move our -ci and -autolanding builders to saucy?
<mmrazik> alf: sure. We can just switch or is there anything else I need to do?
<alf> mmrazik: hopefully everything will work, just a moment to confirm with others
<alf> alan_g: duflu: tvoss: ^^ Any concerns/blockers?
<duflu> alf: No I think we are saucy-ready
<duflu> Other than your kernel :(
<alan_g> alf: I've not tested everything on saucy - but don't know of any blockers
<alf> mmrazik: ok, let's do it then
<duflu> alf: Haven't tried building _on_ saucy-android
<duflu> But cross compiling from saucy to saucy is all good
<duflu> And saucy-desktop is very good
<mmrazik> actually good point
<mmrazik> I tend to forget about android
<mmrazik> let me check if it is easy to switch it too
<duflu> Umm, I mean building on saucy-panda ;)
<alf> duflu: mmrazik: is android -ci a native build? I thought it was cross-compiling?
<mmrazik> alf: its crosscompile in pbuilder chroot
<mmrazik> so it should be easy to switch
<duflu> Cool. That's tested and working then
<mmrazik> I'm just not sure the saucy base image is on that host but that should be easy to create
<mmrazik> alf: I don't think we are compiling on panda at all
<duflu> mmrazik, yeah the tests will fail if not built on a saucy host
<mmrazik> duflu ^
<mmrazik> so let me first change the "native" raring builds
<duflu> mmrazik, in summary, everything must be saucy, or nothing
<mmrazik> duflu: even the android part?
<mmrazik> I think it is running on a box with precise installed
<alf> duflu: mmrazik: I just saw that our vm-ci build is still quantal :)
<mmrazik> alf: you sure? It seems its raring
<mmrazik> changing to saucy anyway
<mmrazik> mir-vm-* is saucy now
<duflu> mmrazik, Just that running on saucy-armhf fails tests unless it was built with gcc-4.8 :/
<alf> mmrazik: sorry, could be, I think I may have been misled by a stale link I had
<mmrazik> I vaguely remember you pinged me about it not-so-long ago and I changed to raring
<mmrazik> btw. I'm changing qmir, lightdm-mir, etc to saucy as well
<RAOF> Excellent.
<RAOF> </burns>
<alf> mmrazik: yes, I remembered now
<duflu> RAOF: ?
<RAOF> duflu: Imagine me steepling my long, yellow fingers.
<alf> mmrazik: when all is done, feel free to retrigger e.g. https://code.launchpad.net/~afrantzis/mir/stream-multiple-lock-back-buffer/+merge/169841
<mmrazik> alf: ok. thanks
<mmrazik> only the android is missing now
<duflu> RAOF: Oh, you mean <steeple>Eeeeexcellent</steeple>
<RAOF> duflu: Indeed. But I decided that post-hoc.
<alf> mmrazik: can we also do an autolanding build e.g. for the branch mentioned above, that doesn't actually perform the final landing? Otherwise, no problem waiting for something actually to land to try -autolanding.
<mlankhorst> RAOF: can you accept the libdrm sru in precise/raring/quantal?
<mmrazik> alf: the -ci and -autolanding jobs should be the same
<mmrazik> in could be done without the autolanding part but I would need to clone the job and modify it
<mmrazik> easier to either wait or re-trigger an existing MP
 * duflu searches for an edition of "Increase your wordiness"
<alf> mmrazik: ok, no problem then, I didn't remember if CI builds branches independently or merges trunk first
<mmrazik> alf: they merge trunk to detect conflicts early
<alf> mmrazik: ok
 * alf is about to try out some code in a VT... let's see if this will lead to another reboot...
<mmrazik> https://code.launchpad.net/~hikiko/mir/mir.dest-tmp/+merge/168934 triggered a new build on saucy so we will see :-)
<mmrazik> only the android part will be raring
 * mmrazik is still building the saucy chroots
<mmrazik> too bad. Conflict there.
<hikiko> I didn't switch to saucy yet, do I have to? (My laptop is my main pc as well)
<mmrazik> hikiko: you don't have to to please jenkins or something similar (although it might be easier to debug compile issues on saucy if jenkins finds some)
<alf> RAOF: heads up about mesa build failure https://launchpad.net/~mir-team/+archive/staging/+build/4727075
<mmrazik> btw. everything is on saucy now. I tested the clang job (works) and now I'm trying the android one
<mmrazik> I assume the rest will just work
<hikiko> alf, mentioned in the meeting that he has some issues with mir, gpu and unity freezing on saucy I think that's why I am afraid to dist-upgrade does everything works fine for you?
<alf> hikiko: I will recheck soon and will let you know
<hikiko> thank you alf !
<mmrazik> alf: re the quantal links for mir-vm-ci-builds... the thing is that we re-created mir-ci (started with build #1) while the mir-vm-ci-build job is there for a while without any big change
<mmrazik> not jenkins has some relations between upstream and downstream job
<mmrazik> but the relation only cares about job name and build number
<mmrazik> no unique ID
<alan_g> mmrazik: alf has gone (forced reboot I think)
<mmrazik> and apparently the mir-ci job build #s are now high enough to make jenkins think that some older mir-vm-ci builds were triggered by mir-ci
<mmrazik> alan_g: oh.. .thanks. didn't notice the quite
<mmrazik> s/quite/quit/
<alan_g> alf: welcome back
<alf> hikiko: Despite appearances, it works better for me now :) Note, though, that latest mir trunk needs latest mesa-mir, and there have been some mesa package build failures
<alf> alan_g: glad to be back ;)
<alf> alan_g: It seems that the problem is not the graphics after all. It is lttng that's crashing the system
<alan_g> alf: unfortunate
<alf> alan_g: Yes and no... at least I can do some useful work now :)
<mmrazik> alf: https://code.launchpad.net/~afrantzis/mir/stream-multiple-lock-back-buffer/+merge/169841/comments/379114
<mmrazik> and the mir-vm-ci/quantal build link seems to be gone too
<alf> mmrazik: Great, thanks!
<tvoss> katie, ping
<katie> tvoss, hi
<tvoss> katie, can we postpone our sync-up by 30 minutes?
<katie> tvoss, sure
<tvoss> katie, awesome, thanks
 * RAOF fixes stupid mesa build failure.
<RAOF> Note: you don't (or shouldn't) need that mesa to build Mir.
<alan_g> alf: I was looking at something else, but noticed something that seems wrong and think you probably know the answer. It seems wrong that both the_compositor() and the_compositing_strategy() depend on the_renderables(). Are they actually using disjoint subsets of that interface? (Implying that there's an interface missing.)
<alf> alan_g: yes, the_compositor just needs to know when the renderables change so it can schedule a redraw, the compositing strategy just needs to access to all the renderables
<alan_g> alf: that's what I thought. Thanks.
<alf> alan_g: IIRC, it's something we were aware of this from the beginning, but decided to use the same interface nonetheless
<katie> tvoss, ready? if you need more time, we can postpone and use the time with matthew tomorrow to discuss
<tvoss> katie, that would be great
<katie> tvoss, gives me more time to respond to your comments :)
<katie> tvoss, see you tomorrow
<tvoss> katie, yup :)
<tvoss> katie, ttyt
<RAOF> alan_g: You were looking into why unity-system-compositor wasn't starting up yesterday? Get anywhere?
<alan_g> RAOF: no. (I was mostly answering tvoss asking what could go wrong before"Successfully setup native resources")
<alan_g> RAOF: I'm still trying to stabilize after upgrading to saucy, so I've not tried to reproduce
<RAOF> alan_g: Ah, ok. That's tomorrow morning's work then.
<alan_g> RAOF: sorry to disappoint
 * alan_g needs to reboot
 * alan_g wonders why he gets "libEgl ... unsupported platform" today
<RAOF> Probably because mesa's currently building past the API change.
<alan_g> Ah, so it will probably sort itself out later.
 * alan_g hates the cascade of issues following upgrading stuff
<alan_g> RAOF: is there anything I can look at to help with USC?
<RAOF> Working out why it doesn't start, and gives no output even on stderr.
<RAOF> That, or why, when it succeeds, it goes all âUnable to set active session, unknown client name 0â
<alan_g> will the above mesa problem stop it getting that far?
<RAOF> Probably, yes.
<RAOF> Jenkins should pick up the fixed mesa in the next 15 minutes, or you can build from github locally.
<duflu> alan_g: https://bugs.launchpad.net/mir/+bug/1161206
<ubot5> Launchpad bug 1161206 in Mir "Mir EGL demos output error: libEGL warning: unsupported platform (null)" [Low,Triaged]
<alan_g> I'll leave it to jenkins - it should be done by the time I've finished lunch
<alan_g> duflu: ta
<alf> alan_g: @fix-1188451, is the dead client caught only when we try to communicate with it, or is there some internal keep-alive mechanism in asio?
<alan_g> alf: asio detects that read won't block and tries to read. If it can't read then the reason that read won't block is that the connection died
<alan_g> I'm having trouble testing it properly ATM as I can't run clients without them dying
<alan_g> (I think that relates to mesa incomparability)
<alan_g> alf: we're almost always waiting on a call from the client
<duflu> alan_g: I forgot to ask; aren't there traditional unix ways to detect the other end of a socket is dead?
<duflu> I haven't checked the library...
<alf> alan_g: I am not sure how what you describe would work. Why would a read from a connected (from the server's perspective), but abruptly killed client, not block?
<alf> alan_g: do unix sockets handle this differently from network sockets?
<alan_g> alf: I'm no expert on sockets, but I think it pretty standard to detect "events" (which can be data or closed).
<alan_g> Be back later
<alf> alan_g|lunch: Indeed, I was thinking in terms of the whole system dying, in which case the network stack wouldn't be able to to send the TCP close sequence. We don't have that problem here, though.
<duflu> alf: What would you expect with multiple processes doing drmSetMaster ?
<duflu> Hmm, never mind. The answer probably doesn't change the solution
<alf> duflu: I would expect all but the first (assuming it succeeds) to fail to get drm master
<duflu> alf: I mean would you ever expect EIO particularly?
<duflu> I would have thought EBUSY/EAGAIN/something else
<alf> duflu: right, EIO seems unlikely (I think it actually returns EINVAL)
<duflu> alf: Yeah I hadn't nailed down which function it was
<alan_g> alf: yep. (I did find some system vs TCP sockets differences while investigating.)
<alan_g> \o/ Updated with the new libs etc from ppa and lots of problems went away.
<tvoss> kgunn, would it make sense to move the task to alan's plate with a lower prio?
<tvoss> kgunn, @switchable backends
<alf> alan_g: great!
<kgunn> tvoss: might make sense since we are going to need that much sooner than we previously tht
 * alan_g wonders if he's being stitched up by references to "alan"
<kgunn> alan_g: we just assigned it all to you :)
<alan_g> kgunn: http://www.dilbert.com/fast/2013-06-19/
<kgunn> :)
<duflu> kgunn: plymouth fixed, kind of, https://code.launchpad.net/~vanvugt/lightdm/fix-1192051/+merge/170362
<kgunn> duflu: \0/ THANKS!
<duflu> And now it's late
 * duflu vanishes
<kgunn> GOTO BED
<mlankhorst> undefined label 'bed'
<tvoss> mlankhorst, :)
<kdub_> hello folks. status, noticed that when the android clients have to drop a deleted buffer (as is common in transitioning from triple buffered to double buffered), the android drivers are not happy
<alan_g> status: MPd a fix for bug 1188451 - working to improve reporting and tests around it
<ubot5> bug 1188451 in Mir "Mir server leaks surfaces from dead clients" [High,In progress] https://launchpad.net/bugs/1188451
<alf> status: More work on session snapshots, getting closer
<kgunn> racarr: greyback ....coming ?
<kdub_> saucy's libhybris sure is chatty
<racarr> Morning
<alan_g> afternoon
<ogra_> evening
<alan_g> Bye all!
<racarr> I think we should not build
<racarr> mirclient mesa on ARM
<racarr> becaue we don't use it and now things are broken because if you install it on the phone (i.e. add the ppa)
<racarr> because it expects mir_mesa_egl_display_is_valid in
<racarr> libmiorclient which isnt there on android
<racarr> I am still running in to weird conlicts
<racarr> between my mesa and mirclient  ending with double frees in static initializers and sadness
<racarr> ah perhaps I had a ghost libEGL.so
<kgunn> mterry: would you feel qualified to review https://code.launchpad.net/~vanvugt/lightdm/fix-1192051/+merge/170362
 * mterry looks
<mterry> kgunn, robert_ancell might be better for that one
<mterry> (just in terms of potential fallout from messing with VTs)
<kgunn> mterry: ok....shot in dark....its something i just want to hustle along...but roberts aware also
<racarr> Have we
<racarr> intentionally dropped support for raring?
<racarr> there doesn't seem to be any mesa with the latest API/ABI changes that
<racarr> builds against the drm in raring
<mterry> racarr, pfft, raring is old hat
<racarr> I know, I just can't find a time where I have a few hours to lose to upgrade yet
<racarr> ill upgrade while im at the dentist tomorrow XD
<racarr> and build drm myself right now
<racarr> mterry: Oh. -DCMAKE_BUILD_TYPE=Debug
<racarr> is not on for default by mir
<racarr> even when building yourself
<racarr> err, and now the mir-ppa branch of mesa on github
<racarr> doesn't contain platorm_mir.c
<mterry> racarr, thanks for the tip
<racarr> *crosses fingers for a flawless dist-upgrade*
<racarr> undefined reference to `std::chrono::steady_clock::now()'. I guess I have to wait for
<racarr> the upgrade to finish :(
<mterry> racarr, building mir takes forever
<racarr> its true
<racarr> you can skip the tests and build from src/ and examples/ directly
<racarr> but if anything goes wrong we will want the tests anyway
<racarr> During the proces of upgrading from raring to saucy my battery-not-having desktop went from 1% battery power to 70
<racarr> %
<racarr> XD
<racarr> Hi guys! I Just upgraded to Ubuntu 13.10 Saucy Salamander and it seems like something called 'mir
<racarr> ' has broken my lightdm
<racarr> and X
<racarr> jk :p, except about the broken :(
<bschaefer> racarr, someone mentioned that you have to remove the line type=unity in /etc/lightdm/lightdm.conf to boot from an xsession (which seemed to work for me!)
<racarr> err
<racarr> ok I got X but things were pretty bad
<racarr> and then it crashed
<bschaefer> haha, yeah I had to do startx to get around the lightdm problem...removing that line fixed it for me
<racarr> im stuck in software
<racarr> and software with some weird rendering quirks
<racarr> and second monitor wont go up to full resolution
<racarr> im deleting usr local and purging mir-team ppa XD
<bschaefer> racarr, even with removing that line from the lightdm.conf?
<racarr> mm, beore that it just wouldnt start
<racarr> SAUCY SALAMANDER
<racarr> * hands in air *
<robert_ancell> racarr, like you just don't care?
<racarr> robert_ancell: That it didn't work?
<robert_ancell> racarr, so hands in the air for frustration?
<racarr> no, I am upset that it didn't work, but happy that I have X back
<racarr> because I am in the middle of other things that I can now finish. then try and make the PPA work
<racarr> robert_ancell: I readded the PPA after cleaning out my /usr/local and purging my own PPA
<racarr> s
<racarr> and it's all good
<racarr> though my mouse acceleration did change haha
<robert_ancell> racarr, XMir?
<racarr> robert_ancell: No that fails :( I was guessing it was the seat thing I heard about earlier and I needed another update
<RAOF> robert_ancell: What's with the lightdm tests failing in the PPA?
<robert_ancell> RAOF, I haven't solved it yet, but they work in the CI, but not the PPA for some reason
<robert_ancell> It might be some c library function has a different name on what they're being built on
<RAOF> Woot.
<robert_ancell> (I only just got them to work on the server)
<RAOF> Urgh. Why am I getting 20KB/sec from archive.ubuntu.com?
#ubuntu-mir 2013-06-20
<robert_ancell> RAOF, what is wrong with your connection in general? You G+ calls are barely working!
<RAOF> I don't know.
<RAOF> I *can* get
<RAOF> I *can* get > 1MB/sec down from the internode mirror.
<racarr> RAOF: I had to try really hard to laugh sometime in the meetings, becaue you would have a conversation with omeone and from my perpective it was about
<racarr> 70% machine noise
<racarr> and 30% word
<racarr> that was why "We only need to care about input when we want to"
<racarr> was so hilarious because it came out super clear after about 20 seconds of machine noise
<racarr> haha
<RAOF> Hah
<racarr> I got what you were getting at though
<RAOF> My natural verbosity is leveraged as an error-correcting code. Yay!
<robert_ancell> Does anyone know of a method to give properties to a rendering backend? I need to tell the GBM platform to use a specific VT, but there doesn't seem to be any channel for backend properties
<RAOF> There's currently no channel to do that.
<RAOF> robert_ancell: I think to do that you'd need to (a) extend DefaultConfiguration to handle a new cmdline parameter, then (b) Extend the interface to create_platform() to pass those configuration options in, and then (c) make the GBMPlatform pass those through to GBMDisplay, and then (d) make GBMDisplay actually act on it.
<robert_ancell> RAOF, yeah, I thought that would be likely
<robert_ancell> RAOF, though the options might not come from the command line, so I was thinking just key-value paird
<robert_ancell> pairs
<RAOF> The options parser also handles environment variables, so that's close already.
<robert_ancell> RAOF, the boost one?
<RAOF> Whatever one we actually use. It might be the boost one?
<racarr> Yep
<racarr> each command line option is also
<racarr> an enviroment variable, i.e. --foo-bar is MIR_SERVER_FOO_BAR
<RAOF> Ok. Apparently the reason why unity-system-compositor doesn't give any output for me when it fails on startup is because it never gets to main()â½
<duflu> RAOF: Nice. That would mean either failure to find DSOs, or a DSO is crashing in init (before main)
<RAOF> Silently!
<duflu> RAOF: env LD_DEBUG=all   ?
<RAOF> Wow. That really dumps *all the things*, doesn't it.
<duflu> There are alternatives to "all". Try "help"
 * RAOF reboots to give that a whilrlygig.
<RAOF> Hah. It must be getting SIGKILLed by lightdm for starting slowly :)
<RAOF> That's not very useful.
<robert_ancell> RAOF, It took more than 5 seconds?!
<RAOF> robert_ancell: Oh, yes.
<RAOF> You underestimate the boot time of my goddamned laptop.
<robert_ancell> RAOF, If you have any clever idea of how to avoid that timeout let me know. I guess there has to be some hard coded value
<robert_ancell> RAOF, you can set the timeout on a recent commit in the config file btw
<RAOF> Yeah, I'll just set that and then be about my business.
<RAOF> You could probably just wait for the system compositor to respond on its pipes or die; it's *probably* not going to hang.
<robert_ancell> RAOF, it's the *probably* we need a catch for otherwise you'll hang forever
<robert_ancell> Is there a number low enough for the user not to hard reset but to be pretty much sure the compositor/driver has failed? 30s? 1min?
<RAOF> Dunno.
<RAOF> Not hanging is something that we should be able to make the vast majority of cases, so we might just not catch that.
<robert_ancell> RAOF, well, then setting it to 5 mins should work
<RAOF> And rely on the failed-boot mechanics to get the user somewhere sane *next* boot.
<robert_ancell> ah, true
<robert_ancell> RAOF, it would make the regression tests faster if we drop that feature
<RAOF> At some point we should be able to just drop it. That point might be now
<RAOF> What's the config key for the timeout?
<robert_ancell> unity-compositor-timeout in [SeatDefaults]
<RAOF> Ta.
<RAOF> Well, that's unhelpful.
<RAOF> Ish.
<RAOF> Setting that timeout to an insane value makes u-s-c work for me.
<RAOF> NO BUG REPRODUCTION FOR YOU!
<robert_ancell> RAOF, how long does it take? (from lightdm.log)
<RAOF> HAH!
<RAOF> 5.36s
<RAOF> Sorry, 5.26s, 'cause it takes .10s to get to the point of starting u-s-c.
<robert_ancell> !
<robert_ancell> default -> 10s?
<RAOF> Maybe?
<RAOF> Why not go 60; that's a nice round number, and even the slowest, most degraded btrfs filesystem surely can't take more than 60s to start u-s-c. âº
<robert_ancell> sure
<robert_ancell> RAOF, do you want to do the MP?
<RAOF> Yeah, I can do that.
<RAOF> Hm. I wonder why it's saing âUnable to set active session, unknown client name 0â?
<RAOF> Or, rather, why can't it find that client name.
<robert_ancell> RAOF, full log?
<RAOF> robert_ancell: http://paste.ubuntu.com/5782352/
<RAOF> That's startup, switching to a guest session, and back.
<robert_ancell> Looks like the session hadn't connected in time
<RAOF> Yeah.
<robert_ancell> Though clearly some more logging is needed..
<robert_ancell> I thought I'd linked up logs to when sessions connected, but apparently didn't find the right class for that..
<duflu> robert_ancell: I was thinking there's a distinct lack of demo/manual test programs for the session stuff. It's a bit slow depending on lightdm to test that externally...
<robert_ancell> duflu, not sure what you mean - 1-1 anyway?
<duflu> robert_ancell: Yes am online
<duflu> Allegedly
<robert_ancell> RAOF, I think you merged into the wrong thing - https://code.launchpad.net/~raof/mir/lightdm-longer-u-s-c-timeout/+merge/170478
<robert_ancell> lp:mir instead of lp:unity-system-compositor
<duflu> https://code.launchpad.net/~vanvugt/lightdm/fix-1192051/+merge/170362
<robert_ancell> RAOF, lp:~mir-team/lightdm/unity rather
<RAOF> robert_ancell: Yeah, just retargetting.
<robert_ancell> RAOF, can you do the 1-1 earlier, say nowish?
<RAOF> Sure.
<robert_ancell> RAOF, https://code.launchpad.net/~robert-ancell/lightdm/unity-disable-tests/+merge/170485
<RAOF> robert_ancell: https://code.launchpad.net/~raof/lightdm/lightdm-longer-u-s-c-timeout/+merge/170486
<tvoss> duflu, ping
<duflu> tvoss: Pong. Seems I tend to get back from lunch when you log on in the mornings
<tvoss> duflu, perfect timing then :)
<tvoss> duflu, we both are sleepy, that is, and long for coffee
<duflu> I got a real coffee on the way back from lunch \o/
<tvoss> duflu, \o/
<duflu> RAOF: What was your system-compositor exiting problem?
<RAOF> duflu: It was taking 5.2 seconds to start, and lightdm was sending SIGKILL after 5 seconds.
<duflu> RAOF: Oh. Why so slow?
<RAOF> Because btrfs
<duflu> Wow
<RAOF> It's *significantly* better now than it has been. It takes less than a minute to get to the unity-greeter.
<RAOF> It used to take more than five.
<tvoss> RAOF, wow, that's long turnaround time
<RAOF> btrfs *really* doesn't like snapshots on rotating rust.
<RAOF> Over time its performance degrades to basically nothing.
<RAOF> I think my worst-case boot time was 20 minutes to the greeter.
<RAOF> Which is a pity, because btrfs has a bunch of awesome features.
<RAOF> robert_ancell: Hey, is there currently any way for XMir to tell when it gains or loses focus?
<robert_ancell> RAOF, I don't think so
<RAOF> I think I could bodge something together by listening for motion events, but it's probably better to actually fix the protocol so that clients can tell when they're focussed.
<RAOF> racarr? :)
<robert_ancell> RAOF, did you confirm the X acceleration is fixed from boot?
<RAOF> Yup.
<robert_ancell> RAOF, i.e. bug 1191937
<ubot5> bug 1191937 in Light Display Manager "loss of x acceleration when xmir is loaded" [Undecided,Fix committed] https://launchpad.net/bugs/1191937
<robert_ancell> Nice
<RAOF> Works For Meâ¢
<RAOF> Breaks once you try and do user-switching, of course, but until then, it works fine :)
<robert_ancell> I was just thinking that the VT number might be wrong based on the duflu review of my VT branch for mir - I set XDG_VNTR to the number in /dev/ttyN - but VT numbers are off by one
<robert_ancell> i.e. tty1 = VT0
<robert_ancell> or duflu has just confused me
<RAOF> I think duflu might have confused you.
<duflu> Well it doesn't look like a Mir bug. We're asking for VT n and it appears on tty n+1 (Alt+(Fn+1))
<duflu> Looks designed that way
<duflu> I mean tty n+1 appears on VT n :)
<duflu> Which is confusion, even if by design, that we should hide from the user
<robert_ancell> duflu, are you sure the mouse pointer has anything to do with that change? I can't see the connection
<duflu> robert_ancell: I can't see the connection either but it doesn't happen to trunk
<duflu> I think you triggered a side-effect
<tvoss> RAOF, for focus events: stay tuned, working with ricmm and racarr on that bit
<RAOF> tvoss: Cool. Presumably they'll come through the event fd, like everything else?
<tvoss> RAOF, presumably
<robert_ancell> RAOF, thanks for the corrections btw :)
<duflu> RAOF: Only input comes through the fd. All other events come over the protobuf
<RAOF> duflu: The things in common/event.h don't all come over the fd?
<tvoss> RAOF, yup, the input stream is separate right now
<duflu> RAOF: Oh, yes. Input events (most of event.h) are on the fd. But MirSurfaceEvent (of which there are multiple sub-types) are on protobuf
<RAOF> Ah, of course!
<RAOF> One more thing to send through my thread-to-eventloop mechanism, I guess.
<tvoss> RAOF, not sure duflu did some experiments with unifying the streams, I did some preliminary investigations and having the event stream separate turned out to be a good idea
<duflu> I've been meaning to write a "ping" type benchmark to establish a baseline and we can work from there
<tvoss> duflu, will dig out my experiemtn I did on the phone
<RAOF> Eh. I guess XMir will just get a callback on a random thread, I'll send it through the pipe, and pick it up in X's event loop.
<duflu> tvoss: Though you can't "ping" with input. Only surface events have simple request/response sequences via the client API... (?)
<tvoss> RAOF, fair
<duflu> RAOF: Most exciting is that *all* event types come to clients in the same callback, regardless of the transport :)
<RAOF> Yay!
<duflu> It gets combined in the client library
<tvoss> duflu, iirc I tagged the input events with a timestamp
<tvoss> duflu, but let me find the code :)
<duflu> Sure
<tvoss> mmrazik, ping
<mmrazik> tvoss: pong
<robert_ancell> didrocks, o/
<seb128> robert_ancell, hey, how are you?
<robert_ancell> seb128, hey, good
<robert_ancell> yourself?
<seb128> I'm good thanks
<seb128> better today that this heat wave is over, I didn't like the 36Â°C from the past days much :p
<seb128> now that*
<robert_ancell> seb128, ow, that's hot for you guys!
<seb128> indeed
<ogra_> seb128, lucky you ... we still have it
<robert_ancell> RAOF, hey, not sure if you noticed but I added conf.d support to lightdm - so you should be able to make /etc/lightdm/lightdm.conf.d/99-unity-system-compositor.conf and set the seat type in there
<robert_ancell> It should work better than lightdm-set-defaults?
<robert_ancell> didrocks, ^ actually, do you know if there's anything using lightdm-set-defaults that wouldn't work switched to using the conf.d dir?
<robert_ancell> tvoss, good to see I'm not the only one worried about feature freeze :)
<tvoss> robert_ancell, yup
<duflu> RAOF, anyone, can you please kick off a Mesa build for raring? We don't have one since libmirclient0 became libmirclient1 ... https://launchpad.net/~mir-team/+archive/staging/+packages
<duflu> Hence the build failures and crashes I mentioned on mir-devel
<robert_ancell> duflu, I'm having a look inside Jenkins. I know it can be done, but Jenkins is a little scary
<duflu> robert_ancell, no problem. I have a workaround
<duflu> But it's ugly
<robert_ancell> duflu, for you or for everyone?
<duflu> robert_ancell, on mir-devel
<tvoss> mmrazik, can you help here?^
 * robert_ancell wonders how close we are to dropping raring in the PPA
<mmrazik> looking
<mmrazik> duflu: what needs to be done? Just dput the mesa into ppa again?
<duflu> mmrazik, Maybe. Haven't checked the cause of failure
<didrocks> hey robert_ancell!
<mmrazik> duflu, robert_ancell: FYI -- the following job takes whatever is in the git repo and dputs into the ppa
<robert_ancell> didrocks, hello
<mmrazik> :
<mmrazik> http://10.97.2.10:8080/job/mesa-egl-platform-mir-dput/
<mmrazik> just triggered it
<didrocks> robert_ancell: I think they should be fine with using conf.d (it's mostly metapackages generated from the seeds)
<robert_ancell> mmrazik, ta
<mmrazik> usually its triggered by git change but if you trigger manually it will do the same
<duflu> mmrazik, thanks. Fingers crossed
<duflu> robert_ancell, should I spend the time trying to fix plymouth properly or move on to transitions?
<robert_ancell> duflu, transitions
<robert_ancell> duflu, because we need that to work for the phone
<duflu> True
<duflu> I might make some dinner instead. 6pm is a bad time to start something new
<robert_ancell> :)
<duflu> Not to mention 10pm
<RAOF> duflu: Mesa won't build against libmirclient1 on raring until *Mir* 0.0.4 builds on raring.
 * duflu looks
<duflu> RAOF: As it happens, Mir 0.0.4 _can't_ build on raring due to the bug I'm trying to solve... https://launchpadlibrarian.net/142922154/buildlog_ubuntu-raring-amd64.mir_0.0.4bzr760raring0_FAILEDTOBUILD.txt.gz
<duflu> And the build won't succeed until it's done against a Mesa that links libmirclient1 :/
<duflu> Chicken or egg?
<tvoss> duflu, RAOF, robert_ancell do we _need_ raring?
 * duflu does for efficient development
<robert_ancell> tvoss, no, just waiting for everything to finish using it
<duflu> It's only a PPA problem. We can support raring if only we rebuild Mesa, somehow
<RAOF> duflu: Why won't the build succeed until it's done against a Mesa that links libmirclient1?
<duflu> RAOF: see my emails on mir-devel. Because we link to Mesa libs that use libmirclient0 (PPA) and also link to libmirclient1 locally
<duflu> How did we fix it for saucy?
<duflu> Should be the same solution
<duflu> /usr/bin/ld: warning: libmirclient.so.0, needed by /usr/lib/gcc/x86_64-linux-gnu/4.7/../../../x86_64-linux-gnu/libEGL.so, may conflict with libmirclient.so.1
 * tvoss wonders if it would be a lot of effort to split out the mesa egl into libEGL.so, which is a chim loading libEGL_${PLATFORM}.so
<tvoss> duflu, RAOF ^?
<duflu> tvoss: Not sure. I'm looking at the dependency graph...
<tvoss> duflu, that would unbreak our build and ease multi-egl-platform support
<duflu> Ah it's the client+server being built together that's the problem
<RAOF> Yes.
<RAOF> If we split libmirclient out, it would be much easier.
<duflu> EGL depends on mirclient. And mirclient depends on nothing important but gets built *with* mirserver which depends on EGL. So we have a dependency cycle we don't really need
<duflu> I think hikiko mentioned this before
<tvoss> duflu, unfuck that please :)
<tvoss> duflu, oh well, you are eod already :)
 * duflu will try to /action/ that another day
<tvoss> yup :)
<tvoss> duflu, sorry :)
<duflu> Sounds messy
<duflu> tvoss: Looks like separation of source packages :P
<tvoss> duflu, ack, noted it down to nag you tomorrow my morning :) or is it already friday for you? not sure ... damn tz
<duflu> Do we *need* MirMesa on the build system? Could it just build with standard Mesa?
<duflu> Have we added any symbols to libEGL for Mir?
<alan_g> duflu: your sleep is more important
<RAOF> duflu: We do not need MirMesa on the build system.
<RAOF> duflu: We can happily build against stock mesa.
<duflu> That's a solution then
<duflu> if it works
<duflu> Well, it's not a long term solution
<duflu> We don't want to reach universe with this cycle problem
<robert_ancell> bye all
<tvoss> robert_ancell, bye )
<tvoss> :)
<tvoss> ffs, https://launchpad.net/~mir-team/+archive/system-compositor-testing/+build/4730486 is so slow I want to help the builder with compiling myself
 * tvoss takes out pen and paper ... 
<tvoss> RAOF, if still around: failed to install usc from system-compositor testing unity-system-compositor : Depends: libmirserver0 (= 0.0.4bzr759saucy0) but 0.0.4bzr760saucy0 is to be installed
<kgunn> tvoss: no!!!!
<tvoss> alf, mmrazik I think we just need to copy over usc again from staging to system-compositor-testing
<mmrazik> usc?
<tvoss> mmrazik, unity-system-compositor
<tvoss> mmrazik, but you might want to wait until mir for i386 completes, although I think we are hitting a hanging builder :/
<mmrazik> ok
<RAOF> tvoss: Urgh, right. I shouldn't have copied the binaries for usc from staging.
<RAOF> tvoss: Yeah, a new copy *without* binaries would work.
<tvoss> RAOF, just forcing a rebuild against the current mir version, right?
<RAOF> tvoss: Exactly. Except that it's built successfully before, so you need to bump the version to get launchpad to rebuild it :)
<tvoss> RAOF, you mind doing that real quick?
<RAOF> tvoss: Done like a dinner.
<RAOF> I'll prepare for bed, then check that it's accepted into the PPA, then sleep :)
<tvoss> RAOF, yup :) \o/
<kgunn> RAOF: thnka you
<kgunn> ....oh and thank you as well
<arsson> So is there any ppa for mir that might actually work?
<RAOF> Good, that's accepted. amd64 will be installable when https://launchpad.net/~mir-team/+archive/system-compositor-testing/+build/4730713 finishes.
<RAOF> tvoss: Could I get you to babysit https://launchpad.net/~mir-team/+archive/system-compositor-testing/+build/4730715 ? You just need to hit the retry-build button once i386 mir has built.
<RAOF> â¦which it looks like it's not going to, because the build has hung again. What is going on with the buildds?
<RAOF> Anyway, I'm not going to get anything more done tonight.
<tvoss> RAOF, sure, will look at it
<tvoss> RAOF, will kill the mir i386 build and retry, too
<tvoss> retriggered
<tvoss> ffs
<alan_g> tvoss: ?! No need for that
<tvoss> alan_g, the buildd for the testing ppa hangs again
<alan_g> tvoss: patience is considered a virtue
<tvoss> alan_g, violence is not a solution but an option?
<alan_g> tvoss: I usually find a polite request to mmrazik results in a solution
<mmrazik> alan_g: when it comes to ppa/buildd I can't do much :-/
<mmrazik> I can only help with jenkins
<tvoss> mmrazik, yup :9
 * tvoss muses that the buildds are hidden away in a 1.5 dimensional manifold somewhere/sometime
 * alan_g wonders who can be made responsible for that bit of infrastructure
 * kgunn wonders why tvoss keeps mentioning "flash file system" ;)
 * kgunn unfortunately...actually knows why
 * alan_g wonders why someone called a static library "mirsharedandroid"
<tvoss> alan_g, would you mind checking if a clean mir checkout builds fine with dpkg-buildpackage for you?
<alan_g> tvoss: I don't mind - but what's the incantation for it?
<tvoss> alan_g, to rule out that we have something non-buildable in the repo
<alan_g> tvoss: I mean I don't want to look up how to use it
<tvoss> in mir's root: dpkg-buildpackage
<alan_g> running...
<tvoss> alan_g, thx
<alan_g> np - but a single process takes a while
<alan_g> (Tried -j8  but that borked)
<tvoss> alan_g, how long can /build/buildd/mir-0.0.4bzr760saucy0/obj-i686-linux-gnu/bin/acceptance-tests --gtest_list_tests
<tvoss> take?
<alan_g> ...run. Finished OK
<alan_g> tvoss: that depends
<alan_g> But if it takes more than a few milliseconds you've a very slow box
<alan_g> real	0m0.012s FWIW
<kdub_> hello all
<alf> kdub_: Hi!
<alan_g> hello one
<alf> alan_g: kdub_: Have a moment to take a look at https://code.launchpad.net/~afrantzis/mir/base-stubs-on-null-platform/+merge/170550 ? I have code that depends on this, waiting to be MPed :)
<kdub_> sure
 * alan_g thinks "this implies a way to avoid seeing those waiting MPs"
<alf> alan_g: yes, so you, as the reviewer, get a double benefit from me doing it like this (and not using dependent branches) 1. you get simpler/cleaner MPs 2. you can control (to a degree) the incoming review queue :)
<alf> alan_g: kdub_: thanks for the quick action
 * tvoss goes to setup an i386 chroot
<alf> Saviq: tvoss: What format do you expect the snapshot pixels to be in?
<kdub_> tiled 3 planar yuv!
<alf> kdub_: \o/ :)
<kgunn> greyback: ^
<greyback> alf: rgba probably, but I'm checking
<alf> greyback: ok, r,g,b,a in memory or 0xRRGGBBAA as an int?
<greyback> alf: ok, at the moment we read ARGB32 premultiplied, each pixel an unsigned char.
<alf> greyback: can you point me to where you got this information?
<greyback> alf: qtubuntu, src/modules/application/application_image.cc, line 63/64
<alf> greyback: thanks
<greyback> alf: that's where the platform api passes us the pixels for the image
<mterry> racarr, poke when you've got a moment to talk libhybris crashes
<racarr> mterry: I can try and parse :D feeling kind of out of it this morning
<mterry> racarr, :-/ suck
<mterry> racarr, so remember yesterday, I was seeing a crash in mir_demo_server on the nexus7
<mterry> racarr, I finally got debug versions of libhybris and mir built
<racarr> mm
<mterry> racarr, this is the full bt: http://pastebin.ubuntu.com/5784142/
<mterry> racarr, seems to actually be in thread 17 when it dies
<mterry> racarr, which is in hooks.c in libhybris
<mterry> I'm looking at that code now, but it seems hooks.c has an early opt-out for nvidia...
<alan_g> Goodbye all!
<kdub_> bye alan
 * kdub_ thinks we might need a 'quirk' system for these closed drivers
<kdub_> maybe.. :) we should probably try to avoid it
<racarr> mterry: I can't really determine anything besides hybris is fucked
<mterry> racarr, ah...  If I run mir_demo_server under GRAPHICS=NVIDIA, it doesn't segfault
<mterry> racarr, so it was just the nvidia_hack not being used
<mterry> I'll try to actually run the demo code
<mterry> racarr, "Assertion `mir_connection_is_valid(connection)' failed." -- does that mean the server isn't running right
<racarr> mterry: Yeah
<racarr> mterry: Or say one is running as root and the other is user
<racarr> or it crashed on connect
<mterry> racarr, still seems to be running as root (same user)
<racarr> does the server crash when you try and connect?
<mterry> seemingly not, it's still runnig
<arsson> I guess i'm running unity-system-compositor. still two cursors but unity de is working.
<arsson> I have nouveau installed, should i install nvidia proprietary drivers?
<arsson> tearing
<kgunn> arsson: per the mir instructions....
<kgunn> mir only works on open drivers atm
<kgunn> unity-sys-comp will fallback to standard x (non-xmir)
<kgunn> if you install proprietary drivers back in
<mterry> racarr, how does a client connect to a server?  DBus or a socket or something?
<racarr> mterry: Socket.
<racarr> mterry: /tmp/mir_socket
<mterry> racarr|dentist, hmm, it exists.  I want a super-verbose mode in Mir
<kgunn> mterry: weird huh....mir working right....makes you wonder if its working :)
<mterry> kgunn, I see your thing above about only working on open drivers.  What is our plan for nexus7?
 * mterry has to run out
<kgunn> mterry: ah...that statement is only a desktop thing
<kgunn> libhybris allows for bins on mobile platforms
<tvoss> RAOF, ping
<arsson> cannot change icons.
<robert_ancell> RAOF, assuming you're not online yet...
<kdub> now if i can just get the driver to stop leaking buffers, i'm in the clear! :)
<kgunn> robert_ancell: previously, i had been toggling successfully between xmir attempts (& back) simply #commenting out the type=unity
<kgunn> in theory should that be all that's needed ?
<robert_ancell> kgunn, yes
<kgunn> robert_ancell: ok....so i'm on lightdm for this w/ type=unity commented _out_.....and i hang
<robert_ancell> kgunn, check there's not a second entry for type - I have seen that
<robert_ancell> kdub, do you need root for mir on android?
<ricmm> hey guys
<ricmm> is it possible to run mir/shell as user?
<kdub> robert_ancell last i checked, yes
<ricmm> oh, he already asked
<ricmm> kdub: do you know the reason?
<robert_ancell> ricmm, I know on desktop you need root for the VT stuff
<kdub> ricmm, let me try to run as user, i'll see what happens...
<kdub> oh, actually...
<ricmm> getting a segfault in pthreads
<kdub> seems ok on the nexus 4 for me
<kgunn> robert_ancell: just in case https://pastebin.canonical.com/93186/
<kgunn> this is my lightdm.conf
<ricmm> kdub: do you have a maguro at hand?
<robert_ancell> kgunn, yeah, you have type=unity on the last line
<kdub> ricmm, yeah, i'll fire it up and see
<ricmm> kdub: thanks!
<kgunn> robert_ancell: so are the instructions wrong? http://unity.ubuntu.com/mir/using_mir_on_pc.html
<robert_ancell> kgunn, sorry, you are trying to enable or disable xmir?
<kgunn> robert_ancell: nvmd....sorry....i am officially an idiot
<kgunn> actually....did you do something to auto-magically add that ?
<kgunn> i dont remember that being there
<robert_ancell> kgunn, RAOF made a change so u-s-c adds it on install
<kgunn> cool
<kgunn> now i know....sorry for not looking closer
<kdub> ricmm, yeah... as far as I can tell, on maguro, you can't drive the display without root
<robert_ancell> but it doesn't recognise a quoted out entry, so it adds a new one if you've got a previously disabled one
<robert_ancell> kgunn, it caught me out the other day too :)
<ricmm> kdub: are you seeing the same segfault tho?
<kdub> yep
<ricmm> or is it something else
<ricmm> right
<kdub> well, probably the same one :)
<ricmm> ;)
<ricmm> does it happen in pthread_mutex_destroy?
<kdub> ricmm, yes
<ricmm> ok
<ricmm> I'll look into it, sucks tho, I only have maguro :(
<ricmm> segfaults in pthread over hybris is rsalveti's land
<ricmm> ill go cook while he returns
<ricmm> racarr: welcome back
<racarr> Danke.
<racarr> now 50% done with teeth repair
<racarr> not counting the root canal next week
<robert_ancell> Can I get someone to do a quick review of https://code.launchpad.net/~robert-ancell/unity-system-compositor/command-line-options/+merge/170562 and https://code.launchpad.net/~robert-ancell/lightdm/unity-usc-command-line/+merge/170561
<robert_ancell> Fairly small changes, but required to set the VT for XMir
<robert_ancell> brb
<robert_ancell> kgunn, ok, so I can get into my session from the u-s-c PPA
<kgunn> robert_ancell: i'm sure its me....somewhere along the line
<robert_ancell> kgunn, yeah, it looks like it
<robert_ancell> kgunn, uninstall mir and u-s-c and then try reinstalling
<kgunn> robert_ancell: ack...i'll leave you alone for real work....
<robert_ancell> kgunn, finally! ;)
<kgunn> robert_ancell: hah!
<jono> robert_ancell, legend!
<jono> thanks for doing the interview :-)
<robert_ancell> jono, :)
<jono> also, just sent https://lists.ubuntu.com/archives/mir-devel/2013-June/000183.html
<jono> maybe this is something you chime in with
<RAOF> robert_ancell: Correct! I'm not online at 7:15 :)
<robert_ancell> RAOF, if looks like you doubly approved https://code.launchpad.net/~robert-ancell/lightdm/unity-usc-command-line/+merge/170561 and not the other one..
<RAOF> Urgh, really?
<RAOF> Welcome to the morning, I guess :/
<robert_ancell> :)
<robert_ancell> RAOF, I'm trying to find confirmation, but do VT numbers start at 1?
<RAOF> I believe so.
<RAOF> robert_ancell: vt_ioctl.c says âif you pass 0 in as the VT to VT_ACTIVATE you get a shiny new ENXIO error for your troublesâ
<robert_ancell> heh
<mlankhorst> :>
<ricmm> kdub: Dynamic exception type: boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::system::system_error> >
<ricmm> std::exception::what: bind: Address already in use
<ricmm> getting that, after a while of debugging my pthreads
<ricmm> I was getting the shell to start but no graphics, probably due to permissions on the fb devices
<ricmm> but once clearing perms I'm getting that
<kdub> so are you still getting that error?
<ricmm> no longer the segfault
<kdub> so, is that a fatal error then?
<ricmm> this one? yes
<kdub> ah, ok. hmm
<ricmm> bind: Address already in use
<ricmm> stale socket?
<kdub> sounds like an ipc sort of error
<kdub> thats what i was thinking
<kdub> stale root-owned socket maybe?
<kdub>  /tmp/mir_socket
<ricmm> yup, that was it
<ricmm> so im running eglplasma and I get nothing on screen
<ricmm> however I get the FPS ticker
<kdub> hmm, getting closer
<ricmm> yup, sounds like the screen isnt being turned on or something
<ricmm> is this something that Mir does? maybe permissions on some node that controls it
<ricmm> works fine as root
<kdub> any errors or anything? (logcat, dmesg)
<ricmm> E/IMGSRV  (  929): :0: PVRSRVCreateDCSwapChain: Error - 10 returned
<ricmm> E/IMGSRV  (  929): :0: framebuffer_device_open: Failed to create flip chain; retrying
<ricmm> I remember those, seen them before
<ricmm> uhh
<kdub> yeah, they just happen when it can't set up the display
<ricmm> crap I remember doing something the last time I got that, but I forgot what it was
#ubuntu-mir 2013-06-21
<racarr> ricmm: Last time that was
<racarr> surface flinger running
<racarr> I think?
<ricmm> yup, this was ssomething similar, wsomeone else was starting a qt process with qtubuntumir
<ricmm> not the main issue anyways
<robert_ancell> duflu, can you recheck https://code.launchpad.net/~robert-ancell/mir/vt-option/+merge/170476?
<duflu> robert_ancell: Yeah no problem. It will be done today
<duflu> And hopefully "done"
<RAOF> And then I get to use the same infrastructure to make input not go to the VTs! Yay!
<duflu> robert_ancell: Approved but you typically need a second review
<robert_ancell> duflu, ta
<RAOF> I'll do that one.
<robert_ancell> I do believe I just did a cold boot, past plymouth, into a XMir greeter and into a session with acceleration
<robert_ancell> RAOF, what was the command to check the /dev/drm permissions?
<RAOF> getfacl /dev/dri/*
<RAOF> Also, I'm not surprised. That's been working for me since your XDG_SEAT fix yesterday :)
<robert_ancell> RAOF, the VT fix seemed to fix the last problem for me
<robert_ancell> RAOF, did you see https://code.launchpad.net/~robert-ancell/unity-system-compositor/lightdm-conf.d/+merge/170730 btw?
<RAOF> I did not.
<RAOF> That's not _quite_ the same thing as debconf, though?
<RAOF> Although people can always delete the conf.d snippet, I guess.
<robert_ancell> RAOF, yeah, I think that's the idea
<robert_ancell> And it handles multiple packages fighting over the same setting
<RAOF> That's fine by me. Going to update the testing instructions?
<robert_ancell> Not today, but can do when it's merged
<robert_ancell> RAOF, duflu, are you subscribed to u-s-c merges btw? It would be handy to have a pool of us who can review them
<RAOF> I think I am, but I think they get filed into a folder I don't regularly look at.
<robert_ancell> ok, coo
<robert_ancell> l
<duflu> robert_ancell: Not subscribed but I can remember to look at the launchpad page
<RAOF> We're in the same timezone, so I think pinging will scale reasonably well.
<robert_ancell> there's some other low priority merges, just wanted to check someone will see them at some point
<RAOF> Ish.
<duflu> I tend to ignore the mail noise and go straight to the summary pages
<robert_ancell> and some for lightdm
<robert_ancell> RAOF, oh, you merged it - do you know where the instructions are to modify off hand?
<RAOF> https://docs.google.com/a/canonical.com/document/d/1M7aH9QF1Q1EXd0UOYz4CWa3HGmBAHewFdQ3kmQO25_o/edit#heading=h.b75suqfnic7w
<robert_ancell> RAOF, do we consider system-compositor-testing PPA still broken?
<RAOF> It's broken for i386 because of hateful buildds, but I don't think it's broken outside that.
<RAOF> It should probably have a big âdon't VT switch or try user switchingâ disclaimer, though.
<robert_ancell> That second cursor is super annoying...
<robert_ancell> bye all - last chance for anything that needs resolving before next week..
<robert_ancell> RAOF, duflu?
<duflu> robert_ancell, annoying but there was a request for a temporary watermark feature ;_
<duflu> ;)
<robert_ancell> duflu, not likely
<duflu> robert_ancell: No in that document it was requested
<RAOF> I think I'm most of the way through fixing that cursor, but other things have bumped it off the priority.
<duflu> RAOF, robert_ancell: https://bugs.launchpad.net/mir/+bug/1192916
<ubot5> Launchpad bug 1192916 in Unity System Compositor "Mir's hardware cursor (arrow) is drawn on top, even though we're not using it." [Undecided,New]
<robert_ancell> duflu, yep
<robert_ancell> it's only cosmetic
<duflu> RAOF: If you're working on it, please claim the bug
<RAOF> Have done so, thanks.
<tvoss_> RAOF, ping
<RAOF> tvoss_: Pong.
<tvoss_> RAOF, good morning :) any good news from the buildd or do I need to setup a vm with an ancient kernel and try to reproduce?
<RAOF> No good news from the buildd, sorry.
<tvoss_> RAOF, I don't understand why it is failing only on i386 when it used to work before
<RAOF> Possibly the buildds having their kernels upgraded? But that wouldn't be the case, because they've out of support.
<tvoss_> RAOF, here is what webops were able to extract: https://pastebin.canonical.com/93178/
<RAOF> That's... annoying?
<tvoss_> RAOF, attached to the hanging process via gdb and interrupted
<RAOF> Something in the free path has deadlocked?
<tvoss_> RAOF, not deadlocked, the process is spinning even
<RAOF> So livelocked then.
<tvoss_> yup, okay, ancient kernel debugging then *fun*
<RAOF> Can there be any more desirable use of a Friday?
<tvoss_> totally not
<tvoss_> olli, ping
<olli> tvoss_, wazzup
<tvoss_> olli, good morning/good night :)
<olli> just read some backlog
<olli> yay for working infrastructure
<olli> tvoss_, I am about to log off, was there anything you wanted to ping me about?
<tvoss_> olli, nope, sent you a pm, though
<tvoss_> olli, wanted to check if you were able to install the ppa
<olli> didn't get to it
<olli> updated to saucy though ;)
<olli> baby steps
<tvoss_> olli, \o/ later then :)
<olli> cya in a few hours
<jono> olli, working late?
<olli> just wrapping up
<olli> u?
<jono> ditto
<jono> night all
<olli> cya all
<duflu> RAOF: Can you give my the idiot's guide to what kind of Mir surface XMir is?
<duflu> -my +me
<RAOF> Whatever is set by default.
<RAOF> duflu: I don't currently explicitly set it to anything.
<duflu> RAOF: I mean hardware or software?
<duflu> EGL?
<duflu> Blitted by memcpy?
<RAOF> Oh, hardware.
<RAOF> Direct access to the contents of the mir_buffer_package.
<RAOF> Blitted by hardware.
<duflu> RAOF: Hmm so XMir is technically GBM-native?
<RAOF> XMir is very much GBM-native at this point.
<duflu> RAOF: I was thinking it would be beneficial to configure Compiz to use its old buffer aging logic (circa 2012 and prior) because that's faster and all we need when another compositor is on top. But was also wondering if XMir itself is optimal
<duflu> -on top +underneath
<RAOF> XMir is not itself optimal.
<duflu> I'm glad you say that
<duflu> It means it could get even faster
<RAOF> Indeed.
<RAOF> First optimisation is to use the buffer_age field to do partial updates.
<RAOF> Second optimisation is to do GLX passthrough for fullscreen surfaces.
<duflu> RAOF: Yeah Compiz can do that without the buffer_age extension, I mean
<RAOF> But it does it by not SwapBuffering, right? XMir can't do that.
<duflu> Hmm
<duflu> RAOF: Yes I think XMir would have to translate that into buffer_age logic
<duflu> Just trying to get Compiz closer to the hardware, even when Mir is in the middle...
<RAOF> Compiz always outputs to a fullscreen GLX window, right?
<RAOF> Composite-bypass for XMir gets you as close to the hardware as you can be.
 * RAOF heads out to get stuff for dinner before it gets dark and even colder.
<duflu> RAOF: Yes Compiz _only_ supports fullscreen GLX composting
<duflu> Hah
<duflu> -composting  +compositing
<duflu> :)
<RAOF> duflu: Then we should be able to hand the buffer from Mir all the way through to Compiz. Once Mir also does composite bypass, that'll have Compiz drawing on the framebuffer.
<duflu> RAOF: Sounds quite awesome
<tvoss> didrocks, ping
<didrocks> tvoss: pong
<RAOF> duflu: If you've got a moment would you kindly check that lp:~raof/mir/prober-drm-device-probe works for you?
<duflu> RAOF: What's it do?
<duflu> Meant to..
<RAOF> It's meant to actually probe the drm devices, rather than hope that one of {i915, radeon, nouveau} will bind to the right thing.
<RAOF> As a secondary benefit, it should also throw sensible errors if it *can't* find a drm device, unlike the current state of things which always returns EPERM on error.
<RAOF> Heh. Misspelt branch name - that's meant to be *proper*-drm-device-probe :)
<duflu> RAOF: Oh I was going to do something similar. Should then include vmware support?
<RAOF> Assuming vmware does sensible EGL, this *is* vmware support.
<RAOF> Or maybe I've misinterpreted what you've said.
<duflu> No, that's cool
<RAOF> Yes, this should include vmware support, assuming vmware can do EGL on their raw kms device.
<RAOF> I'm not sure if that assumption holds, but it seems reasonable.
<duflu> RAOF: You mean Mesa fully implements vmware support in its EGL... ?
<RAOF> Mesa certainly has support for vmware, and I don't _think_ it does anything fancy like needing help from it's X driver.
<RAOF> Prf_Jakob will know!
<duflu> RAOF: Well I hoped not
<duflu> RAOF: Just tinkering with linker madness then I'll test it
<RAOF> :)
<RAOF> duflu: Oh, sorry. I should have fixed the testing PPA, shouldn't I?
<duflu> RAOF: I was working on fixing the code so it builds. What would you "fix"?
<RAOF> The easy way to do that will be to create a new PPA, build Mir in it against the archive mesa, then copy that including the binaries into the testing PPA.
<RAOF> But if you're actually splitting out the libmirclient build then that's much more useful.
<RAOF> Please don't let me interrupt you from doing that!
<duflu> RAOF: That's a workaround that's kind of specific to here and now. I'm trying to find a more permanent solution
<dholbach> hey hey
<dholbach> so regarding the documentation improvements Jono mentioned on the mailing list - would it make sense to file bugs on mir about this? AFAIK http://unity.ubuntu.com/mir/ is generated from the docs in lp:mir? I could tag them with 'docs' or something
<RAOF> dholbach: Yeah, that'd be reasonable.
<dholbach> great - I'll do that and follow up on the mailing list
<alan_g> duflu: about the "ProtobufSocketCommunicator::start()" - I'm not sure how to make it clearer. Any suggestions?
<duflu> alan_g: Not sure. I didn't spend enough time looking at it
<alan_g> np
<RAOF> tvoss_: I'm not sure if we want further sabdfl testing right at the moment, but if we do, https://code.launchpad.net/~raof/mir/prober-drm-device-probe/+merge/170765 should at least generate a more useful error.
<tvoss_> katie, ping
<katie> tvoss_, pong
<duflu> Got to run. Sorry in advance for my merge proposal.
<tvoss_> RAOF, for the build issue in the ppa?
<tvoss_> RAOF, do you think it makes sense to disable i386 to make propagation working fine again?
<sil2100> Hi guys! hm,
<sil2100> Can I get some status update on mir related work? Since currently we're not doing any daily-releases of mir and its components - do you think mir is ready for daily-releasing right now?
<sil2100> What is the overall status?
<tvoss_> sil2100, we are busy preparing a ppa right now
<tvoss_> sil2100, I think once that is done, we can start working towards a daily release
<tvoss_> say: sometime next week
<tvoss_> makes sense?
<sil2100> Excellent, thanks for the update
<sil2100> Then I'll re-poke you guys in a week
<tvoss_> sil2100, cool and thanks for asking
<sil2100> Ah, guys/girls ;)
 * sil2100 has a habbit of using 'guys' to address everyone in the room
<olli> gm
<greyback> hi guys, small question. I'm playing with mir_demo_server and clients. In VT1 I run the server. But then switching to another VT, I see just a blank screen. Ideas?
<greyback> note I'm on saucy
<tvoss_> greyback, ?
<tvoss_> greyback, what do you expect to see on another vt?
<greyback> tvoss_: another login screen
<tvoss_> greyback, hmm, that shouldn't be gone, I'm happily using it like that right now
<tvoss_> greyback, if you don't start mirserver as root, you cannot switch vt's
<greyback> tvoss_: aha
<tvoss_> tvoss_, so you might think you have switched :)
<greyback> tvoss_: talking to yourself again :)
<tvoss_> tvoss_, sure, as always :)
<tvoss_> tvoss_, it's great to always win all arguments, I'm a huge fan of myself ;)
<greyback> tvoss_: which means all clients must run as root too
<greyback> which is fine, just while I'm testing my work
<tvoss_> greyback, not entirely sure, I would need to check with duflu
<tvoss_> greyback, but yeah, all root right now will work
<greyback> tvoss_: it segv on me, server as root, client as me.
<greyback> but not big deal right now. I've enough to work with
<greyback> thanks
<tvoss_> greyback, ack
<alan_g> alf: could I get you to review this? https://code.launchpad.net/~alan-griffiths/mir/dlopen-graphicsplatform/+merge/170797
<alf> alan_g: sure
<alf> alan_g: all good :)
<alf> alan_g: but jenkins doesn't agree :/
<alan_g> alf: thanks.
 * alan_g see it is that packaging stuff he's never understood properly.
<olli> tvoss_: kgunn ping
<olli> are we all good? Kgunn is presenting?
<kgunn> olli: sure
<tvoss_> olli, dialing
<kdub> morning, status, trying to get the n4 driver to release deleted buffers (eg, triple buffered to double buffered transition)
<alf_> status: wrapping up the mir part of session snapshots...
<kdub> alf_, so the basic idea for xmir multimonitor support is to negotiate the display information on behalf of xmir?
<kdub> eg, xmir will ask to change the resolution, and we'll service that. or a hotplug will come in and we'll notify xmir
<alf_> kdub: right, that's the grand plan (C), as a first step we will let xmir handle event but we will implement the decision. So xmir will catch hotplug, read configuration, and send us the configuration to apply.
<kdub> ah, so the hotplug goes to xmir
<kdub> seems some resizing work is needed too
<alf_> kdub: I guess, to begin with, we can destroy/recreate surfaces?
<kdub> i mean, should be easy enough to pop a new swapper with new buffers in there
<kdub> just don't see the scenario we'd need for doing that atm :)
<alan_g> alf_: kdub: I'm off on vacation next week (back following Tuesday). Anything you from me need before then?
<alf_> alan_g: no, enjoy your vacation!
<kdub> yep, have a good time
<mterry> racarr, heyo.  So do you have any pointers except for gdb tracing for trying to figure out my mir connection issue?  (client can't see demo server)
<mterry> racarr, or is it expected that running with the nvidia hack would screw things up?
<alan_g> If anyone has time to double check the install/package changes in dlopen-graphicsplatform  before I go it would give me peace of mind. (As I'm not 100% sure what correct looks like.)
<racarr> mterry: Not really, we hve some logging options, etc but if connecting isn't working
<racarr> they seemingly aren't
<racarr> it seems like it must be the nvidia hack
<racarr> butttttttt
<racarr> Not sure how
<mterry> racarr, I had hoped that our reference device would work better.  :-/
<mterry> stupid nvidia
 * mterry kicks a pebble
 * kdub thought using the 'nvidia hack' was a thing of the past
<kdub> mterry, iirc, the nvidia hack just skips over shared process mutexes, so the nvidia driver would explode if both server/client are hybrisized
<racarr> That could be it!
<racarr> XD, I didn't know what the nvidia hack was ;)
<racarr> mterry: You may be able to run the inprocess shell
<racarr> oh right but you cant :(
<mterry> kdub, mir_demo_server crashes without the hack
<kdub> mterry, are you still moving that hwcomposer.so file so mir can't find it?
<mterry> kdub, um...  Shoot maybe I didn't this time
<kdub> yeah, at the moment, i'd recommend no nvidia hack, and move the hwcomposer.*.so to force mir to use the fb device instead of hwc
<kdub> apparently the n7 hwc doesn't hybrisize well
<racarr> XD. I'm worried this will one day devolve in to
<racarr> NVIDIA_HACK_0=0 NVIDIA_HACK_1=1 NVIDIA_HACK_2=0...
<racarr> lol
<kdub> its probably okay to remove the "nvidia_hack" from hybris
<alf_> all: Have a great weekend
<racarr> See ya! you too
<kgunn> ok...going to tread back onto trying xmir & figuring out why in the heck it wants old boost libs
#ubuntu-mir 2013-06-22
<mterry> So Mir is going to manage screen blanking on idle?  Or is that going to be in some upower/systemd daemon?
#ubuntu-mir 2013-06-23
<robert_ancell> RAOF, ping
<RAOF> robert_ancell: Pong.
<robert_ancell> RAOF, can I get you to review https://code.launchpad.net/~robert-ancell/lightdm/unity-assign-usc-vt/+merge/170729, https://code.launchpad.net/~robert-ancell/lightdm/unity-drop-mir-dep/+merge/170731, https://code.launchpad.net/~robert-ancell/lightdm/unity-compositor-command/+merge/170734 and update the system-compositor PPA once at least the first MP lands?
<robert_ancell> RAOF, also, is there anything in particular about updating the system-compositor PPA - do I just copy packages over if they need updating? Do you rebuild when copying? Or do you prefer to be the gatekeeper for it?
<RAOF> robert_ancell: Certainly.
<robert_ancell> RAOF, also, anything I can do to help solve the mesa i386 issue?
<RAOF> robert_ancell: Is there a mesa i386 issue? The only one I was aware of was âMir doesn't build on i386 in the PPAâ, which tvoss has some MPs for.
<robert_ancell> RAOF, oh, odd. The PPA is just showing mesa not build for i386, but when you expand the mir entry it also hasn't built
<robert_ancell> It's a hidden build failure :)
<RAOF> It's because the i386 builds have all been cancelled, because they hang in the testsuite.
<robert_ancell> ah
<robert_ancell> RAOF, I'm not seeing any branches or bugs from tvoss for that
<RAOF> Let me check that mail again...
<RAOF> Ah. I guess the âpreparingâ in his mail is present continuous.
<robert_ancell> Can you forward it to me?
<RAOF> robert_ancell: Enjoy!
<robert_ancell> hmm, not sure exactly what the issue is there. Guess will have to wait for the branches
<robert_ancell> thomi, are you back?
<thomi> robert_ancell: yup
<robert_ancell> \o/ welcome back
<thomi> robert_ancell: thanks, it was an interesting return trip
<robert_ancell> ?
<thomi> I was evacuated from my house by the fire dept at 5AM the morning after I got back. Then had to spend the entire weekend moving house
<thomi> so... kinda stressfull
<robert_ancell> yeah!
<thomi> but I have Internet, power, and food - what more could you need?
<thomi> I noticed that the mir docs weren't being uploaded, and fixed that thir morning.
<thomi> are there any other developments I should know about?
<robert_ancell> ah, nice
<RAOF> thomi: Did you at least get an amusing anecdote out of the 5am evacuation?
<robert_ancell> thomi, I got the lightdm tests building on the CI, but they seem to fail in the PPA builders - any easy way of debugging stuff like that? Or is that outside what you manage?
<thomi> RAOF: not really :-(
<thomi> robert_ancell: let me guess: failing for ARM only?
<robert_ancell> thomi, no, It was either amd64 or i386 or both (can't remember off hand)
<robert_ancell> Something must be different in their environment
<thomi> oh
<robert_ancell> I was planning on just bashing a PPA with debugging to find out, but that has awful turnaround. I did that to Jenkins and at least I could turn around builds every 15 mins or so
<thomi> which PPA is it? I can take a look, although I can't promise to be able to fix whatever is wrong - the launchpad builders are outside our control.
<thomi> otherwise, maybe ask on #launchpad-ops
<thomi> the build environment should be pretty standard I would have thought
<thomi> certainly on jenkins it builds inside a standard chroot
<RAOF> Yeah, that's what tvoss did to debug the i386 hangs - if you ask very nicely you can apparently get them to attach gdb to things for you.
<robert_ancell> thomi, It was the staging PPA, but I just disabled the tests for now (and then a bug got past because of it!). Haven't got the time at the moment to work it out
<robert_ancell> RAOF, yeah, I saw that
<robert_ancell> I wish there was an easy way to just ssh into a "standard build server" to manually test things
<thomi> robert_ancell: me too
<thomi> the PPA build infrastructure is rather awkward, IMO
<thomi> hmm, I note the last saucy armhf build failed
<robert_ancell> RAOF, still looking at those other two MPs?
<RAOF> Yes. The second is approved.
<RAOF> robert_ancell: Do you deliberately ignore the vt option in the tests?
<robert_ancell> RAOF, LP says no...
<RAOF> +            //vt_number = atoi (argv[i+1]);
<robert_ancell> RAOF, I did since it doesn't enact anything on it
<RAOF> Ah, ok.
<robert_ancell> It just stops the mock from exiting
<RAOF> Should both be approved now.
<robert_ancell> RAOF, https://code.launchpad.net/~robert-ancell/lightdm/unity-drop-mir-dep/+merge/170731 still showing no change
<robert_ancell> RAOF, do you use the web interface or something else to approve them?
<RAOF> Web interface.
<RAOF> Aha.
<robert_ancell> timeout?
<RAOF> There were *3* MPs.
<RAOF> The middle one was hiding in between the outer two :)
<robert_ancell> sneaky :)
<RAOF> *Now* they are all done.
<robert_ancell> RAOF, ta :)
<robert_ancell> RAOF, so the next step - do I push them into the s-c-testing PPA once they're built? Just the copy with build?
<robert_ancell> with rebuild
<RAOF> I just copy with rebuild.
<RAOF> You can push them directly if you like.
<RAOF> Actually, you can just copy *without* rebuild for lightdm.
<RAOF> Because it doesn't have any mir deps.
<RAOF> Or, more specifically, it doesn't have any libmirserver deps.
<robert_ancell> yep
#ubuntu-mir 2014-06-16
<RAOF> Sweet! Implicit serialisation FTW!
<dandrader> anpok_, hi
<dandrader> anpok_, any ETA on the input_sender branch?
<anpok_> hm
<anpok_> I am on holiday this week
<anpok_> I am looking for shepard ..
<anpok_> thought I had everythin cleaned up this morning, but there are still concerns regarding nameing
<dandrader> anpok_, we *really* need this in.
<dandrader> anpok_, so I was thinking about landing it now and fix any badly named bits later
<dandrader> mir interfaces are constantly changing here and there anyway (which is natural). so that should not be a big deal
<racarr_> Morning
<kgunn> greyback: alf_ has been working on the "visibility" i/f for the client in order to help friendly-stop rendering (vs depedning on life cycle events)
<kgunn> question is
<kgunn> is that as important? or less so than the orientation i/f we just discussed
<kgunn> (which is new to mir guys)
<greyback> kgunn: sorry, was in other meeting. visibility is a nice to have, orientation is more useful however
<kgunn> greyback: does this need to be a built in mir i/f ?...or use opaque shell-app channel ?
<kgunn> just needs to be spec'd
<greyback> kgunn: opaque shell-app channel only 1 way sadly - client can give shell information, or ask shell for information. But shell can't send client info with it
<greyback> kgunn: so there are 2 parts. 1) shell tells a client - the current orientation has changed to <something>. 2) client tells shell, this is the list of orientations I support
<greyback> 2) could use the side-channel, but 1) cannot
<kgunn> camako: alf_ ^
<tvoss> greyback, why does the shell need to know the supported orientations?
<greyback> tvoss: if foreground app does not support portrait, shell should not try to change it to landscape
<tvoss> greyback, now I'm confused :)
<greyback> tvoss: quick hangout?
<tvoss> greyback, you are number 4 in a list of 5 right now
<tvoss> greyback, let me get back to you
<greyback> tvoss: :)
<greyback> please hold, your input is important to us
<racarr_> we do have surface_attrib_focus
<racarr_> set by the shell
<racarr_> which wouldnt be so different than orientation
<racarr_> kdub_: alan_g: P.s. iterated onc ursor spike phase 4
<alan_g> racarr_: I agree that a surface attribute is a natural implementation approach. (But let's check the use cases.)
<racarr_> alan_g: Mm.
<racarr_> I think today is finally going to be the day that construction drives me insane
<alan_g> racarr_: coffee shop?
<racarr_> the people who have been working close by are now literally working on my street and they seem to have chosen right outside my window
<racarr_> as the nexus of
<racarr_> ....trucks
<racarr_> yeah I think that might be what I do in 30 min or so...
<alan_g> noise cancelling headset?
<racarr_> Haha. Only works for low frequency noise
<racarr_> which I dont think is the annoying part of jackhammering
<alan_g> Mm. Mine copes with the whine of aircraft engines
<alan_g> Not tried jackhammers
<racarr_> ill just become a master of meditation and cast it from my mind...seems easiest.
<racarr_> alan_g: re: enable-usb-touchscreens
<racarr_> I put the display_bounds in stub server configuration because stubdisplay isnt
<racarr_> a public class
<racarr_> and it inherits from NullDisplay
<racarr_> which shouldn't have a size.
<racarr_> hmm I broke clientsurfaces::are_created_with_correct size when  I changed the default testing disp lay bounds
<racarr_> but its not clear to me why this would have ever passed
<racarr_> as the default server configuration has mostly ignored clients size requests in favor of fullscreening them
<racarr_> for over a year
<racarr_> no thats not true
<racarr_> nvm it all
<racarr_> I just made the screen smaller
<racarr_> than this surface lol
<racarr_> and I forgot we do listen to requests...just most apps dont make them
<racarr_> lala
 * alan_g goes to review "ursor spike phase 4" again
<racarr_> :) Thanks
<alan_g> kdub_: before I EOD - don't forget https://code.launchpad.net/~mir-team/mir/trusted_sessions/+merge/221191
<kdub_> alan_g, i switched to abstain, my internet is having problems
<kdub_> (hopefully that msg went through)
<alan_g> kdub_: Still looks like "Needs Info to me". But I can top approve if you're not going to object.
<alan_g> *"Needs Info" to me
<kdub_> alan_g, sounds good
<alan_g> kdub_: you still have many hours before it lands to find a reason to stop it. ;)
<racarr_> Wow I just got some of those shoe gel pad things...
<racarr_> game changers.
<racarr_> even for sitting down.
<racarr_> *back to things*
<josharenson> do we use the exact same libegl as android?
<racarr_> everything on ubuntu side links against libhybris-egl which "links" against an actual android libegl from cyanogen
<josharenson> ack
<racarr_> libhybris-common/core/something
<racarr_> it has a name and its probably not libhybris-egl lol
<racarr_> but
<racarr_> thats basically the deal
<josharenson> ok, thanks
<racarr_> Lunch :)
<racarr_> made good progress ona cceptance tests for cursor is a renderable
<racarr_> not really clear
<racarr_> they are acceptance tests
<racarr_> but they are something
<racarr_> its acceptance criteria I guess (i.e. there is something that shows up in the renderable list that acts like the cursor)
<racarr_> but for driver writers and compositor authors and such
<racarr_> not
<racarr_> acceptance criteria for clients clearly
<racarr_> so it doesnt really excercise the system from the outside totally in the way our acceptance tests would
<racarr_> notably there is no client. just a thread that makes expectations and then moves the cursor around
<racarr_> *shrug*
<racarr_> Lunch
#ubuntu-mir 2014-06-17
<Laney> hey mir-ers
<Laney> I just quickly want to check if Mir is known to work/not work on desktops with nvidia graphics
<Laney> I'm trying the desktop-next (Unity 8) ISO that we've been building and it looks like it's hung on my machine with nvidia
<Laney> but I can't do anything with it to find out. :)
<alf_> Laney: it doesn't work with the proprietary nvidia drivers yet
<Laney> alf_: I didn't install any drivers yet
<Laney> this is a live session from the iso
<alan_g> alf_: feel like contributing to a discussion? https://code.launchpad.net/~kdub/mir/share-occlusion-with-examples/+merge/222577
<alf_> alan_g: sure
<alan_g> thanks. Otherwise it will keep going in circles
<alan_g> alf_: sorry for slow feedback - I had a very different algorithm in mind: http://paste.ubuntu.com/7657755/ still trying to think yours through
<alf_> alan_g: no worries
<alan_g> alf_: your options "A" and "C" are rather procedural - they are "ask" interfaces not "tell" ones. I'd go with "B"
<alf_> alan_g: I haven't thought through how to pass up-to-date information about available compositors in this case, but it should be workable.
<alf_> alan_g: s/workable/doable/
<alan_g> doesn't the buffer queue already track compositors?
<alan_g> alf_: I've been thinking and we really only need to know that compositors have been removed
<alan_g> http://paste.ubuntu.com/7657933/
<Laney> I heard that mir works under vmware
<Laney> is that true?
<alf_> Laney: Yes. On a Linux host most free drivers are blacklisted, so you need to unblacklist them to get accelaration and get Mir to run.
<Laney> alf_: Interesting, how can I do this? Will they work or are they blacklisted for a good reason? :)
<Laney> Point me to documentation if it exists
<alf_> Laney: There are some glitches, but they work more or less. http://askubuntu.com/questions/181829/how-to-fix-3d-acceleration-for-vmware-workstation-9
<alf_> Laney: (the fixe is applicable for vmware player too)
<alf_> Laney: note that you need a relative recent version of Mir that works with vmware, not sure what version the iso you have has
<Laney> alf_: It's built from utopic
<Laney> hrm, my host session hung
<alf_> Laney: as long as mir >= 0.2.0 you should be ok
<Laney> alf_: can't stop it from crashing my session every time
<Laney> oh well
<alan_g> alf_: @share-occlusion-with-examples: http://programmer.97things.oreilly.com/wiki/index.php/Beware_the_Share
<kgunn> mterry: hey, trying to land 0.3.0 mir, packages built, but i'm not booting....is this a normal u-s-c log
<kgunn> https://pastebin.canonical.com/111823/
<mterry> kgunn, sort of...  except that the "Closing session session-0" line means the user session died for some reason
<mterry> kgunn, look at the ~/.cache/upstart/unity8.log file
<kgunn> ack
<kgunn> mterry: eeewww....doesn't look good https://pastebin.canonical.com/111824/
<mterry> kgunn, well that explains that anyway  :)
<kgunn> hmmm, wonder if this has to do with the platform-api v2 transition....
<kgunn> or the gcc4.9 stuff i wrestled with...
<mterry> kgunn, well we worked with v2 before, eh?  I assume you've rebuild platform-api against the new Mir?
<kgunn> mterry: yes...i'm starting to think this might be gcc4.9 hoo-ha working its  way through...(stuff being stuck in proposed etc)
<mterry> ah
<kgunn> silo got built against proposed archive last night at slangasek's request...so it built...but
<kgunn> i don't think i'm trusting this
<mterry> kgunn, https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1328485/comments/12
<ubot5> Ubuntu bug 1328485 in unity8 (Ubuntu) "unity8 crashed with SIGABRT on Qt 5.3" [High,In progress]
<mterry> seems relevant
 * kgunn looks
<alf_> alan_g: yeap
<alf_> alan_g: (@beware-the-share)
<alan_g> fginther: can you see what's different about our mako tests today? Mir is having a hard time that doesn't appear to relate to the MPs being built: https://jenkins.qa.ubuntu.com/job/mir-mediumtests-runner-mako/
<fginther> alan_g, I can't take a look right away, you should try the cihelp vanguard. I'll guess that the change is due to a new image, but I'll have to look closer to know for sure.
<alan_g> fginther: OK thanks
<dandrader> anpok on holidays?
<kgunn> dandrader: he is, but he doesn't know how...he's been showing up alot
<kgunn> what do you need?
<dandrader> kgunn, wondering who took over https://code.launchpad.net/~andreas-pokorny/mir/input-sender/+merge/220984
<kgunn> dandrader: even i don't know, he acted like he was going to prep someone on the team before dropping completely....he might have plans to come back on just for this...
<kgunn> alf_:  alan_g|tea ^ you guys know ?
<alf_> kgunn: I just know that anpok asked us to revisit and review the input-sender related branches
<alan_g> kgunn: I know the same as you - he's on vacation but not gone
<racarr_> Morning
<anpok> kgunn: yeah my vacation needs fixing
<anpok> it does fail all basic acceptance tests
<anpok> but I make a lot of progress
<kgunn> :)
<kgunn> racarr_: hey, i was just trying to scrub some blueprints...
<kgunn> am i right to include cursor renderable as part of "making cursor settable by client" ? (as one big task...i mean that's the point right?)
<racarr_> kgunn: *incoherent stream of 8 am mumbling*
<kgunn> lol
<racarr_> kgunn: no the cursor settable by client stuff is the rest of the cursor spike
<kgunn> only if i get an racarr "wheeee"
<racarr_> making hte cursor a renderable
<racarr_> is software cursor and
<kgunn> ok...so its really 2 things
<racarr_> visualization spots
<racarr_> and android cursor support I guess
<racarr_> whatever we want that for lol
<kgunn> right...3...but i already broke out the viz spot
<racarr_> :)
<anpok> alan_g: alf_, kdub_, racarr_, AlbertA: If there are further discusions, i.e. on naming moving things around I wont be able to apply them this week. In that case someone needs to take over or it will rest for another week
<alan_g> kgunn: ^
<alf_> anpok: enjoy your time off :)
<anpok> thx... i will go back to my wall
<alan_g> greyback: are you the one to talk to about the "add client & server API's to communicate orientations" requirements?
<greyback> alan_g: I am, but I'm trying to clarify requirements from the SDK team right now
<alan_g> greyback: OK. I'll be doing the implementation - so grab me when you're ready.
<greyback> alan_g: will do, thanks
<alan_g> kdub_: is your question answered? https://code.launchpad.net/~alan-griffiths/mir/rework-integration_tests-test_surfaceloop.cpp/+merge/222946
<kdub_> checking...
<kdub_> approved
<alan_g> ta
<racarr_> the cursor renderable observable problem is annoying...
<racarr_> the thing with just making a "renderable" observer, is what seperates a renderable from a surface? Well its things like
<racarr_> MirSurfaceAttrib...
<racarr_> which a surface observer needs
<racarr_> but a renderable doesnt have
<racarr_> so then do you really need
<racarr_> a renderable observer/render state observer and a surface state observer
<racarr_> and then. there is the awkward position of input which happens to basically want
<racarr_> a renderable
<kdub_> something doesn't mesh with the questions with me
<racarr_> except it doesnt care about the buffers
<kdub_> a renderable is what the compositor sees
<racarr_> kdub_: So I am trying this...build the cursor renderable in to the stack approach
<kdub_> sure
<racarr_> and the problem is how does the compositor get change
<racarr_> notifications for it
<racarr_> because its not a surface, so it cant install a surface observer on it
<racarr_> and just promoting "add/remove_observer" to renderable, and scene::observer::surface_added to renderable_added
<racarr_> isnt enough, because it doesnt make sense to install
<racarr_> a surface observer on a renderable
<racarr_> because it has things like attrib_changed(MirSurfaceAttrib...
<racarr_> which a renderable certainly doesnt have
<kdub_> well, it doesn't make sense to have the add/remove observer on mg::Renderable
<racarr_> mm
<kdub_> but why not have a CursorRenderable: public Renderable, public <update notification thing>
<racarr_> Where UpdateNotificationThing is an interface like add/remove_observer ?
<kdub_> right
 * kdub_ is obviously a step removed from the problem, so it could also be reasonable to have that be a constructor dependency
<racarr_> What is the type of the observer though? It shouldn't contain things like
<racarr_> attrib_changed
<racarr_> because the cursor renderable doesnt have surface attributes
<kdub_> let me poke through the code for a min
<racarr_> :) thanks. I am feeling kind of stuck on it.
<kdub_> oh, i kinda see the problem digging through... the msc::Observer interface is pretty surface-based at the moment
<racarr_> yeah
<racarr_> and unity-mir wants that interface I think...I mean it makes sense that you should be able to observe all surface state somehow
<kdub_> and msc::Surface inherits from classes that don't make sense for a cursor
<racarr_> mm
<kdub_> like, msc::Surface : public input::Surface
<racarr_> well
<racarr_> input::Surface wouldn't be SO bad
<racarr_> because essentially you can be a null input::Surface and everything could skip you
<racarr_> and really all it needs at the core is a rectangle
<racarr_> well, its still ugly
<racarr_> but then also there are all these
<racarr_> extra methods, i.e.
<racarr_> allow_framedropping, type, state
<racarr_> force_requests_to_complete
<racarr_> aha
<kdub_> it kinda feels like msc::Surface is too specific
<kdub_> and the msc::Observer should be based around an interface that's generic enough for the cursor too
<kdub_> and the surface and the cursor can both use that
<kdub_> and both poke the scene via the msc::Observer interface
<racarr_> mm, but I think the shell
<racarr_> really wants i.e. notify_attrib_changed
<racarr_> etc
<kdub_> right, but cursor just never calls that
<racarr_> yeah...it's possible that way.... it just feels a little like interface abuse I guess
<kdub_> eh, observer is a semi-coherent interface of all the levers that can be pushed to trigger a scene change
<kdub_> mostly-semi-coherent even :)
<racarr_> lol yes semi coherent
<racarr_> part of the thing too is
<racarr_> strictly like
<racarr_> I dont think MirSurfaceAttrib changing by itself
<racarr_> is enough to trigger recomposition right
<racarr_> or like input changes
<racarr_> etc
<racarr_> the shell has to
<racarr_> action it
<racarr_> well maybe input
<racarr_> but not recomposition
<kdub_> well, it shouldn't be, i'm not sure of the current state
<racarr_> right shouldn't be
<kdub_> the logic there can be improved for sure
<kdub_> like, MultiThreadedCompositor actually got a bit of smarts to it after some of the recomposition changes
<racarr_> mm
#ubuntu-mir 2014-06-18
<robert_ancell> what's a good command to use the output of mirscreencast and produce a video file with reasonable compression?
<RAOF> robert_ancell: Let me hunt down the email...
<robert_ancell> RAOF, I figured this must have been recorded somewhere but my google-fu is not finding it
<RAOF> mencoder -demuxer rawvideo -rawvideo fps=60:w=1920:h=1200:format=bgra /tmp/foo -ovc lavc -lavcopts vcodec=ffv1 -o all.avi
<RAOF> Is one option.
<RAOF> I don't think we have documented this anywhere, though.
<RAOF> MPs welcome :)
<RAOF> It'd be reasonably easy to translate that into a gstreamer pipeline that'd do the right thing, too.
<robert_ancell> I should be able to convert that to a pipe right? In particular I'm running out of disk space too fast
<RAOF> I *think* so?
<RAOF> You certainly would be able to with gstreamer and fdsrc
<RAOF> Urgh. How can our unittests fail in trunk?
<robert_ancell>  mirscreencast -m /run/lightdm-mir-0 --stdout | mencoder -demuxer rawvideo -rawvideo fps=60:w=1920:h=1200:format=bgra - -ovc lavc -lavcopts vcodec=ffv1 -o $1
<robert_ancell> I think that should do it
<RAOF> Yeah, seems reasonable.
<robert_ancell> except I need to adjust the size I guess..
<RAOF> And probably select a different vcodec; that'll give you lossless compression, which will be pretty good for a screencast but you may want more.
<robert_ancell> It's probably better to encode fast and then re-encode when I'm done
<RAOF> Yeah, not a bad plan.
<RAOF> Intriguing. Tests fail when built with clang, pass with gcc. I guess I'll chalk this up to a compiler bug unless it persists.
<robert_ancell> [ffv1 @ 0x7f8e54797b00]Error getting output packet.
<robert_ancell> Muxer frame buffer cannot allocate memory!
<robert_ancell> hmm
<RAOF> Heh. g++'s error handling for âyou missed a > on a template argument, doofusâ remains gloriously opaque.
<RAOF> Ok. Sped up our tests by a factor of 10, and they almost all still pass.
<robert_ancell> Anyone know why Mir says it's outputting 60fps by screencast but it only appears to be 15fps?
<RAOF> Possibly too slow to write?
<robert_ancell> RAOF, I don't think so - it seems to generate an mp4 at 4x speed. If I set it to 15 it works fine
 * RAOF makes the magic incantations which enable non-glacial speed on battery.
<alan_g> alf_: do you know why a Mir CI build tries to install libunity-mir1 etc.? https://jenkins.qa.ubuntu.com/job/mir-mediumtests-runner-mako/1795/console
<alf_> alan_g: looking
<alf_> alan_g: from what I understand, libunity-mir1 is already installed as part of the flashed image
<alan_g> Oops!
<alan_g> I'll pop over to ci-eng...
<alan_g> CI he say: "/usr/include/android/system/graphics.h:269:5: error: 'size_t' does not name a type" ... I wonder if the android headers have been changed?
<dandrader> dednick, I guess your platform-api branches fixes those issues? http://paste.ubuntu.com/7663936/
<dednick> dandrader: yup
<alan_g> greyback: does this test capture our current orientation requirements? http://paste.ubuntu.com/7664275/
<dandrader> alan_g, btw, gotta define mir_orienation_* values
<dandrader> alan_g, is it an angle in degrees, counter-clockwise?
<dandrader> alan_g, and will the app be able to query the value and not just receive events about it?
<alan_g> dandrader: mir_toolkit/common.h line 120
<alan_g> dandrader: what I took from the discussion was the ability to send the events
<alan_g> but I can add requirements...
<dandrader> alan_g, yes. gotta have a line there explaining what those enum values mean
<dandrader> documentation
<greyback> alan_g: looks good yes
<alan_g> dandrader: I only know what I see there. ;)
<alan_g> greyback: do we need dandrader's suggestion of the client querying the orientation of a surface too?
<greyback> alan_g: hmm, ideally yes a surface should be created with an orientation, or have a getter to read the orientation when it wants to.
 * alan_g wonders if orientation should be a surface creation parameter?
<racarr_> kgunn: dandrader: So I guess if by monday we havent come to an agreement re: input sender (gives tomorrow morning and friday)
<racarr_> we can do inputdispatcher
<racarr_> ugh 5 minutes until the pizza place opens but I cant wait ANY LONGER
<racarr_> ...
<racarr_> lol
<kgunn> yeah...i think if you threaten alan with that, he'll suddenly love input sender :)
<racarr_> haha
<racarr_> using InputDispatcher isnt that bad
<dandrader> racarr_, by inputdispatcher you mean exposing the whole android-input and letting us replace android::InputDispatcher
<racarr_> Yes.
<dandrader> ok. I will have to dust off the patch I had for it :)
<racarr_> :) well maybe input sender will magically land in the morning lol, we will see
<racarr_> I'm sure InputDispatcher hasnt changed though
<racarr_> or android-input much at all
<racarr_> which is one of the reasons I think publishing android-input in a "privatized" library isn't that bad
<dandrader> on the other hand. it will quite a bit of work to go back to that previous approach in qtmir....
<racarr_> its additional ABI, but practically we dont change it rapidly at all.
<racarr_> Oh really ? :(
<racarr_> I imagined it would be almost plug/play InputSender->InputDispatcher-to-channel
<AlbertA> racarr_: ummm, do we really want to do that?
<AlbertA> racarr_: don't we want to have the option to drop the android stuff completely at some point
<racarr_> AlbertA: it would be a privatized interface to unity-mir
<racarr_> if we arent able to land input-sender quick enough
<AlbertA> racarr_: ummm didn't we just basically said no to privatized stuff even for our own examples?
<racarr_> Sure but 3 options
<racarr_> 1. Land input sender or something comparable
<racarr_> 2. Expose android-input for unity-mir
<racarr_> 3. Don't ship qt compositor
<racarr_> ;)
<AlbertA> is there something really wrong with input sender? I haven't reviewed it yet
<racarr_> lol im not sure yet. my first review it just seemed kind of messy, but mostly as a consequence of the android bits....going to look more tomorrow
<racarr_> but there is some discussion between alf/alan_g about it too and
<racarr_> alan_g seems pessimistic about it.
<racarr_> s/tomorrow/this afternoon/
<AlbertA> racarr_: oh I see there's a dependency chain there
<AlbertA> racarr_: it depends on another 2 mps
<racarr_> that too yes
<AlbertA> I think I see the problem now
<AlbertA> It's a massive diff overall
<AlbertA> :)
<racarr_> aha yes that is a concern point
<racarr_> i feel like im so close
<racarr_> to never again having to remember that the cursor
<racarr_> exists
<racarr_> soon we will do everything that xcursor does and the cursor will just be another renderable and it can fade in to memory lol
<racarr_> hmm. if the XCursorLoader fails to load any cursors do you think we should fall back to the builtin cursor
<racarr_> kind of weird to put logic in the server configuration
<racarr_> like that
<racarr_> I mean...there could be a...composite object that does that too...
<racarr_> or the XCursorLoader could have a builtin cursor (that seems the weirdest...)
<racarr_> seems like its still possible to hose the system if you crash the server at the right place in startup
<racarr_> cant even recover from ssh...
<kdub_> robert_ancell, cool, gtk!
<racarr_> Yeah!
<racarr_> ok coming back in a bit to finish off last bit of cursor loader and propose that to get one more thing off my mind lol and then work on groking input sender
<racarr_> but for now away for a while
#ubuntu-mir 2014-06-19
<racarr_> Hmm
<racarr_> it kind of seems like drmModeSetCursor2 plain doesnt work re:hotspot
<racarr_> is that possible? I wonder if im actually using a hardware cursor in X
<racarr_> that doesnt seem possible
<RAOF> racarr_: I'm not sure, but that's going to be changing reasonably soon with the Grand Plane Unification.
<alan_g> alf__: do you have any insight on this one? https://bugs.launchpad.net/bugs/1331980
<ubot5> Ubuntu bug 1331980 in mir (Ubuntu) "mir_demo_server_basic Error opening DRM device VirtualBox" [Undecided,New]
<alf__> alan_g: yes, commenting
<alf__> alan_g: hmm, actually not what I thought, I haven't tried the specific (experimental) video driver for virtualbox
<alan_g> Oh! The joy of many moving parts... ;)
<alan_g> alf__: is there an "official" interpretation of what e.g. "left" means here? http://bazaar.launchpad.net/~mir-team/mir/development-branch/view/head:/include/shared/mir_toolkit/common.h#L120
<alf__> alan_g: I am not aware of one (but haven't been following the relevant design documents). I assume it's 90 degree anti-clockwise rotation relative to normal (but what is normal? :))
<alan_g> alf__: thanks (that's what I thought.)
<alan_g> greyback: do these work for you? https://code.launchpad.net/~alan-griffiths/mir/orientation/+merge/223759 and https://code.launchpad.net/~alan-griffiths/mir/orientation-2nd-use-case/+merge/223788
<greyback> alan_g: looks good to me, thanks!
<alan_g> kgunn: ^
<kgunn> alan_g: you are kickety killin' it! thank you
<alan_g> kgunn: it is easy when we only do the bit we understand. ;)
<mterry> alf__, heyo!  Got a few minutes to talk about visibility hooks or some such?
<kdub_> mterry, alf__ mentioned a wip branch
<kdub_> i think this one? https://code.launchpad.net/~afrantzis/mir/visibility-events-wip
<mterry> kdub_, I'm thinking I'll just shut down spinner when not in use -- this will fix that bug we were going to delay on regarding the memory use anyway
<mterry> kdub_, oh sorry
<mterry> kdub_, confused you with kgunn  :)
<mterry> kdub_, OK, thanks for link
<kdub_> lol, thats okay. i approve the plan, for what that's worth :D
<racarr_> have another cursor spike phase!
<racarr_> *blows kisses*
<racarr_> afk for an hour or so then back to grok the details of input sender
<RAOF> Wooo!
#ubuntu-mir 2014-06-20
<racarr_> annnd back
<racarr_> I just realized a great alternative to input-sender besides
<racarr_> copying InputDispatcher in to unity-mir lol
<racarr_> it's also possible to just take the unity-mir InputDispatcher patches (for a certain kind of injection) in to our input dispatcher, and expose it
<racarr_> via say...the_input_sender() with a small wrapper class
<racarr_> without exposing any of the android-deps.
<alan_g> alf__: I don't really understand the motivation for the attributes mechanism: It uses values (index into the attribute array) in place of types which I guess allows some binary compatibility - but the way we use it hides that behind incompatible functions. (We have mir_surface_set_swapinterval() not mir_surface_set_attribute(...mir_surface_attrib_swapinterval...))
<alf__> alan_g: I see it as an internal convenience mechanism for adding (simple) surface attributes and associated change notifications
<alan_g> alf__: I sometimes see it as an internal inconvenience mechanism. ;)
<alf__> Saviq: Hi! Do you know if Gerry is around today?
<Saviq> alf__, it feels like he took a swap day today... but I'm not positive on that...
<alf__> Saviq: thanks
<alf__> Saviq: Do you know where the qt compositor branch is?
<Saviq> alf__, of unity8?
<alf__> Saviq: yes
<Saviq> alf__, https://code.launchpad.net/~unity-team/unity8/mirCompositor
<alf__> Saviq: great, thanks
<Saviq> alf__, mzanetti will be able to guide you through the branches, too
<Saviq> alf__, you can also always look at https://launchpad.net/~unity-team/+archive/phone-right-edge/+packages
<Saviq> alf__, and see that unity8 was built by recipe unity8-qtcompositor
<Saviq> alf__, and that, in turn, will tell you which branch it builds from :)
<alf__> Saviq: ha ^
<Saviq> :)
<alf__> greyback: Good morning! I have added as reviewer for https://code.launchpad.net/~afrantzis/mir/scene-elements/+merge/223822 . I don't need a code review (but you are welcome to do so), just a Qt compositor perspective on the approach (see comments).
<greyback> alf__: hey. Ok, will take a look
<mterry> Hey folks!  Can I get someone to review https://code.launchpad.net/~mterry/unity-system-compositor/kill-spinner/+merge/223837 ?
<kgunn> AlbertA: ^ would you mind ?
<kgunn> alan_g: alf__ racarr_ so dandrader and i were just chatting about inputsender branch
<alan_g> kgunn: ok
<kgunn> if we go back in time, reason for this was to avoid exposing android headers in our public includes....
<kgunn> howerver, what are your thoughts on it compared to (vs.) input sender
<kgunn> being a large diff, that might bring in bugs
<kgunn> whereas exposing android headers would be a direct/proven path
<kgunn> ...and we're not exactly settling on inputsender
<alan_g> Why would we need to expose android headers?
<dandrader> alan_g, so that qtmir can replace android::InputDispatcher with its own thing
<dandrader> alan_g, not needing the input_sender interfaces then
<kgunn> right, sender is effectively a wrapper
<dandrader> alan_g, and the big mir changes that entails it
<kgunn> dandrader: is that really the _only_ reason ? avoiding the header thing for custom dispatcher
<alf__> kgunn: I assume we are discussing in the context of rtm?
<alan_g> dandrader: I've not been following the branch closely but I don't understand why a custom dispatcher would need all the stuff that has aggregated there.
<kgunn> alf__: yes, well landing qtcomp for sure
<dandrader> alan_g, I didn't go through that branch. I just used the needed interfaces it provides. so can't comment on the rest
<alan_g> E.g. timer and scheduler classes being introduced in or moved to the wrong namespace
<alf__> alan_g: kgunn: IIRC, originally what was needed was to be able to deregister fd handlers from the main loop
<kgunn> ah so there's a little more than the header sanitation issue
<alf__> alan_g: kgunn: but that led to further complexity added to MainLoop, and the decision was made to split things out (and Timer functionality too), as a refactoring
<dandrader> so at this point, to make it for RTM, the safest approach, IMHO, would be to expose android-input headers as a "private API" (i.e. an exposed API that can/will change without further notice, "use it at your own risk")
 * alan_g thinks someone needs to be taught the "mikado game"
 * kgunn has to google mikado game
<alan_g> I thought racarr_ was going to review this and propose a solution?
<dandrader> so that we unblock the qt compositor work and don't bring in any polemic mir changes
<alf__> dandrader: kgunn: will exposing the android-input headers (even as "private") commit us in any way to continue using them?
<dandrader> alf__, you can remove them once mir API for doing the same (e.g. input_sender) is available
<dandrader> alf__, in order to not leave qtmir in the dark
<alan_g> kgunn: try googling "jeff langer mikado Method"
<alf__> alan_g: kgunn: "langr" :)
<kgunn> dandrader: right, but begs the question...is it the right thing
<kgunn> to do
<kgunn> i suppose its not forced on anyone
<kgunn> e.g. only shells that wanna replace input dispatcher
<alan_g> the right thing to do is properly integrate our fork of android input into the rest of Mir
<kgunn> i gotta hop otp, bbian
<kgunn> oops/bbian/bbiab
 * alan_g wonders if we achieved anything
<dandrader> alan_g, but do we have time to do the right thing?
<alan_g> dandrader: Short term: I don't know. But this is a continuing drain of resources: do we have the time not to do the right thing?
<alan_g> I don't have a strong position on anything except that the MP is currently in a state of confusion. It could be pragmatic to land and fix after.
<dandrader> alan_g, I do think we have the time to go for the approach of exposing android-input headers until the input_sender work is shiny and ready to land
<dandrader> meaning landing input_sender post RTM
<dandrader> when-it's-done
<alan_g> dandrader: racarr_ was looking into this. What does he say?
<dandrader> alan_g, we will know once he starts his work-day today
<dandrader> I'm just getting freaked out about the impending deadline approaching and we still having qtcomp blocked
<greyback> alf__: still there?
<alf__> greyback: yes
<greyback> alf__: just looking at https://code.launchpad.net/~afrantzis/mir/scene-elements/+merge/223822/comments/537129
<greyback> alf__: I don't quite understand the question.
<alf__> greyback: ok
<greyback> alf__:" compositor *has* to decide whether it's going to use a renderable or not when getting it"
<greyback> could you rephrase please
<greyback> alf__: directly I don't see any impact to QtComp with that change, since we don't use mir's Scene at all
<greyback> and overall I think it's a good idea
<alf__> greyback: in the MP the compositor gets a sequence of all SceneElements (corresponding to surfaces) as distinct objects and can process them (e.g. mark them as occluded or rendered) at any convenient time during compositing. The alternative is for the scene to do the filtering, but that means that the compositor needs to know at the beginning which surfaces it will render and which not.
<alf__> greyback: @we don't use mir's Scene at all, hmmm, hmmmmmmmm
<alf__> greyback: so qt compositor itself will take care of telling surfaces when they are occluded?
<greyback> alf__: it'll have to yes.
<alf__> greyback: so I guess what's in devel right now (the ability to configure a surface attribute for visibility on the server) is enough for you?
<alf__> greyback: (changing visibility will send an event to the client)
<greyback> alf__: effectively yes
<greyback> alf__: I like the idea of the compositor being pretty dumb, it should just render exactly the list of things it is given. So I'd prefer scene to do the filtering
<alf__> greyback: well, the "scene" in mir is not a proper Scenegraph, so it doesn't have all the information to do the filtering
<greyback> alf__: then with current mir arch, the compositor is the only thing which has the info to do the filtering, am I right?
<alf__> greyback: yes (although the scene could do it for some cases)
<racarr_> dandrader: I have another solution for input sender
<racarr_> alan_g: ^
<alf__> kdub_: ^^ (discussion with greyback)
<alan_g> racarr_: \o/
<racarr_> 1. Small input_dispatcher patcher in our tree that exposes like sendToTargets.
<racarr_> 2. Wrap InputDispatcher in our server configuraiton as
<racarr_> wait for it...the_input_sender
<racarr_> 3. Export that
<racarr_> 3. When non android input sender is ready
<racarr_> drop it in API compatible
<greyback> alf__: I don't know what more I can say then :)
<kdub_> greyback, the thing I don't like about the scene having /all/ the information is scenarios where the compositor (the view) has some state
<greyback> kdub_: IMO compositor should not have any state, only the scene should
<alan_g> racarr_: that sound like what I thought anpok tried to do before starting n unravelling the world
<kdub_> like, if you have some perspective that affects occlusion set in the compositor, then the compositor is the best to figure that out
<alan_g> But I've yet to understand why it doesn't work
<racarr_> alan_g: Ok I am 95% sure it can work...
<racarr_> and I thought
<racarr_> anpok just got excited by
<racarr_> tryinhg to "fix" everything
<racarr_> lol
<racarr_> i.e. eventually we really would like to chunk up input dispatcher
<greyback> kdub_: right, but IMO that perspective should be defined in the scene, just executed by the compositor. Say if you do add that perspective just in the compositir, how then do you calculate the input destination?
<alan_g> racarr_: make it so!
<alan_g> ;)
<kdub_> greyback, right, but that limits the flexibility you can have in putting stuff on the screen
<racarr_> alan_g: mm ill mp something today.
<kdub_> because you can only put on screen what is implemented/designated by the scene
<kdub_> whereas if you're given this universal idea of a scene, then you can shuffle it around however you want during the gl pass
<alan_g> racarr_: Sounds good
<kdub_> like, the compositor as 'the view' should have state, as long as that state applies only to how the view is seen
<kdub_> the visibility stuff is an example of how we can arrange state changes (like input stuff) when accessing the scene
<kdub_> I guess what I'm driving against is having stuff like 'spread' or 'zoom' as scene concepts
<dandrader> racarr_, so we need two things. 1- get all input events out of InputReader, 2- ability to send an event to a given surface (actually its underlying input channel). your solution seems to take care of only item 2?
<alf__> kdub_: greyback: I guess if Qt's Scenegraph is powerful enough to represent all views we need to support for unity8, then qt compositor won't care about compositor->scene communication anyway
<greyback> kdub_: I worry if any visual state is defined in the compositor, then the input system will be lacking information
<dandrader> otherwise, yeah, it sounds like it would solve our problems
<kdub_> greyback, right, but the compositor is already mapping the surface from the 'universal' scene designation to the 'onscreen' mapping, so hopefully that information can just be fed back to the scene
<kdub_> and input is happy
<racarr_> dandrader: Hmm...right...
<racarr_> dandrader: Would it be enough to use
<racarr_> the_input_filter?
<greyback> kdub_: fed back. So compositor writes to the scene?
<racarr_> it will get all the events....and can drop them from the normal dispatch
<racarr_> by "handling them"
<racarr_> then reinject them to a specific channel
<racarr_> if they come back out of Qt
<kdub_> greyback,  it has to get the info there, kinda like the visibility stuff
<kdub_> and so I guess the scene then has the info, but its more generic
<dandrader> racarr_, sounds good. question is: how much effort is required to come up with such MP?
<greyback> kdub_: if the scene had all the visual state itself, then the scene has enough info to determine visibility
<greyback> and compositor doesn't need to "feed back" - just needs to render what it is told to render
<alf__> greyback: "I guess if Qt's Scenegraph is powerful enough to represent all views we need to support for unity8" -> is it?
<dandrader> racarr_, does this the_input_filter already exist?
<racarr_> dandrader: I think like 2-3 hours :)
<racarr_> the_input_filter does exist
<racarr_> the input dispatcher patch...I think I found a quite easy approach
<racarr_> that will let both work
<racarr_> and then
<racarr_> the_input_sender itself is the same interface
<racarr_> as from anpoks mp
<dandrader> racarr_, it's too good to be true :)
<kdub_> greyback, but what about simple vs complex compositors
<greyback> alf__: sorry, missed that. I've not encountered any design request that QML was unable to do yet
<racarr_> it seems so doesnt it lol
<racarr_> dandrader: Anyway im going to give it a try today and get a proposal up then on monday
<racarr_> maybe anpok will have a stroke of brilliance and input sender will be instantly ready
<racarr_> and if not we can land this and it will be ABI compatible
<dandrader> racarr_, the simpler the better
<kdub_> like, if someone doesn't need an animation/zoom/etc framework, but is given one by the scene, makes the usc-type compositors less possible (or at least less lightweight)
<racarr_> :)
<racarr_> dandrader: For the actual injection, surface->consume(event) like in input sender is enough right?
<alf__> greyback: ok, do you need anything more from the visibility events side (as mentioned you can send occluded/exposed events to client surfaces with mir/devel)?
<racarr_> No extra flags or anything
<dandrader> racarr_, yeah surface->consume(event) would be the best API.
<greyback> alf__: I don't think so. Note it is something we'd like working in USC, when split greeter lands it's a nice optimisation, so have unity8 notified it is hidden
<racarr_> Ok! will get on it as soon as the coffee kicks in
<dandrader> :)
<kdub_> so, in summary, I guess I'm just interested in having the ideas in the scene be very generic, and the 'compositor' can set some of those generic ideas
<greyback> kdub_: then building a scene into Mir at all is doomed. How it be both simple and complex?
<greyback> kdub_: QtComp isn't using Mir's scene, because Mir's scene is too basic
<alf__> greyback: go not to the elves for counsel, for they will say both no and yes
<greyback> alf__: :D
<racarr_> kgunn: Just to fill you in, have a new input sender theory
<kdub_> greyback, i guess thats the challenge, to have the scene ideas be flexible enough to support the complex stuff without forcing requirements on the simple compositors
<racarr_> That's the great thing about trees lol
<racarr_> kgunn:  Basically patch our input dispatcher to support what they need
<racarr_> expose it via mir::InputSender
<racarr_> ABI compatible when anpoks stuff is done
<greyback> kdub_: those terms sounds contradictory to me, but perhaps there is a middle-ground
<greyback> I hope you enjoy challenges ;)
<racarr_> I don't think its contradictory!
<racarr_> QML isn't hard for simple apps.
<alf__> greyback: how are you tracking server surfaces in qt compositor (e.g. do you intercept creation and attach the surface to your own/Qt's objects?)
<greyback> alf__: exactly that
<racarr_> kgunn: Did spend time reviewing input-sender...
<racarr_> it does seem roughly correct, but there are...um
<racarr_> on the order of dozens of small issues
<racarr_> which in a normal situation we would block review with
<racarr_> which makes it kind of hard
<racarr_> to convince yourself there aren't major problems because of all the minor problem noise
<racarr_> sooooo....I think we would be luckly to land it by next week.
<racarr_> confidently land it
 * kdub_ has forgotten the original topic
<racarr_> kdub_: We were trying to make an alternative to X11 because its hard to extend.
<racarr_> :p
<alf__> kdub_: greyback: well, ok, for the moment let's focus on something useful for USC and other simple compositors and try to gradually evolve it to something qt compositor can integrate with (it will take time).
<kdub_> alf__, right, sounds good to me
<alf__> kdub_: original topic was getting the Qt compositor perspective on exposing SceneElement objects vs the scene doing the filtering (your proposal in the comment)
<alf__> kdub_: bottom line is that Qt compositor doesn't care about it at all at the moment :P
<greyback> alf__: +1 from me too
<alf__> kdub_: although I like the "tell don't ask" flavor of the scene doing the filtering, it seems from the conversation that exposing SceneElement gives us more flexibility for other use cases (like input)
<kdub_> alf__, yeah, the thing I liked over my suggestion in your approach was that the visibility stuff can only be told on a change, instead of every frame
 * kdub_ makes confusing sentence
<kdub_> alf__, I liked that your approach could only tell when things change
<kdub_> also, scene element might be a way to break Renderable::id()
<kgunn> racarr_: ack
<kgunn> racarr_: maybe with anpok back on monday and some review attention we can iterate more quickly
<kgunn> racarr_: dandrader was espousing earlier the idea that just exposing the android headers might not be less risky both in terms of time & bugs
<kgunn> and then switch when input-sender is ready
<dandrader> kgunn, s/might not be/might be
<kgunn> yes
<kgunn> sorry
<kgunn> exposing the android headers might _be_ less risky both in terms of time & bugs
<racarr_> slightly
<racarr_> the idea is this should not be very risky either
<racarr_> because its 99% the existing android code
<racarr_> so it just saves us exposing the headers I guess
<racarr_> right, I mean, an option that has the same risk
<racarr_> as exposing the android headers
<racarr_> but doesnt expose the headers
<racarr_> is rather than make an input dispatcher that can function in both modes (which...again I dont think will be much more than exposing some stuff)
<racarr_> is copy dandraders patched input dispatcher
<racarr_> in to our tree
<racarr_> expose it via the_input_sender (no android headers, small wrapper object...literally just a forwarder)
<racarr_> and allow selection of input dispatchers via something in the server configuration
<racarr_> that
<racarr_> doesn't require android headers...which is easy because its not arbitrary input dispatchers
<racarr_> just input dispatcher 1 v. 2
<racarr_> kgunn: dandrader: ^
<racarr_> So. I think that's better than exposing the android headers.
<dandrader> racarr_, beware that in my android::InputDispatcher fork I removed all the logic about android::InputDispatcher deciding what windows gets the incoming events. So it works only in "dumb" mode.  ie: "send this event to this channel"
<racarr_> Yes
<racarr_> so it would be
<racarr_> an alternative input dispatcher
<racarr_> rather than replacing ours
<racarr_> but like I said I am very hopeful I can make an input dispatcher which will work in both modes
<racarr_> without much risk
<racarr_> well. it could replace ours at runtime, but I mean we could temporarily have both in tree
<dandrader> racarr_, having both in the tree sounds safer
<racarr_> but I think, taking the InputDispatcher and building it in our tree, then exposing it without android headers.
<racarr_> is better than
<racarr_> building it in your tree
<racarr_> just to prevent leaking
<racarr_> android any more and
<racarr_> right I mean its just slightly better
<racarr_> all around
<racarr_> ABI compatibility when input sender lands
<racarr_> etc
<dandrader> racarr_,  the "one inputdispatcher that servers all modes" is an unproven approach. it might work, but it might not. I don't think we have time to experiment with that
<dandrader> racarr_, resist coming up with a cleaner, more beautiful patch :)
<racarr_> Lol I guess you are right... there are so many member variables in InputDispatcher its basically impossible to "prove" that changing any one method
<racarr_> isn't going to subtly destroy everything
<racarr_> even if I have a strong suspiscion in this case lol...ive been known to be wrong
<racarr_> so um [
<racarr_> we go with
<racarr_> copy your input dispatcher in to our tree
<racarr_> expose it via InputSender?
<racarr_> How do you get the events out of InputReader in this setup...what does your patched dispatcher do when it gets events from the InputReader (where it would normally decide what windows get the events)
<racarr_> because that is the part that offers events to the_input_filter
<dandrader> racarr_, it just doesn't
<racarr_> it doesn't? Where do events go out of the input reader then?
<dandrader> racarr_, well, in my original patch, there's a QtEventFeeder that gets the events from InputReader instead of InputDispatcher
<dandrader> racarr_, then eventually the forked InputDispatcher is told to send event X to channel Y and that's it
<racarr_> dandrader: Ok so to avoid exposing InputListenerInterface (interface from Reader->Dispatcher)
<racarr_> lets modify your forked inputdispatcher to hook up to the input reader again
<racarr_> but rip out ALL the logic
<racarr_> and it will just immediately
<racarr_> send the event
<racarr_> to the mir input filter
<dandrader> racarr_, right
<racarr_> ok :D
<dandrader> racarr_, it was like this https://docs.google.com/a/canonical.com/drawings/d/1tXs9s32ix5c_Iomj2TfGPgx615yCuadWRd1UTJKnbac/edit
<racarr_> mm.
#ubuntu-mir 2015-06-15
<duflu> Oh seriously? Same boot bug now affects my second desktop
 * duflu suspects grub/EFI boot bugs are due to me having customized /etc/default/grub (which confuses updated)
<duflu> It's happened on trusty and wily now
<duflu> *confuses updates
<RAOF> Huh.
<RAOF> I've customised that.
<RAOF> And not had anything break :)
<duflu> RAOF: Just a theory. I've spent Monday morning reinstalling my wily build machine from scratch
<duflu> Also there were slight signs of filesystem corruption in a couple of places
<duflu> So start again
<duflu> The system was only a week or two old to begin with
<miken> kgunn: Hi. I took a look at the kodi/xbmc code over the weekend. It seems they've been moving away from sdl2, using gl/gles/dx for rendering (I'm not certain, still trying to find out on irc). I assume that's narrows my options down for trying to use the mir snap?
<davmor2> miken: I believe that gles wouldn't be an issue, not sure about gl but dx I think is microsofts so almost certainly a no go, others might be able to inform you more
<miken> davmor2: yes, I assumed I'd be using gles if anything (that's what the kodi rpi deb build uses). But I assumed my snap wouldn't have access to gles. Great if it does.
<miken> (heh, and yes, I won't be trying with directx :P)
<anpok_> miken: if egl does not work you will have to implement: https://github.com/xbmc/xbmc/blob/master/xbmc/windowing/egl/EGLNativeType.h
<anpok_> s/egl/sdl
<miken> OK, I'll try a binary using gles and go from there. Thanks anpok_ .
<miken> and davmor2 :)
<attente> is anyone getting really bad flickering in the demo shell after the kernel update to 4.0?
<racarr_> I keep on finding more code to delete in papi :( the delete-deprecations diff is now over
<racarr_> 15k lines and I can't
<racarr_> keep track of it lol
<kgunn> attente: interesting, intel ?
<attente> kgunn: yes. it's reminiscent of https://bugs.freedesktop.org/show_bug.cgi?id=88944. but it's slightly different that the flickering only occurs below wherever the cursor is. and the workaround of switching to a vt before switching to the demo server doesn't work
<ubot5> Freedesktop bug 88944 in DRM/Intel "Heavy black flickering with Intel graphics after VT switching to Mir from X" [Normal,Needinfo]
<kgunn> attente: so i take it you got the kern update via being on wily ?
<attente> kgunn: yes. i switched back to an older one for the mean time
<kgunn> yeah, i think everyone's been real hesitant to step off into wily
<kgunn> most folks staying on vivid+stable overlay
<racarr_> greyback: pushed updates to platform-api delete-deprecations
<greyback> racarr_: thanks for that
<racarr_> np :D
<racarr_> deletedeletedelete
<greyback> yummy red
<racarr_> omg I didn't realize how much code I was going to get to delete in input/android now that droidinput::InputDispatcher
<racarr_> is gone
<racarr_> :)
<racarr_> death to input registrar, input enumerator, android_input_targeter
<racarr_> window handle repository
<racarr_> android window handle
<racarr_> android application handle
<racarr_> and the dispatcher
<RAOF> :)
#ubuntu-mir 2015-06-16
<alan_g> alf_: vt switching bug lp:1465585
<alf_> alan_g: thanks
<tjaalton> mesa doesn't build on wily due to mir abi changes
<tjaalton> so egl-platform-mir.patch needs an update
<alf_> tjaalton: I will take a look
<tjaalton> thanks
<tjaalton> http://pastebin.com/RGP7Bt68
<tjaalton> is the error
<tjaalton> if it's something simple I can apply it directly and upload a new mesa
<tjaalton> since I have 10.5.7 merged and ready
<tjaalton> btw, mir source package still refers to the old lp branch
<tjaalton> in debian/control
<alf_> tjaalton: This package dependency problem in mir. If you want a quick solution to unblock you until we fix it, you can add a build dependency on libmirclient-dev.
<tjaalton> alf_: ah, ok I'll try that
<tjaalton> alf_: yeah that fixed it, thanks
<alf_> tjaalton: yw
<alf_> tjaalton: Is there a branch holding the packaging of mesa? lp:ubuntu/mesa seems not to contain recent updates?
<alf_> tjaalton: ah, found it: http://git.debian.org/?p=pkg-xorg/lib/mesa.git
<tjaalton> alf_: yeah that's it
<tjaalton> just pushed the branch
<alf_> tjaalton: FYI, https://bugs.launchpad.net/mir/+bug/1465642, I will let you know when this change reaches wily, so you can remove the workaround
<ubot5> Launchpad bug 1465642 in Mir "mir-client-platform-mesa-dev package dependency is incorrect" [High,Triaged]
<tjaalton> ok cool
<alan_g> alf_: was there any follow-up planned to your initial end-end test harness? I remember we discussed various options in Dallas...
<alf_> alan_g: I think the discussion was for the end-to-end latency tests (which I haven't made any progress on).
<alan_g> alf_: yeah, that's what I was wondering about. We landed mir_privileged_tests didn't we?
<alf_> alan_g: Yes (and are enabled in CI). At the moment these only test that kernel input events reach clients, they don't perform any latency measurements/checks.
<alan_g> alf_: OK. That's what I was wondering about. Thanks
<alf_> alan_g: When you get some time, could you please check that https://code.launchpad.net/~afrantzis/mir/fix-1465585-1465669-one-input-dispatcher-to-rule-them-all/+merge/262088 solves the VT issue for you. I was getting something but not sure if it is exactly what you bug was about.
<alf_> alan_g: "I was seeing something similar, but not sure..."
<alan_g> alf_: ack. After I finish documenting the latest input bug I've found.
<alf_> alan_g: Does purge-titlebars solve the same problem with GL you were referring to earlier today?
<alan_g> alf_: yes
<alf_> alan_g: Great \o/
<alan_g> alf_: fixes 1465585
<alf_> alan_g: thanks
<alf_> kdub: @allocate-and-release-buffers-protobuf, can the allocate_buffers() call allocate buffers independently of a buffer stream?
<kdub> alf_, no
<alf_> kdub: ok, so 1. why is BufferStreamId optional and 2. why do we need to respecify buffer parameters, don't all buffers have the same parameters specified when creating the buffer stream?
<kdub> its optional because optional fields were recommended somewhere on the protbuf site (bit hazy memory, but still abide by the advice)
<kdub> I guess makes things easier to deprecate in the future
<kdub> and for 2), I don't think we're having the constraint that all buffers have to be the same size
<kdub> in the same stream
<kdub> most the time they will... but I think for resize it might be helpful to have different sizes transiently
<kdub> i have a sneaking suspicion that certain mm decoders might appreciate that too
<alf_> kdub: right, but I am not sure if we will need to explicitly allocate buffers of mixed sizes. We will get mixed sizes as we allocate buffers (of new size) and release buffers (of the old size).
<kdub> alf_, I guess I'm imagining more of a client-cooperating resize
<kdub> where they get a resize event informing it of its "ideal onscreen size" and it will allocate buffers (if it can) to fit that size, and start sending those
<kdub> and release the old-sized buffers when the client is done with them
<kdub> hence the side discussion about separating mg::Renderable::screen_position() from mg::Buffer::size() a bit more
<kdub> side-discussion & card, I should say
<alf_> kdub: I don't get how the scenario you are resizing requires the client to _allocate_ buffers of mixed sizes (I agree that the buffer stream will end up having mixed sizes as the client allocates/releases)
<kdub> well, if the client starts getting unrequested buffers as part of the server-initiated resize event, I guess it then has to free them
<kdub> and, if the client is designating which of its many buffers to use, it can always just say 'use the badly-sized one' if it wants... the client has to cooperate with the resize, and letting it request buffers that it thinks are best seemed the way to go
<alf_> kdub: Perhaps I haven't made myself clear enough... I am not concerned about the client allocating custom sizes, I am doubting the usefulness of being able to allocate mixed sizes in a single call e.g. (100x100, 50x50, 10x10) vs (100x100,100x100,100x100)
<alf_> kdub: But the price we pay is small enough (and we are indeed a bit more versatile), so I guess I don't mind in the end
<alf_> kdub: primarily wanted to know if there was a scenario that absolutely needs this
<alf_> kdub: which I was missing
<kdub> alf_, I started out with one buffer/call, but it seemed that some batching (esp for release) would just mean less ipc (in rev 2661 of the branch)
<alf_> kdub: I am OK with release, mostly concerned with allocate, but I am OK with that too :)
<kdub> and right, I guess its just for versatility
<kdub> I guess (and its stretching a bit) maybe a decoder might want a spare smaller p-frame hanging around, whereas it mostly allocates full-resolution buffers
<kdub> anymore takers on: https://code.launchpad.net/~kdub/mir/multiple-bufferstream-api/+merge/261123 (otherwise will TA shortly)
<alan_g> kdub: you have enough "Approve" by A* without me. ;)
<kdub> :) the "A team"
<AlbertA> @vogons: well looks like there are issues loading both libmirclient.so.8 and libmirclient.so.9 at the same time after fixing the protobuf issue...
<AlbertA> no crashes, just can't get a connection....
<AlbertA> global var issues?
<AlbertA> libmirclient.so.9 is loaded because the mesa client platform module links against it....
<AlbertA> but the ABI number of the modules themselves has not changed
<kdub> groan
<AlbertA> it seems the local scope from symbols.map is gone...hmmmm
<AlbertA> @vogons: so fixed the issue with the libmirclient symbols....it looks like using the protobuf xxx::default_instance().New() is enough to address the issue...so mir 0.13.3 is on
<camako> AlbertA... great!
<kgunn> vogons anyone know about the race between mir and agetty ?
<kgunn> i was wondering...if you lose the race, what's a way to undo the loss ?
<kgunn> like can i just kill the agetty process ?
<kgunn> or is there some other clean up or something that needs to happen ?
<kgunn> ok, need to bail for a little... still post here, but email as well if i'm still off
<AlbertA> kgunn: umm not quite sure...what's the issue? both starting at the same time and either agetty wins the vt or not?
<AlbertA> kgunn: can it be in a different VT?
<RAOF> Yay! I left this code in an uncompilable state, so there's an obvious entry point.
<RAOF> Go me!
#ubuntu-mir 2015-06-17
<RAOF> Huh. I thought explicitly sized enums were in C99.
<RAOF> Incorrect!
<duflu> Sigh. Science is mostly about finding new things that don't work...
<duflu> Speaking of which, time to do some science on dinner.
<kgunn> mterry: yo, so with the agetty race thing
<mterry> kgunn, yeah?
<kgunn> is this the bug
<kgunn> https://bugs.launchpad.net/mir/+bug/1445553
<ubot5> Launchpad bug 1445553 in Mir "[snap] Can't ever VT switch (Ctrl+Alt+Fn) while the deb2snap Mir service is running" [Undecided,New]
<kgunn> mterry: and follow up question is, if you "lose the race"
<kgunn> is there a way around it? e.g. can i just kill agetty
<kgunn> just curious...
<mterry> kgunn, if you lose the race, you can kill mir and it will restart and take the vt.  I've not tried killing agetty, but maybe?
<mterry> kgunn, it's not that bug.
<mterry> kgunn, there's not an LP bug for the race issue
<kgunn> mterry: that seems strange to me, you can kill mir to restart and take the vt ?
<kgunn> mterry: i guess you're assuming in that statement
<kgunn> that the script is always present,
<kgunn> trying to win the race
<mterry> kgunn, so with the vt race, the problem is, whoever starts last gets the VT
<mterry> kgunn, and if you restart mir, it will steal the VT back
<kgunn> mterry: ah...ha
<AlbertA> vogons: any other opinions on https://code.launchpad.net/~albaguirre/mir/fix-1465883/+merge/262160 before I TA?
<AlbertA> that will be backported to 0.13
<dandrader> anpok_, what do I do to in qtmir/unity8 to disable USC's cursor?
<dandrader> I mean, what do I have to do in qtmir/unity8 to accomplish that
<dandrader> racarr_ ^ (you might also know about it)
<AlbertA> alf_: you want lp:mir r2667 in mir 0.13.3 right
<AlbertA> ?
<alf_> AlbertA: Correct
<AlbertA> alf_: ack
<kgunn> racarr_: anpok_ so i'm wanting dandrader to do the mouse cursor rendering, but he's stuck cause mir doesn't have mouse input event type, only pointer
<kgunn> how can we unblock him ?
<kgunn> what needs to happen
<racarr_> the pointer events are the location of the system cursor
<racarr_>  / is the same as mouse input
<racarr_> not sure what you mean :)
<dandrader> racarr_, ah, you're there. unity8 needs the raw mouse events
<racarr_> unless you mean "relative coordinates"
<racarr_> ah yeah
<dandrader> racarr_, qtmir, actually
<racarr_> thats on the backlog...it was blocked by the input event cleanup
<racarr_> I think RAOF had kind of marked it off but not sure
<dandrader> racarr_, so qtmir needs to tell USC to not draw a cursor and it needs to get the raw mouse events (not the higher lever pointer ones)
<dandrader> racarr_, can't find the card...
<racarr_> dandrader|lunch: so I believe you can tell USC not to draw the cursor now using
<racarr_> the_cursor
<racarr_> unless we privatized it
<racarr_> but in the nested case thats hooked up
<racarr_> to the
<racarr_> system compositor cursor
<racarr_> and you can just hide it
<racarr_> dandrader|lunch: This must be the card https://trello.com/c/FfH2HUV8/109-add-client-api-for-subscription-to-raw-events
<racarr_> for raw events
<fisch246> i have a feature request for mir
<anpok_> yes?
<fisch246> there is one feature missing in unity and x that is the one thing missing that prevents me from using Ubuntu as my daily driver. Borderless fullscreen window support. This is used in video games to allow easy access to your second monitor without alt-tabbing. It's in windowed mode, but taking up the dimensions of your screen. Currently the top panel overlaps or pushes the window of the screen. If the panel would either allow windo
<fisch246> if you have any questions about what i mean, feel free to ask
<anpok_> your line was cut off after ".. allow windo"?
<anpok_> why without alt-tabbing?
<fisch246> "allow windows to overlap (which can cause problems) or allow a way for games and windows to tell mir that it is in borderless mode. When it gets this flag it should then draw the window over the panel instead of allowing all windows to do so."
<anpok_> btw that would be a feature request for unity8.. and I believe the plan for unity8 desktop mode includes that feature..
<fisch246> ah so that's DE not display server?
<davmor2> fisch246: you can do fullscreen on Ubuntu now
<fisch246> yea fullscreen works, but i use 2 monitors
<fisch246> so if i need to move my cursor off to answer a message or answer a call from skype, my game closes
<AlbertA> vogons: I need at least one review for: https://code.launchpad.net/~mir-team/mir/0.13/+merge/262262
<kdub> looking
<fisch246> i'm stuck in the game when it's fullscreen mode
<fisch246> i'm trying to come back to ubuntu from arch, but this is the last issue that's stopping me
<fisch246> but anyway, so you think i should go check on the unity team to see if they're working on this?
<kdub> AlbertA, lgtm, but why does launchpad have those 5 bugs as related? I don't see those patches in the diff
<AlbertA> kdub: for some reason it lists the previous resolved bugs from earlier merges
<AlbertA> kdub: thanks btw
<kdub> AlbertA, yep, no problem
<kgunn_> racarr_: so i'm a little confused, wrt adding raw event client api, is mirevent2 cleanedup to the point that can proceed ?
<kgunn_> e.g. is it blocked or no ?
<racarr_> kgunn_: I think it's unblocked enough!
<racarr_> it's sort of a matter of like
 * kgunn_ loves good news
<racarr_> a month ago it would have been obtusely difficult
<racarr_> now there are some minor difficulties
<racarr_> post libinput and some other stuff
<racarr_> it could probably get even easier
<racarr_> but I think it's 'unblocked'
<AlbertA> racarr_: slangasek is complainging about papi build failures (seems related to event headers) in the #ubuntu-ci-eng channel
<AlbertA> might want to join....
#ubuntu-mir 2015-06-18
<AlbertA> @vogons: FYI mir 0.13.3 release is now waiting for QA approval
<RAOF> Woot.
<duflu> RAOF: Remind me what we can't load twice; is it libprotobuf or libmirprotobuf?
<RAOF> duflu: libprotobuf
<duflu> I recall I proposed a solution to that months ago
<duflu> We just never implemented it
<duflu> Need to dig it up
<RAOF> Well, I guess it's actually libmirprotobuf, but due to a libprotobuf behaviour.
<duflu> I also recall alf logged a manual test case somewhere
<RAOF> Yeah, it *would* be possible to patch protobuf to not abort on us.
<RAOF> This has been proposed upstream (at least twice that I'm aware of).
<duflu> RAOF: Or just dlopen libprotobuf and throw away the key. Leaking it once on startup ensures the dynamic loader won't load it twice
<RAOF> Ah, no.
<RAOF> The problem is that libprotobuf calls abort() when we load libmirprotobuf twice.
<duflu> RAOF: Init function?
<RAOF> Correct.
<RAOF> Specifically - the protobuf compiler adds an init function to libmirprotobuf that calls a libprotobuf function that is (a) necessary, and (b) aborts() if called twice.
<RAOF> Well, *that* has profoundly unintuitive consequences...
<RAOF> Ok, sure. Don't call mir_connection_* functions from MirConnection. Why not.
<duflu> RAOF: I would expect deadlocks (default mutexes are not reentrant)...?
<RAOF> This call had no mutexes held.
<RAOF> But it turns out that it'll cause mir-client-debug-extension to fail to link :)
<dandrader> anpok, ping
<anpok> dandrader: pong
<anpok> dandrader: you need relative mouse coordinates.. and hints on how to disable the cursor display of usc?
<dandrader> anpok, I would say mouse device events instead of the higher level pointer events
<dandrader> anpok, and yes, a way for qtmir/unity8 to disable USC cursor
<anpok> .. we still have to implement sending raw mouse movements
<dandrader> anpok, yeah, that card, right. https://trello.com/c/FfH2HUV8/109-add-client-api-for-subscription-to-raw-events
<dandrader> anpok, but is it already possible to hide/disable USC cursor?
<anpok> yes .. I think through the cursor configuration ..  just checking
<anpok> hm ok I might be wrong
<anpok> so it seems we need to add something for both
<dandrader> anpok, should I create a card for this "make it possible for qtmir/unity8 to hide/disable USC cursor"? or will you do it?
<dandrader> anpok, well, I created https://trello.com/c/VrM6AVaq
<anpok> dandrader: take a look at tests/acceptance-tests/throwback/test_client_cursor_api.cpp
<anpok> -> DisabledCursorClient..
<anpok> set mir_disabled_cursor_name and configure at surface
<AlbertA> I think locking a mutex is a fundamentally bad idea....
<AlbertA> in a destructor
<kdub> AlbertA, maybe if there's a static that needs modifying, might be okay
<attente> hi, is mir_surface_configure_cursor() working for anyone in the demo shell? doesn't seem to do anything for me
<attente> tried to pass in mir_caret_cursor_name, but no luck...
<racarr_> attente: The last time I tried I was able to run mir_Demo_client_cursors
<racarr_> and uh
<racarr_> hover the cursor over the surface and see the cursor change
<racarr_> lemme try again now
<racarr_> attente: works for me
<racarr_> -.- which must not be particularly helpful
<racarr_> ill help you more after lunch! I dunno what would be up with your configuration...
<attente> racarr_: sure, thanks :)
<racarr_> back
<racarr_> attente: So does demo_client_cursors work
<attente> racarr_: is there something special i need to do to build the examples?
<racarr_> attente: No it should be there in build/bin/ or mir-demos package
<attente> racarr_: ok, it just pops up a small grey surface, is the cursor supposed to change when i mouse over?
<attente> it doesn't change when i click either
<racarr_> attente: Are you perhaps on fedora or something
<racarr_> I wonder if the cursor locations are different the
<racarr_> XCursor loading isn't horribly sophisticated
<racarr_> attente: There is mir_demo_client_animated_cursor which uhhh
<racarr_> shows like a white rectangle fade opacities
<racarr_> that doesnt require XCursor
<racarr_> so if that works, then the cursor is working but
<racarr_> the cursor themes aren't working
<attente> racarr_: the animated cursor changes it to a white square that fades in repeatedly
<attente> is it supposed to be like that? or is there some graphic usually?
<racarr_> attente: No thats
<racarr_> the graphic :p
<attente> ah :)
<racarr_> but now we've verified that setting hte cursor works
<racarr_> but loading the themed cursor images doesn't work
<racarr_> attente: Hmm...so...uh...
<attente> where do those images come from usually?
<racarr_> attente: You can file a bug and I can help at some point or
<racarr_> attente: instrument src/server/input/xcursor_loader.cpp to see whats happening
<racarr_> attente: I dunno lets see
<racarr_> attente: 3rd_party/xcursor/xcursor.c
<racarr_> #define XCURSORPATH "~/.icons:/usr/share/icons:/usr/share/pixmaps:~/.cursors:/usr/share/cursors/xorg-x11:"ICONDIR
<racarr_> #define ICONDIR "/usr/X11R6/lib/X11/icons"
<racarr_> also accepted
<racarr_> XCURSOR_PATH env var
<attente> oh. do you think if i install adwaita-icon-theme it might work?
<racarr_> attente: Yeah! Do you not have an icon theme?
<racarr_> You need something in one of those directories
<racarr_> with
<racarr_> a cursor.theme inside
<racarr_> uh
<attente> racarr_: i guess i wouldn't have it under a clean jhbuild
<racarr_> anyway if you have it ina nothe rlocation we can modify things to
<racarr_> look there
<racarr_> ah
<racarr_> interesting
<attente> racarr_: i'll try it and let you know :)
<attente> thanks
<racarr_> Thank you
<racarr_> we should add some logging!
<attente> racarr_: unfortunately no luck :(
<racarr_> attente: I guess if it was in a nonstandard location youw ould need to set
<racarr_> XCURSOR_PATH to the folder containing
<racarr_> the
<racarr_> theme folder
<attente> racarr_: even setting it doesn't seem to work
<racarr_> attente: Hmm...the env variable definitely works for loading non system themes because thats used in a test
<racarr_> not sure whats going on...I guess wed need more logging to tell
<attente> racarr_: do you know what directory the cursors are stored in your machine? can you do a dpkg -S on it to see what package they come from?
<racarr_> attente: I have /usr/share/icons/Adwaita/cursor.theme
<racarr_> from gnome-themes-standard-data
<racarr_> and dmz-cursor-theme /usr/share/icons/DMZ-Black/cursor.theme
<racarr_> + DMZ-White
<attente> racarr_: i'm getting this from strace|grep: http://paste.ubuntu.com/11737387/
<attente> er wait
<attente> i have to do that on the server
#ubuntu-mir 2015-06-19
<RAOF> duflu: I think we have different understandings of âunresponsiveâ :(
<duflu> RAOF: Maybe. But I think without enough consideration there's probably only one meaning that applies to "any client". I also would prefer to not think about code reviews any more on a Friday afternoon :P
<RAOF> Fair enough!
<duflu> -without +with (+with dyslexia)
 * duflu blames the keyboard
<duflu> anpok_: This seems like a non-trivial problem to solve. Do you have any thoughts? https://bugs.launchpad.net/mir/+bug/1439078
<ubot5> Launchpad 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]
<duflu> Must be lunch time..
<alan_g> Any vogons want to stop me TA'ing this? https://code.launchpad.net/~alan-griffiths/mir/prepublish-test-headers-that-depend-on-public-api/+merge/262329
#ubuntu-mir 2016-06-22
<greyback> anpok_: https://code.launchpad.net/~gerboland/qtmir/tests-use-stack-instead-of-heap/+merge/298122 based on your miral comment
<greyback> anpok_: I didn't follow your unique_ptr statements though, where were you referring to?
<anpok_> in one of the test models: ScreensModel .. hmm you do create QApplication and "screensModel"-something? .. I suspect those could just be unique_ptr<..>s and make_unique instead of new ..
#ubuntu-mir 2017-06-21
<alan_g> RAOF: what's happening with the mesa/Mir EGL fix?
<RAOF> alan_g (IRC) : it didn't get released today?
<RAOF> alan_g: if not, could you please check the excuses page (Google Ubuntu excuses should get you to it) and see what's blocking mesa?
<RAOF> Yesterday it was a false-positive in glbinding.
<alan_g> RAOF: still on "excuses", if I parse correctly: "autopkgtest for glbinding/2.1.1-1: ... armhf: Regression"
<RAOF> Ah, yes.
<RAOF> Could you please ping on #ubuntu-release to get that overridden?
<RAOF> apw was looking at it yesterday.
<alan_g> RAOF: ack
