diff options
Diffstat (limited to 'Documentation/video4linux')
| -rw-r--r-- | Documentation/video4linux/CARDLIST.cx23885 | 1 | ||||
| -rw-r--r-- | Documentation/video4linux/CARDLIST.em28xx | 3 | ||||
| -rw-r--r-- | Documentation/video4linux/CARDLIST.saa7134 | 1 | ||||
| -rw-r--r-- | Documentation/video4linux/CARDLIST.saa7164 | 9 | ||||
| -rw-r--r-- | Documentation/video4linux/CARDLIST.tuner | 2 | ||||
| -rw-r--r-- | Documentation/video4linux/gspca.txt | 2 | ||||
| -rw-r--r-- | Documentation/video4linux/soc-camera.txt | 40 | ||||
| -rw-r--r-- | Documentation/video4linux/v4l2-framework.txt | 61 |
8 files changed, 87 insertions, 32 deletions
diff --git a/Documentation/video4linux/CARDLIST.cx23885 b/Documentation/video4linux/CARDLIST.cx23885 index 525edb37c75..5f33d848610 100644 --- a/Documentation/video4linux/CARDLIST.cx23885 +++ b/Documentation/video4linux/CARDLIST.cx23885 @@ -23,3 +23,4 @@ 22 -> Mygica X8506 DMB-TH [14f1:8651] 23 -> Magic-Pro ProHDTV Extreme 2 [14f1:8657] 24 -> Hauppauge WinTV-HVR1850 [0070:8541] + 25 -> Compro VideoMate E800 [1858:e800] diff --git a/Documentation/video4linux/CARDLIST.em28xx b/Documentation/video4linux/CARDLIST.em28xx index b13fcbd5d94..b8afef4c0e0 100644 --- a/Documentation/video4linux/CARDLIST.em28xx +++ b/Documentation/video4linux/CARDLIST.em28xx @@ -1,5 +1,5 @@ 0 -> Unknown EM2800 video grabber (em2800) [eb1a:2800] - 1 -> Unknown EM2750/28xx video grabber (em2820/em2840) [eb1a:2710,eb1a:2820,eb1a:2821,eb1a:2860,eb1a:2861,eb1a:2870,eb1a:2881,eb1a:2883] + 1 -> Unknown EM2750/28xx video grabber (em2820/em2840) [eb1a:2710,eb1a:2820,eb1a:2821,eb1a:2860,eb1a:2861,eb1a:2870,eb1a:2881,eb1a:2883,eb1a:2868] 2 -> Terratec Cinergy 250 USB (em2820/em2840) [0ccd:0036] 3 -> Pinnacle PCTV USB 2 (em2820/em2840) [2304:0208] 4 -> Hauppauge WinTV USB 2 (em2820/em2840) [2040:4200,2040:4201] @@ -68,3 +68,4 @@ 70 -> Evga inDtube (em2882) 71 -> Silvercrest Webcam 1.3mpix (em2820/em2840) 72 -> Gadmei UTV330+ (em2861) + 73 -> Reddo DVB-C USB TV Box (em2870) diff --git a/Documentation/video4linux/CARDLIST.saa7134 b/Documentation/video4linux/CARDLIST.saa7134 index 0ac4d254477..2620d60341e 100644 --- a/Documentation/video4linux/CARDLIST.saa7134 +++ b/Documentation/video4linux/CARDLIST.saa7134 @@ -171,3 +171,4 @@ 170 -> AverMedia AverTV Studio 505 [1461:a115] 171 -> Beholder BeholdTV X7 [5ace:7595] 172 -> RoverMedia TV Link Pro FM [19d1:0138] +173 -> Zolid Hybrid TV Tuner PCI [1131:2004] diff --git a/Documentation/video4linux/CARDLIST.saa7164 b/Documentation/video4linux/CARDLIST.saa7164 new file mode 100644 index 00000000000..152bd7b781c --- /dev/null +++ b/Documentation/video4linux/CARDLIST.saa7164 @@ -0,0 +1,9 @@ + 0 -> Unknown + 1 -> Generic Rev2 + 2 -> Generic Rev3 + 3 -> Hauppauge WinTV-HVR2250 [0070:8880,0070:8810] + 4 -> Hauppauge WinTV-HVR2200 [0070:8980] + 5 -> Hauppauge WinTV-HVR2200 [0070:8900] + 6 -> Hauppauge WinTV-HVR2200 [0070:8901] + 7 -> Hauppauge WinTV-HVR2250 [0070:8891,0070:8851] + 8 -> Hauppauge WinTV-HVR2250 [0070:88A1] diff --git a/Documentation/video4linux/CARDLIST.tuner b/Documentation/video4linux/CARDLIST.tuner index ba9fa679e2d..e0d298fe883 100644 --- a/Documentation/video4linux/CARDLIST.tuner +++ b/Documentation/video4linux/CARDLIST.tuner @@ -79,3 +79,5 @@ tuner=78 - Philips FMD1216MEX MK3 Hybrid Tuner tuner=79 - Philips PAL/SECAM multi (FM1216 MK5) tuner=80 - Philips FQ1216LME MK3 PAL/SECAM w/active loopthrough tuner=81 - Partsnic (Daewoo) PTI-5NF05 +tuner=82 - Philips CU1216L +tuner=83 - NXP TDA18271 diff --git a/Documentation/video4linux/gspca.txt b/Documentation/video4linux/gspca.txt index 4686e84dd80..3f61825be49 100644 --- a/Documentation/video4linux/gspca.txt +++ b/Documentation/video4linux/gspca.txt @@ -173,6 +173,8 @@ ov519 05a9:8519 OmniVision ov519 05a9:a518 D-Link DSB-C310 Webcam sunplus 05da:1018 Digital Dream Enigma 1.3 stk014 05e1:0893 Syntek DV4000 +gl860 05e3:0503 Genesys Logic PC Camera +gl860 05e3:f191 Genesys Logic PC Camera spca561 060b:a001 Maxell Compact Pc PM3 zc3xx 0698:2003 CTX M730V built in spca500 06bd:0404 Agfa CL20 diff --git a/Documentation/video4linux/soc-camera.txt b/Documentation/video4linux/soc-camera.txt index 178ef3c5e57..3f87c7da4ca 100644 --- a/Documentation/video4linux/soc-camera.txt +++ b/Documentation/video4linux/soc-camera.txt @@ -116,5 +116,45 @@ functionality. struct soc_camera_device also links to an array of struct soc_camera_data_format, listing pixel formats, supported by the camera. +VIDIOC_S_CROP and VIDIOC_S_FMT behaviour +---------------------------------------- + +Above user ioctls modify image geometry as follows: + +VIDIOC_S_CROP: sets location and sizes of the sensor window. Unit is one sensor +pixel. Changing sensor window sizes preserves any scaling factors, therefore +user window sizes change as well. + +VIDIOC_S_FMT: sets user window. Should preserve previously set sensor window as +much as possible by modifying scaling factors. If the sensor window cannot be +preserved precisely, it may be changed too. + +In soc-camera there are two locations, where scaling and cropping can taks +place: in the camera driver and in the host driver. User ioctls are first passed +to the host driver, which then generally passes them down to the camera driver. +It is more efficient to perform scaling and cropping in the camera driver to +save camera bus bandwidth and maximise the framerate. However, if the camera +driver failed to set the required parameters with sufficient precision, the host +driver may decide to also use its own scaling and cropping to fulfill the user's +request. + +Camera drivers are interfaced to the soc-camera core and to host drivers over +the v4l2-subdev API, which is completely functional, it doesn't pass any data. +Therefore all camera drivers shall reply to .g_fmt() requests with their current +output geometry. This is necessary to correctly configure the camera bus. +.s_fmt() and .try_fmt() have to be implemented too. Sensor window and scaling +factors have to be maintained by camera drivers internally. According to the +V4L2 API all capture drivers must support the VIDIOC_CROPCAP ioctl, hence we +rely on camera drivers implementing .cropcap(). If the camera driver does not +support cropping, it may choose to not implement .s_crop(), but to enable +cropping support by the camera host driver at least the .g_crop method must be +implemented. + +User window geometry is kept in .user_width and .user_height fields in struct +soc_camera_device and used by the soc-camera core and host drivers. The core +updates these fields upon successful completion of a .s_fmt() call, but if these +fields change elsewhere, e.g., during .s_crop() processing, the host driver is +responsible for updating them. + -- Author: Guennadi Liakhovetski <g.liakhovetski@gmx.de> diff --git a/Documentation/video4linux/v4l2-framework.txt b/Documentation/video4linux/v4l2-framework.txt index ba4706afc5f..b806edaf3e7 100644 --- a/Documentation/video4linux/v4l2-framework.txt +++ b/Documentation/video4linux/v4l2-framework.txt @@ -370,19 +370,20 @@ from the remove() callback ensures that this is always done correctly. The bridge driver also has some helper functions it can use: struct v4l2_subdev *sd = v4l2_i2c_new_subdev(v4l2_dev, adapter, - "module_foo", "chipid", 0x36); + "module_foo", "chipid", 0x36, NULL); This loads the given module (can be NULL if no module needs to be loaded) and calls i2c_new_device() with the given i2c_adapter and chip/address arguments. If all goes well, then it registers the subdev with the v4l2_device. -You can also use v4l2_i2c_new_probed_subdev() which is very similar to -v4l2_i2c_new_subdev(), except that it has an array of possible I2C addresses -that it should probe. Internally it calls i2c_new_probed_device(). +You can also use the last argument of v4l2_i2c_new_subdev() to pass an array +of possible I2C addresses that it should probe. These probe addresses are +only used if the previous argument is 0. A non-zero argument means that you +know the exact i2c address so in that case no probing will take place. Both functions return NULL if something went wrong. -Note that the chipid you pass to v4l2_i2c_new_(probed_)subdev() is usually +Note that the chipid you pass to v4l2_i2c_new_subdev() is usually the same as the module name. It allows you to specify a chip variant, e.g. "saa7114" or "saa7115". In general though the i2c driver autodetects this. The use of chipid is something that needs to be looked at more closely at a @@ -410,11 +411,6 @@ the irq and platform_data arguments after the subdev was setup. The older v4l2_i2c_new_(probed_)subdev functions will call s_config as well, but with irq set to 0 and platform_data set to NULL. -Note that in the next kernel release the functions v4l2_i2c_new_subdev, -v4l2_i2c_new_probed_subdev and v4l2_i2c_new_probed_subdev_addr will all be -replaced by a single v4l2_i2c_new_subdev that is identical to -v4l2_i2c_new_subdev_cfg but without the irq and platform_data arguments. - struct video_device ------------------- @@ -490,31 +486,35 @@ VFL_TYPE_RADIO: radioX for radio tuners VFL_TYPE_VTX: vtxX for teletext devices (deprecated, don't use) The last argument gives you a certain amount of control over the device -kernel number used (i.e. the X in videoX). Normally you will pass -1 to -let the v4l2 framework pick the first free number. But if a driver creates -many devices, then it can be useful to have different video devices in -separate ranges. For example, video capture devices start at 0, video -output devices start at 16. - -So you can use the last argument to specify a minimum kernel number and -the v4l2 framework will try to pick the first free number that is equal +device node number used (i.e. the X in videoX). Normally you will pass -1 +to let the v4l2 framework pick the first free number. But sometimes users +want to select a specific node number. It is common that drivers allow +the user to select a specific device node number through a driver module +option. That number is then passed to this function and video_register_device +will attempt to select that device node number. If that number was already +in use, then the next free device node number will be selected and it +will send a warning to the kernel log. + +Another use-case is if a driver creates many devices. In that case it can +be useful to place different video devices in separate ranges. For example, +video capture devices start at 0, video output devices start at 16. +So you can use the last argument to specify a minimum device node number +and the v4l2 framework will try to pick the first free number that is equal or higher to what you passed. If that fails, then it will just pick the first free number. +Since in this case you do not care about a warning about not being able +to select the specified device node number, you can call the function +video_register_device_no_warn() instead. + Whenever a device node is created some attributes are also created for you. If you look in /sys/class/video4linux you see the devices. Go into e.g. video0 and you will see 'name' and 'index' attributes. The 'name' attribute -is the 'name' field of the video_device struct. The 'index' attribute is -a device node index that can be assigned by the driver, or that is calculated -for you. - -If you call video_register_device(), then the index is just increased by -1 for each device node you register. The first video device node you register -always starts off with 0. +is the 'name' field of the video_device struct. -Alternatively you can call video_register_device_index() which is identical -to video_register_device(), but with an extra index argument. Here you can -pass a specific index value (between 0 and 31) that should be used. +The 'index' attribute is the index of the device node: for each call to +video_register_device() the index is just increased by 1. The first video +device node you register always starts with index 0. Users can setup udev rules that utilize the index attribute to make fancy device names (e.g. 'mpegX' for MPEG video capture device nodes). @@ -523,9 +523,8 @@ After the device was successfully registered, then you can use these fields: - vfl_type: the device type passed to video_register_device. - minor: the assigned device minor number. -- num: the device kernel number (i.e. the X in videoX). -- index: the device index number (calculated or set explicitly using - video_register_device_index). +- num: the device node number (i.e. the X in videoX). +- index: the device index number. If the registration failed, then you need to call video_device_release() to free the allocated video_device struct, or free your own struct if the |