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