--- /dev/null
+"cafe_ccic" is a driver for the Marvell 88ALP01 "cafe" CMOS camera
+controller. This is the controller found in first-generation OLPC systems,
+and this driver was written with support from the OLPC project.
+
+Current status: the core driver works. It can generate data in YUV422,
+RGB565, and RGB444 formats. (Anybody looking at the code will see RGB32 as
+well, but that is a debugging aid which will be removed shortly). VGA and
+QVGA modes work; CIF is there but the colors remain funky. Only the OV7670
+sensor is known to work with this controller at this time.
+
+To try it out: either of these commands will work:
+
+ mplayer tv:// -tv driver=v4l2:width=640:height=480 -nosound
+ mplayer tv:// -tv driver=v4l2:width=640:height=480:outfmt=bgr16 -nosound
+
+The "xawtv" utility also works; gqcam does not, for unknown reasons.
+
+There are a few load-time options, most of which can be changed after
+loading via sysfs as well:
+
+ - alloc_bufs_at_load: Normally, the driver will not allocate any DMA
+ buffers until the time comes to transfer data. If this option is set,
+ then worst-case-sized buffers will be allocated at module load time.
+ This option nails down the memory for the life of the module, but
+ perhaps decreases the chances of an allocation failure later on.
+
+ - dma_buf_size: The size of DMA buffers to allocate. Note that this
+ option is only consulted for load-time allocation; when buffers are
+ allocated at run time, they will be sized appropriately for the current
+ camera settings.
+
+ - n_dma_bufs: The controller can cycle through either two or three DMA
+ buffers. Normally, the driver tries to use three buffers; on faster
+ systems, however, it will work well with only two.
+
+ - min_buffers: The minimum number of streaming I/O buffers that the driver
+ will consent to work with. Default is one, but, on slower systems,
+ better behavior with mplayer can be achieved by setting to a higher
+ value (like six).
+
+ - max_buffers: The maximum number of streaming I/O buffers; default is
+ ten. That number was carefully picked out of a hat and should not be
+ assumed to actually mean much of anything.
+
+ - flip: If this boolean parameter is set, the sensor will be instructed to
+ invert the video image. Whether it makes sense is determined by how
+ your particular camera is mounted.
+
+Work is ongoing with this driver, stay tuned.
+
+jon
+
+Jonathan Corbet
+corbet@lwn.net
--- /dev/null
+$Id: README,v 1.7 2005/08/29 23:39:57 sbertin Exp $
+
+1. Introduction
+
+ This is a driver for STMicroelectronics's CPiA2 (second generation
+Colour Processor Interface ASIC) based cameras. This camera outputs an MJPEG
+stream at up to vga size. It implements the Video4Linux interface as much as
+possible. Since the V4L interface does not support compressed formats, only
+an mjpeg enabled application can be used with the camera. We have modified the
+gqcam application to view this stream.
+
+ The driver is implemented as two kernel modules. The cpia2 module
+contains the camera functions and the V4L interface. The cpia2_usb module
+contains usb specific functions. The main reason for this was the size of the
+module was getting out of hand, so I separated them. It is not likely that
+there will be a parallel port version.
+
+FEATURES:
+ - Supports cameras with the Vision stv6410 (CIF) and stv6500 (VGA) cmos
+ sensors. I only have the vga sensor, so can't test the other.
+ - Image formats: VGA, QVGA, CIF, QCIF, and a number of sizes in between.
+ VGA and QVGA are the native image sizes for the VGA camera. CIF is done
+ in the coprocessor by scaling QVGA. All other sizes are done by clipping.
+ - Palette: YCrCb, compressed with MJPEG.
+ - Some compression parameters are settable.
+ - Sensor framerate is adjustable (up to 30 fps CIF, 15 fps VGA).
+ - Adjust brightness, color, contrast while streaming.
+ - Flicker control settable for 50 or 60 Hz mains frequency.
+
+2. Making and installing the stv672 driver modules:
+
+ Requirements:
+ -------------
+ This should work with 2.4 (2.4.23 and later) and 2.6 kernels, but has
+only been tested on 2.6. Video4Linux must be either compiled into the kernel or
+available as a module. Video4Linux2 is automatically detected and made
+available at compile time.
+
+ Compiling:
+ ----------
+ As root, do a make install. This will compile and install the modules
+into the media/video directory in the module tree. For 2.4 kernels, use
+Makefile_2.4 (aka do make -f Makefile_2.4 install).
+
+ Setup:
+ ------
+ Use 'modprobe cpia2' to load and 'modprobe -r cpia2' to unload. This
+may be done automatically by your distribution.
+
+3. Driver options
+
+ Option Description
+ ------ -----------
+ video_nr video device to register (0=/dev/video0, etc)
+ range -1 to 64. default is -1 (first available)
+ If you have more than 1 camera, this MUST be -1.
+ buffer_size Size for each frame buffer in bytes (default 68k)
+ num_buffers Number of frame buffers (1-32, default 3)
+ alternate USB Alternate (2-7, default 7)
+ flicker_freq Frequency for flicker reduction(50 or 60, default 60)
+ flicker_mode 0 to disable, or 1 to enable flicker reduction.
+ (default 0). This is only effective if the camera
+ uses a stv0672 coprocessor.
+
+ Setting the options:
+ --------------------
+ If you are using modules, edit /etc/modules.conf and add an options
+line like this:
+ options cpia2 num_buffers=3 buffer_size=65535
+
+ If the driver is compiled into the kernel, at boot time specify them
+like this:
+ cpia2.num_buffers=3 cpia2.buffer_size=65535
+
+ What buffer size should I use?
+ ------------------------------
+ The maximum image size depends on the alternate you choose, and the
+frame rate achieved by the camera. If the compression engine is able to
+keep up with the frame rate, the maximum image size is given by the table
+below.
+ The compression engine starts out at maximum compression, and will
+increase image quality until it is close to the size in the table. As long
+as the compression engine can keep up with the frame rate, after a short time
+the images will all be about the size in the table, regardless of resolution.
+ At low alternate settings, the compression engine may not be able to
+compress the image enough and will reduce the frame rate by producing larger
+images.
+ The default of 68k should be good for most users. This will handle
+any alternate at frame rates down to 15fps. For lower frame rates, it may
+be necessary to increase the buffer size to avoid having frames dropped due
+to insufficient space.
+
+ Image size(bytes)
+ Alternate bytes/ms 15fps 30fps
+ 2 128 8533 4267
+ 3 384 25600 12800
+ 4 640 42667 21333
+ 5 768 51200 25600
+ 6 896 59733 29867
+ 7 1023 68200 34100
+
+ How many buffers should I use?
+ ------------------------------
+ For normal streaming, 3 should give the best results. With only 2,
+it is possible for the camera to finish sending one image just after a
+program has started reading the other. If this happens, the driver must drop
+a frame. The exception to this is if you have a heavily loaded machine. In
+this case use 2 buffers. You are probably not reading at the full frame rate.
+If the camera can send multiple images before a read finishes, it could
+overwrite the third buffer before the read finishes, leading to a corrupt
+image. Single and double buffering have extra checks to avoid overwriting.
+
+4. Using the camera
+
+ We are providing a modified gqcam application to view the output. In
+order to avoid confusion, here it is called mview. There is also the qx5view
+program which can also control the lights on the qx5 microscope. MJPEG Tools
+(http://mjpeg.sourceforge.net) can also be used to record from the camera.
+
+5. Notes to developers:
+
+ - This is a driver version stripped of the 2.4 back compatibility
+ and old MJPEG ioctl API. See cpia2.sf.net for 2.4 support.
+
+6. Thanks:
+
+ - Peter Pregler <Peter_Pregler@email.com>,
+ Scott J. Bertin <scottbertin@yahoo.com>, and
+ Jarl Totland <Jarl.Totland@bdc.no> for the original cpia driver, which
+ this one was modelled from.
--- /dev/null
+ Programmer's View of Cpia2
+
+Cpia2 is the second generation video coprocessor from VLSI Vision Ltd (now a
+division of ST Microelectronics). There are two versions. The first is the
+STV0672, which is capable of up to 30 frames per second (fps) in frame sizes
+up to CIF, and 15 fps for VGA frames. The STV0676 is an improved version,
+which can handle up to 30 fps VGA. Both coprocessors can be attached to two
+CMOS sensors - the vvl6410 CIF sensor and the vvl6500 VGA sensor. These will
+be referred to as the 410 and the 500 sensors, or the CIF and VGA sensors.
+
+The two chipsets operate almost identically. The core is an 8051 processor,
+running two different versions of firmware. The 672 runs the VP4 video
+processor code, the 676 runs VP5. There are a few differences in register
+mappings for the two chips. In these cases, the symbols defined in the
+header files are marked with VP4 or VP5 as part of the symbol name.
+
+The cameras appear externally as three sets of registers. Setting register
+values is the only way to control the camera. Some settings are
+interdependant, such as the sequence required to power up the camera. I will
+try to make note of all of these cases.
+
+The register sets are called blocks. Block 0 is the system block. This
+section is always powered on when the camera is plugged in. It contains
+registers that control housekeeping functions such as powering up the video
+processor. The video processor is the VP block. These registers control
+how the video from the sensor is processed. Examples are timing registers,
+user mode (vga, qvga), scaling, cropping, framerates, and so on. The last
+block is the video compressor (VC). The video stream sent from the camera is
+compressed as Motion JPEG (JPEGA). The VC controls all of the compression
+parameters. Looking at the file cpia2_registers.h, you can get a full view
+of these registers and the possible values for most of them.
+
+One or more registers can be set or read by sending a usb control message to
+the camera. There are three modes for this. Block mode requests a number
+of contiguous registers. Random mode reads or writes random registers with
+a tuple structure containing address/value pairs. The repeat mode is only
+used by VP4 to load a firmware patch. It contains a starting address and
+a sequence of bytes to be written into a gpio port.
--- /dev/null
+Some notes regarding the cx18 driver for the Conexant CX23418 MPEG
+encoder chip:
+
+1) Currently supported are:
+
+ - Hauppauge HVR-1600
+ - Compro VideoMate H900
+ - Yuan MPC718
+ - Conexant Raptor PAL/SECAM devkit
+
+2) Some people have problems getting the i2c bus to work.
+ The symptom is that the eeprom cannot be read and the card is
+ unusable. This is probably fixed, but if you have problems
+ then post to the video4linux or ivtv-users mailing list.
+
+3) VBI (raw or sliced) has not yet been implemented.
+
+4) MPEG indexing is not yet implemented.
+
+5) The driver is still a bit rough around the edges, this should
+ improve over time.
+
+
+Firmware:
+
+You can obtain the firmware files here:
+
+http://dl.ivtvdriver.org/ivtv/firmware/cx18-firmware.tar.gz
+
+Untar and copy the .fw files to your firmware directory.
--- /dev/null
+cx8800 release notes
+====================
+
+This is a v4l2 device driver for the cx2388x chip.
+
+
+current status
+==============
+
+video
+ - Basically works.
+ - For now, only capture and read(). Overlay isn't supported.
+
+audio
+ - The chip specs for the on-chip TV sound decoder are next
+ to useless :-/
+ - Neverless the builtin TV sound decoder starts working now,
+ at least for some standards.
+ FOR ANY REPORTS ON THIS PLEASE MENTION THE TV NORM YOU ARE
+ USING.
+ - Most tuner chips do provide mono sound, which may or may not
+ be useable depending on the board design. With the Hauppauge
+ cards it works, so there is mono sound available as fallback.
+ - audio data dma (i.e. recording without loopback cable to the
+ sound card) is supported via cx88-alsa.
+
+vbi
+ - Code present. Works for NTSC closed caption. PAL and other
+ TV norms may or may not work.
+
+
+how to add support for new cards
+================================
+
+The driver needs some config info for the TV cards. This stuff is in
+cx88-cards.c. If the driver doesn't work well you likely need a new
+entry for your card in that file. Check the kernel log (using dmesg)
+to see whenever the driver knows your card or not. There is a line
+like this one:
+
+ cx8800[0]: subsystem: 0070:3400, board: Hauppauge WinTV \
+ 34xxx models [card=1,autodetected]
+
+If your card is listed as "board: UNKNOWN/GENERIC" it is unknown to
+the driver. What to do then?
+
+ (1) Try upgrading to the latest snapshot, maybe it has been added
+ meanwhile.
+ (2) You can try to create a new entry yourself, have a look at
+ cx88-cards.c. If that worked, mail me your changes as unified
+ diff ("diff -u").
+ (3) Or you can mail me the config information. I need at least the
+ following information to add the card:
+
+ * the PCI Subsystem ID ("0070:3400" from the line above,
+ "lspci -v" output is fine too).
+ * the tuner type used by the card. You can try to find one by
+ trial-and-error using the tuner=<n> insmod option. If you
+ know which one the card has you can also have a look at the
+ list in CARDLIST.tuner
+
+Have fun,
+
+ Gerd
+
+--
+Gerd Knorr <kraxel@bytesex.org> [SuSE Labs]
--- /dev/null
+
+ VPBE V4L2 driver design
+ ======================================================================
+
+ File partitioning
+ -----------------
+ V4L2 display device driver
+ drivers/media/platform/davinci/vpbe_display.c
+ drivers/media/platform/davinci/vpbe_display.h
+
+ VPBE display controller
+ drivers/media/platform/davinci/vpbe.c
+ drivers/media/platform/davinci/vpbe.h
+
+ VPBE venc sub device driver
+ drivers/media/platform/davinci/vpbe_venc.c
+ drivers/media/platform/davinci/vpbe_venc.h
+ drivers/media/platform/davinci/vpbe_venc_regs.h
+
+ VPBE osd driver
+ drivers/media/platform/davinci/vpbe_osd.c
+ drivers/media/platform/davinci/vpbe_osd.h
+ drivers/media/platform/davinci/vpbe_osd_regs.h
+
+ Functional partitioning
+ -----------------------
+
+ Consists of the following (in the same order as the list under file
+ partitioning):-
+
+ 1. V4L2 display driver
+ Implements creation of video2 and video3 device nodes and
+ provides v4l2 device interface to manage VID0 and VID1 layers.
+
+ 2. Display controller
+ Loads up VENC, OSD and external encoders such as ths8200. It provides
+ a set of API calls to V4L2 drivers to set the output/standards
+ in the VENC or external sub devices. It also provides
+ a device object to access the services from OSD subdevice
+ using sub device ops. The connection of external encoders to VENC LCD
+ controller port is done at init time based on default output and standard
+ selection or at run time when application change the output through
+ V4L2 IOCTLs.
+
+ When connected to an external encoder, vpbe controller is also responsible
+ for setting up the interface between VENC and external encoders based on
+ board specific settings (specified in board-xxx-evm.c). This allows
+ interfacing external encoders such as ths8200. The setup_if_config()
+ is implemented for this as well as configure_venc() (part of the next patch)
+ API to set timings in VENC for a specific display resolution. As of this
+ patch series, the interconnection and enabling and setting of the external
+ encoders is not present, and would be a part of the next patch series.
+
+ 3. VENC subdevice module
+ Responsible for setting outputs provided through internal DACs and also
+ setting timings at LCD controller port when external encoders are connected
+ at the port or LCD panel timings required. When external encoder/LCD panel
+ is connected, the timings for a specific standard/preset is retrieved from
+ the board specific table and the values are used to set the timings in
+ venc using non-standard timing mode.
+
+ Support LCD Panel displays using the VENC. For example to support a Logic
+ PD display, it requires setting up the LCD controller port with a set of
+ timings for the resolution supported and setting the dot clock. So we could
+ add the available outputs as a board specific entry (i.e add the "LogicPD"
+ output name to board-xxx-evm.c). A table of timings for various LCDs
+ supported can be maintained in the board specific setup file to support
+ various LCD displays.As of this patch a basic driver is present, and this
+ support for external encoders and displays forms a part of the next
+ patch series.
+
+ 4. OSD module
+ OSD module implements all OSD layer management and hardware specific
+ features. The VPBE module interacts with the OSD for enabling and
+ disabling appropriate features of the OSD.
+
+ Current status:-
+
+ A fully functional working version of the V4L2 driver is available. This
+ driver has been tested with NTSC and PAL standards and buffer streaming.
+
+ Following are TBDs.
+
+ vpbe display controller
+ - Add support for external encoders.
+ - add support for selecting external encoder as default at probe time.
+
+ vpbe venc sub device
+ - add timings for supporting ths8200
+ - add support for LogicPD LCD.
+
+ FB drivers
+ - Add support for fbdev drivers.- Ready and part of subsequent patches.
--- /dev/null
+Samsung S5P/EXYNOS4 FIMC driver
+
+Copyright (C) 2012 - 2013 Samsung Electronics Co., Ltd.
+---------------------------------------------------------------------------
+
+The FIMC (Fully Interactive Mobile Camera) device available in Samsung
+SoC Application Processors is an integrated camera host interface, color
+space converter, image resizer and rotator. It's also capable of capturing
+data from LCD controller (FIMD) through the SoC internal writeback data
+path. There are multiple FIMC instances in the SoCs (up to 4), having
+slightly different capabilities, like pixel alignment constraints, rotator
+availability, LCD writeback support, etc. The driver is located at
+drivers/media/platform/exynos4-is directory.
+
+1. Supported SoCs
+=================
+
+S5PC100 (mem-to-mem only), S5PV210, EXYNOS4210
+
+2. Supported features
+=====================
+
+ - camera parallel interface capture (ITU-R.BT601/565);
+ - camera serial interface capture (MIPI-CSI2);
+ - memory-to-memory processing (color space conversion, scaling, mirror
+ and rotation);
+ - dynamic pipeline re-configuration at runtime (re-attachment of any FIMC
+ instance to any parallel video input or any MIPI-CSI front-end);
+ - runtime PM and system wide suspend/resume
+
+Not currently supported:
+ - LCD writeback input
+ - per frame clock gating (mem-to-mem)
+
+3. Files partitioning
+=====================
+
+- media device driver
+ drivers/media/platform/exynos4-is/media-dev.[ch]
+
+ - camera capture video device driver
+ drivers/media/platform/exynos4-is/fimc-capture.c
+
+ - MIPI-CSI2 receiver subdev
+ drivers/media/platform/exynos4-is/mipi-csis.[ch]
+
+ - video post-processor (mem-to-mem)
+ drivers/media/platform/exynos4-is/fimc-core.c
+
+ - common files
+ drivers/media/platform/exynos4-is/fimc-core.h
+ drivers/media/platform/exynos4-is/fimc-reg.h
+ drivers/media/platform/exynos4-is/regs-fimc.h
+
+4. User space interfaces
+========================
+
+4.1. Media device interface
+
+The driver supports Media Controller API as defined at
+https://linuxtv.org/downloads/v4l-dvb-apis/media_common.html
+The media device driver name is "SAMSUNG S5P FIMC".
+
+The purpose of this interface is to allow changing assignment of FIMC instances
+to the SoC peripheral camera input at runtime and optionally to control internal
+connections of the MIPI-CSIS device(s) to the FIMC entities.
+
+The media device interface allows to configure the SoC for capturing image
+data from the sensor through more than one FIMC instance (e.g. for simultaneous
+viewfinder and still capture setup).
+Reconfiguration is done by enabling/disabling media links created by the driver
+during initialization. The internal device topology can be easily discovered
+through media entity and links enumeration.
+
+4.2. Memory-to-memory video node
+
+V4L2 memory-to-memory interface at /dev/video? device node. This is standalone
+video device, it has no media pads. However please note the mem-to-mem and
+capture video node operation on same FIMC instance is not allowed. The driver
+detects such cases but the applications should prevent them to avoid an
+undefined behaviour.
+
+4.3. Capture video node
+
+The driver supports V4L2 Video Capture Interface as defined at:
+https://linuxtv.org/downloads/v4l-dvb-apis/devices.html
+
+At the capture and mem-to-mem video nodes only the multi-planar API is
+supported. For more details see:
+https://linuxtv.org/downloads/v4l-dvb-apis/planar-apis.html
+
+4.4. Camera capture subdevs
+
+Each FIMC instance exports a sub-device node (/dev/v4l-subdev?), a sub-device
+node is also created per each available and enabled at the platform level
+MIPI-CSI receiver device (currently up to two).
+
+4.5. sysfs
+
+In order to enable more precise camera pipeline control through the sub-device
+API the driver creates a sysfs entry associated with "s5p-fimc-md" platform
+device. The entry path is: /sys/platform/devices/s5p-fimc-md/subdev_conf_mode.
+
+In typical use case there could be a following capture pipeline configuration:
+sensor subdev -> mipi-csi subdev -> fimc subdev -> video node
+
+When we configure these devices through sub-device API at user space, the
+configuration flow must be from left to right, and the video node is
+configured as last one.
+When we don't use sub-device user space API the whole configuration of all
+devices belonging to the pipeline is done at the video node driver.
+The sysfs entry allows to instruct the capture node driver not to configure
+the sub-devices (format, crop), to avoid resetting the subdevs' configuration
+when the last configuration steps at the video node is performed.
+
+For full sub-device control support (subdevs configured at user space before
+starting streaming):
+# echo "sub-dev" > /sys/platform/devices/s5p-fimc-md/subdev_conf_mode
+
+For V4L2 video node control only (subdevs configured internally by the host
+driver):
+# echo "vid-dev" > /sys/platform/devices/s5p-fimc-md/subdev_conf_mode
+This is a default option.
+
+5. Device mapping to video and subdev device nodes
+==================================================
+
+There are associated two video device nodes with each device instance in
+hardware - video capture and mem-to-mem and additionally a subdev node for
+more precise FIMC capture subsystem control. In addition a separate v4l2
+sub-device node is created per each MIPI-CSIS device.
+
+How to find out which /dev/video? or /dev/v4l-subdev? is assigned to which
+device?
+
+You can either grep through the kernel log to find relevant information, i.e.
+# dmesg | grep -i fimc
+(note that udev, if present, might still have rearranged the video nodes),
+
+or retrieve the information from /dev/media? with help of the media-ctl tool:
+# media-ctl -p
+
+7. Build
+========
+
+If the driver is built as a loadable kernel module (CONFIG_VIDEO_SAMSUNG_S5P_FIMC=m)
+two modules are created (in addition to the core v4l2 modules): s5p-fimc.ko and
+optional s5p-csis.ko (MIPI-CSI receiver subdev).
--- /dev/null
+Guidelines for Linux4Linux pixel format 4CCs
+============================================
+
+Guidelines for Video4Linux 4CC codes defined using v4l2_fourcc() are
+specified in this document. First of the characters defines the nature of
+the pixel format, compression and colour space. The interpretation of the
+other three characters depends on the first one.
+
+Existing 4CCs may not obey these guidelines.
+
+Formats
+=======
+
+Raw bayer
+---------
+
+The following first characters are used by raw bayer formats:
+
+ B: raw bayer, uncompressed
+ b: raw bayer, DPCM compressed
+ a: A-law compressed
+ u: u-law compressed
+
+2nd character: pixel order
+ B: BGGR
+ G: GBRG
+ g: GRBG
+ R: RGGB
+
+3rd character: uncompressed bits-per-pixel 0--9, A--
+
+4th character: compressed bits-per-pixel 0--9, A--
--- /dev/null
+List of the webcams known by gspca.
+
+The modules are:
+ gspca_main main driver
+ gspca_xxxx subdriver module with xxxx as follows
+
+xxxx vend:prod
+----
+spca501 0000:0000 MystFromOri Unknown Camera
+spca508 0130:0130 Clone Digital Webcam 11043
+zc3xx 03f0:1b07 HP Premium Starter Cam
+m5602 0402:5602 ALi Video Camera Controller
+spca501 040a:0002 Kodak DVC-325
+spca500 040a:0300 Kodak EZ200
+zc3xx 041e:041e Creative WebCam Live!
+ov519 041e:4003 Video Blaster WebCam Go Plus
+spca500 041e:400a Creative PC-CAM 300
+sunplus 041e:400b Creative PC-CAM 600
+sunplus 041e:4012 PC-Cam350
+sunplus 041e:4013 Creative Pccam750
+zc3xx 041e:4017 Creative Webcam Mobile PD1090
+spca508 041e:4018 Creative Webcam Vista (PD1100)
+spca561 041e:401a Creative Webcam Vista (PD1100)
+zc3xx 041e:401c Creative NX
+spca505 041e:401d Creative Webcam NX ULTRA
+zc3xx 041e:401e Creative Nx Pro
+zc3xx 041e:401f Creative Webcam Notebook PD1171
+pac207 041e:4028 Creative Webcam Vista Plus
+zc3xx 041e:4029 Creative WebCam Vista Pro
+zc3xx 041e:4034 Creative Instant P0620
+zc3xx 041e:4035 Creative Instant P0620D
+zc3xx 041e:4036 Creative Live !
+sq930x 041e:4038 Creative Joy-IT
+zc3xx 041e:403a Creative Nx Pro 2
+spca561 041e:403b Creative Webcam Vista (VF0010)
+sq930x 041e:403c Creative Live! Ultra
+sq930x 041e:403d Creative Live! Ultra for Notebooks
+sq930x 041e:4041 Creative Live! Motion
+zc3xx 041e:4051 Creative Live!Cam Notebook Pro (VF0250)
+ov519 041e:4052 Creative Live! VISTA IM
+zc3xx 041e:4053 Creative Live!Cam Video IM
+vc032x 041e:405b Creative Live! Cam Notebook Ultra (VC0130)
+ov519 041e:405f Creative Live! VISTA VF0330
+ov519 041e:4060 Creative Live! VISTA VF0350
+ov519 041e:4061 Creative Live! VISTA VF0400
+ov519 041e:4064 Creative Live! VISTA VF0420
+ov519 041e:4067 Creative Live! Cam Video IM (VF0350)
+ov519 041e:4068 Creative Live! VISTA VF0470
+spca561 0458:7004 Genius VideoCAM Express V2
+sn9c2028 0458:7005 Genius Smart 300, version 2
+sunplus 0458:7006 Genius Dsc 1.3 Smart
+zc3xx 0458:7007 Genius VideoCam V2
+zc3xx 0458:700c Genius VideoCam V3
+zc3xx 0458:700f Genius VideoCam Web V2
+sonixj 0458:7025 Genius Eye 311Q
+sn9c20x 0458:7029 Genius Look 320s
+sonixj 0458:702e Genius Slim 310 NB
+sn9c20x 0458:7045 Genius Look 1320 V2
+sn9c20x 0458:704a Genius Slim 1320
+sn9c20x 0458:704c Genius i-Look 1321
+sn9c20x 045e:00f4 LifeCam VX-6000 (SN9C20x + OV9650)
+sonixj 045e:00f5 MicroSoft VX3000
+sonixj 045e:00f7 MicroSoft VX1000
+ov519 045e:028c Micro$oft xbox cam
+spca508 0461:0815 Micro Innovation IC200
+sunplus 0461:0821 Fujifilm MV-1
+zc3xx 0461:0a00 MicroInnovation WebCam320
+stv06xx 046d:0840 QuickCam Express
+stv06xx 046d:0850 LEGO cam / QuickCam Web
+stv06xx 046d:0870 Dexxa WebCam USB
+spca500 046d:0890 Logitech QuickCam traveler
+vc032x 046d:0892 Logitech Orbicam
+vc032x 046d:0896 Logitech Orbicam
+vc032x 046d:0897 Logitech QuickCam for Dell notebooks
+zc3xx 046d:089d Logitech QuickCam E2500
+zc3xx 046d:08a0 Logitech QC IM
+zc3xx 046d:08a1 Logitech QC IM 0x08A1 +sound
+zc3xx 046d:08a2 Labtec Webcam Pro
+zc3xx 046d:08a3 Logitech QC Chat
+zc3xx 046d:08a6 Logitech QCim
+zc3xx 046d:08a7 Logitech QuickCam Image
+zc3xx 046d:08a9 Logitech Notebook Deluxe
+zc3xx 046d:08aa Labtec Webcam Notebook
+zc3xx 046d:08ac Logitech QuickCam Cool
+zc3xx 046d:08ad Logitech QCCommunicate STX
+zc3xx 046d:08ae Logitech QuickCam for Notebooks
+zc3xx 046d:08af Logitech QuickCam Cool
+zc3xx 046d:08b9 Logitech QuickCam Express
+zc3xx 046d:08d7 Logitech QCam STX
+zc3xx 046d:08d9 Logitech QuickCam IM/Connect
+zc3xx 046d:08d8 Logitech Notebook Deluxe
+zc3xx 046d:08da Logitech QuickCam Messenger
+zc3xx 046d:08dd Logitech QuickCam for Notebooks
+spca500 046d:0900 Logitech Inc. ClickSmart 310
+spca500 046d:0901 Logitech Inc. ClickSmart 510
+sunplus 046d:0905 Logitech ClickSmart 820
+tv8532 046d:0920 Logitech QuickCam Express
+tv8532 046d:0921 Labtec Webcam
+spca561 046d:0928 Logitech QC Express Etch2
+spca561 046d:0929 Labtec Webcam Elch2
+spca561 046d:092a Logitech QC for Notebook
+spca561 046d:092b Labtec Webcam Plus
+spca561 046d:092c Logitech QC chat Elch2
+spca561 046d:092d Logitech QC Elch2
+spca561 046d:092e Logitech QC Elch2
+spca561 046d:092f Logitech QuickCam Express Plus
+sunplus 046d:0960 Logitech ClickSmart 420
+nw80x 046d:d001 Logitech QuickCam Pro (dark focus ring)
+sunplus 0471:0322 Philips DMVC1300K
+zc3xx 0471:0325 Philips SPC 200 NC
+zc3xx 0471:0326 Philips SPC 300 NC
+sonixj 0471:0327 Philips SPC 600 NC
+sonixj 0471:0328 Philips SPC 700 NC
+zc3xx 0471:032d Philips SPC 210 NC
+zc3xx 0471:032e Philips SPC 315 NC
+sonixj 0471:0330 Philips SPC 710 NC
+spca501 0497:c001 Smile International
+sunplus 04a5:3003 Benq DC 1300
+sunplus 04a5:3008 Benq DC 1500
+sunplus 04a5:300a Benq DC 3410
+spca500 04a5:300c Benq DC 1016
+benq 04a5:3035 Benq DC E300
+finepix 04cb:0104 Fujifilm FinePix 4800
+finepix 04cb:0109 Fujifilm FinePix A202
+finepix 04cb:010b Fujifilm FinePix A203
+finepix 04cb:010f Fujifilm FinePix A204
+finepix 04cb:0111 Fujifilm FinePix A205
+finepix 04cb:0113 Fujifilm FinePix A210
+finepix 04cb:0115 Fujifilm FinePix A303
+finepix 04cb:0117 Fujifilm FinePix A310
+finepix 04cb:0119 Fujifilm FinePix F401
+finepix 04cb:011b Fujifilm FinePix F402
+finepix 04cb:011d Fujifilm FinePix F410
+finepix 04cb:0121 Fujifilm FinePix F601
+finepix 04cb:0123 Fujifilm FinePix F700
+finepix 04cb:0125 Fujifilm FinePix M603
+finepix 04cb:0127 Fujifilm FinePix S300
+finepix 04cb:0129 Fujifilm FinePix S304
+finepix 04cb:012b Fujifilm FinePix S500
+finepix 04cb:012d Fujifilm FinePix S602
+finepix 04cb:012f Fujifilm FinePix S700
+finepix 04cb:0131 Fujifilm FinePix unknown model
+finepix 04cb:013b Fujifilm FinePix unknown model
+finepix 04cb:013d Fujifilm FinePix unknown model
+finepix 04cb:013f Fujifilm FinePix F420
+sunplus 04f1:1001 JVC GC A50
+spca561 04fc:0561 Flexcam 100
+spca1528 04fc:1528 Sunplus MD80 clone
+sunplus 04fc:500c Sunplus CA500C
+sunplus 04fc:504a Aiptek Mini PenCam 1.3
+sunplus 04fc:504b Maxell MaxPocket LE 1.3
+sunplus 04fc:5330 Digitrex 2110
+sunplus 04fc:5360 Sunplus Generic
+spca500 04fc:7333 PalmPixDC85
+sunplus 04fc:ffff Pure DigitalDakota
+nw80x 0502:d001 DVC V6
+spca501 0506:00df 3Com HomeConnect Lite
+sunplus 052b:1507 Megapixel 5 Pretec DC-1007
+sunplus 052b:1513 Megapix V4
+sunplus 052b:1803 MegaImage VI
+nw80x 052b:d001 EZCam Pro p35u
+tv8532 0545:808b Veo Stingray
+tv8532 0545:8333 Veo Stingray
+sunplus 0546:3155 Polaroid PDC3070
+sunplus 0546:3191 Polaroid Ion 80
+sunplus 0546:3273 Polaroid PDC2030
+ov519 054c:0154 Sonny toy4
+ov519 054c:0155 Sonny toy5
+cpia1 0553:0002 CPIA CPiA (version1) based cameras
+zc3xx 055f:c005 Mustek Wcam300A
+spca500 055f:c200 Mustek Gsmart 300
+sunplus 055f:c211 Kowa Bs888e Microcamera
+spca500 055f:c220 Gsmart Mini
+sunplus 055f:c230 Mustek Digicam 330K
+sunplus 055f:c232 Mustek MDC3500
+sunplus 055f:c360 Mustek DV4000 Mpeg4
+sunplus 055f:c420 Mustek gSmart Mini 2
+sunplus 055f:c430 Mustek Gsmart LCD 2
+sunplus 055f:c440 Mustek DV 3000
+sunplus 055f:c520 Mustek gSmart Mini 3
+sunplus 055f:c530 Mustek Gsmart LCD 3
+sunplus 055f:c540 Gsmart D30
+sunplus 055f:c630 Mustek MDC4000
+sunplus 055f:c650 Mustek MDC5500Z
+nw80x 055f:d001 Mustek Wcam 300 mini
+zc3xx 055f:d003 Mustek WCam300A
+zc3xx 055f:d004 Mustek WCam300 AN
+conex 0572:0041 Creative Notebook cx11646
+ov519 05a9:0511 Video Blaster WebCam 3/WebCam Plus, D-Link USB Digital Video Camera
+ov519 05a9:0518 Creative WebCam
+ov519 05a9:0519 OV519 Microphone
+ov519 05a9:0530 OmniVision
+ov534_9 05a9:1550 OmniVision VEHO Filmscanner
+ov519 05a9:2800 OmniVision SuperCAM
+ov519 05a9:4519 Webcam Classic
+ov534_9 05a9:8065 OmniVision test kit ov538+ov9712
+ov519 05a9:8519 OmniVision
+ov519 05a9:a511 D-Link USB Digital Video Camera
+ov519 05a9:a518 D-Link DSB-C310 Webcam
+sunplus 05da:1018 Digital Dream Enigma 1.3
+stk014 05e1:0893 Syntek DV4000
+gl860 05e3:0503 Genesys Logic PC Camera
+gl860 05e3:f191 Genesys Logic PC Camera
+spca561 060b:a001 Maxell Compact Pc PM3
+zc3xx 0698:2003 CTX M730V built in
+topro 06a2:0003 TP6800 PC Camera, CmoX CX0342 webcam
+topro 06a2:6810 Creative Qmax
+nw80x 06a5:0000 Typhoon Webcam 100 USB
+nw80x 06a5:d001 Divio based webcams
+nw80x 06a5:d800 Divio Chicony TwinkleCam, Trust SpaceCam
+spca500 06bd:0404 Agfa CL20
+spca500 06be:0800 Optimedia
+nw80x 06be:d001 EZCam Pro p35u
+sunplus 06d6:0031 Trust 610 LCD PowerC@m Zoom
+spca506 06e1:a190 ADS Instant VCD
+ov534 06f8:3002 Hercules Blog Webcam
+ov534_9 06f8:3003 Hercules Dualpix HD Weblog
+sonixj 06f8:3004 Hercules Classic Silver
+sonixj 06f8:3008 Hercules Deluxe Optical Glass
+pac7302 06f8:3009 Hercules Classic Link
+pac7302 06f8:301b Hercules Link
+nw80x 0728:d001 AVerMedia Camguard
+spca508 0733:0110 ViewQuest VQ110
+spca501 0733:0401 Intel Create and Share
+spca501 0733:0402 ViewQuest M318B
+spca505 0733:0430 Intel PC Camera Pro
+sunplus 0733:1311 Digital Dream Epsilon 1.3
+sunplus 0733:1314 Mercury 2.1MEG Deluxe Classic Cam
+sunplus 0733:2211 Jenoptik jdc 21 LCD
+sunplus 0733:2221 Mercury Digital Pro 3.1p
+sunplus 0733:3261 Concord 3045 spca536a
+sunplus 0733:3281 Cyberpix S550V
+spca506 0734:043b 3DeMon USB Capture aka
+cpia1 0813:0001 QX3 camera
+ov519 0813:0002 Dual Mode USB Camera Plus
+spca500 084d:0003 D-Link DSC-350
+spca500 08ca:0103 Aiptek PocketDV
+sunplus 08ca:0104 Aiptek PocketDVII 1.3
+sunplus 08ca:0106 Aiptek Pocket DV3100+
+mr97310a 08ca:0110 Trust Spyc@m 100
+mr97310a 08ca:0111 Aiptek PenCam VGA+
+sunplus 08ca:2008 Aiptek Mini PenCam 2 M
+sunplus 08ca:2010 Aiptek PocketCam 3M
+sunplus 08ca:2016 Aiptek PocketCam 2 Mega
+sunplus 08ca:2018 Aiptek Pencam SD 2M
+sunplus 08ca:2020 Aiptek Slim 3000F
+sunplus 08ca:2022 Aiptek Slim 3200
+sunplus 08ca:2024 Aiptek DV3500 Mpeg4
+sunplus 08ca:2028 Aiptek PocketCam4M
+sunplus 08ca:2040 Aiptek PocketDV4100M
+sunplus 08ca:2042 Aiptek PocketDV5100
+sunplus 08ca:2050 Medion MD 41437
+sunplus 08ca:2060 Aiptek PocketDV5300
+tv8532 0923:010f ICM532 cams
+mars 093a:050f Mars-Semi Pc-Camera
+mr97310a 093a:010e All known CIF cams with this ID
+mr97310a 093a:010f All known VGA cams with this ID
+pac207 093a:2460 Qtec Webcam 100
+pac207 093a:2461 HP Webcam
+pac207 093a:2463 Philips SPC 220 NC
+pac207 093a:2464 Labtec Webcam 1200
+pac207 093a:2468 Webcam WB-1400T
+pac207 093a:2470 Genius GF112
+pac207 093a:2471 Genius VideoCam ge111
+pac207 093a:2472 Genius VideoCam ge110
+pac207 093a:2474 Genius iLook 111
+pac207 093a:2476 Genius e-Messenger 112
+pac7311 093a:2600 PAC7311 Typhoon
+pac7311 093a:2601 Philips SPC 610 NC
+pac7311 093a:2603 Philips SPC 500 NC
+pac7311 093a:2608 Trust WB-3300p
+pac7311 093a:260e Gigaware VGA PC Camera, Trust WB-3350p, SIGMA cam 2350
+pac7311 093a:260f SnakeCam
+pac7302 093a:2620 Apollo AC-905
+pac7302 093a:2621 PAC731x
+pac7302 093a:2622 Genius Eye 312
+pac7302 093a:2624 PAC7302
+pac7302 093a:2625 Genius iSlim 310
+pac7302 093a:2626 Labtec 2200
+pac7302 093a:2627 Genius FaceCam 300
+pac7302 093a:2628 Genius iLook 300
+pac7302 093a:2629 Genious iSlim 300
+pac7302 093a:262a Webcam 300k
+pac7302 093a:262c Philips SPC 230 NC
+jl2005bcd 0979:0227 Various brands, 19 known cameras supported
+jeilinj 0979:0280 Sakar 57379
+jeilinj 0979:0280 Sportscam DV15
+zc3xx 0ac8:0302 Z-star Vimicro zc0302
+vc032x 0ac8:0321 Vimicro generic vc0321
+vc032x 0ac8:0323 Vimicro Vc0323
+vc032x 0ac8:0328 A4Tech PK-130MG
+zc3xx 0ac8:301b Z-Star zc301b
+zc3xx 0ac8:303b Vimicro 0x303b
+zc3xx 0ac8:305b Z-star Vimicro zc0305b
+zc3xx 0ac8:307b PC Camera (ZS0211)
+vc032x 0ac8:c001 Sony embedded vimicro
+vc032x 0ac8:c002 Sony embedded vimicro
+vc032x 0ac8:c301 Samsung Q1 Ultra Premium
+spca508 0af9:0010 Hama USB Sightcam 100
+spca508 0af9:0011 Hama USB Sightcam 100
+ov519 0b62:0059 iBOT2 Webcam
+sonixb 0c45:6001 Genius VideoCAM NB
+sonixb 0c45:6005 Microdia Sweex Mini Webcam
+sonixb 0c45:6007 Sonix sn9c101 + Tas5110D
+sonixb 0c45:6009 spcaCam@120
+sonixb 0c45:600d spcaCam@120
+sonixb 0c45:6011 Microdia PC Camera (SN9C102)
+sonixb 0c45:6019 Generic Sonix OV7630
+sonixb 0c45:6024 Generic Sonix Tas5130c
+sonixb 0c45:6025 Xcam Shanga
+sonixb 0c45:6028 Sonix Btc Pc380
+sonixb 0c45:6029 spcaCam@150
+sonixb 0c45:602c Generic Sonix OV7630
+sonixb 0c45:602d LIC-200 LG
+sonixb 0c45:602e Genius VideoCam Messenger
+sonixj 0c45:6040 Speed NVC 350K
+sonixj 0c45:607c Sonix sn9c102p Hv7131R
+sonixj 0c45:60c0 Sangha Sn535
+sonixj 0c45:60ce USB-PC-Camera-168 (TALK-5067)
+sonixj 0c45:60ec SN9C105+MO4000
+sonixj 0c45:60fb Surfer NoName
+sonixj 0c45:60fc LG-LIC300
+sonixj 0c45:60fe Microdia Audio
+sonixj 0c45:6100 PC Camera (SN9C128)
+sonixj 0c45:6102 PC Camera (SN9C128)
+sonixj 0c45:610a PC Camera (SN9C128)
+sonixj 0c45:610b PC Camera (SN9C128)
+sonixj 0c45:610c PC Camera (SN9C128)
+sonixj 0c45:610e PC Camera (SN9C128)
+sonixj 0c45:6128 Microdia/Sonix SNP325
+sonixj 0c45:612a Avant Camera
+sonixj 0c45:612b Speed-Link REFLECT2
+sonixj 0c45:612c Typhoon Rasy Cam 1.3MPix
+sonixj 0c45:6130 Sonix Pccam
+sonixj 0c45:6138 Sn9c120 Mo4000
+sonixj 0c45:613a Microdia Sonix PC Camera
+sonixj 0c45:613b Surfer SN-206
+sonixj 0c45:613c Sonix Pccam168
+sonixj 0c45:6142 Hama PC-Webcam AC-150
+sonixj 0c45:6143 Sonix Pccam168
+sonixj 0c45:6148 Digitus DA-70811/ZSMC USB PC Camera ZS211/Microdia
+sonixj 0c45:614a Frontech E-Ccam (JIL-2225)
+sn9c20x 0c45:6240 PC Camera (SN9C201 + MT9M001)
+sn9c20x 0c45:6242 PC Camera (SN9C201 + MT9M111)
+sn9c20x 0c45:6248 PC Camera (SN9C201 + OV9655)
+sn9c20x 0c45:624c PC Camera (SN9C201 + MT9M112)
+sn9c20x 0c45:624e PC Camera (SN9C201 + SOI968)
+sn9c20x 0c45:624f PC Camera (SN9C201 + OV9650)
+sn9c20x 0c45:6251 PC Camera (SN9C201 + OV9650)
+sn9c20x 0c45:6253 PC Camera (SN9C201 + OV9650)
+sn9c20x 0c45:6260 PC Camera (SN9C201 + OV7670)
+sn9c20x 0c45:6270 PC Camera (SN9C201 + MT9V011/MT9V111/MT9V112)
+sn9c20x 0c45:627b PC Camera (SN9C201 + OV7660)
+sn9c20x 0c45:627c PC Camera (SN9C201 + HV7131R)
+sn9c20x 0c45:627f PC Camera (SN9C201 + OV9650)
+sn9c20x 0c45:6280 PC Camera (SN9C202 + MT9M001)
+sn9c20x 0c45:6282 PC Camera (SN9C202 + MT9M111)
+sn9c20x 0c45:6288 PC Camera (SN9C202 + OV9655)
+sn9c20x 0c45:628c PC Camera (SN9C201 + MT9M112)
+sn9c20x 0c45:628e PC Camera (SN9C202 + SOI968)
+sn9c20x 0c45:628f PC Camera (SN9C202 + OV9650)
+sn9c20x 0c45:62a0 PC Camera (SN9C202 + OV7670)
+sn9c20x 0c45:62b0 PC Camera (SN9C202 + MT9V011/MT9V111/MT9V112)
+sn9c20x 0c45:62b3 PC Camera (SN9C202 + OV9655)
+sn9c20x 0c45:62bb PC Camera (SN9C202 + OV7660)
+sn9c20x 0c45:62bc PC Camera (SN9C202 + HV7131R)
+sn9c2028 0c45:8001 Wild Planet Digital Spy Camera
+sn9c2028 0c45:8003 Sakar #11199, #6637x, #67480 keychain cams
+sn9c2028 0c45:8008 Mini-Shotz ms-350
+sn9c2028 0c45:800a Vivitar Vivicam 3350B
+sunplus 0d64:0303 Sunplus FashionCam DXG
+ov519 0e96:c001 TRUST 380 USB2 SPACEC@M
+etoms 102c:6151 Qcam Sangha CIF
+etoms 102c:6251 Qcam xxxxxx VGA
+ov519 1046:9967 W9967CF/W9968CF WebCam IC, Video Blaster WebCam Go
+zc3xx 10fd:0128 Typhoon Webshot II USB 300k 0x0128
+spca561 10fd:7e50 FlyCam Usb 100
+zc3xx 10fd:8050 Typhoon Webshot II USB 300k
+ov534 1415:2000 Sony HD Eye for PS3 (SLEH 00201)
+pac207 145f:013a Trust WB-1300N
+sn9c20x 145f:013d Trust WB-3600R
+vc032x 15b8:6001 HP 2.0 Megapixel
+vc032x 15b8:6002 HP 2.0 Megapixel rz406aa
+spca501 1776:501c Arowana 300K CMOS Camera
+t613 17a1:0128 TASCORP JPEG Webcam, NGS Cyclops
+vc032x 17ef:4802 Lenovo Vc0323+MI1310_SOC
+pac207 2001:f115 D-Link DSB-C120
+sq905c 2770:9050 Disney pix micro (CIF)
+sq905c 2770:9051 Lego Bionicle
+sq905c 2770:9052 Disney pix micro 2 (VGA)
+sq905c 2770:905c All 11 known cameras with this ID
+sq905 2770:9120 All 24 known cameras with this ID
+sq905c 2770:913d All 4 known cameras with this ID
+sq930x 2770:930b Sweex Motion Tracking / I-Tec iCam Tracer
+sq930x 2770:930c Trust WB-3500T / NSG Robbie 2.0
+spca500 2899:012c Toptro Industrial
+ov519 8020:ef04 ov519
+spca508 8086:0110 Intel Easy PC Camera
+spca500 8086:0630 Intel Pocket PC Camera
+spca506 99fa:8988 Grandtec V.cap
+sn9c20x a168:0610 Dino-Lite Digital Microscope (SN9C201 + HV7131R)
+sn9c20x a168:0611 Dino-Lite Digital Microscope (SN9C201 + HV7131R)
+sn9c20x a168:0613 Dino-Lite Digital Microscope (SN9C201 + HV7131R)
+sn9c20x a168:0618 Dino-Lite Digital Microscope (SN9C201 + HV7131R)
+sn9c20x a168:0614 Dino-Lite Digital Microscope (SN9C201 + MT9M111)
+sn9c20x a168:0615 Dino-Lite Digital Microscope (SN9C201 + MT9M111)
+sn9c20x a168:0617 Dino-Lite Digital Microscope (SN9C201 + MT9M111)
+spca561 abcd:cdee Petcam
--- /dev/null
+
+ivtv release notes
+==================
+
+This is a v4l2 device driver for the Conexant cx23415/6 MPEG encoder/decoder.
+The cx23415 can do both encoding and decoding, the cx23416 can only do MPEG
+encoding. Currently the only card featuring full decoding support is the
+Hauppauge PVR-350.
+
+NOTE: this driver requires the latest encoder firmware (version 2.06.039, size
+376836 bytes). Get the firmware from here:
+
+http://dl.ivtvdriver.org/ivtv/firmware/
+
+NOTE: 'normal' TV applications do not work with this driver, you need
+an application that can handle MPEG input such as mplayer, xine, MythTV,
+etc.
+
+The primary goal of the IVTV project is to provide a "clean room" Linux
+Open Source driver implementation for video capture cards based on the
+iCompression iTVC15 or Conexant CX23415/CX23416 MPEG Codec.
+
+Features:
+ * Hardware mpeg2 capture of broadcast video (and sound) via the tuner or
+ S-Video/Composite and audio line-in.
+ * Hardware mpeg2 capture of FM radio where hardware support exists
+ * Supports NTSC, PAL, SECAM with stereo sound
+ * Supports SAP and bilingual transmissions.
+ * Supports raw VBI (closed captions and teletext).
+ * Supports sliced VBI (closed captions and teletext) and is able to insert
+ this into the captured MPEG stream.
+ * Supports raw YUV and PCM input.
+
+Additional features for the PVR-350 (CX23415 based):
+ * Provides hardware mpeg2 playback
+ * Provides comprehensive OSD (On Screen Display: ie. graphics overlaying the
+ video signal)
+ * Provides a framebuffer (allowing X applications to appear on the video
+ device)
+ * Supports raw YUV output.
+
+IMPORTANT: In case of problems first read this page:
+ http://www.ivtvdriver.org/index.php/Troubleshooting
+
+See also:
+
+Homepage + Wiki
+http://www.ivtvdriver.org
+
+IRC
+irc://irc.freenode.net/ivtv-dev
+
+----------------------------------------------------------
+
+Devices
+=======
+
+A maximum of 12 ivtv boards are allowed at the moment.
+
+Cards that don't have a video output capability (i.e. non PVR350 cards)
+lack the vbi8, vbi16, video16 and video48 devices. They also do not
+support the framebuffer device /dev/fbx for OSD.
+
+The radio0 device may or may not be present, depending on whether the
+card has a radio tuner or not.
+
+Here is a list of the base v4l devices:
+crw-rw---- 1 root video 81, 0 Jun 19 22:22 /dev/video0
+crw-rw---- 1 root video 81, 16 Jun 19 22:22 /dev/video16
+crw-rw---- 1 root video 81, 24 Jun 19 22:22 /dev/video24
+crw-rw---- 1 root video 81, 32 Jun 19 22:22 /dev/video32
+crw-rw---- 1 root video 81, 48 Jun 19 22:22 /dev/video48
+crw-rw---- 1 root video 81, 64 Jun 19 22:22 /dev/radio0
+crw-rw---- 1 root video 81, 224 Jun 19 22:22 /dev/vbi0
+crw-rw---- 1 root video 81, 228 Jun 19 22:22 /dev/vbi8
+crw-rw---- 1 root video 81, 232 Jun 19 22:22 /dev/vbi16
+
+Base devices
+============
+
+For every extra card you have the numbers increased by one. For example,
+/dev/video0 is listed as the 'base' encoding capture device so we have:
+
+ /dev/video0 is the encoding capture device for the first card (card 0)
+ /dev/video1 is the encoding capture device for the second card (card 1)
+ /dev/video2 is the encoding capture device for the third card (card 2)
+
+Note that if the first card doesn't have a feature (eg no decoder, so no
+video16, the second card will still use video17. The simple rule is 'add
+the card number to the base device number'. If you have other capture
+cards (e.g. WinTV PCI) that are detected first, then you have to tell
+the ivtv module about it so that it will start counting at 1 (or 2, or
+whatever). Otherwise the device numbers can get confusing. The ivtv
+'ivtv_first_minor' module option can be used for that.
+
+
+/dev/video0
+The encoding capture device(s).
+Read-only.
+
+Reading from this device gets you the MPEG1/2 program stream.
+Example:
+
+cat /dev/video0 > my.mpg (you need to hit ctrl-c to exit)
+
+
+/dev/video16
+The decoder output device(s)
+Write-only. Only present if the MPEG decoder (i.e. CX23415) exists.
+
+An mpeg2 stream sent to this device will appear on the selected video
+display, audio will appear on the line-out/audio out. It is only
+available for cards that support video out. Example:
+
+cat my.mpg >/dev/video16
+
+
+/dev/video24
+The raw audio capture device(s).
+Read-only
+
+The raw audio PCM stereo stream from the currently selected
+tuner or audio line-in. Reading from this device results in a raw
+(signed 16 bit Little Endian, 48000 Hz, stereo pcm) capture.
+This device only captures audio. This should be replaced by an ALSA
+device in the future.
+Note that there is no corresponding raw audio output device, this is
+not supported in the decoder firmware.
+
+
+/dev/video32
+The raw video capture device(s)
+Read-only
+
+The raw YUV video output from the current video input. The YUV format
+is non-standard (V4L2_PIX_FMT_HM12).
+
+Note that the YUV and PCM streams are not synchronized, so they are of
+limited use.
+
+
+/dev/video48
+The raw video display device(s)
+Write-only. Only present if the MPEG decoder (i.e. CX23415) exists.
+
+Writes a YUV stream to the decoder of the card.
+
+
+/dev/radio0
+The radio tuner device(s)
+Cannot be read or written.
+
+Used to enable the radio tuner and tune to a frequency. You cannot
+read or write audio streams with this device. Once you use this
+device to tune the radio, use /dev/video24 to read the raw pcm stream
+or /dev/video0 to get an mpeg2 stream with black video.
+
+
+/dev/vbi0
+The 'vertical blank interval' (Teletext, CC, WSS etc) capture device(s)
+Read-only
+
+Captures the raw (or sliced) video data sent during the Vertical Blank
+Interval. This data is used to encode teletext, closed captions, VPS,
+widescreen signalling, electronic program guide information, and other
+services.
+
+
+/dev/vbi8
+Processed vbi feedback device(s)
+Read-only. Only present if the MPEG decoder (i.e. CX23415) exists.
+
+The sliced VBI data embedded in an MPEG stream is reproduced on this
+device. So while playing back a recording on /dev/video16, you can
+read the embedded VBI data from /dev/vbi8.
+
+
+/dev/vbi16
+The vbi 'display' device(s)
+Write-only. Only present if the MPEG decoder (i.e. CX23415) exists.
+
+Can be used to send sliced VBI data to the video-out connector.
+
+---------------------------------
+
+Hans Verkuil <hverkuil@xs4all.nl>
--- /dev/null
+Vaio Picturebook Motion Eye Camera Driver Readme
+------------------------------------------------
+ Copyright (C) 2001-2004 Stelian Pop <stelian@popies.net>
+ Copyright (C) 2001-2002 Alcôve <www.alcove.com>
+ Copyright (C) 2000 Andrew Tridgell <tridge@samba.org>
+
+This driver enable the use of video4linux compatible applications with the
+Motion Eye camera. This driver requires the "Sony Laptop Extras" driver (which
+can be found in the "Misc devices" section of the kernel configuration utility)
+to be compiled and installed (using its "camera=1" parameter).
+
+It can do at maximum 30 fps @ 320x240 or 15 fps @ 640x480.
+
+Grabbing is supported in packed YUV colorspace only.
+
+MJPEG hardware grabbing is supported via a private API (see below).
+
+Hardware supported:
+-------------------
+
+This driver supports the 'second' version of the MotionEye camera :)
+
+The first version was connected directly on the video bus of the Neomagic
+video card and is unsupported.
+
+The second one, made by Kawasaki Steel is fully supported by this
+driver (PCI vendor/device is 0x136b/0xff01)
+
+The third one, present in recent (more or less last year) Picturebooks
+(C1M* models), is not supported. The manufacturer has given the specs
+to the developers under a NDA (which allows the development of a GPL
+driver however), but things are not moving very fast (see
+http://r-engine.sourceforge.net/) (PCI vendor/device is 0x10cf/0x2011).
+
+There is a forth model connected on the USB bus in TR1* Vaio laptops.
+This camera is not supported at all by the current driver, in fact
+little information if any is available for this camera
+(USB vendor/device is 0x054c/0x0107).
+
+Driver options:
+---------------
+
+Several options can be passed to the meye driver using the standard
+module argument syntax (<param>=<value> when passing the option to the
+module or meye.<param>=<value> on the kernel boot line when meye is
+statically linked into the kernel). Those options are:
+
+ gbuffers: number of capture buffers, default is 2 (32 max)
+
+ gbufsize: size of each capture buffer, default is 614400
+
+ video_nr: video device to register (0 = /dev/video0, etc)
+
+Module use:
+-----------
+
+In order to automatically load the meye module on use, you can put those lines
+in your /etc/modprobe.d/meye.conf file:
+
+ alias char-major-81 videodev
+ alias char-major-81-0 meye
+ options meye gbuffers=32
+
+Usage:
+------
+
+ xawtv >= 3.49 (<http://bytesex.org/xawtv/>)
+ for display and uncompressed video capture:
+
+ xawtv -c /dev/video0 -geometry 640x480
+ or
+ xawtv -c /dev/video0 -geometry 320x240
+
+ motioneye (<http://popies.net/meye/>)
+ for getting ppm or jpg snapshots, mjpeg video
+
+Private API:
+------------
+
+ The driver supports frame grabbing with the video4linux API,
+ so all video4linux tools (like xawtv) should work with this driver.
+
+ Besides the video4linux interface, the driver has a private interface
+ for accessing the Motion Eye extended parameters (camera sharpness,
+ agc, video framerate), the shapshot and the MJPEG capture facilities.
+
+ This interface consists of several ioctls (prototypes and structures
+ can be found in include/linux/meye.h):
+
+ MEYEIOC_G_PARAMS
+ MEYEIOC_S_PARAMS
+ Get and set the extended parameters of the motion eye camera.
+ The user should always query the current parameters with
+ MEYEIOC_G_PARAMS, change what he likes and then issue the
+ MEYEIOC_S_PARAMS call (checking for -EINVAL). The extended
+ parameters are described by the meye_params structure.
+
+
+ MEYEIOC_QBUF_CAPT
+ Queue a buffer for capture (the buffers must have been
+ obtained with a VIDIOCGMBUF call and mmap'ed by the
+ application). The argument to MEYEIOC_QBUF_CAPT is the
+ buffer number to queue (or -1 to end capture). The first
+ call to MEYEIOC_QBUF_CAPT starts the streaming capture.
+
+ MEYEIOC_SYNC
+ Takes as an argument the buffer number you want to sync.
+ This ioctl blocks until the buffer is filled and ready
+ for the application to use. It returns the buffer size.
+
+ MEYEIOC_STILLCAPT
+ MEYEIOC_STILLJCAPT
+ Takes a snapshot in an uncompressed or compressed jpeg format.
+ This ioctl blocks until the snapshot is done and returns (for
+ jpeg snapshot) the size of the image. The image data is
+ available from the first mmap'ed buffer.
+
+ Look at the 'motioneye' application code for an actual example.
+
+Bugs / Todo:
+------------
+
+ - 'motioneye' still uses the meye private v4l1 API extensions.
--- /dev/null
+OMAP 3 Image Signal Processor (ISP) driver
+
+Copyright (C) 2010 Nokia Corporation
+Copyright (C) 2009 Texas Instruments, Inc.
+
+Contacts: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
+ Sakari Ailus <sakari.ailus@iki.fi>
+ David Cohen <dacohen@gmail.com>
+
+
+Introduction
+============
+
+This file documents the Texas Instruments OMAP 3 Image Signal Processor (ISP)
+driver located under drivers/media/platform/omap3isp. The original driver was
+written by Texas Instruments but since that it has been rewritten (twice) at
+Nokia.
+
+The driver has been successfully used on the following versions of OMAP 3:
+
+ 3430
+ 3530
+ 3630
+
+The driver implements V4L2, Media controller and v4l2_subdev interfaces.
+Sensor, lens and flash drivers using the v4l2_subdev interface in the kernel
+are supported.
+
+
+Split to subdevs
+================
+
+The OMAP 3 ISP is split into V4L2 subdevs, each of the blocks inside the ISP
+having one subdev to represent it. Each of the subdevs provide a V4L2 subdev
+interface to userspace.
+
+ OMAP3 ISP CCP2
+ OMAP3 ISP CSI2a
+ OMAP3 ISP CCDC
+ OMAP3 ISP preview
+ OMAP3 ISP resizer
+ OMAP3 ISP AEWB
+ OMAP3 ISP AF
+ OMAP3 ISP histogram
+
+Each possible link in the ISP is modelled by a link in the Media controller
+interface. For an example program see [2].
+
+
+Controlling the OMAP 3 ISP
+==========================
+
+In general, the settings given to the OMAP 3 ISP take effect at the beginning
+of the following frame. This is done when the module becomes idle during the
+vertical blanking period on the sensor. In memory-to-memory operation the pipe
+is run one frame at a time. Applying the settings is done between the frames.
+
+All the blocks in the ISP, excluding the CSI-2 and possibly the CCP2 receiver,
+insist on receiving complete frames. Sensors must thus never send the ISP
+partial frames.
+
+Autoidle does have issues with some ISP blocks on the 3430, at least.
+Autoidle is only enabled on 3630 when the omap3isp module parameter autoidle
+is non-zero.
+
+
+Events
+======
+
+The OMAP 3 ISP driver does support the V4L2 event interface on CCDC and
+statistics (AEWB, AF and histogram) subdevs.
+
+The CCDC subdev produces V4L2_EVENT_FRAME_SYNC type event on HS_VS
+interrupt which is used to signal frame start. Earlier version of this
+driver used V4L2_EVENT_OMAP3ISP_HS_VS for this purpose. The event is
+triggered exactly when the reception of the first line of the frame starts
+in the CCDC module. The event can be subscribed on the CCDC subdev.
+
+(When using parallel interface one must pay account to correct configuration
+of the VS signal polarity. This is automatically correct when using the serial
+receivers.)
+
+Each of the statistics subdevs is able to produce events. An event is
+generated whenever a statistics buffer can be dequeued by a user space
+application using the VIDIOC_OMAP3ISP_STAT_REQ IOCTL. The events available
+are:
+
+ V4L2_EVENT_OMAP3ISP_AEWB
+ V4L2_EVENT_OMAP3ISP_AF
+ V4L2_EVENT_OMAP3ISP_HIST
+
+The type of the event data is struct omap3isp_stat_event_status for these
+ioctls. If there is an error calculating the statistics, there will be an
+event as usual, but no related statistics buffer. In this case
+omap3isp_stat_event_status.buf_err is set to non-zero.
+
+
+Private IOCTLs
+==============
+
+The OMAP 3 ISP driver supports standard V4L2 IOCTLs and controls where
+possible and practical. Much of the functions provided by the ISP, however,
+does not fall under the standard IOCTLs --- gamma tables and configuration of
+statistics collection are examples of such.
+
+In general, there is a private ioctl for configuring each of the blocks
+containing hardware-dependent functions.
+
+The following private IOCTLs are supported:
+
+ VIDIOC_OMAP3ISP_CCDC_CFG
+ VIDIOC_OMAP3ISP_PRV_CFG
+ VIDIOC_OMAP3ISP_AEWB_CFG
+ VIDIOC_OMAP3ISP_HIST_CFG
+ VIDIOC_OMAP3ISP_AF_CFG
+ VIDIOC_OMAP3ISP_STAT_REQ
+ VIDIOC_OMAP3ISP_STAT_EN
+
+The parameter structures used by these ioctls are described in
+include/linux/omap3isp.h. The detailed functions of the ISP itself related to
+a given ISP block is described in the Technical Reference Manuals (TRMs) ---
+see the end of the document for those.
+
+While it is possible to use the ISP driver without any use of these private
+IOCTLs it is not possible to obtain optimal image quality this way. The AEWB,
+AF and histogram modules cannot be used without configuring them using the
+appropriate private IOCTLs.
+
+
+CCDC and preview block IOCTLs
+=============================
+
+The VIDIOC_OMAP3ISP_CCDC_CFG and VIDIOC_OMAP3ISP_PRV_CFG IOCTLs are used to
+configure, enable and disable functions in the CCDC and preview blocks,
+respectively. Both IOCTLs control several functions in the blocks they
+control. VIDIOC_OMAP3ISP_CCDC_CFG IOCTL accepts a pointer to struct
+omap3isp_ccdc_update_config as its argument. Similarly VIDIOC_OMAP3ISP_PRV_CFG
+accepts a pointer to struct omap3isp_prev_update_config. The definition of
+both structures is available in [1].
+
+The update field in the structures tells whether to update the configuration
+for the specific function and the flag tells whether to enable or disable the
+function.
+
+The update and flag bit masks accept the following values. Each separate
+functions in the CCDC and preview blocks is associated with a flag (either
+disable or enable; part of the flag field in the structure) and a pointer to
+configuration data for the function.
+
+Valid values for the update and flag fields are listed here for
+VIDIOC_OMAP3ISP_CCDC_CFG. Values may be or'ed to configure more than one
+function in the same IOCTL call.
+
+ OMAP3ISP_CCDC_ALAW
+ OMAP3ISP_CCDC_LPF
+ OMAP3ISP_CCDC_BLCLAMP
+ OMAP3ISP_CCDC_BCOMP
+ OMAP3ISP_CCDC_FPC
+ OMAP3ISP_CCDC_CULL
+ OMAP3ISP_CCDC_CONFIG_LSC
+ OMAP3ISP_CCDC_TBL_LSC
+
+The corresponding values for the VIDIOC_OMAP3ISP_PRV_CFG are here:
+
+ OMAP3ISP_PREV_LUMAENH
+ OMAP3ISP_PREV_INVALAW
+ OMAP3ISP_PREV_HRZ_MED
+ OMAP3ISP_PREV_CFA
+ OMAP3ISP_PREV_CHROMA_SUPP
+ OMAP3ISP_PREV_WB
+ OMAP3ISP_PREV_BLKADJ
+ OMAP3ISP_PREV_RGB2RGB
+ OMAP3ISP_PREV_COLOR_CONV
+ OMAP3ISP_PREV_YC_LIMIT
+ OMAP3ISP_PREV_DEFECT_COR
+ OMAP3ISP_PREV_GAMMABYPASS
+ OMAP3ISP_PREV_DRK_FRM_CAPTURE
+ OMAP3ISP_PREV_DRK_FRM_SUBTRACT
+ OMAP3ISP_PREV_LENS_SHADING
+ OMAP3ISP_PREV_NF
+ OMAP3ISP_PREV_GAMMA
+
+The associated configuration pointer for the function may not be NULL when
+enabling the function. When disabling a function the configuration pointer is
+ignored.
+
+
+Statistic blocks IOCTLs
+=======================
+
+The statistics subdevs do offer more dynamic configuration options than the
+other subdevs. They can be enabled, disable and reconfigured when the pipeline
+is in streaming state.
+
+The statistics blocks always get the input image data from the CCDC (as the
+histogram memory read isn't implemented). The statistics are dequeueable by
+the user from the statistics subdev nodes using private IOCTLs.
+
+The private IOCTLs offered by the AEWB, AF and histogram subdevs are heavily
+reflected by the register level interface offered by the ISP hardware. There
+are aspects that are purely related to the driver implementation and these are
+discussed next.
+
+VIDIOC_OMAP3ISP_STAT_EN
+-----------------------
+
+This private IOCTL enables/disables a statistic module. If this request is
+done before streaming, it will take effect as soon as the pipeline starts to
+stream. If the pipeline is already streaming, it will take effect as soon as
+the CCDC becomes idle.
+
+VIDIOC_OMAP3ISP_AEWB_CFG, VIDIOC_OMAP3ISP_HIST_CFG and VIDIOC_OMAP3ISP_AF_CFG
+-----------------------------------------------------------------------------
+
+Those IOCTLs are used to configure the modules. They require user applications
+to have an in-depth knowledge of the hardware. Most of the fields explanation
+can be found on OMAP's TRMs. The two following fields common to all the above
+configure private IOCTLs require explanation for better understanding as they
+are not part of the TRM.
+
+omap3isp_[h3a_af/h3a_aewb/hist]_config.buf_size:
+
+The modules handle their buffers internally. The necessary buffer size for the
+module's data output depends on the requested configuration. Although the
+driver supports reconfiguration while streaming, it does not support a
+reconfiguration which requires bigger buffer size than what is already
+internally allocated if the module is enabled. It will return -EBUSY on this
+case. In order to avoid such condition, either disable/reconfigure/enable the
+module or request the necessary buffer size during the first configuration
+while the module is disabled.
+
+The internal buffer size allocation considers the requested configuration's
+minimum buffer size and the value set on buf_size field. If buf_size field is
+out of [minimum, maximum] buffer size range, it's clamped to fit in there.
+The driver then selects the biggest value. The corrected buf_size value is
+written back to user application.
+
+omap3isp_[h3a_af/h3a_aewb/hist]_config.config_counter:
+
+As the configuration doesn't take effect synchronously to the request, the
+driver must provide a way to track this information to provide more accurate
+data. After a configuration is requested, the config_counter returned to user
+space application will be an unique value associated to that request. When
+user application receives an event for buffer availability or when a new
+buffer is requested, this config_counter is used to match a buffer data and a
+configuration.
+
+VIDIOC_OMAP3ISP_STAT_REQ
+------------------------
+
+Send to user space the oldest data available in the internal buffer queue and
+discards such buffer afterwards. The field omap3isp_stat_data.frame_number
+matches with the video buffer's field_count.
+
+
+Technical reference manuals (TRMs) and other documentation
+==========================================================
+
+OMAP 3430 TRM:
+<URL:http://focus.ti.com/pdfs/wtbu/OMAP34xx_ES3.1.x_PUBLIC_TRM_vZM.zip>
+Referenced 2011-03-05.
+
+OMAP 35xx TRM:
+<URL:http://www.ti.com/litv/pdf/spruf98o> Referenced 2011-03-05.
+
+OMAP 3630 TRM:
+<URL:http://focus.ti.com/pdfs/wtbu/OMAP36xx_ES1.x_PUBLIC_TRM_vQ.zip>
+Referenced 2011-03-05.
+
+DM 3730 TRM:
+<URL:http://www.ti.com/litv/pdf/sprugn4h> Referenced 2011-03-06.
+
+
+References
+==========
+
+[1] include/linux/omap3isp.h
+
+[2] http://git.ideasonboard.org/?p=media-ctl.git;a=summary
--- /dev/null
+ OMAP4 ISS Driver
+ ================
+
+Introduction
+------------
+
+The OMAP44XX family of chips contains the Imaging SubSystem (a.k.a. ISS),
+Which contains several components that can be categorized in 3 big groups:
+
+- Interfaces (2 Interfaces: CSI2-A & CSI2-B/CCP2)
+- ISP (Image Signal Processor)
+- SIMCOP (Still Image Coprocessor)
+
+For more information, please look in [1] for latest version of:
+ "OMAP4430 Multimedia Device Silicon Revision 2.x"
+
+As of Revision AB, the ISS is described in detail in section 8.
+
+This driver is supporting _only_ the CSI2-A/B interfaces for now.
+
+It makes use of the Media Controller framework [2], and inherited most of the
+code from OMAP3 ISP driver (found under drivers/media/platform/omap3isp/*),
+except that it doesn't need an IOMMU now for ISS buffers memory mapping.
+
+Supports usage of MMAP buffers only (for now).
+
+Tested platforms
+----------------
+
+- OMAP4430SDP, w/ ES2.1 GP & SEVM4430-CAM-V1-0 (Contains IMX060 & OV5640, in
+ which only the last one is supported, outputting YUV422 frames).
+
+- TI Blaze MDP, w/ OMAP4430 ES2.2 EMU (Contains 1 IMX060 & 2 OV5650 sensors, in
+ which only the OV5650 are supported, outputting RAW10 frames).
+
+- PandaBoard, Rev. A2, w/ OMAP4430 ES2.1 GP & OV adapter board, tested with
+ following sensors:
+ * OV5640
+ * OV5650
+
+- Tested on mainline kernel:
+
+ http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=summary
+
+ Tag: v3.3 (commit c16fa4f2ad19908a47c63d8fa436a1178438c7e7)
+
+File list
+---------
+drivers/staging/media/omap4iss/
+include/linux/platform_data/media/omap4iss.h
+
+References
+----------
+
+[1] http://focus.ti.com/general/docs/wtbu/wtbudocumentcenter.tsp?navigationId=12037&templateId=6123#62
+[2] http://lwn.net/Articles/420485/
+[3] http://www.spinics.net/lists/linux-media/msg44370.html
+--
+Author: Sergio Aguirre <sergio.a.aguirre@gmail.com>
+Copyright (C) 2012, Texas Instruments
--- /dev/null
+
+$Id$
+Mike Isely <isely@pobox.com>
+
+ pvrusb2 driver
+
+Background:
+
+ This driver is intended for the "Hauppauge WinTV PVR USB 2.0", which
+ is a USB 2.0 hosted TV Tuner. This driver is a work in progress.
+ Its history started with the reverse-engineering effort by Björn
+ Danielsson <pvrusb2@dax.nu> whose web page can be found here:
+
+ http://pvrusb2.dax.nu/
+
+ From there Aurelien Alleaume <slts@free.fr> began an effort to
+ create a video4linux compatible driver. I began with Aurelien's
+ last known snapshot and evolved the driver to the state it is in
+ here.
+
+ More information on this driver can be found at:
+
+ http://www.isely.net/pvrusb2.html
+
+
+ This driver has a strong separation of layers. They are very
+ roughly:
+
+ 1a. Low level wire-protocol implementation with the device.
+
+ 1b. I2C adaptor implementation and corresponding I2C client drivers
+ implemented elsewhere in V4L.
+
+ 1c. High level hardware driver implementation which coordinates all
+ activities that ensure correct operation of the device.
+
+ 2. A "context" layer which manages instancing of driver, setup,
+ tear-down, arbitration, and interaction with high level
+ interfaces appropriately as devices are hotplugged in the
+ system.
+
+ 3. High level interfaces which glue the driver to various published
+ Linux APIs (V4L, sysfs, maybe DVB in the future).
+
+ The most important shearing layer is between the top 2 layers. A
+ lot of work went into the driver to ensure that any kind of
+ conceivable API can be laid on top of the core driver. (Yes, the
+ driver internally leverages V4L to do its work but that really has
+ nothing to do with the API published by the driver to the outside
+ world.) The architecture allows for different APIs to
+ simultaneously access the driver. I have a strong sense of fairness
+ about APIs and also feel that it is a good design principle to keep
+ implementation and interface isolated from each other. Thus while
+ right now the V4L high level interface is the most complete, the
+ sysfs high level interface will work equally well for similar
+ functions, and there's no reason I see right now why it shouldn't be
+ possible to produce a DVB high level interface that can sit right
+ alongside V4L.
+
+ NOTE: Complete documentation on the pvrusb2 driver is contained in
+ the html files within the doc directory; these are exactly the same
+ as what is on the web site at the time. Browse those files
+ (especially the FAQ) before asking questions.
+
+
+Building
+
+ To build these modules essentially amounts to just running "Make",
+ but you need the kernel source tree nearby and you will likely also
+ want to set a few controlling environment variables first in order
+ to link things up with that source tree. Please see the Makefile
+ here for comments that explain how to do that.
+
+
+Source file list / functional overview:
+
+ (Note: The term "module" used below generally refers to loosely
+ defined functional units within the pvrusb2 driver and bears no
+ relation to the Linux kernel's concept of a loadable module.)
+
+ pvrusb2-audio.[ch] - This is glue logic that resides between this
+ driver and the msp3400.ko I2C client driver (which is found
+ elsewhere in V4L).
+
+ pvrusb2-context.[ch] - This module implements the context for an
+ instance of the driver. Everything else eventually ties back to
+ or is otherwise instanced within the data structures implemented
+ here. Hotplugging is ultimately coordinated here. All high level
+ interfaces tie into the driver through this module. This module
+ helps arbitrate each interface's access to the actual driver core,
+ and is designed to allow concurrent access through multiple
+ instances of multiple interfaces (thus you can for example change
+ the tuner's frequency through sysfs while simultaneously streaming
+ video through V4L out to an instance of mplayer).
+
+ pvrusb2-debug.h - This header defines a printk() wrapper and a mask
+ of debugging bit definitions for the various kinds of debug
+ messages that can be enabled within the driver.
+
+ pvrusb2-debugifc.[ch] - This module implements a crude command line
+ oriented debug interface into the driver. Aside from being part
+ of the process for implementing manual firmware extraction (see
+ the pvrusb2 web site mentioned earlier), probably I'm the only one
+ who has ever used this. It is mainly a debugging aid.
+
+ pvrusb2-eeprom.[ch] - This is glue logic that resides between this
+ driver the tveeprom.ko module, which is itself implemented
+ elsewhere in V4L.
+
+ pvrusb2-encoder.[ch] - This module implements all protocol needed to
+ interact with the Conexant mpeg2 encoder chip within the pvrusb2
+ device. It is a crude echo of corresponding logic in ivtv,
+ however the design goals (strict isolation) and physical layer
+ (proxy through USB instead of PCI) are enough different that this
+ implementation had to be completely different.
+
+ pvrusb2-hdw-internal.h - This header defines the core data structure
+ in the driver used to track ALL internal state related to control
+ of the hardware. Nobody outside of the core hardware-handling
+ modules should have any business using this header. All external
+ access to the driver should be through one of the high level
+ interfaces (e.g. V4L, sysfs, etc), and in fact even those high
+ level interfaces are restricted to the API defined in
+ pvrusb2-hdw.h and NOT this header.
+
+ pvrusb2-hdw.h - This header defines the full internal API for
+ controlling the hardware. High level interfaces (e.g. V4L, sysfs)
+ will work through here.
+
+ pvrusb2-hdw.c - This module implements all the various bits of logic
+ that handle overall control of a specific pvrusb2 device.
+ (Policy, instantiation, and arbitration of pvrusb2 devices fall
+ within the jurisdiction of pvrusb-context not here).
+
+ pvrusb2-i2c-chips-*.c - These modules implement the glue logic to
+ tie together and configure various I2C modules as they attach to
+ the I2C bus. There are two versions of this file. The "v4l2"
+ version is intended to be used in-tree alongside V4L, where we
+ implement just the logic that makes sense for a pure V4L
+ environment. The "all" version is intended for use outside of
+ V4L, where we might encounter other possibly "challenging" modules
+ from ivtv or older kernel snapshots (or even the support modules
+ in the standalone snapshot).
+
+ pvrusb2-i2c-cmd-v4l1.[ch] - This module implements generic V4L1
+ compatible commands to the I2C modules. It is here where state
+ changes inside the pvrusb2 driver are translated into V4L1
+ commands that are in turn send to the various I2C modules.
+
+ pvrusb2-i2c-cmd-v4l2.[ch] - This module implements generic V4L2
+ compatible commands to the I2C modules. It is here where state
+ changes inside the pvrusb2 driver are translated into V4L2
+ commands that are in turn send to the various I2C modules.
+
+ pvrusb2-i2c-core.[ch] - This module provides an implementation of a
+ kernel-friendly I2C adaptor driver, through which other external
+ I2C client drivers (e.g. msp3400, tuner, lirc) may connect and
+ operate corresponding chips within the pvrusb2 device. It is
+ through here that other V4L modules can reach into this driver to
+ operate specific pieces (and those modules are in turn driven by
+ glue logic which is coordinated by pvrusb2-hdw, doled out by
+ pvrusb2-context, and then ultimately made available to users
+ through one of the high level interfaces).
+
+ pvrusb2-io.[ch] - This module implements a very low level ring of
+ transfer buffers, required in order to stream data from the
+ device. This module is *very* low level. It only operates the
+ buffers and makes no attempt to define any policy or mechanism for
+ how such buffers might be used.
+
+ pvrusb2-ioread.[ch] - This module layers on top of pvrusb2-io.[ch]
+ to provide a streaming API usable by a read() system call style of
+ I/O. Right now this is the only layer on top of pvrusb2-io.[ch],
+ however the underlying architecture here was intended to allow for
+ other styles of I/O to be implemented with additional modules, like
+ mmap()'ed buffers or something even more exotic.
+
+ pvrusb2-main.c - This is the top level of the driver. Module level
+ and USB core entry points are here. This is our "main".
+
+ pvrusb2-sysfs.[ch] - This is the high level interface which ties the
+ pvrusb2 driver into sysfs. Through this interface you can do
+ everything with the driver except actually stream data.
+
+ pvrusb2-tuner.[ch] - This is glue logic that resides between this
+ driver and the tuner.ko I2C client driver (which is found
+ elsewhere in V4L).
+
+ pvrusb2-util.h - This header defines some common macros used
+ throughout the driver. These macros are not really specific to
+ the driver, but they had to go somewhere.
+
+ pvrusb2-v4l2.[ch] - This is the high level interface which ties the
+ pvrusb2 driver into video4linux. It is through here that V4L
+ applications can open and operate the driver in the usual V4L
+ ways. Note that **ALL** V4L functionality is published only
+ through here and nowhere else.
+
+ pvrusb2-video-*.[ch] - This is glue logic that resides between this
+ driver and the saa711x.ko I2C client driver (which is found
+ elsewhere in V4L). Note that saa711x.ko used to be known as
+ saa7115.ko in ivtv. There are two versions of this; one is
+ selected depending on the particular saa711[5x].ko that is found.
+
+ pvrusb2.h - This header contains compile time tunable parameters
+ (and at the moment the driver has very little that needs to be
+ tuned).
+
+
+ -Mike Isely
+ isely@pobox.com
+
--- /dev/null
+ PXA-Camera Host Driver
+ ======================
+
+Constraints
+-----------
+ a) Image size for YUV422P format
+ All YUV422P images are enforced to have width x height % 16 = 0.
+ This is due to DMA constraints, which transfers only planes of 8 byte
+ multiples.
+
+
+Global video workflow
+---------------------
+ a) QCI stopped
+ Initialy, the QCI interface is stopped.
+ When a buffer is queued (pxa_videobuf_ops->buf_queue), the QCI starts.
+
+ b) QCI started
+ More buffers can be queued while the QCI is started without halting the
+ capture. The new buffers are "appended" at the tail of the DMA chain, and
+ smoothly captured one frame after the other.
+
+ Once a buffer is filled in the QCI interface, it is marked as "DONE" and
+ removed from the active buffers list. It can be then requeud or dequeued by
+ userland application.
+
+ Once the last buffer is filled in, the QCI interface stops.
+
+ c) Capture global finite state machine schema
+
+ +----+ +---+ +----+
+ | DQ | | Q | | DQ |
+ | v | v | v
+ +-----------+ +------------------------+
+ | STOP | | Wait for capture start |
+ +-----------+ Q +------------------------+
++-> | QCI: stop | ------------------> | QCI: run | <------------+
+| | DMA: stop | | DMA: stop | |
+| +-----------+ +-----> +------------------------+ |
+| / | |
+| / +---+ +----+ | |
+|capture list empty / | Q | | DQ | | QCI Irq EOF |
+| / | v | v v |
+| +--------------------+ +----------------------+ |
+| | DMA hotlink missed | | Capture running | |
+| +--------------------+ +----------------------+ |
+| | QCI: run | +-----> | QCI: run | <-+ |
+| | DMA: stop | / | DMA: run | | |
+| +--------------------+ / +----------------------+ | Other |
+| ^ /DMA still | | channels |
+| | capture list / running | DMA Irq End | not |
+| | not empty / | | finished |
+| | / v | yet |
+| +----------------------+ +----------------------+ | |
+| | Videobuf released | | Channel completed | | |
+| +----------------------+ +----------------------+ | |
++-- | QCI: run | | QCI: run | --+ |
+ | DMA: run | | DMA: run | |
+ +----------------------+ +----------------------+ |
+ ^ / | |
+ | no overrun / | overrun |
+ | / v |
+ +--------------------+ / +----------------------+ |
+ | Frame completed | / | Frame overran | |
+ +--------------------+ <-----+ +----------------------+ restart frame |
+ | QCI: run | | QCI: stop | --------------+
+ | DMA: run | | DMA: stop |
+ +--------------------+ +----------------------+
+
+ Legend: - each box is a FSM state
+ - each arrow is the condition to transition to another state
+ - an arrow with a comment is a mandatory transition (no condition)
+ - arrow "Q" means : a buffer was enqueued
+ - arrow "DQ" means : a buffer was dequeued
+ - "QCI: stop" means the QCI interface is not enabled
+ - "DMA: stop" means all 3 DMA channels are stopped
+ - "DMA: run" means at least 1 DMA channel is still running
+
+DMA usage
+---------
+ a) DMA flow
+ - first buffer queued for capture
+ Once a first buffer is queued for capture, the QCI is started, but data
+ transfer is not started. On "End Of Frame" interrupt, the irq handler
+ starts the DMA chain.
+ - capture of one videobuffer
+ The DMA chain starts transferring data into videobuffer RAM pages.
+ When all pages are transferred, the DMA irq is raised on "ENDINTR" status
+ - finishing one videobuffer
+ The DMA irq handler marks the videobuffer as "done", and removes it from
+ the active running queue
+ Meanwhile, the next videobuffer (if there is one), is transferred by DMA
+ - finishing the last videobuffer
+ On the DMA irq of the last videobuffer, the QCI is stopped.
+
+ b) DMA prepared buffer will have this structure
+
+ +------------+-----+---------------+-----------------+
+ | desc-sg[0] | ... | desc-sg[last] | finisher/linker |
+ +------------+-----+---------------+-----------------+
+
+ This structure is pointed by dma->sg_cpu.
+ The descriptors are used as follows :
+ - desc-sg[i]: i-th descriptor, transferring the i-th sg
+ element to the video buffer scatter gather
+ - finisher: has ddadr=DADDR_STOP, dcmd=ENDIRQEN
+ - linker: has ddadr= desc-sg[0] of next video buffer, dcmd=0
+
+ For the next schema, let's assume d0=desc-sg[0] .. dN=desc-sg[N],
+ "f" stands for finisher and "l" for linker.
+ A typical running chain is :
+
+ Videobuffer 1 Videobuffer 2
+ +---------+----+---+ +----+----+----+---+
+ | d0 | .. | dN | l | | d0 | .. | dN | f |
+ +---------+----+-|-+ ^----+----+----+---+
+ | |
+ +----+
+
+ After the chaining is finished, the chain looks like :
+
+ Videobuffer 1 Videobuffer 2 Videobuffer 3
+ +---------+----+---+ +----+----+----+---+ +----+----+----+---+
+ | d0 | .. | dN | l | | d0 | .. | dN | l | | d0 | .. | dN | f |
+ +---------+----+-|-+ ^----+----+----+-|-+ ^----+----+----+---+
+ | | | |
+ +----+ +----+
+ new_link
+
+ c) DMA hot chaining timeslice issue
+
+ As DMA chaining is done while DMA _is_ running, the linking may be done
+ while the DMA jumps from one Videobuffer to another. On the schema, that
+ would be a problem if the following sequence is encountered :
+
+ - DMA chain is Videobuffer1 + Videobuffer2
+ - pxa_videobuf_queue() is called to queue Videobuffer3
+ - DMA controller finishes Videobuffer2, and DMA stops
+ =>
+ Videobuffer 1 Videobuffer 2
+ +---------+----+---+ +----+----+----+---+
+ | d0 | .. | dN | l | | d0 | .. | dN | f |
+ +---------+----+-|-+ ^----+----+----+-^-+
+ | | |
+ +----+ +-- DMA DDADR loads DDADR_STOP
+
+ - pxa_dma_add_tail_buf() is called, the Videobuffer2 "finisher" is
+ replaced by a "linker" to Videobuffer3 (creation of new_link)
+ - pxa_videobuf_queue() finishes
+ - the DMA irq handler is called, which terminates Videobuffer2
+ - Videobuffer3 capture is not scheduled on DMA chain (as it stopped !!!)
+
+ Videobuffer 1 Videobuffer 2 Videobuffer 3
+ +---------+----+---+ +----+----+----+---+ +----+----+----+---+
+ | d0 | .. | dN | l | | d0 | .. | dN | l | | d0 | .. | dN | f |
+ +---------+----+-|-+ ^----+----+----+-|-+ ^----+----+----+---+
+ | | | |
+ +----+ +----+
+ new_link
+ DMA DDADR still is DDADR_STOP
+
+ - pxa_camera_check_link_miss() is called
+ This checks if the DMA is finished and a buffer is still on the
+ pcdev->capture list. If that's the case, the capture will be restarted,
+ and Videobuffer3 is scheduled on DMA chain.
+ - the DMA irq handler finishes
+
+ Note: if DMA stops just after pxa_camera_check_link_miss() reads DDADR()
+ value, we have the guarantee that the DMA irq handler will be called back
+ when the DMA will finish the buffer, and pxa_camera_check_link_miss() will
+ be called again, to reschedule Videobuffer3.
+
+--
+Author: Robert Jarzmik <robert.jarzmik@free.fr>
--- /dev/null
+NOTES ON RADIOTRACK CARD CONTROL
+by Stephen M. Benoit (benoits@servicepro.com) Dec 14, 1996
+----------------------------------------------------------------------------
+
+Document version 1.0
+
+ACKNOWLEDGMENTS
+----------------
+This document was made based on 'C' code for Linux from Gideon le Grange
+(legrang@active.co.za or legrang@cs.sun.ac.za) in 1994, and elaborations from
+Frans Brinkman (brinkman@esd.nl) in 1996. The results reported here are from
+experiments that the author performed on his own setup, so your mileage may
+vary... I make no guarantees, claims or warranties to the suitability or
+validity of this information. No other documentation on the AIMS
+Lab (http://www.aimslab.com/) RadioTrack card was made available to the
+author. This document is offered in the hopes that it might help users who
+want to use the RadioTrack card in an environment other than MS Windows.
+
+WHY THIS DOCUMENT?
+------------------
+I have a RadioTrack card from back when I ran an MS-Windows platform. After
+converting to Linux, I found Gideon le Grange's command-line software for
+running the card, and found that it was good! Frans Brinkman made a
+comfortable X-windows interface, and added a scanning feature. For hack
+value, I wanted to see if the tuner could be tuned beyond the usual FM radio
+broadcast band, so I could pick up the audio carriers from North American
+broadcast TV channels, situated just below and above the 87.0-109.0 MHz range.
+I did not get much success, but I learned about programming ioports under
+Linux and gained some insights about the hardware design used for the card.
+
+So, without further delay, here are the details.
+
+
+PHYSICAL DESCRIPTION
+--------------------
+The RadioTrack card is an ISA 8-bit FM radio card. The radio frequency (RF)
+input is simply an antenna lead, and the output is a power audio signal
+available through a miniature phone plug. Its RF frequencies of operation are
+more or less limited from 87.0 to 109.0 MHz (the commercial FM broadcast
+band). Although the registers can be programmed to request frequencies beyond
+these limits, experiments did not give promising results. The variable
+frequency oscillator (VFO) that demodulates the intermediate frequency (IF)
+signal probably has a small range of useful frequencies, and wraps around or
+gets clipped beyond the limits mentioned above.
+
+
+CONTROLLING THE CARD WITH IOPORT
+--------------------------------
+The RadioTrack (base) ioport is configurable for 0x30c or 0x20c. Only one
+ioport seems to be involved. The ioport decoding circuitry must be pretty
+simple, as individual ioport bits are directly matched to specific functions
+(or blocks) of the radio card. This way, many functions can be changed in
+parallel with one write to the ioport. The only feedback available through
+the ioports appears to be the "Stereo Detect" bit.
+
+The bits of the ioport are arranged as follows:
+
+ MSb LSb
++------+------+------+--------+--------+-------+---------+--------+
+| VolA | VolB | ???? | Stereo | Radio | TuneA | TuneB | Tune |
+| (+) | (-) | | Detect | Audio | (bit) | (latch) | Update |
+| | | | Enable | Enable | | | Enable |
++------+------+------+--------+--------+-------+---------+--------+
+
+
+VolA . VolB [AB......]
+-----------
+0 0 : audio mute
+0 1 : volume + (some delay required)
+1 0 : volume - (some delay required)
+1 1 : stay at present volume
+
+Stereo Detect Enable [...S....]
+--------------------
+0 : No Detect
+1 : Detect
+
+ Results available by reading ioport >60 msec after last port write.
+ 0xff ==> no stereo detected, 0xfd ==> stereo detected.
+
+Radio to Audio (path) Enable [....R...]
+----------------------------
+0 : Disable path (silence)
+1 : Enable path (audio produced)
+
+TuneA . TuneB [.....AB.]
+-------------
+0 0 : "zero" bit phase 1
+0 1 : "zero" bit phase 2
+
+1 0 : "one" bit phase 1
+1 1 : "one" bit phase 2
+
+ 24-bit code, where bits = (freq*40) + 10486188.
+ The Most Significant 11 bits must be 1010 xxxx 0x0 to be valid.
+ The bits are shifted in LSb first.
+
+Tune Update Enable [.......T]
+------------------
+0 : Tuner held constant
+1 : Tuner updating in progress
+
+
+PROGRAMMING EXAMPLES
+--------------------
+Default: BASE <-- 0xc8 (current volume, no stereo detect,
+ radio enable, tuner adjust disable)
+
+Card Off: BASE <-- 0x00 (audio mute, no stereo detect,
+ radio disable, tuner adjust disable)
+
+Card On: BASE <-- 0x00 (see "Card Off", clears any unfinished business)
+ BASE <-- 0xc8 (see "Default")
+
+Volume Down: BASE <-- 0x48 (volume down, no stereo detect,
+ radio enable, tuner adjust disable)
+ * wait 10 msec *
+ BASE <-- 0xc8 (see "Default")
+
+Volume Up: BASE <-- 0x88 (volume up, no stereo detect,
+ radio enable, tuner adjust disable)
+ * wait 10 msec *
+ BASE <-- 0xc8 (see "Default")
+
+Check Stereo: BASE <-- 0xd8 (current volume, stereo detect,
+ radio enable, tuner adjust disable)
+ * wait 100 msec *
+ x <-- BASE (read ioport)
+ BASE <-- 0xc8 (see "Default")
+
+ x=0xff ==> "not stereo", x=0xfd ==> "stereo detected"
+
+Set Frequency: code = (freq*40) + 10486188
+ foreach of the 24 bits in code,
+ (from Least to Most Significant):
+ to write a "zero" bit,
+ BASE <-- 0x01 (audio mute, no stereo detect, radio
+ disable, "zero" bit phase 1, tuner adjust)
+ BASE <-- 0x03 (audio mute, no stereo detect, radio
+ disable, "zero" bit phase 2, tuner adjust)
+ to write a "one" bit,
+ BASE <-- 0x05 (audio mute, no stereo detect, radio
+ disable, "one" bit phase 1, tuner adjust)
+ BASE <-- 0x07 (audio mute, no stereo detect, radio
+ disable, "one" bit phase 2, tuner adjust)
+
+----------------------------------------------------------------------------
--- /dev/null
+
+
+What is it?
+===========
+
+This is a v4l2/oss device driver for saa7130/33/34/35 based capture / TV
+boards. See http://www.semiconductors.philips.com/pip/saa7134hl for a
+description.
+
+
+Status
+======
+
+Almost everything is working. video, sound, tuner, radio, mpeg ts, ...
+
+As with bttv, card-specific tweaks are needed. Check CARDLIST for a
+list of known TV cards and saa7134-cards.c for the drivers card
+configuration info.
+
+
+Build
+=====
+
+Pick up videodev + v4l2 patches from http://bytesex.org/patches/.
+Configure, build, install + boot the new kernel. You'll need at least
+these config options:
+
+ CONFIG_I2C=m
+ CONFIG_VIDEO_DEV=m
+
+Type "make" to build the driver now. "make install" installs the
+driver. "modprobe saa7134" should load it. Depending on the card you
+might have to pass card=<nr> as insmod option, check CARDLIST for
+valid choices.
+
+
+Changes / Fixes
+===============
+
+Please mail me unified diffs ("diff -u") with your changes, and don't
+forget to tell me what it changes / which problem it fixes / whatever
+it is good for ...
+
+
+Known Problems
+==============
+
+* The tuner for the flyvideos isn't detected automatically and the
+ default might not work for you depending on which version you have.
+ There is a tuner= insmod option to override the driver's default.
+
+Card Variations:
+================
+
+Cards can use either of these two crystals (xtal):
+ - 32.11 MHz -> .audio_clock=0x187de7
+ - 24.576MHz -> .audio_clock=0x200000
+(xtal * .audio_clock = 51539600)
+
+Some details about 30/34/35:
+
+ - saa7130 - low-price chip, doesn't have mute, that is why all those
+ cards should have .mute field defined in their tuner structure.
+
+ - saa7134 - usual chip
+
+ - saa7133/35 - saa7135 is probably a marketing decision, since all those
+ chips identifies itself as 33 on pci.
+
+Credits
+=======
+
+andrew.stevens@philips.com + werner.leeb@philips.com for providing
+saa7134 hardware specs and sample board.
+
+
+Have fun,
+
+ Gerd
+
+--
+Gerd Knorr <kraxel@bytesex.org> [SuSE Labs]
--- /dev/null
+ Cropping and Scaling algorithm, used in the sh_mobile_ceu_camera driver
+ =======================================================================
+
+Terminology
+-----------
+
+sensor scales: horizontal and vertical scales, configured by the sensor driver
+host scales: -"- host driver
+combined scales: sensor_scale * host_scale
+
+
+Generic scaling / cropping scheme
+---------------------------------
+
+-1--
+|
+-2-- -\
+| --\
+| --\
++-5-- . -- -3-- -\
+| `... -\
+| `... -4-- . - -7..
+| `.
+| `. .6--
+|
+| . .6'-
+| .´
+| ... -4'- .´
+| ...´ - -7'.
++-5'- .´ -/
+| -- -3'- -/
+| --/
+| --/
+-2'- -/
+|
+|
+-1'-
+
+In the above chart minuses and slashes represent "real" data amounts, points and
+accents represent "useful" data, basically, CEU scaled and cropped output,
+mapped back onto the client's source plane.
+
+Such a configuration can be produced by user requests:
+
+S_CROP(left / top = (5) - (1), width / height = (5') - (5))
+S_FMT(width / height = (6') - (6))
+
+Here:
+
+(1) to (1') - whole max width or height
+(1) to (2) - sensor cropped left or top
+(2) to (2') - sensor cropped width or height
+(3) to (3') - sensor scale
+(3) to (4) - CEU cropped left or top
+(4) to (4') - CEU cropped width or height
+(5) to (5') - reverse sensor scale applied to CEU cropped width or height
+(2) to (5) - reverse sensor scale applied to CEU cropped left or top
+(6) to (6') - CEU scale - user window
+
+
+S_FMT
+-----
+
+Do not touch input rectangle - it is already optimal.
+
+1. Calculate current sensor scales:
+
+ scale_s = ((2') - (2)) / ((3') - (3))
+
+2. Calculate "effective" input crop (sensor subwindow) - CEU crop scaled back at
+current sensor scales onto input window - this is user S_CROP:
+
+ width_u = (5') - (5) = ((4') - (4)) * scale_s
+
+3. Calculate new combined scales from "effective" input window to requested user
+window:
+
+ scale_comb = width_u / ((6') - (6))
+
+4. Calculate sensor output window by applying combined scales to real input
+window:
+
+ width_s_out = ((7') - (7)) = ((2') - (2)) / scale_comb
+
+5. Apply iterative sensor S_FMT for sensor output window.
+
+ subdev->video_ops->s_fmt(.width = width_s_out)
+
+6. Retrieve sensor output window (g_fmt)
+
+7. Calculate new sensor scales:
+
+ scale_s_new = ((3')_new - (3)_new) / ((2') - (2))
+
+8. Calculate new CEU crop - apply sensor scales to previously calculated
+"effective" crop:
+
+ width_ceu = (4')_new - (4)_new = width_u / scale_s_new
+ left_ceu = (4)_new - (3)_new = ((5) - (2)) / scale_s_new
+
+9. Use CEU cropping to crop to the new window:
+
+ ceu_crop(.width = width_ceu, .left = left_ceu)
+
+10. Use CEU scaling to scale to the requested user window:
+
+ scale_ceu = width_ceu / width
+
+
+S_CROP
+------
+
+The API at http://v4l2spec.bytesex.org/spec/x1904.htm says:
+
+"...specification does not define an origin or units. However by convention
+drivers should horizontally count unscaled samples relative to 0H."
+
+We choose to follow the advise and interpret cropping units as client input
+pixels.
+
+Cropping is performed in the following 6 steps:
+
+1. Request exactly user rectangle from the sensor.
+
+2. If smaller - iterate until a larger one is obtained. Result: sensor cropped
+ to 2 : 2', target crop 5 : 5', current output format 6' - 6.
+
+3. In the previous step the sensor has tried to preserve its output frame as
+ good as possible, but it could have changed. Retrieve it again.
+
+4. Sensor scaled to 3 : 3'. Sensor's scale is (2' - 2) / (3' - 3). Calculate
+ intermediate window: 4' - 4 = (5' - 5) * (3' - 3) / (2' - 2)
+
+5. Calculate and apply host scale = (6' - 6) / (4' - 4)
+
+6. Calculate and apply host crop: 6 - 7 = (5 - 2) * (6' - 6) / (5' - 5)
+
+--
+Author: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
--- /dev/null
+Driver for USB radios for the Silicon Labs Si470x FM Radio Receivers
+
+Copyright (c) 2009 Tobias Lorenz <tobias.lorenz@gmx.net>
+
+
+Information from Silicon Labs
+=============================
+Silicon Laboratories is the manufacturer of the radio ICs, that nowadays are the
+most often used radio receivers in cell phones. Usually they are connected with
+I2C. But SiLabs also provides a reference design, which integrates this IC,
+together with a small microcontroller C8051F321, to form a USB radio.
+Part of this reference design is also a radio application in binary and source
+code. The software also contains an automatic firmware upgrade to the most
+current version. Information on these can be downloaded here:
+http://www.silabs.com/usbradio
+
+
+Supported ICs
+=============
+The following ICs have a very similar register set, so that they are or will be
+supported somewhen by the driver:
+- Si4700: FM radio receiver
+- Si4701: FM radio receiver, RDS Support
+- Si4702: FM radio receiver
+- Si4703: FM radio receiver, RDS Support
+- Si4704: FM radio receiver, no external antenna required
+- Si4705: FM radio receiver, no external antenna required, RDS support, Dig I/O
+- Si4706: Enhanced FM RDS/TMC radio receiver, no external antenna required, RDS
+ Support
+- Si4707: Dedicated weather band radio receiver with SAME decoder, RDS Support
+- Si4708: Smallest FM receivers
+- Si4709: Smallest FM receivers, RDS Support
+More information on these can be downloaded here:
+http://www.silabs.com/products/mcu/Pages/USBFMRadioRD.aspx
+
+
+Supported USB devices
+=====================
+Currently the following USB radios (vendor:product) with the Silicon Labs si470x
+chips are known to work:
+- 10c4:818a: Silicon Labs USB FM Radio Reference Design
+- 06e1:a155: ADS/Tech FM Radio Receiver (formerly Instant FM Music) (RDX-155-EF)
+- 1b80:d700: KWorld USB FM Radio SnapMusic Mobile 700 (FM700)
+- 10c5:819a: Sanei Electric, Inc. FM USB Radio (sold as DealExtreme.com PCear)
+
+
+Software
+========
+Testing is usually done with most application under Debian/testing:
+- fmtools - Utility for managing FM tuner cards
+- gnomeradio - FM-radio tuner for the GNOME desktop
+- gradio - GTK FM radio tuner
+- kradio - Comfortable Radio Application for KDE
+- radio - ncurses-based radio application
+- mplayer - The Ultimate Movie Player For Linux
+- v4l2-ctl - Collection of command line video4linux utilities
+For example, you can use:
+v4l2-ctl -d /dev/radio0 --set-ctrl=volume=10,mute=0 --set-freq=95.21 --all
+
+There is also a library libv4l, which can be used. It's going to have a function
+for frequency seeking, either by using hardware functionality as in radio-si470x
+or by implementing a function as we currently have in every of the mentioned
+programs. Somewhen the radio programs should make use of libv4l.
+
+For processing RDS information, there is a project ongoing at:
+http://rdsd.berlios.de/
+
+There is currently no project for making TMC sentences human readable.
+
+
+Audio Listing
+=============
+USB Audio is provided by the ALSA snd_usb_audio module. It is recommended to
+also select SND_USB_AUDIO, as this is required to get sound from the radio. For
+listing you have to redirect the sound, for example using one of the following
+commands. Please adjust the audio devices to your needs (/dev/dsp* and hw:x,x).
+
+If you just want to test audio (very poor quality):
+cat /dev/dsp1 > /dev/dsp
+
+If you use sox + OSS try:
+sox -2 --endian little -r 96000 -t oss /dev/dsp1 -t oss /dev/dsp
+or using sox + alsa:
+sox --endian little -c 2 -S -r 96000 -t alsa hw:1 -t alsa -r 96000 hw:0
+
+If you use arts try:
+arecord -D hw:1,0 -r96000 -c2 -f S16_LE | artsdsp aplay -B -
+
+If you use mplayer try:
+mplayer -radio adevice=hw=1.0:arate=96000 \
+ -rawaudio rate=96000 \
+ radio://<frequency>/capture
+
+Module Parameters
+=================
+After loading the module, you still have access to some of them in the sysfs
+mount under /sys/module/radio_si470x/parameters. The contents of read-only files
+(0444) are not updated, even if space, band and de are changed using private
+video controls. The others are runtime changeable.
+
+
+Errors
+======
+Increase tune_timeout, if you often get -EIO errors.
+
+When timed out or band limit is reached, hw_freq_seek returns -EAGAIN.
+
+If you get any errors from snd_usb_audio, please report them to the ALSA people.
+
+
+Open Issues
+===========
+V4L minor device allocation and parameter setting is not perfect. A solution is
+currently under discussion.
+
+There is an USB interface for downloading/uploading new firmware images. Support
+for it can be implemented using the request_firmware interface.
+
+There is a RDS interrupt mode. The driver is already using the same interface
+for polling RDS information, but is currently not using the interrupt mode.
+
+There is a LED interface, which can be used to override the LED control
+programmed in the firmware. This can be made available using the LED support
+functions in the kernel.
+
+
+Other useful information and links
+==================================
+http://www.silabs.com/usbradio
--- /dev/null
+Driver for I2C radios for the Silicon Labs Si4713 FM Radio Transmitters
+
+Copyright (c) 2009 Nokia Corporation
+Contact: Eduardo Valentin <eduardo.valentin@nokia.com>
+
+
+Information about the Device
+============================
+This chip is a Silicon Labs product. It is a I2C device, currently on 0x63 address.
+Basically, it has transmission and signal noise level measurement features.
+
+The Si4713 integrates transmit functions for FM broadcast stereo transmission.
+The chip also allows integrated receive power scanning to identify low signal
+power FM channels.
+
+The chip is programmed using commands and responses. There are also several
+properties which can change the behavior of this chip.
+
+Users must comply with local regulations on radio frequency (RF) transmission.
+
+Device driver description
+=========================
+There are two modules to handle this device. One is a I2C device driver
+and the other is a platform driver.
+
+The I2C device driver exports a v4l2-subdev interface to the kernel.
+All properties can also be accessed by v4l2 extended controls interface, by
+using the v4l2-subdev calls (g_ext_ctrls, s_ext_ctrls).
+
+The platform device driver exports a v4l2 radio device interface to user land.
+So, it uses the I2C device driver as a sub device in order to send the user
+commands to the actual device. Basically it is a wrapper to the I2C device driver.
+
+Applications can use v4l2 radio API to specify frequency of operation, mute state,
+etc. But mostly of its properties will be present in the extended controls.
+
+When the v4l2 mute property is set to 1 (true), the driver will turn the chip off.
+
+Properties description
+======================
+
+The properties can be accessed using v4l2 extended controls.
+Here is an output from v4l2-ctl util:
+/ # v4l2-ctl -d /dev/radio0 --all -L
+Driver Info:
+ Driver name : radio-si4713
+ Card type : Silicon Labs Si4713 Modulator
+ Bus info :
+ Driver version: 0
+ Capabilities : 0x00080800
+ RDS Output
+ Modulator
+Audio output: 0 (FM Modulator Audio Out)
+Frequency: 1408000 (88.000000 MHz)
+Video Standard = 0x00000000
+Modulator:
+ Name : FM Modulator
+ Capabilities : 62.5 Hz stereo rds
+ Frequency range : 76.0 MHz - 108.0 MHz
+ Subchannel modulation: stereo+rds
+
+User Controls
+
+ mute (bool) : default=1 value=0
+
+FM Radio Modulator Controls
+
+ rds_signal_deviation (int) : min=0 max=90000 step=10 default=200 value=200 flags=slider
+ rds_program_id (int) : min=0 max=65535 step=1 default=0 value=0
+ rds_program_type (int) : min=0 max=31 step=1 default=0 value=0
+ rds_ps_name (str) : min=0 max=96 step=8 value='si4713 '
+ rds_radio_text (str) : min=0 max=384 step=32 value=''
+ audio_limiter_feature_enabled (bool) : default=1 value=1
+ audio_limiter_release_time (int) : min=250 max=102390 step=50 default=5010 value=5010 flags=slider
+ audio_limiter_deviation (int) : min=0 max=90000 step=10 default=66250 value=66250 flags=slider
+audio_compression_feature_enabl (bool) : default=1 value=1
+ audio_compression_gain (int) : min=0 max=20 step=1 default=15 value=15 flags=slider
+ audio_compression_threshold (int) : min=-40 max=0 step=1 default=-40 value=-40 flags=slider
+ audio_compression_attack_time (int) : min=0 max=5000 step=500 default=0 value=0 flags=slider
+ audio_compression_release_time (int) : min=100000 max=1000000 step=100000 default=1000000 value=1000000 flags=slider
+ pilot_tone_feature_enabled (bool) : default=1 value=1
+ pilot_tone_deviation (int) : min=0 max=90000 step=10 default=6750 value=6750 flags=slider
+ pilot_tone_frequency (int) : min=0 max=19000 step=1 default=19000 value=19000 flags=slider
+ pre_emphasis_settings (menu) : min=0 max=2 default=1 value=1
+ tune_power_level (int) : min=0 max=120 step=1 default=88 value=88 flags=slider
+ tune_antenna_capacitor (int) : min=0 max=191 step=1 default=0 value=110 flags=slider
+/ #
+
+Here is a summary of them:
+
+* Pilot is an audible tone sent by the device.
+
+pilot_frequency - Configures the frequency of the stereo pilot tone.
+pilot_deviation - Configures pilot tone frequency deviation level.
+pilot_enabled - Enables or disables the pilot tone feature.
+
+* The si4713 device is capable of applying audio compression to the transmitted signal.
+
+acomp_enabled - Enables or disables the audio dynamic range control feature.
+acomp_gain - Sets the gain for audio dynamic range control.
+acomp_threshold - Sets the threshold level for audio dynamic range control.
+acomp_attack_time - Sets the attack time for audio dynamic range control.
+acomp_release_time - Sets the release time for audio dynamic range control.
+
+* Limiter setups audio deviation limiter feature. Once a over deviation occurs,
+it is possible to adjust the front-end gain of the audio input and always
+prevent over deviation.
+
+limiter_enabled - Enables or disables the limiter feature.
+limiter_deviation - Configures audio frequency deviation level.
+limiter_release_time - Sets the limiter release time.
+
+* Tuning power
+
+power_level - Sets the output power level for signal transmission.
+antenna_capacitor - This selects the value of antenna tuning capacitor manually
+or automatically if set to zero.
+
+* RDS related
+
+rds_ps_name - Sets the RDS ps name field for transmission.
+rds_radio_text - Sets the RDS radio text for transmission.
+rds_pi - Sets the RDS PI field for transmission.
+rds_pty - Sets the RDS PTY field for transmission.
+
+* Region related
+
+preemphasis - sets the preemphasis to be applied for transmission.
+
+RNL
+===
+
+This device also has an interface to measure received noise level. To do that, you should
+ioctl the device node. Here is an code of example:
+
+int main (int argc, char *argv[])
+{
+ struct si4713_rnl rnl;
+ int fd = open("/dev/radio0", O_RDWR);
+ int rval;
+
+ if (argc < 2)
+ return -EINVAL;
+
+ if (fd < 0)
+ return fd;
+
+ sscanf(argv[1], "%d", &rnl.frequency);
+
+ rval = ioctl(fd, SI4713_IOC_MEASURE_RNL, &rnl);
+ if (rval < 0)
+ return rval;
+
+ printf("received noise level: %d\n", rnl.rnl);
+
+ close(fd);
+}
+
+The struct si4713_rnl and SI4713_IOC_MEASURE_RNL are defined under
+include/linux/platform_data/media/si4713.h.
+
+Stereo/Mono and RDS subchannels
+===============================
+
+The device can also be configured using the available sub channels for
+transmission. To do that use S/G_MODULATOR ioctl and configure txsubchans properly.
+Refer to the V4L2 API specification for proper use of this ioctl.
+
+Testing
+=======
+Testing is usually done with v4l2-ctl utility for managing FM tuner cards.
+The tool can be found in v4l-dvb repository under v4l2-apps/util directory.
+
+Example for setting rds ps name:
+# v4l2-ctl -d /dev/radio0 --set-ctrl=rds_ps_name="Dummy"
+
--- /dev/null
+SI476x Driver Readme
+------------------------------------------------
+ Copyright (C) 2013 Andrey Smirnov <andrew.smirnov@gmail.com>
+
+TODO for the driver
+------------------------------
+
+- According to the SiLabs' datasheet it is possible to update the
+ firmware of the radio chip in the run-time, thus bringing it to the
+ most recent version. Unfortunately I couldn't find any mentioning of
+ the said firmware update for the old chips that I tested the driver
+ against, so for chips like that the driver only exposes the old
+ functionality.
+
+
+Parameters exposed over debugfs
+-------------------------------
+SI476x allow user to get multiple characteristics that can be very
+useful for EoL testing/RF performance estimation, parameters that have
+very little to do with V4L2 subsystem. Such parameters are exposed via
+debugfs and can be accessed via regular file I/O operations.
+
+The drivers exposes following files:
+
+* /sys/kernel/debug/<device-name>/acf
+ This file contains ACF(Automatically Controlled Features) status
+ information. The contents of the file is binary data of the
+ following layout:
+
+ Offset | Name | Description
+ ====================================================================
+ 0x00 | blend_int | Flag, set when stereo separation has
+ | | crossed below the blend threshold
+ --------------------------------------------------------------------
+ 0x01 | hblend_int | Flag, set when HiBlend cutoff
+ | | frequency is lower than threshold
+ --------------------------------------------------------------------
+ 0x02 | hicut_int | Flag, set when HiCut cutoff
+ | | frequency is lower than threshold
+ --------------------------------------------------------------------
+ 0x03 | chbw_int | Flag, set when channel filter
+ | | bandwidth is less than threshold
+ --------------------------------------------------------------------
+ 0x04 | softmute_int | Flag indicating that softmute
+ | | attenuation has increased above
+ | | softmute threshold
+ --------------------------------------------------------------------
+ 0x05 | smute | 0 - Audio is not soft muted
+ | | 1 - Audio is soft muted
+ --------------------------------------------------------------------
+ 0x06 | smattn | Soft mute attenuation level in dB
+ --------------------------------------------------------------------
+ 0x07 | chbw | Channel filter bandwidth in kHz
+ --------------------------------------------------------------------
+ 0x08 | hicut | HiCut cutoff frequency in units of
+ | | 100Hz
+ --------------------------------------------------------------------
+ 0x09 | hiblend | HiBlend cutoff frequency in units
+ | | of 100 Hz
+ --------------------------------------------------------------------
+ 0x10 | pilot | 0 - Stereo pilot is not present
+ | | 1 - Stereo pilot is present
+ --------------------------------------------------------------------
+ 0x11 | stblend | Stereo blend in %
+ --------------------------------------------------------------------
+
+
+* /sys/kernel/debug/<device-name>/rds_blckcnt
+ This file contains statistics about RDS receptions. It's binary data
+ has the following layout:
+
+ Offset | Name | Description
+ ====================================================================
+ 0x00 | expected | Number of expected RDS blocks
+ --------------------------------------------------------------------
+ 0x02 | received | Number of received RDS blocks
+ --------------------------------------------------------------------
+ 0x04 | uncorrectable | Number of uncorrectable RDS blocks
+ --------------------------------------------------------------------
+
+* /sys/kernel/debug/<device-name>/agc
+ This file contains information about parameters pertaining to
+ AGC(Automatic Gain Control)
+
+ The layout is:
+ Offset | Name | Description
+ ====================================================================
+ 0x00 | mxhi | 0 - FM Mixer PD high threshold is
+ | | not tripped
+ | | 1 - FM Mixer PD high threshold is
+ | | tripped
+ --------------------------------------------------------------------
+ 0x01 | mxlo | ditto for FM Mixer PD low
+ --------------------------------------------------------------------
+ 0x02 | lnahi | ditto for FM LNA PD high
+ --------------------------------------------------------------------
+ 0x03 | lnalo | ditto for FM LNA PD low
+ --------------------------------------------------------------------
+ 0x04 | fmagc1 | FMAGC1 attenuator resistance
+ | | (see datasheet for more detail)
+ --------------------------------------------------------------------
+ 0x05 | fmagc2 | ditto for FMAGC2
+ --------------------------------------------------------------------
+ 0x06 | pgagain | PGA gain in dB
+ --------------------------------------------------------------------
+ 0x07 | fmwblang | FM/WB LNA Gain in dB
+ --------------------------------------------------------------------
+
+* /sys/kernel/debug/<device-name>/rsq
+ This file contains information about parameters pertaining to
+ RSQ(Received Signal Quality)
+
+ The layout is:
+ Offset | Name | Description
+ ====================================================================
+ 0x00 | multhint | 0 - multipath value has not crossed
+ | | the Multipath high threshold
+ | | 1 - multipath value has crossed
+ | | the Multipath high threshold
+ --------------------------------------------------------------------
+ 0x01 | multlint | ditto for Multipath low threshold
+ --------------------------------------------------------------------
+ 0x02 | snrhint | 0 - received signal's SNR has not
+ | | crossed high threshold
+ | | 1 - received signal's SNR has
+ | | crossed high threshold
+ --------------------------------------------------------------------
+ 0x03 | snrlint | ditto for low threshold
+ --------------------------------------------------------------------
+ 0x04 | rssihint | ditto for RSSI high threshold
+ --------------------------------------------------------------------
+ 0x05 | rssilint | ditto for RSSI low threshold
+ --------------------------------------------------------------------
+ 0x06 | bltf | Flag indicating if seek command
+ | | reached/wrapped seek band limit
+ --------------------------------------------------------------------
+ 0x07 | snr_ready | Indicates that SNR metrics is ready
+ --------------------------------------------------------------------
+ 0x08 | rssiready | ditto for RSSI metrics
+ --------------------------------------------------------------------
+ 0x09 | injside | 0 - Low-side injection is being used
+ | | 1 - High-side injection is used
+ --------------------------------------------------------------------
+ 0x10 | afcrl | Flag indicating if AFC rails
+ --------------------------------------------------------------------
+ 0x11 | valid | Flag indicating if channel is valid
+ --------------------------------------------------------------------
+ 0x12 | readfreq | Current tuned frequency
+ --------------------------------------------------------------------
+ 0x14 | freqoff | Signed frequency offset in units of
+ | | 2ppm
+ --------------------------------------------------------------------
+ 0x15 | rssi | Signed value of RSSI in dBuV
+ --------------------------------------------------------------------
+ 0x16 | snr | Signed RF SNR in dB
+ --------------------------------------------------------------------
+ 0x17 | issi | Signed Image Strength Signal
+ | | indicator
+ --------------------------------------------------------------------
+ 0x18 | lassi | Signed Low side adjacent Channel
+ | | Strength indicator
+ --------------------------------------------------------------------
+ 0x19 | hassi | ditto fpr High side
+ --------------------------------------------------------------------
+ 0x20 | mult | Multipath indicator
+ --------------------------------------------------------------------
+ 0x21 | dev | Frequency deviation
+ --------------------------------------------------------------------
+ 0x24 | assi | Adjacent channel SSI
+ --------------------------------------------------------------------
+ 0x25 | usn | Ultrasonic noise indicator
+ --------------------------------------------------------------------
+ 0x26 | pilotdev | Pilot deviation in units of 100 Hz
+ --------------------------------------------------------------------
+ 0x27 | rdsdev | ditto for RDS
+ --------------------------------------------------------------------
+ 0x28 | assidev | ditto for ASSI
+ --------------------------------------------------------------------
+ 0x29 | strongdev | Frequency deviation
+ --------------------------------------------------------------------
+ 0x30 | rdspi | RDS PI code
+ --------------------------------------------------------------------
+
+* /sys/kernel/debug/<device-name>/rsq_primary
+ This file contains information about parameters pertaining to
+ RSQ(Received Signal Quality) for primary tuner only. Layout is as
+ the one above.
--- /dev/null
+ Soc-Camera Subsystem
+ ====================
+
+Terminology
+-----------
+
+The following terms are used in this document:
+ - camera / camera device / camera sensor - a video-camera sensor chip, capable
+ of connecting to a variety of systems and interfaces, typically uses i2c for
+ control and configuration, and a parallel or a serial bus for data.
+ - camera host - an interface, to which a camera is connected. Typically a
+ specialised interface, present on many SoCs, e.g. PXA27x and PXA3xx, SuperH,
+ AVR32, i.MX27, i.MX31.
+ - camera host bus - a connection between a camera host and a camera. Can be
+ parallel or serial, consists of data and control lines, e.g. clock, vertical
+ and horizontal synchronization signals.
+
+Purpose of the soc-camera subsystem
+-----------------------------------
+
+The soc-camera subsystem initially provided a unified API between camera host
+drivers and camera sensor drivers. Later the soc-camera sensor API has been
+replaced with the V4L2 standard subdev API. This also made camera driver re-use
+with non-soc-camera hosts possible. The camera host API to the soc-camera core
+has been preserved.
+
+Soc-camera implements a V4L2 interface to the user, currently only the "mmap"
+method is supported by host drivers. However, the soc-camera core also provides
+support for the "read" method.
+
+The subsystem has been designed to support multiple camera host interfaces and
+multiple cameras per interface, although most applications have only one camera
+sensor.
+
+Existing drivers
+----------------
+
+As of 3.7 there are seven host drivers in the mainline: atmel-isi.c,
+mx1_camera.c (broken, scheduled for removal), mx2_camera.c, mx3_camera.c,
+omap1_camera.c, pxa_camera.c, sh_mobile_ceu_camera.c, and multiple sensor
+drivers under drivers/media/i2c/soc_camera/.
+
+Camera host API
+---------------
+
+A host camera driver is registered using the
+
+soc_camera_host_register(struct soc_camera_host *);
+
+function. The host object can be initialized as follows:
+
+ struct soc_camera_host *ici;
+ ici->drv_name = DRV_NAME;
+ ici->ops = &camera_host_ops;
+ ici->priv = pcdev;
+ ici->v4l2_dev.dev = &pdev->dev;
+ ici->nr = pdev->id;
+
+All camera host methods are passed in a struct soc_camera_host_ops:
+
+static struct soc_camera_host_ops camera_host_ops = {
+ .owner = THIS_MODULE,
+ .add = camera_add_device,
+ .remove = camera_remove_device,
+ .set_fmt = camera_set_fmt_cap,
+ .try_fmt = camera_try_fmt_cap,
+ .init_videobuf2 = camera_init_videobuf2,
+ .poll = camera_poll,
+ .querycap = camera_querycap,
+ .set_bus_param = camera_set_bus_param,
+ /* The rest of host operations are optional */
+};
+
+.add and .remove methods are called when a sensor is attached to or detached
+from the host. .set_bus_param is used to configure physical connection
+parameters between the host and the sensor. .init_videobuf2 is called by
+soc-camera core when a video-device is opened, the host driver would typically
+call vb2_queue_init() in this method. Further video-buffer management is
+implemented completely by the specific camera host driver. If the host driver
+supports non-standard pixel format conversion, it should implement a
+.get_formats and, possibly, a .put_formats operations. See below for more
+details about format conversion. The rest of the methods are called from
+respective V4L2 operations.
+
+Camera API
+----------
+
+Sensor drivers can use struct soc_camera_link, typically provided by the
+platform, and used to specify to which camera host bus the sensor is connected,
+and optionally provide platform .power and .reset methods for the camera. This
+struct is provided to the camera driver via the I2C client device platform data
+and can be obtained, using the soc_camera_i2c_to_link() macro. Care should be
+taken, when using soc_camera_vdev_to_subdev() and when accessing struct
+soc_camera_device, using v4l2_get_subdev_hostdata(): both only work, when
+running on an soc-camera host. The actual camera driver operation is implemented
+using the V4L2 subdev API. Additionally soc-camera camera drivers can use
+auxiliary soc-camera helper functions like soc_camera_power_on() and
+soc_camera_power_off(), which switch regulators, provided by the platform and call
+board-specific power switching methods. soc_camera_apply_board_flags() takes
+camera bus configuration capability flags and applies any board transformations,
+e.g. signal polarity inversion. soc_mbus_get_fmtdesc() can be used to obtain a
+pixel format descriptor, corresponding to a certain media-bus pixel format code.
+soc_camera_limit_side() can be used to restrict beginning and length of a frame
+side, based on camera capabilities.
+
+VIDIOC_S_CROP and VIDIOC_S_FMT behaviour
+----------------------------------------
+
+Above user ioctls modify image geometry as follows:
+
+VIDIOC_S_CROP: sets location and sizes of the sensor window. Unit is one sensor
+pixel. Changing sensor window sizes preserves any scaling factors, therefore
+user window sizes change as well.
+
+VIDIOC_S_FMT: sets user window. Should preserve previously set sensor window as
+much as possible by modifying scaling factors. If the sensor window cannot be
+preserved precisely, it may be changed too.
+
+In soc-camera there are two locations, where scaling and cropping can take
+place: in the camera driver and in the host driver. User ioctls are first passed
+to the host driver, which then generally passes them down to the camera driver.
+It is more efficient to perform scaling and cropping in the camera driver to
+save camera bus bandwidth and maximise the framerate. However, if the camera
+driver failed to set the required parameters with sufficient precision, the host
+driver may decide to also use its own scaling and cropping to fulfill the user's
+request.
+
+Camera drivers are interfaced to the soc-camera core and to host drivers over
+the v4l2-subdev API, which is completely functional, it doesn't pass any data.
+Therefore all camera drivers shall reply to .g_fmt() requests with their current
+output geometry. This is necessary to correctly configure the camera bus.
+.s_fmt() and .try_fmt() have to be implemented too. Sensor window and scaling
+factors have to be maintained by camera drivers internally. According to the
+V4L2 API all capture drivers must support the VIDIOC_CROPCAP ioctl, hence we
+rely on camera drivers implementing .cropcap(). If the camera driver does not
+support cropping, it may choose to not implement .s_crop(), but to enable
+cropping support by the camera host driver at least the .g_crop method must be
+implemented.
+
+User window geometry is kept in .user_width and .user_height fields in struct
+soc_camera_device and used by the soc-camera core and host drivers. The core
+updates these fields upon successful completion of a .s_fmt() call, but if these
+fields change elsewhere, e.g. during .s_crop() processing, the host driver is
+responsible for updating them.
+
+Format conversion
+-----------------
+
+V4L2 distinguishes between pixel formats, as they are stored in memory, and as
+they are transferred over a media bus. Soc-camera provides support to
+conveniently manage these formats. A table of standard transformations is
+maintained by soc-camera core, which describes, what FOURCC pixel format will
+be obtained, if a media-bus pixel format is stored in memory according to
+certain rules. E.g. if MEDIA_BUS_FMT_YUYV8_2X8 data is sampled with 8 bits per
+sample and stored in memory in the little-endian order with no gaps between
+bytes, data in memory will represent the V4L2_PIX_FMT_YUYV FOURCC format. These
+standard transformations will be used by soc-camera or by camera host drivers to
+configure camera drivers to produce the FOURCC format, requested by the user,
+using the VIDIOC_S_FMT ioctl(). Apart from those standard format conversions,
+host drivers can also provide their own conversion rules by implementing a
+.get_formats and, if required, a .put_formats methods.
+
+--
+Author: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
--- /dev/null
+Linux USB Video Class (UVC) driver
+==================================
+
+This file documents some driver-specific aspects of the UVC driver, such as
+driver-specific ioctls and implementation notes.
+
+Questions and remarks can be sent to the Linux UVC development mailing list at
+linux-uvc-devel@lists.berlios.de.
+
+
+Extension Unit (XU) support
+---------------------------
+
+1. Introduction
+
+The UVC specification allows for vendor-specific extensions through extension
+units (XUs). The Linux UVC driver supports extension unit controls (XU controls)
+through two separate mechanisms:
+
+ - through mappings of XU controls to V4L2 controls
+ - through a driver-specific ioctl interface
+
+The first one allows generic V4L2 applications to use XU controls by mapping
+certain XU controls onto V4L2 controls, which then show up during ordinary
+control enumeration.
+
+The second mechanism requires uvcvideo-specific knowledge for the application to
+access XU controls but exposes the entire UVC XU concept to user space for
+maximum flexibility.
+
+Both mechanisms complement each other and are described in more detail below.
+
+
+2. Control mappings
+
+The UVC driver provides an API for user space applications to define so-called
+control mappings at runtime. These allow for individual XU controls or byte
+ranges thereof to be mapped to new V4L2 controls. Such controls appear and
+function exactly like normal V4L2 controls (i.e. the stock controls, such as
+brightness, contrast, etc.). However, reading or writing of such a V4L2 controls
+triggers a read or write of the associated XU control.
+
+The ioctl used to create these control mappings is called UVCIOC_CTRL_MAP.
+Previous driver versions (before 0.2.0) required another ioctl to be used
+beforehand (UVCIOC_CTRL_ADD) to pass XU control information to the UVC driver.
+This is no longer necessary as newer uvcvideo versions query the information
+directly from the device.
+
+For details on the UVCIOC_CTRL_MAP ioctl please refer to the section titled
+"IOCTL reference" below.
+
+
+3. Driver specific XU control interface
+
+For applications that need to access XU controls directly, e.g. for testing
+purposes, firmware upload, or accessing binary controls, a second mechanism to
+access XU controls is provided in the form of a driver-specific ioctl, namely
+UVCIOC_CTRL_QUERY.
+
+A call to this ioctl allows applications to send queries to the UVC driver that
+directly map to the low-level UVC control requests.
+
+In order to make such a request the UVC unit ID of the control's extension unit
+and the control selector need to be known. This information either needs to be
+hardcoded in the application or queried using other ways such as by parsing the
+UVC descriptor or, if available, using the media controller API to enumerate a
+device's entities.
+
+Unless the control size is already known it is necessary to first make a
+UVC_GET_LEN requests in order to be able to allocate a sufficiently large buffer
+and set the buffer size to the correct value. Similarly, to find out whether
+UVC_GET_CUR or UVC_SET_CUR are valid requests for a given control, a
+UVC_GET_INFO request should be made. The bits 0 (GET supported) and 1 (SET
+supported) of the resulting byte indicate which requests are valid.
+
+With the addition of the UVCIOC_CTRL_QUERY ioctl the UVCIOC_CTRL_GET and
+UVCIOC_CTRL_SET ioctls have become obsolete since their functionality is a
+subset of the former ioctl. For the time being they are still supported but
+application developers are encouraged to use UVCIOC_CTRL_QUERY instead.
+
+For details on the UVCIOC_CTRL_QUERY ioctl please refer to the section titled
+"IOCTL reference" below.
+
+
+4. Security
+
+The API doesn't currently provide a fine-grained access control facility. The
+UVCIOC_CTRL_ADD and UVCIOC_CTRL_MAP ioctls require super user permissions.
+
+Suggestions on how to improve this are welcome.
+
+
+5. Debugging
+
+In order to debug problems related to XU controls or controls in general it is
+recommended to enable the UVC_TRACE_CONTROL bit in the module parameter 'trace'.
+This causes extra output to be written into the system log.
+
+
+6. IOCTL reference
+
+---- UVCIOC_CTRL_MAP - Map a UVC control to a V4L2 control ----
+
+Argument: struct uvc_xu_control_mapping
+
+Description:
+ This ioctl creates a mapping between a UVC control or part of a UVC
+ control and a V4L2 control. Once mappings are defined, userspace
+ applications can access vendor-defined UVC control through the V4L2
+ control API.
+
+ To create a mapping, applications fill the uvc_xu_control_mapping
+ structure with information about an existing UVC control defined with
+ UVCIOC_CTRL_ADD and a new V4L2 control.
+
+ A UVC control can be mapped to several V4L2 controls. For instance,
+ a UVC pan/tilt control could be mapped to separate pan and tilt V4L2
+ controls. The UVC control is divided into non overlapping fields using
+ the 'size' and 'offset' fields and are then independently mapped to
+ V4L2 control.
+
+ For signed integer V4L2 controls the data_type field should be set to
+ UVC_CTRL_DATA_TYPE_SIGNED. Other values are currently ignored.
+
+Return value:
+ On success 0 is returned. On error -1 is returned and errno is set
+ appropriately.
+
+ ENOMEM
+ Not enough memory to perform the operation.
+ EPERM
+ Insufficient privileges (super user privileges are required).
+ EINVAL
+ No such UVC control.
+ EOVERFLOW
+ The requested offset and size would overflow the UVC control.
+ EEXIST
+ Mapping already exists.
+
+Data types:
+ * struct uvc_xu_control_mapping
+
+ __u32 id V4L2 control identifier
+ __u8 name[32] V4L2 control name
+ __u8 entity[16] UVC extension unit GUID
+ __u8 selector UVC control selector
+ __u8 size V4L2 control size (in bits)
+ __u8 offset V4L2 control offset (in bits)
+ enum v4l2_ctrl_type
+ v4l2_type V4L2 control type
+ enum uvc_control_data_type
+ data_type UVC control data type
+ struct uvc_menu_info
+ *menu_info Array of menu entries (for menu controls only)
+ __u32 menu_count Number of menu entries (for menu controls only)
+
+ * struct uvc_menu_info
+
+ __u32 value Menu entry value used by the device
+ __u8 name[32] Menu entry name
+
+
+ * enum uvc_control_data_type
+
+ UVC_CTRL_DATA_TYPE_RAW Raw control (byte array)
+ UVC_CTRL_DATA_TYPE_SIGNED Signed integer
+ UVC_CTRL_DATA_TYPE_UNSIGNED Unsigned integer
+ UVC_CTRL_DATA_TYPE_BOOLEAN Boolean
+ UVC_CTRL_DATA_TYPE_ENUM Enumeration
+ UVC_CTRL_DATA_TYPE_BITMASK Bitmask
+
+
+---- UVCIOC_CTRL_QUERY - Query a UVC XU control ----
+
+Argument: struct uvc_xu_control_query
+
+Description:
+ This ioctl queries a UVC XU control identified by its extension unit ID
+ and control selector.
+
+ There are a number of different queries available that closely
+ correspond to the low-level control requests described in the UVC
+ specification. These requests are:
+
+ UVC_GET_CUR
+ Obtain the current value of the control.
+ UVC_GET_MIN
+ Obtain the minimum value of the control.
+ UVC_GET_MAX
+ Obtain the maximum value of the control.
+ UVC_GET_DEF
+ Obtain the default value of the control.
+ UVC_GET_RES
+ Query the resolution of the control, i.e. the step size of the
+ allowed control values.
+ UVC_GET_LEN
+ Query the size of the control in bytes.
+ UVC_GET_INFO
+ Query the control information bitmap, which indicates whether
+ get/set requests are supported.
+ UVC_SET_CUR
+ Update the value of the control.
+
+ Applications must set the 'size' field to the correct length for the
+ control. Exceptions are the UVC_GET_LEN and UVC_GET_INFO queries, for
+ which the size must be set to 2 and 1, respectively. The 'data' field
+ must point to a valid writable buffer big enough to hold the indicated
+ number of data bytes.
+
+ Data is copied directly from the device without any driver-side
+ processing. Applications are responsible for data buffer formatting,
+ including little-endian/big-endian conversion. This is particularly
+ important for the result of the UVC_GET_LEN requests, which is always
+ returned as a little-endian 16-bit integer by the device.
+
+Return value:
+ On success 0 is returned. On error -1 is returned and errno is set
+ appropriately.
+
+ ENOENT
+ The device does not support the given control or the specified
+ extension unit could not be found.
+ ENOBUFS
+ The specified buffer size is incorrect (too big or too small).
+ EINVAL
+ An invalid request code was passed.
+ EBADRQC
+ The given request is not supported by the given control.
+ EFAULT
+ The data pointer references an inaccessible memory area.
+
+Data types:
+ * struct uvc_xu_control_query
+
+ __u8 unit Extension unit ID
+ __u8 selector Control selector
+ __u8 query Request code to send to the device
+ __u16 size Control data size (in bytes)
+ __u8 *data Control value
--- /dev/null
+
+infrared remote control support in video4linux drivers
+======================================================
+
+
+basics
+------
+
+Current versions use the linux input layer to support infrared
+remote controls. I suggest to download my input layer tools
+from http://bytesex.org/snapshot/input-<date>.tar.gz
+
+Modules you have to load:
+
+ saa7134 statically built in, i.e. just the driver :)
+ bttv ir-kbd-gpio or ir-kbd-i2c depending on your
+ card.
+
+ir-kbd-gpio and ir-kbd-i2c don't support all cards lirc supports
+(yet), mainly for the reason that the code of lirc_i2c and lirc_gpio
+was very confusing and I decided to basically start over from scratch.
+Feel free to contact me in case of trouble. Note that the ir-kbd-*
+modules work on 2.6.x kernels only through ...
+
+
+how it works
+------------
+
+The modules register the remote as keyboard within the linux input
+layer, i.e. you'll see the keys of the remote as normal key strokes
+(if CONFIG_INPUT_KEYBOARD is enabled).
+
+Using the event devices (CONFIG_INPUT_EVDEV) it is possible for
+applications to access the remote via /dev/input/event<n> devices.
+You might have to create the special files using "/sbin/MAKEDEV
+input". The input layer tools mentioned above use the event device.
+
+The input layer tools are nice for trouble shooting, i.e. to check
+whenever the input device is really present, which of the devices it
+is, check whenever pressing keys on the remote actually generates
+events and the like. You can also use the kbd utility to change the
+keymaps (2.6.x kernels only through).
+
+
+using with lircd
+================
+
+The cvs version of the lircd daemon supports reading events from the
+linux input layer (via event device). The input layer tools tarball
+comes with a lircd config file.
+
+
+using without lircd
+===================
+
+XFree86 likely can be configured to recognise the remote keys. Once I
+simply tried to configure one of the multimedia keyboards as input
+device, which had the effect that XFree86 recognised some of the keys
+of my remote control and passed volume up/down key presses as
+XF86AudioRaiseVolume and XF86AudioLowerVolume key events to the X11
+clients.
+
+It likely is possible to make that fly with a nice xkb config file,
+I know next to nothing about that through.
+
+
+Have fun,
+
+ Gerd
+
+--
+Gerd Knorr <kraxel@bytesex.org>
--- /dev/null
+vivid: Virtual Video Test Driver
+================================
+
+This driver emulates video4linux hardware of various types: video capture, video
+output, vbi capture and output, radio receivers and transmitters and a software
+defined radio receiver. In addition a simple framebuffer device is available for
+testing capture and output overlays.
+
+Up to 64 vivid instances can be created, each with up to 16 inputs and 16 outputs.
+
+Each input can be a webcam, TV capture device, S-Video capture device or an HDMI
+capture device. Each output can be an S-Video output device or an HDMI output
+device.
+
+These inputs and outputs act exactly as a real hardware device would behave. This
+allows you to use this driver as a test input for application development, since
+you can test the various features without requiring special hardware.
+
+This document describes the features implemented by this driver:
+
+- Support for read()/write(), MMAP, USERPTR and DMABUF streaming I/O.
+- A large list of test patterns and variations thereof
+- Working brightness, contrast, saturation and hue controls
+- Support for the alpha color component
+- Full colorspace support, including limited/full RGB range
+- All possible control types are present
+- Support for various pixel aspect ratios and video aspect ratios
+- Error injection to test what happens if errors occur
+- Supports crop/compose/scale in any combination for both input and output
+- Can emulate up to 4K resolutions
+- All Field settings are supported for testing interlaced capturing
+- Supports all standard YUV and RGB formats, including two multiplanar YUV formats
+- Raw and Sliced VBI capture and output support
+- Radio receiver and transmitter support, including RDS support
+- Software defined radio (SDR) support
+- Capture and output overlay support
+
+These features will be described in more detail below.
+
+
+Table of Contents
+-----------------
+
+Section 1: Configuring the driver
+Section 2: Video Capture
+Section 2.1: Webcam Input
+Section 2.2: TV and S-Video Inputs
+Section 2.3: HDMI Input
+Section 3: Video Output
+Section 3.1: S-Video Output
+Section 3.2: HDMI Output
+Section 4: VBI Capture
+Section 5: VBI Output
+Section 6: Radio Receiver
+Section 7: Radio Transmitter
+Section 8: Software Defined Radio Receiver
+Section 9: Controls
+Section 9.1: User Controls - Test Controls
+Section 9.2: User Controls - Video Capture
+Section 9.3: User Controls - Audio
+Section 9.4: Vivid Controls
+Section 9.4.1: Test Pattern Controls
+Section 9.4.2: Capture Feature Selection Controls
+Section 9.4.3: Output Feature Selection Controls
+Section 9.4.4: Error Injection Controls
+Section 9.4.5: VBI Raw Capture Controls
+Section 9.5: Digital Video Controls
+Section 9.6: FM Radio Receiver Controls
+Section 9.7: FM Radio Modulator
+Section 10: Video, VBI and RDS Looping
+Section 10.1: Video and Sliced VBI looping
+Section 10.2: Radio & RDS Looping
+Section 11: Cropping, Composing, Scaling
+Section 12: Formats
+Section 13: Capture Overlay
+Section 14: Output Overlay
+Section 15: CEC (Consumer Electronics Control)
+Section 16: Some Future Improvements
+
+
+Section 1: Configuring the driver
+---------------------------------
+
+By default the driver will create a single instance that has a video capture
+device with webcam, TV, S-Video and HDMI inputs, a video output device with
+S-Video and HDMI outputs, one vbi capture device, one vbi output device, one
+radio receiver device, one radio transmitter device and one SDR device.
+
+The number of instances, devices, video inputs and outputs and their types are
+all configurable using the following module options:
+
+n_devs: number of driver instances to create. By default set to 1. Up to 64
+ instances can be created.
+
+node_types: which devices should each driver instance create. An array of
+ hexadecimal values, one for each instance. The default is 0x1d3d.
+ Each value is a bitmask with the following meaning:
+ bit 0: Video Capture node
+ bit 2-3: VBI Capture node: 0 = none, 1 = raw vbi, 2 = sliced vbi, 3 = both
+ bit 4: Radio Receiver node
+ bit 5: Software Defined Radio Receiver node
+ bit 8: Video Output node
+ bit 10-11: VBI Output node: 0 = none, 1 = raw vbi, 2 = sliced vbi, 3 = both
+ bit 12: Radio Transmitter node
+ bit 16: Framebuffer for testing overlays
+
+ So to create four instances, the first two with just one video capture
+ device, the second two with just one video output device you would pass
+ these module options to vivid:
+
+ n_devs=4 node_types=0x1,0x1,0x100,0x100
+
+num_inputs: the number of inputs, one for each instance. By default 4 inputs
+ are created for each video capture device. At most 16 inputs can be created,
+ and there must be at least one.
+
+input_types: the input types for each instance, the default is 0xe4. This defines
+ what the type of each input is when the inputs are created for each driver
+ instance. This is a hexadecimal value with up to 16 pairs of bits, each
+ pair gives the type and bits 0-1 map to input 0, bits 2-3 map to input 1,
+ 30-31 map to input 15. Each pair of bits has the following meaning:
+
+ 00: this is a webcam input
+ 01: this is a TV tuner input
+ 10: this is an S-Video input
+ 11: this is an HDMI input
+
+ So to create a video capture device with 8 inputs where input 0 is a TV
+ tuner, inputs 1-3 are S-Video inputs and inputs 4-7 are HDMI inputs you
+ would use the following module options:
+
+ num_inputs=8 input_types=0xffa9
+
+num_outputs: the number of outputs, one for each instance. By default 2 outputs
+ are created for each video output device. At most 16 outputs can be
+ created, and there must be at least one.
+
+output_types: the output types for each instance, the default is 0x02. This defines
+ what the type of each output is when the outputs are created for each
+ driver instance. This is a hexadecimal value with up to 16 bits, each bit
+ gives the type and bit 0 maps to output 0, bit 1 maps to output 1, bit
+ 15 maps to output 15. The meaning of each bit is as follows:
+
+ 0: this is an S-Video output
+ 1: this is an HDMI output
+
+ So to create a video output device with 8 outputs where outputs 0-3 are
+ S-Video outputs and outputs 4-7 are HDMI outputs you would use the
+ following module options:
+
+ num_outputs=8 output_types=0xf0
+
+vid_cap_nr: give the desired videoX start number for each video capture device.
+ The default is -1 which will just take the first free number. This allows
+ you to map capture video nodes to specific videoX device nodes. Example:
+
+ n_devs=4 vid_cap_nr=2,4,6,8
+
+ This will attempt to assign /dev/video2 for the video capture device of
+ the first vivid instance, video4 for the next up to video8 for the last
+ instance. If it can't succeed, then it will just take the next free
+ number.
+
+vid_out_nr: give the desired videoX start number for each video output device.
+ The default is -1 which will just take the first free number.
+
+vbi_cap_nr: give the desired vbiX start number for each vbi capture device.
+ The default is -1 which will just take the first free number.
+
+vbi_out_nr: give the desired vbiX start number for each vbi output device.
+ The default is -1 which will just take the first free number.
+
+radio_rx_nr: give the desired radioX start number for each radio receiver device.
+ The default is -1 which will just take the first free number.
+
+radio_tx_nr: give the desired radioX start number for each radio transmitter
+ device. The default is -1 which will just take the first free number.
+
+sdr_cap_nr: give the desired swradioX start number for each SDR capture device.
+ The default is -1 which will just take the first free number.
+
+ccs_cap_mode: specify the allowed video capture crop/compose/scaling combination
+ for each driver instance. Video capture devices can have any combination
+ of cropping, composing and scaling capabilities and this will tell the
+ vivid driver which of those is should emulate. By default the user can
+ select this through controls.
+
+ The value is either -1 (controlled by the user) or a set of three bits,
+ each enabling (1) or disabling (0) one of the features:
+
+ bit 0: Enable crop support. Cropping will take only part of the
+ incoming picture.
+ bit 1: Enable compose support. Composing will copy the incoming
+ picture into a larger buffer.
+ bit 2: Enable scaling support. Scaling can scale the incoming
+ picture. The scaler of the vivid driver can enlarge up
+ or down to four times the original size. The scaler is
+ very simple and low-quality. Simplicity and speed were
+ key, not quality.
+
+ Note that this value is ignored by webcam inputs: those enumerate
+ discrete framesizes and that is incompatible with cropping, composing
+ or scaling.
+
+ccs_out_mode: specify the allowed video output crop/compose/scaling combination
+ for each driver instance. Video output devices can have any combination
+ of cropping, composing and scaling capabilities and this will tell the
+ vivid driver which of those is should emulate. By default the user can
+ select this through controls.
+
+ The value is either -1 (controlled by the user) or a set of three bits,
+ each enabling (1) or disabling (0) one of the features:
+
+ bit 0: Enable crop support. Cropping will take only part of the
+ outgoing buffer.
+ bit 1: Enable compose support. Composing will copy the incoming
+ buffer into a larger picture frame.
+ bit 2: Enable scaling support. Scaling can scale the incoming
+ buffer. The scaler of the vivid driver can enlarge up
+ or down to four times the original size. The scaler is
+ very simple and low-quality. Simplicity and speed were
+ key, not quality.
+
+multiplanar: select whether each device instance supports multi-planar formats,
+ and thus the V4L2 multi-planar API. By default device instances are
+ single-planar.
+
+ This module option can override that for each instance. Values are:
+
+ 1: this is a single-planar instance.
+ 2: this is a multi-planar instance.
+
+vivid_debug: enable driver debugging info
+
+no_error_inj: if set disable the error injecting controls. This option is
+ needed in order to run a tool like v4l2-compliance. Tools like that
+ exercise all controls including a control like 'Disconnect' which
+ emulates a USB disconnect, making the device inaccessible and so
+ all tests that v4l2-compliance is doing will fail afterwards.
+
+ There may be other situations as well where you want to disable the
+ error injection support of vivid. When this option is set, then the
+ controls that select crop, compose and scale behavior are also
+ removed. Unless overridden by ccs_cap_mode and/or ccs_out_mode the
+ will default to enabling crop, compose and scaling.
+
+Taken together, all these module options allow you to precisely customize
+the driver behavior and test your application with all sorts of permutations.
+It is also very suitable to emulate hardware that is not yet available, e.g.
+when developing software for a new upcoming device.
+
+
+Section 2: Video Capture
+------------------------
+
+This is probably the most frequently used feature. The video capture device
+can be configured by using the module options num_inputs, input_types and
+ccs_cap_mode (see section 1 for more detailed information), but by default
+four inputs are configured: a webcam, a TV tuner, an S-Video and an HDMI
+input, one input for each input type. Those are described in more detail
+below.
+
+Special attention has been given to the rate at which new frames become
+available. The jitter will be around 1 jiffie (that depends on the HZ
+configuration of your kernel, so usually 1/100, 1/250 or 1/1000 of a second),
+but the long-term behavior is exactly following the framerate. So a
+framerate of 59.94 Hz is really different from 60 Hz. If the framerate
+exceeds your kernel's HZ value, then you will get dropped frames, but the
+frame/field sequence counting will keep track of that so the sequence
+count will skip whenever frames are dropped.
+
+
+Section 2.1: Webcam Input
+-------------------------
+
+The webcam input supports three framesizes: 320x180, 640x360 and 1280x720. It
+supports frames per second settings of 10, 15, 25, 30, 50 and 60 fps. Which ones
+are available depends on the chosen framesize: the larger the framesize, the
+lower the maximum frames per second.
+
+The initially selected colorspace when you switch to the webcam input will be
+sRGB.
+
+
+Section 2.2: TV and S-Video Inputs
+----------------------------------
+
+The only difference between the TV and S-Video input is that the TV has a
+tuner. Otherwise they behave identically.
+
+These inputs support audio inputs as well: one TV and one Line-In. They
+both support all TV standards. If the standard is queried, then the Vivid
+controls 'Standard Signal Mode' and 'Standard' determine what
+the result will be.
+
+These inputs support all combinations of the field setting. Special care has
+been taken to faithfully reproduce how fields are handled for the different
+TV standards. This is particularly noticeable when generating a horizontally
+moving image so the temporal effect of using interlaced formats becomes clearly
+visible. For 50 Hz standards the top field is the oldest and the bottom field
+is the newest in time. For 60 Hz standards that is reversed: the bottom field
+is the oldest and the top field is the newest in time.
+
+When you start capturing in V4L2_FIELD_ALTERNATE mode the first buffer will
+contain the top field for 50 Hz standards and the bottom field for 60 Hz
+standards. This is what capture hardware does as well.
+
+Finally, for PAL/SECAM standards the first half of the top line contains noise.
+This simulates the Wide Screen Signal that is commonly placed there.
+
+The initially selected colorspace when you switch to the TV or S-Video input
+will be SMPTE-170M.
+
+The pixel aspect ratio will depend on the TV standard. The video aspect ratio
+can be selected through the 'Standard Aspect Ratio' Vivid control.
+Choices are '4x3', '16x9' which will give letterboxed widescreen video and
+'16x9 Anamorphic' which will give full screen squashed anamorphic widescreen
+video that will need to be scaled accordingly.
+
+The TV 'tuner' supports a frequency range of 44-958 MHz. Channels are available
+every 6 MHz, starting from 49.25 MHz. For each channel the generated image
+will be in color for the +/- 0.25 MHz around it, and in grayscale for
++/- 1 MHz around the channel. Beyond that it is just noise. The VIDIOC_G_TUNER
+ioctl will return 100% signal strength for +/- 0.25 MHz and 50% for +/- 1 MHz.
+It will also return correct afc values to show whether the frequency is too
+low or too high.
+
+The audio subchannels that are returned are MONO for the +/- 1 MHz range around
+a valid channel frequency. When the frequency is within +/- 0.25 MHz of the
+channel it will return either MONO, STEREO, either MONO | SAP (for NTSC) or
+LANG1 | LANG2 (for others), or STEREO | SAP.
+
+Which one is returned depends on the chosen channel, each next valid channel
+will cycle through the possible audio subchannel combinations. This allows
+you to test the various combinations by just switching channels..
+
+Finally, for these inputs the v4l2_timecode struct is filled in in the
+dequeued v4l2_buffer struct.
+
+
+Section 2.3: HDMI Input
+-----------------------
+
+The HDMI inputs supports all CEA-861 and DMT timings, both progressive and
+interlaced, for pixelclock frequencies between 25 and 600 MHz. The field
+mode for interlaced formats is always V4L2_FIELD_ALTERNATE. For HDMI the
+field order is always top field first, and when you start capturing an
+interlaced format you will receive the top field first.
+
+The initially selected colorspace when you switch to the HDMI input or
+select an HDMI timing is based on the format resolution: for resolutions
+less than or equal to 720x576 the colorspace is set to SMPTE-170M, for
+others it is set to REC-709 (CEA-861 timings) or sRGB (VESA DMT timings).
+
+The pixel aspect ratio will depend on the HDMI timing: for 720x480 is it
+set as for the NTSC TV standard, for 720x576 it is set as for the PAL TV
+standard, and for all others a 1:1 pixel aspect ratio is returned.
+
+The video aspect ratio can be selected through the 'DV Timings Aspect Ratio'
+Vivid control. Choices are 'Source Width x Height' (just use the
+same ratio as the chosen format), '4x3' or '16x9', either of which can
+result in pillarboxed or letterboxed video.
+
+For HDMI inputs it is possible to set the EDID. By default a simple EDID
+is provided. You can only set the EDID for HDMI inputs. Internally, however,
+the EDID is shared between all HDMI inputs.
+
+No interpretation is done of the EDID data with the exception of the
+physical address. See the CEC section for more details.
+
+There is a maximum of 15 HDMI inputs (if there are more, then they will be
+reduced to 15) since that's the limitation of the EDID physical address.
+
+
+Section 3: Video Output
+-----------------------
+
+The video output device can be configured by using the module options
+num_outputs, output_types and ccs_out_mode (see section 1 for more detailed
+information), but by default two outputs are configured: an S-Video and an
+HDMI input, one output for each output type. Those are described in more detail
+below.
+
+Like with video capture the framerate is also exact in the long term.
+
+
+Section 3.1: S-Video Output
+---------------------------
+
+This output supports audio outputs as well: "Line-Out 1" and "Line-Out 2".
+The S-Video output supports all TV standards.
+
+This output supports all combinations of the field setting.
+
+The initially selected colorspace when you switch to the TV or S-Video input
+will be SMPTE-170M.
+
+
+Section 3.2: HDMI Output
+------------------------
+
+The HDMI output supports all CEA-861 and DMT timings, both progressive and
+interlaced, for pixelclock frequencies between 25 and 600 MHz. The field
+mode for interlaced formats is always V4L2_FIELD_ALTERNATE.
+
+The initially selected colorspace when you switch to the HDMI output or
+select an HDMI timing is based on the format resolution: for resolutions
+less than or equal to 720x576 the colorspace is set to SMPTE-170M, for
+others it is set to REC-709 (CEA-861 timings) or sRGB (VESA DMT timings).
+
+The pixel aspect ratio will depend on the HDMI timing: for 720x480 is it
+set as for the NTSC TV standard, for 720x576 it is set as for the PAL TV
+standard, and for all others a 1:1 pixel aspect ratio is returned.
+
+An HDMI output has a valid EDID which can be obtained through VIDIOC_G_EDID.
+
+There is a maximum of 15 HDMI outputs (if there are more, then they will be
+reduced to 15) since that's the limitation of the EDID physical address. See
+also the CEC section for more details.
+
+Section 4: VBI Capture
+----------------------
+
+There are three types of VBI capture devices: those that only support raw
+(undecoded) VBI, those that only support sliced (decoded) VBI and those that
+support both. This is determined by the node_types module option. In all
+cases the driver will generate valid VBI data: for 60 Hz standards it will
+generate Closed Caption and XDS data. The closed caption stream will
+alternate between "Hello world!" and "Closed captions test" every second.
+The XDS stream will give the current time once a minute. For 50 Hz standards
+it will generate the Wide Screen Signal which is based on the actual Video
+Aspect Ratio control setting and teletext pages 100-159, one page per frame.
+
+The VBI device will only work for the S-Video and TV inputs, it will give
+back an error if the current input is a webcam or HDMI.
+
+
+Section 5: VBI Output
+---------------------
+
+There are three types of VBI output devices: those that only support raw
+(undecoded) VBI, those that only support sliced (decoded) VBI and those that
+support both. This is determined by the node_types module option.
+
+The sliced VBI output supports the Wide Screen Signal and the teletext signal
+for 50 Hz standards and Closed Captioning + XDS for 60 Hz standards.
+
+The VBI device will only work for the S-Video output, it will give
+back an error if the current output is HDMI.
+
+
+Section 6: Radio Receiver
+-------------------------
+
+The radio receiver emulates an FM/AM/SW receiver. The FM band also supports RDS.
+The frequency ranges are:
+
+ FM: 64 MHz - 108 MHz
+ AM: 520 kHz - 1710 kHz
+ SW: 2300 kHz - 26.1 MHz
+
+Valid channels are emulated every 1 MHz for FM and every 100 kHz for AM and SW.
+The signal strength decreases the further the frequency is from the valid
+frequency until it becomes 0% at +/- 50 kHz (FM) or 5 kHz (AM/SW) from the
+ideal frequency. The initial frequency when the driver is loaded is set to
+95 MHz.
+
+The FM receiver supports RDS as well, both using 'Block I/O' and 'Controls'
+modes. In the 'Controls' mode the RDS information is stored in read-only
+controls. These controls are updated every time the frequency is changed,
+or when the tuner status is requested. The Block I/O method uses the read()
+interface to pass the RDS blocks on to the application for decoding.
+
+The RDS signal is 'detected' for +/- 12.5 kHz around the channel frequency,
+and the further the frequency is away from the valid frequency the more RDS
+errors are randomly introduced into the block I/O stream, up to 50% of all
+blocks if you are +/- 12.5 kHz from the channel frequency. All four errors
+can occur in equal proportions: blocks marked 'CORRECTED', blocks marked
+'ERROR', blocks marked 'INVALID' and dropped blocks.
+
+The generated RDS stream contains all the standard fields contained in a
+0B group, and also radio text and the current time.
+
+The receiver supports HW frequency seek, either in Bounded mode, Wrap Around
+mode or both, which is configurable with the "Radio HW Seek Mode" control.
+
+
+Section 7: Radio Transmitter
+----------------------------
+
+The radio transmitter emulates an FM/AM/SW transmitter. The FM band also supports RDS.
+The frequency ranges are:
+
+ FM: 64 MHz - 108 MHz
+ AM: 520 kHz - 1710 kHz
+ SW: 2300 kHz - 26.1 MHz
+
+The initial frequency when the driver is loaded is 95.5 MHz.
+
+The FM transmitter supports RDS as well, both using 'Block I/O' and 'Controls'
+modes. In the 'Controls' mode the transmitted RDS information is configured
+using controls, and in 'Block I/O' mode the blocks are passed to the driver
+using write().
+
+
+Section 8: Software Defined Radio Receiver
+------------------------------------------
+
+The SDR receiver has three frequency bands for the ADC tuner:
+
+ - 300 kHz
+ - 900 kHz - 2800 kHz
+ - 3200 kHz
+
+The RF tuner supports 50 MHz - 2000 MHz.
+
+The generated data contains the In-phase and Quadrature components of a
+1 kHz tone that has an amplitude of sqrt(2).
+
+
+Section 9: Controls
+-------------------
+
+Different devices support different controls. The sections below will describe
+each control and which devices support them.
+
+
+Section 9.1: User Controls - Test Controls
+------------------------------------------
+
+The Button, Boolean, Integer 32 Bits, Integer 64 Bits, Menu, String, Bitmask and
+Integer Menu are controls that represent all possible control types. The Menu
+control and the Integer Menu control both have 'holes' in their menu list,
+meaning that one or more menu items return EINVAL when VIDIOC_QUERYMENU is called.
+Both menu controls also have a non-zero minimum control value. These features
+allow you to check if your application can handle such things correctly.
+These controls are supported for every device type.
+
+
+Section 9.2: User Controls - Video Capture
+------------------------------------------
+
+The following controls are specific to video capture.
+
+The Brightness, Contrast, Saturation and Hue controls actually work and are
+standard. There is one special feature with the Brightness control: each
+video input has its own brightness value, so changing input will restore
+the brightness for that input. In addition, each video input uses a different
+brightness range (minimum and maximum control values). Switching inputs will
+cause a control event to be sent with the V4L2_EVENT_CTRL_CH_RANGE flag set.
+This allows you to test controls that can change their range.
+
+The 'Gain, Automatic' and Gain controls can be used to test volatile controls:
+if 'Gain, Automatic' is set, then the Gain control is volatile and changes
+constantly. If 'Gain, Automatic' is cleared, then the Gain control is a normal
+control.
+
+The 'Horizontal Flip' and 'Vertical Flip' controls can be used to flip the
+image. These combine with the 'Sensor Flipped Horizontally/Vertically' Vivid
+controls.
+
+The 'Alpha Component' control can be used to set the alpha component for
+formats containing an alpha channel.
+
+
+Section 9.3: User Controls - Audio
+----------------------------------
+
+The following controls are specific to video capture and output and radio
+receivers and transmitters.
+
+The 'Volume' and 'Mute' audio controls are typical for such devices to
+control the volume and mute the audio. They don't actually do anything in
+the vivid driver.
+
+
+Section 9.4: Vivid Controls
+---------------------------
+
+These vivid custom controls control the image generation, error injection, etc.
+
+
+Section 9.4.1: Test Pattern Controls
+------------------------------------
+
+The Test Pattern Controls are all specific to video capture.
+
+Test Pattern: selects which test pattern to use. Use the CSC Colorbar for
+ testing colorspace conversions: the colors used in that test pattern
+ map to valid colors in all colorspaces. The colorspace conversion
+ is disabled for the other test patterns.
+
+OSD Text Mode: selects whether the text superimposed on the
+ test pattern should be shown, and if so, whether only counters should
+ be displayed or the full text.
+
+Horizontal Movement: selects whether the test pattern should
+ move to the left or right and at what speed.
+
+Vertical Movement: does the same for the vertical direction.
+
+Show Border: show a two-pixel wide border at the edge of the actual image,
+ excluding letter or pillarboxing.
+
+Show Square: show a square in the middle of the image. If the image is
+ displayed with the correct pixel and image aspect ratio corrections,
+ then the width and height of the square on the monitor should be
+ the same.
+
+Insert SAV Code in Image: adds a SAV (Start of Active Video) code to the image.
+ This can be used to check if such codes in the image are inadvertently
+ interpreted instead of being ignored.
+
+Insert EAV Code in Image: does the same for the EAV (End of Active Video) code.
+
+
+Section 9.4.2: Capture Feature Selection Controls
+-------------------------------------------------
+
+These controls are all specific to video capture.
+
+Sensor Flipped Horizontally: the image is flipped horizontally and the
+ V4L2_IN_ST_HFLIP input status flag is set. This emulates the case where
+ a sensor is for example mounted upside down.
+
+Sensor Flipped Vertically: the image is flipped vertically and the
+ V4L2_IN_ST_VFLIP input status flag is set. This emulates the case where
+ a sensor is for example mounted upside down.
+
+Standard Aspect Ratio: selects if the image aspect ratio as used for the TV or
+ S-Video input should be 4x3, 16x9 or anamorphic widescreen. This may
+ introduce letterboxing.
+
+DV Timings Aspect Ratio: selects if the image aspect ratio as used for the HDMI
+ input should be the same as the source width and height ratio, or if
+ it should be 4x3 or 16x9. This may introduce letter or pillarboxing.
+
+Timestamp Source: selects when the timestamp for each buffer is taken.
+
+Colorspace: selects which colorspace should be used when generating the image.
+ This only applies if the CSC Colorbar test pattern is selected,
+ otherwise the test pattern will go through unconverted.
+ This behavior is also what you want, since a 75% Colorbar
+ should really have 75% signal intensity and should not be affected
+ by colorspace conversions.
+
+ Changing the colorspace will result in the V4L2_EVENT_SOURCE_CHANGE
+ to be sent since it emulates a detected colorspace change.
+
+Transfer Function: selects which colorspace transfer function should be used when
+ generating an image. This only applies if the CSC Colorbar test pattern is
+ selected, otherwise the test pattern will go through unconverted.
+ This behavior is also what you want, since a 75% Colorbar
+ should really have 75% signal intensity and should not be affected
+ by colorspace conversions.
+
+ Changing the transfer function will result in the V4L2_EVENT_SOURCE_CHANGE
+ to be sent since it emulates a detected colorspace change.
+
+Y'CbCr Encoding: selects which Y'CbCr encoding should be used when generating
+ a Y'CbCr image. This only applies if the format is set to a Y'CbCr format
+ as opposed to an RGB format.
+
+ Changing the Y'CbCr encoding will result in the V4L2_EVENT_SOURCE_CHANGE
+ to be sent since it emulates a detected colorspace change.
+
+Quantization: selects which quantization should be used for the RGB or Y'CbCr
+ encoding when generating the test pattern.
+
+ Changing the quantization will result in the V4L2_EVENT_SOURCE_CHANGE
+ to be sent since it emulates a detected colorspace change.
+
+Limited RGB Range (16-235): selects if the RGB range of the HDMI source should
+ be limited or full range. This combines with the Digital Video 'Rx RGB
+ Quantization Range' control and can be used to test what happens if
+ a source provides you with the wrong quantization range information.
+ See the description of that control for more details.
+
+Apply Alpha To Red Only: apply the alpha channel as set by the 'Alpha Component'
+ user control to the red color of the test pattern only.
+
+Enable Capture Cropping: enables crop support. This control is only present if
+ the ccs_cap_mode module option is set to the default value of -1 and if
+ the no_error_inj module option is set to 0 (the default).
+
+Enable Capture Composing: enables composing support. This control is only
+ present if the ccs_cap_mode module option is set to the default value of
+ -1 and if the no_error_inj module option is set to 0 (the default).
+
+Enable Capture Scaler: enables support for a scaler (maximum 4 times upscaling
+ and downscaling). This control is only present if the ccs_cap_mode
+ module option is set to the default value of -1 and if the no_error_inj
+ module option is set to 0 (the default).
+
+Maximum EDID Blocks: determines how many EDID blocks the driver supports.
+ Note that the vivid driver does not actually interpret new EDID
+ data, it just stores it. It allows for up to 256 EDID blocks
+ which is the maximum supported by the standard.
+
+Fill Percentage of Frame: can be used to draw only the top X percent
+ of the image. Since each frame has to be drawn by the driver, this
+ demands a lot of the CPU. For large resolutions this becomes
+ problematic. By drawing only part of the image this CPU load can
+ be reduced.
+
+
+Section 9.4.3: Output Feature Selection Controls
+------------------------------------------------
+
+These controls are all specific to video output.
+
+Enable Output Cropping: enables crop support. This control is only present if
+ the ccs_out_mode module option is set to the default value of -1 and if
+ the no_error_inj module option is set to 0 (the default).
+
+Enable Output Composing: enables composing support. This control is only
+ present if the ccs_out_mode module option is set to the default value of
+ -1 and if the no_error_inj module option is set to 0 (the default).
+
+Enable Output Scaler: enables support for a scaler (maximum 4 times upscaling
+ and downscaling). This control is only present if the ccs_out_mode
+ module option is set to the default value of -1 and if the no_error_inj
+ module option is set to 0 (the default).
+
+
+Section 9.4.4: Error Injection Controls
+---------------------------------------
+
+The following two controls are only valid for video and vbi capture.
+
+Standard Signal Mode: selects the behavior of VIDIOC_QUERYSTD: what should
+ it return?
+
+ Changing this control will result in the V4L2_EVENT_SOURCE_CHANGE
+ to be sent since it emulates a changed input condition (e.g. a cable
+ was plugged in or out).
+
+Standard: selects the standard that VIDIOC_QUERYSTD should return if the
+ previous control is set to "Selected Standard".
+
+ Changing this control will result in the V4L2_EVENT_SOURCE_CHANGE
+ to be sent since it emulates a changed input standard.
+
+
+The following two controls are only valid for video capture.
+
+DV Timings Signal Mode: selects the behavior of VIDIOC_QUERY_DV_TIMINGS: what
+ should it return?
+
+ Changing this control will result in the V4L2_EVENT_SOURCE_CHANGE
+ to be sent since it emulates a changed input condition (e.g. a cable
+ was plugged in or out).
+
+DV Timings: selects the timings the VIDIOC_QUERY_DV_TIMINGS should return
+ if the previous control is set to "Selected DV Timings".
+
+ Changing this control will result in the V4L2_EVENT_SOURCE_CHANGE
+ to be sent since it emulates changed input timings.
+
+
+The following controls are only present if the no_error_inj module option
+is set to 0 (the default). These controls are valid for video and vbi
+capture and output streams and for the SDR capture device except for the
+Disconnect control which is valid for all devices.
+
+Wrap Sequence Number: test what happens when you wrap the sequence number in
+ struct v4l2_buffer around.
+
+Wrap Timestamp: test what happens when you wrap the timestamp in struct
+ v4l2_buffer around.
+
+Percentage of Dropped Buffers: sets the percentage of buffers that
+ are never returned by the driver (i.e., they are dropped).
+
+Disconnect: emulates a USB disconnect. The device will act as if it has
+ been disconnected. Only after all open filehandles to the device
+ node have been closed will the device become 'connected' again.
+
+Inject V4L2_BUF_FLAG_ERROR: when pressed, the next frame returned by
+ the driver will have the error flag set (i.e. the frame is marked
+ corrupt).
+
+Inject VIDIOC_REQBUFS Error: when pressed, the next REQBUFS or CREATE_BUFS
+ ioctl call will fail with an error. To be precise: the videobuf2
+ queue_setup() op will return -EINVAL.
+
+Inject VIDIOC_QBUF Error: when pressed, the next VIDIOC_QBUF or
+ VIDIOC_PREPARE_BUFFER ioctl call will fail with an error. To be
+ precise: the videobuf2 buf_prepare() op will return -EINVAL.
+
+Inject VIDIOC_STREAMON Error: when pressed, the next VIDIOC_STREAMON ioctl
+ call will fail with an error. To be precise: the videobuf2
+ start_streaming() op will return -EINVAL.
+
+Inject Fatal Streaming Error: when pressed, the streaming core will be
+ marked as having suffered a fatal error, the only way to recover
+ from that is to stop streaming. To be precise: the videobuf2
+ vb2_queue_error() function is called.
+
+
+Section 9.4.5: VBI Raw Capture Controls
+---------------------------------------
+
+Interlaced VBI Format: if set, then the raw VBI data will be interlaced instead
+ of providing it grouped by field.
+
+
+Section 9.5: Digital Video Controls
+-----------------------------------
+
+Rx RGB Quantization Range: sets the RGB quantization detection of the HDMI
+ input. This combines with the Vivid 'Limited RGB Range (16-235)'
+ control and can be used to test what happens if a source provides
+ you with the wrong quantization range information. This can be tested
+ by selecting an HDMI input, setting this control to Full or Limited
+ range and selecting the opposite in the 'Limited RGB Range (16-235)'
+ control. The effect is easy to see if the 'Gray Ramp' test pattern
+ is selected.
+
+Tx RGB Quantization Range: sets the RGB quantization detection of the HDMI
+ output. It is currently not used for anything in vivid, but most HDMI
+ transmitters would typically have this control.
+
+Transmit Mode: sets the transmit mode of the HDMI output to HDMI or DVI-D. This
+ affects the reported colorspace since DVI_D outputs will always use
+ sRGB.
+
+
+Section 9.6: FM Radio Receiver Controls
+---------------------------------------
+
+RDS Reception: set if the RDS receiver should be enabled.
+
+RDS Program Type:
+RDS PS Name:
+RDS Radio Text:
+RDS Traffic Announcement:
+RDS Traffic Program:
+RDS Music: these are all read-only controls. If RDS Rx I/O Mode is set to
+ "Block I/O", then they are inactive as well. If RDS Rx I/O Mode is set
+ to "Controls", then these controls report the received RDS data. Note
+ that the vivid implementation of this is pretty basic: they are only
+ updated when you set a new frequency or when you get the tuner status
+ (VIDIOC_G_TUNER).
+
+Radio HW Seek Mode: can be one of "Bounded", "Wrap Around" or "Both". This
+ determines if VIDIOC_S_HW_FREQ_SEEK will be bounded by the frequency
+ range or wrap-around or if it is selectable by the user.
+
+Radio Programmable HW Seek: if set, then the user can provide the lower and
+ upper bound of the HW Seek. Otherwise the frequency range boundaries
+ will be used.
+
+Generate RBDS Instead of RDS: if set, then generate RBDS (the US variant of
+ RDS) data instead of RDS (European-style RDS). This affects only the
+ PICODE and PTY codes.
+
+RDS Rx I/O Mode: this can be "Block I/O" where the RDS blocks have to be read()
+ by the application, or "Controls" where the RDS data is provided by
+ the RDS controls mentioned above.
+
+
+Section 9.7: FM Radio Modulator Controls
+----------------------------------------
+
+RDS Program ID:
+RDS Program Type:
+RDS PS Name:
+RDS Radio Text:
+RDS Stereo:
+RDS Artificial Head:
+RDS Compressed:
+RDS Dynamic PTY:
+RDS Traffic Announcement:
+RDS Traffic Program:
+RDS Music: these are all controls that set the RDS data that is transmitted by
+ the FM modulator.
+
+RDS Tx I/O Mode: this can be "Block I/O" where the application has to use write()
+ to pass the RDS blocks to the driver, or "Controls" where the RDS data is
+ provided by the RDS controls mentioned above.
+
+
+Section 10: Video, VBI and RDS Looping
+--------------------------------------
+
+The vivid driver supports looping of video output to video input, VBI output
+to VBI input and RDS output to RDS input. For video/VBI looping this emulates
+as if a cable was hooked up between the output and input connector. So video
+and VBI looping is only supported between S-Video and HDMI inputs and outputs.
+VBI is only valid for S-Video as it makes no sense for HDMI.
+
+Since radio is wireless this looping always happens if the radio receiver
+frequency is close to the radio transmitter frequency. In that case the radio
+transmitter will 'override' the emulated radio stations.
+
+Looping is currently supported only between devices created by the same
+vivid driver instance.
+
+
+Section 10.1: Video and Sliced VBI looping
+------------------------------------------
+
+The way to enable video/VBI looping is currently fairly crude. A 'Loop Video'
+control is available in the "Vivid" control class of the video
+capture and VBI capture devices. When checked the video looping will be enabled.
+Once enabled any video S-Video or HDMI input will show a static test pattern
+until the video output has started. At that time the video output will be
+looped to the video input provided that:
+
+- the input type matches the output type. So the HDMI input cannot receive
+ video from the S-Video output.
+
+- the video resolution of the video input must match that of the video output.
+ So it is not possible to loop a 50 Hz (720x576) S-Video output to a 60 Hz
+ (720x480) S-Video input, or a 720p60 HDMI output to a 1080p30 input.
+
+- the pixel formats must be identical on both sides. Otherwise the driver would
+ have to do pixel format conversion as well, and that's taking things too far.
+
+- the field settings must be identical on both sides. Same reason as above:
+ requiring the driver to convert from one field format to another complicated
+ matters too much. This also prohibits capturing with 'Field Top' or 'Field
+ Bottom' when the output video is set to 'Field Alternate'. This combination,
+ while legal, became too complicated to support. Both sides have to be 'Field
+ Alternate' for this to work. Also note that for this specific case the
+ sequence and field counting in struct v4l2_buffer on the capture side may not
+ be 100% accurate.
+
+- field settings V4L2_FIELD_SEQ_TB/BT are not supported. While it is possible to
+ implement this, it would mean a lot of work to get this right. Since these
+ field values are rarely used the decision was made not to implement this for
+ now.
+
+- on the input side the "Standard Signal Mode" for the S-Video input or the
+ "DV Timings Signal Mode" for the HDMI input should be configured so that a
+ valid signal is passed to the video input.
+
+The framerates do not have to match, although this might change in the future.
+
+By default you will see the OSD text superimposed on top of the looped video.
+This can be turned off by changing the "OSD Text Mode" control of the video
+capture device.
+
+For VBI looping to work all of the above must be valid and in addition the vbi
+output must be configured for sliced VBI. The VBI capture side can be configured
+for either raw or sliced VBI. Note that at the moment only CC/XDS (60 Hz formats)
+and WSS (50 Hz formats) VBI data is looped. Teletext VBI data is not looped.
+
+
+Section 10.2: Radio & RDS Looping
+---------------------------------
+
+As mentioned in section 6 the radio receiver emulates stations are regular
+frequency intervals. Depending on the frequency of the radio receiver a
+signal strength value is calculated (this is returned by VIDIOC_G_TUNER).
+However, it will also look at the frequency set by the radio transmitter and
+if that results in a higher signal strength than the settings of the radio
+transmitter will be used as if it was a valid station. This also includes
+the RDS data (if any) that the transmitter 'transmits'. This is received
+faithfully on the receiver side. Note that when the driver is loaded the
+frequencies of the radio receiver and transmitter are not identical, so
+initially no looping takes place.
+
+
+Section 11: Cropping, Composing, Scaling
+----------------------------------------
+
+This driver supports cropping, composing and scaling in any combination. Normally
+which features are supported can be selected through the Vivid controls,
+but it is also possible to hardcode it when the module is loaded through the
+ccs_cap_mode and ccs_out_mode module options. See section 1 on the details of
+these module options.
+
+This allows you to test your application for all these variations.
+
+Note that the webcam input never supports cropping, composing or scaling. That
+only applies to the TV/S-Video/HDMI inputs and outputs. The reason is that
+webcams, including this virtual implementation, normally use
+VIDIOC_ENUM_FRAMESIZES to list a set of discrete framesizes that it supports.
+And that does not combine with cropping, composing or scaling. This is
+primarily a limitation of the V4L2 API which is carefully reproduced here.
+
+The minimum and maximum resolutions that the scaler can achieve are 16x16 and
+(4096 * 4) x (2160 x 4), but it can only scale up or down by a factor of 4 or
+less. So for a source resolution of 1280x720 the minimum the scaler can do is
+320x180 and the maximum is 5120x2880. You can play around with this using the
+qv4l2 test tool and you will see these dependencies.
+
+This driver also supports larger 'bytesperline' settings, something that
+VIDIOC_S_FMT allows but that few drivers implement.
+
+The scaler is a simple scaler that uses the Coarse Bresenham algorithm. It's
+designed for speed and simplicity, not quality.
+
+If the combination of crop, compose and scaling allows it, then it is possible
+to change crop and compose rectangles on the fly.
+
+
+Section 12: Formats
+-------------------
+
+The driver supports all the regular packed and planar 4:4:4, 4:2:2 and 4:2:0
+YUYV formats, 8, 16, 24 and 32 RGB packed formats and various multiplanar
+formats.
+
+The alpha component can be set through the 'Alpha Component' User control
+for those formats that support it. If the 'Apply Alpha To Red Only' control
+is set, then the alpha component is only used for the color red and set to
+0 otherwise.
+
+The driver has to be configured to support the multiplanar formats. By default
+the driver instances are single-planar. This can be changed by setting the
+multiplanar module option, see section 1 for more details on that option.
+
+If the driver instance is using the multiplanar formats/API, then the first
+single planar format (YUYV) and the multiplanar NV16M and NV61M formats the
+will have a plane that has a non-zero data_offset of 128 bytes. It is rare for
+data_offset to be non-zero, so this is a useful feature for testing applications.
+
+Video output will also honor any data_offset that the application set.
+
+
+Section 13: Capture Overlay
+---------------------------
+
+Note: capture overlay support is implemented primarily to test the existing
+V4L2 capture overlay API. In practice few if any GPUs support such overlays
+anymore, and neither are they generally needed anymore since modern hardware
+is so much more capable. By setting flag 0x10000 in the node_types module
+option the vivid driver will create a simple framebuffer device that can be
+used for testing this API. Whether this API should be used for new drivers is
+questionable.
+
+This driver has support for a destructive capture overlay with bitmap clipping
+and list clipping (up to 16 rectangles) capabilities. Overlays are not
+supported for multiplanar formats. It also honors the struct v4l2_window field
+setting: if it is set to FIELD_TOP or FIELD_BOTTOM and the capture setting is
+FIELD_ALTERNATE, then only the top or bottom fields will be copied to the overlay.
+
+The overlay only works if you are also capturing at that same time. This is a
+vivid limitation since it copies from a buffer to the overlay instead of
+filling the overlay directly. And if you are not capturing, then no buffers
+are available to fill.
+
+In addition, the pixelformat of the capture format and that of the framebuffer
+must be the same for the overlay to work. Otherwise VIDIOC_OVERLAY will return
+an error.
+
+In order to really see what it going on you will need to create two vivid
+instances: the first with a framebuffer enabled. You configure the capture
+overlay of the second instance to use the framebuffer of the first, then
+you start capturing in the second instance. For the first instance you setup
+the output overlay for the video output, turn on video looping and capture
+to see the blended framebuffer overlay that's being written to by the second
+instance. This setup would require the following commands:
+
+ $ sudo modprobe vivid n_devs=2 node_types=0x10101,0x1
+ $ v4l2-ctl -d1 --find-fb
+ /dev/fb1 is the framebuffer associated with base address 0x12800000
+ $ sudo v4l2-ctl -d2 --set-fbuf fb=1
+ $ v4l2-ctl -d1 --set-fbuf fb=1
+ $ v4l2-ctl -d0 --set-fmt-video=pixelformat='AR15'
+ $ v4l2-ctl -d1 --set-fmt-video-out=pixelformat='AR15'
+ $ v4l2-ctl -d2 --set-fmt-video=pixelformat='AR15'
+ $ v4l2-ctl -d0 -i2
+ $ v4l2-ctl -d2 -i2
+ $ v4l2-ctl -d2 -c horizontal_movement=4
+ $ v4l2-ctl -d1 --overlay=1
+ $ v4l2-ctl -d1 -c loop_video=1
+ $ v4l2-ctl -d2 --stream-mmap --overlay=1
+
+And from another console:
+
+ $ v4l2-ctl -d1 --stream-out-mmap
+
+And yet another console:
+
+ $ qv4l2
+
+and start streaming.
+
+As you can see, this is not for the faint of heart...
+
+
+Section 14: Output Overlay
+--------------------------
+
+Note: output overlays are primarily implemented in order to test the existing
+V4L2 output overlay API. Whether this API should be used for new drivers is
+questionable.
+
+This driver has support for an output overlay and is capable of:
+
+ - bitmap clipping,
+ - list clipping (up to 16 rectangles)
+ - chromakey
+ - source chromakey
+ - global alpha
+ - local alpha
+ - local inverse alpha
+
+Output overlays are not supported for multiplanar formats. In addition, the
+pixelformat of the capture format and that of the framebuffer must be the
+same for the overlay to work. Otherwise VIDIOC_OVERLAY will return an error.
+
+Output overlays only work if the driver has been configured to create a
+framebuffer by setting flag 0x10000 in the node_types module option. The
+created framebuffer has a size of 720x576 and supports ARGB 1:5:5:5 and
+RGB 5:6:5.
+
+In order to see the effects of the various clipping, chromakeying or alpha
+processing capabilities you need to turn on video looping and see the results
+on the capture side. The use of the clipping, chromakeying or alpha processing
+capabilities will slow down the video loop considerably as a lot of checks have
+to be done per pixel.
+
+
+Section 15: CEC (Consumer Electronics Control)
+----------------------------------------------
+
+If there are HDMI inputs then a CEC adapter will be created that has
+the same number of input ports. This is the equivalent of e.g. a TV that
+has that number of inputs. Each HDMI output will also create a
+CEC adapter that is hooked up to the corresponding input port, or (if there
+are more outputs than inputs) is not hooked up at all. In other words,
+this is the equivalent of hooking up each output device to an input port of
+the TV. Any remaining output devices remain unconnected.
+
+The EDID that each output reads reports a unique CEC physical address that is
+based on the physical address of the EDID of the input. So if the EDID of the
+receiver has physical address A.B.0.0, then each output will see an EDID
+containing physical address A.B.C.0 where C is 1 to the number of inputs. If
+there are more outputs than inputs then the remaining outputs have a CEC adapter
+that is disabled and reports an invalid physical address.
+
+
+Section 16: Some Future Improvements
+------------------------------------
+
+Just as a reminder and in no particular order:
+
+- Add a virtual alsa driver to test audio
+- Add virtual sub-devices and media controller support
+- Some support for testing compressed video
+- Add support to loop raw VBI output to raw VBI input
+- Add support to loop teletext sliced VBI output to VBI input
+- Fix sequence/field numbering when looping of video with alternate fields
+- Add support for V4L2_CID_BG_COLOR for video outputs
+- Add ARGB888 overlay support: better testing of the alpha channel
+- Improve pixel aspect support in the tpg code by passing a real v4l2_fract
+- Use per-queue locks and/or per-device locks to improve throughput
+- Add support to loop from a specific output to a specific input across
+ vivid instances
+- The SDR radio should use the same 'frequencies' for stations as the normal
+ radio receiver, and give back noise if the frequency doesn't match up with
+ a station frequency
+- Make a thread for the RDS generation, that would help in particular for the
+ "Controls" RDS Rx I/O Mode as the read-only RDS controls could be updated
+ in real-time.
+- Changing the EDID should cause hotplug detect emulation to happen.
--- /dev/null
+Frequently Asked Questions:
+===========================
+subject: unified zoran driver (zr360x7, zoran, buz, dc10(+), dc30(+), lml33)
+website: http://mjpeg.sourceforge.net/driver-zoran/
+
+1. What cards are supported
+1.1 What the TV decoder can do an what not
+1.2 What the TV encoder can do an what not
+2. How do I get this damn thing to work
+3. What mainboard should I use (or why doesn't my card work)
+4. Programming interface
+5. Applications
+6. Concerning buffer sizes, quality, output size etc.
+7. It hangs/crashes/fails/whatevers! Help!
+8. Maintainers/Contacting
+9. License
+
+===========================
+
+1. What cards are supported
+
+Iomega Buz, Linux Media Labs LML33/LML33R10, Pinnacle/Miro
+DC10/DC10+/DC30/DC30+ and related boards (available under various names).
+
+Iomega Buz:
+* Zoran zr36067 PCI controller
+* Zoran zr36060 MJPEG codec
+* Philips saa7111 TV decoder
+* Philips saa7185 TV encoder
+Drivers to use: videodev, i2c-core, i2c-algo-bit,
+ videocodec, saa7111, saa7185, zr36060, zr36067
+Inputs/outputs: Composite and S-video
+Norms: PAL, SECAM (720x576 @ 25 fps), NTSC (720x480 @ 29.97 fps)
+Card number: 7
+
+AverMedia 6 Eyes AVS6EYES:
+* Zoran zr36067 PCI controller
+* Zoran zr36060 MJPEG codec
+* Samsung ks0127 TV decoder
+* Conexant bt866 TV encoder
+Drivers to use: videodev, i2c-core, i2c-algo-bit,
+ videocodec, ks0127, bt866, zr36060, zr36067
+Inputs/outputs: Six physical inputs. 1-6 are composite,
+ 1-2, 3-4, 5-6 doubles as S-video,
+ 1-3 triples as component.
+ One composite output.
+Norms: PAL, SECAM (720x576 @ 25 fps), NTSC (720x480 @ 29.97 fps)
+Card number: 8
+Not autodetected, card=8 is necessary.
+
+Linux Media Labs LML33:
+* Zoran zr36067 PCI controller
+* Zoran zr36060 MJPEG codec
+* Brooktree bt819 TV decoder
+* Brooktree bt856 TV encoder
+Drivers to use: videodev, i2c-core, i2c-algo-bit,
+ videocodec, bt819, bt856, zr36060, zr36067
+Inputs/outputs: Composite and S-video
+Norms: PAL (720x576 @ 25 fps), NTSC (720x480 @ 29.97 fps)
+Card number: 5
+
+Linux Media Labs LML33R10:
+* Zoran zr36067 PCI controller
+* Zoran zr36060 MJPEG codec
+* Philips saa7114 TV decoder
+* Analog Devices adv7170 TV encoder
+Drivers to use: videodev, i2c-core, i2c-algo-bit,
+ videocodec, saa7114, adv7170, zr36060, zr36067
+Inputs/outputs: Composite and S-video
+Norms: PAL (720x576 @ 25 fps), NTSC (720x480 @ 29.97 fps)
+Card number: 6
+
+Pinnacle/Miro DC10(new):
+* Zoran zr36057 PCI controller
+* Zoran zr36060 MJPEG codec
+* Philips saa7110a TV decoder
+* Analog Devices adv7176 TV encoder
+Drivers to use: videodev, i2c-core, i2c-algo-bit,
+ videocodec, saa7110, adv7175, zr36060, zr36067
+Inputs/outputs: Composite, S-video and Internal
+Norms: PAL, SECAM (768x576 @ 25 fps), NTSC (640x480 @ 29.97 fps)
+Card number: 1
+
+Pinnacle/Miro DC10+:
+* Zoran zr36067 PCI controller
+* Zoran zr36060 MJPEG codec
+* Philips saa7110a TV decoder
+* Analog Devices adv7176 TV encoder
+Drivers to use: videodev, i2c-core, i2c-algo-bit,
+ videocodec, sa7110, adv7175, zr36060, zr36067
+Inputs/outputs: Composite, S-video and Internal
+Norms: PAL, SECAM (768x576 @ 25 fps), NTSC (640x480 @ 29.97 fps)
+Card number: 2
+
+Pinnacle/Miro DC10(old): *
+* Zoran zr36057 PCI controller
+* Zoran zr36050 MJPEG codec
+* Zoran zr36016 Video Front End or Fuji md0211 Video Front End (clone?)
+* Micronas vpx3220a TV decoder
+* mse3000 TV encoder or Analog Devices adv7176 TV encoder *
+Drivers to use: videodev, i2c-core, i2c-algo-bit,
+ videocodec, vpx3220, mse3000/adv7175, zr36050, zr36016, zr36067
+Inputs/outputs: Composite, S-video and Internal
+Norms: PAL, SECAM (768x576 @ 25 fps), NTSC (640x480 @ 29.97 fps)
+Card number: 0
+
+Pinnacle/Miro DC30: *
+* Zoran zr36057 PCI controller
+* Zoran zr36050 MJPEG codec
+* Zoran zr36016 Video Front End
+* Micronas vpx3225d/vpx3220a/vpx3216b TV decoder
+* Analog Devices adv7176 TV encoder
+Drivers to use: videodev, i2c-core, i2c-algo-bit,
+ videocodec, vpx3220/vpx3224, adv7175, zr36050, zr36016, zr36067
+Inputs/outputs: Composite, S-video and Internal
+Norms: PAL, SECAM (768x576 @ 25 fps), NTSC (640x480 @ 29.97 fps)
+Card number: 3
+
+Pinnacle/Miro DC30+: *
+* Zoran zr36067 PCI controller
+* Zoran zr36050 MJPEG codec
+* Zoran zr36016 Video Front End
+* Micronas vpx3225d/vpx3220a/vpx3216b TV decoder
+* Analog Devices adv7176 TV encoder
+Drivers to use: videodev, i2c-core, i2c-algo-bit,
+ videocodec, vpx3220/vpx3224, adv7175, zr36050, zr36015, zr36067
+Inputs/outputs: Composite, S-video and Internal
+Norms: PAL, SECAM (768x576 @ 25 fps), NTSC (640x480 @ 29.97 fps)
+Card number: 4
+
+Note: No module for the mse3000 is available yet
+Note: No module for the vpx3224 is available yet
+
+===========================
+
+1.1 What the TV decoder can do an what not
+
+The best know TV standards are NTSC/PAL/SECAM. but for decoding a frame that
+information is not enough. There are several formats of the TV standards.
+And not every TV decoder is able to handle every format. Also the every
+combination is supported by the driver. There are currently 11 different
+tv broadcast formats all aver the world.
+
+The CCIR defines parameters needed for broadcasting the signal.
+The CCIR has defined different standards: A,B,D,E,F,G,D,H,I,K,K1,L,M,N,...
+The CCIR says not much about the colorsystem used !!!
+And talking about a colorsystem says not to much about how it is broadcast.
+
+The CCIR standards A,E,F are not used any more.
+
+When you speak about NTSC, you usually mean the standard: CCIR - M using
+the NTSC colorsystem which is used in the USA, Japan, Mexico, Canada
+and a few others.
+
+When you talk about PAL, you usually mean: CCIR - B/G using the PAL
+colorsystem which is used in many Countries.
+
+When you talk about SECAM, you mean: CCIR - L using the SECAM Colorsystem
+which is used in France, and a few others.
+
+There the other version of SECAM, CCIR - D/K is used in Bulgaria, China,
+Slovakai, Hungary, Korea (Rep.), Poland, Rumania and a others.
+
+The CCIR - H uses the PAL colorsystem (sometimes SECAM) and is used in
+Egypt, Libya, Sri Lanka, Syrain Arab. Rep.
+
+The CCIR - I uses the PAL colorsystem, and is used in Great Britain, Hong Kong,
+Ireland, Nigeria, South Africa.
+
+The CCIR - N uses the PAL colorsystem and PAL frame size but the NTSC framerate,
+and is used in Argentinia, Uruguay, an a few others
+
+We do not talk about how the audio is broadcast !
+
+A rather good sites about the TV standards are:
+http://www.sony.jp/support/
+http://info.electronicwerkstatt.de/bereiche/fernsehtechnik/frequenzen_und_normen/Fernsehnormen/
+and http://www.cabl.com/restaurant/channel.html
+
+Other weird things around: NTSC 4.43 is a modificated NTSC, which is mainly
+used in PAL VCR's that are able to play back NTSC. PAL 60 seems to be the same
+as NTSC 4.43 . The Datasheets also talk about NTSC 44, It seems as if it would
+be the same as NTSC 4.43.
+NTSC Combs seems to be a decoder mode where the decoder uses a comb filter
+to split coma and luma instead of a Delay line.
+
+But I did not defiantly find out what NTSC Comb is.
+
+Philips saa7111 TV decoder
+was introduced in 1997, is used in the BUZ and
+can handle: PAL B/G/H/I, PAL N, PAL M, NTSC M, NTSC N, NTSC 4.43 and SECAM
+
+Philips saa7110a TV decoder
+was introduced in 1995, is used in the Pinnacle/Miro DC10(new), DC10+ and
+can handle: PAL B/G, NTSC M and SECAM
+
+Philips saa7114 TV decoder
+was introduced in 2000, is used in the LML33R10 and
+can handle: PAL B/G/D/H/I/N, PAL N, PAL M, NTSC M, NTSC 4.43 and SECAM
+
+Brooktree bt819 TV decoder
+was introduced in 1996, and is used in the LML33 and
+can handle: PAL B/D/G/H/I, NTSC M
+
+Micronas vpx3220a TV decoder
+was introduced in 1996, is used in the DC30 and DC30+ and
+can handle: PAL B/G/H/I, PAL N, PAL M, NTSC M, NTSC 44, PAL 60, SECAM,NTSC Comb
+
+Samsung ks0127 TV decoder
+is used in the AVS6EYES card and
+can handle: NTSC-M/N/44, PAL-M/N/B/G/H/I/D/K/L and SECAM
+
+===========================
+
+1.2 What the TV encoder can do an what not
+
+The TV encoder are doing the "same" as the decoder, but in the oder direction.
+You feed them digital data and the generate a Composite or SVHS signal.
+For information about the colorsystems and TV norm take a look in the
+TV decoder section.
+
+Philips saa7185 TV Encoder
+was introduced in 1996, is used in the BUZ
+can generate: PAL B/G, NTSC M
+
+Brooktree bt856 TV Encoder
+was introduced in 1994, is used in the LML33
+can generate: PAL B/D/G/H/I/N, PAL M, NTSC M, PAL-N (Argentina)
+
+Analog Devices adv7170 TV Encoder
+was introduced in 2000, is used in the LML300R10
+can generate: PAL B/D/G/H/I/N, PAL M, NTSC M, PAL 60
+
+Analog Devices adv7175 TV Encoder
+was introduced in 1996, is used in the DC10, DC10+, DC10 old, DC30, DC30+
+can generate: PAL B/D/G/H/I/N, PAL M, NTSC M
+
+ITT mse3000 TV encoder
+was introduced in 1991, is used in the DC10 old
+can generate: PAL , NTSC , SECAM
+
+Conexant bt866 TV encoder
+is used in AVS6EYES, and
+can generate: NTSC/PAL, PALÂM, PALÂN
+
+The adv717x, should be able to produce PAL N. But you find nothing PAL N
+specific in the registers. Seem that you have to reuse a other standard
+to generate PAL N, maybe it would work if you use the PAL M settings.
+
+==========================
+
+2. How do I get this damn thing to work
+
+Load zr36067.o. If it can't autodetect your card, use the card=X insmod
+option with X being the card number as given in the previous section.
+To have more than one card, use card=X1[,X2[,X3,[X4[..]]]]
+
+To automate this, add the following to your /etc/modprobe.d/zoran.conf:
+
+options zr36067 card=X1[,X2[,X3[,X4[..]]]]
+alias char-major-81-0 zr36067
+
+One thing to keep in mind is that this doesn't load zr36067.o itself yet. It
+just automates loading. If you start using xawtv, the device won't load on
+some systems, since you're trying to load modules as a user, which is not
+allowed ("permission denied"). A quick workaround is to add 'Load "v4l"' to
+XF86Config-4 when you use X by default, or to run 'v4l-conf -c <device>' in
+one of your startup scripts (normally rc.local) if you don't use X. Both
+make sure that the modules are loaded on startup, under the root account.
+
+===========================
+
+3. What mainboard should I use (or why doesn't my card work)
+
+<insert lousy disclaimer here>. In short: good=SiS/Intel, bad=VIA.
+
+Experience tells us that people with a Buz, on average, have more problems
+than users with a DC10+/LML33. Also, it tells us that people owning a VIA-
+based mainboard (ktXXX, MVP3) have more problems than users with a mainboard
+based on a different chipset. Here's some notes from Andrew Stevens:
+--
+Here's my experience of using LML33 and Buz on various motherboards:
+
+VIA MVP3
+ Forget it. Pointless. Doesn't work.
+Intel 430FX (Pentium 200)
+ LML33 perfect, Buz tolerable (3 or 4 frames dropped per movie)
+Intel 440BX (early stepping)
+ LML33 tolerable. Buz starting to get annoying (6-10 frames/hour)
+Intel 440BX (late stepping)
+ Buz tolerable, LML3 almost perfect (occasional single frame drops)
+SiS735
+ LML33 perfect, Buz tolerable.
+VIA KT133(*)
+ LML33 starting to get annoying, Buz poor enough that I have up.
+
+Both 440BX boards were dual CPU versions.
+--
+Bernhard Praschinger later added:
+--
+AMD 751
+ Buz perfect-tolerable
+AMD 760
+ Buz perfect-tolerable
+--
+In general, people on the user mailinglist won't give you much of a chance
+if you have a VIA-based motherboard. They may be cheap, but sometimes, you'd
+rather want to spend some more money on better boards. In general, VIA
+mainboard's IDE/PCI performance will also suck badly compared to others.
+You'll noticed the DC10+/DC30+ aren't mentioned anywhere in the overview.
+Basically, you can assume that if the Buz works, the LML33 will work too. If
+the LML33 works, the DC10+/DC30+ will work too. They're most tolerant to
+different mainboard chipsets from all of the supported cards.
+
+If you experience timeouts during capture, buy a better mainboard or lower
+the quality/buffersize during capture (see 'Concerning buffer sizes, quality,
+output size etc.'). If it hangs, there's little we can do as of now. Check
+your IRQs and make sure the card has its own interrupts.
+
+===========================
+
+4. Programming interface
+
+This driver conforms to video4linux2. Support for V4L1 and for the custom
+zoran ioctls has been removed in kernel 2.6.38.
+
+For programming example, please, look at lavrec.c and lavplay.c code in
+the MJPEG-tools (http://mjpeg.sf.net/).
+
+Additional notes for software developers:
+
+ The driver returns maxwidth and maxheight parameters according to
+ the current TV standard (norm). Therefore, the software which
+ communicates with the driver and "asks" for these parameters should
+ first set the correct norm. Well, it seems logically correct: TV
+ standard is "more constant" for current country than geometry
+ settings of a variety of TV capture cards which may work in ITU or
+ square pixel format.
+
+===========================
+
+5. Applications
+
+Applications known to work with this driver:
+
+TV viewing:
+* xawtv
+* kwintv
+* probably any TV application that supports video4linux or video4linux2.
+
+MJPEG capture/playback:
+* mjpegtools/lavtools (or Linux Video Studio)
+* gstreamer
+* mplayer
+
+General raw capture:
+* xawtv
+* gstreamer
+* probably any application that supports video4linux or video4linux2
+
+Video editing:
+* Cinelerra
+* MainActor
+* mjpegtools (or Linux Video Studio)
+
+===========================
+
+6. Concerning buffer sizes, quality, output size etc.
+
+The zr36060 can do 1:2 JPEG compression. This is really the theoretical
+maximum that the chipset can reach. The driver can, however, limit compression
+to a maximum (size) of 1:4. The reason for this is that some cards (e.g. Buz)
+can't handle 1:2 compression without stopping capture after only a few minutes.
+With 1:4, it'll mostly work. If you have a Buz, use 'low_bitrate=1' to go into
+1:4 max. compression mode.
+
+100% JPEG quality is thus 1:2 compression in practice. So for a full PAL frame
+(size 720x576). The JPEG fields are stored in YUY2 format, so the size of the
+fields are 720x288x16/2 bits/field (2 fields/frame) = 207360 bytes/field x 2 =
+414720 bytes/frame (add some more bytes for headers and DHT (huffman)/DQT
+(quantization) tables, and you'll get to something like 512kB per frame for
+1:2 compression. For 1:4 compression, you'd have frames of half this size.
+
+Some additional explanation by Martin Samuelsson, which also explains the
+importance of buffer sizes:
+--
+> Hmm, I do not think it is really that way. With the current (downloaded
+> at 18:00 Monday) driver I get that output sizes for 10 sec:
+> -q 50 -b 128 : 24.283.332 Bytes
+> -q 50 -b 256 : 48.442.368
+> -q 25 -b 128 : 24.655.992
+> -q 25 -b 256 : 25.859.820
+
+I woke up, and can't go to sleep again. I'll kill some time explaining why
+this doesn't look strange to me.
+
+Let's do some math using a width of 704 pixels. I'm not sure whether the Buz
+actually use that number or not, but that's not too important right now.
+
+704x288 pixels, one field, is 202752 pixels. Divided by 64 pixels per block;
+3168 blocks per field. Each pixel consist of two bytes; 128 bytes per block;
+1024 bits per block. 100% in the new driver mean 1:2 compression; the maximum
+output becomes 512 bits per block. Actually 510, but 512 is simpler to use
+for calculations.
+
+Let's say that we specify d1q50. We thus want 256 bits per block; times 3168
+becomes 811008 bits; 101376 bytes per field. We're talking raw bits and bytes
+here, so we don't need to do any fancy corrections for bits-per-pixel or such
+things. 101376 bytes per field.
+
+d1 video contains two fields per frame. Those sum up to 202752 bytes per
+frame, and one of those frames goes into each buffer.
+
+But wait a second! -b128 gives 128kB buffers! It's not possible to cram
+202752 bytes of JPEG data into 128kB!
+
+This is what the driver notice and automatically compensate for in your
+examples. Let's do some math using this information:
+
+128kB is 131072 bytes. In this buffer, we want to store two fields, which
+leaves 65536 bytes for each field. Using 3168 blocks per field, we get
+20.68686868... available bytes per block; 165 bits. We can't allow the
+request for 256 bits per block when there's only 165 bits available! The -q50
+option is silently overridden, and the -b128 option takes precedence, leaving
+us with the equivalence of -q32.
+
+This gives us a data rate of 165 bits per block, which, times 3168, sums up
+to 65340 bytes per field, out of the allowed 65536. The current driver has
+another level of rate limiting; it won't accept -q values that fill more than
+6/8 of the specified buffers. (I'm not sure why. "Playing it safe" seem to be
+a safe bet. Personally, I think I would have lowered requested-bits-per-block
+by one, or something like that.) We can't use 165 bits per block, but have to
+lower it again, to 6/8 of the available buffer space: We end up with 124 bits
+per block, the equivalence of -q24. With 128kB buffers, you can't use greater
+than -q24 at -d1. (And PAL, and 704 pixels width...)
+
+The third example is limited to -q24 through the same process. The second
+example, using very similar calculations, is limited to -q48. The only
+example that actually grab at the specified -q value is the last one, which
+is clearly visible, looking at the file size.
+--
+
+Conclusion: the quality of the resulting movie depends on buffer size, quality,
+whether or not you use 'low_bitrate=1' as insmod option for the zr36060.c
+module to do 1:4 instead of 1:2 compression, etc.
+
+If you experience timeouts, lowering the quality/buffersize or using
+'low_bitrate=1 as insmod option for zr36060.o might actually help, as is
+proven by the Buz.
+
+===========================
+
+7. It hangs/crashes/fails/whatevers! Help!
+
+Make sure that the card has its own interrupts (see /proc/interrupts), check
+the output of dmesg at high verbosity (load zr36067.o with debug=2,
+load all other modules with debug=1). Check that your mainboard is favorable
+(see question 2) and if not, test the card in another computer. Also see the
+notes given in question 3 and try lowering quality/buffersize/capturesize
+if recording fails after a period of time.
+
+If all this doesn't help, give a clear description of the problem including
+detailed hardware information (memory+brand, mainboard+chipset+brand, which
+MJPEG card, processor, other PCI cards that might be of interest), give the
+system PnP information (/proc/interrupts, /proc/dma, /proc/devices), and give
+the kernel version, driver version, glibc version, gcc version and any other
+information that might possibly be of interest. Also provide the dmesg output
+at high verbosity. See 'Contacting' on how to contact the developers.
+
+===========================
+
+8. Maintainers/Contacting
+
+The driver is currently maintained by Laurent Pinchart and Ronald Bultje
+(<laurent.pinchart@skynet.be> and <rbultje@ronald.bitfreak.net>). For bug
+reports or questions, please contact the mailinglist instead of the developers
+individually. For user questions (i.e. bug reports or how-to questions), send
+an email to <mjpeg-users@lists.sf.net>, for developers (i.e. if you want to
+help programming), send an email to <mjpeg-developer@lists.sf.net>. See
+http://www.sf.net/projects/mjpeg/ for subscription information.
+
+For bug reports, be sure to include all the information as described in
+the section 'It hangs/crashes/fails/whatevers! Help!'. Please make sure
+you're using the latest version (http://mjpeg.sf.net/driver-zoran/).
+
+Previous maintainers/developers of this driver include Serguei Miridonov
+<mirsev@cicese.mx>, Wolfgang Scherr <scherr@net4you.net>, Dave Perks
+<dperks@ibm.net> and Rainer Johanni <Rainer@Johanni.de>.
+
+===========================
+
+9. License
+
+This driver is distributed under the terms of the General Public License.
+
+ This program is free software; you can redistribute it and/or modify
+ it under the terms of the GNU General Public License as published by
+ the Free Software Foundation; either version 2 of the License, or
+ (at your option) any later version.
+
+ This program is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ GNU General Public License for more details.
+
+ You should have received a copy of the GNU General Public License
+ along with this program; if not, write to the Free Software
+ Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+
+See http://www.gnu.org/ for more information.
--- /dev/null
+Zoran 364xx based USB webcam module version 0.72
+site: http://royale.zerezo.com/zr364xx/
+mail: royale@zerezo.com
+
+introduction:
+This brings support under Linux for the Aiptek PocketDV 3300 in webcam mode.
+If you just want to get on your PC the pictures and movies on the camera, you should use the usb-storage module instead.
+The driver works with several other cameras in webcam mode (see the list below).
+Maybe this code can work for other JPEG/USB cams based on the Coach chips from Zoran?
+Possible chipsets are : ZR36430 (ZR36430BGC) and maybe ZR36431, ZR36440, ZR36442...
+You can try the experience changing the vendor/product ID values (look at the source code).
+You can get these values by looking at /var/log/messages when you plug your camera, or by typing : cat /proc/bus/usb/devices.
+If you manage to use your cam with this code, you can send me a mail (royale@zerezo.com) with the name of your cam and a patch if needed.
+This is a beta release of the driver.
+Since version 0.70, this driver is only compatible with V4L2 API and 2.6.x kernels.
+If you need V4L1 or 2.4x kernels support, please use an older version, but the code is not maintained anymore.
+Good luck!
+
+install:
+In order to use this driver, you must compile it with your kernel.
+Location: Device Drivers -> Multimedia devices -> Video For Linux -> Video Capture Adapters -> V4L USB devices
+
+usage:
+modprobe zr364xx debug=X mode=Y
+ - debug : set to 1 to enable verbose debug messages
+ - mode : 0 = 320x240, 1 = 160x120, 2 = 640x480
+You can then use the camera with V4L2 compatible applications, for example Ekiga.
+To capture a single image, try this: dd if=/dev/video0 of=test.jpg bs=1M count=1
+
+links :
+http://mxhaard.free.fr/ (support for many others cams including some Aiptek PocketDV)
+http://www.harmwal.nl/pccam880/ (this project also supports cameras based on this chipset)
+
+supported devices:
+------ ------- ----------- -----
+Vendor Product Distributor Model
+------ ------- ----------- -----
+0x08ca 0x0109 Aiptek PocketDV 3300
+0x08ca 0x0109 Maxell Maxcam PRO DV3
+0x041e 0x4024 Creative PC-CAM 880
+0x0d64 0x0108 Aiptek Fidelity 3200
+0x0d64 0x0108 Praktica DCZ 1.3 S
+0x0d64 0x0108 Genius Digital Camera (?)
+0x0d64 0x0108 DXG Technology Fashion Cam
+0x0546 0x3187 Polaroid iON 230
+0x0d64 0x3108 Praktica Exakta DC 2200
+0x0d64 0x3108 Genius G-Shot D211
+0x0595 0x4343 Concord Eye-Q Duo 1300
+0x0595 0x4343 Concord Eye-Q Duo 2000
+0x0595 0x4343 Fujifilm EX-10
+0x0595 0x4343 Ricoh RDC-6000
+0x0595 0x4343 Digitrex DSC 1300
+0x0595 0x4343 Firstline FDC 2000
+0x0bb0 0x500d Concord EyeQ Go Wireless
+0x0feb 0x2004 CRS Electronic 3.3 Digital Camera
+0x0feb 0x2004 Packard Bell DSC-300
+0x055f 0xb500 Mustek MDC 3000
+0x08ca 0x2062 Aiptek PocketDV 5700
+0x052b 0x1a18 Chiphead Megapix V12
+0x04c8 0x0729 Konica Revio 2
+0x04f2 0xa208 Creative PC-CAM 850
+0x0784 0x0040 Traveler Slimline X5
+0x06d6 0x0034 Trust Powerc@m 750
+0x0a17 0x0062 Pentax Optio 50L
+0x06d6 0x003b Trust Powerc@m 970Z
+0x0a17 0x004e Pentax Optio 50
+0x041e 0x405d Creative DiVi CAM 516
+0x08ca 0x2102 Aiptek DV T300
+0x06d6 0x003d Trust Powerc@m 910Z
+++ /dev/null
-Guidelines for Linux4Linux pixel format 4CCs
-============================================
-
-Guidelines for Video4Linux 4CC codes defined using v4l2_fourcc() are
-specified in this document. First of the characters defines the nature of
-the pixel format, compression and colour space. The interpretation of the
-other three characters depends on the first one.
-
-Existing 4CCs may not obey these guidelines.
-
-Formats
-=======
-
-Raw bayer
----------
-
-The following first characters are used by raw bayer formats:
-
- B: raw bayer, uncompressed
- b: raw bayer, DPCM compressed
- a: A-law compressed
- u: u-law compressed
-
-2nd character: pixel order
- B: BGGR
- G: GBRG
- g: GRBG
- R: RGGB
-
-3rd character: uncompressed bits-per-pixel 0--9, A--
-
-4th character: compressed bits-per-pixel 0--9, A--
+++ /dev/null
-$Id: README,v 1.7 2005/08/29 23:39:57 sbertin Exp $
-
-1. Introduction
-
- This is a driver for STMicroelectronics's CPiA2 (second generation
-Colour Processor Interface ASIC) based cameras. This camera outputs an MJPEG
-stream at up to vga size. It implements the Video4Linux interface as much as
-possible. Since the V4L interface does not support compressed formats, only
-an mjpeg enabled application can be used with the camera. We have modified the
-gqcam application to view this stream.
-
- The driver is implemented as two kernel modules. The cpia2 module
-contains the camera functions and the V4L interface. The cpia2_usb module
-contains usb specific functions. The main reason for this was the size of the
-module was getting out of hand, so I separated them. It is not likely that
-there will be a parallel port version.
-
-FEATURES:
- - Supports cameras with the Vision stv6410 (CIF) and stv6500 (VGA) cmos
- sensors. I only have the vga sensor, so can't test the other.
- - Image formats: VGA, QVGA, CIF, QCIF, and a number of sizes in between.
- VGA and QVGA are the native image sizes for the VGA camera. CIF is done
- in the coprocessor by scaling QVGA. All other sizes are done by clipping.
- - Palette: YCrCb, compressed with MJPEG.
- - Some compression parameters are settable.
- - Sensor framerate is adjustable (up to 30 fps CIF, 15 fps VGA).
- - Adjust brightness, color, contrast while streaming.
- - Flicker control settable for 50 or 60 Hz mains frequency.
-
-2. Making and installing the stv672 driver modules:
-
- Requirements:
- -------------
- This should work with 2.4 (2.4.23 and later) and 2.6 kernels, but has
-only been tested on 2.6. Video4Linux must be either compiled into the kernel or
-available as a module. Video4Linux2 is automatically detected and made
-available at compile time.
-
- Compiling:
- ----------
- As root, do a make install. This will compile and install the modules
-into the media/video directory in the module tree. For 2.4 kernels, use
-Makefile_2.4 (aka do make -f Makefile_2.4 install).
-
- Setup:
- ------
- Use 'modprobe cpia2' to load and 'modprobe -r cpia2' to unload. This
-may be done automatically by your distribution.
-
-3. Driver options
-
- Option Description
- ------ -----------
- video_nr video device to register (0=/dev/video0, etc)
- range -1 to 64. default is -1 (first available)
- If you have more than 1 camera, this MUST be -1.
- buffer_size Size for each frame buffer in bytes (default 68k)
- num_buffers Number of frame buffers (1-32, default 3)
- alternate USB Alternate (2-7, default 7)
- flicker_freq Frequency for flicker reduction(50 or 60, default 60)
- flicker_mode 0 to disable, or 1 to enable flicker reduction.
- (default 0). This is only effective if the camera
- uses a stv0672 coprocessor.
-
- Setting the options:
- --------------------
- If you are using modules, edit /etc/modules.conf and add an options
-line like this:
- options cpia2 num_buffers=3 buffer_size=65535
-
- If the driver is compiled into the kernel, at boot time specify them
-like this:
- cpia2.num_buffers=3 cpia2.buffer_size=65535
-
- What buffer size should I use?
- ------------------------------
- The maximum image size depends on the alternate you choose, and the
-frame rate achieved by the camera. If the compression engine is able to
-keep up with the frame rate, the maximum image size is given by the table
-below.
- The compression engine starts out at maximum compression, and will
-increase image quality until it is close to the size in the table. As long
-as the compression engine can keep up with the frame rate, after a short time
-the images will all be about the size in the table, regardless of resolution.
- At low alternate settings, the compression engine may not be able to
-compress the image enough and will reduce the frame rate by producing larger
-images.
- The default of 68k should be good for most users. This will handle
-any alternate at frame rates down to 15fps. For lower frame rates, it may
-be necessary to increase the buffer size to avoid having frames dropped due
-to insufficient space.
-
- Image size(bytes)
- Alternate bytes/ms 15fps 30fps
- 2 128 8533 4267
- 3 384 25600 12800
- 4 640 42667 21333
- 5 768 51200 25600
- 6 896 59733 29867
- 7 1023 68200 34100
-
- How many buffers should I use?
- ------------------------------
- For normal streaming, 3 should give the best results. With only 2,
-it is possible for the camera to finish sending one image just after a
-program has started reading the other. If this happens, the driver must drop
-a frame. The exception to this is if you have a heavily loaded machine. In
-this case use 2 buffers. You are probably not reading at the full frame rate.
-If the camera can send multiple images before a read finishes, it could
-overwrite the third buffer before the read finishes, leading to a corrupt
-image. Single and double buffering have extra checks to avoid overwriting.
-
-4. Using the camera
-
- We are providing a modified gqcam application to view the output. In
-order to avoid confusion, here it is called mview. There is also the qx5view
-program which can also control the lights on the qx5 microscope. MJPEG Tools
-(http://mjpeg.sourceforge.net) can also be used to record from the camera.
-
-5. Notes to developers:
-
- - This is a driver version stripped of the 2.4 back compatibility
- and old MJPEG ioctl API. See cpia2.sf.net for 2.4 support.
-
-6. Thanks:
-
- - Peter Pregler <Peter_Pregler@email.com>,
- Scott J. Bertin <scottbertin@yahoo.com>, and
- Jarl Totland <Jarl.Totland@bdc.no> for the original cpia driver, which
- this one was modelled from.
+++ /dev/null
-cx8800 release notes
-====================
-
-This is a v4l2 device driver for the cx2388x chip.
-
-
-current status
-==============
-
-video
- - Basically works.
- - For now, only capture and read(). Overlay isn't supported.
-
-audio
- - The chip specs for the on-chip TV sound decoder are next
- to useless :-/
- - Neverless the builtin TV sound decoder starts working now,
- at least for some standards.
- FOR ANY REPORTS ON THIS PLEASE MENTION THE TV NORM YOU ARE
- USING.
- - Most tuner chips do provide mono sound, which may or may not
- be useable depending on the board design. With the Hauppauge
- cards it works, so there is mono sound available as fallback.
- - audio data dma (i.e. recording without loopback cable to the
- sound card) is supported via cx88-alsa.
-
-vbi
- - Code present. Works for NTSC closed caption. PAL and other
- TV norms may or may not work.
-
-
-how to add support for new cards
-================================
-
-The driver needs some config info for the TV cards. This stuff is in
-cx88-cards.c. If the driver doesn't work well you likely need a new
-entry for your card in that file. Check the kernel log (using dmesg)
-to see whenever the driver knows your card or not. There is a line
-like this one:
-
- cx8800[0]: subsystem: 0070:3400, board: Hauppauge WinTV \
- 34xxx models [card=1,autodetected]
-
-If your card is listed as "board: UNKNOWN/GENERIC" it is unknown to
-the driver. What to do then?
-
- (1) Try upgrading to the latest snapshot, maybe it has been added
- meanwhile.
- (2) You can try to create a new entry yourself, have a look at
- cx88-cards.c. If that worked, mail me your changes as unified
- diff ("diff -u").
- (3) Or you can mail me the config information. I need at least the
- following information to add the card:
-
- * the PCI Subsystem ID ("0070:3400" from the line above,
- "lspci -v" output is fine too).
- * the tuner type used by the card. You can try to find one by
- trial-and-error using the tuner=<n> insmod option. If you
- know which one the card has you can also have a look at the
- list in CARDLIST.tuner
-
-Have fun,
-
- Gerd
-
---
-Gerd Knorr <kraxel@bytesex.org> [SuSE Labs]
+++ /dev/null
-
- VPBE V4L2 driver design
- ======================================================================
-
- File partitioning
- -----------------
- V4L2 display device driver
- drivers/media/platform/davinci/vpbe_display.c
- drivers/media/platform/davinci/vpbe_display.h
-
- VPBE display controller
- drivers/media/platform/davinci/vpbe.c
- drivers/media/platform/davinci/vpbe.h
-
- VPBE venc sub device driver
- drivers/media/platform/davinci/vpbe_venc.c
- drivers/media/platform/davinci/vpbe_venc.h
- drivers/media/platform/davinci/vpbe_venc_regs.h
-
- VPBE osd driver
- drivers/media/platform/davinci/vpbe_osd.c
- drivers/media/platform/davinci/vpbe_osd.h
- drivers/media/platform/davinci/vpbe_osd_regs.h
-
- Functional partitioning
- -----------------------
-
- Consists of the following (in the same order as the list under file
- partitioning):-
-
- 1. V4L2 display driver
- Implements creation of video2 and video3 device nodes and
- provides v4l2 device interface to manage VID0 and VID1 layers.
-
- 2. Display controller
- Loads up VENC, OSD and external encoders such as ths8200. It provides
- a set of API calls to V4L2 drivers to set the output/standards
- in the VENC or external sub devices. It also provides
- a device object to access the services from OSD subdevice
- using sub device ops. The connection of external encoders to VENC LCD
- controller port is done at init time based on default output and standard
- selection or at run time when application change the output through
- V4L2 IOCTLs.
-
- When connected to an external encoder, vpbe controller is also responsible
- for setting up the interface between VENC and external encoders based on
- board specific settings (specified in board-xxx-evm.c). This allows
- interfacing external encoders such as ths8200. The setup_if_config()
- is implemented for this as well as configure_venc() (part of the next patch)
- API to set timings in VENC for a specific display resolution. As of this
- patch series, the interconnection and enabling and setting of the external
- encoders is not present, and would be a part of the next patch series.
-
- 3. VENC subdevice module
- Responsible for setting outputs provided through internal DACs and also
- setting timings at LCD controller port when external encoders are connected
- at the port or LCD panel timings required. When external encoder/LCD panel
- is connected, the timings for a specific standard/preset is retrieved from
- the board specific table and the values are used to set the timings in
- venc using non-standard timing mode.
-
- Support LCD Panel displays using the VENC. For example to support a Logic
- PD display, it requires setting up the LCD controller port with a set of
- timings for the resolution supported and setting the dot clock. So we could
- add the available outputs as a board specific entry (i.e add the "LogicPD"
- output name to board-xxx-evm.c). A table of timings for various LCDs
- supported can be maintained in the board specific setup file to support
- various LCD displays.As of this patch a basic driver is present, and this
- support for external encoders and displays forms a part of the next
- patch series.
-
- 4. OSD module
- OSD module implements all OSD layer management and hardware specific
- features. The VPBE module interacts with the OSD for enabling and
- disabling appropriate features of the OSD.
-
- Current status:-
-
- A fully functional working version of the V4L2 driver is available. This
- driver has been tested with NTSC and PAL standards and buffer streaming.
-
- Following are TBDs.
-
- vpbe display controller
- - Add support for external encoders.
- - add support for selecting external encoder as default at probe time.
-
- vpbe venc sub device
- - add timings for supporting ths8200
- - add support for LogicPD LCD.
-
- FB drivers
- - Add support for fbdev drivers.- Ready and part of subsequent patches.
+++ /dev/null
-
-infrared remote control support in video4linux drivers
-======================================================
-
-
-basics
-------
-
-Current versions use the linux input layer to support infrared
-remote controls. I suggest to download my input layer tools
-from http://bytesex.org/snapshot/input-<date>.tar.gz
-
-Modules you have to load:
-
- saa7134 statically built in, i.e. just the driver :)
- bttv ir-kbd-gpio or ir-kbd-i2c depending on your
- card.
-
-ir-kbd-gpio and ir-kbd-i2c don't support all cards lirc supports
-(yet), mainly for the reason that the code of lirc_i2c and lirc_gpio
-was very confusing and I decided to basically start over from scratch.
-Feel free to contact me in case of trouble. Note that the ir-kbd-*
-modules work on 2.6.x kernels only through ...
-
-
-how it works
-------------
-
-The modules register the remote as keyboard within the linux input
-layer, i.e. you'll see the keys of the remote as normal key strokes
-(if CONFIG_INPUT_KEYBOARD is enabled).
-
-Using the event devices (CONFIG_INPUT_EVDEV) it is possible for
-applications to access the remote via /dev/input/event<n> devices.
-You might have to create the special files using "/sbin/MAKEDEV
-input". The input layer tools mentioned above use the event device.
-
-The input layer tools are nice for trouble shooting, i.e. to check
-whenever the input device is really present, which of the devices it
-is, check whenever pressing keys on the remote actually generates
-events and the like. You can also use the kbd utility to change the
-keymaps (2.6.x kernels only through).
-
-
-using with lircd
-================
-
-The cvs version of the lircd daemon supports reading events from the
-linux input layer (via event device). The input layer tools tarball
-comes with a lircd config file.
-
-
-using without lircd
-===================
-
-XFree86 likely can be configured to recognise the remote keys. Once I
-simply tried to configure one of the multimedia keyboards as input
-device, which had the effect that XFree86 recognised some of the keys
-of my remote control and passed volume up/down key presses as
-XF86AudioRaiseVolume and XF86AudioLowerVolume key events to the X11
-clients.
-
-It likely is possible to make that fly with a nice xkb config file,
-I know next to nothing about that through.
-
-
-Have fun,
-
- Gerd
-
---
-Gerd Knorr <kraxel@bytesex.org>
+++ /dev/null
-
-ivtv release notes
-==================
-
-This is a v4l2 device driver for the Conexant cx23415/6 MPEG encoder/decoder.
-The cx23415 can do both encoding and decoding, the cx23416 can only do MPEG
-encoding. Currently the only card featuring full decoding support is the
-Hauppauge PVR-350.
-
-NOTE: this driver requires the latest encoder firmware (version 2.06.039, size
-376836 bytes). Get the firmware from here:
-
-http://dl.ivtvdriver.org/ivtv/firmware/
-
-NOTE: 'normal' TV applications do not work with this driver, you need
-an application that can handle MPEG input such as mplayer, xine, MythTV,
-etc.
-
-The primary goal of the IVTV project is to provide a "clean room" Linux
-Open Source driver implementation for video capture cards based on the
-iCompression iTVC15 or Conexant CX23415/CX23416 MPEG Codec.
-
-Features:
- * Hardware mpeg2 capture of broadcast video (and sound) via the tuner or
- S-Video/Composite and audio line-in.
- * Hardware mpeg2 capture of FM radio where hardware support exists
- * Supports NTSC, PAL, SECAM with stereo sound
- * Supports SAP and bilingual transmissions.
- * Supports raw VBI (closed captions and teletext).
- * Supports sliced VBI (closed captions and teletext) and is able to insert
- this into the captured MPEG stream.
- * Supports raw YUV and PCM input.
-
-Additional features for the PVR-350 (CX23415 based):
- * Provides hardware mpeg2 playback
- * Provides comprehensive OSD (On Screen Display: ie. graphics overlaying the
- video signal)
- * Provides a framebuffer (allowing X applications to appear on the video
- device)
- * Supports raw YUV output.
-
-IMPORTANT: In case of problems first read this page:
- http://www.ivtvdriver.org/index.php/Troubleshooting
-
-See also:
-
-Homepage + Wiki
-http://www.ivtvdriver.org
-
-IRC
-irc://irc.freenode.net/ivtv-dev
-
-----------------------------------------------------------
-
-Devices
-=======
-
-A maximum of 12 ivtv boards are allowed at the moment.
-
-Cards that don't have a video output capability (i.e. non PVR350 cards)
-lack the vbi8, vbi16, video16 and video48 devices. They also do not
-support the framebuffer device /dev/fbx for OSD.
-
-The radio0 device may or may not be present, depending on whether the
-card has a radio tuner or not.
-
-Here is a list of the base v4l devices:
-crw-rw---- 1 root video 81, 0 Jun 19 22:22 /dev/video0
-crw-rw---- 1 root video 81, 16 Jun 19 22:22 /dev/video16
-crw-rw---- 1 root video 81, 24 Jun 19 22:22 /dev/video24
-crw-rw---- 1 root video 81, 32 Jun 19 22:22 /dev/video32
-crw-rw---- 1 root video 81, 48 Jun 19 22:22 /dev/video48
-crw-rw---- 1 root video 81, 64 Jun 19 22:22 /dev/radio0
-crw-rw---- 1 root video 81, 224 Jun 19 22:22 /dev/vbi0
-crw-rw---- 1 root video 81, 228 Jun 19 22:22 /dev/vbi8
-crw-rw---- 1 root video 81, 232 Jun 19 22:22 /dev/vbi16
-
-Base devices
-============
-
-For every extra card you have the numbers increased by one. For example,
-/dev/video0 is listed as the 'base' encoding capture device so we have:
-
- /dev/video0 is the encoding capture device for the first card (card 0)
- /dev/video1 is the encoding capture device for the second card (card 1)
- /dev/video2 is the encoding capture device for the third card (card 2)
-
-Note that if the first card doesn't have a feature (eg no decoder, so no
-video16, the second card will still use video17. The simple rule is 'add
-the card number to the base device number'. If you have other capture
-cards (e.g. WinTV PCI) that are detected first, then you have to tell
-the ivtv module about it so that it will start counting at 1 (or 2, or
-whatever). Otherwise the device numbers can get confusing. The ivtv
-'ivtv_first_minor' module option can be used for that.
-
-
-/dev/video0
-The encoding capture device(s).
-Read-only.
-
-Reading from this device gets you the MPEG1/2 program stream.
-Example:
-
-cat /dev/video0 > my.mpg (you need to hit ctrl-c to exit)
-
-
-/dev/video16
-The decoder output device(s)
-Write-only. Only present if the MPEG decoder (i.e. CX23415) exists.
-
-An mpeg2 stream sent to this device will appear on the selected video
-display, audio will appear on the line-out/audio out. It is only
-available for cards that support video out. Example:
-
-cat my.mpg >/dev/video16
-
-
-/dev/video24
-The raw audio capture device(s).
-Read-only
-
-The raw audio PCM stereo stream from the currently selected
-tuner or audio line-in. Reading from this device results in a raw
-(signed 16 bit Little Endian, 48000 Hz, stereo pcm) capture.
-This device only captures audio. This should be replaced by an ALSA
-device in the future.
-Note that there is no corresponding raw audio output device, this is
-not supported in the decoder firmware.
-
-
-/dev/video32
-The raw video capture device(s)
-Read-only
-
-The raw YUV video output from the current video input. The YUV format
-is non-standard (V4L2_PIX_FMT_HM12).
-
-Note that the YUV and PCM streams are not synchronized, so they are of
-limited use.
-
-
-/dev/video48
-The raw video display device(s)
-Write-only. Only present if the MPEG decoder (i.e. CX23415) exists.
-
-Writes a YUV stream to the decoder of the card.
-
-
-/dev/radio0
-The radio tuner device(s)
-Cannot be read or written.
-
-Used to enable the radio tuner and tune to a frequency. You cannot
-read or write audio streams with this device. Once you use this
-device to tune the radio, use /dev/video24 to read the raw pcm stream
-or /dev/video0 to get an mpeg2 stream with black video.
-
-
-/dev/vbi0
-The 'vertical blank interval' (Teletext, CC, WSS etc) capture device(s)
-Read-only
-
-Captures the raw (or sliced) video data sent during the Vertical Blank
-Interval. This data is used to encode teletext, closed captions, VPS,
-widescreen signalling, electronic program guide information, and other
-services.
-
-
-/dev/vbi8
-Processed vbi feedback device(s)
-Read-only. Only present if the MPEG decoder (i.e. CX23415) exists.
-
-The sliced VBI data embedded in an MPEG stream is reproduced on this
-device. So while playing back a recording on /dev/video16, you can
-read the embedded VBI data from /dev/vbi8.
-
-
-/dev/vbi16
-The vbi 'display' device(s)
-Write-only. Only present if the MPEG decoder (i.e. CX23415) exists.
-
-Can be used to send sliced VBI data to the video-out connector.
-
----------------------------------
-
-Hans Verkuil <hverkuil@xs4all.nl>
+++ /dev/null
-
-$Id$
-Mike Isely <isely@pobox.com>
-
- pvrusb2 driver
-
-Background:
-
- This driver is intended for the "Hauppauge WinTV PVR USB 2.0", which
- is a USB 2.0 hosted TV Tuner. This driver is a work in progress.
- Its history started with the reverse-engineering effort by Björn
- Danielsson <pvrusb2@dax.nu> whose web page can be found here:
-
- http://pvrusb2.dax.nu/
-
- From there Aurelien Alleaume <slts@free.fr> began an effort to
- create a video4linux compatible driver. I began with Aurelien's
- last known snapshot and evolved the driver to the state it is in
- here.
-
- More information on this driver can be found at:
-
- http://www.isely.net/pvrusb2.html
-
-
- This driver has a strong separation of layers. They are very
- roughly:
-
- 1a. Low level wire-protocol implementation with the device.
-
- 1b. I2C adaptor implementation and corresponding I2C client drivers
- implemented elsewhere in V4L.
-
- 1c. High level hardware driver implementation which coordinates all
- activities that ensure correct operation of the device.
-
- 2. A "context" layer which manages instancing of driver, setup,
- tear-down, arbitration, and interaction with high level
- interfaces appropriately as devices are hotplugged in the
- system.
-
- 3. High level interfaces which glue the driver to various published
- Linux APIs (V4L, sysfs, maybe DVB in the future).
-
- The most important shearing layer is between the top 2 layers. A
- lot of work went into the driver to ensure that any kind of
- conceivable API can be laid on top of the core driver. (Yes, the
- driver internally leverages V4L to do its work but that really has
- nothing to do with the API published by the driver to the outside
- world.) The architecture allows for different APIs to
- simultaneously access the driver. I have a strong sense of fairness
- about APIs and also feel that it is a good design principle to keep
- implementation and interface isolated from each other. Thus while
- right now the V4L high level interface is the most complete, the
- sysfs high level interface will work equally well for similar
- functions, and there's no reason I see right now why it shouldn't be
- possible to produce a DVB high level interface that can sit right
- alongside V4L.
-
- NOTE: Complete documentation on the pvrusb2 driver is contained in
- the html files within the doc directory; these are exactly the same
- as what is on the web site at the time. Browse those files
- (especially the FAQ) before asking questions.
-
-
-Building
-
- To build these modules essentially amounts to just running "Make",
- but you need the kernel source tree nearby and you will likely also
- want to set a few controlling environment variables first in order
- to link things up with that source tree. Please see the Makefile
- here for comments that explain how to do that.
-
-
-Source file list / functional overview:
-
- (Note: The term "module" used below generally refers to loosely
- defined functional units within the pvrusb2 driver and bears no
- relation to the Linux kernel's concept of a loadable module.)
-
- pvrusb2-audio.[ch] - This is glue logic that resides between this
- driver and the msp3400.ko I2C client driver (which is found
- elsewhere in V4L).
-
- pvrusb2-context.[ch] - This module implements the context for an
- instance of the driver. Everything else eventually ties back to
- or is otherwise instanced within the data structures implemented
- here. Hotplugging is ultimately coordinated here. All high level
- interfaces tie into the driver through this module. This module
- helps arbitrate each interface's access to the actual driver core,
- and is designed to allow concurrent access through multiple
- instances of multiple interfaces (thus you can for example change
- the tuner's frequency through sysfs while simultaneously streaming
- video through V4L out to an instance of mplayer).
-
- pvrusb2-debug.h - This header defines a printk() wrapper and a mask
- of debugging bit definitions for the various kinds of debug
- messages that can be enabled within the driver.
-
- pvrusb2-debugifc.[ch] - This module implements a crude command line
- oriented debug interface into the driver. Aside from being part
- of the process for implementing manual firmware extraction (see
- the pvrusb2 web site mentioned earlier), probably I'm the only one
- who has ever used this. It is mainly a debugging aid.
-
- pvrusb2-eeprom.[ch] - This is glue logic that resides between this
- driver the tveeprom.ko module, which is itself implemented
- elsewhere in V4L.
-
- pvrusb2-encoder.[ch] - This module implements all protocol needed to
- interact with the Conexant mpeg2 encoder chip within the pvrusb2
- device. It is a crude echo of corresponding logic in ivtv,
- however the design goals (strict isolation) and physical layer
- (proxy through USB instead of PCI) are enough different that this
- implementation had to be completely different.
-
- pvrusb2-hdw-internal.h - This header defines the core data structure
- in the driver used to track ALL internal state related to control
- of the hardware. Nobody outside of the core hardware-handling
- modules should have any business using this header. All external
- access to the driver should be through one of the high level
- interfaces (e.g. V4L, sysfs, etc), and in fact even those high
- level interfaces are restricted to the API defined in
- pvrusb2-hdw.h and NOT this header.
-
- pvrusb2-hdw.h - This header defines the full internal API for
- controlling the hardware. High level interfaces (e.g. V4L, sysfs)
- will work through here.
-
- pvrusb2-hdw.c - This module implements all the various bits of logic
- that handle overall control of a specific pvrusb2 device.
- (Policy, instantiation, and arbitration of pvrusb2 devices fall
- within the jurisdiction of pvrusb-context not here).
-
- pvrusb2-i2c-chips-*.c - These modules implement the glue logic to
- tie together and configure various I2C modules as they attach to
- the I2C bus. There are two versions of this file. The "v4l2"
- version is intended to be used in-tree alongside V4L, where we
- implement just the logic that makes sense for a pure V4L
- environment. The "all" version is intended for use outside of
- V4L, where we might encounter other possibly "challenging" modules
- from ivtv or older kernel snapshots (or even the support modules
- in the standalone snapshot).
-
- pvrusb2-i2c-cmd-v4l1.[ch] - This module implements generic V4L1
- compatible commands to the I2C modules. It is here where state
- changes inside the pvrusb2 driver are translated into V4L1
- commands that are in turn send to the various I2C modules.
-
- pvrusb2-i2c-cmd-v4l2.[ch] - This module implements generic V4L2
- compatible commands to the I2C modules. It is here where state
- changes inside the pvrusb2 driver are translated into V4L2
- commands that are in turn send to the various I2C modules.
-
- pvrusb2-i2c-core.[ch] - This module provides an implementation of a
- kernel-friendly I2C adaptor driver, through which other external
- I2C client drivers (e.g. msp3400, tuner, lirc) may connect and
- operate corresponding chips within the pvrusb2 device. It is
- through here that other V4L modules can reach into this driver to
- operate specific pieces (and those modules are in turn driven by
- glue logic which is coordinated by pvrusb2-hdw, doled out by
- pvrusb2-context, and then ultimately made available to users
- through one of the high level interfaces).
-
- pvrusb2-io.[ch] - This module implements a very low level ring of
- transfer buffers, required in order to stream data from the
- device. This module is *very* low level. It only operates the
- buffers and makes no attempt to define any policy or mechanism for
- how such buffers might be used.
-
- pvrusb2-ioread.[ch] - This module layers on top of pvrusb2-io.[ch]
- to provide a streaming API usable by a read() system call style of
- I/O. Right now this is the only layer on top of pvrusb2-io.[ch],
- however the underlying architecture here was intended to allow for
- other styles of I/O to be implemented with additional modules, like
- mmap()'ed buffers or something even more exotic.
-
- pvrusb2-main.c - This is the top level of the driver. Module level
- and USB core entry points are here. This is our "main".
-
- pvrusb2-sysfs.[ch] - This is the high level interface which ties the
- pvrusb2 driver into sysfs. Through this interface you can do
- everything with the driver except actually stream data.
-
- pvrusb2-tuner.[ch] - This is glue logic that resides between this
- driver and the tuner.ko I2C client driver (which is found
- elsewhere in V4L).
-
- pvrusb2-util.h - This header defines some common macros used
- throughout the driver. These macros are not really specific to
- the driver, but they had to go somewhere.
-
- pvrusb2-v4l2.[ch] - This is the high level interface which ties the
- pvrusb2 driver into video4linux. It is through here that V4L
- applications can open and operate the driver in the usual V4L
- ways. Note that **ALL** V4L functionality is published only
- through here and nowhere else.
-
- pvrusb2-video-*.[ch] - This is glue logic that resides between this
- driver and the saa711x.ko I2C client driver (which is found
- elsewhere in V4L). Note that saa711x.ko used to be known as
- saa7115.ko in ivtv. There are two versions of this; one is
- selected depending on the particular saa711[5x].ko that is found.
-
- pvrusb2.h - This header contains compile time tunable parameters
- (and at the moment the driver has very little that needs to be
- tuned).
-
-
- -Mike Isely
- isely@pobox.com
-
+++ /dev/null
-
-
-What is it?
-===========
-
-This is a v4l2/oss device driver for saa7130/33/34/35 based capture / TV
-boards. See http://www.semiconductors.philips.com/pip/saa7134hl for a
-description.
-
-
-Status
-======
-
-Almost everything is working. video, sound, tuner, radio, mpeg ts, ...
-
-As with bttv, card-specific tweaks are needed. Check CARDLIST for a
-list of known TV cards and saa7134-cards.c for the drivers card
-configuration info.
-
-
-Build
-=====
-
-Pick up videodev + v4l2 patches from http://bytesex.org/patches/.
-Configure, build, install + boot the new kernel. You'll need at least
-these config options:
-
- CONFIG_I2C=m
- CONFIG_VIDEO_DEV=m
-
-Type "make" to build the driver now. "make install" installs the
-driver. "modprobe saa7134" should load it. Depending on the card you
-might have to pass card=<nr> as insmod option, check CARDLIST for
-valid choices.
-
-
-Changes / Fixes
-===============
-
-Please mail me unified diffs ("diff -u") with your changes, and don't
-forget to tell me what it changes / which problem it fixes / whatever
-it is good for ...
-
-
-Known Problems
-==============
-
-* The tuner for the flyvideos isn't detected automatically and the
- default might not work for you depending on which version you have.
- There is a tuner= insmod option to override the driver's default.
-
-Card Variations:
-================
-
-Cards can use either of these two crystals (xtal):
- - 32.11 MHz -> .audio_clock=0x187de7
- - 24.576MHz -> .audio_clock=0x200000
-(xtal * .audio_clock = 51539600)
-
-Some details about 30/34/35:
-
- - saa7130 - low-price chip, doesn't have mute, that is why all those
- cards should have .mute field defined in their tuner structure.
-
- - saa7134 - usual chip
-
- - saa7133/35 - saa7135 is probably a marketing decision, since all those
- chips identifies itself as 33 on pci.
-
-Credits
-=======
-
-andrew.stevens@philips.com + werner.leeb@philips.com for providing
-saa7134 hardware specs and sample board.
-
-
-Have fun,
-
- Gerd
-
---
-Gerd Knorr <kraxel@bytesex.org> [SuSE Labs]
+++ /dev/null
-Frequently Asked Questions:
-===========================
-subject: unified zoran driver (zr360x7, zoran, buz, dc10(+), dc30(+), lml33)
-website: http://mjpeg.sourceforge.net/driver-zoran/
-
-1. What cards are supported
-1.1 What the TV decoder can do an what not
-1.2 What the TV encoder can do an what not
-2. How do I get this damn thing to work
-3. What mainboard should I use (or why doesn't my card work)
-4. Programming interface
-5. Applications
-6. Concerning buffer sizes, quality, output size etc.
-7. It hangs/crashes/fails/whatevers! Help!
-8. Maintainers/Contacting
-9. License
-
-===========================
-
-1. What cards are supported
-
-Iomega Buz, Linux Media Labs LML33/LML33R10, Pinnacle/Miro
-DC10/DC10+/DC30/DC30+ and related boards (available under various names).
-
-Iomega Buz:
-* Zoran zr36067 PCI controller
-* Zoran zr36060 MJPEG codec
-* Philips saa7111 TV decoder
-* Philips saa7185 TV encoder
-Drivers to use: videodev, i2c-core, i2c-algo-bit,
- videocodec, saa7111, saa7185, zr36060, zr36067
-Inputs/outputs: Composite and S-video
-Norms: PAL, SECAM (720x576 @ 25 fps), NTSC (720x480 @ 29.97 fps)
-Card number: 7
-
-AverMedia 6 Eyes AVS6EYES:
-* Zoran zr36067 PCI controller
-* Zoran zr36060 MJPEG codec
-* Samsung ks0127 TV decoder
-* Conexant bt866 TV encoder
-Drivers to use: videodev, i2c-core, i2c-algo-bit,
- videocodec, ks0127, bt866, zr36060, zr36067
-Inputs/outputs: Six physical inputs. 1-6 are composite,
- 1-2, 3-4, 5-6 doubles as S-video,
- 1-3 triples as component.
- One composite output.
-Norms: PAL, SECAM (720x576 @ 25 fps), NTSC (720x480 @ 29.97 fps)
-Card number: 8
-Not autodetected, card=8 is necessary.
-
-Linux Media Labs LML33:
-* Zoran zr36067 PCI controller
-* Zoran zr36060 MJPEG codec
-* Brooktree bt819 TV decoder
-* Brooktree bt856 TV encoder
-Drivers to use: videodev, i2c-core, i2c-algo-bit,
- videocodec, bt819, bt856, zr36060, zr36067
-Inputs/outputs: Composite and S-video
-Norms: PAL (720x576 @ 25 fps), NTSC (720x480 @ 29.97 fps)
-Card number: 5
-
-Linux Media Labs LML33R10:
-* Zoran zr36067 PCI controller
-* Zoran zr36060 MJPEG codec
-* Philips saa7114 TV decoder
-* Analog Devices adv7170 TV encoder
-Drivers to use: videodev, i2c-core, i2c-algo-bit,
- videocodec, saa7114, adv7170, zr36060, zr36067
-Inputs/outputs: Composite and S-video
-Norms: PAL (720x576 @ 25 fps), NTSC (720x480 @ 29.97 fps)
-Card number: 6
-
-Pinnacle/Miro DC10(new):
-* Zoran zr36057 PCI controller
-* Zoran zr36060 MJPEG codec
-* Philips saa7110a TV decoder
-* Analog Devices adv7176 TV encoder
-Drivers to use: videodev, i2c-core, i2c-algo-bit,
- videocodec, saa7110, adv7175, zr36060, zr36067
-Inputs/outputs: Composite, S-video and Internal
-Norms: PAL, SECAM (768x576 @ 25 fps), NTSC (640x480 @ 29.97 fps)
-Card number: 1
-
-Pinnacle/Miro DC10+:
-* Zoran zr36067 PCI controller
-* Zoran zr36060 MJPEG codec
-* Philips saa7110a TV decoder
-* Analog Devices adv7176 TV encoder
-Drivers to use: videodev, i2c-core, i2c-algo-bit,
- videocodec, sa7110, adv7175, zr36060, zr36067
-Inputs/outputs: Composite, S-video and Internal
-Norms: PAL, SECAM (768x576 @ 25 fps), NTSC (640x480 @ 29.97 fps)
-Card number: 2
-
-Pinnacle/Miro DC10(old): *
-* Zoran zr36057 PCI controller
-* Zoran zr36050 MJPEG codec
-* Zoran zr36016 Video Front End or Fuji md0211 Video Front End (clone?)
-* Micronas vpx3220a TV decoder
-* mse3000 TV encoder or Analog Devices adv7176 TV encoder *
-Drivers to use: videodev, i2c-core, i2c-algo-bit,
- videocodec, vpx3220, mse3000/adv7175, zr36050, zr36016, zr36067
-Inputs/outputs: Composite, S-video and Internal
-Norms: PAL, SECAM (768x576 @ 25 fps), NTSC (640x480 @ 29.97 fps)
-Card number: 0
-
-Pinnacle/Miro DC30: *
-* Zoran zr36057 PCI controller
-* Zoran zr36050 MJPEG codec
-* Zoran zr36016 Video Front End
-* Micronas vpx3225d/vpx3220a/vpx3216b TV decoder
-* Analog Devices adv7176 TV encoder
-Drivers to use: videodev, i2c-core, i2c-algo-bit,
- videocodec, vpx3220/vpx3224, adv7175, zr36050, zr36016, zr36067
-Inputs/outputs: Composite, S-video and Internal
-Norms: PAL, SECAM (768x576 @ 25 fps), NTSC (640x480 @ 29.97 fps)
-Card number: 3
-
-Pinnacle/Miro DC30+: *
-* Zoran zr36067 PCI controller
-* Zoran zr36050 MJPEG codec
-* Zoran zr36016 Video Front End
-* Micronas vpx3225d/vpx3220a/vpx3216b TV decoder
-* Analog Devices adv7176 TV encoder
-Drivers to use: videodev, i2c-core, i2c-algo-bit,
- videocodec, vpx3220/vpx3224, adv7175, zr36050, zr36015, zr36067
-Inputs/outputs: Composite, S-video and Internal
-Norms: PAL, SECAM (768x576 @ 25 fps), NTSC (640x480 @ 29.97 fps)
-Card number: 4
-
-Note: No module for the mse3000 is available yet
-Note: No module for the vpx3224 is available yet
-
-===========================
-
-1.1 What the TV decoder can do an what not
-
-The best know TV standards are NTSC/PAL/SECAM. but for decoding a frame that
-information is not enough. There are several formats of the TV standards.
-And not every TV decoder is able to handle every format. Also the every
-combination is supported by the driver. There are currently 11 different
-tv broadcast formats all aver the world.
-
-The CCIR defines parameters needed for broadcasting the signal.
-The CCIR has defined different standards: A,B,D,E,F,G,D,H,I,K,K1,L,M,N,...
-The CCIR says not much about the colorsystem used !!!
-And talking about a colorsystem says not to much about how it is broadcast.
-
-The CCIR standards A,E,F are not used any more.
-
-When you speak about NTSC, you usually mean the standard: CCIR - M using
-the NTSC colorsystem which is used in the USA, Japan, Mexico, Canada
-and a few others.
-
-When you talk about PAL, you usually mean: CCIR - B/G using the PAL
-colorsystem which is used in many Countries.
-
-When you talk about SECAM, you mean: CCIR - L using the SECAM Colorsystem
-which is used in France, and a few others.
-
-There the other version of SECAM, CCIR - D/K is used in Bulgaria, China,
-Slovakai, Hungary, Korea (Rep.), Poland, Rumania and a others.
-
-The CCIR - H uses the PAL colorsystem (sometimes SECAM) and is used in
-Egypt, Libya, Sri Lanka, Syrain Arab. Rep.
-
-The CCIR - I uses the PAL colorsystem, and is used in Great Britain, Hong Kong,
-Ireland, Nigeria, South Africa.
-
-The CCIR - N uses the PAL colorsystem and PAL frame size but the NTSC framerate,
-and is used in Argentinia, Uruguay, an a few others
-
-We do not talk about how the audio is broadcast !
-
-A rather good sites about the TV standards are:
-http://www.sony.jp/support/
-http://info.electronicwerkstatt.de/bereiche/fernsehtechnik/frequenzen_und_normen/Fernsehnormen/
-and http://www.cabl.com/restaurant/channel.html
-
-Other weird things around: NTSC 4.43 is a modificated NTSC, which is mainly
-used in PAL VCR's that are able to play back NTSC. PAL 60 seems to be the same
-as NTSC 4.43 . The Datasheets also talk about NTSC 44, It seems as if it would
-be the same as NTSC 4.43.
-NTSC Combs seems to be a decoder mode where the decoder uses a comb filter
-to split coma and luma instead of a Delay line.
-
-But I did not defiantly find out what NTSC Comb is.
-
-Philips saa7111 TV decoder
-was introduced in 1997, is used in the BUZ and
-can handle: PAL B/G/H/I, PAL N, PAL M, NTSC M, NTSC N, NTSC 4.43 and SECAM
-
-Philips saa7110a TV decoder
-was introduced in 1995, is used in the Pinnacle/Miro DC10(new), DC10+ and
-can handle: PAL B/G, NTSC M and SECAM
-
-Philips saa7114 TV decoder
-was introduced in 2000, is used in the LML33R10 and
-can handle: PAL B/G/D/H/I/N, PAL N, PAL M, NTSC M, NTSC 4.43 and SECAM
-
-Brooktree bt819 TV decoder
-was introduced in 1996, and is used in the LML33 and
-can handle: PAL B/D/G/H/I, NTSC M
-
-Micronas vpx3220a TV decoder
-was introduced in 1996, is used in the DC30 and DC30+ and
-can handle: PAL B/G/H/I, PAL N, PAL M, NTSC M, NTSC 44, PAL 60, SECAM,NTSC Comb
-
-Samsung ks0127 TV decoder
-is used in the AVS6EYES card and
-can handle: NTSC-M/N/44, PAL-M/N/B/G/H/I/D/K/L and SECAM
-
-===========================
-
-1.2 What the TV encoder can do an what not
-
-The TV encoder are doing the "same" as the decoder, but in the oder direction.
-You feed them digital data and the generate a Composite or SVHS signal.
-For information about the colorsystems and TV norm take a look in the
-TV decoder section.
-
-Philips saa7185 TV Encoder
-was introduced in 1996, is used in the BUZ
-can generate: PAL B/G, NTSC M
-
-Brooktree bt856 TV Encoder
-was introduced in 1994, is used in the LML33
-can generate: PAL B/D/G/H/I/N, PAL M, NTSC M, PAL-N (Argentina)
-
-Analog Devices adv7170 TV Encoder
-was introduced in 2000, is used in the LML300R10
-can generate: PAL B/D/G/H/I/N, PAL M, NTSC M, PAL 60
-
-Analog Devices adv7175 TV Encoder
-was introduced in 1996, is used in the DC10, DC10+, DC10 old, DC30, DC30+
-can generate: PAL B/D/G/H/I/N, PAL M, NTSC M
-
-ITT mse3000 TV encoder
-was introduced in 1991, is used in the DC10 old
-can generate: PAL , NTSC , SECAM
-
-Conexant bt866 TV encoder
-is used in AVS6EYES, and
-can generate: NTSC/PAL, PALÂM, PALÂN
-
-The adv717x, should be able to produce PAL N. But you find nothing PAL N
-specific in the registers. Seem that you have to reuse a other standard
-to generate PAL N, maybe it would work if you use the PAL M settings.
-
-==========================
-
-2. How do I get this damn thing to work
-
-Load zr36067.o. If it can't autodetect your card, use the card=X insmod
-option with X being the card number as given in the previous section.
-To have more than one card, use card=X1[,X2[,X3,[X4[..]]]]
-
-To automate this, add the following to your /etc/modprobe.d/zoran.conf:
-
-options zr36067 card=X1[,X2[,X3[,X4[..]]]]
-alias char-major-81-0 zr36067
-
-One thing to keep in mind is that this doesn't load zr36067.o itself yet. It
-just automates loading. If you start using xawtv, the device won't load on
-some systems, since you're trying to load modules as a user, which is not
-allowed ("permission denied"). A quick workaround is to add 'Load "v4l"' to
-XF86Config-4 when you use X by default, or to run 'v4l-conf -c <device>' in
-one of your startup scripts (normally rc.local) if you don't use X. Both
-make sure that the modules are loaded on startup, under the root account.
-
-===========================
-
-3. What mainboard should I use (or why doesn't my card work)
-
-<insert lousy disclaimer here>. In short: good=SiS/Intel, bad=VIA.
-
-Experience tells us that people with a Buz, on average, have more problems
-than users with a DC10+/LML33. Also, it tells us that people owning a VIA-
-based mainboard (ktXXX, MVP3) have more problems than users with a mainboard
-based on a different chipset. Here's some notes from Andrew Stevens:
---
-Here's my experience of using LML33 and Buz on various motherboards:
-
-VIA MVP3
- Forget it. Pointless. Doesn't work.
-Intel 430FX (Pentium 200)
- LML33 perfect, Buz tolerable (3 or 4 frames dropped per movie)
-Intel 440BX (early stepping)
- LML33 tolerable. Buz starting to get annoying (6-10 frames/hour)
-Intel 440BX (late stepping)
- Buz tolerable, LML3 almost perfect (occasional single frame drops)
-SiS735
- LML33 perfect, Buz tolerable.
-VIA KT133(*)
- LML33 starting to get annoying, Buz poor enough that I have up.
-
-Both 440BX boards were dual CPU versions.
---
-Bernhard Praschinger later added:
---
-AMD 751
- Buz perfect-tolerable
-AMD 760
- Buz perfect-tolerable
---
-In general, people on the user mailinglist won't give you much of a chance
-if you have a VIA-based motherboard. They may be cheap, but sometimes, you'd
-rather want to spend some more money on better boards. In general, VIA
-mainboard's IDE/PCI performance will also suck badly compared to others.
-You'll noticed the DC10+/DC30+ aren't mentioned anywhere in the overview.
-Basically, you can assume that if the Buz works, the LML33 will work too. If
-the LML33 works, the DC10+/DC30+ will work too. They're most tolerant to
-different mainboard chipsets from all of the supported cards.
-
-If you experience timeouts during capture, buy a better mainboard or lower
-the quality/buffersize during capture (see 'Concerning buffer sizes, quality,
-output size etc.'). If it hangs, there's little we can do as of now. Check
-your IRQs and make sure the card has its own interrupts.
-
-===========================
-
-4. Programming interface
-
-This driver conforms to video4linux2. Support for V4L1 and for the custom
-zoran ioctls has been removed in kernel 2.6.38.
-
-For programming example, please, look at lavrec.c and lavplay.c code in
-the MJPEG-tools (http://mjpeg.sf.net/).
-
-Additional notes for software developers:
-
- The driver returns maxwidth and maxheight parameters according to
- the current TV standard (norm). Therefore, the software which
- communicates with the driver and "asks" for these parameters should
- first set the correct norm. Well, it seems logically correct: TV
- standard is "more constant" for current country than geometry
- settings of a variety of TV capture cards which may work in ITU or
- square pixel format.
-
-===========================
-
-5. Applications
-
-Applications known to work with this driver:
-
-TV viewing:
-* xawtv
-* kwintv
-* probably any TV application that supports video4linux or video4linux2.
-
-MJPEG capture/playback:
-* mjpegtools/lavtools (or Linux Video Studio)
-* gstreamer
-* mplayer
-
-General raw capture:
-* xawtv
-* gstreamer
-* probably any application that supports video4linux or video4linux2
-
-Video editing:
-* Cinelerra
-* MainActor
-* mjpegtools (or Linux Video Studio)
-
-===========================
-
-6. Concerning buffer sizes, quality, output size etc.
-
-The zr36060 can do 1:2 JPEG compression. This is really the theoretical
-maximum that the chipset can reach. The driver can, however, limit compression
-to a maximum (size) of 1:4. The reason for this is that some cards (e.g. Buz)
-can't handle 1:2 compression without stopping capture after only a few minutes.
-With 1:4, it'll mostly work. If you have a Buz, use 'low_bitrate=1' to go into
-1:4 max. compression mode.
-
-100% JPEG quality is thus 1:2 compression in practice. So for a full PAL frame
-(size 720x576). The JPEG fields are stored in YUY2 format, so the size of the
-fields are 720x288x16/2 bits/field (2 fields/frame) = 207360 bytes/field x 2 =
-414720 bytes/frame (add some more bytes for headers and DHT (huffman)/DQT
-(quantization) tables, and you'll get to something like 512kB per frame for
-1:2 compression. For 1:4 compression, you'd have frames of half this size.
-
-Some additional explanation by Martin Samuelsson, which also explains the
-importance of buffer sizes:
---
-> Hmm, I do not think it is really that way. With the current (downloaded
-> at 18:00 Monday) driver I get that output sizes for 10 sec:
-> -q 50 -b 128 : 24.283.332 Bytes
-> -q 50 -b 256 : 48.442.368
-> -q 25 -b 128 : 24.655.992
-> -q 25 -b 256 : 25.859.820
-
-I woke up, and can't go to sleep again. I'll kill some time explaining why
-this doesn't look strange to me.
-
-Let's do some math using a width of 704 pixels. I'm not sure whether the Buz
-actually use that number or not, but that's not too important right now.
-
-704x288 pixels, one field, is 202752 pixels. Divided by 64 pixels per block;
-3168 blocks per field. Each pixel consist of two bytes; 128 bytes per block;
-1024 bits per block. 100% in the new driver mean 1:2 compression; the maximum
-output becomes 512 bits per block. Actually 510, but 512 is simpler to use
-for calculations.
-
-Let's say that we specify d1q50. We thus want 256 bits per block; times 3168
-becomes 811008 bits; 101376 bytes per field. We're talking raw bits and bytes
-here, so we don't need to do any fancy corrections for bits-per-pixel or such
-things. 101376 bytes per field.
-
-d1 video contains two fields per frame. Those sum up to 202752 bytes per
-frame, and one of those frames goes into each buffer.
-
-But wait a second! -b128 gives 128kB buffers! It's not possible to cram
-202752 bytes of JPEG data into 128kB!
-
-This is what the driver notice and automatically compensate for in your
-examples. Let's do some math using this information:
-
-128kB is 131072 bytes. In this buffer, we want to store two fields, which
-leaves 65536 bytes for each field. Using 3168 blocks per field, we get
-20.68686868... available bytes per block; 165 bits. We can't allow the
-request for 256 bits per block when there's only 165 bits available! The -q50
-option is silently overridden, and the -b128 option takes precedence, leaving
-us with the equivalence of -q32.
-
-This gives us a data rate of 165 bits per block, which, times 3168, sums up
-to 65340 bytes per field, out of the allowed 65536. The current driver has
-another level of rate limiting; it won't accept -q values that fill more than
-6/8 of the specified buffers. (I'm not sure why. "Playing it safe" seem to be
-a safe bet. Personally, I think I would have lowered requested-bits-per-block
-by one, or something like that.) We can't use 165 bits per block, but have to
-lower it again, to 6/8 of the available buffer space: We end up with 124 bits
-per block, the equivalence of -q24. With 128kB buffers, you can't use greater
-than -q24 at -d1. (And PAL, and 704 pixels width...)
-
-The third example is limited to -q24 through the same process. The second
-example, using very similar calculations, is limited to -q48. The only
-example that actually grab at the specified -q value is the last one, which
-is clearly visible, looking at the file size.
---
-
-Conclusion: the quality of the resulting movie depends on buffer size, quality,
-whether or not you use 'low_bitrate=1' as insmod option for the zr36060.c
-module to do 1:4 instead of 1:2 compression, etc.
-
-If you experience timeouts, lowering the quality/buffersize or using
-'low_bitrate=1 as insmod option for zr36060.o might actually help, as is
-proven by the Buz.
-
-===========================
-
-7. It hangs/crashes/fails/whatevers! Help!
-
-Make sure that the card has its own interrupts (see /proc/interrupts), check
-the output of dmesg at high verbosity (load zr36067.o with debug=2,
-load all other modules with debug=1). Check that your mainboard is favorable
-(see question 2) and if not, test the card in another computer. Also see the
-notes given in question 3 and try lowering quality/buffersize/capturesize
-if recording fails after a period of time.
-
-If all this doesn't help, give a clear description of the problem including
-detailed hardware information (memory+brand, mainboard+chipset+brand, which
-MJPEG card, processor, other PCI cards that might be of interest), give the
-system PnP information (/proc/interrupts, /proc/dma, /proc/devices), and give
-the kernel version, driver version, glibc version, gcc version and any other
-information that might possibly be of interest. Also provide the dmesg output
-at high verbosity. See 'Contacting' on how to contact the developers.
-
-===========================
-
-8. Maintainers/Contacting
-
-The driver is currently maintained by Laurent Pinchart and Ronald Bultje
-(<laurent.pinchart@skynet.be> and <rbultje@ronald.bitfreak.net>). For bug
-reports or questions, please contact the mailinglist instead of the developers
-individually. For user questions (i.e. bug reports or how-to questions), send
-an email to <mjpeg-users@lists.sf.net>, for developers (i.e. if you want to
-help programming), send an email to <mjpeg-developer@lists.sf.net>. See
-http://www.sf.net/projects/mjpeg/ for subscription information.
-
-For bug reports, be sure to include all the information as described in
-the section 'It hangs/crashes/fails/whatevers! Help!'. Please make sure
-you're using the latest version (http://mjpeg.sf.net/driver-zoran/).
-
-Previous maintainers/developers of this driver include Serguei Miridonov
-<mirsev@cicese.mx>, Wolfgang Scherr <scherr@net4you.net>, Dave Perks
-<dperks@ibm.net> and Rainer Johanni <Rainer@Johanni.de>.
-
-===========================
-
-9. License
-
-This driver is distributed under the terms of the General Public License.
-
- This program is free software; you can redistribute it and/or modify
- it under the terms of the GNU General Public License as published by
- the Free Software Foundation; either version 2 of the License, or
- (at your option) any later version.
-
- This program is distributed in the hope that it will be useful,
- but WITHOUT ANY WARRANTY; without even the implied warranty of
- MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- GNU General Public License for more details.
-
- You should have received a copy of the GNU General Public License
- along with this program; if not, write to the Free Software
- Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
-
-See http://www.gnu.org/ for more information.
+++ /dev/null
-"cafe_ccic" is a driver for the Marvell 88ALP01 "cafe" CMOS camera
-controller. This is the controller found in first-generation OLPC systems,
-and this driver was written with support from the OLPC project.
-
-Current status: the core driver works. It can generate data in YUV422,
-RGB565, and RGB444 formats. (Anybody looking at the code will see RGB32 as
-well, but that is a debugging aid which will be removed shortly). VGA and
-QVGA modes work; CIF is there but the colors remain funky. Only the OV7670
-sensor is known to work with this controller at this time.
-
-To try it out: either of these commands will work:
-
- mplayer tv:// -tv driver=v4l2:width=640:height=480 -nosound
- mplayer tv:// -tv driver=v4l2:width=640:height=480:outfmt=bgr16 -nosound
-
-The "xawtv" utility also works; gqcam does not, for unknown reasons.
-
-There are a few load-time options, most of which can be changed after
-loading via sysfs as well:
-
- - alloc_bufs_at_load: Normally, the driver will not allocate any DMA
- buffers until the time comes to transfer data. If this option is set,
- then worst-case-sized buffers will be allocated at module load time.
- This option nails down the memory for the life of the module, but
- perhaps decreases the chances of an allocation failure later on.
-
- - dma_buf_size: The size of DMA buffers to allocate. Note that this
- option is only consulted for load-time allocation; when buffers are
- allocated at run time, they will be sized appropriately for the current
- camera settings.
-
- - n_dma_bufs: The controller can cycle through either two or three DMA
- buffers. Normally, the driver tries to use three buffers; on faster
- systems, however, it will work well with only two.
-
- - min_buffers: The minimum number of streaming I/O buffers that the driver
- will consent to work with. Default is one, but, on slower systems,
- better behavior with mplayer can be achieved by setting to a higher
- value (like six).
-
- - max_buffers: The maximum number of streaming I/O buffers; default is
- ten. That number was carefully picked out of a hat and should not be
- assumed to actually mean much of anything.
-
- - flip: If this boolean parameter is set, the sensor will be instructed to
- invert the video image. Whether it makes sense is determined by how
- your particular camera is mounted.
-
-Work is ongoing with this driver, stay tuned.
-
-jon
-
-Jonathan Corbet
-corbet@lwn.net
+++ /dev/null
- Programmer's View of Cpia2
-
-Cpia2 is the second generation video coprocessor from VLSI Vision Ltd (now a
-division of ST Microelectronics). There are two versions. The first is the
-STV0672, which is capable of up to 30 frames per second (fps) in frame sizes
-up to CIF, and 15 fps for VGA frames. The STV0676 is an improved version,
-which can handle up to 30 fps VGA. Both coprocessors can be attached to two
-CMOS sensors - the vvl6410 CIF sensor and the vvl6500 VGA sensor. These will
-be referred to as the 410 and the 500 sensors, or the CIF and VGA sensors.
-
-The two chipsets operate almost identically. The core is an 8051 processor,
-running two different versions of firmware. The 672 runs the VP4 video
-processor code, the 676 runs VP5. There are a few differences in register
-mappings for the two chips. In these cases, the symbols defined in the
-header files are marked with VP4 or VP5 as part of the symbol name.
-
-The cameras appear externally as three sets of registers. Setting register
-values is the only way to control the camera. Some settings are
-interdependant, such as the sequence required to power up the camera. I will
-try to make note of all of these cases.
-
-The register sets are called blocks. Block 0 is the system block. This
-section is always powered on when the camera is plugged in. It contains
-registers that control housekeeping functions such as powering up the video
-processor. The video processor is the VP block. These registers control
-how the video from the sensor is processed. Examples are timing registers,
-user mode (vga, qvga), scaling, cropping, framerates, and so on. The last
-block is the video compressor (VC). The video stream sent from the camera is
-compressed as Motion JPEG (JPEGA). The VC controls all of the compression
-parameters. Looking at the file cpia2_registers.h, you can get a full view
-of these registers and the possible values for most of them.
-
-One or more registers can be set or read by sending a usb control message to
-the camera. There are three modes for this. Block mode requests a number
-of contiguous registers. Random mode reads or writes random registers with
-a tuple structure containing address/value pairs. The repeat mode is only
-used by VP4 to load a firmware patch. It contains a starting address and
-a sequence of bytes to be written into a gpio port.
+++ /dev/null
-Some notes regarding the cx18 driver for the Conexant CX23418 MPEG
-encoder chip:
-
-1) Currently supported are:
-
- - Hauppauge HVR-1600
- - Compro VideoMate H900
- - Yuan MPC718
- - Conexant Raptor PAL/SECAM devkit
-
-2) Some people have problems getting the i2c bus to work.
- The symptom is that the eeprom cannot be read and the card is
- unusable. This is probably fixed, but if you have problems
- then post to the video4linux or ivtv-users mailing list.
-
-3) VBI (raw or sliced) has not yet been implemented.
-
-4) MPEG indexing is not yet implemented.
-
-5) The driver is still a bit rough around the edges, this should
- improve over time.
-
-
-Firmware:
-
-You can obtain the firmware files here:
-
-http://dl.ivtvdriver.org/ivtv/firmware/cx18-firmware.tar.gz
-
-Untar and copy the .fw files to your firmware directory.
+++ /dev/null
-Samsung S5P/EXYNOS4 FIMC driver
-
-Copyright (C) 2012 - 2013 Samsung Electronics Co., Ltd.
----------------------------------------------------------------------------
-
-The FIMC (Fully Interactive Mobile Camera) device available in Samsung
-SoC Application Processors is an integrated camera host interface, color
-space converter, image resizer and rotator. It's also capable of capturing
-data from LCD controller (FIMD) through the SoC internal writeback data
-path. There are multiple FIMC instances in the SoCs (up to 4), having
-slightly different capabilities, like pixel alignment constraints, rotator
-availability, LCD writeback support, etc. The driver is located at
-drivers/media/platform/exynos4-is directory.
-
-1. Supported SoCs
-=================
-
-S5PC100 (mem-to-mem only), S5PV210, EXYNOS4210
-
-2. Supported features
-=====================
-
- - camera parallel interface capture (ITU-R.BT601/565);
- - camera serial interface capture (MIPI-CSI2);
- - memory-to-memory processing (color space conversion, scaling, mirror
- and rotation);
- - dynamic pipeline re-configuration at runtime (re-attachment of any FIMC
- instance to any parallel video input or any MIPI-CSI front-end);
- - runtime PM and system wide suspend/resume
-
-Not currently supported:
- - LCD writeback input
- - per frame clock gating (mem-to-mem)
-
-3. Files partitioning
-=====================
-
-- media device driver
- drivers/media/platform/exynos4-is/media-dev.[ch]
-
- - camera capture video device driver
- drivers/media/platform/exynos4-is/fimc-capture.c
-
- - MIPI-CSI2 receiver subdev
- drivers/media/platform/exynos4-is/mipi-csis.[ch]
-
- - video post-processor (mem-to-mem)
- drivers/media/platform/exynos4-is/fimc-core.c
-
- - common files
- drivers/media/platform/exynos4-is/fimc-core.h
- drivers/media/platform/exynos4-is/fimc-reg.h
- drivers/media/platform/exynos4-is/regs-fimc.h
-
-4. User space interfaces
-========================
-
-4.1. Media device interface
-
-The driver supports Media Controller API as defined at
-https://linuxtv.org/downloads/v4l-dvb-apis/media_common.html
-The media device driver name is "SAMSUNG S5P FIMC".
-
-The purpose of this interface is to allow changing assignment of FIMC instances
-to the SoC peripheral camera input at runtime and optionally to control internal
-connections of the MIPI-CSIS device(s) to the FIMC entities.
-
-The media device interface allows to configure the SoC for capturing image
-data from the sensor through more than one FIMC instance (e.g. for simultaneous
-viewfinder and still capture setup).
-Reconfiguration is done by enabling/disabling media links created by the driver
-during initialization. The internal device topology can be easily discovered
-through media entity and links enumeration.
-
-4.2. Memory-to-memory video node
-
-V4L2 memory-to-memory interface at /dev/video? device node. This is standalone
-video device, it has no media pads. However please note the mem-to-mem and
-capture video node operation on same FIMC instance is not allowed. The driver
-detects such cases but the applications should prevent them to avoid an
-undefined behaviour.
-
-4.3. Capture video node
-
-The driver supports V4L2 Video Capture Interface as defined at:
-https://linuxtv.org/downloads/v4l-dvb-apis/devices.html
-
-At the capture and mem-to-mem video nodes only the multi-planar API is
-supported. For more details see:
-https://linuxtv.org/downloads/v4l-dvb-apis/planar-apis.html
-
-4.4. Camera capture subdevs
-
-Each FIMC instance exports a sub-device node (/dev/v4l-subdev?), a sub-device
-node is also created per each available and enabled at the platform level
-MIPI-CSI receiver device (currently up to two).
-
-4.5. sysfs
-
-In order to enable more precise camera pipeline control through the sub-device
-API the driver creates a sysfs entry associated with "s5p-fimc-md" platform
-device. The entry path is: /sys/platform/devices/s5p-fimc-md/subdev_conf_mode.
-
-In typical use case there could be a following capture pipeline configuration:
-sensor subdev -> mipi-csi subdev -> fimc subdev -> video node
-
-When we configure these devices through sub-device API at user space, the
-configuration flow must be from left to right, and the video node is
-configured as last one.
-When we don't use sub-device user space API the whole configuration of all
-devices belonging to the pipeline is done at the video node driver.
-The sysfs entry allows to instruct the capture node driver not to configure
-the sub-devices (format, crop), to avoid resetting the subdevs' configuration
-when the last configuration steps at the video node is performed.
-
-For full sub-device control support (subdevs configured at user space before
-starting streaming):
-# echo "sub-dev" > /sys/platform/devices/s5p-fimc-md/subdev_conf_mode
-
-For V4L2 video node control only (subdevs configured internally by the host
-driver):
-# echo "vid-dev" > /sys/platform/devices/s5p-fimc-md/subdev_conf_mode
-This is a default option.
-
-5. Device mapping to video and subdev device nodes
-==================================================
-
-There are associated two video device nodes with each device instance in
-hardware - video capture and mem-to-mem and additionally a subdev node for
-more precise FIMC capture subsystem control. In addition a separate v4l2
-sub-device node is created per each MIPI-CSIS device.
-
-How to find out which /dev/video? or /dev/v4l-subdev? is assigned to which
-device?
-
-You can either grep through the kernel log to find relevant information, i.e.
-# dmesg | grep -i fimc
-(note that udev, if present, might still have rearranged the video nodes),
-
-or retrieve the information from /dev/media? with help of the media-ctl tool:
-# media-ctl -p
-
-7. Build
-========
-
-If the driver is built as a loadable kernel module (CONFIG_VIDEO_SAMSUNG_S5P_FIMC=m)
-two modules are created (in addition to the core v4l2 modules): s5p-fimc.ko and
-optional s5p-csis.ko (MIPI-CSI receiver subdev).
+++ /dev/null
-List of the webcams known by gspca.
-
-The modules are:
- gspca_main main driver
- gspca_xxxx subdriver module with xxxx as follows
-
-xxxx vend:prod
-----
-spca501 0000:0000 MystFromOri Unknown Camera
-spca508 0130:0130 Clone Digital Webcam 11043
-zc3xx 03f0:1b07 HP Premium Starter Cam
-m5602 0402:5602 ALi Video Camera Controller
-spca501 040a:0002 Kodak DVC-325
-spca500 040a:0300 Kodak EZ200
-zc3xx 041e:041e Creative WebCam Live!
-ov519 041e:4003 Video Blaster WebCam Go Plus
-spca500 041e:400a Creative PC-CAM 300
-sunplus 041e:400b Creative PC-CAM 600
-sunplus 041e:4012 PC-Cam350
-sunplus 041e:4013 Creative Pccam750
-zc3xx 041e:4017 Creative Webcam Mobile PD1090
-spca508 041e:4018 Creative Webcam Vista (PD1100)
-spca561 041e:401a Creative Webcam Vista (PD1100)
-zc3xx 041e:401c Creative NX
-spca505 041e:401d Creative Webcam NX ULTRA
-zc3xx 041e:401e Creative Nx Pro
-zc3xx 041e:401f Creative Webcam Notebook PD1171
-pac207 041e:4028 Creative Webcam Vista Plus
-zc3xx 041e:4029 Creative WebCam Vista Pro
-zc3xx 041e:4034 Creative Instant P0620
-zc3xx 041e:4035 Creative Instant P0620D
-zc3xx 041e:4036 Creative Live !
-sq930x 041e:4038 Creative Joy-IT
-zc3xx 041e:403a Creative Nx Pro 2
-spca561 041e:403b Creative Webcam Vista (VF0010)
-sq930x 041e:403c Creative Live! Ultra
-sq930x 041e:403d Creative Live! Ultra for Notebooks
-sq930x 041e:4041 Creative Live! Motion
-zc3xx 041e:4051 Creative Live!Cam Notebook Pro (VF0250)
-ov519 041e:4052 Creative Live! VISTA IM
-zc3xx 041e:4053 Creative Live!Cam Video IM
-vc032x 041e:405b Creative Live! Cam Notebook Ultra (VC0130)
-ov519 041e:405f Creative Live! VISTA VF0330
-ov519 041e:4060 Creative Live! VISTA VF0350
-ov519 041e:4061 Creative Live! VISTA VF0400
-ov519 041e:4064 Creative Live! VISTA VF0420
-ov519 041e:4067 Creative Live! Cam Video IM (VF0350)
-ov519 041e:4068 Creative Live! VISTA VF0470
-spca561 0458:7004 Genius VideoCAM Express V2
-sn9c2028 0458:7005 Genius Smart 300, version 2
-sunplus 0458:7006 Genius Dsc 1.3 Smart
-zc3xx 0458:7007 Genius VideoCam V2
-zc3xx 0458:700c Genius VideoCam V3
-zc3xx 0458:700f Genius VideoCam Web V2
-sonixj 0458:7025 Genius Eye 311Q
-sn9c20x 0458:7029 Genius Look 320s
-sonixj 0458:702e Genius Slim 310 NB
-sn9c20x 0458:7045 Genius Look 1320 V2
-sn9c20x 0458:704a Genius Slim 1320
-sn9c20x 0458:704c Genius i-Look 1321
-sn9c20x 045e:00f4 LifeCam VX-6000 (SN9C20x + OV9650)
-sonixj 045e:00f5 MicroSoft VX3000
-sonixj 045e:00f7 MicroSoft VX1000
-ov519 045e:028c Micro$oft xbox cam
-spca508 0461:0815 Micro Innovation IC200
-sunplus 0461:0821 Fujifilm MV-1
-zc3xx 0461:0a00 MicroInnovation WebCam320
-stv06xx 046d:0840 QuickCam Express
-stv06xx 046d:0850 LEGO cam / QuickCam Web
-stv06xx 046d:0870 Dexxa WebCam USB
-spca500 046d:0890 Logitech QuickCam traveler
-vc032x 046d:0892 Logitech Orbicam
-vc032x 046d:0896 Logitech Orbicam
-vc032x 046d:0897 Logitech QuickCam for Dell notebooks
-zc3xx 046d:089d Logitech QuickCam E2500
-zc3xx 046d:08a0 Logitech QC IM
-zc3xx 046d:08a1 Logitech QC IM 0x08A1 +sound
-zc3xx 046d:08a2 Labtec Webcam Pro
-zc3xx 046d:08a3 Logitech QC Chat
-zc3xx 046d:08a6 Logitech QCim
-zc3xx 046d:08a7 Logitech QuickCam Image
-zc3xx 046d:08a9 Logitech Notebook Deluxe
-zc3xx 046d:08aa Labtec Webcam Notebook
-zc3xx 046d:08ac Logitech QuickCam Cool
-zc3xx 046d:08ad Logitech QCCommunicate STX
-zc3xx 046d:08ae Logitech QuickCam for Notebooks
-zc3xx 046d:08af Logitech QuickCam Cool
-zc3xx 046d:08b9 Logitech QuickCam Express
-zc3xx 046d:08d7 Logitech QCam STX
-zc3xx 046d:08d9 Logitech QuickCam IM/Connect
-zc3xx 046d:08d8 Logitech Notebook Deluxe
-zc3xx 046d:08da Logitech QuickCam Messenger
-zc3xx 046d:08dd Logitech QuickCam for Notebooks
-spca500 046d:0900 Logitech Inc. ClickSmart 310
-spca500 046d:0901 Logitech Inc. ClickSmart 510
-sunplus 046d:0905 Logitech ClickSmart 820
-tv8532 046d:0920 Logitech QuickCam Express
-tv8532 046d:0921 Labtec Webcam
-spca561 046d:0928 Logitech QC Express Etch2
-spca561 046d:0929 Labtec Webcam Elch2
-spca561 046d:092a Logitech QC for Notebook
-spca561 046d:092b Labtec Webcam Plus
-spca561 046d:092c Logitech QC chat Elch2
-spca561 046d:092d Logitech QC Elch2
-spca561 046d:092e Logitech QC Elch2
-spca561 046d:092f Logitech QuickCam Express Plus
-sunplus 046d:0960 Logitech ClickSmart 420
-nw80x 046d:d001 Logitech QuickCam Pro (dark focus ring)
-sunplus 0471:0322 Philips DMVC1300K
-zc3xx 0471:0325 Philips SPC 200 NC
-zc3xx 0471:0326 Philips SPC 300 NC
-sonixj 0471:0327 Philips SPC 600 NC
-sonixj 0471:0328 Philips SPC 700 NC
-zc3xx 0471:032d Philips SPC 210 NC
-zc3xx 0471:032e Philips SPC 315 NC
-sonixj 0471:0330 Philips SPC 710 NC
-spca501 0497:c001 Smile International
-sunplus 04a5:3003 Benq DC 1300
-sunplus 04a5:3008 Benq DC 1500
-sunplus 04a5:300a Benq DC 3410
-spca500 04a5:300c Benq DC 1016
-benq 04a5:3035 Benq DC E300
-finepix 04cb:0104 Fujifilm FinePix 4800
-finepix 04cb:0109 Fujifilm FinePix A202
-finepix 04cb:010b Fujifilm FinePix A203
-finepix 04cb:010f Fujifilm FinePix A204
-finepix 04cb:0111 Fujifilm FinePix A205
-finepix 04cb:0113 Fujifilm FinePix A210
-finepix 04cb:0115 Fujifilm FinePix A303
-finepix 04cb:0117 Fujifilm FinePix A310
-finepix 04cb:0119 Fujifilm FinePix F401
-finepix 04cb:011b Fujifilm FinePix F402
-finepix 04cb:011d Fujifilm FinePix F410
-finepix 04cb:0121 Fujifilm FinePix F601
-finepix 04cb:0123 Fujifilm FinePix F700
-finepix 04cb:0125 Fujifilm FinePix M603
-finepix 04cb:0127 Fujifilm FinePix S300
-finepix 04cb:0129 Fujifilm FinePix S304
-finepix 04cb:012b Fujifilm FinePix S500
-finepix 04cb:012d Fujifilm FinePix S602
-finepix 04cb:012f Fujifilm FinePix S700
-finepix 04cb:0131 Fujifilm FinePix unknown model
-finepix 04cb:013b Fujifilm FinePix unknown model
-finepix 04cb:013d Fujifilm FinePix unknown model
-finepix 04cb:013f Fujifilm FinePix F420
-sunplus 04f1:1001 JVC GC A50
-spca561 04fc:0561 Flexcam 100
-spca1528 04fc:1528 Sunplus MD80 clone
-sunplus 04fc:500c Sunplus CA500C
-sunplus 04fc:504a Aiptek Mini PenCam 1.3
-sunplus 04fc:504b Maxell MaxPocket LE 1.3
-sunplus 04fc:5330 Digitrex 2110
-sunplus 04fc:5360 Sunplus Generic
-spca500 04fc:7333 PalmPixDC85
-sunplus 04fc:ffff Pure DigitalDakota
-nw80x 0502:d001 DVC V6
-spca501 0506:00df 3Com HomeConnect Lite
-sunplus 052b:1507 Megapixel 5 Pretec DC-1007
-sunplus 052b:1513 Megapix V4
-sunplus 052b:1803 MegaImage VI
-nw80x 052b:d001 EZCam Pro p35u
-tv8532 0545:808b Veo Stingray
-tv8532 0545:8333 Veo Stingray
-sunplus 0546:3155 Polaroid PDC3070
-sunplus 0546:3191 Polaroid Ion 80
-sunplus 0546:3273 Polaroid PDC2030
-ov519 054c:0154 Sonny toy4
-ov519 054c:0155 Sonny toy5
-cpia1 0553:0002 CPIA CPiA (version1) based cameras
-zc3xx 055f:c005 Mustek Wcam300A
-spca500 055f:c200 Mustek Gsmart 300
-sunplus 055f:c211 Kowa Bs888e Microcamera
-spca500 055f:c220 Gsmart Mini
-sunplus 055f:c230 Mustek Digicam 330K
-sunplus 055f:c232 Mustek MDC3500
-sunplus 055f:c360 Mustek DV4000 Mpeg4
-sunplus 055f:c420 Mustek gSmart Mini 2
-sunplus 055f:c430 Mustek Gsmart LCD 2
-sunplus 055f:c440 Mustek DV 3000
-sunplus 055f:c520 Mustek gSmart Mini 3
-sunplus 055f:c530 Mustek Gsmart LCD 3
-sunplus 055f:c540 Gsmart D30
-sunplus 055f:c630 Mustek MDC4000
-sunplus 055f:c650 Mustek MDC5500Z
-nw80x 055f:d001 Mustek Wcam 300 mini
-zc3xx 055f:d003 Mustek WCam300A
-zc3xx 055f:d004 Mustek WCam300 AN
-conex 0572:0041 Creative Notebook cx11646
-ov519 05a9:0511 Video Blaster WebCam 3/WebCam Plus, D-Link USB Digital Video Camera
-ov519 05a9:0518 Creative WebCam
-ov519 05a9:0519 OV519 Microphone
-ov519 05a9:0530 OmniVision
-ov534_9 05a9:1550 OmniVision VEHO Filmscanner
-ov519 05a9:2800 OmniVision SuperCAM
-ov519 05a9:4519 Webcam Classic
-ov534_9 05a9:8065 OmniVision test kit ov538+ov9712
-ov519 05a9:8519 OmniVision
-ov519 05a9:a511 D-Link USB Digital Video Camera
-ov519 05a9:a518 D-Link DSB-C310 Webcam
-sunplus 05da:1018 Digital Dream Enigma 1.3
-stk014 05e1:0893 Syntek DV4000
-gl860 05e3:0503 Genesys Logic PC Camera
-gl860 05e3:f191 Genesys Logic PC Camera
-spca561 060b:a001 Maxell Compact Pc PM3
-zc3xx 0698:2003 CTX M730V built in
-topro 06a2:0003 TP6800 PC Camera, CmoX CX0342 webcam
-topro 06a2:6810 Creative Qmax
-nw80x 06a5:0000 Typhoon Webcam 100 USB
-nw80x 06a5:d001 Divio based webcams
-nw80x 06a5:d800 Divio Chicony TwinkleCam, Trust SpaceCam
-spca500 06bd:0404 Agfa CL20
-spca500 06be:0800 Optimedia
-nw80x 06be:d001 EZCam Pro p35u
-sunplus 06d6:0031 Trust 610 LCD PowerC@m Zoom
-spca506 06e1:a190 ADS Instant VCD
-ov534 06f8:3002 Hercules Blog Webcam
-ov534_9 06f8:3003 Hercules Dualpix HD Weblog
-sonixj 06f8:3004 Hercules Classic Silver
-sonixj 06f8:3008 Hercules Deluxe Optical Glass
-pac7302 06f8:3009 Hercules Classic Link
-pac7302 06f8:301b Hercules Link
-nw80x 0728:d001 AVerMedia Camguard
-spca508 0733:0110 ViewQuest VQ110
-spca501 0733:0401 Intel Create and Share
-spca501 0733:0402 ViewQuest M318B
-spca505 0733:0430 Intel PC Camera Pro
-sunplus 0733:1311 Digital Dream Epsilon 1.3
-sunplus 0733:1314 Mercury 2.1MEG Deluxe Classic Cam
-sunplus 0733:2211 Jenoptik jdc 21 LCD
-sunplus 0733:2221 Mercury Digital Pro 3.1p
-sunplus 0733:3261 Concord 3045 spca536a
-sunplus 0733:3281 Cyberpix S550V
-spca506 0734:043b 3DeMon USB Capture aka
-cpia1 0813:0001 QX3 camera
-ov519 0813:0002 Dual Mode USB Camera Plus
-spca500 084d:0003 D-Link DSC-350
-spca500 08ca:0103 Aiptek PocketDV
-sunplus 08ca:0104 Aiptek PocketDVII 1.3
-sunplus 08ca:0106 Aiptek Pocket DV3100+
-mr97310a 08ca:0110 Trust Spyc@m 100
-mr97310a 08ca:0111 Aiptek PenCam VGA+
-sunplus 08ca:2008 Aiptek Mini PenCam 2 M
-sunplus 08ca:2010 Aiptek PocketCam 3M
-sunplus 08ca:2016 Aiptek PocketCam 2 Mega
-sunplus 08ca:2018 Aiptek Pencam SD 2M
-sunplus 08ca:2020 Aiptek Slim 3000F
-sunplus 08ca:2022 Aiptek Slim 3200
-sunplus 08ca:2024 Aiptek DV3500 Mpeg4
-sunplus 08ca:2028 Aiptek PocketCam4M
-sunplus 08ca:2040 Aiptek PocketDV4100M
-sunplus 08ca:2042 Aiptek PocketDV5100
-sunplus 08ca:2050 Medion MD 41437
-sunplus 08ca:2060 Aiptek PocketDV5300
-tv8532 0923:010f ICM532 cams
-mars 093a:050f Mars-Semi Pc-Camera
-mr97310a 093a:010e All known CIF cams with this ID
-mr97310a 093a:010f All known VGA cams with this ID
-pac207 093a:2460 Qtec Webcam 100
-pac207 093a:2461 HP Webcam
-pac207 093a:2463 Philips SPC 220 NC
-pac207 093a:2464 Labtec Webcam 1200
-pac207 093a:2468 Webcam WB-1400T
-pac207 093a:2470 Genius GF112
-pac207 093a:2471 Genius VideoCam ge111
-pac207 093a:2472 Genius VideoCam ge110
-pac207 093a:2474 Genius iLook 111
-pac207 093a:2476 Genius e-Messenger 112
-pac7311 093a:2600 PAC7311 Typhoon
-pac7311 093a:2601 Philips SPC 610 NC
-pac7311 093a:2603 Philips SPC 500 NC
-pac7311 093a:2608 Trust WB-3300p
-pac7311 093a:260e Gigaware VGA PC Camera, Trust WB-3350p, SIGMA cam 2350
-pac7311 093a:260f SnakeCam
-pac7302 093a:2620 Apollo AC-905
-pac7302 093a:2621 PAC731x
-pac7302 093a:2622 Genius Eye 312
-pac7302 093a:2624 PAC7302
-pac7302 093a:2625 Genius iSlim 310
-pac7302 093a:2626 Labtec 2200
-pac7302 093a:2627 Genius FaceCam 300
-pac7302 093a:2628 Genius iLook 300
-pac7302 093a:2629 Genious iSlim 300
-pac7302 093a:262a Webcam 300k
-pac7302 093a:262c Philips SPC 230 NC
-jl2005bcd 0979:0227 Various brands, 19 known cameras supported
-jeilinj 0979:0280 Sakar 57379
-jeilinj 0979:0280 Sportscam DV15
-zc3xx 0ac8:0302 Z-star Vimicro zc0302
-vc032x 0ac8:0321 Vimicro generic vc0321
-vc032x 0ac8:0323 Vimicro Vc0323
-vc032x 0ac8:0328 A4Tech PK-130MG
-zc3xx 0ac8:301b Z-Star zc301b
-zc3xx 0ac8:303b Vimicro 0x303b
-zc3xx 0ac8:305b Z-star Vimicro zc0305b
-zc3xx 0ac8:307b PC Camera (ZS0211)
-vc032x 0ac8:c001 Sony embedded vimicro
-vc032x 0ac8:c002 Sony embedded vimicro
-vc032x 0ac8:c301 Samsung Q1 Ultra Premium
-spca508 0af9:0010 Hama USB Sightcam 100
-spca508 0af9:0011 Hama USB Sightcam 100
-ov519 0b62:0059 iBOT2 Webcam
-sonixb 0c45:6001 Genius VideoCAM NB
-sonixb 0c45:6005 Microdia Sweex Mini Webcam
-sonixb 0c45:6007 Sonix sn9c101 + Tas5110D
-sonixb 0c45:6009 spcaCam@120
-sonixb 0c45:600d spcaCam@120
-sonixb 0c45:6011 Microdia PC Camera (SN9C102)
-sonixb 0c45:6019 Generic Sonix OV7630
-sonixb 0c45:6024 Generic Sonix Tas5130c
-sonixb 0c45:6025 Xcam Shanga
-sonixb 0c45:6028 Sonix Btc Pc380
-sonixb 0c45:6029 spcaCam@150
-sonixb 0c45:602c Generic Sonix OV7630
-sonixb 0c45:602d LIC-200 LG
-sonixb 0c45:602e Genius VideoCam Messenger
-sonixj 0c45:6040 Speed NVC 350K
-sonixj 0c45:607c Sonix sn9c102p Hv7131R
-sonixj 0c45:60c0 Sangha Sn535
-sonixj 0c45:60ce USB-PC-Camera-168 (TALK-5067)
-sonixj 0c45:60ec SN9C105+MO4000
-sonixj 0c45:60fb Surfer NoName
-sonixj 0c45:60fc LG-LIC300
-sonixj 0c45:60fe Microdia Audio
-sonixj 0c45:6100 PC Camera (SN9C128)
-sonixj 0c45:6102 PC Camera (SN9C128)
-sonixj 0c45:610a PC Camera (SN9C128)
-sonixj 0c45:610b PC Camera (SN9C128)
-sonixj 0c45:610c PC Camera (SN9C128)
-sonixj 0c45:610e PC Camera (SN9C128)
-sonixj 0c45:6128 Microdia/Sonix SNP325
-sonixj 0c45:612a Avant Camera
-sonixj 0c45:612b Speed-Link REFLECT2
-sonixj 0c45:612c Typhoon Rasy Cam 1.3MPix
-sonixj 0c45:6130 Sonix Pccam
-sonixj 0c45:6138 Sn9c120 Mo4000
-sonixj 0c45:613a Microdia Sonix PC Camera
-sonixj 0c45:613b Surfer SN-206
-sonixj 0c45:613c Sonix Pccam168
-sonixj 0c45:6142 Hama PC-Webcam AC-150
-sonixj 0c45:6143 Sonix Pccam168
-sonixj 0c45:6148 Digitus DA-70811/ZSMC USB PC Camera ZS211/Microdia
-sonixj 0c45:614a Frontech E-Ccam (JIL-2225)
-sn9c20x 0c45:6240 PC Camera (SN9C201 + MT9M001)
-sn9c20x 0c45:6242 PC Camera (SN9C201 + MT9M111)
-sn9c20x 0c45:6248 PC Camera (SN9C201 + OV9655)
-sn9c20x 0c45:624c PC Camera (SN9C201 + MT9M112)
-sn9c20x 0c45:624e PC Camera (SN9C201 + SOI968)
-sn9c20x 0c45:624f PC Camera (SN9C201 + OV9650)
-sn9c20x 0c45:6251 PC Camera (SN9C201 + OV9650)
-sn9c20x 0c45:6253 PC Camera (SN9C201 + OV9650)
-sn9c20x 0c45:6260 PC Camera (SN9C201 + OV7670)
-sn9c20x 0c45:6270 PC Camera (SN9C201 + MT9V011/MT9V111/MT9V112)
-sn9c20x 0c45:627b PC Camera (SN9C201 + OV7660)
-sn9c20x 0c45:627c PC Camera (SN9C201 + HV7131R)
-sn9c20x 0c45:627f PC Camera (SN9C201 + OV9650)
-sn9c20x 0c45:6280 PC Camera (SN9C202 + MT9M001)
-sn9c20x 0c45:6282 PC Camera (SN9C202 + MT9M111)
-sn9c20x 0c45:6288 PC Camera (SN9C202 + OV9655)
-sn9c20x 0c45:628c PC Camera (SN9C201 + MT9M112)
-sn9c20x 0c45:628e PC Camera (SN9C202 + SOI968)
-sn9c20x 0c45:628f PC Camera (SN9C202 + OV9650)
-sn9c20x 0c45:62a0 PC Camera (SN9C202 + OV7670)
-sn9c20x 0c45:62b0 PC Camera (SN9C202 + MT9V011/MT9V111/MT9V112)
-sn9c20x 0c45:62b3 PC Camera (SN9C202 + OV9655)
-sn9c20x 0c45:62bb PC Camera (SN9C202 + OV7660)
-sn9c20x 0c45:62bc PC Camera (SN9C202 + HV7131R)
-sn9c2028 0c45:8001 Wild Planet Digital Spy Camera
-sn9c2028 0c45:8003 Sakar #11199, #6637x, #67480 keychain cams
-sn9c2028 0c45:8008 Mini-Shotz ms-350
-sn9c2028 0c45:800a Vivitar Vivicam 3350B
-sunplus 0d64:0303 Sunplus FashionCam DXG
-ov519 0e96:c001 TRUST 380 USB2 SPACEC@M
-etoms 102c:6151 Qcam Sangha CIF
-etoms 102c:6251 Qcam xxxxxx VGA
-ov519 1046:9967 W9967CF/W9968CF WebCam IC, Video Blaster WebCam Go
-zc3xx 10fd:0128 Typhoon Webshot II USB 300k 0x0128
-spca561 10fd:7e50 FlyCam Usb 100
-zc3xx 10fd:8050 Typhoon Webshot II USB 300k
-ov534 1415:2000 Sony HD Eye for PS3 (SLEH 00201)
-pac207 145f:013a Trust WB-1300N
-sn9c20x 145f:013d Trust WB-3600R
-vc032x 15b8:6001 HP 2.0 Megapixel
-vc032x 15b8:6002 HP 2.0 Megapixel rz406aa
-spca501 1776:501c Arowana 300K CMOS Camera
-t613 17a1:0128 TASCORP JPEG Webcam, NGS Cyclops
-vc032x 17ef:4802 Lenovo Vc0323+MI1310_SOC
-pac207 2001:f115 D-Link DSB-C120
-sq905c 2770:9050 Disney pix micro (CIF)
-sq905c 2770:9051 Lego Bionicle
-sq905c 2770:9052 Disney pix micro 2 (VGA)
-sq905c 2770:905c All 11 known cameras with this ID
-sq905 2770:9120 All 24 known cameras with this ID
-sq905c 2770:913d All 4 known cameras with this ID
-sq930x 2770:930b Sweex Motion Tracking / I-Tec iCam Tracer
-sq930x 2770:930c Trust WB-3500T / NSG Robbie 2.0
-spca500 2899:012c Toptro Industrial
-ov519 8020:ef04 ov519
-spca508 8086:0110 Intel Easy PC Camera
-spca500 8086:0630 Intel Pocket PC Camera
-spca506 99fa:8988 Grandtec V.cap
-sn9c20x a168:0610 Dino-Lite Digital Microscope (SN9C201 + HV7131R)
-sn9c20x a168:0611 Dino-Lite Digital Microscope (SN9C201 + HV7131R)
-sn9c20x a168:0613 Dino-Lite Digital Microscope (SN9C201 + HV7131R)
-sn9c20x a168:0618 Dino-Lite Digital Microscope (SN9C201 + HV7131R)
-sn9c20x a168:0614 Dino-Lite Digital Microscope (SN9C201 + MT9M111)
-sn9c20x a168:0615 Dino-Lite Digital Microscope (SN9C201 + MT9M111)
-sn9c20x a168:0617 Dino-Lite Digital Microscope (SN9C201 + MT9M111)
-spca561 abcd:cdee Petcam
+++ /dev/null
-Vaio Picturebook Motion Eye Camera Driver Readme
-------------------------------------------------
- Copyright (C) 2001-2004 Stelian Pop <stelian@popies.net>
- Copyright (C) 2001-2002 Alcôve <www.alcove.com>
- Copyright (C) 2000 Andrew Tridgell <tridge@samba.org>
-
-This driver enable the use of video4linux compatible applications with the
-Motion Eye camera. This driver requires the "Sony Laptop Extras" driver (which
-can be found in the "Misc devices" section of the kernel configuration utility)
-to be compiled and installed (using its "camera=1" parameter).
-
-It can do at maximum 30 fps @ 320x240 or 15 fps @ 640x480.
-
-Grabbing is supported in packed YUV colorspace only.
-
-MJPEG hardware grabbing is supported via a private API (see below).
-
-Hardware supported:
--------------------
-
-This driver supports the 'second' version of the MotionEye camera :)
-
-The first version was connected directly on the video bus of the Neomagic
-video card and is unsupported.
-
-The second one, made by Kawasaki Steel is fully supported by this
-driver (PCI vendor/device is 0x136b/0xff01)
-
-The third one, present in recent (more or less last year) Picturebooks
-(C1M* models), is not supported. The manufacturer has given the specs
-to the developers under a NDA (which allows the development of a GPL
-driver however), but things are not moving very fast (see
-http://r-engine.sourceforge.net/) (PCI vendor/device is 0x10cf/0x2011).
-
-There is a forth model connected on the USB bus in TR1* Vaio laptops.
-This camera is not supported at all by the current driver, in fact
-little information if any is available for this camera
-(USB vendor/device is 0x054c/0x0107).
-
-Driver options:
----------------
-
-Several options can be passed to the meye driver using the standard
-module argument syntax (<param>=<value> when passing the option to the
-module or meye.<param>=<value> on the kernel boot line when meye is
-statically linked into the kernel). Those options are:
-
- gbuffers: number of capture buffers, default is 2 (32 max)
-
- gbufsize: size of each capture buffer, default is 614400
-
- video_nr: video device to register (0 = /dev/video0, etc)
-
-Module use:
------------
-
-In order to automatically load the meye module on use, you can put those lines
-in your /etc/modprobe.d/meye.conf file:
-
- alias char-major-81 videodev
- alias char-major-81-0 meye
- options meye gbuffers=32
-
-Usage:
-------
-
- xawtv >= 3.49 (<http://bytesex.org/xawtv/>)
- for display and uncompressed video capture:
-
- xawtv -c /dev/video0 -geometry 640x480
- or
- xawtv -c /dev/video0 -geometry 320x240
-
- motioneye (<http://popies.net/meye/>)
- for getting ppm or jpg snapshots, mjpeg video
-
-Private API:
-------------
-
- The driver supports frame grabbing with the video4linux API,
- so all video4linux tools (like xawtv) should work with this driver.
-
- Besides the video4linux interface, the driver has a private interface
- for accessing the Motion Eye extended parameters (camera sharpness,
- agc, video framerate), the shapshot and the MJPEG capture facilities.
-
- This interface consists of several ioctls (prototypes and structures
- can be found in include/linux/meye.h):
-
- MEYEIOC_G_PARAMS
- MEYEIOC_S_PARAMS
- Get and set the extended parameters of the motion eye camera.
- The user should always query the current parameters with
- MEYEIOC_G_PARAMS, change what he likes and then issue the
- MEYEIOC_S_PARAMS call (checking for -EINVAL). The extended
- parameters are described by the meye_params structure.
-
-
- MEYEIOC_QBUF_CAPT
- Queue a buffer for capture (the buffers must have been
- obtained with a VIDIOCGMBUF call and mmap'ed by the
- application). The argument to MEYEIOC_QBUF_CAPT is the
- buffer number to queue (or -1 to end capture). The first
- call to MEYEIOC_QBUF_CAPT starts the streaming capture.
-
- MEYEIOC_SYNC
- Takes as an argument the buffer number you want to sync.
- This ioctl blocks until the buffer is filled and ready
- for the application to use. It returns the buffer size.
-
- MEYEIOC_STILLCAPT
- MEYEIOC_STILLJCAPT
- Takes a snapshot in an uncompressed or compressed jpeg format.
- This ioctl blocks until the snapshot is done and returns (for
- jpeg snapshot) the size of the image. The image data is
- available from the first mmap'ed buffer.
-
- Look at the 'motioneye' application code for an actual example.
-
-Bugs / Todo:
-------------
-
- - 'motioneye' still uses the meye private v4l1 API extensions.
+++ /dev/null
-OMAP 3 Image Signal Processor (ISP) driver
-
-Copyright (C) 2010 Nokia Corporation
-Copyright (C) 2009 Texas Instruments, Inc.
-
-Contacts: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
- Sakari Ailus <sakari.ailus@iki.fi>
- David Cohen <dacohen@gmail.com>
-
-
-Introduction
-============
-
-This file documents the Texas Instruments OMAP 3 Image Signal Processor (ISP)
-driver located under drivers/media/platform/omap3isp. The original driver was
-written by Texas Instruments but since that it has been rewritten (twice) at
-Nokia.
-
-The driver has been successfully used on the following versions of OMAP 3:
-
- 3430
- 3530
- 3630
-
-The driver implements V4L2, Media controller and v4l2_subdev interfaces.
-Sensor, lens and flash drivers using the v4l2_subdev interface in the kernel
-are supported.
-
-
-Split to subdevs
-================
-
-The OMAP 3 ISP is split into V4L2 subdevs, each of the blocks inside the ISP
-having one subdev to represent it. Each of the subdevs provide a V4L2 subdev
-interface to userspace.
-
- OMAP3 ISP CCP2
- OMAP3 ISP CSI2a
- OMAP3 ISP CCDC
- OMAP3 ISP preview
- OMAP3 ISP resizer
- OMAP3 ISP AEWB
- OMAP3 ISP AF
- OMAP3 ISP histogram
-
-Each possible link in the ISP is modelled by a link in the Media controller
-interface. For an example program see [2].
-
-
-Controlling the OMAP 3 ISP
-==========================
-
-In general, the settings given to the OMAP 3 ISP take effect at the beginning
-of the following frame. This is done when the module becomes idle during the
-vertical blanking period on the sensor. In memory-to-memory operation the pipe
-is run one frame at a time. Applying the settings is done between the frames.
-
-All the blocks in the ISP, excluding the CSI-2 and possibly the CCP2 receiver,
-insist on receiving complete frames. Sensors must thus never send the ISP
-partial frames.
-
-Autoidle does have issues with some ISP blocks on the 3430, at least.
-Autoidle is only enabled on 3630 when the omap3isp module parameter autoidle
-is non-zero.
-
-
-Events
-======
-
-The OMAP 3 ISP driver does support the V4L2 event interface on CCDC and
-statistics (AEWB, AF and histogram) subdevs.
-
-The CCDC subdev produces V4L2_EVENT_FRAME_SYNC type event on HS_VS
-interrupt which is used to signal frame start. Earlier version of this
-driver used V4L2_EVENT_OMAP3ISP_HS_VS for this purpose. The event is
-triggered exactly when the reception of the first line of the frame starts
-in the CCDC module. The event can be subscribed on the CCDC subdev.
-
-(When using parallel interface one must pay account to correct configuration
-of the VS signal polarity. This is automatically correct when using the serial
-receivers.)
-
-Each of the statistics subdevs is able to produce events. An event is
-generated whenever a statistics buffer can be dequeued by a user space
-application using the VIDIOC_OMAP3ISP_STAT_REQ IOCTL. The events available
-are:
-
- V4L2_EVENT_OMAP3ISP_AEWB
- V4L2_EVENT_OMAP3ISP_AF
- V4L2_EVENT_OMAP3ISP_HIST
-
-The type of the event data is struct omap3isp_stat_event_status for these
-ioctls. If there is an error calculating the statistics, there will be an
-event as usual, but no related statistics buffer. In this case
-omap3isp_stat_event_status.buf_err is set to non-zero.
-
-
-Private IOCTLs
-==============
-
-The OMAP 3 ISP driver supports standard V4L2 IOCTLs and controls where
-possible and practical. Much of the functions provided by the ISP, however,
-does not fall under the standard IOCTLs --- gamma tables and configuration of
-statistics collection are examples of such.
-
-In general, there is a private ioctl for configuring each of the blocks
-containing hardware-dependent functions.
-
-The following private IOCTLs are supported:
-
- VIDIOC_OMAP3ISP_CCDC_CFG
- VIDIOC_OMAP3ISP_PRV_CFG
- VIDIOC_OMAP3ISP_AEWB_CFG
- VIDIOC_OMAP3ISP_HIST_CFG
- VIDIOC_OMAP3ISP_AF_CFG
- VIDIOC_OMAP3ISP_STAT_REQ
- VIDIOC_OMAP3ISP_STAT_EN
-
-The parameter structures used by these ioctls are described in
-include/linux/omap3isp.h. The detailed functions of the ISP itself related to
-a given ISP block is described in the Technical Reference Manuals (TRMs) ---
-see the end of the document for those.
-
-While it is possible to use the ISP driver without any use of these private
-IOCTLs it is not possible to obtain optimal image quality this way. The AEWB,
-AF and histogram modules cannot be used without configuring them using the
-appropriate private IOCTLs.
-
-
-CCDC and preview block IOCTLs
-=============================
-
-The VIDIOC_OMAP3ISP_CCDC_CFG and VIDIOC_OMAP3ISP_PRV_CFG IOCTLs are used to
-configure, enable and disable functions in the CCDC and preview blocks,
-respectively. Both IOCTLs control several functions in the blocks they
-control. VIDIOC_OMAP3ISP_CCDC_CFG IOCTL accepts a pointer to struct
-omap3isp_ccdc_update_config as its argument. Similarly VIDIOC_OMAP3ISP_PRV_CFG
-accepts a pointer to struct omap3isp_prev_update_config. The definition of
-both structures is available in [1].
-
-The update field in the structures tells whether to update the configuration
-for the specific function and the flag tells whether to enable or disable the
-function.
-
-The update and flag bit masks accept the following values. Each separate
-functions in the CCDC and preview blocks is associated with a flag (either
-disable or enable; part of the flag field in the structure) and a pointer to
-configuration data for the function.
-
-Valid values for the update and flag fields are listed here for
-VIDIOC_OMAP3ISP_CCDC_CFG. Values may be or'ed to configure more than one
-function in the same IOCTL call.
-
- OMAP3ISP_CCDC_ALAW
- OMAP3ISP_CCDC_LPF
- OMAP3ISP_CCDC_BLCLAMP
- OMAP3ISP_CCDC_BCOMP
- OMAP3ISP_CCDC_FPC
- OMAP3ISP_CCDC_CULL
- OMAP3ISP_CCDC_CONFIG_LSC
- OMAP3ISP_CCDC_TBL_LSC
-
-The corresponding values for the VIDIOC_OMAP3ISP_PRV_CFG are here:
-
- OMAP3ISP_PREV_LUMAENH
- OMAP3ISP_PREV_INVALAW
- OMAP3ISP_PREV_HRZ_MED
- OMAP3ISP_PREV_CFA
- OMAP3ISP_PREV_CHROMA_SUPP
- OMAP3ISP_PREV_WB
- OMAP3ISP_PREV_BLKADJ
- OMAP3ISP_PREV_RGB2RGB
- OMAP3ISP_PREV_COLOR_CONV
- OMAP3ISP_PREV_YC_LIMIT
- OMAP3ISP_PREV_DEFECT_COR
- OMAP3ISP_PREV_GAMMABYPASS
- OMAP3ISP_PREV_DRK_FRM_CAPTURE
- OMAP3ISP_PREV_DRK_FRM_SUBTRACT
- OMAP3ISP_PREV_LENS_SHADING
- OMAP3ISP_PREV_NF
- OMAP3ISP_PREV_GAMMA
-
-The associated configuration pointer for the function may not be NULL when
-enabling the function. When disabling a function the configuration pointer is
-ignored.
-
-
-Statistic blocks IOCTLs
-=======================
-
-The statistics subdevs do offer more dynamic configuration options than the
-other subdevs. They can be enabled, disable and reconfigured when the pipeline
-is in streaming state.
-
-The statistics blocks always get the input image data from the CCDC (as the
-histogram memory read isn't implemented). The statistics are dequeueable by
-the user from the statistics subdev nodes using private IOCTLs.
-
-The private IOCTLs offered by the AEWB, AF and histogram subdevs are heavily
-reflected by the register level interface offered by the ISP hardware. There
-are aspects that are purely related to the driver implementation and these are
-discussed next.
-
-VIDIOC_OMAP3ISP_STAT_EN
------------------------
-
-This private IOCTL enables/disables a statistic module. If this request is
-done before streaming, it will take effect as soon as the pipeline starts to
-stream. If the pipeline is already streaming, it will take effect as soon as
-the CCDC becomes idle.
-
-VIDIOC_OMAP3ISP_AEWB_CFG, VIDIOC_OMAP3ISP_HIST_CFG and VIDIOC_OMAP3ISP_AF_CFG
------------------------------------------------------------------------------
-
-Those IOCTLs are used to configure the modules. They require user applications
-to have an in-depth knowledge of the hardware. Most of the fields explanation
-can be found on OMAP's TRMs. The two following fields common to all the above
-configure private IOCTLs require explanation for better understanding as they
-are not part of the TRM.
-
-omap3isp_[h3a_af/h3a_aewb/hist]_config.buf_size:
-
-The modules handle their buffers internally. The necessary buffer size for the
-module's data output depends on the requested configuration. Although the
-driver supports reconfiguration while streaming, it does not support a
-reconfiguration which requires bigger buffer size than what is already
-internally allocated if the module is enabled. It will return -EBUSY on this
-case. In order to avoid such condition, either disable/reconfigure/enable the
-module or request the necessary buffer size during the first configuration
-while the module is disabled.
-
-The internal buffer size allocation considers the requested configuration's
-minimum buffer size and the value set on buf_size field. If buf_size field is
-out of [minimum, maximum] buffer size range, it's clamped to fit in there.
-The driver then selects the biggest value. The corrected buf_size value is
-written back to user application.
-
-omap3isp_[h3a_af/h3a_aewb/hist]_config.config_counter:
-
-As the configuration doesn't take effect synchronously to the request, the
-driver must provide a way to track this information to provide more accurate
-data. After a configuration is requested, the config_counter returned to user
-space application will be an unique value associated to that request. When
-user application receives an event for buffer availability or when a new
-buffer is requested, this config_counter is used to match a buffer data and a
-configuration.
-
-VIDIOC_OMAP3ISP_STAT_REQ
-------------------------
-
-Send to user space the oldest data available in the internal buffer queue and
-discards such buffer afterwards. The field omap3isp_stat_data.frame_number
-matches with the video buffer's field_count.
-
-
-Technical reference manuals (TRMs) and other documentation
-==========================================================
-
-OMAP 3430 TRM:
-<URL:http://focus.ti.com/pdfs/wtbu/OMAP34xx_ES3.1.x_PUBLIC_TRM_vZM.zip>
-Referenced 2011-03-05.
-
-OMAP 35xx TRM:
-<URL:http://www.ti.com/litv/pdf/spruf98o> Referenced 2011-03-05.
-
-OMAP 3630 TRM:
-<URL:http://focus.ti.com/pdfs/wtbu/OMAP36xx_ES1.x_PUBLIC_TRM_vQ.zip>
-Referenced 2011-03-05.
-
-DM 3730 TRM:
-<URL:http://www.ti.com/litv/pdf/sprugn4h> Referenced 2011-03-06.
-
-
-References
-==========
-
-[1] include/linux/omap3isp.h
-
-[2] http://git.ideasonboard.org/?p=media-ctl.git;a=summary
+++ /dev/null
- OMAP4 ISS Driver
- ================
-
-Introduction
-------------
-
-The OMAP44XX family of chips contains the Imaging SubSystem (a.k.a. ISS),
-Which contains several components that can be categorized in 3 big groups:
-
-- Interfaces (2 Interfaces: CSI2-A & CSI2-B/CCP2)
-- ISP (Image Signal Processor)
-- SIMCOP (Still Image Coprocessor)
-
-For more information, please look in [1] for latest version of:
- "OMAP4430 Multimedia Device Silicon Revision 2.x"
-
-As of Revision AB, the ISS is described in detail in section 8.
-
-This driver is supporting _only_ the CSI2-A/B interfaces for now.
-
-It makes use of the Media Controller framework [2], and inherited most of the
-code from OMAP3 ISP driver (found under drivers/media/platform/omap3isp/*),
-except that it doesn't need an IOMMU now for ISS buffers memory mapping.
-
-Supports usage of MMAP buffers only (for now).
-
-Tested platforms
-----------------
-
-- OMAP4430SDP, w/ ES2.1 GP & SEVM4430-CAM-V1-0 (Contains IMX060 & OV5640, in
- which only the last one is supported, outputting YUV422 frames).
-
-- TI Blaze MDP, w/ OMAP4430 ES2.2 EMU (Contains 1 IMX060 & 2 OV5650 sensors, in
- which only the OV5650 are supported, outputting RAW10 frames).
-
-- PandaBoard, Rev. A2, w/ OMAP4430 ES2.1 GP & OV adapter board, tested with
- following sensors:
- * OV5640
- * OV5650
-
-- Tested on mainline kernel:
-
- http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=summary
-
- Tag: v3.3 (commit c16fa4f2ad19908a47c63d8fa436a1178438c7e7)
-
-File list
----------
-drivers/staging/media/omap4iss/
-include/linux/platform_data/media/omap4iss.h
-
-References
-----------
-
-[1] http://focus.ti.com/general/docs/wtbu/wtbudocumentcenter.tsp?navigationId=12037&templateId=6123#62
-[2] http://lwn.net/Articles/420485/
-[3] http://www.spinics.net/lists/linux-media/msg44370.html
---
-Author: Sergio Aguirre <sergio.a.aguirre@gmail.com>
-Copyright (C) 2012, Texas Instruments
+++ /dev/null
- PXA-Camera Host Driver
- ======================
-
-Constraints
------------
- a) Image size for YUV422P format
- All YUV422P images are enforced to have width x height % 16 = 0.
- This is due to DMA constraints, which transfers only planes of 8 byte
- multiples.
-
-
-Global video workflow
----------------------
- a) QCI stopped
- Initialy, the QCI interface is stopped.
- When a buffer is queued (pxa_videobuf_ops->buf_queue), the QCI starts.
-
- b) QCI started
- More buffers can be queued while the QCI is started without halting the
- capture. The new buffers are "appended" at the tail of the DMA chain, and
- smoothly captured one frame after the other.
-
- Once a buffer is filled in the QCI interface, it is marked as "DONE" and
- removed from the active buffers list. It can be then requeud or dequeued by
- userland application.
-
- Once the last buffer is filled in, the QCI interface stops.
-
- c) Capture global finite state machine schema
-
- +----+ +---+ +----+
- | DQ | | Q | | DQ |
- | v | v | v
- +-----------+ +------------------------+
- | STOP | | Wait for capture start |
- +-----------+ Q +------------------------+
-+-> | QCI: stop | ------------------> | QCI: run | <------------+
-| | DMA: stop | | DMA: stop | |
-| +-----------+ +-----> +------------------------+ |
-| / | |
-| / +---+ +----+ | |
-|capture list empty / | Q | | DQ | | QCI Irq EOF |
-| / | v | v v |
-| +--------------------+ +----------------------+ |
-| | DMA hotlink missed | | Capture running | |
-| +--------------------+ +----------------------+ |
-| | QCI: run | +-----> | QCI: run | <-+ |
-| | DMA: stop | / | DMA: run | | |
-| +--------------------+ / +----------------------+ | Other |
-| ^ /DMA still | | channels |
-| | capture list / running | DMA Irq End | not |
-| | not empty / | | finished |
-| | / v | yet |
-| +----------------------+ +----------------------+ | |
-| | Videobuf released | | Channel completed | | |
-| +----------------------+ +----------------------+ | |
-+-- | QCI: run | | QCI: run | --+ |
- | DMA: run | | DMA: run | |
- +----------------------+ +----------------------+ |
- ^ / | |
- | no overrun / | overrun |
- | / v |
- +--------------------+ / +----------------------+ |
- | Frame completed | / | Frame overran | |
- +--------------------+ <-----+ +----------------------+ restart frame |
- | QCI: run | | QCI: stop | --------------+
- | DMA: run | | DMA: stop |
- +--------------------+ +----------------------+
-
- Legend: - each box is a FSM state
- - each arrow is the condition to transition to another state
- - an arrow with a comment is a mandatory transition (no condition)
- - arrow "Q" means : a buffer was enqueued
- - arrow "DQ" means : a buffer was dequeued
- - "QCI: stop" means the QCI interface is not enabled
- - "DMA: stop" means all 3 DMA channels are stopped
- - "DMA: run" means at least 1 DMA channel is still running
-
-DMA usage
----------
- a) DMA flow
- - first buffer queued for capture
- Once a first buffer is queued for capture, the QCI is started, but data
- transfer is not started. On "End Of Frame" interrupt, the irq handler
- starts the DMA chain.
- - capture of one videobuffer
- The DMA chain starts transferring data into videobuffer RAM pages.
- When all pages are transferred, the DMA irq is raised on "ENDINTR" status
- - finishing one videobuffer
- The DMA irq handler marks the videobuffer as "done", and removes it from
- the active running queue
- Meanwhile, the next videobuffer (if there is one), is transferred by DMA
- - finishing the last videobuffer
- On the DMA irq of the last videobuffer, the QCI is stopped.
-
- b) DMA prepared buffer will have this structure
-
- +------------+-----+---------------+-----------------+
- | desc-sg[0] | ... | desc-sg[last] | finisher/linker |
- +------------+-----+---------------+-----------------+
-
- This structure is pointed by dma->sg_cpu.
- The descriptors are used as follows :
- - desc-sg[i]: i-th descriptor, transferring the i-th sg
- element to the video buffer scatter gather
- - finisher: has ddadr=DADDR_STOP, dcmd=ENDIRQEN
- - linker: has ddadr= desc-sg[0] of next video buffer, dcmd=0
-
- For the next schema, let's assume d0=desc-sg[0] .. dN=desc-sg[N],
- "f" stands for finisher and "l" for linker.
- A typical running chain is :
-
- Videobuffer 1 Videobuffer 2
- +---------+----+---+ +----+----+----+---+
- | d0 | .. | dN | l | | d0 | .. | dN | f |
- +---------+----+-|-+ ^----+----+----+---+
- | |
- +----+
-
- After the chaining is finished, the chain looks like :
-
- Videobuffer 1 Videobuffer 2 Videobuffer 3
- +---------+----+---+ +----+----+----+---+ +----+----+----+---+
- | d0 | .. | dN | l | | d0 | .. | dN | l | | d0 | .. | dN | f |
- +---------+----+-|-+ ^----+----+----+-|-+ ^----+----+----+---+
- | | | |
- +----+ +----+
- new_link
-
- c) DMA hot chaining timeslice issue
-
- As DMA chaining is done while DMA _is_ running, the linking may be done
- while the DMA jumps from one Videobuffer to another. On the schema, that
- would be a problem if the following sequence is encountered :
-
- - DMA chain is Videobuffer1 + Videobuffer2
- - pxa_videobuf_queue() is called to queue Videobuffer3
- - DMA controller finishes Videobuffer2, and DMA stops
- =>
- Videobuffer 1 Videobuffer 2
- +---------+----+---+ +----+----+----+---+
- | d0 | .. | dN | l | | d0 | .. | dN | f |
- +---------+----+-|-+ ^----+----+----+-^-+
- | | |
- +----+ +-- DMA DDADR loads DDADR_STOP
-
- - pxa_dma_add_tail_buf() is called, the Videobuffer2 "finisher" is
- replaced by a "linker" to Videobuffer3 (creation of new_link)
- - pxa_videobuf_queue() finishes
- - the DMA irq handler is called, which terminates Videobuffer2
- - Videobuffer3 capture is not scheduled on DMA chain (as it stopped !!!)
-
- Videobuffer 1 Videobuffer 2 Videobuffer 3
- +---------+----+---+ +----+----+----+---+ +----+----+----+---+
- | d0 | .. | dN | l | | d0 | .. | dN | l | | d0 | .. | dN | f |
- +---------+----+-|-+ ^----+----+----+-|-+ ^----+----+----+---+
- | | | |
- +----+ +----+
- new_link
- DMA DDADR still is DDADR_STOP
-
- - pxa_camera_check_link_miss() is called
- This checks if the DMA is finished and a buffer is still on the
- pcdev->capture list. If that's the case, the capture will be restarted,
- and Videobuffer3 is scheduled on DMA chain.
- - the DMA irq handler finishes
-
- Note: if DMA stops just after pxa_camera_check_link_miss() reads DDADR()
- value, we have the guarantee that the DMA irq handler will be called back
- when the DMA will finish the buffer, and pxa_camera_check_link_miss() will
- be called again, to reschedule Videobuffer3.
-
---
-Author: Robert Jarzmik <robert.jarzmik@free.fr>
+++ /dev/null
-NOTES ON RADIOTRACK CARD CONTROL
-by Stephen M. Benoit (benoits@servicepro.com) Dec 14, 1996
-----------------------------------------------------------------------------
-
-Document version 1.0
-
-ACKNOWLEDGMENTS
-----------------
-This document was made based on 'C' code for Linux from Gideon le Grange
-(legrang@active.co.za or legrang@cs.sun.ac.za) in 1994, and elaborations from
-Frans Brinkman (brinkman@esd.nl) in 1996. The results reported here are from
-experiments that the author performed on his own setup, so your mileage may
-vary... I make no guarantees, claims or warranties to the suitability or
-validity of this information. No other documentation on the AIMS
-Lab (http://www.aimslab.com/) RadioTrack card was made available to the
-author. This document is offered in the hopes that it might help users who
-want to use the RadioTrack card in an environment other than MS Windows.
-
-WHY THIS DOCUMENT?
-------------------
-I have a RadioTrack card from back when I ran an MS-Windows platform. After
-converting to Linux, I found Gideon le Grange's command-line software for
-running the card, and found that it was good! Frans Brinkman made a
-comfortable X-windows interface, and added a scanning feature. For hack
-value, I wanted to see if the tuner could be tuned beyond the usual FM radio
-broadcast band, so I could pick up the audio carriers from North American
-broadcast TV channels, situated just below and above the 87.0-109.0 MHz range.
-I did not get much success, but I learned about programming ioports under
-Linux and gained some insights about the hardware design used for the card.
-
-So, without further delay, here are the details.
-
-
-PHYSICAL DESCRIPTION
---------------------
-The RadioTrack card is an ISA 8-bit FM radio card. The radio frequency (RF)
-input is simply an antenna lead, and the output is a power audio signal
-available through a miniature phone plug. Its RF frequencies of operation are
-more or less limited from 87.0 to 109.0 MHz (the commercial FM broadcast
-band). Although the registers can be programmed to request frequencies beyond
-these limits, experiments did not give promising results. The variable
-frequency oscillator (VFO) that demodulates the intermediate frequency (IF)
-signal probably has a small range of useful frequencies, and wraps around or
-gets clipped beyond the limits mentioned above.
-
-
-CONTROLLING THE CARD WITH IOPORT
---------------------------------
-The RadioTrack (base) ioport is configurable for 0x30c or 0x20c. Only one
-ioport seems to be involved. The ioport decoding circuitry must be pretty
-simple, as individual ioport bits are directly matched to specific functions
-(or blocks) of the radio card. This way, many functions can be changed in
-parallel with one write to the ioport. The only feedback available through
-the ioports appears to be the "Stereo Detect" bit.
-
-The bits of the ioport are arranged as follows:
-
- MSb LSb
-+------+------+------+--------+--------+-------+---------+--------+
-| VolA | VolB | ???? | Stereo | Radio | TuneA | TuneB | Tune |
-| (+) | (-) | | Detect | Audio | (bit) | (latch) | Update |
-| | | | Enable | Enable | | | Enable |
-+------+------+------+--------+--------+-------+---------+--------+
-
-
-VolA . VolB [AB......]
------------
-0 0 : audio mute
-0 1 : volume + (some delay required)
-1 0 : volume - (some delay required)
-1 1 : stay at present volume
-
-Stereo Detect Enable [...S....]
---------------------
-0 : No Detect
-1 : Detect
-
- Results available by reading ioport >60 msec after last port write.
- 0xff ==> no stereo detected, 0xfd ==> stereo detected.
-
-Radio to Audio (path) Enable [....R...]
-----------------------------
-0 : Disable path (silence)
-1 : Enable path (audio produced)
-
-TuneA . TuneB [.....AB.]
--------------
-0 0 : "zero" bit phase 1
-0 1 : "zero" bit phase 2
-
-1 0 : "one" bit phase 1
-1 1 : "one" bit phase 2
-
- 24-bit code, where bits = (freq*40) + 10486188.
- The Most Significant 11 bits must be 1010 xxxx 0x0 to be valid.
- The bits are shifted in LSb first.
-
-Tune Update Enable [.......T]
-------------------
-0 : Tuner held constant
-1 : Tuner updating in progress
-
-
-PROGRAMMING EXAMPLES
---------------------
-Default: BASE <-- 0xc8 (current volume, no stereo detect,
- radio enable, tuner adjust disable)
-
-Card Off: BASE <-- 0x00 (audio mute, no stereo detect,
- radio disable, tuner adjust disable)
-
-Card On: BASE <-- 0x00 (see "Card Off", clears any unfinished business)
- BASE <-- 0xc8 (see "Default")
-
-Volume Down: BASE <-- 0x48 (volume down, no stereo detect,
- radio enable, tuner adjust disable)
- * wait 10 msec *
- BASE <-- 0xc8 (see "Default")
-
-Volume Up: BASE <-- 0x88 (volume up, no stereo detect,
- radio enable, tuner adjust disable)
- * wait 10 msec *
- BASE <-- 0xc8 (see "Default")
-
-Check Stereo: BASE <-- 0xd8 (current volume, stereo detect,
- radio enable, tuner adjust disable)
- * wait 100 msec *
- x <-- BASE (read ioport)
- BASE <-- 0xc8 (see "Default")
-
- x=0xff ==> "not stereo", x=0xfd ==> "stereo detected"
-
-Set Frequency: code = (freq*40) + 10486188
- foreach of the 24 bits in code,
- (from Least to Most Significant):
- to write a "zero" bit,
- BASE <-- 0x01 (audio mute, no stereo detect, radio
- disable, "zero" bit phase 1, tuner adjust)
- BASE <-- 0x03 (audio mute, no stereo detect, radio
- disable, "zero" bit phase 2, tuner adjust)
- to write a "one" bit,
- BASE <-- 0x05 (audio mute, no stereo detect, radio
- disable, "one" bit phase 1, tuner adjust)
- BASE <-- 0x07 (audio mute, no stereo detect, radio
- disable, "one" bit phase 2, tuner adjust)
-
-----------------------------------------------------------------------------
+++ /dev/null
- Cropping and Scaling algorithm, used in the sh_mobile_ceu_camera driver
- =======================================================================
-
-Terminology
------------
-
-sensor scales: horizontal and vertical scales, configured by the sensor driver
-host scales: -"- host driver
-combined scales: sensor_scale * host_scale
-
-
-Generic scaling / cropping scheme
----------------------------------
-
--1--
-|
--2-- -\
-| --\
-| --\
-+-5-- . -- -3-- -\
-| `... -\
-| `... -4-- . - -7..
-| `.
-| `. .6--
-|
-| . .6'-
-| .´
-| ... -4'- .´
-| ...´ - -7'.
-+-5'- .´ -/
-| -- -3'- -/
-| --/
-| --/
--2'- -/
-|
-|
--1'-
-
-In the above chart minuses and slashes represent "real" data amounts, points and
-accents represent "useful" data, basically, CEU scaled and cropped output,
-mapped back onto the client's source plane.
-
-Such a configuration can be produced by user requests:
-
-S_CROP(left / top = (5) - (1), width / height = (5') - (5))
-S_FMT(width / height = (6') - (6))
-
-Here:
-
-(1) to (1') - whole max width or height
-(1) to (2) - sensor cropped left or top
-(2) to (2') - sensor cropped width or height
-(3) to (3') - sensor scale
-(3) to (4) - CEU cropped left or top
-(4) to (4') - CEU cropped width or height
-(5) to (5') - reverse sensor scale applied to CEU cropped width or height
-(2) to (5) - reverse sensor scale applied to CEU cropped left or top
-(6) to (6') - CEU scale - user window
-
-
-S_FMT
------
-
-Do not touch input rectangle - it is already optimal.
-
-1. Calculate current sensor scales:
-
- scale_s = ((2') - (2)) / ((3') - (3))
-
-2. Calculate "effective" input crop (sensor subwindow) - CEU crop scaled back at
-current sensor scales onto input window - this is user S_CROP:
-
- width_u = (5') - (5) = ((4') - (4)) * scale_s
-
-3. Calculate new combined scales from "effective" input window to requested user
-window:
-
- scale_comb = width_u / ((6') - (6))
-
-4. Calculate sensor output window by applying combined scales to real input
-window:
-
- width_s_out = ((7') - (7)) = ((2') - (2)) / scale_comb
-
-5. Apply iterative sensor S_FMT for sensor output window.
-
- subdev->video_ops->s_fmt(.width = width_s_out)
-
-6. Retrieve sensor output window (g_fmt)
-
-7. Calculate new sensor scales:
-
- scale_s_new = ((3')_new - (3)_new) / ((2') - (2))
-
-8. Calculate new CEU crop - apply sensor scales to previously calculated
-"effective" crop:
-
- width_ceu = (4')_new - (4)_new = width_u / scale_s_new
- left_ceu = (4)_new - (3)_new = ((5) - (2)) / scale_s_new
-
-9. Use CEU cropping to crop to the new window:
-
- ceu_crop(.width = width_ceu, .left = left_ceu)
-
-10. Use CEU scaling to scale to the requested user window:
-
- scale_ceu = width_ceu / width
-
-
-S_CROP
-------
-
-The API at http://v4l2spec.bytesex.org/spec/x1904.htm says:
-
-"...specification does not define an origin or units. However by convention
-drivers should horizontally count unscaled samples relative to 0H."
-
-We choose to follow the advise and interpret cropping units as client input
-pixels.
-
-Cropping is performed in the following 6 steps:
-
-1. Request exactly user rectangle from the sensor.
-
-2. If smaller - iterate until a larger one is obtained. Result: sensor cropped
- to 2 : 2', target crop 5 : 5', current output format 6' - 6.
-
-3. In the previous step the sensor has tried to preserve its output frame as
- good as possible, but it could have changed. Retrieve it again.
-
-4. Sensor scaled to 3 : 3'. Sensor's scale is (2' - 2) / (3' - 3). Calculate
- intermediate window: 4' - 4 = (5' - 5) * (3' - 3) / (2' - 2)
-
-5. Calculate and apply host scale = (6' - 6) / (4' - 4)
-
-6. Calculate and apply host crop: 6 - 7 = (5 - 2) * (6' - 6) / (5' - 5)
-
---
-Author: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
+++ /dev/null
-Driver for USB radios for the Silicon Labs Si470x FM Radio Receivers
-
-Copyright (c) 2009 Tobias Lorenz <tobias.lorenz@gmx.net>
-
-
-Information from Silicon Labs
-=============================
-Silicon Laboratories is the manufacturer of the radio ICs, that nowadays are the
-most often used radio receivers in cell phones. Usually they are connected with
-I2C. But SiLabs also provides a reference design, which integrates this IC,
-together with a small microcontroller C8051F321, to form a USB radio.
-Part of this reference design is also a radio application in binary and source
-code. The software also contains an automatic firmware upgrade to the most
-current version. Information on these can be downloaded here:
-http://www.silabs.com/usbradio
-
-
-Supported ICs
-=============
-The following ICs have a very similar register set, so that they are or will be
-supported somewhen by the driver:
-- Si4700: FM radio receiver
-- Si4701: FM radio receiver, RDS Support
-- Si4702: FM radio receiver
-- Si4703: FM radio receiver, RDS Support
-- Si4704: FM radio receiver, no external antenna required
-- Si4705: FM radio receiver, no external antenna required, RDS support, Dig I/O
-- Si4706: Enhanced FM RDS/TMC radio receiver, no external antenna required, RDS
- Support
-- Si4707: Dedicated weather band radio receiver with SAME decoder, RDS Support
-- Si4708: Smallest FM receivers
-- Si4709: Smallest FM receivers, RDS Support
-More information on these can be downloaded here:
-http://www.silabs.com/products/mcu/Pages/USBFMRadioRD.aspx
-
-
-Supported USB devices
-=====================
-Currently the following USB radios (vendor:product) with the Silicon Labs si470x
-chips are known to work:
-- 10c4:818a: Silicon Labs USB FM Radio Reference Design
-- 06e1:a155: ADS/Tech FM Radio Receiver (formerly Instant FM Music) (RDX-155-EF)
-- 1b80:d700: KWorld USB FM Radio SnapMusic Mobile 700 (FM700)
-- 10c5:819a: Sanei Electric, Inc. FM USB Radio (sold as DealExtreme.com PCear)
-
-
-Software
-========
-Testing is usually done with most application under Debian/testing:
-- fmtools - Utility for managing FM tuner cards
-- gnomeradio - FM-radio tuner for the GNOME desktop
-- gradio - GTK FM radio tuner
-- kradio - Comfortable Radio Application for KDE
-- radio - ncurses-based radio application
-- mplayer - The Ultimate Movie Player For Linux
-- v4l2-ctl - Collection of command line video4linux utilities
-For example, you can use:
-v4l2-ctl -d /dev/radio0 --set-ctrl=volume=10,mute=0 --set-freq=95.21 --all
-
-There is also a library libv4l, which can be used. It's going to have a function
-for frequency seeking, either by using hardware functionality as in radio-si470x
-or by implementing a function as we currently have in every of the mentioned
-programs. Somewhen the radio programs should make use of libv4l.
-
-For processing RDS information, there is a project ongoing at:
-http://rdsd.berlios.de/
-
-There is currently no project for making TMC sentences human readable.
-
-
-Audio Listing
-=============
-USB Audio is provided by the ALSA snd_usb_audio module. It is recommended to
-also select SND_USB_AUDIO, as this is required to get sound from the radio. For
-listing you have to redirect the sound, for example using one of the following
-commands. Please adjust the audio devices to your needs (/dev/dsp* and hw:x,x).
-
-If you just want to test audio (very poor quality):
-cat /dev/dsp1 > /dev/dsp
-
-If you use sox + OSS try:
-sox -2 --endian little -r 96000 -t oss /dev/dsp1 -t oss /dev/dsp
-or using sox + alsa:
-sox --endian little -c 2 -S -r 96000 -t alsa hw:1 -t alsa -r 96000 hw:0
-
-If you use arts try:
-arecord -D hw:1,0 -r96000 -c2 -f S16_LE | artsdsp aplay -B -
-
-If you use mplayer try:
-mplayer -radio adevice=hw=1.0:arate=96000 \
- -rawaudio rate=96000 \
- radio://<frequency>/capture
-
-Module Parameters
-=================
-After loading the module, you still have access to some of them in the sysfs
-mount under /sys/module/radio_si470x/parameters. The contents of read-only files
-(0444) are not updated, even if space, band and de are changed using private
-video controls. The others are runtime changeable.
-
-
-Errors
-======
-Increase tune_timeout, if you often get -EIO errors.
-
-When timed out or band limit is reached, hw_freq_seek returns -EAGAIN.
-
-If you get any errors from snd_usb_audio, please report them to the ALSA people.
-
-
-Open Issues
-===========
-V4L minor device allocation and parameter setting is not perfect. A solution is
-currently under discussion.
-
-There is an USB interface for downloading/uploading new firmware images. Support
-for it can be implemented using the request_firmware interface.
-
-There is a RDS interrupt mode. The driver is already using the same interface
-for polling RDS information, but is currently not using the interrupt mode.
-
-There is a LED interface, which can be used to override the LED control
-programmed in the firmware. This can be made available using the LED support
-functions in the kernel.
-
-
-Other useful information and links
-==================================
-http://www.silabs.com/usbradio
+++ /dev/null
-Driver for I2C radios for the Silicon Labs Si4713 FM Radio Transmitters
-
-Copyright (c) 2009 Nokia Corporation
-Contact: Eduardo Valentin <eduardo.valentin@nokia.com>
-
-
-Information about the Device
-============================
-This chip is a Silicon Labs product. It is a I2C device, currently on 0x63 address.
-Basically, it has transmission and signal noise level measurement features.
-
-The Si4713 integrates transmit functions for FM broadcast stereo transmission.
-The chip also allows integrated receive power scanning to identify low signal
-power FM channels.
-
-The chip is programmed using commands and responses. There are also several
-properties which can change the behavior of this chip.
-
-Users must comply with local regulations on radio frequency (RF) transmission.
-
-Device driver description
-=========================
-There are two modules to handle this device. One is a I2C device driver
-and the other is a platform driver.
-
-The I2C device driver exports a v4l2-subdev interface to the kernel.
-All properties can also be accessed by v4l2 extended controls interface, by
-using the v4l2-subdev calls (g_ext_ctrls, s_ext_ctrls).
-
-The platform device driver exports a v4l2 radio device interface to user land.
-So, it uses the I2C device driver as a sub device in order to send the user
-commands to the actual device. Basically it is a wrapper to the I2C device driver.
-
-Applications can use v4l2 radio API to specify frequency of operation, mute state,
-etc. But mostly of its properties will be present in the extended controls.
-
-When the v4l2 mute property is set to 1 (true), the driver will turn the chip off.
-
-Properties description
-======================
-
-The properties can be accessed using v4l2 extended controls.
-Here is an output from v4l2-ctl util:
-/ # v4l2-ctl -d /dev/radio0 --all -L
-Driver Info:
- Driver name : radio-si4713
- Card type : Silicon Labs Si4713 Modulator
- Bus info :
- Driver version: 0
- Capabilities : 0x00080800
- RDS Output
- Modulator
-Audio output: 0 (FM Modulator Audio Out)
-Frequency: 1408000 (88.000000 MHz)
-Video Standard = 0x00000000
-Modulator:
- Name : FM Modulator
- Capabilities : 62.5 Hz stereo rds
- Frequency range : 76.0 MHz - 108.0 MHz
- Subchannel modulation: stereo+rds
-
-User Controls
-
- mute (bool) : default=1 value=0
-
-FM Radio Modulator Controls
-
- rds_signal_deviation (int) : min=0 max=90000 step=10 default=200 value=200 flags=slider
- rds_program_id (int) : min=0 max=65535 step=1 default=0 value=0
- rds_program_type (int) : min=0 max=31 step=1 default=0 value=0
- rds_ps_name (str) : min=0 max=96 step=8 value='si4713 '
- rds_radio_text (str) : min=0 max=384 step=32 value=''
- audio_limiter_feature_enabled (bool) : default=1 value=1
- audio_limiter_release_time (int) : min=250 max=102390 step=50 default=5010 value=5010 flags=slider
- audio_limiter_deviation (int) : min=0 max=90000 step=10 default=66250 value=66250 flags=slider
-audio_compression_feature_enabl (bool) : default=1 value=1
- audio_compression_gain (int) : min=0 max=20 step=1 default=15 value=15 flags=slider
- audio_compression_threshold (int) : min=-40 max=0 step=1 default=-40 value=-40 flags=slider
- audio_compression_attack_time (int) : min=0 max=5000 step=500 default=0 value=0 flags=slider
- audio_compression_release_time (int) : min=100000 max=1000000 step=100000 default=1000000 value=1000000 flags=slider
- pilot_tone_feature_enabled (bool) : default=1 value=1
- pilot_tone_deviation (int) : min=0 max=90000 step=10 default=6750 value=6750 flags=slider
- pilot_tone_frequency (int) : min=0 max=19000 step=1 default=19000 value=19000 flags=slider
- pre_emphasis_settings (menu) : min=0 max=2 default=1 value=1
- tune_power_level (int) : min=0 max=120 step=1 default=88 value=88 flags=slider
- tune_antenna_capacitor (int) : min=0 max=191 step=1 default=0 value=110 flags=slider
-/ #
-
-Here is a summary of them:
-
-* Pilot is an audible tone sent by the device.
-
-pilot_frequency - Configures the frequency of the stereo pilot tone.
-pilot_deviation - Configures pilot tone frequency deviation level.
-pilot_enabled - Enables or disables the pilot tone feature.
-
-* The si4713 device is capable of applying audio compression to the transmitted signal.
-
-acomp_enabled - Enables or disables the audio dynamic range control feature.
-acomp_gain - Sets the gain for audio dynamic range control.
-acomp_threshold - Sets the threshold level for audio dynamic range control.
-acomp_attack_time - Sets the attack time for audio dynamic range control.
-acomp_release_time - Sets the release time for audio dynamic range control.
-
-* Limiter setups audio deviation limiter feature. Once a over deviation occurs,
-it is possible to adjust the front-end gain of the audio input and always
-prevent over deviation.
-
-limiter_enabled - Enables or disables the limiter feature.
-limiter_deviation - Configures audio frequency deviation level.
-limiter_release_time - Sets the limiter release time.
-
-* Tuning power
-
-power_level - Sets the output power level for signal transmission.
-antenna_capacitor - This selects the value of antenna tuning capacitor manually
-or automatically if set to zero.
-
-* RDS related
-
-rds_ps_name - Sets the RDS ps name field for transmission.
-rds_radio_text - Sets the RDS radio text for transmission.
-rds_pi - Sets the RDS PI field for transmission.
-rds_pty - Sets the RDS PTY field for transmission.
-
-* Region related
-
-preemphasis - sets the preemphasis to be applied for transmission.
-
-RNL
-===
-
-This device also has an interface to measure received noise level. To do that, you should
-ioctl the device node. Here is an code of example:
-
-int main (int argc, char *argv[])
-{
- struct si4713_rnl rnl;
- int fd = open("/dev/radio0", O_RDWR);
- int rval;
-
- if (argc < 2)
- return -EINVAL;
-
- if (fd < 0)
- return fd;
-
- sscanf(argv[1], "%d", &rnl.frequency);
-
- rval = ioctl(fd, SI4713_IOC_MEASURE_RNL, &rnl);
- if (rval < 0)
- return rval;
-
- printf("received noise level: %d\n", rnl.rnl);
-
- close(fd);
-}
-
-The struct si4713_rnl and SI4713_IOC_MEASURE_RNL are defined under
-include/linux/platform_data/media/si4713.h.
-
-Stereo/Mono and RDS subchannels
-===============================
-
-The device can also be configured using the available sub channels for
-transmission. To do that use S/G_MODULATOR ioctl and configure txsubchans properly.
-Refer to the V4L2 API specification for proper use of this ioctl.
-
-Testing
-=======
-Testing is usually done with v4l2-ctl utility for managing FM tuner cards.
-The tool can be found in v4l-dvb repository under v4l2-apps/util directory.
-
-Example for setting rds ps name:
-# v4l2-ctl -d /dev/radio0 --set-ctrl=rds_ps_name="Dummy"
-
+++ /dev/null
-SI476x Driver Readme
-------------------------------------------------
- Copyright (C) 2013 Andrey Smirnov <andrew.smirnov@gmail.com>
-
-TODO for the driver
-------------------------------
-
-- According to the SiLabs' datasheet it is possible to update the
- firmware of the radio chip in the run-time, thus bringing it to the
- most recent version. Unfortunately I couldn't find any mentioning of
- the said firmware update for the old chips that I tested the driver
- against, so for chips like that the driver only exposes the old
- functionality.
-
-
-Parameters exposed over debugfs
--------------------------------
-SI476x allow user to get multiple characteristics that can be very
-useful for EoL testing/RF performance estimation, parameters that have
-very little to do with V4L2 subsystem. Such parameters are exposed via
-debugfs and can be accessed via regular file I/O operations.
-
-The drivers exposes following files:
-
-* /sys/kernel/debug/<device-name>/acf
- This file contains ACF(Automatically Controlled Features) status
- information. The contents of the file is binary data of the
- following layout:
-
- Offset | Name | Description
- ====================================================================
- 0x00 | blend_int | Flag, set when stereo separation has
- | | crossed below the blend threshold
- --------------------------------------------------------------------
- 0x01 | hblend_int | Flag, set when HiBlend cutoff
- | | frequency is lower than threshold
- --------------------------------------------------------------------
- 0x02 | hicut_int | Flag, set when HiCut cutoff
- | | frequency is lower than threshold
- --------------------------------------------------------------------
- 0x03 | chbw_int | Flag, set when channel filter
- | | bandwidth is less than threshold
- --------------------------------------------------------------------
- 0x04 | softmute_int | Flag indicating that softmute
- | | attenuation has increased above
- | | softmute threshold
- --------------------------------------------------------------------
- 0x05 | smute | 0 - Audio is not soft muted
- | | 1 - Audio is soft muted
- --------------------------------------------------------------------
- 0x06 | smattn | Soft mute attenuation level in dB
- --------------------------------------------------------------------
- 0x07 | chbw | Channel filter bandwidth in kHz
- --------------------------------------------------------------------
- 0x08 | hicut | HiCut cutoff frequency in units of
- | | 100Hz
- --------------------------------------------------------------------
- 0x09 | hiblend | HiBlend cutoff frequency in units
- | | of 100 Hz
- --------------------------------------------------------------------
- 0x10 | pilot | 0 - Stereo pilot is not present
- | | 1 - Stereo pilot is present
- --------------------------------------------------------------------
- 0x11 | stblend | Stereo blend in %
- --------------------------------------------------------------------
-
-
-* /sys/kernel/debug/<device-name>/rds_blckcnt
- This file contains statistics about RDS receptions. It's binary data
- has the following layout:
-
- Offset | Name | Description
- ====================================================================
- 0x00 | expected | Number of expected RDS blocks
- --------------------------------------------------------------------
- 0x02 | received | Number of received RDS blocks
- --------------------------------------------------------------------
- 0x04 | uncorrectable | Number of uncorrectable RDS blocks
- --------------------------------------------------------------------
-
-* /sys/kernel/debug/<device-name>/agc
- This file contains information about parameters pertaining to
- AGC(Automatic Gain Control)
-
- The layout is:
- Offset | Name | Description
- ====================================================================
- 0x00 | mxhi | 0 - FM Mixer PD high threshold is
- | | not tripped
- | | 1 - FM Mixer PD high threshold is
- | | tripped
- --------------------------------------------------------------------
- 0x01 | mxlo | ditto for FM Mixer PD low
- --------------------------------------------------------------------
- 0x02 | lnahi | ditto for FM LNA PD high
- --------------------------------------------------------------------
- 0x03 | lnalo | ditto for FM LNA PD low
- --------------------------------------------------------------------
- 0x04 | fmagc1 | FMAGC1 attenuator resistance
- | | (see datasheet for more detail)
- --------------------------------------------------------------------
- 0x05 | fmagc2 | ditto for FMAGC2
- --------------------------------------------------------------------
- 0x06 | pgagain | PGA gain in dB
- --------------------------------------------------------------------
- 0x07 | fmwblang | FM/WB LNA Gain in dB
- --------------------------------------------------------------------
-
-* /sys/kernel/debug/<device-name>/rsq
- This file contains information about parameters pertaining to
- RSQ(Received Signal Quality)
-
- The layout is:
- Offset | Name | Description
- ====================================================================
- 0x00 | multhint | 0 - multipath value has not crossed
- | | the Multipath high threshold
- | | 1 - multipath value has crossed
- | | the Multipath high threshold
- --------------------------------------------------------------------
- 0x01 | multlint | ditto for Multipath low threshold
- --------------------------------------------------------------------
- 0x02 | snrhint | 0 - received signal's SNR has not
- | | crossed high threshold
- | | 1 - received signal's SNR has
- | | crossed high threshold
- --------------------------------------------------------------------
- 0x03 | snrlint | ditto for low threshold
- --------------------------------------------------------------------
- 0x04 | rssihint | ditto for RSSI high threshold
- --------------------------------------------------------------------
- 0x05 | rssilint | ditto for RSSI low threshold
- --------------------------------------------------------------------
- 0x06 | bltf | Flag indicating if seek command
- | | reached/wrapped seek band limit
- --------------------------------------------------------------------
- 0x07 | snr_ready | Indicates that SNR metrics is ready
- --------------------------------------------------------------------
- 0x08 | rssiready | ditto for RSSI metrics
- --------------------------------------------------------------------
- 0x09 | injside | 0 - Low-side injection is being used
- | | 1 - High-side injection is used
- --------------------------------------------------------------------
- 0x10 | afcrl | Flag indicating if AFC rails
- --------------------------------------------------------------------
- 0x11 | valid | Flag indicating if channel is valid
- --------------------------------------------------------------------
- 0x12 | readfreq | Current tuned frequency
- --------------------------------------------------------------------
- 0x14 | freqoff | Signed frequency offset in units of
- | | 2ppm
- --------------------------------------------------------------------
- 0x15 | rssi | Signed value of RSSI in dBuV
- --------------------------------------------------------------------
- 0x16 | snr | Signed RF SNR in dB
- --------------------------------------------------------------------
- 0x17 | issi | Signed Image Strength Signal
- | | indicator
- --------------------------------------------------------------------
- 0x18 | lassi | Signed Low side adjacent Channel
- | | Strength indicator
- --------------------------------------------------------------------
- 0x19 | hassi | ditto fpr High side
- --------------------------------------------------------------------
- 0x20 | mult | Multipath indicator
- --------------------------------------------------------------------
- 0x21 | dev | Frequency deviation
- --------------------------------------------------------------------
- 0x24 | assi | Adjacent channel SSI
- --------------------------------------------------------------------
- 0x25 | usn | Ultrasonic noise indicator
- --------------------------------------------------------------------
- 0x26 | pilotdev | Pilot deviation in units of 100 Hz
- --------------------------------------------------------------------
- 0x27 | rdsdev | ditto for RDS
- --------------------------------------------------------------------
- 0x28 | assidev | ditto for ASSI
- --------------------------------------------------------------------
- 0x29 | strongdev | Frequency deviation
- --------------------------------------------------------------------
- 0x30 | rdspi | RDS PI code
- --------------------------------------------------------------------
-
-* /sys/kernel/debug/<device-name>/rsq_primary
- This file contains information about parameters pertaining to
- RSQ(Received Signal Quality) for primary tuner only. Layout is as
- the one above.
+++ /dev/null
- Soc-Camera Subsystem
- ====================
-
-Terminology
------------
-
-The following terms are used in this document:
- - camera / camera device / camera sensor - a video-camera sensor chip, capable
- of connecting to a variety of systems and interfaces, typically uses i2c for
- control and configuration, and a parallel or a serial bus for data.
- - camera host - an interface, to which a camera is connected. Typically a
- specialised interface, present on many SoCs, e.g. PXA27x and PXA3xx, SuperH,
- AVR32, i.MX27, i.MX31.
- - camera host bus - a connection between a camera host and a camera. Can be
- parallel or serial, consists of data and control lines, e.g. clock, vertical
- and horizontal synchronization signals.
-
-Purpose of the soc-camera subsystem
------------------------------------
-
-The soc-camera subsystem initially provided a unified API between camera host
-drivers and camera sensor drivers. Later the soc-camera sensor API has been
-replaced with the V4L2 standard subdev API. This also made camera driver re-use
-with non-soc-camera hosts possible. The camera host API to the soc-camera core
-has been preserved.
-
-Soc-camera implements a V4L2 interface to the user, currently only the "mmap"
-method is supported by host drivers. However, the soc-camera core also provides
-support for the "read" method.
-
-The subsystem has been designed to support multiple camera host interfaces and
-multiple cameras per interface, although most applications have only one camera
-sensor.
-
-Existing drivers
-----------------
-
-As of 3.7 there are seven host drivers in the mainline: atmel-isi.c,
-mx1_camera.c (broken, scheduled for removal), mx2_camera.c, mx3_camera.c,
-omap1_camera.c, pxa_camera.c, sh_mobile_ceu_camera.c, and multiple sensor
-drivers under drivers/media/i2c/soc_camera/.
-
-Camera host API
----------------
-
-A host camera driver is registered using the
-
-soc_camera_host_register(struct soc_camera_host *);
-
-function. The host object can be initialized as follows:
-
- struct soc_camera_host *ici;
- ici->drv_name = DRV_NAME;
- ici->ops = &camera_host_ops;
- ici->priv = pcdev;
- ici->v4l2_dev.dev = &pdev->dev;
- ici->nr = pdev->id;
-
-All camera host methods are passed in a struct soc_camera_host_ops:
-
-static struct soc_camera_host_ops camera_host_ops = {
- .owner = THIS_MODULE,
- .add = camera_add_device,
- .remove = camera_remove_device,
- .set_fmt = camera_set_fmt_cap,
- .try_fmt = camera_try_fmt_cap,
- .init_videobuf2 = camera_init_videobuf2,
- .poll = camera_poll,
- .querycap = camera_querycap,
- .set_bus_param = camera_set_bus_param,
- /* The rest of host operations are optional */
-};
-
-.add and .remove methods are called when a sensor is attached to or detached
-from the host. .set_bus_param is used to configure physical connection
-parameters between the host and the sensor. .init_videobuf2 is called by
-soc-camera core when a video-device is opened, the host driver would typically
-call vb2_queue_init() in this method. Further video-buffer management is
-implemented completely by the specific camera host driver. If the host driver
-supports non-standard pixel format conversion, it should implement a
-.get_formats and, possibly, a .put_formats operations. See below for more
-details about format conversion. The rest of the methods are called from
-respective V4L2 operations.
-
-Camera API
-----------
-
-Sensor drivers can use struct soc_camera_link, typically provided by the
-platform, and used to specify to which camera host bus the sensor is connected,
-and optionally provide platform .power and .reset methods for the camera. This
-struct is provided to the camera driver via the I2C client device platform data
-and can be obtained, using the soc_camera_i2c_to_link() macro. Care should be
-taken, when using soc_camera_vdev_to_subdev() and when accessing struct
-soc_camera_device, using v4l2_get_subdev_hostdata(): both only work, when
-running on an soc-camera host. The actual camera driver operation is implemented
-using the V4L2 subdev API. Additionally soc-camera camera drivers can use
-auxiliary soc-camera helper functions like soc_camera_power_on() and
-soc_camera_power_off(), which switch regulators, provided by the platform and call
-board-specific power switching methods. soc_camera_apply_board_flags() takes
-camera bus configuration capability flags and applies any board transformations,
-e.g. signal polarity inversion. soc_mbus_get_fmtdesc() can be used to obtain a
-pixel format descriptor, corresponding to a certain media-bus pixel format code.
-soc_camera_limit_side() can be used to restrict beginning and length of a frame
-side, based on camera capabilities.
-
-VIDIOC_S_CROP and VIDIOC_S_FMT behaviour
-----------------------------------------
-
-Above user ioctls modify image geometry as follows:
-
-VIDIOC_S_CROP: sets location and sizes of the sensor window. Unit is one sensor
-pixel. Changing sensor window sizes preserves any scaling factors, therefore
-user window sizes change as well.
-
-VIDIOC_S_FMT: sets user window. Should preserve previously set sensor window as
-much as possible by modifying scaling factors. If the sensor window cannot be
-preserved precisely, it may be changed too.
-
-In soc-camera there are two locations, where scaling and cropping can take
-place: in the camera driver and in the host driver. User ioctls are first passed
-to the host driver, which then generally passes them down to the camera driver.
-It is more efficient to perform scaling and cropping in the camera driver to
-save camera bus bandwidth and maximise the framerate. However, if the camera
-driver failed to set the required parameters with sufficient precision, the host
-driver may decide to also use its own scaling and cropping to fulfill the user's
-request.
-
-Camera drivers are interfaced to the soc-camera core and to host drivers over
-the v4l2-subdev API, which is completely functional, it doesn't pass any data.
-Therefore all camera drivers shall reply to .g_fmt() requests with their current
-output geometry. This is necessary to correctly configure the camera bus.
-.s_fmt() and .try_fmt() have to be implemented too. Sensor window and scaling
-factors have to be maintained by camera drivers internally. According to the
-V4L2 API all capture drivers must support the VIDIOC_CROPCAP ioctl, hence we
-rely on camera drivers implementing .cropcap(). If the camera driver does not
-support cropping, it may choose to not implement .s_crop(), but to enable
-cropping support by the camera host driver at least the .g_crop method must be
-implemented.
-
-User window geometry is kept in .user_width and .user_height fields in struct
-soc_camera_device and used by the soc-camera core and host drivers. The core
-updates these fields upon successful completion of a .s_fmt() call, but if these
-fields change elsewhere, e.g. during .s_crop() processing, the host driver is
-responsible for updating them.
-
-Format conversion
------------------
-
-V4L2 distinguishes between pixel formats, as they are stored in memory, and as
-they are transferred over a media bus. Soc-camera provides support to
-conveniently manage these formats. A table of standard transformations is
-maintained by soc-camera core, which describes, what FOURCC pixel format will
-be obtained, if a media-bus pixel format is stored in memory according to
-certain rules. E.g. if MEDIA_BUS_FMT_YUYV8_2X8 data is sampled with 8 bits per
-sample and stored in memory in the little-endian order with no gaps between
-bytes, data in memory will represent the V4L2_PIX_FMT_YUYV FOURCC format. These
-standard transformations will be used by soc-camera or by camera host drivers to
-configure camera drivers to produce the FOURCC format, requested by the user,
-using the VIDIOC_S_FMT ioctl(). Apart from those standard format conversions,
-host drivers can also provide their own conversion rules by implementing a
-.get_formats and, if required, a .put_formats methods.
-
---
-Author: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
+++ /dev/null
-Linux USB Video Class (UVC) driver
-==================================
-
-This file documents some driver-specific aspects of the UVC driver, such as
-driver-specific ioctls and implementation notes.
-
-Questions and remarks can be sent to the Linux UVC development mailing list at
-linux-uvc-devel@lists.berlios.de.
-
-
-Extension Unit (XU) support
----------------------------
-
-1. Introduction
-
-The UVC specification allows for vendor-specific extensions through extension
-units (XUs). The Linux UVC driver supports extension unit controls (XU controls)
-through two separate mechanisms:
-
- - through mappings of XU controls to V4L2 controls
- - through a driver-specific ioctl interface
-
-The first one allows generic V4L2 applications to use XU controls by mapping
-certain XU controls onto V4L2 controls, which then show up during ordinary
-control enumeration.
-
-The second mechanism requires uvcvideo-specific knowledge for the application to
-access XU controls but exposes the entire UVC XU concept to user space for
-maximum flexibility.
-
-Both mechanisms complement each other and are described in more detail below.
-
-
-2. Control mappings
-
-The UVC driver provides an API for user space applications to define so-called
-control mappings at runtime. These allow for individual XU controls or byte
-ranges thereof to be mapped to new V4L2 controls. Such controls appear and
-function exactly like normal V4L2 controls (i.e. the stock controls, such as
-brightness, contrast, etc.). However, reading or writing of such a V4L2 controls
-triggers a read or write of the associated XU control.
-
-The ioctl used to create these control mappings is called UVCIOC_CTRL_MAP.
-Previous driver versions (before 0.2.0) required another ioctl to be used
-beforehand (UVCIOC_CTRL_ADD) to pass XU control information to the UVC driver.
-This is no longer necessary as newer uvcvideo versions query the information
-directly from the device.
-
-For details on the UVCIOC_CTRL_MAP ioctl please refer to the section titled
-"IOCTL reference" below.
-
-
-3. Driver specific XU control interface
-
-For applications that need to access XU controls directly, e.g. for testing
-purposes, firmware upload, or accessing binary controls, a second mechanism to
-access XU controls is provided in the form of a driver-specific ioctl, namely
-UVCIOC_CTRL_QUERY.
-
-A call to this ioctl allows applications to send queries to the UVC driver that
-directly map to the low-level UVC control requests.
-
-In order to make such a request the UVC unit ID of the control's extension unit
-and the control selector need to be known. This information either needs to be
-hardcoded in the application or queried using other ways such as by parsing the
-UVC descriptor or, if available, using the media controller API to enumerate a
-device's entities.
-
-Unless the control size is already known it is necessary to first make a
-UVC_GET_LEN requests in order to be able to allocate a sufficiently large buffer
-and set the buffer size to the correct value. Similarly, to find out whether
-UVC_GET_CUR or UVC_SET_CUR are valid requests for a given control, a
-UVC_GET_INFO request should be made. The bits 0 (GET supported) and 1 (SET
-supported) of the resulting byte indicate which requests are valid.
-
-With the addition of the UVCIOC_CTRL_QUERY ioctl the UVCIOC_CTRL_GET and
-UVCIOC_CTRL_SET ioctls have become obsolete since their functionality is a
-subset of the former ioctl. For the time being they are still supported but
-application developers are encouraged to use UVCIOC_CTRL_QUERY instead.
-
-For details on the UVCIOC_CTRL_QUERY ioctl please refer to the section titled
-"IOCTL reference" below.
-
-
-4. Security
-
-The API doesn't currently provide a fine-grained access control facility. The
-UVCIOC_CTRL_ADD and UVCIOC_CTRL_MAP ioctls require super user permissions.
-
-Suggestions on how to improve this are welcome.
-
-
-5. Debugging
-
-In order to debug problems related to XU controls or controls in general it is
-recommended to enable the UVC_TRACE_CONTROL bit in the module parameter 'trace'.
-This causes extra output to be written into the system log.
-
-
-6. IOCTL reference
-
----- UVCIOC_CTRL_MAP - Map a UVC control to a V4L2 control ----
-
-Argument: struct uvc_xu_control_mapping
-
-Description:
- This ioctl creates a mapping between a UVC control or part of a UVC
- control and a V4L2 control. Once mappings are defined, userspace
- applications can access vendor-defined UVC control through the V4L2
- control API.
-
- To create a mapping, applications fill the uvc_xu_control_mapping
- structure with information about an existing UVC control defined with
- UVCIOC_CTRL_ADD and a new V4L2 control.
-
- A UVC control can be mapped to several V4L2 controls. For instance,
- a UVC pan/tilt control could be mapped to separate pan and tilt V4L2
- controls. The UVC control is divided into non overlapping fields using
- the 'size' and 'offset' fields and are then independently mapped to
- V4L2 control.
-
- For signed integer V4L2 controls the data_type field should be set to
- UVC_CTRL_DATA_TYPE_SIGNED. Other values are currently ignored.
-
-Return value:
- On success 0 is returned. On error -1 is returned and errno is set
- appropriately.
-
- ENOMEM
- Not enough memory to perform the operation.
- EPERM
- Insufficient privileges (super user privileges are required).
- EINVAL
- No such UVC control.
- EOVERFLOW
- The requested offset and size would overflow the UVC control.
- EEXIST
- Mapping already exists.
-
-Data types:
- * struct uvc_xu_control_mapping
-
- __u32 id V4L2 control identifier
- __u8 name[32] V4L2 control name
- __u8 entity[16] UVC extension unit GUID
- __u8 selector UVC control selector
- __u8 size V4L2 control size (in bits)
- __u8 offset V4L2 control offset (in bits)
- enum v4l2_ctrl_type
- v4l2_type V4L2 control type
- enum uvc_control_data_type
- data_type UVC control data type
- struct uvc_menu_info
- *menu_info Array of menu entries (for menu controls only)
- __u32 menu_count Number of menu entries (for menu controls only)
-
- * struct uvc_menu_info
-
- __u32 value Menu entry value used by the device
- __u8 name[32] Menu entry name
-
-
- * enum uvc_control_data_type
-
- UVC_CTRL_DATA_TYPE_RAW Raw control (byte array)
- UVC_CTRL_DATA_TYPE_SIGNED Signed integer
- UVC_CTRL_DATA_TYPE_UNSIGNED Unsigned integer
- UVC_CTRL_DATA_TYPE_BOOLEAN Boolean
- UVC_CTRL_DATA_TYPE_ENUM Enumeration
- UVC_CTRL_DATA_TYPE_BITMASK Bitmask
-
-
----- UVCIOC_CTRL_QUERY - Query a UVC XU control ----
-
-Argument: struct uvc_xu_control_query
-
-Description:
- This ioctl queries a UVC XU control identified by its extension unit ID
- and control selector.
-
- There are a number of different queries available that closely
- correspond to the low-level control requests described in the UVC
- specification. These requests are:
-
- UVC_GET_CUR
- Obtain the current value of the control.
- UVC_GET_MIN
- Obtain the minimum value of the control.
- UVC_GET_MAX
- Obtain the maximum value of the control.
- UVC_GET_DEF
- Obtain the default value of the control.
- UVC_GET_RES
- Query the resolution of the control, i.e. the step size of the
- allowed control values.
- UVC_GET_LEN
- Query the size of the control in bytes.
- UVC_GET_INFO
- Query the control information bitmap, which indicates whether
- get/set requests are supported.
- UVC_SET_CUR
- Update the value of the control.
-
- Applications must set the 'size' field to the correct length for the
- control. Exceptions are the UVC_GET_LEN and UVC_GET_INFO queries, for
- which the size must be set to 2 and 1, respectively. The 'data' field
- must point to a valid writable buffer big enough to hold the indicated
- number of data bytes.
-
- Data is copied directly from the device without any driver-side
- processing. Applications are responsible for data buffer formatting,
- including little-endian/big-endian conversion. This is particularly
- important for the result of the UVC_GET_LEN requests, which is always
- returned as a little-endian 16-bit integer by the device.
-
-Return value:
- On success 0 is returned. On error -1 is returned and errno is set
- appropriately.
-
- ENOENT
- The device does not support the given control or the specified
- extension unit could not be found.
- ENOBUFS
- The specified buffer size is incorrect (too big or too small).
- EINVAL
- An invalid request code was passed.
- EBADRQC
- The given request is not supported by the given control.
- EFAULT
- The data pointer references an inaccessible memory area.
-
-Data types:
- * struct uvc_xu_control_query
-
- __u8 unit Extension unit ID
- __u8 selector Control selector
- __u8 query Request code to send to the device
- __u16 size Control data size (in bytes)
- __u8 *data Control value
+++ /dev/null
-vivid: Virtual Video Test Driver
-================================
-
-This driver emulates video4linux hardware of various types: video capture, video
-output, vbi capture and output, radio receivers and transmitters and a software
-defined radio receiver. In addition a simple framebuffer device is available for
-testing capture and output overlays.
-
-Up to 64 vivid instances can be created, each with up to 16 inputs and 16 outputs.
-
-Each input can be a webcam, TV capture device, S-Video capture device or an HDMI
-capture device. Each output can be an S-Video output device or an HDMI output
-device.
-
-These inputs and outputs act exactly as a real hardware device would behave. This
-allows you to use this driver as a test input for application development, since
-you can test the various features without requiring special hardware.
-
-This document describes the features implemented by this driver:
-
-- Support for read()/write(), MMAP, USERPTR and DMABUF streaming I/O.
-- A large list of test patterns and variations thereof
-- Working brightness, contrast, saturation and hue controls
-- Support for the alpha color component
-- Full colorspace support, including limited/full RGB range
-- All possible control types are present
-- Support for various pixel aspect ratios and video aspect ratios
-- Error injection to test what happens if errors occur
-- Supports crop/compose/scale in any combination for both input and output
-- Can emulate up to 4K resolutions
-- All Field settings are supported for testing interlaced capturing
-- Supports all standard YUV and RGB formats, including two multiplanar YUV formats
-- Raw and Sliced VBI capture and output support
-- Radio receiver and transmitter support, including RDS support
-- Software defined radio (SDR) support
-- Capture and output overlay support
-
-These features will be described in more detail below.
-
-
-Table of Contents
------------------
-
-Section 1: Configuring the driver
-Section 2: Video Capture
-Section 2.1: Webcam Input
-Section 2.2: TV and S-Video Inputs
-Section 2.3: HDMI Input
-Section 3: Video Output
-Section 3.1: S-Video Output
-Section 3.2: HDMI Output
-Section 4: VBI Capture
-Section 5: VBI Output
-Section 6: Radio Receiver
-Section 7: Radio Transmitter
-Section 8: Software Defined Radio Receiver
-Section 9: Controls
-Section 9.1: User Controls - Test Controls
-Section 9.2: User Controls - Video Capture
-Section 9.3: User Controls - Audio
-Section 9.4: Vivid Controls
-Section 9.4.1: Test Pattern Controls
-Section 9.4.2: Capture Feature Selection Controls
-Section 9.4.3: Output Feature Selection Controls
-Section 9.4.4: Error Injection Controls
-Section 9.4.5: VBI Raw Capture Controls
-Section 9.5: Digital Video Controls
-Section 9.6: FM Radio Receiver Controls
-Section 9.7: FM Radio Modulator
-Section 10: Video, VBI and RDS Looping
-Section 10.1: Video and Sliced VBI looping
-Section 10.2: Radio & RDS Looping
-Section 11: Cropping, Composing, Scaling
-Section 12: Formats
-Section 13: Capture Overlay
-Section 14: Output Overlay
-Section 15: CEC (Consumer Electronics Control)
-Section 16: Some Future Improvements
-
-
-Section 1: Configuring the driver
----------------------------------
-
-By default the driver will create a single instance that has a video capture
-device with webcam, TV, S-Video and HDMI inputs, a video output device with
-S-Video and HDMI outputs, one vbi capture device, one vbi output device, one
-radio receiver device, one radio transmitter device and one SDR device.
-
-The number of instances, devices, video inputs and outputs and their types are
-all configurable using the following module options:
-
-n_devs: number of driver instances to create. By default set to 1. Up to 64
- instances can be created.
-
-node_types: which devices should each driver instance create. An array of
- hexadecimal values, one for each instance. The default is 0x1d3d.
- Each value is a bitmask with the following meaning:
- bit 0: Video Capture node
- bit 2-3: VBI Capture node: 0 = none, 1 = raw vbi, 2 = sliced vbi, 3 = both
- bit 4: Radio Receiver node
- bit 5: Software Defined Radio Receiver node
- bit 8: Video Output node
- bit 10-11: VBI Output node: 0 = none, 1 = raw vbi, 2 = sliced vbi, 3 = both
- bit 12: Radio Transmitter node
- bit 16: Framebuffer for testing overlays
-
- So to create four instances, the first two with just one video capture
- device, the second two with just one video output device you would pass
- these module options to vivid:
-
- n_devs=4 node_types=0x1,0x1,0x100,0x100
-
-num_inputs: the number of inputs, one for each instance. By default 4 inputs
- are created for each video capture device. At most 16 inputs can be created,
- and there must be at least one.
-
-input_types: the input types for each instance, the default is 0xe4. This defines
- what the type of each input is when the inputs are created for each driver
- instance. This is a hexadecimal value with up to 16 pairs of bits, each
- pair gives the type and bits 0-1 map to input 0, bits 2-3 map to input 1,
- 30-31 map to input 15. Each pair of bits has the following meaning:
-
- 00: this is a webcam input
- 01: this is a TV tuner input
- 10: this is an S-Video input
- 11: this is an HDMI input
-
- So to create a video capture device with 8 inputs where input 0 is a TV
- tuner, inputs 1-3 are S-Video inputs and inputs 4-7 are HDMI inputs you
- would use the following module options:
-
- num_inputs=8 input_types=0xffa9
-
-num_outputs: the number of outputs, one for each instance. By default 2 outputs
- are created for each video output device. At most 16 outputs can be
- created, and there must be at least one.
-
-output_types: the output types for each instance, the default is 0x02. This defines
- what the type of each output is when the outputs are created for each
- driver instance. This is a hexadecimal value with up to 16 bits, each bit
- gives the type and bit 0 maps to output 0, bit 1 maps to output 1, bit
- 15 maps to output 15. The meaning of each bit is as follows:
-
- 0: this is an S-Video output
- 1: this is an HDMI output
-
- So to create a video output device with 8 outputs where outputs 0-3 are
- S-Video outputs and outputs 4-7 are HDMI outputs you would use the
- following module options:
-
- num_outputs=8 output_types=0xf0
-
-vid_cap_nr: give the desired videoX start number for each video capture device.
- The default is -1 which will just take the first free number. This allows
- you to map capture video nodes to specific videoX device nodes. Example:
-
- n_devs=4 vid_cap_nr=2,4,6,8
-
- This will attempt to assign /dev/video2 for the video capture device of
- the first vivid instance, video4 for the next up to video8 for the last
- instance. If it can't succeed, then it will just take the next free
- number.
-
-vid_out_nr: give the desired videoX start number for each video output device.
- The default is -1 which will just take the first free number.
-
-vbi_cap_nr: give the desired vbiX start number for each vbi capture device.
- The default is -1 which will just take the first free number.
-
-vbi_out_nr: give the desired vbiX start number for each vbi output device.
- The default is -1 which will just take the first free number.
-
-radio_rx_nr: give the desired radioX start number for each radio receiver device.
- The default is -1 which will just take the first free number.
-
-radio_tx_nr: give the desired radioX start number for each radio transmitter
- device. The default is -1 which will just take the first free number.
-
-sdr_cap_nr: give the desired swradioX start number for each SDR capture device.
- The default is -1 which will just take the first free number.
-
-ccs_cap_mode: specify the allowed video capture crop/compose/scaling combination
- for each driver instance. Video capture devices can have any combination
- of cropping, composing and scaling capabilities and this will tell the
- vivid driver which of those is should emulate. By default the user can
- select this through controls.
-
- The value is either -1 (controlled by the user) or a set of three bits,
- each enabling (1) or disabling (0) one of the features:
-
- bit 0: Enable crop support. Cropping will take only part of the
- incoming picture.
- bit 1: Enable compose support. Composing will copy the incoming
- picture into a larger buffer.
- bit 2: Enable scaling support. Scaling can scale the incoming
- picture. The scaler of the vivid driver can enlarge up
- or down to four times the original size. The scaler is
- very simple and low-quality. Simplicity and speed were
- key, not quality.
-
- Note that this value is ignored by webcam inputs: those enumerate
- discrete framesizes and that is incompatible with cropping, composing
- or scaling.
-
-ccs_out_mode: specify the allowed video output crop/compose/scaling combination
- for each driver instance. Video output devices can have any combination
- of cropping, composing and scaling capabilities and this will tell the
- vivid driver which of those is should emulate. By default the user can
- select this through controls.
-
- The value is either -1 (controlled by the user) or a set of three bits,
- each enabling (1) or disabling (0) one of the features:
-
- bit 0: Enable crop support. Cropping will take only part of the
- outgoing buffer.
- bit 1: Enable compose support. Composing will copy the incoming
- buffer into a larger picture frame.
- bit 2: Enable scaling support. Scaling can scale the incoming
- buffer. The scaler of the vivid driver can enlarge up
- or down to four times the original size. The scaler is
- very simple and low-quality. Simplicity and speed were
- key, not quality.
-
-multiplanar: select whether each device instance supports multi-planar formats,
- and thus the V4L2 multi-planar API. By default device instances are
- single-planar.
-
- This module option can override that for each instance. Values are:
-
- 1: this is a single-planar instance.
- 2: this is a multi-planar instance.
-
-vivid_debug: enable driver debugging info
-
-no_error_inj: if set disable the error injecting controls. This option is
- needed in order to run a tool like v4l2-compliance. Tools like that
- exercise all controls including a control like 'Disconnect' which
- emulates a USB disconnect, making the device inaccessible and so
- all tests that v4l2-compliance is doing will fail afterwards.
-
- There may be other situations as well where you want to disable the
- error injection support of vivid. When this option is set, then the
- controls that select crop, compose and scale behavior are also
- removed. Unless overridden by ccs_cap_mode and/or ccs_out_mode the
- will default to enabling crop, compose and scaling.
-
-Taken together, all these module options allow you to precisely customize
-the driver behavior and test your application with all sorts of permutations.
-It is also very suitable to emulate hardware that is not yet available, e.g.
-when developing software for a new upcoming device.
-
-
-Section 2: Video Capture
-------------------------
-
-This is probably the most frequently used feature. The video capture device
-can be configured by using the module options num_inputs, input_types and
-ccs_cap_mode (see section 1 for more detailed information), but by default
-four inputs are configured: a webcam, a TV tuner, an S-Video and an HDMI
-input, one input for each input type. Those are described in more detail
-below.
-
-Special attention has been given to the rate at which new frames become
-available. The jitter will be around 1 jiffie (that depends on the HZ
-configuration of your kernel, so usually 1/100, 1/250 or 1/1000 of a second),
-but the long-term behavior is exactly following the framerate. So a
-framerate of 59.94 Hz is really different from 60 Hz. If the framerate
-exceeds your kernel's HZ value, then you will get dropped frames, but the
-frame/field sequence counting will keep track of that so the sequence
-count will skip whenever frames are dropped.
-
-
-Section 2.1: Webcam Input
--------------------------
-
-The webcam input supports three framesizes: 320x180, 640x360 and 1280x720. It
-supports frames per second settings of 10, 15, 25, 30, 50 and 60 fps. Which ones
-are available depends on the chosen framesize: the larger the framesize, the
-lower the maximum frames per second.
-
-The initially selected colorspace when you switch to the webcam input will be
-sRGB.
-
-
-Section 2.2: TV and S-Video Inputs
-----------------------------------
-
-The only difference between the TV and S-Video input is that the TV has a
-tuner. Otherwise they behave identically.
-
-These inputs support audio inputs as well: one TV and one Line-In. They
-both support all TV standards. If the standard is queried, then the Vivid
-controls 'Standard Signal Mode' and 'Standard' determine what
-the result will be.
-
-These inputs support all combinations of the field setting. Special care has
-been taken to faithfully reproduce how fields are handled for the different
-TV standards. This is particularly noticeable when generating a horizontally
-moving image so the temporal effect of using interlaced formats becomes clearly
-visible. For 50 Hz standards the top field is the oldest and the bottom field
-is the newest in time. For 60 Hz standards that is reversed: the bottom field
-is the oldest and the top field is the newest in time.
-
-When you start capturing in V4L2_FIELD_ALTERNATE mode the first buffer will
-contain the top field for 50 Hz standards and the bottom field for 60 Hz
-standards. This is what capture hardware does as well.
-
-Finally, for PAL/SECAM standards the first half of the top line contains noise.
-This simulates the Wide Screen Signal that is commonly placed there.
-
-The initially selected colorspace when you switch to the TV or S-Video input
-will be SMPTE-170M.
-
-The pixel aspect ratio will depend on the TV standard. The video aspect ratio
-can be selected through the 'Standard Aspect Ratio' Vivid control.
-Choices are '4x3', '16x9' which will give letterboxed widescreen video and
-'16x9 Anamorphic' which will give full screen squashed anamorphic widescreen
-video that will need to be scaled accordingly.
-
-The TV 'tuner' supports a frequency range of 44-958 MHz. Channels are available
-every 6 MHz, starting from 49.25 MHz. For each channel the generated image
-will be in color for the +/- 0.25 MHz around it, and in grayscale for
-+/- 1 MHz around the channel. Beyond that it is just noise. The VIDIOC_G_TUNER
-ioctl will return 100% signal strength for +/- 0.25 MHz and 50% for +/- 1 MHz.
-It will also return correct afc values to show whether the frequency is too
-low or too high.
-
-The audio subchannels that are returned are MONO for the +/- 1 MHz range around
-a valid channel frequency. When the frequency is within +/- 0.25 MHz of the
-channel it will return either MONO, STEREO, either MONO | SAP (for NTSC) or
-LANG1 | LANG2 (for others), or STEREO | SAP.
-
-Which one is returned depends on the chosen channel, each next valid channel
-will cycle through the possible audio subchannel combinations. This allows
-you to test the various combinations by just switching channels..
-
-Finally, for these inputs the v4l2_timecode struct is filled in in the
-dequeued v4l2_buffer struct.
-
-
-Section 2.3: HDMI Input
------------------------
-
-The HDMI inputs supports all CEA-861 and DMT timings, both progressive and
-interlaced, for pixelclock frequencies between 25 and 600 MHz. The field
-mode for interlaced formats is always V4L2_FIELD_ALTERNATE. For HDMI the
-field order is always top field first, and when you start capturing an
-interlaced format you will receive the top field first.
-
-The initially selected colorspace when you switch to the HDMI input or
-select an HDMI timing is based on the format resolution: for resolutions
-less than or equal to 720x576 the colorspace is set to SMPTE-170M, for
-others it is set to REC-709 (CEA-861 timings) or sRGB (VESA DMT timings).
-
-The pixel aspect ratio will depend on the HDMI timing: for 720x480 is it
-set as for the NTSC TV standard, for 720x576 it is set as for the PAL TV
-standard, and for all others a 1:1 pixel aspect ratio is returned.
-
-The video aspect ratio can be selected through the 'DV Timings Aspect Ratio'
-Vivid control. Choices are 'Source Width x Height' (just use the
-same ratio as the chosen format), '4x3' or '16x9', either of which can
-result in pillarboxed or letterboxed video.
-
-For HDMI inputs it is possible to set the EDID. By default a simple EDID
-is provided. You can only set the EDID for HDMI inputs. Internally, however,
-the EDID is shared between all HDMI inputs.
-
-No interpretation is done of the EDID data with the exception of the
-physical address. See the CEC section for more details.
-
-There is a maximum of 15 HDMI inputs (if there are more, then they will be
-reduced to 15) since that's the limitation of the EDID physical address.
-
-
-Section 3: Video Output
------------------------
-
-The video output device can be configured by using the module options
-num_outputs, output_types and ccs_out_mode (see section 1 for more detailed
-information), but by default two outputs are configured: an S-Video and an
-HDMI input, one output for each output type. Those are described in more detail
-below.
-
-Like with video capture the framerate is also exact in the long term.
-
-
-Section 3.1: S-Video Output
----------------------------
-
-This output supports audio outputs as well: "Line-Out 1" and "Line-Out 2".
-The S-Video output supports all TV standards.
-
-This output supports all combinations of the field setting.
-
-The initially selected colorspace when you switch to the TV or S-Video input
-will be SMPTE-170M.
-
-
-Section 3.2: HDMI Output
-------------------------
-
-The HDMI output supports all CEA-861 and DMT timings, both progressive and
-interlaced, for pixelclock frequencies between 25 and 600 MHz. The field
-mode for interlaced formats is always V4L2_FIELD_ALTERNATE.
-
-The initially selected colorspace when you switch to the HDMI output or
-select an HDMI timing is based on the format resolution: for resolutions
-less than or equal to 720x576 the colorspace is set to SMPTE-170M, for
-others it is set to REC-709 (CEA-861 timings) or sRGB (VESA DMT timings).
-
-The pixel aspect ratio will depend on the HDMI timing: for 720x480 is it
-set as for the NTSC TV standard, for 720x576 it is set as for the PAL TV
-standard, and for all others a 1:1 pixel aspect ratio is returned.
-
-An HDMI output has a valid EDID which can be obtained through VIDIOC_G_EDID.
-
-There is a maximum of 15 HDMI outputs (if there are more, then they will be
-reduced to 15) since that's the limitation of the EDID physical address. See
-also the CEC section for more details.
-
-Section 4: VBI Capture
-----------------------
-
-There are three types of VBI capture devices: those that only support raw
-(undecoded) VBI, those that only support sliced (decoded) VBI and those that
-support both. This is determined by the node_types module option. In all
-cases the driver will generate valid VBI data: for 60 Hz standards it will
-generate Closed Caption and XDS data. The closed caption stream will
-alternate between "Hello world!" and "Closed captions test" every second.
-The XDS stream will give the current time once a minute. For 50 Hz standards
-it will generate the Wide Screen Signal which is based on the actual Video
-Aspect Ratio control setting and teletext pages 100-159, one page per frame.
-
-The VBI device will only work for the S-Video and TV inputs, it will give
-back an error if the current input is a webcam or HDMI.
-
-
-Section 5: VBI Output
----------------------
-
-There are three types of VBI output devices: those that only support raw
-(undecoded) VBI, those that only support sliced (decoded) VBI and those that
-support both. This is determined by the node_types module option.
-
-The sliced VBI output supports the Wide Screen Signal and the teletext signal
-for 50 Hz standards and Closed Captioning + XDS for 60 Hz standards.
-
-The VBI device will only work for the S-Video output, it will give
-back an error if the current output is HDMI.
-
-
-Section 6: Radio Receiver
--------------------------
-
-The radio receiver emulates an FM/AM/SW receiver. The FM band also supports RDS.
-The frequency ranges are:
-
- FM: 64 MHz - 108 MHz
- AM: 520 kHz - 1710 kHz
- SW: 2300 kHz - 26.1 MHz
-
-Valid channels are emulated every 1 MHz for FM and every 100 kHz for AM and SW.
-The signal strength decreases the further the frequency is from the valid
-frequency until it becomes 0% at +/- 50 kHz (FM) or 5 kHz (AM/SW) from the
-ideal frequency. The initial frequency when the driver is loaded is set to
-95 MHz.
-
-The FM receiver supports RDS as well, both using 'Block I/O' and 'Controls'
-modes. In the 'Controls' mode the RDS information is stored in read-only
-controls. These controls are updated every time the frequency is changed,
-or when the tuner status is requested. The Block I/O method uses the read()
-interface to pass the RDS blocks on to the application for decoding.
-
-The RDS signal is 'detected' for +/- 12.5 kHz around the channel frequency,
-and the further the frequency is away from the valid frequency the more RDS
-errors are randomly introduced into the block I/O stream, up to 50% of all
-blocks if you are +/- 12.5 kHz from the channel frequency. All four errors
-can occur in equal proportions: blocks marked 'CORRECTED', blocks marked
-'ERROR', blocks marked 'INVALID' and dropped blocks.
-
-The generated RDS stream contains all the standard fields contained in a
-0B group, and also radio text and the current time.
-
-The receiver supports HW frequency seek, either in Bounded mode, Wrap Around
-mode or both, which is configurable with the "Radio HW Seek Mode" control.
-
-
-Section 7: Radio Transmitter
-----------------------------
-
-The radio transmitter emulates an FM/AM/SW transmitter. The FM band also supports RDS.
-The frequency ranges are:
-
- FM: 64 MHz - 108 MHz
- AM: 520 kHz - 1710 kHz
- SW: 2300 kHz - 26.1 MHz
-
-The initial frequency when the driver is loaded is 95.5 MHz.
-
-The FM transmitter supports RDS as well, both using 'Block I/O' and 'Controls'
-modes. In the 'Controls' mode the transmitted RDS information is configured
-using controls, and in 'Block I/O' mode the blocks are passed to the driver
-using write().
-
-
-Section 8: Software Defined Radio Receiver
-------------------------------------------
-
-The SDR receiver has three frequency bands for the ADC tuner:
-
- - 300 kHz
- - 900 kHz - 2800 kHz
- - 3200 kHz
-
-The RF tuner supports 50 MHz - 2000 MHz.
-
-The generated data contains the In-phase and Quadrature components of a
-1 kHz tone that has an amplitude of sqrt(2).
-
-
-Section 9: Controls
--------------------
-
-Different devices support different controls. The sections below will describe
-each control and which devices support them.
-
-
-Section 9.1: User Controls - Test Controls
-------------------------------------------
-
-The Button, Boolean, Integer 32 Bits, Integer 64 Bits, Menu, String, Bitmask and
-Integer Menu are controls that represent all possible control types. The Menu
-control and the Integer Menu control both have 'holes' in their menu list,
-meaning that one or more menu items return EINVAL when VIDIOC_QUERYMENU is called.
-Both menu controls also have a non-zero minimum control value. These features
-allow you to check if your application can handle such things correctly.
-These controls are supported for every device type.
-
-
-Section 9.2: User Controls - Video Capture
-------------------------------------------
-
-The following controls are specific to video capture.
-
-The Brightness, Contrast, Saturation and Hue controls actually work and are
-standard. There is one special feature with the Brightness control: each
-video input has its own brightness value, so changing input will restore
-the brightness for that input. In addition, each video input uses a different
-brightness range (minimum and maximum control values). Switching inputs will
-cause a control event to be sent with the V4L2_EVENT_CTRL_CH_RANGE flag set.
-This allows you to test controls that can change their range.
-
-The 'Gain, Automatic' and Gain controls can be used to test volatile controls:
-if 'Gain, Automatic' is set, then the Gain control is volatile and changes
-constantly. If 'Gain, Automatic' is cleared, then the Gain control is a normal
-control.
-
-The 'Horizontal Flip' and 'Vertical Flip' controls can be used to flip the
-image. These combine with the 'Sensor Flipped Horizontally/Vertically' Vivid
-controls.
-
-The 'Alpha Component' control can be used to set the alpha component for
-formats containing an alpha channel.
-
-
-Section 9.3: User Controls - Audio
-----------------------------------
-
-The following controls are specific to video capture and output and radio
-receivers and transmitters.
-
-The 'Volume' and 'Mute' audio controls are typical for such devices to
-control the volume and mute the audio. They don't actually do anything in
-the vivid driver.
-
-
-Section 9.4: Vivid Controls
----------------------------
-
-These vivid custom controls control the image generation, error injection, etc.
-
-
-Section 9.4.1: Test Pattern Controls
-------------------------------------
-
-The Test Pattern Controls are all specific to video capture.
-
-Test Pattern: selects which test pattern to use. Use the CSC Colorbar for
- testing colorspace conversions: the colors used in that test pattern
- map to valid colors in all colorspaces. The colorspace conversion
- is disabled for the other test patterns.
-
-OSD Text Mode: selects whether the text superimposed on the
- test pattern should be shown, and if so, whether only counters should
- be displayed or the full text.
-
-Horizontal Movement: selects whether the test pattern should
- move to the left or right and at what speed.
-
-Vertical Movement: does the same for the vertical direction.
-
-Show Border: show a two-pixel wide border at the edge of the actual image,
- excluding letter or pillarboxing.
-
-Show Square: show a square in the middle of the image. If the image is
- displayed with the correct pixel and image aspect ratio corrections,
- then the width and height of the square on the monitor should be
- the same.
-
-Insert SAV Code in Image: adds a SAV (Start of Active Video) code to the image.
- This can be used to check if such codes in the image are inadvertently
- interpreted instead of being ignored.
-
-Insert EAV Code in Image: does the same for the EAV (End of Active Video) code.
-
-
-Section 9.4.2: Capture Feature Selection Controls
--------------------------------------------------
-
-These controls are all specific to video capture.
-
-Sensor Flipped Horizontally: the image is flipped horizontally and the
- V4L2_IN_ST_HFLIP input status flag is set. This emulates the case where
- a sensor is for example mounted upside down.
-
-Sensor Flipped Vertically: the image is flipped vertically and the
- V4L2_IN_ST_VFLIP input status flag is set. This emulates the case where
- a sensor is for example mounted upside down.
-
-Standard Aspect Ratio: selects if the image aspect ratio as used for the TV or
- S-Video input should be 4x3, 16x9 or anamorphic widescreen. This may
- introduce letterboxing.
-
-DV Timings Aspect Ratio: selects if the image aspect ratio as used for the HDMI
- input should be the same as the source width and height ratio, or if
- it should be 4x3 or 16x9. This may introduce letter or pillarboxing.
-
-Timestamp Source: selects when the timestamp for each buffer is taken.
-
-Colorspace: selects which colorspace should be used when generating the image.
- This only applies if the CSC Colorbar test pattern is selected,
- otherwise the test pattern will go through unconverted.
- This behavior is also what you want, since a 75% Colorbar
- should really have 75% signal intensity and should not be affected
- by colorspace conversions.
-
- Changing the colorspace will result in the V4L2_EVENT_SOURCE_CHANGE
- to be sent since it emulates a detected colorspace change.
-
-Transfer Function: selects which colorspace transfer function should be used when
- generating an image. This only applies if the CSC Colorbar test pattern is
- selected, otherwise the test pattern will go through unconverted.
- This behavior is also what you want, since a 75% Colorbar
- should really have 75% signal intensity and should not be affected
- by colorspace conversions.
-
- Changing the transfer function will result in the V4L2_EVENT_SOURCE_CHANGE
- to be sent since it emulates a detected colorspace change.
-
-Y'CbCr Encoding: selects which Y'CbCr encoding should be used when generating
- a Y'CbCr image. This only applies if the format is set to a Y'CbCr format
- as opposed to an RGB format.
-
- Changing the Y'CbCr encoding will result in the V4L2_EVENT_SOURCE_CHANGE
- to be sent since it emulates a detected colorspace change.
-
-Quantization: selects which quantization should be used for the RGB or Y'CbCr
- encoding when generating the test pattern.
-
- Changing the quantization will result in the V4L2_EVENT_SOURCE_CHANGE
- to be sent since it emulates a detected colorspace change.
-
-Limited RGB Range (16-235): selects if the RGB range of the HDMI source should
- be limited or full range. This combines with the Digital Video 'Rx RGB
- Quantization Range' control and can be used to test what happens if
- a source provides you with the wrong quantization range information.
- See the description of that control for more details.
-
-Apply Alpha To Red Only: apply the alpha channel as set by the 'Alpha Component'
- user control to the red color of the test pattern only.
-
-Enable Capture Cropping: enables crop support. This control is only present if
- the ccs_cap_mode module option is set to the default value of -1 and if
- the no_error_inj module option is set to 0 (the default).
-
-Enable Capture Composing: enables composing support. This control is only
- present if the ccs_cap_mode module option is set to the default value of
- -1 and if the no_error_inj module option is set to 0 (the default).
-
-Enable Capture Scaler: enables support for a scaler (maximum 4 times upscaling
- and downscaling). This control is only present if the ccs_cap_mode
- module option is set to the default value of -1 and if the no_error_inj
- module option is set to 0 (the default).
-
-Maximum EDID Blocks: determines how many EDID blocks the driver supports.
- Note that the vivid driver does not actually interpret new EDID
- data, it just stores it. It allows for up to 256 EDID blocks
- which is the maximum supported by the standard.
-
-Fill Percentage of Frame: can be used to draw only the top X percent
- of the image. Since each frame has to be drawn by the driver, this
- demands a lot of the CPU. For large resolutions this becomes
- problematic. By drawing only part of the image this CPU load can
- be reduced.
-
-
-Section 9.4.3: Output Feature Selection Controls
-------------------------------------------------
-
-These controls are all specific to video output.
-
-Enable Output Cropping: enables crop support. This control is only present if
- the ccs_out_mode module option is set to the default value of -1 and if
- the no_error_inj module option is set to 0 (the default).
-
-Enable Output Composing: enables composing support. This control is only
- present if the ccs_out_mode module option is set to the default value of
- -1 and if the no_error_inj module option is set to 0 (the default).
-
-Enable Output Scaler: enables support for a scaler (maximum 4 times upscaling
- and downscaling). This control is only present if the ccs_out_mode
- module option is set to the default value of -1 and if the no_error_inj
- module option is set to 0 (the default).
-
-
-Section 9.4.4: Error Injection Controls
----------------------------------------
-
-The following two controls are only valid for video and vbi capture.
-
-Standard Signal Mode: selects the behavior of VIDIOC_QUERYSTD: what should
- it return?
-
- Changing this control will result in the V4L2_EVENT_SOURCE_CHANGE
- to be sent since it emulates a changed input condition (e.g. a cable
- was plugged in or out).
-
-Standard: selects the standard that VIDIOC_QUERYSTD should return if the
- previous control is set to "Selected Standard".
-
- Changing this control will result in the V4L2_EVENT_SOURCE_CHANGE
- to be sent since it emulates a changed input standard.
-
-
-The following two controls are only valid for video capture.
-
-DV Timings Signal Mode: selects the behavior of VIDIOC_QUERY_DV_TIMINGS: what
- should it return?
-
- Changing this control will result in the V4L2_EVENT_SOURCE_CHANGE
- to be sent since it emulates a changed input condition (e.g. a cable
- was plugged in or out).
-
-DV Timings: selects the timings the VIDIOC_QUERY_DV_TIMINGS should return
- if the previous control is set to "Selected DV Timings".
-
- Changing this control will result in the V4L2_EVENT_SOURCE_CHANGE
- to be sent since it emulates changed input timings.
-
-
-The following controls are only present if the no_error_inj module option
-is set to 0 (the default). These controls are valid for video and vbi
-capture and output streams and for the SDR capture device except for the
-Disconnect control which is valid for all devices.
-
-Wrap Sequence Number: test what happens when you wrap the sequence number in
- struct v4l2_buffer around.
-
-Wrap Timestamp: test what happens when you wrap the timestamp in struct
- v4l2_buffer around.
-
-Percentage of Dropped Buffers: sets the percentage of buffers that
- are never returned by the driver (i.e., they are dropped).
-
-Disconnect: emulates a USB disconnect. The device will act as if it has
- been disconnected. Only after all open filehandles to the device
- node have been closed will the device become 'connected' again.
-
-Inject V4L2_BUF_FLAG_ERROR: when pressed, the next frame returned by
- the driver will have the error flag set (i.e. the frame is marked
- corrupt).
-
-Inject VIDIOC_REQBUFS Error: when pressed, the next REQBUFS or CREATE_BUFS
- ioctl call will fail with an error. To be precise: the videobuf2
- queue_setup() op will return -EINVAL.
-
-Inject VIDIOC_QBUF Error: when pressed, the next VIDIOC_QBUF or
- VIDIOC_PREPARE_BUFFER ioctl call will fail with an error. To be
- precise: the videobuf2 buf_prepare() op will return -EINVAL.
-
-Inject VIDIOC_STREAMON Error: when pressed, the next VIDIOC_STREAMON ioctl
- call will fail with an error. To be precise: the videobuf2
- start_streaming() op will return -EINVAL.
-
-Inject Fatal Streaming Error: when pressed, the streaming core will be
- marked as having suffered a fatal error, the only way to recover
- from that is to stop streaming. To be precise: the videobuf2
- vb2_queue_error() function is called.
-
-
-Section 9.4.5: VBI Raw Capture Controls
----------------------------------------
-
-Interlaced VBI Format: if set, then the raw VBI data will be interlaced instead
- of providing it grouped by field.
-
-
-Section 9.5: Digital Video Controls
------------------------------------
-
-Rx RGB Quantization Range: sets the RGB quantization detection of the HDMI
- input. This combines with the Vivid 'Limited RGB Range (16-235)'
- control and can be used to test what happens if a source provides
- you with the wrong quantization range information. This can be tested
- by selecting an HDMI input, setting this control to Full or Limited
- range and selecting the opposite in the 'Limited RGB Range (16-235)'
- control. The effect is easy to see if the 'Gray Ramp' test pattern
- is selected.
-
-Tx RGB Quantization Range: sets the RGB quantization detection of the HDMI
- output. It is currently not used for anything in vivid, but most HDMI
- transmitters would typically have this control.
-
-Transmit Mode: sets the transmit mode of the HDMI output to HDMI or DVI-D. This
- affects the reported colorspace since DVI_D outputs will always use
- sRGB.
-
-
-Section 9.6: FM Radio Receiver Controls
----------------------------------------
-
-RDS Reception: set if the RDS receiver should be enabled.
-
-RDS Program Type:
-RDS PS Name:
-RDS Radio Text:
-RDS Traffic Announcement:
-RDS Traffic Program:
-RDS Music: these are all read-only controls. If RDS Rx I/O Mode is set to
- "Block I/O", then they are inactive as well. If RDS Rx I/O Mode is set
- to "Controls", then these controls report the received RDS data. Note
- that the vivid implementation of this is pretty basic: they are only
- updated when you set a new frequency or when you get the tuner status
- (VIDIOC_G_TUNER).
-
-Radio HW Seek Mode: can be one of "Bounded", "Wrap Around" or "Both". This
- determines if VIDIOC_S_HW_FREQ_SEEK will be bounded by the frequency
- range or wrap-around or if it is selectable by the user.
-
-Radio Programmable HW Seek: if set, then the user can provide the lower and
- upper bound of the HW Seek. Otherwise the frequency range boundaries
- will be used.
-
-Generate RBDS Instead of RDS: if set, then generate RBDS (the US variant of
- RDS) data instead of RDS (European-style RDS). This affects only the
- PICODE and PTY codes.
-
-RDS Rx I/O Mode: this can be "Block I/O" where the RDS blocks have to be read()
- by the application, or "Controls" where the RDS data is provided by
- the RDS controls mentioned above.
-
-
-Section 9.7: FM Radio Modulator Controls
-----------------------------------------
-
-RDS Program ID:
-RDS Program Type:
-RDS PS Name:
-RDS Radio Text:
-RDS Stereo:
-RDS Artificial Head:
-RDS Compressed:
-RDS Dynamic PTY:
-RDS Traffic Announcement:
-RDS Traffic Program:
-RDS Music: these are all controls that set the RDS data that is transmitted by
- the FM modulator.
-
-RDS Tx I/O Mode: this can be "Block I/O" where the application has to use write()
- to pass the RDS blocks to the driver, or "Controls" where the RDS data is
- provided by the RDS controls mentioned above.
-
-
-Section 10: Video, VBI and RDS Looping
---------------------------------------
-
-The vivid driver supports looping of video output to video input, VBI output
-to VBI input and RDS output to RDS input. For video/VBI looping this emulates
-as if a cable was hooked up between the output and input connector. So video
-and VBI looping is only supported between S-Video and HDMI inputs and outputs.
-VBI is only valid for S-Video as it makes no sense for HDMI.
-
-Since radio is wireless this looping always happens if the radio receiver
-frequency is close to the radio transmitter frequency. In that case the radio
-transmitter will 'override' the emulated radio stations.
-
-Looping is currently supported only between devices created by the same
-vivid driver instance.
-
-
-Section 10.1: Video and Sliced VBI looping
-------------------------------------------
-
-The way to enable video/VBI looping is currently fairly crude. A 'Loop Video'
-control is available in the "Vivid" control class of the video
-capture and VBI capture devices. When checked the video looping will be enabled.
-Once enabled any video S-Video or HDMI input will show a static test pattern
-until the video output has started. At that time the video output will be
-looped to the video input provided that:
-
-- the input type matches the output type. So the HDMI input cannot receive
- video from the S-Video output.
-
-- the video resolution of the video input must match that of the video output.
- So it is not possible to loop a 50 Hz (720x576) S-Video output to a 60 Hz
- (720x480) S-Video input, or a 720p60 HDMI output to a 1080p30 input.
-
-- the pixel formats must be identical on both sides. Otherwise the driver would
- have to do pixel format conversion as well, and that's taking things too far.
-
-- the field settings must be identical on both sides. Same reason as above:
- requiring the driver to convert from one field format to another complicated
- matters too much. This also prohibits capturing with 'Field Top' or 'Field
- Bottom' when the output video is set to 'Field Alternate'. This combination,
- while legal, became too complicated to support. Both sides have to be 'Field
- Alternate' for this to work. Also note that for this specific case the
- sequence and field counting in struct v4l2_buffer on the capture side may not
- be 100% accurate.
-
-- field settings V4L2_FIELD_SEQ_TB/BT are not supported. While it is possible to
- implement this, it would mean a lot of work to get this right. Since these
- field values are rarely used the decision was made not to implement this for
- now.
-
-- on the input side the "Standard Signal Mode" for the S-Video input or the
- "DV Timings Signal Mode" for the HDMI input should be configured so that a
- valid signal is passed to the video input.
-
-The framerates do not have to match, although this might change in the future.
-
-By default you will see the OSD text superimposed on top of the looped video.
-This can be turned off by changing the "OSD Text Mode" control of the video
-capture device.
-
-For VBI looping to work all of the above must be valid and in addition the vbi
-output must be configured for sliced VBI. The VBI capture side can be configured
-for either raw or sliced VBI. Note that at the moment only CC/XDS (60 Hz formats)
-and WSS (50 Hz formats) VBI data is looped. Teletext VBI data is not looped.
-
-
-Section 10.2: Radio & RDS Looping
----------------------------------
-
-As mentioned in section 6 the radio receiver emulates stations are regular
-frequency intervals. Depending on the frequency of the radio receiver a
-signal strength value is calculated (this is returned by VIDIOC_G_TUNER).
-However, it will also look at the frequency set by the radio transmitter and
-if that results in a higher signal strength than the settings of the radio
-transmitter will be used as if it was a valid station. This also includes
-the RDS data (if any) that the transmitter 'transmits'. This is received
-faithfully on the receiver side. Note that when the driver is loaded the
-frequencies of the radio receiver and transmitter are not identical, so
-initially no looping takes place.
-
-
-Section 11: Cropping, Composing, Scaling
-----------------------------------------
-
-This driver supports cropping, composing and scaling in any combination. Normally
-which features are supported can be selected through the Vivid controls,
-but it is also possible to hardcode it when the module is loaded through the
-ccs_cap_mode and ccs_out_mode module options. See section 1 on the details of
-these module options.
-
-This allows you to test your application for all these variations.
-
-Note that the webcam input never supports cropping, composing or scaling. That
-only applies to the TV/S-Video/HDMI inputs and outputs. The reason is that
-webcams, including this virtual implementation, normally use
-VIDIOC_ENUM_FRAMESIZES to list a set of discrete framesizes that it supports.
-And that does not combine with cropping, composing or scaling. This is
-primarily a limitation of the V4L2 API which is carefully reproduced here.
-
-The minimum and maximum resolutions that the scaler can achieve are 16x16 and
-(4096 * 4) x (2160 x 4), but it can only scale up or down by a factor of 4 or
-less. So for a source resolution of 1280x720 the minimum the scaler can do is
-320x180 and the maximum is 5120x2880. You can play around with this using the
-qv4l2 test tool and you will see these dependencies.
-
-This driver also supports larger 'bytesperline' settings, something that
-VIDIOC_S_FMT allows but that few drivers implement.
-
-The scaler is a simple scaler that uses the Coarse Bresenham algorithm. It's
-designed for speed and simplicity, not quality.
-
-If the combination of crop, compose and scaling allows it, then it is possible
-to change crop and compose rectangles on the fly.
-
-
-Section 12: Formats
--------------------
-
-The driver supports all the regular packed and planar 4:4:4, 4:2:2 and 4:2:0
-YUYV formats, 8, 16, 24 and 32 RGB packed formats and various multiplanar
-formats.
-
-The alpha component can be set through the 'Alpha Component' User control
-for those formats that support it. If the 'Apply Alpha To Red Only' control
-is set, then the alpha component is only used for the color red and set to
-0 otherwise.
-
-The driver has to be configured to support the multiplanar formats. By default
-the driver instances are single-planar. This can be changed by setting the
-multiplanar module option, see section 1 for more details on that option.
-
-If the driver instance is using the multiplanar formats/API, then the first
-single planar format (YUYV) and the multiplanar NV16M and NV61M formats the
-will have a plane that has a non-zero data_offset of 128 bytes. It is rare for
-data_offset to be non-zero, so this is a useful feature for testing applications.
-
-Video output will also honor any data_offset that the application set.
-
-
-Section 13: Capture Overlay
----------------------------
-
-Note: capture overlay support is implemented primarily to test the existing
-V4L2 capture overlay API. In practice few if any GPUs support such overlays
-anymore, and neither are they generally needed anymore since modern hardware
-is so much more capable. By setting flag 0x10000 in the node_types module
-option the vivid driver will create a simple framebuffer device that can be
-used for testing this API. Whether this API should be used for new drivers is
-questionable.
-
-This driver has support for a destructive capture overlay with bitmap clipping
-and list clipping (up to 16 rectangles) capabilities. Overlays are not
-supported for multiplanar formats. It also honors the struct v4l2_window field
-setting: if it is set to FIELD_TOP or FIELD_BOTTOM and the capture setting is
-FIELD_ALTERNATE, then only the top or bottom fields will be copied to the overlay.
-
-The overlay only works if you are also capturing at that same time. This is a
-vivid limitation since it copies from a buffer to the overlay instead of
-filling the overlay directly. And if you are not capturing, then no buffers
-are available to fill.
-
-In addition, the pixelformat of the capture format and that of the framebuffer
-must be the same for the overlay to work. Otherwise VIDIOC_OVERLAY will return
-an error.
-
-In order to really see what it going on you will need to create two vivid
-instances: the first with a framebuffer enabled. You configure the capture
-overlay of the second instance to use the framebuffer of the first, then
-you start capturing in the second instance. For the first instance you setup
-the output overlay for the video output, turn on video looping and capture
-to see the blended framebuffer overlay that's being written to by the second
-instance. This setup would require the following commands:
-
- $ sudo modprobe vivid n_devs=2 node_types=0x10101,0x1
- $ v4l2-ctl -d1 --find-fb
- /dev/fb1 is the framebuffer associated with base address 0x12800000
- $ sudo v4l2-ctl -d2 --set-fbuf fb=1
- $ v4l2-ctl -d1 --set-fbuf fb=1
- $ v4l2-ctl -d0 --set-fmt-video=pixelformat='AR15'
- $ v4l2-ctl -d1 --set-fmt-video-out=pixelformat='AR15'
- $ v4l2-ctl -d2 --set-fmt-video=pixelformat='AR15'
- $ v4l2-ctl -d0 -i2
- $ v4l2-ctl -d2 -i2
- $ v4l2-ctl -d2 -c horizontal_movement=4
- $ v4l2-ctl -d1 --overlay=1
- $ v4l2-ctl -d1 -c loop_video=1
- $ v4l2-ctl -d2 --stream-mmap --overlay=1
-
-And from another console:
-
- $ v4l2-ctl -d1 --stream-out-mmap
-
-And yet another console:
-
- $ qv4l2
-
-and start streaming.
-
-As you can see, this is not for the faint of heart...
-
-
-Section 14: Output Overlay
---------------------------
-
-Note: output overlays are primarily implemented in order to test the existing
-V4L2 output overlay API. Whether this API should be used for new drivers is
-questionable.
-
-This driver has support for an output overlay and is capable of:
-
- - bitmap clipping,
- - list clipping (up to 16 rectangles)
- - chromakey
- - source chromakey
- - global alpha
- - local alpha
- - local inverse alpha
-
-Output overlays are not supported for multiplanar formats. In addition, the
-pixelformat of the capture format and that of the framebuffer must be the
-same for the overlay to work. Otherwise VIDIOC_OVERLAY will return an error.
-
-Output overlays only work if the driver has been configured to create a
-framebuffer by setting flag 0x10000 in the node_types module option. The
-created framebuffer has a size of 720x576 and supports ARGB 1:5:5:5 and
-RGB 5:6:5.
-
-In order to see the effects of the various clipping, chromakeying or alpha
-processing capabilities you need to turn on video looping and see the results
-on the capture side. The use of the clipping, chromakeying or alpha processing
-capabilities will slow down the video loop considerably as a lot of checks have
-to be done per pixel.
-
-
-Section 15: CEC (Consumer Electronics Control)
-----------------------------------------------
-
-If there are HDMI inputs then a CEC adapter will be created that has
-the same number of input ports. This is the equivalent of e.g. a TV that
-has that number of inputs. Each HDMI output will also create a
-CEC adapter that is hooked up to the corresponding input port, or (if there
-are more outputs than inputs) is not hooked up at all. In other words,
-this is the equivalent of hooking up each output device to an input port of
-the TV. Any remaining output devices remain unconnected.
-
-The EDID that each output reads reports a unique CEC physical address that is
-based on the physical address of the EDID of the input. So if the EDID of the
-receiver has physical address A.B.0.0, then each output will see an EDID
-containing physical address A.B.C.0 where C is 1 to the number of inputs. If
-there are more outputs than inputs then the remaining outputs have a CEC adapter
-that is disabled and reports an invalid physical address.
-
-
-Section 16: Some Future Improvements
-------------------------------------
-
-Just as a reminder and in no particular order:
-
-- Add a virtual alsa driver to test audio
-- Add virtual sub-devices and media controller support
-- Some support for testing compressed video
-- Add support to loop raw VBI output to raw VBI input
-- Add support to loop teletext sliced VBI output to VBI input
-- Fix sequence/field numbering when looping of video with alternate fields
-- Add support for V4L2_CID_BG_COLOR for video outputs
-- Add ARGB888 overlay support: better testing of the alpha channel
-- Improve pixel aspect support in the tpg code by passing a real v4l2_fract
-- Use per-queue locks and/or per-device locks to improve throughput
-- Add support to loop from a specific output to a specific input across
- vivid instances
-- The SDR radio should use the same 'frequencies' for stations as the normal
- radio receiver, and give back noise if the frequency doesn't match up with
- a station frequency
-- Make a thread for the RDS generation, that would help in particular for the
- "Controls" RDS Rx I/O Mode as the read-only RDS controls could be updated
- in real-time.
-- Changing the EDID should cause hotplug detect emulation to happen.
+++ /dev/null
-Zoran 364xx based USB webcam module version 0.72
-site: http://royale.zerezo.com/zr364xx/
-mail: royale@zerezo.com
-
-introduction:
-This brings support under Linux for the Aiptek PocketDV 3300 in webcam mode.
-If you just want to get on your PC the pictures and movies on the camera, you should use the usb-storage module instead.
-The driver works with several other cameras in webcam mode (see the list below).
-Maybe this code can work for other JPEG/USB cams based on the Coach chips from Zoran?
-Possible chipsets are : ZR36430 (ZR36430BGC) and maybe ZR36431, ZR36440, ZR36442...
-You can try the experience changing the vendor/product ID values (look at the source code).
-You can get these values by looking at /var/log/messages when you plug your camera, or by typing : cat /proc/bus/usb/devices.
-If you manage to use your cam with this code, you can send me a mail (royale@zerezo.com) with the name of your cam and a patch if needed.
-This is a beta release of the driver.
-Since version 0.70, this driver is only compatible with V4L2 API and 2.6.x kernels.
-If you need V4L1 or 2.4x kernels support, please use an older version, but the code is not maintained anymore.
-Good luck!
-
-install:
-In order to use this driver, you must compile it with your kernel.
-Location: Device Drivers -> Multimedia devices -> Video For Linux -> Video Capture Adapters -> V4L USB devices
-
-usage:
-modprobe zr364xx debug=X mode=Y
- - debug : set to 1 to enable verbose debug messages
- - mode : 0 = 320x240, 1 = 160x120, 2 = 640x480
-You can then use the camera with V4L2 compatible applications, for example Ekiga.
-To capture a single image, try this: dd if=/dev/video0 of=test.jpg bs=1M count=1
-
-links :
-http://mxhaard.free.fr/ (support for many others cams including some Aiptek PocketDV)
-http://www.harmwal.nl/pccam880/ (this project also supports cameras based on this chipset)
-
-supported devices:
------- ------- ----------- -----
-Vendor Product Distributor Model
------- ------- ----------- -----
-0x08ca 0x0109 Aiptek PocketDV 3300
-0x08ca 0x0109 Maxell Maxcam PRO DV3
-0x041e 0x4024 Creative PC-CAM 880
-0x0d64 0x0108 Aiptek Fidelity 3200
-0x0d64 0x0108 Praktica DCZ 1.3 S
-0x0d64 0x0108 Genius Digital Camera (?)
-0x0d64 0x0108 DXG Technology Fashion Cam
-0x0546 0x3187 Polaroid iON 230
-0x0d64 0x3108 Praktica Exakta DC 2200
-0x0d64 0x3108 Genius G-Shot D211
-0x0595 0x4343 Concord Eye-Q Duo 1300
-0x0595 0x4343 Concord Eye-Q Duo 2000
-0x0595 0x4343 Fujifilm EX-10
-0x0595 0x4343 Ricoh RDC-6000
-0x0595 0x4343 Digitrex DSC 1300
-0x0595 0x4343 Firstline FDC 2000
-0x0bb0 0x500d Concord EyeQ Go Wireless
-0x0feb 0x2004 CRS Electronic 3.3 Digital Camera
-0x0feb 0x2004 Packard Bell DSC-300
-0x055f 0xb500 Mustek MDC 3000
-0x08ca 0x2062 Aiptek PocketDV 5700
-0x052b 0x1a18 Chiphead Megapix V12
-0x04c8 0x0729 Konica Revio 2
-0x04f2 0xa208 Creative PC-CAM 850
-0x0784 0x0040 Traveler Slimline X5
-0x06d6 0x0034 Trust Powerc@m 750
-0x0a17 0x0062 Pentax Optio 50L
-0x06d6 0x003b Trust Powerc@m 970Z
-0x0a17 0x004e Pentax Optio 50
-0x041e 0x405d Creative DiVi CAM 516
-0x08ca 0x2102 Aiptek DV T300
-0x06d6 0x003d Trust Powerc@m 910Z
projects / deliverable / linux.git / commitdiff
