summaryrefslogtreecommitdiffstats
path: root/drivers/media/usb
diff options
context:
space:
mode:
authorHans Verkuil <hverkuil-cisco@xs4all.nl>2023-11-30 13:58:12 +0100
committerMauro Carvalho Chehab <mchehab@kernel.org>2023-12-09 07:34:10 +0100
commit350ab13e1382f2afcc2285041a1e75b80d771c2c (patch)
treeaad3ccd80bbec3ea7b04d8c1592e41b043c78af6 /drivers/media/usb
parent3f1faa154a4316b1b585a25394697504b3c24e98 (diff)
downloadlinux-stable-350ab13e1382f2afcc2285041a1e75b80d771c2c.tar.gz
linux-stable-350ab13e1382f2afcc2285041a1e75b80d771c2c.tar.bz2
linux-stable-350ab13e1382f2afcc2285041a1e75b80d771c2c.zip
media: videobuf2: request more buffers for vb2_read
The vb2 read support requests 1 buffer, leaving it to the driver to increase this number to something that works. Unfortunately, drivers do not deal with this reliably, and in fact this caused problems for the bttv driver and reading from /dev/vbiX, causing every other VBI frame to be all 0. Instead, request as the number of buffers whatever is the maximum of 2 and q->min_buffers_needed+1. In order to start streaming you need at least q->min_buffers_needed queued buffers, so add 1 buffer for processing. And if that field is 0, then choose 2 (again, one buffer is being filled while the other one is being processed). This certainly makes more sense than requesting just 1 buffer, and the VBI bttv support is now working again. It turns out that the old videobuf1 behavior of bttv was to allocate 8 (video) and 4 (vbi) buffers when used with read(). After the vb2 conversion that changed to 2 for both. With this patch it is 3, which is really all you need. Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Fixes: b7ec3212a73a ("media: bttv: convert to vb2") Tested-by: Dr. David Alan Gilbert <dave@treblig.org> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Diffstat (limited to 'drivers/media/usb')
0 files changed, 0 insertions, 0 deletions