[03:29] <thomi> ugh
[03:29] <thomi> it's so easy to lock up the latop when working with mir
[03:30] <thomi> robert_ancell: is there some magic "kill mir_demo_server" keystroke?
[03:33] <robert_ancell> thomi, ctrl+c (is sent through to the console). Or alt+ctrl+backspace if that branch landed..
[03:34] <thomi> robert_ancell: neither seem to be working for me
[03:34] <robert_ancell> and you can't vt switch away from it?
[03:35] <thomi> nope
[03:35] <robert_ancell> it could be mir_demo_shell only has the alt+ctrl+backspace support and there's no escape from mir_demo_server (unless you ssh in)
[03:35] <thomi> I just have a black screen
[03:35] <robert_ancell> I'll just check the recent history
[03:36] <thomi> robert_ancell: OK, ssh fixed it
[03:36] <robert_ancell> that branch hasn't landed so Ctrl+C / alt+Fn should be working
[03:37] <thomi> robert_ancell: should I be running mir_demo_server or mir_demo_shell? what's the difference?
[03:37] <robert_ancell> thomi, mir_demo_server is the trivial server, and mir_demo_shell has some shell like behaviour
[03:37] <robert_ancell> for testing, mir_demo_server should be good
[03:37] <thomi> ok
[03:38] <robert_ancell> though mir_demo_shell is/will be more usable for playing around with
[03:39] <thomi> urp - I get a segfault inside MirConnection::connect(...)
[03:43] <robert_ancell> which client?
[03:43] <thomi> robert_ancell: I don't understand the question - this is in the mir stress test code
[03:44] <thomi> any ideas? http://pastebin.ubuntu.com/5682538/
[03:44] <thomi> I know it doesn't crash if the mir demo server isn't running, although that's not very useful
[03:44] <robert_ancell> nothing on stderr/out?
[03:44] <robert_ancell> where is your client code?
[03:44] <thomi> nope
[03:45] <thomi> not currently pushed anywhere
[03:46] <thomi> just pushed it to lp:~thomir/+junk/mir-stress
[03:46] <robert_ancell> ok
[03:46] <thomi> literally all it tries to do is fire up a single thread, and in that thread, connect to the mir server
[03:48] <robert_ancell> I think you need to set the app name (http://unity.ubuntu.com/mir/group__mir__toolkit.html#gaf8c65b7597fc560616747cf259dcc045)
[03:48] <robert_ancell> you set it to 0
[03:49] <robert_ancell> Silly C++ not being able to tell the difference
[03:49] <thomi> ahaaaa
[03:49] <robert_ancell> because that string is passed to the server
[05:11] <thomi> robert_ancell: so... my mir stress test breaks the demo_server
[05:11] <thomi> robert_ancell: with four threads connecting & disconnecting simultaniously, I get this: http://pastebin.ubuntu.com/5682684/
[05:11] <robert_ancell> thomi, well, I guess that's good in a way?!
[05:12] <thomi> Assuming I haven't make a mistake in my code, yes
[05:12] <thomi> oooh wait...
[05:12] <thomi> I think I'm passing the same application name
[05:12] <thomi> does that have to be unique?
[05:13] <robert_ancell> I think it's just a tag on each connection, but it's not checked for uniqieness
[05:13] <robert_ancell> It might be a good idea to give each thread a name though
[05:14] <thomi> well, I'll make sure that's unique to the thread, and see what happens
[05:14] <robert_ancell> (it's just passed up to the shell and it can decide what ot do with it)
[05:15] <thomi> robert_ancell: so am I right in thinking that the client library is what is used by the GUI toolkits (Qt, Gtk etc) in order to render in  a mir-shell?
[05:15] <robert_ancell> yes
[05:15] <thomi> robert_ancell: do you know of any restrictions around the number of client connections that can be made per process?
[05:16] <thomi> I'm using multiple threads to try and break mir, but I wonder if that's a valid test at all - maybe I should be using multiple processes instead
[05:16] <thomi> like, maybe the mir server code assumes a process will only connect once
[05:17] <robert_ancell> I'm not sure off hand. Multiple processes would certainly be safer
[05:18] <thomi> robert_ancell: who should I ask about this?
[05:18] <robert_ancell> thomi, alan_g or alf are good candidates
[05:18] <thomi> ok, thanks
[05:20] <robert_ancell> thomi, ok, I'm off until next week, good luck!
[05:21] <thomi> robert_ancell: you too !
[05:21] <robert_ancell> thomi, oh, also ask racarr/kdub about it too - they're in a closer timezone
[05:21] <thomi> yeah, will do,t hanks
[05:21] <robert_ancell> bye
[08:31] <alf__> alan_g: Basically, there are two ways to achieve eglSwapInterval(0). Either the compositor doesn't sync with vsync (so you get tearing), or we provide a "spinning" variant of triple-buffering for client surfaces in which both the compositor and the client always have a buffer available without blocking.
[08:31] <alf__> alan_g: Kevin's current MP is for the first option
[08:33] <alan_g> alf__: I think spinning is a no-go on battery powered devices. But is eglSwapInterval(0) actually the right measure?
[08:34] <alan_g> I mean tearing isn't a good user experience, and you can't actually see "eglSwapInterval(0)" as a user
[08:35] <alf__> alan_g: neither of these are useful in the normal case, they only make sense when measuring performance. Normal case is going to be either double or (normal) triple buffering.
[08:36] <alf__> alan_g: We need some way to avoid being bounded above by the refresh rate => eglSwapInterval(0)
[08:37] <alan_g> So is this benchmark driven optimization? Or is there something in the "normal case" that is improved by it?
[08:40] <alan_g> The idea is we can better measure the stack throughput is we're not constrained by updating the screen?
[08:40] <alan_g> s/is/if/
[08:40] <alf__> alan_g: It's not something that will be on by default, neither it is an optimization. It's just a use case that we need to support, so that we can evaluate maximum performance without the vsync restriction.
[08:41] <alf__> alan_g: stack throughput is we're not constrained by updating the screen => yes
[08:41] <alan_g> alf__: OK
[11:29] <alf__> alan_g: looking at https://bugs.launchpad.net/mir/+bug/1175721, was there a particular test (or tests) that you found difficult to implement with the current infrastructure?
[11:31] <alan_g> alf__: I was trying to test that cursor movement resulted in the correct drm calls but to mock those calls got me into a chain of things I needed to replace with test doubles
[11:44] <alf__> alan_g: ok, in this case where we need to test only the extremes (GBMCursor -> drm calls) I think we can actually use our current design. We need to set up drm resources for the right number of screens etc, but we have support for this.
[11:45] <alf__> alan_g: I will start working on something along these lines and see how it goes
[11:45] <alan_g> alf__: what I wanted to test was mocked input to DRM calls
[11:46] <alan_g> I know there's some support there. But the work needed seemed out of proportion to the code to be tested.
[14:55] <alf__> alan_g: @message-processor-report-lttng, 1. are you on raring and 2. what version of lttng-ust do you have (dpkg -s dpkg -s liblttng-ust-dev)
[14:56] <alf__> ?
[14:57] <alan_g> alf__: 1. yes.  2. 2.1.1-2
[14:58] <alf__> alan_g: the version is the same as mine... thinking of what may be going wrong...
[14:59] <alan_g> alf__: let me know if/when I should look closer.
[15:00] <alf__> alan_g: I will, thanks
[15:03] <alf__> kdub: Good morning! Can you confirm that both the integration and the acceptance tests don't need to mock EGL/GL or hw on Android?
[15:04] <kdub> alf__, good morning, will check
[15:43] <alf__> status: gardening bugs, investigating reported test failure with lttng (which unfortunately can't be reproduced locally or in the builders), improving testing infrastructure
[15:44] <alan_g> status: catching up after time off. finding test failure with lttng MP (which, for some reason, is easily reproducible for me)
[15:46] <kdub> satus, mp'd swapinterval 0, going to find some glmark numbers today
[15:51] <racarr> Morning
[15:52] <alf__> racarr: Good morning-10 :)
[15:52] <alan_g> racarr: Afternoon
[15:54] <alan_g> racarr: https://code.launchpad.net/~robertcarr/mir/depthify-stack/+merge/162211 hasn't changed for 2+ weeks. Can we kill it or mark it WIP pending an update?
[15:56] <racarr> alan_g: I guess kill it
[15:56] <kgunn> racarr: alan_g you guys are so violent
[15:56] <racarr> I dont have any further suggestions though
[15:57] <alan_g> Does anyone have an opinion on: https://code.launchpad.net/~vanvugt/mir/move/+merge/162487 (Nothing happening there either - partly due to duflu being away)
[15:58] <racarr> I dont think it makes sense to land any more demo code
[15:58] <hikiko> status: still fixing compiler/linker errors in sdl platform (had to replace a lot of stuff after a local merge I did), fixed some bugs, replaced gcc with cmake to get rid of those compiler internal errors all the time... :)p
[15:59] <alan_g> racarr: You're advocating more violence?
[16:01] <kgunn> alan_g: seems he is, how do i move his to wip ? (do i have that power?)
[16:01] <racarr> alan_g: yes XD
[16:01] <racarr> mine is not WIP it is just dead :p
[16:02] <alan_g> kgunn: Near the top, you can try changing the status (There's an odd icon)
[16:03] <alan_g> If you can't change it the the rest of us can.
[16:04] <kgunn> alan_g: hmmm, i can only change status to approved/rejected/merged
[16:05] <alan_g> kgunn: look harder "Work in Progress" is there (at the top)
[16:05] <kgunn> alan_g: :) i feel stupid now....it was the only one in black text, my eye/brain completely filtered it :)
[16:06] <alan_g> kgunn: you are not the first
[16:13] <racarr> Does anyone want to talk about
[16:13] <racarr> depthify stack? Because I feel like
[16:13] <racarr> err.. that's what I need to work on
[16:13] <kgunn> racarr: as part of the unity-mir layer right?
[16:14] <kgunn> per the comments in the original in mp
[16:14] <racarr> that's what the thread on launchpad talks about but
[16:14] <racarr> I don't think that's really what the question is...
[16:14] <racarr> The surface stack could be implemented in unity-mir or
[16:15] <racarr> in mir.
[16:16] <racarr> but, the discussion in this thread, I think gets to the interfaces too
[16:16] <racarr> i.e. say there is some surface stack interface implemented by unity-mir
[16:16] <racarr> does it know about depth at all?
[16:16] <racarr> i.e. are there methods like, raise this surface relative to this surface, etc in Mir
[16:17] <racarr> the proposal from robert (I don't actually know what alan is proposing/expecting)
[16:17] <racarr> alan_g: ^ ;)
[16:18] <kgunn> racarr: "thinking aloud", when we get to the point where we want to
[16:18] <racarr> Is to not have any of this, and instead have the shell provide a sort function to the compositor and input stack
[16:18] <kgunn> do dirty region tracking for optimization
[16:19] <kgunn> wouldn't it actually be best if mir has the z stack (not unity-mir)
[16:19] <alan_g> racarr: I was expressing doubt that "depth" was adding sufficient flexibility to solve problems
[16:19] <racarr> Well. I think so :) but it can work without mir having the z stack
[16:19] <racarr> kgunn: i.e. whatever is tracking this damage calls the shell sort function
[16:19] <racarr> and determines the z order that way
[16:20] <racarr> the thing I don't like about it is hmm
[16:20] <kgunn> racarr: got it...so really no benefit to stick it in mir, since its gotta go check with shell anyway
[16:20] <alan_g> I've no objection to giving mir a better model of how surfaces are related - just not sure "depth" is the answer
[16:20] <racarr> kgunn: No I think there is an advantage...I'm trying to explain
[16:20]  * kgunn shuts up for a minute :)
[16:20] <alan_g> racarr: kgunn hangout?
[16:21] <kgunn> sure
[16:21] <racarr> Sure. It will be easier.
[16:22] <alan_g> https://plus.google.com/hangouts/_/91e1f9a0e398b79534e877285ddd48e7fe357722?hl=en-GB
[16:25] <racarr> sorry guys ayudio trouble just a sec
[16:35] <katie> tvoss,
[16:58] <racarr> Thanks both :)
[17:00] <racarr> There are still some loose ends around input now that I will tie up
[17:09] <racarr> Going to do some diagraming
[17:18] <racarr> alan_g: Oh! if you have a few minutes I wanted to talk about options
[17:42] <alan_g> racarr: sorry, missed that - and supper is now ready.
[17:46] <racarr> alan_g|life: No worries. Enjoy :)
[18:53] <racarr> Status: Working on hooking the input stack more directly to the surface stack/shell
[18:54] <racarr> involves some InputDispatcher rework, am trying to figure out how deep I need to go
[18:54] <racarr> and kind of spiralling but I think I should pull together a plan over lunch
[18:57] <racarr> spiralling thoughts, not a personal spiral :p
[18:57] <racarr> anyway lunch!

[19:49] <kgunn> thomi ! hey i updated the test spec....might take a gander, stuff to report & how to interp failures
[19:49] <racarr> Oh hey thomi I need to harass you too
[19:50] <racarr> please distract me from this awful world where every class begins with "Input"
[19:50] <racarr> p.s. not to accuse kevin of harassment but that's my plan
[19:52] <kgunn> :)
[20:01] <racarr> diagramming with an aubergine sparkle pen...
[20:02] <racarr> I am the input princess! *twirls*
[20:05] <mlankhorst> racarr: What about MirInput class ? :>
[20:07] <racarr> it's not there! ;)
[20:07] <racarr> right now I am in the world of android::Input*
[20:19] <thomi> racarr: hey
[20:19] <thomi> kgunn: ok, will take a look
[20:20] <racarr> thomi: Hey. I am about to jump in a meeting re:platform API in 10 minutes so we might have to finish this later
[20:20] <thomi> ok
[20:20] <racarr> but I want to get integration testing for mir<->qt in place
[20:20] <thomi> later would be better for me too
[20:20] <racarr> in process and out of process
[20:20] <racarr> ok well ping me later when you have some time to talk about it
[20:20] <racarr> I don't mean I want to do it RIGHT NOW I just mean I want to get a plan
[20:21] <thomi> racarr: nah, you ping me after your meeting, I just need a second coffee, that's all :)
[20:21] <racarr> Ok :D
[20:21] <racarr> thanks
[20:21] <thomi> np
[20:57] <thomi> Hey guys & girls, Mir and unity-system-compositor projects are now in the MBS system, which is suppoosed to trigger a rebuild of U-S-C every time mir lands, to avoid the API breakage issue we currently have. Please let me know if you see anything strange going on there...
[21:10] <kgunn> thomi: yes...but thot it was because prebuilts were still wonky
[21:10] <kgunn> but lightdm "held back, not upgraded"
[21:10] <thomi> kgunn: ummmm
[21:10] <kgunn> tried to mannually install to update...finally complaining about depends on unity-system-compositor
[21:11] <thomi> kgunn: possibly lightdm needs to be added to that system as well then. I'm not aware of what that interaction look slike
[21:11] <thomi> *looks like
[21:12] <kgunn> but then when i tried to manually install unity-system-compositor it complains
[21:12] <kgunn> unity-system-compositor : Depends: libmirserver0 (= 0.0.2bzr676raring0) but 0.0.3bzr691raring0 is to be installed
[21:12] <kgunn> brb
[21:12] <kgunn> gotta run the son somewhere
[21:12] <thomi> kgunn: right, I think that should fix itself now
[21:13] <thomi> once something lands in mir
[21:13]  * thomi crosses fingers
[21:13] <kgunn> mmm, ok
[21:13] <kgunn> well i was trying to build from source this afternoon
[21:14] <kgunn> got to the "make install"
[21:14] <kgunn> which then complained....couldn't find /build/doc/html
[21:14] <kgunn> there's a /build/doc/footer.html
[21:15] <thomi> kgunn: maybe ping me when you get back?
[21:49] <alan_g|life> kgunn: @"....couldn't find /build/doc/html" - that's created by "make doc" HTH
[21:51] <kdub> cross compiling is super fun!
[21:53] <racarr> kdub: Its hard to think of anything more fun
[21:53] <kdub> thomi, i don't understand 'mbs' or 'u-s-c' about the changes  you mentioned to the autolanding
[21:54] <thomi> kdub: u-s-c = unity-system-compositor
[21:54] <thomi> but that's too long to type
[21:54] <thomi> and I'm lazy
[21:54] <kdub> oh, ok :)
[21:54] <thomi> mbs = meta-build-system, which is something we're working on to solve the problem of "when package X gets rebvuilt, we also need to rebuild packages Y and Z, due to API/ABI compatibility"
[21:54] <thomi> which is the case with u-s-c and mir
[21:55] <thomi> so essentially, every time mir lands, we should also build a new u-s-c
[22:10] <thomi> racarr: I need to talk to you about my mir stress tests as well
[22:11] <racarr> thomi: Ok! Lets talk
[22:11] <thomi> racarr: hangout, or...?
[22:11] <racarr> Sure
[22:11] <racarr> just give me 2 minutes to finish writing this test.
[22:11] <thomi> sure
[22:13] <racarr> [  FAILED  ] SurfaceStack.surface_is_created_with_requested_geometry
[22:13] <racarr> what a bummer
[22:13] <racarr> XD
[22:13] <racarr> ok hangout time
[22:14] <racarr> thomi: ^
[22:14] <thomi> sure
[22:14] <racarr> thomi: Err can you start it I have to use the android client today
[22:14] <thomi> let me invite you
[22:14] <racarr> because my audio has chosen to no longer work inside hangouts
[22:16] <thomi> racarr: invite sent
[22:26] <thomi> racarr: lp:~thomir/+junk/mir-stress/
[22:30] <thomi> racarr: http://pastebin.ubuntu.com/5685237/
[22:47] <thomi> racarr: so I can't run the demo_server under gdb since when it crashes it locks up the system, and I can't start it under SSH, since it can't get a FD for the current VT.
[22:47] <thomi> perhaps you know of a way around this?
[22:52] <racarr> it locks up the system or breaks output?
[22:52] <racarr> What I do is
[22:53] <racarr> gdb mir > foo.txt 2>&1
[22:53] <racarr> run
[22:53] <racarr> make crash
[22:53] <racarr> switch back to vt
[22:53] <racarr> bt
[22:53] <racarr> ctrl+c
[22:53] <racarr> ctrl+d
[22:53] <racarr> then answer the insible prompt
[22:53] <racarr> y
[22:53] <racarr> then switch to X and back
[22:53] <racarr> lol
[22:53] <thomi> haha
[22:53] <kdub> haha :P
[22:53] <racarr> then a man will walk up to you and ask you if you like to ride horses
[22:53] <thomi> I'm trying to sort something out with screen, that might help
[22:53] <racarr> offer to trade a golden egg for his bow and arrow
[22:53] <racarr> then the journey begins...
[22:55] <racarr> would be nice to have
[22:55] <racarr> mir --debug like unity has
[22:55] <racarr> that prints a bt on crash
[22:56] <thomi> yeah, or something like --advanced-debug, which drops you into a gdb session
[22:57] <thomi> racarr: hmm, if I run the mir_demo_server under gdb it doesn't crash, so it feels like a race condition to me
[22:58] <racarr> thomi: Of course it doesn't that would be too easy
[22:59] <racarr> thomi: It would be interesting to see if you could reproduce it
[22:59] <racarr> with multiple processes disconnecting/reconnecting as fast as possible
[22:59] <racarr> so we can rule in/out the client library
[22:59] <thomi> yeah
[23:00] <racarr> P.S. This exists: https://code.launchpad.net/~robertcarr/mir/enable-surface-placement/+merge/164817 need it for an upcoming input acceptance test
[23:01] <racarr> thomi: Right now I cant think of anything better than stumbling through the code guessing at race conditions
[23:01] <racarr> but if you can narrow it to server/client
[23:01] <racarr> I can do that XD
[23:33] <kgunn> thanks alan_g|life!
[23:33] <kgunn> like a champ
[23:52] <kgunn> bummer...same probs
[23:52] <kgunn> gotta go tho
[23:53] <thomi> racarr: so... good news and bad news
[23:53] <racarr> kgunn: See you!
[23:53] <thomi> racarr: good news: mir server crashes with multiple processes as well
[23:53] <racarr> thomi: Uhoh
[23:53] <thomi> racarr: bad news: mir server crashes with multiple processes as well
[23:53] <racarr> mm
[23:53] <racarr> nothing informative in backtrace?
[23:54] <thomi> I haven't managed to get a backtrace yet,
[23:54] <thomi> I think I need to look into gdb-remote
[23:57] <racarr> ok ill spend some time investigating soon