#ubuntu-mir 2013-09-23
<racarr> Morning!
<racarr> greyback|food: I found the crash!
<greyback|food> racarr: yeah!
<greyback|food> have a branch I can try?
<racarr> greyback|food: Yeah, of unity-mir actually, the final solution isn't totally evident
<racarr> juts a sec
<greyback|food> racarr: oh, what have I done wrong?
<racarr> greyback|food: Eh, no not really your fault which is why I say the final solution
<racarr> isn't evident
<greyback|food> ok
<racarr> greyback|food: http://pastebin.ubuntu.com/6145326/
<racarr> basically snapshot crashes if default_surface is null
<greyback|food> oh interesting
<racarr> i.e. the application is open but not surface yet
<racarr> so it could throw an exception
<racarr> or perhaps return an empty image or
<racarr> I dunno
<greyback|food> well I should not be asking for a snapshot if the surface hasn't been created yet
<racarr> the good news is it seems really hard to crash with this applied
<racarr> havent seen any
<greyback|food> cool
<kgunn> racarr: nice
<greyback|food> racarr: wanna propose that change as a MR, and I can review?
<kgunn> alf_: can you propose an mr to bump the so name of the mir server?
<racarr> greyback|food: Ok
<racarr> Morning kgunn :)
<kgunn> mornin
<kgunn> gonna grab toast and coffee....
<racarr> :)
<racarr> Oh also im not really up early :p (re: other channel)
<racarr> im in Pennsylvania
<racarr> greyback|food: https://code.launchpad.net/~robertcarr/unity-mir/check-default-surface-before-snapshot/+merge/187012
<greyback|food> racarr: thanks
<racarr> greyback: What's remaining to flip mir in the image.
<racarr> DPMS landed btw and alexandros is working on galaxy nexus support via sysfs stuff
<racarr> Is it just flicker?
<greyback> racarr: yes, just flicker
<racarr> great
<racarr> greyback: There is a lot of reason to believe that has to do with our HWC module and that upgrading the appropriate bionic side bits
<racarr> will fix it :)
<racarr> kdub is on it last I heard
<greyback> cool
<greyback> would be great if we can flip soon
<racarr> Good afternoon alan :)
<kgunn> alf_: scratch my last ping
<racarr> My focus-tell-dont-ask branch is generating the strangest test failures. ApplicationMEdiatorReport session_create_surface and surface_create_buffer failing with broken pipe
<racarr> looks like it's exposing something weird...
<kgunn> didrocks: for libmirclient ffe https://bugs.launchpad.net/ubuntu/+source/mir/+bug/1229212
<ubot5> Ubuntu bug 1229212 in mir (Ubuntu) "[FFe] mir api bump post sprint for libmirclient" [Undecided,New]
<didrocks> kgunn: you should add that it doesn't have any impact on the default ubuntu experience and the risk of regression is low
<didrocks> kgunn: also, as per wiki page, you need to subscribe the release team
<kgunn> didrocks: ack
<didrocks> kgunn: then, let's join #ubuntu-release and get people looking at it ;)
<didrocks> (please ping me once there)
<smartboyhw> No symbols? Ow........
<racarr> ...my laptop power cord is failing me so it seems like I am goign to dissapear for a while soon
<racarr> while I reinstall on an old macbook I have in the closet
<racarr> its depressing to watch your laptop battery go down and know there is nothing you can do about it
<racarr> greyback_: kgunn: I guess we need resizing for october? (phone rotation)
<racarr> so thinking of switching full steam to that?
<kgunn> racarr: greyback_ actually...cleaning up (controlling) the api for server should come first
<kgunn> at least something better than we have atm
<kgunn> i thnk resize is actually something we can use post V1....but i'll defer to greyback_
<racarr> kgunn: It's needed for rotation
<racarr> because of the panel
<racarr> or maybe we could use a hack in qtubuntu with artificially inflated surface sizes to work around it in the interim
<kgunn> greyback_ racarr ....panel didn't rotate before (not arguing its not needed...), so was assuming parity ok
<kgunn> lemme check
<greyback_> kgunn: panel does not rotate right now.
<racarr> kgunn: Well, parity is ok for landing right, but not ok for october final?
<kgunn> racarr: i believe its ok for oct...but lemme check
<racarr> Ok
<racarr> I can start working on stabilizzing the server APIs too
<racarr> I have some ideas for reducing the width of the interface between unity-mir and mir
<racarr> or rather, the number of interfaces used
<racarr> but I'm not sure  I have a full picture solution
<racarr> ok laptop is about to kill itself. if all goes well should be back in an hour or two. Can reach me on
<racarr> google talk via phone in the mean time
<kdub> hello folks
<kgunn> greyback_: can you change the build dep for unity-mir
<kgunn> ricmm: can you change it for platform-api ?
<greyback_> kgunn: can do.
<kgunn> thanks...didrocks is gonna try to land mir
<kgunn> latest
<didrocks> don't forget u-s-c
<kgunn> didrocks: sorry if i am slow...but why are we making this change ?
<kgunn> https://code.launchpad.net/~didrocks/mir/remove-hack/+merge/187029
<didrocks> kgunn: because we don't force reverse depdencies anymore to use the exact mir version they were built against
<kgunn> didrocks: ah...backward compat
<didrocks> yeah ;)
<greyback_> kgunn: it's just a client api bump?
<kgunn> greyback_: ricmm both client & server
<kdub> ricmm, rsalveti how easy (or difficult) would it be to try a cm-10.2 based phablet build?
<kgunn> alf_ racarr kdub read your mail....let me know if you think we should just ressurect the integration branch ?
<kgunn> is alan_g having connectivity issues ?
<ricmm> kgunn: didrocks what exact versions should we start depping on in unity-mir and platform-api?
<ricmm> for the new process, wahts the first dep to dep on
<didrocks> ricmm: 0.0.11 seems to be the version they will bump Mir to
<mterry> kgunn, hi
<kgunn> didrocks: i thot you said since it bumped once
<kgunn> that we shouldn't bump again
<kgunn> or do you want us to ?
<didrocks> kgunn: there are 2 bumps
<didrocks> the packaging ABI name bump -> not needed to change (in debian/control)
<didrocks> the upstream version bump (the version you are releasing), you need to bump it to 0.0.11 in debian/changelog
<ricmm> greyback_: ^ we need to dep client/server on .11 then
<ricmm> so that we benefit of a rebuild
<kgunn> kdub: moving here...do you think its worthwhile to chase a workaround of forced second layer for a bit ?
<kgunn> i'm not sure the feasibility of cm10.2 attempt
<kgunn> didrocks: you gonna be on for a few more ?
<didrocks> kgunn: ~30 minutes, I doubt Mir will have the time to finish building by then (even if we start now)
<didrocks> kgunn: just push everything, I'll staged to proposed an have RAOF tomorrow morning doing the final xmir uploads
<didrocks> sounds right?
<kdub> kgunn, unsure. i don't understand how that forces anything to be right though
<kdub> so it might just be shuffling the problem around
<RAOF> didrocks: I'm at XDC at the moment; I can do uploads, but not necessarily when you want them :)
<didrocks> RAOF: can you just email me a link with the 3 xmir packages source I need to upload then?
<didrocks> I'll do that for you in that case
<RAOF> didrocks: Sure
<didrocks> RAOF: thanks! I'll upload that my tomorrow morning then
<didrocks> kgunn: ^
<kgunn> cool
<RAOF> didrocks: Oh, it's already in the experimental-prevalidation PPA. Are you not going to be copying that over?
<greyback_> didrocks: kgunn: unity-mir version bump branch https://code.launchpad.net/~gerboland/unity-mir/bump-mirclient-to-3/+merge/187071
<didrocks> RAOF: we can't copy from that, just send me the link of the name of the source then, I'll just resign and uploda then
<didrocks> RAOF: I prefer to have an email with the name to ensure we don't forget anything ;)
<RAOF> didrocks: Ok. I'll do that over lunch.
<didrocks> greyback_: approved (not top approved yet, see the comment)
<didrocks> RAOF: thanks!
<greyback_> didrocks: ack
<kgunn> didrocks: greyback_ ricmm mterry ... please do so https://code.launchpad.net/~kgunn72/mir/changlog-update-0.0.11-for-mirserver/+merge/187070
<didrocks> kgunn: commented
<didrocks> https://code.launchpad.net/~kgunn72/mir/changlog-update-0.0.11-for-mirserver/+merge/187070/comments/426686
<kgunn> didrocks: ack all that...but for server, i thot ffe was for touch ? hence blanket...only client has ffe right ?
<mterry> ah, that'll teach me
<didrocks> kgunn: oh, it's just to list it, so that we don't get any issue with the release team :)
<kgunn> didrocks: ok...will include
<didrocks> thx
<kgunn> didrocks: but going fwd...if we break server again....then what ?
<didrocks> kgunn: no need to list a bug
<didrocks> kgunn: but otherwise, same procedure
<kgunn> cool
<didrocks> mterry: I feel sad that you approved :p
<didrocks> mterry: I can do now 5 NEW without looking at the copyright file, relying on you catching up during the MIR ;)
<didrocks> that will be your punishment!
<mterry> didrocks, Now I feel sad too
<didrocks> ahah
<kgunn> didrocks: ok...think its right now...
<kgunn> greyback_: thanks for the list of headers
<didrocks> kgunn: the syntax is (LP: #1229212), not (LP#1229212)
<ubot5> Launchpad bug 1229212 in mir (Ubuntu) "[FFe] mir api bump post sprint for libmirclient" [Undecided,In progress] https://launchpad.net/bugs/1229212
<kgunn> didrocks: ok...one more time
<didrocks> kgunn: otherwise, almost good (well, you have -0ubuntu1, but daily release will strip and fix that anyway)
<kgunn> didrocks: ok...just the : and that's it?
<didrocks> kgunn: : + space
<kgunn> didrocks: ok...for real for real...it should be done :)
 * didrocks checking :)
<didrocks> kgunn: globally approved ;)
<kgunn> racarr: you still around or flying ?
<kgunn> greyback_: so weird...i must have had a bug in my bash...those were there....just moved them, it now seems to work
 * kgunn so lucky
<didrocks> kgunn: I didn't point them out on purpose, not that important (you will remain with "kg" as the signer)
<kgunn> greyback_: ok...lucky me has updated again
<greyback_> kgunn: did you push?
<kgunn> greyback_: yes but just...
<greyback_> kgunn: ok, approving here
<kgunn> kdub: back to the forcing 2nd overlay...i thot you were thinking it'd force diff code paths? or...maybe that  wasn't your idea & someone else was puting it fwd ?
<kgunn> kdub: looking at the code, only thing i saw was an extra invalidate
<kdub> kgunn, i've patched around the obvious problem with the code path, which didn't make much difference
<kgunn> kdub: so, atm we're back to needing to try CM 10.2
<kdub> kgunn, well, at the moment, i'm trying to compile the kernel so I can dig right down to the hardware and figure out what's going on
<kgunn> kdub: need help? or are you able to build & boot ?
<kdub> the kernel guys were helpful in pointing me to how to build, now its just a matter of me getting my chroot in order
<rf9020> ps aux | grep unity-system-compositor
<rf9020> patricia  2833  0.0  0.0   4464   808 pts/0    S+   21:12   0:00 grep --color=auto unity-system-compositor  what is it ?
<ogra_> the process entry for the grep you are running
<ogra_> ps aux | grep unity-system-compositor | grep -v grep
<ogra_> that suppresses finding yourself while searching for something
<rf9020> my problem on xorg kernel 3.11.0.8 reso 800x600 with nvidia 319.32 monitor 24" , mir ok if driver no proprietaire , , if driver Nouveaux screen blank !!
<rf9020> how to have 1920x1200
<racarr> Return of working computer!
<racarr> kgunn: I am still around. I am flying on wednesday
<racarr> I was briefly out due to a failure of my laptop power cable
<rf9020> what video card supports 100% mir
<racarr> is amd64 ci still
<racarr> problematic
<racarr> it seems to be :(
<RAOF> rf9020: Your choice of non-ancient intel, nouveau, radeon.
<rf9020> ?? radeon ok and nvidia ??
<racarr> nvidia is ok as long as the nouveau supports the card
<rf9020> i have  8500 gt nvidia
<racarr> http://nouveau.freedesktop.org/wiki/FeatureMatrix/
<rf9020> nouveau with 8500 gt screen blank with cross
<rf9020> no click right , no terminal , but ctrl+alt f1 ok
<RAOF> Oooh, sweet! There's a new new DRI2Authenticate mechanism that'll let us async that bastartd.
<kgunn> racarr: hey, was just checking on what you decided to attack - my preference is api :)...basically, pat sent a mail saying all ui changes should be deferred anyway...
<kgunn> almost viewing it as risk now
<racarr> kgunn: API it is :)
<racarr> that and trying to get anything to pass jenkins
<kgunn> racarr: no doubt on making jenkins happy....jenkins is so fickle
<racarr> [  FAILED  ] DisplayConfigurationTest.display_change_request_for_unauthorized_client_fails (103032 ms)
<racarr> fhqwfqwhfqwf
<ricmm> kdub: kgunn can we talk here
<ricmm> the other channel is noisy
<ricmm> kdub: can you explain more about what was failing?
<ricmm> we know SF does the 2 layer rendering with the same kernel you are trying
<ricmm> and same HWC
<kdub> ricmm, but i'm not convinced they don't have rendering glitches either
<ricmm> just use the phone with surface flinger then
<kdub> ricmm, i haven't gotten the "hwc's force-2 layers" to work
<ricmm> you wont see the issues
<ricmm> they might still have other issues, but its not the same issue for sure
<ricmm> vsync fencing is happening the right way
<kdub> i won't see the flashing in the same way, i do see problems though
<ricmm> and im not talking android, im talking the default image with SF + unity8
<ricmm> what problems?
<ricmm> well I mean but the difference is majestic
<ricmm> its clearly obvious that something is failing with the Mir one
<ricmm> thats triggering this
<ricmm> the 2-layer rendering being the most obvious cause for the missed fencing on vsync
<kdub> but the problems i see with surfaceflinger are similar to vsync timing issues
<ricmm> porting to 10.2 is not really an option in our current timeframe
<kdub> right
<ricmm> what I want is exactly what surface flinger does to circumvent the problem, in our code
<ricmm> at least as a PoC or a hack until we can move forward with 10.2
<ricmm> as it wont happen before 13.10
<kdub> right, i'm trying to patch what we have for that
<kdub> and, i haven't been able to prove that surfaceflinger is doing the right thing either
<kdub> so i'm currently in the process of trying to patch things
<kdub> preferably hwc
<ricmm> I understand, what I'm saying is that even if SF is also having vsync issues... they are not as apparent to the naked eye as the Mir issue
<ricmm> so you cant put them on the same plane
<ricmm> as the SF flinger one can be considered "flawless" as we've been shipping it for a while, even if there are underlying hwc issues
<ricmm> they clearly dont generate the same outcome as the current tearing with Mir
<ricmm> so, I'd say please keep trying to patch/hack to do what SF is doing re: 2lyr rendering
<ricmm> until we can trigger the right fencing
<ricmm> because it feels like you are right on the money with the missed syncs analysis, we just havent been able to get the hack to work to prove it
<kdub> i can still pursue, i'm just worried that chasing the hack won't be sufficient
<kgunn> kdub: maybe we can enlist duflu here
<ricmm> kdub: unless another better option comes along...
<ricmm> and they pretty much can only come from you as you are the one who knows the issue at hand
<ricmm> 10.2 is not a realistic option for shipping
<kdub> sure, understand that
<kgunn> ricmm: sorry...got distracted, i still think if we could gen up a CM10.2 not for releasing but just to test...it would be very very useful
<kgunn> ricmm: just confirming that we could get some love from rsalveti to give it a shot at least
<kdub> i'll try to stabilize the 2 layer hwc hack i have right now
<ricmm> kgunn: it might not even be possible to get that love
<ricmm> as both salveti and I are buried with stuff
<kgunn> ricmm: is flicker not important ? :)
<ricmm> yes, but I prefer if it can be sorted internally in Mir
<ricmm> as, if SF can do it, Mir can do it
<ricmm> thats our motto after all ;)
<kgunn> ricmm: yeah...but i thot we were cool to get some help fom rsalveti ? ...no ?
<olli> kgunn, isn't that an asac q?
<kgunn> ricmm: i don't even know how much work i'm asking for....can you give a swag ?
<kgunn> olli: yeah..i suppose so
<kgunn> ricmm: it doesn't have to be rsalveti if someone else knows how
<ricmm> guys, if the hack works for SF it will work for us
<ricmm> its just not complete yet
<ricmm> lets not sign off on a huge task as testing 10.2 can be
<kdub> the way sf and mir composition is triggered is a bit different... i guess right now, the first focus is testing the hack and seeing if it does help the flicker
<ricmm> kdub: lets exhaust that route as I asked on friday first
<ricmm> and then we'll see what we can do if all that fails
<ricmm> rsalveti isnt back until tomorrow and he is the one who can tell you how much work it will be to test 10.2
<kgunn> ricmm: thanks...
<ricmm> but I can assure you than more things will be broken, and that we dont have the manpower to get it in place for 13.10
<ricmm> so it is not really a viable solution
<ricmm> therefore whatever cycles we spend there, will be wasted time
<kdub> yeah, it seems like it might be a lot of code to move
<kgunn> but what if that is the right answer?
<ChickenCutlass> kgunn, getting 10.2 up and running is really a big task.
<ricmm> it is not, and that is proven
<kgunn> rock/hardplace
<ricmm> how? because I dont see the same degree of flickering in SF
<ricmm> so, that is not really the only solution
<ricmm> we need to contain the fix in the least amount of code
<ricmm> and that is either Mir or hwcomposer itself
<ricmm> but not moving the whole base to 10.2, that will break some serious havoc :)
<kgunn> or FB
<ricmm> or fb yes
<kgunn> i'm not asking for CM10.2 to be released
<kgunn> and i got the message
<kgunn> its too big for you to attempt
<kgunn> so new requirement is "flicker less than or equal to SF"
<kgunn> ..not no flicker
<ricmm> the req is feature/performance parity with SF
<ricmm> if we get that, we ship Mir
<ricmm> and as not shipping Mir isnt an option, we will get that for sure ;)
<kgunn> ricmm: i used to do phablet-dev-bootstrap but...did it and couldn't build...did it change to phablet-devenv-bootstrap
<ChickenCutlass> kgunn, phablet-dev is still the way
<kgunn> ChickenCutlass: great...its just me
<kgunn> racarr: any thots on the amd ci test ?
<kgunn> racarr: i think francis is going to try to build/ci on a dedicated/non-shared host to see if that helps
<ice9> what is the benefit of Mir over Wayland?
#ubuntu-mir 2013-09-24
<kgunn> kdub: thanks for that update
<kdub> kgunn, sure, will send at least one a day
<rsalveti> ricmm: kgunn: I can easily give that a try tomorrow
<rsalveti> I remember I did this once already when we had the black screen issue (using the kernel from 10.2 and such)
<kgunn> kdub: ^
<rsalveti> will do this first thing tomorrow :-)
<rsalveti> just got back after driving for quite a few hours, food and bed :-)
<kdub> ah great :) thanks rsalveti
<racarr> MORNING
<kgunn_> racarr, mornin'
<alan_g> racarr: afternoon
<didrocks> RAOF: around?
<didrocks> RAOF: you only send me the xserver pacakge
<didrocks> not the list of other package
<didrocks> does it mean we only need to rebuild xserver?
<didrocks> not the rest?
<RAOF> didrocks: Oh. That's the only package that *I* need rebuilt.
<didrocks> RAOF: the other doesn't dep on libmirclient2?
<RAOF> No ABI changes for the drivers
<RAOF> didrocks: No. The drivers depend only on the xmir module, which shelters them from mirclient ABI breaks.
<didrocks> ah nice ;)
<didrocks> excellent
<didrocks> ok, I need to upload it in the ppa first
<didrocks> RAOF: thanks
<didrocks> kgunn_: do you know if RAOF will be back?
<didrocks> kgunn_: xserver failed to build: https://launchpadlibrarian.net/151345408/buildlog_ubuntu-saucy-armhf.xorg-server_2%3A1.14.2.901-2ubuntu5_FAILEDTOBUILD.txt.gz
<didrocks> (so everything's blocked in the ppa, unity8 and all dependencies)
<didrocks> (it passed on amd64 and i386)
<kgunn_> didrocks, he is at XDC which is portland OR i believe
<didrocks> kgunn_: anyone else to help debugging what's wrong?
<kgunn_> didrocks, in theory x should work on arm, can we make an exception to expidite mir update for touch....
<didrocks> kgunn_: what do you mean by exception?
<kgunn_> mlankhorst, ^ could you possibly help with building x for arm ?
<didrocks> kgunn_: putting Mir in the release pocket isn't possible, it won't migrate because we can't keep libmirclient2 and libmirclient3 coinstallable
<didrocks> (due to the common dependency)
<didrocks> and we can't release libmirclient3 because of this issue
<mlankhorst> kgunn_: seems like a libunwind bug or a compiler bug
<mlankhorst> oh it's in the compiler :P
<didrocks> nice ;)
<didrocks> mlankhorst: why the compiler? because the "__aeabi_unwind_cpp_pr0" is there?
<mlankhorst> might be it needs to link with g++, not gcc
<mlankhorst> oh lets see
<lool> it could be a link script issue
<mlankhorst> libunwind should not have undefined references by itself, though...
<RAOF> Yay armhf craziness!
<didrocks> yeah, it's weird
<didrocks> oh, a RAOF ;)
<didrocks> RAOF: https://launchpadlibrarian.net/151345408/buildlog_ubuntu-saucy-armhf.xorg-server_2%3A1.14.2.901-2ubuntu5_FAILEDTOBUILD.txt.gz for context
<RAOF> didrocks: Yeah, just saw my email.
<mlankhorst> any recent libunwind upload I can blame that one on? :P
<RAOF> Yeah, what have we changed?
<RAOF> Because that bit's *not* changed since 0ubuntu4, which built.
<mlankhorst> actually there is..
<didrocks> https://launchpad.net/ubuntu/saucy/+source/libunwind/1.1-2ubuntu3
<mlankhorst>   * d/patches/fix-lzma-linking.patch: Include lzma when linking arm, arm64
<mlankhorst>     and ppc32 libunwind, fixing FTBFS.
<didrocks> https://launchpad.net/ubuntu/saucy/+source/libunwind/1.1-2ubuntu2
<didrocks> yeah
<didrocks> those 2
<RAOF> And by âfixup pkg-config configurationâ we might mean âbreak Xâ :)
<kgunn_> :)
<mlankhorst> https://launchpad.net/ubuntu/+source/libunwind/+publishinghistory
<didrocks> - libunwind_la_LIBADD += -llzma
<didrocks> and then +Libs.private: @LIBLZMA@
<didrocks> I don't see how this interferes with what we are seeing?
<mlankhorst> no it doesn't, but there has been another pload
<mlankhorst> upload*
<RAOF> Also added --enable-minidebuginfo to the configure flags.
<mlankhorst> worst case I guess the act of rebuilding triggered it :P
<lool> --enable-minidebuginfo is pretty suspicious indeed
<lool> came in latest merge from Debian in 1.1-2ubuntu1
<didrocks> mlankhorst: RAOF: kgunn_: do you have any idea on this? quite lost TBH
<RAOF> Is anyone trying a rebuild with a previous libunwind?
<mlankhorst> didrocks: I wouldn't be surprised if it simply happened because of toolchain changes. :P meh I have no builder atm
<didrocks> RAOF: I don't think anyone is trying that
<kgunn> RAOF: are you thinking rollback on toolchain is required ?
<RAOF> kgunn: I'm just wondering if that's the problem. If it is then either rollback or fix is the way forward.
<kgunn> ah...just a test
 * RAOF sees whether xorg-server will build under qemu
<RAOF> Someone should write a parallel automake, so I could at least get 4 slow armhf-emulated processes rather than one. :)
<didrocks> :)
<lool> so I've rebuilt xorg-server on my nexus4
<lool> reproduced the failure
<lool> then I downgraded libunwind and tried to continue the build, and it seems to have past the point where it was failing
<lool> I downgraded to libunwind8 + -dev in version 1.1-1ubuntu2
<lool> RAOF: ^
<lool> did someone ping doko / James?
<RAOF> lool: My build against 1.1-1ubuntu2 looks to be completing in sbuild, too. I don't think anyone's pung doko or James.
<RAOF> Yup, X seems to have got all the way through to the test suite.
<lool> it's not done here, but it keeps going
<lool> RAOF: let's move this to ubuntu-devel@
<lool> err #ubuntu-devel
<davmor2> RAOF: if you have all this speed up through parallel builds when do you get time to practise you sword fighting http://xkcd.com/303/
<roman2861> Hello. Anybody here?
<alan_g> Only us
<RAOF> And the fish god.
<roman2861> :D
<roman2861> So, i have a problem - Mir doesn't works on manta (Nexus 10). Will somebody fix it? And may I dream about Mir on Nexus 10 in near future? Or only after 1.0 release?
<kgunn> roman2861: so i know there's a branch up for it...https://code.launchpad.net/~kdub/mir/mali-client-render-support/+merge/185603
<kgunn> not sure it works completely...but...works-ish
<alan_g> kgunn: should that be linked to bug 1203268?
<ubot5> bug 1203268 in Mir "Mir does not work on Nexus 10" [Low,Triaged] https://launchpad.net/bugs/1203268
<roman2861> ubot5: Yes, I'm am Zonov Roman, who created this bug. But bug is 2 month old. And i really want to see Mir on my Nexus 10 :)
<ubot5> roman2861: I am only a bot, please don't think I'm intelligent :)
<kdub> roman2861, give it... 3 or so weeks, i'm close to getting it working
<kdub> give or take ;-)
<roman2861> Thank you! Your info is great!
<dholbach> hiya
<dholbach> on a galaxy nexus, the power button to lock the screen does not work with mir any more... is that a known issue?
<RAOF> Yeah.
<dholbach> do we have a bug open for it?
<dholbach> is that the same on all devices?
<RAOF> Works on N4, although maybe not on the images.
<RAOF> That's DPMS support.
<dholbach> gotcha
<RAOF> Someone was working on it, but I don't think it's being considered a blocker.
<racarr> Yep. I hear kdub is working on it in the process of updating our HWC bits
<racarr> hopefully once that is finished it should work with no more mir changes.
<kdub> racarr, yeah... hwc might need some more patches though
<kdub> for the galaxynexus
<racarr> Mm.
<dholbach> 1193222 I think
<racarr> Yes. The bug status is a little out of date I guess
<racarr> it's fixed on N4, but the API we use from the drivers isn't working on gnexus
<ogra_> did someone tell ricmm ? i think he is still working on a powerd fix for this
<racarr> ogra_: Yeah we are in sync, the deal is
<ogra_> awesome
<racarr> mir has to be the one to actually turn the screen off due to some...intricacies of the android APIs. so unity will publish a dbus api
<racarr> for powerd
<racarr> Which is just about to land here: https://code.launchpad.net/~gerboland/unity-mir/add-screen-blank/+merge/187028
<ogra_> yeah
<racarr> afk, 20 minutes or so
<RAOF> didrocks: Ba baw!
<davmor2> kgunn: Next app that is playing up.  http://paste.ubuntu.com/6151221
<davmor2> kgunn: again is this just general changes or an xmir issue?
<RAOF> *Probably* not an xmir issue.
<RAOF> Although it's particularly easy to tell from that.
<davmor2> RAOF: ah so is it best to point these at you?  It'll just be little snippets like this that I can gleam from the terminal start of the app
<RAOF> davmor2: You're welcome to filter them through kgunn, but it'll probably filter down to me anyway :)
<RAOF> davmor2: Does that work without xmir?
<davmor2> RAOF: I'm going to go back over any that didn't work due to gfx issues latter on without xmir and then again on nvidia ruling out the intel driver and xmir but that won't be till I've hit the other 880+ apps
<RAOF> davmor2: Ok.
<davmor2> RAOF: too much time taken with all the reboots,  I don't think I'm going to get everything done as it is and I started a fortnight earlier :/
<RAOF> !!!
<davmor2> RAOF: Migration testing of the 960 commercial applications from raring to Saucy.  Quantal to raring took nearly 4 weeks for 600 apps and I didn't have to stay on top of the current queue at that time, this time I have it's not going to plan :D
<kgunn> kdub: you gotta branch for me to try ? n4 flicker
<kdub> kgunn, just getting the tests in order atm
<racarr> 20 minutes...wasn't true :p
<racarr> back now though
<racarr>  ill get my n4 ready for testing too :)
<robert_ancell> kgunn, I'm completely confused by what https://code.launchpad.net/~kgunn72/mir/changlog-update-0.0.11-for-mirserver/+merge/187070 is trying to do...
<rsalveti> kdub: were you able to solve the flicker issue?
<rsalveti> was just waiting the kernel + cm build with the other display stack here
<kgunn> robert_ancell: well, basically it was to bump the so name & in turn the build deps from
<kgunn> u-s-c, unity-mir, & platform-apu
<kgunn> or api even
<robert_ancell> kgunn the packaging has gone from 0.0.10 to 0.0.11 and Mir is still on 0.0.10 (see CMakeLists.txt)
<robert_ancell> and no sonames were changed
<kgunn> robert_ancell: so much for didrocks guiding me through it :)
<kgunn> robert_ancell: so, they landed mir today with no issue...but i guess that's cause they forced a build
<robert_ancell> kgunn, yeah, I'm mostly confused by all the people approving it who should know what this change means!
<kgunn> robert_ancell: so for future reference...i would need to make a corresponding change to cmake....anything else?
<kdub> rsalveti, was able to solve! have a mir branch, and patches for cm-10.1 n4 hwcomposer
<kgunn> robert_ancell: hmmm, so interesting question...if unity-mir, usc, plat-api are all expecting .11...is it because they use >=
<kgunn> kdub: what!?!?
<robert_ancell> kgunn, I think the idea is so a dependent package can depend on mir (>= 0.0.11) right?
<ChickenCutlass> kdub, that is great news
<rsalveti> kdub: what was the issue then?
<kgunn> did you and rsalveti end up with simultaneous soln's
<robert_ancell> kgunn in that case, update "set(MIR_VERSION_PATCH 10)" in CMakeLists.txt and the debian/changelog
<kgunn> robert_ancell: right...but i am saying they (usc, unity-mir) expect version 11 from their control file...
<kgunn> robert_ancell: therefore they are using a >= scheme
<kgunn> robert_ancell: and this is why 0.0.10 actualy works for them ??
<robert_ancell> kgunn, right, but if you asked any code inside Mir what version it was, it would say 0.0.10 (in this case I don't think there's anything that would break)
<kgunn> (its really a question not a statement :)
<kdub> rsalveti, 1) we were relying on the vsync 'heartbeat signal' instead of having hwc's set arrange the sync
<kdub> so that's what the hwc patch is for
<kgunn> robert_ancell: ok...so, question is, do we need to correct the cmake file and can we do so without issue ?
<robert_ancell> kgunn, this is a side effect of having the version number defined in two places - once in the build system and once in the debian packaging
<kdub> and the 2) the shell is an 'internal client' and takes a bit of a different path than the ipc based clients. we were missing waiting on a fence for the internal clients only
<kgunn> robert_ancell: or...do we just wait for the next bump
<robert_ancell> kgunn, we *should*, but in practise we can probably just live with it for now
<kdub> and thats what the mir branch is for
<rsalveti> kdub: right, cool, let me know once you have the cm related patches in hands
<rsalveti> so I can upload a new android package
<kdub> rsalveti, i'll send them after i double check they work okay with surfaceflinger... no reason they shouldn't but safer to double check
<rsalveti> kdub: if you send me know I can do a local build and test
<rsalveti> with sf
<rsalveti> *now
<kdub> rsalveti, sure
<kdub> rsalveti, sent an email with the patch
<rsalveti> thanks, let me try that
<olli_> this is exciting news gentlemen!
<rsalveti> kdub: working just fine
<kdub> rsalveti, great!
<kdub> i kinda want to coordinate that patch going into the phablet build at about the same time as https://code.launchpad.net/~kdub/mir/fix-1215979/+merge/187346
<kdub> would minimize disruption to the mir devs working on the n4
<kdub> not aware of a way to check against a phablet build version when packaging mir
<rsalveti> well, you can dep/build-dep against the android version
<rsalveti> there's a package for it now
<rsalveti> kdub: there's a conflict in https://code.launchpad.net/~kdub/mir/fix-1215979/+merge/187346
<kdub> fixing... a minute or two
<kgunn> hey racarr ...in https://blueprints.launchpad.net/ubuntu/+spec/client-1303-mir-phone, there are like 3 stage items...are those all just enabling side stage
<rsalveti> kdub: seems your mr works fine in here
<rsalveti> just got a unity8 crash, but that is not related
<rsalveti> not with this change at least
<kdub> yeah, the unity8 crash is something else... racarr, know anything about that?
<kdub> (i know some races were fixed last week, might be what we're seeing)
<kdub> just noticed there's a 'review type' field now in lp... handy
#ubuntu-mir 2013-09-25
<robotfuel> x is locking up when using xmir tonight, I was able to grab this right before the machine started a new test http://pastebin.ubuntu.com/6152767/
<robotfuel> I'll have a better bug in about an hour
<robotfuel> robert_ancell: ping
<robert_ancell> robotfuel, hey
<robotfuel> robert_ancell: xrandr doesn't say xmir is running when but I see /tmp/mir_socket did that change?
<robert_ancell> robotfuel, can you confirm /tmp/mir_socket is owned by u-s-c? Or has this test completed
<robert_ancell> robotfuel, /tmp/mir_socket indicates some Mir server is running, which is probably u-s-c
<robotfuel> srwxr-xr-x  1 root    root       0 Sep 25 02:21 mir_socket
<robert_ancell> robotfuel, run fuser on it
<robotfuel> robert_ancell: fuser /tmp/mir_socket returns nothing
<robert_ancell> robotfuel, that implies that file is left over from something
<robert_ancell> robotfuel, you are checking for that existence of that file to confirm u-s-c is running?
<robotfuel> root      1035  1.0  1.0 906132 41188 tty7     Ssl+ 02:21   0:18 /usr/sbin/unity-system-compositor --from-dm-fd 10 --to-dm-fd 13 --vt 7
<robotfuel> robert_ancell: shows it's running
<robotfuel> robert_ancell: /var/log/Xorg.0.log shows mir stuff in it.
<robotfuel> robert_ancell: it's at 10.97.2.151 if you want to log in
<robert_ancell> robotfuel, hang on, I'll just restart to confirm the /tmp/mir_socket behaviour
<robert_ancell> robotfuel, aha, you have to sudo fuser /tmp/mir_socket since it's root owned
<robert_ancell> kind of expected fuser to consider that an error
<robert_ancell> robotfuel, right, xrandr outputs now match their old names, so you can't tell if you're running Mir using xrandr
<robotfuel> robert_ancell: doh! yes it's being used by u-s-c
<robert_ancell> RAOF, there's no X call you know of that can give you information about the driver in use is there?
<robotfuel> robert_ancell: ok I'll use mir_socket and fuser to make sure the process id's match instead of xrandr
<RAOF> robert_ancell: You can call into DRI2 to get the name of the DRI module to load?
<RAOF> robert_ancell: But that's likely not what you want ;)
<robert_ancell> RAOF, I was kind of hoping there was some sort of convenient vendor string that an X call returned, but I don't remember anything like that
<RAOF> Nope, no dice.
<robotfuel> I need to get some sleep thanks robert_ancell and RAOF
<robert_ancell> racarr, kdub, hikiko, alf_, kgunn_, meeting
<robert_ancell> looks like just me and alf_ here, and his microphone/camera is broken :)
<hikiko> still trying to join...
<robert_ancell> bye all
<hikiko> bye robert_ancell
<robert_ancell> didrocks, hey, I noticed the daily releaser did a nice clean up of the changelog. It's nice having guaranteed sane changelogs now :)
<didrocks> robert_ancell: oh, daily-release does that from day one FYI ;)
<didrocks> robert_ancell: I had to iterate 3 times with Kevin to have the diff you saw already
<robert_ancell> didrocks, I wasn't sure if the project version would confuse anything - but if you also can't think of anything I'll update it for consistency
<didrocks> so knowing the rest would be cleaned up automatically, I didn't fight more ;)
<didrocks> robert_ancell: yeah, just update for consistency, from what I know, it's not picked up by anything
<didrocks> so in case you didn't notice, Mir is in the release pocket ;)
<didrocks> (had to bribe some release team member to accept the new xorg-server despite the beta freeze)
<robert_ancell> didrocks, nice :)
<robert_ancell> didrocks, the only place the version is used appears to be the .pc files
<didrocks> yeah, and has the deps weren't forced, we should be fine
<dandrader> alf_, so commits flow from development_branch (where the real action happens) to trunk (stable branch)?
<alf_> dandrader: That's the plan for now. It's not a blocker for branches that don't break the ABI, but keeping merges going in one direction only simplifies the process.
<alf_> dandrader: (i.e. no need to merge from trunk back into devel)
<dandrader> alf_, kdub, racarr  ok I have resubmitted to the development branch. But now I need you guys to reapprove it, please :)
<alf_> dandrader: np, I will reapprove and top-approve when CI is done.
<dandrader> alf_, thanks!
<alan_g> alf_: I suspect there's no auto-landing job for development-branch (i.e. we have to do the merges ourselves)
<alf_> alan_g: hmm, I remember Thomi saying that he could arrange that?
<alan_g> alf_: looks as though I was wrong.
<alan_g> How do I suppress this: /tmp/buildd/mir-0.0.11+13.10.20130904/examples/basic_server.cpp:49:83: error: ignoring return value of 'int system(const char*)', declared with attribute warn_unused_result [-Werror=unused-result]
<alan_g>              (void)system((the_options()->get(launch_child_opt, "") + "&").c_str());
<alan_g> Surely casting the result to void isn't ignoring it
<alf_> alan_g: In the past I have used an "if (bla()) {}" construct to work around this (in test code), but I guess in this case you might as well do something more useful with the return value.
<alan_g> alf_: I've tidied up https://code.launchpad.net/~alan-griffiths/mir/socket-connection/+merge/187326 if you want to take another look
<alf_> alan_g: will do
<kgunn> oh bravo alan_g..... Thumping Termite
<kgunn> thomi: ^
<davmor2> kgunn: Teenage-mutant-ninja Turtles is the obvious choice
<kgunn> davmor2: dang it...how did we miss that one
<alan_g> kgunn: that wasn't intended for publication
<kgunn> :))
<alan_g> kgunn: are you trying to change the Mir culture of only top-approving when discussion is over? (c.f. https://code.launchpad.net/~alan-griffiths/mir/socket-connection/+merge/187326/comments/427682)
<kgunn> alan_g: sorry...i missed that
<kgunn> thanks
<kgunn> back to needs review
<alan_g> kgunn: yw. Just wanted to be sure it was intentional
<alan_g> kgunn: and thanks for getting the ci set up for development-branch. Nice
<kgunn> alan_g: i know....much better...thank francis :)
<kdub> good morning
<alan_g> kdub: kgunn hangout?
<kdub> sure
<kgunn> coming
<hikiko> bye
<alan_g|EOD> kdub: happy reviewing! (https://code.launchpad.net/~alan-griffiths/mir/socket-connection/+merge/187326/comments/427682)
<kdub> alan_g|EOD, could you switch lp:~kdub/mir/fix-1215979 to approve/abstain before you go?
<kdub> alan_g|EOD, will review that today
<kgunn> kdub: so, do we need to wait for alf_ ? on https://code.launchpad.net/~kdub/mir/fix-1215979/+merge/187346
<kgunn> or is ready for ta
<kdub> kgunn, comment should be addressed, so it should be okay
<kgunn> kdub: ok...i'd like to get it landed tomorrow...only way that happens is to TA right now
<kgunn> i'll be doing that now
<kdub> kgunn, okay
<kdub> kgunn, we'll might get some complaints from the n4 users about worse stuttering if the users have mixed and matched the phablet build and the mir build
<kdub> perhaps i should send out a wider email to mir/unity8 folks working on the n4
<kgunn> kdub: understand....this just gets it merged onto our dev
<kgunn> that's probably a good idea...
<kgunn> kdub: does rsalveti already have matching mp's on FB/hwc side ?
<kgunn> or ?
<kgunn> maybe you put some mp's up?
<kdub> according to email, should be in the next image
<rsalveti> kdub: kgunn: it's already in today's image
<kgunn> hey hey...even better
 * kgunn wonders how rsalveti lands stuff so fast
<rsalveti> :-)
<kgunn> kdub: do you still have a GalaxyNexus?
<kdub> yep
<kgunn> curious if you think with mir if its usable as a dev device (i know the perf aint great)
<kgunn> kdub: one other thing to check my thinking....i should just bump our so name on our dev branch, then push the whole damn thing to trunk....e.g. we want it all w/ history right ?
<kgunn> e.g. push --overwrite lp:mir
<kdub> not sure what --overwrite does :/
<kdub> merging is probably better
<kgunn> mmmm...it ignores any conflict, but that would only matter if an mp went in....
<kgunn> so i guess thats not right
<kgunn> it would be better to merge....but somehow perserve history
<kdub> kgunn, what we should do is bump the so in the dev branch, get that landed, and then instruct CI to autoland the revision that has the bump
<kdub> well, jenkin's autolander for lp:mir
<kgunn> kdub: "get that landed" means onto lp:mir trunk right
<kdub> no, land onto the dev branch
<kdub> and then merge that into  lp:mir
<kgunn> kdub: oh...ok...yeah...we're thinking the same
<kgunn> too many "lands"
<kgunn> kdub: i'm just wanting to make sure we pull over history per commit with it
<kdub> kgunn, after a merge, bzr log -n0 shows the individual revisions in the branch that was merged
<robotfuel> robert_ancell: ping
<robotfuel> RAOF: ping
<robert_ancell> robotfuel, hello
<RAOF> robotfuel: Pong
<robotfuel> we have this new bug from the xmir stuff that landed last night https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/1231084
<ubot5> Ubuntu bug 1231084 in xserver-xorg-video-intel (Ubuntu) "xorg freezes with xmir after changing resolution with xrandr " [Undecided,Confirmed]
<robotfuel> it's only on intel and only 2 of the 3 intels in the lab
<RAOF> Hrm.
<RAOF> Does running with MIR_BYPASS=0 fix it?
 * RAOF is currently in a moderately interesting XDC talk, so mental bandwidth is low.
<robotfuel> RAOF: where do I add MIR_BYPASS=0?
<RAOF> robotfuel: Export it from /usr/bin/unity-system-compositor.sleep
<RAOF> robotfuel: Ahem. /usr/sbin/unity-system-compositor.sleep
<robotfuel> RAOF: MIR_BYPASS=0 fixed the issue. it's actually not freezing when the resolution changes it's freezing when using xrandr --output VGA-0 --off
<robotfuel> RAOF: the next step is the resolution change which hangs, but the ui is frozrn after the xrandr --output VGA-0 --off I'll update the bug
<RAOF> Ok.
<RAOF> I think I've seen that before. We're probably blocking the (Mir) frontend, so messages are no longer being handled.
<mlankhorst> RAOF: hm considering you're at XDC (part of me is jealous, but I'm also glad), want me to look at any xmir things?
<mlankhorst> any specific
<RAOF> mlankhorst: Not that I'm aware of :)
<RAOF> mlankhorst: Oh, you could push my xf86-video-ati patch if you felt like it :P
<mlankhorst> ah forgot :P
<mlankhorst> *writes it down*
<mlankhorst> ok will probably do it tomorrow, bedtime for me :P
<RAOF> Yeah, no rush.
<RAOF> I've applied the most interesting bit in Ubuntu already.
 * mlankhorst is in the mood for some triaging tomorrow
<RAOF> mlankhorst: Oh, and there's always https://bugs.launchpad.net/mir/+bug/1195811 :)
<ubot5> Ubuntu bug 1195811 in linux (Ubuntu) "nouveau: Abnormally high FPS and tearing (no vsync) with nouveau" [High,In progress]
<mlankhorst> RAOF: Yeah no luck there, requires upstream cooperation :/
<mlankhorst> I did write a fix that I keep in my tree
<mlankhorst> RAOF: oh bug darktama for me please
<mlankhorst> pester him as much as you can about high resolution vblank timing
<mlankhorst> that patch fixes that issue :P
<robert_ancell> racarr, around?
#ubuntu-mir 2013-09-26
<robert_ancell> kgunn, kdub - anything holding up https://code.launchpad.net/~robert-ancell/mir/dev-branch-abi/+merge/187613?
<kdub> robert_ancell, yes, i think i should clear that fence before updating the packages
<robert_ancell> kdub, ah, ok
<robert_ancell> I was looking at landing https://code.launchpad.net/~alan-griffiths/mir/socket-connection/+merge/187326
<robert_ancell> since Jenkins got confused
<kgunn> good grief jenkins takes a long time to come around and merge it
<robert_ancell> RAOF, heya
<RAOF> Good evening!
<robert_ancell> bbl
<didrocks> kgunn_: Mir FTBFS in i386
<didrocks> robert_ancell: hey, can you help with that?
<didrocks> https://launchpadlibrarian.net/151501033/buildlog_ubuntu-saucy-i386.mir_0.0.12%2B13.10.20130926-0ubuntu1_FAILEDTOBUILD.txt.gz
<didrocks> (as there is the ABI break, we are going to be in a state with everything being blocked)
<didrocks> it passed on other archsâ¦
<didrocks> anyone on the Mir team? this is quite a blocker? ^
<didrocks> alf_: ? ^
<alf_> didrocks: already looking, setting up a i386 chroot to try out solutions
<didrocks> thanks
<didrocks> alf_: any hope? ;)
<alf_> didrocks: a build is in progress
<alf_> didrocks: (I mean locally)
<didrocks> alf_: I hope the build will fail in your env as well ;)
<didrocks> alf_: keep us posted please
<alf_> didrocks: sure
<robert_ancell> didrocks, alf_, back now. Any progress on the i386 build?
<alf_> didrocks: robert_ancell: problem reproduced locally, investigating probable solutions
<alf_> s/probable/possible/g
<robert_ancell> alf_, awesome, thanks!
 * didrocks crosses fingers
<robert_ancell> didrocks, that passed in Jenkins right?
<didrocks> robert_ancell: I think jenkins build are amd64, it only fails on i386
<didrocks> of course all -dev packages are blocked, so we have a huge pile of dominos failing (unity-mir, unity8â¦)
<robert_ancell> didrocks, :(
<robert_ancell> didrocks, it looks like we do an android build on i386 but not a normal build (https://code.launchpad.net/~mir-team/mir/development-branch/+merge/187640/comments/428486)
<didrocks> robert_ancell: that's the story on being on top? ;)
<robert_ancell> didrocks, the story?
<didrocks> robert_ancell: s/story/faith/ (being on top of all the dominos)
<robert_ancell> don't know that one
<didrocks> robert_ancell: indeed, only an android build on i386 in jenkins, weird
<didrocks> robert_ancell: I think upstream-merger should really use the distro builders, we won't end up in all that jazyness
<robert_ancell> didrocks, agreed
<robert_ancell> alf_, do you have the proposed fix pushed somewhere?
<alf_> robert_ancell: not yet, I am trying it out still
<robert_ancell> didrocks, yeah, virtual functions in C++ ABI are a pita :)
<didrocks> oh yeah ;)
<alf_> robert_ancell: didrocks: ok I have a reasonable fix, trying amd64 build to ensure nothing broke there. Will ping with MP url.
<didrocks> alf_: excellent! thanks :)
<robert_ancell> alf_, nice!
<robert_ancell> didrocks, you don't know any magic to make MPs land any faster do you :)
<alf_> robert_ancell: I will push to development-branch and then lp:mir to not break our flow
<alf_> robert_ancell: I mean the MP will be for development-branch
<didrocks> robert_ancell: I do know, it's called bzr push :p
<didrocks> robert_ancell: how long a MP is taking to hit trunk for Mir?
<didrocks> in average
<robert_ancell> didrocks, 1hr or so
<didrocks> alf_: why for development-branch? can we target trunk?
<robert_ancell> didrocks, I'm thinking this probably counts as a good case for just doing a push if it's holding things up and a fairly simple change
<didrocks> ah ok, you have a 2 stage thing
<robert_ancell> didrocks, we need it to land on both
<didrocks> robert_ancell: agreed
<didrocks> as we will rebuild in daily just afterwards
<didrocks> so i'm in favor as well as pushing to trunk
<robert_ancell> didrocks, yes
<robert_ancell> alf_, we'll review the MP but just do the push manually
<alf_> robert_ancell: np
<alf_> robert_ancell: didrocks: https://code.launchpad.net/~afrantzis/mir/fix-i386-build/+merge/187681
<robert_ancell> alf_, some sort of merge conflict?
<alf_> robert_ancell: didrocks: hmm something went wrong in the MP
<didrocks> yeah, seeing conflicts as well
<didrocks> alf_: also, if you take the same branch and show against trunk, are we fine?
<alf_> robert_ancell: didrocks: let me repush cleanly... it's a one line change..
<didrocks> alf_: I would prefer to see the diff against trunk itself
<alf_> didrocks: trunk == development branch atm
<didrocks> alf_: well, we are taking lp:mir for releasing
<didrocks> alf_: I just want to ensure that we only have your changes in
<didrocks> nothing else
<robert_ancell> alf_, do two MPs please
<alf_> robert_ancell: ok
<alf_> robert_ancell: didrocks: https://code.launchpad.net/~afrantzis/mir/fix-i386-build/+merge/187682
<alf_> robert_ancell: didrocks: https://code.launchpad.net/~afrantzis/mir/fix-i386-build/+merge/187683
<didrocks> ah good ;)
<didrocks> alf_: robert_ancell: so, mind pushing the merge to trunk directly?
<didrocks> the other one can use the usual process I guess
<didrocks> (trunk being for me lp:mir)
<robert_ancell> alf_, They make sense to me so feel free to push directly
<mlankhorst> g'day
<alf_> robert_ancell: didrocks: In that case I'd rather follow the usual process, push to development-branch, and merge that into lp:mir
<didrocks> alf_: no, everything is blocked on lp:mir
<didrocks> alf_: nothing can release anymore
<didrocks> hence we need to direct push to lp:mir
<robert_ancell> alf_, I can push if you want me to take responsibility for it
<didrocks> so that we can rebuild mir
<alf_> didrocks: we still get the same effect,1. push to development-branch 2. Merge devel into lp:mir
<didrocks> alf_: devel contains more
<didrocks> than lp:mir
<alf_> didrocks: no
<didrocks> and right now, we are blocked on having the code in lp:mir
<alf_> didrocks: lp:mir == devel at the moment
<didrocks> ah, I'm not sure about your devel branch ;)
<didrocks> what I mean is that, we need to bzr push the fix to lp:mir now
<didrocks> and then, I can rekick a build
<alf_> didrocks: sure, there won't be a delay, let me do it
<robert_ancell> alf_, oh, I see what you mean
<didrocks> ok, ping me please once done :)
<alf_> robert_ancell: I guess we don't need to bump ABI right?
<robert_ancell> alf_, no
<alf_> didrocks: robert_ancell: pushed to both devel and lp:mir
<didrocks> alf_: thanks \o/
<didrocks> I'm relaunching the mir stack build
<robert_ancell> didrocks, how long does it take to rebuild?
<didrocks> robert_ancell: ~30 minutes for Mir
<robert_ancell> didrocks, rebuilt ok?
<alf_> robert_ancell: did you have timer set for exactly 30 minutes? :)
<robert_ancell> alf_, only my built-in timer :)
<didrocks> robert_ancell: still building
<didrocks> robert_ancell: Mir successfully built!
<didrocks> thanks
<didrocks> thanks alf_ ;)
<robert_ancell> yay!
<robert_ancell> alf_ to the rescue
<alf_> didrocks: robert_ancell: np, yw
<robert_ancell> bye all
<didrocks> have a good night robert_ancell :)
<mlankhorst> got any complicated bugs for me to look at? :P
<alan_g> mlankhorst: do you want to admire them or fix them?
<mlankhorst> fix
<mlankhorst> or at least find the cause
<alan_g> mlankhorst: I don't think alf_ or RAOF got much further with the Mir-on-Mir problems with GBM you were helping with a week or so back. Fixing that would be great
<mlankhorst> hm non-trivial though :P
<mlankhorst> meh lets just pretend in that case mir is not used to create the egl screen
<mlankhorst> what could possibly break..
<alan_g> you want complicated and trivial?!
<mlankhorst> alan_g: imo the mir backend should be killed from mesa, and mir should use the normal dri api. :P
<alan_g> mlankhorst: That doesn't sound like it solves the use case, but maybe I've misunderstood you
<mlankhorst> well it would automatically fix nesting
<alan_g> We intend one system compositor that "owns" the hardware, and multiple session compositors that talk to it. And you mean to kill the system compositor?
<mlankhorst> not really
<mlankhorst> but it looks like we simply need something like done in platform_drm
<mlankhorst> alan_g: in any case it probably makes more sense to prohibit nesting and only have 1 compositor :P
<mlankhorst> really!
<mlankhorst> but knowing that won't happen, meh
 * alan_g would like to be able to run a development mir under a mir stack. (And some others want to run unity in a session compositor process)
<alan_g> Anyway, you asked for something complicated. ;^)
<mlankhorst> fine I'll see if I can suck up the information from gbm somehow
<mlankhorst> my life would be so much easier with client side allocation though
<alan_g> I'm told that doesn't work so well on the android stack.
<mlankhorst> how do you want to nest, then?
<mlankhorst> on android
<alan_g> That already works - I turned my N4 into a hand-warmer my having 6 levels of mir nested.
<mlankhorst> need to go deeper
<mlankhorst> alan_g: seems that for platform_drm (which you want to use in this case), wayland has something like         EGLBoolean eglBindWaylandDisplayWL(EGLDisplay dpy,
<mlankhorst>                                            struct wl_display *display);
<mlankhorst> an extension
 * alan_g is out of his depth
<mlankhorst> I guess it's to handle nested too
<alan_g> Does that mean you can make it work?
<mlankhorst> there's the option of creating a EGL buffer from a wayland buffer too, afaict
<mlankhorst> hm I'm not sure yet
<mlankhorst> bad raof, using colour when the rest of the code uses color
<mlankhorst> alan_g: hm looks like the fix is in the tree I was using though? "mir: Reuse the dri2 screen from the gbm device if available"
<mlankhorst> although it still uses dup which is bad
<mlankhorst> oh nm that was the good callsite :P
<sil2100> Hi guys
<sil2100> I seem to be having problems running any autopilot tests on mako with Mir running
<didrocks> kgunn_: ^
<mlankhorst> it's done in a very hacky way, but it looks like it should work theoretically..
<sil2100> The problem seems to be happening both when using phablet-test-run and when directly running autopilot by SSH
<sil2100> Do I have to do anything differently than when using surfaceflinger?
<mlankhorst> alf_: you managed to make that mesa stuff work right?
<davmor2> sil2100: does the test script take any screenshots?  Other than that I don't think any should be different other the the wait time maybe,  windows can load slower on mir on maguro at least
<mlankhorst> alan_g: from what I can tell alf_'s lp:~afrantzis/mir/spike-nested-gbm-egl-image-hack + https://github.com/afrantzis/mesa.git egl-platform-mir-egl-image-i965-experiment
<mlankhorst> would work nested
<sil2100> davmor2: no, since I tried running many different test cases
<sil2100> davmor2: none of them even start - the applications under test are not even starting
<alan_g> mlankhorst: My understanding is that it doesn't, he talked to RAOF about it last week - but they didn't get time to figure it out.
<didrocks> davmor2: have you already try it?
<didrocks> I confirm what sil2100 sees
<mlankhorst> alan_g: meh I'll take a look then
<davmor2> sil2100, didrocks: no worries just trying to rule out anything obvious with the tests before continuing to debug software itself,  those were the 2 obvious things that I could think of.
<mlankhorst> alan_g: I see platform_drm pulling a bunch of stuff from gbm, which might be related
<mlankhorst> actually seems more like it might be overriding a bunch of stuff in gbm
<mlankhorst> :P
<alan_g> Sounds complicated
<mlankhorst> well they're intertwined
<mlankhorst> so not really surprising
<alf_> mlankhorst: alan_g: I tried various approaches, including trying to imitate what platform_drm does (i.e. use the dri screen from the gbm device instead of creating a new one, plus duplicating the dri2 image from gbm buffer), but I couldn't get it to work. It is in RAOF's hands now, but I haven't heard any news about it lately.
<mlankhorst> alf_: ok I'll poke it some more then
<mlankhorst> what you have in your mir/mesa branch looks like it oculd work, though
<mlankhorst> alf_: what exactly is the failure mode? I just finished compiling now
<alf_> mlankhorst: I don't remember exactly for what is in the branch right now :/
<mlankhorst> some hack to slurp the screen from gbm
<mlankhorst> hm it's doing SOMETHING :P
<alf_> mlankhorst: yeah, that's a wicked hack...  wanted to get something asap
<kgunn_> didrocks, from scrollback, looks like mir landed ok, but now....autopilot seems busted ?
<didrocks> kgunn_: yeah, we let it throught as it doesn't block the main experience, but autopilot tests can't be run with Mir enabled on the phone
<didrocks> kgunn_: you can check with Saviq, he has the bug references
<kgunn_> sil2100, did you confirm that if you remove /home/phablet/.display-mir that autopilot starts working as expected ?
<kgunn_> on the same exact image that is
<didrocks> kgunn_: I did that and right, it's working on SF
<sil2100> kgunn_: yep
<mlankhorst> alf_: hm, I'm not getting any information about failure, just getting terrible fps on intel and garbage on radeon
<Saviq> kgunn_, yeah, ap is broken with mir currently: bug #1226234 and bug #1226227
<ubot5> bug 1226234 in Unity 8 "QT_LOAD_TESTABILITY=1 does not work for loading the testability driver under mir" [Undecided,Incomplete] https://launchpad.net/bugs/1226234
<ubot5> bug 1226227 in Mir "libmirserver parses arguments and fails if it's not something it understands" [Medium,Triaged] https://launchpad.net/bugs/1226227
<mlankhorst> alf_: heh.. swrast :P
<alf_> mlankhorst: swrast FTW, GPUs are overrated! :)
<mlankhorst> that explains the 1 fps i was getting at least
<mlankhorst> no idea why it's USING swrast, but still..
<kgunn_> sil2100, any other probs other than the AP tests on mir ??
<kgunn_> sil2100, trying to parse rumor from reality :)
<kgunn_> sil2100, some say you found "other issues"...i'd like to track those as bugs if we can
<sil2100> kgunn_: there were some slowdowns happening when using it for a while, but not sure if that is a known issue
<sil2100> kgunn_: like, if you open up some applications then close them, everything is moving slower and slower
<sil2100> kgunn_: not tragically, just slower ;)
<kgunn_> sil2100, mmm....ok....we definitely need a bug on that tho
<kgunn_> sil2100, i'll test here and
<sil2100> kgunn_: I'll fill it in too
<kgunn_> then file
<sil2100> Oh ok
<kgunn_> sil2100, it should be pending image right ?
<sil2100> kgunn_: I think all packages are in -proposed, not sure where the image is at
<sil2100> kgunn_: btw. https://bugs.launchpad.net/mir/+bug/1231452
<ubot5> Ubuntu bug 1231452 in Mir "Autopilot tests not working Mir-driven touch devices" [High,New]
<robotfuel_> I am trying to run qmltestrunner on a phone with mir enabled and I am getting an error of http://pastebin.ubuntu.com/6158739/, has anyone tried this?  it works when I run it on the phone with surface flinger
<robotfuel_> greyback: ^?
<kgunn> sil2100: so, how can  i flash what you guys are testing ? ....e.g. is there a url i can point at ?
<sil2100> kgunn: what do you mean..?
<sil2100> kgunn: I'm using the latest cdimage-system + mir from daily-build
<greyback> robotfuel_: that's failing as unity8 is rejecting the application, as it has no desktop file specified. If you append "--desktop_file_hint=/usr/share/applications/notes-app.desktop" it should work
<kgunn> sil2100: ok
<kgunn> sil2100: so the mir we pushed last night is all built in? ....or i have to installed packages from proposed?
<kgunn> sil2100: sorry to pester...just trying to figure out which end is up
<sil2100> kgunn: I think it's in -proposed now, so you can simply use daily-build PPA to get it as well
<mlankhorst> alf_: hm I'm trying to understand thism but what is basically happening now is that I believe that window allocations are forwarded :P
<alf_> mlankhorst: I am not sure what this means
<racarr> MORNING
<mlankhorst> alf_: afaict, what would happen before is that when bo's were allocated through gbm they would be allocated from the current drm node
<racarr> East coast to west coast jet lag is great
<mlankhorst> what happens now is that they are allocated the same way that they would as if they were allocated through egl..
<alan_g> greyback: I've started looking at the "clients hang when the server dies" scenario. You were going to provide a bit of info about handling it (a signal or call to save state IIRC). Anyway, the first slice is here: https://code.launchpad.net/~alan-griffiths/mir/client-dies-without-server/+merge/187797
<alan_g> Afternoon
<mlankhorst> hm afaict it should be identical, meh
<alan_g> racarr: Are you OK with https://code.launchpad.net/~dandrader/mir/ainput-log-filtering/+merge/187466?
<greyback> alan_g: I will ask you to chat with ricmm about sending the "save state" signal to clients from Mir itself. He's wrote that code, so would know it better
<racarr> alan_g|tea: Let it land!
<mlankhorst> alf_: hm btw it seems valgrind is complaining, in the cleanup do you uninitialize gbm before or after uninitializing egl? :P
 * mlankhorst is guessing before
<alf_> mlankhorst: I think that gbm is uninitialized after EGL.
<alan_g> ricmm: I'm looking at allowing mir clients to shutdown cleanly after the server dies. greyback tells me there's a mechanism to instruct them to save state and that you're the guy to tell me what's involved.
<ricmm> alan_g: sending clients a LifecycleEvent that sets the state to mir_lifecycle_state_will_suspend should be enough to trigger it
<mlankhorst> alf_: hm fun interactions between gbm and mir :/
<ricmm> alan_g: we could add another field to the LifecycleEvent message to specify not a state transition (as these refer to the client) but a server-death signal
<ricmm> server/shell exiting signal
<alan_g> ricmm: not "exiting" but "gone" - this is from the client library when the server goes AWOL. ;)
<alan_g> But OK, a lifecycle callback seems a sensible
<alan_g> s/a //
<ricmm> ok server gone is valid, we can clean up in the app and decide if we want it to quit itself
<ricmm> is this to fix the fact that clients need to die before the server process dies completely?
<alan_g> ricmm: It might fix that as a side effect. Which bug is that?
<ricmm> well on the phone at least when the server segfaults or something, if clients are still connected then the server process blocks to die... even tho it segfaulted
<ricmm> and it holds a frame in the FB too
<ricmm> have to manually kill client processes and once the last is gone, then the server process disappears and the fb is released
<racarr> I think we should have server exiting and gone
<racarr> in server exiting (normally), the correct case is almost certainly for the clients to just die as cleanly as possible
<racarr> but in server gone (abnormally)
<racarr> that probably means unity/mir crashed and is coming back so lets get ready to set things back up
<alan_g> ricmm: I'll have to try reproducing to understand why the server hangs after segfault. But that needs fixing server-side.
<mlankhorst> alf_: hm, you get a fd from display_get_platform .. do you have to close that one when you call the function?
<mlankhorst> or does it have to stay open
<mlankhorst> and if you call it repeatedly do you get the same fd?
<robotfuel_> greyback: qmltestrunner doesn't like --desktop_file_hint=/usr/share/applications/notes-app.desktop appended to it. I also tryed modifying a .desktop file to run the qmltestrunner without success.
<greyback> robotfuel_: ok, please log a bug and I'll investigate asap
<greyback> robotfuel_: the output of .cache/upstart/unity8.log would be useful for me
<robotfuel_> greyback: ok
<alf_> mlankhorst: you get the same fd each time, you shouldn't close it, it's closed when the mir connection is released
<mlankhorst> kk
<robotfuel_> greyback: I figured it out qmltestrunner needs to do -import --desktop_file_hint=/usr/share/applications/notes-app.desktop
<hikiko> bye everyone!
<greyback> robotfuel_: uhhh, weird. Perhaps a "qmltestrunner <blah> -- --desktop_file_hint=..." might work/be cleaner??
<robotfuel_> greyback: no qmltestrunner needs -import to append the --desktop_file_hint
<greyback> robotfuel_: weird
<greyback> but if it works..
<mlankhorst> alf_: hm, anyway my guess is that to the best of my knowledge things actually work, because they seem to be. but the nested server is messing something up so only garbage gets copied back
<mlankhorst> :P
<mlankhorst> maybe try without bypass?
<mlankhorst> gone
<davmor2> kgunn_: http://paste.ubuntu.com/6159306/  seems to think I don't have opengl 3.2 or higher installed from my gfx card so doesn't start.
<racarr> alan_g: The refactoring to socket-messenger-race ends up not being trivial because of ProtobufMessageProcessor::send_response(mir::protobuf::Surface* response)
<racarr> which relies on being able to call send_fds, twice and send two messages for the client library
<racarr> Wondering if you have any ideas on how that should reshape...
<alan_g> racarr: If it were trivial it would have happened before. 8^/
<kgunn_> davmor2, so you're running closed source drivers with just X?
<davmor2> kgunn_: xmir on intel
<alan_g> racarr: I suspect we should pass in some sort of aggregate
<kgunn_> davmor2, ? hmm...so, the intel driver is open source and it should be xserver-xorg-video-intel
<kdub> one day i'll learn how to stop upstart
<kgunn_> which should start up
<racarr> alan_g: Mm. I'm trying to figure out how to avoid overload explosion though...it seems nasty to have like
<kgunn_> so...looks like your app is the one complaining
<davmor2> kgunn_: once I've migrated all the apps I'll be trying it again without xmir, and then again on nvidia 319
<racarr> send (body) send body(fds), send body(fd aggregate)
<racarr> err...I dont know how to use parenthesis
<racarr> but the idea should be clear
<kgunn_> davmor2, hmmm...weird...yeah, let me hear what you get from playing mix-and-match
<davmor2> kgunn_: it might take a while about 790-ish apps left to migrate :)
<alan_g> racarr: just send(body, {}), send(body, {fds}), send(body, {fds, more_fds})
<racarr> maybe just rely on the caller to produce the aggregate with {}
<racarr> Mm
<alan_g> send(Body const&, initializer_list<vector<fd> const&> const&)
<racarr> alan_g: Why use std::initializer_list over vector<vector> ?
<racarr> looks the same to the caller
<alan_g> racarr: and to the callee - but the initializer_list gets constructed anyway to initialize the vector.
<racarr> Mm, but why have the callee have to use the initializer list rather than just
<racarr> implicitly construct the vector at the call site?
<alan_g> the callee just does "for(auto const& fds : fd_list)" in both cases?
<racarr> hmm yeah
<racarr> but isn't initializer_list kind of a misnomer then?
<racarr> If nothing is being initialized...
<racarr> I have had continual issues trying to understand the nature of initializer_list, heh]
<alan_g> racarr: using better_name = std::initializer_list
<racarr> haha
<racarr> ok
<alan_g> racarr: Or typedef initializer_list<vector<fd> const&> better_name
<racarr> Yes.
<alan_g> Just because WG21 were thinking about initialization doesn't mean we are restricted in how to use what they built
<davmor2> kgunn_: mir definitely has issues with Critter Cascade the app starts up fine but the entire screen flashes like crazy
<davmor2> xmir even
<davmor2> kgunn_: that is a free app, so should be available in a bit in software-center so you can try it for yourself, I don't know how much useful data you can get from it.
<kgunn_> davmor2, ok
<davmor2> kgunn_: critter cascade should be installable now
<kgunn_> alright
<racarr> Updated to a typedef :)
<racarr> Final dentist appointment *success fist* be back after lunch
<racarr> iterated on socket-messenger-reporting and race
<racarr> focus-tell-dont-ask when I get back
<kgunn_> join #ubuntu-touch
<davmor2> kgunn_: dale hardshovel hd has the same strobe light  effect as critter cascade so I'm wondering if all the unity-3d games will
<davmor2> kgunn_: dare_up_wing suit is unity-3d too and has the strobe so I'm guessing so :(
<kgunn_> davmor2, that's interesting....we run phoronix & glmark2...all the time, they never strobe
<kgunn_> those are definitely gl
<kgunn_> davmor2, is it the entire screen or just a window (if you can run windows
<kgunn_> windowed)
<davmor2> kgunn_: 2 are already windowed and 1 is fullscreen
<kgunn_> davmor2, for the windowed cases, is the flicker occuring fullscreen or just inside the window?
<davmor2> kgunn_: Fullscreen
<davmor2> kgunn_: darwinia has an odd glitch it's like 1 frame gets dropped, i.e. if it is meant to run 25 frames a second it's running 24 I'll share a video shortly
<racarr> Could that be what alf just fixed?
<racarr> Also back :)
<davmor2> kgunn_: http://ubuntuone.com/0pvNLyVZrb2VohlRflSbu3
<kgunn_> davmor2, thanks
 * kgunn_ gets popcorn ready
<davmor2> kgunn_: it's not that long a video :)  you'll see it flicker twice though :)
<kgunn_> good grief...download sooooo sloooowww
<davmor2> kgunn_: I just got a video of the strobe effect too for you just waiting for it to land
<davmor2> kgunn_: http://ubuntuone.com/0siU1JGmj5VkKEOu13MXKE that's the strobe effect from the unity-3d apps
<davmor2> robotfuel: ^ by the way they might interest you too :)
<robotfuel> davmor2: what videocard?
<davmor2> robotfuel: intel
<robotfuel> davmor2: do you have a bug with the xorg logs in it?
<davmor2> robotfuel: Nope, but I'll try and throw one together before I knock off
<davmor2> robotfuel, kgunn_: oh that's interesting I wonder if it is the hybrid that is playing up.  This box is an intel/nvidia box without the nvidia bit being enabled so just running on the intel part.  On a pure intel box I have there is no flash
<robotfuel> davmor2: I've seen different results with different intel chips? are they the same type?
<davmor2> robotfuel: I don't think so I'm grabing the info now
<davmor2> robotfuel: flashy one is 3rd gen core processor graphics controller + Nvidia GK107M[Geforce GTX 660M], none flashy one is Core processor integrated grraphics card.  Both intel drivers are the i915
<robotfuel> davmor2: I have a core processor with hybrid graphics I can try tomorrow in lexington
<robotfuel> davmor2: can try a 3rd gen core processor now
<davmor2> robotfuel: I'll write up a bug tomorrow I'll have a fairly fresh xorg then.
<robotfuel> davmor2: ok, I'll email you if I can reproduce and write a bug before your morning
<davmor2> robotfuel: okay cool I need to get off I didn't realise it was that late :D
<robotfuel> davmor2: thanks for your help
<robotfuel> kgunn_: is the ubuntu-unity-experimental-prevalidation ppa suppose to be working now?
<kgunn_> robotfuel, i don't think so
<kgunn_> i think its defunct
<robotfuel> kgunn_: let me know when I should start testing it :)
<robotfuel> or if there is a new proposed ppa I can run test on
<kgunn_> robotfuel, actually what
<kgunn_> is in trunk is effectively in archive
<robotfuel> is there some proposed stuff before trunk that I can run tests on? so we find them before they land in trunk?
<robotfuel> kgunn_: we have a few benchmarks failing after the new stuff landed in archive the other day.
<kgunn_> robotfuel, ok...that's interesting
<kgunn_> which ones?
<kgunn_> and by fail do you mean...not running or perf drop ?
<robotfuel> 2 intel machines  have x freezing when I turn of a display.
<kgunn_> robotfuel, oh yes...that is known... alf_ actuallyl has solutions, but simply hasn't proposed yet
<kgunn_> kdub, racarr have either of you seen a black screen occur with latest mir ? e.g. unity8 getting killed and nothing displayed
<racarr> no, but I havent run it today
<racarr> and didnt update yesterday I dont think
<racarr> gerrys DPMS changes landed and the DPMS API landed wonder if something went wrong
<kgunn_> well, that's the other frustrating thing....this is all from a bunch of ppa's
<kgunn_> still no image with it all in
<racarr> kgunn_: You can reproduce it?
<kgunn_> no was about to try...supposedly ogra hit it....but, still, with ppa's i get kind of suspicious
<kgunn_> i'd prefer a nice imag
<ogra_> what did i hit ? cna i help ?
<ogra_> *can
<kgunn_> ogra_, heard you were seeing black screen with mir...can you elaborate ?
<kgunn_> sorry if its a repeat conversation
<kgunn_> (is there a bug maybe ?)
<ogra_> hmm, no, that was someone else
<kgunn_> geeze i love the rumors :)
<kgunn_> lool, ^
<ogra_> i get a screen, but unusably slow on my maguro ... and the normal flickering one on my mako
 * ogra_ forgot who tested Mir today 
<kgunn_> ogra_, ok, so you haven't tested latest mir where flickering is gone
<lool> kgunn_: it was sil2100 as I mentioned
<lool> in the paste
<ogra_> ah, right
<kgunn_> lool, oh my bad
<ogra_> kgunn_, well, i only occasionally test whats in the image wrt Mir ...
<ogra_> so no, not the very latest :)
<racarr> Ohhh..hmm perhaps pid_t client_pid in test_client_authorization needs to be volatile
<racarr> in process shared memory
<racarr> err. interprocess
<racarr> tbh I don't see why because the semaphore should be a memory barrier...
<kdub> kgunn_, havent seen that
<sil2100> What's up?
<racarr> Off to buy tea! back in a flash
<kgunn_> sil2100, we were wondering about the black screen rumor on the latest mir
<kgunn_> how did you do it ? was it a fleeting issue ?
<kgunn_> heisenbug ? :)
<sil2100> kgunn_: the black screen issue was due to unity8 getting killed for unity8-autopilot tests and not being able to get started ;)
<kgunn_> sil2100, ah...so related to the AP tests....
<kgunn_> racarr, kdub is either of you wants to the see the latest Touch stew...its pretty good
<kgunn_> apt-add-repository ppa:ubuntu-unity/daily-build
<kgunn_> it has everyones staged stuff
<kgunn_> + ours
<kgunn_> i gotta say the performance looks better than what i saw recently with mir...even with kdub's fix
<kgunn_> osk is behaving better
<kdub> good to hear :)
<racarr> Back
<racarr> kgunn_: Ill give it a try soon
<racarr> robert_ancell: Ping?
<robert_ancell> racarr, hi
<racarr> Got kind of drawn in to grocery store XD but back now. Should we do our 1-1?
<robert_ancell> racarr, oh, sorry, I keep thinking it's at 10am my time, not 9am
<robert_ancell> sure
<racarr> robert_ancell: Do you want to reschedule it?
<robert_ancell> racarr, sure
<racarr> ok will move it to 10 on gcal
<racarr> ok I moved mine, but I guess you have to move yours seperate or something
<racarr> never quite understood rescheduling with gcal
<robert_ancell> racarr, yeah, it still showed at 9 on mine, so I've moved it too
<racarr> Oh I got some logs from acceptance-tests gtest-repeat=1000 while
<racarr> I was out and think I understand the ClientPidTestFixture intermittent failure now
<racarr> its just the client which isn't able to connect quits too fast
<racarr> leading to broken pipe
<racarr> perhaps.
<racarr> oh but mir_connection_release is always sync now
<racarr> hmm
<racarr> maybe we are calling waitpid after it has already died
<racarr> and...then handling that properly :(
<racarr> kgunn_: kdub: Just reflashed my phone to test ubuntu-unity daily PPA
<racarr> and the kind of
<racarr> slowness of sorts
<racarr> is present in SF too
<racarr> Nvm thats not true
<racarr> I forgot that ~home was preserved and .display-mir exists now
<robotfuel> kgunn_: I had bad wifi at the auto dealership, is there are proposed/prelease place for xmir I can do testing from?
<robotfuel> kgunn_: my car had a recall
<kgunn_> robotfuel, unfortunately no...
<kgunn_> sorry about your car
<racarr> kgunn_: PPA does feel much better
<racarr> the slowness I was seeing is gone actually now animations feel a little too touchy lol
<racarr> i hope gerrys dpms branch isnt here yet because if it is it isnt working
<racarr> oh I guess there are upower changes needed still
<racarr> Up early, so basically done today
<racarr> Paused working on some refactoring in unity-mir to make eliminating the concrete class usage easier
<racarr> trying to shrink the mir->unity-mir surface in the existing interface before doing further operations on it
<racarr> Will be around for 30 minutes or so if anyone needs anything.
<robotfuel> robert_ancell: ping
<robotfuel> robert_ancell: I have this bug that needs triage https://bugs.launchpad.net/xmir/+bug/1231632
<ubot5> Ubuntu bug 1231632 in XMir "Setting DPMS mode for output to 0 causes screen to blink/flicker once" [Undecided,New]
<robert_ancell> robotfuel, hello
<deathcrawler> Ubuntu touch is using Mir already on the daily builds?
#ubuntu-mir 2013-09-27
<robotfuel> deathcrawler: you need to enable it
<robotfuel> deathcrawler: but it's on the build already
<deathcrawler> thanks
<robotfuel> robert_ancell:  I also had this xorg crash that needs triage https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1231507
<ubot5> Error: ubuntu bug 1231507 not found
<jrr> what causes '(WW) "xmir" is not to be loaded by default. Skipping.' ?
<duflu> jrr: Missing package xserver-xorg-xmir ?
 * duflu reboots for some live image testing
<duflu> alan_g: Did you resolve bug 1216237?
<ubot5> bug 1216237 in Mir "Mir silently overwrites and reuses /tmp/mir_socket, rendering the previous server useless" [Medium,Triaged] https://launchpad.net/bugs/1216237
<duflu> Or someone, somewhere
<alan_g> duflu: not intentionally
<duflu> alan_g: How about https://code.launchpad.net/~alan-griffiths/mir/socket-connection/+merge/187326 ?
<alan_g> duflu: that shouldn't have change the default behaviour
<duflu> Weird
<alan_g> are you seeing a change?
<duflu> Yes, I get a nice error message now... std::exception::what: bind: Address already in use
<duflu> Hence bug resolved apparently
<alan_g> \o/
<duflu> But resolved, really, by what?
<alan_g> I guess I'm the only one to touch that code - will check
<alan_g> duflu: you're right - I did fix it. (By removing some misguided code)
<duflu> alan_g: OK, please link branch and update etc
<alan_g> duflu: ack
<duflu> alan_g: So how are we making it clear which branch a bug fix is in? Just say fixed in project Mir (meaning development branch) but not in "mir (Ubuntu)"?
<alan_g> duflu: I was assuming we'd just reflect the state of lp:mir - it shouldn't be more than a day behind development-branch
<alan_g> but it hasn't been discussed
<duflu> WTF?!
 * duflu looks
<duflu> alan_g: You're saying all dev commits will automatically enter lp:mir ?!
<duflu> I thought it was only fixes from lp:mir which entered Ubuntu...
<alan_g> no, development-branch is just for staging changes so that we can control ABI changes more effectively while saucy is put together
 * duflu rolls eyes at lp:mir r1083
<duflu> It's fine so long as you never want to track history or bisect things :(
<alan_g> duflu: we just work here.
<duflu> alan_g: Is it just good luck that I have not "Broken pipe" any more?
<duflu> -t
<alan_g> duflu: probably, I still see it occasionally
<duflu> Oh.
 * duflu bisects on dev
<alan_g> Oh, is this the case you had an MP for?
<alan_g> that got fixed
<alan_g> (sort of)
<alan_g> But racarr is still working on a better version
<duflu> alan_g: That's kind of what I'm seeing
<alan_g> There are other cases where it happens
<duflu> alan_g: What's the commit? I can't see it and have resorted to bisecting dev
<alan_g> duflu: https://code.launchpad.net/~alan-griffiths/mir/socket-connection/+merge/187326 lines 1030-1032
<duflu> alan_g: Annoyingly I can't reproduce it even with the revision before that landed :/
<mlankhorst> alf_: oh btw did you get what I said? that it it's probably a bug in the compositor now afaict? :P
<alan_g> mlankhorst: alf_ is on vacation today
<mlankhorst> ah k
<olli> hi greyback
<greyback> olli: hey
<olli> did the foregrounding fix make it in :)
<greyback> olli: not yet, being tested now
<olli> ok
<olli> how does it look?
<greyback> olli: there's a bug in teds code, but it's almost working.
<hikiko> alan_g, ping
<alan_g> hi hikiko
<hikiko> hi
<hikiko> are you busy? can I ask you something on a test?
<alan_g> ask away
<hikiko> well there are some DefaultDisplayServerTextFixture* tests that fail from time to time
<hikiko> and the problem is that they cant detect the server
<alan_g> ack
<hikiko> I wonder if that's related to your task or it's a different problem, it shouldnt be related since we use a mock server isn't it?
<alan_g> DefaultDisplayServerTextFixture forks a real server with a test config
<hikiko> so it's the real server that appears and disappears?
<alan_g> Does it appear?
<hikiko> well if I run the tests with gdb
<hikiko> some rare times I see that in launch_server_process
<hikiko> we get PID 0 and is_test_process becomes false
<hikiko> does this mean that the server appears?
<hikiko> I am not very familiar with this part of code
<alan_g> when there's a fork what gdb does depends on what you've told it to do. If you see fork() return 0, then you're in the child process
<alan_g> That is you're debugging the server, not the test process
<hikiko> yes
<hikiko> so in this case there's a server running isnt it?
<alan_g> What you'll probably see is that the test process times out waiting for the server to come up before you've told it to continue
<alan_g> hikiko: the server process may be running, but it needs to create a socket for connections before anything detects it
<alan_g> and it can't do that while it is stopped in the debugger
<hikiko> that's interesting :)
<hikiko> so, what do you think that is happening? the server starts and then ?
<hikiko> I mean, in case that I dont stop it from gdb
<hikiko> if I dont add a breakpoint but just print a message when the server is forked I still get some messages
<alan_g> I don't know what's happening. I'd turn on some logging and see if that gives any clues.
<hikiko> yes, that's what I'll do then, I ll leave gdb for the moment
<alan_g> E.g. does the server initialize properly? Does it crash?
<alan_g> Does it just take a long time to start?
<alan_g> You know how to control the logs?
<hikiko> how? I was about to just print debug messages in stderr but I'd like to do it the proper way if you can give me some guidance
<davmor2> hey guys congratulations mir on maguro is a hell of a lot more stable on the current images
<alan_g> hikiko: Using the MIR_SERVER_* or MIR_CLIENT_* environment variables - they are documented by ./mir_demo_server_basic --help
<hikiko> ok, I ll check it :) thanks a lot
<kgunn> davmor2: thank you!...i am glad to know that....
<alan_g> hikiko: And if you do need to use gdb, then this explains the multi-process options: http://sourceware.org/gdb/onlinedocs/gdb/Forks.html
<kgunn> davmor2: you would be the first person to say such a thing
<kgunn> hikiko: ....http://unity.ubuntu.com/mir/....or even http://unity.ubuntu.com/mir/component_reports.html
<kgunn> hikiko: they've been there for ages ?
<davmor2> kgunn: It's still slower than SF, but at least it doesn't crash if you open an app and the launcher,  Used for about 30 minutes no crashes,  it was just too slow to use all day :)
<kgunn> davmor2: got it...would you mind taking a video of that (just opening apps, swiping the ui, launcher, dash etc....and rotation as well?)
<hikiko> kgunn, I am not looking to trace anything for the moment but thanks I ll have this in mind
<hikiko> +get a look
<davmor2> kgunn: rotation is laggy on SF there is a bug for that, mir is slightly slower but not much
<kgunn> davmor2: yeah...sometimes, the "slow" or "lag" is actually animation _velocities_ set by qt (especially for things that have that rubber band effect)
<davmor2> kgunn: I'll get on with some work for a bit first then look at doing 2 videos one on SF and one on Mir for comparisons
<davmor2> kgunn: yeah if you start top in the terminal and rotate qml-scene is using 132% of the cpu which is why it's slow I guess :)
<davmor2> kgunn: as soon as the rotation finishes qml-scene disappears off the list :)
<kgunn> davmor2: great....I'd love it if you could also take some measurements.... https://pastebin.canonical.com/98152/
<kgunn> davmor2: that'll print render in ms to the console from the device
<kgunn> davmor2: i had someone measure before and it was like 24 ms or some such
<kgunn> davmor2: so you get ~45 fps experience....but i'm curious what the spikes are
<davmor2> kgunn: right I'll do that as I do the video and upload it to u1 for a share
<kgunn> davmor2: that's awesome...thanks for the insights
<racarr> Morning
<kgunn> racarr: mornin'
<alan_g> Rats! racarr woke up before I started reviewing things.
<om26er> Is Mir going to be enabled on the 13.10 phone Image ?
<kgunn> om26er: that is the aim
<om26er> kgunn, How can I help ? :)
<kgunn> om26er: thanks for the offer....lemme think on that....is it an open ended offer ?
<om26er> kgunn, given my skill set I would most likely be helpful with testing. But maybe there are other things that I might be able to help with.
<racarr> kgunn: Standup link?
<racarr> Calendar never works for me :(
<racarr> kgunn: Nvm it worked
<alan_g> racarr: this is probably the wrong channel to publish the link
<racarr> greyback: Hey! Have time for a quick sync up soonish?
<hikiko> bye
<racarr> Just want to chat with you on my plans for API rework
<greyback> racarr: I'm at your disposal
<racarr> greyback: Ok lets hangout. ill invite you
<racarr> https://plus.google.com/hangouts/_/e458079840664e3f891b11aa2d809d703d9882ca?authuser=1&hl=en
<racarr> greyback: ^
<smartboyhw> BTW, is there to remove Mir from a cmake build?
<smartboyhw> I mean, to uninstall it from /usr/local
<racarr> make uninstall
<smartboyhw> racarr, no target "uninstall"
<bschaefer> smartboyhw, you could do: xargs rm < install_manifest.txt
<smartboyhw> bschaefer, thanks
<racarr> ...I thought we had an uninstall target :(
<kgunn> racarr: alan_g kdub .... any volunteer to review todays dev branch merge to trunk ?
<kdub> why would you ever want to uninstall? ;-)
<kgunn> https://code.launchpad.net/~mir-team/mir/development-branch/+merge/188086
<alan_g> kgunn: LGTM
<didrocks> sil2100: coming?
<kdub> kgunn,  me too
<sil2100> didrocks: I didn't get any invite, so I don't even know where to come ;)
<didrocks> sil2100: https://plus.google.com/hangouts/_/b23d56bfd9b5678ec007684d3d181c1af9f34002
<davmor2> om26er: run it all day log any crashes
<om26er> davmor2, right. I thought it was crashing due to a single reason all those times ;)
<om26er> "the many apps opened crash"
<om26er> is that fixed ?
<davmor2> om26er: there was also the open an app and launcher crash that I reported :)
<kgunn> kdub: didn't you fix this one (thot it was most recent mp)
<kgunn> https://bugs.launchpad.net/mir/+bug/1231594
<ubot5> Ubuntu bug 1231594 in Mir "android test failure in HWCCommon/[0,1].test_hwc_throws_on_blank_or_unblank_error" [High,New]
<kdub> oh yeah, should be fixed
<kdub> sometimes launchpad changes for me, sometimes not
<kdub> havent figured out why
<kgunn> no worries...i'll change it (launchpad janitor kgunn :)
<kgunn> racarr: ping
<racarr> kgunn_: pong
<kgunn_> racarr, i hate  my verizon router...missed this...sorry
<kgunn_> racarr, so mterry is gonna put up an mp for ignoring arg's it doesn't uderstand as a quick fix....was just wanting to see if you could review/approve before weekend
<kgunn_> either you or kevin
<kgunn_> its one of our mir blockers for being default in touch (and some mutual management is kinda hot on seeing it all resolved by Monday)
<kgunn_> :)
<racarr> I reviewed the first one then just saw now there is
<racarr> a second one that says something about the 13.10 development version but is targeted towards lp:mir
<racarr> and contains lots of extra diff
<racarr> kgunn_: > I reviewed the first one then just saw now there is
<racarr> 22:02 -!- kgunn [~kgunn@pool-96-226-49-103.dllstx.fios.verizon.net] has joined #ubuntu-mir
<racarr> 22:02 < racarr> a second one that says something about the 13.10 development version but is targeted towards lp:mir
<racarr> 22:02 < racarr> and contains lots of extra diff
<racarr> presumably the goal is to land it
<racarr> to lp:mir
<kgunn_> racarr, i asked mterry to retarget to dev branch
<kgunn_> he said bbiab...a while ago
<racarr> kgunn_: Ok I retargeted it https://code.launchpad.net/~mterry/mir/dev-unregistered-options/+merge/188177
<kgunn_> racarr, ...huh...you can do that ?
<racarr> just waiting to see that the diff is correct
<racarr> apparently!
<kgunn_> wow
 * kgunn_ thinks racarr may be a wizard
<racarr> boom
<racarr> all done
<racarr> no but really there is just a button
<racarr> resubmit proposal
<racarr> I didnt know you could do it until robert ancell did it to my stuff
<kgunn_> racarr, hey thanks!...that's cool...i had no idea, thot the owner had to
<racarr> :D
<kgunn_> racarr, kdub, mterry  ok...i outta here...have a good weekend
<kdub> you too!
<racarr> kgunn_: Cheers! You too
<mterry> racarr, that's where I put it!
<mterry> I manually proposed a new branch...  I thought
<mterry> racarr, ah I see.  I pointed it at lp:mir.  Thanks for the fix, doh!
#ubuntu-mir 2013-09-28
<ice9> I installed Cinnamon on Ubuntu 13.10 but it shows only the desktop icons without any panels
#ubuntu-mir 2013-09-29
<robert_ancell> kgunn, that confused me - I was why is it approved and not merged? Just noticed you approved it right then :)
<kgunn> robert_ancell: yeah...i think i fully mean to approve it on friday...and then...well
<kgunn> friday happened :)
<kgunn> and i got distracted around 6pm
<robert_ancell> kgunn, it looks good to me btw
<kgunn> robert_ancell: i think what confused me...is that, if you propose the dev branch to merge to trunk...but then subsequently merge to it...obviously it "picks up" any subsquent pushes/merges that happened to it
<robert_ancell> kgunn, there is a race between jenkins noticing it's set to approved and it actually doing the merge, but that should be a reasonable short window
<robert_ancell> kgunn, yeah, it needs to be integrated into Launchpad that when you press approve you mean "approved at revision X"
<kgunn> thomi: ping
<thomi> kgunn: hi
<kgunn> thomi: hey man
<kgunn> quick one
<kgunn> so AP is working right (from the mail)
<kgunn> meaning...if we get all the unity-mir fixes in
<kgunn> it'll just work
<thomi> as far as I know, yes. but this is not the first time the release team have seen soem problem, not told me about it (or filed a bug or anything), and then days later said "oh yeah, that's been broken for ages, didn't you know?"
<thomi> so as far as I know, everything should work (well, with the exception of the open bugs)
<kgunn> thomi: ok...but for my update, i'll assume that problem won't be there....and i will help you keep an eye on staying informed ;)
<thomi> thanks - I expect the occaisonal issue to crop up, and am willing to fix it, but I gotta be told when it breaks :)
<thomi> for the mir side of things, the only thing we're missing is the display resolution code
<kgunn> thomi: cool...
<thomi> which I can work-around in the mean time, although it'll be kind of nasty, so I'm not sure how soon we're likely to get that - do yo know?
<kgunn> thomi: ok...i'm going to drop back to my Sunday afternoon :)
<thomi> ok, have a good one
<kgunn> thomi: to make sure i understand...its basically this one
<kgunn> https://bugs.launchpad.net/unity-mir/+bug/1232054
<ubot5> Ubuntu bug 1232054 in unity-mir "[mir] Need to expose geometry for autopilot consumption" [Critical,Triaged]
<kgunn> right ?
<kgunn> if so...gerry is gonna hit that as #1 on his monday (& saviq is involved)
<kgunn> so hopefully we'll have a soln on monday
<thomi> kgunn: correct
<thomi> awesome news
<thomi> thanks
<thomi> I'll make sure to comment on the bug so he has all the informaton he needs
<kgunn> thomi: oh..thanks for that
<kgunn> ok...really dropping :)
<thomi> nw
<thomi> later!
#ubuntu-mir 2014-09-22
<duflu> anpok, RAOF: OK, I've got the old PentiumD updated and waiting for a new mesa to test (i915) :)
<duflu> In the mean time it serves as a noise and heat machine. Handy
<RAOF> :)
<alf_> duflu: Hi! @ bug 1372276, is it Ctrl-C for the nested or host server?
<ubot5> bug 1372276 in Mir "Nested server crashes with SIGSEGV on shutdown in eglDestroyContext()" [High,New] https://launchpad.net/bugs/1372276
<duflu> alf: Good question. Not sure :) Will paste script
<duflu> alf_: Done
<racarr> Hmm trying to test my cmake qtmir on x86 (desktop session) but can't even get desktop session going without my hacked up qtmir
<racarr> :( of course you have to unplug external monitor
<racarr> would like to submit a 15 minute fix but the whole process of testing it woudl take hours and hours
<racarr> so doesnt seem possible
<greyback_> racarr: yeah multi-monitor & qtmir not friends atm
<racarr> It would be easy to for example have
<racarr> qtmir reconfigure multiple outputs to clone
<racarr> rather than crash...
<racarr> but I dont have time today to test all the various configurations, etc...for another branch
<greyback_> problem is to get Qt happy with that
<racarr> really? I mean just present one output
<racarr> to qt
<greyback_> but what renders to each display then?
<greyback_> to close, do you render for one display, then copy the front buffer to the other display?
<greyback_> s/close/clone/
<greyback_> or just to GL for each display.
<racarr> hmm maybe we do render for each display
<racarr> for some reason I was thinking
<racarr> they were the same front buffer
<racarr> im not sure thats truet hough
<racarr> lalala
<racarr> greyback_: On a happier note tested qtmir-cmake ondesktop and emulator
<racarr> (and phone)
<racarr> all good
<greyback_> racarr: cool, thanks
<racarr> greyback_: Adding the tests to ctest now then will submit another mp that should pass jenkins and do some self review
<racarr> then you can do as you wish with it :D
<greyback_> racarr: magic!
<greyback_> racarr: there's this old qtmir branch you made still in review, dandrader left some comments and it's not gone anywhere since: https://code.launchpad.net/~mir-team/qtmir/server-client-acceptance/+merge/230018
<greyback_> mark it WIP or think you'll resume it or...?
<racarr> greyback_: I was just noticing that too...
<racarr> im reflecting on it lol will do something after lunch
<greyback_> racarr: thanks :)
<doneill> Hi all! I'm hopeful in building Touch on an SoC sporting Mali400 GPU, but I can't find any evidence that Mir works with acceleration on this GPU. Can anybody confirm or refute this?
<racarr> doneill: I can't off the top of my head! If you have android drivers theres a good chance Mir can use them.
<greyback_> doneill: you may find this guide helpful: http://unity.ubuntu.com/mir/android_new_device_bringup.html
<doneill> Excellent, thank you so much!
<greyback_> doneill: this is the best channel to find the mir developers, so feel free to ask for help
#ubuntu-mir 2014-09-23
<duflu> What's the present recommended method for preventing USC from starting on touch?
<duflu> Seems my hackish method is unreliable
<ogra_> duflu, well, installing utpoic 252 seems to be enough currently (lightdm doesnt start)
<duflu> ogra_: Oh, I'm slightly behind. Just as well
<ogra_> you could put a user upstart script in place that prevents the session from starting ... or you could replace the system lightdm.override file we ship
<ogra_> i suspect the session blocking would still get you an usc running though
<tsdgeos> alf_: you have actually not deleted the remote tags
<tsdgeos> alf_: tags need to be removed from the remote branch
<alf_> tsdgeos: all of the tags?
<tsdgeos> alf_: all the wrong ones
<tsdgeos> alf_: bzr tags | grep ?
<tsdgeos> alf_: there's a script for it somewhere
<tsdgeos> let me look for it
<tsdgeos> alf_: http://people.canonical.com/~msawicz/unity8/strip-u8-tags.py
<tsdgeos> commented on the MR to make it clear to others too
<alf_> tsdgeos: thanks, done, should be good now hopefully
<alf_> tsdgeos: actually not finished yet
<tsdgeos> oki
#ubuntu-mir 2014-09-24
<RAOF> Why does cross-thread error propagation need to be so hard?
<duflu> RAOF: Why does it exist? :)
<RAOF> Because we're not using a language with a sensible runtime :P
<duflu> Oh look, C++ isn't bad enough. Let's add a couple hundred more pages to the spec and make it worse
<RAOF> Obviously you wouldn't do that.
<RAOF> There are already two or three terrible languages in C++; no need to add more :)
<RAOF> You might do something like Rust, for example.
<duflu> I noticed C++11(?) recently broke even basic C code: "string"STRING
<duflu> doesn't work any more
<anpok> duflu: missing a literal operator?
<duflu> anpok: No I mean "hello""world" is now invalid in C++. You have to insert a space "hello" "world"
<duflu> Which is annoying if one of your literals is a macro and your mature stable code worked perfectly until C++11
<anpok> interesting
<anpok> they had to change the pre processor to get that
<anpok> http://xkcd.com/1172/
<duflu> anpok: I don't think it required a preprocessor change. Only a language change... ?
<anpok> they allow "foo""bar", but not define BLA "bar"  "foo"BLA
<anpok> i guess  "foo"BLA is a token at cpp stage
<anpok> and not two tokens
<anpok> otherwise they would have to deal a lot with whitespace ugly trickery within the grammar
#ubuntu-mir 2014-09-25
<RAOF> Well that has to be the most surprisingly nondeterministic test ever.
<duflu> In other news, it looks like Mir 0.8 has both lower latency _and_ smoother scrolling than 0.7
<duflu> \o/
 * duflu tries backporting some of that to 0.7
<alf_> duflu: Great, I guess that's the result of your input related work?
<duflu> alf_: Yes, but I just noticed a CPU usage increase I have caused with it all. Now fixing that too :P
<duflu> alf_: The new unit test failure has a fix BTW ... https://bugs.launchpad.net/mir/+bug/1373826
<ubot5> Launchpad bug 1373826 in Mir "unit test fails: AndroidInputReceiverSetup.slow_raw_input_doesnt_cause_frameskipping" [Critical,In progress]
<duflu> It's not a single revision that broke, but the combination of two. Hence each one landed OK :P
#ubuntu-mir 2014-09-26
 * duflu dusts off the old netbook in readiness for Mesa 10.3 celebrations
<greyback__> alf_: ping
<alf_> greyback: Hi
<greyback> alf_: hey, I've a weird question about signals
<greyback> during startup unity8/mir raises SIGSTOP on itself to tell upstart that it is running, and so clients can start connecting to it
<greyback> this works perfectly fine
<greyback> I'm moving that SIGSTOP emission to later in the startup, after Mir's event loop is definitely running
<greyback> again, works perfectly fine with upstart
<greyback> but we've an autopilot test that tests this behaviour too
<greyback> so it executes unity8 manually, and waits for it to SIGSTOP itself, then resumes it
<greyback> however, in this case, it appears the Mir signal handling code captures the signal
<greyback> which is weird, as I didn't think it would capture SIGSTOP!
<greyback> do you think there's some raciness here?
<alf_> greyback: so, SIGSTOP cannot be captured anyway, so something else is going on
<greyback> as I'm not using run_mir, qtmir registers a signal handler for SIGINT and SIGTERM in Mir's event loop - and that seems to fire
<greyback> alf_: hmm, it might be unrelated indeed. Something just caught my eye
<greyback> I will dig a bit more, sorry for interruption
<alf_> greyback: no worries, which mir version are you using?
<greyback> alf_: 0.7.3+14.10.20140918.1-0ubuntu1
<alf_> greyback: ok, so the only way for Mir to raise a SIGTERM to itself is at mir::terminate_with_current_exception(), you could check if that is being called, otherwise the signal comes externally
<greyback> alf_: ok, thanks. I suspect it's coming externally
<alf_> kdub_: Hi! @ read-from-buffer-msg , what's the API for returning a buffer going to look like? Something like PlatformIpcOperations::release_buffer(BufferIpcMessage& message) ?
<kdub_> alf_, right, that's in PlatformIpcOperations::unpack_buffer(BufferI&, Buffer const&)
<kdub_> whoops
<kdub_> PlatformIpcOperations::unpack_buffer(BufferIpcMessage&, Buffer const&)
<alf_> kdub_: ah, ok, so no separate call
<kdub_> right
<kdub_> I mean, BufferIpcMessage is somewhat unneeded in the current state of the code
<kdub_> because we don't have anything other than protobuf
<kdub_> but, may as well keep the ipc abstractions around
<kdub_> oh, and, may as well not link the platforms to protobuf too :)
#ubuntu-mir 2015-09-21
<alan_g> duflu: happy with the response to your "Needs Info"? https://code.launchpad.net/~afrantzis/mir/eradicate-drm-auth-magic-rpc/+merge/271667
<duflu> alan_g: No idea.
<duflu> I'll get to it
<duflu> alan_g, alf_: Approved. Just remember to remind camako not to rebase lp:mir/0.16 again because it would then inherit incorrect ABI bumps
<alf_> duflu: thanks
<alan_g> duflu: There's already a warning in place because of the libmirclient stanzas
<duflu> alan_g: Not sure what you mean. What warning would stop him overwriting lp:mir/0.16 again?
<duflu> Oh, we could just make it appendonly
<alan_g> I warned him last week
<duflu> Kay
<duflu> I might set the flag
<alan_g> anpok_: I was just re-reading some of the nested logic. Am I right that nested is now the only thing using DefaultInputManager? Is there a plan to kill it?
<anpok_> alan_g: hum no that shouldnt be specific to being nested
<anpok_> I will only cut off the legacy_dispatchable
<alan_g> anpok_: OK, I've probably missed something.
<anpok_> nested might create a NullInputmanager or an inputmanager with an empty legacy dispatchable and atm not loading any additional input platforms
<anpok_> but it actually .. could.
<alan_g> anpok_: it looks like nested creates DefaultInputManager with either NullLegacyInputDispatchable or the_legacy_input_dispatchable() and other paths create NullInputManager
<anpok_> now thats interesting
<alan_g> anpok_: don't worry.  I but I misread the code.
<alan_g> s/I but//
<anpok_> ha me too
<anpok_> there is a tiny ! inside.
<alan_g> Indeed.
<guest42315> uuu mir 0.17
<guest42315> will 0.16 land in OTA7?
<kgunn> guest42315: most likely
<guest42315> yay
 * alan_g wonders at the excitement
 * guest42315 snappy <3
#ubuntu-mir 2015-09-22
 * guest42315 sudo snappy install coffee
<tsdgeos> duflu: add mir to https://bugs.launchpad.net/canonical-devices-system-image/+bug/1495871 then?
<ubot5> Ubuntu bug 1495871 in Canonical System Image "unity8 leaks file descriptors cause unresponsive ui but power button works display" [Critical,In progress]
<tsdgeos> or you mean it's a known issue?
<duflu> tsdgeos: I opened a separate bug because we're already dealing with 2 maybe 3 different leaks. Also it's easier to follow
<tsdgeos> ok
<zzarr_> hello! will mir be able to use Vulkan drivers?
<zzarr_> (the 3d acceleration)
<alan_g> In principle, yes. (It will need suitable graphics plugins which haven't been written yet.)
<guest42315> i so cry my eyes out :'( the current xmir (on wily) gives me a black window, although it looks like it gets the windows dimensions right :))
<guest42315> tried all the args -damage etc, no luck
<guest42315> such is life :(
<guest42315> + also failed to compile the xmir git, i sux
<alan_g> guest42315: duflu has been making progress with xmir recently. It will get better.
<guest42315> alan_g, yay! i've seen some interesting stuff on git (like mouse scroll and such)
<anpok> alan_g: while writing that up
<anpok> I believe we want to have typeinfo in mirplatform
<anpok> or maybe we want two libraries one for input and one for graphics platform..
<anpok> thinking of cleaning up native buffer.. and all that..
<anpok> I just noticed that we do not properly export all of the typeinfo
<anpok> for mir::graphics::*
<alan_g> anpok: ack
<anpok> AlbertA: what have we done to fix the dreaded scan out but on krillin?
<anpok> *bug
<AlbertA> anpok: can you remind me what the bug is? :)
<anpok> that the leftmost displayed pixel is scanned out from the rightmost pixel each row.
<AlbertA> anpok: ah... I haven't heard nothing about it in a while...
<AlbertA> anpok: I played around with some timings at the display controller end....
<AlbertA> anpok: but it looked like the base clock needed to be changed instead though.... and I have no knowledge of their SoC clock tree
<anpok> because I thought it was resolved.. and it happened to me yesterday
<kgunn> robert_ancell: hey, did you and duflu address start up issues?
<kgunn> wrt xmir
<kgunn> robert_ancell: pd image is available, but not booting
<robert_ancell> kgunn, duflu seems to have most of them sorted, I'm getting it updated so it can go into the overlay PPA
<robert_ancell> The current image will be using the old XMir unless someone has updated it somehow
<kgunn> robert_ancell: exactly, and pretty sure the glx drivers are hosing the boot process
<kgunn> robert_ancell: just checking, so are you guys going to try to land the latest xmir into ppa overlay today ?
 * kgunn hopes yes
<robert_ancell> kgunn, ideally
<kgunn> cool
#ubuntu-mir 2015-09-23
<robert_ancell> duflu, hold off committing any changes to XMir - I'm about to rebase it
<duflu> robert_ancell: Kay
<duflu> robert_ancell: I removed the changes outside of hw/xmir/ so should be easier now
<robert_ancell> duflu, yeah, nice work!
<duflu> The code changes anyway
<robert_ancell> I've kept the rootless as a separate change for now, but we probably can roll it into one patch going forward now those changes are gone.
<robert_ancell> duflu, ok all done. Hopefully I haven't broken anything...
<robert_ancell> Now to set up a CI train thingy for this
<robert_ancell> oh yay. https://requests.ci-train.ubuntu.com/ makes me want to kill myself
<duflu> Can we have traditional distros back please?
<robert_ancell> duflu, I think the intentions were good but this is a million steps backwards in complexity
<duflu> robert_ancell: Absolutely. You're entitled to create complexity, but not when you make it everyone else's problem
<robert_ancell> duflu, do you want the LP bug numbers in the debian/changelog?
<robert_ancell> It's kind of hard to track them post rebasing
<duflu> robert_ancell: Can't hurt, there's only a few. But more interesting are the enhancements to list
<robert_ancell> duflu, do you want to summarise the changes then?
<duflu> robert_ancell: OK
<duflu> robert_ancell: What git commit was the last release?
<robert_ancell> duflu, on the pre-rebased branch?
<duflu> Never mind. I'll just cover the past few weeks
<robert_ancell> There were just those four commits over the 1.17 changes (xmir, rootless, desktop_file_hint and keeping stdout open)
<robert_ancell> I don't know why the stdout change was there, but we haven't been using it in the xorg-server package so we can probably drop it.
<duflu> Yeah stdout doesn't work still
<duflu> robert_ancell: Gimme an hour or so (other tasks in the way)
<robert_ancell> duflu, ok
<robert_ancell> duflu, do you know what the stdout change is for?
<duflu> robert_ancell: Not even looked at it. I just know printf still doesn't work
<robert_ancell> But ErrorF works, so is there any reason to make stdout work?
<robert_ancell> I'm guessing this is a design decision by upstream?
<duflu> robert_ancell: It would be nice if we could use some InfoF instead. DebugF exists but logs nothing
<duflu> Heh, Mir gained a new build-dep overnight that is actually good to see... libinput-dev
<robert_ancell> duflu, nice!
<duflu> robert_ancell: In that email it might be more correct to s/xmir:/Xmir:/
<robert_ancell> duflu, which email?
<duflu> robert_ancell: The one in your inbox
<robert_ancell> ah
<robert_ancell> thanks
<duflu> robert_ancell: Actually let me rewrite that
<robert_ancell> ok
<duflu> Done
<duflu> For a while I was suspicious and wondering why Xwayland was half the size of Xmir. From what I read recently though that might be because Xwayland is missing features
<duflu> Not sure
<duflu> robert_ancell: I might have an extra crucial fix for Xmir today. In an hour or two
<duflu> Maybe not
<duflu> Or 30 min
<duflu> robert_ancell: BTW I think you can rebase Xmir in future without losing the commit history
<duflu> That would be nice
<robert_ancell> duflu, how can you do that?
<robert_ancell> have a separate branch?
<duflu> robert_ancell: I forget but it's a git feature
<duflu> robert_ancell: Oh I just did it by accident. Repushed and everyone's commits are there in chronological order now
<robert_ancell> duflu, you git push -f?
<duflu> robert_ancell: Nope
<duflu> robert_ancell: It was after your merge and includes you merge so I hope everything's there
<robert_ancell> duflu, oh, it just has an empty merge commit
<duflu> robert_ancell: Yeah the beauty of not having revision numbers is that you can merge things and each commit retains the same identifier it always had
<duflu> robert_ancell: YES. Fixed the missing cursors. Let me get that fix in
<duflu> It's a Mir bug, but I can work around it in Xmir
<robert_ancell> I have to head out for 20-30 mins, bbl
<Hock> https://bugs.launchpad.net/ubuntu/+source/ubuntu-ui-toolkit/+bug/1493185
<ubot5> Ubuntu bug 1493185 in ubuntu-ui-toolkit (Ubuntu) "missing icons in dash/app scope for ubuntu touch vivid image" [Undecided,New]
<Hock> any chance for this bug to be look at?
<RAOF> Looks like someone *is* looking at it? It's assigned to someone.
<RAOF> (It might be nice to capture the shaders that your GL is choking on. I wonder if apitrace works on the phone...)
<Hock> how do I capture the shaders?
<RAOF> You *might* be able to install apitrace on the phone, then modify the unity8 upstart job to run âegltrace unity8â rather than just âunity8â.
<RAOF> That'd get you a trace of all the EGL + GLES calls unity8 makes, including the sources of the failing shaders.
<Hock> no wifi at the moment. :(
<Hock> guess have to wait for update to the lp bug
<RAOF> You could adb push the relevant .debs, I think.
<Hock> sure. given that it might not help as much. it might make more sense to wait for LoÃ¯c to find the time to delve into it.
<Hock> if he ever get to it as there seem to be quite a number of bugs going on in the toolkit
<RAOF> Yeah, always more bugs than people ;)
<Hock> sad hard truth
<duflu> Sometimes more projects than people :)
<Hock> the downside to opensource
<Hock> similar projects in some cases fortunately and yet unfortunately
<anpok_> apitraces does work yes..
<anpok_> -s
<duflu> alan_g: Could you do me a favour and audit the SessionMediator? It's starting to look like it forgets to release some resources at least on unclean disconnects. And such bloat would not show up as a leak either, because destructors would clean it up...
<duflu> Some of those resources may be fds related to Android graphics
<alan_g> I'll add it to the list.
<duflu> As usual, not one bug, but multiple bugs in multiple projects... maybe
<guest123124> hi all
<guest123124> i'm on wily, if i run mir_demo_server in a tty it locks my pc
<alan_g|lunch> guest123124: sorry, that's a poor failure mode (there should be better cleanup and a better error message). Mir needs root access in that configuration: just add "sudo".
<guest123124> alan_g|lunch, thanks :D shoud i open a bug? maybe other people will try mir and they'll end up with a locked pc and maybe get angry or stuff
<guest123124> alan_g|lunch, also, do you know if i "mir_demo_server --vt 1" from terminal would work? should it run mir_demo_server in tty1 and i can then ctrl alt f1?
<alan_g|lunch> guest123124: check if there is a bug filed already (it's quite likely)
<guest123124> will do
<alan_g|lunch> You'll need something like --platform-graphics-lib /usr/lib/x86_64-linux-gnu/mir/server-platform/graphics-mesa-kms.so.4 to avoid it defaulting to x11
<guest123124> alan_g|lunch, like this mir_demo_server --platform-input-lib server-mesa-x11.so.4 --vt 1?
<guest123124> alan_g|lunch, like this mir_demo_server --platform-input-lib server-mesa-x11.so.4 - works.. it opens a window (mir on x)
<guest123124> i still get Unknown command line options: --vt 1
<alan_g|lunch> guest123124: --vt only makes sense when using the kms graphics platform.
<guest123124> alan_g|lunch, like this?  mir_demo_server --platform-graphics-lib /usr/lib/x86_64-linux-gnu/mir/server-platform/graphics-mesa-kms.so.4 --vt 1
<guest123124> alan_g|lunch, thanks that worked :P
<alan_g> guest123124: yw
#ubuntu-mir 2015-09-24
<duflu> AlbertA: still around?
<AlbertA> duflu: just for a bit
<AlbertA> duflu: how is it going?
<duflu> AlbertA: OK, I swear you fixed this already, or something like it? https://bugs.launchpad.net/mir/+bug/1406725
<ubot5> Ubuntu bug 1406725 in xorg-server (Ubuntu) "Severe graphical corruption running software clients (including Xmir) on android" [High,Triaged]
<AlbertA> duflu: I fixed one for "software" buffers... does flicker use software buffers?
<duflu> AlbertA: Yep. And I found in a related bug it seriously breaks arale too :)
<duflu> https://bugs.launchpad.net/mir/+bug/1498806
<ubot5> Ubuntu bug 1498806 in Mir "[arale] Software clients can rapidly cause a Mir server to exhaust all fd handles" [High,New]
<duflu> which may be related
<AlbertA> duflu: interesting... I hope HWC is not leaking the fds
<AlbertA> duflu: the fix for the graphical corruptions were the flags in AndroidAllocAdaptor::convert_to_android_usage
<duflu> AlbertA: Although treat them as separate bugs. The primary issue is the corruption which happens on mako with Xmir too. And mako does not have the fd leak
<AlbertA> duflu: the flags in lp:mir look correct.
<duflu> AlbertA: The least buggy form of corruption is when you just get in-surface tearing. So that combined with the fd leak shows our android buffer fencing isn't working
<duflu> I guess that could reveal apparent corruption too
<AlbertA> duflu: right
<duflu> AlbertA: Never mind, and good night. I have endless tangents if you linger too long
<AlbertA> I wonder what changed....
<AlbertA> is this a regression? or did you just notice it now?
<duflu> AlbertA: AFAIK it's never works
<duflu> worked
<AlbertA> ok
<RAOF> Can I plz haz jenkins & merge proposals on launchpad git? Grr.
<duflu> RAOF: Merge proposals for LP git exist. I've done one!
<RAOF> I can't propose a merge into lp:mir though!
<duflu> That's true. Mir is not git yet though
<duflu> BTW did wily break? https://bugs.launchpad.net/mir/+bug/1499134
<ubot5> Ubuntu bug 1499134 in Mir "[wily] Mir suddenly no longer builds: /usr/include/EGL/eglplatform.h:100:35: fatal error: android/native_window.h: No such file or directory" [Critical,New]
<duflu> Fully updated wily can't even build our stable branches any more
 * RAOF updates to check!
<RAOF> Plausibly; we've got mesa 11.0 now.
<duflu> Woo, good news then
<duflu> But we should build too
<RAOF> Hm. I think it's actually mir that's broken...
<RAOF> Heh, yes.
<duflu> That's why I left Mir tasks open :)
<robert_ancell> duflu, hmm, that merge commit seems to be confusing git rebase. I think we should just rebase on xmir-1.17 and you can keep your changes on another branch if you want them. Note that all this history will ultimately be lost when we go upstream.
<duflu> robert_ancell: Do what you need to. Just don't lose yesterday's additional fix... Also I think next time we should aim to merge without clobbering history. It's OK to lose the history when upstreaming, but very annoying when you're mid-sprint and can't see what you've just done
<robert_ancell> duflu, I think you should treat xmir-1.17 branch as upstream and just maintain a branch with your changes. git doesn't seem to handle keeping history around
<duflu> robert_ancell: git does. And in fact it did by accident yesterday. I'm just saying that accident is what git should be doing and is meant to do anyway
<robert_ancell> duflu, but git rebase is horribly confused after you made that change. So I can't effectively rebase anymore.
<duflu> robert_ancell: Sorry, all I did was pull then push. Normal activities so I guess we need to find out where it went wrong
<duflu> robert_ancell: I'll stay hands off for a while so if you want to forcefully overwrite things to fix it, go ahead.
<robert_ancell> duflu, all fixed now
<duflu> I'm still worried that git automagically created this situation....
<duflu> "you're holding it wrong"
<robert_ancell> Not surprised in the least with git :)
<duflu> The whole point of non-numerical revision IDs is that they get to stay around and don't get confused by merges
<robert_ancell> Oh, the changes will always remain. Just I don't think the tools can handle a branch being both rebased and merged at the same time.
<duflu> robert_ancell: So is simply 'push, edit, commit, push' wrong?
<duflu> 'pull, edit, commit, push'
<robert_ancell> I *think* git pull -r might do it right.
<robert_ancell> i.e. you should rebase on xmir-1.17 instead of merging.
<robert_ancell> The other option is to keep on another branch and then rebase those changes into xmir-1.17 periodically (i.e. when we release packages)
<robert_ancell> I'm open to better ideas but I found it very hard to generate the actual patches from a branch with full history.
<duflu> robert_ancell: git diff <oldrev> HEAD ?
<duflu> Something like that was working for me
<duflu> We need some solution that doesn't require deleting commit history so often...
<duflu> Or ever
<robert_ancell> duflu, the history is never deleted - keep it on another branch if you want
<robert_ancell> git diff doesn't handle having more than one change like we do
<duflu> robert_ancell: The history should be visible on launchpad. If we need another branch on LP?....
<duflu> It's not OK to lose history of what you've done
<duflu> And not OK to say, you should keep it locally
<robert_ancell> duflu, just put it on another branch.
<duflu> robert_ancell: Essentially I want to know the URL of the "trunk" that shows everyone's workings
<duflu> That used to be https://git.launchpad.net/~xmir-team/xorg-server/+git/xmir/ but not now
<robert_ancell> duflu, The xmir-1.17 branch is a) the patches that go into the .debs and b) what we will propose upstream. It's never been anything else.
<duflu> robert_ancell: Losing history is still not OK. I don't expect our history to be visible upstream, but it should always be visible on LP
<robert_ancell> THEN PUT IT IN ANOTHER BRANCH
<duflu> robert_ancell: I'm considering it, but the same problem will reoccur when that gets 'rebased'. So still needs fixing
<duflu> robert_ancell: So we'd need one new branch for each "sprint" right? So that branch with the history never needs rebasing in itself
<robert_ancell> duflu, you could just make a branch xmir-1.17-trunk and use that for development
<robert_ancell> or we could rename xmir-1.17 to xmir-1.17-rebased
<duflu> robert_ancell: AFAICT git merge -p solves it
<robert_ancell> yay, git merge --help mentions -p in an example but doesn't define it...
<duflu> robert_ancell: Oops, I mean git rebase -p
<duflu> Although when you're ready to upstream, then you don't use -p  maybe
<RAOF> Hm. We actually need the android NDK around to build Mir now.
<duflu> RAOF: It appears that way. Why did it work up to yesterday?
<RAOF> Because mesa was using a 4 year old version of Khronos' eglplatform.h
<RAOF> Oh, sorry. 5 year old.\
<duflu> RAOF: Oh didn't we have the missing bits in 3rd_party? Just got cleaned out recently by alan_g
<duflu> He removed "unused" files
<RAOF> Oh, good catch. Yes, native_window.h was one of those.
<RAOF> It *was* unused ;)
<duflu> robert_ancell: I think we need just one new branch in LP. One that keeps history (rebase -p) and one for upstreaming preparation (rebase)
<robert_ancell> duflu, well, we have that second one and you're welcome to keep the first if you want it.
<robert_ancell> s/keep/create/
<duflu> robert_ancell: I'll look into it... are we tied to the existing branch name xmir-1.17 too?
<robert_ancell> duflu, nope, the name is fairly arbitrary. It's just 1.17 because at some point we'll need to rebase on 1.18
<robert_ancell> Is something weird going on in vivid with Mir? My silo is failing on amd64, armhf and i386 with a missing mir_toolkit/mesa/platform_operation.h. Builds fine on the other architectures
<duflu> robert_ancell: OK, I've created the two newly named branches. Can we delete the old (duplicate) one now?
<duflu> Or rename it
<duflu> I might try
<robert_ancell> duflu, is -development supposed to have all the history in it?
<duflu> robert_ancell: Yep
<RAOF> duflu: If you need it, https://code.launchpad.net/~raof/mir/fix-ftbfs-against-mesa-11/+merge/272203
<robert_ancell> It doesn't appear to here
<robert_ancell> oh, hang on
<duflu> RAOF: Ta
<robert_ancell> duflu, ok, now I see a single merge commit
<duflu> robert_ancell: Yeah merge seems much more friendly than rebase. The latter is designed to clobber history
<robert_ancell> was there a reason why you didn't set xmir-1.17-development to your old pre-rebased branch?
<duflu> robert_ancell: If that's what I think you mean then it contained history of the breakage. So best to not confuse git with the brokenness in the history
<robert_ancell> bye all
<duflu> robert_ancell: Bye
<anpok> RAOF: shouldnt that header be part of android-headers?
<RAOF> anpok: I don't think so, no. android-headers is for bits of AOSP that we need, right?
<RAOF> native_window.h is a part of the NDK.
<anpok> RAOF: not sure if that is relevant but it defines the native window but not those functions..
<RAOF> Not relevant at all; all we need of it is âstruct ANativeWindow;â
<RAOF> (That's all EGL needs of it, at least)
<duflu> RAOF: I would have top approved but Jenkins has found all sorts of fail
<duflu> Can't see how it's related
<RAOF> I believe the answer is âit isn'tâ
<RAOF> Do we need to build 0.15/0.16 on wily?
<duflu> RAOF: Is that a trick question? What other Mir version do you intend to put in wily archive?
<guest42315> 0.17 pls
<RAOF> 0.17, of course!
<duflu> Hah
<guest42315> :P
<duflu> Let's release 0.16.0 first.
<duflu> To wily
<RAOF> Spoil sport :P
 * duflu is waiting for Mir 0.42 personally
<duflu> Which oddly still happens before 1.0 is reached
 * RAOF presses the Jenkins retry button.
<duflu> RAOF: Works on my machine anyway
<duflu> And presumably yours too
<RAOF> Indeed.
 * guest42315 they see me rollin' la la la
<duflu> alf_: Didn't you kill the auth magic stuff? It's still used in Xmir
<duflu> Or is that OK and it's wrapped as a platform message?
<alf_> duflu: But through platform operations right?
<duflu> alf_:  hw/xmir/xmir-dri2.c:        msg = mir_platform_message_create(auth_magic);
<duflu> Is that current/safe?
<alf_> duflu: yes, so only the direct drm stuff was removed from the API and we replaced them with platform ops
<duflu> alf_: OK thanks
<Saviq> hey guys, any idea why the new mir is in UNAPPROVED queue? sounds like wily feature freeze is starting to bite us?
<alan_g> Saviq: first I've heard (camako has been working this release), I thought yesterday it just needed to re-sync qtmir.
<Saviq> alan_g, oh yeah it's past QA and all, it's published, but says mir is in UNAPPROVED, I think that's because of FF in effect
#ubuntu-mir 2015-09-25
<RAOF> Oh, great. It's a racy test.
<duflu> Umm what is r2962? :)
<duflu> A bit of a mess it seems
<duflu> RAOF: ^ that's not the proposal I remember from yesterday
<RAOF> Not my proposal :)
<RAOF> Or, rather, mine plus a bunch of other things to make it pass CI, I presume.
<duflu> Oh for the days when the display server was a different process to the shell
<alan_g> burn the heretic!
<alan_g> ;)
<davmor2> alan_g: ah bless you must be new to the whole heretic thing, we don't burn them now it's ecologically unsound, that's what the dunking stall is for, if they drown they were good, if they float they are heretics and you drive a stake through their heart
<alan_g> duflu: do you want to leave lp:~alan-griffiths/mir/fix-1496849 pending API rework, or shall we land it as a bugfix?
<duflu> alan_g: Not worth blocking
<anpok_> oh another chapter in the book of module_deleter..
<Saviq> hey folks, I was able to upgrade qtmir without adding some new needed packages
<Saviq> so ended up with broken unity8:
<Saviq> ERROR: /build/mir-MEFZIJ/mir-0.16.0+15.10.20150921.1/src/platform/graphics/platform_probe.cpp(59): Throw in function std::shared_ptr<mir::SharedLibrary> mir::graphics::module_for_device(const std::vector<std::shared_ptr<mir::SharedLibrary> >&, const mir::options::ProgramO
<Saviq> ption&)
<Saviq> Dynamic exception type: boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<std::runtime_error> >
<Saviq> std::exception::what: Failed to find platform for current system
<Saviq> there seems to be some dependency missing, as apt was happy with that situation
<Saviq> dist-upgrade resolved it fortunately
<Saviq> but still, sounds like there's some link missing
<Saviq> and will cause boottest failures
<Saviq> because boottest is stuck on an image pre-mir-0.16 due to a broken NM
<AlbertA> Saviq: yeah.. it's because of the drivers
<AlbertA> Saviq: they are pulled by the seeds...
<AlbertA> Saviq: the issue is different platform need different drivers... and that's not exactly expressible in debian packaging deps
<alan_g> AlbertA: the assumption that cursors have contiguous buffers is spread over a lot of our code. @https://code.launchpad.net/~alan-griffiths/mir/fix-nested-cursor/+merge/272011/comments/686746
<AlbertA> alan_g: It's not the cursor but the underlying buffer stream buffer. in android you may get a stride that is bigger than the width of the image
<AlbertA> alan_g: but I see it's pre-existing... ummm I guess it may not work correctly in some phones
<alan_g> AlbertA: I'm willing to log it and fix it. Just think its wider than the code this MP touches.
<BlackJohnny> bschaefer, hi
<BlackJohnny> bschaefer, about the compiling of the cocos2d engine with mir for ubuntu touch
<BlackJohnny> bschaefer, i get this message "OpenGL version too old ..." and i suspect is an EGL message
<BlackJohnny> bschaefer, do i need also an EGL build with mir support?
<BlackJohnny> bschaefer, i also get this GLFW error GLFWError #65542 Happen, EGL: Failed to initialize EGL: EGL is not or could not be initialized
<bschaefer> BlackJohnny, well thats a good start
<bschaefer> BlackJohnny, not sure about the OpenGL version to old bit though
<BlackJohnny> i think egl gets somehow initialized later and not with gles... but lets ignore that
<bschaefer> BlackJohnny, but everything is compiling?
<bschaefer> you could try to run a GLFW3 example to make sure GLFW3 is working on mir
<BlackJohnny> yes
<BlackJohnny> did not compile samples, but I will do that thank you
<BlackJohnny> bschaefer, -- NOTE: Examples and tests require OpenGL
<BlackJohnny> bschaefer, not possible to link against GLES?
<BlackJohnny> bschaefer, actually i have compiled them and got the libGL not found msg
<BlackJohnny> bschaefer, compiled and executed
 * bschaefer thought it ran through egl
<BlackJohnny> bschaefer, for the record, i do not use the latest code because I had to revert to the version of mir that is installed with ota 7 (0.12?)
<bschaefer> maybe it just uses EGL to get a gl context
<BlackJohnny> ota6
<bschaefer> BlackJohnny, yeah it looks like it using EGL to get a GL context
<bschaefer> soo opengl can be used :(
<bschaefer> for those examples, maybe we can disable opengl
<bschaefer> in glfw when compiling
<bschaefer> GLFW_USE_EGL=ON
<bschaefer> BlackJohnny, but that should be turned on when you do -DGLFW_USE_MIR=ON
 * bschaefer wonders how he got the examples working on mir now looking at the cmake
<BlackJohnny> bschaefer, it is, i have checked
<bschaefer> since EGL=ON means no tests
<bschaefer> or examples
<bschaefer> actually
<bschaefer>     if (${GLFW_CLIENT_LIBRARY} STREQUAL "opengl")
<bschaefer> err
<BlackJohnny> i have changed that to gles2
<bschaefer> o i see
<bschaefer> BlackJohnny, yeah then the examples wont work hmm
<BlackJohnny> bschaefer, at runtime you mean because they get compiled
<bschaefer> BlackJohnny, this is a compile time check
<BlackJohnny> bschaefer, hmm i understand why u say that
<bschaefer> you can only have OPENGL OR glesv2 OR glesv1
<BlackJohnny> maybe those binaries ar from a previous build :S
<BlackJohnny> sorry
<bschaefer> BlackJohnny, check: src/glfw_config.h:80:/* #undef _GLFW_USE_GLESV2 */
<bschaefer> build/src/glfw_config.h
<bschaefer> to see what was selected
 * bschaefer does not have glesv2 selected
<BlackJohnny> bschaefer, you are right
<BlackJohnny> bschaefer, with glesv2 the samples are not built
<bschaefer> right, which is expected since the examples use OpenGL
<bschaefer> BlackJohnny, but you had that already right?
<BlackJohnny> bschaefer, i guess so ... with ldd i see the deps on mir
<bschaefer> i think you need
<bschaefer> -DGLFW_CLIENT_LIBRARY=glesv2
 * bschaefer tries
<BlackJohnny> bschaefer, i have changed this line: set(GLFW_CLIENT_LIBRARY "glesv2" CACHE STRING
<BlackJohnny> bschaefer, is the define a better way?
<bschaefer> cmake .. -DCMAKE_INSTALL_PREFIX=<PREFIX> -DGLFW_USE_MIR=ON -DGLFW_CLIENT_LIBRARY=glesv2
<bschaefer> BlackJohnny, now the issue, i've glesv2 built... but how do i test it hmm
<BlackJohnny> bschaefer, i've missed this error msg "libEGL warning: DRI2: xcb_connect failed"
<bschaefer> o... hmm try
<bschaefer> EGL_PLATFORM=mir
<BlackJohnny> building glfw?
<bschaefer> BlackJohnny, when you run it
<bschaefer> or just export EGL_PLATFORM=mir (env var)
<BlackJohnny> is it ok to modify the EXEC line in the desktop file with this? Exec=export EGL_PLATFORM=mir && bin/hexpuzzle
<bschaefer> BlackJohnny, you can make the exec in the desktop file point to an exe wrapper
<bschaefer> ie. hexpuzzle.sh
<bschaefer> which will run the export + bin/hexpuzzle
<BlackJohnny> ok
<BlackJohnny> bschaefer, Segmentation fault (core dumped) :)
<bschaefer> BlackJohnny, nice, soo hmm now why
<BlackJohnny> bschaefer, i will check wihtout the export to check if that is the real reason
<bschaefer> you can also just try
<bschaefer> EGL_PLATFORM=mir bin/hexpuzzle
<bschaefer> but hmm
<BlackJohnny> bschaefer, without that is gives the same errors as before
<bschaefer> well we will need to batch gdb
<BlackJohnny> bschaefer, but it might be that it works but then i implemented wrongly the mir connection or something
<BlackJohnny> bschaefer, same error as before = OpenGL related
<bschaefer> BlackJohnny, http://paste.ubuntu.com/12558073/
<bschaefer> BlackJohnny, well the mir connection is glfw3 doing
<BlackJohnny> bschaefer, i also do that with cocos2d to get the display parameters
<bschaefer>  --args  /usr/games/hexpuzzle $ARGS
<bschaefer> BlackJohnny, o open the mir sever?
<bschaefer> try to remove all that extra stuff for now (or just dont do anything)
<bschaefer> lets just try to get glfw main loop spinning
<bschaefer> even if it doesnt display anything
<BlackJohnny> bschaefer, /opt/click.ubuntu.com/hexpuzzle/0.1/bin/hexpuzzle: error while loading shared libraries: libglfw.so.3: cannot open shared object file: No such file or directory
<bschaefer> hmmm
<BlackJohnny> bschaefer, probably it does not check the lib path?
<bschaefer> BlackJohnny, you can force the path with export LD_LIBRARY_PATH in the *.sh
<bschaefer> but im not super good with clicks :)
<BlackJohnny> bschaefer, ok
<BlackJohnny> sec
<BlackJohnny> bschaefer, my .sh, is it correct?http://paste.ubuntu.com/12558221/
<bschaefer>  BlackJohnny as long as thats where the libglfw lib lives :)
<bschaefer> BlackJohnny, if it still fails, we'll have to use strace to check *where* its looking for the lib
<BlackJohnny> bschaefer, it is ok, I will continue myself because u did more than enough
<BlackJohnny> bschaefer, i will ask you when I get really stucked
<bschaefer> BlackJohnny, good luck!
<BlackJohnny> bschaefer, i suspect a missing dep
<BlackJohnny> will check
<BlackJohnny> bschaefer, nope ldd says everything is ok
<bschaefer> :(
<bschaefer> BlackJohnny, you can try ldd when you run it :)
<bschaefer> otherwise check strace when you run it
<BlackJohnny> bschaefer, hmm and it is not linked to libGL directly
<bschaefer> strace <exe>
<bschaefer> it shouldnt use libGL anymore (should be using gles2
<bschaefer> )
<BlackJohnny> bschaefer, that is ok but then the libGL is ref by EGL
<BlackJohnny> bschaefer, thank you and have a good day
<bschaefer> BlackJohnny, np, and you as well
#ubuntu-mir 2015-09-26
<BlackJohnny> hello
<BlackJohnny> anyone knows why libEGL would give such an error message on a device running ubuntu-touch? libEGL warning: DRI2: xcb_connect failed
<BlackJohnny> i assume that is an attempt to connect to X server
<anpok> yes
#ubuntu-mir 2016-09-26
<alan_g> anpok: is this likely to be another gtk-mir problem? https://bugs.launchpad.net/miral/+bug/1627697
<ubot5> Ubuntu bug 1627697 in MirAL "gnome-terminal crashes on resize" [Undecided,New]
<alf_> kdub: Is our IRC server down for you too, or is it just me?
<kdub> hmm, launchpad is down for me, so i'd guess outage
<alan_g> #launchpad says "Launchpad temporarily unavailable due to a network failure"
 * alan_g decides to try again after lunch
<RAOF> Firewall madness strikes again.
<NeKit> http://pastebin.com/DtHEr0U8
<NeKit> any idea what might be the reason for unity8 to fail? unity-system-compositor works though
<NeKit> the device is MTK Helio X10
<anpok> NeKit: kdub might have an diea..
<anpok> alan_g: I will take a look when the keymapping bug is in a better state
<kdub> NeKit, it seems to fail to map the buffer on the server side
<kdub> and then seems to have fencing problems
<kdub> maybe the usage bits go wrong somewhere
<kdub> not sure though
<NeKit> visually Ubuntu logo animation is playing fine though
<NeKit> but nested compositor won't start due to buffer error
<alan_g> anpok: thanks, I'm starting to feel that some spelunking tin gtk+ is needed.
<om26er> Hi! How can I query screen resolution from Mir ?
<anpok> om26er: as soon as you create a surface that is shown on screen you get surface_output_event
<om26er> anpok, is there a commandline way to get that ?
<om26er> or something pythonic ?
<kdub> mirout
<anpok> that even will tell you on which output you are displayed.. the via mir_connection_display_config you get access to the current setup...
<anpok> *event
<anpok> yes mirout
<NeKit> kdub, might it be related to https://code-review.phablet.ubuntu.com/gitweb?p=aosp/platform/frameworks/native.git;a=commitdiff;h=90c5a47b7c7f00c04b4b681f4b81aea90b606b6f?
<kdub> broken link
<NeKit> kdub, https://code-review.phablet.ubuntu.com/gitweb?p=aosp/platform/frameworks/native.git;a=commitdiff;h=90c5a47b7c7f00c04b4b681f4b81aea90b606b6f
<kdub> well, we don't really use the BufferQueue system in the ubuntu touch stack
<NeKit> any steps that might help to debug buffer mapping then?
<kdub> eh, I suppose I would start tinkering with mir::graphics::android::Buffer::write or read, and see if you can figure out a reason why its failing
<kdub> maybe tinker with the allocation bits passed in to gralloc
<NeKit> thanks
<kgunn> alf_: hey, i'm back...but only here :)
<kgunn> but  i was going to say, i added the core/kern snap to the drawing in order to
<alf_> kgunn: (me too, only here...)
<kgunn> show that those my have facilities needed by the u8-session snap
<kgunn> to actually control the screen
<kgunn> which i think is exactly what you were indicating
<kgunn> was missing from the display control i/f that is there today
<alf_> kgunn: that's one aspect, the other is actually allowing repowerd (or others) provide the dbus service over which apps can request keep-display-on
<kgunn> alf_: yes, exactly
<kgunn> alf_: so what may not be obvious, "an interface" (as in a single interface)
<kgunn> can actually provide the slot/plug to the system/server side & the plug/slot to the client side
<kgunn> alf_: mir interface is actually an example of this
<kgunn> alf_: in the mir interface anything under "permanent slot" is what the mir server side is needing from the system
<alf_> kgunn: looking...
<kgunn> anything on the "connected slot" is what the mir server may need to do on the client side, and "connected plug" is what the client needs from the server
<kgunn> alf_: ^
<kgunn> hope that makes sense
<alf_> kgunn: so, an interface can contain multiple slot/plug pairs?
<kgunn> alf_: yes...well, specifically 2
<kgunn> alf_: in my simple mind, i think of it as "top" pair and "bottom" pair architecturally
<alf_> kgunn: thank, your explanation + reading the mir snap helps.
<alf_> kgunn: my approach would be for the screen-inhibit-control interface to have a ConnectedSlot (allowing accepting dbus request) and ConnectedPlug (allowing sending dbus requests)
<alf_> kgunn: but no PermanentSlot/Plug
<kgunn> alf_: well, i think you've gotta drive that thru some testing....
<kgunn> e.g. can u8 session do what it needs to do ?
<kgunn> alf_:  when AlbertA and tedg ge the u8-session to the point where you can launch an app we'd need to try on an all-snaps system
<alf_> kgunn: yes, I need to test, but my point (and I could be wrong) is that screen-inhibit-control interface shouldn't know about how repowerd in particular implements this functionality (hence no PermanentSlot/Plug)
<kgunn> alf_: well...it's not that the plug/slot knows about implementation per se...it's just permissions
<alf_> kgunn: it leaks implementation details, e.g., PermanentSlot contains the paths that repowerd needs to access to provide the display-on functionality.
<alf_> kgunn: mir can get away with this because the interface is 'mir' not 'compositor'
<kdub> hmm, login.ubuntu.com isn't working for me, which means no hangouts
<alan_g> anpok: when you get headspace to look at gtk-mir, could you check all the miral bugs tagged with gtk-mir - AFAICT they are all in the toolkit
<bschaefer> alan_g, do you want me to tag vs put [ gtk ] in the name for bugs?
 * bschaefer wasnt really sure how you wanted to do the bug reports
<alan_g> bschaefer: tags are easy to search
<bschaefer> right, ill make sure to add those for future bugs
<alan_g> But really once we're sure they're toolkit related they should be logged upstream
<bschaefer> i agree
<alan_g> I've  not got around to that either
<bschaefer> (not sure where to log gtk mir issue?)
<bschaefer> is there a launchpad page for it?
<bschaefer> same with sdl2/sdl1.2 i suppose you *could* log it upstream for SDL2 (which is fine since mir lives in upstream SDL2)
<kdub> 22 MP's up for review :/
<bschaefer> kdub, partly my fault :|
 * bschaefer made a bunch of sub MPs
<bschaefer> but now depend on the ABI changes (which is blocked atm)
<kdub> partly everyone's fault :)
<bschaefer> :)
 * bschaefer starts reviewing
<dandrader> alan_g, how do I tell miral that no window should have focus? ie, I opened a indicator panel, so the foreground window should lose focus and it should not be given to any other window
<dandrader> when indicator panel closes, focus return to foreground window
<alan_g> select_active_window(Window{}) should do it
<dandrader> alan_g, if I understood its code, it will give focus to the previous window
<alan_g> Hmm. Let me look...
<alan_g> select_active_window(Window{}) should do it.
<dandrader> alan_g, right, that prev_window variable confused me....
<alan_g> It needs to notify focus loss to the previous window
<alan_g> bschaefer: anpok did point me where to log gtk bugs, butr I can't find it in my IRC log today
<bschaefer> alan_g, :) i can poke anpok later
<bschaefer> as if i can figure out if its miral (ill still report it for miral) then report it for gtk as well
<bschaefer> just so i can mark it as a dup of that (so others can follow it)
<alan_g> That sounds good
<anpok> ... i am out for a bit .. but will continue for a few hours later tonight
<anpok> bschaefer: bugzilla.gnome.org product:gtk+ component: Backend:Mir
<bschaefer> anpok, sweet thanks
<bschaefer> alan_g, ^
<alan_g> 8)
 * alan_g has lp:1625401 in gdb, with debug symbols
<bschaefer> o nice
<bschaefer> its not just X?
 * bschaefer only saw it on miral on x
<bschaefer> but doesnt mean it didnt happen on kms :)
<bschaefer> o strange on mir 0.24... ive not seen this on mir_demo_server (wonder if its something strange happening specifically in miral?)
<bschaefer> though ive not tried xmir on mir_demo_server
<alan_g> I hope to find out
<bschaefer> thats a good hope
<alan_g> bschaefer: found it
<bschaefer> alan_g, o nice, what was it?
<alan_g> https://bugs.launchpad.net/mir/+bug/1625401/comments/3
<ubot5> Ubuntu bug 1625401 in MirAL "Miral seems to spin at 100% and steals focus from everything until the server shutdown" [Critical,Confirmed]
<bschaefer> o interesting
<bschaefer> alan_g, just it just loop forever trying to find a not null session?
<alan_g> Trying to find a session that's either null or doesn't have a null default_surface
<bschaefer> interesting
<alan_g> I wish I could reproduce more than twice a day. But I've already stretched EOD, so I'll finish off tomorrow.
<bschaefer> yeah :( i was randomly hitting
<bschaefer> alan_g, o also the reason we couldnt remove that API
<bschaefer> is it would break ABI? (from my understanding?)
<bschaefer> (the public client API) since it was released in 0.24
<alan_g> No worse than changing the function to not work
<bschaefer> but we cant break public client ABI?
<alan_g> Both cases break clients that use it
<bschaefer> (the C abi)
<alan_g> the function
<kdub> any other takers? https://code.launchpad.net/~kdub/mir/eglimage-from-mirbuffer-android/+merge/305868 https://code.launchpad.net/~kdub/mir/passthrough-ipc-plumbing/+merge/305698 https://code.launchpad.net/~kdub/mir/fix-1626503/+merge/306480 ?
<bschaefer> kdub, ill attempt to review but a lot of the context is lost :)
<bschaefer> alan_g, hmm right but ... i would love to remove it but if we are going to break client ABI ... shouldnt we just go ahead and break it for a bunch of things we want to remove?
<kdub> bschaefer, thanks (and thanks to the other vogons who have reviewed those ones too)
<bschaefer> alan_g, ill ask you tomorrow, dont want to question to much here :)
<bschaefer> (since you're EOD)
<alan_g> bschaefer: I've pushed an (untested) fix, if you have time to try it...
<bschaefer> alan_g, yeah i can try to reproduce it all day
<bschaefer> and let you know
<alan_g> bschaefer: breaking the function affects exactly the same clients that removing it does
 * alan_g has to go
<bschaefer> alan_g|EOD, ...very true
#ubuntu-mir 2016-09-27
<duflu> anpok: Meet alan_g. He's thinking about putting more things in 0.24.1
<alan_g> anpok: For the record I said "maybe" https://bugs.launchpad.net/mir/+bug/1625401/comments/6 (and the fix hasn't even landed on trunk yet)
<ubot5> Ubuntu bug 1625401 in Mir "Mir server seems to spin at 100% and steals focus from everything until the server shutdown" [High,In progress]
<mterry> I'm hitting a problem when running unity8, mirserver fails to start (sometime after printing "Starting").  Setting MIR_SERVER_XXX_REPORT=log doesn't print anything extra -- or maybe I just didn't use the right XXX values.  Other ideas for getting a sense of where the error lies?
<mterry> (this is in a snap -- I just started hitting this problem after fixing XDG_DATA_HOME to be writable.  When it pointed at a readonly dir, Mir worked...  got any ideas why that might be?)
#ubuntu-mir 2016-09-28
<alan_g> greyback: are you happy with the answer? https://code.launchpad.net/~alan-griffiths/miral/workaround-1627697/+merge/306774
<greyback> alan_g: if it does the job, it'll do
<alan_g> greyback: I hope to remove it once gtk-mir is fixed, but as a stopgap...
<greyback> yep, that I understand
<greyback> it's well labeled as a workaround, so it's fine
<greyback> alan_g: question about https://code.launchpad.net/~alan-griffiths/miral/update-symbols-map-generator/+merge/306912
<greyback> for each release, do we need to copy in the symbol table into scripts/process_doxygen_xml.py ?
<alan_g> As it stands, yes
<greyback> ok. Just wanted to clarify that
#ubuntu-mir 2016-09-29
<alan_g> greyback: do you agree this is the right approach? https://bugs.launchpad.net/miral/+bug/1628630/comments/1
<ubot5> Ubuntu bug 1628630 in MirAL "miral should not change surface geometry because it got maximized" [Medium,In progress]
<greyback> alan_g: I do agree
<alan_g> thanks
<zzarr> hello! is it possible to run the 16.10 mir version on 16.04 with an overlay (or other ppa)?
<anpok> stable-phone-overlay gets the same mir version that is released to yakety
<anpok> https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/stable-phone-overlay
<zzarr> anpok, that works on my desktop?
<zzarr> E: The repository 'http://ppa.launchpad.net/ci-train-ppa-service/landing-031/ubuntu xenial Release' does not have a Release file.
<zzarr> ohh... that was another repo
<zzarr> yes the one you linked is fine
<zzarr> I should fix... but I feel that the release of Yakkey is to close to care
<om26er> Hello! How reliable is fbset under Mir, shall I use it in production ready code to query screen resolutions ?
<greyback> om26er: I don't think fbset would have anything to do with mir. fbset reads the geometry of the primary framebuffer, so the resolution of your "first" screen
<greyback> om26er: what are you wanting to do?
<om26er> greyback, I am trying to replace some code in autopilot that have hard-coded resolutions for some devices like mako, grouper etc. I want to make that dynamic by talking to the system
<om26er> since I want the code to work both under Mir and X11, I probably have limited options, but fbset seems to work under both
<greyback> om26er: if you want it display server independent, then yeah, fbset is best that I know of
<greyback> fbset no good with multiple displays tho
<greyback> MIR_SOCKET=/run/mir_socket mirout  only works if Mir running
<greyback> om26er: coud you ask the toolkit? Toolkit should know the display geometry
<greyback> danger with fbset might be on something like M10, whose display is rotated
<om26er> greyback, hmm, for reliability I could have a hybrid xrandr/mirout solution. though if I can talk to the toolkit that would be cleaner though it would only be tied to Ubuntu then.
<greyback> mode "1200x1920-0"   <- output on my M10
<om26er> bummer
<greyback> mirout reports the same
<greyback> we have to fix how rotation is reported
<greyback> unfortunately at the moment, I cannot provide you a reliable way of getting the actual screen geometry (incorporating rotation) - I fear for now you'll need a per-device rotation hack
<zzarr> would a Intel Joule 570x thrive with Mir?
<zzarr> my question is, would it be possible and a good idea to use Intel Joule as a platform for a phone?
<kdub> zzarr, if it has a mesa driver (probably) then its alright, you might need to backport the mir patches to the egl triee
<kdub> sorry, the mir patches to the egl bits in the mesa tree
<zzarr> okey
<zzarr> I'm thinking about designing a qwerty slider with a mouse-pointer feature
<zzarr> (propably a gaming stick for mouse)
<om26er> greyback, how can I check if the current display server is Mir ? Can I rely on /run/mir_socket mirout existence ?
<om26er> */run/mir_socket existence
<greyback> om26er: eh. That is a socket which can be located anywhere. On desktop, I think it at /tmp/lightdm-mir-0
<greyback> om26er: check if MIR_SOCKET env var is set, probably safest
<om26er> greyback__, it seems MIR_SOCKET is not in the environment at all
<bregma> om26er, what is you environment?
<om26er> I want to be very safe while detecting if the display server is based on Mir. For example it could be the demo server or unity8 server, is there lower level interface to check that
<om26er> bregma, I tested on Arale and kvm
<greyback__> om26er: it won't be set in the global env, but will be set in the env of any app that needs a display server
<bschaefer> hmm the MIR_SOCKET should be unset since the default socket location will be under XDG_RUNTIME_DIR
<bschaefer> you need MIR_SOCKET when you're running in kms/tty1 while X is running
 * bschaefer is also a little unsure about U8 :)
<om26er> I need to detect which display server is running in python/shell. There are quite a few ways to check if X the display server. For Mir, probably currently I could check if Unity8 is running.
<bschaefer> om26er, can you just attempt to connection to the mir server?
<bschaefer> if it fails then its not around?
<om26er> bschaefer, How to ?
<bschaefer> mir_toolkit/mir_connection.h:63:MirConnection *mir_connect_sync(char const *server, char const *app_name);
<bschaefer> though not sure about python
<bschaefer> the other thing is to check XDG_RUNTIME_DIR for a mir_socket or MIR_SOCKET
<bschaefer> XDG_RUNTIME_DIR/mir_socket should exist or MIR_SOCKET should be around
#ubuntu-mir 2016-09-30
<duflu> RAOF: Why doesn't MirSurfaceOutputEvent just give you an output to query with the output API? Are you reserving the right to virtualize the output (if it represents multiple physical outputs)?
<RAOF> duflu: I was actually going to add the MirOutput to it, but it turned out to be unnecessary.
<RAOF> (And kinda annoying to do)
<RAOF> It already contains the display ID, and you can look up the MirOutput by the id.
<duflu> RAOF: Maybe but I find myself adding new fields
<duflu> And it seems I shouldn't have to
<duflu> So I'm wondering if jumping to just MirOutput makes sense. Although the caller then has to annoyingly query current mode etc
<duflu> Actually we've already had this conversation. I now remember arguing for the status quo... as heterogeneous attributes of multiple monitors a surface is on should be massaged into a summary (which is not a single physical output)
<duflu> So maybe the current API is more future proof
<duflu> Just has more functions
<RAOF> duflu: If the fields are already exposed by MirOutput then they're unnecessary.
<RAOF> The client can look up the MirOutput itself.
<duflu> RAOF: That's true but similar to other parts of the client API, common use cases shouldn't be so complicated as requiring multiple function calls...
<duflu> I think we can do better but won't rush into adding more functions either
<duflu> There's no clear winner
<RAOF> As I said, I was going to add a MirOutput* accessor.
<RAOF> But (a) it doesn't make the API any more powerful, just more convenient, and (b) it was a bastard to try and plumb througgh.
<duflu> Agreed. And you lose the power to summarise multiple heterogeneous physical outputs in a single result
<RAOF> No, that's already gone.
<duflu> Only if you query the ID :)
<RAOF> Right, but if a client *does* query the ID we need to give them sensible results.
<duflu> Yep
<duflu> OK, current API stands
<RAOF> If we want to provide them with enough information to handle âyou're on two different outputsâ then we should just give them both the outputs.
<RAOF> (Plus an API for binding RenderSurfaces to output, so they can render their content twice and we display it appropriately)
<duflu> I'm ignoring that last part. Discussed it multiple times before and each time concluded it hurts toolkit compatibility too much to ask each frame get rendered multiple times
<RAOF> We'd only do it if a toolkit asked us for it.
<RAOF> (Plus, we control the relevant toolkits, so we'd basically only do it if *we* wanted it done)
<duflu> Target audience too small to worry right now
<duflu> Although on that subject... intel where is my 10-bit support?!
<alan_g> greyback: once we can land my current two MPs I think we should start thinking of a miral-0.2 release. What do you think?
<greyback> alan_g: sure. It has what we need in there
<alan_g> greyback: your comment suggests you're happy, your vote suggests you're not - which is it? https://code.launchpad.net/~alan-griffiths/miral/rework-handling-of-surface-state-changes/+merge/307163
<greyback> ah it was not a question, you did it
<alan_g> thanks
<alan_g> greyback: does this look right to you? https://code.launchpad.net/~alan-griffiths/miral/changelog-for-0.2.0/+merge/307295
<greyback> alan_g: those are the main enhancements anyway. I'll trust you collated all the bugs
<om26er> Hi! is there a way I can run mirout without proving the MIR_SOCKET var ?
<om26er> greyback, Hey! yesterday you were saying that if a client requires a display server under Mir session it has MIR_SOCKET env variable available. Does that mean python script wont be able to access that variable ?
<bregma> om26er, if the environment variable is available there is no reason a Python script can't get at it
<om26er> bregma, its not a global variable apparently
<bregma> there is no such thingv
<bregma> vogons, is there a command-line too that connects to the Mir server ^^?
<kdub> argv[1] of mirout accepts socket file
<alf_> bregma: how do you mean? We can mirping that connects,pings, and disconnect?
<bregma> om26er, there's a good answer for you:  the mirping tool from the mir-utils package
<bregma> after all, it;s not enough to check check that an environment variable is set
<om26er> bregma, will test mirping as my phone boots.
<om26er> kdub, alf_ I need to query screen resolutions sans xrandr with mirout, the problem is the location of the socket is not consistent in different environments. Is there a way to find the MIR_SOCKET ?
<kdub> I'm not sure how that gets set up, I thought something in upstart set the env variable
<alf_> om26er: I think that for unity8 the socket is always XDG_RUNTIME_DIR/mir_socket
<alf_> om26er: What kind of inconsistencies have you found?
<om26er> alf_, $XDG_RUNTIME_DIR/mir_socket does exit reliable but it does not work with mirout. on touch devices mirout works with /tmp/mir_socket
<om26er> and seems on unity8 desktop that path is different, something under the banner of lightdm
<om26er> also is it normal message: Could not connect to a display server: Failed to send message to server: Success
<om26er> success as in ?
<om26er> (that's result of mirping)
<bregma> that doesn't sound useful
<kdub> success! we didn't crash
<bregma> generally speaking if mirout doesn't connect to the server and get the right information, using something else that isn;t a part of Mir is not going to work any better
<bregma> mirout should know how to connect to the server i the absolute correct way
<om26er> MIR_SOCKET=/run/mir_socket mirping <-- that command gives "Could not create a surface."
<om26er> so that does sound like its working ?
<om26er> but the thing is... How do I dynamically find that mir_socket path :)
<kdub> that's probably a policy denial from u8
<kdub> and bregma it should know how to connect to the server, but it still has to know which server to connect to
<kdub> and... that error message is very confusing
<bregma> I would suggest trying to second-guess the mir server configuration is not going to bring a satisfactory level of success
<bregma> om26er, exactly what is your goal?
<om26er> bregma, I need to check which display server is running (X or Mir), then talk to their relevant utilities (xrandr or mirout) to query screen resolutions.
<om26er> this is needed for autopilot. I want a concrete solution not something on guesswork.
<bregma> you're looking for ways to get your solution to work, but you're not describing what it's a solution to so we're not going to give you useful answers
<bregma> that's why I'm asking what your goal is, not your solution
<om26er> bregma, the goal is to make autopilot input code ready for convergence.
<bregma> OK, but that's a little vague...  what problem are you trying to solve that involves the Mir server?
<bregma> are you trying to run autopilot tests in a pristine environment without all the session setup that goes into a Touch or Ubuntu session?
<bregma> under what circumstances will these tests be running, and how is the Mir server being run?
<om26er> autopilot currently saves hard coded screen resolutions for many touch devices, its not scalable as we add more and more devices. We want dynamically determine the device resolution.
<bregma> what device?  when is the test run and under what circumstances?
<om26er> this is important because we have code that relies on display resolutions along with windows geometry to determine if that window is visible on a given screen.
<om26er> bregma, Unity8 desktop for example, where different people have different screen resolutions on their laptops.
<om26er> current autopilot assumes that if you are on a desktop you are running X11, we need to change that.
<bregma> om26er, so this is for tests that will be run from a logged-in Unity 8 session?
<bregma> or does it need to run elsewhere?
<om26er> bregma, unity8 desktop and/or our current touch devices.
<om26er> maybe in kvm as well
 * alan_g muses: "the server" isn't always meaningful. Just now I happen to have two X servers and two Mir servers running onscreen. Which is "the server"?
<bregma> if you are in a Unity 8 session, then MIR_SOCKET is the environment variable that contains the address of the Mir socket.  It doesn;t make any difference what device you're running Unity 8 on.
<bregma> you can't just up and connect to the Unity 8 Mir server, however, because it accepts only authorized connections.
<om26er> bregma, only that $MIR_SOCKET is not in the environment :/
<bregma> Unity 8 in Mir is not X11
<bregma> om26er, if MIR_SOCKET is not in the environment, then you have a borked installation
<bregma> if you do not have MIR_SOCKET set, you;re not in a Unity 8 environment
<bregma> well, not a valid oner
<om26er> I tested on krillin and arale.
<bregma> how did you test?
<om26er> echo $MIR_SOCKET
<om26er> also `env` does not list it
<bregma> so, you opened a Terminal App instance and typed those commands?
<om26er> what about just `pidof unity8` ? if its running we are in Mir, what you say.
<om26er> bregma, ssh'd
<bregma> om26er, you're not in a Unity 8 environment if you ssh in
<bregma> try this: tr '\0' '\n' </proc/$(pidof unity8)/environ | grep MIR_SOCKET
<bregma> alan_g, greyback, HO?
<om26er> bregma, hmm, that does give UNITY_MIR_SOCKET that points to /run/mir_socket
<bregma> om26er, you will notice if you ssh in to any machine you do not have an X11 environment either, unless you use -X to tunnel your local server over the ssh socket
<om26er> bregma, is that the same for adb shell ?
<bregma> om26er, yes, that's the nature of Unix logins
<bregma> om26er, the Unity 8 mir server belongs to a particular login session, unlike X11 in which it runs as root and can be accessed by anyone
<bregma> there is a system-level Mir compositor also, but you're not allowed to connect to that, for obvious security reasons
<bregma> that said, I've successfully used the above tr command to bring up Mir-based applications through ssh on my Unity 8 desktop
<bregma> but Unity 8 only accepts authorized connections, it's not promiscuous like X11
<bregma> om26er, it looks like there have been some changes in the unity8.conf file (the upstart script that invokes Unity 8) and MIR_SOCKET does not show up in the unity8 process environment any more
<bregma> it does get expoerted to Unity 8 clients, however
<bregma> this still works reliably: tr '\0' '\n' </proc/$(pidof unity8-dash)/environ | grep MIR
<bregma> sorry, that should be grep MIR_SOCKET
<bregma> $ eval $(tr '\0' '\n' </proc/$(pidof unity8-dash)/environ | grep MIR_SOCKET) mirout
<bregma> Could not connect to a display server: Failed to connect: not accepted by server
<bregma> so, Unity8 still rejects the connection attempt because it's not authorized...  need to wrap that in a .desktop file.....
<bregma> hey vogons, did we not provide a D-Bus interface that can be used to query the display config of a Mir server?
<anpok_> there is only UnityScreen
<kdub> mir doesnt do dbus
<alan_g> bregma: Mir doesn't know about dbus
<anpok_> provided by usc
<bregma> I know we did discuss it last December
<bregma> well, it sounds like we have another topic for discussion at the upcoming sprint
<TheKit> why there is no arm64 in Mir PPAs?
<anpok_> there should be
<TheKit> https://launchpad.net/~mir-team/+archive/ubuntu/staging - only amd64, armhf and i386
<TheKit> is it somewhere else?
<anpok_> https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/stable-phone-overlay .. there you get the released mir versions
<anpok_> with arm64..
<anpok_> not sure why the staging ppa does not include arm64
<anpok_> oh reminds me that I have to fix usc
<bregma> just togled arm64 in that PPA
<bregma> it's just that no one went in and manually did that after the functionality was made available in Launchpad
<bregma> the staging PPA isn't really a part of the Mir development workflow so it did not go amiss
<TheKit> thanks
<bregma> TheKit, thank you for bringing it to our attention
#ubuntu-mir 2017-09-28
<RAOF> alan_g: https://code.launchpad.net/~raof/mir/fixish-wayland-keyboard/+merge/331520
#ubuntu-mir 2017-09-29
<alan_g> RAOF: http://voices.canonical.com/alan.griffiths/2017/09/29/custom-compositing/
<RAOF> bschaefer: https://code.launchpad.net/~raof/mir/actually-respect-seat-version/ Enjoy.
<bschaefer> RAOF, thanks!
