| 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 | 01:16 |
| === grenadecx-Ascend is now known as 65MAA0XUD | ||
| === dandrader is now known as dandrader|afk | ||
| === dandrader|afk is now known as dandrader | ||
| robert_ancell | mterry, https://launchpad.net/~ubuntu-unity/+archive/experimental-prevalidation | 14:39 |
| 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:49 |
| 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 | 14:53 |
| kgunn | ricmm: ^ could you possibly help kdub ? | 15:52 |
| ricmm | kdub: whats the issue? | 16:04 |
| 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:05 |
| 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:06 |
| ricmm | ok, ill build one for you | 16:07 |
| ricmm | give me a bit | 16:07 |
| kdub | ricmm, thanks | 16:08 |
| rsalveti | kdub: ricmm: this might not be necessarily trivial but something to test | 16:16 |
| 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:20 |
| kdub | well, our kernel does not... i think the lge-kernel-mako from cyanogenmod does though? | 16:21 |
| rsalveti | well, our kernel should reflect that, might not be completely updated with our current cyanogen branch | 16:22 |
| kdub | its in the 10.2 kernel | 16:23 |
| kdub | and we're still 10.1 basde? | 16:23 |
| === dandrader is now known as dandrader|lunch | ||
| rsalveti | iirc, yes | 16:36 |
| tvoss | kdub, are we able to reproduce the flicker issue with a simple test setup? | 16:59 |
| kdub | tvoss, like, if i drive the display with the fb hal, i see it... or if i force surfaceflinger in certain ways | 17:04 |
| 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:05 |
| tvoss | kdub, ? | 17:06 |
| tvoss | kdub, does that mean you know the root cause? | 17:06 |
| 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:07 |
| ricmm | rsalveti: yea right just saw that | 17:10 |
| ricmm | so not trivial to build with what kdub needs | 17:10 |
| ricmm | kdub: can you isolate the kernel patch? or got a link I can see the relevant bits in? | 17:11 |
| 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:14 |
| 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:16 |
| kdub | 1 minute | 17:17 |
| kdub | so if you look here... https://github.com/CyanogenMod/android_hardware_qcom_display/blob/cm-10.1/libhwcomposer/hwc.cpp#L283 | 17:18 |
| 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:19 |
| 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:20 |
| 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:22 |
| 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:23 |
| kdub | tvoss, right, but it goes and calls draw in l387 | 17:24 |
| kdub | whereas the first one just returns | 17:25 |
| tvoss | kdub, true | 17:25 |
| tvoss | and it does a display_commit, too | 17:25 |
| 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:26 |
| 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:27 |
| 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:28 |
| ricmm | ok, fingers crossed | 17:29 |
| ricmm | good catch if it is that | 17:29 |
| 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:53 |
| 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:54 |
| alan_g | do you also watch paint dry? | 17:55 |
| tvoss | thomi, what's wrong with the cross-building setup? | 17:56 |
| === dandrader|lunch is now known as dandrader | ||
| 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:27 |
| alan_g | thomi: the script is rubbish, but cross compiling works and I run the tests on an N4 | 18:30 |
| === dandrader is now known as dandrader|afk | ||
| === dandrader|afk is now known as dandrader | ||
| ricmm | kdub: ping, still around? | 20:41 |
| 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:42 |
| 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:44 |
| ricmm | the gstreamer pipeline is set to use the android decoder | 20:45 |
| ricmm | kdub: jhodapp is the guy | 20:45 |
| jhodapp | yo | 20:45 |
| 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:46 |
| 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:47 |
| 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:48 |
| 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:49 |
| 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:50 |
| 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:51 |
| 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:52 |
| 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:53 |
| 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:54 |
| jhodapp | the SurfaceTextureClient connects the GL API to do that buffer pushing that avoids the main CPU | 20:55 |
| jhodapp | does that help at all kdub? | 20:56 |
| kdub | jhodapp, okay so, the buffers that were acquired came from mir, via qtubuntu? | 20:59 |
| jhodapp | ricmm, can you answer that one? | 20:59 |
| 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:00 |
| jhodapp | kdub, indeed...now I kind of wish ricmm and I were at the sprint with you to push through this | 21:01 |
| 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:02 |
| 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:03 |
| 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:04 |
| 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:05 |
| 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:06 |
| 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:07 |
| 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:09 |
| 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:10 |
| jhodapp | ricmm, so you're wanting to try messing with it, is that right? | 21:11 |
| jhodapp | ricmm, if so that's cool, otherwise I can try in the morning as I've got to run for the evening | 21:12 |
| 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:14 |
| 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:15 |
| 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:16 |
| 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:17 |
| 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:18 |
| jhodapp | ricmm, ok I'm out now | 21:19 |
| ricmm | ok cya tomorrow | 21:20 |
| === jhodapp is now known as jhodapp|afk | ||
| jhodapp|afk | later | 21:20 |
| ricmm | kdub: did you manage to get a patch for the hwcomposer ? | 21:20 |
| 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:21 |
| ricmm | alright | 21:33 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!