jnettlet has quit [Remote host closed the connection]
jnettlet has joined #imx6-dev
codinho_ is now known as codinho
codinho has quit [Changing host]
codinho has joined #imx6-dev
alexst has joined #imx6-dev
<codinho>
dv_, hi, is it possible to build chromium without X11?
<dv_>
not at the moment
alexst has quit [Ping timeout: 255 seconds]
<codinho>
dv_, ok, but looks like zero-copying rendering for gst1.x should work?
<dv_>
assuming you use imxeglvivsink
<codinho>
ok
<dv_>
otherwise it is not guaranteed that the dma buffer contents of the decoded video pictures wont be copied with the CPU
<codinho>
sure
bfederau has quit [Remote host closed the connection]
<codinho>
otavio, hi, does glTexDirectInvalidateVIV* stuff broken currently in master?
<codinho>
I've found that this method has stopped to work for qtgstreamer for me since my last repo sync
<applepi>
Hi all.. I'm trying to get suspend/resume working on a wandboard solo, but for some reason as it enters suspend, I get "aborting journal" and "Error -5 detected when updating journal superblock for mmcblk0p1"... full log here: http://codepad.org/f96jdrQx
<dv_>
codinho: broken how?
<applepi>
I am able to get a nitrogen6_lite to suspend/resume, also using ext3, so I know it isn't specifically that ext3 can't do it or the solo can't, which leaves me either with the wandboard or some config setting I missed when building the 3.12 kernel I'm running on this
<applepi>
Any thoughts?
<dv_>
codinho: with master you mean the 3.10.17 kernel & vivante drivers?
<codinho>
dv_, yes
<dv_>
do you build the rootfs with OE?
<codinho>
dv_, just master+fsl-image-multimedia+meta-qt5+recipe for qtgstreamer with patch for using glTexDirectInvalidateVIV* stuff
<dv_>
hm
<dv_>
try to build & run eglinfo-x11
<codinho>
it worked some time ago, now I can see just black screen
<codinho>
dv_, there is no error in logs but there is a black screen instead of actual picture, all glTexDirectInvalidateVIV* stuff works with no errors
<codinho>
it worked few weeks ago
jas-hacks has joined #imx6-dev
alexst has joined #imx6-dev
<dv_>
hmm. seems okay
<codinho>
dv_, is it GL_VIV_direct_texture extension?
staylor has joined #imx6-dev
alexst has quit [Ping timeout: 240 seconds]
<codinho>
dv_, qtgstreamer is not supported currently, is there any recipe to check glTexDirectInvalidateVIV* stuff currently?
kroon has joined #imx6-dev
<dv_>
well, my sink :)
<dv_>
other than that, no
<dv_>
not at the moment
<dv_>
I have some test code for x11 though
<dv_>
I'll have something in an hour or so
<codinho>
dv_, meta-qt5 has such patch also, but I didn't find the way to check it, does your sink uses such custom vivante mapping to texture thing?
<dv_>
"custom vivante mapping to texture thing"?
<codinho>
dv_, glTexDirectInvalidateVIV*
<dv_>
thats not "mapping"
<dv_>
but yes, it uses that function
<dv_>
it has to
<codinho>
dv_, yeah, sorry, wrong words
<dv_>
without this call, some internal GPU caches apparently wont be flushed
<dv_>
note though that the vivante drivers are buggy
<otavio>
codinho: this patch is integrated in master
<dv_>
it is quite possible that a certain sequence of valid GLES calls triggers bugs
<otavio>
codinho: but be sure to use meta-qt5 master
<dv_>
I experiences such strange bugs during eglvivsink development (had to call glBufferData twice)
<dv_>
that might explain why eglvivsink works and qtgstreamer doesnt : different GLES calls
<dv_>
or at least a different order of calls. difficult to guess
<codinho>
dv_, well, I'm using master and patch for qt-gstreamer master with such kind of rendering, its worked few weeks ago, but now after repo sync I can see just black screen with the same app and there is not errors in logs
<dv_>
uh, no idea
<otavio>
codinho: check meta-qt5
<dv_>
there are like a billion possible reasons for that
<otavio>
codinho: and be sure you are using 5.3.0 or newer
<codinho>
otavio, its master also
<dv_>
I always recommend to write down the layer git revisions and do fresh rebuilds
<codinho>
otavio, I do
<dv_>
fresh as in: from scratch. delete all temporary data.
<codinho>
otavio, is there any recipe to check this?
<dv_>
this is the only way to be sure there is actually a problem
<dv_>
codinho: look at the recipe fileanmes
<dv_>
*filenames
<dv_>
they have the version numbers
<codinho>
dv_, otavio is there any way to check meta-qt5 zero-copy rendering currently?
<dv_>
define "check"
<codinho>
dv_, just any recipe which is currently in master which uses it for meta-qt5
<dv_>
oh. no idea. I dont think so.
<dv_>
but isnt this supposed to be used automatically
<dv_>
?
<dv_>
(I never used qtgstreamer)
<codinho>
dv_, I don't think so
<dv_>
perhaps some qtgstreamer example programs which use video playback?
<codinho>
dv_, automatically where? qtmultimedia examples which could be added to local.conf can't use it
<dv_>
I mean, it would be weird if you had to explicitely enable the direct textures for video output
<dv_>
qtgstreamer should pick this automatically
<codinho>
dv_, qtgstreamer is not currently in recipes
<dv_>
then why do you mention qtgstreamer?
<dv_>
<codinho> I've found that this method has stopped to work for qtgstreamer for me since my last repo sync
<codinho>
dv_, cuz after I didn't find the way to render zero-copy way with qt5, I've wrote recipe for qtgstreamer and gind the way to have zero-copy way of video rendering way using patch for such kind of thing, after my last repo sync it stopped to work, that is why I've asked
<dv_>
how does qtgstreamer help with zero copy?
<dv_>
oh you mean by using qtgstreamer you were able to use gstreamer-imx , thus achieving zerocopy?
<dv_>
either way, I do not see how qtgstreamer is related to a qtmultimedia patch
<codinho>
dv_, no, qtgsreamer uses qtquick2videosink, I have patch for this sink which uses imx6 extension for rendering
<dv_>
aha
<codinho>
dv_, this patch I mentioned using the same way which was used for qtmultimedia
<codinho>
and its the patch which uses glTexDirectInvalidateVIV* stuff
<codinho>
just like it done in qtmultimedia's patch
<dv_>
so, to summarize: since gstreamer 1.0 is not supported in qtmultimedia so far, you wrote qtgstreamer recipes, which use qtmultimedia for rendering. qtmultimedia in turn contains a patch for using vivante direct textures to render with zero copy.
<dv_>
the problem is that this used to work, but now displays black frames.
<codinho>
dv_, correct
<dv_>
well. since I do not know what repo sync actually did, I unfortunately cannot help you there
<dv_>
I'd try to revert the layers to some earlier revisions
<dv_>
until the problem goes away
<dv_>
then you can start narrowing the search
alexst has joined #imx6-dev
<codinho>
dv_, my last question actually is: as my recipe is my own and as my patch is my own it could be buggy, but as meta-qt5 has the same thing to render video the same way, so is there any way to check it using recipe which is currently presented in master branch?
<dv_>
I dont think so. the whole point of zerocopy is to render dma buffers without copying. you need a way to generate said dma buffers.
<dv_>
I doubt something for this exists already
<dv_>
you'd have to write it yourself
<dv_>
zerocopy wont work with regular memory blocks, since they may not be physically contiguous
<dv_>
(plus, the gpu doesnt know about the MMU mappings)
<codinho>
dv_, so layer-qt5 had some time ago patch for this commited by otavia, then its was removed when qtmultimedia was moved to 5.3 as this patch included, so what is the point to add this patch if there is no way to check it?
<dv_>
well, how many software packages come without tests? :)
alexst has quit [Ping timeout: 245 seconds]
<dv_>
I think it is a useful addition, but not a feature that can yield advantages just like that
<dv_>
in other words, its a building block
<dv_>
you need to explicitely use it
<dv_>
and you do that by passing buffers to it that are physically contiguous.
<dv_>
btw. I do not know what happens if you pass non-dma buffers to it. IIRC glTexDirectVIVMap fails with these.
<codinho>
dv_, just for your understanding, it worked well for me at the past, now it just shows the black frames, I just want to have the way to check whether its my bug or it doesn't work because of some bug in master
<dv_>
codinho: where do the frames come from? from the imxvpudec element?
<codinho>
dv_, yes
<dv_>
hmm.
projectg1s has joined #imx6-dev
<dv_>
its a pity you dont have the layer revisions from before the repo sync
<codinho>
dv_, do you meant layer-qt5? or meta-qt5?
<dv_>
here's one idea: construct a gstreamer pipeline, like this : videotestsrc ! imxipuvideotransform output-rotation=1 ! <your sink<
<dv_>
the imxipuvideotransform output is placed in DMA buffers
<dv_>
perhaps these do not show black frames
<codinho>
dv_, imxipuvideotransform works with your sink
<dv_>
no. I meant YOUR sink.
<dv_>
qtquick2videosink
projectgus has quit [Ping timeout: 252 seconds]
projectgus has joined #imx6-dev
projectg1s has quit [Ping timeout: 252 seconds]
<codinho>
dv_, yes, something strange... imxipuallocator ../src/ipu/allocator.c:91:gst_imx_ipu_free_phys_mem:<imxipuallocator0> could not free physical memory at address 0x31400000: Bad file descriptor
<dv_>
uh what?
<dv_>
check the permissions of /dev/mxc_ipu
<dv_>
I cannot, since I currently do not have a rootfs handy (I am cleaning up things here)
<dv_>
as said, I have zero idea what repo sync did
<dv_>
again: retrace your steps. manually revert layer revisions to an earlier state, until things work again.
<dv_>
then try to find the commit which broke it.
<dv_>
tedious, time consuming, but the only way to fix it.
<dv_>
there are like a billion possible reasons for this weirdness
<codinho>
dv_, yeah, as from my poor experience with master branch almost any commit can break any thing
<dv_>
codinho: yep. thats why you _must_ write down the srcrevs every time.
<dv_>
just a reminder for future development
<codinho>
dv_, but again, how can I check the same rendering vivante thing using current master?
<codinho>
which recipe should work? is it your sink? or what?
<dv_>
my sink should work
<codinho>
dv_, your sink works
<codinho>
dv_, but this thing is about qt5
<dv_>
but now you know it works
<dv_>
so the drivers are not completely broken
<codinho>
dv_, I've understand it for sure, I just trying to find the recipe which uses it and it should work, and I don't understand what was the point to add zero-copy patch to layer-qt5 if there is no recipe to use it, that is why I'm asking for such kind of recipe
<dv_>
codinho: tried to contact the author of the patch?
<dv_>
maybe he has a test program
<codinho>
dv_, original patch was for qtmultimedia, but as otavio added it to fsl-community-bsp-platform I've started to think that there is a point
<codinho>
dv_, no, I did not
<dv_>
try to do that
bfederau has joined #imx6-dev
<codinho>
dv_, when I said what is the point, I meant what is the point to the yocto project, otavio, please clarify it
alexst has joined #imx6-dev
<dv_>
what does that now have to do with it?
<dv_>
contact the author. ask him for a test program. done.
<codinho>
dv_, sure, but if it was commited to yocto then I think there should be some app to just check it where it should be useful, if there is no one then there is no point to commit such thing fpr me
<codinho>
simple logic for me
<codinho>
that is why I've started to think that there is a example which use such thing
alexst has quit [Ping timeout: 264 seconds]
<dv_>
I actually agree. tests&examples are very useful. but they are not a requirement. it is difficult to require this though.
<dv_>
there are many cases where they simply cannot be provided
<codinho>
dv_, so there is a feature which is actually not working
<dv_>
note that this is not a core feature. it is an add-on. a bonus.
<dv_>
that is, I dont think otavio & co. test this one
<codinho>
dv_, sure, but there is no even single thing where it used
<codinho>
just loud comments about commits like "zero-copy rendering"
<codinho>
I'm not offending, just trying to understand what is actually going on
<dv_>
codinho: as said, discuss this with the author in the mailing list
<codinho>
dv_, ok, sure, thanks
<codinho>
dv_, I'm trying to find the author who broke the thing which worked some time ago or whether is it the bug
<codinho>
dv_, that is why I've asked whether I can check any recipe from official branch which should work
jas-hacks has left #imx6-dev [#imx6-dev]
<codinho>
omg, 5-0...
alexst has joined #imx6-dev
alexst has quit [Ping timeout: 240 seconds]
codinho has left #imx6-dev ["Leaving"]
alexst has joined #imx6-dev
alexst has quit [Ping timeout: 240 seconds]
Er0l_ has quit [Ping timeout: 240 seconds]
Er0l has joined #imx6-dev
alexst has joined #imx6-dev
bfederau has quit [Remote host closed the connection]
bfederau has joined #imx6-dev
steeve has quit [Remote host closed the connection]