diff options
Diffstat (limited to 'Documentation/video4linux')
| -rw-r--r-- | Documentation/video4linux/et61x251.txt | 315 | ||||
| -rw-r--r-- | Documentation/video4linux/ibmcam.txt | 323 | ||||
| -rw-r--r-- | Documentation/video4linux/m5602.txt | 12 | ||||
| -rw-r--r-- | Documentation/video4linux/ov511.txt | 288 | ||||
| -rw-r--r-- | Documentation/video4linux/se401.txt | 54 | ||||
| -rw-r--r-- | Documentation/video4linux/soc-camera.txt | 146 | ||||
| -rw-r--r-- | Documentation/video4linux/stv680.txt | 53 | ||||
| -rw-r--r-- | Documentation/video4linux/v4l2-framework.txt | 3 | ||||
| -rw-r--r-- | Documentation/video4linux/w9968cf.txt | 458 | ||||
| -rw-r--r-- | Documentation/video4linux/zc0301.txt | 270 |
10 files changed, 76 insertions, 1846 deletions
diff --git a/Documentation/video4linux/et61x251.txt b/Documentation/video4linux/et61x251.txt deleted file mode 100644 index e0cdae491858..000000000000 --- a/Documentation/video4linux/et61x251.txt +++ /dev/null | |||
| @@ -1,315 +0,0 @@ | |||
| 1 | |||
| 2 | ET61X[12]51 PC Camera Controllers | ||
| 3 | Driver for Linux | ||
| 4 | ================================= | ||
| 5 | |||
| 6 | - Documentation - | ||
| 7 | |||
| 8 | |||
| 9 | Index | ||
| 10 | ===== | ||
| 11 | 1. Copyright | ||
| 12 | 2. Disclaimer | ||
| 13 | 3. License | ||
| 14 | 4. Overview and features | ||
| 15 | 5. Module dependencies | ||
| 16 | 6. Module loading | ||
| 17 | 7. Module parameters | ||
| 18 | 8. Optional device control through "sysfs" | ||
| 19 | 9. Supported devices | ||
| 20 | 10. Notes for V4L2 application developers | ||
| 21 | 11. Contact information | ||
| 22 | |||
| 23 | |||
| 24 | 1. Copyright | ||
| 25 | ============ | ||
| 26 | Copyright (C) 2006-2007 by Luca Risolia <luca.risolia@studio.unibo.it> | ||
| 27 | |||
| 28 | |||
| 29 | 2. Disclaimer | ||
| 30 | ============= | ||
| 31 | Etoms is a trademark of Etoms Electronics Corp. | ||
| 32 | This software is not developed or sponsored by Etoms Electronics. | ||
| 33 | |||
| 34 | |||
| 35 | 3. License | ||
| 36 | ========== | ||
| 37 | This program is free software; you can redistribute it and/or modify | ||
| 38 | it under the terms of the GNU General Public License as published by | ||
| 39 | the Free Software Foundation; either version 2 of the License, or | ||
| 40 | (at your option) any later version. | ||
| 41 | |||
| 42 | This program is distributed in the hope that it will be useful, | ||
| 43 | but WITHOUT ANY WARRANTY; without even the implied warranty of | ||
| 44 | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the | ||
| 45 | GNU General Public License for more details. | ||
| 46 | |||
| 47 | You should have received a copy of the GNU General Public License | ||
| 48 | along with this program; if not, write to the Free Software | ||
| 49 | Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. | ||
| 50 | |||
| 51 | |||
| 52 | 4. Overview and features | ||
| 53 | ======================== | ||
| 54 | This driver supports the video interface of the devices mounting the ET61X151 | ||
| 55 | or ET61X251 PC Camera Controllers. | ||
| 56 | |||
| 57 | It's worth to note that Etoms Electronics has never collaborated with the | ||
| 58 | author during the development of this project; despite several requests, | ||
| 59 | Etoms Electronics also refused to release enough detailed specifications of | ||
| 60 | the video compression engine. | ||
| 61 | |||
| 62 | The driver relies on the Video4Linux2 and USB core modules. It has been | ||
| 63 | designed to run properly on SMP systems as well. | ||
| 64 | |||
| 65 | The latest version of the ET61X[12]51 driver can be found at the following URL: | ||
| 66 | http://www.linux-projects.org/ | ||
| 67 | |||
| 68 | Some of the features of the driver are: | ||
| 69 | |||
| 70 | - full compliance with the Video4Linux2 API (see also "Notes for V4L2 | ||
| 71 | application developers" paragraph); | ||
| 72 | - available mmap or read/poll methods for video streaming through isochronous | ||
| 73 | data transfers; | ||
| 74 | - automatic detection of image sensor; | ||
| 75 | - support for any window resolutions and optional panning within the maximum | ||
| 76 | pixel area of image sensor; | ||
| 77 | - image downscaling with arbitrary scaling factors from 1 and 2 in both | ||
| 78 | directions (see "Notes for V4L2 application developers" paragraph); | ||
| 79 | - two different video formats for uncompressed or compressed data in low or | ||
| 80 | high compression quality (see also "Notes for V4L2 application developers" | ||
| 81 | paragraph); | ||
| 82 | - full support for the capabilities of every possible image sensors that can | ||
| 83 | be connected to the ET61X[12]51 bridges, including, for instance, red, green, | ||
| 84 | blue and global gain adjustments and exposure control (see "Supported | ||
| 85 | devices" paragraph for details); | ||
| 86 | - use of default color settings for sunlight conditions; | ||
| 87 | - dynamic I/O interface for both ET61X[12]51 and image sensor control (see | ||
| 88 | "Optional device control through 'sysfs'" paragraph); | ||
| 89 | - dynamic driver control thanks to various module parameters (see "Module | ||
| 90 | parameters" paragraph); | ||
| 91 | - up to 64 cameras can be handled at the same time; they can be connected and | ||
| 92 | disconnected from the host many times without turning off the computer, if | ||
| 93 | the system supports hotplugging; | ||
| 94 | - no known bugs. | ||
| 95 | |||
| 96 | |||
| 97 | 5. Module dependencies | ||
| 98 | ====================== | ||
| 99 | For it to work properly, the driver needs kernel support for Video4Linux and | ||
| 100 | USB. | ||
| 101 | |||
| 102 | The following options of the kernel configuration file must be enabled and | ||
| 103 | corresponding modules must be compiled: | ||
| 104 | |||
| 105 | # Multimedia devices | ||
| 106 | # | ||
| 107 | CONFIG_VIDEO_DEV=m | ||
| 108 | |||
| 109 | To enable advanced debugging functionality on the device through /sysfs: | ||
| 110 | |||
| 111 | # Multimedia devices | ||
| 112 | # | ||
| 113 | CONFIG_VIDEO_ADV_DEBUG=y | ||
| 114 | |||
| 115 | # USB support | ||
| 116 | # | ||
| 117 | CONFIG_USB=m | ||
| 118 | |||
| 119 | In addition, depending on the hardware being used, the modules below are | ||
| 120 | necessary: | ||
| 121 | |||
| 122 | # USB Host Controller Drivers | ||
| 123 | # | ||
| 124 | CONFIG_USB_EHCI_HCD=m | ||
| 125 | CONFIG_USB_UHCI_HCD=m | ||
| 126 | CONFIG_USB_OHCI_HCD=m | ||
| 127 | |||
| 128 | And finally: | ||
| 129 | |||
| 130 | # USB Multimedia devices | ||
| 131 | # | ||
| 132 | CONFIG_USB_ET61X251=m | ||
| 133 | |||
| 134 | |||
| 135 | 6. Module loading | ||
| 136 | ================= | ||
| 137 | To use the driver, it is necessary to load the "et61x251" module into memory | ||
| 138 | after every other module required: "videodev", "v4l2_common", "compat_ioctl32", | ||
| 139 | "usbcore" and, depending on the USB host controller you have, "ehci-hcd", | ||
| 140 | "uhci-hcd" or "ohci-hcd". | ||
| 141 | |||
| 142 | Loading can be done as shown below: | ||
| 143 | |||
| 144 | [root@localhost home]# modprobe et61x251 | ||
| 145 | |||
| 146 | At this point the devices should be recognized. You can invoke "dmesg" to | ||
| 147 | analyze kernel messages and verify that the loading process has gone well: | ||
| 148 | |||
| 149 | [user@localhost home]$ dmesg | ||
| 150 | |||
| 151 | |||
| 152 | 7. Module parameters | ||
| 153 | ==================== | ||
| 154 | Module parameters are listed below: | ||
| 155 | ------------------------------------------------------------------------------- | ||
| 156 | Name: video_nr | ||
| 157 | Type: short array (min = 0, max = 64) | ||
| 158 | Syntax: <-1|n[,...]> | ||
| 159 | Description: Specify V4L2 minor mode number: | ||
| 160 | -1 = use next available | ||
| 161 | n = use minor number n | ||
| 162 | You can specify up to 64 cameras this way. | ||
| 163 | For example: | ||
| 164 | video_nr=-1,2,-1 would assign minor number 2 to the second | ||
| 165 | registered camera and use auto for the first one and for every | ||
| 166 | other camera. | ||
| 167 | Default: -1 | ||
| 168 | ------------------------------------------------------------------------------- | ||
| 169 | Name: force_munmap | ||
| 170 | Type: bool array (min = 0, max = 64) | ||
| 171 | Syntax: <0|1[,...]> | ||
| 172 | Description: Force the application to unmap previously mapped buffer memory | ||
| 173 | before calling any VIDIOC_S_CROP or VIDIOC_S_FMT ioctl's. Not | ||
| 174 | all the applications support this feature. This parameter is | ||
| 175 | specific for each detected camera. | ||
| 176 | 0 = do not force memory unmapping | ||
| 177 | 1 = force memory unmapping (save memory) | ||
| 178 | Default: 0 | ||
| 179 | ------------------------------------------------------------------------------- | ||
| 180 | Name: frame_timeout | ||
| 181 | Type: uint array (min = 0, max = 64) | ||
| 182 | Syntax: <n[,...]> | ||
| 183 | Description: Timeout for a video frame in seconds. This parameter is | ||
| 184 | specific for each detected camera. This parameter can be | ||
| 185 | changed at runtime thanks to the /sys filesystem interface. | ||
| 186 | Default: 2 | ||
| 187 | ------------------------------------------------------------------------------- | ||
| 188 | Name: debug | ||
| 189 | Type: ushort | ||
| 190 | Syntax: <n> | ||
| 191 | Description: Debugging information level, from 0 to 3: | ||
| 192 | 0 = none (use carefully) | ||
| 193 | 1 = critical errors | ||
| 194 | 2 = significant information | ||
| 195 | 3 = more verbose messages | ||
| 196 | Level 3 is useful for testing only, when only one device | ||
| 197 | is used at the same time. It also shows some more information | ||
| 198 | about the hardware being detected. This module parameter can be | ||
| 199 | changed at runtime thanks to the /sys filesystem interface. | ||
| 200 | Default: 2 | ||
| 201 | ------------------------------------------------------------------------------- | ||
| 202 | |||
| 203 | |||
| 204 | 8. Optional device control through "sysfs" | ||
| 205 | ========================================== | ||
| 206 | If the kernel has been compiled with the CONFIG_VIDEO_ADV_DEBUG option enabled, | ||
| 207 | it is possible to read and write both the ET61X[12]51 and the image sensor | ||
| 208 | registers by using the "sysfs" filesystem interface. | ||
| 209 | |||
| 210 | There are four files in the /sys/class/video4linux/videoX directory for each | ||
| 211 | registered camera: "reg", "val", "i2c_reg" and "i2c_val". The first two files | ||
| 212 | control the ET61X[12]51 bridge, while the other two control the sensor chip. | ||
| 213 | "reg" and "i2c_reg" hold the values of the current register index where the | ||
| 214 | following reading/writing operations are addressed at through "val" and | ||
| 215 | "i2c_val". Their use is not intended for end-users, unless you know what you | ||
| 216 | are doing. Remember that you must be logged in as root before writing to them. | ||
| 217 | |||
| 218 | As an example, suppose we were to want to read the value contained in the | ||
| 219 | register number 1 of the sensor register table - which is usually the product | ||
| 220 | identifier - of the camera registered as "/dev/video0": | ||
| 221 | |||
| 222 | [root@localhost #] cd /sys/class/video4linux/video0 | ||
| 223 | [root@localhost #] echo 1 > i2c_reg | ||
| 224 | [root@localhost #] cat i2c_val | ||
| 225 | |||
| 226 | Note that if the sensor registers cannot be read, "cat" will fail. | ||
| 227 | To avoid race conditions, all the I/O accesses to the files are serialized. | ||
| 228 | |||
| 229 | |||
| 230 | 9. Supported devices | ||
| 231 | ==================== | ||
| 232 | None of the names of the companies as well as their products will be mentioned | ||
| 233 | here. They have never collaborated with the author, so no advertising. | ||
| 234 | |||
| 235 | From the point of view of a driver, what unambiguously identify a device are | ||
| 236 | its vendor and product USB identifiers. Below is a list of known identifiers of | ||
| 237 | devices mounting the ET61X[12]51 PC camera controllers: | ||
| 238 | |||
| 239 | Vendor ID Product ID | ||
| 240 | --------- ---------- | ||
| 241 | 0x102c 0x6151 | ||
| 242 | 0x102c 0x6251 | ||
| 243 | 0x102c 0x6253 | ||
| 244 | 0x102c 0x6254 | ||
| 245 | 0x102c 0x6255 | ||
| 246 | 0x102c 0x6256 | ||
| 247 | 0x102c 0x6257 | ||
| 248 | 0x102c 0x6258 | ||
| 249 | 0x102c 0x6259 | ||
| 250 | 0x102c 0x625a | ||
| 251 | 0x102c 0x625b | ||
| 252 | 0x102c 0x625c | ||
| 253 | 0x102c 0x625d | ||
| 254 | 0x102c 0x625e | ||
| 255 | 0x102c 0x625f | ||
| 256 | 0x102c 0x6260 | ||
| 257 | 0x102c 0x6261 | ||
| 258 | 0x102c 0x6262 | ||
| 259 | 0x102c 0x6263 | ||
| 260 | 0x102c 0x6264 | ||
| 261 | 0x102c 0x6265 | ||
| 262 | 0x102c 0x6266 | ||
| 263 | 0x102c 0x6267 | ||
| 264 | 0x102c 0x6268 | ||
| 265 | 0x102c 0x6269 | ||
| 266 | |||
| 267 | The following image sensors are supported: | ||
| 268 | |||
| 269 | Model Manufacturer | ||
| 270 | ----- ------------ | ||
| 271 | TAS5130D1B Taiwan Advanced Sensor Corporation | ||
| 272 | |||
| 273 | All the available control settings of each image sensor are supported through | ||
| 274 | the V4L2 interface. | ||
| 275 | |||
| 276 | |||
| 277 | 10. Notes for V4L2 application developers | ||
| 278 | ========================================= | ||
| 279 | This driver follows the V4L2 API specifications. In particular, it enforces two | ||
| 280 | rules: | ||
| 281 | |||
| 282 | - exactly one I/O method, either "mmap" or "read", is associated with each | ||
| 283 | file descriptor. Once it is selected, the application must close and reopen the | ||
| 284 | device to switch to the other I/O method; | ||
| 285 | |||
| 286 | - although it is not mandatory, previously mapped buffer memory should always | ||
| 287 | be unmapped before calling any "VIDIOC_S_CROP" or "VIDIOC_S_FMT" ioctl's. | ||
| 288 | The same number of buffers as before will be allocated again to match the size | ||
| 289 | of the new video frames, so you have to map the buffers again before any I/O | ||
| 290 | attempts on them. | ||
| 291 | |||
| 292 | Consistently with the hardware limits, this driver also supports image | ||
| 293 | downscaling with arbitrary scaling factors from 1 and 2 in both directions. | ||
| 294 | However, the V4L2 API specifications don't correctly define how the scaling | ||
| 295 | factor can be chosen arbitrarily by the "negotiation" of the "source" and | ||
| 296 | "target" rectangles. To work around this flaw, we have added the convention | ||
| 297 | that, during the negotiation, whenever the "VIDIOC_S_CROP" ioctl is issued, the | ||
| 298 | scaling factor is restored to 1. | ||
| 299 | |||
| 300 | This driver supports two different video formats: the first one is the "8-bit | ||
| 301 | Sequential Bayer" format and can be used to obtain uncompressed video data | ||
| 302 | from the device through the current I/O method, while the second one provides | ||
| 303 | "raw" compressed video data (without frame headers not related to the | ||
| 304 | compressed data). The current compression quality may vary from 0 to 1 and can | ||
| 305 | be selected or queried thanks to the VIDIOC_S_JPEGCOMP and VIDIOC_G_JPEGCOMP | ||
| 306 | V4L2 ioctl's. | ||
| 307 | |||
| 308 | |||
| 309 | 11. Contact information | ||
| 310 | ======================= | ||
| 311 | The author may be contacted by e-mail at <luca.risolia@studio.unibo.it>. | ||
| 312 | |||
| 313 | GPG/PGP encrypted e-mail's are accepted. The GPG key ID of the author is | ||
| 314 | 'FCE635A4'; the public 1024-bit key should be available at any keyserver; | ||
| 315 | the fingerprint is: '88E8 F32F 7244 68BA 3958 5D40 99DA 5D2A FCE6 35A4'. | ||
diff --git a/Documentation/video4linux/ibmcam.txt b/Documentation/video4linux/ibmcam.txt deleted file mode 100644 index a51055211e62..000000000000 --- a/Documentation/video4linux/ibmcam.txt +++ /dev/null | |||
| @@ -1,323 +0,0 @@ | |||
| 1 | README for Linux device driver for the IBM "C-It" USB video camera | ||
| 2 | |||
| 3 | INTRODUCTION: | ||
| 4 | |||
| 5 | This driver does not use all features known to exist in | ||
| 6 | the IBM camera. However most of needed features work well. | ||
| 7 | |||
| 8 | This driver was developed using logs of observed USB traffic | ||
| 9 | which was produced by standard Windows driver (c-it98.sys). | ||
| 10 | I did not have data sheets from Xirlink. | ||
| 11 | |||
| 12 | Video formats: | ||
| 13 | 128x96 [model 1] | ||
| 14 | 176x144 | ||
| 15 | 320x240 [model 2] | ||
| 16 | 352x240 [model 2] | ||
| 17 | 352x288 | ||
| 18 | Frame rate: 3 - 30 frames per second (FPS) | ||
| 19 | External interface: USB | ||
| 20 | Internal interface: Video For Linux (V4L) | ||
| 21 | Supported controls: | ||
| 22 | - by V4L: Contrast, Brightness, Color, Hue | ||
| 23 | - by driver options: frame rate, lighting conditions, video format, | ||
| 24 | default picture settings, sharpness. | ||
| 25 | |||
| 26 | SUPPORTED CAMERAS: | ||
| 27 | |||
| 28 | Xirlink "C-It" camera, also known as "IBM PC Camera". | ||
| 29 | The device uses proprietary ASIC (and compression method); | ||
| 30 | it is manufactured by Xirlink. See http://xirlinkwebcam.sourceforge.net, | ||
| 31 | http://www.ibmpccamera.com, or http://www.c-itnow.com/ for details and pictures. | ||
| 32 | |||
| 33 | This very chipset ("X Chip", as marked at the factory) | ||
| 34 | is used in several other cameras, and they are supported | ||
| 35 | as well: | ||
| 36 | |||
| 37 | - IBM NetCamera | ||
| 38 | - Veo Stingray | ||
| 39 | |||
| 40 | The Linux driver was developed with camera with following | ||
| 41 | model number (or FCC ID): KSX-XVP510. This camera has three | ||
| 42 | interfaces, each with one endpoint (control, iso, iso). This | ||
| 43 | type of cameras is referred to as "model 1". These cameras are | ||
| 44 | no longer manufactured. | ||
| 45 | |||
| 46 | Xirlink now manufactures new cameras which are somewhat different. | ||
| 47 | In particular, following models [FCC ID] belong to that category: | ||
| 48 | |||
| 49 | XVP300 [KSX-X9903] | ||
| 50 | XVP600 [KSX-X9902] | ||
| 51 | XVP610 [KSX-X9902] | ||
| 52 | |||
| 53 | (see http://www.xirlink.com/ibmpccamera/ for updates, they refer | ||
| 54 | to these new cameras by Windows driver dated 12-27-99, v3005 BETA) | ||
| 55 | These cameras have two interfaces, one endpoint in each (iso, bulk). | ||
| 56 | Such type of cameras is referred to as "model 2". They are supported | ||
| 57 | (with exception of 352x288 native mode). | ||
| 58 | |||
| 59 | Some IBM NetCameras (Model 4) are made to generate only compressed | ||
| 60 | video streams. This is great for performance, but unfortunately | ||
| 61 | nobody knows how to decompress the stream :-( Therefore, these | ||
| 62 | cameras are *unsupported* and if you try to use one of those, all | ||
| 63 | you get is random colored horizontal streaks, not the image! | ||
| 64 | If you have one of those cameras, you probably should return it | ||
| 65 | to the store and get something that is supported. | ||
| 66 | |||
| 67 | Tell me more about all that "model" business | ||
| 68 | -------------------------------------------- | ||
| 69 | |||
| 70 | I just invented model numbers to uniquely identify flavors of the | ||
| 71 | hardware/firmware that were sold. It was very confusing to use | ||
| 72 | brand names or some other internal numbering schemes. So I found | ||
| 73 | by experimentation that all Xirlink chipsets fall into four big | ||
| 74 | classes, and I called them "models". Each model is programmed in | ||
| 75 | its own way, and each model sends back the video in its own way. | ||
| 76 | |||
| 77 | Quirks of Model 2 cameras: | ||
| 78 | ------------------------- | ||
| 79 | |||
| 80 | Model 2 does not have hardware contrast control. Corresponding V4L | ||
| 81 | control is implemented in software, which is not very nice to your | ||
| 82 | CPU, but at least it works. | ||
| 83 | |||
| 84 | This driver provides 352x288 mode by switching the camera into | ||
| 85 | quasi-352x288 RGB mode (800 Kbits per frame) essentially limiting | ||
| 86 | this mode to 10 frames per second or less, in ideal conditions on | ||
| 87 | the bus (USB is shared, after all). The frame rate | ||
| 88 | has to be programmed very conservatively. Additional concern is that | ||
| 89 | frame rate depends on brightness setting; therefore the picture can | ||
| 90 | be good at one brightness and broken at another! I did not want to fix | ||
| 91 | the frame rate at slowest setting, but I had to move it pretty much down | ||
| 92 | the scale (so that framerate option barely matters). I also noticed that | ||
| 93 | camera after first powering up produces frames slightly faster than during | ||
| 94 | consecutive uses. All this means that if you use 352x288 (which is | ||
| 95 | default), be warned - you may encounter broken picture on first connect; | ||
| 96 | try to adjust brightness - brighter image is slower, so USB will be able | ||
| 97 | to send all data. However if you regularly use Model 2 cameras you may | ||
| 98 | prefer 176x144 which makes perfectly good I420, with no scaling and | ||
| 99 | lesser demands on USB (300 Kbits per second, or 26 frames per second). | ||
| 100 | |||
| 101 | Another strange effect of 352x288 mode is the fine vertical grid visible | ||
| 102 | on some colored surfaces. I am sure it is caused by me not understanding | ||
| 103 | what the camera is trying to say. Blame trade secrets for that. | ||
| 104 | |||
| 105 | The camera that I had also has a hardware quirk: if disconnected, | ||
| 106 | it needs few minutes to "relax" before it can be plugged in again | ||
| 107 | (poorly designed USB processor reset circuit?) | ||
| 108 | |||
| 109 | [Veo Stingray with Product ID 0x800C is also Model 2, but I haven't | ||
| 110 | observed this particular flaw in it.] | ||
| 111 | |||
| 112 | Model 2 camera can be programmed for very high sensitivity (even starlight | ||
| 113 | may be enough), this makes it convenient for tinkering with. The driver | ||
| 114 | code has enough comments to help a programmer to tweak the camera | ||
| 115 | as s/he feels necessary. | ||
| 116 | |||
| 117 | WHAT YOU NEED: | ||
| 118 | |||
| 119 | - A supported IBM PC (C-it) camera (model 1 or 2) | ||
| 120 | |||
| 121 | - A Linux box with USB support (2.3/2.4; 2.2 w/backport may work) | ||
| 122 | |||
| 123 | - A Video4Linux compatible frame grabber program such as xawtv. | ||
| 124 | |||
| 125 | HOW TO COMPILE THE DRIVER: | ||
| 126 | |||
| 127 | You need to compile the driver only if you are a developer | ||
| 128 | or if you want to make changes to the code. Most distributions | ||
| 129 | precompile all modules, so you can go directly to the next | ||
| 130 | section "HOW TO USE THE DRIVER". | ||
| 131 | |||
| 132 | The ibmcam driver uses usbvideo helper library (module), | ||
| 133 | so if you are studying the ibmcam code you will be led there. | ||
| 134 | |||
| 135 | The driver itself consists of only one file in usb/ directory: | ||
| 136 | ibmcam.c. This file is included into the Linux kernel build | ||
| 137 | process if you configure the kernel for CONFIG_USB_IBMCAM. | ||
| 138 | Run "make xconfig" and in USB section you will find the IBM | ||
| 139 | camera driver. Select it, save the configuration and recompile. | ||
| 140 | |||
| 141 | HOW TO USE THE DRIVER: | ||
| 142 | |||
| 143 | I recommend to compile driver as a module. This gives you an | ||
| 144 | easier access to its configuration. The camera has many more | ||
| 145 | settings than V4L can operate, so some settings are done using | ||
| 146 | module options. | ||
| 147 | |||
| 148 | To begin with, on most modern Linux distributions the driver | ||
| 149 | will be automatically loaded whenever you plug the supported | ||
| 150 | camera in. Therefore, you don't need to do anything. However | ||
| 151 | if you want to experiment with some module parameters then | ||
| 152 | you can load and unload the driver manually, with camera | ||
| 153 | plugged in or unplugged. | ||
| 154 | |||
| 155 | Typically module is installed with command 'modprobe', like this: | ||
| 156 | |||
| 157 | # modprobe ibmcam framerate=1 | ||
| 158 | |||
| 159 | Alternatively you can use 'insmod' in similar fashion: | ||
| 160 | |||
| 161 | # insmod /lib/modules/2.x.y/usb/ibmcam.o framerate=1 | ||
| 162 | |||
| 163 | Module can be inserted with camera connected or disconnected. | ||
| 164 | |||
| 165 | The driver can have options, though some defaults are provided. | ||
| 166 | |||
| 167 | Driver options: (* indicates that option is model-dependent) | ||
| 168 | |||
| 169 | Name Type Range [default] Example | ||
| 170 | -------------- -------------- -------------- ------------------ | ||
| 171 | debug Integer 0-9 [0] debug=1 | ||
| 172 | flags Integer 0-0xFF [0] flags=0x0d | ||
| 173 | framerate Integer 0-6 [2] framerate=1 | ||
| 174 | hue_correction Integer 0-255 [128] hue_correction=115 | ||
| 175 | init_brightness Integer 0-255 [128] init_brightness=100 | ||
| 176 | init_contrast Integer 0-255 [192] init_contrast=200 | ||
| 177 | init_color Integer 0-255 [128] init_color=130 | ||
| 178 | init_hue Integer 0-255 [128] init_hue=115 | ||
| 179 | lighting Integer 0-2* [1] lighting=2 | ||
| 180 | sharpness Integer 0-6* [4] sharpness=3 | ||
| 181 | size Integer 0-2* [2] size=1 | ||
| 182 | |||
| 183 | Options for Model 2 only: | ||
| 184 | |||
| 185 | Name Type Range [default] Example | ||
| 186 | -------------- -------------- -------------- ------------------ | ||
| 187 | init_model2_rg Integer 0..255 [0x70] init_model2_rg=128 | ||
| 188 | init_model2_rg2 Integer 0..255 [0x2f] init_model2_rg2=50 | ||
| 189 | init_model2_sat Integer 0..255 [0x34] init_model2_sat=65 | ||
| 190 | init_model2_yb Integer 0..255 [0xa0] init_model2_yb=200 | ||
| 191 | |||
| 192 | debug You don't need this option unless you are a developer. | ||
| 193 | If you are a developer then you will see in the code | ||
| 194 | what values do what. 0=off. | ||
| 195 | |||
| 196 | flags This is a bit mask, and you can combine any number of | ||
| 197 | bits to produce what you want. Usually you don't want | ||
| 198 | any of extra features this option provides: | ||
| 199 | |||
| 200 | FLAGS_RETRY_VIDIOCSYNC 1 This bit allows to retry failed | ||
| 201 | VIDIOCSYNC ioctls without failing. | ||
| 202 | Will work with xawtv, will not | ||
| 203 | with xrealproducer. Default is | ||
| 204 | not set. | ||
| 205 | FLAGS_MONOCHROME 2 Activates monochrome (b/w) mode. | ||
| 206 | FLAGS_DISPLAY_HINTS 4 Shows colored pixels which have | ||
| 207 | magic meaning to developers. | ||
| 208 | FLAGS_OVERLAY_STATS 8 Shows tiny numbers on screen, | ||
| 209 | useful only for debugging. | ||
| 210 | FLAGS_FORCE_TESTPATTERN 16 Shows blue screen with numbers. | ||
| 211 | FLAGS_SEPARATE_FRAMES 32 Shows each frame separately, as | ||
| 212 | it was received from the camera. | ||
| 213 | Default (not set) is to mix the | ||
| 214 | preceding frame in to compensate | ||
| 215 | for occasional loss of Isoc data | ||
| 216 | on high frame rates. | ||
| 217 | FLAGS_CLEAN_FRAMES 64 Forces "cleanup" of each frame | ||
| 218 | prior to use; relevant only if | ||
| 219 | FLAGS_SEPARATE_FRAMES is set. | ||
| 220 | Default is not to clean frames, | ||
| 221 | this is a little faster but may | ||
| 222 | produce flicker if frame rate is | ||
| 223 | too high and Isoc data gets lost. | ||
| 224 | FLAGS_NO_DECODING 128 This flag turns the video stream | ||
| 225 | decoder off, and dumps the raw | ||
| 226 | Isoc data from the camera into | ||
| 227 | the reading process. Useful to | ||
| 228 | developers, but not to users. | ||
| 229 | |||
| 230 | framerate This setting controls frame rate of the camera. This is | ||
| 231 | an approximate setting (in terms of "worst" ... "best") | ||
| 232 | because camera changes frame rate depending on amount | ||
| 233 | of light available. Setting 0 is slowest, 6 is fastest. | ||
| 234 | Beware - fast settings are very demanding and may not | ||
| 235 | work well with all video sizes. Be conservative. | ||
| 236 | |||
| 237 | hue_correction This highly optional setting allows to adjust the | ||
| 238 | hue of the image in a way slightly different from | ||
| 239 | what usual "hue" control does. Both controls affect | ||
| 240 | YUV colorspace: regular "hue" control adjusts only | ||
| 241 | U component, and this "hue_correction" option similarly | ||
| 242 | adjusts only V component. However usually it is enough | ||
| 243 | to tweak only U or V to compensate for colored light or | ||
| 244 | color temperature; this option simply allows more | ||
| 245 | complicated correction when and if it is necessary. | ||
| 246 | |||
| 247 | init_brightness These settings specify _initial_ values which will be | ||
| 248 | init_contrast used to set up the camera. If your V4L application has | ||
| 249 | init_color its own controls to adjust the picture then these | ||
| 250 | init_hue controls will be used too. These options allow you to | ||
| 251 | preconfigure the camera when it gets connected, before | ||
| 252 | any V4L application connects to it. Good for webcams. | ||
| 253 | |||
| 254 | init_model2_rg These initial settings alter color balance of the | ||
| 255 | init_model2_rg2 camera on hardware level. All four settings may be used | ||
| 256 | init_model2_sat to tune the camera to specific lighting conditions. These | ||
| 257 | init_model2_yb settings only apply to Model 2 cameras. | ||
| 258 | |||
| 259 | lighting This option selects one of three hardware-defined | ||
| 260 | photosensitivity settings of the camera. 0=bright light, | ||
| 261 | 1=Medium (default), 2=Low light. This setting affects | ||
| 262 | frame rate: the dimmer the lighting the lower the frame | ||
| 263 | rate (because longer exposition time is needed). The | ||
| 264 | Model 2 cameras allow values more than 2 for this option, | ||
| 265 | thus enabling extremely high sensitivity at cost of frame | ||
| 266 | rate, color saturation and imaging sensor noise. | ||
| 267 | |||
| 268 | sharpness This option controls smoothing (noise reduction) | ||
| 269 | made by camera. Setting 0 is most smooth, setting 6 | ||
| 270 | is most sharp. Be aware that CMOS sensor used in the | ||
| 271 | camera is pretty noisy, so if you choose 6 you will | ||
| 272 | be greeted with "snowy" image. Default is 4. Model 2 | ||
| 273 | cameras do not support this feature. | ||
| 274 | |||
| 275 | size This setting chooses one of several image sizes that are | ||
| 276 | supported by this driver. Cameras may support more, but | ||
| 277 | it's difficult to reverse-engineer all formats. | ||
| 278 | Following video sizes are supported: | ||
| 279 | |||
| 280 | size=0 128x96 (Model 1 only) | ||
| 281 | size=1 160x120 | ||
| 282 | size=2 176x144 | ||
| 283 | size=3 320x240 (Model 2 only) | ||
| 284 | size=4 352x240 (Model 2 only) | ||
| 285 | size=5 352x288 | ||
| 286 | size=6 640x480 (Model 3 only) | ||
| 287 | |||
| 288 | The 352x288 is the native size of the Model 1 sensor | ||
| 289 | array, so it's the best resolution the camera can | ||
| 290 | yield. The best resolution of Model 2 is 176x144, and | ||
| 291 | larger images are produced by stretching the bitmap. | ||
| 292 | Model 3 has sensor with 640x480 grid, and it works too, | ||
| 293 | but the frame rate will be exceptionally low (1-2 FPS); | ||
| 294 | it may be still OK for some applications, like security. | ||
| 295 | Choose the image size you need. The smaller image can | ||
| 296 | support faster frame rate. Default is 352x288. | ||
| 297 | |||
| 298 | For more information and the Troubleshooting FAQ visit this URL: | ||
| 299 | |||
| 300 | http://www.linux-usb.org/ibmcam/ | ||
| 301 | |||
| 302 | WHAT NEEDS TO BE DONE: | ||
| 303 | |||
| 304 | - The button on the camera is not used. I don't know how to get to it. | ||
| 305 | I know now how to read button on Model 2, but what to do with it? | ||
| 306 | |||
| 307 | - Camera reports its status back to the driver; however I don't know | ||
| 308 | what returned data means. If camera fails at some initialization | ||
| 309 | stage then something should be done, and I don't do that because | ||
| 310 | I don't even know that some command failed. This is mostly Model 1 | ||
| 311 | concern because Model 2 uses different commands which do not return | ||
| 312 | status (and seem to complete successfully every time). | ||
| 313 | |||
| 314 | - Some flavors of Model 4 NetCameras produce only compressed video | ||
| 315 | streams, and I don't know how to decode them. | ||
| 316 | |||
| 317 | CREDITS: | ||
| 318 | |||
| 319 | The code is based in no small part on the CPiA driver by Johannes Erdfelt, | ||
| 320 | Randy Dunlap, and others. Big thanks to them for their pioneering work on that | ||
| 321 | and the USB stack. | ||
| 322 | |||
| 323 | I also thank John Lightsey for his donation of the Veo Stingray camera. | ||
diff --git a/Documentation/video4linux/m5602.txt b/Documentation/video4linux/m5602.txt deleted file mode 100644 index 4450ab13f37b..000000000000 --- a/Documentation/video4linux/m5602.txt +++ /dev/null | |||
| @@ -1,12 +0,0 @@ | |||
| 1 | This document describes the ALi m5602 bridge connected | ||
| 2 | to the following supported sensors: | ||
| 3 | OmniVision OV9650, | ||
| 4 | Samsung s5k83a, | ||
| 5 | Samsung s5k4aa, | ||
| 6 | Micron mt9m111, | ||
| 7 | Pixel plus PO1030 | ||
| 8 | |||
| 9 | This driver mimics the windows drivers, which have a braindead implementation sending bayer-encoded frames at VGA resolution. | ||
| 10 | 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 | ||
| 11 | |||
| 12 | Anyway, have fun and please report any bugs to m560x-driver-devel@lists.sourceforge.net | ||
diff --git a/Documentation/video4linux/ov511.txt b/Documentation/video4linux/ov511.txt deleted file mode 100644 index b3326b167ada..000000000000 --- a/Documentation/video4linux/ov511.txt +++ /dev/null | |||
| @@ -1,288 +0,0 @@ | |||
| 1 | ------------------------------------------------------------------------------- | ||
| 2 | Readme for Linux device driver for the OmniVision OV511 USB to camera bridge IC | ||
| 3 | ------------------------------------------------------------------------------- | ||
| 4 | |||
| 5 | Author: Mark McClelland | ||
| 6 | Homepage: http://alpha.dyndns.org/ov511 | ||
| 7 | |||
| 8 | INTRODUCTION: | ||
| 9 | |||
| 10 | This is a driver for the OV511, a USB-only chip used in many "webcam" devices. | ||
| 11 | Any camera using the OV511/OV511+ and the OV6620/OV7610/20/20AE should work. | ||
| 12 | Video capture devices that use the Philips SAA7111A decoder also work. It | ||
| 13 | supports streaming and capture of color or monochrome video via the Video4Linux | ||
| 14 | API. Most V4L apps are compatible with it. Most resolutions with a width and | ||
| 15 | height that are a multiple of 8 are supported. | ||
| 16 | |||
| 17 | If you need more information, please visit the OV511 homepage at the above URL. | ||
| 18 | |||
| 19 | WHAT YOU NEED: | ||
| 20 | |||
| 21 | - If you want to help with the development, get the chip's specification docs at | ||
| 22 | http://www.ovt.com/omniusbp.html | ||
| 23 | |||
| 24 | - A Video4Linux compatible frame grabber program (I recommend vidcat and xawtv) | ||
| 25 | vidcat is part of the w3cam package: http://mpx.freeshell.net/ | ||
| 26 | xawtv is available at: http://linux.bytesex.org/xawtv/ | ||
| 27 | |||
| 28 | HOW TO USE IT: | ||
| 29 | |||
| 30 | Note: These are simplified instructions. For complete instructions see: | ||
| 31 | http://alpha.dyndns.org/ov511/install.html | ||
| 32 | |||
| 33 | You must have first compiled USB support, support for your specific USB host | ||
| 34 | controller (UHCI or OHCI), and Video4Linux support for your kernel (I recommend | ||
| 35 | making them modules.) Make sure "Enforce bandwidth allocation" is NOT enabled. | ||
| 36 | |||
| 37 | Next, (as root): | ||
| 38 | |||
| 39 | modprobe usbcore | ||
| 40 | modprobe usb-uhci <OR> modprobe usb-ohci | ||
| 41 | modprobe videodev | ||
| 42 | modprobe ov511 | ||
| 43 | |||
| 44 | If it is not already there (it usually is), create the video device: | ||
| 45 | |||
| 46 | mknod /dev/video0 c 81 0 | ||
| 47 | |||
| 48 | Optionally, symlink /dev/video to /dev/video0 | ||
| 49 | |||
| 50 | You will have to set permissions on this device to allow you to read/write | ||
| 51 | from it: | ||
| 52 | |||
| 53 | chmod 666 /dev/video | ||
| 54 | chmod 666 /dev/video0 (if necessary) | ||
| 55 | |||
| 56 | Now you are ready to run a video app! Both vidcat and xawtv work well for me | ||
| 57 | at 640x480. | ||
| 58 | |||
| 59 | [Using vidcat:] | ||
| 60 | |||
| 61 | vidcat -s 640x480 -p c > test.jpg | ||
| 62 | xview test.jpg | ||
| 63 | |||
| 64 | [Using xawtv:] | ||
| 65 | |||
| 66 | From the main xawtv directory: | ||
| 67 | |||
| 68 | make clean | ||
| 69 | ./configure | ||
| 70 | make | ||
| 71 | make install | ||
| 72 | |||
| 73 | Now you should be able to run xawtv. Right click for the options dialog. | ||
| 74 | |||
| 75 | MODULE PARAMETERS: | ||
| 76 | |||
| 77 | You can set these with: insmod ov511 NAME=VALUE | ||
| 78 | There is currently no way to set these on a per-camera basis. | ||
| 79 | |||
| 80 | NAME: autobright | ||
| 81 | TYPE: integer (Boolean) | ||
| 82 | DEFAULT: 1 | ||
| 83 | DESC: Brightness is normally under automatic control and can't be set | ||
| 84 | manually by the video app. Set to 0 for manual control. | ||
| 85 | |||
| 86 | NAME: autogain | ||
| 87 | TYPE: integer (Boolean) | ||
| 88 | DEFAULT: 1 | ||
| 89 | DESC: Auto Gain Control enable. This feature is not yet implemented. | ||
| 90 | |||
| 91 | NAME: autoexp | ||
| 92 | TYPE: integer (Boolean) | ||
| 93 | DEFAULT: 1 | ||
| 94 | DESC: Auto Exposure Control enable. This feature is not yet implemented. | ||
| 95 | |||
| 96 | NAME: debug | ||
| 97 | TYPE: integer (0-6) | ||
| 98 | DEFAULT: 3 | ||
| 99 | DESC: Sets the threshold for printing debug messages. The higher the value, | ||
| 100 | the more is printed. The levels are cumulative, and are as follows: | ||
| 101 | 0=no debug messages | ||
| 102 | 1=init/detection/unload and other significant messages | ||
| 103 | 2=some warning messages | ||
| 104 | 3=config/control function calls | ||
| 105 | 4=most function calls and data parsing messages | ||
| 106 | 5=highly repetitive mesgs | ||
| 107 | |||
| 108 | NAME: snapshot | ||
| 109 | TYPE: integer (Boolean) | ||
| 110 | DEFAULT: 0 | ||
| 111 | DESC: Set to 1 to enable snapshot mode. read()/VIDIOCSYNC will block until | ||
| 112 | the snapshot button is pressed. Note: enabling this mode disables | ||
| 113 | /proc/video/ov511/<minor#>/button | ||
| 114 | |||
| 115 | NAME: cams | ||
| 116 | TYPE: integer (1-4 for OV511, 1-31 for OV511+) | ||
| 117 | DEFAULT: 1 | ||
| 118 | DESC: Number of cameras allowed to stream simultaneously on a single bus. | ||
| 119 | Values higher than 1 reduce the data rate of each camera, allowing two | ||
| 120 | or more to be used at once. If you have a complicated setup involving | ||
| 121 | both OV511 and OV511+ cameras, trial-and-error may be necessary for | ||
| 122 | finding the optimum setting. | ||
| 123 | |||
| 124 | NAME: compress | ||
| 125 | TYPE: integer (Boolean) | ||
| 126 | DEFAULT: 0 | ||
| 127 | DESC: Set this to 1 to turn on the camera's compression engine. This can | ||
| 128 | potentially increase the frame rate at the expense of quality, if you | ||
| 129 | have a fast CPU. You must load the proper compression module for your | ||
| 130 | camera before starting your application (ov511_decomp or ov518_decomp). | ||
| 131 | |||
| 132 | NAME: testpat | ||
| 133 | TYPE: integer (Boolean) | ||
| 134 | DEFAULT: 0 | ||
| 135 | DESC: This configures the camera's sensor to transmit a colored test-pattern | ||
| 136 | instead of an image. This does not work correctly yet. | ||
| 137 | |||
| 138 | NAME: dumppix | ||
| 139 | TYPE: integer (0-2) | ||
| 140 | DEFAULT: 0 | ||
| 141 | DESC: Dumps raw pixel data and skips post-processing and format conversion. | ||
| 142 | It is for debugging purposes only. Options are: | ||
| 143 | 0: Disable (default) | ||
| 144 | 1: Dump raw data from camera, excluding headers and trailers | ||
| 145 | 2: Dumps data exactly as received from camera | ||
| 146 | |||
| 147 | NAME: led | ||
| 148 | TYPE: integer (0-2) | ||
| 149 | DEFAULT: 1 (Always on) | ||
| 150 | DESC: Controls whether the LED (the little light) on the front of the camera | ||
| 151 | is always off (0), always on (1), or only on when driver is open (2). | ||
| 152 | This is not supported with the OV511, and might only work with certain | ||
| 153 | cameras (ones that actually have the LED wired to the control pin, and | ||
| 154 | not just hard-wired to be on all the time). | ||
| 155 | |||
| 156 | NAME: dump_bridge | ||
| 157 | TYPE: integer (Boolean) | ||
| 158 | DEFAULT: 0 | ||
| 159 | DESC: Dumps the bridge (OV511[+] or OV518[+]) register values to the system | ||
| 160 | log. Only useful for serious debugging/development purposes. | ||
| 161 | |||
| 162 | NAME: dump_sensor | ||
| 163 | TYPE: integer (Boolean) | ||
| 164 | DEFAULT: 0 | ||
| 165 | DESC: Dumps the sensor register values to the system log. Only useful for | ||
| 166 | serious debugging/development purposes. | ||
| 167 | |||
| 168 | NAME: printph | ||
| 169 | TYPE: integer (Boolean) | ||
| 170 | DEFAULT: 0 | ||
| 171 | DESC: Setting this to 1 will dump the first 12 bytes of each isoc frame. This | ||
| 172 | is only useful if you are trying to debug problems with the isoc data | ||
| 173 | stream (i.e.: camera initializes, but vidcat hangs until Ctrl-C). Be | ||
| 174 | warned that this dumps a large number of messages to your kernel log. | ||
| 175 | |||
| 176 | NAME: phy, phuv, pvy, pvuv, qhy, qhuv, qvy, qvuv | ||
| 177 | TYPE: integer (0-63 for phy and phuv, 0-255 for rest) | ||
| 178 | DEFAULT: OV511 default values | ||
| 179 | DESC: These are registers 70h - 77h of the OV511, which control the | ||
| 180 | prediction ranges and quantization thresholds of the compressor, for | ||
| 181 | the Y and UV channels in the horizontal and vertical directions. See | ||
| 182 | the OV511 or OV511+ data sheet for more detailed descriptions. These | ||
| 183 | normally do not need to be changed. | ||
| 184 | |||
| 185 | NAME: lightfreq | ||
| 186 | TYPE: integer (0, 50, or 60) | ||
| 187 | DEFAULT: 0 (use sensor default) | ||
| 188 | DESC: Sets the sensor to match your lighting frequency. This can reduce the | ||
| 189 | appearance of "banding", i.e. horizontal lines or waves of light and | ||
| 190 | dark that are often caused by artificial lighting. Valid values are: | ||
| 191 | 0 - Use default (depends on sensor, most likely 60 Hz) | ||
| 192 | 50 - For European and Asian 50 Hz power | ||
| 193 | 60 - For American 60 Hz power | ||
| 194 | |||
| 195 | NAME: bandingfilter | ||
| 196 | TYPE: integer (Boolean) | ||
| 197 | DEFAULT: 0 (off) | ||
| 198 | DESC: Enables the sensor´s banding filter exposure algorithm. This reduces | ||
| 199 | or stabilizes the "banding" caused by some artificial light sources | ||
| 200 | (especially fluorescent). You might have to set lightfreq correctly for | ||
| 201 | this to work right. As an added bonus, this sometimes makes it | ||
| 202 | possible to capture your monitor´s output. | ||
| 203 | |||
| 204 | NAME: fastset | ||
| 205 | TYPE: integer (Boolean) | ||
| 206 | DEFAULT: 0 (off) | ||
| 207 | DESC: Allows picture settings (brightness, contrast, color, and hue) to take | ||
| 208 | effect immediately, even in the middle of a frame. This reduces the | ||
| 209 | time to change settings, but can ruin frames during the change. Only | ||
| 210 | affects OmniVision sensors. | ||
| 211 | |||
| 212 | NAME: force_palette | ||
| 213 | TYPE: integer (Boolean) | ||
| 214 | DEFAULT: 0 (off) | ||
| 215 | DESC: Forces the palette (color format) to a specific value. If an | ||
| 216 | application requests a different palette, it will be rejected, thereby | ||
| 217 | forcing it to try others until it succeeds. This is useful for forcing | ||
| 218 | greyscale mode with a color camera, for example. Supported modes are: | ||
| 219 | 0 (Allows all the following formats) | ||
| 220 | 1 VIDEO_PALETTE_GREY (Linear greyscale) | ||
| 221 | 10 VIDEO_PALETTE_YUV420 (YUV 4:2:0 Planar) | ||
| 222 | 15 VIDEO_PALETTE_YUV420P (YUV 4:2:0 Planar, same as 10) | ||
| 223 | |||
| 224 | NAME: backlight | ||
| 225 | TYPE: integer (Boolean) | ||
| 226 | DEFAULT: 0 (off) | ||
| 227 | DESC: Setting this flag changes the exposure algorithm for OmniVision sensors | ||
| 228 | such that objects in the camera's view (i.e. your head) can be clearly | ||
| 229 | seen when they are illuminated from behind. It reduces or eliminates | ||
| 230 | the sensor's auto-exposure function, so it should only be used when | ||
| 231 | needed. Additionally, it is only supported with the OV6620 and OV7620. | ||
| 232 | |||
| 233 | NAME: unit_video | ||
| 234 | TYPE: Up to 16 comma-separated integers | ||
| 235 | DEFAULT: 0,0,0... (automatically assign the next available minor(s)) | ||
| 236 | DESC: You can specify up to 16 minor numbers to be assigned to ov511 devices. | ||
| 237 | For example, "unit_video=1,3" will make the driver use /dev/video1 and | ||
| 238 | /dev/video3 for the first two devices it detects. Additional devices | ||
| 239 | will be assigned automatically starting at the first available device | ||
| 240 | node (/dev/video0 in this case). Note that you cannot specify 0 as a | ||
| 241 | minor number. This feature requires kernel version 2.4.5 or higher. | ||
| 242 | |||
| 243 | NAME: remove_zeros | ||
| 244 | TYPE: integer (Boolean) | ||
| 245 | DEFAULT: 0 (do not skip any incoming data) | ||
| 246 | DESC: Setting this to 1 will remove zero-padding from incoming data. This | ||
| 247 | will compensate for the blocks of corruption that can appear when the | ||
| 248 | camera cannot keep up with the speed of the USB bus (eg. at low frame | ||
| 249 | resolutions). This feature is always enabled when compression is on. | ||
| 250 | |||
| 251 | NAME: mirror | ||
| 252 | TYPE: integer (Boolean) | ||
| 253 | DEFAULT: 0 (off) | ||
| 254 | DESC: Setting this to 1 will reverse ("mirror") the image horizontally. This | ||
| 255 | might be necessary if your camera has a custom lens assembly. This has | ||
| 256 | no effect with video capture devices. | ||
| 257 | |||
| 258 | NAME: ov518_color | ||
| 259 | TYPE: integer (Boolean) | ||
| 260 | DEFAULT: 0 (off) | ||
| 261 | DESC: Enable OV518 color support. This is off by default since it doesn't | ||
| 262 | work most of the time. If you want to try it, you must also load | ||
| 263 | ov518_decomp with the "nouv=0" parameter. If you get improper colors or | ||
| 264 | diagonal lines through the image, restart your video app and try again. | ||
| 265 | Repeat as necessary. | ||
| 266 | |||
| 267 | WORKING FEATURES: | ||
| 268 | o Color streaming/capture at most widths and heights that are multiples of 8. | ||
| 269 | o Monochrome (use force_palette=1 to enable) | ||
| 270 | o Setting/getting of saturation, contrast, brightness, and hue (only some of | ||
| 271 | them work the OV7620 and OV7620AE) | ||
| 272 | o /proc status reporting | ||
| 273 | o SAA7111A video capture support at 320x240 and 640x480 | ||
| 274 | o Compression support | ||
| 275 | o SMP compatibility | ||
| 276 | |||
| 277 | HOW TO CONTACT ME: | ||
| 278 | |||
| 279 | You can email me at mark@alpha.dyndns.org . Please prefix the subject line | ||
| 280 | with "OV511: " so that I am certain to notice your message. | ||
| 281 | |||
| 282 | CREDITS: | ||
| 283 | |||
| 284 | The code is based in no small part on the CPiA driver by Johannes Erdfelt, | ||
| 285 | Randy Dunlap, and others. Big thanks to them for their pioneering work on that | ||
| 286 | and the USB stack. Thanks to Bret Wallach for getting camera reg IO, ISOC, and | ||
| 287 | image capture working. Thanks to Orion Sky Lawlor, Kevin Moore, and Claudio | ||
| 288 | Matsuoka for their work as well. | ||
diff --git a/Documentation/video4linux/se401.txt b/Documentation/video4linux/se401.txt deleted file mode 100644 index bd6526ec8dd7..000000000000 --- a/Documentation/video4linux/se401.txt +++ /dev/null | |||
| @@ -1,54 +0,0 @@ | |||
| 1 | Linux driver for SE401 based USB cameras | ||
| 2 | |||
| 3 | Copyright, 2001, Jeroen Vreeken | ||
| 4 | |||
| 5 | |||
| 6 | INTRODUCTION: | ||
| 7 | |||
| 8 | The SE401 chip is the used in low-cost usb webcams. | ||
| 9 | It is produced by Endpoints Inc. (www.endpoints.com). | ||
| 10 | It interfaces directly to a cmos image sensor and USB. The only other major | ||
| 11 | part in a se401 based camera is a dram chip. | ||
| 12 | |||
| 13 | The following cameras are known to work with this driver: | ||
| 14 | |||
| 15 | Aox se401 (non-branded) cameras | ||
| 16 | Philips PVCV665 USB VGA webcam 'Vesta Fun' | ||
| 17 | Kensington VideoCAM PC Camera Model 67014 | ||
| 18 | Kensington VideoCAM PC Camera Model 67015 | ||
| 19 | Kensington VideoCAM PC Camera Model 67016 | ||
| 20 | Kensington VideoCAM PC Camera Model 67017 | ||
| 21 | |||
| 22 | |||
| 23 | WHAT YOU NEED: | ||
| 24 | |||
| 25 | - USB support | ||
| 26 | - VIDEO4LINUX support | ||
| 27 | |||
| 28 | More information about USB support for linux can be found at: | ||
| 29 | http://www.linux-usb.org | ||
| 30 | |||
| 31 | |||
| 32 | MODULE OPTIONS: | ||
| 33 | |||
| 34 | When the driver is compiled as a module you can also use the 'flickerless' | ||
| 35 | option. With it exposure is limited to values that do not interfere with the | ||
| 36 | net frequency. Valid options for this option are 0, 50 and 60. (0=disable, | ||
| 37 | 50=50hz, 60=60hz) | ||
| 38 | |||
| 39 | |||
| 40 | KNOWN PROBLEMS: | ||
| 41 | |||
| 42 | The driver works fine with the usb-ohci and uhci host controller drivers, | ||
| 43 | the default settings also work with usb-uhci. But sending more than one bulk | ||
| 44 | transfer at a time with usb-uhci doesn't work yet. | ||
| 45 | Users of usb-ohci and uhci can safely enlarge SE401_NUMSBUF in se401.h in | ||
| 46 | order to increase the throughput (and thus framerate). | ||
| 47 | |||
| 48 | |||
| 49 | HELP: | ||
| 50 | |||
| 51 | The latest info on this driver can be found at: | ||
| 52 | http://members.chello.nl/~j.vreeken/se401/ | ||
| 53 | And questions to me can be send to: | ||
| 54 | pe1rxq@amsat.org | ||
diff --git a/Documentation/video4linux/soc-camera.txt b/Documentation/video4linux/soc-camera.txt index 3f87c7da4ca2..f62fcdbc8b9f 100644 --- a/Documentation/video4linux/soc-camera.txt +++ b/Documentation/video4linux/soc-camera.txt | |||
| @@ -9,32 +9,36 @@ The following terms are used in this document: | |||
| 9 | of connecting to a variety of systems and interfaces, typically uses i2c for | 9 | of connecting to a variety of systems and interfaces, typically uses i2c for |
| 10 | control and configuration, and a parallel or a serial bus for data. | 10 | control and configuration, and a parallel or a serial bus for data. |
| 11 | - camera host - an interface, to which a camera is connected. Typically a | 11 | - camera host - an interface, to which a camera is connected. Typically a |
| 12 | specialised interface, present on many SoCs, e.g., PXA27x and PXA3xx, SuperH, | 12 | specialised interface, present on many SoCs, e.g. PXA27x and PXA3xx, SuperH, |
| 13 | AVR32, i.MX27, i.MX31. | 13 | AVR32, i.MX27, i.MX31. |
| 14 | - camera host bus - a connection between a camera host and a camera. Can be | 14 | - camera host bus - a connection between a camera host and a camera. Can be |
| 15 | parallel or serial, consists of data and control lines, e.g., clock, vertical | 15 | parallel or serial, consists of data and control lines, e.g. clock, vertical |
| 16 | and horizontal synchronization signals. | 16 | and horizontal synchronization signals. |
| 17 | 17 | ||
| 18 | Purpose of the soc-camera subsystem | 18 | Purpose of the soc-camera subsystem |
| 19 | ----------------------------------- | 19 | ----------------------------------- |
| 20 | 20 | ||
| 21 | The soc-camera subsystem provides a unified API between camera host drivers and | 21 | The soc-camera subsystem initially provided a unified API between camera host |
| 22 | camera sensor drivers. It implements a V4L2 interface to the user, currently | 22 | drivers and camera sensor drivers. Later the soc-camera sensor API has been |
| 23 | only the mmap method is supported. | 23 | replaced with the V4L2 standard subdev API. This also made camera driver re-use |
| 24 | with non-soc-camera hosts possible. The camera host API to the soc-camera core | ||
| 25 | has been preserved. | ||
| 24 | 26 | ||
| 25 | This subsystem has been written to connect drivers for System-on-Chip (SoC) | 27 | Soc-camera implements a V4L2 interface to the user, currently only the "mmap" |
| 26 | video capture interfaces with drivers for CMOS camera sensor chips to enable | 28 | method is supported by host drivers. However, the soc-camera core also provides |
| 27 | the reuse of sensor drivers with various hosts. The subsystem has been designed | 29 | support for the "read" method. |
| 28 | to support multiple camera host interfaces and multiple cameras per interface, | 30 | |
| 29 | although most applications have only one camera sensor. | 31 | The subsystem has been designed to support multiple camera host interfaces and |
| 32 | multiple cameras per interface, although most applications have only one camera | ||
| 33 | sensor. | ||
| 30 | 34 | ||
| 31 | Existing drivers | 35 | Existing drivers |
| 32 | ---------------- | 36 | ---------------- |
| 33 | 37 | ||
| 34 | As of 2.6.27-rc4 there are two host drivers in the mainline: pxa_camera.c for | 38 | As of 3.7 there are seven host drivers in the mainline: atmel-isi.c, |
| 35 | PXA27x SoCs and sh_mobile_ceu_camera.c for SuperH SoCs, and four sensor drivers: | 39 | mx1_camera.c (broken, scheduled for removal), mx2_camera.c, mx3_camera.c, |
| 36 | mt9m001.c, mt9m111.c, mt9v022.c and a generic soc_camera_platform.c driver. This | 40 | omap1_camera.c, pxa_camera.c, sh_mobile_ceu_camera.c, and multiple sensor |
| 37 | list is not supposed to be updated, look for more examples in your tree. | 41 | drivers under drivers/media/i2c/soc_camera/. |
| 38 | 42 | ||
| 39 | Camera host API | 43 | Camera host API |
| 40 | --------------- | 44 | --------------- |
| @@ -45,38 +49,37 @@ soc_camera_host_register(struct soc_camera_host *); | |||
| 45 | 49 | ||
| 46 | function. The host object can be initialized as follows: | 50 | function. The host object can be initialized as follows: |
| 47 | 51 | ||
| 48 | static struct soc_camera_host pxa_soc_camera_host = { | 52 | struct soc_camera_host *ici; |
| 49 | .drv_name = PXA_CAM_DRV_NAME, | 53 | ici->drv_name = DRV_NAME; |
| 50 | .ops = &pxa_soc_camera_host_ops, | 54 | ici->ops = &camera_host_ops; |
| 51 | }; | 55 | ici->priv = pcdev; |
| 56 | ici->v4l2_dev.dev = &pdev->dev; | ||
| 57 | ici->nr = pdev->id; | ||
| 52 | 58 | ||
| 53 | All camera host methods are passed in a struct soc_camera_host_ops: | 59 | All camera host methods are passed in a struct soc_camera_host_ops: |
| 54 | 60 | ||
| 55 | static struct soc_camera_host_ops pxa_soc_camera_host_ops = { | 61 | static struct soc_camera_host_ops camera_host_ops = { |
| 56 | .owner = THIS_MODULE, | 62 | .owner = THIS_MODULE, |
| 57 | .add = pxa_camera_add_device, | 63 | .add = camera_add_device, |
| 58 | .remove = pxa_camera_remove_device, | 64 | .remove = camera_remove_device, |
| 59 | .suspend = pxa_camera_suspend, | 65 | .set_fmt = camera_set_fmt_cap, |
| 60 | .resume = pxa_camera_resume, | 66 | .try_fmt = camera_try_fmt_cap, |
| 61 | .set_fmt_cap = pxa_camera_set_fmt_cap, | 67 | .init_videobuf2 = camera_init_videobuf2, |
| 62 | .try_fmt_cap = pxa_camera_try_fmt_cap, | 68 | .poll = camera_poll, |
| 63 | .init_videobuf = pxa_camera_init_videobuf, | 69 | .querycap = camera_querycap, |
| 64 | .reqbufs = pxa_camera_reqbufs, | 70 | .set_bus_param = camera_set_bus_param, |
| 65 | .poll = pxa_camera_poll, | 71 | /* The rest of host operations are optional */ |
| 66 | .querycap = pxa_camera_querycap, | ||
| 67 | .try_bus_param = pxa_camera_try_bus_param, | ||
| 68 | .set_bus_param = pxa_camera_set_bus_param, | ||
| 69 | }; | 72 | }; |
| 70 | 73 | ||
| 71 | .add and .remove methods are called when a sensor is attached to or detached | 74 | .add and .remove methods are called when a sensor is attached to or detached |
| 72 | from the host, apart from performing host-internal tasks they shall also call | 75 | from the host. .set_bus_param is used to configure physical connection |
| 73 | sensor driver's .init and .release methods respectively. .suspend and .resume | 76 | parameters between the host and the sensor. .init_videobuf2 is called by |
| 74 | methods implement host's power-management functionality and its their | 77 | soc-camera core when a video-device is opened, the host driver would typically |
| 75 | responsibility to call respective sensor's methods. .try_bus_param and | 78 | call vb2_queue_init() in this method. Further video-buffer management is |
| 76 | .set_bus_param are used to negotiate physical connection parameters between the | 79 | implemented completely by the specific camera host driver. If the host driver |
| 77 | host and the sensor. .init_videobuf is called by soc-camera core when a | 80 | supports non-standard pixel format conversion, it should implement a |
| 78 | video-device is opened, further video-buffer management is implemented completely | 81 | .get_formats and, possibly, a .put_formats operations. See below for more |
| 79 | by the specific camera host driver. The rest of the methods are called from | 82 | details about format conversion. The rest of the methods are called from |
| 80 | respective V4L2 operations. | 83 | respective V4L2 operations. |
| 81 | 84 | ||
| 82 | Camera API | 85 | Camera API |
| @@ -84,37 +87,21 @@ Camera API | |||
| 84 | 87 | ||
| 85 | Sensor drivers can use struct soc_camera_link, typically provided by the | 88 | Sensor drivers can use struct soc_camera_link, typically provided by the |
| 86 | platform, and used to specify to which camera host bus the sensor is connected, | 89 | platform, and used to specify to which camera host bus the sensor is connected, |
| 87 | and arbitrarily provide platform .power and .reset methods for the camera. | 90 | and optionally provide platform .power and .reset methods for the camera. This |
| 88 | soc_camera_device_register() and soc_camera_device_unregister() functions are | 91 | struct is provided to the camera driver via the I2C client device platform data |
| 89 | used to add a sensor driver to or remove one from the system. The registration | 92 | and can be obtained, using the soc_camera_i2c_to_link() macro. Care should be |
| 90 | function takes a pointer to struct soc_camera_device as the only parameter. | 93 | taken, when using soc_camera_vdev_to_subdev() and when accessing struct |
| 91 | This struct can be initialized as follows: | 94 | soc_camera_device, using v4l2_get_subdev_hostdata(): both only work, when |
| 92 | 95 | running on an soc-camera host. The actual camera driver operation is implemented | |
| 93 | /* link to driver operations */ | 96 | using the V4L2 subdev API. Additionally soc-camera camera drivers can use |
| 94 | icd->ops = &mt9m001_ops; | 97 | auxiliary soc-camera helper functions like soc_camera_power_on() and |
| 95 | /* link to the underlying physical (e.g., i2c) device */ | 98 | soc_camera_power_off(), which switch regulators, provided by the platform and call |
| 96 | icd->control = &client->dev; | 99 | board-specific power switching methods. soc_camera_apply_board_flags() takes |
| 97 | /* window geometry */ | 100 | camera bus configuration capability flags and applies any board transformations, |
| 98 | icd->x_min = 20; | 101 | e.g. signal polarity inversion. soc_mbus_get_fmtdesc() can be used to obtain a |
| 99 | icd->y_min = 12; | 102 | pixel format descriptor, corresponding to a certain media-bus pixel format code. |
| 100 | icd->x_current = 20; | 103 | soc_camera_limit_side() can be used to restrict beginning and length of a frame |
| 101 | icd->y_current = 12; | 104 | side, based on camera capabilities. |
| 102 | icd->width_min = 48; | ||
| 103 | icd->width_max = 1280; | ||
| 104 | icd->height_min = 32; | ||
| 105 | icd->height_max = 1024; | ||
| 106 | icd->y_skip_top = 1; | ||
| 107 | /* camera bus ID, typically obtained from platform data */ | ||
| 108 | icd->iface = icl->bus_id; | ||
| 109 | |||
| 110 | struct soc_camera_ops provides .probe and .remove methods, which are called by | ||
| 111 | the soc-camera core, when a camera is matched against or removed from a camera | ||
| 112 | host bus, .init, .release, .suspend, and .resume are called from the camera host | ||
| 113 | driver as discussed above. Other members of this struct provide respective V4L2 | ||
| 114 | functionality. | ||
| 115 | |||
| 116 | struct soc_camera_device also links to an array of struct soc_camera_data_format, | ||
| 117 | listing pixel formats, supported by the camera. | ||
| 118 | 105 | ||
| 119 | VIDIOC_S_CROP and VIDIOC_S_FMT behaviour | 106 | VIDIOC_S_CROP and VIDIOC_S_FMT behaviour |
| 120 | ---------------------------------------- | 107 | ---------------------------------------- |
| @@ -153,8 +140,25 @@ implemented. | |||
| 153 | User window geometry is kept in .user_width and .user_height fields in struct | 140 | User window geometry is kept in .user_width and .user_height fields in struct |
| 154 | soc_camera_device and used by the soc-camera core and host drivers. The core | 141 | soc_camera_device and used by the soc-camera core and host drivers. The core |
| 155 | updates these fields upon successful completion of a .s_fmt() call, but if these | 142 | updates these fields upon successful completion of a .s_fmt() call, but if these |
| 156 | fields change elsewhere, e.g., during .s_crop() processing, the host driver is | 143 | fields change elsewhere, e.g. during .s_crop() processing, the host driver is |
| 157 | responsible for updating them. | 144 | responsible for updating them. |
| 158 | 145 | ||
| 146 | Format conversion | ||
| 147 | ----------------- | ||
| 148 | |||
| 149 | V4L2 distinguishes between pixel formats, as they are stored in memory, and as | ||
| 150 | they are transferred over a media bus. Soc-camera provides support to | ||
| 151 | conveniently manage these formats. A table of standard transformations is | ||
| 152 | maintained by soc-camera core, which describes, what FOURCC pixel format will | ||
| 153 | be obtained, if a media-bus pixel format is stored in memory according to | ||
| 154 | certain rules. E.g. if V4L2_MBUS_FMT_YUYV8_2X8 data is sampled with 8 bits per | ||
| 155 | sample and stored in memory in the little-endian order with no gaps between | ||
| 156 | bytes, data in memory will represent the V4L2_PIX_FMT_YUYV FOURCC format. These | ||
| 157 | standard transformations will be used by soc-camera or by camera host drivers to | ||
| 158 | configure camera drivers to produce the FOURCC format, requested by the user, | ||
| 159 | using the VIDIOC_S_FMT ioctl(). Apart from those standard format conversions, | ||
| 160 | host drivers can also provide their own conversion rules by implementing a | ||
| 161 | .get_formats and, if required, a .put_formats methods. | ||
| 162 | |||
| 159 | -- | 163 | -- |
| 160 | Author: Guennadi Liakhovetski <g.liakhovetski@gmx.de> | 164 | Author: Guennadi Liakhovetski <g.liakhovetski@gmx.de> |
diff --git a/Documentation/video4linux/stv680.txt b/Documentation/video4linux/stv680.txt deleted file mode 100644 index e3de33645308..000000000000 --- a/Documentation/video4linux/stv680.txt +++ /dev/null | |||
| @@ -1,53 +0,0 @@ | |||
| 1 | Linux driver for STV0680 based USB cameras | ||
| 2 | |||
| 3 | Copyright, 2001, Kevin Sisson | ||
| 4 | |||
| 5 | |||
| 6 | INTRODUCTION: | ||
| 7 | |||
| 8 | STMicroelectronics produces the STV0680B chip, which comes in two | ||
| 9 | types, -001 and -003. The -003 version allows the recording and downloading | ||
| 10 | of sound clips from the camera, and allows a flash attachment. Otherwise, | ||
| 11 | it uses the same commands as the -001 version. Both versions support a | ||
| 12 | variety of SDRAM sizes and sensors, allowing for a maximum of 26 VGA or 20 | ||
| 13 | CIF pictures. The STV0680 supports either a serial or a usb interface, and | ||
| 14 | video is possible through the usb interface. | ||
| 15 | |||
| 16 | The following cameras are known to work with this driver, although any | ||
| 17 | camera with Vendor/Product codes of 0553/0202 should work: | ||
| 18 | |||
| 19 | Aiptek Pencam (various models) | ||
| 20 | Nisis QuickPix 2 | ||
| 21 | Radio Shack 'Kid's digital camera' (#60-1207) | ||
| 22 | At least one Trust Spycam model | ||
| 23 | Several other European brand models | ||
| 24 | |||
| 25 | WHAT YOU NEED: | ||
| 26 | |||
| 27 | - USB support | ||
| 28 | - VIDEO4LINUX support | ||
| 29 | |||
| 30 | More information about USB support for linux can be found at: | ||
| 31 | http://www.linux-usb.org | ||
| 32 | |||
| 33 | |||
| 34 | MODULE OPTIONS: | ||
| 35 | |||
| 36 | When the driver is compiled as a module, you can set a "swapRGB=1" | ||
| 37 | option, if necessary, for those applications that require it | ||
| 38 | (such as xawtv). However, the driver should detect and set this | ||
| 39 | automatically, so this option should not normally be used. | ||
| 40 | |||
| 41 | |||
| 42 | KNOWN PROBLEMS: | ||
| 43 | |||
| 44 | The driver seems to work better with the usb-ohci than the usb-uhci host | ||
| 45 | controller driver. | ||
| 46 | |||
| 47 | HELP: | ||
| 48 | |||
| 49 | The latest info on this driver can be found at: | ||
| 50 | http://personal.clt.bellsouth.net/~kjsisson or at | ||
| 51 | http://stv0680-usb.sourceforge.net | ||
| 52 | |||
| 53 | Any questions to me can be send to: kjsisson@bellsouth.net | ||
diff --git a/Documentation/video4linux/v4l2-framework.txt b/Documentation/video4linux/v4l2-framework.txt index 32bfe926e8d7..0a1ef671c9d4 100644 --- a/Documentation/video4linux/v4l2-framework.txt +++ b/Documentation/video4linux/v4l2-framework.txt | |||
| @@ -68,8 +68,7 @@ Structure of the framework | |||
| 68 | The framework closely resembles the driver structure: it has a v4l2_device | 68 | The framework closely resembles the driver structure: it has a v4l2_device |
| 69 | struct for the device instance data, a v4l2_subdev struct to refer to | 69 | struct for the device instance data, a v4l2_subdev struct to refer to |
| 70 | sub-device instances, the video_device struct stores V4L2 device node data | 70 | sub-device instances, the video_device struct stores V4L2 device node data |
| 71 | and in the future a v4l2_fh struct will keep track of filehandle instances | 71 | and the v4l2_fh struct keeps track of filehandle instances. |
| 72 | (this is not yet implemented). | ||
| 73 | 72 | ||
| 74 | The V4L2 framework also optionally integrates with the media framework. If a | 73 | The V4L2 framework also optionally integrates with the media framework. If a |
| 75 | driver sets the struct v4l2_device mdev field, sub-devices and video nodes | 74 | driver sets the struct v4l2_device mdev field, sub-devices and video nodes |
diff --git a/Documentation/video4linux/w9968cf.txt b/Documentation/video4linux/w9968cf.txt deleted file mode 100644 index 9649450f3b90..000000000000 --- a/Documentation/video4linux/w9968cf.txt +++ /dev/null | |||
| @@ -1,458 +0,0 @@ | |||
| 1 | |||
| 2 | W996[87]CF JPEG USB Dual Mode Camera Chip | ||
| 3 | Driver for Linux 2.6 (basic version) | ||
| 4 | ========================================= | ||
| 5 | |||
| 6 | - Documentation - | ||
| 7 | |||
| 8 | |||
| 9 | Index | ||
| 10 | ===== | ||
| 11 | 1. Copyright | ||
| 12 | 2. Disclaimer | ||
| 13 | 3. License | ||
| 14 | 4. Overview | ||
| 15 | 5. Supported devices | ||
| 16 | 6. Module dependencies | ||
| 17 | 7. Module loading | ||
| 18 | 8. Module parameters | ||
| 19 | 9. Contact information | ||
| 20 | 10. Credits | ||
| 21 | |||
| 22 | |||
| 23 | 1. Copyright | ||
| 24 | ============ | ||
| 25 | Copyright (C) 2002-2004 by Luca Risolia <luca.risolia@studio.unibo.it> | ||
| 26 | |||
| 27 | |||
| 28 | 2. Disclaimer | ||
| 29 | ============= | ||
| 30 | Winbond is a trademark of Winbond Electronics Corporation. | ||
| 31 | This software is not sponsored or developed by Winbond. | ||
| 32 | |||
| 33 | |||
| 34 | 3. License | ||
| 35 | ========== | ||
| 36 | This program is free software; you can redistribute it and/or modify | ||
| 37 | it under the terms of the GNU General Public License as published by | ||
| 38 | the Free Software Foundation; either version 2 of the License, or | ||
| 39 | (at your option) any later version. | ||
| 40 | |||
| 41 | This program is distributed in the hope that it will be useful, | ||
| 42 | but WITHOUT ANY WARRANTY; without even the implied warranty of | ||
| 43 | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the | ||
| 44 | GNU General Public License for more details. | ||
| 45 | |||
| 46 | You should have received a copy of the GNU General Public License | ||
| 47 | along with this program; if not, write to the Free Software | ||
| 48 | Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. | ||
| 49 | |||
| 50 | |||
| 51 | 4. Overview | ||
| 52 | =========== | ||
| 53 | This driver supports the video streaming capabilities of the devices mounting | ||
| 54 | Winbond W9967CF and Winbond W9968CF JPEG USB Dual Mode Camera Chips. OV681 | ||
| 55 | based cameras should be supported as well. | ||
| 56 | |||
| 57 | The driver is divided into two modules: the basic one, "w9968cf", is needed for | ||
| 58 | the supported devices to work; the second one, "w9968cf-vpp", is an optional | ||
| 59 | module, which provides some useful video post-processing functions like video | ||
| 60 | decoding, up-scaling and colour conversions. | ||
| 61 | |||
| 62 | Note that the official kernels do neither include nor support the second | ||
| 63 | module for performance purposes. Therefore, it is always recommended to | ||
| 64 | download and install the latest and complete release of the driver, | ||
| 65 | replacing the existing one, if present. | ||
| 66 | |||
| 67 | The latest and full-featured version of the W996[87]CF driver can be found at: | ||
| 68 | http://www.linux-projects.org. Please refer to the documentation included in | ||
| 69 | that package, if you are going to use it. | ||
| 70 | |||
| 71 | Up to 32 cameras can be handled at the same time. They can be connected and | ||
| 72 | disconnected from the host many times without turning off the computer, if | ||
| 73 | your system supports the hotplug facility. | ||
| 74 | |||
| 75 | To change the default settings for each camera, many parameters can be passed | ||
| 76 | through command line when the module is loaded into memory. | ||
| 77 | |||
| 78 | The driver relies on the Video4Linux, USB and I2C core modules. It has been | ||
| 79 | designed to run properly on SMP systems as well. An additional module, | ||
| 80 | "ovcamchip", is mandatory; it provides support for some OmniVision image | ||
| 81 | sensors connected to the W996[87]CF chips; if found in the system, the module | ||
| 82 | will be automatically loaded by default (provided that the kernel has been | ||
| 83 | compiled with the automatic module loading option). | ||
| 84 | |||
| 85 | |||
| 86 | 5. Supported devices | ||
| 87 | ==================== | ||
| 88 | At the moment, known W996[87]CF and OV681 based devices are: | ||
| 89 | - Aroma Digi Pen VGA Dual Mode ADG-5000 (unknown image sensor) | ||
| 90 | - AVerMedia AVerTV USB (SAA7111A, Philips FI1216Mk2 tuner, PT2313L audio chip) | ||
| 91 | - Creative Labs Video Blaster WebCam Go (OmniVision OV7610 sensor) | ||
| 92 | - Creative Labs Video Blaster WebCam Go Plus (OmniVision OV7620 sensor) | ||
| 93 | - Lebon LDC-035A (unknown image sensor) | ||
| 94 | - Ezonics EZ-802 EZMega Cam (OmniVision OV8610C sensor) | ||
| 95 | - OmniVision OV8610-EDE (OmniVision OV8610 sensor) | ||
| 96 | - OPCOM Digi Pen VGA Dual Mode Pen Camera (unknown image sensor) | ||
| 97 | - Pretec Digi Pen-II (OmniVision OV7620 sensor) | ||
| 98 | - Pretec DigiPen-480 (OmniVision OV8610 sensor) | ||
| 99 | |||
| 100 | If you know any other W996[87]CF or OV681 based cameras, please contact me. | ||
| 101 | |||
| 102 | The list above does not imply that all those devices work with this driver: up | ||
| 103 | until now only webcams that have an image sensor supported by the "ovcamchip" | ||
| 104 | module work. Kernel messages will always tell you whether this is case. | ||
| 105 | |||
| 106 | Possible external microcontrollers of those webcams are not supported: this | ||
| 107 | means that still images cannot be downloaded from the device memory. | ||
| 108 | |||
| 109 | Furthermore, it's worth to note that I was only able to run tests on my | ||
| 110 | "Creative Labs Video Blaster WebCam Go". Donations of other models, for | ||
| 111 | additional testing and full support, would be much appreciated. | ||
| 112 | |||
| 113 | |||
| 114 | 6. Module dependencies | ||
| 115 | ====================== | ||
| 116 | For it to work properly, the driver needs kernel support for Video4Linux, USB | ||
| 117 | and I2C, and the "ovcamchip" module for the image sensor. Make sure you are not | ||
| 118 | actually using any external "ovcamchip" module, given that the W996[87]CF | ||
| 119 | driver depends on the version of the module present in the official kernels. | ||
| 120 | |||
| 121 | The following options of the kernel configuration file must be enabled and | ||
| 122 | corresponding modules must be compiled: | ||
| 123 | |||
| 124 | # Multimedia devices | ||
| 125 | # | ||
| 126 | CONFIG_VIDEO_DEV=m | ||
| 127 | |||
| 128 | # I2C support | ||
| 129 | # | ||
| 130 | CONFIG_I2C=m | ||
| 131 | |||
| 132 | The I2C core module can be compiled statically in the kernel as well. | ||
| 133 | |||
| 134 | # OmniVision Camera Chip support | ||
| 135 | # | ||
| 136 | CONFIG_VIDEO_OVCAMCHIP=m | ||
| 137 | |||
| 138 | # USB support | ||
| 139 | # | ||
| 140 | CONFIG_USB=m | ||
| 141 | |||
| 142 | In addition, depending on the hardware being used, only one of the modules | ||
| 143 | below is necessary: | ||
| 144 | |||
| 145 | # USB Host Controller Drivers | ||
| 146 | # | ||
| 147 | CONFIG_USB_EHCI_HCD=m | ||
| 148 | CONFIG_USB_UHCI_HCD=m | ||
| 149 | CONFIG_USB_OHCI_HCD=m | ||
| 150 | |||
| 151 | And finally: | ||
| 152 | |||
| 153 | # USB Multimedia devices | ||
| 154 | # | ||
| 155 | CONFIG_USB_W9968CF=m | ||
| 156 | |||
| 157 | |||
| 158 | 7. Module loading | ||
| 159 | ================= | ||
| 160 | To use the driver, it is necessary to load the "w9968cf" module into memory | ||
| 161 | after every other module required. | ||
| 162 | |||
| 163 | Loading can be done this way, from root: | ||
| 164 | |||
| 165 | [root@localhost home]# modprobe usbcore | ||
| 166 | [root@localhost home]# modprobe i2c-core | ||
| 167 | [root@localhost home]# modprobe videodev | ||
| 168 | [root@localhost home]# modprobe w9968cf | ||
| 169 | |||
| 170 | At this point the pertinent devices should be recognized: "dmesg" can be used | ||
| 171 | to analyze kernel messages: | ||
| 172 | |||
| 173 | [user@localhost home]$ dmesg | ||
| 174 | |||
| 175 | There are a lot of parameters the module can use to change the default | ||
| 176 | settings for each device. To list every possible parameter with a brief | ||
| 177 | explanation about them and which syntax to use, it is recommended to run the | ||
| 178 | "modinfo" command: | ||
| 179 | |||
| 180 | [root@locahost home]# modinfo w9968cf | ||
| 181 | |||
| 182 | |||
| 183 | 8. Module parameters | ||
| 184 | ==================== | ||
| 185 | Module parameters are listed below: | ||
| 186 | ------------------------------------------------------------------------------- | ||
| 187 | Name: ovmod_load | ||
| 188 | Type: bool | ||
| 189 | Syntax: <0|1> | ||
| 190 | Description: Automatic 'ovcamchip' module loading: 0 disabled, 1 enabled. | ||
| 191 | If enabled, 'insmod' searches for the required 'ovcamchip' | ||
| 192 | module in the system, according to its configuration, and | ||
| 193 | loads that module automatically. This action is performed as | ||
| 194 | once soon as the 'w9968cf' module is loaded into memory. | ||
| 195 | Default: 1 | ||
| 196 | ------------------------------------------------------------------------------- | ||
| 197 | Name: simcams | ||
| 198 | Type: int | ||
| 199 | Syntax: <n> | ||
| 200 | Description: Number of cameras allowed to stream simultaneously. | ||
| 201 | n may vary from 0 to 32. | ||
| 202 | Default: 32 | ||
| 203 | ------------------------------------------------------------------------------- | ||
| 204 | Name: video_nr | ||
| 205 | Type: int array (min = 0, max = 32) | ||
| 206 | Syntax: <-1|n[,...]> | ||
| 207 | Description: Specify V4L minor mode number. | ||
| 208 | -1 = use next available | ||
| 209 | n = use minor number n | ||
| 210 | You can specify up to 32 cameras this way. | ||
| 211 | For example: | ||
| 212 | video_nr=-1,2,-1 would assign minor number 2 to the second | ||
| 213 | recognized camera and use auto for the first one and for every | ||
| 214 | other camera. | ||
| 215 | Default: -1 | ||
| 216 | ------------------------------------------------------------------------------- | ||
| 217 | Name: packet_size | ||
| 218 | Type: int array (min = 0, max = 32) | ||
| 219 | Syntax: <n[,...]> | ||
| 220 | Description: Specify the maximum data payload size in bytes for alternate | ||
| 221 | settings, for each device. n is scaled between 63 and 1023. | ||
| 222 | Default: 1023 | ||
| 223 | ------------------------------------------------------------------------------- | ||
| 224 | Name: max_buffers | ||
| 225 | Type: int array (min = 0, max = 32) | ||
| 226 | Syntax: <n[,...]> | ||
| 227 | Description: For advanced users. | ||
| 228 | Specify the maximum number of video frame buffers to allocate | ||
| 229 | for each device, from 2 to 32. | ||
| 230 | Default: 2 | ||
| 231 | ------------------------------------------------------------------------------- | ||
| 232 | Name: double_buffer | ||
| 233 | Type: bool array (min = 0, max = 32) | ||
| 234 | Syntax: <0|1[,...]> | ||
| 235 | Description: Hardware double buffering: 0 disabled, 1 enabled. | ||
| 236 | It should be enabled if you want smooth video output: if you | ||
| 237 | obtain out of sync. video, disable it, or try to | ||
| 238 | decrease the 'clockdiv' module parameter value. | ||
| 239 | Default: 1 for every device. | ||
| 240 | ------------------------------------------------------------------------------- | ||
| 241 | Name: clamping | ||
| 242 | Type: bool array (min = 0, max = 32) | ||
| 243 | Syntax: <0|1[,...]> | ||
| 244 | Description: Video data clamping: 0 disabled, 1 enabled. | ||
| 245 | Default: 0 for every device. | ||
| 246 | ------------------------------------------------------------------------------- | ||
| 247 | Name: filter_type | ||
| 248 | Type: int array (min = 0, max = 32) | ||
| 249 | Syntax: <0|1|2[,...]> | ||
| 250 | Description: Video filter type. | ||
| 251 | 0 none, 1 (1-2-1) 3-tap filter, 2 (2-3-6-3-2) 5-tap filter. | ||
| 252 | The filter is used to reduce noise and aliasing artifacts | ||
| 253 | produced by the CCD or CMOS image sensor. | ||
| 254 | Default: 0 for every device. | ||
| 255 | ------------------------------------------------------------------------------- | ||
| 256 | Name: largeview | ||
| 257 | Type: bool array (min = 0, max = 32) | ||
| 258 | Syntax: <0|1[,...]> | ||
| 259 | Description: Large view: 0 disabled, 1 enabled. | ||
| 260 | Default: 1 for every device. | ||
| 261 | ------------------------------------------------------------------------------- | ||
| 262 | Name: upscaling | ||
| 263 | Type: bool array (min = 0, max = 32) | ||
| 264 | Syntax: <0|1[,...]> | ||
| 265 | Description: Software scaling (for non-compressed video only): | ||
| 266 | 0 disabled, 1 enabled. | ||
| 267 | Disable it if you have a slow CPU or you don't have enough | ||
| 268 | memory. | ||
| 269 | Default: 0 for every device. | ||
| 270 | Note: If 'w9968cf-vpp' is not present, this parameter is set to 0. | ||
| 271 | ------------------------------------------------------------------------------- | ||
| 272 | Name: decompression | ||
| 273 | Type: int array (min = 0, max = 32) | ||
| 274 | Syntax: <0|1|2[,...]> | ||
| 275 | Description: Software video decompression: | ||
| 276 | 0 = disables decompression | ||
| 277 | (doesn't allow formats needing decompression). | ||
| 278 | 1 = forces decompression | ||
| 279 | (allows formats needing decompression only). | ||
| 280 | 2 = allows any permitted formats. | ||
| 281 | Formats supporting (de)compressed video are YUV422P and | ||
| 282 | YUV420P/YUV420 in any resolutions where width and height are | ||
| 283 | multiples of 16. | ||
| 284 | Default: 2 for every device. | ||
| 285 | Note: If 'w9968cf-vpp' is not present, forcing decompression is not | ||
| 286 | allowed; in this case this parameter is set to 2. | ||
| 287 | ------------------------------------------------------------------------------- | ||
| 288 | Name: force_palette | ||
| 289 | Type: int array (min = 0, max = 32) | ||
| 290 | Syntax: <0|9|10|13|15|8|7|1|6|3|4|5[,...]> | ||
| 291 | Description: Force picture palette. | ||
| 292 | In order: | ||
| 293 | 0 = Off - allows any of the following formats: | ||
| 294 | 9 = UYVY 16 bpp - Original video, compression disabled | ||
| 295 | 10 = YUV420 12 bpp - Original video, compression enabled | ||
| 296 | 13 = YUV422P 16 bpp - Original video, compression enabled | ||
| 297 | 15 = YUV420P 12 bpp - Original video, compression enabled | ||
| 298 | 8 = YUVY 16 bpp - Software conversion from UYVY | ||
| 299 | 7 = YUV422 16 bpp - Software conversion from UYVY | ||
| 300 | 1 = GREY 8 bpp - Software conversion from UYVY | ||
| 301 | 6 = RGB555 16 bpp - Software conversion from UYVY | ||
| 302 | 3 = RGB565 16 bpp - Software conversion from UYVY | ||
| 303 | 4 = RGB24 24 bpp - Software conversion from UYVY | ||
| 304 | 5 = RGB32 32 bpp - Software conversion from UYVY | ||
| 305 | When not 0, this parameter will override 'decompression'. | ||
| 306 | Default: 0 for every device. Initial palette is 9 (UYVY). | ||
| 307 | Note: If 'w9968cf-vpp' is not present, this parameter is set to 9. | ||
| 308 | ------------------------------------------------------------------------------- | ||
| 309 | Name: force_rgb | ||
| 310 | Type: bool array (min = 0, max = 32) | ||
| 311 | Syntax: <0|1[,...]> | ||
| 312 | Description: Read RGB video data instead of BGR: | ||
| 313 | 1 = use RGB component ordering. | ||
| 314 | 0 = use BGR component ordering. | ||
| 315 | This parameter has effect when using RGBX palettes only. | ||
| 316 | Default: 0 for every device. | ||
| 317 | ------------------------------------------------------------------------------- | ||
| 318 | Name: autobright | ||
| 319 | Type: bool array (min = 0, max = 32) | ||
| 320 | Syntax: <0|1[,...]> | ||
| 321 | Description: Image sensor automatically changes brightness: | ||
| 322 | 0 = no, 1 = yes | ||
| 323 | Default: 0 for every device. | ||
| 324 | ------------------------------------------------------------------------------- | ||
| 325 | Name: autoexp | ||
| 326 | Type: bool array (min = 0, max = 32) | ||
| 327 | Syntax: <0|1[,...]> | ||
| 328 | Description: Image sensor automatically changes exposure: | ||
| 329 | 0 = no, 1 = yes | ||
| 330 | Default: 1 for every device. | ||
| 331 | ------------------------------------------------------------------------------- | ||
| 332 | Name: lightfreq | ||
| 333 | Type: int array (min = 0, max = 32) | ||
| 334 | Syntax: <50|60[,...]> | ||
| 335 | Description: Light frequency in Hz: | ||
| 336 | 50 for European and Asian lighting, 60 for American lighting. | ||
| 337 | Default: 50 for every device. | ||
| 338 | ------------------------------------------------------------------------------- | ||
| 339 | Name: bandingfilter | ||
| 340 | Type: bool array (min = 0, max = 32) | ||
| 341 | Syntax: <0|1[,...]> | ||
| 342 | Description: Banding filter to reduce effects of fluorescent | ||
| 343 | lighting: | ||
| 344 | 0 disabled, 1 enabled. | ||
| 345 | This filter tries to reduce the pattern of horizontal | ||
| 346 | light/dark bands caused by some (usually fluorescent) lighting. | ||
| 347 | Default: 0 for every device. | ||
| 348 | ------------------------------------------------------------------------------- | ||
| 349 | Name: clockdiv | ||
| 350 | Type: int array (min = 0, max = 32) | ||
| 351 | Syntax: <-1|n[,...]> | ||
| 352 | Description: Force pixel clock divisor to a specific value (for experts): | ||
| 353 | n may vary from 0 to 127. | ||
| 354 | -1 for automatic value. | ||
| 355 | See also the 'double_buffer' module parameter. | ||
| 356 | Default: -1 for every device. | ||
| 357 | ------------------------------------------------------------------------------- | ||
| 358 | Name: backlight | ||
| 359 | Type: bool array (min = 0, max = 32) | ||
| 360 | Syntax: <0|1[,...]> | ||
| 361 | Description: Objects are lit from behind: | ||
| 362 | 0 = no, 1 = yes | ||
| 363 | Default: 0 for every device. | ||
| 364 | ------------------------------------------------------------------------------- | ||
| 365 | Name: mirror | ||
| 366 | Type: bool array (min = 0, max = 32) | ||
| 367 | Syntax: <0|1[,...]> | ||
| 368 | Description: Reverse image horizontally: | ||
| 369 | 0 = no, 1 = yes | ||
| 370 | Default: 0 for every device. | ||
| 371 | ------------------------------------------------------------------------------- | ||
| 372 | Name: monochrome | ||
| 373 | Type: bool array (min = 0, max = 32) | ||
| 374 | Syntax: <0|1[,...]> | ||
| 375 | Description: The image sensor is monochrome: | ||
| 376 | 0 = no, 1 = yes | ||
| 377 | Default: 0 for every device. | ||
| 378 | ------------------------------------------------------------------------------- | ||
| 379 | Name: brightness | ||
| 380 | Type: long array (min = 0, max = 32) | ||
| 381 | Syntax: <n[,...]> | ||
| 382 | Description: Set picture brightness (0-65535). | ||
| 383 | This parameter has no effect if 'autobright' is enabled. | ||
| 384 | Default: 31000 for every device. | ||
| 385 | ------------------------------------------------------------------------------- | ||
| 386 | Name: hue | ||
| 387 | Type: long array (min = 0, max = 32) | ||
| 388 | Syntax: <n[,...]> | ||
| 389 | Description: Set picture hue (0-65535). | ||
| 390 | Default: 32768 for every device. | ||
| 391 | ------------------------------------------------------------------------------- | ||
| 392 | Name: colour | ||
| 393 | Type: long array (min = 0, max = 32) | ||
| 394 | Syntax: <n[,...]> | ||
| 395 | Description: Set picture saturation (0-65535). | ||
| 396 | Default: 32768 for every device. | ||
| 397 | ------------------------------------------------------------------------------- | ||
| 398 | Name: contrast | ||
| 399 | Type: long array (min = 0, max = 32) | ||
| 400 | Syntax: <n[,...]> | ||
| 401 | Description: Set picture contrast (0-65535). | ||
| 402 | Default: 50000 for every device. | ||
| 403 | ------------------------------------------------------------------------------- | ||
| 404 | Name: whiteness | ||
| 405 | Type: long array (min = 0, max = 32) | ||
| 406 | Syntax: <n[,...]> | ||
| 407 | Description: Set picture whiteness (0-65535). | ||
| 408 | Default: 32768 for every device. | ||
| 409 | ------------------------------------------------------------------------------- | ||
| 410 | Name: debug | ||
| 411 | Type: int | ||
| 412 | Syntax: <n> | ||
| 413 | Description: Debugging information level, from 0 to 6: | ||
| 414 | 0 = none (use carefully) | ||
| 415 | 1 = critical errors | ||
| 416 | 2 = significant information | ||
| 417 | 3 = configuration or general messages | ||
| 418 | 4 = warnings | ||
| 419 | 5 = called functions | ||
| 420 | 6 = function internals | ||
| 421 | Level 5 and 6 are useful for testing only, when only one | ||
| 422 | device is used. | ||
| 423 | Default: 2 | ||
| 424 | ------------------------------------------------------------------------------- | ||
| 425 | Name: specific_debug | ||
| 426 | Type: bool | ||
| 427 | Syntax: <0|1> | ||
| 428 | Description: Enable or disable specific debugging messages: | ||
| 429 | 0 = print messages concerning every level <= 'debug' level. | ||
| 430 | 1 = print messages concerning the level indicated by 'debug'. | ||
| 431 | Default: 0 | ||
| 432 | ------------------------------------------------------------------------------- | ||
| 433 | |||
| 434 | |||
| 435 | 9. Contact information | ||
| 436 | ====================== | ||
| 437 | I may be contacted by e-mail at <luca.risolia@studio.unibo.it>. | ||
| 438 | |||
| 439 | I can accept GPG/PGP encrypted e-mail. My GPG key ID is 'FCE635A4'. | ||
| 440 | My public 1024-bit key should be available at your keyserver; the fingerprint | ||
| 441 | is: '88E8 F32F 7244 68BA 3958 5D40 99DA 5D2A FCE6 35A4'. | ||
| 442 | |||
| 443 | |||
| 444 | 10. Credits | ||
| 445 | ========== | ||
| 446 | The development would not have proceed much further without having looked at | ||
| 447 | the source code of other drivers and without the help of several persons; in | ||
| 448 | particular: | ||
| 449 | |||
| 450 | - the I2C interface to kernel and high-level image sensor control routines have | ||
| 451 | been taken from the OV511 driver by Mark McClelland; | ||
| 452 | |||
| 453 | - memory management code has been copied from the bttv driver by Ralph Metzler, | ||
| 454 | Marcus Metzler and Gerd Knorr; | ||
| 455 | |||
| 456 | - the low-level I2C read function has been written by Frederic Jouault; | ||
| 457 | |||
| 458 | - the low-level I2C fast write function has been written by Piotr Czerczak. | ||
diff --git a/Documentation/video4linux/zc0301.txt b/Documentation/video4linux/zc0301.txt deleted file mode 100644 index b41c83cf09f4..000000000000 --- a/Documentation/video4linux/zc0301.txt +++ /dev/null | |||
| @@ -1,270 +0,0 @@ | |||
| 1 | |||
| 2 | ZC0301 and ZC0301P Image Processor and Control Chip | ||
| 3 | Driver for Linux | ||
| 4 | =================================================== | ||
| 5 | |||
| 6 | - Documentation - | ||
| 7 | |||
| 8 | |||
| 9 | Index | ||
| 10 | ===== | ||
| 11 | 1. Copyright | ||
| 12 | 2. Disclaimer | ||
| 13 | 3. License | ||
| 14 | 4. Overview and features | ||
| 15 | 5. Module dependencies | ||
| 16 | 6. Module loading | ||
| 17 | 7. Module parameters | ||
| 18 | 8. Supported devices | ||
| 19 | 9. Notes for V4L2 application developers | ||
| 20 | 10. Contact information | ||
| 21 | 11. Credits | ||
| 22 | |||
| 23 | |||
| 24 | 1. Copyright | ||
| 25 | ============ | ||
| 26 | Copyright (C) 2006-2007 by Luca Risolia <luca.risolia@studio.unibo.it> | ||
| 27 | |||
| 28 | |||
| 29 | 2. Disclaimer | ||
| 30 | ============= | ||
| 31 | This software is not developed or sponsored by Z-Star Microelectronics Corp. | ||
| 32 | Trademarks are property of their respective owner. | ||
| 33 | |||
| 34 | |||
| 35 | 3. License | ||
| 36 | ========== | ||
| 37 | This program is free software; you can redistribute it and/or modify | ||
| 38 | it under the terms of the GNU General Public License as published by | ||
| 39 | the Free Software Foundation; either version 2 of the License, or | ||
| 40 | (at your option) any later version. | ||
| 41 | |||
| 42 | This program is distributed in the hope that it will be useful, | ||
| 43 | but WITHOUT ANY WARRANTY; without even the implied warranty of | ||
| 44 | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the | ||
| 45 | GNU General Public License for more details. | ||
| 46 | |||
| 47 | You should have received a copy of the GNU General Public License | ||
| 48 | along with this program; if not, write to the Free Software | ||
| 49 | Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. | ||
| 50 | |||
| 51 | |||
| 52 | 4. Overview and features | ||
| 53 | ======================== | ||
| 54 | This driver supports the video interface of the devices mounting the ZC0301 or | ||
| 55 | ZC0301P Image Processors and Control Chips. | ||
| 56 | |||
| 57 | The driver relies on the Video4Linux2 and USB core modules. It has been | ||
| 58 | designed to run properly on SMP systems as well. | ||
| 59 | |||
| 60 | The latest version of the ZC0301[P] driver can be found at the following URL: | ||
| 61 | http://www.linux-projects.org/ | ||
| 62 | |||
| 63 | Some of the features of the driver are: | ||
| 64 | |||
| 65 | - full compliance with the Video4Linux2 API (see also "Notes for V4L2 | ||
| 66 | application developers" paragraph); | ||
| 67 | - available mmap or read/poll methods for video streaming through isochronous | ||
| 68 | data transfers; | ||
| 69 | - automatic detection of image sensor; | ||
| 70 | - video format is standard JPEG; | ||
| 71 | - dynamic driver control thanks to various module parameters (see "Module | ||
| 72 | parameters" paragraph); | ||
| 73 | - up to 64 cameras can be handled at the same time; they can be connected and | ||
| 74 | disconnected from the host many times without turning off the computer, if | ||
| 75 | the system supports hotplugging; | ||
| 76 | |||
| 77 | |||
| 78 | 5. Module dependencies | ||
| 79 | ====================== | ||
| 80 | For it to work properly, the driver needs kernel support for Video4Linux and | ||
| 81 | USB. | ||
| 82 | |||
| 83 | The following options of the kernel configuration file must be enabled and | ||
| 84 | corresponding modules must be compiled: | ||
| 85 | |||
| 86 | # Multimedia devices | ||
| 87 | # | ||
| 88 | CONFIG_VIDEO_DEV=m | ||
| 89 | |||
| 90 | # USB support | ||
| 91 | # | ||
| 92 | CONFIG_USB=m | ||
| 93 | |||
| 94 | In addition, depending on the hardware being used, the modules below are | ||
| 95 | necessary: | ||
| 96 | |||
| 97 | # USB Host Controller Drivers | ||
| 98 | # | ||
| 99 | CONFIG_USB_EHCI_HCD=m | ||
| 100 | CONFIG_USB_UHCI_HCD=m | ||
| 101 | CONFIG_USB_OHCI_HCD=m | ||
| 102 | |||
| 103 | The ZC0301 controller also provides a built-in microphone interface. It is | ||
| 104 | supported by the USB Audio driver thanks to the ALSA API: | ||
| 105 | |||
| 106 | # Sound | ||
| 107 | # | ||
| 108 | CONFIG_SOUND=y | ||
| 109 | |||
| 110 | # Advanced Linux Sound Architecture | ||
| 111 | # | ||
| 112 | CONFIG_SND=m | ||
| 113 | |||
| 114 | # USB devices | ||
| 115 | # | ||
| 116 | CONFIG_SND_USB_AUDIO=m | ||
| 117 | |||
| 118 | And finally: | ||
| 119 | |||
| 120 | # V4L USB devices | ||
| 121 | # | ||
| 122 | CONFIG_USB_ZC0301=m | ||
| 123 | |||
| 124 | |||
| 125 | 6. Module loading | ||
| 126 | ================= | ||
| 127 | To use the driver, it is necessary to load the "zc0301" module into memory | ||
| 128 | after every other module required: "videodev", "v4l2_common", "compat_ioctl32", | ||
| 129 | "usbcore" and, depending on the USB host controller you have, "ehci-hcd", | ||
| 130 | "uhci-hcd" or "ohci-hcd". | ||
| 131 | |||
| 132 | Loading can be done as shown below: | ||
| 133 | |||
| 134 | [root@localhost home]# modprobe zc0301 | ||
| 135 | |||
| 136 | At this point the devices should be recognized. You can invoke "dmesg" to | ||
| 137 | analyze kernel messages and verify that the loading process has gone well: | ||
| 138 | |||
| 139 | [user@localhost home]$ dmesg | ||
| 140 | |||
| 141 | |||
| 142 | 7. Module parameters | ||
| 143 | ==================== | ||
| 144 | Module parameters are listed below: | ||
| 145 | ------------------------------------------------------------------------------- | ||
| 146 | Name: video_nr | ||
| 147 | Type: short array (min = 0, max = 64) | ||
| 148 | Syntax: <-1|n[,...]> | ||
| 149 | Description: Specify V4L2 minor mode number: | ||
| 150 | -1 = use next available | ||
| 151 | n = use minor number n | ||
| 152 | You can specify up to 64 cameras this way. | ||
| 153 | For example: | ||
| 154 | video_nr=-1,2,-1 would assign minor number 2 to the second | ||
| 155 | registered camera and use auto for the first one and for every | ||
| 156 | other camera. | ||
| 157 | Default: -1 | ||
| 158 | ------------------------------------------------------------------------------- | ||
| 159 | Name: force_munmap | ||
| 160 | Type: bool array (min = 0, max = 64) | ||
| 161 | Syntax: <0|1[,...]> | ||
| 162 | Description: Force the application to unmap previously mapped buffer memory | ||
| 163 | before calling any VIDIOC_S_CROP or VIDIOC_S_FMT ioctl's. Not | ||
| 164 | all the applications support this feature. This parameter is | ||
| 165 | specific for each detected camera. | ||
| 166 | 0 = do not force memory unmapping | ||
| 167 | 1 = force memory unmapping (save memory) | ||
| 168 | Default: 0 | ||
| 169 | ------------------------------------------------------------------------------- | ||
| 170 | Name: frame_timeout | ||
| 171 | Type: uint array (min = 0, max = 64) | ||
| 172 | Syntax: <n[,...]> | ||
| 173 | Description: Timeout for a video frame in seconds. This parameter is | ||
| 174 | specific for each detected camera. This parameter can be | ||
| 175 | changed at runtime thanks to the /sys filesystem interface. | ||
| 176 | Default: 2 | ||
| 177 | ------------------------------------------------------------------------------- | ||
| 178 | Name: debug | ||
| 179 | Type: ushort | ||
| 180 | Syntax: <n> | ||
| 181 | Description: Debugging information level, from 0 to 3: | ||
| 182 | 0 = none (use carefully) | ||
| 183 | 1 = critical errors | ||
| 184 | 2 = significant information | ||
| 185 | 3 = more verbose messages | ||
| 186 | Level 3 is useful for testing only, when only one device | ||
| 187 | is used at the same time. It also shows some information | ||
| 188 | about the hardware being detected. This module parameter can be | ||
| 189 | changed at runtime thanks to the /sys filesystem interface. | ||
| 190 | Default: 2 | ||
| 191 | ------------------------------------------------------------------------------- | ||
| 192 | |||
| 193 | |||
| 194 | 8. Supported devices | ||
| 195 | ==================== | ||
| 196 | None of the names of the companies as well as their products will be mentioned | ||
| 197 | here. They have never collaborated with the author, so no advertising. | ||
| 198 | |||
| 199 | From the point of view of a driver, what unambiguously identify a device are | ||
| 200 | its vendor and product USB identifiers. Below is a list of known identifiers of | ||
| 201 | devices mounting the ZC0301 Image Processor and Control Chips: | ||
| 202 | |||
| 203 | Vendor ID Product ID | ||
| 204 | --------- ---------- | ||
| 205 | 0x041e 0x4017 | ||
| 206 | 0x041e 0x401c | ||
| 207 | 0x041e 0x401e | ||
| 208 | 0x041e 0x401f | ||
| 209 | 0x041e 0x4022 | ||
| 210 | 0x041e 0x4034 | ||
| 211 | 0x041e 0x4035 | ||
| 212 | 0x041e 0x4036 | ||
| 213 | 0x041e 0x403a | ||
| 214 | 0x0458 0x7007 | ||
| 215 | 0x0458 0x700c | ||
| 216 | 0x0458 0x700f | ||
| 217 | 0x046d 0x08ae | ||
| 218 | 0x055f 0xd003 | ||
| 219 | 0x055f 0xd004 | ||
| 220 | 0x0ac8 0x0301 | ||
| 221 | 0x0ac8 0x301b | ||
| 222 | 0x0ac8 0x303b | ||
| 223 | 0x10fd 0x0128 | ||
| 224 | 0x10fd 0x8050 | ||
| 225 | 0x10fd 0x804e | ||
| 226 | |||
| 227 | The list above does not imply that all those devices work with this driver: up | ||
| 228 | until now only the ones that mount the following image sensors are supported; | ||
| 229 | kernel messages will always tell you whether this is the case: | ||
| 230 | |||
| 231 | Model Manufacturer | ||
| 232 | ----- ------------ | ||
| 233 | PAS202BCB PixArt Imaging, Inc. | ||
| 234 | PB-0330 Photobit Corporation | ||
| 235 | |||
| 236 | |||
| 237 | 9. Notes for V4L2 application developers | ||
| 238 | ======================================== | ||
| 239 | This driver follows the V4L2 API specifications. In particular, it enforces two | ||
| 240 | rules: | ||
| 241 | |||
| 242 | - exactly one I/O method, either "mmap" or "read", is associated with each | ||
| 243 | file descriptor. Once it is selected, the application must close and reopen the | ||
| 244 | device to switch to the other I/O method; | ||
| 245 | |||
| 246 | - although it is not mandatory, previously mapped buffer memory should always | ||
| 247 | be unmapped before calling any "VIDIOC_S_CROP" or "VIDIOC_S_FMT" ioctl's. | ||
| 248 | The same number of buffers as before will be allocated again to match the size | ||
| 249 | of the new video frames, so you have to map the buffers again before any I/O | ||
| 250 | attempts on them. | ||
| 251 | |||
| 252 | |||
| 253 | 10. Contact information | ||
| 254 | ======================= | ||
| 255 | The author may be contacted by e-mail at <luca.risolia@studio.unibo.it>. | ||
| 256 | |||
| 257 | GPG/PGP encrypted e-mail's are accepted. The GPG key ID of the author is | ||
| 258 | 'FCE635A4'; the public 1024-bit key should be available at any keyserver; | ||
| 259 | the fingerprint is: '88E8 F32F 7244 68BA 3958 5D40 99DA 5D2A FCE6 35A4'. | ||
| 260 | |||
| 261 | |||
| 262 | 11. Credits | ||
| 263 | =========== | ||
| 264 | - Information about the chip internals needed to enable the I2C protocol have | ||
| 265 | been taken from the documentation of the ZC030x Video4Linux1 driver written | ||
| 266 | by Andrew Birkett <andy@nobugs.org>; | ||
| 267 | - The initialization values of the ZC0301 controller connected to the PAS202BCB | ||
| 268 | and PB-0330 image sensors have been taken from the SPCA5XX driver maintained | ||
| 269 | by Michel Xhaard <mxhaard@magic.fr>; | ||
| 270 | - Stanislav Lechev donated one camera. | ||