pinchartl: pong
hverkuil: pong
posciak: you're alive ! :-) o genki desu ka ?
genki genki desu yo
tada isogashii
you lost me on the second sentence :-)
I have a quick question for you
I was wondering if you had one (or multiple) git branche(s) with the latest codec support code
especially on the kernel side
I think posciak has been replaced by a bot: it can say 'pong' but never actually answers questions :-)
pinchartl: "codec support code" ?
do you mean slice API?
for controls?
request API?
posciak: I expect it's the slice API. I certainly am interested in knowing what the status is of that.
hverkuil: well, not much can be done without request API functionality
hverkuil: I saw that you guys decided to talk with me after the summit
to have some discussion about minimal set of features for slice API that could be provided by request API's first iteration
if my understanding is correct?
if so, it would be great to do this
it would unblock me
pinchartl is working on the request API. Ideally we would be able to post a minimal feature set, but it is not clear at the moment whether that is feasible.
what is the actual concern?
Can you perhaps write an RFC describing what is needed for the slice API and where we can find the code that you wrote so far for this? And what the current status is of the slice API?
Basically a status update from your side. We haven't talked in quite some time, after all.
basically what your original configuration store did
allow storing control values with config store id
and apply_store
That is all working well for the slice API? Is there anything missing or things that could be improved?
yes it's working well
it's good that the old version didn't have any transactions or anything
we just do s_ext_ctrls
for all required controls
and that's it
and of course store id in qbuf
and then the driver just calls apply_store
mszyprow: sorry for not looking at that patch in December, but that month was very busy for me and I couldn't keep up.
Things have slowed down, so I can do a better review job now.
hverkuil: okay, I will prepare a new version tomorrow, now I need to go home
hey, is WARN() appropriate in v4l2-ioctl.c when unknown pixel format is encountered?
i mean... if you have out of tree driver that defines some custom pixfmts, you end up with ugly polluted dmesg if someone enumerate them
Hmm, I might make sense to make this WARN_ONCE. At least it won't spam in that case.
Feel free to post a patch changing this.
and do we really need a call trace in this situation at all?
yes, it is way too easy to add a new pixelformat and to forget to update that function. This will warn if that's the case.
we don't care about out-of-tree drivers (well, for the most part).
ok, i guess for embedded applications it's no problem as well as even when only old kernels are supported by the soc vendor, you can always patch v4l2 with new pixfmts
mchehab: thanks for all those patches. i will take a look and see how they work with the s,g_parm implementation.
out of curiosity, what is your kernel dev distro and version?
ezequielg: yeah, please test and see if the framerate will aproximately match what's estimated
mchehab: i will
from what I saw, with 50Hz, the original code were setting some wrong values for 6fps
(putting the device on 8fps)
btw, I think it is possible to add odd fps values too
by offseting the value calculated for the register by 0x000000001
and, for 1 fps, setting it to 0x8000 0001
but again that requires testing
mchehab: ok, i'll keep this in mind.
I just got a: Delivery to the following recipient failed permanently:  linux-media@vger.kernel.org, is anyone else having problems to send emails to the mailing list?
koike: does it say why it failed?
larsc, solved. I forgot to mark the plain text mode and it was sent with html
posciak: sorry, I had to leave in a hurry to board my plane :-/
yes, I mean the slice API
posciak: do you have a public branch with your current implementation ?
I assume there's one for chromeos
pinchartl: AFAIK the ChromiumOS branch for the Rockchip Chromebooks is chromeos-3.14, so quite likely that it will be there
https://chromium.googlesource.com/chromiumos/third_party/kernel
s/quite likely/I guess :)