[07:49] <tfiga> hverkuil: am I missing something or we have a bug in vb2 in handling of v4l2_plane::length == 0?
[07:52] <tfiga> hverkuil: __prepare_dmabuf() will call __fill_vb2_buffer(), which will call __verify_length(), which will fail if plane length is 0
[07:53] <tfiga> hverkuil: however, in __prepare_dmabuf(), several lines below, there is code that handles the case when length is 0
[07:53] <tfiga> hverkuil: https://elixir.bootlin.com/linux/latest/source/drivers/media/common/videobuf2/videobuf2-core.c#L1127
[08:22] <svarbanov> tfiga: do you mean that b->m.planes[plane].length can be zero but b->m.planes[plane].bytesused != 0?
[08:22] <tfiga> svarbanov: yes
[08:23] <tfiga> technically bytesused can be 0 too
[08:23] <tfiga> it doesn't matter in this case
[08:24] <tfiga> svarbanov: ah, it matters, because it's for OUTPUT planes
[08:24] <svarbanov> tfiga: it is for OUTPUT planes __only__
[08:24] <tfiga> but then, for OUTPUT planes it's unlikely to have 0 bytesused
[08:25] <svarbanov> tfiga: bytesused can be filled by drivers only, right?
[08:25] <tfiga> no, bytesused for OUTPUT buffers is filled by the application
[08:26] <tfiga> the driver doesn't know how much data the application wrote to the buffer
[08:26] <svarbanov> tfiga: right, I always think about capture buffers :)
[08:26] <tfiga> I always use uppercase when using V4L2 buffer type
[08:27] <tfiga> so effectively, CAPTURE buffers are output buffers
[08:27] <tfiga> the spec also allows the userspace to set bytesused to 0
[08:27] <tfiga> and then it's assumed to be the same as length indeed
[08:29] <tfiga> svarbanov: also the spec defines length as "Size in bytes of the plane (not its payload). This is set by the driver based on the calls to ioctl VIDIOC_REQBUFS and/or ioctl VIDIOC_CREATE_BUFS."
[08:29] <tfiga> it doesn't say that the application needs to fill it...
[08:29] <tfiga> so failing if it's 0 sounds like a bug
[08:30] <svarbanov> tfiga: but what is a plane with size = 0 :)
[08:31] <svarbanov> it is more like dmabuf workaround when the size is not set by userspace
[08:34] <tfiga> svarbanov: why would the userspace need to set the size?
[08:34] <tfiga> it doesn't set it for MMAP buffers either
[08:34] <tfiga> because the size is known from the DMA-buf
[08:34] <tfiga> and the code from my link seems to attempt to handle it
[08:34] <tfiga> but it cannot happen, because __verify_length() fails before
[08:35] <tfiga> in any case, we have to fix it by either specifying that the application is required to set it for USERPTR and DMA-buf or by allowing it to be 0
[09:56] <kbingham> sailus, Hrm ... is your webserver/git server down? I can't clone : git://git.retiisi.org.uk/~sailus/raw2rgbpnm.git
[09:59] <kbingham> sailus, Aha - never mind - seems I might have had an old url ? <git://salottisipuli.retiisi.org.uk/~sailus/raw2rgbpnm.git> worked.
[11:03] <sailus> kbingham: Yeah, it's a different virtual machine now...
[15:53] <ezequielg> hverkuil: tfiga: just sent a series with some pixelformat helpers. if it's what you had in mind, we can add the missing bits.
[15:59] *** prabhakarlad has left 
[16:24] <sailus> mchehab: Do you have plans to write a summit report from the last week's meeting?
[16:24] <sailus> I'd be happy to do that, perhaps apart from the CEC or Rc-core topics which I know little about.
[16:24] <sailus> (And remember little as well.)
[16:59] <mchehab> sailus: yes, we should write a summit report
[16:59] <mchehab> if you have time for doing it, that would be great!
[17:07] <sailus> mchehab: Ack.
[17:08] <sailus> I expect to post a draft (w/o CEC/RC-core) during the next week.
[17:10] <sailus> Time to leave.
[17:10] <sailus> Have a nice week-end!
[17:26] <mchehab> have a nice weekend
[23:57] <sailus> kbingham: I just realised I had a problem with the firewall configuration.
[23:57] <sailus> The right hostname is indeed git.retiisi.org.uk; it seems you're the first to notice in some year or so.
[23:57] <sailus> Or... could it be others are using ipv6? ;)