On 5/3/2013 2:07 PM, Michael Grzeschik wrote:
Hi Laurent,
On Fri, May 03, 2013 at 01:20:15AM +0200, Laurent Pinchart wrote:
[snip]
I'm open to suggestions :-) What features of the userspace application do you
think could (and should) be moved to kernelspace ? Many of them are highly
application-specific.
All UVC_EVENTS beneath STREAMON and STREAMOFF could go into
the kernelspace. I have seen such codepath:
[1]
v4l2_event_queue /* kernelspace */
v4l2_event_dequeue /* kernelspace */
uvc_events_process_setup /* userspace */
uvc_events_process_class /* userspace */
uvc_events_process_streaming /* userspace */
uvc_fill_streaming_control /* userspace */
The codepath [1] is needed to respond with the possible supported
streaming capabilities. That information really should come from the
uvc_descriptor_header. We already have this information in the kernel,
there is no need for redundancy.
[2]
v4l2_event_queue /* kernelspace */
v4l2_event_dequeue /* kernelspace */
uvc_events_process_data /* userspace */
/* in case of UVC_VS_COMMIT_CONTROL */
uvc_video_set_format /* kernelspace */
uvc_v4l2_do_ioctl /* kernelspace */
The codepath [2] is really odd, as we jump out of the kernel back into
the kernel just to gather some information about the requested
videoformat by the host. The application itself should call the ioctl
VIDIOC_G_FMT on UVC_EVENT_STREAMON and change its videosetup likewise.
This should be possible with gstreamer. I currently work on an derived
version of the gstv4l2sink -> gstv4l2uvcsink to handle the uvc
specialities.
Well, its great that you are working on the 'gstv4l2uvcsink' plugin, as
the v4l2src and v4l2sink gstreamer pipeline doesn't work out of box of
UVC gadget. I have already burned by hands with it :)
That's why it I think the UVC gadget test application from Laurent is
really good starting point and as and when my patches related to the
same are added (see [1]) , it will be able to handle most of the
interaction required between a v4L2 based video capture device and UVC
v4L2 video
output device and even pass USBCV's USB video class tests.
[1]. [Test Application PATCH 0/2] UVC gadget test application enhancements.
http://comments.gmane.org/gmane.linux.usb.general/84813
And addressing the initial problem with the missing userspace application;
The gadget can loose its dependency to it, if the kernel would produce dummy
frames with the requested format and switch over to the real streaming data,
when opened.
I don't think dummy frames appearing at the very start of image data
would be much appreciated by a user using a real UVC webcam running
Linux. The user would expect real live data as soon as he issues a
START_STREAMING command from the USB host side.
And for completing doing away with the user-space application, you will
have to support the UVC default frame format always, but the user
ideally should not be restricted to default format and he can
start image capture in other possible image formats supported by
underlying video capture source.
This would mean we need to have dummy frames for each possible image
format and send the same to the Host until the actual streaming starts.
Wouldn't that be an overkill?
Regards,
Bhupesh
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
