redonkable/alistair23-linux
redonkable/alistair23-linux
1
0
Fork 0
Code Releases Activity

[media] Documentation/media: Remove docs for obsoleted and removed v4l1 drivers

Browse source 
When the v4l1 drivers were removed, there docs were forgotten.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This commit is contained in:
Hans de Goede 2012-11-29 07:06:22 -03:00 committed by Mauro Carvalho Chehab
parent 7a29ee2e37
commit 23e8321624
8 changed files with 0 additions and 1773 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

315
Documentation/video4linux/et61x251.txt
View file

@ -1,315 +0,0 @@
ET61X[12]51 PC Camera Controllers
Driver for Linux
=================================
- Documentation -
Index
=====
1. Copyright
2. Disclaimer
3. License
4. Overview and features
5. Module dependencies
6. Module loading
7. Module parameters
8. Optional device control through "sysfs"
9. Supported devices
10. Notes for V4L2 application developers
11. Contact information
1. Copyright
============
Copyright (C) 2006-2007 by Luca Risolia <luca.risolia@studio.unibo.it>
2. Disclaimer
=============
Etoms is a trademark of Etoms Electronics Corp.
This software is not developed or sponsored by Etoms Electronics.
3. 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.
4. Overview and features
========================
This driver supports the video interface of the devices mounting the ET61X151
or ET61X251 PC Camera Controllers.
It's worth to note that Etoms Electronics has never collaborated with the
author during the development of this project; despite several requests,
Etoms Electronics also refused to release enough detailed specifications of
the video compression engine.
The driver relies on the Video4Linux2 and USB core modules. It has been
designed to run properly on SMP systems as well.
The latest version of the ET61X[12]51 driver can be found at the following URL:
http://www.linux-projects.org/
Some of the features of the driver are:
- full compliance with the Video4Linux2 API (see also "Notes for V4L2
application developers" paragraph);
- available mmap or read/poll methods for video streaming through isochronous
data transfers;
- automatic detection of image sensor;
- support for any window resolutions and optional panning within the maximum
pixel area of image sensor;
- image downscaling with arbitrary scaling factors from 1 and 2 in both
directions (see "Notes for V4L2 application developers" paragraph);
- two different video formats for uncompressed or compressed data in low or
high compression quality (see also "Notes for V4L2 application developers"
paragraph);
- full support for the capabilities of every possible image sensors that can
be connected to the ET61X[12]51 bridges, including, for instance, red, green,
blue and global gain adjustments and exposure control (see "Supported
devices" paragraph for details);
- use of default color settings for sunlight conditions;
- dynamic I/O interface for both ET61X[12]51 and image sensor control (see
"Optional device control through 'sysfs'" paragraph);
- dynamic driver control thanks to various module parameters (see "Module
parameters" paragraph);
- up to 64 cameras can be handled at the same time; they can be connected and
disconnected from the host many times without turning off the computer, if
the system supports hotplugging;
- no known bugs.
5. Module dependencies
======================
For it to work properly, the driver needs kernel support for Video4Linux and
USB.
The following options of the kernel configuration file must be enabled and
corresponding modules must be compiled:
# Multimedia devices
#
CONFIG_VIDEO_DEV=m
To enable advanced debugging functionality on the device through /sysfs:
# Multimedia devices
#
CONFIG_VIDEO_ADV_DEBUG=y
# USB support
#
CONFIG_USB=m
In addition, depending on the hardware being used, the modules below are
necessary:
# USB Host Controller Drivers
#
CONFIG_USB_EHCI_HCD=m
CONFIG_USB_UHCI_HCD=m
CONFIG_USB_OHCI_HCD=m
And finally:
# USB Multimedia devices
#
CONFIG_USB_ET61X251=m
6. Module loading
=================
To use the driver, it is necessary to load the "et61x251" module into memory
after every other module required: "videodev", "v4l2_common", "compat_ioctl32",
"usbcore" and, depending on the USB host controller you have, "ehci-hcd",
"uhci-hcd" or "ohci-hcd".
Loading can be done as shown below:
[root@localhost home]# modprobe et61x251
At this point the devices should be recognized. You can invoke "dmesg" to
analyze kernel messages and verify that the loading process has gone well:
[user@localhost home]$ dmesg
7. Module parameters
====================
Module parameters are listed below:
-------------------------------------------------------------------------------
Name: video_nr
Type: short array (min = 0, max = 64)
Syntax: <-1|n[,...]>
Description: Specify V4L2 minor mode number:
-1 = use next available
n = use minor number n
You can specify up to 64 cameras this way.
For example:
video_nr=-1,2,-1 would assign minor number 2 to the second
registered camera and use auto for the first one and for every
other camera.
Default: -1
-------------------------------------------------------------------------------
Name: force_munmap
Type: bool array (min = 0, max = 64)
Syntax: <0|1[,...]>
Description: Force the application to unmap previously mapped buffer memory
before calling any VIDIOC_S_CROP or VIDIOC_S_FMT ioctl's. Not
all the applications support this feature. This parameter is
specific for each detected camera.
0 = do not force memory unmapping
1 = force memory unmapping (save memory)
Default: 0
-------------------------------------------------------------------------------
Name: frame_timeout
Type: uint array (min = 0, max = 64)
Syntax: <n[,...]>
Description: Timeout for a video frame in seconds. This parameter is
specific for each detected camera. This parameter can be
changed at runtime thanks to the /sys filesystem interface.
Default: 2
-------------------------------------------------------------------------------
Name: debug
Type: ushort
Syntax: <n>
Description: Debugging information level, from 0 to 3:
0 = none (use carefully)
1 = critical errors
2 = significant information
3 = more verbose messages
Level 3 is useful for testing only, when only one device
is used at the same time. It also shows some more information
about the hardware being detected. This module parameter can be
changed at runtime thanks to the /sys filesystem interface.
Default: 2
-------------------------------------------------------------------------------
8. Optional device control through "sysfs"
==========================================
If the kernel has been compiled with the CONFIG_VIDEO_ADV_DEBUG option enabled,
it is possible to read and write both the ET61X[12]51 and the image sensor
registers by using the "sysfs" filesystem interface.
There are four files in the /sys/class/video4linux/videoX directory for each
registered camera: "reg", "val", "i2c_reg" and "i2c_val". The first two files
control the ET61X[12]51 bridge, while the other two control the sensor chip.
"reg" and "i2c_reg" hold the values of the current register index where the
following reading/writing operations are addressed at through "val" and
"i2c_val". Their use is not intended for end-users, unless you know what you
are doing. Remember that you must be logged in as root before writing to them.
As an example, suppose we were to want to read the value contained in the
register number 1 of the sensor register table - which is usually the product
identifier - of the camera registered as "/dev/video0":
[root@localhost #] cd /sys/class/video4linux/video0
[root@localhost #] echo 1 > i2c_reg
[root@localhost #] cat i2c_val
Note that if the sensor registers cannot be read, "cat" will fail.
To avoid race conditions, all the I/O accesses to the files are serialized.
9. Supported devices
====================
None of the names of the companies as well as their products will be mentioned
here. They have never collaborated with the author, so no advertising.
From the point of view of a driver, what unambiguously identify a device are
its vendor and product USB identifiers. Below is a list of known identifiers of
devices mounting the ET61X[12]51 PC camera controllers:
Vendor ID Product ID
--------- ----------
0x102c 0x6151
0x102c 0x6251
0x102c 0x6253
0x102c 0x6254
0x102c 0x6255
0x102c 0x6256
0x102c 0x6257
0x102c 0x6258
0x102c 0x6259
0x102c 0x625a
0x102c 0x625b
0x102c 0x625c
0x102c 0x625d
0x102c 0x625e
0x102c 0x625f
0x102c 0x6260
0x102c 0x6261
0x102c 0x6262
0x102c 0x6263
0x102c 0x6264
0x102c 0x6265
0x102c 0x6266
0x102c 0x6267
0x102c 0x6268
0x102c 0x6269
The following image sensors are supported:
Model Manufacturer
----- ------------
TAS5130D1B Taiwan Advanced Sensor Corporation
All the available control settings of each image sensor are supported through
the V4L2 interface.
10. Notes for V4L2 application developers
=========================================
This driver follows the V4L2 API specifications. In particular, it enforces two
rules:
- exactly one I/O method, either "mmap" or "read", is associated with each
file descriptor. Once it is selected, the application must close and reopen the
device to switch to the other I/O method;
- although it is not mandatory, previously mapped buffer memory should always
be unmapped before calling any "VIDIOC_S_CROP" or "VIDIOC_S_FMT" ioctl's.
The same number of buffers as before will be allocated again to match the size
of the new video frames, so you have to map the buffers again before any I/O
attempts on them.
Consistently with the hardware limits, this driver also supports image
downscaling with arbitrary scaling factors from 1 and 2 in both directions.
However, the V4L2 API specifications don't correctly define how the scaling
factor can be chosen arbitrarily by the "negotiation" of the "source" and
"target" rectangles. To work around this flaw, we have added the convention
that, during the negotiation, whenever the "VIDIOC_S_CROP" ioctl is issued, the
scaling factor is restored to 1.
This driver supports two different video formats: the first one is the "8-bit
Sequential Bayer" format and can be used to obtain uncompressed video data
from the device through the current I/O method, while the second one provides
"raw" compressed video data (without frame headers not related to the
compressed data). The current compression quality may vary from 0 to 1 and can
be selected or queried thanks to the VIDIOC_S_JPEGCOMP and VIDIOC_G_JPEGCOMP
V4L2 ioctl's.
11. Contact information
=======================
The author may be contacted by e-mail at <luca.risolia@studio.unibo.it>.
GPG/PGP encrypted e-mail's are accepted. The GPG key ID of the author is
'FCE635A4'; the public 1024-bit key should be available at any keyserver;
the fingerprint is: '88E8 F32F 7244 68BA 3958 5D40 99DA 5D2A FCE6 35A4'.

323
Documentation/video4linux/ibmcam.txt
View file

@ -1,323 +0,0 @@
README for Linux device driver for the IBM "C-It" USB video camera
INTRODUCTION:
This driver does not use all features known to exist in
the IBM camera. However most of needed features work well.
This driver was developed using logs of observed USB traffic
which was produced by standard Windows driver (c-it98.sys).
I did not have data sheets from Xirlink.
Video formats:
128x96 [model 1]
176x144
320x240 [model 2]
352x240 [model 2]
352x288
Frame rate: 3 - 30 frames per second (FPS)
External interface: USB
Internal interface: Video For Linux (V4L)
Supported controls:
- by V4L: Contrast, Brightness, Color, Hue
- by driver options: frame rate, lighting conditions, video format,
default picture settings, sharpness.
SUPPORTED CAMERAS:
Xirlink "C-It" camera, also known as "IBM PC Camera".
The device uses proprietary ASIC (and compression method);
it is manufactured by Xirlink. See http://xirlinkwebcam.sourceforge.net,
http://www.ibmpccamera.com, or http://www.c-itnow.com/ for details and pictures.
This very chipset ("X Chip", as marked at the factory)
is used in several other cameras, and they are supported
as well:
- IBM NetCamera
- Veo Stingray
The Linux driver was developed with camera with following
model number (or FCC ID): KSX-XVP510. This camera has three
interfaces, each with one endpoint (control, iso, iso). This
type of cameras is referred to as "model 1". These cameras are
no longer manufactured.
Xirlink now manufactures new cameras which are somewhat different.
In particular, following models [FCC ID] belong to that category:
XVP300 [KSX-X9903]
XVP600 [KSX-X9902]
XVP610 [KSX-X9902]
(see http://www.xirlink.com/ibmpccamera/ for updates, they refer
to these new cameras by Windows driver dated 12-27-99, v3005 BETA)
These cameras have two interfaces, one endpoint in each (iso, bulk).
Such type of cameras is referred to as "model 2". They are supported
(with exception of 352x288 native mode).
Some IBM NetCameras (Model 4) are made to generate only compressed
video streams. This is great for performance, but unfortunately
nobody knows how to decompress the stream :-( Therefore, these
cameras are *unsupported* and if you try to use one of those, all
you get is random colored horizontal streaks, not the image!
If you have one of those cameras, you probably should return it
to the store and get something that is supported.
Tell me more about all that "model" business
--------------------------------------------
I just invented model numbers to uniquely identify flavors of the
hardware/firmware that were sold. It was very confusing to use
brand names or some other internal numbering schemes. So I found
by experimentation that all Xirlink chipsets fall into four big
classes, and I called them "models". Each model is programmed in
its own way, and each model sends back the video in its own way.
Quirks of Model 2 cameras:
-------------------------
Model 2 does not have hardware contrast control. Corresponding V4L
control is implemented in software, which is not very nice to your
CPU, but at least it works.
This driver provides 352x288 mode by switching the camera into
quasi-352x288 RGB mode (800 Kbits per frame) essentially limiting
this mode to 10 frames per second or less, in ideal conditions on
the bus (USB is shared, after all). The frame rate
has to be programmed very conservatively. Additional concern is that
frame rate depends on brightness setting; therefore the picture can
be good at one brightness and broken at another! I did not want to fix
the frame rate at slowest setting, but I had to move it pretty much down
the scale (so that framerate option barely matters). I also noticed that
camera after first powering up produces frames slightly faster than during
consecutive uses. All this means that if you use 352x288 (which is
default), be warned - you may encounter broken picture on first connect;
try to adjust brightness - brighter image is slower, so USB will be able
to send all data. However if you regularly use Model 2 cameras you may
prefer 176x144 which makes perfectly good I420, with no scaling and
lesser demands on USB (300 Kbits per second, or 26 frames per second).
Another strange effect of 352x288 mode is the fine vertical grid visible
on some colored surfaces. I am sure it is caused by me not understanding
what the camera is trying to say. Blame trade secrets for that.
The camera that I had also has a hardware quirk: if disconnected,
it needs few minutes to "relax" before it can be plugged in again
(poorly designed USB processor reset circuit?)
[Veo Stingray with Product ID 0x800C is also Model 2, but I haven't
observed this particular flaw in it.]
Model 2 camera can be programmed for very high sensitivity (even starlight
may be enough), this makes it convenient for tinkering with. The driver
code has enough comments to help a programmer to tweak the camera
as s/he feels necessary.
WHAT YOU NEED:
- A supported IBM PC (C-it) camera (model 1 or 2)
- A Linux box with USB support (2.3/2.4; 2.2 w/backport may work)
- A Video4Linux compatible frame grabber program such as xawtv.
HOW TO COMPILE THE DRIVER:
You need to compile the driver only if you are a developer
or if you want to make changes to the code. Most distributions
precompile all modules, so you can go directly to the next
section "HOW TO USE THE DRIVER".
The ibmcam driver uses usbvideo helper library (module),
so if you are studying the ibmcam code you will be led there.
The driver itself consists of only one file in usb/ directory:
ibmcam.c. This file is included into the Linux kernel build
process if you configure the kernel for CONFIG_USB_IBMCAM.
Run "make xconfig" and in USB section you will find the IBM
camera driver. Select it, save the configuration and recompile.
HOW TO USE THE DRIVER:
I recommend to compile driver as a module. This gives you an
easier access to its configuration. The camera has many more
settings than V4L can operate, so some settings are done using
module options.
To begin with, on most modern Linux distributions the driver
will be automatically loaded whenever you plug the supported
camera in. Therefore, you don't need to do anything. However
if you want to experiment with some module parameters then
you can load and unload the driver manually, with camera
plugged in or unplugged.
Typically module is installed with command 'modprobe', like this:
# modprobe ibmcam framerate=1
Alternatively you can use 'insmod' in similar fashion:
# insmod /lib/modules/2.x.y/usb/ibmcam.o framerate=1
Module can be inserted with camera connected or disconnected.
The driver can have options, though some defaults are provided.
Driver options: (* indicates that option is model-dependent)
Name Type Range [default] Example
-------------- -------------- -------------- ------------------
debug Integer 0-9 [0] debug=1
flags Integer 0-0xFF [0] flags=0x0d
framerate Integer 0-6 [2] framerate=1
hue_correction Integer 0-255 [128] hue_correction=115
init_brightness Integer 0-255 [128] init_brightness=100
init_contrast Integer 0-255 [192] init_contrast=200
init_color Integer 0-255 [128] init_color=130
init_hue Integer 0-255 [128] init_hue=115
lighting Integer 0-2* [1] lighting=2
sharpness Integer 0-6* [4] sharpness=3
size Integer 0-2* [2] size=1
Options for Model 2 only:
Name Type Range [default] Example
-------------- -------------- -------------- ------------------
init_model2_rg Integer 0..255 [0x70] init_model2_rg=128
init_model2_rg2 Integer 0..255 [0x2f] init_model2_rg2=50
init_model2_sat Integer 0..255 [0x34] init_model2_sat=65
init_model2_yb Integer 0..255 [0xa0] init_model2_yb=200
debug You don't need this option unless you are a developer.
If you are a developer then you will see in the code
what values do what. 0=off.
flags This is a bit mask, and you can combine any number of
bits to produce what you want. Usually you don't want
any of extra features this option provides:
FLAGS_RETRY_VIDIOCSYNC 1 This bit allows to retry failed
VIDIOCSYNC ioctls without failing.
Will work with xawtv, will not
with xrealproducer. Default is
not set.
FLAGS_MONOCHROME 2 Activates monochrome (b/w) mode.
FLAGS_DISPLAY_HINTS 4 Shows colored pixels which have
magic meaning to developers.
FLAGS_OVERLAY_STATS 8 Shows tiny numbers on screen,
useful only for debugging.
FLAGS_FORCE_TESTPATTERN 16 Shows blue screen with numbers.
FLAGS_SEPARATE_FRAMES 32 Shows each frame separately, as
it was received from the camera.
Default (not set) is to mix the
preceding frame in to compensate
for occasional loss of Isoc data
on high frame rates.
FLAGS_CLEAN_FRAMES 64 Forces "cleanup" of each frame
prior to use; relevant only if
FLAGS_SEPARATE_FRAMES is set.
Default is not to clean frames,
this is a little faster but may
produce flicker if frame rate is
too high and Isoc data gets lost.
FLAGS_NO_DECODING 128 This flag turns the video stream
decoder off, and dumps the raw
Isoc data from the camera into
the reading process. Useful to
developers, but not to users.
framerate This setting controls frame rate of the camera. This is
an approximate setting (in terms of "worst" ... "best")
because camera changes frame rate depending on amount
of light available. Setting 0 is slowest, 6 is fastest.
Beware - fast settings are very demanding and may not
work well with all video sizes. Be conservative.
hue_correction This highly optional setting allows to adjust the
hue of the image in a way slightly different from
what usual "hue" control does. Both controls affect
YUV colorspace: regular "hue" control adjusts only
U component, and this "hue_correction" option similarly
adjusts only V component. However usually it is enough
to tweak only U or V to compensate for colored light or
color temperature; this option simply allows more
complicated correction when and if it is necessary.
init_brightness These settings specify _initial_ values which will be
init_contrast used to set up the camera. If your V4L application has
init_color its own controls to adjust the picture then these
init_hue controls will be used too. These options allow you to
preconfigure the camera when it gets connected, before
any V4L application connects to it. Good for webcams.
init_model2_rg These initial settings alter color balance of the
init_model2_rg2 camera on hardware level. All four settings may be used
init_model2_sat to tune the camera to specific lighting conditions. These
init_model2_yb settings only apply to Model 2 cameras.
lighting This option selects one of three hardware-defined
photosensitivity settings of the camera. 0=bright light,
1=Medium (default), 2=Low light. This setting affects
frame rate: the dimmer the lighting the lower the frame
rate (because longer exposition time is needed). The
Model 2 cameras allow values more than 2 for this option,
thus enabling extremely high sensitivity at cost of frame
rate, color saturation and imaging sensor noise.
sharpness This option controls smoothing (noise reduction)
made by camera. Setting 0 is most smooth, setting 6
is most sharp. Be aware that CMOS sensor used in the
camera is pretty noisy, so if you choose 6 you will
be greeted with "snowy" image. Default is 4. Model 2
cameras do not support this feature.
size This setting chooses one of several image sizes that are
supported by this driver. Cameras may support more, but
it's difficult to reverse-engineer all formats.
Following video sizes are supported:
size=0 128x96 (Model 1 only)
size=1 160x120
size=2 176x144
size=3 320x240 (Model 2 only)
size=4 352x240 (Model 2 only)
size=5 352x288
size=6 640x480 (Model 3 only)
The 352x288 is the native size of the Model 1 sensor
array, so it's the best resolution the camera can
yield. The best resolution of Model 2 is 176x144, and
larger images are produced by stretching the bitmap.
Model 3 has sensor with 640x480 grid, and it works too,
but the frame rate will be exceptionally low (1-2 FPS);
it may be still OK for some applications, like security.
Choose the image size you need. The smaller image can
support faster frame rate. Default is 352x288.
For more information and the Troubleshooting FAQ visit this URL:
http://www.linux-usb.org/ibmcam/
WHAT NEEDS TO BE DONE:
- The button on the camera is not used. I don't know how to get to it.
I know now how to read button on Model 2, but what to do with it?
- Camera reports its status back to the driver; however I don't know
what returned data means. If camera fails at some initialization
stage then something should be done, and I don't do that because
I don't even know that some command failed. This is mostly Model 1
concern because Model 2 uses different commands which do not return
status (and seem to complete successfully every time).
- Some flavors of Model 4 NetCameras produce only compressed video
streams, and I don't know how to decode them.
CREDITS:
The code is based in no small part on the CPiA driver by Johannes Erdfelt,
Randy Dunlap, and others. Big thanks to them for their pioneering work on that
and the USB stack.
I also thank John Lightsey for his donation of the Veo Stingray camera.

12
Documentation/video4linux/m5602.txt
View file

@ -1,12 +0,0 @@
This document describes the ALi m5602 bridge connected
to the following supported sensors:
OmniVision OV9650,
Samsung s5k83a,
Samsung s5k4aa,
Micron mt9m111,
Pixel plus PO1030
This driver mimics the windows drivers, which have a braindead implementation sending bayer-encoded frames at VGA resolution.
In a perfect world we should be able to reprogram the m5602 and the connected sensor in hardware instead, supporting a range of resolutions and pixelformats
Anyway, have fun and please report any bugs to m560x-driver-devel@lists.sourceforge.net

288
Documentation/video4linux/ov511.txt
View file

@ -1,288 +0,0 @@
-------------------------------------------------------------------------------
Readme for Linux device driver for the OmniVision OV511 USB to camera bridge IC
-------------------------------------------------------------------------------
Author: Mark McClelland
Homepage: http://alpha.dyndns.org/ov511
INTRODUCTION:
This is a driver for the OV511, a USB-only chip used in many "webcam" devices.
Any camera using the OV511/OV511+ and the OV6620/OV7610/20/20AE should work.
Video capture devices that use the Philips SAA7111A decoder also work. It
supports streaming and capture of color or monochrome video via the Video4Linux
API. Most V4L apps are compatible with it. Most resolutions with a width and
height that are a multiple of 8 are supported.
If you need more information, please visit the OV511 homepage at the above URL.
WHAT YOU NEED:
- If you want to help with the development, get the chip's specification docs at
http://www.ovt.com/omniusbp.html
- A Video4Linux compatible frame grabber program (I recommend vidcat and xawtv)
vidcat is part of the w3cam package: http://mpx.freeshell.net/
xawtv is available at: http://linux.bytesex.org/xawtv/
HOW TO USE IT:
Note: These are simplified instructions. For complete instructions see:
http://alpha.dyndns.org/ov511/install.html
You must have first compiled USB support, support for your specific USB host
controller (UHCI or OHCI), and Video4Linux support for your kernel (I recommend
making them modules.) Make sure "Enforce bandwidth allocation" is NOT enabled.
Next, (as root):
modprobe usbcore
modprobe usb-uhci <OR> modprobe usb-ohci
modprobe videodev
modprobe ov511
If it is not already there (it usually is), create the video device:
mknod /dev/video0 c 81 0
Optionally, symlink /dev/video to /dev/video0
You will have to set permissions on this device to allow you to read/write
from it:
chmod 666 /dev/video
chmod 666 /dev/video0 (if necessary)
Now you are ready to run a video app! Both vidcat and xawtv work well for me
at 640x480.
[Using vidcat:]
vidcat -s 640x480 -p c > test.jpg
xview test.jpg
[Using xawtv:]
From the main xawtv directory:
make clean
./configure
make
make install
Now you should be able to run xawtv. Right click for the options dialog.
MODULE PARAMETERS:
You can set these with: insmod ov511 NAME=VALUE
There is currently no way to set these on a per-camera basis.
NAME: autobright
TYPE: integer (Boolean)
DEFAULT: 1
DESC: Brightness is normally under automatic control and can't be set
manually by the video app. Set to 0 for manual control.
NAME: autogain
TYPE: integer (Boolean)
DEFAULT: 1
DESC: Auto Gain Control enable. This feature is not yet implemented.
NAME: autoexp
TYPE: integer (Boolean)
DEFAULT: 1
DESC: Auto Exposure Control enable. This feature is not yet implemented.
NAME: debug
TYPE: integer (0-6)
DEFAULT: 3
DESC: Sets the threshold for printing debug messages. The higher the value,
the more is printed. The levels are cumulative, and are as follows:
0=no debug messages
1=init/detection/unload and other significant messages
2=some warning messages
3=config/control function calls
4=most function calls and data parsing messages
5=highly repetitive mesgs
NAME: snapshot
TYPE: integer (Boolean)
DEFAULT: 0
DESC: Set to 1 to enable snapshot mode. read()/VIDIOCSYNC will block until
the snapshot button is pressed. Note: enabling this mode disables
/proc/video/ov511/<minor#>/button
NAME: cams
TYPE: integer (1-4 for OV511, 1-31 for OV511+)
DEFAULT: 1
DESC: Number of cameras allowed to stream simultaneously on a single bus.
Values higher than 1 reduce the data rate of each camera, allowing two
or more to be used at once. If you have a complicated setup involving
both OV511 and OV511+ cameras, trial-and-error may be necessary for
finding the optimum setting.
NAME: compress
TYPE: integer (Boolean)
DEFAULT: 0
DESC: Set this to 1 to turn on the camera's compression engine. This can
potentially increase the frame rate at the expense of quality, if you
have a fast CPU. You must load the proper compression module for your
camera before starting your application (ov511_decomp or ov518_decomp).
NAME: testpat
TYPE: integer (Boolean)
DEFAULT: 0
DESC: This configures the camera's sensor to transmit a colored test-pattern
instead of an image. This does not work correctly yet.
NAME: dumppix
TYPE: integer (0-2)
DEFAULT: 0
DESC: Dumps raw pixel data and skips post-processing and format conversion.
It is for debugging purposes only. Options are:
0: Disable (default)
1: Dump raw data from camera, excluding headers and trailers
2: Dumps data exactly as received from camera
NAME: led
TYPE: integer (0-2)
DEFAULT: 1 (Always on)
DESC: Controls whether the LED (the little light) on the front of the camera
is always off (0), always on (1), or only on when driver is open (2).
This is not supported with the OV511, and might only work with certain
cameras (ones that actually have the LED wired to the control pin, and
not just hard-wired to be on all the time).
NAME: dump_bridge
TYPE: integer (Boolean)
DEFAULT: 0
DESC: Dumps the bridge (OV511[+] or OV518[+]) register values to the system
log. Only useful for serious debugging/development purposes.
NAME: dump_sensor
TYPE: integer (Boolean)
DEFAULT: 0
DESC: Dumps the sensor register values to the system log. Only useful for
serious debugging/development purposes.
NAME: printph
TYPE: integer (Boolean)
DEFAULT: 0
DESC: Setting this to 1 will dump the first 12 bytes of each isoc frame. This
is only useful if you are trying to debug problems with the isoc data
stream (i.e.: camera initializes, but vidcat hangs until Ctrl-C). Be
warned that this dumps a large number of messages to your kernel log.
NAME: phy, phuv, pvy, pvuv, qhy, qhuv, qvy, qvuv
TYPE: integer (0-63 for phy and phuv, 0-255 for rest)
DEFAULT: OV511 default values
DESC: These are registers 70h - 77h of the OV511, which control the
prediction ranges and quantization thresholds of the compressor, for
the Y and UV channels in the horizontal and vertical directions. See
the OV511 or OV511+ data sheet for more detailed descriptions. These
normally do not need to be changed.
NAME: lightfreq
TYPE: integer (0, 50, or 60)
DEFAULT: 0 (use sensor default)
DESC: Sets the sensor to match your lighting frequency. This can reduce the
appearance of "banding", i.e. horizontal lines or waves of light and
dark that are often caused by artificial lighting. Valid values are:
0 - Use default (depends on sensor, most likely 60 Hz)
50 - For European and Asian 50 Hz power
60 - For American 60 Hz power
NAME: bandingfilter
TYPE: integer (Boolean)
DEFAULT: 0 (off)
DESC: Enables the sensor´s banding filter exposure algorithm. This reduces
or stabilizes the "banding" caused by some artificial light sources
(especially fluorescent). You might have to set lightfreq correctly for
this to work right. As an added bonus, this sometimes makes it
possible to capture your monitor´s output.
NAME: fastset
TYPE: integer (Boolean)
DEFAULT: 0 (off)
DESC: Allows picture settings (brightness, contrast, color, and hue) to take
effect immediately, even in the middle of a frame. This reduces the
time to change settings, but can ruin frames during the change. Only
affects OmniVision sensors.
NAME: force_palette
TYPE: integer (Boolean)
DEFAULT: 0 (off)
DESC: Forces the palette (color format) to a specific value. If an
application requests a different palette, it will be rejected, thereby
forcing it to try others until it succeeds. This is useful for forcing
greyscale mode with a color camera, for example. Supported modes are:
0 (Allows all the following formats)
1 VIDEO_PALETTE_GREY (Linear greyscale)
10 VIDEO_PALETTE_YUV420 (YUV 4:2:0 Planar)
15 VIDEO_PALETTE_YUV420P (YUV 4:2:0 Planar, same as 10)
NAME: backlight
TYPE: integer (Boolean)
DEFAULT: 0 (off)
DESC: Setting this flag changes the exposure algorithm for OmniVision sensors
such that objects in the camera's view (i.e. your head) can be clearly
seen when they are illuminated from behind. It reduces or eliminates
the sensor's auto-exposure function, so it should only be used when
needed. Additionally, it is only supported with the OV6620 and OV7620.
NAME: unit_video
TYPE: Up to 16 comma-separated integers
DEFAULT: 0,0,0... (automatically assign the next available minor(s))
DESC: You can specify up to 16 minor numbers to be assigned to ov511 devices.
For example, "unit_video=1,3" will make the driver use /dev/video1 and
/dev/video3 for the first two devices it detects. Additional devices
will be assigned automatically starting at the first available device
node (/dev/video0 in this case). Note that you cannot specify 0 as a
minor number. This feature requires kernel version 2.4.5 or higher.
NAME: remove_zeros
TYPE: integer (Boolean)
DEFAULT: 0 (do not skip any incoming data)
DESC: Setting this to 1 will remove zero-padding from incoming data. This
will compensate for the blocks of corruption that can appear when the
camera cannot keep up with the speed of the USB bus (eg. at low frame
resolutions). This feature is always enabled when compression is on.
NAME: mirror
TYPE: integer (Boolean)
DEFAULT: 0 (off)
DESC: Setting this to 1 will reverse ("mirror") the image horizontally. This
might be necessary if your camera has a custom lens assembly. This has
no effect with video capture devices.
NAME: ov518_color
TYPE: integer (Boolean)
DEFAULT: 0 (off)
DESC: Enable OV518 color support. This is off by default since it doesn't
work most of the time. If you want to try it, you must also load
ov518_decomp with the "nouv=0" parameter. If you get improper colors or
diagonal lines through the image, restart your video app and try again.
Repeat as necessary.
WORKING FEATURES:
o Color streaming/capture at most widths and heights that are multiples of 8.
o Monochrome (use force_palette=1 to enable)
o Setting/getting of saturation, contrast, brightness, and hue (only some of
them work the OV7620 and OV7620AE)
o /proc status reporting
o SAA7111A video capture support at 320x240 and 640x480
o Compression support
o SMP compatibility
HOW TO CONTACT ME:
You can email me at mark@alpha.dyndns.org . Please prefix the subject line
with "OV511: " so that I am certain to notice your message.
CREDITS:
The code is based in no small part on the CPiA driver by Johannes Erdfelt,
Randy Dunlap, and others. Big thanks to them for their pioneering work on that
and the USB stack. Thanks to Bret Wallach for getting camera reg IO, ISOC, and
image capture working. Thanks to Orion Sky Lawlor, Kevin Moore, and Claudio
Matsuoka for their work as well.

54
Documentation/video4linux/se401.txt
View file

@ -1,54 +0,0 @@
Linux driver for SE401 based USB cameras
Copyright, 2001, Jeroen Vreeken
INTRODUCTION:
The SE401 chip is the used in low-cost usb webcams.
It is produced by Endpoints Inc. (www.endpoints.com).
It interfaces directly to a cmos image sensor and USB. The only other major
part in a se401 based camera is a dram chip.
The following cameras are known to work with this driver:
Aox se401 (non-branded) cameras
Philips PVCV665 USB VGA webcam 'Vesta Fun'
Kensington VideoCAM PC Camera Model 67014
Kensington VideoCAM PC Camera Model 67015
Kensington VideoCAM PC Camera Model 67016
Kensington VideoCAM PC Camera Model 67017
WHAT YOU NEED:
- USB support
- VIDEO4LINUX support
More information about USB support for linux can be found at:
http://www.linux-usb.org
MODULE OPTIONS:
When the driver is compiled as a module you can also use the 'flickerless'
option. With it exposure is limited to values that do not interfere with the
net frequency. Valid options for this option are 0, 50 and 60. (0=disable,
50=50hz, 60=60hz)
KNOWN PROBLEMS:
The driver works fine with the usb-ohci and uhci host controller drivers,
the default settings also work with usb-uhci. But sending more than one bulk
transfer at a time with usb-uhci doesn't work yet.
Users of usb-ohci and uhci can safely enlarge SE401_NUMSBUF in se401.h in
order to increase the throughput (and thus framerate).
HELP:
The latest info on this driver can be found at:
http://members.chello.nl/~j.vreeken/se401/
And questions to me can be send to:
pe1rxq@amsat.org

53
Documentation/video4linux/stv680.txt
View file

@ -1,53 +0,0 @@
Linux driver for STV0680 based USB cameras
Copyright, 2001, Kevin Sisson
INTRODUCTION:
STMicroelectronics produces the STV0680B chip, which comes in two
types, -001 and -003. The -003 version allows the recording and downloading
of sound clips from the camera, and allows a flash attachment. Otherwise,
it uses the same commands as the -001 version. Both versions support a
variety of SDRAM sizes and sensors, allowing for a maximum of 26 VGA or 20
CIF pictures. The STV0680 supports either a serial or a usb interface, and
video is possible through the usb interface.
The following cameras are known to work with this driver, although any
camera with Vendor/Product codes of 0553/0202 should work:
Aiptek Pencam (various models)
Nisis QuickPix 2
Radio Shack 'Kid's digital camera' (#60-1207)
At least one Trust Spycam model
Several other European brand models
WHAT YOU NEED:
- USB support
- VIDEO4LINUX support
More information about USB support for linux can be found at:
http://www.linux-usb.org
MODULE OPTIONS:
When the driver is compiled as a module, you can set a "swapRGB=1"
option, if necessary, for those applications that require it
(such as xawtv). However, the driver should detect and set this
automatically, so this option should not normally be used.
KNOWN PROBLEMS:
The driver seems to work better with the usb-ohci than the usb-uhci host
controller driver.
HELP:
The latest info on this driver can be found at:
http://personal.clt.bellsouth.net/~kjsisson or at
http://stv0680-usb.sourceforge.net
Any questions to me can be send to: kjsisson@bellsouth.net

458
Documentation/video4linux/w9968cf.txt
View file

@ -1,458 +0,0 @@
W996[87]CF JPEG USB Dual Mode Camera Chip
Driver for Linux 2.6 (basic version)
=========================================
- Documentation -
Index
=====
1. Copyright
2. Disclaimer
3. License
4. Overview
5. Supported devices
6. Module dependencies
7. Module loading
8. Module parameters
9. Contact information
10. Credits
1. Copyright
============
Copyright (C) 2002-2004 by Luca Risolia <luca.risolia@studio.unibo.it>
2. Disclaimer
=============
Winbond is a trademark of Winbond Electronics Corporation.
This software is not sponsored or developed by Winbond.
3. 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.
4. Overview
===========
This driver supports the video streaming capabilities of the devices mounting
Winbond W9967CF and Winbond W9968CF JPEG USB Dual Mode Camera Chips. OV681
based cameras should be supported as well.
The driver is divided into two modules: the basic one, "w9968cf", is needed for
the supported devices to work; the second one, "w9968cf-vpp", is an optional
module, which provides some useful video post-processing functions like video
decoding, up-scaling and colour conversions.
Note that the official kernels do neither include nor support the second
module for performance purposes. Therefore, it is always recommended to
download and install the latest and complete release of the driver,
replacing the existing one, if present.
The latest and full-featured version of the W996[87]CF driver can be found at:
http://www.linux-projects.org. Please refer to the documentation included in
that package, if you are going to use it.
Up to 32 cameras can be handled at the same time. They can be connected and
disconnected from the host many times without turning off the computer, if
your system supports the hotplug facility.
To change the default settings for each camera, many parameters can be passed
through command line when the module is loaded into memory.
The driver relies on the Video4Linux, USB and I2C core modules. It has been
designed to run properly on SMP systems as well. An additional module,
"ovcamchip", is mandatory; it provides support for some OmniVision image
sensors connected to the W996[87]CF chips; if found in the system, the module
will be automatically loaded by default (provided that the kernel has been
compiled with the automatic module loading option).
5. Supported devices
====================
At the moment, known W996[87]CF and OV681 based devices are:
- Aroma Digi Pen VGA Dual Mode ADG-5000 (unknown image sensor)
- AVerMedia AVerTV USB (SAA7111A, Philips FI1216Mk2 tuner, PT2313L audio chip)
- Creative Labs Video Blaster WebCam Go (OmniVision OV7610 sensor)
- Creative Labs Video Blaster WebCam Go Plus (OmniVision OV7620 sensor)
- Lebon LDC-035A (unknown image sensor)
- Ezonics EZ-802 EZMega Cam (OmniVision OV8610C sensor)
- OmniVision OV8610-EDE (OmniVision OV8610 sensor)
- OPCOM Digi Pen VGA Dual Mode Pen Camera (unknown image sensor)
- Pretec Digi Pen-II (OmniVision OV7620 sensor)
- Pretec DigiPen-480 (OmniVision OV8610 sensor)
If you know any other W996[87]CF or OV681 based cameras, please contact me.
The list above does not imply that all those devices work with this driver: up
until now only webcams that have an image sensor supported by the "ovcamchip"
module work. Kernel messages will always tell you whether this is case.
Possible external microcontrollers of those webcams are not supported: this
means that still images cannot be downloaded from the device memory.
Furthermore, it's worth to note that I was only able to run tests on my
"Creative Labs Video Blaster WebCam Go". Donations of other models, for
additional testing and full support, would be much appreciated.
6. Module dependencies
======================
For it to work properly, the driver needs kernel support for Video4Linux, USB
and I2C, and the "ovcamchip" module for the image sensor. Make sure you are not
actually using any external "ovcamchip" module, given that the W996[87]CF
driver depends on the version of the module present in the official kernels.
The following options of the kernel configuration file must be enabled and
corresponding modules must be compiled:
# Multimedia devices
#
CONFIG_VIDEO_DEV=m
# I2C support
#
CONFIG_I2C=m
The I2C core module can be compiled statically in the kernel as well.
# OmniVision Camera Chip support
#
CONFIG_VIDEO_OVCAMCHIP=m
# USB support
#
CONFIG_USB=m
In addition, depending on the hardware being used, only one of the modules
below is necessary:
# USB Host Controller Drivers
#
CONFIG_USB_EHCI_HCD=m
CONFIG_USB_UHCI_HCD=m
CONFIG_USB_OHCI_HCD=m
And finally:
# USB Multimedia devices
#
CONFIG_USB_W9968CF=m
7. Module loading
=================
To use the driver, it is necessary to load the "w9968cf" module into memory
after every other module required.
Loading can be done this way, from root:
[root@localhost home]# modprobe usbcore
[root@localhost home]# modprobe i2c-core
[root@localhost home]# modprobe videodev
[root@localhost home]# modprobe w9968cf
At this point the pertinent devices should be recognized: "dmesg" can be used
to analyze kernel messages:
[user@localhost home]$ dmesg
There are a lot of parameters the module can use to change the default
settings for each device. To list every possible parameter with a brief
explanation about them and which syntax to use, it is recommended to run the
"modinfo" command:
[root@locahost home]# modinfo w9968cf
8. Module parameters
====================
Module parameters are listed below:
-------------------------------------------------------------------------------
Name: ovmod_load
Type: bool
Syntax: <0|1>
Description: Automatic 'ovcamchip' module loading: 0 disabled, 1 enabled.
If enabled, 'insmod' searches for the required 'ovcamchip'
module in the system, according to its configuration, and
loads that module automatically. This action is performed as
once soon as the 'w9968cf' module is loaded into memory.
Default: 1
-------------------------------------------------------------------------------
Name: simcams
Type: int
Syntax: <n>
Description: Number of cameras allowed to stream simultaneously.
n may vary from 0 to 32.
Default: 32
-------------------------------------------------------------------------------
Name: video_nr
Type: int array (min = 0, max = 32)
Syntax: <-1|n[,...]>
Description: Specify V4L minor mode number.
-1 = use next available
n = use minor number n
You can specify up to 32 cameras this way.
For example:
video_nr=-1,2,-1 would assign minor number 2 to the second
recognized camera and use auto for the first one and for every
other camera.
Default: -1
-------------------------------------------------------------------------------
Name: packet_size
Type: int array (min = 0, max = 32)
Syntax: <n[,...]>
Description: Specify the maximum data payload size in bytes for alternate
settings, for each device. n is scaled between 63 and 1023.
Default: 1023
-------------------------------------------------------------------------------
Name: max_buffers
Type: int array (min = 0, max = 32)
Syntax: <n[,...]>
Description: For advanced users.
Specify the maximum number of video frame buffers to allocate
for each device, from 2 to 32.
Default: 2
-------------------------------------------------------------------------------
Name: double_buffer
Type: bool array (min = 0, max = 32)
Syntax: <0|1[,...]>
Description: Hardware double buffering: 0 disabled, 1 enabled.
It should be enabled if you want smooth video output: if you
obtain out of sync. video, disable it, or try to
decrease the 'clockdiv' module parameter value.
Default: 1 for every device.
-------------------------------------------------------------------------------
Name: clamping
Type: bool array (min = 0, max = 32)
Syntax: <0|1[,...]>
Description: Video data clamping: 0 disabled, 1 enabled.
Default: 0 for every device.
-------------------------------------------------------------------------------
Name: filter_type
Type: int array (min = 0, max = 32)
Syntax: <0|1|2[,...]>
Description: Video filter type.
0 none, 1 (1-2-1) 3-tap filter, 2 (2-3-6-3-2) 5-tap filter.
The filter is used to reduce noise and aliasing artifacts
produced by the CCD or CMOS image sensor.
Default: 0 for every device.
-------------------------------------------------------------------------------
Name: largeview
Type: bool array (min = 0, max = 32)
Syntax: <0|1[,...]>
Description: Large view: 0 disabled, 1 enabled.
Default: 1 for every device.
-------------------------------------------------------------------------------
Name: upscaling
Type: bool array (min = 0, max = 32)
Syntax: <0|1[,...]>
Description: Software scaling (for non-compressed video only):
0 disabled, 1 enabled.
Disable it if you have a slow CPU or you don't have enough
memory.
Default: 0 for every device.
Note: If 'w9968cf-vpp' is not present, this parameter is set to 0.
-------------------------------------------------------------------------------
Name: decompression
Type: int array (min = 0, max = 32)
Syntax: <0|1|2[,...]>
Description: Software video decompression:
0 = disables decompression
(doesn't allow formats needing decompression).
1 = forces decompression
(allows formats needing decompression only).
2 = allows any permitted formats.
Formats supporting (de)compressed video are YUV422P and
YUV420P/YUV420 in any resolutions where width and height are
multiples of 16.
Default: 2 for every device.
Note: If 'w9968cf-vpp' is not present, forcing decompression is not
allowed; in this case this parameter is set to 2.
-------------------------------------------------------------------------------
Name: force_palette
Type: int array (min = 0, max = 32)
Syntax: <0|9|10|13|15|8|7|1|6|3|4|5[,...]>
Description: Force picture palette.
In order:
0 = Off - allows any of the following formats:
9 = UYVY 16 bpp - Original video, compression disabled
10 = YUV420 12 bpp - Original video, compression enabled
13 = YUV422P 16 bpp - Original video, compression enabled
15 = YUV420P 12 bpp - Original video, compression enabled
8 = YUVY 16 bpp - Software conversion from UYVY
7 = YUV422 16 bpp - Software conversion from UYVY
1 = GREY 8 bpp - Software conversion from UYVY
6 = RGB555 16 bpp - Software conversion from UYVY
3 = RGB565 16 bpp - Software conversion from UYVY
4 = RGB24 24 bpp - Software conversion from UYVY
5 = RGB32 32 bpp - Software conversion from UYVY
When not 0, this parameter will override 'decompression'.
Default: 0 for every device. Initial palette is 9 (UYVY).
Note: If 'w9968cf-vpp' is not present, this parameter is set to 9.
-------------------------------------------------------------------------------
Name: force_rgb
Type: bool array (min = 0, max = 32)
Syntax: <0|1[,...]>
Description: Read RGB video data instead of BGR:
1 = use RGB component ordering.
0 = use BGR component ordering.
This parameter has effect when using RGBX palettes only.
Default: 0 for every device.
-------------------------------------------------------------------------------
Name: autobright
Type: bool array (min = 0, max = 32)
Syntax: <0|1[,...]>
Description: Image sensor automatically changes brightness:
0 = no, 1 = yes
Default: 0 for every device.
-------------------------------------------------------------------------------
Name: autoexp
Type: bool array (min = 0, max = 32)
Syntax: <0|1[,...]>
Description: Image sensor automatically changes exposure:
0 = no, 1 = yes
Default: 1 for every device.
-------------------------------------------------------------------------------
Name: lightfreq
Type: int array (min = 0, max = 32)
Syntax: <50|60[,...]>
Description: Light frequency in Hz:
50 for European and Asian lighting, 60 for American lighting.
Default: 50 for every device.
-------------------------------------------------------------------------------
Name: bandingfilter
Type: bool array (min = 0, max = 32)
Syntax: <0|1[,...]>
Description: Banding filter to reduce effects of fluorescent
lighting:
0 disabled, 1 enabled.
This filter tries to reduce the pattern of horizontal
light/dark bands caused by some (usually fluorescent) lighting.
Default: 0 for every device.
-------------------------------------------------------------------------------
Name: clockdiv
Type: int array (min = 0, max = 32)
Syntax: <-1|n[,...]>
Description: Force pixel clock divisor to a specific value (for experts):
n may vary from 0 to 127.
-1 for automatic value.
See also the 'double_buffer' module parameter.
Default: -1 for every device.
-------------------------------------------------------------------------------
Name: backlight
Type: bool array (min = 0, max = 32)
Syntax: <0|1[,...]>
Description: Objects are lit from behind:
0 = no, 1 = yes
Default: 0 for every device.
-------------------------------------------------------------------------------
Name: mirror
Type: bool array (min = 0, max = 32)
Syntax: <0|1[,...]>
Description: Reverse image horizontally:
0 = no, 1 = yes
Default: 0 for every device.
-------------------------------------------------------------------------------
Name: monochrome
Type: bool array (min = 0, max = 32)
Syntax: <0|1[,...]>
Description: The image sensor is monochrome:
0 = no, 1 = yes
Default: 0 for every device.
-------------------------------------------------------------------------------
Name: brightness
Type: long array (min = 0, max = 32)
Syntax: <n[,...]>
Description: Set picture brightness (0-65535).
This parameter has no effect if 'autobright' is enabled.
Default: 31000 for every device.
-------------------------------------------------------------------------------
Name: hue
Type: long array (min = 0, max = 32)
Syntax: <n[,...]>
Description: Set picture hue (0-65535).
Default: 32768 for every device.
-------------------------------------------------------------------------------
Name: colour
Type: long array (min = 0, max = 32)
Syntax: <n[,...]>
Description: Set picture saturation (0-65535).
Default: 32768 for every device.
-------------------------------------------------------------------------------
Name: contrast
Type: long array (min = 0, max = 32)
Syntax: <n[,...]>
Description: Set picture contrast (0-65535).
Default: 50000 for every device.
-------------------------------------------------------------------------------
Name: whiteness
Type: long array (min = 0, max = 32)
Syntax: <n[,...]>
Description: Set picture whiteness (0-65535).
Default: 32768 for every device.
-------------------------------------------------------------------------------
Name: debug
Type: int
Syntax: <n>
Description: Debugging information level, from 0 to 6:
0 = none (use carefully)
1 = critical errors
2 = significant information
3 = configuration or general messages
4 = warnings
5 = called functions
6 = function internals
Level 5 and 6 are useful for testing only, when only one
device is used.
Default: 2
-------------------------------------------------------------------------------
Name: specific_debug
Type: bool
Syntax: <0|1>
Description: Enable or disable specific debugging messages:
0 = print messages concerning every level <= 'debug' level.
1 = print messages concerning the level indicated by 'debug'.
Default: 0
-------------------------------------------------------------------------------
9. Contact information
======================
I may be contacted by e-mail at <luca.risolia@studio.unibo.it>.
I can accept GPG/PGP encrypted e-mail. My GPG key ID is 'FCE635A4'.
My public 1024-bit key should be available at your keyserver; the fingerprint
is: '88E8 F32F 7244 68BA 3958 5D40 99DA 5D2A FCE6 35A4'.
10. Credits
==========
The development would not have proceed much further without having looked at
the source code of other drivers and without the help of several persons; in
particular:
- the I2C interface to kernel and high-level image sensor control routines have
been taken from the OV511 driver by Mark McClelland;
- memory management code has been copied from the bttv driver by Ralph Metzler,
Marcus Metzler and Gerd Knorr;
- the low-level I2C read function has been written by Frederic Jouault;
- the low-level I2C fast write function has been written by Piotr Czerczak.

270
Documentation/video4linux/zc0301.txt
View file

@ -1,270 +0,0 @@
ZC0301 and ZC0301P Image Processor and Control Chip
Driver for Linux
===================================================
- Documentation -
Index
=====
1. Copyright
2. Disclaimer
3. License
4. Overview and features
5. Module dependencies
6. Module loading
7. Module parameters
8. Supported devices
9. Notes for V4L2 application developers
10. Contact information
11. Credits
1. Copyright
============
Copyright (C) 2006-2007 by Luca Risolia <luca.risolia@studio.unibo.it>
2. Disclaimer
=============
This software is not developed or sponsored by Z-Star Microelectronics Corp.
Trademarks are property of their respective owner.
3. 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.
4. Overview and features
========================
This driver supports the video interface of the devices mounting the ZC0301 or
ZC0301P Image Processors and Control Chips.
The driver relies on the Video4Linux2 and USB core modules. It has been
designed to run properly on SMP systems as well.
The latest version of the ZC0301[P] driver can be found at the following URL:
http://www.linux-projects.org/
Some of the features of the driver are:
- full compliance with the Video4Linux2 API (see also "Notes for V4L2
application developers" paragraph);
- available mmap or read/poll methods for video streaming through isochronous
data transfers;
- automatic detection of image sensor;
- video format is standard JPEG;
- dynamic driver control thanks to various module parameters (see "Module
parameters" paragraph);
- up to 64 cameras can be handled at the same time; they can be connected and
disconnected from the host many times without turning off the computer, if
the system supports hotplugging;
5. Module dependencies
======================
For it to work properly, the driver needs kernel support for Video4Linux and
USB.
The following options of the kernel configuration file must be enabled and
corresponding modules must be compiled:
# Multimedia devices
#
CONFIG_VIDEO_DEV=m
# USB support
#
CONFIG_USB=m
In addition, depending on the hardware being used, the modules below are
necessary:
# USB Host Controller Drivers
#
CONFIG_USB_EHCI_HCD=m
CONFIG_USB_UHCI_HCD=m
CONFIG_USB_OHCI_HCD=m
The ZC0301 controller also provides a built-in microphone interface. It is
supported by the USB Audio driver thanks to the ALSA API:
# Sound
#
CONFIG_SOUND=y
# Advanced Linux Sound Architecture
#
CONFIG_SND=m
# USB devices
#
CONFIG_SND_USB_AUDIO=m
And finally:
# V4L USB devices
#
CONFIG_USB_ZC0301=m
6. Module loading
=================
To use the driver, it is necessary to load the "zc0301" module into memory
after every other module required: "videodev", "v4l2_common", "compat_ioctl32",
"usbcore" and, depending on the USB host controller you have, "ehci-hcd",
"uhci-hcd" or "ohci-hcd".
Loading can be done as shown below:
[root@localhost home]# modprobe zc0301
At this point the devices should be recognized. You can invoke "dmesg" to
analyze kernel messages and verify that the loading process has gone well:
[user@localhost home]$ dmesg
7. Module parameters
====================
Module parameters are listed below:
-------------------------------------------------------------------------------
Name: video_nr
Type: short array (min = 0, max = 64)
Syntax: <-1|n[,...]>
Description: Specify V4L2 minor mode number:
-1 = use next available
n = use minor number n
You can specify up to 64 cameras this way.
For example:
video_nr=-1,2,-1 would assign minor number 2 to the second
registered camera and use auto for the first one and for every
other camera.
Default: -1
-------------------------------------------------------------------------------
Name: force_munmap
Type: bool array (min = 0, max = 64)
Syntax: <0|1[,...]>
Description: Force the application to unmap previously mapped buffer memory
before calling any VIDIOC_S_CROP or VIDIOC_S_FMT ioctl's. Not
all the applications support this feature. This parameter is
specific for each detected camera.
0 = do not force memory unmapping
1 = force memory unmapping (save memory)
Default: 0
-------------------------------------------------------------------------------
Name: frame_timeout
Type: uint array (min = 0, max = 64)
Syntax: <n[,...]>
Description: Timeout for a video frame in seconds. This parameter is
specific for each detected camera. This parameter can be
changed at runtime thanks to the /sys filesystem interface.
Default: 2
-------------------------------------------------------------------------------
Name: debug
Type: ushort
Syntax: <n>
Description: Debugging information level, from 0 to 3:
0 = none (use carefully)
1 = critical errors
2 = significant information
3 = more verbose messages
Level 3 is useful for testing only, when only one device
is used at the same time. It also shows some information
about the hardware being detected. This module parameter can be
changed at runtime thanks to the /sys filesystem interface.
Default: 2
-------------------------------------------------------------------------------
8. Supported devices
====================
None of the names of the companies as well as their products will be mentioned
here. They have never collaborated with the author, so no advertising.
From the point of view of a driver, what unambiguously identify a device are
its vendor and product USB identifiers. Below is a list of known identifiers of
devices mounting the ZC0301 Image Processor and Control Chips:
Vendor ID Product ID
--------- ----------
0x041e 0x4017
0x041e 0x401c
0x041e 0x401e
0x041e 0x401f
0x041e 0x4022
0x041e 0x4034
0x041e 0x4035
0x041e 0x4036
0x041e 0x403a
0x0458 0x7007
0x0458 0x700c
0x0458 0x700f
0x046d 0x08ae
0x055f 0xd003
0x055f 0xd004
0x0ac8 0x0301
0x0ac8 0x301b
0x0ac8 0x303b
0x10fd 0x0128
0x10fd 0x8050
0x10fd 0x804e
The list above does not imply that all those devices work with this driver: up
until now only the ones that mount the following image sensors are supported;
kernel messages will always tell you whether this is the case:
Model Manufacturer
----- ------------
PAS202BCB PixArt Imaging, Inc.
PB-0330 Photobit Corporation
9. Notes for V4L2 application developers
========================================
This driver follows the V4L2 API specifications. In particular, it enforces two
rules:
- exactly one I/O method, either "mmap" or "read", is associated with each
file descriptor. Once it is selected, the application must close and reopen the
device to switch to the other I/O method;
- although it is not mandatory, previously mapped buffer memory should always
be unmapped before calling any "VIDIOC_S_CROP" or "VIDIOC_S_FMT" ioctl's.
The same number of buffers as before will be allocated again to match the size
of the new video frames, so you have to map the buffers again before any I/O
attempts on them.
10. Contact information
=======================
The author may be contacted by e-mail at <luca.risolia@studio.unibo.it>.
GPG/PGP encrypted e-mail's are accepted. The GPG key ID of the author is
'FCE635A4'; the public 1024-bit key should be available at any keyserver;
the fingerprint is: '88E8 F32F 7244 68BA 3958 5D40 99DA 5D2A FCE6 35A4'.
11. Credits
===========
- Information about the chip internals needed to enable the I2C protocol have
been taken from the documentation of the ZC030x Video4Linux1 driver written
by Andrew Birkett <andy@nobugs.org>;
- The initialization values of the ZC0301 controller connected to the PAS202BCB
and PB-0330 image sensors have been taken from the SPCA5XX driver maintained
by Michel Xhaard <mxhaard@magic.fr>;
- Stanislav Lechev donated one camera.