#ubuntu-mir 2013-07-08
<RAOF> Clang once again to the rescue, with error messages that are (a) readable on a 1366x768 screen and (b) actually tell you what the error is.
<duflu> RAOF: Any idea why we have all-the-X-things in staging now? Looks crowded... https://launchpad.net/~mir-team/+archive/staging
<RAOF> duflu: Because we're about to go through the Xserver 1.14 transition, so I pushed that through staging first.
<duflu> OIC
<RAOF> And you can't just upload the server + any drivers with XMir changes, because the server ABI changed; you need the full enchilada.
<RAOF> Hm.
<RAOF> Dear filesystem: why is that file 0 bytes?
<duflu> RAOF: New laptop yet?
<RAOF> Nope. Should be shipping soon.
<duflu> robert_ancell: Can you add this to 0.0.6? https://bugs.launchpad.net/mir/+bug/1130553
<ubot5> Ubuntu bug 1130553 in Mir "Mir does not support eglSwapInterval(0)" [Medium,Fix released]
<robert_ancell> duflu, done
<duflu> Ta
<tvoss> good morning :)
<duflu> Morning tvoss
<tvoss> duflu, hey :) how goes?
<duflu> tvoss: Monday afternoon and still waking up. You?
<tvoss> duflu, Monday morning, mostly awake :)
<tvoss> although my caffeine level could be higher
<duflu> It could always be higher...
<duflu> To about 100 cups a day, which I believe is the lethal dose
<didrocks> tvoss: hey
<didrocks> how are you?
<tvoss> didrocks, hey :) quite good, summer here in Germany. How about you?
<didrocks> tvoss: same here, and seems the week will stay on that note ;)
<tvoss> didrocks, hopefully :) So for Unity and Nux: I will push out those branches shortly
<didrocks> summer finally \o/ (before apparently not so splending end of July and bad August)
<didrocks> tvoss: excellent, you answered before even I asked! :p
<tvoss> didrocks, sure :)
<didrocks> tvoss: do you still have my branch somewhere?
<tvoss> didrocks, let me find it :)
<didrocks> should be https://code.launchpad.net/~didrocks/unity/new-gmock
<tvoss> https://code.launchpad.net/~didrocks/unity/new-gmock
<didrocks> :)
<tvoss> didrocks, mind pinging me the gmock package location again? would like to check in a chroot
 * duflu wonders who "Ken" is
<didrocks> duflu: kenvandine?
<didrocks> or kevin duboi?
<didrocks> duboit*?
<duflu> didrocks: Kidding. I think your meant Kevin... https://code.launchpad.net/~didrocks/mir/use-system-googlemock/+merge/173008
<didrocks> ah Kevin ;)
<duflu> I think I meant "you", not "your"
<didrocks> duflu: more than possible, it's coffee-1 here (speaking of whichâ¦) ;)
<didrocks> tvoss: https://code.launchpad.net/~didrocks/location-service/devsuggestsdoc/+merge/173136
<didrocks> tvoss: btw, you did approve it, but not globally approve?
<tvoss> didrocks, done
<didrocks> tvoss: thanks
<didrocks> let me look for the location service gmock branch
<didrocks> tvoss: https://code.launchpad.net/~didrocks/location-service/build-with-system-gmock
<tvoss> didrocks, did you see my question for the new gmock package?
<tvoss> didrocks, wanna propose that location-service branch?
<didrocks> tvoss: we need to upload the gmock package first to distro, but sure, can propose
<didrocks> tvoss: ppa:didrocks/ppa for the gmock package
<didrocks> https://code.launchpad.net/~didrocks/location-service/build-with-system-gmock/+merge/173407
<tvoss> didrocks, approved but no top-approve yet
<didrocks> tvoss: perfect, thanks!
<duflu> alf___, hello... ?
<alf___> duflu: hi!
<duflu> alf___: compositor_buffer(), is that actually latest_complete_buffer() ?
<dholbach> good morning
<duflu> Morning dholbach
<dholbach> hi duflu
<alf___> duflu: it's the next buffer to be consumed by the compositor, it may be the latest submitted clien buffer or not (e.g. if the client has submitted two unprocessed buffers it's not the latest)
<duflu> alf___, cool. But it is "complete" either way
<alf___> duflu: what does complete mean?
<duflu> alf___, I mean the client has finished rendering to it
<alf___> duflu: yes
<alf___> duflu: @different-mesa-display-validation-functions, how about mir_server_mesa_egl_display_is_valid(), mir_toolkit_mesa_egl_display_is_valid()?
<duflu> alf___, Argh. I think I prefer "server". We have outstanding tasks/arguments against "toolkit"
<alf___> duflu: mir_server_mesa_egl_display_is_valid(), mir_client_mesa_egl_display_is_valid() ?
<duflu> alf___, I don't think my review was blocking really
<duflu> alf___, Yup sounds better. I wonder if we're still inconsistent omitting "native". Bu that makes it longer
<duflu> That reminds me. I meant to add a typedef for mir_bool to improve the client API readability
<alf__> duflu: mir_server_mesa_egl_native_display_is_valid(), mir_client_mesa_egl_native_display_is_valid(): perphaps they are not too bad considering only mesa (through dlsym) and a couple of tests will use them.
<duflu> alf__: Yeah I'm undecided about "native". It's more consistent but makes it marginally too long. Abstain.
<alf___> duflu: (flaky connection may have lost messages) mir_server_mesa_egl_native_display_is_valid(), mir_client_mesa_egl_native_display_is_valid(): perphaps they are not too bad considering only mesa (through dlsym) and a couple of tests will use them.
<duflu> alf___: Yeah I'm undecided about "native". It's more consistent but makes it marginally too long. Abstain.
<duflu> alf___: I will use MPs/email for you from now on :)
<greyback> alf___: duflu: hi guys, either of you have good understanding of the input stack?
<duflu> greyback: I have some experience from the client POV
<greyback> duflu: it's more the server POV I'm asking from. But maybe you'll have an idea
<greyback> Shell is a surface that will always be "on top". I also need shell to receive all input events, even with another surface has focus
<greyback> so in my shell mir configuration, I can add a EventFilter to the chain of eventFilters - which is the solution I believe
<duflu> greyback: Yeah InputFilters are meant to do that. But I'm not saying the design is perfect yet. Perhaps we need to marry InputFilters with a particular surface, sometimes
<greyback> but what I need to be able to do is pass those Events to the shell input handler itself
<duflu> greyback: The one from mir_surface_set_event_handler ?
<greyback> duflu: yep
<duflu> greyback: We could do that. We already merge multiple event sources into that behind the scenes in libmirclient
<duflu> greyback: Not sure about specifics. Can you log an enhancement for racarr to look at too?
<greyback> duflu: will do
<greyback> thanks
<duflu> No problems
<duflu> -s
<duflu> greyback: So that means you're linking libmirclient and libmirserver?
<greyback> duflu: no I'm not
<greyback> it's something I need to do from the server side
<greyback> duflu: quick terminology check: EventFilter handles events, returns true if accepted, false if not. EventSink similar but always returns true?
<greyback> i.e. doesn't allow events to propagate
<duflu> greyback: Argh. I wrote EventSink and don't remember
 * duflu checks
<duflu> greyback: EventSink is unconditional (returns void)
<duflu> So that's kind of like true (handled) and false (continue to next sink)
<greyback> duflu: ok, that's how I expected it.
<duflu> Although AFAIK, we don't yet have chains of EventSinks. It's only ever 1:1
<greyback> that's ok
<greyback> really my issue is, how to get the EventFilter associated with a Surface
<duflu> greyback: Yeah it's a good question. But there might be architectural considerations racarr can think of before we dive in
<tvoss> greyback, what are you trying to solve?
<greyback> duflu: indeed. I'll get his advice
<duflu> greyback: Actually I had thought of it already, and started. Some events already contain surface IDs. We need more of them to (input events too)
<greyback> tvoss: the shell surface will always be on top of the application surfaces. I need also that the shell surface receives all events, even if application surfaces have focus.
<duflu> So we need a mir_surface_post_event(event_caught_by_my_filter)
<tvoss> greyback, hmmm, I would propose an event filter implementation that "knows" about the shell surface
<greyback> tvoss: sounds right, yes
<greyback> but the part I'm unable to solve is how to know get the event filter of the shell surface
<duflu> greyback: How about just letting the filter "requeue" it conditionally and the event trickles down to the surface per usual?
<greyback> duflu: that could work...
<duflu> greyback: We should have it already. If filter returns false I would have thought it should go on to the surface... ?
<duflu> Otherwise, what's the point in returning that bool?
<greyback> duflu: true. I can't see why it wouldn't. I'll give it a go
<duflu> greyback: Sounds vaguely like some input bugs I've encountered. So maybe it's just a little broken. But I think it is meant to work like that in theory
<duflu> Of course, a filter can handle an event and still return false to send it on to the surface too.
<greyback> duflu: ah there will be times when shell should accept the event, so application doesn't get it
<duflu> greyback: Yes just return true in that case
<duflu> Oh, I forgot. You need the surface handle still
<duflu> OK
<greyback> yep
<duflu> greyback: So all you want to know is what was the surface that "would have" received the event, had it not been caught in the filter?
<duflu> Of course, this is why XEvent has the window field :)
<greyback> duflu: with my current understanding: I want a pointer to the event filter for surface x
<greyback> because I think it makes most sense for me to grab the event filter of the shell, and push it to the start of the EventFilterChain. As is done in demo-shell
<tvoss> greyback, +1
<tvoss> duflu, I think we can save the hassle of hit testing if greyback's filter implementation knows the shell surface and just passes on the event
<duflu> tvoss: Yeah there might be a use case for redirection in future anyway. In which case we just want a send_event(event, surface)
<duflu> Although it would be nice if input events told you the target surface ID too
<tvoss> duflu, later down in the filter chain: yes, definitely.
<tvoss> didrocks, down to one issue with mismatch between header files and library linked in for unity
<didrocks> tvoss: phew, nice work! It seems they changed the API quite extensively (but not surprising in 2 years)
<tvoss> didrocks, oh, it's more or less subtle: testing::internal::String is now std::string and the linker gets confused
<didrocks> tvoss: am I the only one to think there are too many internal replications of std types in unity btw?
<tvoss> didrocks, not sure what you are referring to
<didrocks> tvoss: the glib::string types and all those kinds of mapper
<tvoss> didrocks, oh yeah, that's ugly, but still: I don't think we should touch that code until absolutely necessary
<didrocks> tvoss: agreed, that's why I wasn't sure the mismatch with latest gmock was due to something like that, I didn't take time to look at it closely TBH
<tvoss> didrocks, different question: assume that I would like to install test executables. Where would be the most appropriate place to put them?
<didrocks> tvoss: I think we would create a binary -tests package
<didrocks> tvoss: not sure what's the point for non integration tests though
<tvoss> didrocks, basic smoke testing could benefit from being able to run the tests against an existing image
<tvoss> didrocks, mir is not the best example for that approach, but platform-api is
<didrocks> tvoss: ok, so tests for the integration with the rest of the platform (libs, perfs and so on)
<didrocks> yeah, I think a -tests package is reasonable
<tvoss> didrocks, yup
<tvoss> didrocks, what about the path? /usr/bin?
<didrocks> tvoss: I would prefer libexec to not polluate the $PATH
<tvoss> didrocks, ack. btw: for nux, we need bregma's help, my autoconf foo is not sufficient
<didrocks> tvoss: sounds good :)
<duflu> alan_g: Why does mir_demo_server* lose/hide/mangle stdout and stderr?
<duflu> Sometimes I can see part of one line, but that's all
<alan_g> duflu: I didn't know it did
<alan_g> it shouldn't
<duflu> Hmm maybe it's only when I run it from the VT. Maybe the VT output is blocked
<alan_g> alf___: ^
<alf___> duflu: If you mean that you lose the output that should be output to the VT, that's normal since we put the VT in graphics mode. If you mean that you lose output after having redirected it, then that's a problem.
<duflu> alf___, OK normal is good
<duflu> I'll use ssh for debugging
<alf___> duflu: (or redirect to a file for non-live debugging)
<duflu> alf___, Yep thanks
 * duflu stresses his GPU so much that it makes a /new sound/
<RAOF> Wow. They're not lying when they say clang's static analyser makes compilation slow.
<duflu> RAOF: BTW confirmed clang on saucy works well. So well I can actually run clang-built mir with it
<duflu> Tho, clang's binaries are slightly slower
<RAOF> Feel like trying -O4? :)
 * alan_g thinks the point of supporting clang is that the binaries work
<duflu> Clang was just to improve code scanning... and to further prove the correctness of the code. Yes.
<RAOF> Also error messages.
<duflu> Yes, how could I forget clang's lovely colours
<duflu> ?
<tvoss> didrocks, https://code.launchpad.net/~thomas-voss/unity/new-gmock/+merge/173450
<didrocks> tvoss: building and testing :)
<didrocks> tvoss: argh, failing to build, but it's because I don't have the right xorg version yet
<didrocks> tvoss: I'll wait for the current proposed migration to finish
<tvoss> didrocks, okay
<tvoss> didrocks, ack
<RAOF> Wow. clang-analyse finds only 22 bugs in Mir, of which only 5 are actually in our code, most of which are in the demos.
<alan_g> RAOF: *Only*? That's 22 too many! (How many are legit bugs?)
<RAOF> Of the 5 I've looked at, it's not clear that 3 of them are bugs, one is an obvious bug, and one is a not-checking-for-errors.
<alan_g> That's pretty good. IME static analysis tools can create a LOT of false positives.
 * alan_g decides to look himself later
<RAOF> Enjoy: https://code.launchpad.net/~raof/mir/fix-two-clang-analyse-results/+merge/173462
<RAOF> Hm, first result in android-input also looks legit.
<RAOF> Ah, and the protobuf ones would be because clang doesn't understand GOOGLE_CHECK(), which I presume will evaluate to either an exception or an assertion.
<alan_g> alf__: RAOF - do you guys recognise "/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../x86_64-linux-gnu/libEGL.so: undefined reference to `mir_egl_mesa_display_is_valid'" - I'm getting that on trunk this morning
<RAOF> alan_g: We *have* been poking around that area of the code, but I thought we'd removed all the direct linkages.
 * RAOF checks his checkout.
<alf__> alan_g: RAOF: Yes, I don't see any direct linkage that could cause this error, what does 'ldd /usr/lib/gcc/x86_64-linux-gnu/libEGL.so' say?
<alan_g> alf__: "ldd: /usr/lib/gcc/x86_64-linux-gnu/libEGL.so: No such file or directory" ;)
<alf__> alan_g: oops, ldd /usr/lib/x86_64-linux-gnu/libEGL.so
<alan_g> alf__: ;) http://paste.ubuntu.com/5855073/
<alf__> alan_g: objdump -p /usr/lib/x86_64-linux-gnu/libEGL.so ?
<alan_g> alf__:  http://paste.ubuntu.com/5855080/
<alf__> alan_g: that's not right: "NEEDED libmirclient.so.1", so you need to update your mesa version, and I also need to push some naming changes to trunk, just a moment
<alan_g> alf__: looks like I should read upgrade info more carefully - http://paste.ubuntu.com/5855087/
<alf__> alan_g: :)
<alf__> RAOF: Is the Mesa in staging uploaded automatically when your repo changes?
<RAOF> alf__: Yes.
<RAOF> After an hour or so.
<RAOF> There *is* a manual step of propagating the changes from the egl-platform-mir branch to the mir-ppa branch.
<RAOF> Hm. Again with the everything-deadlocking-in-the-kernel.
 * RAOF goes to sleep, like his kernel.
<alan_g> alf__: are you happy with https://code.launchpad.net/~alan-griffiths/mir/SessionMediator-session-race/+merge/173247?
<alf__> alan_g: looks good, although I was under the impression that each SessionMediator would need to handle only one request at a time
<alan_g> alf__: I don't think there's anything stopping asio starting a new request while an existing one is running. And then there are shutdown cases...
<alf__> alan_g: yeah, I guess my impression came from the client side, where we have a single thread servicing client requests...
<netlar> does Mir use the Gallium open source driver?
<alan_g> netlar: I don't think that's been tried. alf__ ^?
<alf__> netlar: Mir uses the Mesa drivers on the desktop. The radeon and nouveau drivers are implemented using Gallium3D internally.
<netlar> alf__: So it should be very similar to X.org
<alf__> netlar: the plan is not to be :D
<netlar> alf__: I do wonder if my graphics card will be supported
<netlar> I have a Radeon 7750, has the Cape Verde chipset
<alf__> netlar: (but in terms of hardware support it would be similar)
<netlar> Is that because it is going to use the Mesa and Gallium drivers?
<alf__> netlar: yes
<netlar> alf__: Is there a list of radeon cards that have full support, becuase I think my card is still in testing stage
<alf__> netlar: http://xorg.freedesktop.org/wiki/RadeonFeature/
<netlar> thanks
<netlar> One more question please
<netlar> Is it going to be recommended to use the open source driver over the binary driver?
<kdub> netlar, whichever one works and is best suited to your preferences, I suppose
<netlar> kdub: I have always had trouble with the binary driver.  Just I do not get any 3d performance with the open source driver
<racarr> Morning!
<kgunn> didrocks: just a quick check...how are we for xmir into universe?
<kdub> hello racarr
<didrocks> kgunn: I think xmir will just be a patch on top of xorg? That's how RAOF wants to deal with it AFAIK
<racarr> Hi kevin :)
<kgunn> yep
<kgunn> racarr: hey
<didrocks> kgunn: personnaly, every daily release but Mir because of the bug lists I tagged 1.5 weeks ago :)
<didrocks> everything*
<racarr> and hello also kevin :D
<racarr> kgunn: I see you cancelled mir/unity sync...that must mean its done right?
<kgunn> racarr: you  wish :)
<kgunn> racarr: greyback was looking fwd to chatting today
<greyback> racarr: hey!
<kgunn> i just cancelled the regular meeting....cause we weren't being very regular
<kgunn> figured we'd just go ad-hoc
<racarr> greyback: Hey!
<racarr> want to sync up in say...15 min?
<greyback> racarr: sounds good
<racarr> I am still waiting for brian to come online
<racarr> ok great
<racarr> brb
<kdub> racarr, can I book a sync on remove-surface-target with you after that? :)
<racarr> kdub: Ok
<kgunn> didrocks: so we are good for daily release but not in universe
<kgunn> ?
<didrocks> kgunn: no, mir doesn't build on armhf/powerpc AFAIK
<didrocks> kgunn: so this is still blocking daily
<didrocks> (we can skip tests for both for daily, but we need the tests running on armhf for universe)
<kgunn> didrocks: this is what i was wanting to confirm with you....e.g. can we skip armhf/powerpc tests for daily
<kgunn> didrocks: my bad....didn't realize the intree gmock issue was still open
<didrocks> kgunn: yeah, but not for distro (at least, armhf)
<didrocks> kgunn: this is blocking for universe, I've done most of the patching
<didrocks> (7 components involved)
<didrocks> tvoss finished unity
<didrocks> the remaining one is nux
<didrocks> I tvoss asked bregma to do it?
<didrocks> think*
<tvoss> didrocks, not yet
<alf__> netlar: proper support for you chipset recently landed upstream (kernel+mesa) and it should be soon landing in distributions, so expect the situation to improve
<kdub> kgunn, i think we need a task to have the tests run 'driverless' on armhf
<kdub> or at least skip the tests without proper driver support
<bregma> I think we need to disable all integration tests within the package build, because they make no sense and give no useful results
<didrocks> bregma: can we have them as autopilot tests then? if they are integration tests? (I'm still wondering what they are testing then on i386 and amd64 ;))
<bregma> the tests that fail on armhf do not run on other platforms because they require the andoid drivers
<didrocks> bregma: so yeah, autopilot tests that can be triggered dynamically if a file is present maybe?
<didrocks> (like a file from qtubuntu-android)
<netlar> alf__: that is great news. and that would include 3d support?
<alf__> netlar: yes
<netlar> woohoo, love it
<racarr> greyback: Ok inviting you to a hangout whenever it's good
<greyback> racarr: go for it
<racarr> from my phone so I dont have a url
<racarr> but you hould get it in G+
<racarr> greyback: Not working?
<greyback> racarr: just managed to get into G+ now
<greyback> racarr: lp:~gerboland/+junk/qml-demo-shell/
<racarr> kdub: Want to talk about remove-surace-target now?
<kdub> racarr, sure
<racarr> kdub: Ok trying to invite you on G+
<racarr> greyback: Working some on the demo shell
<racarr> just installed a SurfaceBuilder to assign DepthIds
<racarr> so now clients open under the shell and transparency works, etc
<greyback> racarr: nice
<racarr> I still need to figure out why focus is broken
<greyback> racarr: though for me, clients were opening under shell and transparency was working
<greyback> but all's good :)
<greyback> I'm using a build of mir that's over a week or two old I think
<racarr> oh
<racarr> tht would explin it
<racarr> the stacking order was backwards actually
<greyback> aha
<racarr> but it wasn't noticeable because we
<racarr> used the hiding every other surface
<greyback> that explains a lot then, yes
<racarr> rather than restack approach
<racarr> but the shell surface isn't
<racarr> um
<racarr> subject to that
<greyback> tho still, the second app opened under shell, on top of first one...
<greyback> anyway, am building latest mir to check things out
<racarr> because
<racarr> the irst one was hidden
<racarr> it was actually "under" the first one still
<greyback> racarr: yep, makes sense
<racarr> greyback: "Makes sense"
<racarr> XD
<greyback> well, it explains why what I was seeing was happening
<greyback> you know what I mean
<bschaefer> hey, so im hitting a fun problem:
<bschaefer> (EE) Failed to load /usr/lib/xorg/modules/drivers/intel_drv.so: /usr/lib/xorg/modules/drivers/intel_drv.so: undefined symbol: xorgMir
<bschaefer> seems theres a new intel driver the mir ppa hasn't been built with?
<tvoss|dinner> bschaefer, did you pin the ppa?
<racarr> greyback: Of course :)
<bschaefer> tvoss|dinner, pin the ppa?
<tvoss|dinner> bschaefer, making sure that updates from the archive that are newer than the ppa don't override the ppa packages
<bschaefer> tvoss|dinner, o, well thats a nice features... and no I have not pined it, which I should have :)
<kdub> racarr, i'm teasing out the state from ms::Surface, and looking at the transformation
<kdub> seems that its just used by the graphics side, but will the input side need the transform eventually?
<racarr> kdub: Yes.
<kdub> racarr, thought so, i'll just put that info in the generic info about the surface
<kdub> for anticipated future use :)
<racarr> Excellent
<tvoss> bschaefer, http://www.olli-ries.com/running-mir/
<tvoss> greyback, ping
<greyback> tvoss: pong
<bschaefer> tvoss, thanks
<tvoss> bschaefer, yw
<kgunn> racarr: just reading the scrollback...i guess client focus notif is broken huh?...so nvmd my last question about it
<racarr> kgunn: It's 90% done. I just need to find time to come bck to the branch
<kgunn> racarr: np
<greyback> racarr: you fixed it? https://code.launchpad.net/~robertcarr/mir/fix-input-obscurance/+merge/173586
<racarr> greyback: Yes the other thing is
<racarr> greyback: lp:~robertcarr/+junk/demo-shell-with-surface-controller
<racarr> it's kind of a hack
<racarr> in one place
<racarr> the shell is using..Window 1 a the surface name apparently? (maybe somewhere in papi or qtubuntu)
<racarr> and it just matches on tht to stack the shell surface higher
<greyback> racarr: ok. No idea what's setting the surface name. Probably papi, need to check
<greyback> is qtubuntu. WIll need to make that harder to guess
<robert_ancell> kgunn, these are the blocker bugs for entering the archive https://bugs.launchpad.net/mir/+bugs?field.tag=entering-saucy
<robert_ancell> (matches what we said)
<kgunn> yep
<olli> kgunn, https://blueprints.launchpad.net/ubuntu/+spec/mir-testing fyi
<olli> I will add a BP for the cert test rollout
<kgunn> olli: ack
<kdub> ms::Surface is shaping up :)
<kgunn> olli: let me know what you think https://blueprints.launchpad.net/ubuntu/+spec/mir-testing
<kgunn> robert_ancell: bregma ^
 * bregma looks
<robert_ancell> kgunn, is this supposed to be mir or unity testing?
<robert_ancell> kgunn, as I read it this is tests on Unity 7 on X, and then followed up later with the same tests on XMir?
<kgunn> robert_ancell: yes thats the idea
<kgunn> its a bit of regression testing combined wirh perf/ux
<robert_ancell> kgunn, ok, the name of the bp is a bit confusing, but the tests / rationale seem good
<robert_ancell> kgunn, I believe some of these tests should already exist right?
<bregma> OK, might want to add Super-S (a known problem performer in the past) and some FPS numbers for something like glxgears as a general representation of games
<racarr> greyback: For surface destruction I guess you could use the surface builder for notification but it's a little weird
<racarr> the session listener could be extended
<greyback> racarr: a bit yes, but it would work.
<kgunn> bregma: ack....
<kgunn> will add
<thomi> robert_ancell: Is the mir-team responsible for the ubuntu platform API?
<robert_ancell> thomi, no, see ricmm_ and others
<thomi> robert_ancell: OK, last time I asked I was told that the mir team would be taking over responsibility some time in the future. Is that still the case?
<robert_ancell> thomi, not that I'm aware of
<robert_ancell> kgunn, ^ ?
<thomi> ok, good to know - want to make sure I don't drop the wrong person in it ;)
<kgunn> thomi: mmm, where's that rumor coming from?
<kgunn> thomi: altho we do contribute to it in a way sometimes
<thomi> kgunn: I asked someone about it in Oakland... I think it was tvoss?
<kgunn> but i think that api is quite broad....e.g. convenience api's for an os basically
<kgunn> so even things like vcr functionality for music/video etc.
<kgunn> note...i've been known to be wrong
<kgunn> thomi: btw...since you're here....i see mir-stress on jenkins
<kgunn> so is there an extra step to make it part of ci ?
<thomi> kgunn: ugh... that thing is killing me slowly.
<thomi> kgunn: The job needs to be re-worked. I'm having huge trouble provisioning a machine and running mir on it. First I tried using UTAH, but when that failed miserably, I'm now tryingn an lxc container and otto
<thomi> it's been cauing me much stress - the bloody tests are there, but getting them to run is much harder than it ought to be
<kgunn> thomi: thanks for continuing to chase...i think you've proven them to be good tests which caught quite a few bugs
<thomi> kgunn: it certainly catches bugs, it's a pain that sooo much work is involved integrating it with our existing infrastructure
<kgunn> thomi: hmmm....is there any help to be called in ? any other experts to lean on or bang ideas against ?
<thomi> kgunn: I'm already leaning on people - my time zone gets in the way, as does the fact that at the moment my Internet connection is intermittent at best
<kgunn> thomi: well, if there's anyway to do something clever with your problem and sharing it...let me know...its definitely something we want
<thomi> yeah, will do
#ubuntu-mir 2013-07-09
<mterry> robert_ancell, heyo.  So I started on a dbus api branch for the greeter.  But...  I ran into some problems, partly terminology, partly unsure if u-s-c is just very incomplete now
<robert_ancell> mterry, hi
<mterry> robert_ancell, I have some IRC questions, but if interested, my simple branch is here: https://code.launchpad.net/~mterry/unity-system-compositor/greeter-api/+merge/173592
<mterry> robert_ancell, so (A) mir::Surface vs mir::Session inside of Mir.  Let's say I want the object that equals the whole user session image.  What is that called in Mir?
<mterry> mir::Session seemed to be app-oriented, but contain sub surfaces
<robert_ancell> mterry, mir::Session is a single connection to Mir. In the case of a shell/XMir they only have one mir::Surface. So mir::Session is the object that uniquely defines a user session
<mterry> robert_ancell, hmm, OK.  Each session is assigned a name.  The only place I could see that being set was creating ApplicationSessions, which seemed to be the app name.  What might those user mir::Session names be?  (I'm trying to see how to find a given session based on user name)
<robert_ancell> mterry, lightdm gives them a name so it can recognise them when they reconnect. At the moment it's just '0', '1', ...
<robert_ancell> though there is now a new feature where we get the PID for each session, so might switch to that
<mterry> robert_ancell, I couldn't find anything in mir or u-s-c that related to users, uids, or names
<robert_ancell> mterry, the ID is passed to XMir with the -mir flag xserver_local_get_mir_id() in lightdm
<robert_ancell> and that's used in the mir_connect call
<robert_ancell> see SystemCompositor::set_active_session for accessing that name - mir::shell::Session::name()
<robert_ancell> mterry, u-s-c doesn't know about users, but lightdm does. So I think the greeter is going to have to get that mapping from or via lightdm
<mterry> robert_ancell, ok
<duflu> This is crazy
 * duflu checks NBN rollout schedule
<thomi> robert_ancell, all: the mir docs upload job is broken. It's a known issue, and will be fixed in the next 24 hours - I'm just waiting on a new SSH keypair from Francis.
<robert_ancell> thomi, ta
<thomi> so the docs won't get updated, but I'm on it :)
<robert_ancell> mterry, still there?
<mterry> robert_ancell, yeah
<robert_ancell> mterry, was thinking more about the transition, can you do a call?
<mterry> robert_ancell, err, not easily
<robert_ancell> mterry, ok, np
<robert_ancell> mterry, the session being logged into needs to show  when the user starts authenticating for that session right? Is there a reason lightdm doesn't pick that up and notify u-s-c?
<robert_ancell> Are there more complicated cases where we need to synchronize the greeter with u-s-c?
<mterry> robert_ancell, not yet, but that puts u-s-c support into lightdm, which may not be ideal from an abstraction POV
<robert_ancell> mterry, I'm thinking this would just be contained to seat-unity.c, which would be acceptable in that sense
<mterry> robert_ancell, there's already special unity support?   I see, that wouldn't be any worse then
<mterry> robert_ancell, so sure, no need to involve the greeter then
<mterry> robert_ancell, and that means we don't have to poke a DBus hole for the lightdm user
<robert_ancell> mterry, yeah, the "unity" seat type is named like that so we can put whatever is appropriate in there
<robert_ancell> mterry, correct, we'd just use the link that lightdm has already to u-s-c which would be simpler
<robert_ancell> It would be more difficult if we need a more complex interaction, but I'm not seeing that at present
<mterry> robert_ancell, is there a u-s-c branch of lightdm for me to look at?
<robert_ancell> mterry, it's on trunk now
<mterry> k
<smartboyhw> robert_ancell, mterry http://paste.ubuntu.com/5857176/ ?
<smartboyhw> Freshly pulled from bzr
<robert_ancell> smartboyhw, you need a modified version of mesa, best got from https://launchpad.net/~mir-team/+archive/system-compositor-testing
<smartboyhw> robert_ancell, I do have that ppa installed
<smartboyhw> robert_ancell, I think that it is the problem of a new X version in archive
<robert_ancell> RAOF, ^ Do those recent naming changes match up in the PPA?
<robert_ancell> smartboyhw, you might be hit by this change http://bazaar.launchpad.net/~mir-team/mir/trunk/revision/821
<robert_ancell> heh, in saying that. I just compiled and I'm hitting the same problem :)
<smartboyhw> robert_ancell, HAH HAH HAH
<RAOF> robert_ancell: Just back from a run; I'll check in a moment.
<duflu> robert_ancell, smartboyhw: system-compositor-testing will not only have likely linkage problems, but crashes too: https://bugs.launchpad.net/bugs/1197260
<ubot5> Ubuntu bug 1197260 in Mir "Mir GL clients are crashing with SIGSEGV inside gl* calls" [Critical,Fix released]
<smartboyhw> duflu, uh
<duflu> Seems RAOF has updated staging but not system-compositor-testing yet
<RAOF> Oh, that would be right.
<duflu> Ugg, more raring FTBS regressions
<duflu> FTBFS
<robert_ancell> RAOF, what's stopping up updating X in the PPA to 1.14?
<RAOF> robert_ancell: It already is 1.14 in staging; I'm in the process of fixing XMir on hybrid systems, then I'll update the testing-ppa too.
<robert_ancell> RAOF, ok
<robert_ancell> thomi, is the raring mesa in https://launchpad.net/~mir-team/+archive/system-compositor-testing/+packages still coming from the autolanding system? Can we disable it if not?
<robert_ancell> racarr, around?
<smartboyhw> robert_ancell, you are in ~bug-control right?
<robert_ancell> smartboyhw, LP doesn't seem to have a group called that...
<smartboyhw> robert_ancell, ~ubuntu-bug-control?
<robert_ancell> smartboyhw, that doesn't seem to exist either
<smartboyhw> robert_ancell, just the Ubuntu Bug Control team...
<robert_ancell> ~ubuntu-bugcontrol
<robert_ancell> LP says I am an indirect member of that team, yes
<smartboyhw> robert_ancell, alright.
<thomi> robert_ancell: hmmm, will take a look. I didn't think we autolanded anything in there, but it seems we do
<duflu> thomi: Please keep raring open in staging at least. I'm using it :)
<thomi> duflu: it looks like it's not even building in raring
<thomi> I'll leave it along, since I didn't even know it was enabled, unless robert_ancell asks me to disable it again, in which case he wins ;)
<robert_ancell> thomi, ok, I'll delete the package, and bug you if it turns up again :)
<duflu> thomi: I'm talking about PPAs. I believe we already banished raring from autolanding and CI
<duflu> Because I remember the argument :)
<thomi> duflu: yeah, I'm talking about PPAs as well - the system-compositor-testing PPA in this instance
<thomi> I remember this argument as well, I also seem to get mixed instructions about raring support, so I'm not really sure what to do about that, beside give priority to the last request
<duflu> thomi: I only ask that you don't delete it from staging
<duflu> Although if I want a stable machine then one could argue I'm stupid for using PPAs
<thomi> duflu: ok, I'm not going to delete it from anywhere, but you'll need to upgrade to saucy and join the cool kids one day ;)
<duflu> thomi: I have several saucy machines. But I like raring
<robert_ancell> RAOF, any ETA on updating the system-compositor PPA?
<RAOF> robert_ancell: Everything's building in mir-team/staging now.
<robert_ancell> RAOF, k
<tvoss> thomi, ping
<tvoss> RAOF, ping
<thomi> tvoss: Hi
<tvoss> didrocks, ping
<RAOF> tvoss: Pong.
<didrocks> tvoss: pong
<tvoss> didrocks, hey there :) any update on the unity-gmock branch?
<tvoss> didrocks, also: a review of https://code.launchpad.net/~thomas-voss/platform-api/add-location-service-api-take-2/+merge/173457
<tvoss> would be highly appreciated
<didrocks> tvoss: it's building as we speach
<didrocks> tvoss: will have a look
<tvoss> didrocks, thanks :)
<didrocks> tvoss: do you know if bregma got to the nux branch btw?
<tvoss> didrocks, nope, no idea. Will ping him today
<didrocks> thx
<didrocks> tvoss: hum, you didn't fix the MP since I pinged you, right?
<didrocks> https://code.launchpad.net/~thomas-voss/platform-api/add-location-service-api-take-2/+merge/173457/comments/387948
<tvoss> didrocks, forgot to push ;)
<didrocks> :)
<tvoss> didrocks, pushed
<didrocks> tvoss: thanks, looking
<didrocks> tvoss: I don't understand your package naming convention
<tvoss> didrocks, why not?
<didrocks> libplatform-hardware-api1-hybris installs libubuntu-platform-hardware-api1
<tvoss> didrocks, yup, I would like to fix it, but in another MP
<didrocks> I guess your intend is that it's the platform hybris flavor?
<didrocks> tvoss: hum, you are introducing those new packages, wouldn't it be better to fix them right now?
<didrocks> rather than delivering another package that will have again a transition path needed?
<tvoss> didrocks, I would rather prefer to have that MP land as is in accordance with the rest of the packaging setup
<tvoss> didrocks, and clean it up in one go
<didrocks> tvoss: can we wait to land that one + cleanup the same day then?
<didrocks> 95 This package provides the hybris implementation of the hw-access parts of the Platform API.
<didrocks> -> this is > 80 characters, won't fit in some UIs
<didrocks> (same with -headers)
<didrocks> tvoss: please look at the lintian warnings, you have quite a lot on the -doc package as well
<tvoss> didrocks, can I just split the lines?
<didrocks> tvoss: sure, as long as it's not the short description, this is possible
<tvoss> didrocks, dpkg-buildpackage gives me the lintian warnings?
<didrocks> tvoss: debuild or bzr bd does
<didrocks> tvoss: you can launch manually as lintian *.deb
<didrocks> tvoss:          libplatform-hardware-api1-hybris | libplatform-hardware-api1,
<didrocks> okâ¦ let's wait for the package reshaping for that oneâ¦ :)
<didrocks> tvoss: just summed that up as https://code.launchpad.net/~thomas-voss/platform-api/add-location-service-api-take-2/+merge/173457/comments/388392
<tvoss> didrocks, for the comments: I wonder why this mp raises those concerns as the previous one that landed actually introduced the changes you are commenting (if I understand correctly)
<duflu> RAOF: ping
<RAOF> duflu: Fong.
<duflu> RAOF: Why don't I see, or why don't we need to set_crtc to a new DRM FB ID when the display's buffer object changes?
<didrocks> tvoss: the new packages are added in that MP, isn't it?
<didrocks> tvoss: the splitting in 2 packages
<RAOF> duflu: Because we drmModePageFlip instead.
<RAOF> (See kms_page_flipper.cpp
<RAOF> )
<didrocks> tvoss: the unity build failed, can you try to have your branch merged against trunk to ensure you have the barriers fix?
<tvoss> didrocks, nope, that's the branch you already approved :)
<didrocks> tvoss: that doesn't make the arg invalid. I'm reviewing 30+ branches a day, can do mistakes :)
<tvoss> didrocks, fair point :) I was just confused
<tvoss> didrocks, I fixed the lintian warnings and addressed your comments
<didrocks> tvoss: looking good, let me look at a last rebuild
<RAOF> Aaaand everything's deadlocked in the kernel again.
<tvoss> RAOF, \o/
<tvoss> didrocks, updated the unity mp
<didrocks> tvoss: so, approved with a missing long description fix (would be nice to do that) and waiting on the followup MP to get both landing
<didrocks> pulling unity
<tvoss> didrocks, I will take the package renaming discussion to ricmm and rsalveti once they are awake
<didrocks> tvoss: great :)
<dholbach> good morning
<didrocks> tvoss: hum, still has the same issue than with my branch
<didrocks> for unity
<didrocks> no target check-headless
<didrocks> tvoss: did you try running bzr bd on your branch?
<tvoss> didrocks, it fails locally, too
<tvoss> didrocks, still building locally :)
<tvoss> greyback, ping
<didrocks> tvoss: waow, you need ccache I guess :)
<tvoss> didrocks, yup
<tvoss> didrocks, I need a distcc cloud :)
<didrocks> heh
<didrocks> I did that some years ago on my machine
<didrocks> and then, became lazy
<ogra_> get faster hardware :P
<tvoss> ogra_, why not juju deploy massive-distcc-cloud
<greyback> tvoss: pong
<ogra_> tvoss, heh, feel free ....
<tvoss> katie_, ping
<katie_> tvoss, hi
<tvoss> katie_, can you add me to the hangout?
<katie_> tvoss, i'm in the hangout
<katie_> sure
<tvoss> didrocks, so there is no target check-headless, and make check fails due to an assertion in g_main_loop
<didrocks> tvoss: yeah, the check-headless target is only generated when unity successfully detected gtests and so on
<didrocks> from what I saw in cmake
<tvoss> didrocks, yeah, looking into that, too
<tvoss> didrocks, found the issue, final dpkg-buildpackage run to check that all is good
<didrocks> tvoss: ah, excellent! tell me once you pushed :)
<tvoss> didrocks, package build successful, pushed the changes
<didrocks> tvoss: built fine here as well, please link to the bug and make a MP
<didrocks> tvoss: oh, please add the version in google-mock build-dep
<didrocks> the only remaining one for new gmock is thus nux now
<tvoss> didrocks, done: https://code.launchpad.net/~thomas-voss/unity/new-gmock/+merge/173450
<greyback_> kdub: ping
<xjunior> Morning guys. Since yesterday I'm not being able to start X/XMir
<xjunior> it starts to initialize (I even see Mir's big arrow at the top-left corner)
<xjunior> Then crashes. Anybody having this issue?
<greyback_> xjunior: first I've heard of it. Would you mind following this guide on helping us figure out such problems: http://bazaar.launchpad.net/~mir-team/mir/trunk/view/head:/doc/debug_for_xmir.md
<xjunior> sure!
<greyback_> xjunior: appreciated, thank you
<smartboyhw> Hmm RAOF isn't here, so I can't ask him on the progress on building new X version
<xjunior> greyback_: the logs in /var/logs/lightdm seem way more useful than Xorg.0.log
<xjunior> greyback_: found this
<xjunior> Switching to Mir session 0
<xjunior> Logging to /var/log/lightdm/x-0.log
<xjunior> Can't launch X server X -core, not found in path
<xjunior> :P
<smartboyhw> :O
<greyback_> xjunior: did you pin the xmir packages, as described in http://unity.ubuntu.com/mir/installing_prebuilt_on_pc.html ?
<xjunior> xserver-xorg was removed by an update
<xjunior> not manually
<xjunior> yep
<greyback_> interesting.
<xjunior> greyback_: I didn't install that mir-demos package though
<xjunior> is it important? what's that?
<smartboyhw> xjunior, try installing xserver-xorg and see what will it remove...
<xjunior> I installed following another step-by-step
<greyback_> xjunior: a set of mir-demos, not vital IMO (only recommended as it pulls in all libmir* packages)
<xjunior> so, xserver-xorg has unmet dependencies
<smartboyhw> xjunior, what unmet dependencies?
<smartboyhw> !paste | xjunior
<ubot5> xjunior: For posting multi-line texts into the channel, please use http://paste.ubuntu.com | To post !screenshots use http://imagebin.org/?page=add | !pastebinit to paste directly from command line | Make sure you give us the URL for your paste - see also the channel topic.
<xjunior> xserver-xorg-core (>= 2:1.11) but it is not going to be installed
<xjunior> xserver-xorg-video-all but it is not going to be installed or xorg-driver-video
<smartboyhw> xjunior, if you install xserver-xorg-core what shows up?
<xjunior> boom
<smartboyhw> xjunior, ?
<greyback_> xjunior: you're not the first with the issue: https://lists.ubuntu.com/archives/ubuntu-devel/2013-July/037450.html
<xjunior> xserver-xorg-core : Depends: libmirclient1 (>= 0.0.6bzr828saucy0) but 0.0.6bzr798saucy0 is to be installed
<smartboyhw> Ah, I remembered that
<smartboyhw> xjunior, :O
<xjunior> smartboyhw: :D any idea?
<smartboyhw> xjunior, um, I
<smartboyhw> 'm looking @ the PPA
<xjunior> is there a base pack I can remove to uninstall everything, then I install all over again?
<smartboyhw> What happened it seems
<greyback_> xjunior: I'd first apt-get update, then try to install xserver-xorg-core, and then follow apt's recommendation to "apt-get -f install" - hopefully it'll downgrade the mirclient package and let you re=isntall xorg
<xjunior> greyback_: I've done dozens of apt-get update last hour
<tvoss> xjunior, best approach would be to purge the ppa from your system, reboot and readd the ppa
<smartboyhw> greyback_, xjunior the new xorg RAOF uploaded lists libmirclient bzr828 as dep
<ogra_> sounds like you had saucy-proposed enabled ...
<xjunior> apt-get -f install didn't help =/
<ogra_> never ever do that
<tvoss> xjunior, sudo ppa-purge ppa:mir-team/system-compositor-testing
<smartboyhw> But, obviously the PPA only has bzr798
<smartboyhw> It's PPA's fault
<tvoss> smartboyhw, mind filing a bug against mir?
<xjunior> ogra_: I have what?
<smartboyhw> tvoss, let the bug reporter file the bug himself
<ogra_> xjunior, do you have the saucy proposed archive enabled ? (you shouldnt)
<tvoss> smartboyhw, ah sorry, I thought you had encountered the issue, too
<xjunior> ogra_: I don't think I do
<ogra_> k
<ogra_> (it is just that we had someone yesterday who had that and X was completely removed due to that)
<xjunior> tvoss: ok, so I'll purge, update, upgrade and reboot?
<tvoss> xjunior, ppa-purge does the job of update and upgrade, only reboot should be required after that
<xjunior> nice
<smartboyhw> Well, hopefully someone will move latest mir into the testing PPA
<ogra_> heh, hopefully Mir will land in the archive soon instead
<xjunior> smartboyhw: do you think it will happen yet today? I don't mind waiting
<smartboyhw> xjunior, not sure, I need to ask RAOF
<smartboyhw> Who isn't here
<ogra_> australia sleeps :)
<smartboyhw> Yeah
<smartboyhw> I did meet him earlier in the afternnon
<smartboyhw> *afternoon
<tvoss> xjunior, mind if I file a bug against Mir?
<xjunior> slackers :)
<xjunior> tvoss: be my guest :) I wouldn't know how to do that
<xjunior> ogra_: couldn't find package list for PPA: mir-team
<xjunior> system-compositor-testing
<kgunn> bregma: ping
<kgunn> xjunior: https://launchpad.net/~mir-team/+archive/system-compositor-testing
<xjunior> ogra_: well. that's odd
<xjunior> but the ppa's source list was all commented out
<xjunior> it's doing its job now. I'll wait until tomorrow to try again the ppa.
<kdub> morning folks
<kdub> greyback_, pong
<xjunior> ogra_, tvoss, smartboyhw: back to g'old xorg
<smartboyhw> xjunior, good, wait for a few days then:)
<tvoss> xjunior, yup, filing the bug now :) we usually update the ppa during my mornings
<smartboyhw> Heh, the two pointers thing is quite annoying for me, ogra_ when will the fix land?
<xjunior> smartboyhw: I'm trying to get the PPA back and actually pay attention to what it upgrades
<greyback_> kdub: hey, let me unping you for a bit :)
<smartboyhw> tvoss, BTW why do you guys mark 0.0.6 as done but without actually releasing it?:P
<tvoss> xjunior, for your tracking pleasure https://bugs.launchpad.net/mir/+bug/1199399
<ubot5> Ubuntu bug 1199399 in Mir "System-Compositor-Testing PPA's Mir/XMir out of sync" [Undecided,New]
<xjunior> thanks a bunch, tvoss
<tvoss> smartboyhw, not entirely sure, best if you check with robert_ancell or duflu
<xjunior> tvoss: I re-enabled the PPA, apt-get update, installed unity-system-compositor
<xjunior> now apt-get upgrade
<xjunior> it doesn't want to remove my stuff now
<xjunior> let's see where this takes me
<tvoss> xjunior, let's see :9
 * smartboyhw raises eyes at xjunior 
<xjunior> alright
<xjunior> it seem to have installed and didn't remove anything
<xjunior> but xserver-xorg-core is being kept back
<xjunior> do y'all work at canonical, tvoss, smartboyhw ?
<tvoss> xjunior, I'm working at Canonical, yes
<smartboyhw> xjunior, not me
<smartboyhw> I'm a Ubuntu member though
<xjunior> ok, it broke again :)
<xjunior> got it
<smartboyhw> xjunior, ouch
<xjunior> at least it's consistent. I like consistency
<smartboyhw> xjunior, great
<smartboyhw> Well let's get that sorted shall we
<smartboyhw> tvoss, ^
<tvoss> smartboyhw, xjunior I think it's best to wait for RAOF to put the ppa in a consistent state again
<smartboyhw> tvoss, yeah
<greyback_> kdub: unping for now.
<xjunior> tvoss: indeed. I could track all that with you guys, but I'm working on an android app in that computer. can't be without it for now
<smartboyhw> xjunior, backup:p
<xjunior> smartboyhw: absolutely :)
<xjunior> git FTW
<xjunior> I know you guys like bazaar, though :P
<smartboyhw> Sorry, it's bzr+nano FTW for me
<smartboyhw> git is OK too
<smartboyhw> No SVN plz
<xjunior> SVN was great in the past.
<xjunior> smartboyhw: hey, which advantages do you see of bzr over git?
<smartboyhw> xjunior, less commands? Easier merging? Cleaner CLI?
<xjunior> Got itâ¦
<xjunior> don't fully agree with all of them, but cleaner CLI is very likely to be true ;)
<xjunior> tvoss: do you guys work remotely at canonical?
<smartboyhw> xjunior, well probably due to my age I don't like too complicated things (albeit I know quite a lot on packaging and QA and sort)
<kdub> greyback_, ok :)
<xjunior> smartboyhw: I never actually tried bzr, so I can't say much. I admit I had a lot of difficulties with git in the beginning, but after I learned it it's just an awesome tool
<smartboyhw> I like cleaner tools
<xjunior> specially if you've developed in C, or C++. The object model is quite interesting
<smartboyhw> And I appreciate those who made it
<xjunior> indeed. I'll take some time to try out bzr for sure
<tvoss> xjunior, yup
<xjunior> is it my impression, or does Mir/XMir looks sharper than Xorg alone?
 * smartboyhw does want to join Canonical (or better still Google) one day
<ogra_> Google means you need to move ... Canonical doesnt :)
<tvoss> ogra_, +1 :)
<smartboyhw> ogra_, I would rather move there to work
<xjunior> that's a big thing
<xjunior> I'm a former ThoughtWorker. Worked there for some years. Left because I wanted to be more home.
<smartboyhw> If I work @ Canonical, the only thing I wouldn't want to touch is Mir:P
 * smartboyhw rather likes kernel or QA
<xjunior> really? Seem like an interesting project
<smartboyhw> Well, maybe talk about it 10 years later or so
<smartboyhw> Still too young to be employed:P
<xjunior> I see where you're coming from.
<smartboyhw> xjunior, where?
<xjunior> smartboyhw: I mean, about rather working with Kernel and QA
<smartboyhw> xjunior, oh
<smartboyhw> Well, these are more *fun*
<xjunior> Just different kind of work. I like visual thingsâ¦ I'd work with Mir/Unity
<xjunior> also a big fan of dev-tools
 * smartboyhw likes sticking to a terminal
<bregma> kgunn, pong
<kgunn> bregma: hey...i was chatting w tvoss earlier...he was indicating now valgrind is up on arm...but now runs oom
<kgunn> bregma: i was trying to square this with what you were originally proposing
<kgunn> e.g. disabling the test
<kgunn> for arm
<bregma> kgunn, valgrind on qemu gets OOM on startup, but it runs fine on my N7
<kgunn> bregma: ah...so to parse it finer...disable for qemu ?
<bregma> no, the problem is actual tests are deadlocking on at least the N7, I'm proposing to just not run the integration tests on ARM because they exercise the Android drivers
<bregma> at least in the packaging, in Jenkins it's a different story
<ChrisTownsend> Hey all, I followed the directions here: http://unity.ubuntu.com/mir/installing_prebuilt_on_pc.html and now my system is in a bad state.  After plymouth, I see a big mouse cursor and then a black screen with a steady cursor in the upper left part of the screen.  Also, I cannot switch to any VT's.  Any ideas?
<bregma> ChrisTownsend, the big cursor is a good sign...  but it sounds like you have a broken Xorg somewhere, check /var/log/Xorg.0.log and /var/log/lightdm/* for signs of trouble
<ChrisTownsend> bregma: The problem is I cannot do *anything* right now.
<alan_g> ChrisTownsend: can you ssh in from another box?
<ChrisTownsend> I suppose I can boot a live stick and mount that partition and check.
<bregma> well, you can reboot into safe mode, too
<ChrisTownsend> alan_g: Umm, I'm not sure what the IP is and I can't check.
 * ChrisTownsend Tries recovery move
<ChrisTownsend> Err, mode
<bregma> if you can use recovery mode to comment out the type=unity line in /etc/lightdm/lightdm.conf, you should be good to go
<ChrisTownsend> bregma: Alright, I'll see if I can do that.
<smartboyhw> bregma, when is that big cursor going to disappear?
<ChrisTownsend> bregma: I don't have the line "type=unity" in /etc/lightdm/lightdm.conf
<ChrisTownsend> bregma: I think I found it in /etc/lightdm/lightdm.conf.d/10-unity-system-compositor.conf
<smartboyhw> ChrisTownsend, that's correct
<ChrisTownsend> Yay, it works
<ChrisTownsend> bregma: Thanks
<smartboyhw> It should:) ChrisTownsend now you're back at your normal X
<bregma> ...and all you need to do is figure out why lightdm doesn;t come up!
<ChrisTownsend> Oh, I see.  Well...
<bregma> smartboyhw, is one cursor is good, more is better
<smartboyhw> bregma, well, that's a bug actually
<smartboyhw> But it will take sometime to fix
<smartboyhw> I don't know the ETA
<bregma> it has to be gone by mid-August
<smartboyhw> DISCLAIMER: I'm NOT on the Mir Development Team or associated by Canonical by anyway, so don't ask me when it will fixed:P
<smartboyhw> bregma, I think the guys will be able to fix it by then
<bregma> right now we're sort of using the supernumerary cursor as a kind of watermark to indicate the Mir system compositor is running
<smartboyhw> bregma, yeah
<ChrisTownsend> Strange, it seems that the non Mir version of xserver-xorg-core is being held back.
<ChrisTownsend> So, the version of xserver-xorg-core in the Mir PPA depends on libmirclient1 >= 0.0.6bzr828saucy0, but the version of libmirclient1 in the PPA is 0.0.6bzr798saucy0.
<ChrisTownsend> Any ideas when this will be fixed?
<tvoss> ChrisTownsend, bug is filed: https://bugs.launchpad.net/mir/+bug/1199399
<ubot5> Ubuntu bug 1199399 in Mir "System-Compositor-Testing PPA's Mir/XMir out of sync" [Critical,Confirmed]
<tvoss> ChrisTownsend, RAOF will take care of it as soon as he comes nline
<dandrader> can I parallel-build (e.g. -j10) with cross-compile-chroot.sh?
<kdub> dandrader, it won't accept the parameter
<dandrader> kdub, so, when cross-compiling, I have to stick to one thread?
<kdub> the script is more useful for understanding how to set things up and for CI purposes
<kdub> dandrader, all it does really is set up the partial arm chroot, cmake, make
<dandrader> kdub, ah, ok, so I can just call make directly
<kdub> so you can go into the build directory and make -jX there
<dandrader> kdub, ok, thanks!
<greyback_> Anyone with XMir finding typing gets strange after a few hours? If I type 10 characters quickly, the first 9 come out reasonably fast, but the last after a delay of almost1/2  a second
<greyback_> tvoss: ever heard of that? ^^
<kgunn> greyback_: i had
<greyback_> kgunn: Xorg memory usage seems to be growing slowly too.
<kgunn> it seemed (seems) to relate to having a google hangout & flash having been run
<kgunn> at least some deduction around that
<greyback_> I've not had a hangout today
<kgunn> but honestly...it corrected itself sometime ago...
<greyback_> but if that reproduces it, great
<kgunn> yeah...yours might be new
<alan_g> greyback_: I've seen the same occasionally, but only without XMir.
<alan_g> Never found a pattern
<greyback_> well I've not experienced this before. I switched to XMir just today.
<xjunior> greyback_, kgunn: I experienced a lot of memory leak in hangout, but that's happening in OSX as well.
<xjunior> I blame google
<kgunn> xjunior: yeah...i've heard all sort of complaints about hangouts in recent updates (but strangely....its rock solid for me)
<greyback_> xjunior: but I've not used hangout today, so something else is the culprit
<xjunior> kgunn: my laptops are always on, also I use hangout daily for hours. I guess that helps to perceive the leak
<kgunn> greyback_: fwiw, i had that issue for like 1 day....but then magically disappeared as an issue
<greyback_> kgunn: well I'm logging it: https://bugs.launchpad.net/mir/+bug/1199450
<ubot5> Ubuntu bug 1199450 in Mir "[xmir] Inputs slowing, last event of a stream of events greatly delayed" [Undecided,New]
<greyback_> I can't give more info than that unfortunately
<xjunior> is it just my impression or ubuntu/unity details looks sharper when running on XMir?
<ChrisTownsend> tvoss: Ack, thanks
<om26er> when do we move to mir on mako as default ?
<kgunn> bregma: have you seen the oom for arm mir builds happen on pandas ?
<kgunn> ricmm_: ^
<kgunn> bregma: or was it only on the qemu ?
<kdub> some of our functions are only used in example code, sorta frustrating
<kdub> unless...
<kdub> well, i suppose some of what the shell team is using could be touching those
<racarr> recessitating client_ocus_notifications is running in to insane test failures...
<racarr> some of the changes in session mediator ended up doing something very weird in the tests... :(
<kdub> session mediator?
<kdub> racarr, with input tests, there's this bug https://bugs.launchpad.net/mir/+bug/1196744
<ubot5> Ubuntu bug 1196744 in Mir "intermittent acceptance test bug in TestClientInput" [Medium,New]
<racarr> kdub: Ill investigate ater I ifnish client-focus-notiications
<kdub> racarr, i'm curious the path the notification takes through the system
<kdub> but maybe I should just be patient until an MP :)
<racarr> kdub: Same as surface states
<testingmir> Hi All! I am testing 13.10 with Mir (from PPA). Got an AMD/ATI card, r600.
<testingmir> How do I verify that Mir is actually running? Dash is much slower (unaccelerated?) compared to vanilla 13.10.
<testingmir> Anything interesting that I should try out, like testing app?
<mlankhorst> sounds more like the mesa regression thing
<mlankhorst> in 9.1.X we reverted a bunch of patches to fix it, but the mesa in mir ppa probably doesn't have it
<mlankhorst> oh wait ati.. all memory is pinned in system memory unless you're using a recent drm-next kernel
<testingmir>  /usr/lib/nux/unity_support_test -p   shows  that llvmpipe is running, "Gallium 0.4 on llvmpipe (LLVM 3.2, 128 bits)".
<testingmir> How do I verify that Unity runs under Mir?
 * testingmir running Linux 3.10.0-2-generic.
<bschaefer> testingmir, a sign is there is a second cursor, also "ps aux | grep mir" should tell you if mir is running in the background
<bschaefer> testingmir, also checking your /var/log/Xorg.0.log could help you know why your driver failed to load
<testingmir> bschaefer: no 'mir' process is running, so this is not Mir. This is a fresh 13.10 installation (today's CD image), and the system booted OK with the radeon driver).
<bschaefer> testingmir, have you followed: http://www.olli-ries.com/running-mir/
<bschaefer> ?
<ChrisTownsend> testingmir: Unfortunately,if you installed today, the Mir PPA is out of sync: https://bugs.launchpad.net/mir/+bug/1199399
<ubot5> Ubuntu bug 1199399 in Mir "System-Compositor-Testing PPA's Mir/XMir out of sync" [Critical,Confirmed]
<bschaefer> there's also that problem :)
<testingmir> bschaefer: I configured my 13.10 with those instructions, http://www.olli-ries.com/running-mir/ (fresh install of 13.10)
<bschaefer> testingmir, I would wait until tomorrow unfortunately, for that ppa to get fixed up
<bschaefer> (hopefully by tomorrow!)
<olli> bschaefer, isn't it ps auf | grep unity-system-compositor?
<testingmir> ChrisTownsend: I see. On my initial boot of the system, I managed to see an oversize curson as soon as Mir got started, then a blank screen.
<olli> testingmir, sorry for the messed up PPA, we are all waiting for RAOF to get up and fix it
<bschaefer> olli, yeah that will tell you if unity system compositor is running, the other way I said will pick up if the mir server is running
<ChrisTownsend> testingmir: Yep, that's what I had too.  Wait for the PPA to get updated as bschaefer said.
<testingmir> bschaefer: ok. Is there a way to easily revert to the vanilla 13.10 for now, and try out Mir again tomorrow? Shall I ppa-purge when I need to switch?
<bschaefer> testingmir, yup! at the bottom of ollis blog, purge the ppa :)
 * bschaefer re-reads the blog just to be sure
<testingmir> bschaefer: nice. Olli's page is good. Thanks!
<bschaefer> testingmir, cool, yup :). np! Good luck tomorrow :), you can also check with the bug to see if its been resolved!
<olli> mterry, ping
<mterry> olli, hi
<olli> hey mterry is there a BP for the system compositor/flicker free boot work?
<mterry> olli, I'm not sure, I believe robert_ancell is working on that
<mterry> robert_ancell, did you see the question?  Looks like you logged in twice
<mterry> robert_ancell_, ^
<olli> mterry, I thought kgunn told me you are looking into getting mir in at boot time as system compositor
<robert_ancell_> mterry, been having network connection problems, seems better now
<olli> well, let me refine... you are working on the transitions
<robert_ancell_> mterry, can you repeat?
<mterry> olli, I've been helping test it, but not doing the work work
<mterry> olli, yeah, I'm looking at how to let the greeter transition into the session right now
<olli> robert_ancell_, do we have a BP for mir as system compositor/flicker free boot
<robert_ancell_> olli, https://blueprints.launchpad.net/ubuntu/+spec/client-1303-mir-system-compositor
<olli> awkward
 * olli could have found that himself
<robert_ancell_> :)
<olli> thanks robert_ancell_
<robert_ancell_> too many blueprints!
<olli> nah, didn't bother looking
<olli> ;)
<mterry> robert_ancell_, speaking of transitions, so I was looking at the current Mir API that u-s-c uses.  Notably, FocusSetter::set_focus_to
<mterry> robert_ancell_, do you want a new API proposal that's more targeted, like FocusSetter::set_underneath (or something better named) or something more generic, that lets a client reorder the stack in general?
<olli> kgunn, is there a BP that specifically addresses input device compatibility between X & Xmir?
<robert_ancell_> mterry, my gut feel is something more generic would be appropriate
<kgunn> olli: i think so...but need to dig
<kgunn> olli: altho, its probably something akin to "make sure input devices work"
<olli> heh
<olli> oki
<mterry> robert_ancell_, maybe in FocusSequence
<kgunn> and i suspect we'd want to be a bit more specific
<robert_ancell_> mterry, oh, sorry - I was thinking you meant the lightdm -> u-s-c API
<mterry> robert_ancell_, oh, for that, I was thinking we can be more specific, since it's closer to the feature
<robert_ancell_> racarr, ^ mterry needs to set the surface below the active one, what sort of API do you recommend for that?
<robert_ancell_> mterry, I was pushing for the shell just providing the sort function so you could handle cases like this easily. But no-one listens to me :)
<robert_ancell_> shell = u-s-c in this case
<mterry> robert_ancell_, for lightdm->u-s-c I was thinking a new message ID that meant "set_next_session" to mirror the "set_active_session"
<robert_ancell_> mterry, yeah, that sounds about right
<mterry> robert_ancell_, but can't seem to implement that in u-s-c with current Mir API, so would like some guidance from you or racarr
<robert_ancell_> mterry, racarr has been the one working on that API, so I'll have to defer to him at the moment. My feel is based on the current API we should just have a set_above / set_underneath
<racarr> robert_ancell_: mterry: Was picking up lunch :)
<racarr> I think I agree set_above/set_underneath
<racarr> What is the case here?
<kgunn> bregma when can we expect to have the arm valgrind tests disabled & close out that "entering saucy" bug ?
 * kgunn looks for a brighter future away from ppa hell
<bregma> kgunn, working on the gmock thing first, arm is queued next
<kgunn> bregma: thanks....think it'll be before weeks end ? (trying to balance how much tinkering we need to do on ppa automation)
<bregma> definitely
<bregma> hopefully by end of tomorrow for the lot
<kgunn> \o/
<olli> robert_ancell_, can you pls update me when the PPA is good again (mail)
<robert_ancell_> thomi, the version of u-s-c in the testing PPA is using one version older than libmirserver - is there a new version being built currently?
<olli> jono has a post waiting on that
<robert_ancell_> olli, will do
<olli> robert_ancell_, thx
<thomi> robert_ancell_: on a call, one moment
<mterry> racarr, sorry, my service is spotty apparently.  The use case for set_above/set_underneath is the greeter wanting to superimpose its surface on top of the user's session surface
<mterry> racarr, along those same lines, is there easy support for adding transforms like "blur this surface" to surfaces?
<kdub> mterry, no support for that yet
<mterry> kdub, understood
<racarr> mterry: The greeter is always above the session surface right?
<racarr> So you can give the greeter, DepthId{1}
<racarr> nd show/hide it
<racarr> then give all the user sessions DepthId{0}, then you can raise the user sessions, etc
<racarr> but the greeter will always be on top
<mterry> racarr, I didn't notice the API to futz with DepthId
<kdub> ms::SurfaceController needs some refinement, i think
<racarr> mterry: you can override the_surface_builder and assign them at construct time. it's slightly awkward perhaps (just in that the interface name is wrong)
<racarr> mterry: Let me find an example
<racarr> mterry: lp:~robertcarr/+junk/with-depth-ids
<racarr> unity-mir/surfacebuilder.cpp
<racarr> I have an intermittent test failure and I don't even know how to figure out if it's in the client or the server :( the client seems to block endlessly in one of mir_connection_release/mir_connection_sync
<racarr> but adding
<racarr> any prints or turning on logging makes it go away
<mterry> racarr, hrmm..   I'm not sure I fully understand DepthIds
<racarr> likewise gdb (even ignoring the difficulty of attaching to the child process)
<racarr> mterry: If there are two surfaces with DepthId X and Y and X > Y
<racarr> then X will always be on top of Y
<racarr> you can call
<racarr> raise(Y), and Y will be moved to the top of all surfaces with DepthId <=Y
<mterry> racarr, always meaning, even if I use FocusSetter::set_focus_to or some such?
<racarr> but still be under X
<racarr> mterry: Yes
<racarr> its like Layers
<mterry> racarr, OK.  I remember looking at them in the API, but they only were used at creation.  It makes sense now that you say I can override the surface builder
<racarr> excellent :)
<kdub> racarr, that hang you mention... in what tests?
<racarr> kdub: create_surfaces/create_surfaces_async
<racarr> it seems to also be in the input tests
<racarr> but I am trying to fix it in these first
<racarr> kdub_: Mine ends up being a deadlock on the client side mir connection
<racarr> it gets to MirSurface::release_surface which acquires the recursive lock on the MirSurface
<racarr> then calls MirConnection::release_surface
<robert_ancell> RAOF_, I've just copied over the staging mir, mesa and u-s-c into the compositor testing PPA, any reason why I shouldn't have done that?
<racarr> which trys to acquire the lock, but blocks because an RPC thread is
<racarr> has called MirConnection::handle_event
<racarr> taking the lock
<kdub_> hmm, with the input ones, i have a fix i've been using (it was the difference between surface creation/input callback registration)
<racarr> but MirConnection::handle_event tries to call
<kdub_> haven't hit that one though
<racarr> MirSurface::handle_event
<racarr> but the Surface is already locked from the
<racarr> original thread
<racarr> *deep breath*
<robert_ancell> thomi, RAOF, others, the system-compositor PPA seems to upgrade now, can you check if you can run XMir from it?
<robert_ancell> kgunn, ^
<kdub_> racarr, that sounds like it would be plausible though for the other deadlock
<RAOF_> robert_ancell: Not that I'm aware of.
<robert_ancell> RAOF, can you test the updated PPA asap? We have been in a broken state overnight
<RAOF> What blew up?
<RAOF> I tested the new X bits in the staging PPA, then copied them to -testing. Which shouldn't have blown up -testing.
<robert_ancell> RAOF, xorg depended on an old version of Mir I think, I can't remember the exact mismatch
 * robert_ancell looks through his logs
<RAOF> Hm. Xorg may have depended on a *new* version of Mir, I guess.
<robert_ancell> RAOF, yeah, that was it
<thomi> robert_ancell: hey, sorry - that was a long call
<thomi> robert_ancell: the problem resolved itself?
<RAOF> Ok. Time to actually generate a symbols file for libmirclient, so this doesn't happen again.
<robert_ancell> thomi, I rebuilt u-s-c in the -testing PPA so it matched, though the staging PPA still seems mismatched
<thomi> I wonder if autolanding failed
 * thomi checks
<robert_ancell> thomi, does it wait until the mir build completes, or is published? Since it's one version behind perhaps it doesn't wait long enough to rebuild
<thomi> robert_ancell: no, the autolanding stuff uses it's own internal archive
<thomi> so anything that's been autolanded is avaialble
<robert_ancell> to clarify - u-s-c 0.0.1bzr33saucy0.144 is built against mir 0.0.6bzr831saucy0 , but 0.0.6bzr832saucy0  is the latest (7 hours old)
<thomi> robert_ancell: I'll have to ask about that
<racarr> kdub_: That was in fact the first hang :) I may have a seperate input hang, or perhaps yours is related and the client bit just appears to solve it
<racarr> in the key hndling tests, there is  race between the InputRegistrar in the test fixture saying "Surface ready for input"
<kdub_> right
<racarr> which happens right after the ms::Surce being creted
<racarr> and the
<racarr> surface actually receiving
<racarr> keybord focus
<racarr> which happens after the msh::Surface has been created later in the shell
<racarr> so key events are being dropped on
<racarr> the server side
<racarr> Ill change the test fixture to ...do something better
<robert_ancell> RAOF, thomi, are you able to test the system-compositor-testing PPA? I need some confirmation before I can announce it fixed
<RAOF> Looks like it *should* work from my end, but I get terrible bandwidth from the archive. thomi, can you pull from launchpad at > 30kbsec?
 * RAOF is testing, but it'll take a while to verify.
<robert_ancell> RAOF, thanks
<kdub_> racarr, i have a branch that pulls the pipe based cross ipc synchronization out of some of the integration tests that fixes that test fixture input race
<kdub_> just not sure if we want to make that the way all our tests with fork()'s in them have sync yet :)
<thomi> RAOF: I'm on mobile broadband until this afternoon :(
<RAOF> We win the bandwidth award!
 * RAOF has noticed people doing what appears to be feeding fibre into the pits in the next street. C'mon NBN. Rollout here!
<racarr> kdub_: I think I have fixed it in the server side
<racarr> the notification "its ok to inject input" is now done right before returning the SurfaceId from the_frontend_shell
<racarr> and it's all fine
<jono_> olli, hey
<jono_> is the PPA fixed now?
<jono_> ahhh RAOF, are you on the PPA issue?
<RAOF> jono_: Yes.
<jono_> RAOF cool, when it is resolved can you ping me, I will be afk for a bit and then I can move forward with a post I was going to make
<jono_> thnaks
<RAOF> Well, robert_ancell queued the rebuilds. I'm checking that it works now, hampered by my 30kb/sec bandwidth to Launchpad.
<jono_> thanks
<jono_> 30kb/sec
<jono_> wow
<jono_> raging
<robert_ancell> jono_, if you're using the PPA, please update and check
<robert_ancell> jono_, I think it works, I just need confirmation
<jono_> robert_ancell, I removed the PPA when I couldn't boot earlier ;-)
<robert_ancell> jono_, :(
<jono_> it turned out that X was removed
<robert_ancell> jono_, you did a dist-upgrade without checking?
<jono_> when I installed xorg everything worked again
<jono_> robert_ancell, indeed, I got lazy with everything working so reliably
<jono_> I won't make that mistake again :-)
<robert_ancell> jono_, yeah, I've been burned by cases like that before
<jono_> ok gotta go and work out
<jono_> trying to get my fat ass in shape :-)
<robert_ancell> We really need a "are you really really sure" message if ubuntu-desktop is marked for uninstallation - that would stop these cases
<RAOF> Hm. Has my scheduler died again?
<bschaefer> yay the mir ppa i working again
<bschaefer> s/i/is
<RAOF> bschaefer: The system-compositor-testing PPA?
<bschaefer> RAOF, yup
<RAOF> jono_: ^^ Looks like it works again :)
 * RAOF 's laptop is still in the process of verifying that.
#ubuntu-mir 2013-07-10
<robert_ancell> bschaefer, you can confirm it works for you?
<robert_ancell> i.e. get into XMir?
<bschaefer> robert_ancell, yeah
<bschaefer> robert_ancell, i had the cursor, and the process was up and running
<robert_ancell> bschaefer, awesome, thanks
<bschaefer> robert_ancell, np :)
<jono_> thanks RAOF
<RAOF> ARGH!
<thomi> robert_ancell: I believe marking ubuntu-desktop as required would do what you want, but would likely be viewed rather poorly by some people :)
<RAOF> I was sure I fixed the signals-plus-threads-equal-pain problem before.
<mterry> Pressing alt+left reliably makes my desktop mir session freeze (alt+f1 fixes though)
<mterry> Not sure if that's bug 1102756 or something else
<ubot5> bug 1102756 in Mir "System compositor input events passed to console (particularly troublesome for Alt+Fn and Alt+Left/Right)" [High,Triaged] https://launchpad.net/bugs/1102756
<mterry> racarr, heyo!  So I looked at the surface builder override example you provided, thanks.  It keys off params.name, but I'm not certain where that gets set originally.  Is that something that any client can set, or is that controlled by other parts of the system compositor?
<racarr> mterry: It gets set by the client, though once the shell (and the system compositor too) implement the session authorizer
<racarr> it can be trusted.
<racarr> the key off param.name is a bit of a hack. we should have a better way to
<racarr> sort o tag it...
<mterry> racarr, sorry, I'm a bit confused.  You say it can be set by the client, and it can be trusted, but there's an unwritten authorizer in between that lets us actually trust it?
<mterry> racarr, so both sessions and surfaces have names, it seems
 * mterry is still getting used to how Mir works
<RAOF> mterry: Yup, that's bug 1102756 - what's happening is the kernel is interpreting <alt>+<left> as a VT switch.
<ubot5> bug 1102756 in Mir "System compositor input events passed to console (particularly troublesome for Alt+Fn and Alt+Left/Right)" [High,Triaged] https://launchpad.net/bugs/1102756
<racarr> mterry: Well right now it is set by the client but hte basic path is
<racarr> the shell starts the clients (say through upstart and gets hey I just launched 'application-id' (i.e. session->name()) as PID pid
<racarr> then when the client tries to connect the shell will be told hey
<racarr> thi PID is connecting is that ok
<racarr> perhaps surface name should be title
<racarr> and session name should be application-id
<RAOF> racarr: Did we ever work out how that is meant to interact with fork()
<RAOF> ?
<duflu> fork is such a great idea, and a bad one. Bad because there's often a little slice of time between fork() and exec() and you can have state/global objects as well as threads go nuts in that time.
<duflu> -state +static
<racarr> RAOF: Perhaps it's not
<racarr> Is forking and opening new mir connections something clients are allowed to do?
<racarr> I'm not sure
<racarr> not on the phone or the system compositor
<racarr> perhaps for the desktop we will need
<racarr> a more complex mechanism
<racarr> i.e. DBus API in the shell
<RAOF> racarr: An âapplicationâ being a shell script that sets some environment and then calls the real binary is a very common idiom; not all of those are going to exec.
 * RAOF heads to lunch.
<duflu> racarr: I can't think of a sensible use case for us to worry about forking clients yet...
<duflu> That's odd. I don't remember doing updates but EGL Mir clients are broken again
 * duflu updates again
<duflu> RAOF: Ping (hopefully I won't drop out like yesterday)
<RAOF> :)
<RAOF> duflu: Pong.
<duflu> RAOF: drmModePageFlip ... appears to require the DRM FB ID to remain valid and the buffer unchanged for the duration of the following frame. Is this confirmed in docs anywhere?
<RAOF> Hah!
<RAOF> Docs?
<RAOF> Hah!
<duflu> Confirmed in folklore even?
<duflu> RAOF: Because if I don't keep the DRM FB alive and untouched for the duration of the frame I get tearing. So I assume I have to hold it.
<duflu> But holding it creates a world of deadlock pain I'm working through
<RAOF> duflu: My expectation would be that the fb id you send to drmModePageFlip will need to be unchanged between the call to drmMode and the page flip event for the *next* fb you page flip.
<duflu> RAOF: Yes, that agrees with my findings
<RAOF> You *should* be able to do any form of bookkeeping you want on it, though; unreffing it should work.
<duflu> It also confirms the buffer really is scanout. And any premature unsynced changes will give me tearing
<RAOF> Oh, yes.
<RAOF> That's rather the point, isn't it?
<duflu> Yup
<kgunn> bschaefer: just to double check...did you try the ppa from a "purged state" ?
<bschaefer> kgunn, hmm no, I just had a broken system, ie. my intel driver was failing to load due, and I was running unity in software mode
<bschaefer> did an upgrade and then the intel driver was being loaded correctly, and xmir and x11 started working correctly
<bschaefer> kgunn, would you like me to try purge my ppa and test it out?
<bschaefer> purging*
<kgunn> so just because i'm crazy i purged first....took system back to "default"....and now, i'm hitting "broken" packages....lightdm not updated, due to u-s-c, due to libmirserver
<kgunn> bschaefer: hey thanks...good to get a second data point
<bschaefer> kgunn, yup, hmm it could be that libmirserver was updated in the ppa recently
 * bschaefer goes to check
<bschaefer> kgunn, do you also have the mir staging ppa?
<kgunn> bschaefer: nope
<kgunn> ...but double checking for stupid mistakes
<bschaefer> hmm strange, have you also pined the unity system compositors ppa?
 * bschaefer was unaware of this until yesterday
<bschaefer> from : http://www.olli-ries.com/running-mir/
<kgunn> bschaefer: oh yes...altho, when i purged...i unpinned & removed the deb ref to -testing
<kgunn> rebooted into x no prob etc
<kgunn> but yes...i repinned just now
<bschaefer> kgunn, so you have a working lightdm still, and mir isn't working?
<bschaefer> or is it uninstalled?
<bschaefer> yeah, re-pinning should help downgrade your packages :)
<kgunn> ligthdm yep & yep.....installed
<kgunn> checking all my versions now against -testing
<bschaefer> cool, cause usually when I ran into broken packages it would uninstall my lightdm :(
<bschaefer> so xmir *should* be working hmm
<RAOF> As far as I can tell u-s-c in -testing *should* be installable from testing.
<kgunn> well...it seems that all the versions look ok, except lightdm is one behind
<bschaefer> what is your apt-cache policy on it?
<bschaefer> I've got:   Installed: 1.7.5bzr1634saucy0
<bschaefer> from: 1002 http://ppa.launchpad.net/mir-team/system-compositor-testing/ubuntu/ saucy/main i386 Packages
<kgunn> bschaefer: what the command there "sudo apt-cache <what> -p lightdm" ?
<bschaefer> kgunn, "apt-cache policy lightdm" should do it
<bschaefer> no need for sudo :)
<kgunn> bschaefer: ta
<bschaefer> np!
<kgunn> right...Installed: 1.7.4-0ubuntu1
<bschaefer> strange! hmm have you missed an update?
<kgunn> candidate is 1.7.5....however if i attempt to install...it complains
<kgunn> about unmet deps on u-s-c
<kgunn> which in turn complains about libmirserver0
<bschaefer> mind pasting the error :)
<RAOF> What version of mirserver0 is it complaining of?
<RAOF> Because the version in -testing depends on = 0.0.6bzr832saucy0, which is the version in the PPA.
<kgunn> Depends: libmirserver0 (= 0.0.6bzr831saucy0) but 0.0.6bzr832saucy0 is to be installed
<RAOF> I suspect you may need to apt-get update?
<RAOF> The deb that I downloaded from the PPA just now depends on 832
<kgunn> i have a few times
<kgunn> hmmm...might repurge and try again
<RAOF> apt-cache policy ubuntu-system-compositor?
<kgunn> none installed...but again, that's because of the whinging about libmirserver0
<bschaefer> kgunn, unity-system-compositor
<bschaefer> hmm strange still
<kgunn> bschaefer: yeah ;) i corrected it...i knew
<bschaefer> kgunn, what is the versions Candidate?
<bschaefer> for u-s-c?
<bschaefer>   Candidate: 0.0.1bzr33saucy0.144 should be yours?
<kgunn> one moment...got impatient, repurged, trying again....
<bschaefer> cause your libmirserver0 is the correct version, but for some reason u-s-c wants a lower version?
<bschaefer> :), good luck!
<kgunn> ...i think it worked...rebooting
<kgunn> bschaefer: RAOF ...hooray! never so happy to see my annoying friend "extra mouse cursor"
<bschaefer> kgunn, awesome :)
<RAOF> :)
<kgunn> not sure what happened...i'm sure it was due to my futzing around earlier today
<duflu> kgunn: It's a /watermark/ to tell you Mir is working ;)
<kgunn> duflu: yes....serious investment in that "feature"
<tvoss_> good morning :)
<kgunn> kind reminds me of bob the paperclip
<duflu> Intentional or not, it's very useful
<kgunn> tvoss_: ditto
<duflu> tvoss_, Hi
<tvoss_> guys, I need some help as lightdm from the ppa won't install its configuration file
<robert_ancell> tvoss_, which config file?
<tvoss_> robert_ancell, I don't see the 10-unity-system-compositor in /etc/lightdm/lightdm.conf.d
<robert_ancell> tvoss_, did you delete it previously?
<tvoss_> robert_ancell, might well be, yeah :)
<robert_ancell> tvoss_, it's provided by unity-system-compositor and debian remembers if you delete stuff - see http://serverfault.com/questions/82801/linux-how-to-restore-config-file-using-apt-get-aptitude
<robert_ancell> "debian remembers if you delete stuff in /etc"
<robert_ancell> tvoss_, or failing that just make it yourself
<RAOF> robert_ancell: Or dpkg --purge then reinstall.
<kgunn> didrocks: morning
<didrocks> hey kgunn! it's quite late for you, isn't it?
<kgunn> didrocks:  or early...yes.
<didrocks> :)
<duflu> Rule of thumb: If you're talking to Australia then you probably should not be awake :)
<duflu> Unless it's only early evening...
<duflu> Or you're in Europe
<duflu> Or you're in Asia
<robert_ancell> RAOF, https://bugs.launchpad.net/mir/+bug/1195811 - this is because XMir doesn't limit frame rate from X clients right?
<ubot5> Ubuntu bug 1195811 in Mir "Abnormally high FPS (no vsync) on natively mir testing demo-clients. Ubuntu 13.10" [Undecided,New]
<duflu> robert_ancell: It's a driver-specific bug (nouveau). I have not got around to doing manual testing on nouveau yet
<duflu> nouveau has a long history of not vsync'ing
<robert_ancell> duflu, but I believe no X client in XMir vsyncs right?
<RAOF> robert_ancell: Yeah, what duflu said. You're correct that XMir doesn't do vsync yet, but that bug appears to be about native Mir clients, which *should* vsync
<duflu> robert_ancell: Yes compiz enforces vsync for everything on the screen, except when it's full screen and bypassed
<duflu> Umm, that's a misleading statement I made. The point is that our custom GL for nouveau is failing to vsync in clients even when it should
<duflu> I have two nvidia cards. I guess I should install one to keep the room warm during winter
<RAOF> I should get my netbook bootable again so I can use it's BLAZING FAST geforce 9300
<duflu> You mean blazing (hot) ?
 * duflu wonders how Mir would go on the old N270 netbook
<RAOF> Hm. Trunk doesn't build for me?
<kgunn> didrocks: did i understand right that we were going to leave our version of gmock in mir tree ? just want to make sure this is the plan (to get into universe)
<didrocks> kgunn: hum, no, I mean we can leave it unresolved for daily release into a ppa
<didrocks> not for universe
<kgunn> didrocks: so what's the mandate ?  as i understand it, we actually use features in the latest gmock...not available via the version used in ubuntu today
<didrocks> kgunn: knowing that I spent a day making most of the stuff, the only remaining one for making the gmock transition is nux to be adapted
<didrocks> kgunn: well, I spent an extensible amount of time updating to latest gmock
<didrocks> and updating all components (mir included) to use that distro version
<didrocks> the only remaining piece is nux
<robert_ancell> kgunn, RAOF, duflu, racarr, kdub_, meeting
<kgunn> didrocks: ah....thanks...its clear now
<didrocks> kgunn: bregma was asked to do nux 2 days ago, not sure what's the status (he told me he would do it yesterday)
<robert_ancell> thomi, too if your internet got solved :)
<kgunn> didrocks: thanks...tvoss had his name there...but i'll pester bregma tomorrow
<didrocks> kgunn: the most important one is the armhf tests failing (some needs to be separated in autopilot tests I guess)
<kgunn> didrocks: again, i understand bregma is going to disable valgrind tests for arm
<didrocks> kgunn: but they should be run as part of autopilot tests, right?
<didrocks> so that we run them in the phone image
<didrocks> with the actual hardware, and so on
<kgunn> didrocks: right, i believe it was qemu failing...but mobile hw ok
<didrocks> kgunn: can we ensure they are not just disabled but converted to AP tests? loosing possibly valuable tests isn't good for quality (nobody is running tests manually on the long term ;))
<kgunn> didrocks: thanks for pointing that out...i'll followup with bregma
<didrocks> yw!
<RAOF> Huh. Mir lttng fails to build with -std=c99
<dholbach> good morning
<tvoss> RAOF, thanks for your answer :) I was thinking that we actually have less context switches for the shell when linking against libmirserver, right?
<RAOF> tvoss: The shell has no context switches at all.
<RAOF> As long as it's in-process.
<tvoss> RAOF, yup, I will add that to the answer :)
<RAOF> If it's not in-process, then, again, it's one context-switch per frame.
<duflu> I'm pretty sure libmirserver has ~3 basic threads +N (number of clients up to the thread limit ~10), hence context switches a fair bit
<duflu> So 4 threads with a single client
<duflu> It would be really nice if the number of wakeups per second matched the frame rate, but that's not an immediate goal
<tvoss> duflu, sure, but still: let's wait for hard numbers until we start optimizing that part
<duflu> tvoss: Yeah I have no evidence that waking up hundreds of times per second like Mir does, is affecting frame rates yet
<duflu> Only power consumption that's not ideal for sure
<RAOF> Several years ago, several-year-old hardware managed 20,000 context switches/sec. We're not going to be dropping framerate :
<tvoss> duflu, that reminds me: I need to log a bug about some build time flags that we introduced to satisfy the buildds
<duflu> Yeah, it's just the modern day race to zero watts :)
<RAOF> We do want to stop waking up to save power, though.
<tvoss_> didrocks, ping
<didrocks> tvoss_: pong
<tvoss_> didrocks, good morning :) how goes?
<didrocks> tvoss_: I'm fine, thanks! Ensuring that the temperature remains hot with building nux :p
<didrocks> and you?
<tvoss_> :D
<tvoss_> didrocks, looking through the list of open bugs
<didrocks> tvoss_: FYI, nux package doesn't build, there seems to be a PREFIX override
<tvoss_> didrocks, *sigh*
<didrocks> tvoss_: seems like people don't try to bzr bd :/
<didrocks> (it's easy though :/)
<tvoss_> didrocks, looking into disabling tests on powerpc now
<didrocks> tvoss_: no need anymore
<didrocks> tvoss_: I've disabled powerpc builds
<tvoss_> didrocks, oh, do we have a branch?
<tvoss_> didrocks, okay
<didrocks> as per the discussion
<tvoss_> didrocks, okay, mind closing the bug?
<didrocks> tvoss_: doing so :)
<tvoss_> didrocks, thx
<tvoss_> RAOF, mind giving me a quick status on the system-compositor-testing ppa before you eod?
<pete-woods> hey guys! So you publish your docs to http://unity.ubuntu.com/mir/
<pete-woods> how can I do the same with my library?
<tvoss_> pete-woods, talk to mhall119
<pete-woods> tvoss_, cool, thanks!
<tvoss_> pete-woods, yw
<RAOF> tvoss_: As far as I'm aware, system-compositor-testing is ready to roll.
<tvoss_> RAOF, ack, so nothing to be copied over right now?
<tvoss_> RAOF, rolling fine on my machine :)
<RAOF> Nothing particularly to be copied over, no.
<tvoss_> RAOF, ack, thanks
<RAOF> Xserver 1.14 is in there, with the xmir changes to not hate hybrid.
 * tvoss_ wonders if putting that information in the channel title would make sense
<alf__> hikiko: alan_g: Have time for a nested mir sync/chat?
<pete-woods> tvoss_: are you guys in any kind of dialogue with vmware, parallels, etc to get them to think about Mir drivers for their virtualisation tech?
<alan_g> alf__: hikiko 8 mins?
<tvoss_> pete-woods, not yet
<hikiko> hey
<hikiko> sorry
<pete-woods> okay, thanks for the info
<hikiko> alan_g, alf__ sure can you wait for 5 mins?
<hikiko> I have to go downstairs to collect something brb in 5mins alan_g alf__
<alf__> alan_g: hikiko: sure, I will create the hangout, join when ready
<alf__> alan_g: hikiko: https://plus.google.com/hangouts/_/1c0bb852740e0eb0560f57be1e1c793df9897a89?hl=en
<hikiko> alan_g, alf__ back
<tvoss_> RAOF, ping
<RAOF> tvoss_: Pong.
<RAOF> pete-woods: I've been in contact with a VMWare developer; all that's needed there is dma-buf support for their mesa driver. It's basiacally the free stack.
<pete-woods> ROAF, that sounds pretty cool. It's a shame things like the Parallels stuff is more restrictively licensed. Although if 13.10 does have Mir on by default (or maybe even an option) I guess they will have lots of users nagging them to support it!
<tvoss_> alan_g, ping
<alan_g> tvoss_: ?
<tvoss> RAOF, okay, not an issue with xfce
<duflu> alf__: Can you point me to where in the server the client's choice of swapinterval is implemented?
<alf__> duflu: src/server/compositor/switching_bundle.cpp
<duflu> alf__, thanks
<duflu> Oh, I forgot the terminology changes to "frame dropping"
<duflu> Of course
<alf__> duflu: the path on the server side is mf::SessionMediator::configure_surface() -> msh::Surface::configure() -> msh::Surface::allow_framedropping() and propagates down to the buffer_bundle
<duflu> alf__: Yep thanks. I'm trying to figure out what I've done to make synchronous clients hang. Something is deadlocked
<duflu> And I think it might be too late in the day to continue
<duflu> alf__: I did notice this, but it doesn't seem related to my problem now... https://bugs.launchpad.net/mir/+bug/1199717
<ubot5> Ubuntu bug 1199717 in Mir "BufferSwapperMulti::in_use_by_client counter drops below zero" [Undecided,New]
<alf__> duflu: thanks, I will take a look
<dandrader> Is mir going to get AppArmor support?
<tvoss> dandrader, sure, you mean in terms of having a SecurityManager server-side?
<dandrader> tvoss, in term of a call mir_surface_set_type(mySurface, mir_surface_type_inputmethod) failing (i.e., server reports back failure) if the client is not allowed to have an input method surface
<tvoss> dandrader, yes, that's not there, yet, though
<dandrader> tvoss, sure, but the plan is to have it implemented with AppArmor, right?
<dandrader> (sounds like I'm repeating the same question with different words but I do like to have it made clear :) )
<tvoss_> dandrader, might have lost some of your messages
<dandrader> <dandrader> tvoss, sure, but the plan is to have it implemented with AppArmor, right?
<dandrader> <dandrader> (sounds like I'm repeating the same question with different words but I do like to have it made clear :) )
<dandrader> tvoss_, ^
<tvoss_> dandrader, right our technology of choice is apparmor
<dandrader> ok, thanks (because in the e-mail discussion I've suggested discretionary access control)
<tvoss_> dandrader, I think we need mandatory access control, too
<dandrader> yeah, that's more powerful
<didrocks> bregma: give me a sign once you will win over the PREFIX override for nux :)
<bregma> didrocks, I fixed that last night, MP should be OK now
<didrocks> bregma: ah, you just didn't push it in the previous MP then?
<didrocks> bregma: let me rebuild the package then
<didrocks> bregma: thanks for taking the opportunity for -X.la btw ;)
<bregma> well, what actually happened was I kicked off a local build to verify it and went to bed, then pushed the branch up to LP when I woke up, but MP should be good now
 * didrocks builds, with ccache, should be quick now
<didrocks> bregma: beautifully build!
<didrocks> tvoss_: kgunn: ok, so pushing new google-mock snapshot to distro
<didrocks> once published, switching all MP to approved
<didrocks> thanks bregma for nux! :)
<kgunn> bregma: didrocks \o/
<didrocks> kgunn: already awake? really really short night :)
<kgunn> didrocks: zzzzzz, huh?
<kgunn> ;)
<didrocks> heh
 * bregma slurps yet another mug of coffee
<didrocks> bregma: another? it's not your first? :-)
<bregma> no chat or email until at least the second mug or I always regret it
<didrocks> ahah
<kgunn> bregma: .....a wise man
<didrocks> tvoss_: can I get 2 quick acks for https://code.launchpad.net/~didrocks/libusermetrics/build-new-gmock/+merge/173945 and https://code.launchpad.net/~didrocks/mir/remove-local-google-mock/+merge/173946? (I didn't propose them for merging apparently previously)
<mterry> greyback, where is the unity8 branch that uses mir?
<mterry> greyback, oh, nm: lp:~unity-team/unity/unity8-integrate-mir/
<greyback> mterry: yep that's it. Any luck with mir?
<mterry> greyback, I haven't tried reflashing my nexus4 in a couple days.  But now I'm investigating how surfaces will get assigned names
<greyback> mterry: ok. Look up ua_ui_window_properties_set_titlen
<greyback> mterry: that's used in the qtubuntu plugin, which sets the surface name that shell will get
<mterry> greyback, ah, OK
<mterry> thanks
<greyback> is in platform-api. yw
<mterry> racarr, so in that surfacebuilder example you gave me yesterday, I assumed that "Window 1" was just some testing name.  But it seems that qtubuntu actually does use that title for all its windows.
<mterry> racarr, is there an easy way to change that name on a per-window basis, so that I can actually treat the greeter window differently?
<mterry> greyback, about mir+unity on nexus4, do you know if there's a bug about the black screen issue?
<greyback> mterry: no I don't. You'd need to talk with ricmm about it, since I guess you're using his images
<greyback> mterry: quick question: what version of "ubuntu-touch-session" is on the image you've installed?
<mterry> greyback, hm, ok
<mterry> greyback, 0.57 (though 0.56+mir2 is available and unused...  seems bad)
<greyback> mterry: switch to the mir package and reboot
<greyback> mterry: I think that's hte culprit
<mterry> greyback, yup, that fixed it for me
<greyback> I didn't realise it until last last night when I was slowly building a working stack of Mir+Platform-api+qtubuntu, that when I updated that package, the crash happend. That package seems to configure things inside the android chroot, maybe also the graphics
<greyback> excellent!
<greyback> ricmm_: ^^
<ricmm_> greyback: mterry yup, setting up a recipe for that now
<kgunn> alf__: ping
<alf__> kgunn: pong
<racarr> Morning
<alan_g> Afternoon
<tvoss_> alf__, ping
<alf__> tvoss_: pong
<didrocks> alf__: your patches for google-mock was for clang build?
<alf__> didrocks: no, for g++ 4.7 (but it could be that clang needs them too)
<alf__> didrocks: issues?
<didrocks> alf__: yeah, with the google-mock version I pushed today in distro (so the snapshot without your patch), I see:
<didrocks> alf__: http://paste.ubuntu.com/5861927/
<didrocks> is that what your patch would prevent?
<didrocks> alf__: this issue doesn't seem to appear with gcc
<didrocks> (at least, it's at 72%, passed that point)
<alf__> didrocks: that shouldn't be relevant to my patch
<didrocks> alf__: let's wait for the gcc build to finish, but then, I think CI will reject it if it doesn't build with clang, right?
<kdub_> right
<didrocks> kdub_: I'm afraid I'll need help on that one then :)
<kdub_> hopefully clang just goes through :)
<didrocks> kdub_: I'm pushing the fix first to add the missing build-deps to setup-partial-armhf-chroot.sh (this script should really take build-deps from the packaging)
<kdub_> didrocks, oh, thanks! that script was just kinda 'kevin's first way to get mir armhf running' that evolved into 'everyone use just this thing'
<kdub_> probably needed a revamp
<didrocks> kdub_: I'll give it a shot for grabbing the build-deps from the packaging. In exchange, let's hope someone can help on clang :p
<kdub_> i can help get it going, but if its a large compilation failure requiring a fair amount of gtest fixes, don't know if i have the time to sort through it
<didrocks> kdub_: it's working with the inline version, right? so it should be a patch you pushed to it that I need to put in the distro gmock, right?
<kdub_> didrocks, might be, but I know there were other patches too, potentially
 * didrocks loves it:
<didrocks> dpkg-deb: building package `mir-build-deps' in `../mir-build-deps_1.0_amd64.deb'.
<didrocks> Attention, the package has been created in the current directory,
<didrocks> not in ".." as indicated by the message above!
<didrocks> kdub_: hum, in your script, you even don't install the packages, just extract them in random dir?
<didrocks>   add_subdirectory given source "/usr/src/gmock" which is not an existing
<didrocks> is what I get
<kdub_> didrocks, yeah, just enough to provide headers and linking
<didrocks> kdub_: do you have a generic way of dealing with this hacked path then?
<didrocks> in cmake?
<kdub_> we use cmake's cross compilation system
<didrocks> kdub_: hum, I will try something to point to the google-mock usr/ path
<didrocks> but doesn't sounds sane TBH ;)
<racarr> greyback_: Anything I can do to be helpful on application module?
<racarr> kind of inbetween tasks
<racarr> so have to pick something new up
<greyback_> racarr: Hey, lp:~gerboland/+junk/qml-demo-shell/ - please open an app (using buttons at the bottom) and then try to interact with the app
<racarr> greyback_: Is it a trap? :(
<racarr> the way you phrase it makes it sound like a trap
<racarr> buillding
<greyback_> racarr: gah, foiled again!
<racarr> segfault, probably
<racarr> abi mismatch
<racarr> on my machine
<racarr> i.e. can't even start it
<racarr> I think I need a mesa upgrade
<racarr> will be a ew minutes
<racarr> greyback_: I don't see any calls to set_input_region
<racarr> so how would you be able to interact with an app?
<greyback_> racarr: aha, that's what I was missing
<greyback_> yes, stupid me
<greyback_> how did I completely forget that??
<racarr> forgetting is easy!
<racarr> XD
<racarr> how will that bit work?
<racarr> I've been wondering about the least troublesome way to wire that up
<greyback_> Yeah me too. I'd love to define InputRegions that shell should accept, and all other regions the input passes through
<greyback_> I've idea how to do it, is next on the list
<racarr> whee
<greyback_> racarr: if you want to look at my app manager code, you're welcome to it. ATM I've #ifdef'd in Qt manually starting the processes, not upstart. I'm also not using the session authorizer still
<greyback_> so please put those together and check everything works
<greyback_> but right now, I'm away :) Talk later
<racarr> greyback_: Excellent. Thanks
<racarr> see you
<kgunn> kdub_: did you read  Jim Haddops mail ? i'm wondering if he's highlighting a "new" requirement....e.g. if the intent is to get rid of surface flinger, then something would need to take care of
<kgunn> binding the output video buffers as textures to the surfaces (for egl streaming)
<kdub_> ah, haven't read yet
<kgunn> so its most likely a backend to gstreamer (which ends up being a native mir client....like qmir)
<kgunn> ah...i'll give you a chance
<kgunn> btw....per session mode setting still more important than that discussion ;)
<jo-erlend> there is a discussion going on at the Elementary OS mailing list following a chat with jono.. They seem to be under the impression that Canonical does not intend to create a GTK+ backend for Mir and unless the community does it, eventually you won't be able to run GTK apps in Ubuntu. Surely, this must be the result of some confusion?
<jo-erlend> I know Ubuntu SDK does not support GTK+ and that's kinda reasonable from the arguments I've heard. But not making sure the display server supports one of the big toolkits around, seems almost unthinkable.
<jo-erlend> These people have lots of listeners, so if it is indeed a misunderstanding, I hope it gets rectified asap.
<jono> jo-erlend, I mentioned that I didn't know if we were creating a GTK backend, and that I would get back to them
<jo-erlend> jono, they seem to have interpreted that as "extremely unlikely".
<jono> jo-erlend, I will weigh in, I am on the list
<jo-erlend> great. :)
<jo-erlend> jono, but wasn't this talked about in the Mir interview? That things would be written, but that you couldn't be sure it'd be accepted upstream? Perhaps I misunderstood.
<racarr> We've always said that we were creating a GTK  backend
<racarr> but it's behind anything for the phone or the system compositor of course :)
<jo-erlend> racarr, good to hear. It seemed very strange to me that anyone writing a display server would neglect GTK support.
<racarr> robert_ancell: So the thing is, I think we need to move to a model where the Shell sets the 'Application-id' or session name
<racarr> rather than relying on the client to provide it, and verifying
<racarr> because if there are two clients starting up at the same time (say one trying to impersonate another), just PID isnt enough to verify
<racarr> so instead of, say like bool SessionAuthorizer::is_allowed_to_connect(pid_t)
<racarr> it's like std::string SessionIdentifier::identify_session(pid_t) throws-exception
<racarr> or some such
<racarr> and I just wanted to know how this affects the system compositor
<racarr> i.e. is this easy to accomodate
<robert_ancell> racarr, currently lightdm picks the IDs, then tells XMir to use a given ID, then lightdm tells u-s-c to switch sessions based on id
<robert_ancell> racarr, potentially we could switch the id with a PID, but there's no current convention that the PID the display manager launches is the process that connect back (e.g. there are often shell scripts in between)
<racarr> ok, so instead of lightdm telling xmir, it just needs to tell u-s-c
<racarr> PID blabla is XMir
<robert_ancell> but only if there's no forking
<racarr> mm
<robert_ancell> It feels like there must be something nicer we can use than just the pid of the process lightdm forked, something that will propogate down
<robert_ancell> Perhaps some sort of cgroup thing
<racarr> hmm
<robert_ancell> racarr, note, these are logind sessions that are connecting to u-s-c, so they should be identifiable. That is a different case to applications within a session though where they are all in the same logind session
<racarr> mm
<robert_ancell> mmm
<robert_ancell> bacon
<racarr> its a different kind of case for u-s-c, the thing is its difficult
<racarr> to let unity act as
<robert_ancell> racarr, yeah. I'm treating the ID as a kind of secret at the moment, which is reasonably* secure
<racarr> this "SessionIdentifier" and pick all the application-id's
<racarr> without removing
<racarr> client provided session names completely
<robert_ancell> racarr, what does an application-id mean then>
<robert_ancell> ?
<robert_ancell> is this the .desktop association?
<racarr> Yeah
<robert_ancell> racarr, ok, if the client session names remain then that should be sufficient for u-s-c I think. We can just ignore the application-ids since they don't mean anything at the system compositor layer
<racarr> oh well
<racarr> I was thinking session->name basically becomes session->application_id
<robert_ancell> and the client session names might become unnecessary if we can use logind
<racarr> I dunno, it's tricky
<robert_ancell> racarr, it can have a different meaning for unity-shell than in u-s-c right?
<racarr> because session->name doesn't have any meaning for unity8 really
<racarr> but application_id doesn't really have
<racarr> any meaning for system compositor
<racarr> yeah
<racarr> at this point I am just thinking about names :)
<robert_ancell> racarr, and unity-shell implements the application id assigner and u-s-c leaves it stubbed
<racarr> ...the name or the name member
<robert_ancell> or vice versa
<racarr> Mm ok.
<racarr> Ill take a crack at it in the next week or so, the current solution is sufficient for now (just the shell can only let one app be int he launching state at a time)
<racarr> thanks :)
<racarr> for...exactly now, I think I am going to the bakery.
<kgunn_> bregma: wrt disabling the arm valgrind tests on qemu, are you going to also ensure they'll run via autopilot on real mobile hw ??
<kgunn_> this was a didrocks query...and i wanted to make sure if you _weren't_ doing it...that we got you some help to do so
<kgunn_> robert_ancell: ^ was this the integrated AP tests you were speaking about in the other testing thread....or were you thinking of other tests
<robert_ancell> kgunn_, not sure what you're referring to
<kgunn_> robert_ancell: the "what's keeping us from saucy" thread....with olli
<robert_ancell> kgunn_, As I understand it these are unit-tests that are failing on build. So if there're disabled it wont affect autopilot
<thomi> robert_ancell: could I get you to take a look at this MP please? https://code.launchpad.net/~thomir/mir/remove-close-fd-workaround/+merge/174071
<kgunn_> robert_ancell: right...but didrocks was saying we should move those tests to ap for arm
<kgunn_> ...i'll let you look at that mp
<kgunn_> we can catch up later
<thomi> robert_ancell: also, I'm still able to reproduce this bug: https://bugs.launchpad.net/mir/+bug/1195089 - I wonder if we could bump the priority of that bug?
<ubot5> Ubuntu bug 1195089 in Mir "mir_stress suite causes mir_demo_server to crash" [Critical,Triaged]
<robert_ancell> thomi, higher than critical?
<thomi> ....
<thomi> yeah :)
<thomi> ok, so maybe bump the status
<robert_ancell> thomi, that bug is driving me insane :)
<robert_ancell> oh, I thought it should be in progress
<thomi> Confirmed -> In Progress would be nice :)
 * robert_ancell fixes
<thomi> cool - I hadn't realised you were looking at it
<robert_ancell> done and done
<thomi> robert_ancell: anything I can do to help you fix it?
<robert_ancell> thomi, find the problem? :)
<thomi> heh
<thomi> I'll fire up valgrind and see if I can get anything sensible from it
<robert_ancell> I can reproduce it reliably, but really lost trying to find out where the problem is occurring
<robert_ancell> the stack traces seem to change over time and they're not pinpointing the problem
<thomi> hmmmm
<thomi> is the stack constant to a certain point? I wonder if we're corrupting the stack somehow
<robert_ancell> thomi, it definitely seems to be a threading issue when releasing the surface
<racarr> robert_ancell: Oh I found and fixed one of those I think
<kdub> racarr was talking about something like htat
<kdub> right :)
<racarr> in client-focus-notifications let me find it
<robert_ancell> racarr, yeah, I've been seeing a number of fixes in that area, but none are fixing the problem for me :(
<robert_ancell> racarr, is there a new fix on a branch somewhere?
<racarr> robert_ancell: https://code.launchpad.net/~robertcarr/mir/client-focus-notifications/+merge/166440 at 253
<racarr> and
<racarr> 264
<racarr> well
<robert_ancell> racarr, ta, I'll try that
<racarr> hmm I don't know if it can actually crash
<racarr> it was a deadlock in my case
<robert_ancell> RAOF, can you check https://code.launchpad.net/~robert-ancell/mir/mesa-xorg-docs/+merge/174073 for accuracy
<robert_ancell> kgunn_, you might also be interested
<robert_ancell> kgunn_, aha, I knew I'd missed something :)
<RAOF> robert_ancell: Looks good, let me double check.
<robert_ancell> kgunn_, can you re-review
<RAOF> Heh, cool. Glyph cache corruption. It's been a while!
<racarr> RAOF: http://en.wikipedia.org/wiki/Peak_experience
<racarr> :p
<racarr> I love glyph cache corruption
<RAOF> robert_ancell: You've misspelt â--enable-xmirâ in that doc; you've got â--with-xmirâ, which doesn't work.
<robert_ancell> RAOF, fixe
<robert_ancell> d
<RAOF> SaÌÍªÌÌÍÌvÍÍÍ¦ÌÍ­ÍÌ§ÌÌ­eÌÌÍ£ÌÌÌÍÌ¬Ì­Ì¹Ì£ ÌÍÌÍ¤Í­Ì½Ì«ÍÍÍÌ°Ì¬cÌ¿ÍÍÍ¤Ì¶ÌhÌ¯Ì¤aÌÍ¥Ì¾ÌÍÍnÌÍªÍÍÌgÌÌ°ÌÌÍÌºÌ»eÍÍ¢Ì©ÍÌ«Ì¤sÍ Í¦ÍÌ²tÌÍÌ¯ÌªoÌ¬ ÌÍÌÌÍ¦Í«Ì¶XÌÍÍ¤Ì¾ÌÍ©ÌÌ°ÌÍoÍ­Ì¿ÍrÍªÍÌÌÌÍÌÌÌ¼Ì³Ì£Ì Ì¼gÌ£.ÍÍÍÍÌÍ§Ì¥Ì¯ÍÌ¤0ÌÍ®Í¨ÌÌÍ¨ÌÌÌÌ«Ì°Ì®ÌÌÌ®.Í¯ÌÍÍÍÌÌÌ¢Ì£Ì¯Ì¯Ì©lÍÍ¦ÍÍÍ¡oÍÍ¤ÍªÌÌÌÌ®ÍÌ¹gÍ¬ÍÍ¬ÌÌÌÌÍÌºÌÌ¯ÍÌ°?Í®Í­ÌÍ®Ì¬ÌºÌ²
<robert_ancell> !
<robert_ancell> how many bytes is that string
<robert_ancell> 395 :)
<robert_ancell> kgunn_, woah, that's a lot of critical bugs :)
<robert_ancell> RAOF, if you're happy with https://code.launchpad.net/~robert-ancell/mir/mesa-xorg-docs/+merge/174073, can you put your stamp on it? thanks
<kgunn_> robert_ancell: yeah...critical means need to address for 13.10
<robert_ancell> kgunn_, yep, I agree, just scary to see so much red
<RAOF> robert_ancell: Doing a build of both xserver and mesa to check that those instructions really really really work.
<robert_ancell> RAOF, thanks. I did them to the configure stage but no futher
<RAOF> Oh - you should probably say at least â--with-egl-platforms=mir,drmâ. If someone configures mesa with only --with-egl-platforms=mir then Mir won't run, because it needs the drm platform.
 * kdub has always put the wayland platform in the mesa config
<kdub> i remember once it tried to link to something in there
#ubuntu-mir 2013-07-11
<robert_ancell> RAOF, ah
<mterry> robert_ancell, guh, so many layers of abstraction to make a surface, and none of them include the session
<robert_ancell> mterry, yes..
<mterry> robert_ancell, I'm going to file a bug
<robert_ancell> mterry, please do
<mterry> robert_ancell, https://bugs.launchpad.net/mir/+bug/1200035
<ubot5> Ubuntu bug 1200035 in Mir "Should expose the session that a new surface is for" [Undecided,New]
<mterry> robert_ancell, is that bug something I should assign to you?
<mterry> Or shall I look into it?
<robert_ancell> mterry, if you feel up to it go ahead
 * robert_ancell -> lunch
<mterry> robert_ancell, it will take me longer, but I suspect you are pretty busy already
<robert_ancell> yep :)
 * mterry rolls up sleeves
<mterry> robert_ancell, but basic approach is just to modify all the layers between session and surface to include session pointer, eh?
<mterry> in the create_surface call
<robert_ancell> thomi, is the docs uploader still broken?
<duflu> robert_ancell: Do you prefer Skype or Hangouts?
<robert_ancell> duflu, hangouts
<duflu> robert_ancell: OK, the usual one?
<robert_ancell> duflu, there's a usual one?
<duflu> robert_ancell: Umm, give me a link, any link
<RAOF> Damn duflu's flaky internet!
<thomi> robert_ancell: yeah, I need to update the configuration, it's been on my TODO list all day
<thomi> will do it now
<robert_ancell> thomi, ta
<didrocks> robert_ancell: hey, FYI, kevin told me he would look at the clang issue if he has time, I have no idea how to fix it as I don't use it
<thomi> robert_ancell: IS are fixing something relating to the mir docs uploads. I'll come back later and see if it's fixed. Gotta go help with dinner now though
<duflu> YES. Internet tubing fixed. Let's hope it sticks.
<RAOF> WOOT!
<RAOF> duflu: Hey, can I ask some compiz rendering questions?
<duflu> RAOF: OK. Might remember
<RAOF> Well, I guess it's really only a single question.
<RAOF> In two parts!
<duflu> Does it always swapbuffers? :)
<RAOF> 1) Does compiz use the composite-overlay window? and
<RAOF> 2) Does it ensure the composite overlay window is fullscreen?
<duflu> 1) Can't remember. I vaguely recall the "overlay window" is deprecated.
<duflu> smspillaz can verify
 * duflu looks at the code
<duflu> RAOF: Yes it does use overlay windows: plugins/composite/src/screen.cpp
<duflu> Also window.cpp
<RAOF> Ok.
<duflu> RAOF: And they are not guaranteed full screen
<RAOF> Hrm.
<duflu> Which I guess is part of the reason why unredirect works with multi-monitor
<RAOF> Heh, yeah.
<duflu> Oh, hang on
<duflu> RAOF: There was other logic mentioning overlay. I think the answer is yes it is only ever one overlay == root window:     overlay = XCompositeGetOverlayWindow (screen->dpy (), screen->root ());
<duflu> But the root window is all outputs, not "full screen"
<RAOF> Right.
<RAOF> Getting GLX bypass for anything spanning more than one monitor is not going to happen. Sadly.
<RAOF> But that's not soooo bad.
<duflu> RAOF: Can we still have it for windows which fit a single monitor?
<RAOF> Yes.
<duflu> Cool. Though I just realize my existing logic doesn't handle the multi-monitor case for bypass
<duflu> +d
<duflu> Then again, there are no multi-monitors yet
<RAOF> The condition should be âGLX window exactly covers an entire monitor and has override-redirect setâ
<duflu> RAOF: No, not override-redirect. It's a normal window. The decision is based on stacking order
<duflu> RAOF: "Full screen" is generally a WM hint only.
<RAOF> duflu: That can't work in general, right? There's nothing saying that a fullscreen, on top window has to be uncomposited.
<duflu> RAOF: If it's on top, and lacks an alpha channel, and not being transformed, and fits the full monitor then it's unredirected/bypassed
 * RAOF goes digging in the compiz code to see how the server can tell.
<duflu> Apps generally flag full screen with WM hints. They never set override redirect any more
<RAOF> Nor does compiz?
<duflu> RAOF: Compiz doesn't ever "set" override redirect. That's an app/toolkit decision.
<RAOF> Oh, right. I'm getting my terminology mixed up, aren't I.
<duflu> RAOF: More generally Compiz does not use the WM flags in deciding to bypass. It looks at window placement and size in the end.
<duflu> ... that way bypass decisions are right no matter how old-fashioned or modern the fullscreen method it
<duflu> *is
<duflu> RAOF: P.S. Old-fashioned fullscreen is seen with glxgears. Modern hinted full screen is seen in browsers or gnome-terminal. Though the latter uses RGBA so is never bypassed
<RAOF> What I actually want to gate on is composite status, isn't it.
<duflu> RAOF: You mean take the XComposite redirection state? Probably...?
<RAOF> Right.
<tvoss> good morning :)
<duflu> tvoss: Hi
<tvoss> duflu, hey :) how goes?
<duflu> tvoss: Going slowly but I finally have fast internet again. So that's something
<thomi> robert_ancell: mir-docs-upload job is fixed. Documentation uploads should be working again now
<RAOF> What ended up being the problem, by the way?
 * thomi goes to eat dinner
<duflu> RAOF: I was on a noisy cable to the exchange in which all the pairs experienced heavy noise. They put me on a different cable
<tvoss> thomi, hey there :)
<tvoss> duflu, \o/
<tvoss> RAOF, good morning
<RAOF> tvoss: Yo!
<tvoss> robert_ancell, good morning :)
<duflu> alf__, ping
<alf__> duflu: pong
<NikTh> Hello everyone
<duflu> alf__: BufferSwapperMulti is being constructed (a second time) with a buffer list of length 1
<duflu> Is that meant to happen?
<NikTh> Somehow apport allowed me to report a bug, even with third party software (Xmir PPA) installed. I filled a new bug report here, now full logs are listed. https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1200097
<ubot5> Ubuntu bug 1200097 in unity (Ubuntu) "compiz crashed with SIGSEGV in nouveau_pushbuf_kick() - Xmir" [Undecided,New]
<NikTh> Hope this helps devs to spot the exact problem :-)
<duflu> NikTh, ok thanks
<NikTh> duflu: Hey :-) good to see you again
<alf__> duflu: What's the scenario?
<duflu> alf__: I have client_queue constructed as size 1, even when swapper_size==3. And one is not enough so I hang waiting for a new buffer
<duflu> Haven't verified the same issue is on trunk
<duflu> Maybe it's not an issue, but designed that way. If so then it might partly explain how in_use_by_client dips to -1
<alf___> duflu: If this happens while switching swappers then it is possible that the client is holding 2 buffers and only one is passed to the new swapper, that's ok. However in_use_by_client falling to -1 is a bug, probably because when we switch to a new swapper this is not set correctly.
<duflu> alf___: OK maybe not a bug then. But with bypass it will be so I'll figure it out
<duflu> alf___: Yes BTW. The client is holding one and the DisplayBuffer holding the other (as it's being scanned out via bypass)
 * duflu counts the underscores again
<dholbach> good morning
<robert_ancell> didrocks, ok
<robert_ancell> thomi, thanks!
<robert_ancell> tvoss_, hello
<robert_ancell> tvoss_, I think you called me via G+? We were on the hangout in the meeting invite and didn't see you on IRC
<tvoss_> robert_ancell, yeah, tried to call via g+ as I was on a birthday
<tvoss_> robert_ancell, damn android, couldn't figure out how to join the hangout from the meeting invite :)
<robert_ancell> tvoss_, sorry about that, too many windows
<tvoss_> robert_ancell, know that problem :)
<robert_ancell> tvoss_, did you want a quick call without mterry or reschedule?
<tvoss_> robert_ancell, reschedule is fine with me, it's not urgent, just want to touch base with the both of you
<robert_ancell> sure
<robert_ancell> we discussed a bit together, try again at a similar time?
<tvoss_> robert_ancell, yup, let me quickly check my calendar
<tvoss_> I've got a call at 8:30 my time, what is my 9pm in your timezone?
<tvoss_> RAOF, your doc mp failed ci ;) https://jenkins.qa.ubuntu.com/job/mir-saucy-amd64-ci/220/console
<RAOF> tvoss_: You've probably got the vpn setup required to hit the âretryâ button, don't you?
<tvoss_> RAOF, nope, did a fresh install yesterday after my adventures in "all the DEs"-land
<RAOF> Because that's clearly a nondeterministic test.
<RAOF> Oh, bah.
<tvoss_> mzanetti, ping
<RAOF> robert_ancell ^^ ?
<tvoss_> mzanetti, mind hitting retry here: https://code.launchpad.net/~raof/mir/more-doc-doc-docies/+merge/174121
<tvoss_> ?
<robert_ancell> RAOF, I retries it
<robert_ancell> tvoss_, ^^
<RAOF> Hurray!
<robert_ancell> retried it already I mean
<robert_ancell> tvoss_, that's 7am my time
<RAOF> We should really turn on dbgsyms for the PPA, too.
<tvoss_> robert_ancell, bit early, isn't it? let's postpone to next week then
<robert_ancell> tvoss_, ok
<robert_ancell> tvoss_, yeah, my daughter gets up then so it clashes for me
<tvoss_> robert_ancell, no worries, next week it is
<mzanetti> tvoss_: you mean a test rebuild or autolanding?
<tvoss_> mzanetti, hold on, robert ancell already hit the button
<RAOF> To the pizza!
<tvoss_> RAOF, enjoy
<smspillaz> RAOF: 1) yes, 2) It is always fullscreen
<smspillaz> (except when there are other "unredirected windows")
<smspillaz> (in which case its fullscreen but shaped)
<duflu> smspilaz: Kinda... It's fullscreen in the single monitor case
<duflu> Man, I've lost a buffer and don't know what's holding it
 * duflu looks behind the fridge
<racarr> smspillaz: Lol internet
<racarr> (smspillaz and I just got back from berkeley ;))
<smspillaz> racarr: dude
<racarr> smspillaz: I met some guy who seemed like he was a compiz developer on the bart
<racarr> but I thought he was a total hack
<smspillaz> oh you meam robert parr?
<racarr> haha
<smspillaz> i occasionally run into him
<tvoss_> hmmm, the doc mp fails on clang :)
<smspillaz> he stalks me or something
<duflu> tvoss_: It's the build machine broken, not clang
<tvoss_> duflu, still annoying as we cannot land the mp. mzanetti: mind taking a look here: https://jenkins.qa.ubuntu.com/job/mir-clang-saucy-amd64-build/1155/console?
<smspillaz> duflu: the cow is always screensize
 * duflu realizes it's past midnight in California and stops trying to make sense of the (likely) drunk people
<smspillaz> well im not drunk anymore
<smspillaz> but by cow i mesnt composite overlay window
<smspillaz> its just phone typing
<racarr> Sam speaks truth. Its only me thats drunk
<racarr> (Zzz...)
<duflu> smspillaz: OK, so not http://www.flickr.com/photos/joshmt/5604316602/
<smspillaz> racarr: not as drunk as i was last night :)
<racarr> I dunno I did fall over on that old woman.
<racarr> err ^H^H^H^H
<racarr> Im going to go to sleep ;)
 * duflu is only jealous
<duflu> of the drinking, not the falling
<smspillaz> lolllllllll
<smspillaz> and the dropped glass
<smspillaz> XD
<racarr> Ok, I think everyone gets the picture.
<duflu> smspillaz: I meant that the COW covers all screens. All the while a "fullscreen" window usually only covers one
<smspillaz> (theres really not mich more than that)
<duflu> It's important if you're using multiple monitors and need one of them unredirected to play HD video :)
<smspillaz> duflu:ah, correct. im the case though the cow may effectively be smaller than the screensize
<duflu> Yes, where "Screen" is the compiz word for Mir's "Display"
<smspillaz> anyways, the main caveat is that the assunption tjat cow output size == screensize vreaks when there is internal redirection happening
<smspillaz> anywyas, night :)
<duflu> smspillaz: Night. Happy holidays
<mzanetti> tvoss_: I logged in jenkins and tried to reproduce the failure. couldn't reproduce. then I retriggered the job and it past that point now
<tvoss_> mzanetti, thx
<mzanetti> tvoss_: probably some temporary network issues
<tvoss_> mzanetti, saw it being merged
<alan_g> duflu: you're building on raring? I'm failing to do so because I can't find a libmockdev.dev package. What was your solution?
<tvoss_> alan_g, are you looking into the test hang on armhf?
<alan_g> tvoss_: no
<alan_g> tvoss_: I thought racarr had a solution
<tvoss_> alan_g, don't see an mp up and the bug is blocking us from landing in distro
<alan_g> tvoss_: "<racarr> alan_g: Yes. client-focus-notifications contains a solution"
<tvoss_> didrocks, mind sending me your .pbuilderrc again?
<didrocks> tvoss_: sure
<duflu> alan_g: Yes just install the saucy packages: https://launchpad.net/ubuntu/+source/umockdev
<didrocks> tvoss_: http://paste.ubuntu.com/5864291/
<didrocks> tvoss_: you probably want to change the HOOK_DIR :)
<alan_g> duflu: thanks
<didrocks> tvoss_: if you need any hook, tell me
<xnox> RAOF: i think you said you'd want to see bugs when dual screen setup is not mirrored.
<xnox> bug 1200130
<ubot5> bug 1200130 in Mir "Multi-monitor bug: different results after VT-switch" [Undecided,New] https://launchpad.net/bugs/1200130
<xnox> bug 1200129
<ubot5> bug 1200129 in Mir "Multi-monitor bug: different brightness" [Undecided,New] https://launchpad.net/bugs/1200129
<xnox> bug 1200127
<ubot5> bug 1200127 in Mir "Multi-monitor bug: different resolution" [Undecided,New] https://launchpad.net/bugs/1200127
<duflu> alf__: Is there a high-level description of how buffers are shared safely between server threads?
<duflu> A locking plan even?
<alf__> duflu: the idea is that once a buffer is extracted from the swapper, whoever extracts it owns that thread. There hasn't been a need for multiple buffer ownership until now. Do you have a use case?
<alf__> duflu: ...owns that buffer...
<duflu> alf__: Yes unfortunately the compositor/flipper thread now needs to own the buffer, not just till the flip, but also until the next page flip. And that's a different thread to the session mediator
<duflu> Hmm, maybe it's the compositor locking I should be looking at
<alf__> duflu: to be clear, there hasn't been a use case for multiple buffer ownership with both readers/writers. There can be multiple read-only users of a buffer.
<duflu> alf__: Alright. I need to figure out the multi-thread implications... or figure out how to avoid multi-threaded ownership
<duflu> ... also to figure out where my buffers are going. Because the session_mediator should never be starved with 3 buffers. Somehow it is
<alf__> duflu: could we do all this by switching compositing strategies when a full-screen session is active?
<duflu> alf__: That's part of the plan, kind of. And possibly not exactly what I'm talking about right now
<alf__> duflu: I mention this because the amount of time a buffer is held is currently managed in the compositing strategy. With a different strategy we could use a different policy for holding buffers.
<duflu> alf__: Yes I noticed the multithreaded compositor locking is a big factor. I need to clarify the problem further before I ask you more questions
<duflu> And maybe make dinner
<alf__> duflu: ok, enjoy!
<duflu> Hmm, the throttling of swapinterval=1 clients is a much more implicit chain of events than I expected
<tvoss_> duflu, I'm surprised that thoughts like that arise while doing dinner :)
<duflu> If I was making dinner I wouldn't be logged in
<duflu> My IRC presence is more definitive than other peoples
<dandrader> what do you guys do when you wanna build mir packages? doing so in an armhf chroot (with qemu) is taking forever...
<dandrader> ... and qemu crashes when running the acceptance tests
<duflu> dandrader: We usually develop via cross compilation, for speed. I'm not sure anyone else has ever needed "fast" builds of armhf debs
<didrocks> the nexus 4 + ccache works fine with Mir for my tests
<tvoss_> alf__, ping
<tvoss_> alf__, ping
<alf__> tvoss_: pong
<tvoss_> alf__, hey there :) got a list of the Mir lttng tracepoints handy?
<alf__> tvoss_: grep -C2 -R TRACEPOINT_EVENT src/
<derEremit> just booted with mir ppa and:
<derEremit> cat /var/log/lightdm/x-0.log:
<derEremit> Fatal server error:
<derEremit> no screens found
<derEremit> intel core i7
<derEremit> also as second card nvidia ( optimus ) if that matters
<kdub> didrocks, i'm trying a new approach for getting gmock out of our tree, hopefully will get it through jenkins today
<didrocks> kdub: what do you mean by new approach?
 * didrocks is interested
<kdub> by having cmake build the external project (ExternalProject_Add), instead of just adding the out of tree sources as internal sources
<didrocks> kdub: neat idea :)
<mlankhorst> fwiw, the xorg-server needs to be refreshed
<xjunior> mlankhorst: what do you mean?
<mlankhorst> system-compositor-testing xorg-server is out of date :-)
<mlankhorst> anyway I'm EOD, if anyone else wants to pick up some fixes for unity-system-compositor..
<mlankhorst> http://paste.debian.net/15562/ <- attempt to fix xserver-xorg-video-radeon alignment
<mlankhorst> seems to hard lock up here, but it does show the cursor for a bit before it hard locks up :P
<mlankhorst> http://paste.debian.net/15490/ <- experimental fix to enable sna in xserver-xorg-video-intel
<mlankhorst> probably RAOF will look at it, I'll be back on monday
<mlankhorst> kgunn_: that ati fix should help your radeon https://bugs.launchpad.net/mir/+bug/1195425 bug
<ubot5> Ubuntu bug 1195425 in Mir "Corrupted screen using radeon drivers" [Critical,Triaged]
<mlankhorst> EOD, EOW
<katie> racarr, hello
<kgunn_> mlankhorst: thanks!
<greyback> racarr: ping
<racarr> Woo. Root canal 2/3rds complete
<racarr> sorry I forgot to send an email
<robert_ancell> kgunn, oh sorry, I missed the meeting
<kgunn> robert_ancell: no problem really, everyone's got their bit to do...bregma was waiting on an arm build to finish & then we should be good to go for universe (i think)
<robert_ancell> kgunn, awesome
<olli_> robert_ancell, quick q, will we have lightdm on the phone
<robert_ancell> olli_, yes, I believe that is what the phone team decided, and I'm working to implement the required changes
<olli_> robert_ancell, thx for putting the doc together
<robert_ancell> olli_, np
<kdub> i guess resizing the display is more associated with the MirConnection than the MirSurface
<kdub> 'is this session allowed to change the resolution' more than 'is this surface on this session allowed to do change it'
<RAOF> kdub: Yup, that sounds right.
<kgunn> wrt lib deps, does anyone know why it seems sometimes android-input is the dep...sometimes 3rd_party...but 3rd_party seems to be a wrapper for android-input
<kgunn> seems redundant/overkill?
<kdub> kgunn, we've been working on deflating that directory, eventually it should just become android-input
<kgunn> kdub: thanks...confirmation i'm actually understanding my unwinding exercise :)
<kdub> RAOF, what is the easiest way for xmir to get 'display changed' notifications?
<kdub> trying to come up with an api for monitor configuration that makes sense for xmir
<RAOF> kdub: Use whatever racarr's using for focus notification?
<kdub> hmm
<RAOF> I'm resigned to the fact that it's likely to be a callback from a random thread :)
<kdub> yes, likely
<kdub> i guess i'm just asking what happens in the xserver when that callback happens though
<kdub> like, does it go and recompute the output configuration the xserver wants, and then asks to apply it?
<RAOF> I guess that depends on the cause of the notification.
<RAOF> ie: there are two possibilities - âthe hardware has changedâ, or âsome other client changed the configurationâ
<RAOF> Actually, now that I think about it - no.
<RAOF> The X server never does any output configuration directly.
<RAOF> It's just going to forward that notification on to whatever clients are listening to RANDR events.
<kdub> ah, interesting
<RAOF> And there's no guarantee what they think they'll want to be doing.
<kdub> so it does indeed need a callback signal, that it would pass on to the xrandr-subscribed clients
#ubuntu-mir 2013-07-12
<RAOF> Well, it certainly needs to be notified when the display configuration changes, yes.
<RAOF> It does not expect to immediately reply to that notification, though.
<kdub> right
<kdub> the message could be ignored if nothing in the x-world cares about the display change
<RAOF> X *might* want to keep a copy of the display configuration internally, and update it on that signal.
<RAOF> But it might just be easier to forward configuration state probes all the way down to Mir.
<kdub> so if mir can notify x of changes to the physical displays (along with the info associated with the change)
<kdub> and mir can service a configuration request at any time
<kdub> sounds like that would be good enough
<RAOF> X also wants to be notified of non-physical display changes. Basically, any time the display configuration changes - either because the hardware has changed, or because the resolution has changed, or whatnot - X wants to be notified.
<RAOF> But yeah. Notification when the configuration changes plus the ability to get the current configuration at any time is enough for X.
<kdub> well, i guess by 'physical' i meant 'the displays, and all properties associated, like resolution'
<kdub> right
<TheDrums> There was an email sent with results of people testing XMir, and one that came in late with an Intel card (Intel Corporation 82845G/GL[Brookdale-G]/GE) came up with http://paste.openstack.org/show/40176 still.
<RAOF> TheDrums: Oooh, that's a shiny new error.
<RAOF> That would be a âYour GPU is too old to support Mirâ type error, though.
<duflu> TheDrums, RAOF: I was thinking about this only a few hours ago. It should be perfectly possible to enhance gl_renderer to switch to a more compatible compositing method (i.e. no GLSL). That's what Compiz and Unity do today. I'm not aware of any significant technical hurdles
<duflu> Do we have a bug yet?
<duflu> :)
<RAOF> duflu: That's not a âI failed to get GLSLâ style thing, that's an âI can't create ARGB EGL surfacesâ type thing.
<duflu> RAOF: Sure, but they're both solvable problems
<RAOF> Failure to create ARGB surfaces will be pretty hard to solve.
<duflu> And both likely to occur on similar systems
<RAOF> How would you work around a lack of alpha channel?
<duflu> RAOF: Either ignore alpha as a fallback ugly mode, or change the surface type, or enhance Mesa
<duflu> It's all solvable.
<duflu> Some more easily than other parts
<duflu> I don't accept we have to impose tougher restrictions on hardware support in Mir than Ubuntu has today.
<duflu> It's just "not implemented yet"
<RAOF> Fair enough.
<duflu> RAOF: Laptop? :)
 * duflu is excited for new hardware
<RAOF> Not yet shipped.
<duflu> Boo
<RAOF> Indeed.
<RAOF> Soon!
<duflu> Has anyone else noticed a second or two delay in mir_demo_server[_shell] starting?
<duflu> Any idea why it's not immediate?
<RAOF> I don't _think_ I've noticed that?
<RAOF> Woo!
<RAOF> That *almost* works.
<RAOF> Modulo Unity crashing.
<RAOF> And unredirected rendering always being done in the top-left corner.
<duflu> RAOF: Isn't top-left correct? (unless you have multiple outputs)
<RAOF> Not if you're a popup that's meant to go at 1200,230
<duflu> RAOF: Oh. That's not unredirected, usually. Unless you're playing with XComposite clients
<RAOF> Or don't have a compositor running.
<duflu> Oh, of course
<RAOF> Which is easy to do, if Unity crashes :)
<TheDrums> Heh, wow.  So the answer isn't "Switch distros." after all, interesting.
<duflu> TheDrums: Even if support for older hardware is not implemented by 13.10, Ubuntu will still fall back to legacy X where Mir can't start. So long as X works for you now...
<TheDrums> Indeed, so I've noticed.
 * RAOF has ZoÃ« for an hour or so.
<tvoss_> good morning :)
<tvoss_> duflu, good morning :)
<duflu> tvoss_: Good afternoon
<tvoss_> duflu, hello, mind giving https://code.launchpad.net/~thomas-voss/mir/get-rid-of-disable-epoll-flag/+merge/174180 a quick review?
<duflu> tvoss_: Shrug, approve.
<tvoss_> duflu, the change might reduce spurious wakeups in the frontend threads
<duflu> OK. I wasn't aware we had "spurious" wakeups
<duflu> But I've never looked too hard
<tvoss_> duflu, we introduced the flag to support the ancient kernel in the buildds
<tvoss_> duflu, ignoring some of the warnings present in the code :)
<tvoss_> thomi, ping
 * duflu wonders about the evils of std::shared_ptr<T> a(p), b(p)
<tvoss_> RAOF, ping for later when you have time
<RAOF> tvoss_: Pong.
<thomi> tvoss_: hey
<tvoss_> thomi, sorry, might have lost some of your messages
<thomi> tvoss_: I just said "hi" :)
<thomi> I have the in-laws arriving for dinner any second though, so I can't stick around I'm afraid :-/
<tvoss_> thomi, okay, no problem :)
<thomi> of course, having said that, they appear to be late...
<tvoss_> thomi, of course
<duflu> alf__: I think I have a clearer explanation of my buffer problems...
<duflu> TemporaryCompositorBuffer is unsafe to put in a shared_ptr because it maintains its own use_count in back_buffer_strategy
<duflu> So even after the last shared_ptr is destroyed, the strategy has a refcount of 1 and fails to compositor_release()
<dholbach> good morning
<alf__> dholbach: Good morning!
<dholbach> hi alf__
<alf__> duflu: I am not sure I got what you mean... when the shared_ptr holding a TemporaryCompositorBuffer is destroyed, it calls BackBufferStrategy::release() which either releases the buffer or not, depending on whether someone else has acquired the same buffer in the meantime.
<duflu> alf__: I'm writing a better explanation...
<duflu> alf__: https://bugs.launchpad.net/mir/+bug/1200504
<ubot5> Ubuntu bug 1200504 in Mir "surfaces::Surface::compositor_buffer() will leak and cause hangs if used more than once" [Undecided,New]
<alf__> duflu: what I don't get is how 'a' and 'b' are the same shared_ptr?  mc::BufferStreamSurfaces::lock_back_buffer()
<alf__> duflu: returns a new shared_ptr<TemporaryCompositorBuffer> every time
<duflu> alf__: It's the same from mc::MultiAcquisitionBackBufferStrategy::acquire
<alf__> duflu: it's the same real buffer but wrapped by different TemporaryCompositorBuffer object, so I would expect ~TemporaryCompositorBuffer() to be called when b goes out of scope.
 * duflu checks again
<duflu> alf__: You make a good point. Bug incomplete for now
<alf__> duflu: ok, let me now if I can help you investigate this further
<duflu> Ooh. I think I'm alternating shared_ptr's. But because there are always at least one in existence, the underlying buffer is never released properly. And actually that's kind of what I need.
<duflu> So maybe I need a special scanout_buffer()
<duflu> Ugg. How many internal compiler errors can I hit in one day?
<RAOF> All the clangs
<RAOF> Builds faster, too ;)
 * duflu goes clang
 * duflu was sure gcc never sucked so much before
<hikiko> hi
<hikiko> could you please give me a hand with cmake?
<alan_g> tvoss: https://code.launchpad.net/~alan-griffiths/mir/workaround-1200236/+merge/174201
<alan_g> hi hikiko, what do you need?
<hikiko> I just realized alan_g that what I did yesterday doesn't give any errors because it doesn't compile anything :\
<hikiko> I have a directory nested
<hikiko> inside src/server/graphics
<hikiko> I did add_subdirectory(nested/) in graphics/CMakeLists.txt
<hikiko> and in nested/CMakeLists.txt
<hikiko> I want to:
<hikiko> 1- link with mirclient
<hikiko> 2- add the source files
<hikiko> 3- maybe(?) build mirplatformgraphics (?) <- not sure at all this is necessary
<hikiko> and I have no idea what I am doing so wrong
<hikiko> if I add target_link_libraries( mirclient )
<hikiko> I get:
<hikiko> This typically indicates a problem with your CMakeLists.txt file
<hikiko> CMake Warning (dev) at src/server/graphics/nested/CMakeLists.txt:10 (target_link_libraries):
<hikiko>   Cannot specify link libraries for target "mirclient" which is not built by
<hikiko>   this project.
<hikiko> then make shows no errors and doesn't build my source files
<tvoss> hikiko, how is your target called?
<alan_g> hikiko: you're leaving me to guess where you get a problem. graphics/nested/CMakeLists.txt should be similar to src/server/frontend/CMakeLists.txt with appropriate name changes
<alan_g> maybe you can pastebin your graphics/nested/CMakeLists.txt?
<hikiko> oh I did something completely different :) I thought target_link_libraries are the libraries you want to link with
<hikiko> sure alan_g
<hikiko> 1 sec
<hikiko> alan_g, http://paste.ubuntu.com/5867495/ that's what I have now (I removed include_directories etc to keep it simple)
<alan_g> hikiko: the first parameter to those commands is the library you want to build
<hikiko> so I have to add mirplatformgraphics SHARED?
<hikiko> or a new one?
<alan_g> http://www.cmake.org/cmake/help/cmake_tutorial.html
<alan_g> hikiko: you want a new static library that will be linked info mirserver
<alan_g> add_library(mirnestedgraphics STATIC ...
<alan_g> target_link_libraries(mirnestedgraphics mirclient
<hikiko> no :) I did this yesterday, but then I thought what alexandros meant was that I have to remove it and use mirplatformgraphics and since I was getting errors with mirplatformgraphics I totally removed it... :p I can't make myself clear :\ that worked :DD +I got the compile errors back!!! thanks a lot... :)
<alan_g> hikiko: that wasn't clear. If you still have a problem, push a branch to ~mir-team (where I can see and fix the problem)
<alan_g> hikiko: if you don't have a problem, that's even better
<hikiko> no I haven't :) it works :D I just misunderstood something yesterday :) thank you alan_g! :)
<alan_g> hikiko: you're welcome
 * duflu gives up; goes to dinner
 * alf__ is attempting a reboot after 600MB worth of saucy updates...
<FernandoMiguel> morning
<FernandoMiguel> I assume todays update of ppa on ubuntu 13.10 is broken?
<FernandoMiguel> got to boot in safemode
<FernandoMiguel> xserver -mir is not a valid option, according to the logs
<RAOF> Ah. You've not pinned the PPA as suggested.
<RAOF> And someone's uploaded a new Xserver  :)
<FernandoMiguel> RAOF: ehe
<FernandoMiguel> trying to purge it now
<tvoss> FernandoMiguel, pinning the ppa is really a good idea right now :)
 * tvoss is doing a reboot, too
<RAOF> You should get a shiny new -ati that works on resolutions that aren't 1366x768 and a bonus -intel that uses sna.
<FernandoMiguel> good luck tvoss :p
<FernandoMiguel> RAOF: all intel DELL here
<FernandoMiguel> The following packages will be DOWNGRADED:
<FernandoMiguel>   libdrm-intel1 libdrm-nouveau2 libdrm-radeon1 libdrm2 libegl1-mesa libegl1-mesa-drivers libgbm1 libgl1-mesa-dri libgl1-mesa-glx
<FernandoMiguel>   libglapi-mesa libgles2-mesa libkms1 liblightdm-gobject-1-0 libopenvg1-mesa libsdl1.2debian libxatracker1 lightdm unity-greeter
<FernandoMiguel>   xserver-xorg-video-ati xserver-xorg-video-intel xserver-xorg-video-nouveau xserver-xorg-video-radeon
<FernandoMiguel> I had two mouse pointers too
<FernandoMiguel> https://bugs.launchpad.net/ubuntu/+source/ubuntu-ui-toolkit/+bug/1200553
<ubot5> Ubuntu bug 1200553 in ubuntu-ui-toolkit (Ubuntu) "two mouse pointers" [Undecided,New]
<FernandoMiguel> guess we can close that one... probably the new X
<FernandoMiguel> PPA purged successfully using aptitude fallback
<FernandoMiguel> RAOF: that should be enough, no?
<RAOF> FernandoMiguel: That should get you back to stock Ubuntu, which should get rid of the second mouse pointer and allow you to start, yes ;)
<FernandoMiguel> ok
<FernandoMiguel> guess I'll wait for MIR to hit the repos
<FernandoMiguel> that was a fun trial
<FernandoMiguel> I must say, it is faster
<FernandoMiguel> brb
<RAOF> People do say that.
<FernandoMiguel> reboot
<RAOF> I don't really know why!
<FernandoMiguel> ofc it could also be from other upgrades
<RAOF> Some thing we do must make us feel faster.
<FernandoMiguel> but the last version of unity/X before I upgraded to MIR was actually slower than the earlier ones
<FernandoMiguel> hence a person notices more the speed bump
<RAOF> That could be it :)
<FernandoMiguel> I did notice while jumping windows
<FernandoMiguel> and expose
<FernandoMiguel> multi screen with a 37" 1080p tv also behaved much better than X
<FernandoMiguel> brb
<FernandoMiguel> FYI it's working
<FernandoMiguel> :)
<FernandoMiguel> any time table for MIR to hit 13.10 repos?
<tvoss_> FernandoMiguel, bugs preventing us from entering universe https://bugs.launchpad.net/mir/+bugs?field.tag=entering-saucy
<tvoss_> FernandoMiguel, so yeah, hopefully really soon
<FernandoMiguel> cool
<RAOF> tvoss_: I'm pretty sure the input delay we're seeing is a missing-damage issue. It's possible that the signal unmunging MP might fix that (fingers crossed!). Failing that, I'll investigate next week.
<tvoss_> RAOF, ack ... that's mostly my conclusion, too
<tvoss_> RAOF, can we get an updated version into the system-testing ppa today?
<RAOF> tvoss_: Sure. Do you want to babysit the copies? All you need to do is copy-with-binaries Mir, and then copy-with-rebuild unity-system-compositor.
<tvoss_> RAOF, okay, what about the xserver?
<tvoss_> RAOF, or do we just need a new mirclient library?
<RAOF> Just a new mirclient library
<tvoss_> RAOF, no versioning conflicts, then?
<RAOF> There *shouldn't* be.
 * tvoss_ wonders if we should break the ppa over the weekend
<RAOF> The xserver depends on a (too strict) >= version, so a newer mir won't break that.
<tvoss_> RAOF, okay
<tvoss_> RAOF, can you trigger the respective copies?
<tvoss_> RAOF,  I will watch it building then
<mirtestuser> Hi All! I am running Mir (Ubuntu 13.10 + enabled Mir according to Olli's blog post).
<tvoss_> mirtestuser, cool :)
<mirtestuser> I get the two mouse pointers (hardware and software pointers).
<mirtestuser> Typing text feels a big laggish (takes a few moments for the text to appear). Is this a known behaviour?
<tvoss_> mirtestuser, yes, that's a known bug: https://bugs.launchpad.net/mir/+bug/1199450
<ubot5> Ubuntu bug 1199450 in XMir "[xmir] Inputs slowing, last event of a stream of events greatly delayed" [Critical,Triaged]
<tvoss_> mirtestuser, it turned up after the last update of the ppa and we are working on the fix
<tvoss_> mirtestuser, what gpu are you running on?
<mirtestuser> (also compiled from the 'mir' repository in order to get the examples, etc)
<mirtestuser> tvoss_: thanks. It's AMD/ATI Radeon HD 6320 ( Evergreen).
<tvoss_> mirtestuser, cool, I'm running Intel myself
<mirtestuser> What Mir examples, etc are available to try out?
<tvoss_> mirtestuser, there is not a documented list right now, but if you have built from source, you can find the examples in bin of your build dir
<mirtestuser> I am going through those available at mir/build-linux-x86/bin/
<mirtestuser> The mir_demo_client* do not run. I get some errors.
<RAOF> What errors.
<RAOF> ?
<mirtestuser> ./mir_demo_client_eglflash Can't get connection user@laptop:~/Downloads/mir/build-linux-x86/bin$ ./mir_demo_client Starting Connected mir_demo_client: /home/user/Downloads/mir/examples/demo_client.c:109: demo_client: Assertion `mir_connection_is_valid(mcd.connection)' failed. Aborted (core dumped)
<RAOF> Have you started a mir server? mir_demo_server_shell is most likely the one you want.
<mirtestuser> Those mir_demo_client* apps do not seem to get a valid connection to the running Mir server.
<mirtestuser> RAOF: I see. I am trying to run them from within the GUI (Ubuntu) assuming that they will connect to the running Mir server. That is not the case?
<RAOF> They should get a connection to the running Mir server.
<RAOF> If you started mir_demo_server_shell as root and the clients as non-root though you'll need to chmod the /tmp/mir_socket so that they can connect to it.
<mirtestuser> RAOF: that's right, the running Mir server on Ubuntu probably runs are root. By changing the permissions I manage to run the demos.
<RAOF> mirtestuser: Oh, you're running these from XMir?
<mirtestuser> RAOF: Yes, I am running them from gnome-terminal/XMir.
<RAOF> Funky :)
<mirtestuser> If a process is spawned from gnome-terminal (XMir), then it is limited to XMir then?
<tvoss_> RAOF, yeah, it's actually quite cool, the demos are overlayed on top
<mirtestuser> Is there an app that is pure Mir (like simple text editor) so that it is possible to compare the behaviour between Mir / XMir? (for example, the lag during typing).
<RAOF> I don't know. If the qtplatform was in the PPA you could just use a random Qt app.
 * alan_g starts to hate clang
<kgunn> alf__: alan_g hikiko any of you running xmir...like dogfooding/using it regularly ?
<kgunn> i have pinned ppa, but this morning i did a dist-upgrade...and it uninstalled my lightdm & u-s-c
<alan_g> kgunn: never - until I can test the mir I build with a session mir it would just prevent any work being done.
<kgunn> ...so i think packages might be busted again....
<hikiko> kgunn, I removed it
<alf__> kgunn: +1 alan_g
<hikiko> I have an intel and I was getting a black screen so I removed it
<hikiko> but if you want me to test it
<hikiko> I can use it again
<kgunn> well i'm not going to force anyone...but it is nice to have a second sane opinion (esp if you have multiple machines)
<hikiko> I ran ubuntu only in my laptop
<kgunn> bregma: ^
<kgunn> you having any trouble?
<hikiko> but ok I can try (not atm because I have to finish something)
<kgunn> hikiko: np
<kgunn> i know bregma is a user
<bregma> I'll check
<alan_g> kgunn: Some of us want one of the machines to work (and keep it on raring)
<kgunn> alan_g: stability...its so overrated :)
<bregma> I have a test machine running mir because that's what I do
<bregma> besides, it's fun to watch people try to control two pointers
<alan_g> kgunn: Until I worked here I kept my "stable" machine on the LTS
<kgunn> bregma: ....you need a hobby if you like watching pointers race across the screen
<kgunn> btw...the x pointer always loses
<bregma> people like to watch cursor races just to see a pointer crash
<tvoss_> alf__, ping
<alf__> tvoss_: pong
<tvoss_> alf__, the testing ppa is broken, do you know how to trigger a rebuild of unity-system compositor?
<alf__> tvoss_: no :/
<kgunn> tvoss_: checking to see if ancell told me last time...
<olli_> kgunn, bregma... who is on the armhf build issue?
<olli_> do we have an eta
<alf__> tvoss_: packages for the testing ppa are copied from the staging ppa. Does the staging ppa have what you need?
<bregma> olli_, I'm still working on it, expect something today
<tvoss_> alf__, we need a non-binary copy
<kgunn> tvoss_: seems u-s-c is building now
<alf__> tvoss_: you can have non-binary copies from one ppa to another
<alf__> tvoss_: (i.e. rebuilt the package in the target ppa)
<alan_g> olli_: kgunn bregma - is that the hanging input tests? (tentative fix in -c 847)
<tvoss_> kgunn, ack
<kgunn> tvoss_: so we need to copy both u-s-c & mir right ?
<tvoss_> kgunn, mir should already be current
<kgunn> tvoss_: ok
<kgunn> tvoss_: yeah....makes sense...duh
<greyback> kgunn: hmm, something may be wrong somewhere. I just distupgraded, now xmir fails to start. X is failing with "unrecognised option -mir"
<tvoss_> greyback, did you pin the ppa?
<kgunn> greyback: working on it
<greyback> tvoss_: yes
<tvoss_> kgunn, you sure that usc is building in the testing ppa?
<kgunn> tvoss_: i was about to copy u-s-c over
<tvoss_> kgunn, do so
<greyback> Huh, my xserver-xorg is from saucy main repo. That can't be right
<greyback> but no other version exists in apt-cache policy
<kgunn> tvoss_: copying
<tvoss_> kgunn, but source, not binary, right?
<kgunn> tvoss_: binary per ancell's instructions
<kgunn> that he sent in case this happened again
<tvoss_> kgunn, the system compositor needs to rebuild against mir in the ppa
<kgunn> tvoss_: it did technically....in staging...it was building against 848...which is the same that was in the -testing
<tvoss_> kgunn, okay
<bregma> just managed to get my apt updates done, and yes, it kindly wants to remove lightdm and unity-system-compositor for me
<bregma> and also unity
 * bregma looks for his trusty hammer.....
<kgunn> didrocks: confused/looking for help....so i copied over u-s-c to
<kgunn> https://launchpad.net/~mir-team/+archive/system-compositor-testing/+packages
<kgunn> 2 things...#1...i accidently copied raring & saucy ( just meant to copy saucy)
<tvoss_> kgunn, unity-system-compositor - 0.0.1bzr33saucy0.161 is pending and not yet propagated
<kgunn> tvoss_: thanks...where did you see that / how does one tell ? (i must have missed it)
<tvoss_> https://launchpad.net/~mir-team/+archive/system-compositor-testing/+packages
<didrocks> kgunn: what's the question? ;)
<kgunn> didrocks: well...my #1 is still valid....if i accidently copied in a package that shouldn't be in a ppa...how to expunge ?
<didrocks> kgunn: you have this "delete package link"
<didrocks> https://launchpad.net/~mir-team/+archive/system-compositor-testing/+delete-packages
<kgunn> didrocks: got it thnaks
<didrocks> yw ;)
<tvoss_> kgunn, propagated
<tvoss_> dist-upgrading right now
<kgunn> tvoss_: moi aussi
<sil2100> renato: ping
<sil2100> renato: is there any work being done related to adding more autopilot integration tests to address-book-app?
<mhall119> kgunn: where is the XMir code and the modified Xorg server code that is needs?
<kgunn> mhall119: uno momento
<kgunn> mhall119: instructions here http://unity.ubuntu.com/mir/building_source_for_pc.html
<kgunn> are now updated to include all the other bits
<kgunn> hth
<mhall119> thanks kgunn
<mhall119> kgunn: have the xorg-server changes been submitted upstream?
<kgunn> mhall119: i have to punt on that one...
<kgunn> its on the todo list...and
<kgunn> raof is listed as inprogress (i just looked at it yesterday)
<kgunn> so the full intention is to do so....
<kdub> ok, so for names for the surface-state-related stuff...
<kdub> mi::InputCriteria, mg::CompositorCriteria, ms::SurfaceCriteria (for the readonly information)
<kdub> and for the interface to change that information
<kdub> i think we can group that all into ms::MutableSurfaceState (containing alpha, input regions, position)
<kdub> just because at the moment, there's no need to split that all up
<alan_g> CompositorCriteria makes sense as it sets out the way that compositing should be done. I'm not so convinced by the others...
<kdub> mi::SurfaceConfiguration
<kdub> ms::SurfaceState
 * alan_g tries to remember what those interfaces have in them
<mhall119> RAOF: /w 116
<mhall119> ignore
<alan_g> kdub: mi::SurfaceConfiguration is your rework of InputChannel?
<kdub> well, no mi::InputChannel hasn't changed
<kdub> mi::SurfaceConfiguration has the size, position, and input regions
<alan_g> mi::Surface?
<kdub> i think that works
<kdub> with ms:: though, there already is a ms::Surface, so ms::SurfaceState sounds better (containing transform, size, name)
<alan_g> alf__: what do you think of these names? ^^
<alan_g> kdub: does ms need the transform? Or just the pre- and post-transform properties
<kdub> alan_g, i'll have to check
<kdub> alan_g, no, transform will go away when I consolidate the implementation class
<kdub> so that should just be name, size_and_position
<kdub> so, to summarize, mg::CompositorCriteria ( the read-only interface the compositor uses), mi::Surface, the read-only interface the input stack uses
<kdub> ms::SurfaceState (the basic generic info the shell needs) and ms::MutableSurfaceState (the way the shell can change the surface state how it needs)
<alan_g> Wasn't it mg::CompositingCriteria?
<kdub> ah, ok :) mg::CompositingCriteria
<alf__> alan_g: kdub: they seem ok. I wonder if at some poin ms::Surface should be renamed to ms::SurfaceImpl (or perhaps hidden somewhere), and free ms::Surface to be used for an interface name
<kdub> alf__, i'd expect something like that in the future, not in the MP
<alan_g> alf__: ms::Surface should never have been public - it was forced there by some early example code
<kdub> right
<alf__> kdub: ok
<kdub> but after this mp, ms::Surface : public mg::Renderable is broken, so we can put a sensible  public interface around it
<kdub> and what is now ms::Surface will just become an implementation class
 * kdub goes about changes
 * alan_g escapes to the weekend before kdub pushes changes for review
<kdub> haha :)
<bregma> gosh dang I made one small typo and now I have to restart my arm build.... another hour-and-a-half delay
 * tvoss notes that the testing ppa has got a very snappy version of mir/xmir
 * ogra_ still waits for XMir on his chromebook 
<kdub> renaming is a pain, but worth it in the long run
<renato> sil2100, we are waiting for the final designs before start to writing autopilot
<renato> sil2100, does not make sense implement autopilot tests with the current UI since this will change
<kgunn> bregma: dang it!!...success yet?
<bregma> kgunn, https://code.launchpad.net/~bregma/mir/lp-1195265/+merge/174478 ...  I finally get a build on my machine
<bregma> won;t know if it fixes on the builders until they've done their bit
<sil2100> renato: ok, thanks
<bregma> gah, my branch fails in the builders https://jenkins.qa.ubuntu.com/job/mir-android-saucy-i386-build/1299/console but passes fine on my hardware...  anyone have any ideas?
<bregma> is jenkins actually cross-building on i386 and failing because it tries to run just-built executables?
<wilee-nilee> So in what release does mir become the default?
<gotwig> howdy :D
<gotwig> mhall119: any idea when QT apps can run on Mir?
<kgunn> gotwig: its happening already...https://wiki.ubuntu.com/Touch/Testing/Mir
<kgunn> kdub: ^ can you take a look at bregma err's
<mhall119> gotwig: the bigger question is when we'll be running Unity 8 on mir (on desktops and devices)
<kdub> hmm, looks like the builder's trying to exec the arm executable, i'd guess
<kgunn> bregma when you say "passes fine on your hw"....are you native compiling on arm? or cross compiling ?
<kdub> right, it looks like a cross-arch execution attempt is being made
<kgunn> but if you go look at that check_discover_tests_in_acceptance-tests it just looks like a bunch of make calls to verify directories are populated....
<kdub> right, but it touches ctest (which i beleive we make)
<olli_> quick question (stupid question too;)
<olli_> GPUs using UMA doesn't tell whether it's using a binary/free driver
<olli_> i.e. any GPU can be using UMA
<olli_> is that correct?
 * olli_ tries to parse a statement from sales
<olli_> and it doesn't quite make sense
<olli_> racarr, kdub, kgunn ^
<kdub> olli_, uma == unified memory architecture?
<olli_> yep
<olli_> well
<olli_> that's how I read it
<olli_> not sure what Mr. SalesPerson had in mind
<olli_> ;)
<kdub> the question is sort of a 'does not compute'
<kgunn> olli_: or if it was wrt graphics....did he mean to say UXA ?
<kgunn> the evolution of EXA
<kgunn> which is now subsumed by SNA
<kgunn> so chronologically it went EXA -> UXA -> SNA
<olli_> kdub, UMA is not an attribute of a GPU which would say anything about vendor or driver
<kgunn> olli_: after a quick googling...yeah, its using system mem instead of dedicated video/gfx mem i think
<kgunn> it seems to be kind of associated with intel....but i know for a fact of other architectures that use system mem
<kgunn> gpu archs that is
<kgunn> so conceptually....yeah....any gpu could do it
<olli_> kgunn, nv & ati do UMA as well
<olli_> according to uncle google
<kdub> right, its of course common in the mobile world too
<mlankhorst> kdub: ^citation needed
<mlankhorst> it's a mess :P
<kdub> https://developer.qualcomm.com/forum/qdevnet-forums/mobile-gaming-graphics-optimization-adreno/1286
<kdub> it is sort of whatever they want to do though of course
<kgunn> bregma: do you need help ?
<kdub> bregma, the problem is in MirCommon.cmake
<bschaefer> kgunn, kdub bregma is EOD
<kgunn> kdub: do you know a sensible solution ?
<kdub> ah, ok, well, i'll MP how I got his fix to work
<kdub> as like, a merge to a merge
<kgunn> kdub: excellent
<kgunn> put bregma as reviewer
<kgunn> too
#ubuntu-mir 2013-07-13
<Walther_> Hello folks! Just did do-release-upgrade -d to saucy and followed isntall instructions on how to install Mir. However, now I'm getting no "unity" - no top bar, no sidebar, but desktop shows and i can fire up terminals via ctrl-alt-t and so forth
<Walther_> Also, the display is running in pretty low res
<Walther> on the suggested "sudo mir_demo_server", i get the following, pehaps hinting at problems:
<Walther> ERROR: /build/buildd/mir-0.0.6bzr848saucy0/src/server/graphics/gbm/gbm_display_helpers.cpp(284): Throw in function int mir::graphics::gbm::helpers::DRMHelper::open_drm_device(const mir::graphics::gbm::helpers::UdevHelper&)
<Walther> Dynamic exception type: boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<std::runtime_error> >
<Walther> std::exception::what: Error opening DRM device
<Walther> [boost::errinfo_errno_*] = -13, "Unknown error -13"
<Walther> Help very much appreciated!
<Walther> Also, walther@doppio:~$ grep -i xmir /var/log/Xorg.0.log
<Walther> [     8.668] xorg-server 2:1.14.1-0ubuntu0.8+xmir1 (For technical support please see http://www.ubuntu.com/support)
<Walther> [     8.678] (WW) "xmir" is not to be loaded by default. Skipping.
<mlankhorst> Walther: hybrid, by any chance?
<Walther> Nope, pure 7970 only desktop
<Walther> core2quad -> no integrated graphics
<mlankhorst> is the dri node in use by any chance? lsof /dev/dri/*
<Walther> Will have a haswell w/ igpu soon when my new parts arrive, but that's another matter
<Walther> mlankhorst: empty
<Walther> er, empty response, that is
<Walther> I'm pretty sure i'm not getting mir at all, from Xorg.0.log [     8.678] (WW) "xmir" is not to be loaded by default. Skipping.
<Walther> also the ps aux grep compositor thingy returns nothing but the grep command itself
<Walther> Not afraid of cli/techy stuff, if you have any ideas on where to look / what to try, just mention
<Walther> /etc/lightdm/lightdm.conf.d/10-unity-system-compositor.conf has the appropriate lines
<Walther> mlankhorst: further ideas, by any chance?
<mlankhorst> not atm, is that southern islands? :P
<mlankhorst> and does it work with normal X?
<Walther> Tahiti, and worked fine on 13.04
<Walther> w/ fglrx at least
<Walther> but logging in with this 13.10 + mir install -> a desktop without bars/dash and low res
<Walther> Hm, apparently by launching gnome-control-center I could adjust the screen res to right. But I think I'm not running mir, and yeah, unity/dash are mising
<Walther> Ha, dconf reset -f /org/compiz did the trick
<Walther> of getting bars back.
<Walther> Still not sure I'm having mir though.
<Walther> ...yeah, still getting [     9.099] (WW) "xmir" is not to be loaded by default. Skipping.
<mlankhorst> fglrx won't work with mir
<Walther> Also, graphics rendering is slow - moving windows around, typing text, etc
<Walther> mlankhorst: Yeah, I removed proprietary drivers as per instructions
<Walther> on the foss drivers atm afaik
<mlankhorst> yeah you have a southern islands chip, most support is in saucy atm except for the ddx :P
<Walther> I am running saucy :)
<mlankhorst> so you'd need to recompile xserver-xorg-video-ati yourself with glamor enabled for it to work
<Walther> but yeah, i'm running saucy, so you said the support should be there
<mlankhorst> most support, but you need all support..
<Walther> Ah
<Walther> hmm, i wonder if xorg-edgers would help
<Walther> Or would that just completely break all chances of mir workigng?
<Walther> -g
<mlankhorst>  if you want mir on that card you need to build glamor support in the xserver-xorg-video-ati source of the mir ppa
<Walther> hnggh, are you absolutely sure that's the only option for now?
<Walther> i can't find any documentation on the matter
<Walther> (of course at early testing / development phases there *isn't* often documentation...)
 * mlankhorst points at the 'need'
<Walther> Sigh... Well, thanks for help!
<Walther> I'll probably purge the mir repo and revert back to "just" 13.10 then, and see how / when things progress
<Walther> Should I file a bug or something on Tahiti / Southern island support?
<Walther> (and mir compatibility, that is)
<mlankhorst> it's the same as normal xorg-server in this case, if normal xorg-server works, mir-ified xserver would probably work too
<arsson> u-s-c nouveau support? When...?
<mlankhorst> dno, wrote it ages ago
#ubuntu-mir 2013-07-14
<sgx1> it seems that all bugs in https://bugs.launchpad.net/mir/+bugs?field.tag=entering-saucy have been fixed. so has mir landed in saucy daily build? can i try it without adding the mir ppa?
<TheDrums> For one thing, you need to wait for "Fix released", what it is now means it's in Bzr, so my guess is 0.0.7 should technically make it.
<thomi> morning
<robert_ancell> thomi, ping
<thomi> robert_ancell: hey
<thomi> what's up?
<robert_ancell> thomi, can you do a call about this qa lab stuff?
<thomi> sure
<thomi> let me just grab my headset, one moment
#ubuntu-mir 2014-07-07
<RAOF> H
<RAOF> Dear armhf: really?
<duflu> Hmm, did some pipe specific to Canonical just go down?
<RAOF> Dunno. What are you trying to resolve?
<duflu> RAOF: Canonical mail, Launchpad and IRC all went quiet for a while.
<duflu> Now they're back
<RAOF> duflu: Is there any particular reason not to _catch_ the exceptions in the compositing thread?
<duflu> RAOF: Because we don't know how to recover from them, and the act of catching trashes the stack trace
<duflu> Is there another solution?
<RAOF> Hm. I think we actually _do_ know how to recover from them; try again next frame.
<RAOF> That'll work for some of the errors.
<RAOF> Well, some classes of failure.
<duflu> RAOF: Recovery would be excellent if it was reliable. If there's a risk of looping then it's safer to get a nice bug report.
<RAOF> We'd need to try for 5 or so frames, then bail.
<duflu> But still, I'd prefer to debate the recoverability of each scenario separately
<RAOF> Yeah. That'd require us to have an actual exception hierarchy. And to proxy said things to the main thread, I think.
<RAOF> Which is indeed a post-RTM thing.
<duflu> RAOF: Yes, actual exceptions with actual catching
<duflu> Although if the recovery is near the ioctls then maybe not even exceptions are required
<RAOF> How useful were the cores generated when these exceptions _were_ generating cores?
<RAOF> Because looking through the code it looks like a lot of the error state has dropped out of the stack before the exception is thrown.
<duflu> RAOF: Very, for a brief while between the first fix and when it regressed.
<duflu> Unfortunately the first fix occurred after the first flood of bug reports
 * RAOF is quite surprised
<anpok> we could assemble additional error information with boost exception while unwinding
 * duflu offers anpok the wear jar
<duflu> *swear jar
<RAOF> anpok: You know what we should do? Rather than use enable_error_info on std::runtime_errors, we should just throw std::system_errors.
<duflu> Throwing anything you don't know how to catch and recover from is the problem
<RAOF> duflu: Not really, because we're a library.
<anpok> RAOF: well .. if there is relevant information in the stack itself
<RAOF> But throwing something we don't handle in a thread of our creation is indeed a problem.
<anpok> but yes system_error looks more like the right type
 * RAOF queues up a âreplace everything with system_errorâ branch.
<duflu> RAOF: Unless it includes full catching and recovery it's a step backwards... we really need to deal with each throw separately
<duflu> It's a long path
<RAOF> It's not a step backwards. At worse it's a step sideways. It gets us a better exception message if nothing else.
<RAOF> It's also just the sort of mechanical transformation that I feel I'm about capable of doing at the moment :/
<duflu> RAOF: I know how that feels. However using any exceptions without full recover implemented will fail to solve the bug
<duflu> recovery even
<RAOF> That is correct.
<duflu> RAOF: OK then, no problem. Please don't create conflicts for me though :)
<duflu> Oh Compiz/Unity7 I won't miss you... just as soon as we have the replacement ready
 * duflu has the tiny phantom window problem. They sporadically appear and disappear
<duflu> camako: Still showing 0.1.9 is the latest download. Don't forget https://launchpad.net/mir   Development focus = 0.5
<camako> duflu... Weird... I coulda sworn I saw 0.4.0...  lemme check again
<duflu> camako: Should be Development focus = 0.5, but is presently utopic (which is obsolete)
<duflu> You have to configure the Mir project page
<duflu> Sorry I can't give more details. I don't administer any projects any more. I can't see a project details page to cite for an example
<duflu> camako: You should have a "Change project details" option (or similar) on https://launchpad.net/mir
<duflu> ... which I don't
<duflu> Oh and the trusty (and earlier) series possibly should still be visible.  Because it's theoretically possible for them to get fixes backported, although highly unlikely
<camako> duflu still looking
<duflu> camako: https://answers.launchpad.net/launchpad/+question/82049
<camako> duflu .. "change details" doesn't exist for me
<duflu> camako: Oh. You aren't a project admin either
<duflu> I wonder who it
<duflu> is
<camako> duflu... guess not
<camako> Thomas?
<duflu> didrocks, sil2100, Saviq: Can anyone add camako to pspmteam?
<duflu> Or Mirv? ^
<duflu> The Mir Tech Lead has no permissions to administer the Mir project :)
<camako> duflu.. I was able to change status for 0.3, 0.4 as I was the "release manager" on lp...
<camako> for 0.5, you are the release manager since you created it
<duflu> camako: Yeah I can do that too on the series I created. But you need top-level access to admin the Mir project. That's owned by https://launchpad.net/~pspmteam
<camako> right
<duflu> camako: popey is also an admin. Ask him when he comes online
<camako> duflu... ok
<duflu> It's really annoying then the button you need is hidden
<ogra_> duflu, camako looks like dbarth or popey can add people there
<duflu> Yep. And David's not online yet either
<camako> ogra_.. ok thanks
<duflu> alf_: You around?
<alf_> duflu: yes
<duflu> alf_: Are you familiar with any changes that happened in June around buffer ownership? Looks like the new behaviour is that a client can own _all_ the buffers until/unless a compositor needs one.
<duflu> Sounds like a bug but may be a feature
<alf_> duflu: I don't remember of an explicit change, but it sounds like something that may have changed by Alberto's work on the BufferQueue?
<duflu> alf_: It seems to work but in theory shouldn't. If a client is allowed to have all the buffers on startup then compositors get what?
<duflu> I guess I'll keep trying to write more tests till I can prove something is amiss
<RAOF> Soooooo.
<alf_> duflu: Perhaps it works currently because the clients get one buffer at a time?
<RAOF> Why does armhf seem to receive fewer fds than sent?
<duflu> RAOF: sizeof() silliness?
<RAOF> Hm.
<duflu> But AFAIK sizeof all the important bits is the same as desktop
<RAOF> I shall come back to this later.
<RAOF> But I *send* 2 fds, and cmsg->cmsg_len on the receiving end is 16.
<RAOF> Which is *not* CMSG_LEN(2 * sizeof(int))
<RAOF> Anyway, later.
<duflu> RAOF: Oh. I don't understand the cmsg stuff but remember everyone was suspicious of recent changes to it
<popey> someone ping me?
<ogra_> camako, duflu ^^^^
<seb128> popey, hey
<duflu> popey: Yeah can you add camako to pspmteam?
<camako> ogra_.. thanks
<ogra_> ;)
<duflu> We presently have no one able to administer the Mir project :)
 * popey looks
<popey> "lol"
<camako> I think kgunn is part of the pspm team
<camako> but yea.. I should be as well
<popey> done
<duflu> popey: Ta
<camako> popey thanks
<camako> duflu... done... looks good now?
<duflu> camako: Ah cool yes
<popey> np
<duflu> camako: For cleanliness we could rename "trusty" to "0.1" and "saucy" to "0.0"
<duflu> I think that's possible
<camako> duflu... sure
<camako> duflu.. done! Looks all neat :-)
<duflu> camako: Cool again. Also looks better here now: https://launchpad.net/ubuntu/+source/mir
<camako> yep
<duflu> camako: I think we need a new plan to reduce branching. Somehow we need to avoid branching until after the server ABI has changed
<camako> duflu.. yea I agree
<duflu> Perhaps explicitly targeting lp:mir/0.N (where N is "next") would work
<duflu> then we don't need to call anything "devel"
<duflu> but that increases the risk of proposals targeting the wrong one
<duflu> Whatever the approach it should be possible to release 0.5.1, 0.5.2 ... before ever needing to branch a 0.6 for example
<camako> yea currently it's a presumptive approach
<alan_g> duflu: instead of changing targets can we just rename devel and create a new one each release
<duflu> alan_g: You mean use "devel" as a series? I think that would look confusing in Bugs that are targeted
<duflu> Better to have a number
<duflu> Or just keep the development branch as it is and tag 0.5.x on devel _until_ an ABI break happens
<duflu> Then branch
<duflu> But that requires a "freeze" period for each point release. Same old problem
<alan_g> duflu: got time to review this before you go? https://code.launchpad.net/~alan-griffiths/mir/fix-1300653/+merge/225692
<duflu> alan_g: Maybe :) Hang on
<alan_g> duflu: thanks
<duflu> np
<kdub_> hey all
<mzanetti> anpok: hey, I'd need some help with touch input events.
<mzanetti> would you have a bit of time for that?
<alf_> mterry: Hi! I am working on refactoring USC. Do we have a document (or even better tests) describing the expected behavior for session switching and spinner display when we get DM events?
<mterry> alf_, no, but I could try to put together a quick explanation
<anpok> mzanetti: meeting is in a minutes
<anpok> -s
<anpok> right after that
<alf_> mterry: That would be useful, thanks. Based on that I can write some tests you can then review for expected behavior.
<alf_> mterry: could you please also briefly describe in the explanation what exactly "next" and "active" mean for the DM
<mterry> alf_, yup
<mterry> writing that now in fact  :)
<alf_> mterry: thank you :)
<mterry> alf_, sent email.  Let me know if you have questions
<alf_> mterry: great, thanks
<alf_> camako: Sorry, hangouts crashed computer
<greyback> alf_: hey just to tell you, the issues I was having on Friday last week (the GL/GLES conflict) I resolved. I needed to call eglBindAPI before mir created a context. However I had made a typo: EGL_OPENGL_BIT instead of EGL_OPENGL_API
<greyback> so no need for an immediate mir change
<alf_> greyback: Interesting that this works, since Mir sets eglBindAPI() to ES2 when creating a context
<alf_> greyback: this for the desktop, IIRC?
<greyback> alf_: really? Heh, then I'm confused :) Yes desktop
<alan_g> dednick: had a look at this yet? https://code.launchpad.net/~alan-griffiths/mir/spike-trusted-helper-socket/+merge/225677
<dednick> alan_g: eh. no, i haven't had a chance yet.
<dednick> alan_g: sorry. i will try to get it in tomorrow morning. Just busy trying to get somethings to land
<alan_g> dednick: np. (Until kgunn asks why it didn't land.) ;)
<PreSSion> so, for example, a game for example metro,... will be compatible in ubuntu mir?
<PreSSion> i think no
<kdub_> PreSSion, not enough info.... mir can run games
<PreSSion> yes, i know, but i want buy metro for linux
<PreSSion> but idk because i don't know if in the future i will can play in ubuntu with mir
<PreSSion> sorry for my "engrish"
<PreSSion> so, I  want to buy a game, its ok, i know now i can play in ubuntu
<PreSSion> but i don't know if in the future i will can play in the future ubuntu versions with mir
<kdub_> we should have backwards compatibility with xmir
<PreSSion> oh nice, so i will play for example metro in ubuntu phone
<PreSSion> posible right=
<PreSSion> i mean when i put the dock station with the monitor
<racarr> well most phones are arm not x86
<racarr> so no binary compatibility
<PreSSion> yes, but ubuntu said his phone will have full convergence
<PreSSion> so, ubuntu will sell some phone with x86 processor?
<PreSSion> nice, i see one of the ubuntu phone have got an intel atom processor, so that phone will be full convergence and play games as metro right?
<PreSSion> with xmir ofc
<racarr> allllmost done with my foray in to surface attributes
<racarr> I instantiated 4 common tests over all of them 1.Default value. 2. Notifies observer on change 3.Doesntnotify observer on default change
 * greyback raises an eyebrow
<racarr> err on no change
<racarr> 4. Throws on invalid value
<racarr> and only about half pass...
<racarr> and then DPI uses invalid value to mean "Query"
<racarr> greyback: ?
<greyback> racarr: just curious
<greyback> racarr: thought you were adding more surface attributes or something
<racarr> haha not yet
<greyback> racarr: would be nice if we could have a protobuf style way of defining properties on surfaces, just a text file which defines type and range could do a lot
 * greyback wakes from dream world and goes back to work
<racarr> haha
<racarr> im not sure about that far
<racarr> but ultimately I would like the attribute system to be more generic...
<racarr> i.e. cursor setting should be an attribute...
<racarr> its not clear that size isnt an attribute
<racarr> etc
<greyback> it was one reason I wanted the custom protobuf stuff, so we could rapidly iterate on surface attributes. Sadly that wasn't possible with protobuf
 * kdub_ sorta likes that idea
<kdub_>  s/sorta//
<racarr> :)
<racarr> all im doingh now...is ensuring consistent semantics on all of them
<racarr> and also making them
<racarr> sent on surface creation
<racarr> so that the client can always query them with a non blocking getter
<racarr> currently we are missing getters for 2
<racarr> and one has a blocking getter
<racarr> (dpi)
<kdub_> i've been thinking that some sort of generic/extensible compositor data system would be a win too
<racarr> mm
<kdub_> like...
<kdub_> visibility
<kdub_> or animation... the compositor should be able to tag the surfaces with data
<kdub_> and the data can be generic to libmirserver
<kdub_> and every individual compositor keeps the concept of what data they're tagging with
 * kdub_ ends musing
<racarr> Lunnch
<greyback> hey guys, anyone run xmir with nouveau recently? I'm just seeing a black screen for USC
<greyback> bregma: hey, I'm having trouble testing unity8-mir on my desktop (well having trouble with USC) - could I ask you to do a quick test of ppa:unity-team/phone-right-edge to see if unity8-mir comes up or not?
<greyback> ok so working with mterry a bit, he think it's more XMir issue than USC.
<greyback> let me recap:
<greyback> I have  ubuntu-desktop-mir  & USC installed
<greyback> When I startup, after plymouth, I just get a black screen
<greyback> I see that USC is running though. Also appears to be an X server running
<greyback> here's useful log-files http://pastebin.ubuntu.com/7762355/
<greyback> mterry sees from the USC log file that USC never sees a client session - i.e. the xmir greeter session
<greyback> running mir 0.4.0
<racarr> greyback: no ideas on my end sorry...
<racarr> you can start xmir with Xorg :1 -mi r <ANYTHING>
<racarr>  -mir
<racarr> and make sure it doesnt segfault
<racarr> even Xorg :1 -mir 0 -retro
<racarr> to get the crosshatch so there will be something
<racarr> on screen lol
<bschaefer> racarr, you don't need -mirSocket?
<racarr> oh
<racarr> maybe
<racarr> I think you can use
<racarr> MIR_SOCKET
<racarr> env
<bschaefer> oo right yeah you can
<greyback> racarr: thanks for suggestion, doing that leaves me with a hanging process http://pastebin.ubuntu.com/7762468/
<bschaefer> greyback, i was running into that earlier attempt to do xmir ... let me try on a mir server
<greyback> bschaefer: thanks :)
<bschaefer> np!
<bschaefer> greyback, X seems to start up for me
<bschaefer> greyback, this is just a mir_demo_server though, + xmir
<greyback> bschaefer: ok, I'll try that,  just to see
<bschaefer> wouldn't hurt to try that out
<greyback> huh, I get a "Connection refused" error.
<greyback> but I can run a mir demo client ok
<bschaefer> greyback, chmod 777 /tmp/mir_socket?
<bschaefer> o
<bschaefer> hmm
<bschaefer> greyback, is it trying forever to attempt to connect to the xserver?
<greyback> bschaefer: nope
<greyback> bschaefer: nope, it terminates
<bschaefer> greyback, whats your MIR_SOCKET?
<bschaefer> err well a demo works...
<greyback> http://pastebin.ubuntu.com/7762489/
<bschaefer> why does a demo work...
<greyback>  /run/mir_socket
<greyback> oh oh oh
<bschaefer> greyback, mir_demo_server_* puts the socket in /run for you?
<greyback>  /tmp/mir_socket
<bschaefer> yeah
<bschaefer> that'll be the issue :)
<greyback> Loading extension GLX
<greyback> Driver needs flags 0, incompatible with nested, deleting.
<greyback> Driver needs flags 0, incompatible with nested, deleting.
<greyback> Driver needs flags 1, incompatible with nested, deleting.
<bschaefer> thats normal, at lease i hit those
<greyback> ok
<bschaefer> then the background loads, and you get a nice x cursor
<greyback> bschaefer: kinda, I just saw the screen flash black/grey/black/grey/black and I'm back to a black screen
<bschaefer> greyback, o, that doesn't sound good. I get the flashing for a second, then it loads
<bschaefer> maybe the xorg log offers some info?
<greyback> bschaefer: nothing I can see as obvious anyway: http://pastebin.ubuntu.com/7762506/
<bschaefer> greyback, im also using intel
<bschaefer> which could explain some things...
<greyback> bschaefer: indeed
<greyback> but this did used to work
<greyback> well it's late here, think I'll give up for the night,
<bschaefer> interesting...
<greyback> bschaefer: thanks for the help so far
<bschaefer> greyback, its only mid afternoon here :)
<bschaefer> greyback, hopefully you can figure out some more info! Have a good night!
<greyback> bschaefer: ah you folk in your sunny climes
<bschaefer> haha
<greyback> o/
<racarr> RAOF: Ping?
<RAOF> racarr: Pong!
<racarr> RAOF: The import of xcursor.c has lead to mass abstention
<racarr> on cursor spike phase 6
<racarr> can you weigh in?
<racarr> I mean not urgently or anything just at some point
<RAOF> racarr: Sure, queued up.
<racarr> thanks
#ubuntu-mir 2014-07-08
<duflu> robert_ancell: Hey I'm still catching up after vacationing. What's the state of GTK-Mir?
<robert_ancell> duflu, hey
<robert_ancell> duflu, it's in the archive now. The patch is pretty basic, the main feature we're blocked on from Mir is support for multiple windows
<robert_ancell> The main blocker in Unity is allowing GTK+ applications to be launched without editing the .desktop files (probably using a hard-coded whitelist for now)
<duflu> robert_ancell: Yeah that's a Unity8 thing. I'm just wondering about the packages. So standard utopic gtk3 supports Mir?
<robert_ancell> yes
<duflu> Awesome
<duflu> Very nice
<duflu> I shall have to play
<robert_ancell> We'll just update the debian patch from GNOME Git when we change it there
<duflu> robert_ancell: Got a list of "pure" apps that work without recompiling?
<robert_ancell> duflu, I've been playing with gedit, gnome-calculator, simple-scan as test cases
<robert_ancell> Just set X-Ubuntu-Touch=true in the .desktop files to show then in Unity
<duflu> robert_ancell: Straight from utopic archive?
<robert_ancell> just with the above change
<duflu> robert_ancell: How about demo shell?
<robert_ancell> They run in there fine
<duflu> Handy
<robert_ancell> You just need to set MIR_SOCKET and permissions appropriate
<duflu> I didn't see any news about this milestone. But I also didn't read news during June
<robert_ancell> fine = as well as we currently have support for
<robert_ancell> in the public?
<duflu> Yeah
<robert_ancell> http://www.omgubuntu.co.uk/2014/06/ubuntu-devs-demo-gtk-apps-running-mir-unity-8
<robert_ancell> I haven't mentioned it's all in the archive now because it's not much use until Unity 8 shows the apps by default
<duflu> robert_ancell: What's underneath? Is it cairo on GL? cairo on software?
<robert_ancell> duflu, cairo on software
<duflu> robert_ancell: Oh so we have a cairo port
<duflu> ?
<robert_ancell> duflu, no, cairo just renders to the surface memory
<robert_ancell> it has no idea about mir
<duflu> robert_ancell: Ah, right. Cairo just uses pointers to memory
<robert_ancell> We can't have cairo on GL because that requires libGL to be linked to it and nvidia libGL would use crazy amounts of memory
<robert_ancell> cairo on GL also slower in some cases still
<duflu> robert_ancell: Well Cairo on GL is completely unnecessary for use cases where your surfaces are pre-generated
<duflu> (don't change much)
<robert_ancell> yeah
<duflu> robert_ancell: Did you encounter many gnome apps with X linkage?
<robert_ancell> not very many, and they've mostly been fixed because Wayland has the same issues
<robert_ancell> We had a couple of GTK+ plugins for Ubuntu that were assuming X, but we just disable them if not under X and they work fine
<duflu> Heh. Nothing like supporting multiple platforms to improve code quality
<robert_ancell> oh, you also have to unset DISPLAY because GDK tries the X11 backend before the Mir one
<duflu> robert_ancell: OK. I'll try to get through all the un-fun tasks today and then try it
<duflu> How exactly am I involved in 2/3rds of all code reviews already?
<duflu> I need to close my eyes more
<RAOF> duflu: What would you like as an overview for RPC work?
<duflu> RAOF: I guess just more description of what the goal/advantages are
<duflu> It's shinier and you'll lose 10kg
<duflu> (tm)
<duflu> Buy now
<RAOF> duflu: Description updated for you :)
<duflu> RAOF: Mostly curious. I have no immediate plans to do an in-depth review or block it
<RAOF> Ah.
<RAOF> Basically, it makes us more awesome.
<RAOF> Boo! I was using test_file_descriptors!
<RAOF> Although all those reasons for its removal are perfectly true. The split-rpc-transport branch has some better tests for fd passing, too.
<duflu> RAOF: "removes our current serialisation of reads/writes" ... we don't lose ordering guarantees of messages like events do we?
<RAOF> No. It means âwrites are no longer serialised with readsâ
<duflu> RAOF: Cool. And "expose manual event dispatch" ... what's that?
<RAOF> Handing a file descriptor out to GTK that, when it becomes readable, GTK can call mir_connection_dispatch() and have all the processing happen there.
<RAOF> ie: threading only when you want it..
<duflu> Sounds nice
<duflu> RAOF: I was about to try benchmarking the protocol change and see if it's different... but can't build
<duflu> Maybe later
<RAOF> duflu: Indeed. See above, âI was using test_file_descriptors!â :)
<duflu> I lacked the context back then
<duflu> Time to fix dednick's tests then
<RAOF> Eh, I can just use a different message.
<RAOF> duflu: There we go, now builds again.
<RAOF> BAH!
<RAOF> Next time we're sprinting, can we please have a session on profiling? :)
<RAOF> Anyway, EOD here.
<anpok_> mzanetti: http://paste.ubuntu.com/7764887/ please try
<mzanetti> anpok_: hey cool, thanks. will try.
<mzanetti> trying to understand the comment...
<anpok_> without that the system thinks that only the first pointer is pressed or released
<mzanetti> anpok_: confirming that your patch works. Thanks a bunch!
<anpok_> cool
<greyback> anpok_: thank you!
<dobey> AlbertA: hi!
<dobey> AlbertA: have you been able to make any progress on https://bugs.launchpad.net/ubuntu/+source/mir/+bug/1337481 ?
<ubot5> Ubuntu bug 1337481 in mir (Ubuntu) "Crash in libmirclient on app exit on phone" [Undecided,Confirmed]
<AlbertA> dobey: I was out for us holidays...but I'm back now, I will resume looking at this
<dobey> AlbertA: ok, thanks
<racarr> Morning
<alan_g> AlbertA: I think I've a working deadlock free observers implementation. I am cleaning up the code (too much implementation in the wrong place). But you're welcome to preview: lp:~alan-griffiths/mir/spike-deadlock-free-observers
<AlbertA> alan_g: cool I'll check it out
<racarr> I think we may have some memory fragmentation issues...
<racarr> My system got all swappy and slow
<racarr> so I went to a VT...
<racarr> where I realized I had been running
<racarr> mir and a demo client for like
<racarr> well since friday
<racarr> then I killed Mir and everything got better
<racarr> I wish I had thought to check some things but I had literally just gotten out of bed lol
<racarr> alan_g: on cursor-spike-phase-7 were you just talking about the whitespace? (https://code.launchpad.net/~mir-team/mir/cursor-spike-phase-7-name-some-cursors/+merge/225242)
<AlbertA> racarr: reads like a mem leak too
<alan_g> racarr: I was
<racarr> alan_g: We have a seperate C style?
<racarr> I couldn't find it in the style guide...
<alan_g> I'm talking practice not documentation
<racarr> AlbertA: Yeah...
<racarr> alan_g: ?
<racarr> a quick peek at the files shows both are
<racarr> used
<alan_g> Then never mind
<racarr> :)
<racarr> the wording of your comment made me paranoid that there was some strange different meaning of char const* const in C that I had forgotten
<racarr> lol
<kdub_> racarr, while we're on the topic of spike-7
<kdub_> I guess, once we support the custom uploading can we remove the names?
<greyback> racarr: hey you reviewed https://code.launchpad.net/~unity-team/platform-api/devel-for-qtmircompositor/+merge/225320 - you had 2 main issues. One was that a comment (about the event struct conversion) was removed, which I put back. What was the other? I can't find it in my logs now
<racarr> kdub_: I don't think so...where would the client get the system cursor images then?
<racarr> kdub_: I mean we could replicate the system under X where you use an external library and a strange undocumented series of names
<racarr> to load ARGB data for you
<kdub_> well, I was going to say the external library, without the undocumented/strange stuff
<racarr> We would have to make this library though, because xcursor is strange
<racarr> so why not have it in mir?
<kdub_> like, it seems strange to me that mir just helps with the theming for cursors
<kdub_> maybe I'm just asking whats the plan for how much theming mir will be responsible for
<kdub_> like the same issue exists for window borders
<kdub_> and stuff like that
<racarr> mm
<kdub_> it seems (since mir is a library) that those concerns are different enough that a theming sort of helper library would be justified
<racarr> the cursor theme is a little different
<kdub_> like it could even be libmirtheming.so and live in tree
<racarr> unlike the initial proposals...you see how its landed
<kdub_> (talking past the immediate branch here)
<racarr> we dont actually expose any theming
<racarr> its just
<racarr> a set of cursors with different meanings
<racarr> and then we have an intree implementation that loads the default xcursor theme because thats something lots of shells may be interested in doing
<racarr> but the actual themeing, i.e. choosing a theme or something is basically the shells responsibility
<racarr> I mean...I guess if we did end up with more themeing stuff espescially borders, etc (can't imagine all the way atm)
<racarr> libmirtheming would make sense
<racarr> I think of the cursor names as more like the surface state enum though
<racarr> if that makes any sense...
<greyback> +1 for separate library from me. I don't see why core Mir should do anything more than have a method which lets a shell set an image as the cursor. Then the shell can use this helper library to get that image if it wants
<racarr> well 1 because USC
<racarr> should probably set the cursor in most configurations ...
<racarr> I mean I guess USC could have the XCursor loader
<greyback> not everyone will want to use USC
<racarr> this isnt what the cursor names solve though...its just
<racarr> right so if either USC or unity8 may need to load the cursors
<racarr> the code should be in mir -.-
<racarr> the names is just though
<kdub_> right, I guess I'm talking at the next-step level
<racarr> how does the client request
<racarr> a "busy" (for example)
<racarr> cursor
<kdub_> the "spike-7" branch is okay, but I think that the next step should drive at chasing the specific cursor images out of the mir core
<racarr> meh, maybe
<racarr> I mean I thought about it right because
<racarr> its obviously ugly
<racarr> and obviously incorrect an always will be
<racarr> i.e. there is no "This is the correct list of cursor names"
<kdub_> like, the interested client can link to libmirtheming.so and use that, or if they are very interested in developing their own theme system, they can link to something else
<racarr> this doesnt prevent that though
<racarr> you could replace the_cursor_images with something
<racarr> that themes as you want
<racarr> but you can still interpret mir_cursor_default
<racarr> as the default cursor from your theme
<kdub_> sure, it doesn't prevent it, but it does make mir provide more
<racarr> yes
<racarr> I guess I just figured...I mean some part of ubuntu has to provide it
<kdub_> right, and by 'mir' i really mean 'core mir'
<racarr> maybe...
<kdub_> sure, I agree... I just think its something that core mir shouldn't have (it can be in-tree under a different helpful theming stuff)
<racarr> where to draw the line?
<kdub_> like "i want to set a cursor image" or "this is my default image" seems generic
<racarr> I mean, a shell is free to ignore surface states and implement its own system.
<racarr> so should there be libmirshellstates
<kdub_> I think there should be some sort of shell scratchpad, but I think that's a bit different topic
<racarr> lol
<kdub_> :D
<racarr> im not really against some sort of mirtheming seperate thing I guess...just as far as I imagine it so far I think
<racarr> I would rather just have it in mir (because its pretty harmless...) rather than have
<racarr> a new thing with a name that has to be remembered and thought about
<racarr> lol
<racarr> greyback: Sorry um the
<racarr> other thing was
<racarr> greyback: l427
<racarr> is a strange but I guess justified choice (danmdrader explained)
<racarr> but it should maybe come with a comment about how that whole block only makes sense for tablet/phone (i.e. using maximized as restored)
<kdub_> racarr, yeah, but really, people don't want what's in mir when it gets too specific
<kdub_> like, 'here's a compositor for you, isn't it nice?' gets met with 'no, sorry, want to do my own thing'
<kdub_> just seems 'cursor images' is something like that
<greyback> racarr: it's an initial state that's overwritten before used? I guess it could be U_UNKNOWN_STATE
<racarr> kdub_: Mmm...yeah its possible...
<racarr> ill continue thinking
<racarr> greyback: Yeah I think so...
<racarr> greyback: ERr...unless windows
<racarr> start on maximized
<racarr> err
<racarr> as minimized
<racarr> before they are shown
<racarr> and line 445
<racarr> depends on it
 * kdub_ just keeps thinking of the decorations/compiz situation :P
<racarr> I feel like its fine with a comment that maximized is only the default for tablet or phones or something
<greyback> racarr: you're right. Code bit clunky. Comment will do
<racarr> :) thanks
<racarr> besides that
<racarr> it all looked good and left a comment on launchpad as thus
<racarr> gosh I am so happy today
<racarr> I bought a memory foam pillow
<racarr> and slept the best ive slept in like a month
<racarr> been having growing insomnia again
<greyback> racarr: ok comment pushed
<greyback> glad you're sleeping better
<greyback> insomnia can be horrible, I suffered it a few years ago
<racarr> Mm...I had it really bad as a kid and finally got it under control a few years ago so it was frustrating to see it return
<racarr> I think in this case it was just back stuff though
<racarr> and a better pillow will help a lot...maybe a new mattress
<racarr> ...better office chair -.-
<greyback> racarr: if you're happy, please mark approved
<racarr> greyback: Oh hmm one more thing
<greyback> racarr: omg an iWatch!
<racarr> not sure of the deal with platform-api but
<racarr> iWatch?
<racarr> does it require
<racarr> an soname bump or
<racarr> some version must have to change right
<greyback> sorry, bad apple "one more thing" jke
<racarr> oh lol
<racarr> just because its API change
<racarr> ABI
<racarr> change
<greyback> soname should bump yeah, good catch. Should match package version really
<racarr> I think THEN we are good though
<AlbertA> uhhh...what happened to mir trunk?
<AlbertA> it's gone...
<AlbertA> camako: ^
<racarr> lol
<AlbertA> kgunn: ^
<kgunn> oh no
<alf_> mterry_: https://code.launchpad.net/~afrantzis/unity-system-compositor/grand-refactoring-first-steps/+merge/226000
<kgunn> AlbertA: seems its still there....maybe series funny biz
<kgunn> but this is there
<kgunn> https://code.launchpad.net/~mir-team/mir/utopic
<greyback> racarr: pushed
<AlbertA> ok, I guess we had an alias before? lp:mir => lp:mir/utopic ?
<alf_> mterry_: please check whether the session switching tests I introduced match the expectations we have for USC
<racarr> alf_: Sounds grand
<kgunn> AlbertA: yeah...we need to link lp:mir-team/mir/utopic to lp:mir
<kgunn> weird...
<racarr> ;)
<racarr> greyback: Looks good...approve on launchpad
<greyback> racarr: thank you
<AlbertA> alf_: yey tests in USC !
<racarr> brb more breakfast
<alf_> AlbertA: only unit tests for one component (although central), but it's a start
<alf_> AlbertA: do you get emails about USC MPs?
 * alf_ wonders if I should add mir-team to the reviewers
<AlbertA> alf_: nope
<AlbertA> alan_g: ok, so if I understand correctly in the deadlock free branch, observers are now a linked list of ListItems and a custom lock that allows multiple concurrent readers but only one writer at any one time...
<AlbertA> alan_g: and allows a reader to become a writer if it's in the same thread context
<alan_g> AlbertA: that's the idea
<alan_g> Also the linked list is a "grow only" structure (nodes are only deleted on destruction)
<AlbertA> alan_g: ok, to avoid allocation overhead?
<alan_g> AlbertA: to avoid the "current" node being removed or repurposed
<AlbertA> alan_g: ahh
<alan_g> AlbertA: hang on - I'm pushing a cleaner version of the code.
<racarr> nice technique...:)
<alan_g> AlbertA: I'm at EOD - if you want to grab the code and run with it feel free. If you don't have time I'll get back to it tomorrow.
<AlbertA> alan_g: sure
<camako> kgunn, AlbertA, yea the alias is not right
<camako> any more
<camako> kgunn, we (duflu/Alan_g/others) want lp:mir to point to devel
<kgunn> camako: ack...i won't touch a thing....
<camako> kgunn, and want the distro to pull from lp:~mir-team/mir/utopic
<camako> kgunn, dunno if this is possible
<kgunn> camako: right...i was going to say, you might need to talk to "someone"....that used to be didrocks...but he's since moved away from that job
<kgunn> sil2100 would be the next person i would speak to...
<kgunn> but i thikn their machinary needs lp:mir to be trunk...(this is an ancient problem)
 * kgunn realizes we're overdue for our quarterly "can't we have trunk not be distro target" discussion
<kgunn> discussion...or inquistition
<camako> kgunn, we should let duflu loose on 'em
<kgunn> exactly
<camako> kgunn, currently lp:mir is an alias to the "development focus" branch
<camako> which is now mir/0.5
<camako> but it has no corresponding branch
<camako> so it's difficult to set up the branches in a way that makes sense
<camako> for our development
<kgunn> yeah
<kgunn> which is why it was the way it was
 * camako thinks we'll deal with it in the next release
<bregma> is there now power management in Mir 0.4?
<racarr> Lunnch
<kdub_> bregma, not in mir, although iirc, that has shifted to USC recently
<kdub_> AlbertA can probably give better dates around when that happened
<bregma> hmm, well, it's crept in somewhere and requires I reboot the desktop every 5 minutes because there's no wake support in the Unity 8 shell.
<bschaefer> greyback, were you able to get xmir working?
<greyback> bschaefer: nope. I gave up and logged a bug https://bugs.launchpad.net/mir/+bug/1339001
<ubot5> Ubuntu bug 1339001 in Mir "XMir not working with nouveau" [Undecided,New]
<bschaefer> greyback, good idea :)
<greyback> bschaefer: things work on my intel machine, so guess it's nouveau issue
<bregma> ahh, the power button works like on the phone, a little unexpected on a desktop system
<bschaefer> greyback, yeah, sounds like a nouveau issue then ... strange has to be have been a recent push
<bschaefer> bregma, like, holding the button to turn it on?
<bregma> bschaefer, yes, just like the phone
<bregma> and, the power-down timeout is seems like about 30 seconds
<bregma> also a little unexpected on a desktop
<bschaefer> o wow, thats a long time to hold it
<bschaefer> yeah
<bschaefer> (at lease on a desktop)
<bregma> no, you just tap the power button, the screen shuts off with no activity in 30 seconds
<bregma> also, the second time you press the power button it just shuts down the whole machine â¹
 * bschaefer does not know how phones work
<bschaefer> my phone i have to hold the power button for ~30 seconds to shut it down
<bregma> bschaefer, not shut down, wake up
<bschaefer> otherwise it locks the screen
<bschaefer> i see yeah
<AlbertA> bregma: I updated USC to disable power key and inactivity handling with xmir
<AlbertA> bregma: bu tthis is with unity 8 desktop? So it still uses usc wrapper to start up unity-system-compositor?
<bregma> what is usc wrapper?
<AlbertA> in touch
<AlbertA> usc-wrapper is the one that lightdm will call to startup unity-system-compositor
<AlbertA> for xmir, there's another wrapper which lives in tree in unity-system-compositor
<bregma> that's new to me
<AlbertA> I modified that last thursday to avoid the power key/inactivity stuff for xmir
<bregma> what's with the sudden support for xmir?  who uses it?
<AlbertA> bregma: so do you know how usc get's started for unity8 desktop?
<bregma> lightdm starts u-s-c:  if there have been mods to have it do something special for the phone they didn't get publicized on the channels i follow
<AlbertA> bregma: directly? no wrapper script or anything?
<bregma> that's the way it used to do it
<AlbertA> this is what will be used for ubuntu-desktop-mir:
<AlbertA> http://bazaar.launchpad.net/~unity-system-compositor-team/unity-system-compositor/trunk/view/head:/debian/unity-system-compositor.sleep
<AlbertA> http://bazaar.launchpad.net/~unity-system-compositor-team/unity-system-compositor/trunk/view/head:/debian/10-unity-system-compositor.conf
<bregma> what is ubuntu-desktop-mir and how does it relate to the stuff currently in use in the Unity 8 desktop?
<AlbertA> bregma: I don't know how it relates, I just know we use that for xmir
<AlbertA> i.e. you install ubuntu-desktop-mir and you get xmir with unity7
<bregma> what is xmir used for?
<racarr> adventure
<bregma> we do not support Unity 7 running that way
<racarr> its "available for testing"
<bregma> all I know is if you installed ubuntu-desktop-mir it would break OpenGL and my team would have to spend time supported people with broken systems
<AlbertA> bregma: ok let's get back to the core issue
<AlbertA> bregma: Is it unity8-desktop-session that has the lightdm confs?
<bregma> AlbertA, yes indeed
<AlbertA> bregma: I don't see unity-system-compositor there though...
<bregma> AlbertA, no, because lightdm knows how to configure it automatically ... although if I can add a wrapper, I'd be happy
<AlbertA> bregma: oh I see...well all we need is to set the cmd line arg: --disable-inactivity-policy=true
<bregma> evidently the ability has been there for a while, now I look through the code
<bregma> I shall play with this until usability is restored
<AlbertA> bregma: well actually...usc may need more changes,
<AlbertA> bregma: we need different policies I guess
<AlbertA> bregma: because I assume you still need inactivity to take effect
<AlbertA> bregma: but wakeups should occur with mouse or keyboard events, not power key
<bregma> AlbertA, that will require support from the Shell, and it's not on the near-term radar
<AlbertA> bregma: ok
<AlbertA> bregma: well ping me if I can help further...
<bregma> sure thing
<racarr> the cursor renderable needs to support padding the image if the cursor buffer is larger than the image
<racarr> i.e. on some gbm where its always 64x64
<racarr> like mgm::Cursor does now
<racarr> the thing is...it should also support multiple pixel formats now.
<racarr> I guess I am just wondering if its appropriate to link in pixman
<kdub_> groan
<kdub_> :)
<kdub_> nothing against pixman :)
<kdub_> but once we do that... why not libjpeg and  and libpng
<anpok> hm recently saw a patch that allows fantastic 128x128 for kaveri gpus..
<kdub_> I probably wouldn't mind libmirhelpfultheming.so linking to things like that though
<racarr> lol
<racarr> anpok: Yes hence most. the thing is just that the cursor renderable buffer may not be the same size
<racarr> as the cursor
<racarr> nvm im dumb. for some reason I thought I was going to have to specialize the padding code for different
<racarr> pixel formats
<racarr> but
<racarr> transparent
<racarr> is the same everywhere...
<racarr> *facepalm*
#ubuntu-mir 2014-07-09
<duflu> RAOF: You didn't seem excited when I pointed out your branch improved performance... ?
<RAOF> duflu: It's neat, but it's not really the point :)
<duflu> Nice freebie
<duflu> And quite unexpected that we can reduce round trip time at all, especially without trying
<RAOF> Well, it can help when you don't have to do quite so much queuing on the main loop.
 * duflu isn't familiar with any of that newfangled main loop stuff
<duflu> Probably just as well or else I might have an opinion
<duflu> But there are other problems to be worked on...
<RAOF> Not newfangled :)
<RAOF> Before the rework all IO was being deferred to the IO mainloop, afterwards you just write().
<duflu> RAOF: Care to reconsider? https://code.launchpad.net/~vanvugt/mir/fix-1338902/+merge/225929
<RAOF> duflu: You don't seem to have fixed the race?
<duflu> RAOF: What race?
<RAOF> Between if(locked) and locked = false.
<RAOF> Unless the event handler cannot be called from multiple threads, in which case you've got a spurious std::atomic<bool> :)
<duflu> RAOF: Yes the latter
<RAOF> Ah. Then drop the std::atomic and I'll reconsider :)
<duflu> RAOF: The whole only works from one particular thread thing is fragile, but I wasn't aiming to fix everything about that code
<duflu> RAOF: So is anyone else building on utopic or am I just unlucky to have that test failing constantly?
<RAOF> Then why not replace with if(locked.compare_exchange_strong(true, false) ?
<RAOF> I build on Utopic; you're just unlucky to have that test reproducibly fail.
<RAOF> Or lucky, depending on your perspective :)
<duflu> I hate compare/exchange ops. They always mess with my head and require surprisingly careful thought every time I see one
<duflu> But they're often necessary
<duflu> RAOF: Done
<RAOF> Is it really pending Nick's approval?L
<duflu> RAOF: Not really. That was just if he's curious (since I think he's the only one the test is meaningful to)
<RAOF> In which case... top-approved.
<duflu> Whee... and then I won't have every branch failing the same test
<duflu> sil2100: Hello?
<duflu> anpok: How goes life with Mesa/GBM?
<sil2100> duflu: morning
<duflu> sil2100: Morning. Do you have any thoughts on this? https://code.launchpad.net/~vanvugt/mir/fix-changelog-0.4.0/+merge/225608
<sil2100> duflu: let me take a look, hmm
<anpok> duflu: moving to the kernel now
<duflu> anpok: Umm, good (?)
<duflu> sil2100: Thanks
<anpok> duflu: different source code quality  :)
<duflu> anpok: What in the kernel needs fixing?
<anpok> page flipping
<duflu> anpok: Oh, vesa doesn't do it?
<duflu> Or is it some hypervisor driver?
<anpok> hm qxl needs it - I think most if not all of the others provide it
<anpok> e.g. the displaylink driver recently received support for it
<duflu> Oh, right. Pity we can't say the kernel fixes from last year provide minimum Mir support :(
<anpok> the qxl-spice protocol does not seem to provide something like swap command or plane configuration command
<anpok> so I will first investigate what it would take to make a clean solution before I settle with - just copy it.
<duflu> anpok: If there's no display hardware to accelerate the scanout offset setting then there's no performance benefit to implementing it in the kernel over userspace. Userspace would at least provide better kernel compatibility... (?)
<anpok> but .. i mean it could be done .. if the host system allocates the buffers we could do bypass all steps to the host
<duflu> anpok: Oh, yes.
<anpok> duflu: well the user space fallback would have to go into mesa eglSwapBuffers and into mir and for mir we would need another mesa api to mmap the buffer
<anpok> which is not complex either
<sil2100> duflu: yw!
<duflu> greyback: I'm doubting my sanity now. I think triple buffers has high latency, but actually with the current protocol design, double may not be any better
<duflu> I wonder what I was thinking back in May !?
<greyback> duflu: why would double not be better?
<duflu> greyback: Because the swapping protocol still requires a round trip, either way
<duflu> We can eliminate that round trip delay with a protocol change, but only triple-buffers would benefit
<greyback> duflu: I can't remember the details of our discussion to make a good argument :(
<duflu> greyback: Me too. It's present me vs past-me
<greyback> older and wiser you
<duflu> greyback: I sense more grey hair coming on
<ogra_> duflu, the traceback in bug 1339610 is from the smoke tests (that crash causes 34 failures in ui-toolkit tests) ... since it has to install the test suites it cant relly work without PPAs ...
<ubot5> bug 1339610 in Mir "unity8 crashed with SIGSEGV in mir::frontend::ClientBufferTracker::client_has()" [Undecided,Incomplete] https://launchpad.net/bugs/1339610
<duflu> ogra_: OK, well I tried looking into the offending function. It's trivial and has no reason to crash without further details :(
<ogra_> :8
<ogra_> :( even
<duflu> And then it was dinner time
<desrt> hihi
<desrt> just tried to build the 0.4.0 release of mir -- it fixed some issues... but there is still this one hitting me: https://bugs.launchpad.net/mir/+bug/1323031
<ubot5> Ubuntu bug 1323031 in Mir "google::ShutDownCommandLineFlags not available on Fedora" [Medium,Triaged]
<desrt> we already had a patch for it in jhbuild, so i'll just roll it over.... this is really just a 'reminder' :)
<davmor2> kgunn: so tomorrow AM I'm going to start testing Qtcomp on mako manta and flo.  Is there anything other than testing that nothing breaks or is more broken that at present that I need to do?
<kgunn> davmor2: it should be on par except for the one sidestage exception i describe in the wiki
<davmor2> kgunn: no worries then
<racarr_> I hope everyone is enjoying the cursor color change
<racarr_> :p
<racarr_> what is round trip time to a modern GPU
<kdub_> like, round trip over ipc?
<racarr_> no I mean like just from CPU to GPU
<racarr_> not content flush or anything
<racarr_> just like hey ping GPU
<kdub_> like, command submission to some sort of end point?
<racarr_> yeah or something like that.
<racarr_> It doesn't really matter lol, im just curious all of a sudden.
<kdub_> like, writing to a register is fast of course, the time comes from processing/pushing pixels
<racarr_> Mm but I mean writing to a register
<racarr_> is slower than writing to a register on the CPU
<racarr_> so by how much?
<racarr_> I guess it has to be slower than writing to system memory
<racarr_> which basically answers my question "its a lot slower" :p
<kdub_> racarr_, yeah, i'd guess so, but in the same ballpark
<racarr_> mm
<racarr_> ah the joy of arguing over totally speculative performance points in small text boxes in the web browser.
<racarr_> (touchspot-visualizer :p)
<kdub_> yeah... well you have a +1 from me :D
<racarr_> :)
<racarr_> cursor as a renderable will be up soon and make it more clear
<racarr_> just getting the mesa hardware cursor to work again
<bschaefer> racarr_, the mouse looks to real now :)
<bschaefer> cursor*
<racarr_> lol
<racarr_> bschaefer: p.s. you can implement cursor support in SDL if you want
<bschaefer> racarr_, yay!
<racarr_> bschaefer: In cursor-spike-phase-7 (up for review) there are mir_curosr* names for the different cursors.
<bschaefer> racarr_, sweet, that'll be fun to get in :)
<racarr_> so I guess not quite yet lol
<racarr_> yes its surprisingly satisfying to watch the cursor change
<bschaefer> but i can at lease see the api haha
<racarr_> yeah just mir_surface_configure_cursor
<bschaefer> racarr_, nice! also was hotspot implemented?
 * bschaefer remembers you mentioning it wasn't before
<racarr_> bschaefer: indeed
<racarr_> it is implemented that is
<bschaefer> implemented is always nice, didn't see it mentioned in the client api
<racarr_> oh well there is no client side cursor upload yet just
<racarr_> the system cursor theme
<racarr_> so the hotspot is contained
<racarr_> in the cursor theme
<bschaefer> hopefully its just the case of "need to expose it to the client api"
<bschaefer> oo
<bschaefer> i see
<bschaefer> racarr_, o, so atm its just the system themes makes much more sense :)
 * bschaefer was thinking to far ahead :)
 * bschaefer actually looked at the MP
<racarr_> I guess the two remaining features are animted cursors (not actually particularly difficult) and client cursor upload
<bschaefer> yup, and i think SDL2 only really uses client cursor upload. I didn't even think about animated cursors
<bschaefer> racarr_, at lease, thats from the point of view of my needs haha
<bschaefer> racarr_, (besides warp cursor, but thats a different story)
<racarr_> mm
<racarr_> ok ill add client side cursor uploads soon its really quite straight forward.
<bschaefer> racarr_, no rush :), and thanks! (Cursors!!)
<Saviq> AlbertA, kgunn, manta seems to be indeed more vulnerable, I just flashed it and left for an hour maybe â locked up
<kgunn> Saviq: ack...btw, is it only on lock screen? or also on edge-tutorial ?
<Saviq> kgunn, I only saw it on lock screen, rsalveti reported after phone hang-up though
<kgunn> Saviq: does anyone know which image it actually showed up in ?
<kgunn> e.g. which packages changed?
<Saviq> kgunn, 114 seems to be the first people remember this
<Saviq> kgunn, http://people.canonical.com/~ogra/touch-image-stats/114.changes
<Saviq> doesn't really mean it wasn't there before
 * Saviq flashes 110 on manta
<kgunn> lol... Saviq suspects mir040
<Saviq> kgunn, maybe I can rule it out...
<kgunn> yep
<Saviq> actually 109 probably makes more sense
<AlbertA> huh...I got a manta here that I had not woken up, #112
<AlbertA> it seems unity8 is locked up...
<AlbertA> so to replicate just let the device sleep for a while?
<kgunn> Saviq: just curious...for stuff like qtdeclarative...do the core devs still do the build of the src against latest image ?
<kgunn> e.g. no chance of someone sneaking in a bin against an "unknown" environ ?
<Saviq> kgunn, there's nothing built outside of PPAs/distro
<Saviq> kgunn, even if someone uploads directly, without train, stuff gets rebuilt on buildd
<Saviq> AlbertA, yeah, looks like it
<Saviq> AlbertA, manta seems especially vulnerable
<AlbertA> Saviq: does it happen pretty fast in manta?
<kgunn> AlbertA: noteworthy that the u-s-c bug fix for xmir went in on http://people.canonical.com/~ogra/touch-image-stats/113.changes
<AlbertA> well I'm suspecting a deadlock in the timeout frame dropping policy...
<AlbertA> because all these 3 stack traces look similar
<AlbertA> where a compositor release, triggers an update in the policy at the same time a timeout happened
<Saviq> AlbertA, I couldn't really say, but between when I flashed and had it locked it must've been under an hour
<AlbertA> oh yeah, deadlock...
<AlbertA> essentially, the compositor thread owns the buffer_queue mutex as it's releasing...
<AlbertA> but it's trying to update the timeout framedropping policy, so it waits to own the internal alarm mutex
<AlbertA> meanwhile a timeout has occurred, so the timedropping policy inthis thread owns the internal alarm mutex
<AlbertA> but its waiting on the buffer queue mutex...so deadlock...
<Saviq> AlbertA, awesome
<AlbertA> kgunn: should I target a fix against devel or mir/0.4?
<kgunn> AlbertA: you can dual target i suppose
<kgunn> that might be simplest
<AlbertA> ok
<kgunn> AlbertA: might wanna propose as mir-team to leave on Cemil's desk overnight
<AlbertA> kgunn: ok, still thinking of how to fix...:)
<kgunn> ack
#ubuntu-mir 2014-07-10
<RAOF> Bah! Why does my USB controller suddenly drop dead?
<RAOF> I _like_ my external keyboard, damnit!
<duflu> RAOF: Snap. Me too, on random systems
<anpok_> it workss
<anpok_> now i need to add mir platform support.. hmm
<duflu> Hmm why is bzr push suddenly so slow this week?
<duflu> My upload speed is unchanged
<duflu> camako, alan_g: Priority regression fix needs review: https://code.launchpad.net/~vanvugt/mir/fix-1339700-alarm/+merge/226252
<alan_g> duflu: looking...
<duflu> I think the safety of dropping the lock early is easy to verify on inspection. Then you just have to be convinced that it's the same issue as shown in the stack traces
<duflu> Agh, stupid slow uploads. What's wrong with the pipe?
<duflu> Hmm, actually it looks like it's uploading at theoretically max speed. So bzr has somehow been slowed down by the complexity of our branches?..
<alan_g> duflu: I'm not convinced by "*easy* to verify on inspection" - if the cb be can removed between the unlock and invoking the copy then the called back code may touch objects that no longer exist.
<duflu> alan_g: You're assuming the callback touches its own alarm object. That's actually quite hard to do, and even if you did, you would be re-entering the alarm's mutex (which is not recursive), resulting in a crash/deadlock
<duflu> Actually C++ says "undefined" behaviour, which is sometimes crash or deadlock
<duflu> alan_g: Or rather, the callback is only made within the lifetime of the code that owns the alarm. So you do have confidence in when/how the callback will be made
<alan_g> duflu: I'm saying that it is isn't "easy to verify" that nothing (on any thread) can decide to cancel the alarm and destroy the handler between the unlock and the invoke.
<alan_g> It may well be *possible* to verify
<alan_g> Am looking...
<duflu> alan_g: OK, I'm not sure now either. The right answer is for objects to never have internal locking except to protect threads they themselves have created. But that's a larger architectural change
<alf_> camako: alan_g: duflu: top-approving https://code.launchpad.net/~thomas-voss/mir/explicit-gcc-version/+merge/226140 unless someone objects soon
<duflu> alf_: *shrug*
<alan_g> alf_: no objection
<alf_> @duflu's "Hmm why is bzr push suddenly so slow this week?" -> something changed and bzr is uploading an awful lot even for small branches: just uploaded 40M for a 6K diff :/
<alan_g> alf_: I *think* it is because we lost lp:mir and the uploads are diffs against that
<alf_> alan_g: hmm, so lp is not using stacked branches for our new branches...
<alan_g> alf_: it is a guess based on the delays seen when we diverge from lp:mir not on research into how bzr works
<alan_g> alf_: camako as duflu has gone can we have another opinion on https://code.launchpad.net/~mir-team/mir/fix-1339700/+merge/226233 with a view to top-approving?
<camako> alan_g, sure...
<alf_> camako: ^^ and we also need to fix the bzr upload issue... we can't be pushing 40M for each new branch
<camako> alf_, okay
<greyback> I think you can use bzr push --stacked-on=lp:something for now. But not having lp:mir is extremely confusing!
<alan_g> greyback: thanks, that makes sense.
<anpok_> alan_g, alf, camako: I have a third solution
<anpok_> but not ready yet
<alan_g> anpok_: solution to which discussion?
<anpok_> deadlock
<alan_g> anpok_: lp:1339700?
<anpok_> yes
<anpok_> calling timer callback without a lock, and ensuring sequential ordering of timer callback execution and eventual canceling/reconfiguration
<anpok_> havent worked on it since I do the qxl mesa/kernel stuff
<anpok_> https://code.launchpad.net/~andreas-pokorny/mir/synchronous-cancel-of-alarms/+merge/224530
<anpok_> just updated it
<alf_> anpok_: Can't we make main_loop_thread atomic<> instead of locking it? As it is, the code may deadlock if e.g. a synchronous action from execute() calls AsioMainLoop::stop()
<anpok_> hmmm
<anpok_> hm
<anpok_> ok then i would reset the main_loop_thread before stopping the io service
<anpok_> to ensure that nobody queues in further handlers/actions that might not get executed
<anpok_> the lock is more about the stop() than about the reset
<alf_> anpok_: so, to make sure I understand correctly:
<alf_> anpok_: 150+ if (data->state.compare_exchange_strong(expected_state, mir::time::Alarm::triggered)) , is what guards us from an alarm event that was enqueued asynchronously after cancel() was called?
<alf_> anpok_: e.g. we call cancel and enqueue a cancellation handler, but meanwhile the alarm gets triggered and enqueues an alarm handler
<anpok_> the cancel op is first
<anpok_> it will remove the strong ref from the timer object
<anpok_> when the alarm handler is called it will fail in getting a shared_ptr
<davmor2> Hey guys I'm ready to start testing silo 006 the qt comp only I've been informed that the lastest version didn't build is there anyone that can double check that before I waste my time trying to install and test it please?
<alan_g> greyback: were you dealing with the silo? ^
<davmor2> greyback: looking at it, it might of built for arm and just failed else where but I just wanted to be sure
<anpok_> alf_: i would love to get rid of the thread id mutex - if we could gurantee that any outstanding operation is executed during stop - and an attempt to restart during the stop procedure is avoided (<-why did I think this is necessary?)
<anpok_> during or before stop completes
<alf_> anpok_: "the cancel op is first, it will remove the strong ref from the timer object", where does it do that?
<anpok_> oh you are right
<anpok_> I have seen too many versions of that part
<anpok_> it just changes the state
<anpok_> so cas will fail and no handler will be executed
<greyback> davmor2: silo is rebuilding, a recent unity8 release means silo6 is a little out of date
<davmor2> greyback: awesome thanks,  Didn't want to waste half a day to realise I hadn't actually tested what needed testing :)
<greyback> davmor2: I'd love your testing feedback at some stage however. Can I ping you when silo ready?
<davmor2> greyback: yeap sure I'm setup today for just testing this silo on manta mako and flo
<greyback> davmor2: magic. Silo6 does work currently, but you have to carefully specify packages with this http://pastebin.ubuntu.com/7774465/ - you might be better off waiting for the rebuild tho
<davmor2> greyback: I can wait there is other stuff I need to get on with too :)
<greyback> davmor2: ack
<davmor2> greyback: hmm silobot tells me that the packages are built now ;)
<greyback> davmor2: huh, it didn't ping me
<davmor2> greyback: see #ubuntu-ci-eng
 * greyback doubts his irc client now
<greyback> aha there we are
<davmor2> haha
<alf_> greyback: Trying out QtComp on N4, works well. Some notes that I am not sure if they are problems:
<greyback> alf_: great, please share!
<alf_> greyback: The icons in the launcher seem strange, at least slightly different from what I remember with previous unity8. e.g. some icons have the bottom left corner cut off
<alf_> greyback: launcher => the bar you swipe in from the left
<greyback> mzanetti: is that the new design^^
<mzanetti> greyback: alf_: yes it is. It indicates which icons are pinned to the launcher
<mzanetti> recent (unpinned) onces won't have the corner clipped
<mzanetti> and yes, the whole launcher got a new design :)
<alf_> greyback: mzanetti: also the ubuntu/home icon is now a full rectangle?
<greyback> mzanetti: how are you doing that corner clip?
<mzanetti> yeah... I'm not yet used to that either...
<mzanetti> greyback: shadereffect
<greyback> mzanetti: ok
<alf_> greyback: I also only see the apps scope, is this normal, or have I messed up something?
<mzanetti> alf_: are you?
<mzanetti> alf_: note, scopes have a new header too :)
<mzanetti> alf_: tried swiping left/right?
<alf_> mzanetti: nothing happens
<mzanetti> hmm... ok... *should* work
<greyback> actually same here
<alf_> mzanetti: I see the new header with search icon on the right
<mzanetti> is this QtComp?
<greyback> yeah
<mzanetti> it was working here before when I tried the merge. lemme check
<alf_> greyback: mzanetti: not related to qtcomp, more of a design issue, but I find the various different ways that you go "back" distracting
<alf_> greyback: mzanetti: not much consistency there
<mzanetti> alf_: hmm... example?
<mzanetti> alf_: afaik we only have the one back button at the upper left corner (except for apps that haven't been updated yet)
<mzanetti> which shouldn't be many any more
<mzanetti> gallery app is one of them
<alf_> mzanetti: right, that's the one I was thinking of
<mzanetti> alf_: yeah... that's gallery app being outdated
<alf_> mzanetti: but on a related note, the upper left corner is not very easy to reach if you are holding the phone with one hand (the right)
<mzanetti> alf_: I agree. there has been a discussion on the ubuntu-phone mailing list
<mzanetti> alf_: seems that's the only place where users don't fail to find it
<mzanetti> don't ask me why
<mzanetti> alf_: ogra_ even dropped his phone multiple times because of this :D
<alf_> mzanetti: since I am play testing... have there been any discussions to reduce applications start up times, perhaps preload some common ones (e.g. waiting 2-3 seconds for the dialer to come up is painful)
<ogra_> mzanetti, yeah !
<mzanetti> alf_: there has been a discussion although I don't know the state/outcome.
<ogra_> there wasnt any
<ogra_> design said "this is how we designed it" ... no further discussion happened
<mzanetti> right, for the back button. yep, that's what it was mostly
<mzanetti> for the preloading though I think architects had some thoughts about it
<anpok_> well, we should look what takes so much time - i.e. it could be something trivial like shader compilation..
<mzanetti> lots of it is QML compilation
<mzanetti> there have been thoughts about precompiling QML
<AlbertA> alf_: so there is one scenario in TimeoutFrameDroppingPolicy
<AlbertA> alf_: where an alarm can be rescheduled after it was cancelled
<AlbertA> alf_: if Thread A calling swap_not_blocking is pre-empted right after if (pending_swaps++ == 0)
<AlbertA> alf_: and Thread B calls swap_unblocked, cancels alarm and decrements pending_swaps
<AlbertA> then Thread A will reschedule the timer, which can potentially lead to the assert(pending_swaps.load() > 0); triggering
<AlbertA> but I think converting that assert into just a return should cover that...
<dobey> AlbertA: for #1337481 i wonder if just doing a no-change rebuild in the archive might fix it? (though of coruse it won't prevent it from possibly recurring in the future)
<AlbertA> dobey: it's something I wanted to try for sure...we are about to spin 0.4.1 though...so perhaps that would cover it
<AlbertA> dobey: I hate these heisenbugs...
<davmor2> kgunn: osk is playing up in Qtcomp trying to put my finger on why also I only see the apps scope I don't seem to be able to change
<dobey> AlbertA: yeah, i know what you mean
<greyback> davmor2: apps scope bug is our bug, we've fix on the way
<davmor2> greyback: right nice
<greyback> davmor2: osk bug?
<davmor2> greyback: what I've discovered is that osk will randomly stops working in some apps.  Like messaging app I now can't get it to raise, The text box goes white but the cursor doesn't appear in the test field
<kgunn> davmor2: might want to make doubly sure its qtcomp...it was acting up like hell on N7 for me in the virgin image (y'day)
<kgunn> messaging and phone app very very wonky specifically on n7 virgin image also
<davmor2> kgunn: okay so everything I can test seems to be working,  Only the keyboard issue that I've hit.  I'll start digging into that and see if I can get anything useful from logs etc.  I would need the fix for scopes to land to actually continue testing though.  Apps only currently :)
<kgunn> davmor2: thanks for testing!
<popey> kgunn: looks like latest mir broke the music app (again). Unplug phone, start music app, press play, let phone go dark, it doesn't continue to the next track, but does when you wake the phone.
<popey> bug 1292306 related
<ubot5> bug 1292306 in mir (Ubuntu) "Qt render gets blocked on EGLSwapBuffers [fka Upon upgrading to Qt5.2 the music app no longer plays the next song if the screen is off]" [Critical,Fix released] https://launchpad.net/bugs/1292306
<kgunn> popey: are you playing local music ?
<popey> yes
<kgunn> hmmm....
<popey> ahayzen: music dev discovered and I confirmed it
<kgunn> mir hadn't changed since image 110
<kgunn> popey: are you sure its mir  ^
<popey> well it felt like *that* bug â»
<ahayzen> kgunn, how can we tell if it is/isn't mir?
<kgunn> popey: and we sure hadn't touched that particular part of the mechanism (....so....much....pain)
<popey> heh, i hear you!
<kgunn> ahayzen: when did it start happening ?
<kgunn> i assume this gets tested every image
<popey> not sure it does â¨
<ahayzen> kgunn, 'recently' ... no we don't have any automated testing on this :/
<popey> i have it on the devel image
<kgunn> popey: i do know that jhaddop and the boys/girls were changing stuff in their area related to this....but not sure what...i can go retro and test an image to see if it was mir...but nothings changed since 110
<kgunn> btw i need to run
<popey> ok, thanks kgunn
<ahayzen> thanks kgunn
<popey> ahayzen: lets get a new bug filed for this, and get it on the radar
 * popey moves to -ci-eng
<ahayzen> popey, agreed
<anpok> AlbertA: regarding the deadlock
<anpok> display needs to be off?
<anpok> to experience it
<AlbertA> anpok: it needs to be off, and then you need to hit the power key again to start the compositor
<anpok> oh seems like I just experienced a different problem
<AlbertA> so if you get lucky
<AlbertA> the timeout will be executing as the compositor starts and calls swap_unblocked
<AlbertA> which will deadlock
<AlbertA> anpok: oh yea?
<anpok> n10 with qtcomp branch .. freezes
<AlbertA> just in normal use?
<anpok> for a few seconds then continues
<anpok> hmm during animations
<anpok> from app to shell
<anpok> or on application startup
<AlbertA> anpok: I see....
<anpok> hm this is new .. n10 was working extremely fluid yesterday
<greyback> anpok: yeah, I'm seeing it now too. First time I've ever experienced that, wtf is making everything just block?
<greyback> hmm, wonder if the snapshotting is to blame
<greyback> I see blocking in libdbus which I didn't expect either
<AlbertA> anpok: so your branch https://code.launchpad.net/~andreas-pokorny/mir/synchronous-cancel-of-alarms/+merge/224530
<AlbertA> anpok: would not resolve the deadlock for https://bugs.launchpad.net/mir/+bug/1339700
<ubot5> Ubuntu bug 1339700 in Mir 0.4 "[regression] Device locks randomly on welcome screen" [High,In progress]
<AlbertA> anpok: since cancel is synchronous
<AlbertA> i.e. Thread A (the one executing the ServerActionQueue.. may be executing the alarm handler for TimeoutFrameDroppingPolicy
<AlbertA> the policy callback then will try to acquire BufferQueue::guard
<AlbertA> let's say there's thread B, calling BufferQueue::compositor_release
<AlbertA> which owns BufferQueue::guard
<AlbertA> and attempts to cancel the alarm (due to framedrop_policy->swap_unblocked();)
<AlbertA> which will wait indefintely since it's synchronous and won't get executed until AsioMainLoop::process_server_actions returns from the alarm handler
<AlbertA> so deadlock...
<AlbertA> anpok: but I think if we expose the async_cancel api, we can make use of that to avoid this condition. The alarm handler in TimeoutFrameDroppingPolicy
<AlbertA> can deal with spurious calls....
<AlbertA> maybe....I need to think about it some more....
<anpok> AlbertA: hm but it wont use the queue in that case
<AlbertA> anpok: ? Trhead B? but that's the compositor thread
<anpok> ah ok I have to read that again
<anpok> AlbertA: yes you are right this was an attemmpt to keep up the synchronous api
<anpok> but it seems that is the actual mistake
<AlbertA> anpok: so the reason for queing them up for server action queue,
<AlbertA> is due to timer.cancel() not guaranteeing that there will be no more handlers invoked?
<anpok> yes
<AlbertA> ok
<anpok> timer.cancel tries to provide a synchronous api without the guarantees
<anpok> i.e. cancel may return, and may destroy other related objects, previously referenced by the timer callback, and another thread is scheduled and executes the timer
<anpok> i.e. happened in ~TimeoutFrameDroppingPolicy
<anpok> greyback: yes there are unity8 logs about snapshotting
<greyback> anpok: actually I think it is a problem with dbus
<anpok> but only in the app -> phone shell switch cases..
<greyback> anpok: connecting with strace, unity8 is continually polling for something, and when it tries to send a dbus message, blocks for 25seconds before timing out (then tries again I think)
<greyback> sbus messages are sent for app focus changes
<anpok> and that inside the rendering thread?
<anpok> or the event thread block rendering again?
<greyback> anpok: event thread blocks
<anpok> yay!
<greyback> why dbus is failing I don't understand
<anpok> was there a recent change?
<greyback> but I see in my unity8 log that it crashed the first time when trying to connect to the dbus socket
<anpok> my n4 image is a bit older than the n10 image
<anpok> only see it there
<greyback> no relevant recent change actually
<greyback> I only see this on N10, not N4/7
<greyback> perhaps a race somewhere
<anpok> AlbertA: i am not sure - there are a few synchronisation points like destructors - there we need to have synchronous behavior. Apart from that queuing or working with completion handlers seems simpler.
<AlbertA> also it looks like the users of alarm need to protect it externally
<AlbertA> i.e. like if one thread is doing reschedule_in and another trying to cancel
<AlbertA> well not in the traditional sense I suppose
<AlbertA> alarm state itself will be fine
<AlbertA> anpok: I think the branch looks fine, except for line 244
<AlbertA> data = std::make_shared<InternalState>(data->callback);
<AlbertA> USC will update the timer repeatedly to reset the inactivity timer during motion events
<AlbertA> I'm concerned about the overhead
<kgunn> i love it when i type reboot in the wrong window
<AlbertA> kgunn: I hate it...:)
<kgunn> so annoying
<AlbertA> I've gotten used to adb shell reboot instead.... <= workaround
<kgunn> totally...
<kgunn> i had a moment of weakness :)
<anpok> AlbertA: wait until your system exposes an adb service that can be used from your phone
<AlbertA> anpok: ha
<anpok> AlbertA: hm could be replaced by a different mechanism
<anpok> maybe a configuration counter? to differ between two pending states?
<anpok> and the action inside the queue stores the expected pending counter?
<AlbertA> like adding a pending_state ?
<anpok> hm there alread is?
<anpok> i meant something to detect inside the queue whether the alarm object is out of sync with the currently executed action
<AlbertA> anpok: so the only reason I see for data being a shared_ptr is for lifetime issues...which should be now addressed with the synchronous cancel no?
<AlbertA> do we really need auto data = possible_data.lock();
<AlbertA> anpok: I mean basicaly this comment
<AlbertA> http://paste.ubuntu.com/7777346/
#ubuntu-mir 2014-07-11
<AlbertA> too many threads.....too many mutexes....
<AlbertA> so I think a combination of anpok_ branch and just avoiding canceling the timer in TimeoutFrameDroppingPolicy
<AlbertA> with appropiate checks of pending_swaps...should do it...
<RAOF> AlbertA: I think one extra mutex should make everything work right :)
<AlbertA> RAOF: heh...I think we also need an extra thread :)
<duflu> Guest2511: Welcome to Mir :)
<Guest2511> its just me :) kgunn
<Guest2511> night o/
<RAOF> Is there really no way to tell before you try writing how much data you'll need to write to a socket before it'll block?
<alan_g> anpok_: I know you've a wider solution in the pipe, but if you're happy with this can we top-approve to get a fix landed? https://code.launchpad.net/~vanvugt/mir/fix-1339700-alarm/+merge/226252
<alf_> alan_g: http://paste.ubuntu.com/7779262/ , it's not a problem in the observer code per se, it's a race in our session shutdown code
<alf_> alan_g: if when closing a session we focus another session that has a different display configuration, we queue a display configuration change in the action loop that eventually needs to a acquire a write lock to remove surface observers when shutting the compositor down
<alan_g> alf_: should I take your word for it or do you need a second set of eyes?
<alf_> alan_g: thanks, the problem is clear to me so need to take up your time
<alf_> alan_g: ...so no need...
<alf_> alan_g: ... meanwhile we continue tearing down the session object which triggers a surface remove observer (under read lock) and which eventually wants to unregister an input fd from the main loop
<alf_> alan_g: that's just FYI, you can ignore the above, just expressing the issue so that it becomes even clearer in mind
<alan_g> alf_: understood. And it will help me with the review
<alf_> alan_g: camako_: FYI, https://bugs.launchpad.net/mir/+bug/1340669
<ubot5> Ubuntu bug 1340669 in Mir "Intermittent deadlock when swithcing to session with custom display configuration while closing other session" [High,New]
<camako_> alf_, hmmm this is different from the other deadlocks?
<alf_> camako_: yes
<alf_> camako_: (not fixed/affected by Alan's branch)
<camako_> alf_, ack... just as severe, and need to be included soon in a release, I guess.
<alf_> camako_: right, I marked it "high" instead of "critical" since it only affects XMir session at the moment, but feel free to upgrade
<alf_> camako_: unfortunately, although the problem is clear, the solution hasn't become clear yet
<camako_> alf_, finding the bug is half of the work to fix it :-)...
<alan_g> writing the test that demonstrates the bug is half of the work too
<alan_g> ...so fixing it must be trivial
<alan_g> camako_: any problems with the nested_lifecycle_events MP or just been busy?
<camako_> alan_g, just back to it now.. should update soon
<alan_g> cool
<anpok_> alan_g: alf_: hey what about going all single threaded?
<alan_g> alf_: what's the status of MesaDisplayTest? I thought there was a recent "intermittent failure" bug but can't seem to find it
<alan_g> anpok_: where's the fun in that?
<anpok_> I believe we should copy whatever the renderers need to composite a scene each frame, and have the rest happen in a single thread
<anpok_> alan_g: there is none! but maybe when we get bored after a few months without a race or deadlock we would happily switch back?
<alf_> alan_g: https://bugs.launchpad.net/mir/+bug/1336671 , waiting for fixed umockdev package to land in the archive (haven't checked today, perhaps it already did)
<ubot5> Ubuntu bug 1336671 in Mir "Intermittent mir_unit_tests.MesaDisplayTest.drm_device_change_event_triggers_handler test failure: libumockdev isn't thread safe" [Medium,In progress]
<alf_> anpok_: all the threads we have are there for a reason (performance), I am all for a single threaded structure, but I doubt we could get decent performance this way
<alan_g> alf_: thanks.
<anpok_> alf_: you mean both the ipc handling threads and the renderer threads?
<alf_> anpok_: and input
<anpok_> ah right I forgot about input
<anpok_> at least i try to :)
 * alf_ is reminded once again that "Writing correct shut-down code is hard" http://books.google.gr/books?id=_i6bDeoCQzsC&lpg=PT411&ots=eo2Pxn2b06&dq=writing%20correct%20shutdown%20code%20is%20hard%20martin&pg=PT411#v=onepage&q&f=false
<alf_> at least I know have an acceptance/regression test for the deadlock...
<anpok_> doodle?
<camako_> alan_g, just pushed the fixed version of nested_lc
<camako_> alan_g|lunch ^^
<sil2100> kgunn: hi!
<kgunn> sil2100: hey
<alan_g> camako_: looking
 * kgunn realizes this is going to be a 3 coffee day
<kgunn> see i've included all the "e"s so i've already had 2
<sil2100> kgunn: how's the progress on bug LP: #1339700 ? As I see many merges there and got a bit confused ;)
<ubot5> Launchpad bug 1339700 in Mir "[regression] Device locks randomly on welcome screen" [High,In progress] https://launchpad.net/bugs/1339700
<kgunn> sil2100: sorry...i meant to send a mail last night
<kgunn> sil2100: lemme see one email in my pile real quick
<kgunn> re this
<sil2100> Ok :)
<sil2100> Thanks
<kgunn> sil2100: ok, bottom line, we thot we had a fix, got to talking realized we needed to do a little surgery vs band-aiding....
<kgunn> sil2100: so we backed up, had lots of discussion on irc & launchpad....
<kgunn> sil2100: i think we'll consolidate those thots into one patch today, test, promote on our devel, then propose to trunk in an isolated fashion...
<kgunn> e.g. we'll do a 0.4.1mir with this bug fix only
<sil2100> kgunn: that's a good plan
<kgunn> camako_: ^ did i speak right ?
<sil2100> kgunn: would be best to land this isolated, without pulling in all the other, risky bits
<sil2100> Especially that we're trying to get a completely green image ;)
<camako_> kgunn, yeah sounds right
<sil2100> kgunn, camako_: thanks guys :)
<sil2100> camako_: oh, and let me finish up my check-up on the lp:mir request you had yesterday
<camako_> sil2100.. sure.. take ur time
<alan_g> camako: another iteration of fixes
<camako> alan_g ack
 * kdub_ is debating adding a mir::Fd type
<alan_g> kdub_: do it
<kdub_> yay, will help me fix this flummoxing resource problem where I have to dance around pod-int-fds
 * kdub_ wishes gmock was better with movable / not copyable types
 * alan_g too
<AlbertA> If I could just std::lock all the three mutexes involved....we would be golden...
<alan_g> AlbertA: assuming there is a canonical order to the locking
<AlbertA> alan_g: right... it would mean maybe the Alarm would need to get a reference to the mutex it's handler uses
<AlbertA> so the handler can lock it in the same order
<alan_g> Sounds messy - a mutex should only be protecting data in the associated object
<AlbertA> maybe we could make it part of the handler interface
<AlbertA> a lock method...
<AlbertA> then you have an opportunity to implement the same locking order
<AlbertA> and optional if the handler does not need to deal with such a thing
<alan_g> Hmm. It is too late in the week for me to think about that.
<AlbertA> its still too brittle though, prone to error, because as soon as you break the lock hierarchy ( inadvertently) you would still deadlock
<AlbertA> very possible with the levels of indirection we have
<AlbertA> my head hurts....but I think a simple solution is just to restore cancel to the way it was...and just make the destructor of AlarmImpl
<AlbertA> use the synchronous wait for callback to complete version
<AlbertA> kgunn: so I'm confident that https://code.launchpad.net/~mir-team/mir/fix-1339700-take2/+merge/226534
<AlbertA> kgunn: with Daniel's just landed change should address the deadlock without sideeffects
<AlbertA> kgunn: so this should not break abi: https://code.launchpad.net/~mir-team/mir/fix-1339700-take2-in-0.4/+merge/226537
<kgunn> AlbertA: you are awesome
<kgunn> thanks
<kgunn> racarr__: ^ can you give that a quick review as well ?
<kgunn> kdub_: ^ if you're gonna be on for a little
<kgunn> AlbertA: so i assume you tested on n4 & n10 ?
<AlbertA> kgunn: yes
#ubuntu-mir 2015-07-06
<RAOF> Bah! All these valgrind errors are present in trunk, too!
<tjaalton> mesa dropped support for external egl drivers, because egl_gallium was the only user (besides mir) and got removed earlier
<tjaalton> anyone looked at that yet?
<anpok_> eh no.. they dropped the egl state tracker inside gallium
<tjaalton> egl/main: drop support for external egl drivers
<anpok_> because it was not maintained and the egl driver inside src/egl/ was working fine
<tjaalton> 209360bbb91bb10
<tjaalton> this is in 10.6.0
<anpok_> it was in a bit rot state at last.. the mir platform is still patched to egl/drivers/dri2/ ..
<tjaalton> right, I'm trying to fix that patch to apply, but looks like it needs bigger rework
<anpok_> oh
<anpok_> tjaalton: i thought the mir platform did not rely on that?
<tjaalton> anpok_: I don't know if it relies on that or not, but the patch doesn't apply :)
<tjaalton> can just drop that part then?
<anpok_> tjaalton: first time that I realize that this part was touched by the platform patch too..
<anpok_> I believe it is not needed
<tjaalton> ok thanks
<racarr> Hey all! Back from chicago
<racarr> need to get some breakfast and wash the grateful dead off my face
<racarr> be in after lunch
<kenvandine> racarr, any progress on bug 1468029?
<ubot5> bug 1468029 in Mir "unity8 crash breaking autopilot tests entering text" [Critical,In progress] https://launchpad.net/bugs/1468029
<kenvandine> lack of passing CI is really hurting
<racarr> kenvandine: Not really...I've uh
<racarr> I mean I started on it friday but then I basically spent
<racarr> a half day failing to get unity8 desktop session to work
<racarr> and then another half day struggling with flashing issues on arale
<racarr> ending the day with my arale bricked and no desktop session
<racarr> but I'm sure I'll make some progress soon!
<kenvandine> racarr, no fun...
<racarr> I was thinking next I might try the emulator
<racarr> just to knock this out quickly
<racarr> then figure out what is going on with desktop session, etc...
<kenvandine> it's been easy to reproduce on my mako, if i run more than just a few tests it blows up everytime :/
<kenvandine> and have to restart unity8 to get it moving again
<kenvandine> today i've resorted to running each test manually one at a time
<kenvandine> to get some confidence the code we want to land actually passes, since we haven't had a passing CI run in 2 weeks now
<racarr> kenvandine: Yes the problem is I can't test devel
<racarr> so I can't make changes and see if it fixes it
<kgunn> racarr: sorry, why can't you test devel ?
<bschaefer> mterry, hello, i had a question on the mir framework deb2snap. How did the mir demo server end up auto starting on init?
 * bschaefer tries to dig through the snap
<mterry> bschaefer, that's because the snap contains a 'service' which is a systemd unit on the snappy system
<mterry> bschaefer, those are autostarted
<bschaefer> mterry, sweet, thanks!
<bschaefer> ill look at the services within that lp:snappy-package i think
<mterry> bschaefer, look at ./meta/package.yaml and ./service
<bschaefer> mterry, awesome thanks!
<racarr> kgunn: Well...I just wasn't able to on friday. First I tried in vain to get desktop session working after my last series of upgrades
<racarr> err thursday*
<racarr> then there were the arale flashing issues
<racarr> my arale is working again now I don't understand what happened though
<racarr> it was totally unresponsive via flashboot and now is
<kgunn> racarr: ok, so all good ?
<racarr> kgunn: Seems so now...:)
<racarr> kenvandine: Ping?
<RAOF> anpok_: http://paste.ubuntu.com/11833355/
#ubuntu-mir 2015-07-07
<kenvandine> racarr, pong
<duflu_> racarr: ubuntu-device-flash touch --help
<duflu> The non-obvious bit is that --help gives a different answer according to context
<racarr> duflu: I guess that was the one that I found not to work actually
<racarr> --recovery-image (which I copied from the PES wiki)
<racarr> I still dont end up with adb in recovery
<racarr> and have to fastboot flash
<racarr> I dunno
<racarr> the USB issues make it hard to understand
<racarr> what really happened
<racarr> I have a cable/port combo that seems steayd now though
<anpok> RAOF: hrhr
<RAOF> anpok: Yeah, rad isn't it?
 * RAOF just had to finish it over the weekend.
<anpok> havent grasped it yet
<anpok> i spent this weekend restarting the compile time widget tree thing.. and even uploaded it..
<RAOF> Oooh, InputSender. That's what I'm after!
<tjaalton> hm no ancell? wonder if the xmir patch is going upstream soon, 1.18 is finally about to freeze
<tjaalton> xserver
<duflu> greyback: Does unity8 always have GL_BLEND on (regardless of surface pixel format)?
<greyback_> duflu: sorry, wifi dropped
<greyback_> duflu: it doesn't always have blending enabled. It first draws opaques front to back with blending disabled but depth masking enabled. Then non-opaques are drawn back to front with blending enabled
<duflu> greyback_: So "opaque" is XRGB as opposed to ARGB
<duflu> ?
<duflu> Depending on the surface pixel format
<greyback_> duflu: anything in the qml not needing an alpha channel
<greyback_> the surface format for mir, we've probably chosen XRGB
<greyback_> mainly because it'll always work. But we're working on more intelligently selecting the mir surface format, to improve perf
<duflu> greyback_: I've got hints that Unity8 might be blending XRGB as if it was ARGB. Admittedly Mir demo servers have the same bug. I was just wondering if we're all affected
<greyback_> duflu: is possible, unity8 does the same thing as mir in that respect
<duflu> alf_: Feel like chatting today?
<alf_> duflu: coming
<mcphail> greyback_: do you think the blending contributes to this bug? : https://bugs.launchpad.net/ubuntu/+source/libsdl2/+bug/1460149
<ubot5> Launchpad bug 1460149 in libsdl2 (Ubuntu) "Visible corruption in SDL apps (Neverball, Neverputt) on Nexus 4 / Nexus 7." [High,Triaged]
<greyback_> mcphail: not directly, but I suspect the sdl's surface may be using a mir surface format with an alpha channel, making unity8 blend it. Would have to dig to learn more
<mcphail> greyback_: just interested as to why the aberrant blending clears when you swipe the app away
<greyback_> /usr/lib/gcc-cross/arm-linux-gnueabihf/4.9/../../../../arm-linux-gnueabihf/bin/ld: ../../gmock/libs/gtest/libgtest.a(gtest-all.cc.o): relocation R_ARM_THM_MOVW_ABS_NC against `__stack_chk_guard' can not be used when making a shared object; recompile with -fPIC
<greyback_> ../../gmock/libs/gtest/libgtest.a: error adding symbols: Bad value
<greyback_> ^^ I get that building mir in my arm Xcompile chroot. Would libgtest.a not be compiled with -fPIC?
<kdub> greyback_, libgtest.a seems to be compiled with fPIC from the mir build system
<kdub> alf_, was curious, is it the mg::DisplayBuffer/mg::Display system that has the gl stuff baked in the most? or is there somewhere else
<greyback_> kdub: yeah. Am still confused
<kdub> greyback_, using sbuild?
<greyback_> kdub: yes
 * kdub did that a day or two ago, seemed okay, after updating with -udacr
<alf_> kdub: Excellent timing :) I have started a document with a tentative plan about removing gl dependencies (including where these dependencies are in the code). Will post a link of a first draft before EOD today.
<kdub> alf_, cool, I just felt compelled to point out that mg::DisplayBuffer::post_renderables_if_optimizable is really not posting anymore
<kdub> and mg::DisplayBuffer is mostly about content, which seems good for abstracting the gl bits out
<kenvandine> racarr, you pinged me last night?
<racarr> kenvandine: Oh hey sorry yeah I think I've since resolved my question
<racarr> I was trying to narrow down what may be triggering the text input failure...because
<racarr> just uh
<racarr> Like making an autopilot keyboard object from python
<racarr> typing
<racarr> doing stuff
<racarr> typing doing stuff
<racarr> seemingly infinitely never triggers it
<racarr> s/seemingly infinitely/for a few minutes/
<racarr> So I was trying to find a collection of tests to trigger it but I have a few now...
<racarr> its hard to find the common element the
<racarr> lol
<kenvandine> yeah
<kenvandine> sucks
<racarr> the autopilot tests aren't easy to read
<kenvandine> nope
<racarr> because theres so much inheritance of implementation
<racarr> Its like
<racarr> I dunno
<racarr> I tried tracing base classes up and
<racarr> butttt
<racarr> hard to isolate anything
<racarr> so my new strategy is instrument USC :)
<kenvandine> i don't think it has anything to do with the system-settings autopilot tests
<kenvandine> well
<racarr> well...it may have something to do with autopilot though
<kenvandine> we're using the keyboard input provided from the uitk i think
<kenvandine> yeah
<racarr> like I said with just the fake uinput thing
<racarr> I can't trigger it
<kenvandine> it's triggered by something autopilot is doing
<kenvandine> also... i think it's more than just the fake keyboard
<kenvandine> there is a fake mouse too for touch events
<kenvandine> also uinput
<racarr> that stops working?
<racarr> yes so I thought
<kenvandine> yes
<racarr> this was all related
<racarr> to uinput
<racarr> which according to the bug is what is being used in autopilot now
<racarr> and it seems that the problem is
<kenvandine> yeah
<racarr> the unity8 session loses focus
<kenvandine> and mir starts discarding the events
<racarr> loses keyboard focus
<racarr> mm
<kenvandine> from what dandrader said
<racarr> Yeah I confirmed that unless im only seeing part of the bug
<racarr> I haven't seen any unity8 crashes for example so far
<racarr> and don't understand where that comes in
<kenvandine> yeah...
<kenvandine> that wasn't related
<kenvandine> i don't think
<racarr> ok :)
<kenvandine> well, we saw the same unity8 crash everytime we had run into this
<racarr> yeah that was my other question.
<racarr> ah
<kenvandine> but the crash stopped
<kenvandine> and this kept happening :)
<kenvandine> so unrelated
<kenvandine> it was a distraction from the real problem
<kenvandine> racarr, it affects at least webbrowser-app and ubuntu-system-settings
<kenvandine> but likely more too
<kenvandine> we just have long autopilot tests
<kenvandine> i think we've had the problem intermittently for a while, we used to have random failures where it seemed to stop getting the uinput events
<kenvandine> touch stuff
<greyback> crazy idea: could there be a test pressing down a meta key, and crashing before that key is released?
<kenvandine> but re-running it would pass
<kenvandine> now it's consistent
<kenvandine> i haven't had a passing CI run in settings in 2 weeks
<kenvandine> greyback, i don't think so
<greyback> worth a shot :)
<kenvandine> i'm pretty sure i've hit it when tests that didn't even use the keyboard
<racarr> greyback: That's a good idea but I think it wouldn't explain the focus behavior
<kenvandine> just the fake mouse events stop
<racarr> which im 99% sure isn't a red herring
<racarr> wait the fake mouse events stop oO
<kenvandine> makes sense though
<kenvandine> because of focus
<racarr|lunch> yay just catching up on MLs...anpoks libinput changes are landing :)
<anpok> hum .. time to say goodbye
<anpok> .. to those hp/webos usb cables
<racarr> kenvandine: After upgrading arale to r50 from
<racarr> ubuntu-touch/rc-proposed/meizu.en
<racarr> The test I was using autopilot3 run ubuntu_system_settings.tests.test_search.SearchTestCases.test_search_filter_results
<racarr> doesnt fail anymore after like 25 times
<kenvandine> oh?
<racarr> I was on either 48 or 49 yesterday
<kenvandine> any idea what change fixed it?
<racarr> I Was wondering 1. Could you suggest some other tests. 2. Can you try upgrading as well?
<racarr> No...lol...
<kenvandine> i mostly care about wily, since that's what CI runs on
<kenvandine> racarr, try running the full suite
<racarr> kenvandine: Running :)
<racarr> I don't think I've ever put wily on my uh
<racarr> arale...is it
<racarr> ubuntu-touch/devel/meizu.en?
<kenvandine> not sure off hand, i have it on my mako
 * kenvandine checks channel
<kenvandine> ubuntu-touch/devel-proposed/ubuntu
<kenvandine> racarr, that's the channel i have on my mako
<racarr> ok thanks :) anyway full suite running now
<kenvandine> racarr, ubuntu-touch/devel-proposed/meizu.en
<racarr> changing laundry...uh
<kenvandine> is for arale
<kenvandine> racarr, thx
<racarr> then I guess I can switch to latest wily
<racarr> and see whats going on
<racarr> I was just trying to test with an
<racarr> instrumented USC to try and understand
<racarr> but then before I was like ok first
<racarr> clean image and reproduce
<racarr> and now I can't reprouce anymore lol
<kenvandine> might be a good sign :)
<racarr> probably but not understanding is frustrating...
<kenvandine> i'm updating my mako and will try the tests too
<racarr> kenvandine: Aghhh I managed to trigger it...
<racarr> I guess it was just being elusive
<racarr> :/
<kenvandine> ok
<racarr> is there a way to work with the citrain on vivid + overlay without
<racarr> writing apt pins, etc...?
<anpok> i think you no longer have to
<anpok> racarr: the current phablet tools should already do that
<anpok> at least after i used an unbroken cable.. a current image from the right channel.. it finally worked
<kgunn> yeah robru said you shouldn't have to pin with overlay
<racarr> hmm
<racarr> I have a plausible theory about the text input bug now!
<racarr> 1. An autopilot test eventually fails because that happens with the timeouts and stuff causing mirscreencast to be invoked
<racarr> 2. Bug in surfaceless session management with mirscreencast
<racarr> connecting and disconnecting
<racarr> causes
<racarr> focus to be cleared when
<racarr> mirscreencast closes
<racarr> instead of
<racarr> unity8
<racarr> I kind of see a plausible path in the code but its hard to tell whats happening because
<racarr> um
<racarr> as far as I can tell there are two window managers in USC
<racarr> lol
<racarr> WindowManager seems to take care of like focusing sessions when sessions are removed and stuff like that
<racarr> but then so does SessionSwitcher oO
<racarr> anyway...I feel good about this theory but I'm still struglging to test anything
<racarr> I needed to install the mir 0.14 ppa to build USC trunk with my instrumentation on vivid+overlay of course
<racarr> but mir 0.14 ppa did not work on vivid+overlay for me
<racarr> (u8 crashes after 3-4 seconds)
<racarr> so now I'm trying to test with wily...
<racarr> in particular usc::WindowManager l115 auto const next_session = session_coordinator->successor_of({});
<racarr> I can't see why that would be the right value...
<racarr> hmm and this code is in mir now in system_compositor_window_manager
<racarr> with some modifications
<racarr> too bad about no Alan...
<racarr> Interesting ok
<racarr> I guess the SurfaceReadyObserver
<racarr> may be bale to prevent screencast from stealing focus...
<racarr> (a new introduction to the logic when it was imported)
<racarr> um so both vivid and wily+overlay
<racarr> the mir 0.14 ppa
<racarr> unity8 crashes within seconds on arale
<racarr> has anyone else tested it?
<anpok> the ppa is incomplete.
<anpok> i was waiting for platform api and qtubuntu to land
<racarr> oh
<racarr> anpok: When is that expected?
<anpok> it just happened for wily
<anpok> it now needs to be synced to vivid+overlay... but at least the lp branches are updated.. so I guess I can build it..
<racarr> anpok: :D That would help me
<kenvandine> Ran 135 tests in 2750.871s
<kenvandine> OK
<kenvandine> racarr, ^^ on my mako with wily
<kenvandine> that hasn't happened in 2 weeks
<kenvandine> maybe it was a fluke... or maybe something's been fixed?
<racarr> kenvandine: So uh...yeah I also got
<racarr> well right I ran that one test like 30 times and
<racarr> then saw dozens in the test suite complete
<racarr> before failing
<racarr> so its possible the race has just gotten
<racarr> way tinier lol...
<racarr> though, right I still haven't tested wily! my result was from vivid + overlay
<RAOF> racarr: With your input sending reworkything, were you thinking of having mf::Surface have a send_event method?
#ubuntu-mir 2015-07-08
<racarr> RAOF: I'm not sure...I hadn't really gotten that far yet so much as digesting/rewriting/importing the existing InputTransport code
<RAOF> Ah, right.
<racarr> that doesn't sound quite right to me though
<racarr> What in frontend wants to call send_event on a surface?
<racarr> I would think for example the input dispatcher would be calling it (as it does now)
<racarr> which would work on mi::Surface
<RAOF> Nothing in frontend, but frontend needs to *provide* send_event.
<racarr> yes. I guess it needs to provide
<racarr> the_input_sender
<racarr> which
<racarr> Surface::consume
<racarr> uses
<RAOF> Which is what I'm doing. Ish.
<RAOF> Because there isn't actually a single input_sender.
<RAOF> (There isn't *currently* a single input_sender, really; it's just that we've split the input sending code into multiple pieces, owned by different things)
<RAOF> Which is why trying to make it do something different is annoying :)
<RAOF> Damn. I should have left this branch not-compiling.
<kenvandine> racarr, weird... i had the tests pass once... but not again :/
<racarr> kenvandine: ONce it fails it fails until u8 restarts yeah...and...yes I think it just became more resilient but not totally
<racarr> Once mir 0.14 ppa finishes building
<racarr> well maybe thats done
<racarr> once its tomorrow
<racarr> ill be in a good position to verify my theory about
<racarr> mirscreencast confusing
<racarr> USC window management....
<RAOF> Have I mentioned before how much I hate the way nothing in Mir ever has an owner? :/
<anpok_> owner?
<anpok_> like mir::DisplayServer::Privae?
<RAOF> Everything we ever create is a shared_ptr; nothing is owned by anything.
<anpok_> but shared_ptr describes ownership.. shared but still .. ownership
<anpok_> hmm
<anpok_> i guess for a lot of stuff unique_ptr and passing around references would be enough
<RAOF> Yeah. shared_ptr describes âeh, working out who owns this is hard. Let's go shopping!â
<anpok_> hehe
<RAOF> Lots of our things are âthis thing is owned by the compositor; it's basically a singletonâ.
<RAOF> A bunch of others are âthis thing exists for as long as a client has connected. And then for an indeterminate time afterwards, even though that doesn't make senseâ.
<RAOF> You are in a maze of classes, all called Shell.
<RAOF> It doesn't help that Qt Creator gets confused about the type hierarchy.
<anpok_> hm is passing argv=nullptr and argc=0 a user error
<dandrader> duflu_, ping
<duflu_> dandrader: Hello!
<dandrader> duflu_, hi
<dandrader> duflu_, If I draw a surface twice in my qml scene. Should each item there have a different compositor "user id"  when fetching buffers?
<dandrader> duflu, or should I use a single compositor user id
<duflu> dandrader: That's the multi-monitor frame sync library. Technically you should get one user ID per frame for a single monitor display.
<duflu> -library +logic
<duflu> dandrader: It's really an opaque "monitor ID". If two monitors with different IDs ask for a frame around the same time they will get the same frame. But if any ID asks for a frame twice it will get different (the next) frame
<duflu> dandrader: You doing multi-display?
<dandrader> duflu, no. I'm doing "having multiple items showing the same mir surface in a qml scene"
<dandrader> duflu, and I'm finding it may be easier to implement if each qml item did its own buffer fecthing using separate ids...
<dandrader> duflu, but wondering if that's a wrong approach
<duflu> dandrader: Hmm, still with a single display and a single ID I imagine you will get messed up by that. The right answer is to only ask each surface for a buffer once per frame (and use it any number of times). I you want a kludge, use different user IDs to force each call to get the same frame.
<dandrader> duflu, yeah, that was my intent. using a unique id per qml item (eg "(void*)this") so that they get the same frame
<duflu> dandrader: If you imagine "user ID" actually means "view ID" it makes sense. You're free to make up new IDs. And different views using different IDs will see the same frame
<dandrader> or work independently
<dandrader> duflu, so, would that be a valid use of this compositor user id API or would that be a hack?
<dandrader> s/valid/correct
<duflu> dandrader: It might feel like a hack, but the model is very abstract. If your two views with different IDs are on the same screen it should always work. I don't expect it would be a problem
<duflu> dandrader: But frankly for the sake of OpenGL performance you should be binding the surface to a texture once and then reusing the texture multiple times in the frame
<dandrader> duflu, right.
<dandrader> although I don't see a mir surface being rendered more than twice in a scene (say, its may view/window and a thumbnail in the tab switcher)
<duflu> dandrader: So it's a bit unexpected what you're doing but I don't expect it will ever break. It will work but it's not optimal. Also keep in mind for multi-monitor, each display needs a separate ID (or IDs)
<duflu> dandrader: Yeah the switcher or workspace previews is where I'd expect to see the same texture used multiple times on the same screen
<greyback> Mir API quiz: If I am a nested server, and my surface is resized by the system compositor - how do I know?
<omg_run> hi. i'm trying to record something with mir but i don't know what's mir's server socket file?
<omg_run> /run/lightdm-mir-o doesn't work
<anpok_> there is one for the unity-system-compositor and another one for the user session
<omg_run> something changed lately?
<anpok_> greyback: hum iirc you do not notice
<greyback> anpok_: yeah I'm reading the code and am seeing the mirclient resize event being swallowed in mgn::detail::DisplayBuffer::mir_event(MirEvent const& event)
<anpok_> omg_run: iirc /run/mir_socket and /run/user/<USER_ID>/mir_socket
<omg_run> anpok_: thanks :D let's see
<anpok_> greyback: I believe back then we assumed that it was not necessary..
<anpok_> hm I think I even had a fix branch that dispatches that too
<greyback> anpok_: bad assumption :)
<anpok_> I thought you get a display configuration change callback?
<greyback> sure I do, but the display config has only a bit to do with how USC wants to draw its scene
<greyback> my current approach: on display config, configure displays to clone (rotate if necessary), calculate the subrectangle which fits on both displays, resize scene to fit in that subrectangle
<greyback> so USC is calling resize() on unity8's surface
<greyback> but unity8 has no idea
<omg_run> doesn't work.. /run/lightdm-mir-0 worked fine until the last update.. hm.. let's see what changed
<greyback> anpok_: I see you noticed it a while ago: https://bugs.launchpad.net/mir/+bug/1294574 ;)
<ubot5> Launchpad bug 1294574 in Mir "Resize of nested server surfaces never reaches mir::graphics::NestedOutput - nested server always renders with original size" [Medium,Triaged]
<anpok_> greyback: hm so how do you want that fixed.. i believe just getting the resize event somewhere isnt enough?
<greyback> anpok_: I can work around it
<greyback> but it's definitely something I'll want in future
<racarr> Good morning!
<racarr> working on verifying some theories related to USC window management about the autopilot tex tbug
<kenvandine> racarr, cool
<kenvandine> racarr, when do we expect to see 0.14 in wily?
<kenvandine> assuming that has the fix :)
<racarr> kenvandine: Quite soon I think but I'm really not sure it does
<racarr> I will be soon
<racarr> I get very slow connections to the image server lately :(
<racarr> anpok_: Is the mir 0.14 silo expected working now?
<racarr> seems to work
<racarr> kenvandine: Ok...so theres a lot to suggest its fixed in .14 but there is a new problem in that
<racarr> autopilot is triggering lots of key repeats now...
<racarr> We changed the way key repeat was implemented/disabled so
<racarr> thats not so unexpected
<kenvandine> ugh
<racarr> it seems like key repeat must have just been off before...I unno
<anpok_> racarr: nearly
<racarr> anpok_: Oh its working for me
<anpok_> i misconfigured qtubuntu-gles
<racarr> hmm
<racarr> How was key repeat working before
<racarr> as far as I remember we didn't provide a runtime way to
<racarr> disable key repeat until now and it was
<racarr> on by default and qtmir doesn't disable it
<racarr> so...is it just the new key repeat timeout is way too low
<racarr> and
<racarr> ....
<anpok_> nah not quite
<racarr> but seems unlikely that this would have never come up before but ive never heard of it
<anpok_> unity8 had its own input dispatcher so it bypassed the repeat
<anpok_> handling
<racarr> anpok_: But from USC
<anpok_> so usc was repeating.. yes
<anpok_> and qtmir event feeder might have ignored the repeats?
<anpok_> not sure
<racarr> thats an idea!
<racarr> hmm it seems to interpret autorep correctly
<racarr> Hmm I dont get it how were there no key repeats before
<racarr> oh
<racarr> The initial key repeat timeout may actually be
<racarr> much lower than before...
<racarr> yep
<racarr> ok hmm
<racarr> kenvandine: So yeah...I can't trigger the text failing bug anymore but there is definitely this issue with key repeat
<racarr> we either need to get a mir patch in (which I should be able to cook up today...shouhld be roughly 20 lines of diff)
<racarr> OR
<racarr> autopilot can restart usc with MIR_SERVER_ENABLE_KEY_REPEAT=false :p
<racarr> kgunn: ^
<kgunn> awesome racarr thanks for chasing it so hard
<kenvandine> great news!
<racarr> I think autopilot with specific
<racarr> mir options has been shot down in the past right
<racarr> so....uh....
<racarr> should we try and get something in 0.14 or just
<racarr> let 0.14 go and do a point release
<racarr> No ABI break...
<racarr>  / API
<racarr> lunch!
<racarr> lol this would have showed up in manual testing
<racarr> for the silo too
<racarr> it makes the volume control so hard to use
<racarr> (tried to turn on music on the way to lunch)
<bschaefer> mir demos needs to depend on mir-platform-graphics-mesa2
<bschaefer> otherwise the demo server wont run
<attente> hello, does/will mir support any kind of clipboard/selection api?
<racarr> Back
<racarr> anyone have any opinions on 0.14/point release
<racarr> attente:  I think in the end we decided not to support it
<racarr> in favor of the content hub supporting it
<attente> racarr: yeah, that's what i thought too, but it's not clear to me if this is implemented there yet
<kenvandine> attente, it isn't
<kenvandine> the spec is still being written up
 * kenvandine is looking forward to working on that :)
<attente> kenvandine: ok, thanks :)
<kenvandine> np
<racarr> kenvandine: Are there workarounds now for this issue? e.g.
<racarr> we have a fix for the key repeat thing now so with that + 0.14 everything should work again
<racarr> and trying to sort out urgencies/what to do with it
<kgunn> reboot brb
#ubuntu-mir 2015-07-09
<RAOF> Dear lord it is prodictivity-sappingly cold upstairs in my office.
<kenvandine> racarr, no work arounds, we can't get passing CI :(
<RAOF> Hah!
<RAOF> Â¸ â  ,
<duflu> ==1
<duflu> Hmm, that's apparently an answer and a facial expression... =1
#ubuntu-mir 2015-07-10
<robert_ancell> Has anything changed with how to run Mir demo servers? I'm running sudo mir_demo_server ; chown me.me /run/usr/1000/mir_socket ; mir_demo_client_basic -m /run/user/1000/mir_socket and getting "Failed to connect to server `/run/user/1000/mir_socket': No such file or directory"
<robert_ancell> /run/usr/1000/mir_socket definitely exists
<duflu> robert_ancell: Not that I'm aware of. Everything should work as before..
<robert_ancell> duflu, any debugging tips?
<robert_ancell> The client/server seem otherwise happy
<robert_ancell> aha, strace suggest the failure is actually to open /usr/lib/x86_64-linux-gnu/mir/client-platform/
<duflu> robert_ancell: Try installing mir-graphics-drivers-desktop
<duflu> I think there's a bug for that but it's also arguably a feature
<robert_ancell> duflu, yeah, I'm looking at the Mir code so see how the error text could be clearer
<duflu> I agree, our lack of useful error messages is an issue. There are one or two bugs for that.
<robert_ancell> The issue is there's more than one thing that might not exist, so the error text needs to be clear
<robert_ancell> ugh, I give up trawling the frontend code. Bug it is.
<duflu> robert_ancell: A new bug is fine. Although I remember it was logged recently somewhere and ended up being won't fix/can't fix because you can't automatically determine the best driver package to have installed. We do however have: https://bugs.launchpad.net/mir/+bug/1381398
<ubot5> Launchpad bug 1381398 in Mir "Mir error messages from exceptions are not user-friendly" [Medium,Triaged]
<robert_ancell> yeah, they're the server side messages.
<robert_ancell> The client side should be easier to fix
<robert_ancell> bug 1473268
<ubot5> bug 1473268 in Mir "Connection error when no client-platform installed is confusing" [Undecided,New] https://launchpad.net/bugs/1473268
<duflu> robert_ancell: Wait, what?! If your server is already running you must have graphics drivers installed...
<duflu> You must have installed a working mir-platform-* to get the server driver but be missing the client driver package
<robert_ancell> duflu, I had mir-platform-graphics-mesa2 installed but not mir-client-platform-mesa2
<duflu> robert_ancell: Yeah OK, no problem.
<duflu> robert_ancell: At last discussion this was labelled "not an issue" as our desktop-next metapackage has the required deps
<duflu> But we can do better
<robert_ancell> It would be fine if the error message actually indicated the mismatch
<duflu> robert_ancell: Totally agree. Should be a simple enhancement
<duflu> robert_ancell: Also I have had thoughts that "driver" should be a single package, not separate client/server.
<duflu> Even a single binary
<robert_ancell> Yeah, it would be nicer to have one package though I guess there are potential small gains in splitting?
<duflu> robert_ancell: We can keep two binaries and still have a single package. But also code reuse (and hence total system memory used) might be reduced by a single binary
<duflu> -reuse +duplication
<duflu> robert_ancell: Incidentally, this week I was focussing on "bugs that users can actually see"
<robert_ancell> duflu, do you know of an issue running mir_demo_server on wily and it crashing when a client connects with "*** stack smashing detected ***"?
<duflu> robert_ancell: I am aware of only one stack smashable issue. That is apparently fixed in 0.13.3 and later - https://bugs.launchpad.net/mir/+bug/1465883
<ubot5> Launchpad bug 1465883 in Mir "libmirprotobuf's ABI can be broken when modifying protobuf message definitions" [High,Fix committed]
<duflu> robert_ancell: Obviously first check if it's the client rather than Mir doing the smashing
<robert_ancell> the message is on the servers stderr
<robert_ancell> ah, I have a 0.14.0 version of libmirprotobuf it seems
<duflu> robert_ancell: From memory you need the fix in libmirclient and libmirserver packages (0.13.3 and later)
<duflu> Not libmirprotobuf, despite that being closely related
<robert_ancell> duflu, I downgraded and that fixed it, thanks!
<robert_ancell> btw fingerpaint is fun with a 10 fingers :)
<duflu> robert_ancell: That's a worry if 0.14 caused issues
<duflu> Yay, fingerpaint
<robert_ancell> Should libmirclient8 0.13.3+15.10.20150617-0ubuntu1 with with libmirprotobuf0 0.14.0+15.10.20150701-0ubuntu1?
<duflu> robert_ancell: I think so. But there might be bugs we're not aware of
<duflu> If you can install them simultaneously then that's theoretically a supported combination. But not a guarantee that they will talk to each other (you might have multiple versions of a package installed too)
<robert_ancell> RAOF, with DRI3 do you create a Pixmap then use DRI3BufferFromPixmap or do you create the buffer using some direct call to the driver and then use DRI3PixmapFromBuffer?
<duflu> robert_ancell: He's on holiday for a week now
<robert_ancell> ah
<duflu> Although reading email on the go
<duflu> sometimes
<UukGoblin> hi :-)
<UukGoblin> is there a way to run applications written for X11 under Mir?
<anpok_> yes
<anpok_> in wily the new package is called xmir .. on vivid it was xserver-xorg-xmir
<anpok_> you bascially launch xmir with -mirSocket /path-to-your-mir-socket/ (i.e. /run/3201/mir_socket) and assign a display id and launch the x-application with that DISPLAY
<anpok_> UukGoblin: depending on the mir shell in use you might need additional steps.. I believe for unity8 you need to append a --desktop-file-hint <path-to-a-desktop-file> if in doubt ask in #ubuntu-unity
<UukGoblin> cool, thanks :-)
<kgunn> alf_: i'm assumign the system setting for "lock screen timout" does not alter or change the dimming timer?
<kgunn> (it's currently conflating lock with screen blank i think)
<kgunn> so for 1 minute.... 50 bright, 10 sec dim
<alf_> kgunn: the dimming timout is set to power-off timout - 10s
<kgunn> ah...so fixed
<alf_> kgunn: (by other components, we are not forcing it, our API is set_timeouts(dim, poweroff)
<kgunn> alf_: for your ques 6 i think scenario 1 makes the most sense to me at least
<alf_> kgunn: note: there was mistake in the description of (6) (fixed now), the initial trigger is a power key event
<kgunn> sure
 * kdub figures out how to tease apart BufferQueue
<camako> \o/
#ubuntu-mir 2016-07-11
<alan_g> hi duflu, welcome back!
<duflu> thanks... otp :)
<kdub> hmm, libmir-test-assist linking failure in builders
<alan_g> well... no-one uses it anyway. :(
#ubuntu-mir 2016-07-12
<alan_g> anpok_: it looks like your NI is addressed: https://code.launchpad.net/~kdub/mir/anw-logger/+merge/299343
<alan_g> anpok_: this covers it? https://bugs.launchpad.net/miral/+bug/1602331
<ubot5> Launchpad bug 1602331 in MirAL "Hidden Menu windows are not restored relative to the parent" [Undecided,New]
<anpok_> alan_g: why do you have to restore the position at all? - I thought hidden surfaces get position updates in move_tree
<anpok_> will try that in a few minutes
#ubuntu-mir 2016-07-13
<anpok> alan_g: tested your branch.. now looking at other window type placements..
<anpok> +it works..
<anpok> for a tooltip .. the aux_rect() window specification parameter should be filled, shoudlnt it?
<anpok> I think that case is still wrong in the gdk backend.
<alan_g> @"for a tooltip" the aux_rect() should be used for placement
<alan_g> DId I answer your "needs info"?
<anpok> alan_g: I think what do not understand here is why window_info needs to be updated.. Is the WindowInfo object destroyed when the Window is hidden?
<anpok> Or is WindowInfo kept alive but not updated for some reason when the parent Window is moved around?
<alan_g> anpok: no... the restore_rect is only updated on state transitions.
<anpok> ah!
<alan_g> I think it will be clearer when I update the follow-up branch to fix other issues I found as a result.
<anpok> Now.. ok
<anpok> I thought you would be moving the location of WindowInfo to match the one of Window.. But instead you are preparing WindowInfo for the 'restore' step
<alan_g> Yep
<sil2100> alf: ping
<duflu> sil2100: Paternity leave :)
<sil2100> duflu: argh, damn, since he's the only admin of the new repowerd team ;/
<sil2100> duflu: thanks for the info
<sil2100> duflu: do you know till when?
<duflu> Of course. That's how these things always go
<duflu> No I don't know
<alan_g> anpok: while you still remember gtk-mir... When running (e.g.) bin/miral-kiosk --startup gnome-terminal the terminal doesn't paint the full (fullscreen) surface. Is the fix trivial?
<anpok> hm miral-kiosk does not start up for me
<alan_g> Odd. Get an error?
<anpok> ah ok .. the startup or startup-apps does not work
<anpok> http://pastebin.ubuntu.com/19259936/
<anpok> now it fails with: Error creating terminal: No screen 0 on display "Mir"
<alan_g> anpok: the pastebin looks like trying to start mesa-kms without root
<alan_g> Which is the same code that all the other Mir servers run. Kiosk isn't any different there
<anpok> so I did not manage to get gnome-terminal to start
<alan_g> anpok: gnome-terminal doesn't work as root (without fiddling). try running on X11
<alan_g> Or... hack scripts/testrun to run kiosk
<anpok> oh i get a bunch of errors with radeonsi now..
<anpok> so couldnt see it in action yet..
<alan_g> nm was just a passing thought
<alan_g> anpok: another thought: did you fix this in your gtk-mir travels? lp:1445543
<bregma> sil2100, alf is gone at least two weeks, supposed to be back 2016.08.02
<bregma> sil2100, I'm sure canonical IS can probably do something if there's an emergency....
<anpok> alan_g: something worth trying
<anpok> alan_g: still exists.. the input event reaches gdk.. from then on it is a bit unclear.
<alan_g> anpok: thanks for checking
<anpok> hmm or actually I did not check whether the event reaches the right surface..
<anpok> Now looking at a ci issue with the nested input device state event tests I added recently..
<anpok> alan_g: the way that window looks it seems to not receive keyboard focus.. maybe it got mapped to a window type not allowed to receive user input?
<anpok> alan_g: do we have something in scene report showing that?
<alan_g> anpok: I suspect not (yet)
#ubuntu-mir 2016-07-15
<alan_g> anpok: @lp:1603086 I don't see any modify_surface happening with gedit on xenial. Have I misunderstood something?
<alan_g> Hmm. I don't see a client API for that update either. So that explains why the server doesn't see a call.
<anpok> alan_g: aerhm just recreating the same surface spec .. and submitting that..
<anpok> there is a chance that the old gdk backend is not doing that..
<alan_g> anpok: AFAICK gedit/gtk-mir creates a "normal" window (which has no placement properties) and has no way (in the mir_toolkit API) to place or move that.
<alan_g> *AFAICS
<alan_g> Which API call is "and submitting that"?
<anpok> mir_surface_apply_spec
<alan_g> I don't see that call to my server - I guess that's a gtk-mir change?
<anpok> hm
<anpok> and I dont see the second position update
<alan_g> But there's no API to position mir_surface_type_normal anyway
<anpok> Ok my bug description is invalid
 * alan_g thinks this feature would be better implemented as a bufferstream
<anpok> I thought about that too
<anpok> but that means gtk needs to be aware that the gdk backend does that.. because then the tooltip is no longer a gdk window
<anpok> and the input events need to be somewhat dispatched between those two..
<aquarius_> heya, Mir peeps. I know there's been some discussion in the past about remote desktop viewing for Mir -- implementing VNC, possibly via shaders to send damage? -- and I wondered whether that discussion's moved on since last year?
<anpok> alan_g: could it be that we ignore the x/y position request in tooltips for some reason?
<alan_g> 1. it's mir_surface_type_normal; 2. mir_surface_type_tip doesn't have position properties
<anpok> it has a rectangle?
<anpok> alan_g: my version sends type_tooltip - I guess because I managed to delay the construction long enough so that all necessary properties are in..
<alan_g> That's the "zone" - "A tooltip, whenever you are hovering over a particular zone."
<anpok> oh
<anpok> lend me a hand, that needs a triple face palm
<alan_g> Yes, I think this API is confused
<anpok> aquarius_: we havent done much in that area, but now there is an API that might help. But it has not been used for that purpose yet.
<anpok> aquarius_: the wifi display support is implementing by configuring a virtual display output on the server.. the content of that virtual output then grabbed via the mirclient api for screencasting and sent off to the hardware encoder..
<alan_g> aquarius_: nothing explicit. But some of the design discussions I've had with greyback about tracking damage for wireless display could apply. (But we're a long way from implementing any of that)
<anpok> hmm if it is supposed to show up when the ponter hovers that zone - shouldnt it also be displayed .. somewhere close to that?
<anpok> pointer
<alan_g> anpok: Yes. *I* think this area of the spec is dubious. I also think we need a mir_surface_spec_set_attachment(MirRectangle* attachment_rect, MirEdgeAttachment edge)
<alan_g> But it doesn't help me test when gtk-mir sends the wrong surface type
<anpok> yup
<anpok> I could give you my debs
<anpok> amd64?
 * alan_g doesn't really want to mess with his system any more than he has already
<anpok> hmm
<alan_g> Actually, do you have a ppa to shove them on?
<anpok> there is a trello card for configuring edge attachments..
<anpok> nope
<alan_g> nm is easy enough to write a test client. And we really should have an acceptance test
<anpok> just figuring out how to upload that..
<alan_g> Don't waste time on it. I'd rather have a proper test.
<alan_g> Anyway, we don't do tooltips according to the spec either. Try mir_demo_client_tooltip in any of our servers.
<alan_g> /sigh
<alan_g> anpok: I think we need new bugs. In the revised description this is no longer about repositioning a tooltip, but about creating one and correctly implementing the hover zone. (Should the server be managing that anyway?)
<anpok> I doubt the server has to handle the zone
<alan_g> Unless... maybe it is to ensure that we don't place the tooltip over it?
<anpok> oh
<alan_g> Q: should the server or the toolkit identify "hover"?
<aquarius_> anpok, alan_g: thank you! Using the stuff that wifi display uses makes sense, although that's presumably just output, and a vnc server would need to plug into the input queue as well?
<alan_g> aquarius_: well, you were the one to mention shaders and damage. ;) Adding an input source ought to be (relatively) simple.
<aquarius_> alan_g, I'm basing the shader stuff on duflu's comment in https://lists.ubuntu.com/archives/mir-devel/2015-March/001080.html :-)
<aquarius_> myself personally, I only have the dimmest understanding of what a shader even is :)
<alan_g> I find it best to stay that way
#ubuntu-mir 2017-07-10
<alan_g> greyback: I know you're in no way responsible, but I'm not understanding some code and hope you eyes will see what I'm missing: unity-system-compositor/debian/rules has
<alan_g> 	set -ex; for python in $(shell py3versions -r); do \
<alan_g> WTF is "py3versions -r"?
<alan_g> nm found the manpage
<greyback> :)
<greyback> I am a second behind you
<alan_g> Now I still don't understand *why*
<greyback> seems to be a common method to set the python path
<greyback> https://wiki.debian.org/Python/AppStyleGuide
<alan_g> Ack. but in this context...
<greyback> that Iâm less sure about. Is python used in a script in usc somewhere?
<alan_g> Yes, at build time it is used to embed the graphics
<alan_g> But in "override_dh_install:"
<alan_g> ?
<greyback> maybe thatâs it? Trying to use standardeze to deliberately call python3
<greyback> I can see no other reason
<alan_g> Maybe, but "py3versions -i" would make more  sense to me
<alan_g> Rather than trying several versions and failing if the don't all work
<alan_g> Though, that can return several versions too. But at least they all have a chance
<greyback> no idea
<alan_g> Well, I'll just change it and see what happens. "What can possibly go wrong?"
<alan_g> greyback: this hack seems to build. Does it seem reasonable? https://code.launchpad.net/~alan-griffiths/unity-system-compositor/mir-0.27-compat/+merge/325751
<greyback> alan_g: why was it failing to build? You need to update the commit message
<alan_g> greyback: it was trying to run 3.6 which was not uninstalled
<alan_g> On artful anyway - previous versions worked
<alan_g> s/versions/series/
<greyback> ok. Change looks reasonable. USC still has CI, right?
<alan_g> I assume so. I've not actually looked. It builds in silo 2806.
<alan_g> commit message OK now?
<alan_g> If so, I'll backport to trunk
<greyback> yeah, thanks
<greyback> alan_g: CI complaining, but with overlays only, which I presume we do not care about
<alan_g> Yes, was just about to drop those from CI
 * alan_g hopes that unblocks the 0.27 release
<alan_g> Oh rats! I had the USC MP targeting lp:usc and it autolanded
<alan_g> greyback: which QtMir branch corresponds to artful source?
<greyback> alan_g: Iâve not created such a thing, we just kept lp:qtmir up with the latest release
<alan_g> greyback: there's a dependency on libcgmanager-dev which isn't in artful.
<alan_g> And that's removed from the source package
<greyback> interesting. Probably from https://code.launchpad.net/~xnox/qtmir/no-more-cgmanager-or-upstart/+merge/323036
<greyback> it didnât land, but the source package was updated nevertheless
<alan_g> greyback: <xnox> alan_g, are you missing http://launchpadlibrarian.net/316830238/qtmir_0.5.1+17.04.20170404-0ubuntu2_0.5.1+17.04.20170404-0ubuntu3.diff.gz this upload?
<alan_g> OK, so there's no definitive branch to add my patch. At least I know.
 * alan_g wonders why he's having to update packages we want to drop from artful.
<xnox> alan_g, if you have things needing an upload into artful, I am happy to review them and upload them into artful direct with dput.
<greyback> alan_g: yes, why are you?
<xnox> alan_g, that should be quick enough without any ci/bzr/branches
<xnox> is it failing to build from source now?
<alan_g> xnox: yes, FTBFS
<xnox> greyback, the AA team / foundations are still in progress identifying and removing things in order. Because we do not want to have uninstallable packages in the archive at any point in time, because britney goes crazy and replaces all broken packages with a different set of broken packages.
<greyback> xnox: understood
<xnox> alan_g, and you have a fix that you can give to me via paste.ubuntu.com? =)
<alan_g> greyback: USC and qtmir are in artful/universe. They need rebuilding with Mir 0.27 for that to clear proposed
<alan_g> xnox: yes
<xnox> alan_g, please pastebinit =)
<xnox> $ pastebinit foo.diff
<xnox> for the win =)
<alan_g> http://paste.ubuntu.com/25062216/
<xnox> alan_g, cool, will apply and upload to both qtmir and qtmir-gles to unblock your migration in a second.
 * alan_g wonders if all his hacking has confused bileto
<alan_g> It's a wonderful system when everything works...
#ubuntu-mir 2017-07-11
<alan_g> duflu: thanks for doing the 0.27 admin
<duflu> alan_g, np, otp (aged care :P)
<xnox> alan_g, all migrated \o/
<alan_g> xnox: yes, thanks for all the help yesterday!
#ubuntu-mir 2017-07-12
<RAOF> Huh.
<RAOF> Do none of our tests test that mir_connection_allocate_buffer actually allocates a valid buffer?
#ubuntu-mir 2017-07-13
<AdamH_> Gents, is there a known issue with screen rotation using mir/mir-kiosk? Seems to ignore virtual framebuffer settings
<alan_g> AdamH_: screen rotation in Mir is controlled by the display configuration. What do you mean by "virtual framebuffer settings"?
<AdamH_> Been using the following on Ubuntu Core on a rPi3 to  change the screen rotation but mir-kiosk doesn't use the same echo 3 | sudo tee /sys/class/graphics/fbcon/rotate_all
<AdamH_> Will have to have a look at the snaps to see where I can change this in mir conf
<alan_g> AdamH_: there's no config option in miral-kiosk to change the orientation. It would need a client (e.g. mirout) to set the orientation.
<AdamH_> alan_g: Thanks will do some digging
