FS#44091 - [zbar] zbarcam fails on uvcvideo V4L2 driver

Attached to Project: Community Packages
Opened by point (mpoint) - Saturday, 07 March 2015, 19:20 GMT
Last edited by Morten Linderud (Foxboron) - Saturday, 06 June 2020, 14:52 GMT
Task Type Bug Report
Category Upstream Bugs
Status Closed
Assigned To Felix Yan (felixonmars)
Architecture x86_64
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No

Details

Description:

ZBar processor uses VIDIOC_REQBUFS ioctl while probing for supported I/O modes. Then it uses VIDIOC_S_FMT, which fails probably because the driver is already prepared to capture in another format. The solution is to release video buffers after probing and request them again when needed.

I think this is the same bug as already reported upstream:
http://sourceforge.net/p/zbar/bugs/81/
Sorry for posting it here, SourceForge doesn't let me post there.

Additional info:

zbar 0.10-5
linux 3.18.6-1

Steps to reproduce:

Try to use zbarcam with a UVC camera.

zbarcam --verbose=8 --nodisplay
_zbar_video_open: opened camera device /dev/video0 (fd=5)
_zbar_v4l2_probe: HD WebCam on usb-0000:00:14.0-3 driver uvcvideo (version 3.18.6)
_zbar_v4l2_probe: capabilities: CAPTURE STREAMING
v4l2_reset_crop: crop bounds: 640 x 480 @ (0, 0)
v4l2_reset_crop: current crop win: 640 x 480 @ (0, 0) aspect 1 / 1
ERROR: zbar video in v4l2_reset_crop():
system error: setting default crop window (VIDIOC_S_CROP): Inappropriate ioctl for device (25)
v4l2_probe_formats: enumerating supported formats:
v4l2_probe_formats: [0] YUYV : YUV 4:2:2 (YUYV)
v4l2_probe_formats: [1] MJPG : MJPEG COMPRESSED
v4l2_probe_formats: current format: YUYV(56595559) 640 x 480 (line=0x500 size=0x96000)
_zbar_v4l2_probe: using I/O mode: USERPTR
proc_input_thread: spawned input thread
_zbar_best_format: from YUYV(56595559) to Y800(30303859)=24
zbar_negotiate_format: YUYV(56595559) -> Y800(30303859) (24)
_zbar_best_format: from MJPG(47504a4d) to Y800(30303859)=96
zbar_negotiate_format: MJPG(47504a4d) -> Y800(30303859) (96)
zbar_negotiate_format: setting best format YUYV(56595559) (24)
v4l2_set_format: VIDIOC_S_FMT returned -1(16), trying interlaced...
ERROR: zbar video in v4l2_set_format():
system error: setting format 56595559 (VIDIOC_S_FMT): Device or resource busy (16)
zbar_processor_init: ERROR: no compatible video input format
ERROR: zbar processor in zbar_processor_init():
unsupported request: no compatible image format
ERROR: zbar processor in zbar_processor_init():
unsupported request: no compatible image format
   v4l2.patch (1.5 KiB)
This task depends upon

Closed by  Morten Linderud (Foxboron)
Saturday, 06 June 2020, 14:52 GMT
Reason for closing:  Not a bug
Comment by Alexander Blinne (Sunday) - Friday, 22 December 2017, 14:24 GMT
I have tested this patch and for me it resolves the issue.
I vote for including the patch in the package, as upstream does not seem to care about it and this problem has been around for years now.
Comment by Darrell (denns) - Saturday, 17 February 2018, 17:01 GMT
I have the same issue with a Realtek uvcvideo cam (USB ID 0bda:5650). It works perfectly with the patch. I agree that we should just patch it here. Upstream hasn't had any code pushed since 2012, and hasn't had any response on the ticket for this issue since 2015 (when a link was posted to this Arch ticket).
Comment by Nimrod Maclomhair (nimrod_mack) - Friday, 13 December 2019, 16:32 GMT
Soo apparently a new version of zbar (0.23), maintained by someone else over at GitHub is now used - and there, the patch seems to be already incorporated (I checked...) (So I guess this task can actually be closed...)

But unfortunately, I still get the problem: No video output with my Webcam, although barcode recognition works.

[Update] I figured out that my webcam driver doesn't support user pointer IO. So MMAP is used and that patch wouldn't help me...

Loading...