#ubuntu-mir 2014-02-17
<robert_ancell> duflu, could you have a look at https://code.launchpad.net/~robert-ancell/unity-system-compositor/usc-config-usr-share/+merge/200610
<duflu> robert_ancell: Will do
<robert_ancell> ta
<RAOF> Eat that, Jenkins!
<duflu> Om Nom Nom
<mlankhorst> morning
<alf_> mlankhorst: Hi!
<mlankhorst> hey
<alf_> rsalveti: Hi! Do we build mir on powerpc at all? We have a special rule for it in debian/rules but all of our binary packages are 'armhf i386 amd64 arm64'
<mlankhorst> don't think so
<alf_> alan_g: FYI, I am working on resolving the failure in MesaDisplayTest.drm_device_change_event_triggers_handler (seems like a race)
<alan_g> alf_: first I've heard of it. But OK
<alf_> alan_g: https://jenkins.qa.ubuntu.com/job/mir-team-mir-development-branch-trusty-amd64-ci/583/console , https://jenkins.qa.ubuntu.com/job/mir-team-mir-development-branch-trusty-amd64-ci/587/console
<alf_> alan_g: https://jenkins.qa.ubuntu.com/job/mir-mediumtests-runner-mako/502/console and https://jenkins.qa.ubuntu.com/job/mir-mediumtests-runner-mako/505/console
<alf_> alan_g:  RUN ] [mBufferStreamTest.stress_test_distinct_buffers
<alf_> terminate called after throwing an instance of 'boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<std::logic_error> >'
<alf_> what(): compositor_release given a non-compositor buffer
<alf_> Aborted (core dumped)
<alf_> alan_g: Could this be related to the SwitchingBundle etc changes?
<alan_g> alf_: I guess it is possible - want me to look?
<alf_> alan_g: If you have time, otherwise I will pick it up after I figure out the MesaDisplayTest.drm_device_change_event_triggers_handler failure.
<alan_g> alf_: I'll take a look
<alf_> alan_g: ok
<alan_g> alf_: FYI it is to do with those changes. I'm still working out why
<alf_> alan_g: ok, thanks
<alan_g> alf_: did you log a bug?
<alf_> alan_g: no
<alf_> alan_g: let me do so, for both CI issues
<alan_g> alf_: ok
<alf_> alan_g|tea: bug 1281145
<ubot5> bug 1281145 in Mir "Intermittent CI test failures in BufferStreamTest.stress_test_distinct_buffers" [Critical,New] https://launchpad.net/bugs/1281145
<alf_> alan_g|tea: bug 1281146
<ubot5> bug 1281146 in Mir "Intermittent CI test failures in MesaDisplayTest.drm_device_change_event_triggers_handler" [Critical,New] https://launchpad.net/bugs/1281146
#ubuntu-mir 2014-02-18
<RAOF> Alright. Let's see if I can wrangle a useful acceptance-test out of this...
<mlankhorst> ;)
<alan_g> alf_: I'm just trawling through our bugs and noticed 1218428 - I thought we'd enabled tests on clang a while back, but I seem to be wrong. Is there any reason they're not run?
<alf_> alan_g|lunch: no reason, AFAIK. clang+tests run fine for me locally.
<alan_g> alf_: Could you check (because I feel I must have missed something) - have we disabled the tests on the g++ desktop builds?
<alf_> alan_g: Not in our build system. It's just that mir-clang-trusty-amd64-build builds the source manually (doesn't do a package build), and never calls make test/ctest
<alan_g> Not the clang build
<alan_g> the g++ one
<alf_> alan_g: tests run fine in mir-team-mir-development-branch-trusty-amd64-ci
<alf_> alan_g: https://jenkins.qa.ubuntu.com/job/mir-team-mir-development-branch-trusty-amd64-ci/611/consoleFull
<alan_g> alf_: I'm missing something https://jenkins.qa.ubuntu.com/job/mir-team-mir-development-branch-trusty-amd64-ci/609/consoleFull
<alf_> alan_g: the tests are there, just lost in the noisy output :)
<alf_> alan_g: search for LGPL-required
<alan_g> Ah. Found it. thanls
<alan_g> *thanks
<alf_> alan_g: yw
<kgunn> mterry: just curious...what features? (for mwc)
<alf_> rsalveti: When you finish testing lp:~afrantzis/mir/platform-packages, and if it meets your needs, feel free to top-approve
<alan_g> alf_: don't your recent changes fix bug 1205389?
<ubot5> bug 1205389 in Mir "Mir is built assuming armhf is always android" [High,Triaged] https://launchpad.net/bugs/1205389
<alf_> alan_g: yes
<alf_> alan_g: although, the packaging still assumes that
<alf_> alan_g: (because the tests are still platform dependent)
<alan_g> Ack. I've assigned it to you anyway. ;)
#ubuntu-mir 2014-02-19
<RAOF> Ah, bollocks.
<RAOF> umockdev doesn't handle marking fds as readable, so poll/select/epoll etc don't.
<RAOF> Which is why I'm not getting any events.
<RAOF> HUZZAH!
<duflu> w00t? Bah.
<anpok> alf__: could you have a look at https://code.launchpad.net/~andreas-pokorny/mir/report-namespace/+merge/205577
<alf__> anpok: sure, I have it in my list for this morning
<duflu> alf__: Also https://bugs.launchpad.net/mir/+bug/1281938 ? :)
<alf__> duflu: I wonder if calling glFinish() on the client has any effect (it shouldn't be needed since we are swapping the buffers, but...)
<duflu> alf__: Yeah, haven't tried
<duflu> Now checking the old SessionMediator
<alf__> duflu: Also if this is not present on Android, it could indicate a problem with our Mesa mir egl
<duflu> alf__: Yeah, I'm completely unfamiliar with that
<duflu> Although we should have seen this bug sooner. Might have to try older Mesa
<duflu> alf_: Put a huge delay in the client. And the server still shows an old frame immediately, much sooner than the client has posted the frame. Somehow the compositor thinks it's been given a frame before it has
<alf__> duflu: strange
<duflu> Which is weird, because just asking the server it shows it doesn't post until it gets a next_frame. Seems like perhaps the client is next_frame'ing prematurely
<anpok> I believe mterry was looking into that topic last week
<anpok> or is that bug ticket the result of that?
<duflu> anpok: One is an enhancement request, the other is a bug :)
<duflu> So they're still separate for now
<duflu> alf__: Found the problem, but still don't understand the why. Mesa has decided that eglCreateWindowSurface will trigger a surface_advance_buffer immediately
<alf__> duflu: hmm, sounds like an issue in our mesa mir egl layer
<duflu> alf__: Yep. But I'm still surprised I never saw it before
<alf__> duflu: so, looking at https://github.com/RAOF/mesa/blob/egl-platform-mir/src/egl/drivers/dri2/platform_mir.c , we do a mir_advance_colour_buffer() @ line 201 when creating the egl surface
<alan_g> duflu: is that what is causing 1280842?
<duflu> alf__: Excellent. Well if it's needed then we need to tell BasicSurface to ignore the first 2, not the first 1. Otherwise fix Mesa
<duflu> alan_g: Looks possible. But I'd like to keep the enhancement request separate to the bug report
<alan_g> duflu: sure - especially until it is proven
<duflu> alan_g: I mean we wouldn't implement the enhancement if it's just a bug to fix
<alan_g> ack
<alf__> duflu: MirMesaEGLNativeSurface only has surface_advance_buffer)(MirMesaEGLNativeSurface* surface, 50                                    MirBufferPackage* buffer_package)
<alf__> duflu: which means that the only way mesa can currently get the buffer package is to advance the buffer
<duflu> alf__: Yeah I figured there was a reason. But still, buggy :)
<alf__> duflu: so we need to fix that, so that that advancing and getting the buffer package are separate operations, like in the client api
<alan_g> Or at least have it return the buffer it already has
<alf__> alan_g: what do you mean?
<anpok> at the first call of surface_advance_buffer let it behave like "get buffer package"?
<alan_g> alf__: it is a bad solution - but the first call to surface_advance_buffer() could just return the current buffer
<alf__> alan_g: well, I wouldn't want to use this as our final solution, but it makes a good quick test to validate our hypothesis
<duflu> Yep, that seems to be how software surfaces work around it
<alan_g> alf__: yep
<duflu> On the other hand, I can't see how that's safe. It requires buffer_depository->current_buffer() which dereferences an empty front() value (end())
<duflu> Oops, not end() but it should throw
<alf__> duflu: when the surface is created, it sends a buffer to the client, so that should be saved in the depository. Do you mean something different?
<duflu> Oh, I see. We do a dummy process_incoming_buffer on startup to ready the depository
<alf__> duflu: it's not a dummy operation, there is a buffer there for real.
<duflu> alf__: Semantics... Anyway I think I have a simple workaround for mirclient
<duflu> Sigh. That's enough. Net zero bug progress. One found, one fixed.
<alan_g> anpok: there are some merge conflicts to fix and then we can finally land: https://code.launchpad.net/~andreas-pokorny/mir/report-namespace/+merge/205577
<alf__> fginther: Hi! I want to try mir-mediumtests-trusty-touch/572 with a custom hook, is that possible? Basically, I want to enable valgrind on all architectures again for this build (i.e., remove the arch check in hook H15enable_testing), to see if everything works, before I push to trunk and amend H15enable_testing permanently.
<fginther> alf__, that job specifically isn't, but the mir-team-mir-development-branch-trusty-$arch-ci can be. That should provide a sufficient test
<alan_g> fginther: can we get the tests run on the clang CI build?
<fginther> alan_g, this one ? https://bugs.launchpad.net/ubuntu-ci-services-itself/+bug/1281591
<ubot5> Launchpad bug 1281591 in Ubuntu CI Services "Mir build with clang doesn't run tests" [Undecided,New]
<alan_g> fginther: yes
<alf__> fginther: yes, that would be sufficient. What's the best way to achieve that? (e.g. add a temporary script that enables valgrind or perhaps temporarily amend H15enable_testing, or ...?)
<fginther> alf__, go ahead and prepare it as an MP to pbuilderjenkins
<alf__> fginther: ok, I will add a new script so I don't affect other builds until we are sure this is fixed
<fginther> alan_g, i'll get back to you in a moment, in a meeting
<dednick> getting the following error on mir 0.1.5
<dednick> (process:13028): GLib-ERROR **: Creating pipes for GWakeup: Too many open files
<dednick> anyone seen it before?
<dednick> although i guess i'm not 100% sure it's mir that's causing it.
<alf__> fginther: https://code.launchpad.net/~afrantzis/pbuilderjenkins/mir-enable-testing-temp/+merge/207252
<fginther> alf__, thanks, I have a plan to test this today after lunch
<alf__> fginther: great, thanks
<kdub> alf__, trying to remember, why did our mg::GLContext not have a swap_buffers() method? kinda forces us to use eglGetCurrent*()
<kdub> trying to remember if that was intentional or not :)
<rsalveti> alf__: hey, there's just one issue with mir trunk currently, that is not working nicely in nested mode
<alf__> kdub: none of the mg::GLContext consumers (PixelBuffer,CompositingScreencast) need it
<rsalveti> alf__: and not x86 specific, got the same crash on armhf as well
<rsalveti> alf__: flashing latest on my n4 and will test that as well to see if I'm able to reproduce it
<alf__> rsalveti: that's with the android platform or mesa?
<rsalveti> alf__: android platform
<rsalveti> alf__: http://paste.ubuntu.com/6957542/
<rsalveti> this is with the armhf emulator
<rsalveti> alf__: and with the x86 one: http://paste.ubuntu.com/6952522/
<rsalveti> alf__: http://paste.ubuntu.com/6951930/
<kdub> alf__, I have a place where it would be useful to android... debating putting swap_buffers() in mg::GLContext or making a mga::SwappingGLContext interface
<rsalveti> alf__: in case you want to try the x86 emulator https://plus.google.com/+RicardoSalveti/posts/1u7HSYjF2He
<rsalveti> to use nested mode, just install ubuntu-touch-session from the archive (downgrade the package)
<rsalveti> as I had to disable it in a ppa for now, to get unity8 to work
<alf__> rsalveti: ok, can you please file a bug about this?
<rsalveti> alf__: sure
<rsalveti> alf__: bug 1282248
<ubot5> bug 1282248 in Mir "Unity8 crashes when using latest mir/android backend with system-compositor" [Undecided,New] https://launchpad.net/bugs/1282248
<rsalveti> kgunn: from the mir perspective, I guess this is the last remaining blocker for the x86 emulator
<rsalveti> kgunn: also know that without fixing this issue, we can't land current mir/devel, as it also affects every device
<rsalveti> just a heads up
<kgunn> rsalveti: ack,thanks...i'll get someone on it
<rsalveti> thanks
<fginther> kgunn, can someone help me with https://bugs.launchpad.net/ubuntu-ci-services-itself/+bug/1281591 ? I'm trying to figure out the correct build configuration to trigger running of the tests
<ubot5> Launchpad bug 1281591 in Ubuntu CI Services "Mir build with clang doesn't run tests" [Undecided,New]
<kgunn> racarr: can you help fginther ?
<racarr> kgunn: fginther: Hi :)
<racarr> so the default build options should enabe running the tests
<racarr> so the way I thought it was set up was just the amd64 job runs ctest
<racarr> and the clang job
<racarr> omits it
<racarr> RAOF: p.s. about my recent user data mp...I have this vague memory of you talking with Gerry
<racarr> and agreeing that surface user data was reasonable XD
<racarr> 1. Was that a dream.
<racarr> 2. Do you remember the context?
<fginther> racarr, thanks
<fginther> racarr, thanks, it appears to be working: http://s-jenkins.ubuntu-ci:8080/job/mir-clang-trusty-amd64-build-fjg/5/console
<RAOF> racarr: I don't recall that conversation with Gerry.
<RAOF> racarr: When would this have been?
<racarr> RAOF: Haha cest la vie
<racarr> I think in london
<RAOF> Ah.
<racarr> dont worry about all I remember
<racarr> is this image of you being like So some sort of user data...thats reasonable
<racarr> :p
<RAOF> I certainly discussed a bunch of things with Gerry, and I'm not generally opposed to user data thingies :)
<racarr> just collecting thoughts
#ubuntu-mir 2014-02-20
<RAOF> ...that point where you realise there's *more* umockdev work to be done :/
<duflu> RAOF: Sounds less than awesome
<duflu> At least from your perspective, having worked on it for so long already
<RAOF> I think what it actually means is that I'll do something else for a moment.
<duflu> Hey Mir's surface class hierarchy appears to be simpler and nicer than last time I mapped it out. Nice
<duflu> Eek. I just managed to delete 620 lines of code, and everything still works :)
<alf__> duflu: as long as they are not 620 lines of tests... ;)
<duflu> alf__: No, mostly interface definitions not used within Mir itself. Seems unity-mir uses it still so can't quite propose removing it yet
<duflu> But it's fun to see a large diff of red that doesn't break anything locally :)
<alan_g> duflu: are we intentionally delaying https://code.launchpad.net/~vanvugt/mir/server-abi-16/+merge/206842? or shall we top-approve?
<duflu> alan_g: Nothing has landed since 0.1.5 requiring the bump yet. Still all under review
<alan_g> ok
<duflu> It would be nice to have a point release without ABI bumps
<alan_g> What about https://code.launchpad.net/~andreas-pokorny/mir/report-namespace/+merge/205577
<duflu> alan_g: Yeah that would probably qualify ( bzr status -r1413..1414)
<duflu> alan_g: Given we will almost certainly have to change unity-mir multiple times for various SDK cleanups, it's probably a good idea to spread the changes out, without dumping too many of them in a single point release.
<duflu> Although that's not necessarily something we can completely plan
<duflu> It seems every time I find something that makes no sense at all in the Mir source, unity-mir is using it. It's just a matter of whether we can design a better way each time :P
<alan_g> duflu: Yep
 * duflu goes to find dinner, with a newfound aversion to spaghetti ;)
<alan_g> alf__: can this really be true? https://code.launchpad.net/~vanvugt/mir/fix-1281938/+merge/207123/comments/486466
<alf__> alan_g: no, replying
<alan_g> thanks
<alan_g> BRB (reboot)
<alan_g> alf__: are we happy with https://code.launchpad.net/~afrantzis/mir/valgrind-suppressions-armhf/+merge/207188?
<alf__> alan_g: I am waiting fo fginther to schedule the pre-merge tests
<alan_g> anpok_: alf__ - [not urgent] any preferences on the way forward? https://code.launchpad.net/~alan-griffiths/mir/make-ConfigurationOptions-a-dependency-of-DefaultServerConfiguration/+merge/206996
<anpok_> hm hm
<kgunn> anpok_: alan_g alf__ so who wants to have some mwc fun ? :)
<kgunn> ok, so seems like we might have a freeze/crash caused by the snapshotting interaction on the phone
<kgunn> phone is special due to the new right edge navigation
<kgunn> https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1281728
<alan_g> kgunn: what? (can it wait until after lunch?)
<ubot5> Launchpad bug 1281728 in unity8 (Ubuntu) "Unity8 random freeze on demo image" [Critical,In progress]
<kgunn> alan_g: yes...eating still allowed :)
<kgunn> looking at it, i wonder if alf__ might be the right person ?
<mzanetti> hey, I'm able to reproduce https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1281728
<ubot5> Launchpad bug 1281728 in unity8 (Ubuntu) "Unity8 random freeze on demo image" [Critical,In progress]
<kgunn> mzanetti: i think alf__ might be the right person...but he hasn't responded yet....but seems all the repro instructions are there
<mzanetti> I believe its the screenshotting functionality in mir
<kgunn> mzanetti: yep...they got prepped
<mzanetti> in case a screenshot is requested shortly after an app has crashed
<kgunn> stepping away for a.m. duties....
<mzanetti> who can help me with this?
<kgunn> mzanetti: he might be at lunch...he'll come back soon...as alan_g|lunch just left
<alf__> kgunn: I am investigating https://bugs.launchpad.net/mir/+bug/1282248 , but I can switch if it's more urgent
<ubot5> Launchpad bug 1282248 in Mir "Unity8 crashes when using latest mir/android backend with system-compositor" [High,In progress]
<mzanetti> ah
<kgunn> alf__: yeah....this one is a race on time unfortunately
<kgunn> thank you
<mzanetti> alf__: steps to reproduce are in the bug report, 3rd last comment
<alf__> mzanetti: which image should I get?
<mzanetti> alf__: in theory it should happen with trunk too. however, we've been using the MWC demo image. its easiest to reproduce there
<mzanetti> alf__: unitymirteam ML has instructions how to flash it
<mzanetti> comes down to:
<mzanetti> sudo add-apt-repository ppa:cwayne18/demo
<mzanetti> sudo apt-get update && sudo apt-get install mwcinstall
<mzanetti> mwc-flash
<mzanetti> alf__: ^
<alf__> mzanetti: ok, nexus 4 or 10?
<mzanetti> 4
<alf__> mzanetti: ok, starting process I will let you know if I need anything... don't leave town :)
<mzanetti> heh, ok
<alf__> mzanetti: so, the problem is that unity-mir is requesting a screenshot for a crashed app, and mir can't handle that?
<mzanetti> alf__: yes, afaics
<mzanetti> alf__: there is a time gap in between the app crashes and unity-mir gets informed about that
<mzanetti> alf__: and if unity-mir tries to update the screenshot in that timeframe it'll crash
<mzanetti> alf__: given that this should behave better for MWC I'd probably be ok if Mir just doesn't crash and returns an empty screenshot or whatever
<mzanetti> the proper solution would probably be to handle crashes faster
<alf__> mzanetti: ok
<mzanetti> not sure what's involved there tho
<alf__> mzanetti: do you know if this is pure mir 0.1.5 or whether it's mir/devel or ...?
<mzanetti> alf__: hmm... afaik it's whatever is in the regular image + this ppa: https://code.launchpad.net/~unity-team/+archive/phone-right-edge/+packages
<alf__> mzanetti: ok, thanks
<greyback> anyone else using nexus7 find if shell restarts, input breaks?
<mzanetti> greyback: I think I've seen this on the Nex4 today
<mzanetti> greyback: does it recover if you press the power button twice?
<greyback> mzanetti: will try that next time
<greyback> mzanetti: ah that helped
<mzanetti> greyback: so yeah. seen this quite often already today with the MWC image
<mzanetti> on the Nexus 4
<greyback> mzanetti: well shell just has to never fall over and we'll be fine :)
<mzanetti> heh, ack
<mzanetti> greyback: there are more reasons to that :D. While hunting another issue I found that there are cases where unity8 restarts, but leaves a previously running app around, eating 100% cpu
<mzanetti> have seen it a couple of times, but not way to intentionally reproduce it yet
<greyback> mzanetti: yeah that I see often too. When it looses the Mir server, the client sometimes does that
<mzanetti> alf__: leaving town for ~1h, ok?
<mzanetti> anything you need from me before?
<alf__> mzanetti: Do the instructions to reproduce this still apply?
<alf__> mzanetti: I read that you have a partial fix for this?
<mzanetti> alf__: yes, they still apply. especially if you didn't upgrade after flashing you don't even have the partial fix ye
<mzanetti> t
<mzanetti> alf__: if you did upgrade, just make sure to be fast enough after the app crashes.
<mzanetti> but its about 2 secs, so plenty of time
<alf__> mzanetti: ok
<alf_> mzanetti: kgunn: I can't get a crash! I open Calculator, swipe it away => back to apps screen, open Media Player, click on OK button. Then I see something both a "blank" app (white) and the Calculator app trying to get to the screen. I have tried swiping to the right both while this is happening and after things have settled, and everything works ok, I am back to apps screen.
<fginther`> alf_, I attached test results to your MP: https://code.launchpad.net/~afrantzis/mir/valgrind-suppressions-armhf/+merge/207188
<fginther`> alf_, the armhf build passed, the amd64 did not
<mzanetti> alf_: re
<alf_> fginther`: great thanks
<mzanetti> alf_: hmm... strange. crashes reliable here
<mzanetti> alf_: did you use the mwc-flash script to set it up?
<kgunn> alf_: so just to be sure...you're using the mwc-flash image ?
<alf_> mzanetti: kgunn: yes, perhaps because I got the image so recently, something has changed?
<kgunn> mzanetti: video maybe ?
<kgunn> of your methodology
<mzanetti> ack
 * kgunn is updating his n4
<kgunn> alf_: its possible...or we just buy you and your n4 a ticket to barcelona :)
<alf_> mzanetti: kgunn: unity8 7.84+14.04.20140218-1rightedge647~659~ubuntu14.04.1,  libunity-mir1 0.2+14.04.20140214-1rightedge176~180~ubuntu14.04.1
 * mzanetti compares
<mzanetti> alf_: yep, that's it
<alan_g> kgunn: I take it alf_ has taken the "fun"?
<alf_> alan_g: yes, but I cannot reproduce the issue...
<kgunn> alan_g: yes :) of course there's always fun to go around if you want some
<kgunn> ...uh, i think i need to reboot...somethings wonky...brb
<mzanetti> alf_: http://notyetthere.org/data/14020002.mp4
<alf_> mzanetti: ok, I think I can get it now (I rebooted)
<alf_> mzanetti: thanks
<mzanetti> alf_: not always, but most of the time you need to reboot after reproducing because the media player won't start at all any more
<alf_> mzanetti: an interesting observation... removing the apport package "fixes" the problem for me, try it and in the worst case we can use this as a workaround
<mzanetti> alf_: now that's quite weird...
 * mzanetti tries
<mzanetti> alf_: indeed... confirming you observation
<alf_> kgunn: managed to reproduce (needed a reboot for some reason), also found that removing the apport package """fixes""" this
<mzanetti> so I guess apport tracing the media player delays some threads in unity/mir to increase chances of this happening
<kgunn> alf_: ack...weird..
<kgunn> what made you try that ?
<kgunn> hunch ?
<alf_> kgunn: no, just I saw apport delaying the phone's startup :)
<anpok_> is this one of those apps get the wrong session object bugs?
<alf_> anpok_: hmm, I don't know, but may be related somehow
<anpok_> if the media player closes itself it might go through ApplicationManager::onSessionStopping - and it could then terminate the calculater of it was in "Starting" mode while the media player came up
<alf_> kgunn: mzanetti: anpok_: After installing the debug packages I am getting a different problem. *Every* time I try to swipe an app away, I get: http://paste.ubuntu.com/6965862/
<kgunn> greyback: dandrader ^
<alf_> kgunn: mzanetti: anpok_: perhaps that's related to what anpok_ suggested, i.e., apps get the wrong session object somehow?
<anpok_> there would be a fix for that one..
<anpok_> but if it happens everytime you swipe away it might be that there is just no session yet
<anpok_> not sure
<anpok_> where is updateScreenshot?
<anpok_> thats a different branch?
<greyback> alf_: this the nexus4?
<alf_> anpok_: I mean  every time I swipe away from an app, so there's at least that app's session
<alf_> greyback: yes, with mwc image
<greyback> ok, let me flash & see
<alf_> greyback: plus some -dbg packages
<greyback> I don't understand how -dbg packages would change anything
<kgunn> timing
<kgunn> ....or worse
 * kgunn remembers finding new code path in gpu vendor (who'll remain nameless) debug drivers
<alf_> kgunn: greyback: I will reflash to get a clean environment...
<fginther`> alan_g, can you take a look at this job and let me know if it's running the tests as you expect? http://s-jenkins.ubuntu-ci:8080/job/mir-clang-trusty-amd64-build-fjg/6/
<alan_g> fginther`: sure...
<kgunn> greyback:  just fyi...i'm gonna land the 4 mp's approved on unity-mir
<kgunn> https://code.launchpad.net/unity-mir/+activereviews
<greyback> kgunn: thanks
<alan_g> fginther`: it is running the tests (which is what I asked for) but not under valgrind (which is much less important as we do that with the other builds). So I'd be happy with this
<mzanetti> alf_: which version of unity-mir do you have when you see the "new" issue?
<greyback> anpok_: ah thanks for https://code.launchpad.net/~andreas-pokorny/unity-mir/fix-1281075/+merge/207375 ! I had it done myself, but no test.
<fginther`> alan_g, just for the record, adding the build tests increased the build time from 16 minutes to 75 minutes
<alan_g> fginther`: that's weird: "Total Test time (real) =  12.33 sec"
<fginther`> alan_g, ugh, I looked at the wrong field
<fginther`> build time was under 9 minutes
<fginther`> alan_g, sorry for the alarm
<alan_g> fginther`: np
<alan_g> kgunn: ^^
<kgunn> cool, times are coming down
<alf_> mzanetti: I don't know, I reflashed and I can't reproduce anymore...
<alf_> mzanetti: I will check if I may have updated to a newer version
<mzanetti> alf_: well, you need the ppa stuff as that one changes when screenshots are requested
<mzanetti> might well be that trunk never triggers this
<anpok_> greyback: after refactoring it got tempting simple to add the tests
<kgunn> mzanetti: just to be sure...the recipe uses unity-mir trunk & then merges your right edge changes no top
<kgunn> assuming that's the pkg you guys are talking about
<greyback> anpok_: tests badly needed, so it's very welcome. I see your refactoring branch too, will review next week once things calm down, but again, am delighted.
<kgunn> Saviq: any specific question about the freeze bug ?
<Saviq> kgunn, no, just saw that John posted another .crash file, was wondering if anything's happening
<kgunn> alf_ is looking into it...but now hitting the issue of getting a different bug/result when he builds debug packages
<kgunn> Saviq: i thikn the guys did determine that the crashes fire apport ...which in turn causes the timing to change such that mir freezes
<kgunn> point being...if people are loading crash files...those are seperate bugs i think
<mzanetti> Saviq: does building code in debug mode and calling "make install" prevent apport from kicking in?
<Saviq> mzanetti, it might prevent it from crashing, not from apport kicking in...
<mzanetti> which could explain why I didn't see the issue at all when I first tried ricmm's fix manually
<mzanetti> alf_: anything I can do to help you? can you reproduce again?
<alf_> kgunn: mzanetti: I have a workaround (solution?). I need to leave really soon, so please take care of it. It's a small patch, I will pastebin soon.
<mzanetti> alf_: awesome!
 * kgunn suspects alf_'s pastebin will say "remove apport" :P
<alf_> kgunn: lol
<alf_> mzanetti: kgunn: http://paste.ubuntu.com/6966425/ , it returns an empty Snapshot if we don't have a surface for some reason. It seems that  ApplicationScreenshotProvider in unity-mir can handle that, i.e., a QImage(nullptr, 0,0) is a valid (although null) image
<mzanetti> alf_: yep, should be safe from a QImage pov. I'll verify that
<mzanetti> exactly what I hoped for :)
<mzanetti> kgunn: what are we doing with this? merge to trunk of put into the ppa for mwc for now? I think trunk would make sense in any case.
<alf_> all: bye!
<mzanetti> byu alf
<mzanetti> -u+e
<kgunn> alf_: thanks! enjoy the evening
<mzanetti> kgunn: I need to leave too for today :/. Can you make sure this patch somehow ends up in the mir we use for MWC and first thing I'll do tomorrow morning is to verify if unity-mir can properly digest this.
<alf_> mzanetti: It works for me (TM) :)
<kgunn> mzanetti: yeah...i'll wrestle with it
<mzanetti> alf_: I'm thinking about generating a white surface in that case
<kgunn> should only take me 5x as long as you guys :)
<mzanetti> so crashed apps hang around as white rect instead of transparent surfaces blocking mouse input
<mzanetti> and then it'll disappear when apport is done with it
<mzanetti> kgunn: meh... you're right... let me propose a merge for it
<kgunn> mzanetti: no worries...
<kgunn> mzanetti:  i can do it...
<kgunn> mzanetti: i'll just create a recipe for it
<kgunn> mzanetti: reason being...don't quite feel comfortable promoting mir-devel right now due to some other stuff that's gone in recently
<mzanetti> kgunn: https://code.launchpad.net/~mzanetti/mir/dont-crash-when-shooting-invalid-surface/+merge/207507
<mzanetti> kgunn: ah
<mzanetti> kgunn: should I propose it against another branch?
<kgunn> mzanetti: propose against lp:mir/devel
<mzanetti> ack
<kgunn> mzanetti: so it will get picked up and landed probably next week....
<kgunn> just not today
<mzanetti> kgunn: ok, new one: https://code.launchpad.net/~mzanetti/mir/dont-crash-when-shooting-invalid-surface/+merge/207509
<kgunn> mzanetti: ta...i'll get right on the recipe
<kgunn> mzanetti: phone only right ?
<mzanetti> kgunn: yeah, trunk never seems to trigger this, otherwise we'd have noticed earlier I'd say
<mzanetti> but it shouldn't hurt (TM)
<mzanetti> maybe it even fixes some crashes we've seen very rarely
<mzanetti> ok. then. I'm off too
<kgunn> mzanetti: enjoy the evening
<mzanetti> kgunn: meh... need to help a friend moving
<mzanetti> carrying furniture down 4 floors
<kgunn> oh geeeze....please be careful!....don't end up like dandrader
<mzanetti> heh... I'll try
<fginther`> alf_, any comments on https://code.launchpad.net/~afrantzis/mir/valgrind-suppressions-armhf/+merge/207188 and the modified hook script?
<mzanetti> oh noes. I messed with the changelog.. will resubmit
<mzanetti> fginther`: alf has gone for today
<fginther`> thx
#ubuntu-mir 2014-02-21
<mterry> duflu_, heyo!
<duflu_> mterry! sup?
<mterry> duflu_, so maybe I don't understand C++ well enough, but the code in ./include/server/mir/compositor/scene.h doesn't seem to give access to CompositingCriteria...
<duflu> mterry: It's a bit ugly, but all designed to work with a filter/applicator interface. I think all those are defined in scene.h?
 * duflu checks
<mterry> duflu, it looks like they *take* a criteria, not give one
<duflu> mterry: All you need is a Scene object. Then... scene->for_each_if(filter, operator) to do your rendering. The instances will be provided by the underlying scene implementation in Mir
<duflu> That's a bit of an ugly way to iterate though. I'd like to replace it with something else
<duflu> You will need to create implementations of FilterForScene and OperatorForScene :P
<mterry> duflu, oh I see.  I write a filter, and the for_each_if will call operator() giving a criteria
<duflu> mterry: Yep. The instances implementing those interfaces are hidden, but you will get called with them
<mterry> duflu, then I also need to get a Rectangle for the surface to pass the criteria...
<mterry> this is really roundabout
<duflu> mterry: Your display_buffer->view_area() is good for that
<mterry> ah ok
<duflu> mterry: I know. I found it this way :)
<duflu> "It was like that when I found it"
<mterry> duflu, :)
<duflu> mterry: So a minimal filter would call should_be_rendered_in
<mterry> duflu, so my Filters get called...  But how do I match a filter call to a given surface?
<duflu> mterry: You can't right now. We all want that fixed up and I think kdub is most likely to do it soonest
 * mterry is trying to imagine how I use these pieces together
<duflu> mterry: Our immediate desire is to replace both the CompositingCriteria and BufferStream parameters with some *Surface interface which implements both. We just need to restructure the Surface class hierarchy
<mterry> Whoops, disconnected.  duflu, don't know where we stopped
<mterry> <mterry> duflu, yeah, so I can iterate and ask the criteria, but without being able to differentiate between what the various iterate calls *mean* (i.e. what surfaces they match), I don't know how that API is useful to a 3rd party
<duflu> mterry: You missed nothing
<mterry>  hmm
<mterry>  maybe I'm missing a piece of the puzzle
<mterry>  I guess the Operator sees a BufferStream..
<mterry>  But that's not super informative
<mterry> duflu, cool
<mterry> duflu, so kdub is working in this space?
<duflu> mterry: Even the built-in renderer treats it as a TODO. I had to use "&criteria" as a dummy surface ID :(
<duflu> mterry: Better check with kdub. He's always likely to get pulled into more pressing Android work
<mterry> kdub, if I don't get to you first, poke me tomorrow!
<mterry> duflu, thanks so much!
 * mterry is very slowly grokking Mir
<duflu> mterry: No problem. Sorry you're stuck on something that we already planned to redesign :/
<RAOF> Ok. That should really, truly, absolutely be the last umockdev merge request in a while!
<mlankhorst> RAOF: erm can you now at a mainloop api like in pulseaudio? :P
<duflu> So many things I'd like to move around. But the weekend is in the way.
<duflu> Till next time
<alan_g> alf_: were you looking at an intermittent failure in MesaDisplayTest recently? https://jenkins.qa.ubuntu.com/job/mir-clang-trusty-amd64-build/1007/console
<alf_> alan_g: yes, but it was a clean failure, no exceptions, and fixed (by all appearances) by r1401
<alan_g> alf_: thanks, will try to reproduce this one then
 * alan_g reproduces intermittent failures in MesaDisplayTest.drm_device_change_event_triggers_handler
<alf_> alan_g: exceptions, or other test failure?
<alan_g> Segmentation fault (core dumped)
<alan_g> I'll look deeper after lunch
<alan_g> alf_: still happy with the updates to https://code.launchpad.net/~alan-griffiths/mir/make-ConfigurationOptions-a-dependency-of-DefaultServerConfiguration/+merge/206996?
<alf_> alan_g: looking
<alf_> rsalveti: Hi! I am trying to run the x86 emulator to get more information about https://bugs.launchpad.net/mir/+bug/1282248 , but all I am getting is a blank screen in the emulator
<ubot5> Launchpad bug 1282248 in Mir "Unity8 crashes when using latest mir/android backend with system-compositor" [High,In progress]
<alf_> rsalveti: Any ideas?
<rsalveti> alf_: hm, getting a black screen with my guide?
<rsalveti> *blank
<rsalveti> alf_: are you using it with a proprietary gl driver at your host?
<alf_> rsalveti: yes, your guide, free drivers, radeon and intel (tried with both)
<rsalveti> alf_: weird, trying it again locally
<alf_> rsalveti: I do get related errors: http://paste.ubuntu.com/6971401/
<rsalveti> oh, alright
<alf_> rsalveti: hmm, I think I need to install the i386 mesa drivers (running on amd64)?
<rsalveti> alf_: yes
<alf_> rsalveti: isn't there an amd64 version of this?
<rsalveti> alf_: not yet
<rsalveti> there will be sson
<rsalveti> *soon
<alf_> rsalveti: ok
<alf_> rsalveti: works now great!
<rsalveti> alf_: great!
<alf_> rsalveti: does the image have persistent storage?
<rsalveti> alf_: any idea of what might be wrong with that bug?
<rsalveti> alf_: yes
<alf_> rsalveti: I have found the exact commit that introduces it (on a real device at least), but the armhf backtraces I can get are less than helpful...
<rsalveti> alf_: yeah =\
<alf_> rsalveti: the commit is the one that changes the client platform to be dynamically loaded instead of built-in, not sure why that would cause a failure, though. Running nested tests with mir_demo_* works...
<alf_> rsalveti: anyway, hopefully the x86 backtraces will be more helpful
<rsalveti> alf_: yeah, it's quite weird, at least the x86 image doesn't have any issue with android TLS
<alf_> fginther: Thanks for preparing the jobs. I realized that this is something I could by myself in the future if I want to try something, if I branch the hooks, right?
<fginther> alf_, yes, I did have to configure the job first to allow the hooks, but once they are there you can substitute in your own branch / hooks for testing
<kdub> mterry, ping
<mterry> kdub, hello!
<mterry> kdub, I had some questions for you.  Is that what this ping is?
<kdub> yeah, saw some chatter about the surface stack iteration stuff
<mterry> kdub, so my ultimate goal is to be able to tell when a session/surface actually has posted their first frame to render.  This has been harder than I'd thought
<mterry> kdub, recently I tried to go down the CompositingCriteria route
<mterry> kdub, but it isn't exposed in a particularly meaningful way
<mterry> kdub, but I was told you were working in that space?
<kdub> well, I have to revise the surface stack to enable android bypass/overlays
<kdub> the interfaces now have been out-grown by the way they are being used, and need some reassessment
<mterry> kdub, well.  I am highly interested in being able to tell when a (at least first) frame has been rendered
<mterry> kdub, what is priority of your work?  Like, how likely is it to happen soonish?
<kdub> mterry, that's a bit different area than refactoring the surfacestack/compositingcriteria system
<mterry> kdub, well, I can probably get what I need from actual access to CompositingCriterias and being able to match them to a surface
<kdub> let me see if there's a way to do that in the public interfaces
<kdub> or if there's a quick way to add a fn
<mterry> kdub, because they have the should_be_rendered_in() call
<mterry> kdub, and I can iterate over the CompositingCriterias via the Scene object and its for_each_if calls
<mterry> kdub, but I can't actually tell which Surface they each match with
<kdub> thats kinda a heavyweight solution though, as we lock the surfacestack during the iteration over the surfaces
<mterry> kdub, well I'm all for better ways.  It's literally the only way to get at Criterias right now though
<alan_g> kdub: also, that locking is something we plan to rip out - along with the associated code
<kdub> alan_g, sure
<kdub> mterry, what is the larger problem? (eg, trying to coordinate some animation or something)
<alan_g> I've still not understood why waiting for swap_buffers(Not(nullptr)) doesn't work
<alan_g> duflu found a Mesa bug while looking into this. But mterry is on the android drivers
<mterry> alan_g, there are internally several buffers posted before the client gets to run
<mterry> alan_g, so maybe that's just a bug.  But it's not usable at the moment
<mterry> alan_g, that's all in the bug
<alan_g> mterry: yeah, I don't understand why
<mterry> alan_g, meaning that you think it's a bug that Mir is swapping buffers so early?
<mterry> kdub, https://bugs.launchpad.net/ubuntu/+source/mir/+bug/1280842 explains my ultimate goal in all this
<alan_g> mterry: mir should only be getting a buffer once it has been drawn. I don't know exactly what your scenario is doing to send buffers from the client before they are ready.
<ubot5> Launchpad bug 1280842 in mir (Ubuntu) "[enhancement] Need a method of hiding surfaces until they are ready to draw themselves" [Medium,Opinion]
<mterry> alan_g, it's not even *my* scenario. It's just a client calling mir::run_mir
<mterry> alan_g, something about constructing/running a DisplayServer causes 4 buffers to be swapped
<alan_g> mterry: so this client is a nested server?
<mterry> alan_g, yeah
<mterry> alan_g, (this is all in the context of USC which just deals with nested servers)
<alan_g> mterry: I strongly suspect a bug in the nested code then
<alan_g> With a second possibility that the android client code is the cause
<alan_g> *internal* client
<mterry> alan_g, would that be work-around-able?
<alf_> alan_g: mterry: Hmm, when the compositor starts up it triggers itself, each trigger being 3 compositings. In a nested server, swapping the buffer when compositing means sending the buffer to usc.
<alan_g> And the 4th could be something like the Mesa "advance_buffer" bug?
<alf_> alan_g: yeah
<mterry> I do only get 3 if I hide() the surface first, FYI
<alan_g> mterry: that makes sense
<kdub> iirc, android shouldnt do that 'advance_buffer'
<kdub> rather, the same sort of bug as the Mesa "advance_buffer". it does request a buffer on eglCreateWindowSurface, but it should get the buffer associated with the surface creation
<kdub> (nexus 10 does something different)
<alan_g> kdub: ok, but I'll buy alf_ explanation - we need to something different when compositing in nested mode.
<alan_g> If no-one else grabs it I can have a go on Monday
 * mterry hugs alan_g
 * alan_g blushes
<mterry> alan_g, so the idea would be that USC could call hide(), watch for buffer swaps, and when it gets a non-null one, show() again?
<mterry> or maybe it wouldn't need to call hide if it weren't getting buffer swaps in the first place
<alan_g> mterry: yes, nested clients ought to behave like regular ones
<mterry> alan_g, sounds perfect
 * alan_g decides to cut & paste the above discussion into the bug
<greyback> why are surfaces visible if client hasn't drawn to them yet? To me makes more sense for mir to tell a shell that a Surface was created, only when that surface was drawn to by the client
<greyback> not when the surface buffer was allocated for that client
<greyback> anyway, gotta run, good weekend all!
#ubuntu-mir 2015-02-16
<duflu> greyback: Happy New Week. Do you care to test the latest cursor fix or shall we just land it and see? :)
<greyback> duflu: am happy to test
<duflu> greyback: https://code.launchpad.net/~andreas-pokorny/mir/fix-1417581/+merge/249636
<greyback> duflu: great, thanks for pointing it out
<mlankhorst> I'm having some instability with Xmir on android
<mlankhorst> it seems to be regardless of egl driver, are there any other clients that stress EGL on mir?
<mlankhorst> .. is multi-threaded EGL even allowed with hybris? :P
<tsdgeos> racarr: seen last comment in https://code.launchpad.net/~mir-team/qtubuntu/port-to-mirclient/+merge/245164 ?
<kgunn> tsdgeos: americans are off today
<tsdgeos> k
#ubuntu-mir 2015-02-17
<mlankhorst> o/
<willcooke> hi mlankhorst
<willcooke> So folks - we have a problem
<willcooke> Xmir on the N7 using EGL causes reboots of the device
<willcooke> It works fine and dandy on my x86 laptop
<willcooke> and it's stable on my BQ phone too
<mlankhorst> and SW mode doesn't ignore the alpha channel if you specify XRGB format :/
<mlankhorst> willcooke: it's stable now with the separate thread for flipping disabled right? before it was slightly unstable?
<willcooke> So we need some help to trouble shoot this ASAP - it's getting to be quite important
<willcooke> mlankhorst, on my N7 with the Xmir binary from your website I can cause a reboot by simply trying to resize the window
<willcooke> *every time*
<mlankhorst> I mean on the BQ phone
<willcooke> ah, right - I'll need to update my phone to the latest bin.  please hold :)
<mlankhorst> if it was stable before don't worry
<willcooke> oki - still interested to see if I have similar problems - hopefully not
<mlankhorst> but I was getting corruption when I moved flipping to a separate thread.. still wish there was a way to do so..
<willcooke> mlankhorst, latest Xmir binary on phone doesn't update the screen,  I just have the LO splash screen
<mlankhorst> oke :/
<willcooke> mlankhorst, is there a hacky workaround for the transparency issue if we need it?
<willcooke> I'm thinking that I can use -sw mode if I have to - as long as it's not see-through  :)
<mlankhorst> I tried, need to understand how the initial background is blanked better..
<willcooke> oki
<mlankhorst> -sw mode has no -2x support or rotation
<willcooke> mlankhorst, can live without it
<micahf> hey, i'm having trouble with multitouch in chrome on 14.10
<micahf> two finger gestures work so-so (scroll, pinch zoom), but i can only get one touch event!
<micahf> i'm using a lenovo x220t convertable laptop
<micahf> the thing is, in ubuntu 13.10, I was able to use multitouch events with an acer w700 and aura builds of chrome
<micahf> i've done lots of searching and am baffled!!!
<micahf> maybe this has nothing to do with Mir!!!
<ogra_> most likely :)
<ogra_> perhaps someone in #ubuntu-x has a clue
<micahf> ogra_: thanks :)
<micahf> ah, x is running on top of mir in 14.10?
<ogra_> no
<ogra_> Mir isnt used at all in a default install
<ogra_> only in the desktop-next builds
<micahf> ohhh :) got it!
<micahf> ah, i will avoid those builds for now!
<micahf> good luck with them though
<ogra_> (on phones/tablets it has always been the default though)
<micahf> ogra_ is there a way to install desktop-next along side desktop-now
<micahf> (it's probably not called "desktop-now", but you know what i mean)
<ogra_> i dont think thats safe, no
<ogra_> you could try desktop-next in live mode i think
<ogra_> juts from usb stick
<micahf> ogra_ yeah that sounds much safer.  it's especially unsafe because I only have one computer and am traveling at the moment
<davmor2> ogra_ juts from a usb stick......man you must be the hide and seek champ.......that or it's the worlds biggest usb stick ;)
<ogra_> every usb stick juts, no ?
<davmor2> yeah but not every usb has an ogra_ jutting from it :)
<ogra_> haha
<racarr> Morning!
<greyback_> racarr: greets! Mind checkout out my comment here: https://code.launchpad.net/~mir-team/qtmir/port-to-event-2.0/+merge/248067
<greyback_> suspect a merge went bad somewhere
<racarr> greyback_: So this branch seems to revert thementioned branches?
<racarr> Weird...thanks
<racarr> will get on it after breakfast
<greyback_> racarr: yeah, but it screws up the history, files appear deleted & recreated
<greyback_> I wasn't able to fix that
<racarr> greyback_: I think there isn't a way to fix it right
<racarr> that is the "history"
<racarr> anything else is a rebase...
<racarr> well so I mean there are various ways
<racarr> but not encouraged?
<racarr> greyback_: e.g. the only thing I know todo ismerge the other branches and resolve --take-other
<greyback_> worth a shot I guess
 * greyback_ has to run for a bit
<racarr> bye :)
<racarr> Has anyone ever seen a valgrind invalid read in "readdir"
<racarr> https://jenkins.qa.ubuntu.com/job/mir-vivid-amd64-ci/963/console
<racarr> (can search for readdir in the full log)
#ubuntu-mir 2015-02-18
<alan_g> duflu_: @scene-can-identify-surface-under-cursor would you be happy if I renamed the function surface_visible_at()?
<duflu_> alan_g: Don't think so. Because the answer is incorrect if that point has transparent pixels (which are meant to be communicated via input_area_contains in theory)
<alan_g> But for click select, drag and resize I want to include decorations - not just the input area
<alan_g> Or do I misunderstand "input area"?
<duflu_> alan_g: You mean the usual Alt+mouse?
<alan_g> yes
<duflu_> alan_g: Unfortunately I think tiling would require the rectangle and free floating windows should honour the shape properly, maybe
<duflu_> alan_g: I think input_area is meant to follow the non-transparent shape of the surface. If so use that. But it might be meant for something else...?
<duflu_> You can't automate keeping them in sync because that would involve reading all pixels on every frame
<duflu_> So the client is meant to do it traditionally, somehow
<duflu_> OK, that's late enough
<alan_g> anpok_: got your answer now? https://code.launchpad.net/~mir-team/mir/add-keymap-change-support/+merge/248719
<anpok_> alan_g: yes
<racarr> text standup: Moving pointer enter/exit event synthesis from input dispatcher to pointer controller.
<racarr> to fix 2 remaining bugs
<racarr> one of which includes...emittingpointer enter/exit events in response to sce3ne changes
<racarr> instead of input changes
<racarr> the input dispatcher doesnt even track the location of the cursor as it stands though
<racarr> so decided to go for thissplit rather than add another input dispatcher responsibility
#ubuntu-mir 2015-02-19
<alan_g> alf_:  are you looking into lp:1423591?
<alf_> alan_g: Not yet
<alan_g> Should I make time for it? Or are you planning to fix?
<alf_> alan_g: I was planning to pick it up tomorrow, if no one else had picked it up by then.
<alan_g> That's fine with me. (I have learnt to hate the debian/* files.)
<kgunn> lol
<alan_g> AlbertA: are you satisfied with the answer on https://code.launchpad.net/~alan-griffiths/mir/scene-can-identify-surface-under-cursor/+merge/249696?
<AlbertA> alan_g: yeah
 * alan_g waits for racarr ...
#ubuntu-mir 2015-02-20
<duflu> Hmm, could it be Mir 0.11 finally supports double buffering properly?
<alan_g> duflu: does this address your concern? https://code.launchpad.net/~alan-griffiths/mir/scene-can-identify-surface-under-cursor/+merge/249696/comments/620845
<duflu> alan_g: Don't know :)
 * duflu --> dinner guests
<duflu> Assume yes
<alan_g> LOL have fun!
 * alan_g wonders whether to fix the current focus management APIs or just build a replacement. (And if there's really a difference.)
<alan_g> alf_: should I merge lp:~afrantzis/mir/versioned-platform-libraries into my test branch as an additional test?
<alf_> alan_g: https://code.launchpad.net/~afrantzis/mir/versioned-platform-libraries-plus-server-abi-bump/+merge/250441
<alan_g> :)
<MacSlow> Greetings everybody!
<MacSlow> I'm wondering how how such a mir-common error http://pastebin.ubuntu.com/10325163 is
<racarr> text standup: Still working on my branch to shuffle some of the InputDispatcher responsibilities out (and fix the remaining pointer crossing event bugs)
<racarr> still dealing with SurfaceObserver list corruption there
<racarr> ...uh kind of the same situation with add-keymap-change-support except I can only reproduce in jenkins so I only get about 20-30 minutes on it a day
<alan_g> alf_: I've just discovered that I can kill X by running mir_performance_tests nested in demo server and killing it with Alt-F4 - that isn't to be expected is it?
#ubuntu-mir 2016-02-22
<zzarr> hello!
<anpok_> tjaalton: hm I am trying your vulkan binaries..
<anpok_> and I have a problem within X ..
<anpok_> vkcube and other examples I pulled complain that there is no DRI3 support..
<anpok_> but I actually rebuilt the most recent intel xorg video driver .. enableing dri2 in debian/rules..
<anpok_> did I miss a step?
<anpok_> dri3 of course..
<anpok_> stuff runs fin on top of drm/kms though
<anpok_> zzarr: any news form your endevaours?
<zzarr> anpok_, it's hard to understand what parts of the kernel I need to make an Android container work/run
<anpok_> .. write a detailed description when you figure that out..
<anpok_> i want to try that too next time i get some more free time..
<zzarr> right now it's more like if I figure it out
<anpok_> :)
<zzarr> is there a more detailed block diagram of the kernel/libhybris and all of it?
<zzarr> anpok_, what would be the best approach? trying with the Android driver or wrap the freon driver?
<zzarr> if the question is not clear by wrapping the freon driver I mean making a Mir-server that runs on top of freon
<anpok_> zzarr: well you need to solve the problem of transfering a rendering result from a client to the server.. if the freon driver has capabilities to do that - then this will be the more intersting approach because you get to write some code..
<tjaalton> anpok_: you missed reading the ppa description :)
<anpok_> my (maybe outdated?) understanding of the chrome os rendering system is that they only have a single process doing the actual rendering with the gpu driver.. the other processes just use an inter process version of GLES/EGL and maybe some 2D drawing library
<zzarr> anpok_, I think so too I would get a much deeper knowledge and it would work on any Chrome OS device (Intel/ARM alike)
<anpok_> zzarr: but yeah that would also be an interesting integration task.. let USC do all the rendering..
<anpok_> tjaalton: yeah I am good at that
<zzarr> anpok_, I'm still not familiar with all the terms, what does USC stand for *feeling like I should know*
<anpok_> unity-system-compositor the system compositor in the default ubuntu touch setup
<anpok_> usually the thing that posts to screen
<zzarr> anpok_, okey
<anpok_> with kms/android drivers it just posts the buffer of the nested server to screen
<anpok_> so it is a process that runs a mirserver
<zzarr> anpok_, is that a good approach here too?
<anpok_> what do you refer to:
<anpok_> ?
<anpok_> ah you mean having usc there too ..
<anpok_> yes you need something with the necessary permissions to access the gpu.. and the screen.. and you want to allow as processes as possible
<anpok_> thats actually even safer than with kms/android drivers..
<zzarr> anpok_, good call
<anpok_> *as few processes
<zzarr> anpok_, could you help me figure out  where to start? (I'm still new to graphics in general)
<anpok_> hm first I would try to figure out where and how chrome os sets up rendering with the drivers you have..
<anpok_> then try to get that workin outside of chrome os..
<anpok_> then take that as a basis for a mir graphics platform
<zzarr> anpok_, Is the lack of console a problem or is that bypassed if I get freon running?
<anpok_> hm no i do not think so..
<anpok_> it might just make stuff harder to try out :)
<zzarr> I have a kernel with console right now, so I don't think that would hinder anything
<anpok_> i guess figuring those things out will keep you busy for a while ... then you have to look into getting the IPC services working..
<anpok_> and after that you might have to make some changes to mir to get all of that working as a graphics platform
<zzarr> IPC?
<anpok_> interprocess communication
<zzarr> okey, yes
<anpok_> http://www.chromium.org/developers/design-documents/displaying-a-web-page-in-chrome
<zzarr> thanks anpok_
<anpok_> https://sites.google.com/a/chromium.org/dev/developers/design-documents/gpu-accelerated-compositing-in-chrome..
<anpok_> oops
<anpok_> strip the last two dots
<zzarr> thanks again :-)
<zzarr> anpok_, the second link is a bit outdated, (Chrome OS used X back then, and Freon as of Q3/Q4 last year)
<anpok_> tjaalton: yay works..
<anpok_> tjaalton: oh.. those demos at //github.com/SaschaWillems/Vulkan.git make the i915 reset the gpu in various ways..
<zzarr> anpok_, it's hard to find any info about how freon works
<zzarr> anpok_, this might be interesting https://sites.google.com/a/chromium.org/dev/developers/design-documents/ozone
<zzarr> Vulkan looks nice
<alan_g> alf_: I'd like your eyes on this (as you wrote the original). I tried reverting the associated changes and this appeared reproduce the original failure, but it was hardly a clean merge so I can't verify I've captured the intent: https://code.launchpad.net/~alan-griffiths/unity-system-compositor/rework-DeadlockLP1491566/+merge/286698
<tjaalton> anpok_: which cpu?
<alf_> alan_g: ack, I will take a look
<anpok_> tjaalton: i7-4750HQ .. so haswell iris 5200
<tjaalton> anpok_: hmm might be a known issue then
<anpok_> there is an incomplete support warning on startup of each demo..
<anpok_> zzarr: hm there was a mir port of that one once -- running ozone as a mir client -- not what you need as far as i can tell..
<tjaalton> yeah, the driver is in flux and moving stuff around upstream, so i haven't bothered updating it yet
<zzarr> anpok_, I guess that I could have a look at that but only to get a general feel
<zzarr> anpok_, is there an picture or description how the components communicate in Mir?
<zzarr> I have found this, what parts don't I need? http://i1-linux.softpedia-static.com/screenshots/Mir_1.png
<zzarr> If I ported QtMir and QtUbuntu, would that be enough?
<alan_g> zzarr: as it port them to something other than Mir?
<zzarr> or is it everything below libhybris?
 * alan_g should probably read backchat
<zzarr> I guess I was thinking a bit wrong
<zzarr> I should have the freon driver in the position where libhybris is now
<anpok_> probably..
<anpok_> there is no nice colorful picture that guides you through the source code
<anpok_> you will have to provide an implementation of the mir::graphics::Platform interface
<zzarr> anpok, the image I found as well as knowing that the interface mir::graphics::Platform is a colorful image ;-)
<alan_g> zzarr: does this help? https://bazaar.launchpad.net/~mir-team/mir/development-branch/view/head:/design/Architecture.dia (You need dia to view it)
<zzarr> I was about to install dia from the repository... but I could not... it says that it don't know about a package called "dia-gnome-gnome-gnome-gnome"... I suspect I know why
<zzarr> alan_g, nice diagram
#ubuntu-mir 2016-02-23
<tjaalton> do we want libinput 1.2 in 16.04? adds graphics tablet (wacom) support
<anpok> tjaalton: I have nothing against it.. but mir has not support for graphics tablets yet
<anpok> s/not/no
<tjaalton> I know
<tjaalton> well, I assumed it didn't
<seb128> tjaalton, does the update breaks anything? if no it looks like it would be nice to have the current version in the lts in any case?
<anpok> oh you are concerned that we might regress ..
<anpok> i think it will not hurt.. it adds more event types.. so we will only ignore those for now
<tjaalton> right, I think it shouldn't break anything
<tjaalton> I'll push it to debian first :)
#ubuntu-mir 2016-02-24
<zzarr> hello!
<zzarr> I think that I should try to clone libhybris and rewrite it so that it can use a freon driver, that's the current approach I have
<zzarr> duflu, do you think that using libhybris source would be a good start in order to communicate with freon?
<duflu> zzarr: I don't know enough about freon... Hybris is only for Android systems and not ChromeOS so probably not
<zzarr> I know that, but it should interface Mir so I though that if I rewrite the Android part so that it go against freon instead I should get the Mir part pretty much for free
<anpok> zzarr: I believe you would have to integrate that: https://chromium.googlesource.com/chromium/src/gpu/+/3fe34d024f4726ad860771fab98b1e9b528bd3ab/
<zzarr> thanks anpok
<Saviq> hey guys, this is quite likely a Mir 0.20 - bug #1549226
<ubot5> bug 1549226 in Canonical System Image "top panel drop down menu is semi-transparent and items are unreadable" [High,Confirmed] https://launchpad.net/bugs/1549226
<Saviq> only happens on arale, I remember this being the case at some point in the past and you fixed it somehow :)
<Saviq> bregma, camako, FYI â
<davmor2> Saviq: are there meant to be 3 dots on it too? Under the location indicator
<Saviq> davmor2, hmm? the three dots on the bottom? that's the indicator panel handle
<davmor2> Saviq: when I say under the location indicator I mean they bleed through the indicator they are literally under it not below it
<Saviq> davmor2, anything "bleeding through" is that bug above, unless I'm totally missing what you're asking :)
<davmor2> Saviq: right okay that's what I was hoping for :)
<alan_g> Saviq: it sounds like a wrong pixel format. And that sounds vaguely familiar from "overheard" discussions about arele
<Saviq> yup
<anpok> Saviq: sounds like the gl-fence change
<anpok> or it behaves exactly like it..
<anpok> we pulled it from 0.19 back then.. because it behaved like that on arale (while it fixes stuttering on n10) - but I thought we resolved the cause for that in the 0.20 version of the patch
<Saviq> doesn't look like it
<zzarr> If I bought a Dragonboard 410c would I be able to run Mir on it? (HDMI)
<anpok> zzarr: alan_g has one
<anpok> and runs mir with the freedreno driver iirc?
<anpok> alan_g: so point release? and I can integrate the button bugfix?
<zzarr> thanks anpok, I'll hear with alan_g
<alan_g> anpok: sounds like it
<alan_g> zzarr: I have it working, but not exactly a stable image (yet)
<alan_g> So what I did was install the vivid based image from 96boards and then update from the xenial archive. Then Mir 0.20 works.
<alan_g> (The essential part from xenial was the mesa stack - as the vivid image wasn't built with Mir support in mesa
<alan_g> )
<alan_g> zzarr: there's a snappy image in the works, but I'm not sure of the current status
<alan_g> Here: https://insights.ubuntu.com/2016/02/24/canonical-to-offer-powerful-arm-64-bit-iot-developer-environment/
<zzarr> thanks alan_g, but does that mean there will be a Mir driver for it in the future?
<zzarr> ohh, now I see, I think I misread some, you're running Mir right now alan_g?
<alan_g> Yes, it just needs the mesa driver built with mir support enabled. And that's in xenial
<alan_g> So, with a xenial based image it works out of the box
<alan_g> Mir-0.20 is now in xenial
<anpok> zzarr: thats too boring for you!
<zzarr> anpok, no it's not ;-)
<bregma> zzarr, Canonical intends to make the DragonBoard 410c a reference platform
<zzarr> that just means the Dragonboard 410c is on the buy list
<zzarr> bregma, I know, but that is a future thing ;-)
<zzarr> bregma, thanks for the reply in any way
<anpok> oh kdub you are here... the transparent indicator problem is back on arale... Just like with the first time with the fence MP.. but maybe it is something different that has the same effect.
<anpok> kdub: https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1549179
<ubot5> Launchpad bug 1549226 in Canonical System Image "duplicate for #1549179 top panel drop down menu is semi-transparent and items are unreadable" [Critical,Confirmed]
<kdub> anpok, ack, was just flashing that, will look
<zzarr> alan_g, can the board be powered by USB?
<alan_g> AFAIK no
<kdub> anpok, from a quick look around, i think they changed the ro.product.device name
<kdub> breaking our quirk detection
<kdub> and giving another reason for https://trello.com/c/XzFGfwlE
<anpok> ah yes
<bregma> zzarr, the DragonBoard 410c requires an external 12 V power supply.
<zzarr> okey, thanks bregma :-)
<zzarr> alan_g, is the Dragonboard fast?
<alan_g> Compared to? It's a passively cooled CPU on a chip, not a developer system.
<alan_g> s/chip/card/
<alan_g> Its about the same speed as a 14 year old laptop I have laying around. (But draws a lot less power.)
<zzarr> alan_g|lunch, compared to the pi2?
<zzarr> if I bought one Dragonboard and this display http://www.amazon.com/Eleduino-Raspberry-1024x600-Capacitive-TouchScreen/dp/B019K6CRVY/ref=sr_1_9?ie=UTF8&qid=1456321182&sr=8-9&keywords=hdmi+display and hooked them up, would the touch work?
<alan_g> zzarr: @"compared to the pi2" I don't have one of those to compare. The specs are online though
<alan_g> @"TouchScreen Display" it depends on what "Support...Ubuntu" means. Certainly not impossible, but I doubt anyone has tried it with libinput. anpok?
<anpok> it is an USB touchscreen .. chances are goodt that it works out of the box.. only limitation .. we dont correlate touchscreen and diplay
<anpok> *display
<anpok> zzarr: ^ that means on your setup the output with your touchscreen should be your 'first' output..
<zzarr> thanks anpok
<zzarr> you see anpok I can make it trixy ;-)
<anpok> yeah you could try attaching two of those..
<zzarr> one HDMI and the other?
<zzarr> should I use my imagination? USB to HDMI?
<zzarr> but... I don't need 2 monitors to it.
<bregma> just a note: the only difference between a touchscreen and a touchpad is where you put it on your desk:  there is really no correlation between a touchscreen and the display it's attached to other than the coordinate projection (usually) done in the display server
<bregma> same goes for a (Wacom-style) tablet
<bregma> from the kernel point of view they're all separate devices, some have multiple input axes, some have multiple touchpoints
<bregma> some even have multiple buttons
<bregma> a good design would leave all that pluggable and configurable, so add-on touchscreens and not-yet-imagined technologies like 3D gesture sensors and assistive technologies would "just work"
<zzarr> thanks bregma, I know, a touch screen have absolute coordinates and a touch pad have relative
<bregma> zzarr, nope, touchpads have absolute coordinates
<bregma> some drivers will do cursor emulation, but that has nothing to do with what the device reports
<anpok> bregma: well the device may appear simultaneously .. :)
<anpok> may .. in zzarr case .. they wont .. since they are reached through separate cables..
<bregma> internally, often the touchscreen is just a USB HID device
<bregma> just because you don't see the cable doesn't mean it's not there
<bregma> I mean it when I say touchscreens and touchpads are virtually identical devices and have nothing to do with the display they're associated with
<zzarr> bregma, I know they are similar, and that a touchpad have absolute coordinates on device level, but I meant that they should be handled like a mouse
<zzarr> bregma, I think you're wrong about internal devices often being USB HID's, I think that they are connected through some other bus like I2C
<zzarr> I could be wrong but I don't see the reason why they should use USB
<bregma> manufacturing cost:  vendors churn out plenty of HID devices and if they're all built to the Microsoft HID spec, they all just work
<bregma> I have a large selection of touch input devices here, and every laptop I have that has touch sensors has them hanging off the USB
<bregma> some of the mobile devices have bespoke drivers in the Android kernel, so it's harder for me to probe their real config without browsing Android kernel source
<bregma> as for the display stack emulating relative coordinate for an absolute input device, sure, it can do that, but it's not because a touchpad and a touchscreen are different, it's because some configuration says "map absolute coordinates from the this device into relative coordinates and do pointer emulation" inside the display stack
<bregma> or, really, the input stack associated with the display stack, so the cursor can be drawn on the screen
<zzarr> bregma, thanks for the info
<mzanetti> anpok, hey, so mir 0.20 landed, but the mouse is still broken in the emulator :/
<anpok> was there a new emulator release?
<mzanetti> does it need an emulator release?
<anpok> or rather android release..
<mzanetti> I thought a mir release would be the required thing
<anpok> hm that fixes qml touch gestures in emulator
<anpok> but the android patch will fix the emulated device being detected as an odd mouse..
<mzanetti> anpok, so the weird thing is that with xenial it works fine, but it's broken with rc-proposed
<anpok> hum it depends on when the emulator image was updated last time..
<anpok> if is with the android input reading stuff.. the device will be detected as a touchscreen
<alan_g> alf_: another try - https://code.launchpad.net/~alan-griffiths/unity-system-compositor/rework-DeadlockLP1491566/+merge/286698
 * alan_g wishes he could reproduce failures that only happen during release
<bschaefer> that would make the release cycle to easy :)
#ubuntu-mir 2016-02-25
<tjaalton> pushed mesa 11.2.0-rc1 to ppa:tjaalton/ppa
<tjaalton> mir-egl patch didn't need work, and it at least compiles
<tjaalton> there is a FFE bug for this, but it will be properly tested before pushing to main
<alf_> sil2100: Hi! When you get some free cycles, could you please also disable unity-system-compositor jobs in s-jenkins (unity-system-compositor-ci, unity-system-compositor-autolanding etc)
<sil2100> alf_: ok, will try to do that in a minute :)
<alf_> sil2100: thanks
<Saviq> alf_, can you please add me to your CI team so I can steal your device jobs? :)
<alf_> Saviq: sure
<Saviq> alf_, oh, maybe I'm there already, just was looking at a config from a multi-config job
<alf_> Saviq: so, our 'ci team' is actually mir-team
<Saviq> alf_, yeah just saw
<alf_> Saviq: so you should be there
<Saviq> alf_, looking at device-0-flash, find it weird that you flash per label, shouldn't you have it per slave instead? otherwise you rely on the fact that you have just one of each?
<alf_> Saviq: I thought that if I select a label in a multiconfig job it would just pick a single node matching that label?
<Saviq> alf_, that's correct, but how do you then know that you flash and test on that same slave?
<Saviq> I mean a "monitor" job can have a label, but downstream from that you need to stick to a slave
<alf_> Saviq: yeah, you are right
<alf_> Saviq: perhaps there is a way to constrain the node to be the same for run job as it is for the flash job?
<Saviq> alf_, only way I can think of is for the upstream job to run on that slave (throttled to just one per slave) and run downstream jobs on that same slave
<Saviq> alf_, otherwise other jobs could get queued on that slave in the mean time
<Saviq> I mean, they still could, if you did it manually
<Saviq> other than having a single job that does everything in sequence (flash + test)
<Saviq> without letting the slave out
<Saviq> I think that's the safer approach actually
<Saviq> because otherwise you can queue a job on the same slave before the flashing completes
<Saviq> and that would "steal" the slae
<alan_g> alf_: if you fix the conflict I'll TA
<alan_g> https://code.launchpad.net/~afrantzis/unity-system-compositor/log/+merge/274550
<alf_> alan_g: thanks, see latest comment on why it can't land yet
<alan_g> /sigh! So many barriers to progress!
<fsbif> hello everyone. I can't get unity 8 run in ubuntu 15.10
<fsbif> it says "unity8-lxc-setup: error: The container already exists." when I try to remove the container
<ChrisTownsend> fsbif: Hi!  How exactly are you trying to remove the unity8-lxc container?
<ChrisTownsend> D'oh!
#ubuntu-mir 2016-02-26
<zzarr> hello!
<zzarr> I'm going to buy a Dragonboard 410c I wonder if it is possible to rotate the screen?
<zzarr> (HDMI output)
<zzarr> I wish to have a display in portrait mode
<ogra_> zzarr, we have no graphical support on the dragonboard yet (in snappy ... not sure there wil be non-snappy images for it )
<zzarr> I though that the xenial image had Mir support for it
<ogra_> if you throw something together yourself (i.e. to use X11 on a standard minimal install) there seems to be a freedreno based xserver from linaro though
<ogra_> there will be Mir support for it in the snappy image at some point, for sure
<ogra_> current focus is on IoT and headless though
<zzarr> ogra_, this is a quote from alan_g "So what I did was install the vivid based image from 96boards and then update from the xenial archive. Then Mir 0.20 works."
<ogra_> zzarr, well, then 6talk to 96boards, or linaro or so ... thats nothing we produce
<alan_g> I also said this was hardly a supported approach
<zzarr> alan_g, I missed that
<zzarr> but it is a real Ubuntu right?
<ogra_> we have a kernel in the archive ... but i doubt any of the tradition installers will ever get support for this device ... there are many biary blobs involved to even boot
<ogra_> so it is unlikely yoou will see official traditional images for it
<ogra_> (snappy OTOH will get graphical suport at some point, but is still a bit away from that)
<alan_g> 96boards produce a vivid based image and instructions for installing that. Updating that from the xenial archives works well enough to prove Mir works, but isn't what anyone will provide support for.
<ogra_> yeah
<zzarr> well, what matters for me right now is that I can boot a graphical system (X or Mir) that can run a custom application written in Qt Creator (by me)
<ogra_> that should even just work with fbdev
<ogra_> (though, not at stellar speed i guess :) )
<zzarr> and that I can rotate the screen to portrait
<zzarr> okey, that's nice :-D
<zzarr> order placed :-D
<alan_g> alf_: do you want to review before I TA? https://code.launchpad.net/~raof/mir/new-display-api/+merge/286975
<zzarr> okey, I guess that you all are (not) itching to know what I'm going to do with the board, I'm going to make a "smart mirror"
<zzarr> there are a type of mirror film that reflects from one side, but lets light through in the other direction
<zzarr> so I figured that I should make a mirror with a touch screen behind
<alf_> alan_g: I'll take a quick look
<xperia> Hi everyone! I am trying to Install Ubuntu-Desktop-Mir on a new Bootstraped Rootfs but somehow i am not able to pass the Login Screen after the Boot. Can somebody please tell me what are the Steps to install a full functional Ubuntu Touch Desktop on a bootstraped ubuntu rootfs please?
<alan_g> xperia: perhaps you are seeing bug 1549455
<ubot5`> bug 1549455 in unity8 (Ubuntu) "Unity 8/Mir doesn't load" [High,Incomplete] https://launchpad.net/bugs/1549455
<xperia> alan_g: its exactly this Bug! have the same Problem like Described.
<xperia> alan_g: is this somehow related to unity8 becouse if i try also just to install the newest version of ubuntu-desktop its same.
<alan_g> xperia: sorry, I've not been actively following the problem, just thought it sounded similar
<ChrisTownsend> xperia: There is some entropy issue that can cause failed logins.  Have you waited a while after a reboot to try to log in?  A while meaning at least 30 seconds, but maybe even longer just to be sure.
<ChrisTownsend> That issue bites me all of the time:-(
 * ChrisTownsend Tries to find the entropy bug...
<ChrisTownsend> https://bugs.launchpad.net/mir/+bug/1536662
<ubot5`> Launchpad bug 1536662 in Mir "[regression] Black screen: Mir hangs and then crashes on startup/login due to reading from /dev/random" [High,In progress]
<alan_g> bschaefer: ^
<bschaefer> ChrisTownsend, xperia hmm that *should* be fix with umm
<bschaefer> uSC
<bschaefer> 0.4.1? or 0.4.2
 * bschaefer checks
<ChrisTownsend> bschaefer: Really?  I thought I hit it the other day.
<bschaefer> hmm
 * ChrisTownsend Tries
<alan_g> bschaefer: is USC used for Ubuntu-Desktop-Mir?
 * alan_g forgets
<bschaefer> alan_g, as far as i know? It should be?
<bschaefer> ChrisTownsend, would you oknow :)?
<ChrisTownsend> Yes, u-s-c is used in a Unity8/Mir desktop session.
<bschaefer> im fearful this fix was said to be fixed but never released...
<bschaefer> (which is slightly my own doing ... since i had to revert it last minute but didnt revert it from trunk)
 * bschaefer double checks it made it
<ChrisTownsend> bschaefer: I still have the issue on my fully updated xenial machine.
<bschaefer> ChrisTownsend, alright hmm let me check the package source
<ChrisTownsend> bschaefer: Ok
<bschaefer> ChrisTownsend, one thing you can do is make a bunch of noise with your devices :)
<bschaefer> in hope that it generates some entropy
<ChrisTownsend> bschaefer: lol, yes, but that's not really a workaround.
<bschaefer> huh the fix is there...
<bschaefer> ChrisTownsend, strange, do you have a log by chance :)
 * bschaefer must have put the override in the wrong place maybe
<ChrisTownsend> bschaefer: I can get one.  Is it in u-s-c.log?
<bschaefer> ChrisTownsend, yeah
<bschaefer> ChrisTownsend, since the current *fix* should just create a dummy cookie factory, but i wasnt ever really able to test it
<ChrisTownsend> bschaefer: Here is the log: http://pastebin.ubuntu.com/15207496/
<ChrisTownsend> bschaefer: I'm going to try to log into the machine now after having let it sit for a while.
<ChrisTownsend> bschaefer: And now it works.
<ChrisTownsend> bschaefer: So fix is not working as expected.
<bschaefer> ChrisTownsend, thanks!
<bschaefer> yup
<ChrisTownsend> bschaefer: Sure, np!
<bschaefer> hmm i dont see anything about that log
 * bschaefer attempts to reproduce it
<bschaefer> ChrisTownsend, easier to reproduce on a reboot?
<ChrisTownsend> bschaefer: Yes, it has to be after a reboot.
<bschaefer> thanks
<ChrisTownsend> bschaefer: Sure
<bschaefer> alan_g, is the default server config all loaded before overrides take in effect (for an overriden mir::Server?)
 * bschaefer is wondering if we *attempt* to create a cookie authority, then override it
<bschaefer> looks like it depends on ... if the function is called or not?
<bschaefer> ie. the_cookie_authority()
<xperia> ChrisTownsend: Thanks a lot for your Tips! I waited 5 Minutes but nothing happens. Just the Background Screen is showed and nothing else. Looked at all Logs but could not find any usefull information to find out what the Problem could be to solve. With Ubuntu Desktop i have the Same Problem. No Laucher and No Top Bar is showed. I am able however with the Right Mouse to Start Programms Like...
<xperia> ...Nautilus and Navigate trough all dirs. Just Windows Frame Border is missing around it. Its Strange. Some worte its related to the GPU Driver.
<alan_g> Shouldn't be - overrides should throw if anything has been built
<bschaefer> ChrisTownsend, idk if thats the same issue ^
<ChrisTownsend> xperia: Hmm, ok, definitely sounds like you have some other issue.  Unfortunately I have nothing else to add at this time:-(
<bschaefer> if you hit this issue your desktop wouldnt do anything
<bschaefer> alan_g, thanks!
<ChrisTownsend> bschaefer: Right, just black screen and maybe it eventually crashes back to lightdm.
<bschaefer> ChrisTownsend, hmm since last time you did see a log info about it?
<bschaefer> soo this could be a different issue, but could be related...
<bschaefer> ie. see the log say NOT ENOUGH ENTROPY?
<ChrisTownsend> bschaefer: Well, it's the same symptom, but maybe a different cause.
<bschaefer> true hmm i wonder if my override is doing something bad...
<ChrisTownsend> bschaefer: I'll try again and see if anything is in the unity8.log since that is not starting.
<bschaefer> ChrisTownsend, alright, im also going to upgrade and check it out (soo ill most likly be off irc)
 * bschaefer should really get a test laptop
<ChrisTownsend> bschaefer: This is the unity8.log: http://pastebin.ubuntu.com/15207712/
<bschaefer> hmm
<bschaefer> if it was the entropy issue... i wonder
<bschaefer> you would expect
<bschaefer> to see Not enough entropy like you saw before?
<ChrisTownsend> bschaefer: But u-s-c.log looks sane.
<ChrisTownsend> bschaefer: The only thing I would see before in u-s-c.log is an exception line which I'm not seeing now.
<bschaefer> but same symptoms, ie. once you generate enough *entropy* or do things enough
<bschaefer> hmm
<ChrisTownsend> bschaefer: Right
<bschaefer> if it was an issue with my override you would expect to see the issue *every* time
 * bschaefer will be upgraded soon
<bschaefer> ill look at it
<ChrisTownsend> bschaefer: I do see the issue every time if I don't wait long enough before logging in.
<bschaefer> thats strange
<ChrisTownsend> bschaefer: I just don't see std::exception(blah) in u-s-c.log like I would before.
<xperia> best would be if there is a possibility haveÃ®ng a very verbose version of ubuntu-desktop-mir that can be installed to see what exactly is happening and where it hangs.
<bschaefer> thats my starting plan :)
<bschaefer> reproduce, recompile/test
<ChrisTownsend> bschaefer: Yeah, you should get a testing laptop.  One for that purpose would be pretty cheap.
<bschaefer> yeah
<xperia> i would need to have a armhf version of it
<bschaefer> xperia, err this isnt the desktop?
<bschaefer> deskop is x86/amd64
 * bschaefer goes to test and logs of irc
<xperia> well have the same problem with ubuntu-desktop and ubuntu-desktop-mir
<xperia> mir is touch gui of ubuntu desktop
<xperia> btw just to be sure that i have doen everything right
<xperia> what for steps are needed to install ubuntu-desktop-mir inside a chrooted debootstrap rootfs?
<xperia> is apt-get install ubuntu-desktop-mir only needed or it is requered to do more like modify some scripts add aditional users and so on ?
<xperia> maybe is realted also to some missing additional config steps.
<ChrisTownsend> xperia: Sounds to me you are doing something *very* custom.
<xperia> yeees i am trying to port ubuntu touch desktop to a new device
<bschaefer> ChrisTownsend, hmm getting a different issue
<xperia> it works actually. ubuntu boots on new device. login screen is showed. i am able to login but after this just background and nothing else.
<bschaefer> ChrisTownsend, http://paste.ubuntu.com/15207808/
<bschaefer> xperia, yeah that sadly isnt the same issue im looking at :( or suspecting
<ChrisTownsend> xperia: I don't think your pulling in a desktop environment.  You probably need unity8.
<ChrisTownsend> bschaefer: You may need to remove some package.
<bschaefer> :|
<bschaefer> yeah
<bschaefer> figured
<xperia> bschaefer i am sure we have both the same problem
<bschaefer> but which ones haha
<xperia> its the gpu driver
<bschaefer> xperia, but you see unity8 right?
<bschaefer> err or based on my log?
<xperia> what for a gpu do you have ?
<bschaefer> some intel one
 * bschaefer looks
<xperia> do sudo lsmod
<bschaefer> 00:02.0 VGA compatible controller: Intel Corporation Broadwell-U Integrated Graphics (rev 09)
<xperia> and what does sudo lsmod show
<xperia> on my side the gpu driver is not loaded but it looks like its needed for the display of the Ubuntu GUI
<bschaefer> i915
<xperia> need to work on this. loading of the rigth gpu driver on my side.
<ChrisTownsend> bschaefer: Did you apt-get autoremove any unneeded packages?
<bschaefer> o lots
<ChrisTownsend> bschaefer: Also, what mir mesa packages to you have?
<bschaefer> ChrisTownsend, 4
 * bschaefer also isnt sure which mesa package you're refering to :)
<bschaefer> mir-client-platform-mesa4:amd64
<bschaefer> ii  mir-platform-graphics-mesa-kms7:amd64                0.19.3+16.04.20160212-0ubuntu1              amd64        Display server for Ubuntu - platform library for KMS Mesa
<bschaefer> ii  mir-platform-graphics-mesa-x7:amd64                  0.19.3+16.04.20160212-0ubuntu1              amd64        Display server for Ubuntu - platform library for X11 Mesa
<ChrisTownsend> bschaefer: lol, yeah, those are what I was talkin' 'bout.
<xperia> bschaefer: from your Log it Load this Graphic Library here => graphics-mesa-kms.so.7 then it try to load mircommon Kernel Module => mircommon: Loading module: /usr/lib/x86_64-linux-gnu/mir/server-platform/input-evdev.so.4
<xperia> and it crashes. I am sure its related to Driver like on my Side.
<xperia> [2016-02-26 09:53:07.267594] mircommon: Loading module: /usr/lib/x86_64-linux-gnu/mir/server-platform/input-evdev.so.5
<xperia> [2016-02-26 09:53:07.268073] mircommon: Loading module: /usr/lib/x86_64-linux-gnu/mir/server-platform/input-evdev.so.4
<bschaefer> xperia, try doing a auto remove of packages
 * bschaefer just removed a bunch
<bschaefer> let me reboot
<bschaefer> hmm now gtk3 wont load :|
<bschaefer> umm
<bschaefer> ChrisTownsend, same issue let me check
<ChrisTownsend> bschaefer: Why does this stuff have to be so temperamental????:)
<bschaefer> :||||
<bschaefer> ChrisTownsend, not sure :( and im pretty sure this is blocking your stuff atm?
<bschaefer> hmm
<ChrisTownsend> bschaefer: You have the same platform module issue?
<ChrisTownsend> bschaefer: From you previous pastebin that is?
<bschaefer> ChrisTownsend, yeah
<ChrisTownsend> bschaefer: Mine is not a client platform module issue.
<bschaefer> i just upgrade a bunch though...
<bschaefer> upgraded*
<ChrisTownsend> bschaefer: It looks like from your pastebin, it is trying to load an older version of the driver .so's.  Here's yours: server-mesa-x11.so.7 and graphics-mesa-kms.so.7.  Mine are both .8.
<ChrisTownsend> Dang, he just left.
<bschaefer> ChrisTownsend, hmm works fine for me
<bschaefer> unity8 :|
<bschaefer> takes 5-8 seconds to load
<bschaefer> but idk if thats normal or not...
<bschaefer> dam entropy pool
<ChrisTownsend> bschaefer: You mean you can (fairly) immediately get to Unity8 after a reboot.
<ChrisTownsend> ?
<bschaefer> ChrisTownsend, yeah
<bschaefer> twice in a row from boot
<ChrisTownsend> bschaefer: 5-8 seconds is normal.
<bschaefer> yeah
<ChrisTownsend> bschaefer: Never works for me.
<bschaefer> let me ... write something that will drain my entropy
<bschaefer> ChrisTownsend, try to do a dist-upgrade?
<bschaefer> and what version of USC do you have
<ChrisTownsend> bschaefer: I did as of about an hour ago.
<bschaefer> dang
<ChrisTownsend> $ apt-cache policy unity-system-compositor
<bschaefer> hmmmm
<ChrisTownsend> unity-system-compositor:
<ChrisTownsend>   Installed: 0.4.2+16.04.20160219.1-0ubuntu1
<bschaefer> yeah
<bschaefer> hmm
<bschaefer> but yeah let me write something that will drain my entropy pool then attempt to log in
<ChrisTownsend> bschaefer: It should be emptied on reboot, no?
<bschaefer> entropy gets generated from devices
<bschaefer> starting from boot
<ChrisTownsend> bschaefer: Maybe you have busy devices?:)
<bschaefer> soo it really depends on how much *gets* generated on boot
<bschaefer> haha
<bschaefer> i didnt touch anything
<bschaefer> in hopes to get something...
<bschaefer> ChrisTownsend, you can do: cat /proc/sys/kernel/random/entropy_avail
<bschaefer> maybe if you can try to print that out in tty1 ... before logging into unity8 to see how much you have?
<ChrisTownsend> bschaefer: Also, before, it would crash back out to lightdm and I'd get the exception message in u-s-c.log, but now, it just sits at the black screen.
<ChrisTownsend> bschaefer: Ok, I'll try that.
<bschaefer> ChrisTownsend, hmm
<bschaefer> vogons any other changes in USC/boot stuff with mir that could cause a black screen with no message?
 * bschaefer still assumes my code somewhere but i can reproduce
<bschaefer> ChrisTownsend, the thing is *all* we need is 1 byte
<bschaefer> of entropy
<bschaefer> err 1 bit
<bschaefer> all we need to know is we can read from it, as we select(..) on /dev/random
<bschaefer> which should tell us its ok to read from
<ChrisTownsend> bschaefer: Hmm, ok.  entropy_avail showed stuff and it worked.
<bschaefer> ChrisTownsend, yeah ... im worried that you logging into your tty
<bschaefer> will cause entropy
<ChrisTownsend> bschaefer: Probably
<bschaefer> with the clickity clackity of the keyboard
<bschaefer> ChrisTownsend, how much?
<ChrisTownsend> bschaefer: Actually, it's through ssh, but NIC has activity
<bschaefer> ChrisTownsend, like pretty low? 20-30?
<bschaefer> or high?
<ChrisTownsend> bschaefer: Wouldn't typing on the keyboard to log in create entropy?
<bschaefer> yes
<ChrisTownsend> bschaefer: It was in the 30 range.
<bschaefer> but
<bschaefer> maybe not
<bschaefer> ChrisTownsend, o thats super low
<ChrisTownsend> bschaefer: This time, it didn't work.
<bschaefer> mine is sitting at ~1000 right now
<bschaefer> hmm 30? isnt enough
<bschaefer> hmm i wonder if they collect entropy and dont write to /dev/random ... until?
<bschaefer> 256 or something?
<bschaefer> ChrisTownsend, keep checking the entropy?
<bschaefer> is it going up?
<bschaefer> that doesnt make sense though...
<ChrisTownsend> bschaefer: Strange, it went from 61 to 35.
<bschaefer> bregma, would you have any ideas about entropy and when it would write to /dev/random?
<bschaefer> ChrisTownsend, huh... is something eating it all up?
<bschaefer> that *we* arent controlling?
<ChrisTownsend> bschaefer: Now, it's going back up...96.
<bschaefer> that would make sense to me? You have low entropy on boot, then something eats all of it
<ChrisTownsend> bschaefer: But unity8 already failed.
<bschaefer> hmm what caused it to drop...
<bschaefer> right
<ChrisTownsend> No idea
<ChrisTownsend> bschaefer: Ok, I just tried it and entropy was at ~17 and unity8 failed to load.
<bschaefer> ChrisTownsend, can you do a watch -n <command to read entropy> on your ssh?
<bschaefer> while you're about to boot unity8?
<bschaefer> so you can see if it drops to 0?
<ChrisTownsend> ok, I'll try it
<bschaefer> we dont even read from that FD
<bschaefer> all we do is, open /dev/random, select on that FD
<bschaefer> and when it becomes ready, we drop, then read from it
<bschaefer> but that code *shouldnt* be running
<bschaefer> :|
<bschaefer> since we override it with a nothing factory
<bschaefer> but does it actually get overriden... it should throw if something is there...but let me check
<ChrisTownsend> bschaefer: I saw entropy drop twice.  I'm going to see if it does this without trying to log in to unity8.
<bschaefer> drops to 0?
<ChrisTownsend> ~0, definitely single digits.
<bschaefer> yeah
<bschaefer> ChrisTownsend, because once we see /dev/random is open to be read, we then drop to use /dev/urandom... which wont block on that
<bschaefer> but we shouldnt be using that code... haha... ok umm
<ChrisTownsend> bschaefer: Hmm, so as soon I start typing in my password in lightdm, it drops to ~0.
<bschaefer> i need to be able to reproduce this
<bschaefer> hmm what?
<bschaefer> pam?
 * bschaefer wants to blame pam
<bschaefer> but i wont
<ChrisTownsend> bschaefer: Not even hitting enter, so not pam.
<bschaefer> but doesnt lightdm interact with lightdm?
<bschaefer> before enter?
 * bschaefer cant find the override the cookie factory function?
<bschaefer> i must be blind as i remember writting it
<ChrisTownsend> bschaefer: So I see it drop to 0, then wait to let it build again, and then it works.
<bschaefer> yeah
<bschaefer> soo yeah something is eating the entropy pool, but i dont see why we would block on that?
<bschaefer> if anything exists
<bschaefer> we wait 30 seconds
<bschaefer> for /dev/random to be working again
<ChrisTownsend> bschaefer: I don't think unity8 waits 30 seconds.
<bschaefer> and also this function shouldnt even be running...
<bschaefer> yeah
<bschaefer> but it jumps back up quickly
<ChrisTownsend> bschaefer: unity8 fails saying connecting to Mir has failed which must be the time it is waiting for entropy to build.
<bschaefer> o yeah that function gets generated...
<ChrisTownsend> bschaefer: I think it's a race.
<bschaefer> yeah
<bschaefer> dang
<bschaefer> ChrisTownsend, but but but ... it shouldnt be running that code :)
<bschaefer> but i guess it must
<bschaefer> as this makes to much sense
<ChrisTownsend> bschaefer: Well, not sure what to say.
<bschaefer> but where is that expection?
<bschaefer> yeah im just rambling to my self
<ChrisTownsend> I know you are:)
<bschaefer> hmmm
<ChrisTownsend> bschaefer: If whatever is eating the entropy didn't eat it, then I think it would be fine.
<bschaefer> ChrisTownsend, let me do some testing, to see what happens when i drop my entropy pool to 0 but just looping for ever with a
<bschaefer> random call
<ChrisTownsend> bschaefer: Ok.
<bschaefer> ChrisTownsend, yeah i bet it wouldnt but ... we should wait a few seconds
<bschaefer> which should be enough to recover?
<bschaefer> ChrisTownsend, how fast do it come back?
<ChrisTownsend> bschaefer: I think if I type my password in slowly enough in lightdm, then it'll work.
<bschaefer> ChrisTownsend, ill be logging out...bb in like ~10-15
<bschaefer> haha
<ChrisTownsend> bschaefer: Fairly fast
<bschaefer> ChrisTownsend, but it seems to do the check in an instant
<bschaefer> yeah
<ChrisTownsend> bschaefer: Well, u-s-c is happy, it's that unity8 is not patient.
<bschaefer> which 1 second *should* be enough time of waiting? I wonder of unity8 just instantly fails?
<bschaefer> yeah
<bschaefer> hmm soo if unity8 waited like 1 second when attempting to create the mir server?
<ChrisTownsend> bschaefer: Yeah, the unity8 upstart is just fired off and it does it stuff immediately.
<bschaefer> didnt we use to have a spinner/sleep for this?
 * bschaefer relogs and messes around
<ChrisTownsend> bschaefer: Some sort of query of u-s-c from unity8 would be nice, like "Hey, u-s-c are you ready?", and u-s-c is like, "Nope", and unity8 waits a bit before trying again.
<bschaefer> yeah that would be nice ...
<bschaefer> brb
<ChrisTownsend> ok
<bschaefer> ChrisTownsend, yeah i can reproduce when i do: cat /dev/random then attempt to log in
<bschaefer> and my entropy drops to ~0 then climbs to 20-30 but yeah mir server does not start
<bschaefer> (from the unity8 log)
<bschaefer> but my USC log is normal...
 * bschaefer wonders if he can reproduce this issue on a tty
<bschaefer> with a demo server
<ChrisTownsend> bschaefer: Ok.  IS most definitely a race in that u-s-c is not quite ready when unity8 starts up.
<bschaefer> yeah
<bschaefer> but ... hmm why
<ChrisTownsend> bschaefer: You mean why is u-s-c not ready?
<bschaefer> ok... dont cat dev random and attempt to start a server in the tty... that will lock the machine up
<bschaefer> ChrisTownsend, yeah on the demo server it locks up... but once i stop cating /dev/random the server works perfectly
<bschaefer> sooo the issue is unity8 not waiting a mirco second once we attempt to start login
<bschaefer> or start it
<bschaefer> (well an issue)
<ChrisTownsend> bschaefer: Well, any way to make u-s-c ready sooner, like before?  Or does it have to wait on some entropy?
<bschaefer> ChrisTownsend, well USC shouldnt need entropy...
<bschaefer> but i should stop saying that
<anpok> hm
<ChrisTownsend> bschaefer: Or whatever it is?  It's obvious that *something* related to Mir needs it.
<bschaefer> yeah
<anpok> bschaefer: what happened with the make the wait for dev random asynchronous?
<ChrisTownsend> bschaefer: If I wait long enough then watch entropy, then log in, entropy doesn't drain and all is fine.
<bschaefer> anpok, does anything else input wise depend on /dev/random on boot? Im pretty sure the cookies is the issue
<anpok> +plan
<bschaefer> anpok, needs to be done
<bschaefer> i should write that and test it fixes this
<ChrisTownsend> bschaefer: You have a task!
<ChrisTownsend> :)
<bschaefer> anpok, thought the USC fix would be a good hold until then
<bschaefer> :)
<bschaefer> but
<bschaefer> the confusing part is the USC fix seems to do nothing but remove the throw?
<anpok> there is another problem?
<ChrisTownsend> bschaefer: In all fairness, the time needed to wait before logging in is much less than before.
<bschaefer> ... well the throw is no longer happening but thats most likely due to unity8 puking beofr ehtne
<bschaefer> yeah
<anpok> ah yes..
<bschaefer> anpok, my worry was, that i override the cookie factory
<bschaefer> after the cookie factory is asked to be made
<anpok> so u8 is adding the cookies to input events, right? (where is that actually happedning?)
<anpok> -d
<bschaefer> ie. when the_connection_creator
<bschaefer> anpok, nope, this is all on boot
<bschaefer> soo if i did a lazy eval
<bschaefer> the secret shouldnt be generated...
<bschaefer> until libinput generates an event for u8
<anpok> aehrm
<bschaefer> that is a keyboard/mouse
<anpok> libinput is not in the u8  process
<bschaefer> :|
<bschaefer> anpok, how does it get event
<bschaefer> events*?
<bschaefer> a mir surface?
<anpok> yes
<bschaefer> which ... would be libinput? on mirs side
<bschaefer> as u8 does not use the cookies yet
<anpok> the one the nested display creates for each output the nested servers uses
<bschaefer> afaik
<anpok> yes
<anpok> so the libinput-input platform reads events and attaches an empty cookie to it..
<bschaefer> anpok, im pretty sure... whats happening in usc
<bschaefer> i override the cookie factory after
<bschaefer> the WM builder is overriden
<bschaefer> and when the WM builder is overriden it uses
<bschaefer> like the focus controller and a few other things
<bschaefer> which will end up building the cookie authority
<bschaefer> before we overrid
 * bschaefer checks thats the issue
<anpok> hm nothing should be created when you are still allowed to inject implementations
<bschaefer> anpok, but ... what if you do
<bschaefer> anpok, http://paste.ubuntu.com/15208526/
<bschaefer> anpok, yeah actually ... those are just functions
<bschaefer> that arent called until
<bschaefer> after that...
<bschaefer> :|
<anpok> yeah
<bschaefer> so much for that idea... as i've no clue *why* it even thinks it want entropy
<bschaefer> ie. i've no clue why it doesnt use the stub version
<bschaefer> thats most troubling... hmm
<anpok> oh but it is usc failing to start or u8
<bschaefer> anpok, both
<bschaefer> usc is failing, then u8 freaks out
<bschaefer> and says mir server could not start
<bschaefer> anpok, but it also waits for a micro second to do this as well
<bschaefer> if it only gave usc ~500ms it *should* be fine
<ChrisTownsend> I don't think u-s-c is failing per se as it's up and running.  It's u8 failing because it seems u-s-c is not "ready".
<bschaefer> since ChrisTownsend is losing entropy when he types
<bschaefer> and USC blocks for a little bit waiting for /dev/random
<bschaefer> but unity8 sees this as a failure
<bschaefer> and terminates
<anpok> bschaefer: but why would usc wait for /dev/random?
<bschaefer> or just logs an issue and stops
<bschaefer> anpok, well from the cookie authority ... even though i override it...
<bschaefer> anpok, i just can seem to reproduce this when theres little entropy
<ChrisTownsend> I think maybe u8 should try more than once befroe giving up, maybe adding some delay between tries and then giving up after x amount of tries.
<ChrisTownsend> Yeah, only seems to occur for me when entropy is maybe less than 30, but that's just observation, not a measured threshold.
<anpok> bschaefer: but there is only one place in the code.. and you seem to override that..
<anpok> bschaefer: are you sure the right versions are being used?
<bschaefer> anpok, i know... thats my confusion this entire time...
<bschaefer> anpok, yeah i grabed the source from universe :(
<bschaefer> anpok, which is why im wondering... if the override didnt work?
<bschaefer> for w/e reason...
 * bschaefer attempts to override the demo server...
<bschaefer> anpok, but the override has to be working
<bschaefer> because it was crashing before
<bschaefer> anpok, does anything else depend on random?
 * bschaefer cant think of it 
<bschaefer> anpok, umm im reading this... and i dont override the create functions...
<bschaefer> but the create should be...
<bschaefer> the override lambda it self
<bschaefer> ChrisTownsend, thanks i think i've enough to work with
 * bschaefer finds a better solution here
<ChrisTownsend> bschaefer: Oh good!
<ChrisTownsend> bschaefer: Thank you too!
<bschaefer> np!
<bschaefer> urg stub works perfectly in the demo server
<bschaefer> anpok, the nested serer... vs the usc server
<bschaefer> wouldnt both need to be overriden?
<anpok> bschaefer: well .. i thought one shoud be the cookie authority for the session?
<bschaefer> anpok, but .. doesnt unity8 make its own server? with its own overrides and everything?
<anpok> sure
<bschaefer> soo unity8 will be depending on /dev/random
<bschaefer> since we dont override that server?
<bschaefer> (but it will be needed)
<bschaefer> soo we cant soo yeah let me create the lazy eval
<bschaefer> and it should fix the issue...
<anpok> yes
<bschaefer> ChrisTownsend, ok i have a fix
<bschaefer> test confirmed (being able to log in with cat /dev/random going on, and while smashing the keyboard)
<bschaefer> soo the delay in creating the secret is enough to allow for usc to start and unity8 to be so it gives it time to create the secret
#ubuntu-mir 2017-02-21
<oSoMoN> webbrowser-app unit tests are failing in xenial+overlay arm64 with the following error, and I could use some help in understanding whatâs going on: http://pastebin.ubuntu.com/24039585/
<oSoMoN> why is it even trying to load libubuntu_application_api_touch_mirclient.so.3.0.0 when Iâm running the tests in xvfb?
<alan_g> oSoMoN: presumably somewhere it's configured Qt to use a Mir backend? That's something like "$ export QT_QPA_PLATFORM=ubuntumirclient".
<oSoMoN> ah of course
 * oSoMoN facepalms
<alan_g> yw
#ubuntu-mir 2017-02-22
<duflu> greyback: One more thing: Is there an artificial throttle in QSG somewhere?
<duflu> Like if you try to render too quickly it slows you down?
<duflu> I'm wondering why the screen class wants to know the refresh rate too...
<duflu> Good idea
 * duflu -> EOD
<ads20000> Do the Unity 8 17.04 and 16.04 + Phone Overlay PPA sessions use Mir by default? Is it possible to use Mir with Unity 7?
<greyback> ads20000: no not possible. Unity7 relies on X, which is what Mir is designed to replace.
<greyback> is why we have to do unity8
<greyback> X and Mir are so very different
<ads20000> greyback: OK thank you :) Do the Unity 8 sessions use Mir by default? I thought they could use X too? (I'm probably getting confused)
<greyback> ads20000: unity8 uses mir. It cannot use X.
<ads20000> greyback: I'm asking because I want to reply to this https://github.com/phw/peek/issues/39#issuecomment-281496884 , the dev wants to test using Mir for an app, how can they best do this, maybe you should reply
<ads20000> greyback: should they use Libertine? Or make a Snap? If using Libertine would it be using XMir? etc
<greyback> ads20000: let me reply, I know more about this situatino
<ads20000> greyback: thank you! :)
<greyback> ads20000: ok I replied, did I answer the question ok?
<ads20000> greyback: That's excellent thank you! My only question would be about the dev environment you suggested, is it a problem that Ubuntu 16.04 LTS and 16.10 use old versions of Unity 8? Quite a while ago some people said they would try to push Unity 8 updates to 16.04 by SRU and to 16.10 but this hasn't happened...
<ads20000> greyback: I.e., is it OK if they test their application on those old Unity 8 versions? Would it still work on more recent ones? :)
<bregma> just an addition to that answer: Ubuntu 16.04 and later comes with Mir and Unity 8 installed by default, it's just not the default shell selected when you log in
<bregma> no need to install extra packages or anything
<bregma> er, sorry, 16.10 not 16.04
<bregma> my mind said 16.10 and my fingers typed 16.04, I think I need new fingers
#ubuntu-mir 2017-02-23
<bregma> tjaalton, Xmir branch at https://git.launchpad.net/~xmir-team/xorg-server/+git/xmir/?h=xmir-1.19 now builds and tests cleanly on Zesty if you can find the time to integrate into xorg-server
<tjaalton> bregma: sweet, thanks! will do that next week when I'm back
<greyback> alf_: On https://bugs.launchpad.net/mir/+bug/1667001   I think repowerd is innocent, suspect Mir/kms
<ubot5> Ubuntu bug 1667001 in unity8 (Ubuntu) "[amd] screen-unblanking seems to flicker backlight on/off 5 times before display resumes" [Undecided,Incomplete]
<greyback> I've attached the log you requested
<alf_> greyback: thanks
<greyback> alf_: the machine is by me if there's anything else I can offer you
<alf_> greyback: if you are willing to recompile repowerd we may get some more hints about what's going wrong
<greyback> alf_: Sure. I know it's not a high priority bug though, so only if you want
<alf_> greyback: sure, let's do it now that it's hot :)
<alf_> greyback: git clone lp:repowerd (assuming you have set the lp: shortcut for git)
<greyback> I have
<alf_> greyback: build repowerd the usual cmake way (no special options needed)
<alf_> greyback: get the deps first of course
<alf_> greyback: ... "sudo systemctl stop repowerd" to stop the system one, and from the build dir run the git version with 'sudo REPOWERD_LOG=console bin/repowerd'
<alf_> greyback: make sure it works and you can see the same issue as before
<greyback> ok
<greyback> alf_: my build machine != my test machine, can I just copy over the repowerd binary, or do I need the tools too?
<alf_> greyback: not yet, perhaps later depending on the results of our experiments
<greyback> alf_: repowerd binary is 10mb!
<greyback> alf_: http://pastebin.ubuntu.com/24053613/ <- any idea?
<alf_> greyback: do you have repowerd-2017.02 installed on that system?
<greyback> alf_: no 2016.12+17.04.20161212.1-0ubuntu1
<alf_> greyback: ok, then update (and stop the system repowerd again)
<greyback> ok
<greyback> alf_: http://pastebin.ubuntu.com/24053671/
<greyback> same issue with the newer repowerd
<alf_> greyback: good
<alf_> greyback: one thing to change to see if it makes a difference: make the turn_on() call to USC synchronous
<alf_> greyback: so in src/adapters/unity_display.cpp
<dandrader> alan_g, how do I get the top-left position of a miral::WindowInfo?
<alan_g> dandrader: wi.top_left()
<greyback> alf_: done, trying
<alf_> greyback: in ::turn_on() change the dbus call to _sync and remove one "nullptr,"
<greyback> alf_: already done ;)
<alf_> greyback: ack
<greyback> I am still surprised how big the binary is
<dandrader> alan_g, ah, you mean windowIndo.window().top_left()
<dandrader> *windowInfo
<alan_g> dandrader: oh, right. yes
 * alan_g isn't a good autocomplete function
<greyback> alf_: yes it seems to block on that TurnOn dbus call, as the screen flickers
<alf_> greyback: It's all the debug info I guess? The released binary is much smaller (~700kb)
<greyback> alf_: yeah probably
<alf_> greyback: ok, so this strongly indicates that repowerd is not doing anything strange, but let's experiment a bit more
<alan_g> c++ debug symbols are BUG
<alf_> greyback: with the screen on stop repowerd (ctrl-c)
<alf_> greyback: i.e. I want the backlight to stay on
<greyback> yep
<alf_> greyback: now just turn USC rendering on/off manually to see what behavior you get: sudo gdbus call --system --dest com.canonical.Unity.Display --object-path /com/canonical/Unity/Display --method  com.canonical.Unity.Display.TurnOff "all"
<greyback> alf_: I've actually gone further. A while ago I made this tool: https://code.launchpad.net/~gerboland/+git/display-configurator
<greyback> alf_: just extending the mir display config tool, adding display power on/off stuff
<greyback> alf_: if I ask mir to turn off the display, and then on, the on causes the same flicker
<alf_> greyback: ok, just wanted to test if the backlight state affects this at all
<alf_> greyback: it seems not
<greyback> alf_: ack
<alf_> greyback: ok, so repowerd is out... anything interesting in /var/log/lightdm/unity-system-compositor.log
<alf_> greyback: or in /var/log/syslog for that matter? Any drm kernel messages?
<greyback> alf_: I tore it down to the simplest elements: mir_demo_server_basic and my test client. From Mir: http://pastebin.ubuntu.com/24053776/
<greyback> there's a small complaint from kms about invalid argument for Gamma setting
<greyback> but I see nothing at all relevant in syslog or dmesg
<greyback> actually I get the flicker when I turn off the display too
<greyback> and setting mir power mode to 1 (on) does not enable the display again
<greyback> I have to kill the client to get the display to turn back on
<alan_g> greyback: I just submitted a QtMir MP that ran into LTTng errors that seem unrelated. Is there a known problem?
<greyback> alan_g: news to me
<greyback> dandrader|afk: ^^
<alan_g> Hmm, seems to be just my MP.
 * alan_g can't ignore it
<alf_> greyback: I am out of easy-to-test ideas. I guess next step would be to check if something wrong is going on at the Mir platform/backend level, and if everything is fine there, too, then it's probably a driver or hardware issue.
<greyback> alf_: ack. I'm updating the bug with all I've found, but I expect it's driver/hardware
<alan_g> greyback: not sure what the cause is, but after "apt update" it is happening locally on a clean lp:qtmir. :(
 * greyback trying
#ubuntu-mir 2017-02-24
<greyback> alan_g: qtmir still building ok for me here after all updates
<alan_g> greyback: it is working for me in CI, but now failing locally!
<greyback> alan_g: zesty I presume. Care to share the error message?
<alan_g> X+O actually, I got a compile error (wrong version of dep I guessed) on Zesty so switched to my test laptop for qtmir
<greyback> oh, let me try that
 * alan_g should try Zesty again
<alan_g> greyback: on Zesty I have "Broken qtmir-build-deps:amd64 Depends on libubuntu-app-launch3-dev:amd64...I can't find libubuntu-app-launch3-dev:amd64"
<greyback> alan_g: I don't have a libubuntu-app-launch3-dev installed, only 2-dev. But I do have  libubuntu-app-launch3 installed. Both with equal versions. You might be on to something
<alan_g> greyback: not sure what's going on. But cmake says "No package 'ubuntu-app-launch-3' found" and I apt search doesn't find it.
<greyback> alan_g: it is in zesty-proposed
<alan_g> Ah. I'm on the plain archive.
 * alan_g will stick to X+O for qtmir today
<greyback> alan_g: which should be fine. I presume it got stuck in release
<alan_g> A bit odd that I see libubuntu-app-launch3 but not -dev, but SEP
<greyback> that confuses me too
<greyback> afaics it should pass through proposed fairly soon
<greyback> On X+O I do get a lttng fail when running tests though, that is new
<alan_g> Glad to have that confirmed, but CI seems to have recovered from that - so I'm losing interest. (OTOH I don't know why my laptop hasn't)
 * alan_g has found a (probably) Mir bug to track down instead
<dandrader> alan_g, confirm_inherited_move takes a Displacement and returns a Rectangle. Does that mean that a movement can affect the window's dimensions!?
<dandrader> alan_g, if the policy wants to do it, that is
<dandrader> alan_g, but that also means that the policy has to be careful enough when filling the returned Rectangle if it doesn't want to affect the window size there...
<alan_g> dandrader: that's right
<dandrader> alan_g, can MirWindowVisibility affect MirWindowState? Ie, if a window is mir_window_visibility_occluded, can miral refuse to apply certain state changes?
<alan_g> By miral do you mean libmiral or a server using it?
<dandrader> alan_g, miral or mir
<alan_g> dandrader: no, I can't see a reason to do that
<dandrader> alan_g, what about a window that is not "ready" yet?
<dandrader> alan_g, can that affect state changes?
<alan_g> dandrader: no, I can't see a reason to do that
<dandrader> alan_g, ok
<dandrader> trying to make sense of a strange behavior in unity8
 * alan_g feels he hasn't understood the real question
<alan_g> Ah! U8 is often a mystery to me.
<dandrader> :)
 * davmor2 hands alan_g https://www.youtube.com/watch?v=hgee3IGYZsU
 * alan_g suspects rickrolling
<davmor2> alan_g: I promise it isn't
<davmor2> alan_g: it's just an apt song for your U8 knowledge :D
<alan_g> Is Toyah better?
<davmor2> alan_g: Hey I know way more annoying songs
<greyback> that's true, he does
<alan_g> LOL
