Hi Michael, On Friday 03 May 2013 10:37:40 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. Those two code paths could indeed be moved to the kernel. I'm open to patches :-) One point to keep in mind is that format-specific processing (such as computing the dwMaxVideoFrameSize value) needs to be implemented in an extensible way to minimize required changes to the code when adding a new format. UVC-specific control events (uvc_events_process_control), however, still need to be processed in userspace. The current UVC gadget application ignores them, but in a real product they will need to be handled to control the video source. > This should be possible with gstreamer. I currently work on an derived > version of the gstv4l2sink -> gstv4l2uvcsink to handle the uvc > specialities. > > 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'm not too fond about that. The kernel driver would need to generate dummy frames in all supported formats, which can easily become an issue with M(J)PEG formats. Then, on the host side, applications might not expect dummy frames, as they could mess up the application logic (especially in case of automatic image processing). Moreover, even if we could generate dummy frames we would still have an issue with controls handling. -- Regards, Laurent Pinchart -- 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
