Date: Mon, 06 Apr 2020 19:37:08 +0000 From: bugzilla-noreply@freebsd.org To: multimedia@FreeBSD.org Subject: [Bug 236673] multimedia/gstreamer1-plugins-good 1.14.4: problem with v4l2src Message-ID: <bug-236673-12827-moyiOpSqz0@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-236673-12827@https.bugs.freebsd.org/bugzilla/> References: <bug-236673-12827@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236673 Christoph Moench-Tegeder <cmt@freebsd.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |cmt@freebsd.org --- Comment #2 from Christoph Moench-Tegeder <cmt@freebsd.org> --- Created attachment 213136 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=213136&action=edit catch EINVAL errno when probing DMA capabilities to be dropped into multimedia/gstreamer1-plugins-good/files/ (bump PORTREVISION on multimedia/gstreamer1-plugins-v4l2). poking at an old-ish Logitech C270 cam, I noticed the same problem ("Buffer pool activation failed" and camera not working in gstreamer-based applications). Working backwards through gstreamer and cuse) it became obvious that gstreamer probes the DMA capabilities of the device using ioctls, expecting ENOTTY (as it is customary when the request is not applicable to the object in question) in case DMA capabilities are not available. Unfortunately, FreeBSD's cuse returns EINVAL for this ioctl. As it's easier to fix the port than to fix the kernel: Here's the workaround, catching both ENOTTY and EINVAL on the DMA probing. With that, my camery works with gstreamer. -- You are receiving this mail because: You are the assignee for the bug.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-236673-12827-moyiOpSqz0>