=== chihchun_afk is now known as chihchun [03:13] what's a good command to use the output of mirscreencast and produce a video file with reasonable compression? [03:15] robert_ancell: Let me hunt down the email... [03:15] RAOF, I figured this must have been recorded somewhere but my google-fu is not finding it [03:17] mencoder -demuxer rawvideo -rawvideo fps=60:w=1920:h=1200:format=bgra /tmp/foo -ovc lavc -lavcopts vcodec=ffv1 -o all.avi [03:17] Is one option. [03:17] I don't think we have documented this anywhere, though. [03:17] MPs welcome :) [03:17] It'd be reasonably easy to translate that into a gstreamer pipeline that'd do the right thing, too. [03:19] I should be able to convert that to a pipe right? In particular I'm running out of disk space too fast [03:20] I *think* so? [03:22] You certainly would be able to with gstreamer and fdsrc [03:22] Urgh. How can our unittests fail in trunk? [03:23] mirscreencast -m /run/lightdm-mir-0 --stdout | mencoder -demuxer rawvideo -rawvideo fps=60:w=1920:h=1200:format=bgra - -ovc lavc -lavcopts vcodec=ffv1 -o $1 [03:23] I think that should do it [03:23] Yeah, seems reasonable. [03:23] except I need to adjust the size I guess.. [03:23] And probably select a different vcodec; that'll give you lossless compression, which will be pretty good for a screencast but you may want more. [03:24] It's probably better to encode fast and then re-encode when I'm done [03:25] Yeah, not a bad plan. [03:27] Intriguing. Tests fail when built with clang, pass with gcc. I guess I'll chalk this up to a compiler bug unless it persists. [03:27] [ffv1 @ 0x7f8e54797b00]Error getting output packet. [03:27] Muxer frame buffer cannot allocate memory! [03:27] hmm [03:34] Heh. g++'s error handling for “you missed a > on a template argument, doofus” remains gloriously opaque. [03:37] Ok. Sped up our tests by a factor of 10, and they almost all still pass. [03:42] Anyone know why Mir says it's outputting 60fps by screencast but it only appears to be 15fps? [03:48] Possibly too slow to write? [03:50] RAOF, I don't think so - it seems to generate an mp4 at 4x speed. If I set it to 15 it works fine [03:52] * RAOF makes the magic incantations which enable non-glacial speed on battery. === tvoss is now known as tvoss|test === tvoss|test is now known as tvoss [09:46] alf_: do you know why a Mir CI build tries to install libunity-mir1 etc.? https://jenkins.qa.ubuntu.com/job/mir-mediumtests-runner-mako/1795/console [09:46] alan_g: looking [09:49] alan_g: from what I understand, libunity-mir1 is already installed as part of the flashed image [09:50] Oops! [09:50] I'll pop over to ci-eng... [10:26] CI he say: "/usr/include/android/system/graphics.h:269:5: error: 'size_t' does not name a type" ... I wonder if the android headers have been changed? === chihchun is now known as chihchun_afk === dandrader is now known as dandrader|afk === dandrader|afk is now known as dandrader === alan_g is now known as alan_g|tea [14:26] dednick, I guess your platform-api branches fixes those issues? http://paste.ubuntu.com/7663936/ [14:27] dandrader: yup === alan_g|tea is now known as alan_g === chihchun_afk is now known as chihchun [15:45] greyback: does this test capture our current orientation requirements? http://paste.ubuntu.com/7664275/ [15:48] alan_g, btw, gotta define mir_orienation_* values [15:49] alan_g, is it an angle in degrees, counter-clockwise? [15:50] alan_g, and will the app be able to query the value and not just receive events about it? [15:50] dandrader: mir_toolkit/common.h line 120 [15:51] dandrader: what I took from the discussion was the ability to send the events [15:51] but I can add requirements... [15:51] alan_g, yes. gotta have a line there explaining what those enum values mean [15:52] documentation [15:54] alan_g: looks good yes [15:54] dandrader: I only know what I see there. ;) [15:55] greyback: do we need dandrader's suggestion of the client querying the orientation of a surface too? [15:57] alan_g: hmm, ideally yes a surface should be created with an orientation, or have a getter to read the orientation when it wants to. [15:59] * alan_g wonders if orientation should be a surface creation parameter? === dandrader is now known as dandrader|lunch === dandrader|lunch is now known as dandrader === dandrader is now known as dandrader|afk === dandrader|afk is now known as dandrader === chihchun is now known as chihchun_afk [19:22] kgunn: dandrader: So I guess if by monday we havent come to an agreement re: input sender (gives tomorrow morning and friday) [19:22] we can do inputdispatcher [19:23] ugh 5 minutes until the pizza place opens but I cant wait ANY LONGER [19:23] ... [19:23] lol [19:23] yeah...i think if you threaten alan with that, he'll suddenly love input sender :) [19:24] haha [19:25] using InputDispatcher isnt that bad [19:25] racarr_, by inputdispatcher you mean exposing the whole android-input and letting us replace android::InputDispatcher [19:25] Yes. [19:25] ok. I will have to dust off the patch I had for it :) [19:25] :) well maybe input sender will magically land in the morning lol, we will see [19:26] I'm sure InputDispatcher hasnt changed though [19:26] or android-input much at all [19:26] which is one of the reasons I think publishing android-input in a "privatized" library isn't that bad [19:26] on the other hand. it will quite a bit of work to go back to that previous approach in qtmir.... [19:26] its additional ABI, but practically we dont change it rapidly at all. [19:27] Oh really ? :( [19:27] I imagined it would be almost plug/play InputSender->InputDispatcher-to-channel === dandrader is now known as dandrader|afk [19:37] racarr_: ummm, do we really want to do that? [19:38] racarr_: don't we want to have the option to drop the android stuff completely at some point [19:50] AlbertA: it would be a privatized interface to unity-mir [19:51] if we arent able to land input-sender quick enough [19:51] racarr_: ummm didn't we just basically said no to privatized stuff even for our own examples? [19:52] Sure but 3 options [19:52] 1. Land input sender or something comparable [19:52] 2. Expose android-input for unity-mir [19:52] 3. Don't ship qt compositor [19:52] ;) [19:53] is there something really wrong with input sender? I haven't reviewed it yet [19:54] lol im not sure yet. my first review it just seemed kind of messy, but mostly as a consequence of the android bits....going to look more tomorrow [19:54] but there is some discussion between alf/alan_g about it too and [19:55] alan_g seems pessimistic about it. [19:55] s/tomorrow/this afternoon/ [19:57] racarr_: oh I see there's a dependency chain there [19:57] racarr_: it depends on another 2 mps [19:57] that too yes [19:58] I think I see the problem now [19:58] It's a massive diff overall [19:58] :) [19:59] aha yes that is a concern point === josharenson1 is now known as josharenson === dandrader|afk is now known as dandrader [22:18] i feel like im so close [22:18] to never again having to remember that the cursor [22:18] exists [22:18] soon we will do everything that xcursor does and the cursor will just be another renderable and it can fade in to memory lol [22:20] hmm. if the XCursorLoader fails to load any cursors do you think we should fall back to the builtin cursor [22:20] kind of weird to put logic in the server configuration [22:20] like that [22:21] I mean...there could be a...composite object that does that too... [22:21] or the XCursorLoader could have a builtin cursor (that seems the weirdest...) [22:49] seems like its still possible to hose the system if you crash the server at the right place in startup [22:49] cant even recover from ssh... [22:55] robert_ancell, cool, gtk! [23:02] Yeah! [23:51] ok coming back in a bit to finish off last bit of cursor loader and propose that to get one more thing off my mind lol and then work on groking input sender [23:51] but for now away for a while