mchehab: re: the mtk-vcodec encoder series at https://patchwork.kernel.org/patch/11744247/, Bjorn gave us permission to take the remoteproc patch in the media tree (https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg2310691.html). Do you have everything needed to proceed with the merge?
gnurou: everything but time :-)
I'll try to merge this during this weekend.
I'll try to merge the patchset during this weekend.
mchehab: ok :) no pressure though.
that'd be great! There is more coming on the decoder side after this
montjoie: ping
hverkuil: pong
montjoie == Corentin Labbe <clabbe@baylibre.com> ?
yes
Ah :-)
I noticed that patch 01/49 (and perhaps the cover letter 00/49) never made it to linux-media.
I think that there were some vger.kernel.org issues at the time you posted this series, so perhaps it was lost.
at least lkml got it, present on lore
Can you post these two to linux-media again? That way patchwork will pick it up.
I can resent a RFC2 with first comments fixed
BTW, out of curiosity, was this work paid for by baylibre?
RFC2 would be fine as well.
not really
migrating slowy all stuff under an uniq address
Oh, was the first patch just a revert of the zoran deprecation patch? It might have been too big for linux-media.
yes it is the revert
was there a cover letter as well?
yes cover is 00/49
OK, that's gone as well. Just post a RFCv2, I think two posts just were lost.
I want to take a look at it today to see if it would make sense to just accept it for 5.10 (deadline for that today), which would make it easier to continue development.
It's a staging driver, so as long as it compiles cleanly and is in reasonable state, then that should be OK.
in cover letter I ask if staging is a good target
for me staging is useless since it is already converted, compiling and working
but gregkh didnt say a word
If you want to move it out of staging, then this needs more time for review etc.
that's no problem for me, I can wait
It's our responsibility to make that decision, and since the cover letter didn't make it to linux-media (and I wasn't CC-ed) I never saw your question :-)
do you want to be CC/TO ?
In that case, when you post RFCv2 have a final patch that moves it out of staging.
Yes, please Cc me.
You don't need to Cc Greg or lkml, patches for drivers/staging/media are handled by us, not Greg (well, for the most part).
lkml is mandatory for me, my workflow is based on lore
ok
hverkuil: hello there, how are things going? Would you mind checking prepare_ext_ctrls() in drivers/media/v4l2-core/v4l2-ctrls.c ? The condition for pointer controls size (c->size < tot_size), why do we allow applications to pass less bytes than needed? For our new codec controls, sounds like applications should be checked they are passing the exact size.
ezequielg: for G_EXT_CTRLS if the size is too small it will set the size to the right size and return ENOSPC. For try/set it will return EFAULT, indicating that the size is too small.
It's in part legacy code from the time that QUERY_EXT_CTRL didn't exist and the only payload control was a string.
Modern applications should just query the payload size and allocate the correct size.
right. I meant the other way around, what if applications pass more size than expected?
Sorry, a correction:  It's in part legacy code from the time that QUERY_EXT_CTRL didn't exist.
That's fine. The remainder is just ignored and c->size is set to the actual size.
I wonder if passing more bytes than expected should be errored. But then I suspect some application might start complaining. I'm thinking that if the application is passing more bytes than expected, it is an indication of something going wrong.
Could be useful to trap that.
Well, it would break ABI :-)
yeah.
at some point I will have to look into flexible sized controls. I suspect I'll have to create  VIDIOC_G/S/TRY_EXT2_CTRLS ioctls at that time. We'll see.
mchehab: I've sent in my PR, sorry for being late
tfiga: hverkuil: regarding the issue with "[PATCH v12 07/29] media: v4l2-mem2mem: add v4l2_m2m_suspend, v4l2_m2m_resume", how about we just post a fix, removing the line that got added by accident, and ask mchehab to merge it directly?
ezequielg: anything that works for mchehab is fine with me