[Kernel-packages] [Bug 1938669] Re: Epiphan framegrabbers stream only once then need unbinding/rebinding to uvcvideo to work again
[Expired for linux (Ubuntu) because there has been no activity for 60 days.] ** Changed in: linux (Ubuntu) Status: Incomplete => Expired -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1938669 Title: Epiphan framegrabbers stream only once then need unbinding/rebinding to uvcvideo to work again Status in linux package in Ubuntu: Expired Bug description: Video capture devices made by Epiphan Systems (vendor id 0x2b77) work once, but as soon as the video device is closed (or even if it is kept open but the application issues a VIDIOC_STREAMOFF ioctl) it won't work again - subsequent calls to VIDOC_DQBUF simply hang - until the device is unbound from and rebound to the uvcvideo module. (modprobe -r uvcvideo; modprobe uvcvideo also works). For example: ffplay /dev/video0 -- works fine and shows the captured stream. ffplay /dev/video0 -- when run a second time: hangs and does not capture anything modprobe -r uvcvideo ; modprobe uvcvideo; ffplay /dev/video -- works fine again. Experimenting with the device and the uvcvideo module source code reveals that problem is the device is expecting SET_INTERFACE(0) to be sent to return it to a state where it can accept control requests and start streaming again. The code in uvc_video.c has several comments stating that some bulk- transfer devices require a SET_INTERFACE(0) call to be made before any control commands, even though 0 is already the default and only valid interface value. And, the function uvc_video_init makes such a call (which is why the device starts working again after rebinding to the uvcvideo module). But no such call is made when streaming is stopped then restarted. Furthermore, SET_INTERFACE(0) is the mechanism by which isochronous devices are told to stop streaming, and the comments in uvc_video_stop_streaming state that the UVC specification is unclear on how a bulk-based device should be told to stop streaming, so it is reasonable to expect this particular bulk-based device might be expecting the same SET_INTERFACE(0) call that an isochronous device would get as means of being told to stop streaming. The attached patch fixes the problem for these Epiphan devices by adding a SET_INTERFACE(0) call in two places. Either one by itself is sufficient to resolve the symptoms but I think it is probably safest to include both. The first hunk adds a SET_INTERFACE(0) call in uvc_video_start_streaming, but only in the bulk-based case where 0 is the only possible interface value (it won't mess with an isochronous device that might be set to a different interface). The second hunk modifies the behaviour of uvc_video_stop_streaming to call SET_INTERFACE(0) unconditionally instead of only calling it for isochronous devices. Since interface 0 should already be set on non- isochronous devices, it should be safe to set it again, and this way devices that are expecting it as a signal to stop streaming will get it. The patch is against 5.4.137 in the vanilla kernel.org source tree, but also applies cleanly to the 5.8.63 kernel in Ubuntu 20.4 LTS and to the 5.14-rc3 release candidate kernel. Since this is clearly an upstream issue unrelated to any vendor modifications, should I also submit an upstream bug report directly to bugzilla.kernel.org? To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1938669/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1938669] Re: Epiphan framegrabbers stream only once then need unbinding/rebinding to uvcvideo to work again
Thanks; I have done so, to the uvcvideo maintainer with copies to the media input maintainer, LKML and the linux-media mailing list, as indicated by the get_maintainer.pl script. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1938669 Title: Epiphan framegrabbers stream only once then need unbinding/rebinding to uvcvideo to work again Status in linux package in Ubuntu: New Bug description: Video capture devices made by Epiphan Systems (vendor id 0x2b77) work once, but as soon as the video device is closed (or even if it is kept open but the application issues a VIDIOC_STREAMOFF ioctl) it won't work again - subsequent calls to VIDOC_DQBUF simply hang - until the device is unbound from and rebound to the uvcvideo module. (modprobe -r uvcvideo; modprobe uvcvideo also works). For example: ffplay /dev/video0 -- works fine and shows the captured stream. ffplay /dev/video0 -- when run a second time: hangs and does not capture anything modprobe -r uvcvideo ; modprobe uvcvideo; ffplay /dev/video -- works fine again. Experimenting with the device and the uvcvideo module source code reveals that problem is the device is expecting SET_INTERFACE(0) to be sent to return it to a state where it can accept control requests and start streaming again. The code in uvc_video.c has several comments stating that some bulk- transfer devices require a SET_INTERFACE(0) call to be made before any control commands, even though 0 is already the default and only valid interface value. And, the function uvc_video_init makes such a call (which is why the device starts working again after rebinding to the uvcvideo module). But no such call is made when streaming is stopped then restarted. Furthermore, SET_INTERFACE(0) is the mechanism by which isochronous devices are told to stop streaming, and the comments in uvc_video_stop_streaming state that the UVC specification is unclear on how a bulk-based device should be told to stop streaming, so it is reasonable to expect this particular bulk-based device might be expecting the same SET_INTERFACE(0) call that an isochronous device would get as means of being told to stop streaming. The attached patch fixes the problem for these Epiphan devices by adding a SET_INTERFACE(0) call in two places. Either one by itself is sufficient to resolve the symptoms but I think it is probably safest to include both. The first hunk adds a SET_INTERFACE(0) call in uvc_video_start_streaming, but only in the bulk-based case where 0 is the only possible interface value (it won't mess with an isochronous device that might be set to a different interface). The second hunk modifies the behaviour of uvc_video_stop_streaming to call SET_INTERFACE(0) unconditionally instead of only calling it for isochronous devices. Since interface 0 should already be set on non- isochronous devices, it should be safe to set it again, and this way devices that are expecting it as a signal to stop streaming will get it. The patch is against 5.4.137 in the vanilla kernel.org source tree, but also applies cleanly to the 5.8.63 kernel in Ubuntu 20.4 LTS and to the 5.14-rc3 release candidate kernel. Since this is clearly an upstream issue unrelated to any vendor modifications, should I also submit an upstream bug report directly to bugzilla.kernel.org? To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1938669/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1938669] Re: Epiphan framegrabbers stream only once then need unbinding/rebinding to uvcvideo to work again
If possible, please send the patch to mailing list directly, that's the quickest way to get the patch merged. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1938669 Title: Epiphan framegrabbers stream only once then need unbinding/rebinding to uvcvideo to work again Status in linux package in Ubuntu: New Bug description: Video capture devices made by Epiphan Systems (vendor id 0x2b77) work once, but as soon as the video device is closed (or even if it is kept open but the application issues a VIDIOC_STREAMOFF ioctl) it won't work again - subsequent calls to VIDOC_DQBUF simply hang - until the device is unbound from and rebound to the uvcvideo module. (modprobe -r uvcvideo; modprobe uvcvideo also works). For example: ffplay /dev/video0 -- works fine and shows the captured stream. ffplay /dev/video0 -- when run a second time: hangs and does not capture anything modprobe -r uvcvideo ; modprobe uvcvideo; ffplay /dev/video -- works fine again. Experimenting with the device and the uvcvideo module source code reveals that problem is the device is expecting SET_INTERFACE(0) to be sent to return it to a state where it can accept control requests and start streaming again. The code in uvc_video.c has several comments stating that some bulk- transfer devices require a SET_INTERFACE(0) call to be made before any control commands, even though 0 is already the default and only valid interface value. And, the function uvc_video_init makes such a call (which is why the device starts working again after rebinding to the uvcvideo module). But no such call is made when streaming is stopped then restarted. Furthermore, SET_INTERFACE(0) is the mechanism by which isochronous devices are told to stop streaming, and the comments in uvc_video_stop_streaming state that the UVC specification is unclear on how a bulk-based device should be told to stop streaming, so it is reasonable to expect this particular bulk-based device might be expecting the same SET_INTERFACE(0) call that an isochronous device would get as means of being told to stop streaming. The attached patch fixes the problem for these Epiphan devices by adding a SET_INTERFACE(0) call in two places. Either one by itself is sufficient to resolve the symptoms but I think it is probably safest to include both. The first hunk adds a SET_INTERFACE(0) call in uvc_video_start_streaming, but only in the bulk-based case where 0 is the only possible interface value (it won't mess with an isochronous device that might be set to a different interface). The second hunk modifies the behaviour of uvc_video_stop_streaming to call SET_INTERFACE(0) unconditionally instead of only calling it for isochronous devices. Since interface 0 should already be set on non- isochronous devices, it should be safe to set it again, and this way devices that are expecting it as a signal to stop streaming will get it. The patch is against 5.4.137 in the vanilla kernel.org source tree, but also applies cleanly to the 5.8.63 kernel in Ubuntu 20.4 LTS and to the 5.14-rc3 release candidate kernel. Since this is clearly an upstream issue unrelated to any vendor modifications, should I also submit an upstream bug report directly to bugzilla.kernel.org? To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1938669/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1938669] Re: Epiphan framegrabbers stream only once then need unbinding/rebinding to uvcvideo to work again
** Tags added: patch -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1938669 Title: Epiphan framegrabbers stream only once then need unbinding/rebinding to uvcvideo to work again Status in linux package in Ubuntu: New Bug description: Video capture devices made by Epiphan Systems (vendor id 0x2b77) work once, but as soon as the video device is closed (or even if it is kept open but the application issues a VIDIOC_STREAMOFF ioctl) it won't work again - subsequent calls to VIDOC_DQBUF simply hang - until the device is unbound from and rebound to the uvcvideo module. (modprobe -r uvcvideo; modprobe uvcvideo also works). For example: ffplay /dev/video0 -- works fine and shows the captured stream. ffplay /dev/video0 -- when run a second time: hangs and does not capture anything modprobe -r uvcvideo ; modprobe uvcvideo; ffplay /dev/video -- works fine again. Experimenting with the device and the uvcvideo module source code reveals that problem is the device is expecting SET_INTERFACE(0) to be sent to return it to a state where it can accept control requests and start streaming again. The code in uvc_video.c has several comments stating that some bulk- transfer devices require a SET_INTERFACE(0) call to be made before any control commands, even though 0 is already the default and only valid interface value. And, the function uvc_video_init makes such a call (which is why the device starts working again after rebinding to the uvcvideo module). But no such call is made when streaming is stopped then restarted. Furthermore, SET_INTERFACE(0) is the mechanism by which isochronous devices are told to stop streaming, and the comments in uvc_video_stop_streaming state that the UVC specification is unclear on how a bulk-based device should be told to stop streaming, so it is reasonable to expect this particular bulk-based device might be expecting the same SET_INTERFACE(0) call that an isochronous device would get as means of being told to stop streaming. The attached patch fixes the problem for these Epiphan devices by adding a SET_INTERFACE(0) call in two places. Either one by itself is sufficient to resolve the symptoms but I think it is probably safest to include both. The first hunk adds a SET_INTERFACE(0) call in uvc_video_start_streaming, but only in the bulk-based case where 0 is the only possible interface value (it won't mess with an isochronous device that might be set to a different interface). The second hunk modifies the behaviour of uvc_video_stop_streaming to call SET_INTERFACE(0) unconditionally instead of only calling it for isochronous devices. Since interface 0 should already be set on non- isochronous devices, it should be safe to set it again, and this way devices that are expecting it as a signal to stop streaming will get it. The patch is against 5.4.137 in the vanilla kernel.org source tree, but also applies cleanly to the 5.8.63 kernel in Ubuntu 20.4 LTS and to the 5.14-rc3 release candidate kernel. Since this is clearly an upstream issue unrelated to any vendor modifications, should I also submit an upstream bug report directly to bugzilla.kernel.org? To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1938669/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
