[01:16] kdub_: hey, afaik nothing changed in libhardware that could affect mir [01:16] kdub_: can you get some more details, and open a bug as well? [01:16] I'm in vac this week, but I can take a look at the bug === grenadecx-Ascend is now known as 65MAA0XUD === dandrader is now known as dandrader|afk === dandrader|afk is now known as dandrader [14:39] mterry, https://launchpad.net/~ubuntu-unity/+archive/experimental-prevalidation [14:49] robert_ancell, ah... that's a boring PPA that doesn't have armhf enabled :( [14:49] mterry, :( [14:49] robert_ancell, I'm trying to avoid rebuilding the "world" in armhf [14:53] rsalveti, so, i have a theory about how to fix the nexus4 flicker [14:53] but need some help spinning up a phablet build [14:53] specifically, a kernel [15:52] ricmm: ^ could you possibly help kdub ? [16:04] kdub: whats the issue? [16:05] ricmm, long story short... i want to make a build for mako with this in BoardConfig.mk [16:05] TARGET_QCOM_DISPLAY_VARIANT := caf [16:05] when i try to do so though, it needs a kernel with some new ioctls [16:06] ricmm, the 'why' is that the hwcomposer.msm8960.so module that we're using is just what works for CM... its not what qcom ships from codeaurora forum [16:07] ok, ill build one for you [16:07] give me a bit [16:08] ricmm, thanks [16:16] kdub: ricmm: this might not be necessarily trivial but something to test [16:20] rsalveti, not trivial because of the kernel changes? [16:20] yup, not sure if our kernel has everything that's needed by it [16:21] well, our kernel does not... i think the lge-kernel-mako from cyanogenmod does though? [16:22] well, our kernel should reflect that, might not be completely updated with our current cyanogen branch [16:23] its in the 10.2 kernel [16:23] and we're still 10.1 basde? === dandrader is now known as dandrader|lunch [16:36] iirc, yes [16:59] kdub, are we able to reproduce the flicker issue with a simple test setup? [17:04] tvoss, like, if i drive the display with the fb hal, i see it... or if i force surfaceflinger in certain ways [17:05] the obvious problem is that the fb isn't being synced right [17:05] kdub, okay [17:05] kdub, was just curious [17:05] and its plain to see why looking through the source for the hwc we're /currently/ using :) [17:06] kdub, ? [17:06] kdub, does that mean you know the root cause? [17:07] i meant that its obvious that what the hwc is doing right now won't cause any fb sync [17:07] ah okay [17:10] rsalveti: yea right just saw that [17:10] so not trivial to build with what kdub needs [17:11] kdub: can you isolate the kernel patch? or got a link I can see the relevant bits in? [17:14] ricmm, i'll see if i can dig up the kernel patch [17:14] the relevant bits are [17:14] the MSM_ROTATOR_IOCTL_BUFFER_SYNC ioctl in https://github.com/CyanogenMod/lge-kernel-mako/blob/cm-10.2/drivers/char/msm_rotator.c [17:16] kdub: how come we dont see this in SF tho? [17:16] we are running 10.1 and that isnt available there [17:16] looking up sources... i minute [17:17] 1 minute [17:18] so if you look here... https://github.com/CyanogenMod/android_hardware_qcom_display/blob/cm-10.1/libhwcomposer/hwc.cpp#L283 [17:19] you see that hwc skips doing any fb sync if we have 1 layer (like mir runs with) [17:19] sf always operates with 2 or more layers, so they get the sync code [17:19] but really, i don't know where that hwc came from [17:20] because the ones qualcomm puts out are in... [17:20] here: https://github.com/CyanogenMod/android_hardware_qcom_display-caf/tree/cm-10.1 [17:22] i've tried to patch the one we're using, haven't gotten it quite right yet :) [17:22] that'd be a nicer solution :) [17:23] can you just do the sync outside of the check? [17:23] * ricmm taking wild guesses [17:23] kdub, but the qualcomm one you are referring only syncs for more than one layer, too, see: https://github.com/CyanogenMod/android_hardware_qcom_display-caf/blob/cm-10.1/libhwcomposer/hwc.cpp#L367 [17:24] tvoss, right, but it goes and calls draw in l387 [17:25] whereas the first one just returns [17:25] kdub, true [17:25] and it does a display_commit, too [17:26] sounds patchable [17:26] whatever their argument for doing it differently, the patch will show if it works or not [17:26] ;) [17:26] ricmm, +1 [17:27] right, trying to make a patch, but i think we should move to the caf stuff from qualcomm [17:27] try the patch first, the other move might be more intrusive than you think [17:27] CM also has a reason for not using that, I guess [17:28] i'm sure they do, just don't know if its a good reason (or one that applies to mir/ubuntu touch too) [17:28] at any rate, trying to patch [17:29] ok, fingers crossed [17:29] good catch if it is that [17:53] thomi: did you figure out the valgrind incantation on arnhf? Maybe just run the tests without valgrind? [17:53] alan_g: I did not [17:54] I believe that's all done in the packaging [17:54] so, we can do whatever we like there :) [17:54] will try and get mir building on the phone though, that sounds like fun [17:55] do you also watch paint dry? [17:56] thomi, what's wrong with the cross-building setup? === dandrader|lunch is now known as dandrader [18:27] tvoss: the script? It used to fail in wierd and wonderful ways, so I generally don't trust it. Also I'm trying to make sure I can run the tests on the target hardware, so cross-compiling really isn't a solution here [18:30] thomi: the script is rubbish, but cross compiling works and I run the tests on an N4 === dandrader is now known as dandrader|afk === dandrader|afk is now known as dandrader [20:41] kdub: ping, still around? [20:42] ricmm, yep [20:42] kdub: I have this http://paste.ubuntu.com/6129884/ [20:42] when running the gstreamer-backed mediaplayer [20:42] works under SF [20:44] so... somehow a client has an egl context and is trying to... [20:44] use buffers from the video decoders with it? [20:44] indeed [20:45] the gstreamer pipeline is set to use the android decoder [20:45] kdub: jhodapp is the guy [20:45] yo [20:46] jhodapp, so what's the scenario? specifically what egl windows are in play [20:46] jhodapp: maybe a quick run down of what the arch looks like for your gstreamer plugin [20:47] kdub: I use eglGenTextures() to get a texture id, and then I use the Android SurfaceTexture call which I pass off to a SurfaceTextureClient [20:47] kdub, that texture id is obtained from qtmultimedia, which passes it to my video sink, which does the calls into hybris where I make the Android calls to set up a SurfaceTexture [20:48] simple, eh? ;-) [20:48] hehe, yeah [20:48] :) [20:48] but with this backtrace http://paste.ubuntu.com/6129884/ [20:48] that's the high level call chain [20:48] mir is used [20:49] yes, and with this other logcat output: http://paste.ubuntu.com/6129901/, you can see that it blows up when trying to create the SurfaceTextureClient [20:50] I'll have to say that I was getting weird backtraces [20:50] like corrupt stacks or something, whenever I added some debugging it went past [20:50] until I started hitting some Mir in the backlog [20:50] great [20:50] then I pinged people [20:51] a heisenbug [20:51] but indeed the last I see is the ::connect(), client-wise [20:51] so the client is rendering to a mir buffer [20:51] i guess i don't see how a SurfaceTextureClient would mesh with a mir client [20:51] is that a statement or a question? [20:52] how so? [20:52] jhodapp, a question, sorry [20:52] so the client connects to the mir server, wit the intention of posting some buffers to the screen, right? [20:52] I guess so, I'm not making any direct mir client/server calls myself [20:53] have you essentially gutted the Android SurfaceTexture and SurfaceTextureClient underneith to use a mir buffer? [20:53] no no, this is a normal QtUbuntu client, out through mirclient [20:53] our SurfaceTexture is bound with the Mir window [20:54] a SurfaceTextureClient just needs to be able to take a raw decoded frame and push that to the rendering texture buffer [20:54] the difference here is that we are then passing that ST to the decoder to dump back decoded buffers into it [20:54] exactly [20:55] the SurfaceTextureClient connects the GL API to do that buffer pushing that avoids the main CPU [20:56] does that help at all kdub? [20:59] jhodapp, okay so, the buffers that were acquired came from mir, via qtubuntu? [20:59] ricmm, can you answer that one? [21:00] because if you switch QT_QPA_PLUGIN environment variable, it will switch from getting the buffers from sf to mir [21:00] kdub, I'm not familiar with how mir fits in behind the scenes as I developed everything with SurfaceFlinger [21:00] jhodapp, right, so there might be some banging on mir bits to get it to work with the media stuff [21:01] kdub, indeed...now I kind of wish ricmm and I were at the sprint with you to push through this [21:02] jhodapp, so when you get a buffer to feed to the video decoders, that comes from where? [21:02] the buffer is allocated natively [21:02] directly out gralloc [21:02] kdub, it comes from gralloc [21:02] yes [21:03] jhodapp: this runs the same code path in hybris as the old media stuff, right? [21:03] the non-SF provided buffers [21:03] ricmm, it is a new hybris compat layer, but it uses a SurfaceTextureClient and such just like the old one [21:03] kdub: SurfaceTextureClient's BufferQueue used to use the SF allocator by default, in the hybris code we now extracted that code natively into hybris [21:04] so we use GraphicBuffer() directly [21:04] ricmm, it merely gets rid of using the MediaPlayer class, and uses MediaCodec instead [21:04] and thats what we pass to the STC [21:04] so in theory it should be the same [21:04] jhodapp: oh, what file is that? [21:04] ricmm: compat/media/media_codec_layer.cpp [21:05] ricmm: and also take a look at surface_texture_client_hybris.cpp [21:05] _SurfaceTextureClientHybris::getInstance().surface_texture = new SurfaceTexture(texture_id, allow_synchronous_mode); [21:05] thats wrong, we need to pass the native BufferQueue as in media_compatibility_layer.cpp [21:05] exactly [21:05] otherwise it will try to reach out into SF for it [21:06] ricmm, I need a SurfaceTexture though because I need to be able to call updateTexImage() on it [21:06] ricmm, if we can still do that with what you said, that's fine [21:06] thats fine, just look at how its done in media_compatibility_layer [21:06] its weird because I dont see the failing call out into SurfaceFlinger [21:07] but I'm sure that this code path will block that thread and maybe blow up somewhere else, perhaps [21:07] lemme get something for my wife and I'll give it a shot [21:07] ricmm, so more like this, minus the SurfaceTexture: _SurfaceTextureClientHybris::getInstance().setISurfaceTexture(surface_texture->getBufferQueue()); [21:09] i got a little lost in the discussion there, but it sounds to me like the client is allocating the buffer for media usage directly? [21:09] yes [21:10] down on the bionic side [21:10] in which case... you could composite it to a mir buffer [21:10] kdub: not yet, right now we realized theres something wrong in the code [21:10] we'll take a stab at fixing it [21:10] okay [21:11] ricmm, so you're wanting to try messing with it, is that right? [21:12] ricmm, if so that's cool, otherwise I can try in the morning as I've got to run for the evening [21:14] jhodapp: go ahead, ill take a look [21:14] and if not ill get an email going with the three of us for later/tomorrow [21:15] ricmm, ok, I can come back on later this evening...I'll ping you when I get home [21:15] ricmm, let me know if you have any success [21:16] jhodapp: DONE [21:16] works [21:16] lol [21:16] shipping now [21:16] what's your change? [21:16] theres a weird flickering but its decoding and showing [21:16] dude, you're on a role [21:16] made it use the native buffer allocator [21:16] one line change? [21:16] I'll send a patch to salveti later [21:16] ~5 [21:17] ok, send it to me as well so I can update my local git branch [21:17] kk [21:17] thanks dude [21:18] the flickering sounds interesting [21:18] ricmm, on maguro? [21:18] yep [21:18] wonder if it would flicker on the n4 [21:19] ricmm, ok I'm out now [21:20] ok cya tomorrow === jhodapp is now known as jhodapp|afk [21:20] later [21:20] kdub: did you manage to get a patch for the hwcomposer ? [21:21] ricmm, no, digging a bit deeper [21:21] i have a suspicion though about why the patches aren't working, i'll let you know if it works out [21:33] alright