| ↑back Search ←Prev date Next date→ Show only urls | (Click on time to select a line by its url) |
| Who | What | When |
|---|---|---|
| zid` | error: ‘struct v4l2_requestbuffers’ has no member named ‘capabilities’
zid` wonders if he forgot how to spell Hmm indeed, my /usr/src/linux/videodev2.h has a reserved[2] and no capabilities instead of a capabilities and a reserved[1] Is there some version test I was supposed to do on the API? | [08:32] |
| hverkuil | zid`: what application are you trying to compile? | [08:41] |
| zid` | https://linuxtv.org/downloads/v4l-dvb-apis/uapi/v4l/vidioc-reqbufs.html#c.v4l2_requestbuffers I was writing code based on this page
but apparently it doesn't match my kernel's version of the api | [08:53] |
| hverkuil | It's using the latest videodev2.h from the mainline kernel. You can also get a copy from the v4l-utils git repo, include/linux directory.
https://git.linuxtv.org/v4l-utils.git/ | [08:54] |
| zid` | Oh I'm stupid, I was looking for the version as an ifdef in the header, but I get the version from QUERYCAP don't I
s/ifdef/define | [08:55] |
| zzam | What is needed to fix cx23885 to work after suspend? | [08:56] |
| zid` | oh that change is only 22 days old heh, thatd explain why this kernel doesn't have it :D
I can't really ifdef that until I know which mainline it's going to end up in, I'll just pretend it doesn't exist | [08:56] |
| hverkuil | zid`: it will be released in 4.20. | [08:58] |
| zid` | Those linuxtv.org docs are really useful btw, good job to whoever made them | [08:59] |
| ............... (idle for 1h13mn) | ||
| svarbanov | hverkuil: tfiga: can you give me a hint how the drivers can know when reqbuf(count=0) is called? | [10:12] |
| tfiga | svarbanov: what do you mean by "can know"?
it's the driver that implements the .vidioc_reqbufs callback | [10:12] |
| svarbanov | hverkuil: tfiga: I'm asking in the context of this state machine transition: Seek -> Initialization [ label = "VIDIOC_REQBUFS(OUTPUT, 0)" ];
tfiga: queue_setup for reqbuf(count=0) is not called, just vb2::stop_streaming is called but in this case I don't know is that regular streamoff or reqbuf(0) | [10:13] |
| tfiga | svarbanov: queue_setup is a vb2 callback, but I got your point
if one just uses vb2_reqbufs, it might be problematic... or v4l2_m2m_reqbufs() I think you may need to wrap it into your own callback for now but I wonder if we shouldn't be calling queue setup with 0 buffers that probably wouldn't work with existing driver code, though | [10:15] |
| hverkuil | tfiga: no, it is stop_streaming that should know this. It could be as simple as a flag in the vb2_queue struct. | [10:18] |
| tfiga | hverkuil: why stop_streaming? one can STREAMOFF without the intention to free the buffers
hverkuil: in earlier discussions, we agreed that the driver must not allocate any hardware resources (e.g. instance ID) before REQBUFS and so the corresponding place to free such would be REQBUFS(0) which is actually how s5p-mfc handles it | [10:18] |
| hverkuil | Ah, I get it. In other words, you need a counterpart to queue_setup.
i.e. a queue_release or queue_free callback. makes sense to me as it allows you to allocate resources in queue_setup and free them when the queue is freed. Most drivers only allocate resources in start_streaming and free them in stop_streaming, but for codecs that's a bit different. | [10:21] |
| svarbanov | hverkuil: and call queue_release from here https://elixir.bootlin.com/linux/v4.20-rc4/source/drivers/media/common/videobuf2/videobuf2-core.c#L698 ? | [10:26] |
| hverkuil | I'd call it in __vb2_queue_free all the way at the end in the final 'if (!q->num_buffers)'.
scratch that. This is trickier than you would expect. esp. in combination with CREATE_BUFS. | [10:34] |
| svarbanov | hverkuil: yes, I saw that it is not so easy | [10:46] |
| .... (idle for 19mn) | ||
| hverkuil | svarbanov: I don't have time right now. I can give some food for thought, though:
queue_setup doesn't actually allocate anything. It is really a validation step. So this isn't a good place to allocate resources. You either need a queue_alloc/queue_free pair (called after the first buffer(s) were successfully allocated and before the last buffer(s) are freed), or a buf_alloc/buf_free pair called for each allocated/freed buffer. For the latter pair it would be nice if you can somehow know (argument? q->num_buffers?) if it is the first or last buffer that is allocated/freed. I am inclined to go for buf_alloc/free since it works better with CREATE_BUFS and a future DELETE_BUFS. And it allows for per-buffer resources. | [11:05] |
| .......... (idle for 46mn) | ||
| svarbanov | hverkuil: buf_free will has the same semantics as .buf_cleanup ... | [11:55] |
| hverkuil | svarbanov: no, buf_init and buf_cleanup is also called when the same buffer is queued with a new dmabuf or a new userptr.
But for MMAP your statement is true. | [11:56] |
| ...... (idle for 26mn) | ||
| tfiga | hmm, the callback we're looking for should be only called when the number of buffers in the queue goes down to 0 | [12:23] |
| hverkuil | tfiga: for this hardware, yes. But perhaps some hw will need to allocate resources per buffer? | [12:24] |
| tfiga | hverkuil: not really for hardware - for the transition to "unitialized" state
this is the time we can free any state of the encode/decode | [12:25] |
| hverkuil | Again, for this specific case. I rather have a more generic op than something that is specific to one use-case. | [12:26] |
| tfiga | for buffers, we indeed may need some separate per-buffer callbacks, but I think that's another problem
although we could indeed use the per-buffer callbacks and just do something there after the last buffer is freed but I wonder if a callback that is defined to be called only after there is no buffers anymore wouldn't make the code cleaner | [12:26] |
| hverkuil | As I mentioned: you need two ops: you can't really use queue_setup to allocate resources since it's a validate step, not an allocation step. | [12:32] |
| tfiga | right | [12:33] |
| hverkuil | But you need to take into account what happens when new buffers are allocated later. Do you call a 'queue_alloc' again? What is going to happen when DELETE_BUF(S) is added in the future?
A buf_alloc/free pair is more future-proof IMHO than a queue_alloc/free pair. | [12:33] |
| .... (idle for 19mn) | ||
| tfiga | hverkuil: it's a kernel API, though, it can evolve if new needs show up
but since a per-buffer API would work for us, I think that's okay | [12:53] |
| svarbanov | hverkuil: tfiga: still the boundary is thin between buf_init/cleanup and buf_alloc/free, both pairs crossing each other IMO | [12:56] |
| hverkuil | buf_init/cleanup deals with buffer memory, buf_alloc/free (perhaps we need better names for that) are called when new buffers are added or removed (i.e. q->num_buffers changes). | [13:01] |
| zid` | Am I allowed to bug you with userspace issues here? Why might mmap be giving eperm for the VIDIOC_QUERYBUF stuff | [13:04] |
| hverkuil | zid`: did you open the video node with RW permissions? (O_RDWR) | [13:05] |
| zid` | ah, thanks
that'd make sense, seeing as I asked mmap for rw access (not sure why though, the howto said 'recommended') | [13:06] |
| ..... (idle for 20mn) | ||
| svarbanov | hverkuil: tfiga: infact if we have some kind of codec api implementation v4l2-codec.c based on mem2mem we can handle the state transitions there? once i have .vidioc_reqbuf I can call some registered codec ops | [13:26] |
| hverkuil | svarbanov: I very much prefer a generic vb2 solution rather than a codec hack that is not usable elsewhere. | [13:31] |
| svarbanov | hverkuil: ok, agreed. but v4l2-codec.c is not bad idea though | [13:36] |
| hverkuil | I agree with that. | [13:37] |
| ........ (idle for 35mn) | ||
| tfiga | svarbanov: that's the ultimate goal
something like a stateful codec framework hverkuil: buf_alloc/free could be fine, but I'd like to make it easy for the driver to detect the edge cases of first buffer allocated / last buffer freed e.g. no need to count the number of buffers on its own | [14:12] |
| hverkuil | tfiga: I agree. Easiest would be to use q->num_buffers. Alternatively it can be an argument. It depends a bit on the implementation what is easiest.
I'm tracing a bunch of request-related kernel oopses BTW. There are some nasty corner cases that weren't tested properly by v4l2-compliance. You can expect some patches soon. As part of that I am modifying v4l2-compliance to be able to take advantage of the vivid error injection controls, so I can test what happens when the driver returns an error in start_streaming(). Nothing good happens then, BTW :-( Esp. with requests in the mix. | [14:19] |
| ............. (idle for 1h3mn) | ||
| tfiga | hverkuil: thanks for looking into this :) | [15:25] |
| hverkuil | tfiga: I'm about to post the patches and update v4l2-compliance. | [15:27] |
| tfiga | hverkuil: I'll be traveling tomorrow, but should be able to take a look later this week | [15:31] |
| ....... (idle for 34mn) | ||
| hverkuil | tfiga: Hmm, not all requests and request objects are released. I need to dig some more tomorrow before I can post the patches. | [16:05] |
| *** | benjiG has left | [16:19] |
| hverkuil | tfiga: fixed it, will post tomorrow. | [16:31] |
| .................................................................. (idle for 5h29mn) | ||
| *** | BenG83 has left "Leaving" | [22:00] |
| .......... (idle for 49mn) | ||
| kbingham | Is there any shortcut that I'm missing for resetting control values back to defaults?
I.e. perhaps from v4l2-ctl ? using scripting to iterate over 'v4l2-ctl -l' to extract the default, and then re-apply seems very tedious... Use case : Running tests, I want to make sure all controls on a {sub,}dev are at defaults before I start the test. | [22:49] |
| ↑back Search ←Prev date Next date→ Show only urls | (Click on time to select a line by its url) |