| ↑back Search ←Prev date Next date→ Show only urls | (Click on time to select a line by its url) |
| Who | What | When |
|---|---|---|
| hverkuil | ezequielg: that's correct, capture buffers aren't part of the request. In practice it is very likely that the capture buffer will be marked 'done' at the same time that the request is completed, but that is by no means a guarantee. The capture queue is independent of the output request. | [07:04] |
| sailus | Any concerns separating v4l2-async as a module from videodev? | [07:04] |
| hverkuil | sailus: not particularly, but why do you want to? | [07:06] |
| sailus | hverkuil: v4l2-fwnode is also a separate module.
Few systems of certain classes need anything in v4l2-async. | [07:08] |
| hverkuil | Fine by me. | [07:11] |
| ..... (idle for 20mn) | ||
| sailus | hverkuil: It's 25 kiB on 32-bit ARM. Thank you. | [07:31] |
| ................................................ (idle for 3h59mn) | ||
| ezequielg | hverkuil: thanks for confirming this. I believe we will have to clarify this in the Request API doc (I can make a try), since it's rather unfortunate that's applications have assumed that the capture buffer would be somehow relate to a request.
And also, I think we _might_ want to offer a way for applications to poll one fd (the request fd) and get notified of both output/capture buffer being ready. I will be thinking about this as well. | [11:30] |
| .............. (idle for 1h5mn) | ||
| sailus | ezequielg: Any comments on the async/fwnode patches? I was thinkin of sending a pull request on them soon. | [12:36] |
| ........... (idle for 53mn) | ||
| ezequielg | sailus: let me review that :) | [13:29] |
| ......... (idle for 42mn) | ||
| *** | minecrell has quit IRC (Quit: :() | [14:11] |
| ........ (idle for 36mn) | ||
| tfiga | hverkuil: out of curiosity, what's the reason for me being in the email threads about samsung drivers? | [14:47] |
| pinchartl | tfiga: do you also receive too many e-mails ? :-) | [14:59] |
| ndufresne | hverkuil: I think for codecs, it is documented that (even though not at the same time) that the decode would be complete when the request is signalled
if not, this is how it was interpreted everywhere, you'd just break userspace (using non-blocking DQBUF) by interpreting it otherwise of course, with the exception of when the HOLD flag was used, in this case, the driver is free to do whatever it wants hverkuil: the reason you don't want to go the route of stating the dqbuf is totally independant, is that you would force two poll() calls per decode operation which is slow | [15:09] |
| ..... (idle for 20mn) | ||
| ribalda | hello, it is only me who it is not receiving emails from patchwork? (when a state has changed?) | [15:33] |
| ......... (idle for 42mn) | ||
| tfiga | pinchartl: yes, but that's not anything new ;)
just wondering if I'm listed somewhere as someone related to those drivers because I was explicitly CCed | [16:15] |
| ezequielg | ndufresne: you won't break userspace, as the drivers that are going to complete the request before the capture buffer are not upstream.
so nothing will be broken. just that we are clearly saying that it wasn't ever a guarantee. | [16:20] |
| ribalda: maybe you need to have a user in patchwork? (I think I'm getting those) | [16:31] | |
| ribalda | ezequielg: I have it and it has: Notify, yes | [16:31] |
| ezequielg | then dunno. | [16:32] |
| ribalda | ezequielg: arrrrggg, the spam filter
sorry, my bad (i fwd mail from @chromium to my normal account, but the spam is not fwd) | [16:32] |
| Inky1003 | Hello guys, I'm with a TM6010 device (id 1f4d:6650), made by Geniatech, as It seems. The problem is: the video is not 100%, also, there is a function that just spammed my system logs, dmesg and everything that is related to v4l2. | [16:36] |
| ndufresne | ezequielg: on the opposite side, I'm saying that for performance reason, in absence of dmafence support, it should guaranty that the capture buffer is ready somewhere before (or at the same time) as the request completes for codecs
you can achieve your special case (or hack ?) with polling for the release of the bitstream buffer anyway | [16:41] |
| ezequielg | i know you'll disklike this: but that's a new expectation (which I'm happy to discuss). the capture buffer is not part of the request, and so the assumption about capture and request being associated is made up. | [16:42] |
| ..... (idle for 21mn) | ||
| ndufresne | ezequielg: the spec does say, so the polling behaviour of the request is totally undefined, which is a mistake, in fact, the decoding process is incomplete, as it should specify how to sync with the decoding state | [17:03] |
| ezequielg | where do you read this in the spec? | [17:03] |
| ndufresne | The intention, and that was discussed with gnurou is that the FD polling was sufficient to sync on the decode operation to be complete, hence, assuming decode order (Which is well documented in the spec), you can just call DQBUF to get the result
ezequielg: I'm surprised, I thought it was what you referred to, https://www.kernel.org/doc/html/latest/userspace-api/media/v4l/dev-stateless-decoder.html ezequielg: and there is indirect reference to this intention, "This will result in the (potentially partially) decoded CAPTURE buffer not being made available for dequeueing," but clearly something went missing here, I would need to collect and read the review comments again, this is quite far, and was done in a rush fortunatly, omission is not as bad as errors | [17:04] |
| ezequielg | I personally don't like this "capture is implicitly part of the request". Not sure when this was decided, or why. | [17:08] |
| ndufresne | it's not part of the request, that we all agree on
but the request outcome is that there will be ca capture buffer ready to be dequeued unless of course the HOLD flag is used ezequielg: whatever we do, we need eventually to fill the gap and define what "polling the request" means, but as I said, the intention was that the request was like a fence, it would be signalled when everything around the decoding operation is done, that includes the capture buffer marking (done vs error) perhaps unfortunate, but you can signal bitstream (output queue) independently if you need bitstream buffer to be made available earlier | [17:12] |
| ezequielg | Do you know what's preventing the capture from being part of the request (besides some code currently preventing it) ? | [17:19] |
| ndufresne | but you would not need this if you weren't emulating in the first place
ezequielg: I wasn't involved in this decision, it feels like a limitation of the vb2 queue model, not sure if it's internal or external, I think hverkuil and pinchartl came to that conclusion That's mainly why we have this (to my opinion) horrible timestamp passing and magically saved in driver references ah, I'm starting to figure-out | [17:19] |
| Inky1003 | guys, my v4l device is spamming an error on qv4l2, and the video is struggled with a green color | [17:22] |
| ndufresne | ezequielg: you cannot queue buffer twice, so you cannot do two operations that write to the same capture buffer
and that looks like why we cannot do explicit reference passing, and need to use timestamp | [17:22] |
| .... (idle for 19mn) | ||
| *** | Inky1003 has left "Konversation terminated!" | [17:41] |
| ezequielg | sailus: reviewed :) | [17:52] |
| ↑back Search ←Prev date Next date→ Show only urls | (Click on time to select a line by its url) |