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 525edb37c758..5f33d8486102 100644 --- a/Documentation/video4linux/CARDLIST.cx23885 +++ b/Documentation/video4linux/CARDLIST.cx23885 | |||
@@ -23,3 +23,4 @@ | |||
23 | 22 -> Mygica X8506 DMB-TH [14f1:8651] | 23 | 22 -> Mygica X8506 DMB-TH [14f1:8651] |
24 | 23 -> Magic-Pro ProHDTV Extreme 2 [14f1:8657] | 24 | 23 -> Magic-Pro ProHDTV Extreme 2 [14f1:8657] |
25 | 24 -> Hauppauge WinTV-HVR1850 [0070:8541] | 25 | 24 -> Hauppauge WinTV-HVR1850 [0070:8541] |
26 | 25 -> Compro VideoMate E800 [1858:e800] | ||
diff --git a/Documentation/video4linux/CARDLIST.em28xx b/Documentation/video4linux/CARDLIST.em28xx index b13fcbd5d94b..b8afef4c0e01 100644 --- a/Documentation/video4linux/CARDLIST.em28xx +++ b/Documentation/video4linux/CARDLIST.em28xx | |||
@@ -1,5 +1,5 @@ | |||
1 | 0 -> Unknown EM2800 video grabber (em2800) [eb1a:2800] | 1 | 0 -> Unknown EM2800 video grabber (em2800) [eb1a:2800] |
2 | 1 -> Unknown EM2750/28xx video grabber (em2820/em2840) [eb1a:2710,eb1a:2820,eb1a:2821,eb1a:2860,eb1a:2861,eb1a:2870,eb1a:2881,eb1a:2883] | 2 | 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] |
3 | 2 -> Terratec Cinergy 250 USB (em2820/em2840) [0ccd:0036] | 3 | 2 -> Terratec Cinergy 250 USB (em2820/em2840) [0ccd:0036] |
4 | 3 -> Pinnacle PCTV USB 2 (em2820/em2840) [2304:0208] | 4 | 3 -> Pinnacle PCTV USB 2 (em2820/em2840) [2304:0208] |
5 | 4 -> Hauppauge WinTV USB 2 (em2820/em2840) [2040:4200,2040:4201] | 5 | 4 -> Hauppauge WinTV USB 2 (em2820/em2840) [2040:4200,2040:4201] |
@@ -68,3 +68,4 @@ | |||
68 | 70 -> Evga inDtube (em2882) | 68 | 70 -> Evga inDtube (em2882) |
69 | 71 -> Silvercrest Webcam 1.3mpix (em2820/em2840) | 69 | 71 -> Silvercrest Webcam 1.3mpix (em2820/em2840) |
70 | 72 -> Gadmei UTV330+ (em2861) | 70 | 72 -> Gadmei UTV330+ (em2861) |
71 | 73 -> Reddo DVB-C USB TV Box (em2870) | ||
diff --git a/Documentation/video4linux/CARDLIST.saa7134 b/Documentation/video4linux/CARDLIST.saa7134 index 0ac4d2544778..2620d60341ee 100644 --- a/Documentation/video4linux/CARDLIST.saa7134 +++ b/Documentation/video4linux/CARDLIST.saa7134 | |||
@@ -171,3 +171,4 @@ | |||
171 | 170 -> AverMedia AverTV Studio 505 [1461:a115] | 171 | 170 -> AverMedia AverTV Studio 505 [1461:a115] |
172 | 171 -> Beholder BeholdTV X7 [5ace:7595] | 172 | 171 -> Beholder BeholdTV X7 [5ace:7595] |
173 | 172 -> RoverMedia TV Link Pro FM [19d1:0138] | 173 | 172 -> RoverMedia TV Link Pro FM [19d1:0138] |
174 | 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 000000000000..152bd7b781ca --- /dev/null +++ b/Documentation/video4linux/CARDLIST.saa7164 | |||
@@ -0,0 +1,9 @@ | |||
1 | 0 -> Unknown | ||
2 | 1 -> Generic Rev2 | ||
3 | 2 -> Generic Rev3 | ||
4 | 3 -> Hauppauge WinTV-HVR2250 [0070:8880,0070:8810] | ||
5 | 4 -> Hauppauge WinTV-HVR2200 [0070:8980] | ||
6 | 5 -> Hauppauge WinTV-HVR2200 [0070:8900] | ||
7 | 6 -> Hauppauge WinTV-HVR2200 [0070:8901] | ||
8 | 7 -> Hauppauge WinTV-HVR2250 [0070:8891,0070:8851] | ||
9 | 8 -> Hauppauge WinTV-HVR2250 [0070:88A1] | ||
diff --git a/Documentation/video4linux/CARDLIST.tuner b/Documentation/video4linux/CARDLIST.tuner index ba9fa679e2d3..e0d298fe8830 100644 --- a/Documentation/video4linux/CARDLIST.tuner +++ b/Documentation/video4linux/CARDLIST.tuner | |||
@@ -79,3 +79,5 @@ tuner=78 - Philips FMD1216MEX MK3 Hybrid Tuner | |||
79 | tuner=79 - Philips PAL/SECAM multi (FM1216 MK5) | 79 | tuner=79 - Philips PAL/SECAM multi (FM1216 MK5) |
80 | tuner=80 - Philips FQ1216LME MK3 PAL/SECAM w/active loopthrough | 80 | tuner=80 - Philips FQ1216LME MK3 PAL/SECAM w/active loopthrough |
81 | tuner=81 - Partsnic (Daewoo) PTI-5NF05 | 81 | tuner=81 - Partsnic (Daewoo) PTI-5NF05 |
82 | tuner=82 - Philips CU1216L | ||
83 | tuner=83 - NXP TDA18271 | ||
diff --git a/Documentation/video4linux/gspca.txt b/Documentation/video4linux/gspca.txt index 4686e84dd800..3f61825be499 100644 --- a/Documentation/video4linux/gspca.txt +++ b/Documentation/video4linux/gspca.txt | |||
@@ -173,6 +173,8 @@ ov519 05a9:8519 OmniVision | |||
173 | ov519 05a9:a518 D-Link DSB-C310 Webcam | 173 | ov519 05a9:a518 D-Link DSB-C310 Webcam |
174 | sunplus 05da:1018 Digital Dream Enigma 1.3 | 174 | sunplus 05da:1018 Digital Dream Enigma 1.3 |
175 | stk014 05e1:0893 Syntek DV4000 | 175 | stk014 05e1:0893 Syntek DV4000 |
176 | gl860 05e3:0503 Genesys Logic PC Camera | ||
177 | gl860 05e3:f191 Genesys Logic PC Camera | ||
176 | spca561 060b:a001 Maxell Compact Pc PM3 | 178 | spca561 060b:a001 Maxell Compact Pc PM3 |
177 | zc3xx 0698:2003 CTX M730V built in | 179 | zc3xx 0698:2003 CTX M730V built in |
178 | spca500 06bd:0404 Agfa CL20 | 180 | spca500 06bd:0404 Agfa CL20 |
diff --git a/Documentation/video4linux/soc-camera.txt b/Documentation/video4linux/soc-camera.txt index 178ef3c5e579..3f87c7da4ca2 100644 --- a/Documentation/video4linux/soc-camera.txt +++ b/Documentation/video4linux/soc-camera.txt | |||
@@ -116,5 +116,45 @@ functionality. | |||
116 | struct soc_camera_device also links to an array of struct soc_camera_data_format, | 116 | struct soc_camera_device also links to an array of struct soc_camera_data_format, |
117 | listing pixel formats, supported by the camera. | 117 | listing pixel formats, supported by the camera. |
118 | 118 | ||
119 | VIDIOC_S_CROP and VIDIOC_S_FMT behaviour | ||
120 | ---------------------------------------- | ||
121 | |||
122 | Above user ioctls modify image geometry as follows: | ||
123 | |||
124 | VIDIOC_S_CROP: sets location and sizes of the sensor window. Unit is one sensor | ||
125 | pixel. Changing sensor window sizes preserves any scaling factors, therefore | ||
126 | user window sizes change as well. | ||
127 | |||
128 | VIDIOC_S_FMT: sets user window. Should preserve previously set sensor window as | ||
129 | much as possible by modifying scaling factors. If the sensor window cannot be | ||
130 | preserved precisely, it may be changed too. | ||
131 | |||
132 | In soc-camera there are two locations, where scaling and cropping can taks | ||
133 | place: in the camera driver and in the host driver. User ioctls are first passed | ||
134 | to the host driver, which then generally passes them down to the camera driver. | ||
135 | It is more efficient to perform scaling and cropping in the camera driver to | ||
136 | save camera bus bandwidth and maximise the framerate. However, if the camera | ||
137 | driver failed to set the required parameters with sufficient precision, the host | ||
138 | driver may decide to also use its own scaling and cropping to fulfill the user's | ||
139 | request. | ||
140 | |||
141 | Camera drivers are interfaced to the soc-camera core and to host drivers over | ||
142 | the v4l2-subdev API, which is completely functional, it doesn't pass any data. | ||
143 | Therefore all camera drivers shall reply to .g_fmt() requests with their current | ||
144 | output geometry. This is necessary to correctly configure the camera bus. | ||
145 | .s_fmt() and .try_fmt() have to be implemented too. Sensor window and scaling | ||
146 | factors have to be maintained by camera drivers internally. According to the | ||
147 | V4L2 API all capture drivers must support the VIDIOC_CROPCAP ioctl, hence we | ||
148 | rely on camera drivers implementing .cropcap(). If the camera driver does not | ||
149 | support cropping, it may choose to not implement .s_crop(), but to enable | ||
150 | cropping support by the camera host driver at least the .g_crop method must be | ||
151 | implemented. | ||
152 | |||
153 | 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 | ||
155 | 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 | ||
157 | responsible for updating them. | ||
158 | |||
119 | -- | 159 | -- |
120 | Author: Guennadi Liakhovetski <g.liakhovetski@gmx.de> | 160 | Author: Guennadi Liakhovetski <g.liakhovetski@gmx.de> |
diff --git a/Documentation/video4linux/v4l2-framework.txt b/Documentation/video4linux/v4l2-framework.txt index ba4706afc5fb..b806edaf3e75 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. | |||
370 | The bridge driver also has some helper functions it can use: | 370 | The bridge driver also has some helper functions it can use: |
371 | 371 | ||
372 | struct v4l2_subdev *sd = v4l2_i2c_new_subdev(v4l2_dev, adapter, | 372 | struct v4l2_subdev *sd = v4l2_i2c_new_subdev(v4l2_dev, adapter, |
373 | "module_foo", "chipid", 0x36); | 373 | "module_foo", "chipid", 0x36, NULL); |
374 | 374 | ||
375 | This loads the given module (can be NULL if no module needs to be loaded) and | 375 | This loads the given module (can be NULL if no module needs to be loaded) and |
376 | calls i2c_new_device() with the given i2c_adapter and chip/address arguments. | 376 | calls i2c_new_device() with the given i2c_adapter and chip/address arguments. |
377 | If all goes well, then it registers the subdev with the v4l2_device. | 377 | If all goes well, then it registers the subdev with the v4l2_device. |
378 | 378 | ||
379 | You can also use v4l2_i2c_new_probed_subdev() which is very similar to | 379 | You can also use the last argument of v4l2_i2c_new_subdev() to pass an array |
380 | v4l2_i2c_new_subdev(), except that it has an array of possible I2C addresses | 380 | of possible I2C addresses that it should probe. These probe addresses are |
381 | that it should probe. Internally it calls i2c_new_probed_device(). | 381 | only used if the previous argument is 0. A non-zero argument means that you |
382 | know the exact i2c address so in that case no probing will take place. | ||
382 | 383 | ||
383 | Both functions return NULL if something went wrong. | 384 | Both functions return NULL if something went wrong. |
384 | 385 | ||
385 | Note that the chipid you pass to v4l2_i2c_new_(probed_)subdev() is usually | 386 | Note that the chipid you pass to v4l2_i2c_new_subdev() is usually |
386 | the same as the module name. It allows you to specify a chip variant, e.g. | 387 | the same as the module name. It allows you to specify a chip variant, e.g. |
387 | "saa7114" or "saa7115". In general though the i2c driver autodetects this. | 388 | "saa7114" or "saa7115". In general though the i2c driver autodetects this. |
388 | The use of chipid is something that needs to be looked at more closely at a | 389 | 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 | |||
410 | v4l2_i2c_new_(probed_)subdev functions will call s_config as well, but with | 411 | v4l2_i2c_new_(probed_)subdev functions will call s_config as well, but with |
411 | irq set to 0 and platform_data set to NULL. | 412 | irq set to 0 and platform_data set to NULL. |
412 | 413 | ||
413 | Note that in the next kernel release the functions v4l2_i2c_new_subdev, | ||
414 | v4l2_i2c_new_probed_subdev and v4l2_i2c_new_probed_subdev_addr will all be | ||
415 | replaced by a single v4l2_i2c_new_subdev that is identical to | ||
416 | v4l2_i2c_new_subdev_cfg but without the irq and platform_data arguments. | ||
417 | |||
418 | struct video_device | 414 | struct video_device |
419 | ------------------- | 415 | ------------------- |
420 | 416 | ||
@@ -490,31 +486,35 @@ VFL_TYPE_RADIO: radioX for radio tuners | |||
490 | VFL_TYPE_VTX: vtxX for teletext devices (deprecated, don't use) | 486 | VFL_TYPE_VTX: vtxX for teletext devices (deprecated, don't use) |
491 | 487 | ||
492 | The last argument gives you a certain amount of control over the device | 488 | The last argument gives you a certain amount of control over the device |
493 | kernel number used (i.e. the X in videoX). Normally you will pass -1 to | 489 | device node number used (i.e. the X in videoX). Normally you will pass -1 |
494 | let the v4l2 framework pick the first free number. But if a driver creates | 490 | to let the v4l2 framework pick the first free number. But sometimes users |
495 | many devices, then it can be useful to have different video devices in | 491 | want to select a specific node number. It is common that drivers allow |
496 | separate ranges. For example, video capture devices start at 0, video | 492 | the user to select a specific device node number through a driver module |
497 | output devices start at 16. | 493 | option. That number is then passed to this function and video_register_device |
498 | 494 | will attempt to select that device node number. If that number was already | |
499 | So you can use the last argument to specify a minimum kernel number and | 495 | in use, then the next free device node number will be selected and it |
500 | the v4l2 framework will try to pick the first free number that is equal | 496 | will send a warning to the kernel log. |
497 | |||
498 | Another use-case is if a driver creates many devices. In that case it can | ||
499 | be useful to place different video devices in separate ranges. For example, | ||
500 | video capture devices start at 0, video output devices start at 16. | ||
501 | So you can use the last argument to specify a minimum device node number | ||
502 | and the v4l2 framework will try to pick the first free number that is equal | ||
501 | or higher to what you passed. If that fails, then it will just pick the | 503 | or higher to what you passed. If that fails, then it will just pick the |
502 | first free number. | 504 | first free number. |
503 | 505 | ||
506 | Since in this case you do not care about a warning about not being able | ||
507 | to select the specified device node number, you can call the function | ||
508 | video_register_device_no_warn() instead. | ||
509 | |||
504 | Whenever a device node is created some attributes are also created for you. | 510 | Whenever a device node is created some attributes are also created for you. |
505 | If you look in /sys/class/video4linux you see the devices. Go into e.g. | 511 | If you look in /sys/class/video4linux you see the devices. Go into e.g. |
506 | video0 and you will see 'name' and 'index' attributes. The 'name' attribute | 512 | video0 and you will see 'name' and 'index' attributes. The 'name' attribute |
507 | is the 'name' field of the video_device struct. The 'index' attribute is | 513 | is the 'name' field of the video_device struct. |
508 | a device node index that can be assigned by the driver, or that is calculated | ||
509 | for you. | ||
510 | |||
511 | If you call video_register_device(), then the index is just increased by | ||
512 | 1 for each device node you register. The first video device node you register | ||
513 | always starts off with 0. | ||
514 | 514 | ||
515 | Alternatively you can call video_register_device_index() which is identical | 515 | The 'index' attribute is the index of the device node: for each call to |
516 | to video_register_device(), but with an extra index argument. Here you can | 516 | video_register_device() the index is just increased by 1. The first video |
517 | pass a specific index value (between 0 and 31) that should be used. | 517 | device node you register always starts with index 0. |
518 | 518 | ||
519 | Users can setup udev rules that utilize the index attribute to make fancy | 519 | Users can setup udev rules that utilize the index attribute to make fancy |
520 | device names (e.g. 'mpegX' for MPEG video capture device nodes). | 520 | 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: | |||
523 | 523 | ||
524 | - vfl_type: the device type passed to video_register_device. | 524 | - vfl_type: the device type passed to video_register_device. |
525 | - minor: the assigned device minor number. | 525 | - minor: the assigned device minor number. |
526 | - num: the device kernel number (i.e. the X in videoX). | 526 | - num: the device node number (i.e. the X in videoX). |
527 | - index: the device index number (calculated or set explicitly using | 527 | - index: the device index number. |
528 | video_register_device_index). | ||
529 | 528 | ||
530 | If the registration failed, then you need to call video_device_release() | 529 | If the registration failed, then you need to call video_device_release() |
531 | to free the allocated video_device struct, or free your own struct if the | 530 | to free the allocated video_device struct, or free your own struct if the |