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