diff options
Diffstat (limited to 'Documentation/video4linux')
-rw-r--r-- | Documentation/video4linux/soc-camera.txt | 40 |
1 files changed, 40 insertions, 0 deletions
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> |