[12:17] <yang> Hello, maybe I am in the right channel ? I want to backup VHS tapes from analog VCR to Linux, and was looking for the best adaptor to do that - I found this article here which suggests "WZYuan USB 2.0 Easycap Dc60" - https://gordonlesti.com/digitize-a-vhs-tape-with-ffmpeg-and-easycap-on-linux/
[12:18] <yang> So I am interested if this dongle is the best one to suit the purpose?
[12:20] <hverkuil> yang: should be OK. Just be aware that manufacturers of those dongles can switch to a different chipset without notice. And if you are unlucky, the new chipset is not supported by linux. On the other hand, these dongles are dirt cheap.
[12:21] <yang> right, I think the current (old) dongle is still supported, so I won't risk to buy a more modern one
[12:28] <hverkuil> bbrezillon: can you review https://patchwork.linuxtv.org/patch/59915/ ? That's the only patch in this hantro series that isn't reviewed yet.
[12:34] <hverkuil> paulk-leonov: can you review https://patchwork.linuxtv.org/patch/59893/ ? That's the only patch in this cedrus series that isn't reviewed yet.
[12:43] <ndufresne> hverkuil, what I really dislike with delete_buf is that it's a regression over using reference count (dmabuf/fd)
[12:44] <ndufresne> basically, I don't really like this idea that a queue is aware of buffers even if they are not queued
[12:45] <ndufresne> afaic there is hardware that uses that (samsung mfc) but this is always a restriction imposed by software (firmware)
[12:45] <ndufresne> I don't disagree that it would fit the current state of vb queues
[12:46] <ndufresne> I would not be surprise though that users will simply do REQBUFS, EXPBUF, DELETE_BUF and then use dmabuf importation for the rest, as it's much more flexible to keep the buffer detached
[12:47] <hverkuil> ndufresne: good point. Definitely something to look at when working on the new streaming ioctls.
[12:48] <ndufresne> indeed, I think this will need a bit of time to think through
[12:49] <hverkuil> Oh yes, but it is an interesting point that you raised.
[12:51] <hverkuil> One option is that we add a new ioctl to allocate and export N dmabufs, suitable for the current format (or a specified format), and the new streaming ioctls will only use dmabuf.
[12:51] <ndufresne> there will also soon be request to support dma heap also, maybe delete_buf make sense in the context of in-queue allocation, and allocating detached buffer would be through heaps, but I'm not sure how this will work really
[12:52] <ndufresne> even on drm side (which is already using detached allocation) it's not clear how heaps fit
[12:53] <hverkuil> ndufresne: do you have a pointer to dma heaps documentation?
[13:00] <paulk-leonov> hverkuil: done, thanks for the reminder
[13:00] <paulk-leonov> 4k series is good to go IMO
[13:05] <hverkuil> paulk-leonov: nice. I'll post a new PR today and I'll include this in it.
[13:05] <paulk-leonov> great!
[13:08] <ndufresne> hverkuil, https://lkml.org/lkml/2019/11/5/1301 in the cover there is usage links, remember, it's just ION renamed, no one have worked on a generic Linux integration yet, ideas I've came around during ELCE is that drivers could expose some heaps, some general purpose heaps will likely exist, and then drivers could have new API to tell user space which heap they are compatible with, drivers needs of course to document the allocation size (including extra
[13:08] <ndufresne> for alignment), this is already done by v4l2 through sizeimage I think
[13:12] * yang waves to paulk-leonov 
[13:12] <paulk-leonov> hey!
[13:18] <hverkuil> ndufresne: thanks for the pointer.
[19:04] <bbrezillon> hverkuil: done
[19:05] <bbrezillon> looks like we have the same info in different places (ctrl and OUTPUT_FMT)
[19:06] <bbrezillon> I'm fine using the OUTPUT_FMT bits, but I'd like to understand if it's fixing a real bug or if it's done to make things consistent
[19:06] <bbrezillon> Kwiboo: ^
[19:07] <bbrezillon> if this is the latter, we should drop the Fixes tag IMHO
[19:29] <hverkuil> bbrezillon: thanks! I'll make a new PR for these hantro patches.
[20:19] <Kwiboo> bbrezillon, hverkuil: the change to use the OUTPUT_FMT bits was made mainly made for consistency with mv buffer offset calculation (and cedrus), no real bug that is fixed, so probably best to drop the Fixes tag :)