#ubuntu-mir 2013-04-15
<RAOF> Woot!
<RAOF> Mir should be buildable in the PPA again!
<duflu> RAOF: Awesome-tastic
<duflu> !
<duflu> RAOF: Do we need more Mesa rebuilding?... https://bugs.launchpad.net/mir/+bug/1169022
<ubot5> Launchpad bug 1169022 in Mir "[regression] Mir cannot start any more (std::exception::what: Failed to initialize EGL display)" [Critical,New]
<RAOF> duflu: You need the mir6 mesa building in the PPA as we speak.
<duflu> RAOF: Kay,t a
<duflu> ta
<RAOF> duflu: Should be good to go now, unless you're on i386
<duflu> RAOF: Confirmed all fixed
<duflu> RAOF: Would it make sense to create a new series in the Mir project for Mesa, with milestones "mirN" etc?
<duflu> Then we could say where Mesa problems are fixed
<RAOF> \
<RAOF> Maybe?
<duflu> RAOF: How about I do it and we see if it makes visual sense?
<RAOF> The problems that I'm aware of have been fixed pretty promptly, which makes documenting when they're fixed less useful.
<duflu> RAOF: It's useful to clarify that "mir" bugs are not problems in lp:mir branch, or the trunk series
<duflu> Leaving milestone blank is ambiguous so I'd like to fill it in
<duflu> *clarify when
<RAOF> Even when they're "fix released"?
<duflu> RAOF: Yeah it looks too much like a mistake unless there's a milestone
<duflu> RAOF: Where does the Mesa branch live?
<RAOF> github.com/RAOF/mesa
<duflu> Oh, umm, hmm
<duflu> RAOF: Done. You don't have to do anything. It just helps me keep bugs tidy... https://launchpad.net/mir/mesa
<duflu> RAOF: Thanks for all your Mesa fixing today. It's nice to have a working platform again :)
<RAOF> Heh.
<RAOF> Maybe we can have a fully-working XMir platform tomorrow!
<duflu> When did it stop working?
 * duflu hasn't looked in a while at xmir
<RAOF> With the use-dma-buf change.
<alan_g> alf_, duflu : Good morning.
<duflu> alan_g, good afternoon
<alan_g> I've just tried building trunk...
<alan_g> Linking CXX executable ../../bin/mir
<alan_g> /usr/lib/gcc/i686-linux-gnu/4.7/../../../i386-linux-gnu/libEGL.so: undefined reference to `mir_egl_native_display_is_valid'
<alan_g> What has changed?
<duflu> alan_g: Fixed. Just update from the PPA
<alan_g> duflu: thanks
<duflu> alan_g, https://bugs.launchpad.net/bugs/1167828
<ubot5> Launchpad bug 1167828 in Mir "lp:mir r582 FTBFS on fully updated raring (mir staging 0.0.2bzr580raring0)" [Critical,Fix released]
<alan_g> Anything interesting been happening?
<alf_> alan_g: Hi! How was the conference?
<alan_g> alf_: a lot of fun. (Except my talk was plagued by equipment failures.)
<mlankhorst> morning
<duflu> mlankhorst: Morning/afternoon
<alan_g> mlankhorst: morning
<alf_> alan_g: Nice (for the fun part) :)
<alan_g> alf_: there were a few people that wished they could be employed to work on mir after my talk. (We can feel smug.)
<alf_> alan_g: :) Does ACCU provide recordings of talks?
<alan_g> Some are recorded (mine was - or at least it was supposed to be). They're not online yet.
<duflu> The grass is always greener... and sometimes it really is
<alan_g> Some grass is brown and some has blown away. ;)
<duflu> Oh I just noticed... In the Android headers Google has dual licensed a few of them. There are separate copies with different licenses (GPL and Apache). Seems Google doesn't like LGPL either (like IBM)
<alan_g> duflu: I don't like LGPL either - but it exists
<kgunn> morin', welcome back alan_g !
<alan_g> morning kgunn - how's it been going?
<racarr> Morning
<racarr> *cringe at light*
<alan_g> racarr: afternoon
<racarr> alan_g: Did you enjoy your talk and conference?
<alan_g> racarr: I did. (Although having a mini-displayport/VGA adaptor break 15min before talk and my reserve/netbook crash during the talk didn't make it easy)
<racarr> alan_g: XD  I think that happens everytime
<alan_g> racarr: a first for me
<alf_> alan_g: kdub: I am considering renaming Shell::shutdown() (and all other related shutdown methods) to ::unblock_clients(), since I need to use it while pausing/resuming. Objections?
<racarr> Updates to ease-shell-configuration xkbcommon-mapper and rebuild-input-focus-selection
<alan_g> alf_: no objection to renaming for more general use, but not convinced by your proposal. Don't we want to block clients while pausing?
<alf_> alan_g: Yes. The plan is to stop the communicator when pausing, and restart it when resuming. My current approach is to stop() the io_service processing, so new connections/requests will block until we resume. However, for this to work I need to stop all the io_service threads, which poses the same problems with our shutdown sequence (a client may be blocked waiting for a buffer), hence I need to use the same mechanism for unblocking the client
<alan_g> alf_: so the name "unblock_clients()" isn't quite the right one?
<alan_g> alf_: is it more like "interrupt_blocked_calls()"
<alf_> alan_g: It's step two of the process: 1. stop io_service 2. unblock pending blocked client requests and allow them to finish 3. wait for io_service threads to exit
<alan_g> alf_: actually, could such calls be retried from within the frontend (leaving the client blocked)?
<alan_g> Or am I getting too clever?
<kdub> good morning!
<kdub> welcome back alan_g
<alan_g> Good afternoon
<alan_g> kdub: thanks. Hope things went smoothly in my absence?
<alan_g> alf_: or "force_blocked_calls_to_complete()"
<alf_> alan_g: @retrying, For our current approach and needs, I think this would complicate the situation
<kdub> alan_g, smoothly enough :)
 * kdub wonders if the accu talks will be posted anywhere
 * alan_g knows his was recorded, but it isn't posted yet
<alf_> alan_g: All of the suggestions are much better than "shutdown", I don't have a favorite :)
<alan_g> kdub: racarr - want to help alf_  find a good name? ^^
<racarr> status: Refactoring interface between shell and InputDispatcherController to fix some things.
<alf_> alan_g: kdub: Shell::unblock_clients(), Shell::interrupt_block_calls(), Shell::force_blocked_calls_to_complete(), Shell::unblock_client_requests(), Shell::force_block_client_requests_to_complete() ...
<kdub> alan_g, cool! hopefully they'll pop up somewhere over the next month
<kdub> alf_, alan_g still getting my bearings back about that problem :)
<racarr> hmm
<alf_> kdub: I just want to give Shell::shutdown() (and friends) a more general name because I need to use it also while pausing/resuming
<alf_> racarr: ^^
<racarr> Shell::suspend_clients ?
<racarr> Session::suspend
<racarr> etc
<racarr> makes it sound disciplinary XD
<alf_> racarr: I need to do the opposite of suspend :)
<racarr> ohhhh
<racarr> I see
<racarr> hmm
<alf_> status: investigating bugs, implementing proper communications management when pausing/resuming
<alan_g> status: catching up on MPs that appeared over last week.
<alan_g> force_requests_to_complete()
<kdub> status, hopefully moving my mp forward, working to some bug fixes, maybe doing some android display logging this afternoon
<alf_> alan_g: I like this, sold!
<alan_g> \o/
<alan_g> alf_: if we ever decide to support automatic retry we can have force_requests_to_retry()
<alf_> alan_g: yes
 * kdub wonders if there's anything i can do to ease the review of server-render-window... maybe a quick hangout with anyone who's reviewing?
<racarr> kdub: I am not revieing yet but will join a hangout if there is one going on to discuss it
<racarr> hit a nice stopping point so unless anyone wants to hangout or anything before
<racarr> Europe umps off
<racarr> I am going to go for a walk and get some sunshine :) already up for 4 hours.
<kdub> sunshine? in san francisco in april?
<racarr> It's beautiful!
<racarr> Windy though
<racarr> alan_g: We can talk about the server configuration if you want...I don't know. I'm not really seeing a hierarchy that can make it better for the class users
<racarr> just that the current code is becoming a mess
<alan_g> racarr: It's a bit close to EOD for me - my wife is calling. I'll try to come up with an approach before you wake up tomorrow.
<racarr> Ok! See you tomorro
<racarr> w
 * alan_g wishes he wasn't first line support for a WindowsXP(Dutch) PC.
<racarr> Back. and back to the InputDispatcher
<kdub> rsalveti, whoo, raring phablet images!
<rsalveti> kdub: yup, soon to be the official (hopefully later today/tomorrow)
<kdub> bumping all the mir android scripts to raring then! :)
<kdub> racarr, is xkbcommon-mapper good to go?
<racarr> kdub: Yeah!
<racarr> kdub: I just flipped it to approved
<racarr> now you can type fun things like !@#$%^&()_+!
<kdub> yay!
<thomi> morning everyone
<kdub> hello thomi
<thomi> o/
<thomi> any Mir/QE emergencies I should know about?
<kdub> thomi, no emergencies i know of, i sent a funny failure that might be of interest on my friday
<thomi> kdub: I saw that, thanks. I haven't seen it again, so I assume it was some network issue in the QA lab
<kdub> yeah, thats all it looked like to me as well
<thomi> better mir benchmark graphs are up - still need that mesa bug fixed before they show anything useful though: http://people.canonical.com/~thomir/
<thomi> there was a bug in the graph generation script - pyplot doesn't automatically order your x axis in date order :-/
<kdub> hey racarr, does this quick mp look good to you? https://code.launchpad.net/~brandontschaefer/mir/replace-deprecated-auto-ptr/+merge/158994
<racarr> ugh I finished my
<racarr> rework of the DispatcherController
<racarr> and am happy with how the code came together, but somehow...something is going wrong on the integration test driving it all :(
#ubuntu-mir 2013-04-16
<racarr> Derp! I was using
<racarr> sequenced expectations to wake up a series of wait conditions
<racarr> but didn't actually sequence the expectations
<racarr> Got a free bonus from this derp of spending a good hour reading InputDispatcher.cpp *facepalm*
<RAOF> Whoops!
<racarr> Any opinions on https://code.launchpad.net/~robertcarr/mir/rebuild-input-focus-selection/+merge/158505 ?
<RAOF> racarr: Looks OK to me.
<racarr> RAOF: Ok. Thanks :) Once I finish my branch (needs a few fixes...but after 11 hours it is...not computer time) will switch this one to approved if no one finds anything
<alan_g> duflu: could you re-review https://code.launchpad.net/~kdub/mir/fix-shutdown-bug/+merge/158710 - thanks
<duflu> alan_g: Done. Sorry but I've obviously been busy with my own branches today
<alan_g> duflu: np - was an easy one to clear
<duflu> Wow, gcc is so bad at error messages. I just spent 10 minutes trying to decipher various errors. None of which told me the truth -- missing closing parenthesis
<duflu> Almost switched to clang
<alf_> duflu: I've heard that g++-4.8 has improved error messages a lot
<alan_g> alf_: I've heard that too. (From one of the developers. ;)
<alan_g> Actually, thinking about it - from one of the *library* developers, so that's more convincing.
<alf_> alan_g: Regardless of how much it has improved, at least (and at last) there is some interest in it... the benefits of competition :)
<alf_> alan_g: a.k.a. why even wayland supporters should be excited about Mir ;)
<alan_g> alf_: I don't think the mir protocol is in the same solution space as Wayland.
<alf_> alan_g: Perhaps not, but they are *conceived* as being competing technologies, and that's enough to drive competition.
<duflu> alan_g: Could you please ignore my branches for the next hour or two. Otherwise my day will never end :)
<alan_g> duflu: Sure.  Alternatively, you could also ignore my comments for the next hour or two. ;)
<duflu> alan_g: Yeah I normally close my email for the last hour or so of the day. Just missed the cut-foff
<duflu> cut-off
<alan_g> kgunn: Good morning
<kdub> good morning! status, bumped our scripts to raring, trying to think of a way to ease reviewing my display branch, and working on getting galaxy nexus to look nice again
<alf_> status: working on vt switching communications management, currently blocked on improving our test infrastructure so I can perform needed tests
<alf_> kdub: alan_g: racarr: It seems that all this time our display server test process (launch_server_process(...)) didn't exit() after the server finished. I am trying to make it exit(), but it seems a lot of tests depend on the broken behavior in some way or another.
<alan_g> alf_: "this time"?
<alan_g> alf_: "all this time"?
<alf_> kdub: alan_g: racarr: I mean "since the beginning" :)
<alan_g> alf_: I find that hard to believe - I occasionally saw zombi server processes near the beginning, but AFAIK that got fixed.
<alan_g> alf_: What makes you think it isn't exiting?
<alf_> alan_g: There is no exit() after the server finishes, so after finishing, the server process continues executing into the test code. In tests up to now this wasn't visible because we let the test infrastructure kill the server process after the test. However, in a test I am working on, the server is terminated during the test and all of this becomes apparent.
 * alan_g looks
<kdub> hmm
<alan_g> alf_: why doesn't it exit in tear_down_clients()?
<alan_g> alf_: I guess you meant: "all this time the server exited in tear_down_clients() - not in launch_server_process() where I'd now like it to".
<alf_> alan_g: s/tear_down_clients/tear_down_server/?
<alan_g> alf_: I'm still not following
<alf_> alan_g: kdub: hangout?
<alan_g> Was just about to suggest it
<kdub> sure
<alf_> alan_g: kdub: creating one
<alf_> alan_g: kdub: https://plus.google.com/hangouts/_/ba672682fda0c13019ca0531e91417dc0ce83b39?authuser=0&hl=en
<racarr> Morning
<kdub> hello racarr
<racarr> Hey :)
<racarr> ugh
<racarr> was finally ready to propose my new input dispatcher controller stuff and
<racarr> realized I based it off ease-shell-configuration
<racarr> because it required changing session manager arguments
<racarr> only 12 conflicts to remove it!
<kgunn> tvoss: can you sanity check my whiteboard entry on this bp ?
<kgunn> https://blueprints.launchpad.net/ubuntu/+spec/client-1303-unity-ui-windowmanager
<tvoss> kgunn, tomorrow fine with you?
<kgunn> sure :)
<tvoss> kgunn, cool, thx
<racarr> https://code.launchpad.net/~robertcarr/mir/reflow-input-focus-selection/+merge/159225 new DispatcherController :)
<racarr> couldn't get bzr to cooperate so had to manually back out ease-shell-configuration
 * mlankhorst couldn't get bzr to work, at all, now using git-bzr :)
<thomi> morning
<racarr> MORNING!
<racarr> *descends in to hunger psychosis as lunch becomes later and later...*
<racarr> ah phew its here
<kgunn> robert_ancell: i'd love to make the team meeting...but had another 5am start.
<robert_ancell> kgunn, fair enough!
<kgunn> i'll be on later during baseball practice....gonna go eat right now
#ubuntu-mir 2013-04-17
<RAOF> Grr. Do mir_demo_client* work for anyone else on the current staging PPA?
<RAOF> They all fail for me in assert(mir_surface_is_valid()), and XMir also dies with a garbage MirBufferPackage
<bryce> RAOF, I updated to the latest staging ppa on my intel box last Friday, but the screen was just static noise
<bschaefer> RAOF, yeah, im getting the same thing :(
<bschaefer> was working just before I pulled some new changes to lp:mir
<bschaefer> RAOF, looks like rev 590 caused the issue for me
 * kdub just merged lp:mir onto my working branch, looks like i see the same thing on android
<kdub> i'll try to confirm the rev590...
<kdub> bschaefer,  yep... something happened in 590
<bschaefer> kdub, its a large branch soo hopefully it'll be easy to track down
<racarr> RAOF: Err.  so I had garbage mir buffer package
<racarr> but then I built mesa with usa-dma-buf which you still didn't merge to the main github branch
<racarr> and it worked fine
<racarr> oh 590
<RAOF> I actually reverse-merged that (ie: merged egl-platform-mir into -use-dma-buf), and the mesa packages in the PPA aren't built out of either of those branches anyway.
<racarr> RAOF: New theory...something crazy due to a bug
<racarr> try with --enable-input=true
<racarr> the_input_focus_selector needs to
<racarr> check the options and ahve a null implementaiton
<racarr> like the input manager does
<racarr> trunk right now with --enable-input=false (the default) is starting up a malformed input stack
<racarr> and who knows what happens
<racarr> um.
<racarr> I'll propose a branch to fix it soon. I actually need to run and do some errands though
<RAOF> racarr: Correct guess!
<kdub> ok, trunk with --enable-input=true works for me too
<racarr> ok
<racarr> sorry about that
<kdub> let's set the topic until its changed
<racarr> I don't remember how to get my +o back
<racarr> but! I really do want to run some errands because I need to be somewhere by 7
<racarr> ill be back later though, and even later for team meeting :)
<racarr> Cheers!
<kdub> well, until the proper fix for --enable-input=false is in
<kdub> let's change the default
<kdub> https://code.launchpad.net/~kdub/mir/server-startup-bandaid/+merge/159270
<kdub> bandaid branch^^
<bschaefer> kdub, I can approve that for you, if you don't mind
<kdub> bschaefer, sure
 * bschaefer isn't sure what the procedure for MPs are in lp:mir
<bschaefer> approved
<kdub> bschaefer, one reviewer +1, plus no blocking comments
<bschaefer> kdub, sounds about normal :)
<kdub> bug report: https://bugs.launchpad.net/mir/+bug/1169781
<ubot5> Launchpad bug 1169781 in Mir "mir after rev590 won't run without --enable-input=true" [Critical,Confirmed]
<kdub> someone with ops set the /topic to mention to run with --enable-input=true in the meantime?
<duflu> kdub: I always assumed it was 2+ reviewers?
<duflu> No wonder my proposals linger :)
<racarr> I think its understood as +2 for nontrivial proposals
<racarr> but that's just how I have been thinking
<duflu> Yeah, trivial or time-critical stuff would be only 1
<duflu> time-critical means when something is broken and it's holding us up
<racarr> https://code.launchpad.net/~robertcarr/mir/fix-disabled-input/+merge/159277
<racarr> exists
<RAOF> racarr: Code looks fine; checking that it actually works, too :)
<robert_ancell> "Internal compiler error: Error reporting routines re-entered."
<robert_ancell> seriously GCC?
<duflu> Error during reporting of the first error? Nice
<smspillaz> robert_ancell: std::make_shared ?
<robert_ancell> smspillaz, it looks like it. I'm trying to reduce the program to create a test case
<smspillaz> robert_ancell: known bug
<smspillaz> https://bugs.launchpad.net/ubuntu/+source/gcc-4.7/+bug/1165732
<ubot5> Launchpad bug 1165732 in gcc "GCC 4.7.3 internal compiler error when using std::make_shared" [Medium,Confirmed]
<smspillaz> robert_ancell: if you have a class that would fail to have its constructor compiled (eg, because it was private or had pure virtual methods) then gcc freaks out when you get that inside of a template
<robert_ancell> smspillaz, ah
<smspillaz> robert_ancell: we should probably put that in the channel topic, I've seen four different people hit it and then start to write testcases :)
<robert_ancell> ha!
<RAOF> And, of course, the solution is to build with clang, which provides non-terrible error messages. :)
<smspillaz> speaking of clang
<smspillaz> duflu: needed to ask you something
<smspillaz> duflu: remember when we made the templates extern for compiz plugins?
<smspillaz> (eg PluginClassHandler, WrapableInterface etc)
<racarr> RAOF: Thanks :)
<racarr> robert_ancell: It's a known bug I believe that is fixed upstream according to some mailing list post I read or something
<robert_ancell> racarr, yeah, the bug trail shows its a regression that's been fixed
<RAOF> It's a regression from 4.6, and it's fixed in 4.8 apparently.
<duflu> smspillaz: Yeah I remember
<smspillaz> for some reason (dunno why yet) if you have liba.so which is linked to libb.so, both of them are not in the system library path, liba.so has a template definition that libb.so needs, if you dlopen libb.so but not liba.so it doesn't pull in the template
<duflu> (sorry, am outside occasionally talking to painter)
<smspillaz> no problem :)
<smspillaz> duflu: any ideas ?
<smspillaz> nm -S says its defined as "W" in liba.so
<smspillaz> and U in libb.so
<duflu> smspillaz: Yeah (W)eak symbol
<smspillaz> cool, so what do I do in order to get a definition in libb.so ?
<duflu> I don't follow the problem yet
<duflu> Hang on
<smspillaz> I'll try and write a simple testcase
<smspillaz> (this is just my understanding of the problem by looking at compiz plugins)
<smspillaz> ohhhh hmm
<smspillaz> I wonder if the weak symbol is a template that never got defined
<smspillaz> just declared as "yeah this exists"
<duflu> smspillaz: I see. Yes. You don't want to accidentally pull in symbols from indirect libraries, for safety. I don't know how you would even if you wanted to.
<smspillaz> and then the actual definition is some other symbol
<duflu> (W)eak means defined, but can be rebound at runtime
<duflu> smspillaz: Your problem might be less obvious. Only an explicit instantiation will create all methods for the class. Otherwise the default is to only create what you used the first time. External users might depend on some methods that do not exist
<smspillaz> duflu: well, in this case they're directly linked
<smspillaz> duflu: well, I don't know if its that. If for example, I dlopen both liba.so and libb.so then libb.so gets the definition
<smspillaz> but its perplexing, because libb.so is definitely linked to liba.so, its just in a custom rpath (eg $prefix/lib/compiz)
<duflu> smspillaz: Dependencies only go one way. If A links to (depends on) B, then dlopen(B) will indeed be missing everything that A provides
<smspillaz> duflu: ah, sorry, B is linked to A
<duflu> smspillaz: Yeah you need dlopen flag RTLD_GLOBAL (default is RTLD_LOCAL for safety)
<duflu> You're usually meant to dlsym functions you need and not implicitly gain symbols from plugins loaded
<smspillaz> duflu: hmm, what do you mean by "implicitly gain symbols from plugins loadeD"
<smspillaz> *loaded
<duflu> smspillaz: I recommend putting common template instantiations in a separate library, or duplicating them safely with -Bsymbolic
<smspillaz> duflu: I was going to suggest that
<duflu> smspillaz: Default is RTLD_LOCAL so you gain NO symbols from the load, unless you grab them explicitly (dlsym())
<smspillaz> duflu: so you'd suggest a libcompiz_opengl_interface.so in the $prefix/lib ?
<duflu> RTLD_GLOBAL however means you get all symbols from the loaded library, which might be used in a later dlopen
<smspillaz> duflu: I don't think the problem is that I'm trying to get symbols from a library that I've opened and have not dlsym'd yet, rather its getting symbols from a another library that the library I'm dlopening is linked to
<smspillaz> (though maybe that's what you're referring to)
<duflu> smspillaz: The big risk is: Load plugin A, load plugin B, unload plugin A. You could have B accidentally bound to symbols (no longer addressible)
<duflu> .. bound to symbols from the unloaded A
<smspillaz> duflu: I don't see why that would arise if B was linked explicitly to A
<duflu> smspillaz: Because the dynamic loader only allows one copy of each symbol name. If one already exists from an earlier plugin then the later plugin binds to that copy
<duflu> So you either need a universally unique library for common symbols, or build with -Bsymbolic to tell the dynamic loader that each plugin should get private copies
<smspillaz> oh I see, so we initially get the symbols from loading A, then B, which is linked to A doesn't bring the symbols in, then A gets unloaded and the symbols are gone
<smspillaz> duflu: iirc we had some trouble with -Bsymbolic. I'll try the separate library approach
<duflu> smspillaz: -Bsymbolic is _only_ a problem if your classes have static members which are unsafe to have multiple copies of
<duflu> It also causes code bloat, but maybe not so bad
<duflu> smspillaz: On the other hand, explicit instantiation in a separate library means you instantiate all methods (most of which you never use). And that can cause worse code bloat
<smspillaz> duflu: well, we definitely use all the methods
<duflu> That's OK if it's your own template (not from the STL)
<smspillaz> yep, its our own template
<smspillaz> duflu: okay, I think I'll go with that then.
<duflu> smspillaz: If it's all opengl-specific then you don't need a new library. Just instantiate it in the opengl plugin
<smspillaz> been trying to fix this long-standing issue where loading plugins effectively causes other plugins to be implicitly loaded
<smspillaz> duflu: well, see that's the thing. we do instantiate it in the opengl plugin
<smspillaz> (or at least I think we do)
<duflu> And remember to "extern" the template in public headers
<duflu> Or else you'll have more copies
<smspillaz> duflu: yeah, its already extern'd
<duflu> smspillaz: I think implicit loading on dependent plugins is a good thing. You shouldn't have to know what A depends on if all you want to load is A
<smspillaz> duflu: the problem is optional dependencies
<duflu> Oh, the optional ones
<smspillaz> eg, I need to be able to set up a test framework so that we load move, but move doesn't pull in opengl
<smspillaz> but move implicitly does that because it checks if opengl is available
<smspillaz> ... by pulling in opengl
<smspillaz> which then causes opengl to be loaded
<smspillaz> again implicitly
<smspillaz> its a bit nasty
<duflu> I would like to say it should be a simple flag in a simple loading call: CompizLoadPlugin(foo, NO_OPTIONALS)
<duflu> But I remember it's not the simple
<smspillaz> duflu: well, the way it works at the moment is that it calls PluginClassHandler <GLWindow, CompWindow>::get ()
<smspillaz> which *should* go to the vtable and then return null if it isn't loaded
<duflu> Arg. I'm having terrible flashbacks
<smspillaz> except that I fixed a problem several years ago which had the side effect of short-circuiting that
<smspillaz> haha
<smspillaz> anyways, maybe the problem is that we never really explicitly instantiated that template anywhere in opengl
<duflu> In an ideal world, a plugin system should start with simple C functions which you look up by dysym. And then pretty quickly when all succeeds you can get a pointer/reference to higher-level objects
<duflu> *dlsym
<smspillaz> duflu: that's basically how it works right now
<smspillaz> (or at least, that's the entry point from core)
<duflu> Interesting trivia on the subject of bloat from template instantiation... quite often it is the symbol name itself that wastes the most space. Not the code. It's not uncommon for mangled template names to be hundreds of characters long.
<duflu> Made worse by overuse of namespaces and default parameters like allocators
<smspillaz> duflu: heh
<smspillaz> _ZN5boost7variantIbifSsNS_17recursive_wrapperISt6vectorItSaItEEEENS1_I10CompActionEENS1_I9CompMatchEENS1_IS2_IN10CompOption5ValueESaISB_EEEENS_6detail7variant5void_ESH_SH_SH_SH_SH_SH_SH_SH_SH_SH_SH_E8assigner11assign_implIS5_EEvRKT_N4mpl_5bool_ILb0EEESQ_NSP_ILb1EEE.isra.230
<smspillaz> case in point
<racarr> smspillaz: How did you guess my password
<smspillaz> oh crap
<duflu> Yes, and for some reason compilers need to emit that string _many_ times in a single object
<smspillaz> I've been found out
<smspillaz> racarr: ahaha, that'd be awesome "my password is a mangled template symbol"
<smspillaz> -EUNGUESSABLE
 * duflu wonders what _SH_SH_SH_SH translates to
<smspillaz> the compiler freaking out
<smspillaz> duflu: I feel like lots of these problems could be solved by having a binary format specifically designed to handle C++
<smspillaz> like, for once, being able to have aliases for template parameters
<duflu> smspillaz: Kinda. It still needs to be copy and pasteable sometimes
<smspillaz> like 43d452 = int, string, char, bool
 * smspillaz notes that the majority of C++'s problems come from trying to be bolted on top of a C-like infrastructure
<smspillaz> the solution is clearly to abolish C *waits for pitchforks to arrive at door*
<duflu> More generally a lot of problems would be solved by well-defined symbol/linkage rules in the language definition. Some languages do that
<smspillaz> you mean Go, right ? :p
<duflu> Java, mostly
<duflu> And probably Go
<racarr> I heard all the cool kids were using rust last week
<smspillaz> duflu: so I'm still wondering, even if I explicitly instantiate the template in liba, have it declared extern, then link libb to liba, I don't get the definition on dlopening libb
<duflu> smspillaz: You may not "get the symbol" if it wasn't already in use at run-time before the dlopen
<duflu> Hmm
<duflu> smspillaz: As always, link with -zdefs (CFLAG -Wl,-zdefs) to tell you what you've forgotten at build time
<duflu> Things will be clearer if the linker is giving you errors and no binary
<smspillaz> duflu: doesn't seem to be complaining :/
<duflu> smspillaz: That's extra weird. It means the linker has found all symbols resolved at build time. And yet some are missing at run time?
<smspillaz> yeah
<smspillaz> duflu: also I wrote a testcase without rpath and it works fine
<duflu> smspillaz: Whatever is missing symbols needs to be linked with -zdefs
<smspillaz> I'm going to try "installing" the testcase and installing the plugins somewhere unconventional
<smspillaz> so that we'll have to use rpath
<smspillaz> curious, that works the way you'd expect too
<robert_ancell> racarr, around?
<duflu> smspillaz: Remember make install with CMake actually strips rpaths :P
<smspillaz> I know, I'm asking it not to in the testcase :)
<smspillaz> though I still can't reproduce this problem :(
<smspillaz> and there's nothing in the link flags that stands out
<racarr> robert_ancell: Halfway
<racarr> will be around and focused at meeting time :)
<racarr> around but surrounded by noise atm
<robert_ancell> argh, we have shell sessions and frontend sessions. Very confusing
<robert_ancell> racarr, should SessionContainer contain shell:Sessions not frontend::Sessions?
<robert_ancell> I need to focus a session by name for the system compositor (removing the hacky lightdm code) but it seems really hard to iterate over the current shell sessions
<robert_ancell> racarr, and SessionContainer has virtual methods for insert and remove, but it's a concrete class - what is the point of the virtual methods?
<racarr> robert_ancell: Yes it should contain shell::Sessions I think
<racarr> it's a little difficult to do without dynamic casts somewhere :) there is one now...it could move and you could have shell::Sessions everywhere
<racarr> I think the point of the virtual methods is for mocking
<robert_ancell> duflu, alf_, meeting
<smspillaz> duflu: ah frick, I think I've found the problem
<duflu> smspillaz: OTP
<smspillaz> np
<smspillaz> its being linked to the wrong library, rpath madness it seems
<smspillaz> fixable
<smspillaz> \o/
<duflu> kdub: Done now?... [kdub] transition android build to raring: TODO
<duflu> Oh, no kdub
<kdub> in progress
<duflu> smspillaz: Cool. A simple answer
<smspillaz> duflu: though its scary. for some reason if you build with rpaths cmake will put $prefix/lib into your rpath as well as any INSTALL_RPATH hint you add
<smspillaz> and considering the plugin names are quite generic, there's a real risk of accidentally pulling in a library we didn't intend to
<smspillaz> anyways, -EWRONGCHAN :p
<RAOF> Wheee! We should run the glmark2-mir benchmarks on my radeon system - it's happy to do 10FPS on the terrain bench, for example :)
<duflu> RAOF: Yeah that's the only one I got less than 60 FPS. Twas 59
<RAOF> The trick is asking a 2-gen-old low-power card to render at 1920x1200 :)
<RAOF> Woot! I win the "it-doesn't-work-if-you-try-and-dereference-an-fd-as-a-pointer" award!
<mlankhorst> :X
<duflu> tvoss: mir_connection_create_surface ? mir_create_surface? mir_connection_createsurface :)
<tvoss> RAOF, \o/
<tvoss> duflu, put my vote in for mir_connection_create_surface
<tvoss> duflu, it's verbose but clear
<duflu> I thought as much
<RAOF> In my defence, passing fds as "void *handle" is unnecessarily obscure.
<duflu> I'm trying to think if there are any single verbs to describe a surface being created :)
<tvoss> RAOF, it forces the API user to really know what's going on ... which might be considered a good thing
<alf_> RAOF: which branch from mesa-mir (github) is the latest? egl-platform-mir-use-dma-buf ?
<tvoss> duflu, genesis ... not a verb, but shiny nevertheless :)
<RAOF> alf_: Yes. The PPA is built from mir-ppa on github, though.
<duflu> tvoss: Yeah you catch my drift
<alf_> RAOF: hmm, I think egl-platform-mir-use-dma-buf is missing a commit (the last from branch egl-platform-mir)
<RAOF> alf_: Quite true; you'll find them there now.
<alf_> RAOF: excellent, thanks!
<alan_g> tvoss: I was wondering if the guidelines you adopted from mir were online and came across something subtly different: http://unity.ubuntu.com/wp-content/uploads/2012/03/cppguide.html - is there a plan for convergence?
 * alf_ notices that the input components in mir are very chatty...
<tvoss> alan_g, those are the old ones, good catch
<tvoss> alan_g, will check how to update those guidelines
<alan_g> tvoss: you're welcome. (I followed a link from https://wiki.ubuntu.com/Unity/CodingStyle which might also need maintenance)
<alf_> duflu: alan_g: tvoss: Any objection to changing mir_socket to be 777, so that other users can connect?
<duflu> alf_: I was thinking that. It would be useful now, but creates security problems later
<alf_> duflu: what security problems?
<tvoss> alf_, fine with me
<duflu> alf_: Any remotely logged in user can start a client and it renders on your desktop
<duflu> ... or any daemon (non-root) can spawn surfaces on your desktop
<alf_> duflu: hmm...
<duflu> alf_: And later... any daemon could screen-scrape (if clients are given such power in future)
<alan_g> alf_: Is this something that would need to differ between session and system compositing?
<duflu> alf_: Looks like the Ubuntu/Linux approach is to limit access to group "video" which I suspect you become a member of on login (?)
<alan_g> I.e. should it be configurable?
<duflu> alan_g: Probably configurable eventually. But right now we just don't want any gaping security holes to forget about
<alf_> duflu: the "video" approach is sensible
<duflu> alf_: Seems to be how /dev/dri/* works
<alf_> alan_g: we probably want only the user owning a session to be able to render to it, whereas the system compositor needs to accept connections from various users (from their session compositor)
<alan_g> alf_: so "video" makes sense for system compositing, what we have now for session?
<alf_> alan_g: that sounds right
<alf_> duflu: do you get video permissions only when you log in locally?
<duflu> alf_: Hmm, actually I'm not in group video. That might not work
 * duflu looks at X
<alf_> alan_g: duflu: perhaps we should just ask the security team or the X team, I am sure they have this figured out
<alan_g> alf_: adding oneself to "video" was a hack you gave me to get mir working in the early days. It isn't a default.
<alf_> alan_g: right
<duflu> alf_: X seems to chmod 777 and implements its own security...
<duflu> srwxrwxrwx 1 root root 0 Apr 16 09:04 /tmp/.X11-unix/X0
<alf_> duflu: right, with xhosts etc
<duflu> Yep
<duflu> That's annoying. I was sure some groups were assign dynamically and video was included
<duflu> +ed
<alf_> duflu: alan_g: tvoss: I leave the mir_socket as it is for now, until we discuss a bit more and get some feedback from the security team
<tvoss> alf_, do you take care of reaching out to the security team?
<tvoss> RAOF, still around?
<alf_> tvoss: I am not sure who they are, so I was planning on letting Robert A. know and handling this
<tvoss> alf_, yup, fine with me
<AlanBell> is there some documentation on what Mir will be able to do from a user perspective?
<AlanBell> I can see lots of stuff about the low level detail of how it works, but will it do stuff like full screen zoom, text tracking zoom, multiple desktops on a cube or anything like that?
<AlanBell> all I can see in the documentation is that it will do drop shadows on windows
<duflu> AlanBell: Mir is no yet complete enough to answer those questions, or to be interesting at all for "users"
<AlanBell> sure, but are these things going to be what it is for?
<duflu> AlanBell: Yes, that kind of thing. But it's a long way from having such special effects yet. In the mean time we have Compiz
<AlanBell> how about colour management, is that in the plans?
<RAOF> tvoss: Yes.
<RAOF> AlanBell: I'd like to make colour management happen, yes.
<RAOF> alf_: The system compositor never accepts any sessions from anything but the display manager (in this case, LightDM)R
<RAOF> alf_: Once Robert's got the LightDM bits hooked up, the system compositor will no longer have a listening socket on the filesystem at all.
<alf_> RAOF: interesting
<tvoss> AlanBell, anything you are especially interested in for ColorManagement?
<duflu> alf_: To avoid duplication, look and comment here (I have added more): https://bugs.launchpad.net/mir/+bug/1169075
<ubot5> Launchpad bug 1169075 in Mir "Mir server running as root does not accept connections from non-root clients" [Medium,New]
<AlanBell> tvoss: well interested in whether Mir is the layer in which that is planned to be done
<alf_> duflu: ok
<tvoss> AlanBell, cool
<AlanBell> I know Mir is planned to be lighter than wayland, and wayland has text tracking zoom and just got colour management
<tvoss> AlanBell, ack
<AlanBell> I was just concerned that if these were not in scope for Mir they probably won't get done at any other level because they are in Wayland
<RAOF> AlanBell: Mir needs to be involved in colour management, yes, because Mir is in control of the CRTCs which is where you do the monitor response curve calibration.
<alan_g> AlanBell: mir currently has a design that allows rendering "effects" to be added by other code in the server process. Our priority will be the effects needed by unity - but that isn't a technical limitation.
<AlanBell> yeah, and unity doesn't need desktop switching any more
<RAOF> alf_: Yeah. Basically what you end up with is: the DM spawns the SC (or visa versa), handing it an open fd to communicate over. The DM then spawns the sessions, handing *them* one end of an open fd and the SC the other end.
<alan_g> AlanBell: *I* need desktop switching - and I'm sure other developers here do too. ;)
<RAOF> alf_: That simplifies security to "I need to trust that the DM only spawns sensible sessions"
<AlanBell> alan_g: ah, that is encouraging ;)
<alf_> RAOF: it's unfortunate that both "system compositor" and "session compositor" have the same initials "SC" :)
<RAOF> alf_: This is true :)
<RAOF> I think we could potentially do a similar thing in the session compositor, too.
<alan_g> alf_: "global compositor"? ;)
<RAOF> I'm not sure if we need to have *any* sockets on the filesystem anywhere. Except for testing purposes.
<alf_> RAOF: how do clients connect to the session compositor?
<RAOF> They get spawned by a client connected to the session compositor.
<RAOF> Well, most will be spawned by the session compositor itself, of course.
<RAOF> I'm not sure if this is practical, but it's something we *could* do :)
<alf_> RAOF: yes, I am not sure how well this  would work. Imagine I have a terminal (in a mir session) and start another client from there. How would the terminal know that this is a mir client and that it expects the fd to be passed in a certain way?
<RAOF> It'd leave a mir fd open for *all* the clients it spawns. It doesn't need to know that it's a mir client that its spawning.
<RAOF> Nothing relies on the first free fd being 3, right?
<RAOF> âº
<alf_> RAOF: ok, how would you start something from an ssh session? :)
<RAOF> You wouldn't :)
<RAOF> Actually, that's not strictly true. You'd write an upstart conf file and get the session upstart to start it :)
<RAOF> Or have a client already spawned that provides an interface to spawn further clients, or whatever.
<RAOF> Woot! We now have daily packages for xf86-video-{ati,intel,nouveau} with XMir support.
<RAOF> HUZZAH
<duflu> Excellent-ness
<tvoss> RAOF, \o/
<alan_g> That's working packages?
<RAOF> alan_g: Should be - I haven't tested nouveau, but mlankhorst assures me that works :)
<mlankhorst> RAOF: I only tested with the kernel changes patched in, though
<alan_g> RAOF: excellent. (Of course we *should* have automated tests to guarantee it all works.)
<RAOF> We should indeed, but probably once the lightdm bits are in place.
<hikiko__> hi, is there a hangout right now?
<hikiko__> ah am :p ignore
<thiagoandrade> I finally managed to build Mir and run it without errors, but in the Mir demos are all appearing glitchy when I run then. For instance the mir_egltriangle is nowhere near a triangle, it's a bunch of little white squares. Is there something I'm missing?
<alan_g> thiagoandrade: yes (although its hard to guess what without more context)
<thiagoandrade> alan_g, I believe the problem is my video driver. I tried to install fglrx but it wouldn't work as my  video card is a little old (Radeon HD 4200). I don know if I have a driver installed or if that matters, but "lsmod | grep drm" returns me the drm module. Should I install the driver available on the ATI website?
<alan_g> thiagoandrade: that sounds plausible but is a bit outside my knowledge.
<alan_g> alf_ ^ - any thoughts?
<alf_> thiagoandrade: It sounds like a tiling issue. Do you see the squares changing or is it just a static image?
<thiagoandrade> alf_, static image.
<alf_> thiagoandrade: hmm, are you using the mesa from the mir-team staging PPA?
<thiagoandrade> yes
<alf_> thiagoandrade: ok, can you please try build/bin/render_surfaces (on its own, without a mir server)
<thiagoandrade> alf_, ok.
<thiagoandrade> alf_, it works.
<alf_> thiagoandrade: ok, now please try running the mir_demo_client_unaccelerated with a mir server, you should see a rectangle flashing between two colors
<thiagoandrade> alf_, no. Purple glitchy square.
<alf_> thiagoandrade: what bzr version of mir are you using, and what mesa version (dpkg -s libegl1-mesa)
<thiagoandrade> alf_, libegl1-mesa version is 9.2~git20130402.b2eee086-0ubuntu0+mir6-jenkins69. bzr version of Mir I don how to see, but updated yesterday.
<alf_> thiagoandrade: please try the latest version of mir (bzr pull), there was a fix yesterday for a similar problem with clients
<thiagoandrade> alf_, Updated. Now it's on version 597, gonna try again. By the way, just for curiosity. How one sees the current version of the branch with bzr?
<alf_> thiagoandrade: to get the mir bzr version -> "bzr revno"
<thiagoandrade> alf_, Ok now I get the flashing screen with mir_demo_client_unaccelerated
<thiagoandrade> Guess it's working.
<thiagoandrade> alf_, Thanks.
<alf_> thiagoandrade: try the mir_egltriangle, too (which is accelerated), just to make sure
<thiagoandrade> alf_, Working. :D
<alf_> thiagoandrade: great :)
<thiagoandrade> alf_,  Now I can play around with Mir. Thanks.
<alf_> thiagoandrade: np
<kdub> alf_, updated server-render-window (if the review is still fresh in your mind)
<alf_> kdub: looking
<alf_> kdub: I guess I shouldn't take it as a sign that the update revision is revision 666 ;)
<kdub> haha! i thought the same thing :P
<alf_> kdub: hmm, return -1 is still there ?
<kdub> shouldn't be...
<kdub> oh, that's a different return -1
<kdub> i should change that too!
<kdub> alf_, ok, removed. now the commit number is much nicer too!
<alf_> kdub: ok, approved
<kdub> cool, thanks
<kgunn> kdub: hell yeah! fb native window!
<kdub> kgunn, yay! now android graphics doesnt have to depend on android glue
<kdub> working on rooting out that glue now...
 * kdub -> eye dr
<robert_ancell> thomi, will https://code.launchpad.net/~gber/lightdm/lightdm-style-fixes/+merge/159097 autoland? Or is both CI and autolanding disabled for MPs not proposed by someone in the whitelist
<thomi> robert_ancell: will find out, one minute
<robert_ancell> thomi, ta
<thomi> robert_ancell: autolanding will work, as long as the MP approver is on the whitelist. CI won't trigger however
<robert_ancell> thomi, ok good. Has anyone considered starting CI if someone on the whitelist gives the MP an 'approve' review? I can live with the autolanding testing, but it would be nicer if CI would start once I'd checked the merge was good
<thomi> robert_ancell: in fact, it's running now: http://10.97.2.10:8080/job/lightdm-raring-amd64-autolanding/12/console
<robert_ancell> thomi, also nice would be in Jenkins would comment on the MP that it was building it with the link - the delay can be confusing
<robert_ancell> thomi, is there a bug tracker I can file against or do I just keep bugging you? :)
<thomi> robert_ancell: I don't believe we have, I'll file a feature request on your behalf if you like
<robert_ancell> please do
<thomi> robert_ancell: I'm happy to be bugged about this stuff, but FYI the project responsible is https://launchpad.net/jenkins-launchpad-plugin
<robert_ancell> thomi, ok, cool I can file bugs there. The second issue is probably bug 1134328
<ubot5> bug 1134328 in jenkins-launchpad-plugin "not enough feedback from autolanding jobs" [Undecided,New] https://launchpad.net/bugs/1134328
<robert_ancell> thomi, and the first issue is bug 1157855 :)
<ubot5> bug 1157855 in jenkins-launchpad-plugin "allow triggering of CI jobs when somebody trusted Approved the MP" [Undecided,New] https://launchpad.net/bugs/1157855
<thomi> dammit, I'll stop typing then :)
<thomi> robert_ancell: if you want attention on a particular bug for that project you're probably best emailing Martin :)
<robert_ancell> thomi, he created those bugs so I'll assume he'll get emailed when I comment on them
<thomi> good point
<thomi> robert_ancell: I just noticed that on https://code.launchpad.net/~gber/lightdm/lightdm-style-fixes/+merge/159097 there's a CI approve vote
<thomi> robert_ancell: so... apparently it already does what we want!?
<thomi> robert_ancell: either that, or someone fixed it *really* fast :P
<robert_ancell> thomi, I think it did it when it did the autolang
<robert_ancell> autoland
<thomi> that's a bit odd
<thomi> once it's landed there's not much point running CI
#ubuntu-mir 2013-04-18
<robert_ancell> when is that GCC bug going to be fixed? Driving me insane...
<robert_ancell> kdub if I set that destructor to default I get "/home/bob/bzr/mir-session-container1/tests/unit-tests/shell/test_session_manager.cpp:51:8: error: looser throw specifier for âvirtual {anonymous}::MockSessionContainer::~MockSessionContainer()â
<robert_ancell> In file included from /home/bob/bzr/mir-session-container1/tests/unit-tests/shell/test_session_manager.cpp:22:0:
<robert_ancell> /home/bob/bzr/mir-session-container1/include/server/mir/shell/default_session_container.h:38:7: error:   overriding âvirtual mir::shell::DefaultSessionContainer::~DefaultSessionContainer() noexcept (true)â"
<robert_ancell> do you know what that means?
<RAOF> robert_ancell: You need to mark your destructor as noexcept
<RAOF> Which most destructors should be, because throwing from destructors is entering a world of std::terminate
<RAOF> That should probably be a style-guide entry, really; there are optimisations available to the compiler if it knows something can't generate an exception.
<robert_ancell> RAOF, so kdub suggested that this change should make them so (https://code.launchpad.net/~robert-ancell/mir/abstract-session-container/+merge/159523)
<RAOF> robert_ancell: But your derived one isn't marked as noexcept, right?
<robert_ancell> RAOF, the derived class doesn't have one, does it need an explicit one?
<RAOF> Yes
<robert_ancell> RAOF, and can I just do "= default" for the derived class too?
<RAOF> If you've got a trivial destructor, sure.
<robert_ancell> so in short every class that extends another needs an explicit destructor
<RAOF> Grrr
<smspillaz> robert_ancell: I suspect you have to do ~MockSessionContainer () noexcept = default;
<smspillaz> oh. oops, didn't see the rest of the scrollback
<smspillaz> in any case, I've had some trouble with default destructors on google mocks - you need to have an explcit or compiler generated destructor for some reason, dunno why
<robert_ancell> smspillaz, thanks
<smspillaz> robert_ancell: generally speaking it goes [virtuality] returntype function_name () [const-specifier] [exception-specifier] [body | =]
<robert_ancell> Hmm, trying to assign a value with a shared pointer not working - any ideas? http://paste.ubuntu.com/5717823/
<duflu> robert_ancell: Seems auto might be doing something you don't want. Make sure the RHS is a non-const shared_ptr of compatible type
<RAOF> robert_ancell: Did catching session by reference rather than value in the lambda expression fix it?
<alan_g> robert_ancell: morning!
<robert_ancell> alan_g, hello!
<alan_g> robert_ancell: "When I originally had the default destructor it stops the mock SessionContainer classes from working" - you mean compiling?
<alan_g> That's because mocks have members with non-noexcept destructors, so you need to explicitly mark the destructor noexcept. (Which is valid when using google-test.)
<robert_ancell> alan_g, right - I couldn't work out the correct syntax to mark them
<alan_g> robert_ancell: ~MockWhatever() noexcept {}
<robert_ancell> alan_g, just checking that..
<robert_ancell> alan_g, I was just trying that - it only works once https://code.launchpad.net/~kdub/mir/nicemock-improvements/+merge/159465 lands
<alan_g> robert_ancell: I see. (Or avoiding NiceMock ;)
<robert_ancell> alan_g, so, should ServerConfiguration also use the same style destructor?
<alan_g> robert_ancell: some of us have started updating stuff as we touch it - but it can get a bit "viral", so it isn't required. New stuff we do "right".
<alf_> alan_g: @disallow-vt-switching-when-pause-fails, so the idea is to handle any exceptions (and report the relevant errors) internally e.g. in display->pause(), and have the high level functions just return bool? What if handle the exceptions (and reports) at the mid level and rethrow?
<alan_g> alf_: It all depends if display->pause() failing is an exception or just a result. Looking at the code in DisplayServer::Private::pause() it seems easier for it to be a result.
<alf_> alan_g: it's an exception which we can gracefully handle, failure is not really an expected result, but I guess the line is somewhat blurry in this case
<alan_g> alf_: which code is simpler?
<alf_> alan_g: the high-level pause() snippet is simpler now, but I am not sure if it will continue to be simpler when we add other components to the mix (e.g. pause the communicator, which will come soon. That's the reason I added ScopedAction, since the recovery was going to get unwieldy).
<alf_> alan_g: internally there is no really difference in code complexity
<alan_g> alf_: OK. In that case, can we define an exception type that carries the reporting context up to the top level and have a single exception handler doing the reporting?
<alf_> alan_g: Hmm, not really, because we need to cross out of platform specific boundaries with a platform specific issue/context (DRM failure). The highest level at which we know what is going on is inside display->pause() (hence my suggestion to catch, report and rethrow).
<alan_g> alf_: what I don't like about that is the eventual catch and ignore
<alan_g> alf_: that's why I thought of catch, report and return an error. ;)
<alf_> alan_g: at the DS level we could report a general pause() failure
<alf_> alan_g: plus we are not really ignoring, we are return false from the handler :)
<alan_g> alf_: ok
<alf_> alan_g: I'll iterate and we can see how it looks
<kdub> morning!
<kdub> status, working towards removing 3rd_party/fbtype, then hopefully some hwc1.0 work
<alf_> status: working on handling pause/resume failures (i.e. vt switching) more gracefully, working on pausing communicator
<alan_g> status: documenting and cleaning up configuration related classes
<racarr> morning
<alan_g> Afternoon
<racarr> spinning in circles on the circular dependency
<tvoss> bryce, ping
<racarr> taking a stab at software cursor in a demoI wonder if
<racarr> the right approach is to subclass the compositing strategy
<racarr> or to subclass Renderables (to emit a cursor renderable after the surfaces)
<bryce> tvoss, yep?
<racarr> neither one really works well in trunk now.if you subclass the compositing strategy you have to reimplement the whole thing rather than just chain up and overlay (because of the location of display::post_update)
<racarr> which is all you want to do...
<racarr> the renderable interface isn't set up for anything beside surfaces though, inparticular, void bind_to_texture()
<racarr> is alittle inflexible
 * kdub falls for the trap of confusing quantal/raring  arm toolchains
<racarr> lunch
<racarr> software cursor demo is maybe half done
<racarr> just flicked a cursor allover the screen
<racarr> it felt good
<racarr> hmm
<racarr> all works except the software cursor itself cant trigger the compositor
<racarr> so you need a client rendering at 60fps for the cursor to work ;)
<kdub> racarr, excellent :)
<racarr> kdub: Any idea for what sort of interface
<racarr> to allow triggering the compositor?
<racarr> it seems like exposing compositor.schedule_compositing or whatever
<racarr> defeats the purpose of the whole change callback mechanism in place now
<racarr> which I dont entirely understand
<kdub> racarr, yes, let me check...
<racarr> buts its clear its needed eventually, not every redraw will correspond to a change of a renderable (i.e. due to animations or some such)
<tvoss> racarr, ping
<racarr> tvoss: pong
<racarr> ok just updated my qtubuntu to trunk to test
<racarr> pointer input, and key input is broken!
<racarr> might be related to the vt changes? or something...or might be a mistake in my qtubuntu :)
<racarr> it seems impossible to gdb mir since the vt changes
#ubuntu-mir 2013-04-19
<racarr> I just used
<racarr> the cursor to click on things in a Qt app
<racarr> oO
<racarr> :D
<racarr> kdub: Any ideas yet for cursor damage
<kdub> racarr, got distracted :P
<racarr> kdub: np
<racarr> one possibility is the compositor sets the damage callback the same way it does now for the Renderables
<racarr> on the Display
<racarr> and Display exposes some method like
<racarr> damage_region
<racarr> moving the cursor is so great
<racarr> *grin*
<RAOF> racarr: Cursor damage? You mean, for swcursor?
<racarr> RAOF: Yeah! I wrote a sw cursor shell
<racarr> it implements the compositing strategy to draw an overlay
<RAOF> Cool
<racarr> RAOF: And I filled out enough of window handle to get pointer events working :)
<racarr> clicked on some qt stuff
<RAOF> Woo! Input you can *see* :)
<racarr> I think I will write an acceptance test for pointer events
<racarr> then make it pass with the bits from this branch and propose those seperately
<racarr> because the sw cursor is in the demo shell which isn't ready to land yet I guess
<racarr> or work on damage
<racarr> hmm
<deathye> :3
<robert_ancell> racarr, what is the point of CachedPtr?
<racarr> robert_ancell: Prevent reference cycles (it keeps a weak_ptr)
<RAOF> The question remains: what is the point of CachedPtr?
<RAOF> Is it simply a weak_ptr convenience class?
<racarr> Basically.
<duflu> Hmm, I wonder how well that abstraction makes sense? Haven't used it. But I did encounter a reference cycle problem in surface-states which required weak_ptr
<racarr> well it doesnt
<racarr> prevent reference cycles in general but it
<racarr> allows for each of the components
<racarr> of the server configuration
<racarr> to have singleton factory methods
<racarr> without reference cycle
<duflu> Umm, kay.
<mpt> Mirrrrrrrrrrrrrrrrr
<duflu> rocks?
<ogra_> rrrrors ?
<duflu> OK... Friday nonsense. Must be weekend time...
<alan_g> alf_: where do you think EventSink/Queue belong?
<alf_> alan_g: EventSink is used all over the place (and both in server and client), so I think that the current placement is OK
<alf_> alan_g: EventQueue is currently a detail in frontend, so I would be inclined to place it there (and don't expose it)
<alf_> alan_g: to other modules yet
<alan_g> alf_: that sounds right to me too
<alan_g> although I think namespace mir should be uncluttered
<alf_> alan_g: so create e.g. mir::event ?
<alan_g> alf_: perhaps. Not a blocker just now though.
<kdub> hello all! status, a few branches in the air to remove the 3rd_party/android-fbtype directory, to upgrade to raring. working on hwc1.0 vsync support today
<alan_g> kdub: hello one!
<alan_g> status: reviewing and refactoring
<alf_> status: iterating MPs, working on/proposed pause-communicator MP
<racarr> Morning
<kdub> morning racarr
<kdub> hmm, no android classes on doxygen?
<alan_g> Afternoon all
<bschaefer> racarr, ping
<racarr> bschaefer: Pong
<bschaefer> racarr, hello!
<racarr> bschaefer: Hey! How goes?
<racarr> Just got back from lunch :)
<bschaefer> racarr, good! How about yourself :)
<racarr> Excellent!
<bschaefer> awesome, soo I've some questions about mir input :)
<racarr> Ok! Shoot
<bschaefer> im working on porting Mir to SDL atm, but looking at setting up : mir_surface_set_event_handler
<racarr> ok
<bschaefer> which isn't working atm, as it seems to be using the android platform?
<racarr> no its just the android
<racarr> input stack
<racarr> its a little misleading
<bschaefer> also the egl apps don't seem to be working with input either :(
<racarr> as it stands input in trunk ... at least for key! You should be able to get some events
<racarr> you need --enable-input=true
<racarr> and permissions on /dev/input/*
<racarr> Can you try with both of those?
<bschaefer> right, I had to do that for umm the eglapp and got this problem
<bschaefer> http://paste.ubuntu.com/5722394/
<bschaefer> there doesn't seem to be focus?
<racarr> bschaefer: Ah!
<racarr> input was briefly broken in trunk
<racarr> https://code.launchpad.net/~robertcarr/mir/fix-1170524/+merge/159743
<racarr> do you have this revision?
<bschaefer> racarr, oo nice, I havn't updated today!
 * bschaefer checks
<bschaefer> im at rev 606 :), let me try that out!
<bschaefer> also, so the basic idea for input in Mir, is to set up an event callback, and let the app filter out the events?
<racarr> bschaefer: Yes. I mean the app only gets events intended for it
<bschaefer> racarr, awesome, sounds very easy :)
<racarr> bschaefer: Yes. The thing to remember is event callback
<racarr> will be invoked from a seperate thread
<racarr> so you have to
<racarr> well. synchronize somehow
<bschaefer> oo, so pump/flush the fd?
<bschaefer> for the surface
<bschaefer> or wait until its received an event ... there was mir_wait but that was for something else :)
<racarr> bschaefer: The input is on a seperate fd that is all managed internally
<racarr> so once you create the surface
<racarr> there is a thread which polls on that fd
<racarr> and dispatches events to your callback once they arrive
<racarr> I just mean
<racarr> whatever object in SDL you are giving the events to
<racarr> needs to be prepared to be used from another thread
<racarr> or you have to lock it yourself
<bschaefer> racarr, ooo, alright Ill have to keep that in mind
<racarr> Excited to see SDL on Mir :)
<bschaefer> cause, im just starting on the input side of things, as I already have opengles v 1/2 running fine :)
 * bschaefer digs up a screenshot
<racarr> In my ~1 week ahead of trunk branch we have a software cursor and
<racarr> pointer events to apps
<bschaefer> racarr, http://i.imgur.com/D591bOX.jpg
<racarr> so will be fun to play with a fully functioning toolkit
<bschaefer> awesome!
<racarr> QtUbuntu stll has some quirks
<racarr> whereas I imagine SDL
<bschaefer> yeah, I saw you getting it working yesterday
<racarr> well should just work
<racarr> mwahaha smileys
<bschaefer> :)
<bschaefer> 1500
<bschaefer> racarr, right, all I think I should have to do, is receive an event from mir, figure out mouse/keyboard and tell SDL we have received a specific event
 * bschaefer hopes its that easy
<bschaefer> also sweet, receiving events in egl apps now :)
<racarr> yay :)
<racarr> bschaefer: The keycodes in
<racarr> MirEvent are xkbcommon keysyms so you can probably even copy paste
<racarr> a big event translation table from somewhere
<racarr> if its needed
<bschaefer> racarr, right, yeah thats how wayland was doing it
<racarr> dont know thatmuch about SDL
<racarr> mm
<bschaefer> neither do i :)
<bschaefer> well more now
<racarr> :)
<kdub> is it just me, or does g++ ICE all the time?
<racarr> kdub: All the time
<racarr> i.e. its not just you
<racarr> its mostly around std::make_shared
<alan_g|EOW> racarr: only if you don't pass the right parameters ;)
<racarr> haha
<racarr> alan is funny at night
<racarr> mer its difficult to acceptance test motion events due to the event batching behavior
<kdub> whoohoo, hwc 1.0 was much easier to get going :)
<kdub> now that all my android factories are set up
#ubuntu-mir 2014-04-14
<alan_g> greyback: alf_ do you still need to "hold" https://code.launchpad.net/~alan-griffiths/mir/move-more-stuff-to-scene/+merge/214752?
<alf_> alan_g: greyback: I am OK with it getting in, but I can't speak for Gerry and the unity-mir etc side
<greyback> alan_g: ok from me.
<alan_g> Cool.
<greyback> alan_g: could I get you to cast your eye over this please: https://code.launchpad.net/~gerboland/unity-mir/fix-compatibility-with-mir-0.1.8/+merge/215454
<alan_g> greyback: https://code.launchpad.net/~gerboland/unity-mir/fix-compatibility-with-mir-0.1.8/+merge/215454/comments/511654
<alan_g> synchronicity
 * greyback presses F5
<alf_> alan_g: also please take a look at https://code.launchpad.net/~afrantzis/mir/fix-1306464/+merge/215387  (fixes a cause of intermittent CI failures)
<alan_g> alf_: ack
<alan_g> greyback: Not quite a "nit" https://code.launchpad.net/~gerboland/unity-mir/fix-compatibility-with-mir-0.1.8/+merge/215454/comments/511656
<greyback> alan_g: ah good to know
<greyback> all feedback welcome, so "nit" away
<alan_g> alf_: why has  "woken_" grown a "_"?
<alf_> alan_g: I added a woken() method
<alan_g> ok
<greyback> Anyone in here familiar enough with platform-api to review https://code.launchpad.net/~gerboland/platform-api/fix-compatibility-with-mir-0.1.8/+merge/215455
<kgunn> greyback: i'm building with https://code.launchpad.net/~gerboland/unity-mir/fix-compatibility-with-mir-0.1.8/+merge/215454 & https://code.launchpad.net/~gerboland/platform-api/fix-compatibility-with-mir-0.1.8/+merge/215455
<greyback> kgunn: great, thanks
<kgunn> i assume its all i needed...and ready to go
<greyback> kgunn: yes, I built all & tested this morning, it should be good
<kgunn> thank you
<kgunn> alf_: greyback ...are we able to test non-blocking ?
<greyback> kgunn: I think all the code is ready to land, but I suppose a silo would be good to bring all the bits together
<kgunn> greyback: yep...that's what i meant, i'd like to give it a full day of team beating on it in silo
<kgunn> (...or even more than a day...)
<greyback> sure
<alf_> kgunn: so the code for Mir is in mir/devel, and the needed changes for usc is in https://code.launchpad.net/~afrantzis/unity-system-compositor/non-blocking-swap-buffers/+merge/214759 and can be merged at will
<kgunn> alf_: awesome! ...and thanks for tackling a tedious surgery :)
<alf_> kgunn: np
<kgunn> i'll ping here and shoot a mail with silo#
<alf_> kgunn: what's the plan for making a release with them (and the other changes, e.g. scene refactoring that Alan is working on)?
<kgunn> alf_: let's chat at our standup...but, my preference would be to promote wholesale from dev to trunk
 * kgunn assumed you were asking about cherry picking
<alf_> kgunn: that would be my preference too
<anpok> alf_: https://code.launchpad.net/~andreas-pokorny/mir/custom_input_dispatcher/+merge/215174/comments/511794 is that beneficial enough
<anpok> asking because I tend to believe your proposal would yield a smaller change set
<alf_> anpok: it feels strange conceptually for the DefaultInputConfiguration to both depend on and provide the InputDispatcherConf...
<alf_> anpok: It means that the InputDispatcherConfiguration is a completely independent entity
<anpok> yes, we could see it that way.. we split the stack in to entities
<anpok> *two
<anpok> the one that reads input from devices or from the mir conncetion
<anpok> and the part that sits on top of that and dispatches the input to clients/internally
<anpok> hmm at some point one has to register to the other
<anpok> s/register/be connected/..
<alf_> anpok: if the two parts (read,dispatch) are really independent, and it's a pain if we want to override only one part, I wonder if we should split InputConfiguration into two independent interfaces.
<anpok> alf_: I could rename InputConfiguration to InputReceiverConfiguration.. and I think I can easily remove the input_dispatcher_configuration from InputReceiverConfiguration..
<anpok> the connection is currently done in InputConfiguration and there is a short cut if the dispatcher is the android dispatcher.
<anpok> cannot remember any reasons why I also have the_input_dispatcher_configuration() inside InputConfiguration ..
<anpok> or InputReaderConfiguration
<kgunn> greyback: hey...don't you have a unity-mir branch that would need to go with alf_'s non-blocking branch ?(e.g. expose event)
<greyback> kgunn: not yet, working on it
<kgunn> ack
<alan_g> kgunn: alf_ anpok we've too many (IMO) MPs in flight. We need to finish stuff as well as start it.
<kgunn> alan_g: can you elaborate ?....i guess you are saying people need to do reviews and get stuff merged ?
<alan_g> kgunn: mostly address review comments. But "do reviews" too.
<racarr__> Morning!
<kgunn> racarr__: mornin'
<kgunn> greyback: ok, just hit me up when you got it...i can't get a silo until then
<greyback> kgunn: ok
<dandrader> anpok, so that would be that last missing bit, right? https://code.launchpad.net/~andreas-pokorny/mir/use-input-channel-to-send-input/+merge/215450
<anpok> yes
<anpok> alf_: wifi issues - did we reach a conclusion i might be unaware of?
<alf_> anpok: no, let's talk after the stand-up
<alf_> anpok: I am OK with the two interfaces, but I am not intimately familiar with the input side of things and would appreciate some discussion
<anpok> k
<racarr__> I am going to spend a good portion of the morning reviewing the input bits :)
<kdub> alan_g, so were you intending SurfaceObserver to eventually become the way the compositors are notified of scene changes? or was it just for purposes of the shell?
<alan_g> kdub: SurfaceObserver can notify changes to a surface, but not to e.g. the stacking order. That's a whole new Observer
<kdub> right
<kdub> so will the compositors eventually use the newObserver + the SurfaceObserver to figure out when to recomposite?
<racarr__> That was my conclusion on what seemed nice when I studied it for the CursorController
<alan_g> There's nothing stopping class CompositeScheduler : public  ms::SurfaceObserver, public ms::StackObserver
<racarr__> which uses the surface stack change callback (as in multiple-change-callbacks)
<racarr__> like the compositor
<racarr__> but for optimization and clarity shouhld also be
<racarr__> SurfaceObserver, StackObserver
<kdub> ack, and then ms::Scene doesn't have to change much immediately
<kdub> that seems sensible
<kdub> *mc::Scene
<kdub> I'm trying to target the whole recomposition system to be nicer
<kdub> instead of callback, render, check Renderables, render, check Renderables
<kdub> just callback, render, callback, render
<kdub> no more mg::Renderable::buffers_ready_for_compositor()
<alan_g> that would be nice - not thought through getting there
<kdub> I can see a path to doing that, probably would be a side clean-up for me
<kdub> I guess the other longer-term thought is callback, renderable_list_for(), callback, renderable_list_for(), etc
<kdub> could just be a callback containing the renderable list
<kdub> but that's further down the road :)
<racarr__> it seems like specialized callback is useful, because for example if the only scene change is a renderable dissapearing
<racarr__> as the compositor I should be able to recognize this
<racarr__> without having to search a list or anything
<kdub> racarr__, yeah, good point
<kdub> thanks alan_g & racarr__
<anpok> racarr__: hm regarding input - then I need to do more in the case we replace the droidinput dispatcher - I need to process the finished signals produced by the clients..
<anpok> with the current mps those signals sent back to the server are never read..
<racarr__> anpok: Well its not an immediate requirement...but yes there is some work there
<racarr__> this is why I am favoring this approach where we split the InputDispatcher
<racarr__> in to an InputTargeter
<racarr__> err
<racarr__> or like InputTargetSelector
<racarr__> and InputSender (manges seq ids, receiving finished signals, broken channels, etc)
<anpok> i thought that (inputsender) would be the inputchannel in a few mps
<anpok> hm but yeah channel might be not the right name then...
<alan_g> racarr__: I've posted some thoughts to the spike MP. Hope they help
<anpok> but back to the finished signal - we would fill the socket and block some time if I dont start to work something out in that direction
<racarr__> alan_g|EOD: Thanks :)
<racarr__>  still so sore from the plane need to go for a walk or something...back in 30
<racarr__> ibuprofen granola bar and a walk around the block...catch all miracle cure.
<kdub> hah, I didn't know they made ibuprofen in granola bar form ;)
<racarr__> kdub: Hahaha no just a missing comma
<racarr__> thats a great idea though
<racarr__> granola bar infused with ibuprofen
<racarr__> vitamin infused ramen
<racarr__> sell it to college students
<racarr__> $$$
<kdub> now that we have a great idea, we just need a name! GranolaBarHeadSaver
<racarr__> kdub: Needs fixing.
<racarr__> :p
<kdub> lol
<racarr__> somehow I had ambitions of reviewing every open branch before lunch...
<racarr__> and its already clear that is not going to happen lol
<racarr__> so
<racarr__> many
<racarr__> branches
<racarr__> oh no
<racarr__> now Im on custom-input-dispatcher
<racarr__> this is the hard one lol
<racarr__> well maybe not
<anpok> no not at all
<anpok> thought you meant the input channel thing
<dandrader> anpok, so are you planning to split android::InputDispatcher responsibilities (target selection and supervision of event delivery through channels) in your custom-input-dispatcher branch?
<dandrader> or is that to be done later
<racarr__> I think it should probably be done later...
<dandrader> +1. I think this splitting is going to be a big big patch
<racarr__> I mean maybe it could have been done now but on the other hand anpok has already done this so its good to just unblock qt compositor
<racarr__> well this patch ended up pretty big too because of all the input configuration changes, etc...whereas
<anpok> I wanted to do that last week
<racarr__> if InputDispatcher was a sensible interface
<racarr__> we could just expose it and
<anpok> but it looked liked a lot of work ..
<anpok> so I thought that I would do that
<anpok> and while keeping the interface further cleanup the InputDispatcher
<anpok> as in splitting functionalities out..
<racarr__> I think aim at collapsing the input configuration hierarchy...right now its only a seperate hierarchy
<racarr__> to hide android bits that we havent...made sensible yet basically
<anpok> hm that was two weeks ago
<racarr__> what I mean is like, InputReader, EventHub, InputDispatcher, etc
<anpok> then in between other stuff hapened..
<racarr__> are all too ...
<racarr__> poorly defined to have like
<racarr__> ServerConfiguration::the_input_dispatcher, etc...because it depends on too many android details
<anpok> yes
<racarr__> but as we split responsibilities, DefaultServerConfiguration::the_input_target_selector DefaultServerConfiguration::the_input_event_sender(relay?) etc
<racarr__> make perfecnt sense and we can
<racarr__> delete a lot of header file code lol
<racarr__> and just kind of clarify things
<racarr__> is this on your agenda? should I help?
<anpok> thats also what alf_ pointed me to
<anpok> as in he didnt like InputConfiguration and InputDispatcherConfiguration
<racarr__> Mm
<anpok> right now I feel I have to make sure that the InputConsumer does not block at some point
<anpok> I would like to to get rid of things like the input_registrar too
<anpok> and the co-ordinate calculations being buried inside the InputDispatcher ..
<anpok> and all that
<racarr__> yes
<anpok> racarr__: I dont know to which degree we can work on that thing at the same time
<dandrader> I would say, unblock the qt compositor work now and do all the refactoring later
<anpok> so .. to unblock the consumer it I have the feeling I should establish the inout sender ..
<racarr__> haha yes I guess what I meant do you have time for it now
<racarr__> anpok: well for now qtcompositor has a copied modified version of input dispatcher
<anpok> racarr__: no other thing on my direct agenda.. i also have fix-126726 something that is in that area..
<racarr__> so they can be unblocked by that...
<racarr__> I mean...now I am just reviewing the diff for correctness and then It hink am happy to just go with that for the next few weeks
<racarr__> but would like to bring real sanity to the area soon :D
<racarr__> anpok: Ok. I leave it in your capable hands lol
<racarr__> I have chromium and X input driver to keep me busy at least this week
<anpok> dandrader: i would keep the current mir::input::InputDispatcher rather stable wrt further refactorings, but InputChannel .. I have to change rather sooner..
<anpok> or the thing to dispatch the input too
<dandrader> anpok,  what's wrong with InputChannel?
<racarr__> one thing is send_event(seq_id, MirEvent) is weird because the caller cant know how to use seq_id really so its weird as a public interface
<anpok> it has to be non null :) and should not collide with other input sequences
<anpok> and nobody reads the ACK signals that come back from the input reader..
<racarr__> indeed but they will
<anpok> I only discovered that part today
<dandrader> racarr__, true
<racarr__> and if it has to be non null and not collide and thats all
<racarr__> then it should just be hidden inside the object
<racarr__> just going to leave comments 1 by 1 on this as I go through because its a large diff lol
<racarr__> anpok: Ok I left a bunch of comments lol
<racarr__> im
<racarr__> gonna make it
<racarr__> so hungry but only two branches left
<racarr__> LUNCCCCCCCH
<racarr__> *triumph and joy*
<racarr__> oh man spot on too
<racarr__> A+ lunch
<racarr__> Iterating on cursor spike in just a sec then in to ozone world until EOD
#ubuntu-mir 2014-04-15
<kgunn> RAOF: hey, do you happen to know if/how xmir install/enabling changes with unity8-desktop-session-mir ?
<kgunn> racarr_: ^ ?
<RAOF> kgunn: Yes; is there anything in particular that you want to know?
<kgunn> ....so i'm just wondering, unity8-desktop-session-mir installs unity-system-compositor....
<kgunn> and installing u-s-c was the mechanism to install xmir
<kgunn> ..i assumed it still was ?
<kgunn> but guess it must not be true
<kgunn> ...wonder, now, one must go modify /etc/lightdm/lightdm.conf.d/unity-system-compositor.conf ?
<kgunn> i was thinking to test this...
<kgunn> wondered if you knew off the top of your head
<racarr_> kgunn: I think ubuntu-desktop-mir enables xmir
<racarr_> err
<racarr_> which is pulled in by unity8-desktop-session-x11 what?
<racarr_> so lets hope not lol
<kgunn> racarr_: ah-ha...unless, you already had a usc conf file...? which had #type-unity modified :)
<racarr_> kgunn: I dunno, packages can either override or not override conf files...would have to look deeper
<RAOF> kgunn: Yeah, if you already had a usc config file lying around it wouldn't overwrite it.
<RAOF> kgunn: Assuming that the config file that the package wants to install is exactly the same as the config file at the time you modified it.
<kgunn> ok...gonna just see if it still works, rebooting
<RAOF> This bodes.
<kgunn> uh well...that was unpleasant...
<kgunn> usc log says https://pastebin.canonical.com/108519/
<kgunn> RAOF: ^ in case something comes to mind...it could easily be something of mine
<kgunn> setup incorrect...
<kgunn> racarr_: totally...bag o candy, 8o clock...i got a sick belly now :(
 * RAOF will check just as soon as his SSO 2fa device finishes being unresponsive.
<RAOF> kgunn: Hrm. Looks like we failed to do drm setup there, which we should be able to do. I wonder if things like plymouth are being silly?
<kgunn> RAOF: wanna join meeting ?
<kgunn> it'll be quick one
<RAOF> Sure.
<RAOF> Was rather expecting it to be at 13:00
<racarr_> kgunn: Oh no :(
<racarr_> oh
<racarr_> did I miss
<racarr_> meeting
<racarr_> I guess not that much to say
<racarr_> RAOF: I am writing X Input driver
<racarr_> I wont be able to get back to it until wednesday but its almost all done
<RAOF> racarr_: Hurray!
<racarr_> was going to test some basics of it but then had intel driver mis match...and
<RAOF> racarr_: Also, meeting is on now. Come on down!
<racarr_> I dunno probably just built wrong stuff during sprint
<kgunn> thomi: are there specific instructions to the "Run the autopilot functional and unit tests" for desktop ?
<kgunn> or just read the readme?
<thomi> kgunn: I can show you here, if you like
<thomi> you have the packages installed from the landing silo?
<kgunn> thomi: just upgrading...will install as soon as that completes
<thomi> ok
<thomi> well, when that's done, opena  terminal and run:
<thomi> autopilot run -o ap_2_results autopilot ; autopilot3 run -o ap_3_results autopilot
<thomi> you'll want to double check that all the AP-related packages from the silo have been installed
<thomi> especially: python-autopilot python-autopilot-tests python3-autopilot python3-autopilot-tests autopilot-desktop
<kgunn> thomi: ok...will do that
<kgunn> RAOF: duflu...weird you both expected the meeting to be later, but i updated and saved it earlier today....hmmm
<kgunn> is there a google-american-aussie-daylightsavings-bug somewhere?
<kgunn> RAOF: any other ideas on my xmir failing to start? (i'm updating just in case)
 * kgunn wonders if there's a handy drm debug wiki
<duflu> kgunn: Well my timezone never moves. Only the meeting did. Not sure why
<RAOF> kgunn: Can you switch to a VT and try restarting lightdm? Can you ssh in and do the same?
 * duflu is actually mostly impressed with being awake in the *morning* at all
<kgunn> RAOF: i will try...kinda got too many spinning plates atm :)
 * duflu mixes fresh XMir with fresh coffee
<AlbertA> kgunn: just fyi I built against mir devel r1550 for the mir-0.1.9 branches I sent you
<duflu> kgunn: Yeah using that PPA XMir doesn't start (normal X starts fine instead)
<duflu> Probably because USC is never started
<RAOF> Hm. This test is becoming more complex than the code it's trying to test. Time to rethink.
<kgunn> thomi: so...i ran autopilot run -o ap_2_results autopilot
<kgunn> and it ran a bunch of stuff...
<kgunn> no failures
<kgunn> but no summary either
<kgunn> normal ?
<thomi> kgunn: it'll be in the ap_2_results file
<thomi> that's what the -o bit does
<kgunn> thomi: thanks (i should've read the command line and thot a little)
<thomi> kgunn: :)
<kgunn> all pass btw
<thomi> kgunn: sweet - now you gotta repeat with 'autopilot3' :)
<thomi> kgunn: I gotta head out for 45 minutes or so. If you need anything in the mean time, I'msure veebers can help you in #ubuntu-autopilot
<kgunn_> RAOF, racarr_ interesting...so i'm on my clean machine, installing unity8-desktop-session-mir, which in turn installs u-s-c, did not create a /etc/lightdm/lightdm,conf.d/10-unity-system-compositor.conf file
<duflu> kgunn_: That would explain why XMir wasn't running either :)
<kgunn_> duflu, nope, completely different machine...other machine, i had a 10-usc.conf file....
<RAOF> kgunn_: Got ubuntu-desktop-mir installed?
<kgunn> RAOF: on the new machine...no
<RAOF> kgunn: That is the package with 10-unity-system-compositor.conf in it.
<kgunn> huh...not installed on this machine either
<duflu> I knew that was true. But it's a problem for Unity8 it seems
<kgunn> hmmm....ok, so unity-system-compositor no longer installs ubuntu-desktop-mir ?
<RAOF> Apparently so.
<duflu> Maybe?... what does "ubuntu-desktop-mir" mean? Does it mean XMir or "XMir or Unity8"?
<kgunn> duflu: afaict, unity8-desktop-session-mir....means unity8
<kgunn> on mir
<kgunn> but unity7 still on x (no mir)
<duflu> kgunn: So we either need to depend on ubuntu-desktop-mir or move the conf file to another package...
<kgunn> whereas ubuntu-desktop-mir means xmir (guessing there)
<kgunn> or just change the instructions ?
<duflu> Ah but ubuntu-desktop-mir isn not XMir-specific, is it?
<kgunn> RAOF: ^ ?
 * duflu checks package contents
<RAOF> kgunn: Dunno; I didn't do those packages :)
<duflu> kgunn: The only purpose (only content) of ubuntu-desktop-mir is to provide 10-unity-system-compositor.conf. Unfortunately it depends on xserver-xorg-xmir, which I think we should uncouple
<duflu> ... and then unity8 can cleanly depend on ubuntu-desktop-mir. As should xserver-xorg-xmir (i.e. reverse the current dependency)
 * duflu now wonders why the USC conf is not included in USC packages
<duflu> That would make more sense -- I have USC installed and therefore I expect it to start\
<RAOF> I don't know if unity8-desktop-session-mir is expected to work on a raw VT or not.
<kgunn> so on my clean machine, just installed ubuntu-desktop-mir...still no conf file installed
<RAOF> I don't know why unity8-desktop-session-x11 depends on ubuntu-desktop-mir, though.
<kgunn> ok..i'll try again tomorrow...i need to tie loose ends and go to bed
<kgunn> RAOF: duflu ...btw, silo3 ppa may actually build (...making it sucessfully thru usc now)
<kgunn> so if you wanted to test xmir with https://launchpad.net/~ci-train-ppa-service/+archive/landing-003
<kgunn> and send a mail...that'd be great
<duflu> kgunn: I think we should abolish ubuntu-desktop-mir. It's confusing and it's only contents (the conf file) would be better placed in the USC package
<duflu> -it's +its
<kgunn> duflu: might file a bug and flag bregma to stay in sync
<RAOF> That seems sensible.
<duflu> Well as usual it's a simple change to make... if only I can find the branches (often the greatest challenge)
<duflu> On second thoughts, I don't know lightdm that well. Might be missing something
<duflu> RAOF, all: Please?https://code.launchpad.net/~vanvugt/mir/version-0.1.9/+merge/215804
<duflu> There's more to come too
<alf_> Saviq: Hi! Where does unity8 keep its log on the phone (e.g. if I print to stderr from the unity8 process)?
<anpok> alf_: ~/.cache/upstart/unity8.log.*
<josharenson> When I try to cross compile mir (in my own feature branch) get an error about the boost libs not being found. Compiling any other branch works just fine... Any pointers? I have changed a lot of cmakefiles, but nothing that should have affected libboost
<alan_g> josharenson: are the boost libs in your cross-compilation environment and not being found or are they not being installed there?
<josharenson> alan_g not being found I believe
<josharenson> http://pastebin.ubuntu.com/7256002/  shows the first of several errors
<alan_g> josharenson: You're setting CMAKE_PREFIX_PATH to somewhere useful?
<alan_g> Oops PKG_CONFIG_PATH
<josharenson> alan_g never had to do that before... should I try setting it to /usr/bin ?
<alan_g> No, to wherever you're installing your target libraries
<josharenson> ok
<alan_g> s/libraries/packages/
<alan_g> E.g. from cross-compile-chroot.sh : export PKG_CONFIG_PATH="${MIR_NDK_PATH}/usr/lib/pkgconfig:${MIR_NDK_PATH}/usr/lib/arm-linux-gnueabihf/pkgconfig"
<josharenson> alan_g yes I tried that manually and via the script
<josharenson> re-downloading some deps over airplane wifi right now.....
<josharenson> hummm seem to be getting 404s for all armhf repositories
<kgunn> racarr_: kdub ...so that whole "scene observer" discussion going on, is that going to be another hit on server api ?
<kgunn> i'm just starting to wonder if we should just plan on cherry picking the non-blocking egl (...feels like an endless api update exercise otherwise)
<racarr_> kgunn: Yeah it would be
<kgunn> racarr_: so do you think we're killing ourselves trying to work this particular item at high priority while also keeping step with all the other churn ?
<kgunn> AlbertA: thots ^ ? guess you suffered y'day...
<AlbertA> kgunn: I've rebased the branches to tip again locally
<AlbertA> kgunn: well actually only papi was affected
<AlbertA> kgunn: trying to cross-compile to test
<kgunn> AlbertA: on papi was it the removal of the placement strategy ?
<AlbertA> kgunn: yeah
<racarr_> kgunn: Ah sorry. It's
<racarr_> server ABI
<racarr_> but not sever API
<kgunn> AlbertA: ok..just worrying there's more to come e.g. "scene observer" , cursor stuff, input dispatcher,
<racarr_> cursor stuff also breaks ABI but not API
<kgunn> racarr_:  true..that makes it less churn-y
<AlbertA> kgunn: for 0.1.9?
<AlbertA> kgunn: when do we expect to tag?
<kgunn> AlbertA: yeah...since its not really tagged
<kgunn> well...that's just it, if we take a "wholesale" approach...we need to tag _after_ we get mir good to go for non-blocking swap
<kgunn> if we take a cherry pick approach...it'll just be rework pain for alf
<racarr_> ok well all this stuff doesnt have to land quite let
<racarr_> yet
<racarr_> no one minds MPs sitting around if everything is an approve
<kdub> kgunn, I have something for the android overlays to work on that shouldn't hit much server api, I can switch to that for a bit so there's less churn from me for a few days
<racarr_> imo
<AlbertA> kgunn: yeah theres's only 4 MPs ready to land which should not break api
<AlbertA> kgunn: I'm holding off on the one that does (add uid/gid) after tagging
 * kdub to lunch
<kgunn> thanks AlbertA, kdub, racarr_ ...if we can keep it a bit more "calm" for some days it'll help for sure
<kgunn> i might still get my arm twisted
<kgunn> by rel team to cherry pick
<racarr_> ok well keep it cool
<racarr_> hmm
<racarr_> this scene observer + register surface observer approach ends up being really annoying for the compositor
<racarr_> because its hard to unregister
<racarr_> oh nvm I can just move the
<racarr_> started/stopped check in to the callback, it already owns the right lock
<racarr_> so its the same
<racarr_> lalala
<AlbertA> racarr-
<AlbertA> racarr_: note that logic is about to change a little bit
<AlbertA> racarr_: the compositor start/stop state
<racarr_> AlbertA: Mm..I think it will be fine
<racarr_> we will find out soon :p almost to that part
<AlbertA> kgunn: there's a deadlock issue with non-blocking
<kgunn> AlbertA: awesome :-/
<kgunn> how is that possible ?
<kgunn> ....its non blocking :)
<kgunn> lol
<AlbertA> kgunn: he yeah It does sound ironic
<kdub> haha
<kgunn> at least it made me laugh a little...
<AlbertA> kgunn: if you turn off the screen
<AlbertA> kgunn: and try to turn it back on it will never turn back on
<AlbertA> kgunn: it's waiting for allthe compositors to stop
<AlbertA> kgunn: but at the same time, the display is waiting on a power on  condition so it can unblock
<AlbertA> kgunn: so deadlock
<AlbertA> kgunn: what was the issue alexandros was looking at? that or something else?
<kgunn> AlbertA: so is it basically that it needs your powerd change to land first?
<AlbertA> kgunn: no it's real deadlock
<AlbertA> kgunn: just trying to understand how we can fix it
<kgunn> AlbertA: he was looking at 2 things...1 was apps in background still blocked
<kgunn> and then 2 some apps seemed to not render (or render beneath the shell)
<AlbertA> kgunn: ah I see what's happening...
<AlbertA> we turn stop the compositors, turn off the display, start the compositors again
<AlbertA> the display buffer compositors then try to post to display buffer
<AlbertA> which will be locked
<AlbertA> waiting for a power on change
<AlbertA> press the power button again, we try to stop compositors
<AlbertA> and we wait forever since one of them is blocked
<kgunn> you mean even with the change we "stop the compositors" ?
<AlbertA> the display buffer compositor yeah
<AlbertA> which makes sense
<AlbertA> well
<kgunn> b/c they can't touch FB's at that time ?
<AlbertA> kgunn: yeah
<racarr_> RAOF: Can you review cursor spike phase 1 again when you have time?
<kgunn> AlbertA: i'd agree with that...yeah, you gotta stop, to just "release" the FB's
<AlbertA> kgunn: I guess I can fix it in usc
<kgunn> AlbertA: i guess its "after display off, compositors start again"...why does it try to post to FB ?
<AlbertA> kgunn: if we are going to power on, power on display first
<kgunn> AlbertA: oh, you're assuming a rapid sucession of power button striking...e.g. this specific case is its "going to on"
<AlbertA> kgunn: why? because the multi threaded compositor has no idea about the display buffer power state
<AlbertA> kgunn: so it just receives start/stop
<AlbertA> kgunn: this is specific to going off then going on, it happens all the time for me
<AlbertA> kgunn: I don't see how it cannot actually
<AlbertA> kgunn: unless you are really fast yeah...then you shoulnd't see it :)
<kgunn> AlbertA: oh wait...you mean its not rapid...reaching steady state for off
<AlbertA> kgunn: yeah just a normal power off
<AlbertA> kgunn: then a casual power on
<kgunn> AlbertA: so when pressing the button to go to "on"...why do we try to "stop the compositors" again ?...e.g. aren't they in effect already stopped ?
<kgunn> i guess state-wise, they're technically not
<kgunn> ?
<AlbertA> kgunn: yeah that's what I'm changing now
<AlbertA> kgunn: if on = just turn on the display
<kgunn> right
<AlbertA> kgunn: if off = stop compositors, change display state, turn compositors back on
<AlbertA> kgunn: that will mean that we'll still have at least one stale buffer though
<AlbertA> kgunn: but I suppose we can work on that issue
<AlbertA> kgunn: later
<kgunn> AlbertA: yeah...its no worse than what we have at the moment
<kgunn> which is like a whole pipeline :)
<AlbertA> kgunn: ok this works
<AlbertA> kgunn: anything in particular I need to test for non-blocking?
<kgunn> AlbertA: hit power button, screen off with music playing, try volume
<kgunn> if volume keys work, then gui thd is svcing events
<AlbertA> kgunn: send mp3 through adb?
<kgunn> AlbertA: shamefully, i dunno :)
<AlbertA> kgunn: well volume keys not working
<kgunn> damnit
<AlbertA> kgunn: btw yeah sending mp3 through adb to /home/phablet/Music worked fine
<kgunn> AlbertA: this all seems strange...i don't think alf_ & greyback ever saw the display off deadlock, and the volume keys worked
<AlbertA> kgunn: strange..let me see the mir history
<kgunn> just thinking with them specifically testing screen off....they would see that
<kgunn> almost sounds like the compositors didn't "turn back on" in the sequence of comp-off, change-dpy-state, comp-on
<AlbertA> kgunn: I was testing with the fix proposed today, let me back that up
<AlbertA> kgunn: well I don't know what I'm missing...
<AlbertA> kgunn: I'm using the updated 0.1.9 branches for umir/usc/papi
<AlbertA> kgunn: and mir r1557 with alf's patch on top
<AlbertA> kgunn: oh I think I may need a unity change no? I think by default they pause when they receive the display off
<AlbertA> notification
<AlbertA> Shell.qml?
<kgunn> AlbertA: yeah...actually i thikn greyback commented out his changes in qtubuntu right before he EOD'd
<kgunn> he said something about it not doing what he thot
<AlbertA> kgunn: well I took out the greeter.show after a power off is received
<kgunn> hmmm...
<kgunn> https://code.launchpad.net/~gerboland/qtubuntu/surface-visible-hidden-side-channel/+merge/215884
<AlbertA> kgunn: that did the trick
<kgunn> he has attempt 2
<kgunn> oh cool...
<AlbertA> kgunn: in Shell.qml
<AlbertA> kgunn: I guess that triggers Qt's window management
<kgunn> AlbertA: does it do that pre-emptively ?
<kgunn> oh...yeah, maybe ?
<kgunn> mterry: might know ^
 * mterry  looks
<kgunn> mterry: mainly, the greeter.show from shell in a display off case
<mterry> kgunn, er, what problems does the greeter.show cause?
<AlbertA> mterry: the volume keys didn't work with the non-blocking egl swapbuffers branches
<AlbertA> mterry: after greeter.show
<AlbertA> mterry: if I take it out, during screen on, the volume keys work while playing music
<AlbertA> sorry screen off
<mterry> AlbertA, OK...  so the shell is trying to render frames while screen off, and it can't take input as a result...
<mterry> AlbertA, I wouldn't say that would involve Qt's window management, unless you mean a low-level window.  The greeter is just a Qml object being slid offscreen and on
<AlbertA> mterry: but it should be able to render now with the non-blocking implementation
<mterry> AlbertA, right...  Is it greeter specific?  Like, if you show something else..  Like maybe the launcher or something
<AlbertA> mterry: you mean do that in Shell.qml?
<AlbertA> mterry: of just leave the launcher on, hit power off
<mterry> AlbertA, yeah, keep greeter.show() commented out, but maybe do launcher.show() instead
<AlbertA> mterry: let me see
<mterry> AlbertA, just as a test to see if it's just anything with frames, or if greeter is doing something insane
<AlbertA> kgunn: I'm wondering now if eglSwapBuffers is blocking at the driver this time
<kgunn> AlbertA: very well would....at the driver level it would
<kgunn> most likely
<AlbertA> kgunn: oh...maybe we are hitting autosuspend
<AlbertA> kgunn: nah but then the music wouldnt' play
<racarr_> *not entirely sure I undewrstand the context*
<racarr_> but in this case eglSwapBuffers is mir egl swap buffers right so
<racarr_> I mean it only blocks if we block it?
<AlbertA> racarr_: it still goes through the driver first though
<kgunn> AlbertA: the music can play ok...it just won't advance to the next song or vol change
<kgunn> gotta restart....
<AlbertA> mterry: launcher.show() doesn't do anything, It doesn't show the launcher
<mterry> AlbertA, oh really?  let me see Shell.qml
<AlbertA> mterry: should that me showNow()?
<mterry> AlbertA, how about launcher.tease() then
<mterry> AlbertA, show() is not used, because the launcher is always dragged, not programmatically shown
<AlbertA> racarr_: so it goes through the driver then the driver calls us through AnativeWindow methods for android drivers
<racarr_> yes. I guess I just assumed it doesnt do any direct
<racarr_> hardware access itself or
<racarr_> try and do anything fancy but who knows
<AlbertA> well you never know, it's an egl context after all
<AlbertA> mterry: yeah that worked
<mterry> AlbertA, volume worked too?
<AlbertA> mterry: nah same issue
<AlbertA> mterry: which means we really do need Gerry's side channel branch
<mterry> AlbertA, OK, well good that greeter isn't doing something weird.  Just general qml stuff then
<AlbertA> mterry: right
<AlbertA> kgunn_: so it looks like it still blocks when qml tries to render things
<AlbertA> kgunn_: maybe I'm not pushing the correct libraries for mir nested
<AlbertA> kgunn_:I 'll check that
<kgunn_> ack
<AlbertA> kgunn_: well that wasn't it, I can see in the log the fake compositor is posting
<AlbertA> kgunn_: both in usc and unity8
<AlbertA> kgunn_: I guess time for gdb
<kgunn_> man....
<kgunn_> definitely leave the findings in a mail for gerry & alf
<AlbertA> kgunn_: the good news is that it doesn't seem to be blocked at the driver
<AlbertA> kgunn_: it's blocked at the client side waiting for the next buffer
<AlbertA> kgunn_: yeah I'll put all this on an e-mail
<AlbertA> kgunn_: ah I think I know why
<kgunn_> ....cliffhanger....why ?
<AlbertA> kgunn_: well since the display compositors are blocked
<AlbertA> kgunn_: they are never going to release the buffer they are holding
<AlbertA> kgun__: so eventually we consume all buffers from client but we have to return in sequence
<kgunn_> so it just blocks on buffers being full...
<AlbertA> kgunn: and that only happens when all compositors release their reference
<AlbertA> kgunn: so we probably need a way to just start the fake compositor only
<AlbertA> kgunn: at display off
<kgunn_> this is what duflu was hinting at i think...wrt unsync'd swapinterval0
<AlbertA> kgunn: uhhh, yeah we have to guarantee sequence
<AlbertA> kgunn: but that's ok, the fake compositor will guarantee that
#ubuntu-mir 2014-04-16
<RAOF> racarr_: Enjoy your +1 on cursor-spike.
<AlbertA> looks like the landing ci is stuck?
<AlbertA> there's 4 MP's ready to land for the last 10 hours and they haven't landed yet
<kgunn> ack, will see if someone in ci can kick the coke machine
<duflu> AlbertA: Umm, happy final release eve... ?
<duflu> That shouldn't block anything though
<AlbertA> duflu: oh is that what it is?
<duflu> https://wiki.ubuntu.com/TrustyTahr/ReleaseSchedule
<duflu> Probably not related. People are usually working furiously on SRU-0/SRU-1 for their various projects around now
<duflu> which means blocking is unexpected
<AlbertA> kgunn: so for the non-blocking swapbuffers I believe the best course of action is to avoid
<AlbertA> kgunn: starting the display buffer compositor threads during display off
<kgunn> AlbertA: so does that just end up making it an order of operation issue, and can you guarantee display on prior to starting disp-buff-comp ?
<AlbertA> kgunn: well currently the responsibility lies on whoever is changing the display configuration
<kgunn> usc ?
<AlbertA> kgunn: they need to make sure the compositor is stopped before changing the display configuration
<AlbertA> kgunn: yes usc in this case
<AlbertA> kgunn: the main issue will be that the compositor will have to have indication of the display power state somehow
<AlbertA> kgunn: so either it's start method takes a hint parameter
<AlbertA> kgunn: or the compositor interface exposes some method that makes sense for display power off
<kgunn> AlbertA: right...i would think you'd want more of a handshake, hint "i need to know when you've actually stopped/started"
<AlbertA> kgunn: well you want the compositor to only start the buffer consuming thread only
<kgunn> mmm, yeah, maybe it does...
<AlbertA> kgunn: the hard part is not exposing those internal implementation details
<kgunn> well it is the "display" buffer compositor
<kgunn> so it does imply it can "know" display stuff
<kgunn> ok...still on irc on my other machine...trying xmir again :)
<kgunn_> RAOF, ok...ssh'd into my other machine which is now a black screen on xmir attempt
<RAOF> kgunn_: Good, good. If you restart lightdm, does anything happen?
<kgunn_> one note, early today i reinstalled xserver-xorg-*, dri2 wondering if that would cleanly return any default conf files that might have been hosed....(e.g. apt-get install --reinstall..) is that true ? would it cleanly take care of conf files?
<kgunn_> RAOF, so i just restarted lightdm, nada
<kgunn_> just black screen
<kgunn_> lightdm.log says waiting for signal from xserver, Process 8238 terminated with signal 6
<RAOF> SIGABRT is unlikely to end in pleasantness.
<RAOF> What sayeth /var/log/Xorg.0.log?
<AlbertA> kgunn_: actually what I've said is already taken care of by https://code.launchpad.net/~afrantzis/mir/expose-display-buffer-only-for-power-mode-on/+merge/214758
<AlbertA> kgunn_: I wonder why that's not the case...
<kgunn_> RAOF, so it seems to go thru some display config checking & updates...then
<kgunn_> just before backtrace its [  9484.653] (II) Putting surface on output 9
<kgunn_> [  9484.653] (EE) Backtrace:
<kgunn_> [  9484.653] (EE) 0: /usr/bin/X (xorg_backtrace+0x48) [0x7fd14470ec48]
<kgunn_> [  9484.653] (EE) 1: /usr/bin/X (0x7fd144566000+0x1ac939) [0x7fd144712939]
<kgunn_> [  9484.653] (EE) 2: /lib/x86_64-linux-gnu/libpthread.so.0 (0x7fd143663000+0x10340) [0x7fd143673340]
<kgunn_> [  9484.653] (EE) 3: /lib/x86_64-linux-gnu/libpthread.so.0 (pthread_mutex_lock+0x4) [0x7fd14366d414]
<kgunn_> ...is this some stupid "hybris got installed" thing ?
<duflu> kgunn_: Only if you have hybris installed :)
<kgunn_> hmmm, so libhybris isn;t, but ...libhybris-common1 is ?
<duflu> kgunn_: Yeah apparently that much is safe
<duflu> And required, for some reason
<kgunn_> ok...everytime i see pthread's i think libhybris...just cause of the tegra thing
<RAOF> Harumph.
<duflu> kgunn_: When that happens the path name will contain "hybris" so it's OK
<RAOF> That's *all* the backtrace?
<duflu> Also it will only apply to lib*GL
<kgunn_> the whole thing is https://pastebin.canonical.com/108605/
<RAOF> Hm. Died in mir_surface_is_valid?
<RAOF> So I guess what's happening here is that XMir is getting a null MirSurface* and calling mir_surface_is_valid on it.
<AlbertA> kgunn_: so it turned out I was not updating the mir platform libraries on my device...:)
<AlbertA> kgunn_: volume keys work just fine now
<kgunn_> ah man!
<duflu> RAOF: https://bugs.launchpad.net/mir/+bug/1248474
<ubot5> Ubuntu bug 1248474 in Mir "mir_surface_is_valid(NULL) crashes instead of returning false" [Medium,Triaged]
<RAOF> Another well-known cleanup bug!
<kgunn_> this is the part where duflu throws me "that  look"
<kgunn_> i don't mean to question the experts...but, i'm on a mac/intel w/ integ gfx...wouldn't think it would be a consistent prob
<kgunn_> others would've complained ?
<RAOF> I would have thought so, yes.
<AlbertA> can anybody else download branches through bzr? Getting connection issues
<RAOF> Also, how *can* we get a null MirSurface? The callback is called from Surface::created() thusly: callback(this, context);
<kgunn_> AlbertA, fails here too
<kgunn_> RAOF, so if its really a mir thing, then i should fail to launch a demo_server
<kgunn_> right ?
<RAOF> kgunn_: Probably, yes.
<kgunn_> RAOF, hmmm...got majorly distracted, but ok, server seems to launch, but client does fail w a seg fault
<kgunn_> and gdb backtrace showing same mir_surface_is_valid
<kgunn_> ok...heading to bed, maybe some more tomorrow
<RAOF> Bah! That's really annoying.
<RAOF> Stupid race-condition testing!
<alf_> greyback: Is this still needed? https://bugs.launchpad.net/mir/+bug/1226778
<ubot5> Ubuntu bug 1226778 in Mir "[unity8 shell] mc::Compositor has no method to get running state" [High,Incomplete]
<greyback> alf_: I think calling stop() twice doesn't cause a crash any more, so that bug is more a nice-to-have.
<alf_> greyback: ok, marking as "wishlist" then
<kgunn> alf_: AlbertA greyback ...ok, unity-mir, qtubuntu rebuilt...
<alf_> kgunn: ok updating
 * greyback too
<alf_> kgunn: greyback: what do the updates fix/improve?
<greyback> alf_: the qtubuntu change will have Qt client apps stop rendering as soon as they are off-screen (well, when they get lifecycle events)
<alf_> greyback: ah, great
<greyback> alf_: I have instructions in a comment in https://code.launchpad.net/~gerboland/qtubuntu/surface-visible-hidden-side-channel/+merge/215884 to show how you can test it
<greyback> I'd appreciate a third party check...
<kgunn> will update also ...(when/if i can stop the irc pinging)
<alf_> kgunn: kdub: racarr_: stand up
<alf_> greyback: confirmed that printDate.qml stop requesting buffers, but still keeps printing to stdout with latest silo builds
<greyback> alf_: that's perfect
<greyback> alf_: the printing is from the GUI thread, which can continue working unblocked
<greyback> so the rendering thread has shut down cleanly
<greyback> (sorry I always fall into the Qt terminology. GUI thread = even handling thread)
<greyback> event
<alf_> greyback: seems so, I am running with MIR_CLIENT_RPC_REPORT=log and see that the client stops requesting buffers
<greyback> alf_: yes, sounds right
<greyback> \o/
<greyback> \o\
<greyback>  /o/
<alf_> greyback: exercising? ;)
<alf_> _o_
<alf_> \o/
<alf_> _o_
<alf_> \o/
<greyback> lol
<greyback> just happy this is working :)
<alf_> greyback: kgunn: hmm, the falling-letters app freezes when you turn the screen of and back on again
<alf_> greyback: kgunn: but other apps (e.g. sudoku) work fine, so perhaps that app is at fault?
<greyback> alf_: confirmed. will investigate
<alf_> greyback: the camera-app freezes too, but the clock doesn't, perhaps it has to do with whether there is some animation/app update going on when the screen is turned off (just wild guess)
<kgunn> kdub: if you do happen to try xmir...i'd be interested to hear your results...and _after_ confirming it works, if you could try the mir/usc in ppa:ci-train-ppa-service/landing-003
<kgunn> that would be interesting
<kdub> kgunn, i'm set up to try the demo server/shell pretty quickly, was that broken too?
<kgunn> alf_: greyback ...is there a chance here the apps aren't expecting the expose event ?
<greyback> alf_: that shouldn't be the case, most animations run on the unblocked thread. But yeah the render thread is blocked for dropping letters, need to figure out why
<kgunn> kdub: demoshell/client was broken for me yes
<kgunn> agian...it might be me
<kdub> i'll try that out real quick.. a few minutes
<kgunn> greyback: do you know if dropping letters and camera are pure qml ? (i would suspect dropping letters is for sure)
<greyback> kgunn: it is pure qml
<kgunn> mmm there goes that theory
<greyback> so I must have something wrong in qtubuntu
<kgunn> or bug in qt itself...
<greyback> I'll assume I'm at fault first :)
<racarr_> even if the expose event wasnt working apps should be rendering out of control and not blocking right?
<racarr_> (maybe this has evolved since I briefly understood it in london ;))
<greyback> indeed. But I've managed to do this in qtubuntu before, it sometimes managed to lie to the renderer and renderer gets locked up
<racarr_> -.-
<alf_> greyback: in case it is helpful, here is the client rpc log for mir when running dropping-letters: http://paste.ubuntu.com/7262240/
<alf_> greyback: Result id:0 responses are events
<AlbertA> kgunn: just checked mir/devel on my haswell laptop, demo server/client works well here
<greyback> alf_: is definitely my problem, render thread not shutting down correctly, need to determine why...
<kgunn> ta AlbertA
<kgunn> so when you play video, it keeps playing for about 2 secs when you hit the power button....and then immediately restarts for ~1 second after unlock
<kgunn> even tho, you cant see it, but stops again, until you bring it into focus
<kgunn> oops...ok, browser locked up
<kgunn> greyback: alf_ ^
<kgunn> ...i abused it several times before lockup
<kgunn> (and only the browser, shell & other apps still respond)
<greyback_> kgunn: I've something that I think will fix it. Have just pushed it to the qtubuntu branch. Am building package
<greyback_> (locally)
<kgunn> ack
<kgunn> dude...watching the "i think we're alone now" trailer over and over is strarting to creep me out
<racarr_> ...
<racarr_> :p
<greyback_> kgunn: could you please test http://people.canonical.com/~gerboland/qtubuntu-android_0.54+14.04.20140402-0ubuntu1_armhf.deb
<greyback_> and see if it fixes the blocking issue
<josharenson> Is there an easy way to change the background color of mir_server_demo_shell? I think I found a bug, and changing the color to, say red, would make identifying it a bit easier.
<kgunn> greyback_: i will...stepping out for a quick bite
<kdub> josharenson, search for glClearColor in the examples/ code... i beleive its set to grey there
<josharenson> kdub: ack
<greyback_> kgunn: ok. I'm heading out for dinner, so will be away a few hours. Please email with the verdict
<kgunn> lunch date running late...lemme see if i can do quickly
<greyback_> man the new browser is good
<kgunn> greyback_: nope.....same experience
<greyback_> kgunn: with dropping letters even?
<kgunn> sorry...just video
<kgunn> lemme check dropping letters
<kgunn> cool!...time out worked on video...same little hiccups
<greyback_> you play video from the video scope right? Why not working for me...
<kgunn> yep, i'm playing the "i think we're alone now"
<greyback_> ** (process:2021): WARNING **: Unable to dispatch url 'https://videosearch.ubuntu.com/v0/redirect?s=TPzN98RZt0eNHhrYvplj9d3_WtKAbOSC3wun2Q%3D%3D&u=http%3A%2F%2Fvodo.net%2Fitwan':GDBus.Error:com.canonical.URLDispatcher.BadURL: URL 'https://videosearch.ubuntu.com/v0/redirect?s=TPzN98RZt0eNHhrYvplj9d3_WtKAbOSC3wun2Q%3D%3D&u=http%3A%2F%2Fvodo.net%2Fitwan' is not handleable by the URL Dispatcher
<kgunn> no hang on dropping letters....
<greyback_> ok, improvement
<greyback_> though I notice dropping letters not pausing when we switch away from it
 * greyback_ has to go
<josharenson> if MIR_BYPASS is unset, then bypass is enabled?
<kdub> 1) that's becoming MIR_SERVER_BYPASS very soon and 2 yes, default is on
<kdub> its also becoming a --help option soon, so it will be clearer wh at the default is
<dandrader> "what():  error during hwc prepare(). rc = ffffffff"
<dandrader> is that known on the N4? ^
<kdub> dandrader, not known
<dandrader> oh, that's surprising
<dandrader> happens when I turn off/on the display, pressing the power button
<dandrader> backtrace is useless as usual
<kgunn> camako: ^ might be an intersting one
<kgunn> what josharenson found
<kdub> dandrader, yeah, I know there's some synchronization issues with the compositor/display power on/off being worked on
<josharenson> kgunn: ?
<josharenson> kdub: that sounds like what I see... flickering/tearing when starting fullscreen app
<camako> kgunn: abt bkgrnd color?
<kgunn> sorry josharenson, meant dandrader
<josharenson> ah
<kgunn> camako: sorry, meant the hwc prepare issue
<kdub> josharenson, well, bypass is only on the mesa platform, is that where you're seeing it?
<kgunn> as far as digging in code
<camako> kgunn: o i see
<josharenson> kdub: nope
<camako> kgunn: perfect.. right up my alley :-)
<josharenson> kdub: reason I wanted to change bkgnd color is i see the flickering when unity is running... want to isloate unity/mir
<camako> dandrader: does it happen every time?
<josharenson> kdub: working on other things now, but will file a bug when i investigate in a bit (my guess is it will be a dupe of something filed already... I'll read up)
<dandrader> camako, started happening consistently after I restarted unity8 manually.
<kdub> greyback and alf_ , they might know something more than me
<camako> dandrader: let me poke around a bit
<dandrader> camako, btw, I was using the "qt as mir compositor" branch of unity8, if that makes any difference...
<camako> dandrader: I see
<AlbertA> we are hitting some sort of timeout issue in CI for landings
<AlbertA> https://jenkins.qa.ubuntu.com/job/mir-mediumtests-runner-mako/1116/console
<AlbertA> https://jenkins.qa.ubuntu.com/job/mir-mediumtests-runner-mako/1117/console
<AlbertA> kdub: ^ just pinged CI channel they are checking
<kdub> oh, I just was poking through that, and retriggered the landing
<AlbertA> yeah me too :)
<kdub> sometimes that's a transient problem, other times, its a permanent problem
<AlbertA> kdub: I guess the lander is getting hit hard today
<kdub> AlbertA, yeah, those 4mps have been waiting a while
<kgunn> camako: i think dandrader means this... https://docs.google.com/a/canonical.com/document/d/163nyfh_G90nzQnRdI7IYgrMH_0VdmesBju5jpb4wse0/edit
<camako> kgunn: Thanks for the doc... I am looking through code atm...
<AlbertA> dandrader: and you sure unity8 is started in nested mode? sounds like it's not
<dandrader> AlbertA, hmm, that could be it!
 * dandrader tries
<dandrader> AlbertA, you got it.
<AlbertA> dandrader: cool
<kdub> i'm being brave
<kdub> and cleaning up GLRenderer test
<racarr_> IN TO THE DEPTHS!
<anpok> yeah thats an interesting bunch of tests
<kdub> it was maybe the second test ever written
<racarr_> Ok...mostly finished...new ozone-mir (lots of upstream changes, quite helpful ones...just...all the code has to change)
<racarr_> feeling kind of exhausted though, so going to switch to fixing this bug I found in introduce-scene-observer (or think might exist, rather the first task is writing a test)
<racarr_> and then fiddle with xinput for a while.
<racarr_> actually first im going to eat ice cream. haha. brb.
<kgunn> AlbertA: camako....good grief this took me too long....could you review https://wiki.ubuntu.com/Mir/NonBlockingSwapTesting#preview
<camako> kgunn: sure... how soon do you need it?
<kgunn> just look it over for 5 min...for any big idea that maybe i missed
<kgunn> pretty sure the notes are good...its editable :) so we can fix if it strikes you in 10 minutes not 5
<camako> kgunn: looks good to me
<camako> kgunn: but what do I know...
<kgunn> camako: thank you mir-expert :P
<camako> kgunn: at least wording is good and I was able to follow the text... Dunno abt the commands mentioned therein..
<camako> kgunn: mir-expert... :-)
<kgunn> greyback: earlier you said dropping letters isn't stopping...but it is, i think you just witness that a few more letters drop before sigstop
<greyback> kgunn: right, but there are times that it's not sigstopped, yet it is not in front. Leaving the spread open for instance.
<greyback> kgunn: oh, would you please kick qtubuntu to build the latest revision
<kgunn> greyback: you bet
<greyback> thanks
#ubuntu-mir 2014-04-17
<AlbertA> kgunn: wiki looks good
<kgunn> thank you sir
<kgunn> btw, new qtubuntu in packages
<kgunn> AlbertA: you still on? do you kow if you can get screen shots on unity8 desktop preview ?...or do we still have the mesa bug ?
<AlbertA> kgunn: like with mirscreencast you mean or something else?
<kgunn> AlbertA: yeah screencast
<kgunn> olli: ^
<AlbertA> kgunn: I wasn't aware of a mesa bug. but screenshots should work let me check on the demo server
<olli> how exactly do i do that
 * olli has to bath the baby
<kgunn> AlbertA: you gotta pass in flags right ? ...or you can enable on the fly
<kgunn> ?
<olli> bbiab
<kgunn> seems olli you'll likely have to hack the scripts somewhere to pass flags in to enable screenshotting
<AlbertA> kgunn: yeah it's a command line utility
<kgunn> hmmm....we almost need a "special" usc to just do this when we need to...
<AlbertA> you should be able to do
<AlbertA> mirscreencast -m /tmp/mir_socket
<AlbertA> if you do mirscreencast -m /tmp/mir_socket --query it tells you where the file name will be and where it will end up
<AlbertA> so for a screenshot in my laptop I did
<AlbertA> mirscreencast -m /tmp/mir_socket -n 1
<AlbertA> kgunn: and then you can use convert -depth 8 -size 1920x1080 /tmp/mir_screencast_1920x1080_60Hz.bgra screenshot.png
<kgunn> AlbertA: mmm....so, mirscreencast is really just like a client app ?? so olli can just glom on to the existing usc server started by the unity8 session ??
<kgunn> duflu: you better ?
<AlbertA> kgunn: yeah I think the default authorization to allow screenshoting
<kgunn> ok...i better bail, wife kinda irritated
<olli> AlbertA, thx
<olli> I'll give it a shot
<alf_> duflu: https://code.launchpad.net/~vanvugt/mir/no-savings/+merge/216084/comments/513688
<duflu> alf_: OK. Unfortunately there's not long left in the week. I suspect we might have triggered an odd multi-monitor frame sync bug because I believe the change is theoretically correct
<duflu> I might try a couple of machines and see if I can find one which exhibits the issue.
<duflu> alf_: What GPU?
<duflu> number of monitors?
<alf_> duflu: i965, built-in laptop monitor
<duflu> alf_: Hmm. Then again Intel is showing obvious vsync regressions at times. Wonder if that's related
<duflu> ... seems to have come with the new kernel in trusty
<duflu> alf_: No (idle) monitor attached?
<alf_> duflu: with either only the built-in monitor or a monitor attached with sidebyside configuration I get the speed-up. However with monitor attached and clone configuration I don't.
<duflu> alf_: OK, obviously something somewhere is violating the basic rule of getting a new buffer only when buffer(id) is called with a previously seen id
<duflu> ... the buffer consuming stuff should behave just like another monitor
<alf_> duflu: at some point something happens and things get locked for a bit in [BufferConsuming] compositor_acquire enter: (0x7f1cd80025e8,nfree=0,nclients=0,nready=3,ncompositors=0)
<alf_> [BufferConsuming] same_frame: 1 can_recycle: 0
<alf_> duflu: and the same for [Compositing]
<duflu> alf_: Sounds like a deep problem I won't fit into my head today, or this week
<duflu> On the plus side, there is some serious sleep on the horizon
<alf_> duflu: enjoy :)
<duflu> Oh, umm, happy LTS release day
<duflu> The web site's not showing it published yet though
<greyback> kgunn: hey, for bug 1308735, at step 2, does the video play continually in the background? For me it stops after ~3 seconds, which is as I'd expect as it is SIGSTOPped
<ubot5> bug 1308735 in Mir "[nonblockswap] video playing a bit after screen off and after unlock" [Undecided,Incomplete] https://launchpad.net/bugs/1308735
<greyback> kgunn: never mind, I misread your description
<dandrader> anpok,  any estimate on when you will have the needed input branches ready?
<anpok> hmm probably not today..
<anpok> i think it will come with an easter egg?
<anpok> so the new send part is now as far as the other MP
<anpok> just right now adding the result handling
<anpok> dandrader: interface is more or less ready - i can update the WIP branch
<anpok> and you could start using it..
<dandrader> anpok, awesome
<josharenson> kgunn: How important is it that we run glmark w/ and w/o bypass?
<josharenson> kgunn: because if I remove that part, it would be nice to get the code merged and start working on the reporting tool (which robot fuel has provided me with info for)
<kgunn> josharenson: totallly want to get the ci part done....then we can fart around with variants
<kgunn> +1 on your thinking
<josharenson> kgunn: ok, its close
<kdub> alan_g, when your'e done with the discussion, could you weigh in on https://code.launchpad.net/~kdub/mir/platform-specific-bypass-option/+merge/214816 again?
<kdub> some back-and-forth over enum class vs bool
 * alan_g sighs
<kdub> sorry :)
<josharenson> kgunn: any value in writing a helper class for performance tests that can add PPAs and install packages? It seems that installing glmark2 during the test is the best way to go about things...
<kgunn> josharenson: that seems valuable to me
<kgunn> josharenson: also, to be sure, you're not turning on preformance tests/glmark2 by default as part of the build process ? (e.g. jenkins job runs it just like android integration tests...only for hw)
<kgunn> camako: thank you for the list
<camako> kgunn: Sure.. A bit raw but a start
<josharenson> kgunn: ack
<kgunn> AlbertA: did a test get added for stale socket removal ? panic the driver, orphan the socket and ensure it gets cleaned
<AlbertA> kgunn: yeah
<AlbertA> kgunn: probs with it?
<kgunn> excellent
<kgunn> nope just wanted to make sure
<AlbertA> kgunn: oh you scared me there for a moment
<AlbertA> kgunn: :)
<ahayzen> kgunn, Hi I'm one of the music-app devs, FYI i've just tried your NonBlockingSwapTesting and after some quick testing it appears to have resolved our issues. I'll continue testing over the next few days and report any issues I find. Thanks for all the hard work your team has put into this.
<kgunn> ahayzen: thanks for testing!
<ahayzen> kgunn, no problem
#ubuntu-mir 2014-04-18
<riesgo> hello
<mterry> What's the best way for USC to tell a session to "freeze" -- i.e. don't render any frames.  I thought it was hide(), but it seems that doesn't stop it from swapping buffers
<mterry> Do I send a lifecycle event?
<racarr_> mterry: Lifecycle event is the best atm but its all in flux a little
<mterry> racarr_, I tried, but it didn't seem to affect anything
<mterry> on 0.1.8
<racarr_> mterry: I dont think it will in 0.1.8...sorry im not sure exactly what code is in what phases right now
<racarr_> but because of the non blocking swpa buffers stuff hide no longer stops things
<racarr_> from swapping buffers
<racarr_> and instead qtubuntu interprets
<racarr_> the lifecycle events
<racarr_> to stop rendering
<mterry> k...
<racarr_> is my understanding
<racarr_> but im not sure its 100% landed
<AlbertA> mterry: any reason for trying to stop swapbuffers at USC?
<ice9> is there any advantage to use Mir instead of X currently?
#ubuntu-mir 2015-04-13
<alan_g> kdub: AlbertA RAOF now returning void. Please check: https://code.launchpad.net/~alan-griffiths/mir/first-pass-of-surface-spec-modification/+merge/255707
#ubuntu-mir 2015-04-14
<racarr> reading kDBus thread...
<racarr> * With priority-inheritance, we can do synchronous calls into trusted
<racarr> peers and let them optionally use our time-slice to perform the
<racarr> action. This allows syscall-like/binder-like method-calls into other
<racarr> processes. Without priority-inheritance, this is not possible in a
<racarr> secure manner (see 'priority-inheritance').
<racarr> that could be cool for us...(the time slice donation)
<alan_g> I love it when a test tells me I accidentally broke something I didn't even realize I was touching
<kdub> alan_g, with ~alan-griffiths/mir/first-pass-of-surface-spec-modification and my comment about rejecting some spec requests
<kdub> it kinda feels like i'm coming late to the party on this discussion, but if there are some specs that can be invalid, isn't aborting on those a bit unfriendly to the client-api-users?
<alan_g> kdub: if the client wilfully creates a spec intended for change and then tries using it for create they are breaking the contract and we shouldn't hide that.
<alan_g> It isn't as though anything is outside their control
<kdub> so, it just seems that aborting for misuses is harsh... and I guess I also see some degree of difference between requesting an invalid operation for a specific MirSurfaceType, and trying to do something that clearly violates the contract
<kdub> and I guess I'm also assuming that there are some violations of policies that are more subtle, like, trying to resize or reposition type X that would be unclear to a client
<alan_g> aborting is better for the client writer than trying to carry on and having unexpected behaviour later
<alan_g> violations of policies (trying to resize a maximized window) are not invalid surface specifications but things the window management policy decides
<alan_g> and that doesn't break contract and lead to an abort
<kdub> right, so there's no such thing as an invalid MirSurfaceSpec?
<kdub> its more that the client is just setting preferences (which can't fail), and that the server tries to respect the preferences, according to WM policy
<alan_g> There can be a MirSurfaceSpec that is invalid for create, but not for apply
<alan_g> But, yes that's the model
<kdub> okay, so I based the comment on the idea that there was an "apply spec" that could be invalid, but if there's not, then I guess, comment resolved!
<duflu> alan_g: We're going to need an expanded input::Surface in the stack to cover the "aura" or invisible resize area. I can imagine it could be either a secondary input::Surface underneath the existing one, or an expansion of the existing input::Surface. Do you have plans either way?
<alan_g> duflu: not yet. But it likely will be done in terms of the bufferstreams kdub has started
<duflu> alan_g: No I just mean the input region (which has no buffer stream)
<duflu> It needs to extend beyond the buffer streams
<alan_g> Exactly, currently there's a buffer stream conflated with the surface
<duflu> alan_g: "buffer stream" shouldn't come into it. I'm not talking about pixels, just the invisible input region (that doesn't overlap any bufferstream)
<alan_g> duflu: buffer stream comes into it because it is currently conflated with the surface (and needs separating)
<kdub> right, so it would be a surface of size 100x100, and the buffer stream would be at 10,10 of size 80x80?
<duflu> kdub: No, the input surface would be at (-10,-10) of the surface. Because the aura doesn't affect placement either
<duflu> We already have input::Surface. Just need to unconflate it with the visible surface/buffer stream
<duflu> Possibly with two separate input::Surfaces per surface
<kdub> ah, yes I see
<duflu> Or three
<kdub> so maybe a MirSurface can have multiple buffer streams, and multiple input regions...
<duflu> kdub: Yeah one or more. But only input over the client area goes to the client. Input to the aura should be handled by the server
<duflu> -server + shell
<duflu> Presently you can click the invisible input region of a non-focused window to raise it. That might not be important, but you still need to be able to do that to resize non-focused windows
<duflu> kdub: I like the idea of adding the aura as a new input::Surface under the existing one. If input hits that then the shell handles it without the client being aware
<duflu> It's also then independent of the decoration mode (client, server or hybrid)
<alan_g> That's similar to what we have for title bar in examples
<duflu> Maybe. I'm not aware of anyone making the input surface dimensions different to the buffer stream though
<duflu> Yet
<kdub> so, having aura as a new input::Surface seems like a good idea to me, and having the input surface dimensions be different also seems okay
<kdub> with the limitation that the client api cant go grabbing input from anywhere on the screen
<duflu> kdub: No the client would never be aware of it. It's all shell handled
<kdub> right, so that plan seems even better then
<duflu> kdub: We might want to start calling each app a window now :)
<kdub> yay
<duflu> Umm, the demo servers are all freezing on my laptop today. Did we break Mir or the kernel or something else?
<alan_g> duflu: quick test of mir_demo_server seems OK - any clues to reproducing?
<duflu> alan_g No clues yet
<duflu> Everything worked yesterday but not today
<duflu> I do update my system and Mir every day
<alan_g> You just start it and it hangs?
<duflu> Yep
<alan_g> Hmm. I've not updated system today
<duflu> Mouse doesn't move and can't switch VTs
<duflu> alan_g: Yeah bisecting now. We broke lp:mir this past day
<alan_g> duflu: confirmed, must be since I updated mir around lunchtime
<alan_g> The only plausible culpret is -c 2480
<duflu> alan_g: Yeah testing that one now
<duflu> alan_g: No r2480 is also broken. r2477 works so guess
<duflu> kgunn: Built as a deb solves all my Xmir problems. I'll do that and learn what I did wrong from debian/* later
<duflu> Yesterday was going on 3 hours sleep at most
<alan_g> duflu: I think one of us misunderstands - I'm guessing 2480 broke it (so predicting 2479 works)
<duflu> alan_g: Yes, whoops. probably
<duflu> alan_g: Doing final verification now. If that's it I'll just revert it. The change is too non-trivial and the bug too critical to wait for the proper fix
<alan_g> duflu: +1
<duflu> alf__: Re flickering we did land Android buffer changes yesterday.... :)
<duflu> Or not using 0.13?
#ubuntu-mir 2015-04-15
<alan_g> alf__: OK now? https://code.launchpad.net/~kdub/mir/mesa-reconstruct-buffer/+merge/255722
<alf__> alan_g: yes, approved
<alan_g> :)
<duflu> mterry: http://bazaar.launchpad.net/~mir-team/mir/development-branch/view/head:/doc/demo_shell_controls.md
<racarr> Can I have one more review on nested-cursor-pass-through? I feel like there have been too many changes since the last review
<racarr> anpok: You are needs information which should be addressed
<racarr> Ahhhh. New-input-dispatcher seems to be working fine :) now in the extract small branches out of it phase
#ubuntu-mir 2015-04-16
<anpok> alf__: i could also just avoid the rethrow as a workaround
<anpok> and just test that the exception handler gets called with !=nullptr exception
<alf__> anpok: sounds good
<anpok> hm there is a fixed version of rethrow attached to the bug report
<anpok> alf__: are errors like "terminated without an active excpetion" other symptoms of this error?
<alf__> anpok: ENOCONTEXT
<alf__> anpok: which is "this error"?
<anpok> the wrong active exception counter
<anpok> caused by rethrow_exception..
<duflu> mterry: https://code.launchpad.net/xmir
<duflu> attente_: Noticed you're keeping GTK up to date with lp:mir. Thanks for that. Is much improvement happening or just fixes?
<attente_> duflu: just fixes. is there any new api available we can use in gtk?
<duflu> attente_: Yes. You can now set the window title, and resize yourself. Possibly more
<attente_> duflu: nice, i'll take a look into using that
<duflu> attente_: Also while you want (if you want) to do your own title bar, try setting surface type freestyle and we'll update the demo shells to not add titlebars to them
<duflu> mterry ...
<duflu> /usr/include/features.h:364:25: fatal error: sys/cdefs.h: No such file or directory
<duflu>  #  include <sys/cdefs.h>
<duflu>                          ^
<mterry> duflu, libc6-dev
<duflu> mterry: lib32gcc-4.9-dev
<mterry> duflu, http://www.tweaking4all.com/software/linux-software/use-xrdp-remote-access-ubuntu-14-04/
<mterry> duflu, nano /etc/xrdp/startwm.sh
#ubuntu-mir 2015-04-17
<alan_g> alf__: bug 1445473 is worrying. Are you working on it?
<ubot5> bug 1445473 in Mir "Acceptance tests link with static versions of client library and server components" [High,New] https://launchpad.net/bugs/1445473
<alf__> alan_g: Not yet. I just tried removing the transitive dependencies, but got various errors.
<duflu> alf__: You might want to change pm-fail to pm (which is what I've already used in Mir bugs)
<alf__> duflu: tvoss asked for this tag to mark bugs that with a proper architecture shouldn't be filed against USC but rather powerd or similar
<alf__> duflu: (there was a discussion about reworking the power management architecture)
<alf__> duflu: (repeating in case you missed them)
<alf__> duflu: tvoss asked for this tag to mark bugs that with a proper architecture shouldn't be filed against USC but rather powerd or similar
<duflu> alf__: Yep OK. I added "pm" for general power management bugs
#ubuntu-mir 2015-04-19
<mibofra> hi guys, a question. If I use for a porting a cyanogenmod 10.2 instead of the 10.1, this will broke anything with mir?
#ubuntu-mir 2016-04-18
<duflu> alan_g: You might find this shortlist handy:  https://bugs.launchpad.net/mir/+bugs?field.tag=gtk-mir
<alan_g> duflu: thanks
#ubuntu-mir 2016-04-20
<hikiko> hello
<hikiko> is it possible to run mir-u8 on a vm? (and which one?)
<hikiko> I tried virt-manager yesterday but it doesn't seem to have hardware acceleration by default
<duflu> hikiko: Hi. In theory, yes anpok did some work on that but only one or two hypervisors work. I'm not sure which
<hikiko> :D
<hikiko> thanks duflu
<hikiko> I'm going to ping him
<duflu> hikiko: He'll be on soon
<duflu> hikiko: Oh Mir has doc/* for it
<duflu> doc/setup_kvm_for_mir.md  doc/setup_vmware_for_mir.md
<hikiko> https://unity.ubuntu.com/mir/setup_kvm_for_mir.html
<hikiko> :)
<hikiko> ok let's see
<hikiko> alright that's what I did but with 4.4.0-18-generic
<hikiko> and didn't build krm-next
<duflu> hikiko: The web docs are always old (represent the last Ubuntu release) so check the source
<hikiko> alright :)
<hikiko> thanks duflu
<duflu> No worries
<hikiko> installed :D
<hikiko> I have u8 running on virt-manager \m/
<anpok> using kms-swrast or using vt-d?
<hikiko> anpok, lsmod doesn't show any of them
<hikiko> I see qxl, drm_kms_helper
<anpok> ok kms swrast .. I was recently messing around with forwarding graphics cards to kvm directly.. by disabling them on the host..
<anpok> and ran into assertions in qemu
<hikiko> do I have to do that to experiment with u8?! :s
<anpok> nah
<hikiko> :D
#ubuntu-mir 2016-04-22
<hallyn> bah - so i can use /etc/default/keymap to set capslock as control in *console*, but unity8 still resets it to capslock :(
<RAOF> hallyn: Urgh. Yeah, we don't read that properly at the moment. U8 isn't friendly to keyboards that aren't qwerty en_US.
<hallyn> RAOF: drat, that's a bit of a blocker to getting serious work done in unity8
<RAOF> Yes; particularly for me, as I use a dvorak keymap.
<RAOF> So it's just plain wrong.
<RAOF> https://bugs.launchpad.net/mir/+bug/1570340
<ubot5`> Launchpad bug 1570340 in Canonical System Image "Mir should read default keymap from udev properties." [Medium,Confirmed]
<hallyn> oh that reminds me i need to add a comment to the webbrowser-app crashing bug
<hallyn> RAOF: ouch :)
<RAOF> If you'd like to fix it yourself, it probably wouldn't be *that* hard. I could mentor you!
<Mirv> kdub: kgunn: related to https://code.launchpad.net/~kdub/mir/avert-1563287/+merge/292298 Turbo also has Mali, or have you tested there's such a difference between T720 and T760?
<Mirv> all our shipping or soon to be shipping devices have Mali.
<kgunn> Mirv: we only have like 3 turbos among us, i do think kdub has one?
<kdub> no
<kdub> we can add the turbo name to that list, if that's what's being asked
<kgunn> kdub: really?!?
<kdub> I'll probably just change to a whitelist for adreno instead of a blacklist
 * kgunn knows he asked
<kdub> oh, I don't want one :)
<kgunn> kdub: pvr ?
<kgunn> ;)
<kgunn> kdub: can you blacklist mali midgard
<kgunn> ?
<kgunn> rather than device
<kgunn> just gpu
<kdub> not yet
<kdub> there's a card about it
<kgunn> ? i feel like i've done this
<kgunn> with a pvr quirk
<kdub> we have a quirk system, but its config file + device name
<Mirv> ok, thanks :)
<kdub> Mirv, do you have a turbo?
<Mirv> kdub: no :(
<Mirv> they are hard to get so far, but that should of course change once they start to be sold
<kdub> great, we developers can fix it then
<kdub> ;)
<kgunn> kdub: mzanetti and Saviq have one
<Saviq> what up?
<kdub> Saviq, if you do getprop ro.product.device is the string "turbo" ?
<kdub> we're trying to anticipate further 'quirks' for that device
<Saviq> kdub, yes
<Saviq> $ getprop ro.product.device
<Saviq> turbo
<kdub> thanks Saviq
<Saviq> hi all, can anyone point me to where is the virtual output for WiFi display created? We've been (temporarily, possibly wrongly) assuming that LVDS is our internal screen (that's the case on all hour hardware devices), but now WiFi Display says it's LVDS also, and that's breaking some scaling logic
<AlbertA> Saviq: it is in
<AlbertA> Saviq:  <mir>/src/platforms/android/server/display_configuration.cpp:45
<AlbertA> http://bazaar.launchpad.net/~mir-team/mir/development-branch/view/head:/src/platforms/android/server/display_configuration.cpp#L45
<Saviq> AlbertA, think it would make sense to make that unknown at least? at least as long as we don't have "virtual" or able to get the actual thing from the other side (but why would we - as far as we're concerned it's virtual)
<AlbertA> Saviq: I could add a virtual type
<AlbertA> Saviq: is that all you would need?
<Saviq> AlbertA, yeah, as far as I know right now
<AlbertA> Saviq: ok I'll roll that in to mir 0.22
<Saviq> AlbertA, when you have a diff I could apply against lp:mir/ubuntu I'd be obliged, we'd put it in the aethercast silo
<Saviq> temporarily at least
<n1md4> hi.   tried using mir and unity8 recently.  after entering my details it just locks up.  im running a gtx980m with nvidia-361 driver.  any clues to get this working?
<bregma> n1md4, we're only just enabling the nVidia binary blob driver...  it's,  uh, special
<bregma> you could try nouveau instead
<n1md4> bregma: thanks for the update.  I'd prefer something open, but to miss all the 980 goodness ... would almost be criminal.
<bregma> fortunately nVidia is very interested in providing a better experience on Linux and we've been working with them to make sure that includes Mir support
<bregma> they do go at their own pace, though
<n1md4> it's always nice to hear though
#ubuntu-mir 2017-04-18
<jsgrant__> Besides familarity, is there any real advantages with using a "display server" or a compositor?
<duflu> jsgrant__, you are free to use a text console.... but most people prefer a graphical interface which involves a display server and compositing. Which component does the compositing is not relevant to users
<jsgrant__> Oh! Sorry, I meant "over a compositor".
<duflu> jsgrant__, it's not a choice of one or the other. All desktops contain both
<duflu> It's better to think of it as all desktops involve a display server, and "compositing" is something that some part of the desktop does. Don't think of "compositor" as a component
<jsgrant__> duflu: Are we talking about compistor in the same sense, I'm wondering; I mean a'la a Wayland implementation of/on a client or the like.
<duflu> jsgrant__, yes we are but your question only makes sense in a Wayland world. In Wayland you build a compositor as a component. In other desktops compositing already exists and is done by some existing part of the system
<duflu> So there is no answer to the question if the question isn't relevant to other systems
<jsgrant__> duflu: Is there some overview somewhere of the actual architectural diffrences between the two systems/methods, that you know of? Looked around & can't find anything.
<duflu> jsgrant__, let me check...
<jsgrant__> I've seen "Wayland is nicer than Xorg, because xorg is bloated" arguments -- that's about it.
<jsgrant__> duflu: If you don't know any offhand, don't let me assign you hw; Just find it curious I really can't find any in-depth comparissions.
<duflu> jsgrant__, Yes I found a useful page (http://wiki.ubuntu.com/MirSpec). Confusingly it refers to compositor and shell as the same thing. That's true but only true for Mir :)
<jsgrant__> Maybe my searchfu is just poori.]
<jsgrant__> Will certainly look into page (notice now it's in the topic) & will look further; Have a feeling it must be out there more-so than I've been able to find thusfar, maybe just being drowned out by Wayland hype-pieces.
<jsgrant__> duflu: Ty.
<duflu> I know people like to draw architectural diagrams where "compositor" or "window manager" are labelled boxes. However those only make sense in certain contexts. Specifically, having a separate "compositor" component is only really true for Wayland and Xorg. And having a separate "window manager" is only really true for Xorg (where it typically is also the compositor). But neither of those are true for Mir. You might have a Mir server which
<duflu> does both compositing and window management, but those are not themselves separate components you need to build or reinvent. This is one way in which Mir tries to be different
<jsgrant__> Are there any alternative "window manager" environment you're aware of for Mir, that I can take a look at? Again if you aren't aware, don't have me give you hw.
<jsgrant__> "window manager"-like*
<jsgrant__> Sans Unity of course.
<jsgrant__> Just found, https://insights.ubuntu.com/2016/11/28/mir-is-not-only-about-unity8/ -- which kinda orbits this.
<duflu> jsgrant__, yes the 'mir-demos' package contains 'mir_proving_server' and the 'miral-examples' package contains 'miral-shell'
<duflu> Although none were ever really nice and ready for general use
 * jsgrant__ wonders if it's worth the effort to try to run on Fedora or just spin up an Ubuntu VM. :^P
<jsgrant__> Will probably end up doing both. Have spare box already running a minimal F25 install.
<duflu> Mir by itself will run perfectly smoothly even on an original Atom from 2008. It's only Unity8 that had less backward-compatibility/performance
<duflu> And actually Mir's backward compatibility is only limited by Mesa. Mesa chose to drop compatibility for older chips, so Mir (and others) can't go back that far
<duflu> It's only Mesa dictating that limitation
<duflu> *"so Mir (and others) can't go back much further than 2008 for Intel chips"
<jsgrant__> Have boxes about that old, but not in active rotation; Shouldn't be a problem then -- neat! :^)
<Son_Goku> hey
<Son_Goku> morning all
<Son_Goku> tvoss: hey
<Son_Goku> alan_g: so apparently mir can't find capnproto on Fedora :/
<Son_Goku> because Debian changed how the capnproto cmake stuff looks compared to upstream
<Son_Goku> well, and upstream doesn't install it when using autotools (which is what they recommend for Linux)
<Son_Goku> and there's the fun bigger problem that capnproto isn't building on GCC7 :(
#ubuntu-mir 2017-04-19
<RAOF> Son_Goku: there's a patch in capnproto master to fix the build.
<duflu> Excellent. Changing to display mode 640x480 still gives the EGL draw buffer dimensions 1920x1200
<duflu> Not my fault [tm]
<zorrolechat> hi
<zorrolechat> Is Mir included in 17.04 ? or it's Wayland by default now ???
<zorrolechat> not following everything in the Ubuntu world
<zorrolechat> Unity has been dropped right ? Which is a good thing...it is FUGLY as in Fucking Ulgly
<zorrolechat> Many people moved to other distros since that Unity thing started
<zorrolechat> Good to see Ubuntu is back on track
<zorrolechat> I just wanna install a good distro for the latest Kaby Lake intel processor...Gonna used the internal HD GRAPHICS
<zorrolechat> which distro should I install
<zorrolechat> and should I try Mir / Wayland or stay with X
<zorrolechat> We're completely lost these days with all those news
<duflu> zorrolechat: Ubuntu 17.04 was completed before the news broke, so is still Unity7 by default with the Unity8 option available
<duflu> The real changes will occur starting 17.10
<zorrolechat> oh thanks
<zorrolechat> so 17.10 will come with Wayland or Mir ?
<zorrolechat> I just want to install something on a Kaby Lake processor (so probably kernel 4.10+)...that will support Mir / Wayland
<zorrolechat> without needing to reinstall everything in a few months
<duflu> zorrolechat: If you want to minimize reinstalls, it's a good idea to stick to long term releases (16.04, 18.04...)
<zorrolechat> right....typing from a 16.04 mate install
<zorrolechat> I see
<duflu> RAOF: Did you know that changing modes to lower resolution keeps the old larger bounding rect? So the display buffer remains larger than the display
<duflu> Such is mesa-kms
<duflu> Oh, maybe it's just this branch
<zzarr> I know that Unity 8 + convergence + phone is discontinued, but what happens to Mir?
<ogra_> zzarr, the mir-kiosk snap will persist
<ogra_> (no idea if any other aspects of mir will see any canonical side development ... but perhaps the community will pick up)
<zzarr> ogra_, thanks
<zzarr> I still have hope for convergence and phone/tablet, I just think that the time was not right
<ogra_> the time was erfectly right ... see the galaxy S8 ... the adoption of manufacturers wasnt
<ogra_> *perfectly
<Son_Goku> you were too early :)
<Son_Goku> fortune favors the bold, but it punishes the early
<ogra_> well, we were showing it to them giving them ideas :)
<zzarr> I saw the first computer with touchscreen that could be used as tablet about 5-10 years before they became common
<zorrolechat> i think we need to sell our smartphones and buy dumb cell phones
<zorrolechat> computers were made with keyboards
<zorrolechat> to do text processing
<zorrolechat> coding
<zorrolechat> video editing
<zorrolechat> smart phones are toys
<zorrolechat> for teens
<zorrolechat> ...
<zorrolechat> I hate Android and iOS
<zorrolechat> they're both fugly IMHO
<zorrolechat> Blackberry was smarter and more secure
<zorrolechat> As long as a phone can call, send texts, occasionally browse the webs or have a mail client it should be enough
#ubuntu-mir 2017-04-21
<alan_g> alan_g_
<Son_Goku> alan_g: hey
<alan_g> ?
<Son_Goku> so I'm once again trying to bring Mir up on Fedora
<Son_Goku> interestingly, the biggest problem now is that it can't find capnproto
<Son_Goku> apparently, there's a Debian-specific change that you guys are depending on (Debian added CMake things to the autotools build, but different ones from what upstream Provides)
<Son_Goku> the Fedora package only has pkgconfig stuff
<Son_Goku> I also found out I can't build patched libinput and mesa for Fedora 26, since the patches don't work on libinput 1.7.0 and Mesa 17
<alan_g> Son_Goku: that's interesting, but I'm not really set up to investigate that
<Son_Goku> I figured, but since you were interested a few weeks ago, I figured I might as well tell you now
<anpok_> Son_Goku: I thought about changing mir to not require those additional symbols... should be simple change.. I think about proposing that this weekend..
<Son_Goku> anpok_: that'd be great
<alan_g> Son_Goku: yes, I'd like to know and can help if (for example) you can put together a PR
<Son_Goku> alan_g: I'm already investigating how to fix gmock, since it can't find it on Fedora
<alan_g> Son_Goku: I just put up an MP to use cmake-extras for finding it
<anpok_> also I have seen Marius is working on a wayland backend platform driver.. wl client support will be way more work
<alan_g> (dunno if that works on fedora)
<Son_Goku> that would be very cool
<anpok_> but I guess more important than the other changes
<Son_Goku> alan_g: cmake-extras, as in CMake's own FindGTest.cmake?
<Son_Goku> because if so, then yes, that helps a lot
<alan_g> Well FindGMock
<Son_Goku> right
<Son_Goku> we offer the compiled library, since Google Mock guys lifted that silly requirement to only do sources quite a while back
<Son_Goku> at least two years ago, I think
<alan_g> Yeah, I just noticed a couple of days ago
<Son_Goku> it took a while to convince juliank the same thing, and then we fixed it for apt
<Son_Goku> so apt now builds on Fedora too :P
<Son_Goku> apparently, the only platform where the "only sources" thing matters is Windows :)
<Son_Goku> because compilers have vastly different ABIs there
<Son_Goku> ah, I see Android support is toast now
<Son_Goku> that will simplify things in my spec file
<alan_g> Yeah, even between compiler options on Windows
<Son_Goku> yeah...
 * Son_Goku shudders
<Son_Goku> I'm part of a game development project, so I'm keenly aware of how broken the Windows platform is
<Son_Goku> people there have Stockholm Syndrome about the Windows development environment :/
<Son_Goku> they don't realize it can be better
<alan_g> *I* made money out of Windows for years, but it was horrid to work on
<Son_Goku> yeah
<Son_Goku> the only reason people endure it is because the Linux Desktop hasn't taken off yet :(
<Son_Goku> ONE DAY!!! :D
 * alan_g is hoping never to go back
 * Son_Goku is hoping the same
<Son_Goku> the job I had before my current one, I had to develop for embedded systems from Windows
<Son_Goku> that's a whole new level of pain
<Son_Goku> there was no technical reason I couldn't do it from Linux, I was just forbidden to because "we already paid for the Windows licenses, so we should use them" (their words)
<anpok_> in a few weeks I will probably work for a linux based product.. but I fear the development systems will all run windows..
 * alan_g shuts out the bad memories
<Son_Goku> anpok_: you're leaving Canonical?
<anpok_> yes
<alan_g> anpok_: at least on Windows 10 you'll have "Bash for Windows"
<Son_Goku> alan_g: it's a very poor substitute
<Son_Goku> most things are subtly broken in horrifying ways
<alan_g> Better than cygwin
<Son_Goku> ironically, no
<alan_g> Really?
<Son_Goku> while performance is certainly better, Cygwin preserves Linux primitives better
<Son_Goku> Windows things bleed into LXSS and cause odd issues
<alan_g> But it could never do fork() right
<Son_Goku> well, technically, now Cygwin could do fork() correctly
<Son_Goku> since there's a brand new syscall to do it
<alan_g> Thanks for the warning
<Son_Goku> alan_g: one fun issue: the text encoding of paths was messed up :(
<Son_Goku> I went NUTS trying to figure out what was wrong in an app built and running in LXSS, and when it came to that, I was rather upset
<alan_g> I remember having problems with paths in cygwin - it worked except when it didn't
<Son_Goku> path literals were always screwy in cygwin in the old days
<Son_Goku> but latest versions don't seem to have issues
#ubuntu-mir 2017-04-22
<anpok> bschaefer: ping
<bschaefer> anpok, hello!
<anpok> i just realized that the android platform was removed
<bschaefer> yes it was
<anpok> i know that ubports has its own branch of mir already..
<bschaefer> anpok, yeah its mainly so we can look at refactoring those bits
<bschaefer> to allow for 3rd party platforms
<bschaefer> which will allow for someone to carry their own 3rd party platform ie. anrdoid
<anpok> ok .. would have been nicer if you would have moved it into a separate 3rd party rep. after refactoring..
