hverkuil: about [RFC] media: v4l2: Variable length controls (for h265 slice headers), I advised John Cox to post that RFC and bring this topic. It's required to support rkvdec and cedrus as well, so it would be a useful feature :)
ezequielg: are you hitting any limitation with the model that the capture queue is (on paper) independent from requests? one can also poll on the device fd to know when capture buffers are available for dequeuing, and use the flush command for flow control
Hey there. Some devices will release output and capture buffers at the same time. Eg. Hantro.
Because the output buffer is being decoded, so it's not released until the job is done. So far so good.
Notably all drivers in mainline are like this.
However, rpi4 hevc decoder is able to release the output buffer long before decoding is done. And the libre elec folks want to do that.
However, marking the output buffer as done will complete the request (because it's the only buffer in the request).
And so it's an issue.
ah~ in that case case I guess we can add some extra object representing the act of decoding to the request and only complete it when decoding is effectively done
Yeah, but from the uapi?
I added a pin/unpin internal api for them, and that worked, but I dislike the idea.
I think the request api spec is quite clear that request is done when the buffers in it are done.
what is the expectation from the uapi? being able to poll for when the OUTPUT buffer can be dequeued?
I think you can do that, but only if all the OUTPUT buffers are currently queued
Enoparse :)
I think it's reasonable to expect request complete is equal to decoding complete. But that's not what the spec and the core guarantees :)
"request complete = decoding complete" is what is guaranteed IIUC. What is not is that you will have a CAPTURE buffer ready by then :)
It's not guaranteed per se.
although the implication is so obvious that it probably shouldn't hurt to have it explicitly written in the spec (modulo the HOLD flag of course)
If decoding is done, and that's the semantics,then imo the capture buffer should be done too (to save an extra call). No?
And it would need some extra clarification and an api to help drivers that also want to early return the output buffer (does not seem hard)
in practice, I agree that's what currently happens. And I'm fine with adding that to the spec. But in the end you'll still do a DQBUF to get your buffer, so which call is being saved?
The extra poll (no?)
Bare with me being a tool ;)
in both cases you can do "poll for request -> do (tentative) DQBUF"
Hm... Let me think...
with the current spec, you just need to also handle the fact that the DQBUF is not guaranteed to succeed (which you should do anyway even if the spec says otherwise :))
Right. I think that's the expectation that is being questioned.
and if you use a model where CAPTURE buffers are dequeued by a separate thread, then polling on the device to wait for them is the simplest and most reliable solution in both cases as well (since requests will have been submitted from the application thread)
I was under the same impression. But I'm told application want stronger semantics.
Iiuc, they want request complete == capture buf available
IIUC our userspace takes the approach of polling on the device for CAPTURE buffers, and ignores requests until it is time to recycle them (by which time they are supposedly completed)
Right.
Then you are not really assuming request complete means decoding done. It only means it can be recycled.
Iiuc :)
if there is a reason why they can't do without this expectation then sure, we can discuss it, but at the moment I don't see a blocking factor in not having it
Unsure what blocking factor would be.
And unsure if this hurts performance either.
that being said, maybe having the expectation clearly stated would also make the spec simpler to understand and implement
That would be nice.
Note that this means that actually, request complete had nothing to do with job completion.
They have different lifetimes.
the current spec does not mention anything about request completion...
yeah, currently anything goes basically
it would probably be harmless to state that a request must not complete until all the decoding work for the job (including writing to the CAPTURE buffer and making it available if the frame is complete) is done
right now requests are just used as a mean to associate controls to be applied when processing the OUTPUT buffer
Right. Or have a flag to pick the request semantics.
If we want to make a request completion at decoding completion, but still want to release output buffers when done .. some simple helpers are needed.
ah but actually I think that expectation is already implicitly enforced by the way requests work. Since user-space is supposed to be able to read controls on the completed request, the request completion cannot happen until processing is done, otherwise we cannot know the values of these controls
in that case there should be no problem clearly stating that in the spec as well
You mean in the case of readback controls?
yes
not that we need to read controls back with stateless decoding, but that's how requests are supposed to behave at their core
So in this regard... Do you recall what blocked us from having the capture buffer as part of the request too?
That would be the most intuitive way of expressing the relationship, output and capture are in the request.
nothing I think! it's just that it was not a requirement, and it allows to handle both queues independently (i.e. OUTPUT buffers and requests queued by one thread, CAPTURE buffers by another), so there is not need to enforce it
I see.
having the CAPTURE buffer in the requests would also make the driver guarantee which CAPTURE buffer will contain which frame, which may be nice for management, but puts more constraints on them
(as you know we are not safe from funky firmware doing what they want...)
so at this point I think the only question I have is, would explicitly stating that request completion means decoding completion be enough for your use-case? If so I think there is no harm in stating that explicitly in the spec
then internally we can do whatever is needed to make early OUTPUT buffer release possible. Maybe we can just sneakingly add the CAPTURE buffer to the request once the target buffer is decided
Tbh, I was considering the same solution. Only wondering if that would have any side effect I'm missing.
sounds safe and logical to me (famous last words)
And will make our users the happiest users in the whole wide world.
hello all
is there a connection between drm writeback connectors (such as in the r-car du) and v4l2 capture devices?
or, to phrase it better, how can i capture the writeback data? does v4l2 offer a way to do so?
hverkuil: ping
neg: pong
hverkuil: I like the EDID patches and plan to test during the day. In the last patch you mentioned tesitng on Koelsch with a looped HDMI cable, is that test procedure public somewhere?
Just use v4l2-ctl to set the EDID, and edid-decode /sys/devices/platform/soc/feb00000.display/drm/card0/card0-HDMI-A-1/edid to read it out from the adv7511.
I've added 3 and 4 block EDIDs to v4l2-ctl:
4 blocks: --set-edid type=hdmi-4k-600mhz-with-displayid
3 blocks: --set-edid type=displayport-with-cta861
So you do need the very latest v4l-utils to test this. Those example EDIDs are representative of what you can find in real displays.
To be honest, I thought that the adv76xx HDMI receivers only supported 2 blocks, so it was a happy surprise to me when I found out that they actually support 4 blocks. It was just the driver that didn't support it.
neat, I will give it a spin
hverkuil: tfiga: about V4L2_BUF_FLAG_NO_CACHE_INVALIDATE, the doc says "if the buffer is not going to be touched by the CPU", this is awkward and is missing a lot of usage context, the doc also does not use the usual phrasing like "set by user" or "set by driver"
Any change to decipher the doc ?
I would not know how to use that
same applies to the CLEAN flag  "has not been created by the CPU but by some DMA-capable unit", created is awkward, the buffer could have simply been "edited"
my two cent, and I think this should not be at v4l2 layer ....
ndufresne: it's best if you ask this on the mailing list. Include Sergey Senozhatsky <senozhatsky@chromium.org> in the CC list, he's working in that area.
sure, I'll do, just doing a quick check if I didn't miss something
hverkuil: just an example, we already call into DMABUF sync API in gst, whenever CPU access (read or write) happens, I understand that CACHE_INVALIDATE is a one time thing (and not delayed) in v4l2, looks like core issue in v4l2 dmabuf usage, but for CLEAN, this is 100% redundant
this all looks like if worms came out of a rotten box ;-P
It's only for mmap buffers
But yes, the documentation sounds weird indeed
ndufresne: ^
tfiga: for mmap, excluding mmap+expbufs ?
but now I get why redundancy is needed
thank