From 8e080c2e6cadada82a6b520e0c23a1cb974822d5 Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Sun, 13 Sep 2009 22:16:04 -0300 Subject: V4L/DVB (12761): DocBook: add media API specs The V4L and DVB API's are there for a long time. however, up to now, no efforts were done to merge them to kernel DocBook. This patch adds the current versions of the specs as an unique compendium. Signed-off-by: Mauro Carvalho Chehab --- Documentation/DocBook/v4l/vidioc-g-parm.xml | 332 ++++++++++++++++++++++++++++ 1 file changed, 332 insertions(+) create mode 100644 Documentation/DocBook/v4l/vidioc-g-parm.xml (limited to 'Documentation/DocBook/v4l/vidioc-g-parm.xml') diff --git a/Documentation/DocBook/v4l/vidioc-g-parm.xml b/Documentation/DocBook/v4l/vidioc-g-parm.xml new file mode 100644 index 00000000000..78332d365ce --- /dev/null +++ b/Documentation/DocBook/v4l/vidioc-g-parm.xml @@ -0,0 +1,332 @@ + + + ioctl VIDIOC_G_PARM, VIDIOC_S_PARM + &manvol; + + + + VIDIOC_G_PARM + VIDIOC_S_PARM + Get or set streaming parameters + + + + + + int ioctl + int fd + int request + v4l2_streamparm *argp + + + + + + Arguments + + + + fd + + &fd; + + + + request + + VIDIOC_G_PARM, VIDIOC_S_PARM + + + + argp + + + + + + + + + Description + + The current video standard determines a nominal number of +frames per second. If less than this number of frames is to be +captured or output, applications can request frame skipping or +duplicating on the driver side. This is especially useful when using +the read() or write(), which +are not augmented by timestamps or sequence counters, and to avoid +unneccessary data copying. + + Further these ioctls can be used to determine the number of +buffers used internally by a driver in read/write mode. For +implications see the section discussing the &func-read; +function. + + To get and set the streaming parameters applications call +the VIDIOC_G_PARM and +VIDIOC_S_PARM ioctl, respectively. They take a +pointer to a struct v4l2_streamparm which +contains a union holding separate parameters for input and output +devices. + + + struct <structname>v4l2_streamparm</structname> + + &cs-ustr; + + + &v4l2-buf-type; + type + + The buffer (stream) type, same as &v4l2-format; +type, set by the application. + + + union + parm + + + + + + &v4l2-captureparm; + capture + Parameters for capture devices, used when +type is +V4L2_BUF_TYPE_VIDEO_CAPTURE. + + + + &v4l2-outputparm; + output + Parameters for output devices, used when +type is +V4L2_BUF_TYPE_VIDEO_OUTPUT. + + + + __u8 + raw_data[200] + A place holder for future extensions and custom +(driver defined) buffer types V4L2_BUF_TYPE_PRIVATE and +higher. + + + +
+ + + struct <structname>v4l2_captureparm</structname> + + &cs-str; + + + __u32 + capability + See . + + + __u32 + capturemode + Set by drivers and applications, see . + + + &v4l2-fract; + timeperframe + This is is the desired period between +successive frames captured by the driver, in seconds. The +field is intended to skip frames on the driver side, saving I/O +bandwidth.Applications store here the desired frame +period, drivers return the actual frame period, which must be greater +or equal to the nominal frame period determined by the current video +standard (&v4l2-standard; frameperiod +field). Changing the video standard (also implicitly by switching the +video input) may reset this parameter to the nominal frame period. To +reset manually applications can just set this field to +zero.Drivers support this function only when they set the +V4L2_CAP_TIMEPERFRAME flag in the +capability field. + + + __u32 + extendedmode + Custom (driver specific) streaming parameters. When +unused, applications and drivers must set this field to zero. +Applications using this field should check the driver name and +version, see . + + + __u32 + readbuffers + Applications set this field to the desired number +of buffers used internally by the driver in &func-read; mode. Drivers +return the actual number of buffers. When an application requests zero +buffers, drivers should just return the current setting rather than +the minimum or an error code. For details see . + + + __u32 + reserved[4] + Reserved for future extensions. Drivers and +applications must set the array to zero. + + + +
+ + + struct <structname>v4l2_outputparm</structname> + + &cs-str; + + + __u32 + capability + See . + + + __u32 + outputmode + Set by drivers and applications, see . + + + &v4l2-fract; + timeperframe + This is is the desired period between +successive frames output by the driver, in seconds. + + + The field is intended to +repeat frames on the driver side in &func-write; mode (in streaming +mode timestamps can be used to throttle the output), saving I/O +bandwidth.Applications store here the desired frame +period, drivers return the actual frame period, which must be greater +or equal to the nominal frame period determined by the current video +standard (&v4l2-standard; frameperiod +field). Changing the video standard (also implicitly by switching the +video output) may reset this parameter to the nominal frame period. To +reset manually applications can just set this field to +zero.Drivers support this function only when they set the +V4L2_CAP_TIMEPERFRAME flag in the +capability field. + + + __u32 + extendedmode + Custom (driver specific) streaming parameters. When +unused, applications and drivers must set this field to zero. +Applications using this field should check the driver name and +version, see . + + + __u32 + writebuffers + Applications set this field to the desired number +of buffers used internally by the driver in +write() mode. Drivers return the actual number of +buffers. When an application requests zero buffers, drivers should +just return the current setting rather than the minimum or an error +code. For details see . + + + __u32 + reserved[4] + Reserved for future extensions. Drivers and +applications must set the array to zero. + + + +
+ + + Streaming Parameters Capabilites + + &cs-def; + + + V4L2_CAP_TIMEPERFRAME + 0x1000 + The frame skipping/repeating controlled by the +timeperframe field is supported. + + + +
+ + + Capture Parameters Flags + + &cs-def; + + + V4L2_MODE_HIGHQUALITY + 0x0001 + High quality imaging mode. High quality mode +is intended for still imaging applications. The idea is to get the +best possible image quality that the hardware can deliver. It is not +defined how the driver writer may achieve that; it will depend on the +hardware and the ingenuity of the driver writer. High quality mode is +a different mode from the the regular motion video capture modes. In +high quality mode: + + The driver may be able to capture higher +resolutions than for motion capture. + + + The driver may support fewer pixel formats +than motion capture (eg; true color). + + + The driver may capture and arithmetically +combine multiple successive fields or frames to remove color edge +artifacts and reduce the noise in the video data. + + + + The driver may capture images in slices like +a scanner in order to handle larger format images than would otherwise +be possible. + + + An image capture operation may be +significantly slower than motion capture. + + + Moving objects in the image might have +excessive motion blur. + + + Capture might only work through the +read() call. + + + + + +
+ + + + + &return-value; + + + + EINVAL + + This ioctl is not supported. + + + + + + + -- cgit v1.2.3-70-g09d2