jdonald / uvc-gadget Goto Github PK

UVC gadget test application Readme

Copyright (C) 2010 Ideas on board SPRL
Copyright (C) 2013 ST Microelectronics Ltd.

Contacts:
Laurent Pinchart <laurent.pinchart@xxxxxxxxxxxxxxxx>
Bhupesh Sharma <bhupesh.sharma@xxxxxx>

Introduction
============

This README file documents the UVC gadget test application available
here git://git.ideasonboard.org/uvc-gadget.git, which can be used to
test the UVC webcam gadget driver located under drivers/usb/gadget
directory.

Possible Use-Case scenarios
===========================

There can be a number of scenarios under which the UVC webcam gadget can
be used and each use-case can vary in the following ways:

- Video streaming endpoint choice:
  --------------------------------

  As per UVC specifications (Revision 1.1), either Bulk or Isochronous
  USB endpoints can be used are for implementing UVC Video streaming
  interface. Both have there unique challenges as:

	Isochronous video streaming interface will have two
	alt-settings:
		- Alt-setting 0 for zero-bandwidth mode, and
		- Alt-setting 1 for full-bandwidth mode.

	This requires us to ACK status stage of SET_ALT(alt-setting =
	1), only when we have video frames available which can be queued
	to UVC domain.

	Bulk video streaming interface, on the other hand will have only
	one alt-setting.

	This requires us to prepare UVC gadget for streaming when we
	receive a a UVC_VS_COMMIT_CONTROL command from USB host and
	actually start streaming as soon as we have video frames
	available which can be queued to UVC domain.

- Availability of a video capture device:
  ---------------------------------------

  To emulate a real UVC webcam gadget (capturing live video from a video
  capture source and sending it over USB bus), it is possible to
  integrate a V4L2 based video-capture device driver with the UVC gadget
  test application acting as an interface between the UVC based
  video-output device and V4L2 based video-capture device.
  
  Accordingly, there can be the following scenarios possible:

	- No video capture device available:

		In this case, there is no video capture device available
		and the UVC webcam gadget is working in an standalone
		environment.

		It is possible in this case to stream a dummy test
		pattern from the UVC webcam gadget and view the same on
		the Linux/Windows USB Host machine using standard video
		capture utilities like CHEESE.

	- VIVI (Virtual Video driver) acting as a video capture source:

		In case we don't have a real video capture hardware
		(e.g. sensor) available, it is still possible to
		exercise the complete path from the V4L2 based
		video-capture domain to UVC based video-output domain,
		using the Virtual Video driver (VIVI) available here:
		drivers/media/platform/vivi.c

		It is possible in this case to stream changing vertical
		color bar pattern pattern from the VIVI capture device
		and send it to UVC webcam gadget, which will eventually
		send these frames over USB bus.

		Similar to the case above, it is possible to view the
		frames on the Linux/Windows USB Host machine using
		standard video capture utilities like CHEESE.

	- Real video capture hardware and corresponding V4L2 driver
	  available:

		In this case, we have a real video capture hardware
		(e.g. CCD / CMOS sensor) available.

		Here, it is possible to exercise the complete path from
		the V4L2 based video-capture driver domain to UVC based
		video-output domain, using the UVC gadget test
		application.

		It is possible in this case to stream real video/still
		images from capture source and send it to UVC webcam
		gadget, which will eventually send these frames over USB
		bus.

- IO methods supported:
  --------------------

  V4L2 framework supports a number of IO methods and to achieve
  zero-memcpy of video frames as they pass from V4L2 video-capture
  domain to UVC video-output domain, it is important to select
  appropriate IO methods for working on videobuffers.

  Accordingly we can have the following scenarios possible:
  
	- UVC webcam standalone, supporting IO_METHOD_MMAP method:

		In this case, there is no video capture device available
		and the UVC webcam gadget is working in an standalone
		environment.

		It is supporting IO_MMAP method, which implies that the
		videobuffers are allocated by the UVC webcam gadget
		itself and they are filled with dummy test pattern by
		UVC gadget test application.

	- UVC webcam standalone, supporting IO_METHOD_USERPTR method:

		In this case, there is no video capture device available
		and the UVC webcam gadget is working in an standalone
		environment.

		It is supporting IO_METHOD_USERPTR method, which implies
		that the videobuffers are allocated and filled with
		dummy test pattern by the UVC gadget test application
		and UVC webcam gadget operates on a USERPTR of these
		videobuffers.

	- UVC webcam integrated with V4L2 video-capture driver, with
	  V4L2 video-capture driver supporting IO_METHOD_MMAP method and
	  UVC webcam supporting IO_METHOD_USERPTR:

		In this case, either VIVI or another V4L2 based driver
		(working on real HW) is available as a video capture
		device and is integrated with the UVC webcam gadget via
		UVC gadget test application, with V4L2 video-capture
		driver supporting IO_METHOD_MMAP method and UVC webcam
		supporting IO_METHOD_USERPTR.

		Here, the videobuffers are allocated in the V4L2
		video-capture domain and UVC gadget test application
		acts as a means to pass a USERPTR of these videobuffers
		to the UVC webcam gadget domain, without requiring any
		memcpy from the CPU.

	- UVC webcam integrated with V4L2 video-capture driver, with
	  V4L2 video-capture driver supporting IO_METHOD_USERPTR method
	  and UVC webcam supporting IO_METHOD_MMAP:

		In this case, either VIVI or another V4L2 based driver
		(working on real HW) is available as a video capture
		device and is integrated with the UVC webcam gadget via
		UVC gadget test application, with V4L2 video-capture
		driver supporting IO_METHOD_USERPTR method and UVC
		webcam supporting IO_METHOD_MMAP.

		Here, the videobuffers are allocated in the UVC webcam
		gadget domain and UVC gadget test application acts as a
		means to pass a USERPTR of these videobuffers to the
		V4L2 video-capture domain, without requiring any memcpy
		from the CPU.

Modifying UVC gadget test application
=====================================

The UVC webcam gadget kernel driver located under drivers/usb/gadget
directory and compilable as g_webcam.ko kernel module, supports 360p and
720p frame resolutions and YUV4:2:2 and MJPEG frame formats by default.

So, the video capture device must be aligned to support similar frame
format and resolutions.

In case the video capture device supports other resolutions and frame
formats, we need to replace the default values used in the UVC gadget
test application with the same and also update the UVC webcam gadget
kernel driver.

Keeping USBCV's UVC test-suite happy
====================================

The UVC webcam gadget kernel driver located under drivers/usb/gadget
directory and compilable as g_webcam.ko kernel module, supports changing
the Brightness attribute of the Processing Unit (PU) by default.

If the underlying video capture device supports changing the Brightness
attribute of the image being acquired (like the Virtual Video, VIVI
driver does), then we should route this UVC request to the respective
video capture device.

Incase, there is no actual video capture device associated with the UVC
gadget and we wish to use this application as the final destination of
the UVC specific requests then we should return pre-cooked (static)
responses to GET_CUR(BRIGHTNESS) and SET_CUR(BRIGHTNESS) commands to
keep command verifier test tools like UVC class specific test suite of
USBCV, happy.

Note that the values used in UVC gadget test application are in sync
with the VIVI driver and must be changed for your specific video capture
device. These values also work well in case there in no actual video
capture device.