From 3b4bd47f8f4ed3aaf7c81c9b5d2d37ad79fadf4a Mon Sep 17 00:00:00 2001 From: Fathi Boudra Date: Sun, 28 Apr 2013 09:33:08 +0300 Subject: Imported Upstream version 3.9.0 --- Documentation/DocBook/media/v4l/biblio.xml | 269 ++ Documentation/DocBook/media/v4l/capture.c.xml | 659 +++ Documentation/DocBook/media/v4l/common.xml | 1214 +++++ Documentation/DocBook/media/v4l/compat.xml | 2640 +++++++++++ Documentation/DocBook/media/v4l/controls.xml | 4690 ++++++++++++++++++++ Documentation/DocBook/media/v4l/crop.pdf | Bin 0 -> 5846 bytes Documentation/DocBook/media/v4l/dev-capture.xml | 110 + Documentation/DocBook/media/v4l/dev-codec.xml | 18 + Documentation/DocBook/media/v4l/dev-effect.xml | 17 + Documentation/DocBook/media/v4l/dev-event.xml | 43 + Documentation/DocBook/media/v4l/dev-osd.xml | 149 + Documentation/DocBook/media/v4l/dev-output.xml | 106 + Documentation/DocBook/media/v4l/dev-overlay.xml | 371 ++ Documentation/DocBook/media/v4l/dev-radio.xml | 49 + Documentation/DocBook/media/v4l/dev-raw-vbi.xml | 339 ++ Documentation/DocBook/media/v4l/dev-rds.xml | 196 + Documentation/DocBook/media/v4l/dev-sliced-vbi.xml | 699 +++ Documentation/DocBook/media/v4l/dev-subdev.xml | 467 ++ Documentation/DocBook/media/v4l/dev-teletext.xml | 29 + Documentation/DocBook/media/v4l/driver.xml | 200 + Documentation/DocBook/media/v4l/fdl-appendix.xml | 671 +++ Documentation/DocBook/media/v4l/fieldseq_bt.pdf | Bin 0 -> 9185 bytes Documentation/DocBook/media/v4l/fieldseq_tb.pdf | Bin 0 -> 9173 bytes Documentation/DocBook/media/v4l/func-close.xml | 62 + Documentation/DocBook/media/v4l/func-ioctl.xml | 71 + Documentation/DocBook/media/v4l/func-mmap.xml | 183 + Documentation/DocBook/media/v4l/func-munmap.xml | 76 + Documentation/DocBook/media/v4l/func-open.xml | 113 + Documentation/DocBook/media/v4l/func-poll.xml | 119 + Documentation/DocBook/media/v4l/func-read.xml | 181 + Documentation/DocBook/media/v4l/func-select.xml | 130 + Documentation/DocBook/media/v4l/func-write.xml | 128 + Documentation/DocBook/media/v4l/gen-errors.xml | 77 + Documentation/DocBook/media/v4l/io.xml | 1481 ++++++ Documentation/DocBook/media/v4l/keytable.c.xml | 172 + Documentation/DocBook/media/v4l/libv4l.xml | 160 + .../DocBook/media/v4l/lirc_device_interface.xml | 253 ++ .../DocBook/media/v4l/media-controller.xml | 89 + .../DocBook/media/v4l/media-func-close.xml | 59 + .../DocBook/media/v4l/media-func-ioctl.xml | 73 + .../DocBook/media/v4l/media-func-open.xml | 94 + .../DocBook/media/v4l/media-ioc-device-info.xml | 132 + .../DocBook/media/v4l/media-ioc-enum-entities.xml | 308 ++ .../DocBook/media/v4l/media-ioc-enum-links.xml | 207 + .../DocBook/media/v4l/media-ioc-setup-link.xml | 84 + Documentation/DocBook/media/v4l/pipeline.pdf | Bin 0 -> 20276 bytes Documentation/DocBook/media/v4l/pixfmt-grey.xml | 62 + Documentation/DocBook/media/v4l/pixfmt-m420.xml | 139 + Documentation/DocBook/media/v4l/pixfmt-nv12.xml | 143 + Documentation/DocBook/media/v4l/pixfmt-nv12m.xml | 153 + Documentation/DocBook/media/v4l/pixfmt-nv12mt.xml | 66 + Documentation/DocBook/media/v4l/pixfmt-nv16.xml | 166 + Documentation/DocBook/media/v4l/pixfmt-nv24.xml | 121 + .../DocBook/media/v4l/pixfmt-packed-rgb.xml | 935 ++++ .../DocBook/media/v4l/pixfmt-packed-yuv.xml | 236 + Documentation/DocBook/media/v4l/pixfmt-sbggr16.xml | 83 + Documentation/DocBook/media/v4l/pixfmt-sbggr8.xml | 67 + Documentation/DocBook/media/v4l/pixfmt-sgbrg8.xml | 67 + Documentation/DocBook/media/v4l/pixfmt-sgrbg8.xml | 67 + Documentation/DocBook/media/v4l/pixfmt-srggb10.xml | 90 + .../DocBook/media/v4l/pixfmt-srggb10alaw8.xml | 34 + .../DocBook/media/v4l/pixfmt-srggb10dpcm8.xml | 28 + Documentation/DocBook/media/v4l/pixfmt-srggb12.xml | 90 + Documentation/DocBook/media/v4l/pixfmt-srggb8.xml | 67 + Documentation/DocBook/media/v4l/pixfmt-uv8.xml | 62 + Documentation/DocBook/media/v4l/pixfmt-uyvy.xml | 120 + Documentation/DocBook/media/v4l/pixfmt-vyuy.xml | 120 + Documentation/DocBook/media/v4l/pixfmt-y10.xml | 79 + Documentation/DocBook/media/v4l/pixfmt-y10b.xml | 43 + Documentation/DocBook/media/v4l/pixfmt-y12.xml | 79 + Documentation/DocBook/media/v4l/pixfmt-y16.xml | 81 + Documentation/DocBook/media/v4l/pixfmt-y41p.xml | 149 + Documentation/DocBook/media/v4l/pixfmt-yuv410.xml | 133 + Documentation/DocBook/media/v4l/pixfmt-yuv411p.xml | 147 + Documentation/DocBook/media/v4l/pixfmt-yuv420.xml | 149 + Documentation/DocBook/media/v4l/pixfmt-yuv420m.xml | 154 + Documentation/DocBook/media/v4l/pixfmt-yuv422p.xml | 153 + Documentation/DocBook/media/v4l/pixfmt-yuyv.xml | 120 + Documentation/DocBook/media/v4l/pixfmt-yvu420m.xml | 154 + Documentation/DocBook/media/v4l/pixfmt-yvyu.xml | 120 + Documentation/DocBook/media/v4l/pixfmt.xml | 1042 +++++ Documentation/DocBook/media/v4l/planar-apis.xml | 62 + .../DocBook/media/v4l/remote_controllers.xml | 177 + Documentation/DocBook/media/v4l/selection-api.xml | 325 ++ .../DocBook/media/v4l/selections-common.xml | 164 + Documentation/DocBook/media/v4l/subdev-formats.xml | 2519 +++++++++++ .../media/v4l/subdev-image-processing-crop.dia | 614 +++ .../media/v4l/subdev-image-processing-crop.svg | 63 + .../media/v4l/subdev-image-processing-full.dia | 1588 +++++++ .../media/v4l/subdev-image-processing-full.svg | 163 + ...ubdev-image-processing-scaling-multi-source.dia | 1152 +++++ ...ubdev-image-processing-scaling-multi-source.svg | 116 + Documentation/DocBook/media/v4l/v4l2.xml | 636 +++ Documentation/DocBook/media/v4l/v4l2grab.c.xml | 164 + Documentation/DocBook/media/v4l/vbi_525.pdf | Bin 0 -> 3395 bytes Documentation/DocBook/media/v4l/vbi_625.pdf | Bin 0 -> 3683 bytes Documentation/DocBook/media/v4l/vbi_hsync.pdf | Bin 0 -> 7405 bytes .../DocBook/media/v4l/vidioc-create-bufs.xml | 154 + Documentation/DocBook/media/v4l/vidioc-cropcap.xml | 167 + .../DocBook/media/v4l/vidioc-dbg-g-chip-ident.xml | 266 ++ .../DocBook/media/v4l/vidioc-dbg-g-register.xml | 258 ++ .../DocBook/media/v4l/vidioc-decoder-cmd.xml | 249 ++ Documentation/DocBook/media/v4l/vidioc-dqevent.xml | 277 ++ .../DocBook/media/v4l/vidioc-dv-timings-cap.xml | 205 + .../DocBook/media/v4l/vidioc-encoder-cmd.xml | 189 + .../DocBook/media/v4l/vidioc-enum-dv-presets.xml | 240 + .../DocBook/media/v4l/vidioc-enum-dv-timings.xml | 125 + .../DocBook/media/v4l/vidioc-enum-fmt.xml | 159 + .../media/v4l/vidioc-enum-frameintervals.xml | 259 ++ .../DocBook/media/v4l/vidioc-enum-framesizes.xml | 264 ++ .../DocBook/media/v4l/vidioc-enum-freq-bands.xml | 179 + .../DocBook/media/v4l/vidioc-enumaudio.xml | 76 + .../DocBook/media/v4l/vidioc-enumaudioout.xml | 79 + .../DocBook/media/v4l/vidioc-enuminput.xml | 313 ++ .../DocBook/media/v4l/vidioc-enumoutput.xml | 198 + Documentation/DocBook/media/v4l/vidioc-enumstd.xml | 389 ++ Documentation/DocBook/media/v4l/vidioc-expbuf.xml | 208 + Documentation/DocBook/media/v4l/vidioc-g-audio.xml | 172 + .../DocBook/media/v4l/vidioc-g-audioout.xml | 138 + Documentation/DocBook/media/v4l/vidioc-g-crop.xml | 124 + Documentation/DocBook/media/v4l/vidioc-g-ctrl.xml | 133 + .../DocBook/media/v4l/vidioc-g-dv-preset.xml | 113 + .../DocBook/media/v4l/vidioc-g-dv-timings.xml | 331 ++ .../DocBook/media/v4l/vidioc-g-enc-index.xml | 189 + .../DocBook/media/v4l/vidioc-g-ext-ctrls.xml | 378 ++ Documentation/DocBook/media/v4l/vidioc-g-fbuf.xml | 463 ++ Documentation/DocBook/media/v4l/vidioc-g-fmt.xml | 197 + .../DocBook/media/v4l/vidioc-g-frequency.xml | 147 + Documentation/DocBook/media/v4l/vidioc-g-input.xml | 83 + .../DocBook/media/v4l/vidioc-g-jpegcomp.xml | 175 + .../DocBook/media/v4l/vidioc-g-modulator.xml | 238 + .../DocBook/media/v4l/vidioc-g-output.xml | 85 + Documentation/DocBook/media/v4l/vidioc-g-parm.xml | 314 ++ .../DocBook/media/v4l/vidioc-g-priority.xml | 135 + .../DocBook/media/v4l/vidioc-g-selection.xml | 241 + .../DocBook/media/v4l/vidioc-g-sliced-vbi-cap.xml | 255 ++ Documentation/DocBook/media/v4l/vidioc-g-std.xml | 98 + Documentation/DocBook/media/v4l/vidioc-g-tuner.xml | 569 +++ .../DocBook/media/v4l/vidioc-log-status.xml | 41 + Documentation/DocBook/media/v4l/vidioc-overlay.xml | 74 + .../DocBook/media/v4l/vidioc-prepare-buf.xml | 94 + Documentation/DocBook/media/v4l/vidioc-qbuf.xml | 192 + .../DocBook/media/v4l/vidioc-query-dv-preset.xml | 78 + .../DocBook/media/v4l/vidioc-query-dv-timings.xml | 110 + .../DocBook/media/v4l/vidioc-querybuf.xml | 105 + .../DocBook/media/v4l/vidioc-querycap.xml | 332 ++ .../DocBook/media/v4l/vidioc-queryctrl.xml | 480 ++ .../DocBook/media/v4l/vidioc-querystd.xml | 74 + Documentation/DocBook/media/v4l/vidioc-reqbufs.xml | 137 + .../DocBook/media/v4l/vidioc-s-hw-freq-seek.xml | 184 + .../DocBook/media/v4l/vidioc-streamon.xml | 112 + .../v4l/vidioc-subdev-enum-frame-interval.xml | 152 + .../media/v4l/vidioc-subdev-enum-frame-size.xml | 154 + .../media/v4l/vidioc-subdev-enum-mbus-code.xml | 119 + .../DocBook/media/v4l/vidioc-subdev-g-crop.xml | 158 + .../DocBook/media/v4l/vidioc-subdev-g-edid.xml | 152 + .../DocBook/media/v4l/vidioc-subdev-g-fmt.xml | 183 + .../media/v4l/vidioc-subdev-g-frame-interval.xml | 141 + .../media/v4l/vidioc-subdev-g-selection.xml | 165 + .../DocBook/media/v4l/vidioc-subscribe-event.xml | 206 + 160 files changed, 42725 insertions(+) create mode 100644 Documentation/DocBook/media/v4l/biblio.xml create mode 100644 Documentation/DocBook/media/v4l/capture.c.xml create mode 100644 Documentation/DocBook/media/v4l/common.xml create mode 100644 Documentation/DocBook/media/v4l/compat.xml create mode 100644 Documentation/DocBook/media/v4l/controls.xml create mode 100644 Documentation/DocBook/media/v4l/crop.pdf create mode 100644 Documentation/DocBook/media/v4l/dev-capture.xml create mode 100644 Documentation/DocBook/media/v4l/dev-codec.xml create mode 100644 Documentation/DocBook/media/v4l/dev-effect.xml create mode 100644 Documentation/DocBook/media/v4l/dev-event.xml create mode 100644 Documentation/DocBook/media/v4l/dev-osd.xml create mode 100644 Documentation/DocBook/media/v4l/dev-output.xml create mode 100644 Documentation/DocBook/media/v4l/dev-overlay.xml create mode 100644 Documentation/DocBook/media/v4l/dev-radio.xml create mode 100644 Documentation/DocBook/media/v4l/dev-raw-vbi.xml create mode 100644 Documentation/DocBook/media/v4l/dev-rds.xml create mode 100644 Documentation/DocBook/media/v4l/dev-sliced-vbi.xml create mode 100644 Documentation/DocBook/media/v4l/dev-subdev.xml create mode 100644 Documentation/DocBook/media/v4l/dev-teletext.xml create mode 100644 Documentation/DocBook/media/v4l/driver.xml create mode 100644 Documentation/DocBook/media/v4l/fdl-appendix.xml create mode 100644 Documentation/DocBook/media/v4l/fieldseq_bt.pdf create mode 100644 Documentation/DocBook/media/v4l/fieldseq_tb.pdf create mode 100644 Documentation/DocBook/media/v4l/func-close.xml create mode 100644 Documentation/DocBook/media/v4l/func-ioctl.xml create mode 100644 Documentation/DocBook/media/v4l/func-mmap.xml create mode 100644 Documentation/DocBook/media/v4l/func-munmap.xml create mode 100644 Documentation/DocBook/media/v4l/func-open.xml create mode 100644 Documentation/DocBook/media/v4l/func-poll.xml create mode 100644 Documentation/DocBook/media/v4l/func-read.xml create mode 100644 Documentation/DocBook/media/v4l/func-select.xml create mode 100644 Documentation/DocBook/media/v4l/func-write.xml create mode 100644 Documentation/DocBook/media/v4l/gen-errors.xml create mode 100644 Documentation/DocBook/media/v4l/io.xml create mode 100644 Documentation/DocBook/media/v4l/keytable.c.xml create mode 100644 Documentation/DocBook/media/v4l/libv4l.xml create mode 100644 Documentation/DocBook/media/v4l/lirc_device_interface.xml create mode 100644 Documentation/DocBook/media/v4l/media-controller.xml create mode 100644 Documentation/DocBook/media/v4l/media-func-close.xml create mode 100644 Documentation/DocBook/media/v4l/media-func-ioctl.xml create mode 100644 Documentation/DocBook/media/v4l/media-func-open.xml create mode 100644 Documentation/DocBook/media/v4l/media-ioc-device-info.xml create mode 100644 Documentation/DocBook/media/v4l/media-ioc-enum-entities.xml create mode 100644 Documentation/DocBook/media/v4l/media-ioc-enum-links.xml create mode 100644 Documentation/DocBook/media/v4l/media-ioc-setup-link.xml create mode 100644 Documentation/DocBook/media/v4l/pipeline.pdf create mode 100644 Documentation/DocBook/media/v4l/pixfmt-grey.xml create mode 100644 Documentation/DocBook/media/v4l/pixfmt-m420.xml create mode 100644 Documentation/DocBook/media/v4l/pixfmt-nv12.xml create mode 100644 Documentation/DocBook/media/v4l/pixfmt-nv12m.xml create mode 100644 Documentation/DocBook/media/v4l/pixfmt-nv12mt.xml create mode 100644 Documentation/DocBook/media/v4l/pixfmt-nv16.xml create mode 100644 Documentation/DocBook/media/v4l/pixfmt-nv24.xml create mode 100644 Documentation/DocBook/media/v4l/pixfmt-packed-rgb.xml create mode 100644 Documentation/DocBook/media/v4l/pixfmt-packed-yuv.xml create mode 100644 Documentation/DocBook/media/v4l/pixfmt-sbggr16.xml create mode 100644 Documentation/DocBook/media/v4l/pixfmt-sbggr8.xml create mode 100644 Documentation/DocBook/media/v4l/pixfmt-sgbrg8.xml create mode 100644 Documentation/DocBook/media/v4l/pixfmt-sgrbg8.xml create mode 100644 Documentation/DocBook/media/v4l/pixfmt-srggb10.xml create mode 100644 Documentation/DocBook/media/v4l/pixfmt-srggb10alaw8.xml create mode 100644 Documentation/DocBook/media/v4l/pixfmt-srggb10dpcm8.xml create mode 100644 Documentation/DocBook/media/v4l/pixfmt-srggb12.xml create mode 100644 Documentation/DocBook/media/v4l/pixfmt-srggb8.xml create mode 100644 Documentation/DocBook/media/v4l/pixfmt-uv8.xml create mode 100644 Documentation/DocBook/media/v4l/pixfmt-uyvy.xml create mode 100644 Documentation/DocBook/media/v4l/pixfmt-vyuy.xml create mode 100644 Documentation/DocBook/media/v4l/pixfmt-y10.xml create mode 100644 Documentation/DocBook/media/v4l/pixfmt-y10b.xml create mode 100644 Documentation/DocBook/media/v4l/pixfmt-y12.xml create mode 100644 Documentation/DocBook/media/v4l/pixfmt-y16.xml create mode 100644 Documentation/DocBook/media/v4l/pixfmt-y41p.xml create mode 100644 Documentation/DocBook/media/v4l/pixfmt-yuv410.xml create mode 100644 Documentation/DocBook/media/v4l/pixfmt-yuv411p.xml create mode 100644 Documentation/DocBook/media/v4l/pixfmt-yuv420.xml create mode 100644 Documentation/DocBook/media/v4l/pixfmt-yuv420m.xml create mode 100644 Documentation/DocBook/media/v4l/pixfmt-yuv422p.xml create mode 100644 Documentation/DocBook/media/v4l/pixfmt-yuyv.xml create mode 100644 Documentation/DocBook/media/v4l/pixfmt-yvu420m.xml create mode 100644 Documentation/DocBook/media/v4l/pixfmt-yvyu.xml create mode 100644 Documentation/DocBook/media/v4l/pixfmt.xml create mode 100644 Documentation/DocBook/media/v4l/planar-apis.xml create mode 100644 Documentation/DocBook/media/v4l/remote_controllers.xml create mode 100644 Documentation/DocBook/media/v4l/selection-api.xml create mode 100644 Documentation/DocBook/media/v4l/selections-common.xml create mode 100644 Documentation/DocBook/media/v4l/subdev-formats.xml create mode 100644 Documentation/DocBook/media/v4l/subdev-image-processing-crop.dia create mode 100644 Documentation/DocBook/media/v4l/subdev-image-processing-crop.svg create mode 100644 Documentation/DocBook/media/v4l/subdev-image-processing-full.dia create mode 100644 Documentation/DocBook/media/v4l/subdev-image-processing-full.svg create mode 100644 Documentation/DocBook/media/v4l/subdev-image-processing-scaling-multi-source.dia create mode 100644 Documentation/DocBook/media/v4l/subdev-image-processing-scaling-multi-source.svg create mode 100644 Documentation/DocBook/media/v4l/v4l2.xml create mode 100644 Documentation/DocBook/media/v4l/v4l2grab.c.xml create mode 100644 Documentation/DocBook/media/v4l/vbi_525.pdf create mode 100644 Documentation/DocBook/media/v4l/vbi_625.pdf create mode 100644 Documentation/DocBook/media/v4l/vbi_hsync.pdf create mode 100644 Documentation/DocBook/media/v4l/vidioc-create-bufs.xml create mode 100644 Documentation/DocBook/media/v4l/vidioc-cropcap.xml create mode 100644 Documentation/DocBook/media/v4l/vidioc-dbg-g-chip-ident.xml create mode 100644 Documentation/DocBook/media/v4l/vidioc-dbg-g-register.xml create mode 100644 Documentation/DocBook/media/v4l/vidioc-decoder-cmd.xml create mode 100644 Documentation/DocBook/media/v4l/vidioc-dqevent.xml create mode 100644 Documentation/DocBook/media/v4l/vidioc-dv-timings-cap.xml create mode 100644 Documentation/DocBook/media/v4l/vidioc-encoder-cmd.xml create mode 100644 Documentation/DocBook/media/v4l/vidioc-enum-dv-presets.xml create mode 100644 Documentation/DocBook/media/v4l/vidioc-enum-dv-timings.xml create mode 100644 Documentation/DocBook/media/v4l/vidioc-enum-fmt.xml create mode 100644 Documentation/DocBook/media/v4l/vidioc-enum-frameintervals.xml create mode 100644 Documentation/DocBook/media/v4l/vidioc-enum-framesizes.xml create mode 100644 Documentation/DocBook/media/v4l/vidioc-enum-freq-bands.xml create mode 100644 Documentation/DocBook/media/v4l/vidioc-enumaudio.xml create mode 100644 Documentation/DocBook/media/v4l/vidioc-enumaudioout.xml create mode 100644 Documentation/DocBook/media/v4l/vidioc-enuminput.xml create mode 100644 Documentation/DocBook/media/v4l/vidioc-enumoutput.xml create mode 100644 Documentation/DocBook/media/v4l/vidioc-enumstd.xml create mode 100644 Documentation/DocBook/media/v4l/vidioc-expbuf.xml create mode 100644 Documentation/DocBook/media/v4l/vidioc-g-audio.xml create mode 100644 Documentation/DocBook/media/v4l/vidioc-g-audioout.xml create mode 100644 Documentation/DocBook/media/v4l/vidioc-g-crop.xml create mode 100644 Documentation/DocBook/media/v4l/vidioc-g-ctrl.xml create mode 100644 Documentation/DocBook/media/v4l/vidioc-g-dv-preset.xml create mode 100644 Documentation/DocBook/media/v4l/vidioc-g-dv-timings.xml create mode 100644 Documentation/DocBook/media/v4l/vidioc-g-enc-index.xml create mode 100644 Documentation/DocBook/media/v4l/vidioc-g-ext-ctrls.xml create mode 100644 Documentation/DocBook/media/v4l/vidioc-g-fbuf.xml create mode 100644 Documentation/DocBook/media/v4l/vidioc-g-fmt.xml create mode 100644 Documentation/DocBook/media/v4l/vidioc-g-frequency.xml create mode 100644 Documentation/DocBook/media/v4l/vidioc-g-input.xml create mode 100644 Documentation/DocBook/media/v4l/vidioc-g-jpegcomp.xml create mode 100644 Documentation/DocBook/media/v4l/vidioc-g-modulator.xml create mode 100644 Documentation/DocBook/media/v4l/vidioc-g-output.xml create mode 100644 Documentation/DocBook/media/v4l/vidioc-g-parm.xml create mode 100644 Documentation/DocBook/media/v4l/vidioc-g-priority.xml create mode 100644 Documentation/DocBook/media/v4l/vidioc-g-selection.xml create mode 100644 Documentation/DocBook/media/v4l/vidioc-g-sliced-vbi-cap.xml create mode 100644 Documentation/DocBook/media/v4l/vidioc-g-std.xml create mode 100644 Documentation/DocBook/media/v4l/vidioc-g-tuner.xml create mode 100644 Documentation/DocBook/media/v4l/vidioc-log-status.xml create mode 100644 Documentation/DocBook/media/v4l/vidioc-overlay.xml create mode 100644 Documentation/DocBook/media/v4l/vidioc-prepare-buf.xml create mode 100644 Documentation/DocBook/media/v4l/vidioc-qbuf.xml create mode 100644 Documentation/DocBook/media/v4l/vidioc-query-dv-preset.xml create mode 100644 Documentation/DocBook/media/v4l/vidioc-query-dv-timings.xml create mode 100644 Documentation/DocBook/media/v4l/vidioc-querybuf.xml create mode 100644 Documentation/DocBook/media/v4l/vidioc-querycap.xml create mode 100644 Documentation/DocBook/media/v4l/vidioc-queryctrl.xml create mode 100644 Documentation/DocBook/media/v4l/vidioc-querystd.xml create mode 100644 Documentation/DocBook/media/v4l/vidioc-reqbufs.xml create mode 100644 Documentation/DocBook/media/v4l/vidioc-s-hw-freq-seek.xml create mode 100644 Documentation/DocBook/media/v4l/vidioc-streamon.xml create mode 100644 Documentation/DocBook/media/v4l/vidioc-subdev-enum-frame-interval.xml create mode 100644 Documentation/DocBook/media/v4l/vidioc-subdev-enum-frame-size.xml create mode 100644 Documentation/DocBook/media/v4l/vidioc-subdev-enum-mbus-code.xml create mode 100644 Documentation/DocBook/media/v4l/vidioc-subdev-g-crop.xml create mode 100644 Documentation/DocBook/media/v4l/vidioc-subdev-g-edid.xml create mode 100644 Documentation/DocBook/media/v4l/vidioc-subdev-g-fmt.xml create mode 100644 Documentation/DocBook/media/v4l/vidioc-subdev-g-frame-interval.xml create mode 100644 Documentation/DocBook/media/v4l/vidioc-subdev-g-selection.xml create mode 100644 Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml (limited to 'Documentation/DocBook/media/v4l') diff --git a/Documentation/DocBook/media/v4l/biblio.xml b/Documentation/DocBook/media/v4l/biblio.xml new file mode 100644 index 00000000..d2eb79e4 --- /dev/null +++ b/Documentation/DocBook/media/v4l/biblio.xml @@ -0,0 +1,269 @@ + + References + + + EIA 608-B + + Electronic Industries Alliance (http://www.eia.org) + + EIA 608-B "Recommended Practice for Line 21 Data +Service" + + + + EN 300 294 + + European Telecommunication Standards Institute +(http://www.etsi.org) + + EN 300 294 "625-line television Wide Screen Signalling +(WSS)" + + + + ETS 300 231 + + European Telecommunication Standards Institute +(http://www.etsi.org) + + ETS 300 231 "Specification of the domestic video +Programme Delivery Control system (PDC)" + + + + ETS 300 706 + + European Telecommunication Standards Institute +(http://www.etsi.org) + + ETS 300 706 "Enhanced Teletext specification" + + + + ISO 13818-1 + + International Telecommunication Union (http://www.itu.ch), International +Organisation for Standardisation (http://www.iso.ch) + + ITU-T Rec. H.222.0 | ISO/IEC 13818-1 "Information +technology — Generic coding of moving pictures and associated +audio information: Systems" + + + + ISO 13818-2 + + International Telecommunication Union (http://www.itu.ch), International +Organisation for Standardisation (http://www.iso.ch) + + ITU-T Rec. H.262 | ISO/IEC 13818-2 "Information +technology — Generic coding of moving pictures and associated +audio information: Video" + + + + ITU BT.470 + + International Telecommunication Union (http://www.itu.ch) + + ITU-R Recommendation BT.470-6 "Conventional Television +Systems" + + + + ITU BT.601 + + International Telecommunication Union (http://www.itu.ch) + + ITU-R Recommendation BT.601-5 "Studio Encoding Parameters +of Digital Television for Standard 4:3 and Wide-Screen 16:9 Aspect +Ratios" + + + + ITU BT.653 + + International Telecommunication Union (http://www.itu.ch) + + ITU-R Recommendation BT.653-3 "Teletext systems" + + + + ITU BT.709 + + International Telecommunication Union (http://www.itu.ch) + + ITU-R Recommendation BT.709-5 "Parameter values for the +HDTV standards for production and international programme +exchange" + + + + ITU BT.1119 + + International Telecommunication Union (http://www.itu.ch) + + ITU-R Recommendation BT.1119 "625-line +television Wide Screen Signalling (WSS)" + + + + JFIF + + Independent JPEG Group (http://www.ijg.org) + + JPEG File Interchange Format + Version 1.02 + + + + ITU-T.81 + + International Telecommunication Union +(http://www.itu.int) + + ITU-T Recommendation T.81 +"Information Technology — Digital Compression and Coding of Continous-Tone +Still Images — Requirements and Guidelines" + + + + W3C JPEG JFIF + + The World Wide Web Consortium (http://www.w3.org) + + JPEG JFIF + + + + SMPTE 12M + + Society of Motion Picture and Television Engineers +(http://www.smpte.org) + + SMPTE 12M-1999 "Television, Audio and Film - Time and +Control Code" + + + + SMPTE 170M + + Society of Motion Picture and Television Engineers +(http://www.smpte.org) + + SMPTE 170M-1999 "Television - Composite Analog Video +Signal - NTSC for Studio Applications" + + + + SMPTE 240M + + Society of Motion Picture and Television Engineers +(http://www.smpte.org) + + SMPTE 240M-1999 "Television - Signal Parameters - +1125-Line High-Definition Production" + + + + IEC 62106 + + International Electrotechnical Commission +(http://www.iec.ch) + + Specification of the radio data system (RDS) for VHF/FM sound broadcasting +in the frequency range from 87,5 to 108,0 MHz + + + + NRSC-4-B + + National Radio Systems Committee +(http://www.nrscstandards.org) + + NRSC-4-B: United States RBDS Standard + + + + ISO 12232:2006 + + International Organization for Standardization +(http://www.iso.org) + + Photography — Digital still cameras — Determination + of exposure index, ISO speed ratings, standard output sensitivity, and + recommended exposure index + + + + CEA-861-E + + Consumer Electronics Association +(http://www.ce.org) + + A DTV Profile for Uncompressed High Speed Digital Interfaces + + + + VESA DMT + + Video Electronics Standards Association +(http://www.vesa.org) + + VESA and Industry Standards and Guidelines for Computer Display Monitor Timing (DMT) + + + + EDID + + Video Electronics Standards Association +(http://www.vesa.org) + + VESA Enhanced Extended Display Identification Data Standard + Release A, Revision 2 + + + + HDCP + + Digital Content Protection LLC +(http://www.digital-cp.com) + + High-bandwidth Digital Content Protection System + Revision 1.3 + + + + HDMI + + HDMI Licensing LLC +(http://www.hdmi.org) + + High-Definition Multimedia Interface + Specification Version 1.4a + + + + DP + + Video Electronics Standards Association +(http://www.vesa.org) + + VESA DisplayPort Standard + Version 1, Revision 2 + + + diff --git a/Documentation/DocBook/media/v4l/capture.c.xml b/Documentation/DocBook/media/v4l/capture.c.xml new file mode 100644 index 00000000..1c5c49a2 --- /dev/null +++ b/Documentation/DocBook/media/v4l/capture.c.xml @@ -0,0 +1,659 @@ + +/* + * V4L2 video capture example + * + * This program can be used and distributed without restrictions. + * + * This program is provided with the V4L2 API + * see http://linuxtv.org/docs.php for more information + */ + +#include <stdio.h> +#include <stdlib.h> +#include <string.h> +#include <assert.h> + +#include <getopt.h> /* getopt_long() */ + +#include <fcntl.h> /* low-level i/o */ +#include <unistd.h> +#include <errno.h> +#include <sys/stat.h> +#include <sys/types.h> +#include <sys/time.h> +#include <sys/mman.h> +#include <sys/ioctl.h> + +#include <linux/videodev2.h> + +#define CLEAR(x) memset(&(x), 0, sizeof(x)) + +enum io_method { + IO_METHOD_READ, + IO_METHOD_MMAP, + IO_METHOD_USERPTR, +}; + +struct buffer { + void *start; + size_t length; +}; + +static char *dev_name; +static enum io_method io = IO_METHOD_MMAP; +static int fd = -1; +struct buffer *buffers; +static unsigned int n_buffers; +static int out_buf; +static int force_format; +static int frame_count = 70; + +static void errno_exit(const char *s) +{ + fprintf(stderr, "%s error %d, %s\n", s, errno, strerror(errno)); + exit(EXIT_FAILURE); +} + +static int xioctl(int fh, int request, void *arg) +{ + int r; + + do { + r = ioctl(fh, request, arg); + } while (-1 == r && EINTR == errno); + + return r; +} + +static void process_image(const void *p, int size) +{ + if (out_buf) + fwrite(p, size, 1, stdout); + + fflush(stderr); + fprintf(stderr, "."); + fflush(stdout); +} + +static int read_frame(void) +{ + struct v4l2_buffer buf; + unsigned int i; + + switch (io) { + case IO_METHOD_READ: + if (-1 == read(fd, buffers[0].start, buffers[0].length)) { + switch (errno) { + case EAGAIN: + return 0; + + case EIO: + /* Could ignore EIO, see spec. */ + + /* fall through */ + + default: + errno_exit("read"); + } + } + + process_image(buffers[0].start, buffers[0].length); + break; + + case IO_METHOD_MMAP: + CLEAR(buf); + + buf.type = V4L2_BUF_TYPE_VIDEO_CAPTURE; + buf.memory = V4L2_MEMORY_MMAP; + + if (-1 == xioctl(fd, VIDIOC_DQBUF, &buf)) { + switch (errno) { + case EAGAIN: + return 0; + + case EIO: + /* Could ignore EIO, see spec. */ + + /* fall through */ + + default: + errno_exit("VIDIOC_DQBUF"); + } + } + + assert(buf.index < n_buffers); + + process_image(buffers[buf.index].start, buf.bytesused); + + if (-1 == xioctl(fd, VIDIOC_QBUF, &buf)) + errno_exit("VIDIOC_QBUF"); + break; + + case IO_METHOD_USERPTR: + CLEAR(buf); + + buf.type = V4L2_BUF_TYPE_VIDEO_CAPTURE; + buf.memory = V4L2_MEMORY_USERPTR; + + if (-1 == xioctl(fd, VIDIOC_DQBUF, &buf)) { + switch (errno) { + case EAGAIN: + return 0; + + case EIO: + /* Could ignore EIO, see spec. */ + + /* fall through */ + + default: + errno_exit("VIDIOC_DQBUF"); + } + } + + for (i = 0; i < n_buffers; ++i) + if (buf.m.userptr == (unsigned long)buffers[i].start + && buf.length == buffers[i].length) + break; + + assert(i < n_buffers); + + process_image((void *)buf.m.userptr, buf.bytesused); + + if (-1 == xioctl(fd, VIDIOC_QBUF, &buf)) + errno_exit("VIDIOC_QBUF"); + break; + } + + return 1; +} + +static void mainloop(void) +{ + unsigned int count; + + count = frame_count; + + while (count-- > 0) { + for (;;) { + fd_set fds; + struct timeval tv; + int r; + + FD_ZERO(&fds); + FD_SET(fd, &fds); + + /* Timeout. */ + tv.tv_sec = 2; + tv.tv_usec = 0; + + r = select(fd + 1, &fds, NULL, NULL, &tv); + + if (-1 == r) { + if (EINTR == errno) + continue; + errno_exit("select"); + } + + if (0 == r) { + fprintf(stderr, "select timeout\n"); + exit(EXIT_FAILURE); + } + + if (read_frame()) + break; + /* EAGAIN - continue select loop. */ + } + } +} + +static void stop_capturing(void) +{ + enum v4l2_buf_type type; + + switch (io) { + case IO_METHOD_READ: + /* Nothing to do. */ + break; + + case IO_METHOD_MMAP: + case IO_METHOD_USERPTR: + type = V4L2_BUF_TYPE_VIDEO_CAPTURE; + if (-1 == xioctl(fd, VIDIOC_STREAMOFF, &type)) + errno_exit("VIDIOC_STREAMOFF"); + break; + } +} + +static void start_capturing(void) +{ + unsigned int i; + enum v4l2_buf_type type; + + switch (io) { + case IO_METHOD_READ: + /* Nothing to do. */ + break; + + case IO_METHOD_MMAP: + for (i = 0; i < n_buffers; ++i) { + struct v4l2_buffer buf; + + CLEAR(buf); + buf.type = V4L2_BUF_TYPE_VIDEO_CAPTURE; + buf.memory = V4L2_MEMORY_MMAP; + buf.index = i; + + if (-1 == xioctl(fd, VIDIOC_QBUF, &buf)) + errno_exit("VIDIOC_QBUF"); + } + type = V4L2_BUF_TYPE_VIDEO_CAPTURE; + if (-1 == xioctl(fd, VIDIOC_STREAMON, &type)) + errno_exit("VIDIOC_STREAMON"); + break; + + case IO_METHOD_USERPTR: + for (i = 0; i < n_buffers; ++i) { + struct v4l2_buffer buf; + + CLEAR(buf); + buf.type = V4L2_BUF_TYPE_VIDEO_CAPTURE; + buf.memory = V4L2_MEMORY_USERPTR; + buf.index = i; + buf.m.userptr = (unsigned long)buffers[i].start; + buf.length = buffers[i].length; + + if (-1 == xioctl(fd, VIDIOC_QBUF, &buf)) + errno_exit("VIDIOC_QBUF"); + } + type = V4L2_BUF_TYPE_VIDEO_CAPTURE; + if (-1 == xioctl(fd, VIDIOC_STREAMON, &type)) + errno_exit("VIDIOC_STREAMON"); + break; + } +} + +static void uninit_device(void) +{ + unsigned int i; + + switch (io) { + case IO_METHOD_READ: + free(buffers[0].start); + break; + + case IO_METHOD_MMAP: + for (i = 0; i < n_buffers; ++i) + if (-1 == munmap(buffers[i].start, buffers[i].length)) + errno_exit("munmap"); + break; + + case IO_METHOD_USERPTR: + for (i = 0; i < n_buffers; ++i) + free(buffers[i].start); + break; + } + + free(buffers); +} + +static void init_read(unsigned int buffer_size) +{ + buffers = calloc(1, sizeof(*buffers)); + + if (!buffers) { + fprintf(stderr, "Out of memory\n"); + exit(EXIT_FAILURE); + } + + buffers[0].length = buffer_size; + buffers[0].start = malloc(buffer_size); + + if (!buffers[0].start) { + fprintf(stderr, "Out of memory\n"); + exit(EXIT_FAILURE); + } +} + +static void init_mmap(void) +{ + struct v4l2_requestbuffers req; + + CLEAR(req); + + req.count = 4; + req.type = V4L2_BUF_TYPE_VIDEO_CAPTURE; + req.memory = V4L2_MEMORY_MMAP; + + if (-1 == xioctl(fd, VIDIOC_REQBUFS, &req)) { + if (EINVAL == errno) { + fprintf(stderr, "%s does not support " + "memory mapping\n", dev_name); + exit(EXIT_FAILURE); + } else { + errno_exit("VIDIOC_REQBUFS"); + } + } + + if (req.count < 2) { + fprintf(stderr, "Insufficient buffer memory on %s\n", + dev_name); + exit(EXIT_FAILURE); + } + + buffers = calloc(req.count, sizeof(*buffers)); + + if (!buffers) { + fprintf(stderr, "Out of memory\n"); + exit(EXIT_FAILURE); + } + + for (n_buffers = 0; n_buffers < req.count; ++n_buffers) { + struct v4l2_buffer buf; + + CLEAR(buf); + + buf.type = V4L2_BUF_TYPE_VIDEO_CAPTURE; + buf.memory = V4L2_MEMORY_MMAP; + buf.index = n_buffers; + + if (-1 == xioctl(fd, VIDIOC_QUERYBUF, &buf)) + errno_exit("VIDIOC_QUERYBUF"); + + buffers[n_buffers].length = buf.length; + buffers[n_buffers].start = + mmap(NULL /* start anywhere */, + buf.length, + PROT_READ | PROT_WRITE /* required */, + MAP_SHARED /* recommended */, + fd, buf.m.offset); + + if (MAP_FAILED == buffers[n_buffers].start) + errno_exit("mmap"); + } +} + +static void init_userp(unsigned int buffer_size) +{ + struct v4l2_requestbuffers req; + + CLEAR(req); + + req.count = 4; + req.type = V4L2_BUF_TYPE_VIDEO_CAPTURE; + req.memory = V4L2_MEMORY_USERPTR; + + if (-1 == xioctl(fd, VIDIOC_REQBUFS, &req)) { + if (EINVAL == errno) { + fprintf(stderr, "%s does not support " + "user pointer i/o\n", dev_name); + exit(EXIT_FAILURE); + } else { + errno_exit("VIDIOC_REQBUFS"); + } + } + + buffers = calloc(4, sizeof(*buffers)); + + if (!buffers) { + fprintf(stderr, "Out of memory\n"); + exit(EXIT_FAILURE); + } + + for (n_buffers = 0; n_buffers < 4; ++n_buffers) { + buffers[n_buffers].length = buffer_size; + buffers[n_buffers].start = malloc(buffer_size); + + if (!buffers[n_buffers].start) { + fprintf(stderr, "Out of memory\n"); + exit(EXIT_FAILURE); + } + } +} + +static void init_device(void) +{ + struct v4l2_capability cap; + struct v4l2_cropcap cropcap; + struct v4l2_crop crop; + struct v4l2_format fmt; + unsigned int min; + + if (-1 == xioctl(fd, VIDIOC_QUERYCAP, &cap)) { + if (EINVAL == errno) { + fprintf(stderr, "%s is no V4L2 device\n", + dev_name); + exit(EXIT_FAILURE); + } else { + errno_exit("VIDIOC_QUERYCAP"); + } + } + + if (!(cap.capabilities & V4L2_CAP_VIDEO_CAPTURE)) { + fprintf(stderr, "%s is no video capture device\n", + dev_name); + exit(EXIT_FAILURE); + } + + switch (io) { + case IO_METHOD_READ: + if (!(cap.capabilities & V4L2_CAP_READWRITE)) { + fprintf(stderr, "%s does not support read i/o\n", + dev_name); + exit(EXIT_FAILURE); + } + break; + + case IO_METHOD_MMAP: + case IO_METHOD_USERPTR: + if (!(cap.capabilities & V4L2_CAP_STREAMING)) { + fprintf(stderr, "%s does not support streaming i/o\n", + dev_name); + exit(EXIT_FAILURE); + } + break; + } + + + /* Select video input, video standard and tune here. */ + + + CLEAR(cropcap); + + cropcap.type = V4L2_BUF_TYPE_VIDEO_CAPTURE; + + if (0 == xioctl(fd, VIDIOC_CROPCAP, &cropcap)) { + crop.type = V4L2_BUF_TYPE_VIDEO_CAPTURE; + crop.c = cropcap.defrect; /* reset to default */ + + if (-1 == xioctl(fd, VIDIOC_S_CROP, &crop)) { + switch (errno) { + case EINVAL: + /* Cropping not supported. */ + break; + default: + /* Errors ignored. */ + break; + } + } + } else { + /* Errors ignored. */ + } + + + CLEAR(fmt); + + fmt.type = V4L2_BUF_TYPE_VIDEO_CAPTURE; + if (force_format) { + fmt.fmt.pix.width = 640; + fmt.fmt.pix.height = 480; + fmt.fmt.pix.pixelformat = V4L2_PIX_FMT_YUYV; + fmt.fmt.pix.field = V4L2_FIELD_INTERLACED; + + if (-1 == xioctl(fd, VIDIOC_S_FMT, &fmt)) + errno_exit("VIDIOC_S_FMT"); + + /* Note VIDIOC_S_FMT may change width and height. */ + } else { + /* Preserve original settings as set by v4l2-ctl for example */ + if (-1 == xioctl(fd, VIDIOC_G_FMT, &fmt)) + errno_exit("VIDIOC_G_FMT"); + } + + /* Buggy driver paranoia. */ + min = fmt.fmt.pix.width * 2; + if (fmt.fmt.pix.bytesperline < min) + fmt.fmt.pix.bytesperline = min; + min = fmt.fmt.pix.bytesperline * fmt.fmt.pix.height; + if (fmt.fmt.pix.sizeimage < min) + fmt.fmt.pix.sizeimage = min; + + switch (io) { + case IO_METHOD_READ: + init_read(fmt.fmt.pix.sizeimage); + break; + + case IO_METHOD_MMAP: + init_mmap(); + break; + + case IO_METHOD_USERPTR: + init_userp(fmt.fmt.pix.sizeimage); + break; + } +} + +static void close_device(void) +{ + if (-1 == close(fd)) + errno_exit("close"); + + fd = -1; +} + +static void open_device(void) +{ + struct stat st; + + if (-1 == stat(dev_name, &st)) { + fprintf(stderr, "Cannot identify '%s': %d, %s\n", + dev_name, errno, strerror(errno)); + exit(EXIT_FAILURE); + } + + if (!S_ISCHR(st.st_mode)) { + fprintf(stderr, "%s is no device\n", dev_name); + exit(EXIT_FAILURE); + } + + fd = open(dev_name, O_RDWR /* required */ | O_NONBLOCK, 0); + + if (-1 == fd) { + fprintf(stderr, "Cannot open '%s': %d, %s\n", + dev_name, errno, strerror(errno)); + exit(EXIT_FAILURE); + } +} + +static void usage(FILE *fp, int argc, char **argv) +{ + fprintf(fp, + "Usage: %s [options]\n\n" + "Version 1.3\n" + "Options:\n" + "-d | --device name Video device name [%s]\n" + "-h | --help Print this message\n" + "-m | --mmap Use memory mapped buffers [default]\n" + "-r | --read Use read() calls\n" + "-u | --userp Use application allocated buffers\n" + "-o | --output Outputs stream to stdout\n" + "-f | --format Force format to 640x480 YUYV\n" + "-c | --count Number of frames to grab [%i]\n" + "", + argv[0], dev_name, frame_count); +} + +static const char short_options[] = "d:hmruofc:"; + +static const struct option +long_options[] = { + { "device", required_argument, NULL, 'd' }, + { "help", no_argument, NULL, 'h' }, + { "mmap", no_argument, NULL, 'm' }, + { "read", no_argument, NULL, 'r' }, + { "userp", no_argument, NULL, 'u' }, + { "output", no_argument, NULL, 'o' }, + { "format", no_argument, NULL, 'f' }, + { "count", required_argument, NULL, 'c' }, + { 0, 0, 0, 0 } +}; + +int main(int argc, char **argv) +{ + dev_name = "/dev/video0"; + + for (;;) { + int idx; + int c; + + c = getopt_long(argc, argv, + short_options, long_options, &idx); + + if (-1 == c) + break; + + switch (c) { + case 0: /* getopt_long() flag */ + break; + + case 'd': + dev_name = optarg; + break; + + case 'h': + usage(stdout, argc, argv); + exit(EXIT_SUCCESS); + + case 'm': + io = IO_METHOD_MMAP; + break; + + case 'r': + io = IO_METHOD_READ; + break; + + case 'u': + io = IO_METHOD_USERPTR; + break; + + case 'o': + out_buf++; + break; + + case 'f': + force_format++; + break; + + case 'c': + errno = 0; + frame_count = strtol(optarg, NULL, 0); + if (errno) + errno_exit(optarg); + break; + + default: + usage(stderr, argc, argv); + exit(EXIT_FAILURE); + } + } + + open_device(); + init_device(); + start_capturing(); + mainloop(); + stop_capturing(); + uninit_device(); + close_device(); + fprintf(stderr, "\n"); + return 0; +} + diff --git a/Documentation/DocBook/media/v4l/common.xml b/Documentation/DocBook/media/v4l/common.xml new file mode 100644 index 00000000..ae06afbb --- /dev/null +++ b/Documentation/DocBook/media/v4l/common.xml @@ -0,0 +1,1214 @@ + Common API Elements + + Programming a V4L2 device consists of these +steps: + + + + Opening the device + + + Changing device properties, selecting a video and audio +input, video standard, picture brightness a. o. + + + Negotiating a data format + + + Negotiating an input/output method + + + The actual input/output loop + + + Closing the device + + + + In practice most steps are optional and can be executed out of +order. It depends on the V4L2 device type, you can read about the +details in . In this chapter we will discuss +the basic concepts applicable to all devices. + +
+ Opening and Closing Devices + +
+ Device Naming + + V4L2 drivers are implemented as kernel modules, loaded +manually by the system administrator or automatically when a device is +first opened. The driver modules plug into the "videodev" kernel +module. It provides helper functions and a common application +interface specified in this document. + + Each driver thus loaded registers one or more device nodes +with major number 81 and a minor number between 0 and 255. Assigning +minor numbers to V4L2 devices is entirely up to the system administrator, +this is primarily intended to solve conflicts between devices. + Access permissions are associated with character +device special files, hence we must ensure device numbers cannot +change with the module load order. To this end minor numbers are no +longer automatically assigned by the "videodev" module as in V4L but +requested by the driver. The defaults will suffice for most people +unless two drivers compete for the same minor numbers. + The module options to select minor numbers are named +after the device special file with a "_nr" suffix. For example "video_nr" +for /dev/video video capture devices. The number is +an offset to the base minor number associated with the device type. + + In earlier versions of the V4L2 API the module options +where named after the device special file with a "unit_" prefix, expressing +the minor number itself, not an offset. Rationale for this change is unknown. +Lastly the naming and semantics are just a convention among driver writers, +the point to note is that minor numbers are not supposed to be hardcoded +into drivers. + When the driver supports multiple devices of the same +type more than one minor number can be assigned, separated by commas: + + +> insmod mydriver.o video_nr=0,1 radio_nr=0,1 + + + In /etc/modules.conf this may be +written as: + +alias char-major-81-0 mydriver +alias char-major-81-1 mydriver +alias char-major-81-64 mydriver +options mydriver video_nr=0,1 radio_nr=0,1 + + + + When an application attempts to open a device +special file with major number 81 and minor number 0, 1, or 64, load +"mydriver" (and the "videodev" module it depends upon). + + + Register the first two video capture devices with +minor number 0 and 1 (base number is 0), the first two radio device +with minor number 64 and 65 (base 64). + + + When no minor number is given as module +option the driver supplies a default. +recommends the base minor numbers to be used for the various device +types. Obviously minor numbers must be unique. When the number is +already in use the offending device will not be +registered. + + By convention system administrators create various +character device special files with these major and minor numbers in +the /dev directory. The names recommended for the +different V4L2 device types are listed in . + + + The creation of character special files (with +mknod) is a privileged operation and +devices cannot be opened by major and minor number. That means +applications cannot reliable scan for loaded or +installed drivers. The user must enter a device name, or the +application can try the conventional device names. + + Under the device filesystem (devfs) the minor number +options are ignored. V4L2 drivers (or by proxy the "videodev" module) +automatically create the required device files in the +/dev/v4l directory using the conventional device +names above. +
+ + + +
+ Multiple Opens + + In general, V4L2 devices can be opened more than once. +When this is supported by the driver, users can for example start a +"panel" application to change controls like brightness or audio +volume, while another application captures video and audio. In other words, panel +applications are comparable to an OSS or ALSA audio mixer application. +When a device supports multiple functions like capturing and overlay +simultaneously, multiple opens allow concurrent +use of the device by forked processes or specialized applications. + + Multiple opens are optional, although drivers should +permit at least concurrent accesses without data exchange, &ie; panel +applications. This implies &func-open; can return an &EBUSY; when the +device is already in use, as well as &func-ioctl; functions initiating +data exchange (namely the &VIDIOC-S-FMT; ioctl), and the &func-read; +and &func-write; functions. + + Mere opening a V4L2 device does not grant exclusive +access. + Drivers could recognize the +O_EXCL open flag. Presently this is not required, +so applications cannot know if it really works. + Initiating data exchange however assigns the right +to read or write the requested type of data, and to change related +properties, to this file descriptor. Applications can request +additional access privileges using the priority mechanism described in +. +
+ +
+ Shared Data Streams + + V4L2 drivers should not support multiple applications +reading or writing the same data stream on a device by copying +buffers, time multiplexing or similar means. This is better handled by +a proxy application in user space. When the driver supports stream +sharing anyway it must be implemented transparently. The V4L2 API does +not specify how conflicts are solved. +
+ +
+ Functions + + To open and close V4L2 devices applications use the +&func-open; and &func-close; function, respectively. Devices are +programmed using the &func-ioctl; function as explained in the +following sections. +
+
+ +
+ Querying Capabilities + + Because V4L2 covers a wide variety of devices not all +aspects of the API are equally applicable to all types of devices. +Furthermore devices of the same type have different capabilities and +this specification permits the omission of a few complicated and less +important parts of the API. + + The &VIDIOC-QUERYCAP; ioctl is available to check if the kernel +device is compatible with this specification, and to query the functions and I/O +methods supported by the device. + + Starting with kernel version 3.1, VIDIOC-QUERYCAP will return the +V4L2 API version used by the driver, with generally matches the Kernel version. +There's no need of using &VIDIOC-QUERYCAP; to check if an specific ioctl is +supported, the V4L2 core now returns ENOIOCTLCMD if a driver doesn't provide +support for an ioctl. + + Other features can be queried +by calling the respective ioctl, for example &VIDIOC-ENUMINPUT; +to learn about the number, types and names of video connectors on the +device. Although abstraction is a major objective of this API, the +ioctl also allows driver specific applications to reliable identify +the driver. + + All V4L2 drivers must support +VIDIOC_QUERYCAP. Applications should always call +this ioctl after opening the device. +
+ +
+ Application Priority + + When multiple applications share a device it may be +desirable to assign them different priorities. Contrary to the +traditional "rm -rf /" school of thought a video recording application +could for example block other applications from changing video +controls or switching the current TV channel. Another objective is to +permit low priority applications working in background, which can be +preempted by user controlled applications and automatically regain +control of the device at a later time. + + Since these features cannot be implemented entirely in user +space V4L2 defines the &VIDIOC-G-PRIORITY; and &VIDIOC-S-PRIORITY; +ioctls to request and query the access priority associate with a file +descriptor. Opening a device assigns a medium priority, compatible +with earlier versions of V4L2 and drivers not supporting these ioctls. +Applications requiring a different priority will usually call +VIDIOC_S_PRIORITY after verifying the device with +the &VIDIOC-QUERYCAP; ioctl. + + Ioctls changing driver properties, such as &VIDIOC-S-INPUT;, +return an &EBUSY; after another application obtained higher priority. +An event mechanism to notify applications about asynchronous property +changes has been proposed but not added yet. +
+ +
+ Video Inputs and Outputs + + Video inputs and outputs are physical connectors of a +device. These can be for example RF connectors (antenna/cable), CVBS +a.k.a. Composite Video, S-Video or RGB connectors. Only video and VBI +capture devices have inputs, output devices have outputs, at least one +each. Radio devices have no video inputs or outputs. + + To learn about the number and attributes of the +available inputs and outputs applications can enumerate them with the +&VIDIOC-ENUMINPUT; and &VIDIOC-ENUMOUTPUT; ioctl, respectively. The +&v4l2-input; returned by the VIDIOC_ENUMINPUT +ioctl also contains signal status information applicable when the +current video input is queried. + + The &VIDIOC-G-INPUT; and &VIDIOC-G-OUTPUT; ioctl return the +index of the current video input or output. To select a different +input or output applications call the &VIDIOC-S-INPUT; and +&VIDIOC-S-OUTPUT; ioctl. Drivers must implement all the input ioctls +when the device has one or more inputs, all the output ioctls when the +device has one or more outputs. + + + + + Information about the current video input + + +&v4l2-input; input; +int index; + +if (-1 == ioctl (fd, &VIDIOC-G-INPUT;, &index)) { + perror ("VIDIOC_G_INPUT"); + exit (EXIT_FAILURE); +} + +memset (&input, 0, sizeof (input)); +input.index = index; + +if (-1 == ioctl (fd, &VIDIOC-ENUMINPUT;, &input)) { + perror ("VIDIOC_ENUMINPUT"); + exit (EXIT_FAILURE); +} + +printf ("Current input: %s\n", input.name); + + + + + Switching to the first video input + + +int index; + +index = 0; + +if (-1 == ioctl (fd, &VIDIOC-S-INPUT;, &index)) { + perror ("VIDIOC_S_INPUT"); + exit (EXIT_FAILURE); +} + + +
+ +
+ Audio Inputs and Outputs + + Audio inputs and outputs are physical connectors of a +device. Video capture devices have inputs, output devices have +outputs, zero or more each. Radio devices have no audio inputs or +outputs. They have exactly one tuner which in fact +is an audio source, but this API associates +tuners with video inputs or outputs only, and radio devices have +none of these. + Actually &v4l2-audio; ought to have a +tuner field like &v4l2-input;, not only +making the API more consistent but also permitting radio devices with +multiple tuners. + A connector on a TV card to loop back the received +audio signal to a sound card is not considered an audio output. + + Audio and video inputs and outputs are associated. Selecting +a video source also selects an audio source. This is most evident when +the video and audio source is a tuner. Further audio connectors can +combine with more than one video input or output. Assumed two +composite video inputs and two audio inputs exist, there may be up to +four valid combinations. The relation of video and audio connectors +is defined in the audioset field of the +respective &v4l2-input; or &v4l2-output;, where each bit represents +the index number, starting at zero, of one audio input or output. + + To learn about the number and attributes of the +available inputs and outputs applications can enumerate them with the +&VIDIOC-ENUMAUDIO; and &VIDIOC-ENUMAUDOUT; ioctl, respectively. The +&v4l2-audio; returned by the VIDIOC_ENUMAUDIO ioctl +also contains signal status information applicable when the current +audio input is queried. + + The &VIDIOC-G-AUDIO; and &VIDIOC-G-AUDOUT; ioctl report +the current audio input and output, respectively. Note that, unlike +&VIDIOC-G-INPUT; and &VIDIOC-G-OUTPUT; these ioctls return a structure +as VIDIOC_ENUMAUDIO and +VIDIOC_ENUMAUDOUT do, not just an index. + + To select an audio input and change its properties +applications call the &VIDIOC-S-AUDIO; ioctl. To select an audio +output (which presently has no changeable properties) applications +call the &VIDIOC-S-AUDOUT; ioctl. + + Drivers must implement all input ioctls when the device +has one or more inputs, all output ioctls when the device has one +or more outputs. When the device has any audio inputs or outputs the +driver must set the V4L2_CAP_AUDIO flag in the +&v4l2-capability; returned by the &VIDIOC-QUERYCAP; ioctl. + + + Information about the current audio input + + +&v4l2-audio; audio; + +memset (&audio, 0, sizeof (audio)); + +if (-1 == ioctl (fd, &VIDIOC-G-AUDIO;, &audio)) { + perror ("VIDIOC_G_AUDIO"); + exit (EXIT_FAILURE); +} + +printf ("Current input: %s\n", audio.name); + + + + + Switching to the first audio input + + +&v4l2-audio; audio; + +memset (&audio, 0, sizeof (audio)); /* clear audio.mode, audio.reserved */ + +audio.index = 0; + +if (-1 == ioctl (fd, &VIDIOC-S-AUDIO;, &audio)) { + perror ("VIDIOC_S_AUDIO"); + exit (EXIT_FAILURE); +} + + +
+ +
+ Tuners and Modulators + +
+ Tuners + + Video input devices can have one or more tuners +demodulating a RF signal. Each tuner is associated with one or more +video inputs, depending on the number of RF connectors on the tuner. +The type field of the respective +&v4l2-input; returned by the &VIDIOC-ENUMINPUT; ioctl is set to +V4L2_INPUT_TYPE_TUNER and its +tuner field contains the index number of +the tuner. + + Radio input devices have exactly one tuner with index zero, no +video inputs. + + To query and change tuner properties applications use the +&VIDIOC-G-TUNER; and &VIDIOC-S-TUNER; ioctl, respectively. The +&v4l2-tuner; returned by VIDIOC_G_TUNER also +contains signal status information applicable when the tuner of the +current video or radio input is queried. Note that +VIDIOC_S_TUNER does not switch the current tuner, +when there is more than one at all. The tuner is solely determined by +the current video input. Drivers must support both ioctls and set the +V4L2_CAP_TUNER flag in the &v4l2-capability; +returned by the &VIDIOC-QUERYCAP; ioctl when the device has one or +more tuners. +
+ +
+ Modulators + + Video output devices can have one or more modulators, uh, +modulating a video signal for radiation or connection to the antenna +input of a TV set or video recorder. Each modulator is associated with +one or more video outputs, depending on the number of RF connectors on +the modulator. The type field of the +respective &v4l2-output; returned by the &VIDIOC-ENUMOUTPUT; ioctl is +set to V4L2_OUTPUT_TYPE_MODULATOR and its +modulator field contains the index number +of the modulator. + + Radio output devices have exactly one modulator with index +zero, no video outputs. + + A video or radio device cannot support both a tuner and a +modulator. Two separate device nodes will have to be used for such +hardware, one that supports the tuner functionality and one that supports +the modulator functionality. The reason is a limitation with the +&VIDIOC-S-FREQUENCY; ioctl where you cannot specify whether the frequency +is for a tuner or a modulator. + + To query and change modulator properties applications use +the &VIDIOC-G-MODULATOR; and &VIDIOC-S-MODULATOR; ioctl. Note that +VIDIOC_S_MODULATOR does not switch the current +modulator, when there is more than one at all. The modulator is solely +determined by the current video output. Drivers must support both +ioctls and set the V4L2_CAP_MODULATOR flag in +the &v4l2-capability; returned by the &VIDIOC-QUERYCAP; ioctl when the +device has one or more modulators. +
+ +
+ Radio Frequency + + To get and set the tuner or modulator radio frequency +applications use the &VIDIOC-G-FREQUENCY; and &VIDIOC-S-FREQUENCY; +ioctl which both take a pointer to a &v4l2-frequency;. These ioctls +are used for TV and radio devices alike. Drivers must support both +ioctls when the tuner or modulator ioctls are supported, or +when the device is a radio device. +
+
+ +
+ Video Standards + + Video devices typically support one or more different video +standards or variations of standards. Each video input and output may +support another set of standards. This set is reported by the +std field of &v4l2-input; and +&v4l2-output; returned by the &VIDIOC-ENUMINPUT; and +&VIDIOC-ENUMOUTPUT; ioctl, respectively. + + V4L2 defines one bit for each analog video standard +currently in use worldwide, and sets aside bits for driver defined +standards, ⪚ hybrid standards to watch NTSC video tapes on PAL TVs +and vice versa. Applications can use the predefined bits to select a +particular standard, although presenting the user a menu of supported +standards is preferred. To enumerate and query the attributes of the +supported standards applications use the &VIDIOC-ENUMSTD; ioctl. + + Many of the defined standards are actually just variations +of a few major standards. The hardware may in fact not distinguish +between them, or do so internal and switch automatically. Therefore +enumerated standards also contain sets of one or more standard +bits. + + Assume a hypothetic tuner capable of demodulating B/PAL, +G/PAL and I/PAL signals. The first enumerated standard is a set of B +and G/PAL, switched automatically depending on the selected radio +frequency in UHF or VHF band. Enumeration gives a "PAL-B/G" or "PAL-I" +choice. Similar a Composite input may collapse standards, enumerating +"PAL-B/G/H/I", "NTSC-M" and "SECAM-D/K". + Some users are already confused by technical terms PAL, +NTSC and SECAM. There is no point asking them to distinguish between +B, G, D, or K when the software or hardware can do that +automatically. + + + To query and select the standard used by the current video +input or output applications call the &VIDIOC-G-STD; and +&VIDIOC-S-STD; ioctl, respectively. The received +standard can be sensed with the &VIDIOC-QUERYSTD; ioctl. Note that the parameter of all these ioctls is a pointer to a &v4l2-std-id; type (a standard set), not an index into the standard enumeration. + An alternative to the current scheme is to use pointers +to indices as arguments of VIDIOC_G_STD and +VIDIOC_S_STD, the &v4l2-input; and +&v4l2-output; std field would be a set of +indices like audioset. + Indices are consistent with the rest of the API +and identify the standard unambiguously. In the present scheme of +things an enumerated standard is looked up by &v4l2-std-id;. Now the +standards supported by the inputs of a device can overlap. Just +assume the tuner and composite input in the example above both +exist on a device. An enumeration of "PAL-B/G", "PAL-H/I" suggests +a choice which does not exist. We cannot merge or omit sets, because +applications would be unable to find the standards reported by +VIDIOC_G_STD. That leaves separate enumerations +for each input. Also selecting a standard by &v4l2-std-id; can be +ambiguous. Advantage of this method is that applications need not +identify the standard indirectly, after enumerating.So in +summary, the lookup itself is unavoidable. The difference is only +whether the lookup is necessary to find an enumerated standard or to +switch to a standard by &v4l2-std-id;. + Drivers must implement all video standard ioctls +when the device has one or more video inputs or outputs. + + Special rules apply to devices such as USB cameras where the notion of video +standards makes little sense. More generally for any capture or output device +which is: + + incapable of capturing fields or frames at the nominal +rate of the video standard, or + + + that does not support the video standard formats at all. + + Here the driver shall set the +std field of &v4l2-input; and &v4l2-output; +to zero and the VIDIOC_G_STD, +VIDIOC_S_STD, +VIDIOC_QUERYSTD and +VIDIOC_ENUMSTD ioctls shall return the +&ENOTTY;. + See for a rationale. + Applications can make use of the and + flags to determine whether the video standard ioctls +are available for the device. + + See for a rationale. Probably +even USB cameras follow some well known video standard. It might have +been better to explicitly indicate elsewhere if a device cannot live +up to normal expectations, instead of this exception. + + + + Information about the current video standard + + +&v4l2-std-id; std_id; +&v4l2-standard; standard; + +if (-1 == ioctl (fd, &VIDIOC-G-STD;, &std_id)) { + /* Note when VIDIOC_ENUMSTD always returns ENOTTY this + is no video device or it falls under the USB exception, + and VIDIOC_G_STD returning ENOTTY is no error. */ + + perror ("VIDIOC_G_STD"); + exit (EXIT_FAILURE); +} + +memset (&standard, 0, sizeof (standard)); +standard.index = 0; + +while (0 == ioctl (fd, &VIDIOC-ENUMSTD;, &standard)) { + if (standard.id & std_id) { + printf ("Current video standard: %s\n", standard.name); + exit (EXIT_SUCCESS); + } + + standard.index++; +} + +/* EINVAL indicates the end of the enumeration, which cannot be + empty unless this device falls under the USB exception. */ + +if (errno == EINVAL || standard.index == 0) { + perror ("VIDIOC_ENUMSTD"); + exit (EXIT_FAILURE); +} + + + + + Listing the video standards supported by the current +input + + +&v4l2-input; input; +&v4l2-standard; standard; + +memset (&input, 0, sizeof (input)); + +if (-1 == ioctl (fd, &VIDIOC-G-INPUT;, &input.index)) { + perror ("VIDIOC_G_INPUT"); + exit (EXIT_FAILURE); +} + +if (-1 == ioctl (fd, &VIDIOC-ENUMINPUT;, &input)) { + perror ("VIDIOC_ENUM_INPUT"); + exit (EXIT_FAILURE); +} + +printf ("Current input %s supports:\n", input.name); + +memset (&standard, 0, sizeof (standard)); +standard.index = 0; + +while (0 == ioctl (fd, &VIDIOC-ENUMSTD;, &standard)) { + if (standard.id & input.std) + printf ("%s\n", standard.name); + + standard.index++; +} + +/* EINVAL indicates the end of the enumeration, which cannot be + empty unless this device falls under the USB exception. */ + +if (errno != EINVAL || standard.index == 0) { + perror ("VIDIOC_ENUMSTD"); + exit (EXIT_FAILURE); +} + + + + + Selecting a new video standard + + +&v4l2-input; input; +&v4l2-std-id; std_id; + +memset (&input, 0, sizeof (input)); + +if (-1 == ioctl (fd, &VIDIOC-G-INPUT;, &input.index)) { + perror ("VIDIOC_G_INPUT"); + exit (EXIT_FAILURE); +} + +if (-1 == ioctl (fd, &VIDIOC-ENUMINPUT;, &input)) { + perror ("VIDIOC_ENUM_INPUT"); + exit (EXIT_FAILURE); +} + +if (0 == (input.std & V4L2_STD_PAL_BG)) { + fprintf (stderr, "Oops. B/G PAL is not supported.\n"); + exit (EXIT_FAILURE); +} + +/* Note this is also supposed to work when only B + or G/PAL is supported. */ + +std_id = V4L2_STD_PAL_BG; + +if (-1 == ioctl (fd, &VIDIOC-S-STD;, &std_id)) { + perror ("VIDIOC_S_STD"); + exit (EXIT_FAILURE); +} + + +
+
+ Digital Video (DV) Timings + + The video standards discussed so far have been dealing with Analog TV and the +corresponding video timings. Today there are many more different hardware interfaces +such as High Definition TV interfaces (HDMI), VGA, DVI connectors etc., that carry +video signals and there is a need to extend the API to select the video timings +for these interfaces. Since it is not possible to extend the &v4l2-std-id; due to +the limited bits available, a new set of IOCTLs was added to set/get video timings at +the input and output: + + DV Timings: This will allow applications to define detailed +video timings for the interface. This includes parameters such as width, height, +polarities, frontporch, backporch etc. The linux/v4l2-dv-timings.h +header can be used to get the timings of the formats in the and + standards. + + + + DV Presets: Digital Video (DV) presets (deprecated). + These are IDs representing a +video timing at the input/output. Presets are pre-defined timings implemented +by the hardware according to video standards. A __u32 data type is used to represent +a preset unlike the bit mask that is used in &v4l2-std-id; allowing future extensions +to support as many different presets as needed. This API is deprecated in favor of the DV Timings +API. + + + To enumerate and query the attributes of the DV timings supported by a device, + applications use the &VIDIOC-ENUM-DV-TIMINGS; and &VIDIOC-DV-TIMINGS-CAP; ioctls. + To set DV timings for the device, applications use the +&VIDIOC-S-DV-TIMINGS; ioctl and to get current DV timings they use the +&VIDIOC-G-DV-TIMINGS; ioctl. To detect the DV timings as seen by the video receiver applications +use the &VIDIOC-QUERY-DV-TIMINGS; ioctl. + To enumerate and query the attributes of DV presets supported by a device, +applications use the &VIDIOC-ENUM-DV-PRESETS; ioctl. To get the current DV preset, +applications use the &VIDIOC-G-DV-PRESET; ioctl and to set a preset they use the +&VIDIOC-S-DV-PRESET; ioctl. To detect the preset as seen by the video receiver applications +use the &VIDIOC-QUERY-DV-PRESET; ioctl. + Applications can make use of the and + flags to decide what ioctls are available to set the +video timings for the device. +
+ + &sub-controls; + +
+ Data Formats + +
+ Data Format Negotiation + + Different devices exchange different kinds of data with +applications, for example video images, raw or sliced VBI data, RDS +datagrams. Even within one kind many different formats are possible, +in particular an abundance of image formats. Although drivers must +provide a default and the selection persists across closing and +reopening a device, applications should always negotiate a data format +before engaging in data exchange. Negotiation means the application +asks for a particular format and the driver selects and reports the +best the hardware can do to satisfy the request. Of course +applications can also just query the current selection. + + A single mechanism exists to negotiate all data formats +using the aggregate &v4l2-format; and the &VIDIOC-G-FMT; and +&VIDIOC-S-FMT; ioctls. Additionally the &VIDIOC-TRY-FMT; ioctl can be +used to examine what the hardware could do, +without actually selecting a new data format. The data formats +supported by the V4L2 API are covered in the respective device section +in . For a closer look at image formats see +. + + The VIDIOC_S_FMT ioctl is a major +turning-point in the initialization sequence. Prior to this point +multiple panel applications can access the same device concurrently to +select the current input, change controls or modify other properties. +The first VIDIOC_S_FMT assigns a logical stream +(video data, VBI data etc.) exclusively to one file descriptor. + + Exclusive means no other application, more precisely no +other file descriptor, can grab this stream or change device +properties inconsistent with the negotiated parameters. A video +standard change for example, when the new standard uses a different +number of scan lines, can invalidate the selected image format. +Therefore only the file descriptor owning the stream can make +invalidating changes. Accordingly multiple file descriptors which +grabbed different logical streams prevent each other from interfering +with their settings. When for example video overlay is about to start +or already in progress, simultaneous video capturing may be restricted +to the same cropping and image size. + + When applications omit the +VIDIOC_S_FMT ioctl its locking side effects are +implied by the next step, the selection of an I/O method with the +&VIDIOC-REQBUFS; ioctl or implicit with the first &func-read; or +&func-write; call. + + Generally only one logical stream can be assigned to a +file descriptor, the exception being drivers permitting simultaneous +video capturing and overlay using the same file descriptor for +compatibility with V4L and earlier versions of V4L2. Switching the +logical stream or returning into "panel mode" is possible by closing +and reopening the device. Drivers may support a +switch using VIDIOC_S_FMT. + + All drivers exchanging data with +applications must support the VIDIOC_G_FMT and +VIDIOC_S_FMT ioctl. Implementation of the +VIDIOC_TRY_FMT is highly recommended but +optional. +
+ +
+ Image Format Enumeration + + Apart of the generic format negotiation functions +a special ioctl to enumerate all image formats supported by video +capture, overlay or output devices is available. + Enumerating formats an application has no a-priori +knowledge of (otherwise it could explicitly ask for them and need not +enumerate) seems useless, but there are applications serving as proxy +between drivers and the actual video applications for which this is +useful. + + + The &VIDIOC-ENUM-FMT; ioctl must be supported +by all drivers exchanging image data with applications. + + + Drivers are not supposed to convert image formats in +kernel space. They must enumerate only formats directly supported by +the hardware. If necessary driver writers should publish an example +conversion routine or library for integration into applications. + +
+
+ + &sub-planar-apis; + +
+ Image Cropping, Insertion and Scaling + + Some video capture devices can sample a subsection of the +picture and shrink or enlarge it to an image of arbitrary size. We +call these abilities cropping and scaling. Some video output devices +can scale an image up or down and insert it at an arbitrary scan line +and horizontal offset into a video signal. + + Applications can use the following API to select an area in +the video signal, query the default area and the hardware limits. +Despite their name, the &VIDIOC-CROPCAP;, &VIDIOC-G-CROP; +and &VIDIOC-S-CROP; ioctls apply to input as well as output +devices. + + Scaling requires a source and a target. On a video capture +or overlay device the source is the video signal, and the cropping +ioctls determine the area actually sampled. The target are images +read by the application or overlaid onto the graphics screen. Their +size (and position for an overlay) is negotiated with the +&VIDIOC-G-FMT; and &VIDIOC-S-FMT; ioctls. + + On a video output device the source are the images passed in +by the application, and their size is again negotiated with the +VIDIOC_G/S_FMT ioctls, or may be encoded in a +compressed video stream. The target is the video signal, and the +cropping ioctls determine the area where the images are +inserted. + + Source and target rectangles are defined even if the device +does not support scaling or the VIDIOC_G/S_CROP +ioctls. Their size (and position where applicable) will be fixed in +this case. All capture and output device must support the +VIDIOC_CROPCAP ioctl such that applications can +determine if scaling takes place. + +
+ Cropping Structures + +
+ Image Cropping, Insertion and Scaling + + + + + + + + + The cropping, insertion and scaling process + + +
+ + For capture devices the coordinates of the top left +corner, width and height of the area which can be sampled is given by +the bounds substructure of the +&v4l2-cropcap; returned by the VIDIOC_CROPCAP +ioctl. To support a wide range of hardware this specification does not +define an origin or units. However by convention drivers should +horizontally count unscaled samples relative to 0H (the leading edge +of the horizontal sync pulse, see ). +Vertically ITU-R line +numbers of the first field (, ), multiplied by two if the driver can capture both +fields. + + The top left corner, width and height of the source +rectangle, that is the area actually sampled, is given by &v4l2-crop; +using the same coordinate system as &v4l2-cropcap;. Applications can +use the VIDIOC_G_CROP and +VIDIOC_S_CROP ioctls to get and set this +rectangle. It must lie completely within the capture boundaries and +the driver may further adjust the requested size and/or position +according to hardware limitations. + + Each capture device has a default source rectangle, given +by the defrect substructure of +&v4l2-cropcap;. The center of this rectangle shall align with the +center of the active picture area of the video signal, and cover what +the driver writer considers the complete picture. Drivers shall reset +the source rectangle to the default when the driver is first loaded, +but not later. + + For output devices these structures and ioctls are used +accordingly, defining the target rectangle where +the images will be inserted into the video signal. + +
+ +
+ Scaling Adjustments + + Video hardware can have various cropping, insertion and +scaling limitations. It may only scale up or down, support only +discrete scaling factors, or have different scaling abilities in +horizontal and vertical direction. Also it may not support scaling at +all. At the same time the &v4l2-crop; rectangle may have to be +aligned, and both the source and target rectangles may have arbitrary +upper and lower size limits. In particular the maximum +width and height +in &v4l2-crop; may be smaller than the +&v4l2-cropcap;.bounds area. Therefore, as +usual, drivers are expected to adjust the requested parameters and +return the actual values selected. + + Applications can change the source or the target rectangle +first, as they may prefer a particular image size or a certain area in +the video signal. If the driver has to adjust both to satisfy hardware +limitations, the last requested rectangle shall take priority, and the +driver should preferably adjust the opposite one. The &VIDIOC-TRY-FMT; +ioctl however shall not change the driver state and therefore only +adjust the requested rectangle. + + Suppose scaling on a video capture device is restricted to +a factor 1:1 or 2:1 in either direction and the target image size must +be a multiple of 16 × 16 pixels. The source cropping +rectangle is set to defaults, which are also the upper limit in this +example, of 640 × 400 pixels at offset 0, 0. An +application requests an image size of 300 × 225 +pixels, assuming video will be scaled down from the "full picture" +accordingly. The driver sets the image size to the closest possible +values 304 × 224, then chooses the cropping rectangle +closest to the requested size, that is 608 × 224 +(224 × 2:1 would exceed the limit 400). The offset +0, 0 is still valid, thus unmodified. Given the default cropping +rectangle reported by VIDIOC_CROPCAP the +application can easily propose another offset to center the cropping +rectangle. + + Now the application may insist on covering an area using a +picture aspect ratio closer to the original request, so it asks for a +cropping rectangle of 608 × 456 pixels. The present +scaling factors limit cropping to 640 × 384, so the +driver returns the cropping size 608 × 384 and adjusts +the image size to closest possible 304 × 192. + +
+ +
+ Examples + + Source and target rectangles shall remain unchanged across +closing and reopening a device, such that piping data into or out of a +device will work without special preparations. More advanced +applications should ensure the parameters are suitable before starting +I/O. + + + Resetting the cropping parameters + + (A video capture device is assumed; change +V4L2_BUF_TYPE_VIDEO_CAPTURE for other +devices.) + + +&v4l2-cropcap; cropcap; +&v4l2-crop; crop; + +memset (&cropcap, 0, sizeof (cropcap)); +cropcap.type = V4L2_BUF_TYPE_VIDEO_CAPTURE; + +if (-1 == ioctl (fd, &VIDIOC-CROPCAP;, &cropcap)) { + perror ("VIDIOC_CROPCAP"); + exit (EXIT_FAILURE); +} + +memset (&crop, 0, sizeof (crop)); +crop.type = V4L2_BUF_TYPE_VIDEO_CAPTURE; +crop.c = cropcap.defrect; + +/* Ignore if cropping is not supported (EINVAL). */ + +if (-1 == ioctl (fd, &VIDIOC-S-CROP;, &crop) + && errno != EINVAL) { + perror ("VIDIOC_S_CROP"); + exit (EXIT_FAILURE); +} + + + + + Simple downscaling + + (A video capture device is assumed.) + + +&v4l2-cropcap; cropcap; +&v4l2-format; format; + +reset_cropping_parameters (); + +/* Scale down to 1/4 size of full picture. */ + +memset (&format, 0, sizeof (format)); /* defaults */ + +format.type = V4L2_BUF_TYPE_VIDEO_CAPTURE; + +format.fmt.pix.width = cropcap.defrect.width >> 1; +format.fmt.pix.height = cropcap.defrect.height >> 1; +format.fmt.pix.pixelformat = V4L2_PIX_FMT_YUYV; + +if (-1 == ioctl (fd, &VIDIOC-S-FMT;, &format)) { + perror ("VIDIOC_S_FORMAT"); + exit (EXIT_FAILURE); +} + +/* We could check the actual image size now, the actual scaling factor + or if the driver can scale at all. */ + + + + + Selecting an output area + + +&v4l2-cropcap; cropcap; +&v4l2-crop; crop; + +memset (&cropcap, 0, sizeof (cropcap)); +cropcap.type = V4L2_BUF_TYPE_VIDEO_OUTPUT; + +if (-1 == ioctl (fd, VIDIOC_CROPCAP;, &cropcap)) { + perror ("VIDIOC_CROPCAP"); + exit (EXIT_FAILURE); +} + +memset (&crop, 0, sizeof (crop)); + +crop.type = V4L2_BUF_TYPE_VIDEO_OUTPUT; +crop.c = cropcap.defrect; + +/* Scale the width and height to 50 % of their original size + and center the output. */ + +crop.c.width /= 2; +crop.c.height /= 2; +crop.c.left += crop.c.width / 2; +crop.c.top += crop.c.height / 2; + +/* Ignore if cropping is not supported (EINVAL). */ + +if (-1 == ioctl (fd, VIDIOC_S_CROP, &crop) + && errno != EINVAL) { + perror ("VIDIOC_S_CROP"); + exit (EXIT_FAILURE); +} + + + + + Current scaling factor and pixel aspect + + (A video capture device is assumed.) + + +&v4l2-cropcap; cropcap; +&v4l2-crop; crop; +&v4l2-format; format; +double hscale, vscale; +double aspect; +int dwidth, dheight; + +memset (&cropcap, 0, sizeof (cropcap)); +cropcap.type = V4L2_BUF_TYPE_VIDEO_CAPTURE; + +if (-1 == ioctl (fd, &VIDIOC-CROPCAP;, &cropcap)) { + perror ("VIDIOC_CROPCAP"); + exit (EXIT_FAILURE); +} + +memset (&crop, 0, sizeof (crop)); +crop.type = V4L2_BUF_TYPE_VIDEO_CAPTURE; + +if (-1 == ioctl (fd, &VIDIOC-G-CROP;, &crop)) { + if (errno != EINVAL) { + perror ("VIDIOC_G_CROP"); + exit (EXIT_FAILURE); + } + + /* Cropping not supported. */ + crop.c = cropcap.defrect; +} + +memset (&format, 0, sizeof (format)); +format.fmt.type = V4L2_BUF_TYPE_VIDEO_CAPTURE; + +if (-1 == ioctl (fd, &VIDIOC-G-FMT;, &format)) { + perror ("VIDIOC_G_FMT"); + exit (EXIT_FAILURE); +} + +/* The scaling applied by the driver. */ + +hscale = format.fmt.pix.width / (double) crop.c.width; +vscale = format.fmt.pix.height / (double) crop.c.height; + +aspect = cropcap.pixelaspect.numerator / + (double) cropcap.pixelaspect.denominator; +aspect = aspect * hscale / vscale; + +/* Devices following ITU-R BT.601 do not capture + square pixels. For playback on a computer monitor + we should scale the images to this size. */ + +dwidth = format.fmt.pix.width / aspect; +dheight = format.fmt.pix.height; + + +
+
+ + &sub-selection-api; + +
+ Streaming Parameters + + Streaming parameters are intended to optimize the video +capture process as well as I/O. Presently applications can request a +high quality capture mode with the &VIDIOC-S-PARM; ioctl. + + 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 &func-read; or &func-write;, which are not augmented by timestamps +or sequence counters, and to avoid unnecessary data copying. + + Finally 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 &v4l2-streamparm;, which contains a union holding +separate parameters for input and output devices. + + These ioctls are optional, drivers need not implement +them. If so, they return the &EINVAL;. +
diff --git a/Documentation/DocBook/media/v4l/compat.xml b/Documentation/DocBook/media/v4l/compat.xml new file mode 100644 index 00000000..104a1a2b --- /dev/null +++ b/Documentation/DocBook/media/v4l/compat.xml @@ -0,0 +1,2640 @@ + Changes + + The following chapters document the evolution of the V4L2 API, +errata or extensions. They are also intended to help application and +driver writers to port or update their code. + +
+ Differences between V4L and V4L2 + + The Video For Linux API was first introduced in Linux 2.1 to +unify and replace various TV and radio device related interfaces, +developed independently by driver writers in prior years. Starting +with Linux 2.5 the much improved V4L2 API replaces the V4L API. +The support for the old V4L calls were removed from Kernel, but the +library supports the conversion of a V4L +API system call into a V4L2 one. + +
+ Opening and Closing Devices + + For compatibility reasons the character device file names +recommended for V4L2 video capture, overlay, radio and raw +vbi capture devices did not change from those used by V4L. They are +listed in and below in . + + The teletext devices (minor range 192-223) have been removed in +V4L2 and no longer exist. There is no hardware available anymore for handling +pure teletext. Instead raw or sliced VBI is used. + + The V4L videodev module automatically +assigns minor numbers to drivers in load order, depending on the +registered device type. We recommend that V4L2 drivers by default +register devices with the same numbers, but the system administrator +can assign arbitrary minor numbers using driver module options. The +major device number remains 81. + + + V4L Device Types, Names and Numbers + + + + Device Type + File Name + Minor Numbers + + + + + Video capture and overlay + /dev/video and +/dev/bttv0 According to +Documentation/devices.txt these should be symbolic links to +/dev/video0. Note the original bttv interface is +not compatible with V4L or V4L2. , +/dev/video0 to +/dev/video63 + 0-63 + + + Radio receiver + /dev/radio + According to +Documentation/devices.txt a symbolic link to +/dev/radio0. + , /dev/radio0 to +/dev/radio63 + 64-127 + + + Raw VBI capture + /dev/vbi, +/dev/vbi0 to +/dev/vbi31 + 224-255 + + + +
+ + V4L prohibits (or used to prohibit) multiple opens of a +device file. V4L2 drivers may support multiple +opens, see for details and consequences. + + V4L drivers respond to V4L2 ioctls with an &EINVAL;. +
+ +
+ Querying Capabilities + + The V4L VIDIOCGCAP ioctl is +equivalent to V4L2's &VIDIOC-QUERYCAP;. + + The name field in struct +video_capability became +card in &v4l2-capability;, +type was replaced by +capabilities. Note V4L2 does not +distinguish between device types like this, better think of basic +video input, video output and radio devices supporting a set of +related functions like video capturing, video overlay and VBI +capturing. See for an +introduction. + + + + struct +video_capability +type + &v4l2-capability; +capabilities flags + Purpose + + + + + VID_TYPE_CAPTURE + V4L2_CAP_VIDEO_CAPTURE + The video +capture interface is supported. + + + VID_TYPE_TUNER + V4L2_CAP_TUNER + The device has a tuner or +modulator. + + + VID_TYPE_TELETEXT + V4L2_CAP_VBI_CAPTURE + The raw VBI +capture interface is supported. + + + VID_TYPE_OVERLAY + V4L2_CAP_VIDEO_OVERLAY + The video +overlay interface is supported. + + + VID_TYPE_CHROMAKEY + V4L2_FBUF_CAP_CHROMAKEY in +field capability of +&v4l2-framebuffer; + Whether chromakey overlay is supported. For +more information on overlay see +. + + + VID_TYPE_CLIPPING + V4L2_FBUF_CAP_LIST_CLIPPING +and V4L2_FBUF_CAP_BITMAP_CLIPPING in field +capability of &v4l2-framebuffer; + Whether clipping the overlaid image is +supported, see . + + + VID_TYPE_FRAMERAM + V4L2_FBUF_CAP_EXTERNOVERLAY +not set in field +capability of &v4l2-framebuffer; + Whether overlay overwrites frame buffer memory, +see . + + + VID_TYPE_SCALES + - + This flag indicates if the hardware can scale +images. The V4L2 API implies the scale factor by setting the cropping +dimensions and image size with the &VIDIOC-S-CROP; and &VIDIOC-S-FMT; +ioctl, respectively. The driver returns the closest sizes possible. +For more information on cropping and scaling see . + + + VID_TYPE_MONOCHROME + - + Applications can enumerate the supported image +formats with the &VIDIOC-ENUM-FMT; ioctl to determine if the device +supports grey scale capturing only. For more information on image +formats see . + + + VID_TYPE_SUBCAPTURE + - + Applications can call the &VIDIOC-G-CROP; ioctl +to determine if the device supports capturing a subsection of the full +picture ("cropping" in V4L2). If not, the ioctl returns the &EINVAL;. +For more information on cropping and scaling see . + + + VID_TYPE_MPEG_DECODER + - + Applications can enumerate the supported image +formats with the &VIDIOC-ENUM-FMT; ioctl to determine if the device +supports MPEG streams. + + + VID_TYPE_MPEG_ENCODER + - + See above. + + + VID_TYPE_MJPEG_DECODER + - + See above. + + + VID_TYPE_MJPEG_ENCODER + - + See above. + + + + + + The audios field was replaced +by capabilities flag +V4L2_CAP_AUDIO, indicating +if the device has any audio inputs or outputs. To +determine their number applications can enumerate audio inputs with +the &VIDIOC-G-AUDIO; ioctl. The audio ioctls are described in . + + The maxwidth, +maxheight, +minwidth and +minheight fields were removed. Calling the +&VIDIOC-S-FMT; or &VIDIOC-TRY-FMT; ioctl with the desired dimensions +returns the closest size possible, taking into account the current +video standard, cropping and scaling limitations. +
+ +
+ Video Sources + + V4L provides the VIDIOCGCHAN and +VIDIOCSCHAN ioctl using struct +video_channel to enumerate +the video inputs of a V4L device. The equivalent V4L2 ioctls +are &VIDIOC-ENUMINPUT;, &VIDIOC-G-INPUT; and &VIDIOC-S-INPUT; +using &v4l2-input; as discussed in . + + The channel field counting +inputs was renamed to index, the video +input types were renamed as follows: + + + + struct video_channel +type + &v4l2-input; +type + + + + + VIDEO_TYPE_TV + V4L2_INPUT_TYPE_TUNER + + + VIDEO_TYPE_CAMERA + V4L2_INPUT_TYPE_CAMERA + + + + + + Unlike the tuners field +expressing the number of tuners of this input, V4L2 assumes each video +input is connected to at most one tuner. However a tuner can have more +than one input, &ie; RF connectors, and a device can have multiple +tuners. The index number of the tuner associated with the input, if +any, is stored in field tuner of +&v4l2-input;. Enumeration of tuners is discussed in . + + The redundant VIDEO_VC_TUNER flag was +dropped. Video inputs associated with a tuner are of type +V4L2_INPUT_TYPE_TUNER. The +VIDEO_VC_AUDIO flag was replaced by the +audioset field. V4L2 considers devices with +up to 32 audio inputs. Each set bit in the +audioset field represents one audio input +this video input combines with. For information about audio inputs and +how to switch between them see . + + The norm field describing the +supported video standards was replaced by +std. The V4L specification mentions a flag +VIDEO_VC_NORM indicating whether the standard can +be changed. This flag was a later addition together with the +norm field and has been removed in the +meantime. V4L2 has a similar, albeit more comprehensive approach +to video standards, see for more +information. +
+ +
+ Tuning + + The V4L VIDIOCGTUNER and +VIDIOCSTUNER ioctl and struct +video_tuner can be used to enumerate the +tuners of a V4L TV or radio device. The equivalent V4L2 ioctls are +&VIDIOC-G-TUNER; and &VIDIOC-S-TUNER; using &v4l2-tuner;. Tuners are +covered in . + + The tuner field counting tuners +was renamed to index. The fields +name, rangelow +and rangehigh remained unchanged. + + The VIDEO_TUNER_PAL, +VIDEO_TUNER_NTSC and +VIDEO_TUNER_SECAM flags indicating the supported +video standards were dropped. This information is now contained in the +associated &v4l2-input;. No replacement exists for the +VIDEO_TUNER_NORM flag indicating whether the +video standard can be switched. The mode +field to select a different video standard was replaced by a whole new +set of ioctls and structures described in . +Due to its ubiquity it should be mentioned the BTTV driver supports +several standards in addition to the regular +VIDEO_MODE_PAL (0), +VIDEO_MODE_NTSC, +VIDEO_MODE_SECAM and +VIDEO_MODE_AUTO (3). Namely N/PAL Argentina, +M/PAL, N/PAL, and NTSC Japan with numbers 3-6 (sic). + + The VIDEO_TUNER_STEREO_ON flag +indicating stereo reception became +V4L2_TUNER_SUB_STEREO in field +rxsubchans. This field also permits the +detection of monaural and bilingual audio, see the definition of +&v4l2-tuner; for details. Presently no replacement exists for the +VIDEO_TUNER_RDS_ON and +VIDEO_TUNER_MBS_ON flags. + + The VIDEO_TUNER_LOW flag was renamed +to V4L2_TUNER_CAP_LOW in the &v4l2-tuner; +capability field. + + The VIDIOCGFREQ and +VIDIOCSFREQ ioctl to change the tuner frequency +where renamed to &VIDIOC-G-FREQUENCY; and &VIDIOC-S-FREQUENCY;. They +take a pointer to a &v4l2-frequency; instead of an unsigned long +integer. +
+ +
+ Image Properties + + V4L2 has no equivalent of the +VIDIOCGPICT and VIDIOCSPICT +ioctl and struct video_picture. The following +fields where replaced by V4L2 controls accessible with the +&VIDIOC-QUERYCTRL;, &VIDIOC-G-CTRL; and &VIDIOC-S-CTRL; ioctls: + + + + struct video_picture + V4L2 Control ID + + + + + brightness + V4L2_CID_BRIGHTNESS + + + hue + V4L2_CID_HUE + + + colour + V4L2_CID_SATURATION + + + contrast + V4L2_CID_CONTRAST + + + whiteness + V4L2_CID_WHITENESS + + + + + + The V4L picture controls are assumed to range from 0 to +65535 with no particular reset value. The V4L2 API permits arbitrary +limits and defaults which can be queried with the &VIDIOC-QUERYCTRL; +ioctl. For general information about controls see . + + The depth (average number of +bits per pixel) of a video image is implied by the selected image +format. V4L2 does not explicitely provide such information assuming +applications recognizing the format are aware of the image depth and +others need not know. The palette field +moved into the &v4l2-pix-format;: + + + + struct video_picture +palette + &v4l2-pix-format; +pixfmt + + + + + VIDEO_PALETTE_GREY + V4L2_PIX_FMT_GREY + + + VIDEO_PALETTE_HI240 + V4L2_PIX_FMT_HI240 + This is a custom format used by the BTTV +driver, not one of the V4L2 standard formats. + + + + VIDEO_PALETTE_RGB565 + V4L2_PIX_FMT_RGB565 + + + VIDEO_PALETTE_RGB555 + V4L2_PIX_FMT_RGB555 + + + VIDEO_PALETTE_RGB24 + V4L2_PIX_FMT_BGR24 + + + VIDEO_PALETTE_RGB32 + V4L2_PIX_FMT_BGR32 + Presumably all V4L RGB formats are +little-endian, although some drivers might interpret them according to machine endianness. V4L2 defines little-endian, big-endian and red/blue +swapped variants. For details see . + + + + VIDEO_PALETTE_YUV422 + V4L2_PIX_FMT_YUYV + + + VIDEO_PALETTE_YUYV + VIDEO_PALETTE_YUV422 +and VIDEO_PALETTE_YUYV are the same formats. Some +V4L drivers respond to one, some to the other. + + V4L2_PIX_FMT_YUYV + + + VIDEO_PALETTE_UYVY + V4L2_PIX_FMT_UYVY + + + VIDEO_PALETTE_YUV420 + None + + + VIDEO_PALETTE_YUV411 + V4L2_PIX_FMT_Y41P + Not to be confused with +V4L2_PIX_FMT_YUV411P, which is a planar +format. + + + VIDEO_PALETTE_RAW + None V4L explains this +as: "RAW capture (BT848)" + + + VIDEO_PALETTE_YUV422P + V4L2_PIX_FMT_YUV422P + + + VIDEO_PALETTE_YUV411P + V4L2_PIX_FMT_YUV411P + Not to be confused with +V4L2_PIX_FMT_Y41P, which is a packed +format. + + + VIDEO_PALETTE_YUV420P + V4L2_PIX_FMT_YVU420 + + + VIDEO_PALETTE_YUV410P + V4L2_PIX_FMT_YVU410 + + + + + + V4L2 image formats are defined in . The image format can be selected with the +&VIDIOC-S-FMT; ioctl. +
+ +
+ Audio + + The VIDIOCGAUDIO and +VIDIOCSAUDIO ioctl and struct +video_audio are used to enumerate the +audio inputs of a V4L device. The equivalent V4L2 ioctls are +&VIDIOC-G-AUDIO; and &VIDIOC-S-AUDIO; using &v4l2-audio; as +discussed in . + + The audio "channel number" +field counting audio inputs was renamed to +index. + + On VIDIOCSAUDIO the +mode field selects one +of the VIDEO_SOUND_MONO, +VIDEO_SOUND_STEREO, +VIDEO_SOUND_LANG1 or +VIDEO_SOUND_LANG2 audio demodulation modes. When +the current audio standard is BTSC +VIDEO_SOUND_LANG2 refers to SAP and +VIDEO_SOUND_LANG1 is meaningless. Also +undocumented in the V4L specification, there is no way to query the +selected mode. On VIDIOCGAUDIO the driver returns +the actually received audio programmes in this +field. In the V4L2 API this information is stored in the &v4l2-tuner; +rxsubchans and +audmode fields, respectively. See for more information on tuners. Related to audio +modes &v4l2-audio; also reports if this is a mono or stereo +input, regardless if the source is a tuner. + + The following fields where replaced by V4L2 controls +accessible with the &VIDIOC-QUERYCTRL;, &VIDIOC-G-CTRL; and +&VIDIOC-S-CTRL; ioctls: + + + + struct +video_audio + V4L2 Control ID + + + + + volume + V4L2_CID_AUDIO_VOLUME + + + bass + V4L2_CID_AUDIO_BASS + + + treble + V4L2_CID_AUDIO_TREBLE + + + balance + V4L2_CID_AUDIO_BALANCE + + + + + + To determine which of these controls are supported by a +driver V4L provides the flags +VIDEO_AUDIO_VOLUME, +VIDEO_AUDIO_BASS, +VIDEO_AUDIO_TREBLE and +VIDEO_AUDIO_BALANCE. In the V4L2 API the +&VIDIOC-QUERYCTRL; ioctl reports if the respective control is +supported. Accordingly the VIDEO_AUDIO_MUTABLE +and VIDEO_AUDIO_MUTE flags where replaced by the +boolean V4L2_CID_AUDIO_MUTE control. + + All V4L2 controls have a step +attribute replacing the struct video_audio +step field. The V4L audio controls are +assumed to range from 0 to 65535 with no particular reset value. The +V4L2 API permits arbitrary limits and defaults which can be queried +with the &VIDIOC-QUERYCTRL; ioctl. For general information about +controls see . +
+ +
+ Frame Buffer Overlay + + The V4L2 ioctls equivalent to +VIDIOCGFBUF and VIDIOCSFBUF +are &VIDIOC-G-FBUF; and &VIDIOC-S-FBUF;. The +base field of struct +video_buffer remained unchanged, except V4L2 +defines a flag to indicate non-destructive overlays instead of a +NULL pointer. All other fields moved into the +&v4l2-pix-format; fmt substructure of +&v4l2-framebuffer;. The depth field was +replaced by pixelformat. See for a list of RGB formats and their +respective color depths. + + Instead of the special ioctls +VIDIOCGWIN and VIDIOCSWIN +V4L2 uses the general-purpose data format negotiation ioctls +&VIDIOC-G-FMT; and &VIDIOC-S-FMT;. They take a pointer to a +&v4l2-format; as argument. Here the win +member of the fmt union is used, a +&v4l2-window;. + + The x, +y, width and +height fields of struct +video_window moved into &v4l2-rect; +substructure w of struct +v4l2_window. The +chromakey, +clips, and +clipcount fields remained unchanged. Struct +video_clip was renamed to &v4l2-clip;, also +containing a struct v4l2_rect, but the +semantics are still the same. + + The VIDEO_WINDOW_INTERLACE flag was +dropped. Instead applications must set the +field field to +V4L2_FIELD_ANY or +V4L2_FIELD_INTERLACED. The +VIDEO_WINDOW_CHROMAKEY flag moved into +&v4l2-framebuffer;, under the new name +V4L2_FBUF_FLAG_CHROMAKEY. + + In V4L, storing a bitmap pointer in +clips and setting +clipcount to +VIDEO_CLIP_BITMAP (-1) requests bitmap +clipping, using a fixed size bitmap of 1024 × 625 bits. Struct +v4l2_window has a separate +bitmap pointer field for this purpose and +the bitmap size is determined by w.width and +w.height. + + The VIDIOCCAPTURE ioctl to enable or +disable overlay was renamed to &VIDIOC-OVERLAY;. +
+ +
+ Cropping + + To capture only a subsection of the full picture V4L +defines the VIDIOCGCAPTURE and +VIDIOCSCAPTURE ioctls using struct +video_capture. The equivalent V4L2 ioctls are +&VIDIOC-G-CROP; and &VIDIOC-S-CROP; using &v4l2-crop;, and the related +&VIDIOC-CROPCAP; ioctl. This is a rather complex matter, see + for details. + + The x, +y, width and +height fields moved into &v4l2-rect; +substructure c of struct +v4l2_crop. The +decimation field was dropped. In the V4L2 +API the scaling factor is implied by the size of the cropping +rectangle and the size of the captured or overlaid image. + + The VIDEO_CAPTURE_ODD +and VIDEO_CAPTURE_EVEN flags to capture only the +odd or even field, respectively, were replaced by +V4L2_FIELD_TOP and +V4L2_FIELD_BOTTOM in the field named +field of &v4l2-pix-format; and +&v4l2-window;. These structures are used to select a capture or +overlay format with the &VIDIOC-S-FMT; ioctl. +
+ +
+ Reading Images, Memory Mapping + +
+ Capturing using the read method + + There is no essential difference between reading images +from a V4L or V4L2 device using the &func-read; function, however V4L2 +drivers are not required to support this I/O method. Applications can +determine if the function is available with the &VIDIOC-QUERYCAP; +ioctl. All V4L2 devices exchanging data with applications must support +the &func-select; and &func-poll; functions. + + To select an image format and size, V4L provides the +VIDIOCSPICT and VIDIOCSWIN +ioctls. V4L2 uses the general-purpose data format negotiation ioctls +&VIDIOC-G-FMT; and &VIDIOC-S-FMT;. They take a pointer to a +&v4l2-format; as argument, here the &v4l2-pix-format; named +pix of its fmt +union is used. + + For more information about the V4L2 read interface see +. +
+
+ Capturing using memory mapping + + Applications can read from V4L devices by mapping +buffers in device memory, or more often just buffers allocated in +DMA-able system memory, into their address space. This avoids the data +copying overhead of the read method. V4L2 supports memory mapping as +well, with a few differences. + + + + + + V4L + V4L2 + + + + + + The image format must be selected before +buffers are allocated, with the &VIDIOC-S-FMT; ioctl. When no format +is selected the driver may use the last, possibly by another +application requested format. + + + Applications cannot change the number of +buffers. The it is built into the driver, unless it has a module +option to change the number when the driver module is +loaded. + The &VIDIOC-REQBUFS; ioctl allocates the +desired number of buffers, this is a required step in the initialization +sequence. + + + Drivers map all buffers as one contiguous +range of memory. The VIDIOCGMBUF ioctl is +available to query the number of buffers, the offset of each buffer +from the start of the virtual file, and the overall amount of memory +used, which can be used as arguments for the &func-mmap; +function. + Buffers are individually mapped. The +offset and size of each buffer can be determined with the +&VIDIOC-QUERYBUF; ioctl. + + + The VIDIOCMCAPTURE +ioctl prepares a buffer for capturing. It also determines the image +format for this buffer. The ioctl returns immediately, eventually with +an &EAGAIN; if no video signal had been detected. When the driver +supports more than one buffer applications can call the ioctl multiple +times and thus have multiple outstanding capture +requests.The VIDIOCSYNC ioctl +suspends execution until a particular buffer has been +filled. + Drivers maintain an incoming and outgoing +queue. &VIDIOC-QBUF; enqueues any empty buffer into the incoming +queue. Filled buffers are dequeued from the outgoing queue with the +&VIDIOC-DQBUF; ioctl. To wait until filled buffers become available this +function, &func-select; or &func-poll; can be used. The +&VIDIOC-STREAMON; ioctl must be called once after enqueuing one or +more buffers to start capturing. Its counterpart +&VIDIOC-STREAMOFF; stops capturing and dequeues all buffers from both +queues. Applications can query the signal status, if known, with the +&VIDIOC-ENUMINPUT; ioctl. + + + + + + For a more in-depth discussion of memory mapping and +examples, see . +
+
+ +
+ Reading Raw VBI Data + + Originally the V4L API did not specify a raw VBI capture +interface, only the device file /dev/vbi was +reserved for this purpose. The only driver supporting this interface +was the BTTV driver, de-facto defining the V4L VBI interface. Reading +from the device yields a raw VBI image with the following +parameters: + + + + &v4l2-vbi-format; + V4L, BTTV driver + + + + + sampling_rate + 28636363 Hz NTSC (or any other 525-line +standard); 35468950 Hz PAL and SECAM (625-line standards) + + + offset + ? + + + samples_per_line + 2048 + + + sample_format + V4L2_PIX_FMT_GREY. The last four bytes (a +machine endianness integer) contain a frame counter. + + + start[] + 10, 273 NTSC; 22, 335 PAL and SECAM + + + count[] + 16, 16Old driver +versions used different values, eventually the custom +BTTV_VBISIZE ioctl was added to query the +correct values. + + + flags + 0 + + + + + + Undocumented in the V4L specification, in Linux 2.3 the +VIDIOCGVBIFMT and +VIDIOCSVBIFMT ioctls using struct +vbi_format were added to determine the VBI +image parameters. These ioctls are only partially compatible with the +V4L2 VBI interface specified in . + + An offset field does not +exist, sample_format is supposed to be +VIDEO_PALETTE_RAW, equivalent to +V4L2_PIX_FMT_GREY. The remaining fields are +probably equivalent to &v4l2-vbi-format;. + + Apparently only the Zoran (ZR 36120) driver implements +these ioctls. The semantics differ from those specified for V4L2 in two +ways. The parameters are reset on &func-open; and +VIDIOCSVBIFMT always returns an &EINVAL; if the +parameters are invalid. +
+ +
+ Miscellaneous + + V4L2 has no equivalent of the +VIDIOCGUNIT ioctl. Applications can find the VBI +device associated with a video capture device (or vice versa) by +reopening the device and requesting VBI data. For details see +. + + No replacement exists for VIDIOCKEY, +and the V4L functions for microcode programming. A new interface for +MPEG compression and playback devices is documented in . +
+ +
+ +
+ Changes of the V4L2 API + + Soon after the V4L API was added to the kernel it was +criticised as too inflexible. In August 1998 Bill Dirks proposed a +number of improvements and began to work on documentation, example +drivers and applications. With the help of other volunteers this +eventually became the V4L2 API, not just an extension but a +replacement for the V4L API. However it took another four years and +two stable kernel releases until the new API was finally accepted for +inclusion into the kernel in its present form. + +
+ Early Versions + 1998-08-20: First version. + + 1998-08-27: The &func-select; function was introduced. + + 1998-09-10: New video standard interface. + + 1998-09-18: The VIDIOC_NONCAP ioctl +was replaced by the otherwise meaningless O_TRUNC +&func-open; flag, and the aliases O_NONCAP and +O_NOIO were defined. Applications can set this +flag if they intend to access controls only, as opposed to capture +applications which need exclusive access. The +VIDEO_STD_XXX identifiers are now ordinals +instead of flags, and the video_std_construct() +helper function takes id and transmission arguments. + + 1998-09-28: Revamped video standard. Made video controls +individually enumerable. + + 1998-10-02: The id field was +removed from struct video_standard and the +color subcarrier fields were renamed. The &VIDIOC-QUERYSTD; ioctl was +renamed to &VIDIOC-ENUMSTD;, &VIDIOC-G-INPUT; to &VIDIOC-ENUMINPUT;. A +first draft of the Codec API was released. + + 1998-11-08: Many minor changes. Most symbols have been +renamed. Some material changes to &v4l2-capability;. + + 1998-11-12: The read/write directon of some ioctls was misdefined. + + 1998-11-14: V4L2_PIX_FMT_RGB24 +changed to V4L2_PIX_FMT_BGR24, and +V4L2_PIX_FMT_RGB32 changed to +V4L2_PIX_FMT_BGR32. Audio controls are now +accessible with the &VIDIOC-G-CTRL; and &VIDIOC-S-CTRL; ioctls under +names starting with V4L2_CID_AUDIO. The +V4L2_MAJOR define was removed from +videodev.h since it was only used once in the +videodev kernel module. The +YUV422 and YUV411 planar +image formats were added. + + 1998-11-28: A few ioctl symbols changed. Interfaces for codecs and +video output devices were added. + + 1999-01-14: A raw VBI capture interface was added. + + 1999-01-19: The VIDIOC_NEXTBUF ioctl + was removed. +
+ +
+ V4L2 Version 0.16 1999-01-31 + 1999-01-27: There is now one QBUF ioctl, VIDIOC_QWBUF and VIDIOC_QRBUF +are gone. VIDIOC_QBUF takes a v4l2_buffer as a parameter. Added +digital zoom (cropping) controls. +
+ + + +
+ V4L2 Version 0.18 1999-03-16 + Added a v4l to V4L2 ioctl compatibility layer to +videodev.c. Driver writers, this changes how you implement your ioctl +handler. See the Driver Writer's Guide. Added some more control id +codes. +
+ +
+ V4L2 Version 0.19 1999-06-05 + 1999-03-18: Fill in the category and catname fields of +v4l2_queryctrl objects before passing them to the driver. Required a +minor change to the VIDIOC_QUERYCTRL handlers in the sample +drivers. + 1999-03-31: Better compatibility for v4l memory capture +ioctls. Requires changes to drivers to fully support new compatibility +features, see Driver Writer's Guide and v4l2cap.c. Added new control +IDs: V4L2_CID_HFLIP, _VFLIP. Changed V4L2_PIX_FMT_YUV422P to _YUV422P, +and _YUV411P to _YUV411P. + 1999-04-04: Added a few more control IDs. + 1999-04-07: Added the button control type. + 1999-05-02: Fixed a typo in videodev.h, and added the +V4L2_CTRL_FLAG_GRAYED (later V4L2_CTRL_FLAG_GRABBED) flag. + 1999-05-20: Definition of VIDIOC_G_CTRL was wrong causing +a malfunction of this ioctl. + 1999-06-05: Changed the value of +V4L2_CID_WHITENESS. +
+ +
+ V4L2 Version 0.20 (1999-09-10) + + Version 0.20 introduced a number of changes which were +not backward compatible with 0.19 and earlier +versions. Purpose of these changes was to simplify the API, while +making it more extensible and following common Linux driver API +conventions. + + + + Some typos in V4L2_FMT_FLAG +symbols were fixed. &v4l2-clip; was changed for compatibility with +v4l. (1999-08-30) + + + + V4L2_TUNER_SUB_LANG1 was added. +(1999-09-05) + + + + All ioctl() commands that used an integer argument now +take a pointer to an integer. Where it makes sense, ioctls will return +the actual new value in the integer pointed to by the argument, a +common convention in the V4L2 API. The affected ioctls are: +VIDIOC_PREVIEW, VIDIOC_STREAMON, VIDIOC_STREAMOFF, VIDIOC_S_FREQ, +VIDIOC_S_INPUT, VIDIOC_S_OUTPUT, VIDIOC_S_EFFECT. For example + +err = ioctl (fd, VIDIOC_XXX, V4L2_XXX); + becomes +int a = V4L2_XXX; err = ioctl(fd, VIDIOC_XXX, &a); + + + + + + All the different get- and set-format commands were +swept into one &VIDIOC-G-FMT; and &VIDIOC-S-FMT; ioctl taking a union +and a type field selecting the union member as parameter. Purpose is to +simplify the API by eliminating several ioctls and to allow new and +driver private data streams without adding new ioctls. + + This change obsoletes the following ioctls: +VIDIOC_S_INFMT, +VIDIOC_G_INFMT, +VIDIOC_S_OUTFMT, +VIDIOC_G_OUTFMT, +VIDIOC_S_VBIFMT and +VIDIOC_G_VBIFMT. The image format structure +v4l2_format was renamed to &v4l2-pix-format;, +while &v4l2-format; is now the envelopping structure for all format +negotiations. + + + + Similar to the changes above, the +VIDIOC_G_PARM and +VIDIOC_S_PARM ioctls were merged with +VIDIOC_G_OUTPARM and +VIDIOC_S_OUTPARM. A +type field in the new &v4l2-streamparm; +selects the respective union member. + + This change obsoletes the +VIDIOC_G_OUTPARM and +VIDIOC_S_OUTPARM ioctls. + + + + Control enumeration was simplified, and two new +control flags were introduced and one dropped. The +catname field was replaced by a +group field. + + Drivers can now flag unsupported and temporarily +unavailable controls with V4L2_CTRL_FLAG_DISABLED +and V4L2_CTRL_FLAG_GRABBED respectively. The +group name indicates a possibly narrower +classification than the category. In other +words, there may be multiple groups within a category. Controls within +a group would typically be drawn within a group box. Controls in +different categories might have a greater separation, or may even +appear in separate windows. + + + + The &v4l2-buffer; timestamp +was changed to a 64 bit integer, containing the sampling or output +time of the frame in nanoseconds. Additionally timestamps will be in +absolute system time, not starting from zero at the beginning of a +stream. The data type name for timestamps is stamp_t, defined as a +signed 64-bit integer. Output devices should not send a buffer out +until the time in the timestamp field has arrived. I would like to +follow SGI's lead, and adopt a multimedia timestamping system like +their UST (Unadjusted System Time). See +http://web.archive.org/web/*/http://reality.sgi.com +/cpirazzi_engr/lg/time/intro.html. +UST uses timestamps that are 64-bit signed integers +(not struct timeval's) and given in nanosecond units. The UST clock +starts at zero when the system is booted and runs continuously and +uniformly. It takes a little over 292 years for UST to overflow. There +is no way to set the UST clock. The regular Linux time-of-day clock +can be changed periodically, which would cause errors if it were being +used for timestamping a multimedia stream. A real UST style clock will +require some support in the kernel that is not there yet. But in +anticipation, I will change the timestamp field to a 64-bit integer, +and I will change the v4l2_masterclock_gettime() function (used only +by drivers) to return a 64-bit integer. + + + + A sequence field was added +to &v4l2-buffer;. The sequence field counts +captured frames, it is ignored by output devices. When a capture +driver drops a frame, the sequence number of that frame is +skipped. + + +
+ +
+ V4L2 Version 0.20 incremental changes + + + 1999-12-23: In &v4l2-vbi-format; the +reserved1 field became +offset. Previously drivers were required to +clear the reserved1 field. + + 2000-01-13: The + V4L2_FMT_FLAG_NOT_INTERLACED flag was added. + + 2000-07-31: The linux/poll.h header +is now included by videodev.h for compatibility +with the original videodev.h file. + + 2000-11-20: V4L2_TYPE_VBI_OUTPUT and +V4L2_PIX_FMT_Y41P were added. + + 2000-11-25: V4L2_TYPE_VBI_INPUT was +added. + + 2000-12-04: A couple typos in symbol names were fixed. + + 2001-01-18: To avoid namespace conflicts the +fourcc macro defined in the +videodev.h header file was renamed to +v4l2_fourcc. + + 2001-01-25: A possible driver-level compatibility problem +between the videodev.h file in Linux 2.4.0 and +the videodev.h file included in the +videodevX patch was fixed. Users of an earlier +version of videodevX on Linux 2.4.0 should +recompile their V4L and V4L2 drivers. + + 2001-01-26: A possible kernel-level incompatibility +between the videodev.h file in the +videodevX patch and the +videodev.h file in Linux 2.2.x with devfs patches +applied was fixed. + + 2001-03-02: Certain V4L ioctls which pass data in both +direction although they are defined with read-only parameter, did not +work correctly through the backward compatibility layer. +[Solution?] + + 2001-04-13: Big endian 16-bit RGB formats were added. + + 2001-09-17: New YUV formats and the &VIDIOC-G-FREQUENCY; and +&VIDIOC-S-FREQUENCY; ioctls were added. (The old +VIDIOC_G_FREQ and +VIDIOC_S_FREQ ioctls did not take multiple tuners +into account.) + + 2000-09-18: V4L2_BUF_TYPE_VBI was +added. This may break compatibility as the +&VIDIOC-G-FMT; and &VIDIOC-S-FMT; ioctls may fail now if the struct +v4l2_fmt type +field does not contain V4L2_BUF_TYPE_VBI. In the +documentation of the &v4l2-vbi-format; +offset field the ambiguous phrase "rising +edge" was changed to "leading edge". +
+ +
+ V4L2 Version 0.20 2000-11-23 + + A number of changes were made to the raw VBI +interface. + + + + Figures clarifying the line numbering scheme were +added to the V4L2 API specification. The +start[0] and +start[1] fields no longer count line +numbers beginning at zero. Rationale: a) The previous definition was +unclear. b) The start[] values are ordinal +numbers. c) There is no point in inventing a new line numbering +scheme. We now use line number as defined by ITU-R, period. +Compatibility: Add one to the start values. Applications depending on +the previous semantics may not function correctly. + + + + The restriction "count[0] > 0 and count[1] > 0" +has been relaxed to "(count[0] + count[1]) > 0". Rationale: +Drivers may allocate resources at scan line granularity and some data +services are transmitted only on the first field. The comment that +both count values will usually be equal is +misleading and pointless and has been removed. This change +breaks compatibility with earlier versions: +Drivers may return EINVAL, applications may not function +correctly. + + + + Drivers are again permitted to return negative +(unknown) start values as proposed earlier. Why this feature was +dropped is unclear. This change may break +compatibility with applications depending on the start +values being positive. The use of EBUSY and +EINVAL error codes with the &VIDIOC-S-FMT; ioctl +was clarified. The &EBUSY; was finally documented, and the +reserved2 field which was previously +mentioned only in the videodev.h header +file. + + + + New buffer types +V4L2_TYPE_VBI_INPUT and +V4L2_TYPE_VBI_OUTPUT were added. The former is an +alias for the old V4L2_TYPE_VBI, the latter was +missing in the videodev.h file. + + +
+ +
+ V4L2 Version 0.20 2002-07-25 + Added sliced VBI interface proposal. +
+ +
+ V4L2 in Linux 2.5.46, 2002-10 + + Around October-November 2002, prior to an announced +feature freeze of Linux 2.5, the API was revised, drawing from +experience with V4L2 0.20. This unnamed version was finally merged +into Linux 2.5.46. + + + + As specified in , drivers +must make related device functions available under all minor device +numbers. + + + + The &func-open; function requires access mode +O_RDWR regardless of the device type. All V4L2 +drivers exchanging data with applications must support the +O_NONBLOCK flag. The O_NOIO +flag, a V4L2 symbol which aliased the meaningless +O_TRUNC to indicate accesses without data +exchange (panel applications) was dropped. Drivers must stay in "panel +mode" until the application attempts to initiate a data exchange, see +. + + + + The &v4l2-capability; changed dramatically. Note that +also the size of the structure changed, which is encoded in the ioctl +request code, thus older V4L2 devices will respond with an &EINVAL; to +the new &VIDIOC-QUERYCAP; ioctl. + + There are new fields to identify the driver, a new RDS +device function V4L2_CAP_RDS_CAPTURE, the +V4L2_CAP_AUDIO flag indicates if the device has +any audio connectors, another I/O capability +V4L2_CAP_ASYNCIO can be flagged. In response to +these changes the type field became a bit +set and was merged into the flags field. +V4L2_FLAG_TUNER was renamed to +V4L2_CAP_TUNER, +V4L2_CAP_VIDEO_OVERLAY replaced +V4L2_FLAG_PREVIEW and +V4L2_CAP_VBI_CAPTURE and +V4L2_CAP_VBI_OUTPUT replaced +V4L2_FLAG_DATA_SERVICE. +V4L2_FLAG_READ and +V4L2_FLAG_WRITE were merged into +V4L2_CAP_READWRITE. + + The redundant fields +inputs, outputs +and audios were removed. These properties +can be determined as described in and . + + The somewhat volatile and therefore barely useful +fields maxwidth, +maxheight, +minwidth, +minheight, +maxframerate were removed. This information +is available as described in and +. + + V4L2_FLAG_SELECT was removed. We +believe the select() function is important enough to require support +of it in all V4L2 drivers exchanging data with applications. The +redundant V4L2_FLAG_MONOCHROME flag was removed, +this information is available as described in . + + + + In &v4l2-input; the +assoc_audio field and the +capability field and its only flag +V4L2_INPUT_CAP_AUDIO was replaced by the new +audioset field. Instead of linking one +video input to one audio input this field reports all audio inputs +this video input combines with. + + New fields are tuner +(reversing the former link from tuners to video inputs), +std and +status. + + Accordingly &v4l2-output; lost its +capability and +assoc_audio fields. +audioset, +modulator and +std where added instead. + + + + The &v4l2-audio; field +audio was renamed to +index, for consistency with other +structures. A new capability flag +V4L2_AUDCAP_STEREO was added to indicated if the +audio input in question supports stereo sound. +V4L2_AUDCAP_EFFECTS and the corresponding +V4L2_AUDMODE flags where removed. This can be +easily implemented using controls. (However the same applies to AVL +which is still there.) + + Again for consistency the &v4l2-audioout; field +audio was renamed to +index. + + + + The &v4l2-tuner; +input field was replaced by an +index field, permitting devices with +multiple tuners. The link between video inputs and tuners is now +reversed, inputs point to their tuner. The +std substructure became a +simple set (more about this below) and moved into &v4l2-input;. A +type field was added. + + Accordingly in &v4l2-modulator; the +output was replaced by an +index field. + + In &v4l2-frequency; the +port field was replaced by a +tuner field containing the respective tuner +or modulator index number. A tuner type +field was added and the reserved field +became larger for future extensions (satellite tuners in +particular). + + + + The idea of completely transparent video standards was +dropped. Experience showed that applications must be able to work with +video standards beyond presenting the user a menu. Instead of +enumerating supported standards with an ioctl applications can now +refer to standards by &v4l2-std-id; and symbols defined in the +videodev2.h header file. For details see . The &VIDIOC-G-STD; and +&VIDIOC-S-STD; now take a pointer to this type as argument. +&VIDIOC-QUERYSTD; was added to autodetect the received standard, if +the hardware has this capability. In &v4l2-standard; an +index field was added for &VIDIOC-ENUMSTD;. +A &v4l2-std-id; field named id was added as +machine readable identifier, also replacing the +transmission field. The misleading +framerate field was renamed +to frameperiod. The now obsolete +colorstandard information, originally +needed to distguish between variations of standards, were +removed. + + Struct v4l2_enumstd ceased to +be. &VIDIOC-ENUMSTD; now takes a pointer to a &v4l2-standard; +directly. The information which standards are supported by a +particular video input or output moved into &v4l2-input; and +&v4l2-output; fields named std, +respectively. + + + + The &v4l2-queryctrl; fields +category and +group did not catch on and/or were not +implemented as expected and therefore removed. + + + + The &VIDIOC-TRY-FMT; ioctl was added to negotiate data +formats as with &VIDIOC-S-FMT;, but without the overhead of +programming the hardware and regardless of I/O in progress. + + In &v4l2-format; the fmt +union was extended to contain &v4l2-window;. All image format +negotiations are now possible with VIDIOC_G_FMT, +VIDIOC_S_FMT and +VIDIOC_TRY_FMT; ioctl. The +VIDIOC_G_WIN and +VIDIOC_S_WIN ioctls to prepare for a video +overlay were removed. The type field +changed to type &v4l2-buf-type; and the buffer type names changed as +follows. + + + + Old defines + &v4l2-buf-type; + + + + + V4L2_BUF_TYPE_CAPTURE + V4L2_BUF_TYPE_VIDEO_CAPTURE + + + V4L2_BUF_TYPE_CODECIN + Omitted for now + + + V4L2_BUF_TYPE_CODECOUT + Omitted for now + + + V4L2_BUF_TYPE_EFFECTSIN + Omitted for now + + + V4L2_BUF_TYPE_EFFECTSIN2 + Omitted for now + + + V4L2_BUF_TYPE_EFFECTSOUT + Omitted for now + + + V4L2_BUF_TYPE_VIDEOOUT + V4L2_BUF_TYPE_VIDEO_OUTPUT + + + - + V4L2_BUF_TYPE_VIDEO_OVERLAY + + + - + V4L2_BUF_TYPE_VBI_CAPTURE + + + - + V4L2_BUF_TYPE_VBI_OUTPUT + + + - + V4L2_BUF_TYPE_SLICED_VBI_CAPTURE + + + - + V4L2_BUF_TYPE_SLICED_VBI_OUTPUT + + + V4L2_BUF_TYPE_PRIVATE_BASE + V4L2_BUF_TYPE_PRIVATE (but this is deprecated) + + + + + + + + In &v4l2-fmtdesc; a &v4l2-buf-type; field named +type was added as in &v4l2-format;. The +VIDIOC_ENUM_FBUFFMT ioctl is no longer needed and +was removed. These calls can be replaced by &VIDIOC-ENUM-FMT; with +type V4L2_BUF_TYPE_VIDEO_OVERLAY. + + + + In &v4l2-pix-format; the +depth field was removed, assuming +applications which recognize the format by its four-character-code +already know the color depth, and others do not care about it. The +same rationale lead to the removal of the +V4L2_FMT_FLAG_COMPRESSED flag. The +V4L2_FMT_FLAG_SWCONVECOMPRESSED flag was removed +because drivers are not supposed to convert images in kernel space. A +user library of conversion functions should be provided instead. The +V4L2_FMT_FLAG_BYTESPERLINE flag was redundant. +Applications can set the bytesperline field +to zero to get a reasonable default. Since the remaining flags were +replaced as well, the flags field itself +was removed. + The interlace flags were replaced by a &v4l2-field; +value in a newly added field +field. + + + + Old flag + &v4l2-field; + + + + + V4L2_FMT_FLAG_NOT_INTERLACED + ? + + + V4L2_FMT_FLAG_INTERLACED += V4L2_FMT_FLAG_COMBINED + V4L2_FIELD_INTERLACED + + + V4L2_FMT_FLAG_TOPFIELD += V4L2_FMT_FLAG_ODDFIELD + V4L2_FIELD_TOP + + + V4L2_FMT_FLAG_BOTFIELD += V4L2_FMT_FLAG_EVENFIELD + V4L2_FIELD_BOTTOM + + + - + V4L2_FIELD_SEQ_TB + + + - + V4L2_FIELD_SEQ_BT + + + - + V4L2_FIELD_ALTERNATE + + + + + + The color space flags were replaced by a +&v4l2-colorspace; value in a newly added +colorspace field, where one of +V4L2_COLORSPACE_SMPTE170M, +V4L2_COLORSPACE_BT878, +V4L2_COLORSPACE_470_SYSTEM_M or +V4L2_COLORSPACE_470_SYSTEM_BG replaces +V4L2_FMT_CS_601YUV. + + + + In &v4l2-requestbuffers; the +type field was properly defined as +&v4l2-buf-type;. Buffer types changed as mentioned above. A new +memory field of type &v4l2-memory; was +added to distinguish between I/O methods using buffers allocated +by the driver or the application. See for +details. + + + + In &v4l2-buffer; the type +field was properly defined as &v4l2-buf-type;. Buffer types changed as +mentioned above. A field field of type +&v4l2-field; was added to indicate if a buffer contains a top or +bottom field. The old field flags were removed. Since no unadjusted +system time clock was added to the kernel as planned, the +timestamp field changed back from type +stamp_t, an unsigned 64 bit integer expressing the sample time in +nanoseconds, to struct timeval. With the +addition of a second memory mapping method the +offset field moved into union +m, and a new +memory field of type &v4l2-memory; was +added to distinguish between I/O methods. See +for details. + + The V4L2_BUF_REQ_CONTIG +flag was used by the V4L compatibility layer, after changes to this +code it was no longer needed. The +V4L2_BUF_ATTR_DEVICEMEM flag would indicate if +the buffer was indeed allocated in device memory rather than DMA-able +system memory. It was barely useful and so was removed. + + + + In &v4l2-framebuffer; the +base[3] array anticipating double- and +triple-buffering in off-screen video memory, however without defining +a synchronization mechanism, was replaced by a single pointer. The +V4L2_FBUF_CAP_SCALEUP and +V4L2_FBUF_CAP_SCALEDOWN flags were removed. +Applications can determine this capability more accurately using the +new cropping and scaling interface. The +V4L2_FBUF_CAP_CLIPPING flag was replaced by +V4L2_FBUF_CAP_LIST_CLIPPING and +V4L2_FBUF_CAP_BITMAP_CLIPPING. + + + + In &v4l2-clip; the x, +y, width and +height field moved into a +c substructure of type &v4l2-rect;. The +x and y fields +were renamed to left and +top, &ie; offsets to a context dependent +origin. + + + + In &v4l2-window; the x, +y, width and +height field moved into a +w substructure as above. A +field field of type %v4l2-field; was added +to distinguish between field and frame (interlaced) overlay. + + + + The digital zoom interface, including struct +v4l2_zoomcap, struct +v4l2_zoom, +V4L2_ZOOM_NONCAP and +V4L2_ZOOM_WHILESTREAMING was replaced by a new +cropping and scaling interface. The previously unused struct +v4l2_cropcap and +v4l2_crop where redefined for this purpose. +See for details. + + + + In &v4l2-vbi-format; the +SAMPLE_FORMAT field now contains a +four-character-code as used to identify video image formats and +V4L2_PIX_FMT_GREY replaces the +V4L2_VBI_SF_UBYTE define. The +reserved field was extended. + + + + In &v4l2-captureparm; the type of the +timeperframe field changed from unsigned +long to &v4l2-fract;. This allows the accurate expression of multiples +of the NTSC-M frame rate 30000 / 1001. A new field +readbuffers was added to control the driver +behaviour in read I/O mode. + + Similar changes were made to &v4l2-outputparm;. + + + + The struct v4l2_performance +and VIDIOC_G_PERF ioctl were dropped. Except when +using the read/write I/O method, which is +limited anyway, this information is already available to +applications. + + + + The example transformation from RGB to YCbCr color +space in the old V4L2 documentation was inaccurate, this has been +corrected in . + + +
+ +
+ V4L2 2003-06-19 + + + + A new capability flag +V4L2_CAP_RADIO was added for radio devices. Prior +to this change radio devices would identify solely by having exactly one +tuner whose type field reads V4L2_TUNER_RADIO. + + + + An optional driver access priority mechanism was +added, see for details. + + + + The audio input and output interface was found to be +incomplete. + Previously the &VIDIOC-G-AUDIO; +ioctl would enumerate the available audio inputs. An ioctl to +determine the current audio input, if more than one combines with the +current video input, did not exist. So +VIDIOC_G_AUDIO was renamed to +VIDIOC_G_AUDIO_OLD, this ioctl was removed on +Kernel 2.6.39. The &VIDIOC-ENUMAUDIO; ioctl was added to enumerate +audio inputs, while &VIDIOC-G-AUDIO; now reports the current audio +input. + The same changes were made to &VIDIOC-G-AUDOUT; and +&VIDIOC-ENUMAUDOUT;. + Until further the "videodev" module will automatically +translate between the old and new ioctls, but drivers and applications +must be updated to successfully compile again. + + + + The &VIDIOC-OVERLAY; ioctl was incorrectly defined with +write-read parameter. It was changed to write-only, while the write-read +version was renamed to VIDIOC_OVERLAY_OLD. The old +ioctl was removed on Kernel 2.6.39. Until further the "videodev" +kernel module will automatically translate to the new version, so drivers +must be recompiled, but not applications. + + + + incorrectly stated that +clipping rectangles define regions where the video can be seen. +Correct is that clipping rectangles define regions where +no video shall be displayed and so the graphics +surface can be seen. + + + + The &VIDIOC-S-PARM; and &VIDIOC-S-CTRL; ioctls were +defined with write-only parameter, inconsistent with other ioctls +modifying their argument. They were changed to write-read, while a +_OLD suffix was added to the write-only versions. +The old ioctls were removed on Kernel 2.6.39. Drivers and +applications assuming a constant parameter need an update. + + +
+ +
+ V4L2 2003-11-05 + + + In the following pixel +formats were incorrectly transferred from Bill Dirks' V4L2 +specification. Descriptions below refer to bytes in memory, in +ascending address order. + + + + Symbol + In this document prior to revision +0.5 + Corrected + + + + + V4L2_PIX_FMT_RGB24 + B, G, R + R, G, B + + + V4L2_PIX_FMT_BGR24 + R, G, B + B, G, R + + + V4L2_PIX_FMT_RGB32 + B, G, R, X + R, G, B, X + + + V4L2_PIX_FMT_BGR32 + R, G, B, X + B, G, R, X + + + + The +V4L2_PIX_FMT_BGR24 example was always +correct. + In the mapping +of the V4L VIDEO_PALETTE_RGB24 and +VIDEO_PALETTE_RGB32 formats to V4L2 pixel formats +was accordingly corrected. + + + + Unrelated to the fixes above, drivers may still +interpret some V4L2 RGB pixel formats differently. These issues have +yet to be addressed, for details see . + + +
+ +
+ V4L2 in Linux 2.6.6, 2004-05-09 + + + The &VIDIOC-CROPCAP; ioctl was incorrectly defined +with read-only parameter. It is now defined as write-read ioctl, while +the read-only version was renamed to +VIDIOC_CROPCAP_OLD. The old ioctl was removed +on Kernel 2.6.39. + + +
+ +
+ V4L2 in Linux 2.6.8 + + + A new field input (former +reserved[0]) was added to the &v4l2-buffer; +structure. Purpose of this field is to alternate between video inputs +(⪚ cameras) in step with the video capturing process. This function +must be enabled with the new V4L2_BUF_FLAG_INPUT +flag. The flags field is no longer +read-only. + + +
+ +
+ V4L2 spec erratum 2004-08-01 + + + + The return value of the + function was incorrectly documented. + + + + Audio output ioctls end in -AUDOUT, not -AUDIOOUT. + + + + In the Current Audio Input example the +VIDIOC_G_AUDIO ioctl took the wrong +argument. + + + + The documentation of the &VIDIOC-QBUF; and +&VIDIOC-DQBUF; ioctls did not mention the &v4l2-buffer; +memory field. It was also missing from +examples. Also on the VIDIOC_DQBUF page the &EIO; +was not documented. + + +
+ +
+ V4L2 in Linux 2.6.14 + + + A new sliced VBI interface was added. It is documented +in and replaces the interface first +proposed in V4L2 specification 0.8. + + +
+ +
+ V4L2 in Linux 2.6.15 + + + The &VIDIOC-LOG-STATUS; ioctl was added. + + + + New video standards +V4L2_STD_NTSC_443, +V4L2_STD_SECAM_LC, +V4L2_STD_SECAM_DK (a set of SECAM D, K and K1), +and V4L2_STD_ATSC (a set of +V4L2_STD_ATSC_8_VSB and +V4L2_STD_ATSC_16_VSB) were defined. Note the +V4L2_STD_525_60 set now includes +V4L2_STD_NTSC_443. See also . + + + + The VIDIOC_G_COMP and +VIDIOC_S_COMP ioctl were renamed to +VIDIOC_G_MPEGCOMP and +VIDIOC_S_MPEGCOMP respectively. Their argument +was replaced by a struct +v4l2_mpeg_compression pointer. (The +VIDIOC_G_MPEGCOMP and +VIDIOC_S_MPEGCOMP ioctls where removed in Linux +2.6.25.) + + +
+ +
+ V4L2 spec erratum 2005-11-27 + The capture example in +called the &VIDIOC-S-CROP; ioctl without checking if cropping is +supported. In the video standard selection example in + the &VIDIOC-S-STD; call used the wrong +argument type. +
+ +
+ V4L2 spec erratum 2006-01-10 + + + The V4L2_IN_ST_COLOR_KILL flag in +&v4l2-input; not only indicates if the color killer is enabled, but +also if it is active. (The color killer disables color decoding when +it detects no color in the video signal to improve the image +quality.) + + + + &VIDIOC-S-PARM; is a write-read ioctl, not write-only as +stated on its reference page. The ioctl changed in 2003 as noted above. + + +
+ +
+ V4L2 spec erratum 2006-02-03 + + + In &v4l2-captureparm; and &v4l2-outputparm; the +timeperframe field gives the time in +seconds, not microseconds. + + +
+ +
+ V4L2 spec erratum 2006-02-04 + + + The clips field in +&v4l2-window; must point to an array of &v4l2-clip;, not a linked +list, because drivers ignore the struct +v4l2_clip.next +pointer. + + +
+ +
+ V4L2 in Linux 2.6.17 + + + New video standard macros were added: +V4L2_STD_NTSC_M_KR (NTSC M South Korea), and the +sets V4L2_STD_MN, +V4L2_STD_B, V4L2_STD_GH and +V4L2_STD_DK. The +V4L2_STD_NTSC and +V4L2_STD_SECAM sets now include +V4L2_STD_NTSC_M_KR and +V4L2_STD_SECAM_LC respectively. + + + + A new V4L2_TUNER_MODE_LANG1_LANG2 +was defined to record both languages of a bilingual program. The +use of V4L2_TUNER_MODE_STEREO for this purpose +is deprecated now. See the &VIDIOC-G-TUNER; section for +details. + + +
+ +
+ V4L2 spec erratum 2006-09-23 (Draft 0.15) + + + In various places +V4L2_BUF_TYPE_SLICED_VBI_CAPTURE and +V4L2_BUF_TYPE_SLICED_VBI_OUTPUT of the sliced VBI +interface were not mentioned along with other buffer types. + + + + In it was clarified +that the &v4l2-audio; mode field is a flags +field. + + + + did not mention the +sliced VBI and radio capability flags. + + + + In it was +clarified that applications must initialize the tuner +type field of &v4l2-frequency; before +calling &VIDIOC-S-FREQUENCY;. + + + + The reserved array +in &v4l2-requestbuffers; has 2 elements, not 32. + + + + In and the device file names +/dev/vout which never caught on were replaced +by /dev/video. + + + + With Linux 2.6.15 the possible range for VBI device minor +numbers was extended from 224-239 to 224-255. Accordingly device file names +/dev/vbi0 to /dev/vbi31 are +possible now. + + +
+ +
+ V4L2 in Linux 2.6.18 + + + New ioctls &VIDIOC-G-EXT-CTRLS;, &VIDIOC-S-EXT-CTRLS; +and &VIDIOC-TRY-EXT-CTRLS; were added, a flag to skip unsupported +controls with &VIDIOC-QUERYCTRL;, new control types +V4L2_CTRL_TYPE_INTEGER64 and +V4L2_CTRL_TYPE_CTRL_CLASS (), and new control flags +V4L2_CTRL_FLAG_READ_ONLY, +V4L2_CTRL_FLAG_UPDATE, +V4L2_CTRL_FLAG_INACTIVE and +V4L2_CTRL_FLAG_SLIDER (). See for details. + + +
+ +
+ V4L2 in Linux 2.6.19 + + + In &v4l2-sliced-vbi-cap; a buffer type field was added +replacing a reserved field. Note on architectures where the size of +enum types differs from int types the size of the structure changed. +The &VIDIOC-G-SLICED-VBI-CAP; ioctl was redefined from being read-only +to write-read. Applications must initialize the type field and clear +the reserved fields now. These changes may break the +compatibility with older drivers and applications. + + + + The ioctls &VIDIOC-ENUM-FRAMESIZES; and +&VIDIOC-ENUM-FRAMEINTERVALS; were added. + + + + A new pixel format V4L2_PIX_FMT_RGB444 () was added. + + +
+ +
+ V4L2 spec erratum 2006-10-12 (Draft 0.17) + + + V4L2_PIX_FMT_HM12 () is a YUV 4:2:0, not 4:2:2 format. + + +
+ +
+ V4L2 in Linux 2.6.21 + + + The videodev2.h header file is +now dual licensed under GNU General Public License version two or +later, and under a 3-clause BSD-style license. + + +
+ +
+ V4L2 in Linux 2.6.22 + + + Two new field orders + V4L2_FIELD_INTERLACED_TB and + V4L2_FIELD_INTERLACED_BT were + added. See for details. + + + + Three new clipping/blending methods with a global or +straight or inverted local alpha value were added to the video overlay +interface. See the description of the &VIDIOC-G-FBUF; and +&VIDIOC-S-FBUF; ioctls for details. + A new global_alpha field +was added to v4l2_window, +extending the structure. This may break +compatibility with applications using a struct +v4l2_window directly. However the VIDIOC_G/S/TRY_FMT ioctls, which take a +pointer to a v4l2_format parent +structure with padding bytes at the end, are not affected. + + + + The format of the chromakey +field in &v4l2-window; changed from "host order RGB32" to a pixel +value in the same format as the framebuffer. This may break +compatibility with existing applications. Drivers +supporting the "host order RGB32" format are not known. + + + +
+ +
+ V4L2 in Linux 2.6.24 + + + The pixel formats +V4L2_PIX_FMT_PAL8, +V4L2_PIX_FMT_YUV444, +V4L2_PIX_FMT_YUV555, +V4L2_PIX_FMT_YUV565 and +V4L2_PIX_FMT_YUV32 were added. + + +
+ +
+ V4L2 in Linux 2.6.25 + + + The pixel formats +V4L2_PIX_FMT_Y16 and +V4L2_PIX_FMT_SBGGR16 were added. + + + New controls +V4L2_CID_POWER_LINE_FREQUENCY, +V4L2_CID_HUE_AUTO, +V4L2_CID_WHITE_BALANCE_TEMPERATURE, +V4L2_CID_SHARPNESS and +V4L2_CID_BACKLIGHT_COMPENSATION were added. The +controls V4L2_CID_BLACK_LEVEL, +V4L2_CID_WHITENESS, +V4L2_CID_HCENTER and +V4L2_CID_VCENTER were deprecated. + + + + A Camera controls +class was added, with the new controls +V4L2_CID_EXPOSURE_AUTO, +V4L2_CID_EXPOSURE_ABSOLUTE, +V4L2_CID_EXPOSURE_AUTO_PRIORITY, +V4L2_CID_PAN_RELATIVE, +V4L2_CID_TILT_RELATIVE, +V4L2_CID_PAN_RESET, +V4L2_CID_TILT_RESET, +V4L2_CID_PAN_ABSOLUTE, +V4L2_CID_TILT_ABSOLUTE, +V4L2_CID_FOCUS_ABSOLUTE, +V4L2_CID_FOCUS_RELATIVE and +V4L2_CID_FOCUS_AUTO. + + + The VIDIOC_G_MPEGCOMP and +VIDIOC_S_MPEGCOMP ioctls, which were superseded +by the extended controls +interface in Linux 2.6.18, where finally removed from the +videodev2.h header file. + + +
+ +
+ V4L2 in Linux 2.6.26 + + + The pixel formats +V4L2_PIX_FMT_Y16 and +V4L2_PIX_FMT_SBGGR16 were added. + + + Added user controls +V4L2_CID_CHROMA_AGC and +V4L2_CID_COLOR_KILLER. + + +
+ +
+ V4L2 in Linux 2.6.27 + + + The &VIDIOC-S-HW-FREQ-SEEK; ioctl and the +V4L2_CAP_HW_FREQ_SEEK capability were added. + + + The pixel formats +V4L2_PIX_FMT_YVYU, +V4L2_PIX_FMT_PCA501, +V4L2_PIX_FMT_PCA505, +V4L2_PIX_FMT_PCA508, +V4L2_PIX_FMT_PCA561, +V4L2_PIX_FMT_SGBRG8, +V4L2_PIX_FMT_PAC207 and +V4L2_PIX_FMT_PJPG were added. + + +
+ +
+ V4L2 in Linux 2.6.28 + + + Added V4L2_MPEG_AUDIO_ENCODING_AAC and +V4L2_MPEG_AUDIO_ENCODING_AC3 MPEG audio encodings. + + + Added V4L2_MPEG_VIDEO_ENCODING_MPEG_4_AVC MPEG +video encoding. + + + The pixel formats +V4L2_PIX_FMT_SGRBG10 and +V4L2_PIX_FMT_SGRBG10DPCM8 were added. + + +
+ +
+ V4L2 in Linux 2.6.29 + + + The VIDIOC_G_CHIP_IDENT ioctl was renamed +to VIDIOC_G_CHIP_IDENT_OLD and &VIDIOC-DBG-G-CHIP-IDENT; +was introduced in its place. The old struct v4l2_chip_ident +was renamed to v4l2_chip_ident_old. + + + The pixel formats +V4L2_PIX_FMT_VYUY, +V4L2_PIX_FMT_NV16 and +V4L2_PIX_FMT_NV61 were added. + + + Added camera controls +V4L2_CID_ZOOM_ABSOLUTE, +V4L2_CID_ZOOM_RELATIVE, +V4L2_CID_ZOOM_CONTINUOUS and +V4L2_CID_PRIVACY. + + +
+
+ V4L2 in Linux 2.6.30 + + + New control flag V4L2_CTRL_FLAG_WRITE_ONLY was added. + + + New control V4L2_CID_COLORFX was added. + + +
+
+ V4L2 in Linux 2.6.32 + + + In order to be easier to compare a V4L2 API and a kernel +version, now V4L2 API is numbered using the Linux Kernel version numeration. + + + Finalized the RDS capture API. See for +more information. + + + Added new capabilities for modulators and RDS encoders. + + + Add description for libv4l API. + + + Added support for string controls via new type V4L2_CTRL_TYPE_STRING. + + + Added V4L2_CID_BAND_STOP_FILTER documentation. + + + Added FM Modulator (FM TX) Extended Control Class: V4L2_CTRL_CLASS_FM_TX and their Control IDs. + + + Added Remote Controller chapter, describing the default Remote Controller mapping for media devices. + + +
+
+ V4L2 in Linux 2.6.33 + + + Added support for Digital Video timings in order to support HDTV receivers and transmitters. + + +
+
+ V4L2 in Linux 2.6.34 + + + Added +V4L2_CID_IRIS_ABSOLUTE and +V4L2_CID_IRIS_RELATIVE controls to the + Camera controls class. + + + +
+
+ V4L2 in Linux 2.6.37 + + + Remove the vtx (videotext/teletext) API. This API was no longer +used and no hardware exists to verify the API. Nor were any userspace applications found +that used it. It was originally scheduled for removal in 2.6.35. + + + +
+
+ V4L2 in Linux 2.6.39 + + + The old VIDIOC_*_OLD symbols and V4L1 support were removed. + + + Multi-planar API added. Does not affect the compatibility of + current drivers and applications. See + multi-planar API + for details. + + +
+
+ V4L2 in Linux 3.1 + + + VIDIOC_QUERYCAP now returns a per-subsystem version instead of a per-driver one. + Standardize an error code for invalid ioctl. + Added V4L2_CTRL_TYPE_BITMASK. + + +
+
+ V4L2 in Linux 3.2 + + + V4L2_CTRL_FLAG_VOLATILE was added to signal volatile controls to userspace. + + + Add selection API for extended control over cropping + and composing. Does not affect the compatibility of current + drivers and applications. See selection API for + details. + + +
+ +
+ V4L2 in Linux 3.3 + + + Added V4L2_CID_ALPHA_COMPONENT control + to the User controls class. + + + + Added the device_caps field to struct v4l2_capabilities and added the new + V4L2_CAP_DEVICE_CAPS capability. + + +
+ +
+ V4L2 in Linux 3.4 + + + Added JPEG compression control + class. + + + Extended the DV Timings API: + &VIDIOC-ENUM-DV-TIMINGS;, &VIDIOC-QUERY-DV-TIMINGS; and + &VIDIOC-DV-TIMINGS-CAP;. + + +
+ +
+ V4L2 in Linux 3.5 + + + Added integer menus, the new type will be + V4L2_CTRL_TYPE_INTEGER_MENU. + + + Added selection API for V4L2 subdev interface: + &VIDIOC-SUBDEV-G-SELECTION; and + &VIDIOC-SUBDEV-S-SELECTION;. + + + Added V4L2_COLORFX_ANTIQUE, + V4L2_COLORFX_ART_FREEZE, + V4L2_COLORFX_AQUA, + V4L2_COLORFX_SILHOUETTE, + V4L2_COLORFX_SOLARIZATION, + V4L2_COLORFX_VIVID and + V4L2_COLORFX_ARBITRARY_CBCR menu items + to the V4L2_CID_COLORFX control. + + + Added V4L2_CID_COLORFX_CBCR control. + + + Added camera controls V4L2_CID_AUTO_EXPOSURE_BIAS, + V4L2_CID_AUTO_N_PRESET_WHITE_BALANCE, + V4L2_CID_IMAGE_STABILIZATION, + V4L2_CID_ISO_SENSITIVITY, + V4L2_CID_ISO_SENSITIVITY_AUTO, + V4L2_CID_EXPOSURE_METERING, + V4L2_CID_SCENE_MODE, + V4L2_CID_3A_LOCK, + V4L2_CID_AUTO_FOCUS_START, + V4L2_CID_AUTO_FOCUS_STOP, + V4L2_CID_AUTO_FOCUS_STATUS and + V4L2_CID_AUTO_FOCUS_RANGE. + + + +
+ +
+ V4L2 in Linux 3.6 + + + Replaced input in + v4l2_buffer by + reserved2 and removed + V4L2_BUF_FLAG_INPUT. + + + Added V4L2_CAP_VIDEO_M2M and V4L2_CAP_VIDEO_M2M_MPLANE capabilities. + + + Added support for frequency band enumerations: &VIDIOC-ENUM-FREQ-BANDS;. + + +
+ +
+ V4L2 in Linux 3.9 + + + Added timestamp types to + flags field in + v4l2_buffer. See . + + + Added V4L2_EVENT_CTRL_CH_RANGE control event + changes flag. See . + + +
+ +
+ Relation of V4L2 to other Linux multimedia APIs + +
+ X Video Extension + + The X Video Extension (abbreviated XVideo or just Xv) is +an extension of the X Window system, implemented for example by the +XFree86 project. Its scope is similar to V4L2, an API to video capture +and output devices for X clients. Xv allows applications to display +live video in a window, send window contents to a TV output, and +capture or output still images in XPixmaps + This is not implemented in XFree86. + . With their implementation XFree86 makes the +extension available across many operating systems and +architectures. + + Because the driver is embedded into the X server Xv has a +number of advantages over the V4L2 video +overlay interface. The driver can easily determine the overlay +target, &ie; visible graphics memory or off-screen buffers for a +destructive overlay. It can program the RAMDAC for a non-destructive +overlay, scaling or color-keying, or the clipping functions of the +video capture hardware, always in sync with drawing operations or +windows moving or changing their stacking order. + + To combine the advantages of Xv and V4L a special Xv +driver exists in XFree86 and XOrg, just programming any overlay capable +Video4Linux device it finds. To enable it +/etc/X11/XF86Config must contain these lines: + +Section "Module" + Load "v4l" +EndSection + + As of XFree86 4.2 this driver still supports only V4L +ioctls, however it should work just fine with all V4L2 devices through +the V4L2 backward-compatibility layer. Since V4L2 permits multiple +opens it is possible (if supported by the V4L2 driver) to capture +video while an X client requested video overlay. Restrictions of +simultaneous capturing and overlay are discussed in apply. + + Only marginally related to V4L2, XFree86 extended Xv to +support hardware YUV to RGB conversion and scaling for faster video +playback, and added an interface to MPEG-2 decoding hardware. This API +is useful to display images captured with V4L2 devices. +
+ +
+ Digital Video + + V4L2 does not support digital terrestrial, cable or +satellite broadcast. A separate project aiming at digital receivers +exists. You can find its homepage at http://linuxtv.org. The Linux DVB API +has no connection to the V4L2 API except that drivers for hybrid +hardware may support both. +
+ +
+ Audio Interfaces + + [to do - OSS/ALSA] +
+
+ +
+ Experimental API Elements + + The following V4L2 API elements are currently experimental +and may change in the future. + + + + Video Output Overlay (OSD) Interface, . + + + &VIDIOC-DBG-G-REGISTER; and &VIDIOC-DBG-S-REGISTER; +ioctls. + + + &VIDIOC-DBG-G-CHIP-IDENT; ioctl. + + + &VIDIOC-ENUM-DV-TIMINGS;, &VIDIOC-QUERY-DV-TIMINGS; and + &VIDIOC-DV-TIMINGS-CAP; ioctls. + + + Flash API. + + + &VIDIOC-CREATE-BUFS; and &VIDIOC-PREPARE-BUF; ioctls. + + + Selection API. + + + Sub-device selection API: &VIDIOC-SUBDEV-G-SELECTION; + and &VIDIOC-SUBDEV-S-SELECTION; ioctls. + + + Support for frequency band enumeration: &VIDIOC-ENUM-FREQ-BANDS; ioctl. + + + Vendor and device specific media bus pixel formats. + . + + + Importing DMABUF file descriptors as a new IO method described + in . + + + Exporting DMABUF files using &VIDIOC-EXPBUF; ioctl. + + +
+ +
+ Obsolete API Elements + + The following V4L2 API elements were superseded by new +interfaces and should not be implemented in new drivers. + + + + VIDIOC_G_MPEGCOMP and +VIDIOC_S_MPEGCOMP ioctls. Use Extended Controls, +. + + + &VIDIOC-G-DV-PRESET;, &VIDIOC-S-DV-PRESET;, &VIDIOC-ENUM-DV-PRESETS; and + &VIDIOC-QUERY-DV-PRESET; ioctls. Use the DV Timings API (). + + + VIDIOC_SUBDEV_G_CROP and + VIDIOC_SUBDEV_S_CROP ioctls. Use + VIDIOC_SUBDEV_G_SELECTION and + VIDIOC_SUBDEV_S_SELECTION, . + + +
+
diff --git a/Documentation/DocBook/media/v4l/controls.xml b/Documentation/DocBook/media/v4l/controls.xml new file mode 100644 index 00000000..9e8f8549 --- /dev/null +++ b/Documentation/DocBook/media/v4l/controls.xml @@ -0,0 +1,4690 @@ +
+ User Controls + + Devices typically have a number of user-settable controls +such as brightness, saturation and so on, which would be presented to +the user on a graphical user interface. But, different devices +will have different controls available, and furthermore, the range of +possible values, and the default value will vary from device to +device. The control ioctls provide the information and a mechanism to +create a nice user interface for these controls that will work +correctly with any device. + + All controls are accessed using an ID value. V4L2 defines +several IDs for specific purposes. Drivers can also implement their +own custom controls using V4L2_CID_PRIVATE_BASE +and higher values. The pre-defined control IDs have the prefix +V4L2_CID_, and are listed in . The ID is used when querying the attributes of +a control, and when getting or setting the current value. + + Generally applications should present controls to the user +without assumptions about their purpose. Each control comes with a +name string the user is supposed to understand. When the purpose is +non-intuitive the driver writer should provide a user manual, a user +interface plug-in or a driver specific panel application. Predefined +IDs were introduced to change a few controls programmatically, for +example to mute a device during a channel switch. + + Drivers may enumerate different controls after switching +the current video input or output, tuner or modulator, or audio input +or output. Different in the sense of other bounds, another default and +current value, step size or other menu items. A control with a certain +custom ID can also change name and +type. + It will be more convenient for applications if drivers +make use of the V4L2_CTRL_FLAG_DISABLED flag, but +that was never required. + Control values are stored globally, they do not +change when switching except to stay within the reported bounds. They +also do not change ⪚ when the device is opened or closed, when the +tuner radio frequency is changed or generally never without +application request. Since V4L2 specifies no event mechanism, panel +applications intended to cooperate with other panel applications (be +they built into a larger application, as a TV viewer) may need to +regularly poll control values to update their user +interface. + Applications could call an ioctl to request events. +After another process called &VIDIOC-S-CTRL; or another ioctl changing +shared properties the &func-select; function would indicate +readability until any ioctl (querying the properties) is +called. + + + + All controls use machine endianness. + + + + Control IDs + + &cs-def; + + + ID + Type + Description + + + + + V4L2_CID_BASE + + First predefined ID, equal to +V4L2_CID_BRIGHTNESS. + + + V4L2_CID_USER_BASE + + Synonym of V4L2_CID_BASE. + + + V4L2_CID_BRIGHTNESS + integer + Picture brightness, or more precisely, the black +level. + + + V4L2_CID_CONTRAST + integer + Picture contrast or luma gain. + + + V4L2_CID_SATURATION + integer + Picture color saturation or chroma gain. + + + V4L2_CID_HUE + integer + Hue or color balance. + + + V4L2_CID_AUDIO_VOLUME + integer + Overall audio volume. Note some drivers also +provide an OSS or ALSA mixer interface. + + + V4L2_CID_AUDIO_BALANCE + integer + Audio stereo balance. Minimum corresponds to all +the way left, maximum to right. + + + V4L2_CID_AUDIO_BASS + integer + Audio bass adjustment. + + + V4L2_CID_AUDIO_TREBLE + integer + Audio treble adjustment. + + + V4L2_CID_AUDIO_MUTE + boolean + Mute audio, &ie; set the volume to zero, however +without affecting V4L2_CID_AUDIO_VOLUME. Like +ALSA drivers, V4L2 drivers must mute at load time to avoid excessive +noise. Actually the entire device should be reset to a low power +consumption state. + + + V4L2_CID_AUDIO_LOUDNESS + boolean + Loudness mode (bass boost). + + + V4L2_CID_BLACK_LEVEL + integer + Another name for brightness (not a synonym of +V4L2_CID_BRIGHTNESS). This control is deprecated +and should not be used in new drivers and applications. + + + V4L2_CID_AUTO_WHITE_BALANCE + boolean + Automatic white balance (cameras). + + + V4L2_CID_DO_WHITE_BALANCE + button + This is an action control. When set (the value is +ignored), the device will do a white balance and then hold the current +setting. Contrast this with the boolean +V4L2_CID_AUTO_WHITE_BALANCE, which, when +activated, keeps adjusting the white balance. + + + V4L2_CID_RED_BALANCE + integer + Red chroma balance. + + + V4L2_CID_BLUE_BALANCE + integer + Blue chroma balance. + + + V4L2_CID_GAMMA + integer + Gamma adjust. + + + V4L2_CID_WHITENESS + integer + Whiteness for grey-scale devices. This is a synonym +for V4L2_CID_GAMMA. This control is deprecated +and should not be used in new drivers and applications. + + + V4L2_CID_EXPOSURE + integer + Exposure (cameras). [Unit?] + + + V4L2_CID_AUTOGAIN + boolean + Automatic gain/exposure control. + + + V4L2_CID_GAIN + integer + Gain control. + + + V4L2_CID_HFLIP + boolean + Mirror the picture horizontally. + + + V4L2_CID_VFLIP + boolean + Mirror the picture vertically. + + + V4L2_CID_POWER_LINE_FREQUENCY + enum + Enables a power line frequency filter to avoid +flicker. Possible values for enum v4l2_power_line_frequency are: +V4L2_CID_POWER_LINE_FREQUENCY_DISABLED (0), +V4L2_CID_POWER_LINE_FREQUENCY_50HZ (1), +V4L2_CID_POWER_LINE_FREQUENCY_60HZ (2) and +V4L2_CID_POWER_LINE_FREQUENCY_AUTO (3). + + + V4L2_CID_HUE_AUTO + boolean + Enables automatic hue control by the device. The +effect of setting V4L2_CID_HUE while automatic +hue control is enabled is undefined, drivers should ignore such +request. + + + V4L2_CID_WHITE_BALANCE_TEMPERATURE + integer + This control specifies the white balance settings +as a color temperature in Kelvin. A driver should have a minimum of +2800 (incandescent) to 6500 (daylight). For more information about +color temperature see Wikipedia. + + + V4L2_CID_SHARPNESS + integer + Adjusts the sharpness filters in a camera. The +minimum value disables the filters, higher values give a sharper +picture. + + + V4L2_CID_BACKLIGHT_COMPENSATION + integer + Adjusts the backlight compensation in a camera. The +minimum value disables backlight compensation. + + + V4L2_CID_CHROMA_AGC + boolean + Chroma automatic gain control. + + + V4L2_CID_CHROMA_GAIN + integer + Adjusts the Chroma gain control (for use when chroma AGC + is disabled). + + + V4L2_CID_COLOR_KILLER + boolean + Enable the color killer (&ie; force a black & white image in case of a weak video signal). + + + V4L2_CID_COLORFX + enum + Selects a color effect. The following values are defined: + + + + + + + + V4L2_COLORFX_NONE  + Color effect is disabled. + + + V4L2_COLORFX_ANTIQUE  + An aging (old photo) effect. + + + V4L2_COLORFX_ART_FREEZE  + Frost color effect. + + + V4L2_COLORFX_AQUA  + Water color, cool tone. + + + V4L2_COLORFX_BW  + Black and white. + + + V4L2_COLORFX_EMBOSS  + Emboss, the highlights and shadows replace light/dark boundaries + and low contrast areas are set to a gray background. + + + V4L2_COLORFX_GRASS_GREEN  + Grass green. + + + V4L2_COLORFX_NEGATIVE  + Negative. + + + V4L2_COLORFX_SEPIA  + Sepia tone. + + + V4L2_COLORFX_SKETCH  + Sketch. + + + V4L2_COLORFX_SKIN_WHITEN  + Skin whiten. + + + V4L2_COLORFX_SKY_BLUE  + Sky blue. + + + V4L2_COLORFX_SOLARIZATION  + Solarization, the image is partially reversed in tone, + only color values above or below a certain threshold are inverted. + + + + V4L2_COLORFX_SILHOUETTE  + Silhouette (outline). + + + V4L2_COLORFX_VIVID  + Vivid colors. + + + V4L2_COLORFX_SET_CBCR  + The Cb and Cr chroma components are replaced by fixed + coefficients determined by V4L2_CID_COLORFX_CBCR + control. + + + + + + V4L2_CID_COLORFX_CBCR + integer + Determines the Cb and Cr coefficients for V4L2_COLORFX_SET_CBCR + color effect. Bits [7:0] of the supplied 32 bit value are interpreted as + Cr component, bits [15:8] as Cb component and bits [31:16] must be zero. + + + + V4L2_CID_AUTOBRIGHTNESS + boolean + Enable Automatic Brightness. + + + V4L2_CID_ROTATE + integer + Rotates the image by specified angle. Common angles are 90, + 270 and 180. Rotating the image to 90 and 270 will reverse the height + and width of the display window. It is necessary to set the new height and + width of the picture using the &VIDIOC-S-FMT; ioctl according to + the rotation angle selected. + + + V4L2_CID_BG_COLOR + integer + Sets the background color on the current output device. + Background color needs to be specified in the RGB24 format. The + supplied 32 bit value is interpreted as bits 0-7 Red color information, + bits 8-15 Green color information, bits 16-23 Blue color + information and bits 24-31 must be zero. + + + V4L2_CID_ILLUMINATORS_1 + V4L2_CID_ILLUMINATORS_2 + boolean + Switch on or off the illuminator 1 or 2 of the device + (usually a microscope). + + + V4L2_CID_MIN_BUFFERS_FOR_CAPTURE + integer + This is a read-only control that can be read by the application +and used as a hint to determine the number of CAPTURE buffers to pass to REQBUFS. +The value is the minimum number of CAPTURE buffers that is necessary for hardware +to work. + + + V4L2_CID_MIN_BUFFERS_FOR_OUTPUT + integer + This is a read-only control that can be read by the application +and used as a hint to determine the number of OUTPUT buffers to pass to REQBUFS. +The value is the minimum number of OUTPUT buffers that is necessary for hardware +to work. + + + V4L2_CID_ALPHA_COMPONENT + integer + Sets the alpha color component on the capture device or on + the capture buffer queue of a mem-to-mem device. When a mem-to-mem + device produces frame format that includes an alpha component + (e.g. packed RGB image formats) + and the alpha value is not defined by the mem-to-mem input data + this control lets you select the alpha component value of all + pixels. It is applicable to any pixel format that contains an alpha + component. + + + + V4L2_CID_LASTP1 + + End of the predefined control IDs (currently + V4L2_CID_ALPHA_COMPONENT + 1). + + + V4L2_CID_PRIVATE_BASE + + ID of the first custom (driver specific) control. +Applications depending on particular custom controls should check the +driver name and version, see . + + + +
+ + Applications can enumerate the available controls with the +&VIDIOC-QUERYCTRL; and &VIDIOC-QUERYMENU; ioctls, get and set a +control value with the &VIDIOC-G-CTRL; and &VIDIOC-S-CTRL; ioctls. +Drivers must implement VIDIOC_QUERYCTRL, +VIDIOC_G_CTRL and +VIDIOC_S_CTRL when the device has one or more +controls, VIDIOC_QUERYMENU when it has one or +more menu type controls. + + + Enumerating all controls + + +&v4l2-queryctrl; queryctrl; +&v4l2-querymenu; querymenu; + +static void +enumerate_menu (void) +{ + printf (" Menu items:\n"); + + memset (&querymenu, 0, sizeof (querymenu)); + querymenu.id = queryctrl.id; + + for (querymenu.index = queryctrl.minimum; + querymenu.index <= queryctrl.maximum; + querymenu.index++) { + if (0 == ioctl (fd, &VIDIOC-QUERYMENU;, &querymenu)) { + printf (" %s\n", querymenu.name); + } + } +} + +memset (&queryctrl, 0, sizeof (queryctrl)); + +for (queryctrl.id = V4L2_CID_BASE; + queryctrl.id < V4L2_CID_LASTP1; + queryctrl.id++) { + if (0 == ioctl (fd, &VIDIOC-QUERYCTRL;, &queryctrl)) { + if (queryctrl.flags & V4L2_CTRL_FLAG_DISABLED) + continue; + + printf ("Control %s\n", queryctrl.name); + + if (queryctrl.type == V4L2_CTRL_TYPE_MENU) + enumerate_menu (); + } else { + if (errno == EINVAL) + continue; + + perror ("VIDIOC_QUERYCTRL"); + exit (EXIT_FAILURE); + } +} + +for (queryctrl.id = V4L2_CID_PRIVATE_BASE;; + queryctrl.id++) { + if (0 == ioctl (fd, &VIDIOC-QUERYCTRL;, &queryctrl)) { + if (queryctrl.flags & V4L2_CTRL_FLAG_DISABLED) + continue; + + printf ("Control %s\n", queryctrl.name); + + if (queryctrl.type == V4L2_CTRL_TYPE_MENU) + enumerate_menu (); + } else { + if (errno == EINVAL) + break; + + perror ("VIDIOC_QUERYCTRL"); + exit (EXIT_FAILURE); + } +} + + + + + Changing controls + + +&v4l2-queryctrl; queryctrl; +&v4l2-control; control; + +memset (&queryctrl, 0, sizeof (queryctrl)); +queryctrl.id = V4L2_CID_BRIGHTNESS; + +if (-1 == ioctl (fd, &VIDIOC-QUERYCTRL;, &queryctrl)) { + if (errno != EINVAL) { + perror ("VIDIOC_QUERYCTRL"); + exit (EXIT_FAILURE); + } else { + printf ("V4L2_CID_BRIGHTNESS is not supported\n"); + } +} else if (queryctrl.flags & V4L2_CTRL_FLAG_DISABLED) { + printf ("V4L2_CID_BRIGHTNESS is not supported\n"); +} else { + memset (&control, 0, sizeof (control)); + control.id = V4L2_CID_BRIGHTNESS; + control.value = queryctrl.default_value; + + if (-1 == ioctl (fd, &VIDIOC-S-CTRL;, &control)) { + perror ("VIDIOC_S_CTRL"); + exit (EXIT_FAILURE); + } +} + +memset (&control, 0, sizeof (control)); +control.id = V4L2_CID_CONTRAST; + +if (0 == ioctl (fd, &VIDIOC-G-CTRL;, &control)) { + control.value += 1; + + /* The driver may clamp the value or return ERANGE, ignored here */ + + if (-1 == ioctl (fd, &VIDIOC-S-CTRL;, &control) + && errno != ERANGE) { + perror ("VIDIOC_S_CTRL"); + exit (EXIT_FAILURE); + } +/* Ignore if V4L2_CID_CONTRAST is unsupported */ +} else if (errno != EINVAL) { + perror ("VIDIOC_G_CTRL"); + exit (EXIT_FAILURE); +} + +control.id = V4L2_CID_AUDIO_MUTE; +control.value = TRUE; /* silence */ + +/* Errors ignored */ +ioctl (fd, VIDIOC_S_CTRL, &control); + + +
+ +
+ Extended Controls + +
+ Introduction + + The control mechanism as originally designed was meant +to be used for user settings (brightness, saturation, etc). However, +it turned out to be a very useful model for implementing more +complicated driver APIs where each driver implements only a subset of +a larger API. + + The MPEG encoding API was the driving force behind +designing and implementing this extended control mechanism: the MPEG +standard is quite large and the currently supported hardware MPEG +encoders each only implement a subset of this standard. Further more, +many parameters relating to how the video is encoded into an MPEG +stream are specific to the MPEG encoding chip since the MPEG standard +only defines the format of the resulting MPEG stream, not how the +video is actually encoded into that format. + + Unfortunately, the original control API lacked some +features needed for these new uses and so it was extended into the +(not terribly originally named) extended control API. + + Even though the MPEG encoding API was the first effort +to use the Extended Control API, nowadays there are also other classes +of Extended Controls, such as Camera Controls and FM Transmitter Controls. +The Extended Controls API as well as all Extended Controls classes are +described in the following text. +
+ +
+ The Extended Control API + + Three new ioctls are available: &VIDIOC-G-EXT-CTRLS;, +&VIDIOC-S-EXT-CTRLS; and &VIDIOC-TRY-EXT-CTRLS;. These ioctls act on +arrays of controls (as opposed to the &VIDIOC-G-CTRL; and +&VIDIOC-S-CTRL; ioctls that act on a single control). This is needed +since it is often required to atomically change several controls at +once. + + Each of the new ioctls expects a pointer to a +&v4l2-ext-controls;. This structure contains a pointer to the control +array, a count of the number of controls in that array and a control +class. Control classes are used to group similar controls into a +single class. For example, control class +V4L2_CTRL_CLASS_USER contains all user controls +(&ie; all controls that can also be set using the old +VIDIOC_S_CTRL ioctl). Control class +V4L2_CTRL_CLASS_MPEG contains all controls +relating to MPEG encoding, etc. + + All controls in the control array must belong to the +specified control class. An error is returned if this is not the +case. + + It is also possible to use an empty control array (count +== 0) to check whether the specified control class is +supported. + + The control array is a &v4l2-ext-control; array. The +v4l2_ext_control structure is very similar to +&v4l2-control;, except for the fact that it also allows for 64-bit +values and pointers to be passed. + + It is important to realize that due to the flexibility of +controls it is necessary to check whether the control you want to set +actually is supported in the driver and what the valid range of values +is. So use the &VIDIOC-QUERYCTRL; and &VIDIOC-QUERYMENU; ioctls to +check this. Also note that it is possible that some of the menu +indices in a control of type V4L2_CTRL_TYPE_MENU +may not be supported (VIDIOC_QUERYMENU will +return an error). A good example is the list of supported MPEG audio +bitrates. Some drivers only support one or two bitrates, others +support a wider range. + + + All controls use machine endianness. + +
+ +
+ Enumerating Extended Controls + + The recommended way to enumerate over the extended +controls is by using &VIDIOC-QUERYCTRL; in combination with the +V4L2_CTRL_FLAG_NEXT_CTRL flag: + + + +&v4l2-queryctrl; qctrl; + +qctrl.id = V4L2_CTRL_FLAG_NEXT_CTRL; +while (0 == ioctl (fd, &VIDIOC-QUERYCTRL;, &qctrl)) { + /* ... */ + qctrl.id |= V4L2_CTRL_FLAG_NEXT_CTRL; +} + + + + The initial control ID is set to 0 ORed with the +V4L2_CTRL_FLAG_NEXT_CTRL flag. The +VIDIOC_QUERYCTRL ioctl will return the first +control with a higher ID than the specified one. When no such controls +are found an error is returned. + + If you want to get all controls within a specific control +class, then you can set the initial +qctrl.id value to the control class and add +an extra check to break out of the loop when a control of another +control class is found: + + + +qctrl.id = V4L2_CTRL_CLASS_MPEG | V4L2_CTRL_FLAG_NEXT_CTRL; +while (0 == ioctl (fd, &VIDIOC-QUERYCTRL;, &qctrl)) { + if (V4L2_CTRL_ID2CLASS (qctrl.id) != V4L2_CTRL_CLASS_MPEG) + break; + /* ... */ + qctrl.id |= V4L2_CTRL_FLAG_NEXT_CTRL; + } + + + + The 32-bit qctrl.id value is +subdivided into three bit ranges: the top 4 bits are reserved for +flags (⪚ V4L2_CTRL_FLAG_NEXT_CTRL) and are not +actually part of the ID. The remaining 28 bits form the control ID, of +which the most significant 12 bits define the control class and the +least significant 16 bits identify the control within the control +class. It is guaranteed that these last 16 bits are always non-zero +for controls. The range of 0x1000 and up are reserved for +driver-specific controls. The macro +V4L2_CTRL_ID2CLASS(id) returns the control class +ID based on a control ID. + + If the driver does not support extended controls, then +VIDIOC_QUERYCTRL will fail when used in +combination with V4L2_CTRL_FLAG_NEXT_CTRL. In +that case the old method of enumerating control should be used (see +1.8). But if it is supported, then it is guaranteed to enumerate over +all controls, including driver-private controls. +
+ +
+ Creating Control Panels + + It is possible to create control panels for a graphical +user interface where the user can select the various controls. +Basically you will have to iterate over all controls using the method +described above. Each control class starts with a control of type +V4L2_CTRL_TYPE_CTRL_CLASS. +VIDIOC_QUERYCTRL will return the name of this +control class which can be used as the title of a tab page within a +control panel. + + The flags field of &v4l2-queryctrl; also contains hints on +the behavior of the control. See the &VIDIOC-QUERYCTRL; documentation +for more details. +
+ +
+ MPEG Control Reference + + Below all controls within the MPEG control class are +described. First the generic controls, then controls specific for +certain hardware. + +
+ Generic MPEG Controls + + + MPEG Control IDs + + + + + + + + + + ID + Type + Description + + + + + + V4L2_CID_MPEG_CLASS  + class + The MPEG class +descriptor. Calling &VIDIOC-QUERYCTRL; for this control will return a +description of this control class. This description can be used as the +caption of a Tab page in a GUI, for example. + + + + V4L2_CID_MPEG_STREAM_TYPE  + enum v4l2_mpeg_stream_type + The MPEG-1, -2 or -4 +output stream type. One cannot assume anything here. Each hardware +MPEG encoder tends to support different subsets of the available MPEG +stream types. This control is specific to multiplexed MPEG streams. +The currently defined stream types are: + + + + + + V4L2_MPEG_STREAM_TYPE_MPEG2_PS  + MPEG-2 program stream + + + V4L2_MPEG_STREAM_TYPE_MPEG2_TS  + MPEG-2 transport stream + + + V4L2_MPEG_STREAM_TYPE_MPEG1_SS  + MPEG-1 system stream + + + V4L2_MPEG_STREAM_TYPE_MPEG2_DVD  + MPEG-2 DVD-compatible stream + + + V4L2_MPEG_STREAM_TYPE_MPEG1_VCD  + MPEG-1 VCD-compatible stream + + + V4L2_MPEG_STREAM_TYPE_MPEG2_SVCD  + MPEG-2 SVCD-compatible stream + + + + + + + V4L2_CID_MPEG_STREAM_PID_PMT  + integer + Program Map Table +Packet ID for the MPEG transport stream (default 16) + + + + V4L2_CID_MPEG_STREAM_PID_AUDIO  + integer + Audio Packet ID for +the MPEG transport stream (default 256) + + + + V4L2_CID_MPEG_STREAM_PID_VIDEO  + integer + Video Packet ID for +the MPEG transport stream (default 260) + + + + V4L2_CID_MPEG_STREAM_PID_PCR  + integer + Packet ID for the +MPEG transport stream carrying PCR fields (default 259) + + + + V4L2_CID_MPEG_STREAM_PES_ID_AUDIO  + integer + Audio ID for MPEG +PES + + + + V4L2_CID_MPEG_STREAM_PES_ID_VIDEO  + integer + Video ID for MPEG +PES + + + + V4L2_CID_MPEG_STREAM_VBI_FMT  + enum v4l2_mpeg_stream_vbi_fmt + Some cards can embed +VBI data (⪚ Closed Caption, Teletext) into the MPEG stream. This +control selects whether VBI data should be embedded, and if so, what +embedding method should be used. The list of possible VBI formats +depends on the driver. The currently defined VBI format types +are: + + + + + + V4L2_MPEG_STREAM_VBI_FMT_NONE  + No VBI in the MPEG stream + + + V4L2_MPEG_STREAM_VBI_FMT_IVTV  + VBI in private packets, IVTV format (documented +in the kernel sources in the file Documentation/video4linux/cx2341x/README.vbi) + + + + + + + V4L2_CID_MPEG_AUDIO_SAMPLING_FREQ  + enum v4l2_mpeg_audio_sampling_freq + MPEG Audio sampling +frequency. Possible values are: + + + + + + V4L2_MPEG_AUDIO_SAMPLING_FREQ_44100  + 44.1 kHz + + + V4L2_MPEG_AUDIO_SAMPLING_FREQ_48000  + 48 kHz + + + V4L2_MPEG_AUDIO_SAMPLING_FREQ_32000  + 32 kHz + + + + + + + V4L2_CID_MPEG_AUDIO_ENCODING  + enum v4l2_mpeg_audio_encoding + MPEG Audio encoding. +This control is specific to multiplexed MPEG streams. +Possible values are: + + + + + + V4L2_MPEG_AUDIO_ENCODING_LAYER_1  + MPEG-1/2 Layer I encoding + + + V4L2_MPEG_AUDIO_ENCODING_LAYER_2  + MPEG-1/2 Layer II encoding + + + V4L2_MPEG_AUDIO_ENCODING_LAYER_3  + MPEG-1/2 Layer III encoding + + + V4L2_MPEG_AUDIO_ENCODING_AAC  + MPEG-2/4 AAC (Advanced Audio Coding) + + + V4L2_MPEG_AUDIO_ENCODING_AC3  + AC-3 aka ATSC A/52 encoding + + + + + + + V4L2_CID_MPEG_AUDIO_L1_BITRATE  + enum v4l2_mpeg_audio_l1_bitrate + MPEG-1/2 Layer I bitrate. +Possible values are: + + + + + + V4L2_MPEG_AUDIO_L1_BITRATE_32K  + 32 kbit/s + + V4L2_MPEG_AUDIO_L1_BITRATE_64K  + 64 kbit/s + + + V4L2_MPEG_AUDIO_L1_BITRATE_96K  + 96 kbit/s + + + V4L2_MPEG_AUDIO_L1_BITRATE_128K  + 128 kbit/s + + + V4L2_MPEG_AUDIO_L1_BITRATE_160K  + 160 kbit/s + + + V4L2_MPEG_AUDIO_L1_BITRATE_192K  + 192 kbit/s + + + V4L2_MPEG_AUDIO_L1_BITRATE_224K  + 224 kbit/s + + + V4L2_MPEG_AUDIO_L1_BITRATE_256K  + 256 kbit/s + + + V4L2_MPEG_AUDIO_L1_BITRATE_288K  + 288 kbit/s + + + V4L2_MPEG_AUDIO_L1_BITRATE_320K  + 320 kbit/s + + + V4L2_MPEG_AUDIO_L1_BITRATE_352K  + 352 kbit/s + + + V4L2_MPEG_AUDIO_L1_BITRATE_384K  + 384 kbit/s + + + V4L2_MPEG_AUDIO_L1_BITRATE_416K  + 416 kbit/s + + + V4L2_MPEG_AUDIO_L1_BITRATE_448K  + 448 kbit/s + + + + + + + V4L2_CID_MPEG_AUDIO_L2_BITRATE  + enum v4l2_mpeg_audio_l2_bitrate + MPEG-1/2 Layer II bitrate. +Possible values are: + + + + + + V4L2_MPEG_AUDIO_L2_BITRATE_32K  + 32 kbit/s + + + V4L2_MPEG_AUDIO_L2_BITRATE_48K  + 48 kbit/s + + + V4L2_MPEG_AUDIO_L2_BITRATE_56K  + 56 kbit/s + + + V4L2_MPEG_AUDIO_L2_BITRATE_64K  + 64 kbit/s + + + V4L2_MPEG_AUDIO_L2_BITRATE_80K  + 80 kbit/s + + + V4L2_MPEG_AUDIO_L2_BITRATE_96K  + 96 kbit/s + + + V4L2_MPEG_AUDIO_L2_BITRATE_112K  + 112 kbit/s + + + V4L2_MPEG_AUDIO_L2_BITRATE_128K  + 128 kbit/s + + + V4L2_MPEG_AUDIO_L2_BITRATE_160K  + 160 kbit/s + + + V4L2_MPEG_AUDIO_L2_BITRATE_192K  + 192 kbit/s + + + V4L2_MPEG_AUDIO_L2_BITRATE_224K  + 224 kbit/s + + + V4L2_MPEG_AUDIO_L2_BITRATE_256K  + 256 kbit/s + + + V4L2_MPEG_AUDIO_L2_BITRATE_320K  + 320 kbit/s + + + V4L2_MPEG_AUDIO_L2_BITRATE_384K  + 384 kbit/s + + + + + + + V4L2_CID_MPEG_AUDIO_L3_BITRATE  + enum v4l2_mpeg_audio_l3_bitrate + MPEG-1/2 Layer III bitrate. +Possible values are: + + + + + + V4L2_MPEG_AUDIO_L3_BITRATE_32K  + 32 kbit/s + + + V4L2_MPEG_AUDIO_L3_BITRATE_40K  + 40 kbit/s + + + V4L2_MPEG_AUDIO_L3_BITRATE_48K  + 48 kbit/s + + + V4L2_MPEG_AUDIO_L3_BITRATE_56K  + 56 kbit/s + + + V4L2_MPEG_AUDIO_L3_BITRATE_64K  + 64 kbit/s + + + V4L2_MPEG_AUDIO_L3_BITRATE_80K  + 80 kbit/s + + + V4L2_MPEG_AUDIO_L3_BITRATE_96K  + 96 kbit/s + + + V4L2_MPEG_AUDIO_L3_BITRATE_112K  + 112 kbit/s + + + V4L2_MPEG_AUDIO_L3_BITRATE_128K  + 128 kbit/s + + + V4L2_MPEG_AUDIO_L3_BITRATE_160K  + 160 kbit/s + + + V4L2_MPEG_AUDIO_L3_BITRATE_192K  + 192 kbit/s + + + V4L2_MPEG_AUDIO_L3_BITRATE_224K  + 224 kbit/s + + + V4L2_MPEG_AUDIO_L3_BITRATE_256K  + 256 kbit/s + + + V4L2_MPEG_AUDIO_L3_BITRATE_320K  + 320 kbit/s + + + + + + + V4L2_CID_MPEG_AUDIO_AAC_BITRATE  + integer + AAC bitrate in bits per second. + + + + V4L2_CID_MPEG_AUDIO_AC3_BITRATE  + enum v4l2_mpeg_audio_ac3_bitrate + AC-3 bitrate. +Possible values are: + + + + + + V4L2_MPEG_AUDIO_AC3_BITRATE_32K  + 32 kbit/s + + + V4L2_MPEG_AUDIO_AC3_BITRATE_40K  + 40 kbit/s + + + V4L2_MPEG_AUDIO_AC3_BITRATE_48K  + 48 kbit/s + + + V4L2_MPEG_AUDIO_AC3_BITRATE_56K  + 56 kbit/s + + + V4L2_MPEG_AUDIO_AC3_BITRATE_64K  + 64 kbit/s + + + V4L2_MPEG_AUDIO_AC3_BITRATE_80K  + 80 kbit/s + + + V4L2_MPEG_AUDIO_AC3_BITRATE_96K  + 96 kbit/s + + + V4L2_MPEG_AUDIO_AC3_BITRATE_112K  + 112 kbit/s + + + V4L2_MPEG_AUDIO_AC3_BITRATE_128K  + 128 kbit/s + + + V4L2_MPEG_AUDIO_AC3_BITRATE_160K  + 160 kbit/s + + + V4L2_MPEG_AUDIO_AC3_BITRATE_192K  + 192 kbit/s + + + V4L2_MPEG_AUDIO_AC3_BITRATE_224K  + 224 kbit/s + + + V4L2_MPEG_AUDIO_AC3_BITRATE_256K  + 256 kbit/s + + + V4L2_MPEG_AUDIO_AC3_BITRATE_320K  + 320 kbit/s + + + V4L2_MPEG_AUDIO_AC3_BITRATE_384K  + 384 kbit/s + + + V4L2_MPEG_AUDIO_AC3_BITRATE_448K  + 448 kbit/s + + + V4L2_MPEG_AUDIO_AC3_BITRATE_512K  + 512 kbit/s + + + V4L2_MPEG_AUDIO_AC3_BITRATE_576K  + 576 kbit/s + + + V4L2_MPEG_AUDIO_AC3_BITRATE_640K  + 640 kbit/s + + + + + + + V4L2_CID_MPEG_AUDIO_MODE  + enum v4l2_mpeg_audio_mode + MPEG Audio mode. +Possible values are: + + + + + + V4L2_MPEG_AUDIO_MODE_STEREO  + Stereo + + + V4L2_MPEG_AUDIO_MODE_JOINT_STEREO  + Joint Stereo + + + V4L2_MPEG_AUDIO_MODE_DUAL  + Bilingual + + + V4L2_MPEG_AUDIO_MODE_MONO  + Mono + + + + + + + V4L2_CID_MPEG_AUDIO_MODE_EXTENSION  + enum v4l2_mpeg_audio_mode_extension + Joint Stereo +audio mode extension. In Layer I and II they indicate which subbands +are in intensity stereo. All other subbands are coded in stereo. Layer +III is not (yet) supported. Possible values +are: + + + + + + V4L2_MPEG_AUDIO_MODE_EXTENSION_BOUND_4  + Subbands 4-31 in intensity stereo + + + V4L2_MPEG_AUDIO_MODE_EXTENSION_BOUND_8  + Subbands 8-31 in intensity stereo + + + V4L2_MPEG_AUDIO_MODE_EXTENSION_BOUND_12  + Subbands 12-31 in intensity stereo + + + V4L2_MPEG_AUDIO_MODE_EXTENSION_BOUND_16  + Subbands 16-31 in intensity stereo + + + + + + + V4L2_CID_MPEG_AUDIO_EMPHASIS  + enum v4l2_mpeg_audio_emphasis + Audio Emphasis. +Possible values are: + + + + + + V4L2_MPEG_AUDIO_EMPHASIS_NONE  + None + + + V4L2_MPEG_AUDIO_EMPHASIS_50_DIV_15_uS  + 50/15 microsecond emphasis + + + V4L2_MPEG_AUDIO_EMPHASIS_CCITT_J17  + CCITT J.17 + + + + + + + V4L2_CID_MPEG_AUDIO_CRC  + enum v4l2_mpeg_audio_crc + CRC method. Possible +values are: + + + + + + V4L2_MPEG_AUDIO_CRC_NONE  + None + + + V4L2_MPEG_AUDIO_CRC_CRC16  + 16 bit parity check + + + + + + + V4L2_CID_MPEG_AUDIO_MUTE  + boolean + Mutes the audio when +capturing. This is not done by muting audio hardware, which can still +produce a slight hiss, but in the encoder itself, guaranteeing a fixed +and reproducible audio bitstream. 0 = unmuted, 1 = muted. + + + + V4L2_CID_MPEG_AUDIO_DEC_PLAYBACK  + enum v4l2_mpeg_audio_dec_playback + Determines how monolingual audio should be played back. +Possible values are: + + + + + + V4L2_MPEG_AUDIO_DEC_PLAYBACK_AUTO  + Automatically determines the best playback mode. + + + V4L2_MPEG_AUDIO_DEC_PLAYBACK_STEREO  + Stereo playback. + + + V4L2_MPEG_AUDIO_DEC_PLAYBACK_LEFT  + Left channel playback. + + + V4L2_MPEG_AUDIO_DEC_PLAYBACK_RIGHT  + Right channel playback. + + + V4L2_MPEG_AUDIO_DEC_PLAYBACK_MONO  + Mono playback. + + + V4L2_MPEG_AUDIO_DEC_PLAYBACK_SWAPPED_STEREO  + Stereo playback with swapped left and right channels. + + + + + + + V4L2_CID_MPEG_AUDIO_DEC_MULTILINGUAL_PLAYBACK  + enum v4l2_mpeg_audio_dec_playback + Determines how multilingual audio should be played back. + + + + V4L2_CID_MPEG_VIDEO_ENCODING  + enum v4l2_mpeg_video_encoding + MPEG Video encoding +method. This control is specific to multiplexed MPEG streams. +Possible values are: + + + + + + V4L2_MPEG_VIDEO_ENCODING_MPEG_1  + MPEG-1 Video encoding + + + V4L2_MPEG_VIDEO_ENCODING_MPEG_2  + MPEG-2 Video encoding + + + V4L2_MPEG_VIDEO_ENCODING_MPEG_4_AVC  + MPEG-4 AVC (H.264) Video encoding + + + + + + + V4L2_CID_MPEG_VIDEO_ASPECT  + enum v4l2_mpeg_video_aspect + Video aspect. +Possible values are: + + + + + + V4L2_MPEG_VIDEO_ASPECT_1x1  + + + V4L2_MPEG_VIDEO_ASPECT_4x3  + + + V4L2_MPEG_VIDEO_ASPECT_16x9  + + + V4L2_MPEG_VIDEO_ASPECT_221x100  + + + + + + + V4L2_CID_MPEG_VIDEO_B_FRAMES  + integer + Number of B-Frames +(default 2) + + + + V4L2_CID_MPEG_VIDEO_GOP_SIZE  + integer + GOP size (default +12) + + + + V4L2_CID_MPEG_VIDEO_GOP_CLOSURE  + boolean + GOP closure (default +1) + + + + V4L2_CID_MPEG_VIDEO_PULLDOWN  + boolean + Enable 3:2 pulldown +(default 0) + + + + V4L2_CID_MPEG_VIDEO_BITRATE_MODE  + enum v4l2_mpeg_video_bitrate_mode + Video bitrate mode. +Possible values are: + + + + + + V4L2_MPEG_VIDEO_BITRATE_MODE_VBR  + Variable bitrate + + + V4L2_MPEG_VIDEO_BITRATE_MODE_CBR  + Constant bitrate + + + + + + + V4L2_CID_MPEG_VIDEO_BITRATE  + integer + Video bitrate in bits +per second. + + + + V4L2_CID_MPEG_VIDEO_BITRATE_PEAK  + integer + Peak video bitrate in +bits per second. Must be larger or equal to the average video bitrate. +It is ignored if the video bitrate mode is set to constant +bitrate. + + + + V4L2_CID_MPEG_VIDEO_TEMPORAL_DECIMATION  + integer + For every captured +frame, skip this many subsequent frames (default 0). + + + + V4L2_CID_MPEG_VIDEO_MUTE  + boolean + + "Mutes" the video to a +fixed color when capturing. This is useful for testing, to produce a +fixed video bitstream. 0 = unmuted, 1 = muted. + + + + V4L2_CID_MPEG_VIDEO_MUTE_YUV  + integer + Sets the "mute" color +of the video. The supplied 32-bit integer is interpreted as follows (bit +0 = least significant bit): + + + + + + Bit 0:7 + V chrominance information + + + Bit 8:15 + U chrominance information + + + Bit 16:23 + Y luminance information + + + Bit 24:31 + Must be zero. + + + + + + + V4L2_CID_MPEG_VIDEO_DEC_PTS  + integer64 + This read-only control returns the +33-bit video Presentation Time Stamp as defined in ITU T-REC-H.222.0 and ISO/IEC 13818-1 of +the currently displayed frame. This is the same PTS as is used in &VIDIOC-DECODER-CMD;. + + + + V4L2_CID_MPEG_VIDEO_DEC_FRAME  + integer64 + This read-only control returns the +frame counter of the frame that is currently displayed (decoded). This value is reset to 0 whenever +the decoder is started. + + + + + V4L2_CID_MPEG_VIDEO_DECODER_SLICE_INTERFACE  + boolean + + If enabled the decoder expects to receive a single slice per buffer, otherwise +the decoder expects a single frame in per buffer. Applicable to the decoder, all codecs. + + + + + + V4L2_CID_MPEG_VIDEO_H264_VUI_SAR_ENABLE  + boolean + + Enable writing sample aspect ratio in the Video Usability Information. +Applicable to the H264 encoder. + + + + + V4L2_CID_MPEG_VIDEO_H264_VUI_SAR_IDC  + enum v4l2_mpeg_video_h264_vui_sar_idc + + VUI sample aspect ratio indicator for H.264 encoding. The value +is defined in the table E-1 in the standard. Applicable to the H264 encoder. + + + + + + + V4L2_MPEG_VIDEO_H264_VUI_SAR_IDC_UNSPECIFIED  + Unspecified + + + V4L2_MPEG_VIDEO_H264_VUI_SAR_IDC_1x1  + 1x1 + + + V4L2_MPEG_VIDEO_H264_VUI_SAR_IDC_12x11  + 12x11 + + + V4L2_MPEG_VIDEO_H264_VUI_SAR_IDC_10x11  + 10x11 + + + V4L2_MPEG_VIDEO_H264_VUI_SAR_IDC_16x11  + 16x11 + + + V4L2_MPEG_VIDEO_H264_VUI_SAR_IDC_40x33  + 40x33 + + + V4L2_MPEG_VIDEO_H264_VUI_SAR_IDC_24x11  + 24x11 + + + V4L2_MPEG_VIDEO_H264_VUI_SAR_IDC_20x11  + 20x11 + + + V4L2_MPEG_VIDEO_H264_VUI_SAR_IDC_32x11  + 32x11 + + + V4L2_MPEG_VIDEO_H264_VUI_SAR_IDC_80x33  + 80x33 + + + V4L2_MPEG_VIDEO_H264_VUI_SAR_IDC_18x11  + 18x11 + + + V4L2_MPEG_VIDEO_H264_VUI_SAR_IDC_15x11  + 15x11 + + + V4L2_MPEG_VIDEO_H264_VUI_SAR_IDC_64x33  + 64x33 + + + V4L2_MPEG_VIDEO_H264_VUI_SAR_IDC_160x99  + 160x99 + + + V4L2_MPEG_VIDEO_H264_VUI_SAR_IDC_4x3  + 4x3 + + + V4L2_MPEG_VIDEO_H264_VUI_SAR_IDC_3x2  + 3x2 + + + V4L2_MPEG_VIDEO_H264_VUI_SAR_IDC_2x1  + 2x1 + + + V4L2_MPEG_VIDEO_H264_VUI_SAR_IDC_EXTENDED  + Extended SAR + + + + + + + + V4L2_CID_MPEG_VIDEO_H264_VUI_EXT_SAR_WIDTH  + integer + + Extended sample aspect ratio width for H.264 VUI encoding. +Applicable to the H264 encoder. + + + + + V4L2_CID_MPEG_VIDEO_H264_VUI_EXT_SAR_HEIGHT  + integer + + Extended sample aspect ratio height for H.264 VUI encoding. +Applicable to the H264 encoder. + + + + + V4L2_CID_MPEG_VIDEO_H264_LEVEL  + enum v4l2_mpeg_video_h264_level + + The level information for the H264 video elementary stream. +Applicable to the H264 encoder. +Possible values are: + + + + + + V4L2_MPEG_VIDEO_H264_LEVEL_1_0  + Level 1.0 + + + V4L2_MPEG_VIDEO_H264_LEVEL_1B  + Level 1B + + + V4L2_MPEG_VIDEO_H264_LEVEL_1_1  + Level 1.1 + + + V4L2_MPEG_VIDEO_H264_LEVEL_1_2  + Level 1.2 + + + V4L2_MPEG_VIDEO_H264_LEVEL_1_3  + Level 1.3 + + + V4L2_MPEG_VIDEO_H264_LEVEL_2_0  + Level 2.0 + + + V4L2_MPEG_VIDEO_H264_LEVEL_2_1  + Level 2.1 + + + V4L2_MPEG_VIDEO_H264_LEVEL_2_2  + Level 2.2 + + + V4L2_MPEG_VIDEO_H264_LEVEL_3_0  + Level 3.0 + + + V4L2_MPEG_VIDEO_H264_LEVEL_3_1  + Level 3.1 + + + V4L2_MPEG_VIDEO_H264_LEVEL_3_2  + Level 3.2 + + + V4L2_MPEG_VIDEO_H264_LEVEL_4_0  + Level 4.0 + + + V4L2_MPEG_VIDEO_H264_LEVEL_4_1  + Level 4.1 + + + V4L2_MPEG_VIDEO_H264_LEVEL_4_2  + Level 4.2 + + + V4L2_MPEG_VIDEO_H264_LEVEL_5_0  + Level 5.0 + + + V4L2_MPEG_VIDEO_H264_LEVEL_5_1  + Level 5.1 + + + + + + + + V4L2_CID_MPEG_VIDEO_MPEG4_LEVEL  + enum v4l2_mpeg_video_mpeg4_level + + The level information for the MPEG4 elementary stream. +Applicable to the MPEG4 encoder. +Possible values are: + + + + + + V4L2_MPEG_VIDEO_LEVEL_0  + Level 0 + + + V4L2_MPEG_VIDEO_LEVEL_0B  + Level 0b + + + V4L2_MPEG_VIDEO_LEVEL_1  + Level 1 + + + V4L2_MPEG_VIDEO_LEVEL_2  + Level 2 + + + V4L2_MPEG_VIDEO_LEVEL_3  + Level 3 + + + V4L2_MPEG_VIDEO_LEVEL_3B  + Level 3b + + + V4L2_MPEG_VIDEO_LEVEL_4  + Level 4 + + + V4L2_MPEG_VIDEO_LEVEL_5  + Level 5 + + + + + + + + V4L2_CID_MPEG_VIDEO_H264_PROFILE  + enum v4l2_mpeg_video_h264_profile + + The profile information for H264. +Applicable to the H264 encoder. +Possible values are: + + + + + + V4L2_MPEG_VIDEO_H264_PROFILE_BASELINE  + Baseline profile + + + V4L2_MPEG_VIDEO_H264_PROFILE_CONSTRAINED_BASELINE  + Constrained Baseline profile + + + V4L2_MPEG_VIDEO_H264_PROFILE_MAIN  + Main profile + + + V4L2_MPEG_VIDEO_H264_PROFILE_EXTENDED  + Extended profile + + + V4L2_MPEG_VIDEO_H264_PROFILE_HIGH  + High profile + + + V4L2_MPEG_VIDEO_H264_PROFILE_HIGH_10  + High 10 profile + + + V4L2_MPEG_VIDEO_H264_PROFILE_HIGH_422  + High 422 profile + + + V4L2_MPEG_VIDEO_H264_PROFILE_HIGH_444_PREDICTIVE  + High 444 Predictive profile + + + V4L2_MPEG_VIDEO_H264_PROFILE_HIGH_10_INTRA  + High 10 Intra profile + + + V4L2_MPEG_VIDEO_H264_PROFILE_HIGH_422_INTRA  + High 422 Intra profile + + + V4L2_MPEG_VIDEO_H264_PROFILE_HIGH_444_INTRA  + High 444 Intra profile + + + V4L2_MPEG_VIDEO_H264_PROFILE_CAVLC_444_INTRA  + CAVLC 444 Intra profile + + + V4L2_MPEG_VIDEO_H264_PROFILE_SCALABLE_BASELINE  + Scalable Baseline profile + + + V4L2_MPEG_VIDEO_H264_PROFILE_SCALABLE_HIGH  + Scalable High profile + + + V4L2_MPEG_VIDEO_H264_PROFILE_SCALABLE_HIGH_INTRA  + Scalable High Intra profile + + + V4L2_MPEG_VIDEO_H264_PROFILE_STEREO_HIGH  + Stereo High profile + + + V4L2_MPEG_VIDEO_H264_PROFILE_MULTIVIEW_HIGH  + Multiview High profile + + + + + + + + + V4L2_CID_MPEG_VIDEO_MPEG4_PROFILE  + enum v4l2_mpeg_video_mpeg4_profile + + The profile information for MPEG4. +Applicable to the MPEG4 encoder. +Possible values are: + + + + + + V4L2_MPEG_VIDEO_PROFILE_SIMPLE  + Simple profile + + + V4L2_MPEG_VIDEO_PROFILE_ADVANCED_SIMPLE  + Advanced Simple profile + + + V4L2_MPEG_VIDEO_PROFILE_CORE  + Core profile + + + V4L2_MPEG_VIDEO_PROFILE_SIMPLE_SCALABLE  + Simple Scalable profile + + + V4L2_MPEG_VIDEO_PROFILE_ADVANCED_CODING_EFFICIENCY  + + + + + + + + + V4L2_CID_MPEG_VIDEO_MAX_REF_PIC  + integer + + The maximum number of reference pictures used for encoding. +Applicable to the encoder. + + + + + + V4L2_CID_MPEG_VIDEO_MULTI_SLICE_MODE  + enum v4l2_mpeg_video_multi_slice_mode + + Determines how the encoder should handle division of frame into slices. +Applicable to the encoder. +Possible values are: + + + + + + V4L2_MPEG_VIDEO_MULTI_SLICE_MODE_SINGLE  + Single slice per frame. + + + V4L2_MPEG_VIDEO_MULTI_SLICE_MODE_MAX_MB  + Multiple slices with set maximum number of macroblocks per slice. + + + V4L2_MPEG_VIDEO_MULTI_SLICE_MODE_MAX_BYTES  + Multiple slice with set maximum size in bytes per slice. + + + + + + + + V4L2_CID_MPEG_VIDEO_MULTI_SLICE_MAX_MB  + integer + + The maximum number of macroblocks in a slice. Used when +V4L2_CID_MPEG_VIDEO_MULTI_SLICE_MODE is set to V4L2_MPEG_VIDEO_MULTI_SLICE_MODE_MAX_MB. +Applicable to the encoder. + + + + + V4L2_CID_MPEG_VIDEO_MULTI_SLICE_MAX_BYTES  + integer + + The maximum size of a slice in bytes. Used when +V4L2_CID_MPEG_VIDEO_MULTI_SLICE_MODE is set to V4L2_MPEG_VIDEO_MULTI_SLICE_MODE_MAX_BYTES. +Applicable to the encoder. + + + + + V4L2_CID_MPEG_VIDEO_H264_LOOP_FILTER_MODE  + enum v4l2_mpeg_video_h264_loop_filter_mode + + Loop filter mode for H264 encoder. +Possible values are: + + + + + + V4L2_MPEG_VIDEO_H264_LOOP_FILTER_MODE_ENABLED  + Loop filter is enabled. + + + V4L2_MPEG_VIDEO_H264_LOOP_FILTER_MODE_DISABLED  + Loop filter is disabled. + + + V4L2_MPEG_VIDEO_H264_LOOP_FILTER_MODE_DISABLED_AT_SLICE_BOUNDARY  + Loop filter is disabled at the slice boundary. + + + + + + + + V4L2_CID_MPEG_VIDEO_H264_LOOP_FILTER_ALPHA  + integer + + Loop filter alpha coefficient, defined in the H264 standard. +Applicable to the H264 encoder. + + + + + V4L2_CID_MPEG_VIDEO_H264_LOOP_FILTER_BETA  + integer + + Loop filter beta coefficient, defined in the H264 standard. +Applicable to the H264 encoder. + + + + + V4L2_CID_MPEG_VIDEO_H264_ENTROPY_MODE  + enum v4l2_mpeg_video_h264_entropy_mode + + Entropy coding mode for H264 - CABAC/CAVALC. +Applicable to the H264 encoder. +Possible values are: + + + + + + V4L2_MPEG_VIDEO_H264_ENTROPY_MODE_CAVLC  + Use CAVLC entropy coding. + + + V4L2_MPEG_VIDEO_H264_ENTROPY_MODE_CABAC  + Use CABAC entropy coding. + + + + + + + + V4L2_CID_MPEG_VIDEO_H264_8X8_TRANSFORM  + boolean + + Enable 8X8 transform for H264. Applicable to the H264 encoder. + + + + + V4L2_CID_MPEG_VIDEO_CYCLIC_INTRA_REFRESH_MB  + integer + + Cyclic intra macroblock refresh. This is the number of continuous macroblocks +refreshed every frame. Each frame a successive set of macroblocks is refreshed until the cycle completes and starts from the +top of the frame. Applicable to H264, H263 and MPEG4 encoder. + + + + + V4L2_CID_MPEG_VIDEO_FRAME_RC_ENABLE  + boolean + + Frame level rate control enable. +If this control is disabled then the quantization parameter for each frame type is constant and set with appropriate controls +(e.g. V4L2_CID_MPEG_VIDEO_H263_I_FRAME_QP). +If frame rate control is enabled then quantization parameter is adjusted to meet the chosen bitrate. Minimum and maximum value +for the quantization parameter can be set with appropriate controls (e.g. V4L2_CID_MPEG_VIDEO_H263_MIN_QP). +Applicable to encoders. + + + + + V4L2_CID_MPEG_VIDEO_MB_RC_ENABLE  + boolean + + Macroblock level rate control enable. +Applicable to the MPEG4 and H264 encoders. + + + + + V4L2_CID_MPEG_VIDEO_MPEG4_QPEL  + boolean + + Quarter pixel motion estimation for MPEG4. Applicable to the MPEG4 encoder. + + + + + V4L2_CID_MPEG_VIDEO_H263_I_FRAME_QP  + integer + + Quantization parameter for an I frame for H263. Valid range: from 1 to 31. + + + + + V4L2_CID_MPEG_VIDEO_H263_MIN_QP  + integer + + Minimum quantization parameter for H263. Valid range: from 1 to 31. + + + + + V4L2_CID_MPEG_VIDEO_H263_MAX_QP  + integer + + Maximum quantization parameter for H263. Valid range: from 1 to 31. + + + + + V4L2_CID_MPEG_VIDEO_H263_P_FRAME_QP  + integer + + Quantization parameter for an P frame for H263. Valid range: from 1 to 31. + + + + + V4L2_CID_MPEG_VIDEO_H263_B_FRAME_QP  + integer + + Quantization parameter for an B frame for H263. Valid range: from 1 to 31. + + + + + V4L2_CID_MPEG_VIDEO_H264_I_FRAME_QP  + integer + + Quantization parameter for an I frame for H264. Valid range: from 0 to 51. + + + + + V4L2_CID_MPEG_VIDEO_H264_MIN_QP  + integer + + Minimum quantization parameter for H264. Valid range: from 0 to 51. + + + + + V4L2_CID_MPEG_VIDEO_H264_MAX_QP  + integer + + Maximum quantization parameter for H264. Valid range: from 0 to 51. + + + + + V4L2_CID_MPEG_VIDEO_H264_P_FRAME_QP  + integer + + Quantization parameter for an P frame for H264. Valid range: from 0 to 51. + + + + + V4L2_CID_MPEG_VIDEO_H264_B_FRAME_QP  + integer + + Quantization parameter for an B frame for H264. Valid range: from 0 to 51. + + + + + V4L2_CID_MPEG_VIDEO_MPEG4_I_FRAME_QP  + integer + + Quantization parameter for an I frame for MPEG4. Valid range: from 1 to 31. + + + + + V4L2_CID_MPEG_VIDEO_MPEG4_MIN_QP  + integer + + Minimum quantization parameter for MPEG4. Valid range: from 1 to 31. + + + + + V4L2_CID_MPEG_VIDEO_MPEG4_MAX_QP  + integer + + Maximum quantization parameter for MPEG4. Valid range: from 1 to 31. + + + + + V4L2_CID_MPEG_VIDEO_MPEG4_P_FRAME_QP  + integer + + Quantization parameter for an P frame for MPEG4. Valid range: from 1 to 31. + + + + + V4L2_CID_MPEG_VIDEO_MPEG4_B_FRAME_QP  + integer + + Quantization parameter for an B frame for MPEG4. Valid range: from 1 to 31. + + + + + V4L2_CID_MPEG_VIDEO_VBV_SIZE  + integer + + The Video Buffer Verifier size in kilobytes, it is used as a limitation of frame skip. +The VBV is defined in the standard as a mean to verify that the produced stream will be successfully decoded. +The standard describes it as "Part of a hypothetical decoder that is conceptually connected to the +output of the encoder. Its purpose is to provide a constraint on the variability of the data rate that an +encoder or editing process may produce.". +Applicable to the MPEG1, MPEG2, MPEG4 encoders. + + + + + V4L2_CID_MPEG_VIDEO_VBV_DELAY  + integer + Sets the initial delay in milliseconds for +VBV buffer control. + + + + + V4L2_CID_MPEG_VIDEO_H264_CPB_SIZE  + integer + + The Coded Picture Buffer size in kilobytes, it is used as a limitation of frame skip. +The CPB is defined in the H264 standard as a mean to verify that the produced stream will be successfully decoded. +Applicable to the H264 encoder. + + + + + V4L2_CID_MPEG_VIDEO_H264_I_PERIOD  + integer + + Period between I-frames in the open GOP for H264. In case of an open GOP +this is the period between two I-frames. The period between IDR (Instantaneous Decoding Refresh) frames is taken from the GOP_SIZE control. +An IDR frame, which stands for Instantaneous Decoding Refresh is an I-frame after which no prior frames are +referenced. This means that a stream can be restarted from an IDR frame without the need to store or decode any +previous frames. Applicable to the H264 encoder. + + + + + V4L2_CID_MPEG_VIDEO_HEADER_MODE  + enum v4l2_mpeg_video_header_mode + + Determines whether the header is returned as the first buffer or is +it returned together with the first frame. Applicable to encoders. +Possible values are: + + + + + + V4L2_MPEG_VIDEO_HEADER_MODE_SEPARATE  + The stream header is returned separately in the first buffer. + + + V4L2_MPEG_VIDEO_HEADER_MODE_JOINED_WITH_1ST_FRAME  + The stream header is returned together with the first encoded frame. + + + + + + + V4L2_CID_MPEG_VIDEO_DECODER_MPEG4_DEBLOCK_FILTER  + boolean + Enabled the deblocking post processing filter for MPEG4 decoder. +Applicable to the MPEG4 decoder. + + + + V4L2_CID_MPEG_VIDEO_MPEG4_VOP_TIME_RES  + integer + vop_time_increment_resolution value for MPEG4. Applicable to the MPEG4 encoder. + + + + V4L2_CID_MPEG_VIDEO_MPEG4_VOP_TIME_INC  + integer + vop_time_increment value for MPEG4. Applicable to the MPEG4 encoder. + + + + + V4L2_CID_MPEG_VIDEO_H264_SEI_FRAME_PACKING  + boolean + + Enable generation of frame packing supplemental enhancement information in the encoded bitstream. +The frame packing SEI message contains the arrangement of L and R planes for 3D viewing. Applicable to the H264 encoder. + + + + + V4L2_CID_MPEG_VIDEO_H264_SEI_FP_CURRENT_FRAME_0  + boolean + + Sets current frame as frame0 in frame packing SEI. +Applicable to the H264 encoder. + + + + + V4L2_CID_MPEG_VIDEO_H264_SEI_FP_ARRANGEMENT_TYPE  + enum v4l2_mpeg_video_h264_sei_fp_arrangement_type + + Frame packing arrangement type for H264 SEI. +Applicable to the H264 encoder. +Possible values are: + + + + + + V4L2_MPEG_VIDEO_H264_SEI_FP_ARRANGEMENT_TYPE_CHEKERBOARD  + Pixels are alternatively from L and R. + + + V4L2_MPEG_VIDEO_H264_SEI_FP_ARRANGEMENT_TYPE_COLUMN  + L and R are interlaced by column. + + + V4L2_MPEG_VIDEO_H264_SEI_FP_ARRANGEMENT_TYPE_ROW  + L and R are interlaced by row. + + + V4L2_MPEG_VIDEO_H264_SEI_FP_ARRANGEMENT_TYPE_SIDE_BY_SIDE  + L is on the left, R on the right. + + + V4L2_MPEG_VIDEO_H264_SEI_FP_ARRANGEMENT_TYPE_TOP_BOTTOM  + L is on top, R on bottom. + + + V4L2_MPEG_VIDEO_H264_SEI_FP_ARRANGEMENT_TYPE_TEMPORAL  + One view per frame. + + + + + + + + V4L2_CID_MPEG_VIDEO_H264_FMO  + boolean + + Enables flexible macroblock ordering in the encoded bitstream. It is a technique +used for restructuring the ordering of macroblocks in pictures. Applicable to the H264 encoder. + + + + + V4L2_CID_MPEG_VIDEO_H264_FMO_MAP_TYPE  + enum v4l2_mpeg_video_h264_fmo_map_type + + When using FMO, the map type divides the image in different scan patterns of macroblocks. +Applicable to the H264 encoder. +Possible values are: + + + + + + V4L2_MPEG_VIDEO_H264_FMO_MAP_TYPE_INTERLEAVED_SLICES  + Slices are interleaved one after other with macroblocks in run length order. + + + V4L2_MPEG_VIDEO_H264_FMO_MAP_TYPE_SCATTERED_SLICES  + Scatters the macroblocks based on a mathematical function known to both encoder and decoder. + + + V4L2_MPEG_VIDEO_H264_FMO_MAP_TYPE_FOREGROUND_WITH_LEFT_OVER  + Macroblocks arranged in rectangular areas or regions of interest. + + + V4L2_MPEG_VIDEO_H264_FMO_MAP_TYPE_BOX_OUT  + Slice groups grow in a cyclic way from centre to outwards. + + + V4L2_MPEG_VIDEO_H264_FMO_MAP_TYPE_RASTER_SCAN  + Slice groups grow in raster scan pattern from left to right. + + + V4L2_MPEG_VIDEO_H264_FMO_MAP_TYPE_WIPE_SCAN  + Slice groups grow in wipe scan pattern from top to bottom. + + + V4L2_MPEG_VIDEO_H264_FMO_MAP_TYPE_EXPLICIT  + User defined map type. + + + + + + + + V4L2_CID_MPEG_VIDEO_H264_FMO_SLICE_GROUP  + integer + + Number of slice groups in FMO. +Applicable to the H264 encoder. + + + + + V4L2_CID_MPEG_VIDEO_H264_FMO_CHANGE_DIRECTION  + enum v4l2_mpeg_video_h264_fmo_change_dir + + Specifies a direction of the slice group change for raster and wipe maps. +Applicable to the H264 encoder. +Possible values are: + + + + + + V4L2_MPEG_VIDEO_H264_FMO_CHANGE_DIR_RIGHT  + Raster scan or wipe right. + + + V4L2_MPEG_VIDEO_H264_FMO_CHANGE_DIR_LEFT  + Reverse raster scan or wipe left. + + + + + + + + V4L2_CID_MPEG_VIDEO_H264_FMO_CHANGE_RATE  + integer + + Specifies the size of the first slice group for raster and wipe map. +Applicable to the H264 encoder. + + + + + V4L2_CID_MPEG_VIDEO_H264_FMO_RUN_LENGTH  + integer + + Specifies the number of consecutive macroblocks for the interleaved map. +Applicable to the H264 encoder. + + + + + V4L2_CID_MPEG_VIDEO_H264_ASO  + boolean + + Enables arbitrary slice ordering in encoded bitstream. +Applicable to the H264 encoder. + + + + + V4L2_CID_MPEG_VIDEO_H264_ASO_SLICE_ORDER  + integer + Specifies the slice order in ASO. Applicable to the H264 encoder. +The supplied 32-bit integer is interpreted as follows (bit +0 = least significant bit): + + + + + + Bit 0:15 + Slice ID + + + Bit 16:32 + Slice position or order + + + + + + + + V4L2_CID_MPEG_VIDEO_H264_HIERARCHICAL_CODING  + boolean + + Enables H264 hierarchical coding. +Applicable to the H264 encoder. + + + + + V4L2_CID_MPEG_VIDEO_H264_HIERARCHICAL_CODING_TYPE  + enum v4l2_mpeg_video_h264_hierarchical_coding_type + + Specifies the hierarchical coding type. +Applicable to the H264 encoder. +Possible values are: + + + + + + V4L2_MPEG_VIDEO_H264_HIERARCHICAL_CODING_B  + Hierarchical B coding. + + + V4L2_MPEG_VIDEO_H264_HIERARCHICAL_CODING_P  + Hierarchical P coding. + + + + + + + + V4L2_CID_MPEG_VIDEO_H264_HIERARCHICAL_CODING_LAYER  + integer + + Specifies the number of hierarchical coding layers. +Applicable to the H264 encoder. + + + + + V4L2_CID_MPEG_VIDEO_H264_HIERARCHICAL_CODING_LAYER_QP  + integer + Specifies a user defined QP for each layer. Applicable to the H264 encoder. +The supplied 32-bit integer is interpreted as follows (bit +0 = least significant bit): + + + + + + Bit 0:15 + QP value + + + Bit 16:32 + Layer number + + + + + + + +
+
+ +
+ MFC 5.1 MPEG Controls + + The following MPEG class controls deal with MPEG +decoding and encoding settings that are specific to the Multi Format Codec 5.1 device present +in the S5P family of SoCs by Samsung. + + + + MFC 5.1 Control IDs + + + + + + + + + + ID + Type + Description + + + + + + V4L2_CID_MPEG_MFC51_VIDEO_DECODER_H264_DISPLAY_DELAY_ENABLE  + integer + If the display delay is enabled then the decoder has to return a +CAPTURE buffer after processing a certain number of OUTPUT buffers. If this number is low, then it may result in +buffers not being dequeued in display order. In addition hardware may still use those buffers as reference, thus +application should not write to those buffers. This feature can be used for example for generating thumbnails of videos. +Applicable to the H264 decoder. + + + + + V4L2_CID_MPEG_MFC51_VIDEO_DECODER_H264_DISPLAY_DELAY  + integer + Display delay value for H264 decoder. +The decoder is forced to return a decoded frame after the set 'display delay' number of frames. If this number is +low it may result in frames returned out of dispaly order, in addition the hardware may still be using the returned buffer +as a reference picture for subsequent frames. + + + + + V4L2_CID_MPEG_MFC51_VIDEO_H264_NUM_REF_PIC_FOR_P  + integer + The number of reference pictures used for encoding a P picture. +Applicable to the H264 encoder. + + + + V4L2_CID_MPEG_MFC51_VIDEO_PADDING  + boolean + Padding enable in the encoder - use a color instead of repeating border pixels. +Applicable to encoders. + + + + V4L2_CID_MPEG_MFC51_VIDEO_PADDING_YUV  + integer + Padding color in the encoder. Applicable to encoders. The supplied 32-bit integer is interpreted as follows (bit +0 = least significant bit): + + + + + + Bit 0:7 + V chrominance information + + + Bit 8:15 + U chrominance information + + + Bit 16:23 + Y luminance information + + + Bit 24:31 + Must be zero. + + + + + + + V4L2_CID_MPEG_MFC51_VIDEO_RC_REACTION_COEFF  + integer + Reaction coefficient for MFC rate control. Applicable to encoders. +Note 1: Valid only when the frame level RC is enabled. +Note 2: For tight CBR, this field must be small (ex. 2 ~ 10). +For VBR, this field must be large (ex. 100 ~ 1000). +Note 3: It is not recommended to use the greater number than FRAME_RATE * (10^9 / BIT_RATE). + + + + + V4L2_CID_MPEG_MFC51_VIDEO_H264_ADAPTIVE_RC_DARK  + boolean + Adaptive rate control for dark region. +Valid only when H.264 and macroblock level RC is enabled (V4L2_CID_MPEG_VIDEO_MB_RC_ENABLE). +Applicable to the H264 encoder. + + + + V4L2_CID_MPEG_MFC51_VIDEO_H264_ADAPTIVE_RC_SMOOTH  + boolean + Adaptive rate control for smooth region. +Valid only when H.264 and macroblock level RC is enabled (V4L2_CID_MPEG_VIDEO_MB_RC_ENABLE). +Applicable to the H264 encoder. + + + + V4L2_CID_MPEG_MFC51_VIDEO_H264_ADAPTIVE_RC_STATIC  + boolean + Adaptive rate control for static region. +Valid only when H.264 and macroblock level RC is enabled (V4L2_CID_MPEG_VIDEO_MB_RC_ENABLE). +Applicable to the H264 encoder. + + + + V4L2_CID_MPEG_MFC51_VIDEO_H264_ADAPTIVE_RC_ACTIVITY  + boolean + Adaptive rate control for activity region. +Valid only when H.264 and macroblock level RC is enabled (V4L2_CID_MPEG_VIDEO_MB_RC_ENABLE). +Applicable to the H264 encoder. + + + + V4L2_CID_MPEG_MFC51_VIDEO_FRAME_SKIP_MODE  + enum v4l2_mpeg_mfc51_video_frame_skip_mode + + +Indicates in what conditions the encoder should skip frames. If encoding a frame would cause the encoded stream to be larger then +a chosen data limit then the frame will be skipped. +Possible values are: + + + + + + V4L2_MPEG_MFC51_FRAME_SKIP_MODE_DISABLED  + Frame skip mode is disabled. + + + V4L2_MPEG_MFC51_FRAME_SKIP_MODE_LEVEL_LIMIT  + Frame skip mode enabled and buffer limit is set by the chosen level and is defined by the standard. + + + V4L2_MPEG_MFC51_FRAME_SKIP_MODE_BUF_LIMIT  + Frame skip mode enabled and buffer limit is set by the VBV (MPEG1/2/4) or CPB (H264) buffer size control. + + + + + + + V4L2_CID_MPEG_MFC51_VIDEO_RC_FIXED_TARGET_BIT  + integer + Enable rate-control with fixed target bit. +If this setting is enabled, then the rate control logic of the encoder will calculate the average bitrate +for a GOP and keep it below or equal the set bitrate target. Otherwise the rate control logic calculates the +overall average bitrate for the stream and keeps it below or equal to the set bitrate. In the first case +the average bitrate for the whole stream will be smaller then the set bitrate. This is caused because the +average is calculated for smaller number of frames, on the other hand enabling this setting will ensure that +the stream will meet tight bandwidth contraints. Applicable to encoders. + + + + + V4L2_CID_MPEG_MFC51_VIDEO_FORCE_FRAME_TYPE  + enum v4l2_mpeg_mfc51_video_force_frame_type + + Force a frame type for the next queued buffer. Applicable to encoders. +Possible values are: + + + + + + V4L2_MPEG_MFC51_FORCE_FRAME_TYPE_DISABLED  + Forcing a specific frame type disabled. + + + V4L2_MPEG_MFC51_FORCE_FRAME_TYPE_I_FRAME  + Force an I-frame. + + + V4L2_MPEG_MFC51_FORCE_FRAME_TYPE_NOT_CODED  + Force a non-coded frame. + + + + + + +
+
+ +
+ CX2341x MPEG Controls + + The following MPEG class controls deal with MPEG +encoding settings that are specific to the Conexant CX23415 and +CX23416 MPEG encoding chips. + + + CX2341x Control IDs + + + + + + + + + + ID + Type + Description + + + + + + V4L2_CID_MPEG_CX2341X_VIDEO_SPATIAL_FILTER_MODE  + enum v4l2_mpeg_cx2341x_video_spatial_filter_mode + Sets the Spatial +Filter mode (default MANUAL). Possible values +are: + + + + + + V4L2_MPEG_CX2341X_VIDEO_SPATIAL_FILTER_MODE_MANUAL  + Choose the filter manually + + + V4L2_MPEG_CX2341X_VIDEO_SPATIAL_FILTER_MODE_AUTO  + Choose the filter automatically + + + + + + + V4L2_CID_MPEG_CX2341X_VIDEO_SPATIAL_FILTER  + integer (0-15) + The setting for the +Spatial Filter. 0 = off, 15 = maximum. (Default is 0.) + + + + V4L2_CID_MPEG_CX2341X_VIDEO_LUMA_SPATIAL_FILTER_TYPE  + enum v4l2_mpeg_cx2341x_video_luma_spatial_filter_type + Select the algorithm +to use for the Luma Spatial Filter (default +1D_HOR). Possible values: + + + + + + V4L2_MPEG_CX2341X_VIDEO_LUMA_SPATIAL_FILTER_TYPE_OFF  + No filter + + + V4L2_MPEG_CX2341X_VIDEO_LUMA_SPATIAL_FILTER_TYPE_1D_HOR  + One-dimensional horizontal + + + V4L2_MPEG_CX2341X_VIDEO_LUMA_SPATIAL_FILTER_TYPE_1D_VERT  + One-dimensional vertical + + + V4L2_MPEG_CX2341X_VIDEO_LUMA_SPATIAL_FILTER_TYPE_2D_HV_SEPARABLE  + Two-dimensional separable + + + V4L2_MPEG_CX2341X_VIDEO_LUMA_SPATIAL_FILTER_TYPE_2D_SYM_NON_SEPARABLE  + Two-dimensional symmetrical +non-separable + + + + + + + V4L2_CID_MPEG_CX2341X_VIDEO_CHROMA_SPATIAL_FILTER_TYPE  + enum v4l2_mpeg_cx2341x_video_chroma_spatial_filter_type + Select the algorithm +for the Chroma Spatial Filter (default 1D_HOR). +Possible values are: + + + + + + V4L2_MPEG_CX2341X_VIDEO_CHROMA_SPATIAL_FILTER_TYPE_OFF  + No filter + + + V4L2_MPEG_CX2341X_VIDEO_CHROMA_SPATIAL_FILTER_TYPE_1D_HOR  + One-dimensional horizontal + + + + + + + V4L2_CID_MPEG_CX2341X_VIDEO_TEMPORAL_FILTER_MODE  + enum v4l2_mpeg_cx2341x_video_temporal_filter_mode + Sets the Temporal +Filter mode (default MANUAL). Possible values +are: + + + + + + V4L2_MPEG_CX2341X_VIDEO_TEMPORAL_FILTER_MODE_MANUAL  + Choose the filter manually + + + V4L2_MPEG_CX2341X_VIDEO_TEMPORAL_FILTER_MODE_AUTO  + Choose the filter automatically + + + + + + + V4L2_CID_MPEG_CX2341X_VIDEO_TEMPORAL_FILTER  + integer (0-31) + The setting for the +Temporal Filter. 0 = off, 31 = maximum. (Default is 8 for full-scale +capturing and 0 for scaled capturing.) + + + + V4L2_CID_MPEG_CX2341X_VIDEO_MEDIAN_FILTER_TYPE  + enum v4l2_mpeg_cx2341x_video_median_filter_type + Median Filter Type +(default OFF). Possible values are: + + + + + + V4L2_MPEG_CX2341X_VIDEO_MEDIAN_FILTER_TYPE_OFF  + No filter + + + V4L2_MPEG_CX2341X_VIDEO_MEDIAN_FILTER_TYPE_HOR  + Horizontal filter + + + V4L2_MPEG_CX2341X_VIDEO_MEDIAN_FILTER_TYPE_VERT  + Vertical filter + + + V4L2_MPEG_CX2341X_VIDEO_MEDIAN_FILTER_TYPE_HOR_VERT  + Horizontal and vertical filter + + + V4L2_MPEG_CX2341X_VIDEO_MEDIAN_FILTER_TYPE_DIAG  + Diagonal filter + + + + + + + V4L2_CID_MPEG_CX2341X_VIDEO_LUMA_MEDIAN_FILTER_BOTTOM  + integer (0-255) + Threshold above which +the luminance median filter is enabled (default 0) + + + + V4L2_CID_MPEG_CX2341X_VIDEO_LUMA_MEDIAN_FILTER_TOP  + integer (0-255) + Threshold below which +the luminance median filter is enabled (default 255) + + + + V4L2_CID_MPEG_CX2341X_VIDEO_CHROMA_MEDIAN_FILTER_BOTTOM  + integer (0-255) + Threshold above which +the chroma median filter is enabled (default 0) + + + + V4L2_CID_MPEG_CX2341X_VIDEO_CHROMA_MEDIAN_FILTER_TOP  + integer (0-255) + Threshold below which +the chroma median filter is enabled (default 255) + + + + V4L2_CID_MPEG_CX2341X_STREAM_INSERT_NAV_PACKETS  + boolean + + The CX2341X MPEG encoder +can insert one empty MPEG-2 PES packet into the stream between every +four video frames. The packet size is 2048 bytes, including the +packet_start_code_prefix and stream_id fields. The stream_id is 0xBF +(private stream 2). The payload consists of 0x00 bytes, to be filled +in by the application. 0 = do not insert, 1 = insert packets. + + + +
+
+
+ +
+ Camera Control Reference + + The Camera class includes controls for mechanical (or +equivalent digital) features of a device such as controllable lenses +or sensors. + + + Camera Control IDs + + + + + + + + + + ID + Type + Description + + + + + + V4L2_CID_CAMERA_CLASS  + class + The Camera class +descriptor. Calling &VIDIOC-QUERYCTRL; for this control will return a +description of this control class. + + + + + V4L2_CID_EXPOSURE_AUTO  + enum v4l2_exposure_auto_type + Enables automatic +adjustments of the exposure time and/or iris aperture. The effect of +manual changes of the exposure time or iris aperture while these +features are enabled is undefined, drivers should ignore such +requests. Possible values are: + + + + + + V4L2_EXPOSURE_AUTO  + Automatic exposure time, automatic iris +aperture. + + + V4L2_EXPOSURE_MANUAL  + Manual exposure time, manual iris. + + + V4L2_EXPOSURE_SHUTTER_PRIORITY  + Manual exposure time, auto iris. + + + V4L2_EXPOSURE_APERTURE_PRIORITY  + Auto exposure time, manual iris. + + + + + + + + V4L2_CID_EXPOSURE_ABSOLUTE  + integer + Determines the exposure +time of the camera sensor. The exposure time is limited by the frame +interval. Drivers should interpret the values as 100 µs units, +where the value 1 stands for 1/10000th of a second, 10000 for 1 second +and 100000 for 10 seconds. + + + + + V4L2_CID_EXPOSURE_AUTO_PRIORITY  + boolean + When +V4L2_CID_EXPOSURE_AUTO is set to +AUTO or APERTURE_PRIORITY, +this control determines if the device may dynamically vary the frame +rate. By default this feature is disabled (0) and the frame rate must +remain constant. + + + + + V4L2_CID_EXPOSURE_BIAS  + integer menu + Determines the automatic +exposure compensation, it is effective only when V4L2_CID_EXPOSURE_AUTO +control is set to AUTO, SHUTTER_PRIORITY +or APERTURE_PRIORITY. +It is expressed in terms of EV, drivers should interpret the values as 0.001 EV +units, where the value 1000 stands for +1 EV. +Increasing the exposure compensation value is equivalent to decreasing +the exposure value (EV) and will increase the amount of light at the image +sensor. The camera performs the exposure compensation by adjusting absolute +exposure time and/or aperture. + + + + + V4L2_CID_EXPOSURE_METERING  + enum v4l2_exposure_metering + Determines how the camera measures +the amount of light available for the frame exposure. Possible values are: + + + + + + V4L2_EXPOSURE_METERING_AVERAGE  + Use the light information coming from the entire frame +and average giving no weighting to any particular portion of the metered area. + + + + V4L2_EXPOSURE_METERING_CENTER_WEIGHTED  + Average the light information coming from the entire frame +giving priority to the center of the metered area. + + + V4L2_EXPOSURE_METERING_SPOT  + Measure only very small area at the center of the frame. + + + + + + + + V4L2_CID_PAN_RELATIVE  + integer + This control turns the +camera horizontally by the specified amount. The unit is undefined. A +positive value moves the camera to the right (clockwise when viewed +from above), a negative value to the left. A value of zero does not +cause motion. This is a write-only control. + + + + + V4L2_CID_TILT_RELATIVE  + integer + This control turns the +camera vertically by the specified amount. The unit is undefined. A +positive value moves the camera up, a negative value down. A value of +zero does not cause motion. This is a write-only control. + + + + + V4L2_CID_PAN_RESET  + button + When this control is set, +the camera moves horizontally to the default position. + + + + + V4L2_CID_TILT_RESET  + button + When this control is set, +the camera moves vertically to the default position. + + + + + V4L2_CID_PAN_ABSOLUTE  + integer + This control +turns the camera horizontally to the specified position. Positive +values move the camera to the right (clockwise when viewed from above), +negative values to the left. Drivers should interpret the values as arc +seconds, with valid values between -180 * 3600 and +180 * 3600 +inclusive. + + + + + V4L2_CID_TILT_ABSOLUTE  + integer + This control +turns the camera vertically to the specified position. Positive values +move the camera up, negative values down. Drivers should interpret the +values as arc seconds, with valid values between -180 * 3600 and +180 +* 3600 inclusive. + + + + + V4L2_CID_FOCUS_ABSOLUTE  + integer + This control sets the +focal point of the camera to the specified position. The unit is +undefined. Positive values set the focus closer to the camera, +negative values towards infinity. + + + + + V4L2_CID_FOCUS_RELATIVE  + integer + This control moves the +focal point of the camera by the specified amount. The unit is +undefined. Positive values move the focus closer to the camera, +negative values towards infinity. This is a write-only control. + + + + + V4L2_CID_FOCUS_AUTO  + boolean + Enables continuous automatic +focus adjustments. The effect of manual focus adjustments while this feature +is enabled is undefined, drivers should ignore such requests. + + + + + V4L2_CID_AUTO_FOCUS_START  + button + Starts single auto focus process. +The effect of setting this control when V4L2_CID_FOCUS_AUTO +is set to TRUE (1) is undefined, drivers should ignore +such requests. + + + + + V4L2_CID_AUTO_FOCUS_STOP  + button + Aborts automatic focusing +started with V4L2_CID_AUTO_FOCUS_START control. It is +effective only when the continuous autofocus is disabled, that is when +V4L2_CID_FOCUS_AUTO control is set to FALSE + (0). + + + + + + V4L2_CID_AUTO_FOCUS_STATUS  + bitmask + + The automatic focus status. This is a read-only + control. + + + + + + V4L2_AUTO_FOCUS_STATUS_IDLE  + Automatic focus is not active. + + + V4L2_AUTO_FOCUS_STATUS_BUSY  + Automatic focusing is in progress. + + + V4L2_AUTO_FOCUS_STATUS_REACHED  + Focus has been reached. + + + V4L2_AUTO_FOCUS_STATUS_FAILED  + Automatic focus has failed, the driver will not + transition from this state until another action is + performed by an application. + + + + + +Setting V4L2_LOCK_FOCUS lock bit of the V4L2_CID_3A_LOCK + control may stop updates of the V4L2_CID_AUTO_FOCUS_STATUS +control value. + + + + + + V4L2_CID_AUTO_FOCUS_RANGE  + enum v4l2_auto_focus_range + + Determines auto focus distance range +for which lens may be adjusted. + + + + + + V4L2_AUTO_FOCUS_RANGE_AUTO  + The camera automatically selects the focus range. + + + V4L2_AUTO_FOCUS_RANGE_NORMAL  + Normal distance range, limited for best automatic focus +performance. + + + V4L2_AUTO_FOCUS_RANGE_MACRO  + Macro (close-up) auto focus. The camera will +use its minimum possible distance for auto focus. + + + V4L2_AUTO_FOCUS_RANGE_INFINITY  + The lens is set to focus on an object at infinite distance. + + + + + + + + V4L2_CID_ZOOM_ABSOLUTE  + integer + Specify the objective lens +focal length as an absolute value. The zoom unit is driver-specific and its +value should be a positive integer. + + + + + V4L2_CID_ZOOM_RELATIVE  + integer + Specify the objective lens +focal length relatively to the current value. Positive values move the zoom +lens group towards the telephoto direction, negative values towards the +wide-angle direction. The zoom unit is driver-specific. This is a write-only control. + + + + + V4L2_CID_ZOOM_CONTINUOUS  + integer + Move the objective lens group +at the specified speed until it reaches physical device limits or until an +explicit request to stop the movement. A positive value moves the zoom lens +group towards the telephoto direction. A value of zero stops the zoom lens +group movement. A negative value moves the zoom lens group towards the +wide-angle direction. The zoom speed unit is driver-specific. + + + + + V4L2_CID_IRIS_ABSOLUTE  + integer + This control sets the +camera's aperture to the specified value. The unit is undefined. +Larger values open the iris wider, smaller values close it. + + + + + V4L2_CID_IRIS_RELATIVE  + integer + This control modifies the +camera's aperture by the specified amount. The unit is undefined. +Positive values open the iris one step further, negative values close +it one step further. This is a write-only control. + + + + + V4L2_CID_PRIVACY  + boolean + Prevent video from being acquired +by the camera. When this control is set to TRUE (1), no +image can be captured by the camera. Common means to enforce privacy are +mechanical obturation of the sensor and firmware image processing, but the +device is not restricted to these methods. Devices that implement the privacy +control must support read access and may support write access. + + + + V4L2_CID_BAND_STOP_FILTER  + integer + Switch the band-stop filter of a +camera sensor on or off, or specify its strength. Such band-stop filters can +be used, for example, to filter out the fluorescent light component. + + + + + V4L2_CID_AUTO_N_PRESET_WHITE_BALANCE  + enum v4l2_auto_n_preset_white_balance + Sets white balance to automatic, +manual or a preset. The presets determine color temperature of the light as +a hint to the camera for white balance adjustments resulting in most accurate +color representation. The following white balance presets are listed in order +of increasing color temperature. + + + + + + V4L2_WHITE_BALANCE_MANUAL  + Manual white balance. + + + V4L2_WHITE_BALANCE_AUTO  + Automatic white balance adjustments. + + + V4L2_WHITE_BALANCE_INCANDESCENT  + White balance setting for incandescent (tungsten) lighting. +It generally cools down the colors and corresponds approximately to 2500...3500 K +color temperature range. + + + V4L2_WHITE_BALANCE_FLUORESCENT  + White balance preset for fluorescent lighting. +It corresponds approximately to 4000...5000 K color temperature. + + + V4L2_WHITE_BALANCE_FLUORESCENT_H  + With this setting the camera will compensate for +fluorescent H lighting. + + + V4L2_WHITE_BALANCE_HORIZON  + White balance setting for horizon daylight. +It corresponds approximately to 5000 K color temperature. + + + V4L2_WHITE_BALANCE_DAYLIGHT  + White balance preset for daylight (with clear sky). +It corresponds approximately to 5000...6500 K color temperature. + + + V4L2_WHITE_BALANCE_FLASH  + With this setting the camera will compensate for the flash +light. It slightly warms up the colors and corresponds roughly to 5000...5500 K +color temperature. + + + V4L2_WHITE_BALANCE_CLOUDY  + White balance preset for moderately overcast sky. +This option corresponds approximately to 6500...8000 K color temperature +range. + + + V4L2_WHITE_BALANCE_SHADE  + White balance preset for shade or heavily overcast +sky. It corresponds approximately to 9000...10000 K color temperature. + + + + + + + + + V4L2_CID_WIDE_DYNAMIC_RANGE + boolean + + + Enables or disables the camera's wide dynamic +range feature. This feature allows to obtain clear images in situations where +intensity of the illumination varies significantly throughout the scene, i.e. +there are simultaneously very dark and very bright areas. It is most commonly +realized in cameras by combining two subsequent frames with different exposure +times. This control may be changed to a menu +control in the future, if more options are required. + + + + + V4L2_CID_IMAGE_STABILIZATION + boolean + + + Enables or disables image stabilization. + + + + + + V4L2_CID_ISO_SENSITIVITY  + integer menu + Determines ISO equivalent of an +image sensor indicating the sensor's sensitivity to light. The numbers are +expressed in arithmetic scale, as per standard, +where doubling the sensor sensitivity is represented by doubling the numerical +ISO value. Applications should interpret the values as standard ISO values +multiplied by 1000, e.g. control value 800 stands for ISO 0.8. Drivers will +usually support only a subset of standard ISO values. The effect of setting +this control while the V4L2_CID_ISO_SENSITIVITY_AUTO +control is set to a value other than V4L2_CID_ISO_SENSITIVITY_MANUAL + is undefined, drivers should ignore such requests. + + + + + V4L2_CID_ISO_SENSITIVITY_AUTO  + enum v4l2_iso_sensitivity_type + Enables or disables automatic ISO +sensitivity adjustments. + + + + + + V4L2_CID_ISO_SENSITIVITY_MANUAL  + Manual ISO sensitivity. + + + V4L2_CID_ISO_SENSITIVITY_AUTO  + Automatic ISO sensitivity adjustments. + + + + + + + + V4L2_CID_SCENE_MODE  + enum v4l2_scene_mode + This control allows to select +scene programs as the camera automatic modes optimized for common shooting +scenes. Within these modes the camera determines best exposure, aperture, +focusing, light metering, white balance and equivalent sensitivity. The +controls of those parameters are influenced by the scene mode control. +An exact behavior in each mode is subject to the camera specification. + +When the scene mode feature is not used, this control should be set to +V4L2_SCENE_MODE_NONE to make sure the other possibly +related controls are accessible. The following scene programs are defined: + + + + + + + + V4L2_SCENE_MODE_NONE  + The scene mode feature is disabled. + + + V4L2_SCENE_MODE_BACKLIGHT  + Backlight. Compensates for dark shadows when light is + coming from behind a subject, also by automatically turning + on the flash. + + + V4L2_SCENE_MODE_BEACH_SNOW  + Beach and snow. This mode compensates for all-white or +bright scenes, which tend to look gray and low contrast, when camera's automatic +exposure is based on an average scene brightness. To compensate, this mode +automatically slightly overexposes the frames. The white balance may also be +adjusted to compensate for the fact that reflected snow looks bluish rather +than white. + + + V4L2_SCENE_MODE_CANDLELIGHT  + Candle light. The camera generally raises the ISO +sensitivity and lowers the shutter speed. This mode compensates for relatively +close subject in the scene. The flash is disabled in order to preserve the +ambiance of the light. + + + V4L2_SCENE_MODE_DAWN_DUSK  + Dawn and dusk. Preserves the colors seen in low +natural light before dusk and after down. The camera may turn off the flash, +and automatically focus at infinity. It will usually boost saturation and +lower the shutter speed. + + + V4L2_SCENE_MODE_FALL_COLORS  + Fall colors. Increases saturation and adjusts white +balance for color enhancement. Pictures of autumn leaves get saturated reds +and yellows. + + + V4L2_SCENE_MODE_FIREWORKS  + Fireworks. Long exposure times are used to capture +the expanding burst of light from a firework. The camera may invoke image +stabilization. + + + V4L2_SCENE_MODE_LANDSCAPE  + Landscape. The camera may choose a small aperture to +provide deep depth of field and long exposure duration to help capture detail +in dim light conditions. The focus is fixed at infinity. Suitable for distant +and wide scenery. + + + V4L2_SCENE_MODE_NIGHT  + Night, also known as Night Landscape. Designed for low +light conditions, it preserves detail in the dark areas without blowing out bright +objects. The camera generally sets itself to a medium-to-high ISO sensitivity, +with a relatively long exposure time, and turns flash off. As such, there will be +increased image noise and the possibility of blurred image. + + + V4L2_SCENE_MODE_PARTY_INDOOR  + Party and indoor. Designed to capture indoor scenes +that are lit by indoor background lighting as well as the flash. The camera +usually increases ISO sensitivity, and adjusts exposure for the low light +conditions. + + + V4L2_SCENE_MODE_PORTRAIT  + Portrait. The camera adjusts the aperture so that the +depth of field is reduced, which helps to isolate the subject against a smooth +background. Most cameras recognize the presence of faces in the scene and focus +on them. The color hue is adjusted to enhance skin tones. The intensity of the +flash is often reduced. + + + V4L2_SCENE_MODE_SPORTS  + Sports. Significantly increases ISO and uses a fast +shutter speed to freeze motion of rapidly-moving subjects. Increased image +noise may be seen in this mode. + + + V4L2_SCENE_MODE_SUNSET  + Sunset. Preserves deep hues seen in sunsets and +sunrises. It bumps up the saturation. + + + V4L2_SCENE_MODE_TEXT  + Text. It applies extra contrast and sharpness, it is +typically a black-and-white mode optimized for readability. Automatic focus +may be switched to close-up mode and this setting may also involve some +lens-distortion correction. + + + + + + + + V4L2_CID_3A_LOCK + bitmask + + + This control locks or unlocks the automatic +focus, exposure and white balance. The automatic adjustments can be paused +independently by setting the corresponding lock bit to 1. The camera then retains +the settings until the lock bit is cleared. The following lock bits are defined: + + + + + + + V4L2_LOCK_EXPOSURE + Automatic exposure adjustments lock. + + + V4L2_LOCK_WHITE_BALANCE + Automatic white balance adjustments lock. + + + V4L2_LOCK_FOCUS + Automatic focus lock. + + + + + +When a given algorithm is not enabled, drivers should ignore requests +to lock it and should return no error. An example might be an application +setting bit V4L2_LOCK_WHITE_BALANCE when the +V4L2_CID_AUTO_WHITE_BALANCE control is set to +FALSE. The value of this control may be changed +by exposure, white balance or focus controls. + + + + + +
+
+ +
+ FM Transmitter Control Reference + + The FM Transmitter (FM_TX) class includes controls for common features of +FM transmissions capable devices. Currently this class includes parameters for audio +compression, pilot tone generation, audio deviation limiter, RDS transmission and +tuning power features. + + + FM_TX Control IDs + + + + + + + + + + + ID + Type + Description + + + + + + V4L2_CID_FM_TX_CLASS  + class + The FM_TX class +descriptor. Calling &VIDIOC-QUERYCTRL; for this control will return a +description of this control class. + + + V4L2_CID_RDS_TX_DEVIATION  + integer + + Configures RDS signal frequency deviation level in Hz. +The range and step are driver-specific. + + + V4L2_CID_RDS_TX_PI  + integer + + Sets the RDS Programme Identification field +for transmission. + + + V4L2_CID_RDS_TX_PTY  + integer + + Sets the RDS Programme Type field for transmission. +This encodes up to 31 pre-defined programme types. + + + V4L2_CID_RDS_TX_PS_NAME  + string + + Sets the Programme Service name (PS_NAME) for transmission. +It is intended for static display on a receiver. It is the primary aid to listeners in programme service +identification and selection. In Annex E of , the RDS specification, +there is a full description of the correct character encoding for Programme Service name strings. +Also from RDS specification, PS is usually a single eight character text. However, it is also possible +to find receivers which can scroll strings sized as 8 x N characters. So, this control must be configured +with steps of 8 characters. The result is it must always contain a string with size multiple of 8. + + + V4L2_CID_RDS_TX_RADIO_TEXT  + string + + Sets the Radio Text info for transmission. It is a textual description of +what is being broadcasted. RDS Radio Text can be applied when broadcaster wishes to transmit longer PS names, +programme-related information or any other text. In these cases, RadioText should be used in addition to +V4L2_CID_RDS_TX_PS_NAME. The encoding for Radio Text strings is also fully described +in Annex E of . The length of Radio Text strings depends on which RDS Block is being +used to transmit it, either 32 (2A block) or 64 (2B block). However, it is also possible +to find receivers which can scroll strings sized as 32 x N or 64 x N characters. So, this control must be configured +with steps of 32 or 64 characters. The result is it must always contain a string with size multiple of 32 or 64. + + + V4L2_CID_AUDIO_LIMITER_ENABLED  + boolean + + Enables or disables the audio deviation limiter feature. +The limiter is useful when trying to maximize the audio volume, minimize receiver-generated +distortion and prevent overmodulation. + + + + V4L2_CID_AUDIO_LIMITER_RELEASE_TIME  + integer + + Sets the audio deviation limiter feature release time. +Unit is in useconds. Step and range are driver-specific. + + + V4L2_CID_AUDIO_LIMITER_DEVIATION  + integer + + Configures audio frequency deviation level in Hz. +The range and step are driver-specific. + + + V4L2_CID_AUDIO_COMPRESSION_ENABLED  + boolean + + Enables or disables the audio compression feature. +This feature amplifies signals below the threshold by a fixed gain and compresses audio +signals above the threshold by the ratio of Threshold/(Gain + Threshold). + + + V4L2_CID_AUDIO_COMPRESSION_GAIN  + integer + + Sets the gain for audio compression feature. It is +a dB value. The range and step are driver-specific. + + + V4L2_CID_AUDIO_COMPRESSION_THRESHOLD  + integer + + Sets the threshold level for audio compression freature. +It is a dB value. The range and step are driver-specific. + + + V4L2_CID_AUDIO_COMPRESSION_ATTACK_TIME  + integer + + Sets the attack time for audio compression feature. +It is a useconds value. The range and step are driver-specific. + + + V4L2_CID_AUDIO_COMPRESSION_RELEASE_TIME  + integer + + Sets the release time for audio compression feature. +It is a useconds value. The range and step are driver-specific. + + + V4L2_CID_PILOT_TONE_ENABLED  + boolean + + Enables or disables the pilot tone generation feature. + + + V4L2_CID_PILOT_TONE_DEVIATION  + integer + + Configures pilot tone frequency deviation level. Unit is +in Hz. The range and step are driver-specific. + + + V4L2_CID_PILOT_TONE_FREQUENCY  + integer + + Configures pilot tone frequency value. Unit is +in Hz. The range and step are driver-specific. + + + V4L2_CID_TUNE_PREEMPHASIS  + integer + + Configures the pre-emphasis value for broadcasting. +A pre-emphasis filter is applied to the broadcast to accentuate the high audio frequencies. +Depending on the region, a time constant of either 50 or 75 useconds is used. The enum v4l2_preemphasis +defines possible values for pre-emphasis. Here they are: + + + + + V4L2_PREEMPHASIS_DISABLED  + No pre-emphasis is applied. + + + V4L2_PREEMPHASIS_50_uS  + A pre-emphasis of 50 uS is used. + + + V4L2_PREEMPHASIS_75_uS  + A pre-emphasis of 75 uS is used. + + + + + + + V4L2_CID_TUNE_POWER_LEVEL  + integer + + Sets the output power level for signal transmission. +Unit is in dBuV. Range and step are driver-specific. + + + V4L2_CID_TUNE_ANTENNA_CAPACITOR  + integer + + This selects the value of antenna tuning capacitor +manually or automatically if set to zero. Unit, range and step are driver-specific. + + + + +
+ +For more details about RDS specification, refer to + document, from CENELEC. +
+ +
+ Flash Control Reference + + + Experimental + + This is an experimental +interface and may change in the future. + + + + The V4L2 flash controls are intended to provide generic access + to flash controller devices. Flash controller devices are + typically used in digital cameras. + + + + The interface can support both LED and xenon flash devices. As + of writing this, there is no xenon flash driver using this + interface. + + +
+ Supported use cases + +
+ Unsynchronised LED flash (software strobe) + + + Unsynchronised LED flash is controlled directly by the + host as the sensor. The flash must be enabled by the host + before the exposure of the image starts and disabled once + it ends. The host is fully responsible for the timing of + the flash. + + + Example of such device: Nokia N900. +
+ +
+ Synchronised LED flash (hardware strobe) + + + The synchronised LED flash is pre-programmed by the host + (power and timeout) but controlled by the sensor through a + strobe signal from the sensor to the flash. + + + + The sensor controls the flash duration and timing. This + information typically must be made available to the + sensor. + + +
+ +
+ LED flash as torch + + + LED flash may be used as torch in conjunction with another + use case involving camera or individually. + + + + + Flash Control IDs + + + + + + + + + + + ID + Type + Description + + + + + + V4L2_CID_FLASH_CLASS + class + + + The FLASH class descriptor. + + + V4L2_CID_FLASH_LED_MODE + menu + + + Defines the mode of the flash LED, + the high-power white LED attached to the flash controller. + Setting this control may not be possible in presence of + some faults. See V4L2_CID_FLASH_FAULT. + + + + + + V4L2_FLASH_LED_MODE_NONE + Off. + + + V4L2_FLASH_LED_MODE_FLASH + Flash mode. + + + V4L2_FLASH_LED_MODE_TORCH + Torch mode. See V4L2_CID_FLASH_TORCH_INTENSITY. + + + + + + V4L2_CID_FLASH_STROBE_SOURCE + menu + + Defines the source of the flash LED + strobe. + + + + + + V4L2_FLASH_STROBE_SOURCE_SOFTWARE + The flash strobe is triggered by using + the V4L2_CID_FLASH_STROBE control. + + + V4L2_FLASH_STROBE_SOURCE_EXTERNAL + The flash strobe is triggered by an + external source. Typically this is a sensor, + which makes it possible to synchronises the + flash strobe start to exposure start. + + + + + + V4L2_CID_FLASH_STROBE + button + + + Strobe flash. Valid when + V4L2_CID_FLASH_LED_MODE is set to + V4L2_FLASH_LED_MODE_FLASH and V4L2_CID_FLASH_STROBE_SOURCE + is set to V4L2_FLASH_STROBE_SOURCE_SOFTWARE. Setting this + control may not be possible in presence of some faults. + See V4L2_CID_FLASH_FAULT. + + + V4L2_CID_FLASH_STROBE_STOP + button + + Stop flash strobe immediately. + + + V4L2_CID_FLASH_STROBE_STATUS + boolean + + + Strobe status: whether the flash + is strobing at the moment or not. This is a read-only + control. + + + V4L2_CID_FLASH_TIMEOUT + integer + + + Hardware timeout for flash. The + flash strobe is stopped after this period of time has + passed from the start of the strobe. + + + V4L2_CID_FLASH_INTENSITY + integer + + + Intensity of the flash strobe when + the flash LED is in flash mode + (V4L2_FLASH_LED_MODE_FLASH). The unit should be milliamps + (mA) if possible. + + + V4L2_CID_FLASH_TORCH_INTENSITY + integer + + + Intensity of the flash LED in + torch mode (V4L2_FLASH_LED_MODE_TORCH). The unit should be + milliamps (mA) if possible. Setting this control may not + be possible in presence of some faults. See + V4L2_CID_FLASH_FAULT. + + + V4L2_CID_FLASH_INDICATOR_INTENSITY + integer + + + Intensity of the indicator LED. + The indicator LED may be fully independent of the flash + LED. The unit should be microamps (uA) if possible. + + + V4L2_CID_FLASH_FAULT + bitmask + + + Faults related to the flash. The + faults tell about specific problems in the flash chip + itself or the LEDs attached to it. Faults may prevent + further use of some of the flash controls. In particular, + V4L2_CID_FLASH_LED_MODE is set to V4L2_FLASH_LED_MODE_NONE + if the fault affects the flash LED. Exactly which faults + have such an effect is chip dependent. Reading the faults + resets the control and returns the chip to a usable state + if possible. + + + + + + V4L2_FLASH_FAULT_OVER_VOLTAGE + Flash controller voltage to the flash LED + has exceeded the limit specific to the flash + controller. + + + V4L2_FLASH_FAULT_TIMEOUT + The flash strobe was still on when + the timeout set by the user --- + V4L2_CID_FLASH_TIMEOUT control --- has expired. + Not all flash controllers may set this in all + such conditions. + + + V4L2_FLASH_FAULT_OVER_TEMPERATURE + The flash controller has overheated. + + + V4L2_FLASH_FAULT_SHORT_CIRCUIT + The short circuit protection of the flash + controller has been triggered. + + + V4L2_FLASH_FAULT_OVER_CURRENT + Current in the LED power supply has exceeded the limit + specific to the flash controller. + + + V4L2_FLASH_FAULT_INDICATOR + The flash controller has detected a short or open + circuit condition on the indicator LED. + + + + + + V4L2_CID_FLASH_CHARGE + boolean + + Enable or disable charging of the xenon + flash capacitor. + + + V4L2_CID_FLASH_READY + boolean + + + Is the flash ready to strobe? + Xenon flashes require their capacitors charged before + strobing. LED flashes often require a cooldown period + after strobe during which another strobe will not be + possible. This is a read-only control. + + + + +
+
+
+
+ +
+ JPEG Control Reference + The JPEG class includes controls for common features of JPEG + encoders and decoders. Currently it includes features for codecs + implementing progressive baseline DCT compression process with + Huffman entrophy coding. + + JPEG Control IDs + + + + + + + + + + + ID + Type + Description + + + + + + V4L2_CID_JPEG_CLASS  + class + The JPEG class descriptor. Calling + &VIDIOC-QUERYCTRL; for this control will return a description of this + control class. + + + + + V4L2_CID_JPEG_CHROMA_SUBSAMPLING + menu + + + The chroma subsampling factors describe how + each component of an input image is sampled, in respect to maximum + sample rate in each spatial dimension. See , + clause A.1.1. for more details. The + V4L2_CID_JPEG_CHROMA_SUBSAMPLING control determines how + Cb and Cr components are downsampled after coverting an input image + from RGB to Y'CbCr color space. + + + + + + + V4L2_JPEG_CHROMA_SUBSAMPLING_444 + No chroma subsampling, each pixel has + Y, Cr and Cb values. + + + V4L2_JPEG_CHROMA_SUBSAMPLING_422 + Horizontally subsample Cr, Cb components + by a factor of 2. + + + V4L2_JPEG_CHROMA_SUBSAMPLING_420 + Subsample Cr, Cb components horizontally + and vertically by 2. + + + V4L2_JPEG_CHROMA_SUBSAMPLING_411 + Horizontally subsample Cr, Cb components + by a factor of 4. + + + V4L2_JPEG_CHROMA_SUBSAMPLING_410 + Subsample Cr, Cb components horizontally + by 4 and vertically by 2. + + + V4L2_JPEG_CHROMA_SUBSAMPLING_GRAY + Use only luminance component. + + + + + + V4L2_CID_JPEG_RESTART_INTERVAL + integer + + + The restart interval determines an interval of inserting RSTm + markers (m = 0..7). The purpose of these markers is to additionally + reinitialize the encoder process, in order to process blocks of + an image independently. + For the lossy compression processes the restart interval unit is + MCU (Minimum Coded Unit) and its value is contained in DRI + (Define Restart Interval) marker. If + V4L2_CID_JPEG_RESTART_INTERVAL control is set to 0, + DRI and RSTm markers will not be inserted. + + + + V4L2_CID_JPEG_COMPRESSION_QUALITY + integer + + + + V4L2_CID_JPEG_COMPRESSION_QUALITY control + determines trade-off between image quality and size. + It provides simpler method for applications to control image quality, + without a need for direct reconfiguration of luminance and chrominance + quantization tables. + + In cases where a driver uses quantization tables configured directly + by an application, using interfaces defined elsewhere, + V4L2_CID_JPEG_COMPRESSION_QUALITY control should be set + by driver to 0. + + The value range of this control is driver-specific. Only + positive, non-zero values are meaningful. The recommended range + is 1 - 100, where larger values correspond to better image quality. + + + + + V4L2_CID_JPEG_ACTIVE_MARKER + bitmask + + + Specify which JPEG markers are included + in compressed stream. This control is valid only for encoders. + + + + + + + V4L2_JPEG_ACTIVE_MARKER_APP0 + Application data segment APP0. + + V4L2_JPEG_ACTIVE_MARKER_APP1 + Application data segment APP1. + + V4L2_JPEG_ACTIVE_MARKER_COM + Comment segment. + + V4L2_JPEG_ACTIVE_MARKER_DQT + Quantization tables segment. + + V4L2_JPEG_ACTIVE_MARKER_DHT + Huffman tables segment. + + + + + + + +
+ For more details about JPEG specification, refer + to , , + . +
+ +
+ Image Source Control Reference + + + Experimental + + This is an experimental interface and may + change in the future. + + + + The Image Source control class is intended for low-level + control of image source devices such as image sensors. The + devices feature an analogue to digital converter and a bus + transmitter to transmit the image data out of the device. + + + + Image Source Control IDs + + + + + + + + + + + ID + Type + Description + + + + + + V4L2_CID_IMAGE_SOURCE_CLASS + class + + + The IMAGE_SOURCE class descriptor. + + + V4L2_CID_VBLANK + integer + + + Vertical blanking. The idle period + after every frame during which no image data is produced. + The unit of vertical blanking is a line. Every line has + length of the image width plus horizontal blanking at the + pixel rate defined by + V4L2_CID_PIXEL_RATE control in the + same sub-device. + + + V4L2_CID_HBLANK + integer + + + Horizontal blanking. The idle + period after every line of image data during which no + image data is produced. The unit of horizontal blanking is + pixels. + + + V4L2_CID_ANALOGUE_GAIN + integer + + + Analogue gain is gain affecting + all colour components in the pixel matrix. The gain + operation is performed in the analogue domain before A/D + conversion. + + + + + +
+ +
+ +
+ Image Process Control Reference + + + Experimental + + This is an experimental interface and may + change in the future. + + + + The Image Source control class is intended for low-level control of + image processing functions. Unlike + V4L2_CID_IMAGE_SOURCE_CLASS, the controls in + this class affect processing the image, and do not control capturing + of it. + + + + Image Source Control IDs + + + + + + + + + + + ID + Type + Description + + + + + + V4L2_CID_IMAGE_PROC_CLASS + class + + + The IMAGE_PROC class descriptor. + + + V4L2_CID_LINK_FREQ + integer menu + + + Data bus frequency. Together with the + media bus pixel code, bus type (clock cycles per sample), the + data bus frequency defines the pixel rate + (V4L2_CID_PIXEL_RATE) in the + pixel array (or possibly elsewhere, if the device is not an + image sensor). The frame rate can be calculated from the pixel + clock, image width and height and horizontal and vertical + blanking. While the pixel rate control may be defined elsewhere + than in the subdev containing the pixel array, the frame rate + cannot be obtained from that information. This is because only + on the pixel array it can be assumed that the vertical and + horizontal blanking information is exact: no other blanking is + allowed in the pixel array. The selection of frame rate is + performed by selecting the desired horizontal and vertical + blanking. The unit of this control is Hz. + + + V4L2_CID_PIXEL_RATE + 64-bit integer + + + Pixel rate in the source pads of + the subdev. This control is read-only and its unit is + pixels / second. + + + + V4L2_CID_TEST_PATTERN + menu + + + Some capture/display/sensor devices have + the capability to generate test pattern images. These hardware + specific test patterns can be used to test if a device is working + properly. + + + + +
+ +
+ +
+ Digital Video Control Reference + + + Experimental + + This is an experimental interface and may + change in the future. + + + + The Digital Video control class is intended to control receivers + and transmitters for VGA, + DVI + (Digital Visual Interface), HDMI () and DisplayPort (). + These controls are generally expected to be private to the receiver or transmitter + subdevice that implements them, so they are only exposed on the + /dev/v4l-subdev* device node. + + + Note that these devices can have multiple input or output pads which are + hooked up to e.g. HDMI connectors. Even though the subdevice will receive or + transmit video from/to only one of those pads, the other pads can still be + active when it comes to EDID (Extended Display Identification Data, + ) and HDCP (High-bandwidth Digital Content + Protection System, ) processing, allowing the device + to do the fairly slow EDID/HDCP handling in advance. This allows for quick + switching between connectors. + + These pads appear in several of the controls in this section as + bitmasks, one bit for each pad. Bit 0 corresponds to pad 0, bit 1 to pad 1, + etc. The maximum value of the control is the set of valid pads. + + + Digital Video Control IDs + + + + + + + + + + + ID + Type + Description + + + + + + V4L2_CID_DV_CLASS + class + + + The Digital Video class descriptor. + + + V4L2_CID_DV_TX_HOTPLUG + bitmask + + + Many connectors have a hotplug pin which is high + if EDID information is available from the source. This control shows the + state of the hotplug pin as seen by the transmitter. + Each bit corresponds to an output pad on the transmitter. If an output pad + does not have an associated hotplug pin, then the bit for that pad will be 0. + This read-only control is applicable to DVI-D, HDMI and DisplayPort connectors. + + + + V4L2_CID_DV_TX_RXSENSE + bitmask + + + Rx Sense is the detection of pull-ups on the TMDS + clock lines. This normally means that the sink has left/entered standby (i.e. + the transmitter can sense that the receiver is ready to receive video). + Each bit corresponds to an output pad on the transmitter. If an output pad + does not have an associated Rx Sense, then the bit for that pad will be 0. + This read-only control is applicable to DVI-D and HDMI devices. + + + + V4L2_CID_DV_TX_EDID_PRESENT + bitmask + + + When the transmitter sees the hotplug signal from the + receiver it will attempt to read the EDID. If set, then the transmitter has read + at least the first block (= 128 bytes). + Each bit corresponds to an output pad on the transmitter. If an output pad + does not support EDIDs, then the bit for that pad will be 0. + This read-only control is applicable to VGA, DVI-A/D, HDMI and DisplayPort connectors. + + + + V4L2_CID_DV_TX_MODE + enum v4l2_dv_tx_mode + + + HDMI transmitters can transmit in DVI-D mode (just video) + or in HDMI mode (video + audio + auxiliary data). This control selects which mode + to use: V4L2_DV_TX_MODE_DVI_D or V4L2_DV_TX_MODE_HDMI. + This control is applicable to HDMI connectors. + + + + V4L2_CID_DV_TX_RGB_RANGE + enum v4l2_dv_rgb_range + + + Select the quantization range for RGB output. V4L2_DV_RANGE_AUTO + follows the RGB quantization range specified in the standard for the video interface + (ie. for HDMI). V4L2_DV_RANGE_LIMITED and V4L2_DV_RANGE_FULL override the standard + to be compatible with sinks that have not implemented the standard correctly + (unfortunately quite common for HDMI and DVI-D). Full range allows all possible values to be + used whereas limited range sets the range to (16 << (N-8)) - (235 << (N-8)) + where N is the number of bits per component. + This control is applicable to VGA, DVI-A/D, HDMI and DisplayPort connectors. + + + + V4L2_CID_DV_RX_POWER_PRESENT + bitmask + + + Detects whether the receiver receives power from the source + (e.g. HDMI carries 5V on one of the pins). This is often used to power an eeprom + which contains EDID information, such that the source can read the EDID even if + the sink is in standby/power off. + Each bit corresponds to an input pad on the transmitter. If an input pad + cannot detect whether power is present, then the bit for that pad will be 0. + This read-only control is applicable to DVI-D, HDMI and DisplayPort connectors. + + + + V4L2_CID_DV_RX_RGB_RANGE + enum v4l2_dv_rgb_range + + + Select the quantization range for RGB input. V4L2_DV_RANGE_AUTO + follows the RGB quantization range specified in the standard for the video interface + (ie. for HDMI). V4L2_DV_RANGE_LIMITED and V4L2_DV_RANGE_FULL override the standard + to be compatible with sources that have not implemented the standard correctly + (unfortunately quite common for HDMI and DVI-D). Full range allows all possible values to be + used whereas limited range sets the range to (16 << (N-8)) - (235 << (N-8)) + where N is the number of bits per component. + This control is applicable to VGA, DVI-A/D, HDMI and DisplayPort connectors. + + + + + +
+ +
+
diff --git a/Documentation/DocBook/media/v4l/crop.pdf b/Documentation/DocBook/media/v4l/crop.pdf new file mode 100644 index 00000000..c9fb81cd Binary files /dev/null and b/Documentation/DocBook/media/v4l/crop.pdf differ diff --git a/Documentation/DocBook/media/v4l/dev-capture.xml b/Documentation/DocBook/media/v4l/dev-capture.xml new file mode 100644 index 00000000..e1c5f940 --- /dev/null +++ b/Documentation/DocBook/media/v4l/dev-capture.xml @@ -0,0 +1,110 @@ + Video Capture Interface + + Video capture devices sample an analog video signal and store +the digitized images in memory. Today nearly all devices can capture +at full 25 or 30 frames/second. With this interface applications can +control the capture process and move images from the driver into user +space. + + Conventionally V4L2 video capture devices are accessed through +character device special files named /dev/video +and /dev/video0 to +/dev/video63 with major number 81 and minor +numbers 0 to 63. /dev/video is typically a +symbolic link to the preferred video device. Note the same device +files are used for video output devices. + +
+ Querying Capabilities + + Devices supporting the video capture interface set the +V4L2_CAP_VIDEO_CAPTURE or +V4L2_CAP_VIDEO_CAPTURE_MPLANE flag in the +capabilities field of &v4l2-capability; +returned by the &VIDIOC-QUERYCAP; ioctl. As secondary device functions +they may also support the video overlay +(V4L2_CAP_VIDEO_OVERLAY) and the raw VBI capture +(V4L2_CAP_VBI_CAPTURE) interface. At least one of +the read/write or streaming I/O methods must be supported. Tuners and +audio inputs are optional. +
+ +
+ Supplemental Functions + + Video capture devices shall support audio input, tuner, controls, +cropping and scaling and streaming parameter ioctls as needed. +The video input and video standard ioctls must be supported by +all video capture devices. +
+ +
+ Image Format Negotiation + + The result of a capture operation is determined by +cropping and image format parameters. The former select an area of the +video picture to capture, the latter how images are stored in memory, +&ie; in RGB or YUV format, the number of bits per pixel or width and +height. Together they also define how images are scaled in the +process. + + As usual these parameters are not reset +at &func-open; time to permit Unix tool chains, programming a device +and then reading from it as if it was a plain file. Well written V4L2 +applications ensure they really get what they want, including cropping +and scaling. + + Cropping initialization at minimum requires to reset the +parameters to defaults. An example is given in . + + To query the current image format applications set the +type field of a &v4l2-format; to +V4L2_BUF_TYPE_VIDEO_CAPTURE or +V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE and call the +&VIDIOC-G-FMT; ioctl with a pointer to this structure. Drivers fill +the &v4l2-pix-format; pix or the +&v4l2-pix-format-mplane; pix_mp member of the +fmt union. + + To request different parameters applications set the +type field of a &v4l2-format; as above and +initialize all fields of the &v4l2-pix-format; +vbi member of the +fmt union, or better just modify the +results of VIDIOC_G_FMT, and call the +&VIDIOC-S-FMT; ioctl with a pointer to this structure. Drivers may +adjust the parameters and finally return the actual parameters as +VIDIOC_G_FMT does. + + Like VIDIOC_S_FMT the +&VIDIOC-TRY-FMT; ioctl can be used to learn about hardware limitations +without disabling I/O or possibly time consuming hardware +preparations. + + The contents of &v4l2-pix-format; and &v4l2-pix-format-mplane; +are discussed in . See also the specification of the +VIDIOC_G_FMT, VIDIOC_S_FMT +and VIDIOC_TRY_FMT ioctls for details. Video +capture devices must implement both the +VIDIOC_G_FMT and +VIDIOC_S_FMT ioctl, even if +VIDIOC_S_FMT ignores all requests and always +returns default parameters as VIDIOC_G_FMT does. +VIDIOC_TRY_FMT is optional. +
+ +
+ Reading Images + + A video capture device may support the read() function and/or streaming (memory mapping or user pointer) I/O. See for details. +
diff --git a/Documentation/DocBook/media/v4l/dev-codec.xml b/Documentation/DocBook/media/v4l/dev-codec.xml new file mode 100644 index 00000000..dca0ecd5 --- /dev/null +++ b/Documentation/DocBook/media/v4l/dev-codec.xml @@ -0,0 +1,18 @@ + Codec Interface + + + Suspended + + This interface has been be suspended from the V4L2 API +implemented in Linux 2.6 until we have more experience with codec +device interfaces. + + + A V4L2 codec can compress, decompress, transform, or otherwise +convert video data from one format into another format, in memory. +Applications send data to be converted to the driver through a +&func-write; call, and receive the converted data through a +&func-read; call. For efficiency a driver may also support streaming +I/O. + + [to do] diff --git a/Documentation/DocBook/media/v4l/dev-effect.xml b/Documentation/DocBook/media/v4l/dev-effect.xml new file mode 100644 index 00000000..2350a67c --- /dev/null +++ b/Documentation/DocBook/media/v4l/dev-effect.xml @@ -0,0 +1,17 @@ + Effect Devices Interface + + + Suspended + + This interface has been be suspended from the V4L2 API +implemented in Linux 2.6 until we have more experience with effect +device interfaces. + + + A V4L2 video effect device can do image effects, filtering, or +combine two or more images or image streams. For example video +transitions or wipes. Applications send data to be processed and +receive the result data either with &func-read; and &func-write; +functions, or through the streaming I/O mechanism. + + [to do] diff --git a/Documentation/DocBook/media/v4l/dev-event.xml b/Documentation/DocBook/media/v4l/dev-event.xml new file mode 100644 index 00000000..19f4becf --- /dev/null +++ b/Documentation/DocBook/media/v4l/dev-event.xml @@ -0,0 +1,43 @@ + Event Interface + + The V4L2 event interface provides a means for a user to get + immediately notified on certain conditions taking place on a device. + This might include start of frame or loss of signal events, for + example. Changes in the value or state of a V4L2 control can also be + reported through events. + + + To receive events, the events the user is interested in first must + be subscribed using the &VIDIOC-SUBSCRIBE-EVENT; ioctl. Once an event is + subscribed, the events of subscribed types are dequeueable using the + &VIDIOC-DQEVENT; ioctl. Events may be unsubscribed using + VIDIOC_UNSUBSCRIBE_EVENT ioctl. The special event type V4L2_EVENT_ALL may + be used to unsubscribe all the events the driver supports. + + The event subscriptions and event queues are specific to file + handles. Subscribing an event on one file handle does not affect + other file handles. + + The information on dequeueable events is obtained by using select or + poll system calls on video devices. The V4L2 events use POLLPRI events on + poll system call and exceptions on select system call. + + Starting with kernel 3.1 certain guarantees can be given with + regards to events: + + Each subscribed event has its own internal dedicated event queue. +This means that flooding of one event type will not interfere with other +event types. + + + If the internal event queue for a particular subscribed event +becomes full, then the oldest event in that queue will be dropped. + + + Where applicable, certain event types can ensure that the payload +of the oldest event that is about to be dropped will be merged with the payload +of the next oldest event. Thus ensuring that no information is lost, but only an +intermediate step leading up to that information. See the documentation for the +event you want to subscribe to whether this is applicable for that event or not. + + diff --git a/Documentation/DocBook/media/v4l/dev-osd.xml b/Documentation/DocBook/media/v4l/dev-osd.xml new file mode 100644 index 00000000..dd91d613 --- /dev/null +++ b/Documentation/DocBook/media/v4l/dev-osd.xml @@ -0,0 +1,149 @@ + Video Output Overlay Interface + Also known as On-Screen Display (OSD) + + Some video output devices can overlay a framebuffer image onto +the outgoing video signal. Applications can set up such an overlay +using this interface, which borrows structures and ioctls of the Video Overlay interface. + + The OSD function is accessible through the same character +special file as the Video Output function. +Note the default function of such a /dev/video device +is video capturing or output. The OSD function is only available after +calling the &VIDIOC-S-FMT; ioctl. + +
+ Querying Capabilities + + Devices supporting the Video Output +Overlay interface set the +V4L2_CAP_VIDEO_OUTPUT_OVERLAY flag in the +capabilities field of &v4l2-capability; +returned by the &VIDIOC-QUERYCAP; ioctl. +
+ +
+ Framebuffer + + Contrary to the Video Overlay +interface the framebuffer is normally implemented on the TV card and +not the graphics card. On Linux it is accessible as a framebuffer +device (/dev/fbN). Given a V4L2 device, +applications can find the corresponding framebuffer device by calling +the &VIDIOC-G-FBUF; ioctl. It returns, amongst other information, the +physical address of the framebuffer in the +base field of &v4l2-framebuffer;. The +framebuffer device ioctl FBIOGET_FSCREENINFO +returns the same address in the smem_start +field of struct fb_fix_screeninfo. The +FBIOGET_FSCREENINFO ioctl and struct +fb_fix_screeninfo are defined in the +linux/fb.h header file. + + The width and height of the framebuffer depends on the +current video standard. A V4L2 driver may reject attempts to change +the video standard (or any other ioctl which would imply a framebuffer +size change) with an &EBUSY; until all applications closed the +framebuffer device. + + + Finding a framebuffer device for OSD + + +#include <linux/fb.h> + +&v4l2-framebuffer; fbuf; +unsigned int i; +int fb_fd; + +if (-1 == ioctl (fd, VIDIOC_G_FBUF, &fbuf)) { + perror ("VIDIOC_G_FBUF"); + exit (EXIT_FAILURE); +} + +for (i = 0; i > 30; ++i) { + char dev_name[16]; + struct fb_fix_screeninfo si; + + snprintf (dev_name, sizeof (dev_name), "/dev/fb%u", i); + + fb_fd = open (dev_name, O_RDWR); + if (-1 == fb_fd) { + switch (errno) { + case ENOENT: /* no such file */ + case ENXIO: /* no driver */ + continue; + + default: + perror ("open"); + exit (EXIT_FAILURE); + } + } + + if (0 == ioctl (fb_fd, FBIOGET_FSCREENINFO, &si)) { + if (si.smem_start == (unsigned long) fbuf.base) + break; + } else { + /* Apparently not a framebuffer device. */ + } + + close (fb_fd); + fb_fd = -1; +} + +/* fb_fd is the file descriptor of the framebuffer device + for the video output overlay, or -1 if no device was found. */ + + +
+ +
+ Overlay Window and Scaling + + The overlay is controlled by source and target rectangles. +The source rectangle selects a subsection of the framebuffer image to +be overlaid, the target rectangle an area in the outgoing video signal +where the image will appear. Drivers may or may not support scaling, +and arbitrary sizes and positions of these rectangles. Further drivers +may support any (or none) of the clipping/blending methods defined for +the Video Overlay interface. + + A &v4l2-window; defines the size of the source rectangle, +its position in the framebuffer and the clipping/blending method to be +used for the overlay. To get the current parameters applications set +the type field of a &v4l2-format; to +V4L2_BUF_TYPE_VIDEO_OUTPUT_OVERLAY and call the +&VIDIOC-G-FMT; ioctl. The driver fills the +v4l2_window substructure named +win. It is not possible to retrieve a +previously programmed clipping list or bitmap. + + To program the source rectangle applications set the +type field of a &v4l2-format; to +V4L2_BUF_TYPE_VIDEO_OUTPUT_OVERLAY, initialize +the win substructure and call the +&VIDIOC-S-FMT; ioctl. The driver adjusts the parameters against +hardware limits and returns the actual parameters as +VIDIOC_G_FMT does. Like +VIDIOC_S_FMT, the &VIDIOC-TRY-FMT; ioctl can be +used to learn about driver capabilities without actually changing +driver state. Unlike VIDIOC_S_FMT this also works +after the overlay has been enabled. + + A &v4l2-crop; defines the size and position of the target +rectangle. The scaling factor of the overlay is implied by the width +and height given in &v4l2-window; and &v4l2-crop;. The cropping API +applies to Video Output and Video +Output Overlay devices in the same way as to +Video Capture and Video +Overlay devices, merely reversing the direction of the +data flow. For more information see . +
+ +
+ Enabling Overlay + + There is no V4L2 ioctl to enable or disable the overlay, +however the framebuffer interface of the driver may support the +FBIOBLANK ioctl. +
diff --git a/Documentation/DocBook/media/v4l/dev-output.xml b/Documentation/DocBook/media/v4l/dev-output.xml new file mode 100644 index 00000000..9130a3dc --- /dev/null +++ b/Documentation/DocBook/media/v4l/dev-output.xml @@ -0,0 +1,106 @@ + Video Output Interface + + Video output devices encode stills or image sequences as +analog video signal. With this interface applications can +control the encoding process and move images from user space to +the driver. + + Conventionally V4L2 video output devices are accessed through +character device special files named /dev/video +and /dev/video0 to +/dev/video63 with major number 81 and minor +numbers 0 to 63. /dev/video is typically a +symbolic link to the preferred video device. Note the same device +files are used for video capture devices. + +
+ Querying Capabilities + + Devices supporting the video output interface set the +V4L2_CAP_VIDEO_OUTPUT or +V4L2_CAP_VIDEO_OUTPUT_MPLANE flag in the +capabilities field of &v4l2-capability; +returned by the &VIDIOC-QUERYCAP; ioctl. As secondary device functions +they may also support the raw VBI +output (V4L2_CAP_VBI_OUTPUT) interface. At +least one of the read/write or streaming I/O methods must be +supported. Modulators and audio outputs are optional. +
+ +
+ Supplemental Functions + + Video output devices shall support audio output, modulator, controls, +cropping and scaling and streaming parameter ioctls as needed. +The video output and video standard ioctls must be supported by +all video output devices. +
+ +
+ Image Format Negotiation + + The output is determined by cropping and image format +parameters. The former select an area of the video picture where the +image will appear, the latter how images are stored in memory, &ie; in +RGB or YUV format, the number of bits per pixel or width and height. +Together they also define how images are scaled in the process. + + As usual these parameters are not reset +at &func-open; time to permit Unix tool chains, programming a device +and then writing to it as if it was a plain file. Well written V4L2 +applications ensure they really get what they want, including cropping +and scaling. + + Cropping initialization at minimum requires to reset the +parameters to defaults. An example is given in . + + To query the current image format applications set the +type field of a &v4l2-format; to +V4L2_BUF_TYPE_VIDEO_OUTPUT or +V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE and call the +&VIDIOC-G-FMT; ioctl with a pointer to this structure. Drivers fill +the &v4l2-pix-format; pix or the +&v4l2-pix-format-mplane; pix_mp member of the +fmt union. + + To request different parameters applications set the +type field of a &v4l2-format; as above and +initialize all fields of the &v4l2-pix-format; +vbi member of the +fmt union, or better just modify the +results of VIDIOC_G_FMT, and call the +&VIDIOC-S-FMT; ioctl with a pointer to this structure. Drivers may +adjust the parameters and finally return the actual parameters as +VIDIOC_G_FMT does. + + Like VIDIOC_S_FMT the +&VIDIOC-TRY-FMT; ioctl can be used to learn about hardware limitations +without disabling I/O or possibly time consuming hardware +preparations. + + The contents of &v4l2-pix-format; and &v4l2-pix-format-mplane; +are discussed in . See also the specification of the +VIDIOC_G_FMT, VIDIOC_S_FMT +and VIDIOC_TRY_FMT ioctls for details. Video +output devices must implement both the +VIDIOC_G_FMT and +VIDIOC_S_FMT ioctl, even if +VIDIOC_S_FMT ignores all requests and always +returns default parameters as VIDIOC_G_FMT does. +VIDIOC_TRY_FMT is optional. +
+ +
+ Writing Images + + A video output device may support the write() function and/or streaming (memory mapping or user pointer) I/O. See for details. +
diff --git a/Documentation/DocBook/media/v4l/dev-overlay.xml b/Documentation/DocBook/media/v4l/dev-overlay.xml new file mode 100644 index 00000000..40d1d768 --- /dev/null +++ b/Documentation/DocBook/media/v4l/dev-overlay.xml @@ -0,0 +1,371 @@ + Video Overlay Interface + Also known as Framebuffer Overlay or Previewing + + Video overlay devices have the ability to genlock (TV-)video +into the (VGA-)video signal of a graphics card, or to store captured +images directly in video memory of a graphics card, typically with +clipping. This can be considerable more efficient than capturing +images and displaying them by other means. In the old days when only +nuclear power plants needed cooling towers this used to be the only +way to put live video into a window. + + Video overlay devices are accessed through the same character +special files as video capture devices. +Note the default function of a /dev/video device +is video capturing. The overlay function is only available after +calling the &VIDIOC-S-FMT; ioctl. + + The driver may support simultaneous overlay and capturing +using the read/write and streaming I/O methods. If so, operation at +the nominal frame rate of the video standard is not guaranteed. Frames +may be directed away from overlay to capture, or one field may be used +for overlay and the other for capture if the capture parameters permit +this. + + Applications should use different file descriptors for +capturing and overlay. This must be supported by all drivers capable +of simultaneous capturing and overlay. Optionally these drivers may +also permit capturing and overlay with a single file descriptor for +compatibility with V4L and earlier versions of V4L2. + A common application of two file descriptors is the +XFree86 Xv/V4L interface driver and +a V4L2 application. While the X server controls video overlay, the +application can take advantage of memory mapping and DMA. + In the opinion of the designers of this API, no driver +writer taking the efforts to support simultaneous capturing and +overlay will restrict this ability by requiring a single file +descriptor, as in V4L and earlier versions of V4L2. Making this +optional means applications depending on two file descriptors need +backup routines to be compatible with all drivers, which is +considerable more work than using two fds in applications which do +not. Also two fd's fit the general concept of one file descriptor for +each logical stream. Hence as a complexity trade-off drivers +must support two file descriptors and +may support single fd operation. + + +
+ Querying Capabilities + + Devices supporting the video overlay interface set the +V4L2_CAP_VIDEO_OVERLAY flag in the +capabilities field of &v4l2-capability; +returned by the &VIDIOC-QUERYCAP; ioctl. The overlay I/O method specified +below must be supported. Tuners and audio inputs are optional. +
+ +
+ Supplemental Functions + + Video overlay devices shall support audio input, tuner, controls, +cropping and scaling and streaming parameter ioctls as needed. +The video input and video standard ioctls must be supported by +all video overlay devices. +
+ +
+ Setup + + Before overlay can commence applications must program the +driver with frame buffer parameters, namely the address and size of +the frame buffer and the image format, for example RGB 5:6:5. The +&VIDIOC-G-FBUF; and &VIDIOC-S-FBUF; ioctls are available to get +and set these parameters, respectively. The +VIDIOC_S_FBUF ioctl is privileged because it +allows to set up DMA into physical memory, bypassing the memory +protection mechanisms of the kernel. Only the superuser can change the +frame buffer address and size. Users are not supposed to run TV +applications as root or with SUID bit set. A small helper application +with suitable privileges should query the graphics system and program +the V4L2 driver at the appropriate time. + + Some devices add the video overlay to the output signal +of the graphics card. In this case the frame buffer is not modified by +the video device, and the frame buffer address and pixel format are +not needed by the driver. The VIDIOC_S_FBUF ioctl +is not privileged. An application can check for this type of device by +calling the VIDIOC_G_FBUF ioctl. + + A driver may support any (or none) of five clipping/blending +methods: + + Chroma-keying displays the overlaid image only where +pixels in the primary graphics surface assume a certain color. + + + A bitmap can be specified where each bit corresponds +to a pixel in the overlaid image. When the bit is set, the +corresponding video pixel is displayed, otherwise a pixel of the +graphics surface. + + + A list of clipping rectangles can be specified. In +these regions no video is displayed, so the +graphics surface can be seen here. + + + The framebuffer has an alpha channel that can be used +to clip or blend the framebuffer with the video. + + + A global alpha value can be specified to blend the +framebuffer contents with video images. + + + + When simultaneous capturing and overlay is supported and +the hardware prohibits different image and frame buffer formats, the +format requested first takes precedence. The attempt to capture +(&VIDIOC-S-FMT;) or overlay (&VIDIOC-S-FBUF;) may fail with an +&EBUSY; or return accordingly modified parameters.. +
+ +
+ Overlay Window + + The overlaid image is determined by cropping and overlay +window parameters. The former select an area of the video picture to +capture, the latter how images are overlaid and clipped. Cropping +initialization at minimum requires to reset the parameters to +defaults. An example is given in . + + The overlay window is described by a &v4l2-window;. It +defines the size of the image, its position over the graphics surface +and the clipping to be applied. To get the current parameters +applications set the type field of a +&v4l2-format; to V4L2_BUF_TYPE_VIDEO_OVERLAY and +call the &VIDIOC-G-FMT; ioctl. The driver fills the +v4l2_window substructure named +win. It is not possible to retrieve a +previously programmed clipping list or bitmap. + + To program the overlay window applications set the +type field of a &v4l2-format; to +V4L2_BUF_TYPE_VIDEO_OVERLAY, initialize the +win substructure and call the +&VIDIOC-S-FMT; ioctl. The driver adjusts the parameters against +hardware limits and returns the actual parameters as +VIDIOC_G_FMT does. Like +VIDIOC_S_FMT, the &VIDIOC-TRY-FMT; ioctl can be +used to learn about driver capabilities without actually changing +driver state. Unlike VIDIOC_S_FMT this also works +after the overlay has been enabled. + + The scaling factor of the overlaid image is implied by the +width and height given in &v4l2-window; and the size of the cropping +rectangle. For more information see . + + When simultaneous capturing and overlay is supported and +the hardware prohibits different image and window sizes, the size +requested first takes precedence. The attempt to capture or overlay as +well (&VIDIOC-S-FMT;) may fail with an &EBUSY; or return accordingly +modified parameters. + + + struct <structname>v4l2_window</structname> + + &cs-str; + + + &v4l2-rect; + w + Size and position of the window relative to the +top, left corner of the frame buffer defined with &VIDIOC-S-FBUF;. The +window can extend the frame buffer width and height, the +x and y +coordinates can be negative, and it can lie completely outside the +frame buffer. The driver clips the window accordingly, or if that is +not possible, modifies its size and/or position. + + + &v4l2-field; + field + Applications set this field to determine which +video field shall be overlaid, typically one of +V4L2_FIELD_ANY (0), +V4L2_FIELD_TOP, +V4L2_FIELD_BOTTOM or +V4L2_FIELD_INTERLACED. Drivers may have to choose +a different field order and return the actual setting here. + + + __u32 + chromakey + When chroma-keying has been negotiated with +&VIDIOC-S-FBUF; applications set this field to the desired pixel value +for the chroma key. The format is the same as the pixel format of the +framebuffer (&v4l2-framebuffer; +fmt.pixelformat field), with bytes in host +order. E. g. for V4L2_PIX_FMT_BGR24 +the value should be 0xRRGGBB on a little endian, 0xBBGGRR on a big +endian host. + + + &v4l2-clip; * + clips + When chroma-keying has not +been negotiated and &VIDIOC-G-FBUF; indicated this capability, +applications can set this field to point to an array of +clipping rectangles. + + + + + Like the window coordinates +w, clipping rectangles are defined relative +to the top, left corner of the frame buffer. However clipping +rectangles must not extend the frame buffer width and height, and they +must not overlap. If possible applications should merge adjacent +rectangles. Whether this must create x-y or y-x bands, or the order of +rectangles, is not defined. When clip lists are not supported the +driver ignores this field. Its contents after calling &VIDIOC-S-FMT; +are undefined. + + + __u32 + clipcount + When the application set the +clips field, this field must contain the +number of clipping rectangles in the list. When clip lists are not +supported the driver ignores this field, its contents after calling +VIDIOC_S_FMT are undefined. When clip lists are +supported but no clipping is desired this field must be set to +zero. + + + void * + bitmap + When chroma-keying has +not been negotiated and &VIDIOC-G-FBUF; indicated +this capability, applications can set this field to point to a +clipping bit mask. + + + It must be of the same size +as the window, w.width and +w.height. Each bit corresponds to a pixel +in the overlaid image, which is displayed only when the bit is +set. Pixel coordinates translate to bits like: + +((__u8 *) bitmap)[w.width * y + x / 8] & (1 << (x & 7))where 0 ≤ x < +w.width and 0 ≤ +y <w.height. + Should we require + w.width to be a multiple of + eight? + When a clipping +bit mask is not supported the driver ignores this field, its contents +after calling &VIDIOC-S-FMT; are undefined. When a bit mask is supported +but no clipping is desired this field must be set to +NULL.Applications need not create a +clip list or bit mask. When they pass both, or despite negotiating +chroma-keying, the results are undefined. Regardless of the chosen +method, the clipping abilities of the hardware may be limited in +quantity or quality. The results when these limits are exceeded are +undefined. + When the image is written into frame buffer +memory it will be undesirable if the driver clips out less pixels +than expected, because the application and graphics system are not +aware these regions need to be refreshed. The driver should clip out +more pixels or not write the image at all. + + + + __u8 + global_alpha + The global alpha value used to blend the +framebuffer with video images, if global alpha blending has been +negotiated (V4L2_FBUF_FLAG_GLOBAL_ALPHA, see +&VIDIOC-S-FBUF;, ). + + + + + Note this field was added in Linux 2.6.23, extending the structure. However +the VIDIOC_G/S/TRY_FMT ioctls, +which take a pointer to a v4l2_format parent structure with padding +bytes at the end, are not affected. + + + +
+ + + struct <structname>v4l2_clip</structname><footnote> + <para>The X Window system defines "regions" which are +vectors of struct BoxRec { short x1, y1, x2, y2; } with width = x2 - +x1 and height = y2 - y1, so one cannot pass X11 clip lists +directly.</para> + </footnote> + + &cs-str; + + + &v4l2-rect; + c + Coordinates of the clipping rectangle, relative to +the top, left corner of the frame buffer. Only window pixels +outside all clipping rectangles are +displayed. + + + &v4l2-clip; * + next + Pointer to the next clipping rectangle, NULL when +this is the last rectangle. Drivers ignore this field, it cannot be +used to pass a linked list of clipping rectangles. + + + +
+ + + + + struct <structname>v4l2_rect</structname> + + &cs-str; + + + __s32 + left + Horizontal offset of the top, left corner of the +rectangle, in pixels. + + + __s32 + top + Vertical offset of the top, left corner of the +rectangle, in pixels. Offsets increase to the right and down. + + + __s32 + width + Width of the rectangle, in pixels. + + + __s32 + height + Height of the rectangle, in pixels. Width and +height cannot be negative, the fields are signed for hysterical +reasons. + + + +
+
+ +
+ Enabling Overlay + + To start or stop the frame buffer overlay applications call +the &VIDIOC-OVERLAY; ioctl. +
diff --git a/Documentation/DocBook/media/v4l/dev-radio.xml b/Documentation/DocBook/media/v4l/dev-radio.xml new file mode 100644 index 00000000..3e6ac73b --- /dev/null +++ b/Documentation/DocBook/media/v4l/dev-radio.xml @@ -0,0 +1,49 @@ + Radio Interface + + This interface is intended for AM and FM (analog) radio +receivers and transmitters. + + Conventionally V4L2 radio devices are accessed through +character device special files named /dev/radio +and /dev/radio0 to +/dev/radio63 with major number 81 and minor +numbers 64 to 127. + +
+ Querying Capabilities + + Devices supporting the radio interface set the +V4L2_CAP_RADIO and +V4L2_CAP_TUNER or +V4L2_CAP_MODULATOR flag in the +capabilities field of &v4l2-capability; +returned by the &VIDIOC-QUERYCAP; ioctl. Other combinations of +capability flags are reserved for future extensions. +
+ +
+ Supplemental Functions + + Radio devices can support controls, and must support the tuner or modulator ioctls. + + They do not support the video input or output, audio input +or output, video standard, cropping and scaling, compression and +streaming parameter, or overlay ioctls. All other ioctls and I/O +methods are reserved for future extensions. +
+ +
+ Programming + + Radio devices may have a couple audio controls (as discussed +in ) such as a volume control, possibly custom +controls. Further all radio devices have one tuner or modulator (these are +discussed in ) with index number zero to select +the radio frequency and to determine if a monaural or FM stereo +program is received/emitted. Drivers switch automatically between AM and FM +depending on the selected frequency. The &VIDIOC-G-TUNER; or +&VIDIOC-G-MODULATOR; ioctl +reports the supported frequency range. +
diff --git a/Documentation/DocBook/media/v4l/dev-raw-vbi.xml b/Documentation/DocBook/media/v4l/dev-raw-vbi.xml new file mode 100644 index 00000000..b788c72c --- /dev/null +++ b/Documentation/DocBook/media/v4l/dev-raw-vbi.xml @@ -0,0 +1,339 @@ + Raw VBI Data Interface + + VBI is an abbreviation of Vertical Blanking Interval, a gap +in the sequence of lines of an analog video signal. During VBI +no picture information is transmitted, allowing some time while the +electron beam of a cathode ray tube TV returns to the top of the +screen. Using an oscilloscope you will find here the vertical +synchronization pulses and short data packages ASK +modulatedASK: Amplitude-Shift Keying. A high signal +level represents a '1' bit, a low level a '0' bit. +onto the video signal. These are transmissions of services such as +Teletext or Closed Caption. + + Subject of this interface type is raw VBI data, as sampled off +a video signal, or to be added to a signal for output. +The data format is similar to uncompressed video images, a number of +lines times a number of samples per line, we call this a VBI image. + + Conventionally V4L2 VBI devices are accessed through character +device special files named /dev/vbi and +/dev/vbi0 to /dev/vbi31 with +major number 81 and minor numbers 224 to 255. +/dev/vbi is typically a symbolic link to the +preferred VBI device. This convention applies to both input and output +devices. + + To address the problems of finding related video and VBI +devices VBI capturing and output is also available as device function +under /dev/video. To capture or output raw VBI +data with these devices applications must call the &VIDIOC-S-FMT; +ioctl. Accessed as /dev/vbi, raw VBI capturing +or output is the default device function. + +
+ Querying Capabilities + + Devices supporting the raw VBI capturing or output API set +the V4L2_CAP_VBI_CAPTURE or +V4L2_CAP_VBI_OUTPUT flags, respectively, in the +capabilities field of &v4l2-capability; +returned by the &VIDIOC-QUERYCAP; ioctl. At least one of the +read/write, streaming or asynchronous I/O methods must be +supported. VBI devices may or may not have a tuner or modulator. +
+ +
+ Supplemental Functions + + VBI devices shall support video +input or output, tuner or +modulator, and controls ioctls +as needed. The video standard ioctls provide +information vital to program a VBI device, therefore must be +supported. +
+ +
+ Raw VBI Format Negotiation + + Raw VBI sampling abilities can vary, in particular the +sampling frequency. To properly interpret the data V4L2 specifies an +ioctl to query the sampling parameters. Moreover, to allow for some +flexibility applications can also suggest different parameters. + + As usual these parameters are not +reset at &func-open; time to permit Unix tool chains, programming a +device and then reading from it as if it was a plain file. Well +written V4L2 applications should always ensure they really get what +they want, requesting reasonable parameters and then checking if the +actual parameters are suitable. + + To query the current raw VBI capture parameters +applications set the type field of a +&v4l2-format; to V4L2_BUF_TYPE_VBI_CAPTURE or +V4L2_BUF_TYPE_VBI_OUTPUT, and call the +&VIDIOC-G-FMT; ioctl with a pointer to this structure. Drivers fill +the &v4l2-vbi-format; vbi member of the +fmt union. + + To request different parameters applications set the +type field of a &v4l2-format; as above and +initialize all fields of the &v4l2-vbi-format; +vbi member of the +fmt union, or better just modify the +results of VIDIOC_G_FMT, and call the +&VIDIOC-S-FMT; ioctl with a pointer to this structure. Drivers return +an &EINVAL; only when the given parameters are ambiguous, otherwise +they modify the parameters according to the hardware capabilites and +return the actual parameters. When the driver allocates resources at +this point, it may return an &EBUSY; to indicate the returned +parameters are valid but the required resources are currently not +available. That may happen for instance when the video and VBI areas +to capture would overlap, or when the driver supports multiple opens +and another process already requested VBI capturing or output. Anyway, +applications must expect other resource allocation points which may +return EBUSY, at the &VIDIOC-STREAMON; ioctl +and the first read(), write() and select() call. + + VBI devices must implement both the +VIDIOC_G_FMT and +VIDIOC_S_FMT ioctl, even if +VIDIOC_S_FMT ignores all requests and always +returns default parameters as VIDIOC_G_FMT does. +VIDIOC_TRY_FMT is optional. + + + struct <structname>v4l2_vbi_format</structname> + + &cs-str; + + + __u32 + sampling_rate + Samples per second, i. e. unit 1 Hz. + + + __u32 + offset + Horizontal offset of the VBI image, +relative to the leading edge of the line synchronization pulse and +counted in samples: The first sample in the VBI image will be located +offset / +sampling_rate seconds following the leading +edge. See also . + + + __u32 + samples_per_line + + + + __u32 + sample_format + Defines the sample format as in , a four-character-code. + A few devices may be unable to +sample VBI data at all but can extend the video capture window to the +VBI region. + Usually this is +V4L2_PIX_FMT_GREY, i. e. each sample +consists of 8 bits with lower values oriented towards the black level. +Do not assume any other correlation of values with the signal level. +For example, the MSB does not necessarily indicate if the signal is +'high' or 'low' because 128 may not be the mean value of the +signal. Drivers shall not convert the sample format by software. + + + __u32 + start[2] + This is the scanning system line number +associated with the first line of the VBI image, of the first and the +second field respectively. See and + for valid values. VBI input drivers can +return start values 0 if the hardware cannot reliable identify +scanning lines, VBI acquisition may not require this +information. + + + __u32 + count[2] + The number of lines in the first and second +field image, respectively. + + + Drivers should be as +flexibility as possible. For example, it may be possible to extend or +move the VBI capture window down to the picture area, implementing a +'full field mode' to capture data service transmissions embedded in +the picture.An application can set the first or second +count value to zero if no data is required +from the respective field; count[1] if the +scanning system is progressive, &ie; not interlaced. The +corresponding start value shall be ignored by the application and +driver. Anyway, drivers may not support single field capturing and +return both count values non-zero.Both +count values set to zero, or line numbers +outside the bounds depicted in and , or a field image covering +lines of two fields, are invalid and shall not be returned by the +driver.To initialize the start +and count fields, applications must first +determine the current video standard selection. The &v4l2-std-id; or +the framelines field of &v4l2-standard; can +be evaluated for this purpose. + + + __u32 + flags + See below. Currently +only drivers set flags, applications must set this field to +zero. + + + __u32 + reserved[2] + This array is reserved for future extensions. +Drivers and applications must set it to zero. + + + +
+ + + Raw VBI Format Flags + + &cs-def; + + + V4L2_VBI_UNSYNC + 0x0001 + This flag indicates hardware which does not +properly distinguish between fields. Normally the VBI image stores the +first field (lower scanning line numbers) first in memory. This may be +a top or bottom field depending on the video standard. When this flag +is set the first or second field may be stored first, however the +fields are still in correct temporal order with the older field first +in memory. + Most VBI services transmit on both fields, but +some have different semantics depending on the field number. These +cannot be reliable decoded or encoded when +V4L2_VBI_UNSYNC is set. + + + + V4L2_VBI_INTERLACED + 0x0002 + By default the two field images will be passed +sequentially; all lines of the first field followed by all lines of +the second field (compare +V4L2_FIELD_SEQ_TB and +V4L2_FIELD_SEQ_BT, whether the top or bottom +field is first in memory depends on the video standard). When this +flag is set, the two fields are interlaced (cf. +V4L2_FIELD_INTERLACED). The first line of the +first field followed by the first line of the second field, then the +two second lines, and so on. Such a layout may be necessary when the +hardware has been programmed to capture or output interlaced video +images and is unable to separate the fields for VBI capturing at +the same time. For simplicity setting this flag implies that both +count values are equal and non-zero. + + + +
+ +
+ Line synchronization + + + + + + + + + Line synchronization diagram + + +
+ +
+ ITU-R 525 line numbering (M/NTSC and M/PAL) + + + + + + + + + NTSC field synchronization diagram + + + (1) For the purpose of this specification field 2 +starts in line 264 and not 263.5 because half line capturing is not +supported. + + +
+ +
+ ITU-R 625 line numbering + + + + + + + + + PAL/SECAM field synchronization diagram + + + (1) For the purpose of this specification field 2 +starts in line 314 and not 313.5 because half line capturing is not +supported. + + +
+ + Remember the VBI image format depends on the selected +video standard, therefore the application must choose a new standard or +query the current standard first. Attempts to read or write data ahead +of format negotiation, or after switching the video standard which may +invalidate the negotiated VBI parameters, should be refused by the +driver. A format change during active I/O is not permitted. +
+ +
+ Reading and writing VBI images + + To assure synchronization with the field number and easier +implementation, the smallest unit of data passed at a time is one +frame, consisting of two fields of VBI images immediately following in +memory. + + The total size of a frame computes as follows: + + +(count[0] + count[1]) * +samples_per_line * sample size in bytes + + The sample size is most likely always one byte, +applications must check the sample_format +field though, to function properly with other drivers. + + A VBI device may support read/write and/or streaming (memory mapping or user pointer) I/O. The latter bears the +possibility of synchronizing video and +VBI data by using buffer timestamps. + + Remember the &VIDIOC-STREAMON; ioctl and the first read(), +write() and select() call can be resource allocation points returning +an &EBUSY; if the required hardware resources are temporarily +unavailable, for example the device is already in use by another +process. +
diff --git a/Documentation/DocBook/media/v4l/dev-rds.xml b/Documentation/DocBook/media/v4l/dev-rds.xml new file mode 100644 index 00000000..be2f3373 --- /dev/null +++ b/Documentation/DocBook/media/v4l/dev-rds.xml @@ -0,0 +1,196 @@ + RDS Interface + + The Radio Data System transmits supplementary +information in binary format, for example the station name or travel +information, on an inaudible audio subcarrier of a radio program. This +interface is aimed at devices capable of receiving and/or transmitting RDS +information. + + For more information see the core RDS standard +and the RBDS standard . + + Note that the RBDS standard as is used in the USA is almost identical +to the RDS standard. Any RDS decoder/encoder can also handle RBDS. Only some of the +fields have slightly different meanings. See the RBDS standard for more +information. + + The RBDS standard also specifies support for MMBS (Modified Mobile Search). +This is a proprietary format which seems to be discontinued. The RDS interface does not +support this format. Should support for MMBS (or the so-called 'E blocks' in general) +be needed, then please contact the linux-media mailing list: &v4l-ml;. + +
+ Querying Capabilities + + Devices supporting the RDS capturing API set +the V4L2_CAP_RDS_CAPTURE flag in +the capabilities field of &v4l2-capability; +returned by the &VIDIOC-QUERYCAP; ioctl. Any tuner that supports RDS +will set the V4L2_TUNER_CAP_RDS flag in +the capability field of &v4l2-tuner;. If +the driver only passes RDS blocks without interpreting the data +the V4L2_TUNER_CAP_RDS_BLOCK_IO flag has to be +set, see Reading RDS data. +For future use the +flag V4L2_TUNER_CAP_RDS_CONTROLS has also been +defined. However, a driver for a radio tuner with this capability does +not yet exist, so if you are planning to write such a driver you +should discuss this on the linux-media mailing list: &v4l-ml;. + + Whether an RDS signal is present can be detected by looking +at the rxsubchans field of &v4l2-tuner;: +the V4L2_TUNER_SUB_RDS will be set if RDS data +was detected. + + Devices supporting the RDS output API +set the V4L2_CAP_RDS_OUTPUT flag in +the capabilities field of &v4l2-capability; +returned by the &VIDIOC-QUERYCAP; ioctl. +Any modulator that supports RDS will set the +V4L2_TUNER_CAP_RDS flag in the capability +field of &v4l2-modulator;. +In order to enable the RDS transmission one must set the V4L2_TUNER_SUB_RDS +bit in the txsubchans field of &v4l2-modulator;. +If the driver only passes RDS blocks without interpreting the data +the V4L2_TUNER_CAP_RDS_BLOCK_IO flag has to be set. If the +tuner is capable of handling RDS entities like program identification codes and radio +text, the flag V4L2_TUNER_CAP_RDS_CONTROLS should be set, +see Writing RDS data and +FM Transmitter Control Reference. +
+ +
+ Reading RDS data + + RDS data can be read from the radio device +with the &func-read; function. The data is packed in groups of three bytes. +
+ +
+ Writing RDS data + + RDS data can be written to the radio device +with the &func-write; function. The data is packed in groups of three bytes, +as follows: +
+ +
+ RDS datastructures + + struct +<structname>v4l2_rds_data</structname> + + + + + + + __u8 + lsb + Least Significant Byte of RDS Block + + + __u8 + msb + Most Significant Byte of RDS Block + + + __u8 + block + Block description + + + +
+ + Block description + + + + + + Bits 0-2 + Block (aka offset) of the received data. + + + Bits 3-5 + Deprecated. Currently identical to bits 0-2. Do not use these bits. + + + Bit 6 + Corrected bit. Indicates that an error was corrected for this data block. + + + Bit 7 + Error bit. Indicates that an uncorrectable error occurred during reception of this block. + + + +
+ + + Block defines + + + + + + + + V4L2_RDS_BLOCK_MSK + + 7 + Mask for bits 0-2 to get the block ID. + + + V4L2_RDS_BLOCK_A + + 0 + Block A. + + + V4L2_RDS_BLOCK_B + + 1 + Block B. + + + V4L2_RDS_BLOCK_C + + 2 + Block C. + + + V4L2_RDS_BLOCK_D + + 3 + Block D. + + + V4L2_RDS_BLOCK_C_ALT + + 4 + Block C'. + + + V4L2_RDS_BLOCK_INVALID + read-only + 7 + An invalid block. + + + V4L2_RDS_BLOCK_CORRECTED + read-only + 0x40 + A bit error was detected but corrected. + + + V4L2_RDS_BLOCK_ERROR + read-only + 0x80 + An uncorrectable error occurred. + + + +
+
diff --git a/Documentation/DocBook/media/v4l/dev-sliced-vbi.xml b/Documentation/DocBook/media/v4l/dev-sliced-vbi.xml new file mode 100644 index 00000000..548f8ea2 --- /dev/null +++ b/Documentation/DocBook/media/v4l/dev-sliced-vbi.xml @@ -0,0 +1,699 @@ + Sliced VBI Data Interface + + VBI stands for Vertical Blanking Interval, a gap in the +sequence of lines of an analog video signal. During VBI no picture +information is transmitted, allowing some time while the electron beam +of a cathode ray tube TV returns to the top of the screen. + + Sliced VBI devices use hardware to demodulate data transmitted +in the VBI. V4L2 drivers shall not do this by +software, see also the raw VBI +interface. The data is passed as short packets of fixed size, +covering one scan line each. The number of packets per video frame is +variable. + + Sliced VBI capture and output devices are accessed through the +same character special files as raw VBI devices. When a driver +supports both interfaces, the default function of a +/dev/vbi device is raw VBI +capturing or output, and the sliced VBI function is only available +after calling the &VIDIOC-S-FMT; ioctl as defined below. Likewise a +/dev/video device may support the sliced VBI API, +however the default function here is video capturing or output. +Different file descriptors must be used to pass raw and sliced VBI +data simultaneously, if this is supported by the driver. + +
+ Querying Capabilities + + Devices supporting the sliced VBI capturing or output API +set the V4L2_CAP_SLICED_VBI_CAPTURE or +V4L2_CAP_SLICED_VBI_OUTPUT flag respectively, in +the capabilities field of &v4l2-capability; +returned by the &VIDIOC-QUERYCAP; ioctl. At least one of the +read/write, streaming or asynchronous I/O +methods must be supported. Sliced VBI devices may have a tuner +or modulator. +
+ +
+ Supplemental Functions + + Sliced VBI devices shall support video +input or output and tuner or +modulator ioctls if they have these capabilities, and they may +support control ioctls. The video standard ioctls provide information +vital to program a sliced VBI device, therefore must be +supported. +
+ +
+ Sliced VBI Format Negotiation + + To find out which data services are supported by the +hardware applications can call the &VIDIOC-G-SLICED-VBI-CAP; ioctl. +All drivers implementing the sliced VBI interface must support this +ioctl. The results may differ from those of the &VIDIOC-S-FMT; ioctl +when the number of VBI lines the hardware can capture or output per +frame, or the number of services it can identify on a given line are +limited. For example on PAL line 16 the hardware may be able to look +for a VPS or Teletext signal, but not both at the same time. + + To determine the currently selected services applications +set the type field of &v4l2-format; to + V4L2_BUF_TYPE_SLICED_VBI_CAPTURE or +V4L2_BUF_TYPE_SLICED_VBI_OUTPUT, and the &VIDIOC-G-FMT; +ioctl fills the fmt.sliced member, a +&v4l2-sliced-vbi-format;. + + Applications can request different parameters by +initializing or modifying the fmt.sliced +member and calling the &VIDIOC-S-FMT; ioctl with a pointer to the +v4l2_format structure. + + The sliced VBI API is more complicated than the raw VBI API +because the hardware must be told which VBI service to expect on each +scan line. Not all services may be supported by the hardware on all +lines (this is especially true for VBI output where Teletext is often +unsupported and other services can only be inserted in one specific +line). In many cases, however, it is sufficient to just set the +service_set field to the required services +and let the driver fill the service_lines +array according to hardware capabilities. Only if more precise control +is needed should the programmer set the +service_lines array explicitly. + + The &VIDIOC-S-FMT; ioctl modifies the parameters +according to hardware capabilities. When the driver allocates +resources at this point, it may return an &EBUSY; if the required +resources are temporarily unavailable. Other resource allocation +points which may return EBUSY can be the +&VIDIOC-STREAMON; ioctl and the first &func-read;, &func-write; and +&func-select; call. + + + struct +<structname>v4l2_sliced_vbi_format</structname> + + + + + + + + + + __u32 + service_set + If +service_set is non-zero when passed with +&VIDIOC-S-FMT; or &VIDIOC-TRY-FMT;, the +service_lines array will be filled by the +driver according to the services specified in this field. For example, +if service_set is initialized with +V4L2_SLICED_TELETEXT_B | V4L2_SLICED_WSS_625, a +driver for the cx25840 video decoder sets lines 7-22 of both +fieldsAccording to ETS 300 706 lines 6-22 of the +first field and lines 5-22 of the second field may carry Teletext +data. to V4L2_SLICED_TELETEXT_B +and line 23 of the first field to +V4L2_SLICED_WSS_625. If +service_set is set to zero, then the values +of service_lines will be used instead. +On return the driver sets this field to the union of all +elements of the returned service_lines +array. It may contain less services than requested, perhaps just one, +if the hardware cannot handle more services simultaneously. It may be +empty (zero) if none of the requested services are supported by the +hardware. + + + __u16 + service_lines[2][24] + Applications initialize this +array with sets of data services the driver shall look for or insert +on the respective scan line. Subject to hardware capabilities drivers +return the requested set, a subset, which may be just a single +service, or an empty set. When the hardware cannot handle multiple +services on the same line the driver shall choose one. No assumptions +can be made on which service the driver chooses.Data +services are defined in . Array indices +map to ITU-R line numbers (see also and ) as follows: + + + + + Element + 525 line systems + 625 line systems + + + + + service_lines[0][1] + 1 + 1 + + + + + service_lines[0][23] + 23 + 23 + + + + + service_lines[1][1] + 264 + 314 + + + + + service_lines[1][23] + 286 + 336 + + + + + + Drivers must set +service_lines[0][0] and +service_lines[1][0] to zero. + + + __u32 + io_size + Maximum number of bytes passed by +one &func-read; or &func-write; call, and the buffer size in bytes for +the &VIDIOC-QBUF; and &VIDIOC-DQBUF; ioctl. Drivers set this field to +the size of &v4l2-sliced-vbi-data; times the number of non-zero +elements in the returned service_lines +array (that is the number of lines potentially carrying data). + + + __u32 + reserved[2] + This array is reserved for future +extensions. Applications and drivers must set it to zero. + + + +
+ + + + Sliced VBI services + + + + + + + + + + Symbol + Value + Reference + Lines, usually + Payload + + + + + V4L2_SLICED_TELETEXT_B +(Teletext System B) + 0x0001 + , + PAL/SECAM line 7-22, 320-335 (second field 7-22) + Last 42 of the 45 byte Teletext packet, that is +without clock run-in and framing code, lsb first transmitted. + + + V4L2_SLICED_VPS + 0x0400 + + PAL line 16 + Byte number 3 to 15 according to Figure 9 of +ETS 300 231, lsb first transmitted. + + + V4L2_SLICED_CAPTION_525 + 0x1000 + + NTSC line 21, 284 (second field 21) + Two bytes in transmission order, including parity +bit, lsb first transmitted. + + + V4L2_SLICED_WSS_625 + 0x4000 + , + PAL/SECAM line 23 + +Byte 0 1 + msb lsb msb lsb + Bit 7 6 5 4 3 2 1 0 x x 13 12 11 10 9 + + + + V4L2_SLICED_VBI_525 + 0x1000 + Set of services applicable to 525 +line systems. + + + V4L2_SLICED_VBI_625 + 0x4401 + Set of services applicable to 625 +line systems. + + + +
+ + Drivers may return an &EINVAL; when applications attempt to +read or write data without prior format negotiation, after switching +the video standard (which may invalidate the negotiated VBI +parameters) and after switching the video input (which may change the +video standard as a side effect). The &VIDIOC-S-FMT; ioctl may return +an &EBUSY; when applications attempt to change the format while i/o is +in progress (between a &VIDIOC-STREAMON; and &VIDIOC-STREAMOFF; call, +and after the first &func-read; or &func-write; call). +
+ +
+ Reading and writing sliced VBI data + + A single &func-read; or &func-write; call must pass all data +belonging to one video frame. That is an array of +v4l2_sliced_vbi_data structures with one or +more elements and a total size not exceeding +io_size bytes. Likewise in streaming I/O +mode one buffer of io_size bytes must +contain data of one video frame. The id of +unused v4l2_sliced_vbi_data elements must be +zero. + + + struct +<structname>v4l2_sliced_vbi_data</structname> + + &cs-def; + + + __u32 + id + A flag from +identifying the type of data in this packet. Only a single bit must be +set. When the id of a captured packet is +zero, the packet is empty and the contents of other fields are +undefined. Applications shall ignore empty packets. When the +id of a packet for output is zero the +contents of the data field are undefined +and the driver must no longer insert data on the requested +field and +line. + + + __u32 + field + The video field number this data has been captured +from, or shall be inserted at. 0 for the first +field, 1 for the second field. + + + __u32 + line + The field (as opposed to frame) line number this +data has been captured from, or shall be inserted at. See and for valid +values. Sliced VBI capture devices can set the line number of all +packets to 0 if the hardware cannot reliably +identify scan lines. The field number must always be valid. + + + __u32 + reserved + This field is reserved for future extensions. +Applications and drivers must set it to zero. + + + __u8 + data[48] + The packet payload. See for the contents and number of +bytes passed for each data type. The contents of padding bytes at the +end of this array are undefined, drivers and applications shall ignore +them. + + + +
+ + Packets are always passed in ascending line number order, +without duplicate line numbers. The &func-write; function and the +&VIDIOC-QBUF; ioctl must return an &EINVAL; when applications violate +this rule. They must also return an &EINVAL; when applications pass an +incorrect field or line number, or a combination of +field, line and +id which has not been negotiated with the +&VIDIOC-G-FMT; or &VIDIOC-S-FMT; ioctl. When the line numbers are +unknown the driver must pass the packets in transmitted order. The +driver can insert empty packets with id set +to zero anywhere in the packet array. + + To assure synchronization and to distinguish from frame +dropping, when a captured frame does not carry any of the requested +data services drivers must pass one or more empty packets. When an +application fails to pass VBI data in time for output, the driver +must output the last VPS and WSS packet again, and disable the output +of Closed Caption and Teletext data, or output data which is ignored +by Closed Caption and Teletext decoders. + + A sliced VBI device may support read/write and/or streaming (memory mapping and/or user +pointer) I/O. The latter bears the possibility of synchronizing +video and VBI data by using buffer timestamps. + +
+ +
+ Sliced VBI Data in MPEG Streams + + If a device can produce an MPEG output stream, it may be +capable of providing negotiated sliced VBI +services as data embedded in the MPEG stream. Users or +applications control this sliced VBI data insertion with the V4L2_CID_MPEG_STREAM_VBI_FMT +control. + + If the driver does not provide the V4L2_CID_MPEG_STREAM_VBI_FMT +control, or only allows that control to be set to +V4L2_MPEG_STREAM_VBI_FMT_NONE, then the device +cannot embed sliced VBI data in the MPEG stream. + + The +V4L2_CID_MPEG_STREAM_VBI_FMT control does not implicitly set +the device driver to capture nor cease capturing sliced VBI data. The +control only indicates to embed sliced VBI data in the MPEG stream, if +an application has negotiated sliced VBI service be captured. + + It may also be the case that a device can embed sliced VBI +data in only certain types of MPEG streams: for example in an MPEG-2 +PS but not an MPEG-2 TS. In this situation, if sliced VBI data +insertion is requested, the sliced VBI data will be embedded in MPEG +stream types when supported, and silently omitted from MPEG stream +types where sliced VBI data insertion is not supported by the device. + + + The following subsections specify the format of the +embedded sliced VBI data. + +
+ MPEG Stream Embedded, Sliced VBI Data Format: NONE + The +V4L2_MPEG_STREAM_VBI_FMT_NONE embedded sliced VBI +format shall be interpreted by drivers as a control to cease +embedding sliced VBI data in MPEG streams. Neither the device nor +driver shall insert "empty" embedded sliced VBI data packets in the +MPEG stream when this format is set. No MPEG stream data structures +are specified for this format. +
+ +
+ MPEG Stream Embedded, Sliced VBI Data Format: IVTV + The +V4L2_MPEG_STREAM_VBI_FMT_IVTV embedded sliced VBI +format, when supported, indicates to the driver to embed up to 36 +lines of sliced VBI data per frame in an MPEG-2 Private +Stream 1 PES packet encapsulated in an MPEG-2 +Program Pack in the MPEG stream. + + Historical context: This format +specification originates from a custom, embedded, sliced VBI data +format used by the ivtv driver. This format +has already been informally specified in the kernel sources in the +file Documentation/video4linux/cx2341x/README.vbi +. The maximum size of the payload and other aspects of this format +are driven by the CX23415 MPEG decoder's capabilities and limitations +with respect to extracting, decoding, and displaying sliced VBI data +embedded within an MPEG stream. + + This format's use is not exclusive to +the ivtv driver nor +exclusive to CX2341x devices, as the sliced VBI data packet insertion +into the MPEG stream is implemented in driver software. At least the +cx18 driver provides sliced VBI data insertion +into an MPEG-2 PS in this format as well. + + The following definitions specify the payload of the +MPEG-2 Private Stream 1 PES packets that contain +sliced VBI data when +V4L2_MPEG_STREAM_VBI_FMT_IVTV is set. +(The MPEG-2 Private Stream 1 PES packet header +and encapsulating MPEG-2 Program Pack header are +not detailed here. Please refer to the MPEG-2 specifications for +details on those packet headers.) + + The payload of the MPEG-2 Private Stream 1 PES + packets that contain sliced VBI data is specified by +&v4l2-mpeg-vbi-fmt-ivtv;. The payload is variable +length, depending on the actual number of lines of sliced VBI data +present in a video frame. The payload may be padded at the end with +unspecified fill bytes to align the end of the payload to a 4-byte +boundary. The payload shall never exceed 1552 bytes (2 fields with +18 lines/field with 43 bytes of data/line and a 4 byte magic number). + + + + struct <structname>v4l2_mpeg_vbi_fmt_ivtv</structname> + + + &cs-ustr; + + + __u8 + magic[4] + + A "magic" constant from that indicates +this is a valid sliced VBI data payload and also indicates which +member of the anonymous union, itv0 or +ITV0, to use for the payload data. + + + union + (anonymous) + + + + struct + v4l2_mpeg_vbi_itv0 + + itv0 + The primary form of the sliced VBI data payload +that contains anywhere from 1 to 35 lines of sliced VBI data. +Line masks are provided in this form of the payload indicating +which VBI lines are provided. + + + + struct + v4l2_mpeg_vbi_ITV0 + + ITV0 + An alternate form of the sliced VBI data payload +used when 36 lines of sliced VBI data are present. No line masks are +provided in this form of the payload; all valid line mask bits are +implcitly set. + + + +
+ + + Magic Constants for &v4l2-mpeg-vbi-fmt-ivtv; + <structfield>magic</structfield> field + + &cs-def; + + + Defined Symbol + Value + Description + + + + + V4L2_MPEG_VBI_IVTV_MAGIC0 + + "itv0" + Indicates the itv0 +member of the union in &v4l2-mpeg-vbi-fmt-ivtv; is valid. + + + V4L2_MPEG_VBI_IVTV_MAGIC1 + + "ITV0" + Indicates the ITV0 +member of the union in &v4l2-mpeg-vbi-fmt-ivtv; is valid and +that 36 lines of sliced VBI data are present. + + + +
+ + + struct <structname>v4l2_mpeg_vbi_itv0</structname> + + + &cs-str; + + + __le32 + linemask[2] + Bitmasks indicating the VBI service lines +present. These linemask values are stored +in little endian byte order in the MPEG stream. Some reference +linemask bit positions with their +corresponding VBI line number and video field are given below. +b0 indicates the least significant bit of a +linemask value: +linemask[0] b0: line 6 first field +linemask[0] b17: line 23 first field +linemask[0] b18: line 6 second field +linemask[0] b31: line 19 second field +linemask[1] b0: line 20 second field +linemask[1] b3: line 23 second field +linemask[1] b4-b31: unused and set to 0 + + + struct + v4l2_mpeg_vbi_itv0_line + + line[35] + This is a variable length array that holds from 1 +to 35 lines of sliced VBI data. The sliced VBI data lines present +correspond to the bits set in the linemask +array, starting from b0 of +linemask[0] up through b31 of +linemask[0], and from b0 + of linemask[1] up through b +3 of linemask[1]. +line[0] corresponds to the first bit +found set in the linemask array, +line[1] corresponds to the second bit +found set in the linemask array, etc. +If no linemask array bits are set, then +line[0] may contain one line of +unspecified data that should be ignored by applications. + + + +
+ + + struct <structname>v4l2_mpeg_vbi_ITV0</structname> + + + &cs-str; + + + struct + v4l2_mpeg_vbi_itv0_line + + line[36] + A fixed length array of 36 lines of sliced VBI +data. line[0] through line +[17] correspond to lines 6 through 23 of the +first field. line[18] through +line[35] corresponds to lines 6 +through 23 of the second field. + + + +
+ + + struct <structname>v4l2_mpeg_vbi_itv0_line</structname> + + + &cs-str; + + + __u8 + id + A line identifier value from + that indicates +the type of sliced VBI data stored on this line. + + + __u8 + data[42] + The sliced VBI data for the line. + + + +
+ + + Line Identifiers for struct <link + linkend="v4l2-mpeg-vbi-itv0-line"><structname> +v4l2_mpeg_vbi_itv0_line</structname></link> <structfield>id +</structfield> field + + &cs-def; + + + Defined Symbol + Value + Description + + + + + V4L2_MPEG_VBI_IVTV_TELETEXT_B + + 1 + Refer to +Sliced VBI services for a description of the line payload. + + + V4L2_MPEG_VBI_IVTV_CAPTION_525 + + 4 + Refer to +Sliced VBI services for a description of the line payload. + + + V4L2_MPEG_VBI_IVTV_WSS_625 + + 5 + Refer to +Sliced VBI services for a description of the line payload. + + + V4L2_MPEG_VBI_IVTV_VPS + + 7 + Refer to +Sliced VBI services for a description of the line payload. + + + +
+ +
+
diff --git a/Documentation/DocBook/media/v4l/dev-subdev.xml b/Documentation/DocBook/media/v4l/dev-subdev.xml new file mode 100644 index 00000000..d15aaf83 --- /dev/null +++ b/Documentation/DocBook/media/v4l/dev-subdev.xml @@ -0,0 +1,467 @@ + Sub-device Interface + + + Experimental + This is an experimental + interface and may change in the future. + + + The complex nature of V4L2 devices, where hardware is often made of + several integrated circuits that need to interact with each other in a + controlled way, leads to complex V4L2 drivers. The drivers usually reflect + the hardware model in software, and model the different hardware components + as software blocks called sub-devices. + + V4L2 sub-devices are usually kernel-only objects. If the V4L2 driver + implements the media device API, they will automatically inherit from media + entities. Applications will be able to enumerate the sub-devices and discover + the hardware topology using the media entities, pads and links enumeration + API. + + In addition to make sub-devices discoverable, drivers can also choose + to make them directly configurable by applications. When both the sub-device + driver and the V4L2 device driver support this, sub-devices will feature a + character device node on which ioctls can be called to + + query, read and write sub-devices controls + subscribe and unsubscribe to events and retrieve them + negotiate image formats on individual pads + + + + Sub-device character device nodes, conventionally named + /dev/v4l-subdev*, use major number 81. + +
+ Controls + Most V4L2 controls are implemented by sub-device hardware. Drivers + usually merge all controls and expose them through video device nodes. + Applications can control all sub-devices through a single interface. + + Complex devices sometimes implement the same control in different + pieces of hardware. This situation is common in embedded platforms, where + both sensors and image processing hardware implement identical functions, + such as contrast adjustment, white balance or faulty pixels correction. As + the V4L2 controls API doesn't support several identical controls in a single + device, all but one of the identical controls are hidden. + + Applications can access those hidden controls through the sub-device + node with the V4L2 control API described in . The + ioctls behave identically as when issued on V4L2 device nodes, with the + exception that they deal only with controls implemented in the sub-device. + + + Depending on the driver, those controls might also be exposed through + one (or several) V4L2 device nodes. +
+ +
+ Events + V4L2 sub-devices can notify applications of events as described in + . The API behaves identically as when used on V4L2 + device nodes, with the exception that it only deals with events generated by + the sub-device. Depending on the driver, those events might also be reported + on one (or several) V4L2 device nodes. +
+ +
+ Pad-level Formats + + Pad-level formats are only applicable to very complex device that + need to expose low-level format configuration to user space. Generic V4L2 + applications do not need to use the API described in + this section. + + For the purpose of this section, the term + format means the combination of media bus data + format, frame width and frame height. + + Image formats are typically negotiated on video capture and + output devices using the format and selection ioctls. The + driver is responsible for configuring every block in the video + pipeline according to the requested format at the pipeline input + and/or output. + + For complex devices, such as often found in embedded systems, + identical image sizes at the output of a pipeline can be achieved using + different hardware configurations. One such example is shown on + , where + image scaling can be performed on both the video sensor and the host image + processing hardware. + +
+ Image Format Negotiation on Pipelines + + + + + + + + + High quality and high speed pipeline configuration + + +
+ + The sensor scaler is usually of less quality than the host scaler, but + scaling on the sensor is required to achieve higher frame rates. Depending + on the use case (quality vs. speed), the pipeline must be configured + differently. Applications need to configure the formats at every point in + the pipeline explicitly. + + Drivers that implement the media + API can expose pad-level image format configuration to applications. + When they do, applications can use the &VIDIOC-SUBDEV-G-FMT; and + &VIDIOC-SUBDEV-S-FMT; ioctls. to negotiate formats on a per-pad basis. + + Applications are responsible for configuring coherent parameters on + the whole pipeline and making sure that connected pads have compatible + formats. The pipeline is checked for formats mismatch at &VIDIOC-STREAMON; + time, and an &EPIPE; is then returned if the configuration is + invalid. + + Pad-level image format configuration support can be tested by calling + the &VIDIOC-SUBDEV-G-FMT; ioctl on pad 0. If the driver returns an &EINVAL; + pad-level format configuration is not supported by the sub-device. + +
+ Format Negotiation + + Acceptable formats on pads can (and usually do) depend on a number + of external parameters, such as formats on other pads, active links, or + even controls. Finding a combination of formats on all pads in a video + pipeline, acceptable to both application and driver, can't rely on formats + enumeration only. A format negotiation mechanism is required. + + Central to the format negotiation mechanism are the get/set format + operations. When called with the which argument + set to V4L2_SUBDEV_FORMAT_TRY, the + &VIDIOC-SUBDEV-G-FMT; and &VIDIOC-SUBDEV-S-FMT; ioctls operate on a set of + formats parameters that are not connected to the hardware configuration. + Modifying those 'try' formats leaves the device state untouched (this + applies to both the software state stored in the driver and the hardware + state stored in the device itself). + + While not kept as part of the device state, try formats are stored + in the sub-device file handles. A &VIDIOC-SUBDEV-G-FMT; call will return + the last try format set on the same sub-device file + handle. Several applications querying the same sub-device at + the same time will thus not interact with each other. + + To find out whether a particular format is supported by the device, + applications use the &VIDIOC-SUBDEV-S-FMT; ioctl. Drivers verify and, if + needed, change the requested format based on + device requirements and return the possibly modified value. Applications + can then choose to try a different format or accept the returned value and + continue. + + Formats returned by the driver during a negotiation iteration are + guaranteed to be supported by the device. In particular, drivers guarantee + that a returned format will not be further changed if passed to an + &VIDIOC-SUBDEV-S-FMT; call as-is (as long as external parameters, such as + formats on other pads or links' configuration are not changed). + + Drivers automatically propagate formats inside sub-devices. When a + try or active format is set on a pad, corresponding formats on other pads + of the same sub-device can be modified by the driver. Drivers are free to + modify formats as required by the device. However, they should comply with + the following rules when possible: + + Formats should be propagated from sink pads to source pads. + Modifying a format on a source pad should not modify the format on any + sink pad. + Sub-devices that scale frames using variable scaling factors + should reset the scale factors to default values when sink pads formats + are modified. If the 1:1 scaling ratio is supported, this means that + source pads formats should be reset to the sink pads formats. + + + + Formats are not propagated across links, as that would involve + propagating them from one sub-device file handle to another. Applications + must then take care to configure both ends of every link explicitly with + compatible formats. Identical formats on the two ends of a link are + guaranteed to be compatible. Drivers are free to accept different formats + matching device requirements as being compatible. + + + shows a sample configuration sequence for the pipeline described in + (table + columns list entity names and pad numbers). + + + Sample Pipeline Configuration + + + + + + + + + + + Sensor/0 + Frontend/0 + Frontend/1 + Scaler/0 + Scaler/1 + + + + + Initial state + 2048x1536 + - + - + - + - + + + Configure frontend input + 2048x1536 + 2048x1536 + 2046x1534 + - + - + + + Configure scaler input + 2048x1536 + 2048x1536 + 2046x1534 + 2046x1534 + 2046x1534 + + + Configure scaler output + 2048x1536 + 2048x1536 + 2046x1534 + 2046x1534 + 1280x960 + + + +
+ + + + Initial state. The sensor output is set to its native 3MP + resolution. Resolutions on the host frontend and scaler input and output + pads are undefined. + The application configures the frontend input pad resolution to + 2048x1536. The driver propagates the format to the frontend output pad. + Note that the propagated output format can be different, as in this case, + than the input format, as the hardware might need to crop pixels (for + instance when converting a Bayer filter pattern to RGB or YUV). + The application configures the scaler input pad resolution to + 2046x1534 to match the frontend output resolution. The driver propagates + the format to the scaler output pad. + The application configures the scaler output pad resolution to + 1280x960. + + + + When satisfied with the try results, applications can set the active + formats by setting the which argument to + V4L2_SUBDEV_FORMAT_ACTIVE. Active formats are changed + exactly as try formats by drivers. To avoid modifying the hardware state + during format negotiation, applications should negotiate try formats first + and then modify the active settings using the try formats returned during + the last negotiation iteration. This guarantees that the active format + will be applied as-is by the driver without being modified. + +
+ +
+ Selections: cropping, scaling and composition + + Many sub-devices support cropping frames on their input or output + pads (or possible even on both). Cropping is used to select the area of + interest in an image, typically on an image sensor or a video decoder. It can + also be used as part of digital zoom implementations to select the area of + the image that will be scaled up. + + Crop settings are defined by a crop rectangle and represented in a + &v4l2-rect; by the coordinates of the top left corner and the rectangle + size. Both the coordinates and sizes are expressed in pixels. + + As for pad formats, drivers store try and active + rectangles for the selection targets . + + On sink pads, cropping is applied relative to the + current pad format. The pad format represents the image size as + received by the sub-device from the previous block in the + pipeline, and the crop rectangle represents the sub-image that + will be transmitted further inside the sub-device for + processing. + + The scaling operation changes the size of the image by + scaling it to new dimensions. The scaling ratio isn't specified + explicitly, but is implied from the original and scaled image + sizes. Both sizes are represented by &v4l2-rect;. + + Scaling support is optional. When supported by a subdev, + the crop rectangle on the subdev's sink pad is scaled to the + size configured using the &VIDIOC-SUBDEV-S-SELECTION; IOCTL + using V4L2_SEL_TGT_COMPOSE + selection target on the same pad. If the subdev supports scaling + but not composing, the top and left values are not used and must + always be set to zero. + + On source pads, cropping is similar to sink pads, with the + exception that the source size from which the cropping is + performed, is the COMPOSE rectangle on the sink pad. In both + sink and source pads, the crop rectangle must be entirely + contained inside the source image size for the crop + operation. + + The drivers should always use the closest possible + rectangle the user requests on all selection targets, unless + specifically told otherwise. + V4L2_SEL_FLAG_GE and + V4L2_SEL_FLAG_LE flags may be + used to round the image size either up or down. +
+ +
+ Types of selection targets + +
+ Actual targets + + Actual targets (without a postfix) reflect the actual + hardware configuration at any point of time. There is a BOUNDS + target corresponding to every actual target. +
+ +
+ BOUNDS targets + + BOUNDS targets is the smallest rectangle that contains all + valid actual rectangles. It may not be possible to set the actual + rectangle as large as the BOUNDS rectangle, however. This may be + because e.g. a sensor's pixel array is not rectangular but + cross-shaped or round. The maximum size may also be smaller than the + BOUNDS rectangle. +
+ +
+ +
+ Order of configuration and format propagation + + Inside subdevs, the order of image processing steps will + always be from the sink pad towards the source pad. This is also + reflected in the order in which the configuration must be + performed by the user: the changes made will be propagated to + any subsequent stages. If this behaviour is not desired, the + user must set + V4L2_SEL_FLAG_KEEP_CONFIG flag. This + flag causes no propagation of the changes are allowed in any + circumstances. This may also cause the accessed rectangle to be + adjusted by the driver, depending on the properties of the + underlying hardware. + + The coordinates to a step always refer to the actual size + of the previous step. The exception to this rule is the source + compose rectangle, which refers to the sink compose bounds + rectangle --- if it is supported by the hardware. + + + Sink pad format. The user configures the sink pad + format. This format defines the parameters of the image the + entity receives through the pad for further processing. + + Sink pad actual crop selection. The sink pad crop + defines the crop performed to the sink pad format. + + Sink pad actual compose selection. The size of the + sink pad compose rectangle defines the scaling ratio compared + to the size of the sink pad crop rectangle. The location of + the compose rectangle specifies the location of the actual + sink compose rectangle in the sink compose bounds + rectangle. + + Source pad actual crop selection. Crop on the source + pad defines crop performed to the image in the sink compose + bounds rectangle. + + Source pad format. The source pad format defines the + output pixel format of the subdev, as well as the other + parameters with the exception of the image width and height. + Width and height are defined by the size of the source pad + actual crop selection. + + + Accessing any of the above rectangles not supported by the + subdev will return EINVAL. Any rectangle + referring to a previous unsupported rectangle coordinates will + instead refer to the previous supported rectangle. For example, + if sink crop is not supported, the compose selection will refer + to the sink pad format dimensions instead. + +
+ Image processing in subdevs: simple crop example + + + + + +
+ + In the above example, the subdev supports cropping on its + sink pad. To configure it, the user sets the media bus format on + the subdev's sink pad. Now the actual crop rectangle can be set + on the sink pad --- the location and size of this rectangle + reflect the location and size of a rectangle to be cropped from + the sink format. The size of the sink crop rectangle will also + be the size of the format of the subdev's source pad. + +
+ Image processing in subdevs: scaling with multiple sources + + + + + +
+ + In this example, the subdev is capable of first cropping, + then scaling and finally cropping for two source pads + individually from the resulting scaled image. The location of + the scaled image in the cropped image is ignored in sink compose + target. Both of the locations of the source crop rectangles + refer to the sink scaling rectangle, independently cropping an + area at location specified by the source crop rectangle from + it. + +
+ Image processing in subdevs: scaling and composition + with multiple sinks and sources + + + + + +
+ + The subdev driver supports two sink pads and two source + pads. The images from both of the sink pads are individually + cropped, then scaled and further composed on the composition + bounds rectangle. From that, two independent streams are cropped + and sent out of the subdev from the source pads. + +
+ +
+ + &sub-subdev-formats; diff --git a/Documentation/DocBook/media/v4l/dev-teletext.xml b/Documentation/DocBook/media/v4l/dev-teletext.xml new file mode 100644 index 00000000..bd21c64d --- /dev/null +++ b/Documentation/DocBook/media/v4l/dev-teletext.xml @@ -0,0 +1,29 @@ + Teletext Interface + + This interface was aimed at devices receiving and demodulating +Teletext data [, ], evaluating the +Teletext packages and storing formatted pages in cache memory. Such +devices are usually implemented as microcontrollers with serial +interface (I2C) and could be found on old +TV cards, dedicated Teletext decoding cards and home-brew devices +connected to the PC parallel port. + + The Teletext API was designed by Martin Buck. It was defined in +the kernel header file linux/videotext.h, the +specification is available from +ftp://ftp.gwdg.de/pub/linux/misc/videotext/. (Videotext is the name of +the German public television Teletext service.) + + Eventually the Teletext API was integrated into the V4L API +with character device file names /dev/vtx0 to +/dev/vtx31, device major number 81, minor numbers +192 to 223. + + However, teletext decoders were quickly replaced by more +generic VBI demodulators and those dedicated teletext decoders no longer exist. +For many years the vtx devices were still around, even though nobody used +them. So the decision was made to finally remove support for the Teletext API in +kernel 2.6.37. + + Modern devices all use the raw or +sliced VBI API. diff --git a/Documentation/DocBook/media/v4l/driver.xml b/Documentation/DocBook/media/v4l/driver.xml new file mode 100644 index 00000000..7c6638ba --- /dev/null +++ b/Documentation/DocBook/media/v4l/driver.xml @@ -0,0 +1,200 @@ + V4L2 Driver Programming + + + + to do + diff --git a/Documentation/DocBook/media/v4l/fdl-appendix.xml b/Documentation/DocBook/media/v4l/fdl-appendix.xml new file mode 100644 index 00000000..ae22394b --- /dev/null +++ b/Documentation/DocBook/media/v4l/fdl-appendix.xml @@ -0,0 +1,671 @@ + + + + + + Version 1.1, March 2000 + + + 2000Free Software Foundation, Inc. + + + +
Free Software Foundation, Inc. 59 Temple Place, + Suite 330, Boston, MA + 02111-1307 USA
+ Everyone is permitted to copy and distribute verbatim copies of this + license document, but changing it is not allowed. + + + + GNU Free Documentation License + + + 0. PREAMBLE + + The purpose of this License is to make a manual, textbook, or + other written document free in the sense of + freedom: to assure everyone the effective freedom to copy and + redistribute it, with or without modifying it, either + commercially or noncommercially. Secondarily, this License + preserves for the author and publisher a way to get credit for + their work, while not being considered responsible for + modifications made by others. + + + + This License is a kind of copyleft, which means + that derivative works of the document must themselves be free in + the same sense. It complements the GNU General Public License, + which is a copyleft license designed for free software. + + + + We have designed this License in order to use it for manuals for + free software, because free software needs free documentation: a + free program should come with manuals providing the same + freedoms that the software does. But this License is not limited + to software manuals; it can be used for any textual work, + regardless of subject matter or whether it is published as a + printed book. We recommend this License principally for works + whose purpose is instruction or reference. + + + + 1. APPLICABILITY AND DEFINITIONS + + This License applies to any manual or other work that contains a + notice placed by the copyright holder saying it can be + distributed under the terms of this License. The + Document, below, refers to any such manual or + work. Any member of the public is a licensee, and is addressed + as you. + + + + A Modified Version of the Document means any work + containing the Document or a portion of it, either copied + verbatim, or with modifications and/or translated into another + language. + + + + A Secondary Section is a named appendix or a + front-matter section of the Document that deals exclusively + with the relationship of the publishers or authors of the + Document to the Document's overall subject (or to related + matters) and contains nothing that could fall directly within + that overall subject. (For example, if the Document is in part a + textbook of mathematics, a Secondary Section may not explain any + mathematics.) The relationship could be a matter of historical + connection with the subject or with related matters, or of + legal, commercial, philosophical, ethical or political position + regarding them. + + + + The Invariant Sections are certain Secondary Sections whose titles + are designated, as being those of Invariant Sections, in the + notice that says that the Document is released under this + License. + + + + The Cover Texts are certain short passages of + text that are listed, as Front-Cover Texts or Back-Cover Texts, + in the notice that says that the Document is released under this + License. + + + + A Transparent copy of the Document means a machine-readable + copy, represented in a format whose specification is available + to the general public, whose contents can be viewed and edited + directly and straightforwardly with generic text editors or (for + images composed of pixels) generic paint programs or (for + drawings) some widely available drawing editor, and that is + suitable for input to text formatters or for automatic + translation to a variety of formats suitable for input to text + formatters. A copy made in an otherwise Transparent file format + whose markup has been designed to thwart or discourage + subsequent modification by readers is not Transparent. A copy + that is not Transparent is called + Opaque. + + + + Examples of suitable formats for Transparent copies include + plain ASCII without markup, Texinfo input format, LaTeX input + format, SGML or XML using a publicly available DTD, and + standard-conforming simple HTML designed for human + modification. Opaque formats include PostScript, PDF, + proprietary formats that can be read and edited only by + proprietary word processors, SGML or XML for which the DTD + and/or processing tools are not generally available, and the + machine-generated HTML produced by some word processors for + output purposes only. + + + + The Title Page means, for a printed book, the + title page itself, plus such following pages as are needed to + hold, legibly, the material this License requires to appear in + the title page. For works in formats which do not have any title + page as such, Title Page means the text near the + most prominent appearance of the work's title, preceding the + beginning of the body of the text. + + + + + 2. VERBATIM COPYING + + You may copy and distribute the Document in any medium, either + commercially or noncommercially, provided that this License, the + copyright notices, and the license notice saying this License + applies to the Document are reproduced in all copies, and that + you add no other conditions whatsoever to those of this + License. You may not use technical measures to obstruct or + control the reading or further copying of the copies you make or + distribute. However, you may accept compensation in exchange for + copies. If you distribute a large enough number of copies you + must also follow the conditions in section 3. + + + + You may also lend copies, under the same conditions stated + above, and you may publicly display copies. + + + + + 3. COPYING IN QUANTITY + + If you publish printed copies of the Document numbering more than 100, + and the Document's license notice requires Cover Texts, you must enclose + the copies in covers that carry, clearly and legibly, all these + Cover Texts: Front-Cover Texts on the front cover, and + Back-Cover Texts on the back cover. Both covers must also + clearly and legibly identify you as the publisher of these + copies. The front cover must present the full title with all + words of the title equally prominent and visible. You may add + other material on the covers in addition. Copying with changes + limited to the covers, as long as they preserve the title of the + Document and satisfy these + conditions, can be treated as verbatim copying in other + respects. + + + + If the required texts for either cover are too voluminous to fit + legibly, you should put the first ones listed (as many as fit + reasonably) on the actual cover, and continue the rest onto + adjacent pages. + + + + If you publish or distribute Opaque copies of the Document numbering more than 100, + you must either include a machine-readable Transparent copy along with + each Opaque copy, or state in or with each Opaque copy a + publicly-accessible computer-network location containing a + complete Transparent copy of the Document, free of added + material, which the general network-using public has access to + download anonymously at no charge using public-standard network + protocols. If you use the latter option, you must take + reasonably prudent steps, when you begin distribution of Opaque + copies in quantity, to ensure that this Transparent copy will + remain thus accessible at the stated location until at least one + year after the last time you distribute an Opaque copy (directly + or through your agents or retailers) of that edition to the + public. + + + + It is requested, but not required, that you contact the authors + of the Document well before + redistributing any large number of copies, to give them a chance + to provide you with an updated version of the Document. + + + + + 4. MODIFICATIONS + + You may copy and distribute a Modified Version of the Document under the conditions of + sections 2 and 3 above, provided that you release + the Modified Version under precisely this License, with the + Modified Version filling the role of the Document, thus + licensing distribution and modification of the Modified Version + to whoever possesses a copy of it. In addition, you must do + these things in the Modified Version: + + + + + + A + + Use in the Title + Page (and on the covers, if any) a title distinct + from that of the Document, and from those of + previous versions (which should, if there were any, be + listed in the History section of the Document). You may + use the same title as a previous version if the original + publisher of that version gives permission. + + + + + + + B + + List on the Title + Page, as authors, one or more persons or entities + responsible for authorship of the modifications in the + Modified Version, + together with at least five of the principal authors of + the Document (all of + its principal authors, if it has less than five). + + + + + + + C + + State on the Title + Page the name of the publisher of the Modified Version, as the + publisher. + + + + + + + D + + Preserve all the copyright notices of the Document. + + + + + + + E + + Add an appropriate copyright notice for your modifications + adjacent to the other copyright notices. + + + + + + + F + + Include, immediately after the copyright notices, a + license notice giving the public permission to use the + Modified Version under + the terms of this License, in the form shown in the + Addendum below. + + + + + + + G + + Preserve in that license notice the full lists of Invariant Sections and + required Cover + Texts given in the Document's license notice. + + + + + + + H + + Include an unaltered copy of this License. + + + + + + + I + + Preserve the section entitled History, and + its title, and add to it an item stating at least the + title, year, new authors, and publisher of the Modified Version as given on + the Title Page. If + there is no section entitled History in the + Document, create one + stating the title, year, authors, and publisher of the + Document as given on its Title Page, then add an item + describing the Modified Version as stated in the previous + sentence. + + + + + + + J + + Preserve the network location, if any, given in the Document for public access + to a Transparent + copy of the Document, and likewise the network locations + given in the Document for previous versions it was based + on. These may be placed in the History + section. You may omit a network location for a work that + was published at least four years before the Document + itself, or if the original publisher of the version it + refers to gives permission. + + + + + + + K + + In any section entitled Acknowledgements or + Dedications, preserve the section's title, + and preserve in the section all the substance and tone of + each of the contributor acknowledgements and/or + dedications given therein. + + + + + + + L + + Preserve all the Invariant + Sections of the Document, unaltered in their + text and in their titles. Section numbers or the + equivalent are not considered part of the section titles. + + + + + + + M + + Delete any section entitled + Endorsements. Such a section may not be + included in the Modified + Version. + + + + + + + N + + Do not retitle any existing section as + Endorsements or to conflict in title with + any Invariant + Section. + + + + + + + If the Modified Version + includes new front-matter sections or appendices that qualify as + Secondary Sections and + contain no material copied from the Document, you may at your + option designate some or all of these sections as invariant. To + do this, add their titles to the list of Invariant Sections in the + Modified Version's license notice. These titles must be + distinct from any other section titles. + + + + You may add a section entitled Endorsements, + provided it contains nothing but endorsements of your Modified Version by various + parties--for example, statements of peer review or that the text + has been approved by an organization as the authoritative + definition of a standard. + + + + You may add a passage of up to five words as a Front-Cover Text, and a passage + of up to 25 words as a Back-Cover Text, to the end of + the list of Cover Texts + in the Modified Version. + Only one passage of Front-Cover Text and one of Back-Cover Text + may be added by (or through arrangements made by) any one + entity. If the Document + already includes a cover text for the same cover, previously + added by you or by arrangement made by the same entity you are + acting on behalf of, you may not add another; but you may + replace the old one, on explicit permission from the previous + publisher that added the old one. + + + + The author(s) and publisher(s) of the Document do not by this License + give permission to use their names for publicity for or to + assert or imply endorsement of any Modified Version . + + + + + 5. COMBINING DOCUMENTS + + You may combine the Document + with other documents released under this License, under the + terms defined in section 4 + above for modified versions, provided that you include in the + combination all of the Invariant + Sections of all of the original documents, unmodified, + and list them all as Invariant Sections of your combined work in + its license notice. + + + + The combined work need only contain one copy of this License, + and multiple identical Invariant + Sections may be replaced with a single copy. If there are + multiple Invariant Sections with the same name but different + contents, make the title of each such section unique by adding + at the end of it, in parentheses, the name of the original + author or publisher of that section if known, or else a unique + number. Make the same adjustment to the section titles in the + list of Invariant Sections in the license notice of the combined + work. + + + + In the combination, you must combine any sections entitled + History in the various original documents, + forming one section entitled History; likewise + combine any sections entitled Acknowledgements, + and any sections entitled Dedications. You must + delete all sections entitled Endorsements. + + + + + 6. COLLECTIONS OF DOCUMENTS + + You may make a collection consisting of the Document and other documents + released under this License, and replace the individual copies + of this License in the various documents with a single copy that + is included in the collection, provided that you follow the + rules of this License for verbatim copying of each of the + documents in all other respects. + + + + You may extract a single document from such a collection, and + dispbibute it individually under this License, provided you + insert a copy of this License into the extracted document, and + follow this License in all other respects regarding verbatim + copying of that document. + + + + + 7. AGGREGATION WITH INDEPENDENT WORKS + + A compilation of the Document or its derivatives with + other separate and independent documents or works, in or on a + volume of a storage or distribution medium, does not as a whole + count as a Modified Version + of the Document, provided no compilation copyright is claimed + for the compilation. Such a compilation is called an + aggregate, and this License does not apply to the + other self-contained works thus compiled with the Document , on + account of their being thus compiled, if they are not themselves + derivative works of the Document. If the Cover Text requirement of section 3 is applicable to these + copies of the Document, then if the Document is less than one + quarter of the entire aggregate, the Document's Cover Texts may + be placed on covers that surround only the Document within the + aggregate. Otherwise they must appear on covers around the whole + aggregate. + + + + + 8. TRANSLATION + + Translation is considered a kind of modification, so you may + distribute translations of the Document under the terms of section 4. Replacing Invariant Sections with + translations requires special permission from their copyright + holders, but you may include translations of some or all + Invariant Sections in addition to the original versions of these + Invariant Sections. You may include a translation of this + License provided that you also include the original English + version of this License. In case of a disagreement between the + translation and the original English version of this License, + the original English version will prevail. + + + + + 9. TERMINATION + + You may not copy, modify, sublicense, or distribute the Document except as expressly + provided for under this License. Any other attempt to copy, + modify, sublicense or distribute the Document is void, and will + automatically terminate your rights under this License. However, + parties who have received copies, or rights, from you under this + License will not have their licenses terminated so long as such + parties remain in full compliance. + + + + + 10. FUTURE REVISIONS OF THIS LICENSE + + The Free Software + Foundation may publish new, revised versions of the GNU + Free Documentation License from time to time. Such new versions + will be similar in spirit to the present version, but may differ + in detail to address new problems or concerns. See http://www.gnu.org/copyleft/. + + + + Each version of the License is given a distinguishing version + number. If the Document + specifies that a particular numbered version of this License + or any later version applies to it, you have the + option of following the terms and conditions either of that + specified version or of any later version that has been + published (not as a draft) by the Free Software Foundation. If + the Document does not specify a version number of this License, + you may choose any version ever published (not as a draft) by + the Free Software Foundation. + + + + + Addendum + + To use this License in a document you have written, include a copy of + the License in the document and put the following copyright and + license notices just after the title page: + + +
+ + Copyright © YEAR YOUR NAME. + + + Permission is granted to copy, distribute and/or modify this + document under the terms of the GNU Free Documentation + License, Version 1.1 or any later version published by the + Free Software Foundation; with the Invariant Sections being LIST + THEIR TITLES, with the Front-Cover Texts being LIST, + and with the Back-Cover + Texts being LIST. A copy of the license is included in + the section entitled GNU Free Documentation + License. + +
+ + + If you have no Invariant + Sections, write with no Invariant Sections + instead of saying which ones are invariant. If you have no + Front-Cover Texts, write + no Front-Cover Texts instead of + Front-Cover Texts being LIST; likewise for Back-Cover Texts. + + + + If your document contains nontrivial examples of program code, + we recommend releasing these examples in parallel under your + choice of free software license, such as the GNU General Public + License, to permit their use in free software. + + + + + + + + + diff --git a/Documentation/DocBook/media/v4l/fieldseq_bt.pdf b/Documentation/DocBook/media/v4l/fieldseq_bt.pdf new file mode 100644 index 00000000..26598b23 Binary files /dev/null and b/Documentation/DocBook/media/v4l/fieldseq_bt.pdf differ diff --git a/Documentation/DocBook/media/v4l/fieldseq_tb.pdf b/Documentation/DocBook/media/v4l/fieldseq_tb.pdf new file mode 100644 index 00000000..4965b22d Binary files /dev/null and b/Documentation/DocBook/media/v4l/fieldseq_tb.pdf differ diff --git a/Documentation/DocBook/media/v4l/func-close.xml b/Documentation/DocBook/media/v4l/func-close.xml new file mode 100644 index 00000000..232920d2 --- /dev/null +++ b/Documentation/DocBook/media/v4l/func-close.xml @@ -0,0 +1,62 @@ + + + V4L2 close() + &manvol; + + + + v4l2-close + Close a V4L2 device + + + + + #include <unistd.h> + + int close + int fd + + + + + + Arguments + + + + fd + + &fd; + + + + + + + Description + + Closes the device. Any I/O in progress is terminated and +resources associated with the file descriptor are freed. However data +format parameters, current input or output, control values or other +properties remain unchanged. + + + + Return Value + + The function returns 0 on +success, -1 on failure and the +errno is set appropriately. Possible error +codes: + + + + EBADF + + fd is not a valid open file +descriptor. + + + + + diff --git a/Documentation/DocBook/media/v4l/func-ioctl.xml b/Documentation/DocBook/media/v4l/func-ioctl.xml new file mode 100644 index 00000000..4394184a --- /dev/null +++ b/Documentation/DocBook/media/v4l/func-ioctl.xml @@ -0,0 +1,71 @@ + + + V4L2 ioctl() + &manvol; + + + + v4l2-ioctl + Program a V4L2 device + + + + + #include <sys/ioctl.h> + + int ioctl + int fd + int request + void *argp + + + + + + Arguments + + + + fd + + &fd; + + + + request + + V4L2 ioctl request code as defined in the videodev2.h header file, for example +VIDIOC_QUERYCAP. + + + + argp + + Pointer to a function parameter, usually a structure. + + + + + + + Description + + The ioctl() function is used to program +V4L2 devices. The argument fd must be an open +file descriptor. An ioctl request has encoded +in it whether the argument is an input, output or read/write +parameter, and the size of the argument argp in +bytes. Macros and defines specifying V4L2 ioctl requests are located +in the videodev2.h header file. +Applications should use their own copy, not include the version in the +kernel sources on the system they compile on. All V4L2 ioctl requests, +their respective function and parameters are specified in . + + + + &return-value; + When an ioctl that takes an output or read/write parameter fails, + the parameter remains unmodified. + + diff --git a/Documentation/DocBook/media/v4l/func-mmap.xml b/Documentation/DocBook/media/v4l/func-mmap.xml new file mode 100644 index 00000000..f31ad71b --- /dev/null +++ b/Documentation/DocBook/media/v4l/func-mmap.xml @@ -0,0 +1,183 @@ + + + V4L2 mmap() + &manvol; + + + + v4l2-mmap + Map device memory into application address space + + + + + +#include <unistd.h> +#include <sys/mman.h> + + void *mmap + void *start + size_t length + int prot + int flags + int fd + off_t offset + + + + + + Arguments + + + start + + Map the buffer to this address in the +application's address space. When the MAP_FIXED +flag is specified, start must be a multiple of the +pagesize and mmap will fail when the specified address +cannot be used. Use of this option is discouraged; applications should +just specify a NULL pointer here. + + + + length + + Length of the memory area to map. This must be the +same value as returned by the driver in the &v4l2-buffer; +length field for the +single-planar API, and the same value as returned by the driver +in the &v4l2-plane; length field for the +multi-planar API. + + + + prot + + The prot argument describes the +desired memory protection. Regardless of the device type and the +direction of data exchange it should be set to +PROT_READ | PROT_WRITE, +permitting read and write access to image buffers. Drivers should +support at least this combination of flags. Note the Linux +video-buf kernel module, which is used by the +bttv, saa7134, saa7146, cx88 and vivi driver supports only +PROT_READ | PROT_WRITE. When +the driver does not support the desired protection the +mmap() function fails. + Note device memory accesses (⪚ the memory on a +graphics card with video capturing hardware) may incur a performance +penalty compared to main memory accesses, or reads may be +significantly slower than writes or vice versa. Other I/O methods may +be more efficient in this case. + + + + flags + + The flags parameter +specifies the type of the mapped object, mapping options and whether +modifications made to the mapped copy of the page are private to the +process or are to be shared with other references. + MAP_FIXED requests that the +driver selects no other address than the one specified. If the +specified address cannot be used, mmap() will fail. If +MAP_FIXED is specified, +start must be a multiple of the pagesize. Use +of this option is discouraged. + One of the MAP_SHARED or +MAP_PRIVATE flags must be set. +MAP_SHARED allows applications to share the +mapped memory with other (⪚ child-) processes. Note the Linux +video-buf module which is used by the bttv, +saa7134, saa7146, cx88 and vivi driver supports only +MAP_SHARED. MAP_PRIVATE +requests copy-on-write semantics. V4L2 applications should not set the +MAP_PRIVATE, MAP_DENYWRITE, +MAP_EXECUTABLE or MAP_ANON +flag. + + + + fd + + &fd; + + + + offset + + Offset of the buffer in device memory. This must be the +same value as returned by the driver in the &v4l2-buffer; +m union offset field for +the single-planar API, and the same value as returned by the driver +in the &v4l2-plane; m union +mem_offset field for the multi-planar API. + + + + + + + Description + + The mmap() function asks to map +length bytes starting at +offset in the memory of the device specified by +fd into the application address space, +preferably at address start. This latter +address is a hint only, and is usually specified as 0. + + Suitable length and offset parameters are queried with the +&VIDIOC-QUERYBUF; ioctl. Buffers must be allocated with the +&VIDIOC-REQBUFS; ioctl before they can be queried. + + To unmap buffers the &func-munmap; function is used. + + + + Return Value + + On success mmap() returns a pointer to +the mapped buffer. On error MAP_FAILED (-1) is +returned, and the errno variable is set +appropriately. Possible error codes are: + + + + EBADF + + fd is not a valid file +descriptor. + + + + EACCES + + fd is +not open for reading and writing. + + + + EINVAL + + The start or +length or offset are not +suitable. (E. g. they are too large, or not aligned on a +PAGESIZE boundary.) + The flags or +prot value is not supported. + No buffers have been allocated with the +&VIDIOC-REQBUFS; ioctl. + + + + ENOMEM + + Not enough physical or virtual memory was available to +complete the request. + + + + + diff --git a/Documentation/DocBook/media/v4l/func-munmap.xml b/Documentation/DocBook/media/v4l/func-munmap.xml new file mode 100644 index 00000000..860d49ca --- /dev/null +++ b/Documentation/DocBook/media/v4l/func-munmap.xml @@ -0,0 +1,76 @@ + + + V4L2 munmap() + &manvol; + + + + v4l2-munmap + Unmap device memory + + + + + +#include <unistd.h> +#include <sys/mman.h> + + int munmap + void *start + size_t length + + + + + Arguments + + + start + + Address of the mapped buffer as returned by the +&func-mmap; function. + + + + length + + Length of the mapped buffer. This must be the same +value as given to mmap() and returned by the +driver in the &v4l2-buffer; length +field for the single-planar API and in the &v4l2-plane; +length field for the multi-planar API. + + + + + + + Description + + Unmaps a previously with the &func-mmap; function mapped +buffer and frees it, if possible. + + + + Return Value + + On success munmap() returns 0, on +failure -1 and the errno variable is set +appropriately: + + + + EINVAL + + The start or +length is incorrect, or no buffers have been +mapped yet. + + + + + diff --git a/Documentation/DocBook/media/v4l/func-open.xml b/Documentation/DocBook/media/v4l/func-open.xml new file mode 100644 index 00000000..cf64e207 --- /dev/null +++ b/Documentation/DocBook/media/v4l/func-open.xml @@ -0,0 +1,113 @@ + + + V4L2 open() + &manvol; + + + + v4l2-open + Open a V4L2 device + + + + + #include <fcntl.h> + + int open + const char *device_name + int flags + + + + + + Arguments + + + + device_name + + Device to be opened. + + + + flags + + Open flags. Access mode must be +O_RDWR. This is just a technicality, input devices +still support only reading and output devices only writing. + When the O_NONBLOCK flag is +given, the read() function and the &VIDIOC-DQBUF; ioctl will return +the &EAGAIN; when no data is available or no buffer is in the driver +outgoing queue, otherwise these functions block until data becomes +available. All V4L2 drivers exchanging data with applications must +support the O_NONBLOCK flag. + Other flags have no effect. + + + + + + Description + + To open a V4L2 device applications call +open() with the desired device name. This +function has no side effects; all data format parameters, current +input or output, control values or other properties remain unchanged. +At the first open() call after loading the driver +they will be reset to default values, drivers are never in an +undefined state. + + + Return Value + + On success open returns the new file +descriptor. On error -1 is returned, and the errno +variable is set appropriately. Possible error codes are: + + + + EACCES + + The caller has no permission to access the +device. + + + + EBUSY + + The driver does not support multiple opens and the +device is already in use. + + + + ENXIO + + No device corresponding to this device special file +exists. + + + + ENOMEM + + Not enough kernel memory was available to complete the +request. + + + + EMFILE + + The process already has the maximum number of +files open. + + + + ENFILE + + The limit on the total number of files open on the +system has been reached. + + + + + diff --git a/Documentation/DocBook/media/v4l/func-poll.xml b/Documentation/DocBook/media/v4l/func-poll.xml new file mode 100644 index 00000000..85cad8bf --- /dev/null +++ b/Documentation/DocBook/media/v4l/func-poll.xml @@ -0,0 +1,119 @@ + + + V4L2 poll() + &manvol; + + + + v4l2-poll + Wait for some event on a file descriptor + + + + + #include <sys/poll.h> + + int poll + struct pollfd *ufds + unsigned int nfds + int timeout + + + + + + Description + + With the poll() function applications +can suspend execution until the driver has captured data or is ready +to accept data for output. + + When streaming I/O has been negotiated this function waits +until a buffer has been filled or displayed and can be dequeued with +the &VIDIOC-DQBUF; ioctl. When buffers are already in the outgoing +queue of the driver the function returns immediately. + + On success poll() returns the number of +file descriptors that have been selected (that is, file descriptors +for which the revents field of the +respective pollfd structure is non-zero). +Capture devices set the POLLIN and +POLLRDNORM flags in the +revents field, output devices the +POLLOUT and POLLWRNORM +flags. When the function timed out it returns a value of zero, on +failure it returns -1 and the +errno variable is set appropriately. When the +application did not call &VIDIOC-QBUF; or &VIDIOC-STREAMON; yet the +poll() function succeeds, but sets the +POLLERR flag in the +revents field. + + When use of the read() function has +been negotiated and the driver does not capture yet, the +poll function starts capturing. When that fails +it returns a POLLERR as above. Otherwise it waits +until data has been captured and can be read. When the driver captures +continuously (as opposed to, for example, still images) the function +may return immediately. + + When use of the write() function has +been negotiated the poll function just waits +until the driver is ready for a non-blocking +write() call. + + All drivers implementing the read() or +write() function or streaming I/O must also +support the poll() function. + + For more details see the +poll() manual page. + + + + Return Value + + On success, poll() returns the number +structures which have non-zero revents +fields, or zero if the call timed out. On error +-1 is returned, and the +errno variable is set appropriately: + + + + EBADF + + One or more of the ufds members +specify an invalid file descriptor. + + + + EBUSY + + The driver does not support multiple read or write +streams and the device is already in use. + + + + EFAULT + + ufds references an inaccessible +memory area. + + + + EINTR + + The call was interrupted by a signal. + + + + EINVAL + + The nfds argument is greater +than OPEN_MAX. + + + + + diff --git a/Documentation/DocBook/media/v4l/func-read.xml b/Documentation/DocBook/media/v4l/func-read.xml new file mode 100644 index 00000000..e218bbfb --- /dev/null +++ b/Documentation/DocBook/media/v4l/func-read.xml @@ -0,0 +1,181 @@ + + + V4L2 read() + &manvol; + + + + v4l2-read + Read from a V4L2 device + + + + + #include <unistd.h> + + ssize_t read + int fd + void *buf + size_t count + + + + + + Arguments + + + + fd + + &fd; + + + + buf + + + + + + count + + + + + + + + + Description + + read() attempts to read up to +count bytes from file descriptor +fd into the buffer starting at +buf. The layout of the data in the buffer is +discussed in the respective device interface section, see ##. If count is zero, +read() returns zero and has no other results. If +count is greater than +SSIZE_MAX, the result is unspecified. Regardless +of the count value each +read() call will provide at most one frame (two +fields) worth of data. + + By default read() blocks until data +becomes available. When the O_NONBLOCK flag was +given to the &func-open; function it +returns immediately with an &EAGAIN; when no data is available. The +&func-select; or &func-poll; functions +can always be used to suspend execution until data becomes available. All +drivers supporting the read() function must also +support select() and +poll(). + + Drivers can implement read functionality in different +ways, using a single or multiple buffers and discarding the oldest or +newest frames once the internal buffers are filled. + + read() never returns a "snapshot" of a +buffer being filled. Using a single buffer the driver will stop +capturing when the application starts reading the buffer until the +read is finished. Thus only the period of the vertical blanking +interval is available for reading, or the capture rate must fall below +the nominal frame rate of the video standard. + +The behavior of +read() when called during the active picture +period or the vertical blanking separating the top and bottom field +depends on the discarding policy. A driver discarding the oldest +frames keeps capturing into an internal buffer, continuously +overwriting the previously, not read frame, and returns the frame +being received at the time of the read() call as +soon as it is complete. + + A driver discarding the newest frames stops capturing until +the next read() call. The frame being received at +read() time is discarded, returning the following +frame instead. Again this implies a reduction of the capture rate to +one half or less of the nominal frame rate. An example of this model +is the video read mode of the bttv driver, initiating a DMA to user +memory when read() is called and returning when +the DMA finished. + + In the multiple buffer model drivers maintain a ring of +internal buffers, automatically advancing to the next free buffer. +This allows continuous capturing when the application can empty the +buffers fast enough. Again, the behavior when the driver runs out of +free buffers depends on the discarding policy. + + Applications can get and set the number of buffers used +internally by the driver with the &VIDIOC-G-PARM; and &VIDIOC-S-PARM; +ioctls. They are optional, however. The discarding policy is not +reported and cannot be changed. For minimum requirements see . + + + + Return Value + + On success, the number of bytes read is returned. It is not +an error if this number is smaller than the number of bytes requested, +or the amount of data required for one frame. This may happen for +example because read() was interrupted by a +signal. On error, -1 is returned, and the errno +variable is set appropriately. In this case the next read will start +at the beginning of a new frame. Possible error codes are: + + + + EAGAIN + + Non-blocking I/O has been selected using +O_NONBLOCK and no data was immediately available for reading. + + + + EBADF + + fd is not a valid file +descriptor or is not open for reading, or the process already has the +maximum number of files open. + + + + EBUSY + + The driver does not support multiple read streams and the +device is already in use. + + + + EFAULT + + buf references an inaccessible +memory area. + + + + EINTR + + The call was interrupted by a signal before any +data was read. + + + + EIO + + I/O error. This indicates some hardware problem or a +failure to communicate with a remote device (USB camera etc.). + + + + EINVAL + + The read() function is not +supported by this driver, not on this device, or generally not on this +type of device. + + + + + diff --git a/Documentation/DocBook/media/v4l/func-select.xml b/Documentation/DocBook/media/v4l/func-select.xml new file mode 100644 index 00000000..e12a60d9 --- /dev/null +++ b/Documentation/DocBook/media/v4l/func-select.xml @@ -0,0 +1,130 @@ + + + V4L2 select() + &manvol; + + + + v4l2-select + Synchronous I/O multiplexing + + + + + +#include <sys/time.h> +#include <sys/types.h> +#include <unistd.h> + + int select + int nfds + fd_set *readfds + fd_set *writefds + fd_set *exceptfds + struct timeval *timeout + + + + + + Description + + With the select() function applications +can suspend execution until the driver has captured data or is ready +to accept data for output. + + When streaming I/O has been negotiated this function waits +until a buffer has been filled or displayed and can be dequeued with +the &VIDIOC-DQBUF; ioctl. When buffers are already in the outgoing +queue of the driver the function returns immediately. + + On success select() returns the total +number of bits set in the fd_sets. When the +function timed out it returns a value of zero. On failure it returns +-1 and the errno +variable is set appropriately. When the application did not call +&VIDIOC-QBUF; or &VIDIOC-STREAMON; yet the +select() function succeeds, setting the bit of +the file descriptor in readfds or +writefds, but subsequent &VIDIOC-DQBUF; calls +will fail.The Linux kernel implements +select() like the &func-poll; function, but +select() cannot return a +POLLERR. + + + When use of the read() function has +been negotiated and the driver does not capture yet, the +select() function starts capturing. When that +fails, select() returns successful and a +subsequent read() call, which also attempts to +start capturing, will return an appropriate error code. When the +driver captures continuously (as opposed to, for example, still +images) and data is already available the +select() function returns immediately. + + When use of the write() function has +been negotiated the select() function just waits +until the driver is ready for a non-blocking +write() call. + + All drivers implementing the read() or +write() function or streaming I/O must also +support the select() function. + + For more details see the select() +manual page. + + + + + Return Value + + On success, select() returns the number +of descriptors contained in the three returned descriptor sets, which +will be zero if the timeout expired. On error +-1 is returned, and the +errno variable is set appropriately; the sets and +timeout are undefined. Possible error codes +are: + + + + EBADF + + One or more of the file descriptor sets specified a +file descriptor that is not open. + + + + EBUSY + + The driver does not support multiple read or write +streams and the device is already in use. + + + + EFAULT + + The readfds, +writefds, exceptfds or +timeout pointer references an inaccessible memory +area. + + + + EINTR + + The call was interrupted by a signal. + + + + EINVAL + + The nfds argument is less than +zero or greater than FD_SETSIZE. + + + + + diff --git a/Documentation/DocBook/media/v4l/func-write.xml b/Documentation/DocBook/media/v4l/func-write.xml new file mode 100644 index 00000000..57520788 --- /dev/null +++ b/Documentation/DocBook/media/v4l/func-write.xml @@ -0,0 +1,128 @@ + + + V4L2 write() + &manvol; + + + + v4l2-write + Write to a V4L2 device + + + + + #include <unistd.h> + + ssize_t write + int fd + void *buf + size_t count + + + + + + Arguments + + + + fd + + &fd; + + + + buf + + + + + + count + + + + + + + + + Description + + write() writes up to +count bytes to the device referenced by the +file descriptor fd from the buffer starting at +buf. When the hardware outputs are not active +yet, this function enables them. When count is +zero, write() returns +0 without any other effect. + + When the application does not provide more data in time, the +previous video frame, raw VBI image, sliced VPS or WSS data is +displayed again. Sliced Teletext or Closed Caption data is not +repeated, the driver inserts a blank line instead. + + + + Return Value + + On success, the number of bytes written are returned. Zero +indicates nothing was written. On error, -1 +is returned, and the errno variable is set +appropriately. In this case the next write will start at the beginning +of a new frame. Possible error codes are: + + + + EAGAIN + + Non-blocking I/O has been selected using the O_NONBLOCK flag and no +buffer space was available to write the data immediately. + + + + EBADF + + fd is not a valid file +descriptor or is not open for writing. + + + + EBUSY + + The driver does not support multiple write streams and the +device is already in use. + + + + EFAULT + + buf references an inaccessible +memory area. + + + + EINTR + + The call was interrupted by a signal before any +data was written. + + + + EIO + + I/O error. This indicates some hardware problem. + + + + EINVAL + + The write() function is not +supported by this driver, not on this device, or generally not on this +type of device. + + + + + diff --git a/Documentation/DocBook/media/v4l/gen-errors.xml b/Documentation/DocBook/media/v4l/gen-errors.xml new file mode 100644 index 00000000..7e29a4e1 --- /dev/null +++ b/Documentation/DocBook/media/v4l/gen-errors.xml @@ -0,0 +1,77 @@ +Generic Error Codes + + + Generic error codes + + &cs-str; + + + + EAGAIN (aka EWOULDBLOCK) + The ioctl can't be handled because the device is in state where + it can't perform it. This could happen for example in case where + device is sleeping and ioctl is performed to query statistics. + It is also returned when the ioctl would need to wait + for an event, but the device was opened in non-blocking mode. + + + + EBADF + The file descriptor is not a valid. + + + EBUSY + The ioctl can't be handled because the device is busy. This is + typically return while device is streaming, and an ioctl tried to + change something that would affect the stream, or would require the + usage of a hardware resource that was already allocated. The ioctl + must not be retried without performing another action to fix the + problem first (typically: stop the stream before retrying). + + + EFAULT + There was a failure while copying data from/to userspace, + probably caused by an invalid pointer reference. + + + EINVAL + One or more of the ioctl parameters are invalid or out of the + allowed range. This is a widely used error code. See the individual + ioctl requests for specific causes. + + + ENODEV + Device not found or was removed. + + + ENOMEM + There's not enough memory to handle the desired operation. + + + ENOTTY + The ioctl is not supported by the driver, actually meaning that + the required functionality is not available, or the file + descriptor is not for a media device. + + + ENOSPC + On USB devices, the stream ioctl's can return this error, meaning + that this request would overcommit the usb bandwidth reserved + for periodic transfers (up to 80% of the USB bandwidth). + + + EPERM + Permission denied. Can be returned if the device needs write + permission, or some special capabilities is needed + (e. g. root) + + + +
+ +Note 1: ioctls may return other error codes. Since errors may have side +effects such as a driver reset, applications should abort on unexpected errors. + + +Note 2: Request-specific error codes are listed in the individual +requests descriptions. diff --git a/Documentation/DocBook/media/v4l/io.xml b/Documentation/DocBook/media/v4l/io.xml new file mode 100644 index 00000000..e6c58559 --- /dev/null +++ b/Documentation/DocBook/media/v4l/io.xml @@ -0,0 +1,1481 @@ + Input/Output + + The V4L2 API defines several different methods to read from or +write to a device. All drivers exchanging data with applications must +support at least one of them. + + The classic I/O method using the read() +and write() function is automatically selected +after opening a V4L2 device. When the driver does not support this +method attempts to read or write will fail at any time. + + Other methods must be negotiated. To select the streaming I/O +method with memory mapped or user buffers applications call the +&VIDIOC-REQBUFS; ioctl. The asynchronous I/O method is not defined +yet. + + Video overlay can be considered another I/O method, although +the application does not directly receive the image data. It is +selected by initiating video overlay with the &VIDIOC-S-FMT; ioctl. +For more information see . + + Generally exactly one I/O method, including overlay, is +associated with each file descriptor. The only exceptions are +applications not exchanging data with a driver ("panel applications", +see ) and drivers permitting simultaneous video capturing +and overlay using the same file descriptor, for compatibility with V4L +and earlier versions of V4L2. + + VIDIOC_S_FMT and +VIDIOC_REQBUFS would permit this to some degree, +but for simplicity drivers need not support switching the I/O method +(after first switching away from read/write) other than by closing +and reopening the device. + + The following sections describe the various I/O methods in +more detail. + +
+ Read/Write + + Input and output devices support the +read() and write() function, +respectively, when the V4L2_CAP_READWRITE flag in +the capabilities field of &v4l2-capability; +returned by the &VIDIOC-QUERYCAP; ioctl is set. + + Drivers may need the CPU to copy the data, but they may also +support DMA to or from user memory, so this I/O method is not +necessarily less efficient than other methods merely exchanging buffer +pointers. It is considered inferior though because no meta-information +like frame counters or timestamps are passed. This information is +necessary to recognize frame dropping and to synchronize with other +data streams. However this is also the simplest I/O method, requiring +little or no setup to exchange data. It permits command line stunts +like this (the vidctrl tool is +fictitious): + + + +> vidctrl /dev/video --input=0 --format=YUYV --size=352x288 +> dd if=/dev/video of=myimage.422 bs=202752 count=1 + + + + To read from the device applications use the +&func-read; function, to write the &func-write; function. +Drivers must implement one I/O method if they +exchange data with applications, but it need not be this. + It would be desirable if applications could depend on +drivers supporting all I/O interfaces, but as much as the complex +memory mapping I/O can be inadequate for some devices we have no +reason to require this interface, which is most useful for simple +applications capturing still images. + When reading or writing is supported, the driver +must also support the &func-select; and &func-poll; +function. + At the driver level select() and +poll() are the same, and +select() is too important to be optional. + +
+ +
+ Streaming I/O (Memory Mapping) + + Input and output devices support this I/O method when the +V4L2_CAP_STREAMING flag in the +capabilities field of &v4l2-capability; +returned by the &VIDIOC-QUERYCAP; ioctl is set. There are two +streaming methods, to determine if the memory mapping flavor is +supported applications must call the &VIDIOC-REQBUFS; ioctl. + + Streaming is an I/O method where only pointers to buffers +are exchanged between application and driver, the data itself is not +copied. Memory mapping is primarily intended to map buffers in device +memory into the application's address space. Device memory can be for +example the video memory on a graphics card with a video capture +add-on. However, being the most efficient I/O method available for a +long time, many other drivers support streaming as well, allocating +buffers in DMA-able main memory. + + A driver can support many sets of buffers. Each set is +identified by a unique buffer type value. The sets are independent and +each set can hold a different type of data. To access different sets +at the same time different file descriptors must be used. + One could use one file descriptor and set the buffer +type field accordingly when calling &VIDIOC-QBUF; etc., but it makes +the select() function ambiguous. We also like the +clean approach of one file descriptor per logical stream. Video +overlay for example is also a logical stream, although the CPU is not +needed for continuous operation. + + + To allocate device buffers applications call the +&VIDIOC-REQBUFS; ioctl with the desired number of buffers and buffer +type, for example V4L2_BUF_TYPE_VIDEO_CAPTURE. +This ioctl can also be used to change the number of buffers or to free +the allocated memory, provided none of the buffers are still +mapped. + + Before applications can access the buffers they must map +them into their address space with the &func-mmap; function. The +location of the buffers in device memory can be determined with the +&VIDIOC-QUERYBUF; ioctl. In the single-planar API case, the +m.offset and length +returned in a &v4l2-buffer; are passed as sixth and second parameter to the +mmap() function. When using the multi-planar API, +struct &v4l2-buffer; contains an array of &v4l2-plane; structures, each +containing its own m.offset and +length. When using the multi-planar API, every +plane of every buffer has to be mapped separately, so the number of +calls to &func-mmap; should be equal to number of buffers times number of +planes in each buffer. The offset and length values must not be modified. +Remember, the buffers are allocated in physical memory, as opposed to virtual +memory, which can be swapped out to disk. Applications should free the buffers +as soon as possible with the &func-munmap; function. + + + Mapping buffers in the single-planar API + +&v4l2-requestbuffers; reqbuf; +struct { + void *start; + size_t length; +} *buffers; +unsigned int i; + +memset(&reqbuf, 0, sizeof(reqbuf)); +reqbuf.type = V4L2_BUF_TYPE_VIDEO_CAPTURE; +reqbuf.memory = V4L2_MEMORY_MMAP; +reqbuf.count = 20; + +if (-1 == ioctl (fd, &VIDIOC-REQBUFS;, &reqbuf)) { + if (errno == EINVAL) + printf("Video capturing or mmap-streaming is not supported\n"); + else + perror("VIDIOC_REQBUFS"); + + exit(EXIT_FAILURE); +} + +/* We want at least five buffers. */ + +if (reqbuf.count < 5) { + /* You may need to free the buffers here. */ + printf("Not enough buffer memory\n"); + exit(EXIT_FAILURE); +} + +buffers = calloc(reqbuf.count, sizeof(*buffers)); +assert(buffers != NULL); + +for (i = 0; i < reqbuf.count; i++) { + &v4l2-buffer; buffer; + + memset(&buffer, 0, sizeof(buffer)); + buffer.type = reqbuf.type; + buffer.memory = V4L2_MEMORY_MMAP; + buffer.index = i; + + if (-1 == ioctl (fd, &VIDIOC-QUERYBUF;, &buffer)) { + perror("VIDIOC_QUERYBUF"); + exit(EXIT_FAILURE); + } + + buffers[i].length = buffer.length; /* remember for munmap() */ + + buffers[i].start = mmap(NULL, buffer.length, + PROT_READ | PROT_WRITE, /* recommended */ + MAP_SHARED, /* recommended */ + fd, buffer.m.offset); + + if (MAP_FAILED == buffers[i].start) { + /* If you do not exit here you should unmap() and free() + the buffers mapped so far. */ + perror("mmap"); + exit(EXIT_FAILURE); + } +} + +/* Cleanup. */ + +for (i = 0; i < reqbuf.count; i++) + munmap(buffers[i].start, buffers[i].length); + + + + + Mapping buffers in the multi-planar API + +&v4l2-requestbuffers; reqbuf; +/* Our current format uses 3 planes per buffer */ +#define FMT_NUM_PLANES = 3 + +struct { + void *start[FMT_NUM_PLANES]; + size_t length[FMT_NUM_PLANES]; +} *buffers; +unsigned int i, j; + +memset(&reqbuf, 0, sizeof(reqbuf)); +reqbuf.type = V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE; +reqbuf.memory = V4L2_MEMORY_MMAP; +reqbuf.count = 20; + +if (ioctl(fd, &VIDIOC-REQBUFS;, &reqbuf) < 0) { + if (errno == EINVAL) + printf("Video capturing or mmap-streaming is not supported\n"); + else + perror("VIDIOC_REQBUFS"); + + exit(EXIT_FAILURE); +} + +/* We want at least five buffers. */ + +if (reqbuf.count < 5) { + /* You may need to free the buffers here. */ + printf("Not enough buffer memory\n"); + exit(EXIT_FAILURE); +} + +buffers = calloc(reqbuf.count, sizeof(*buffers)); +assert(buffers != NULL); + +for (i = 0; i < reqbuf.count; i++) { + &v4l2-buffer; buffer; + &v4l2-plane; planes[FMT_NUM_PLANES]; + + memset(&buffer, 0, sizeof(buffer)); + buffer.type = reqbuf.type; + buffer.memory = V4L2_MEMORY_MMAP; + buffer.index = i; + /* length in struct v4l2_buffer in multi-planar API stores the size + * of planes array. */ + buffer.length = FMT_NUM_PLANES; + buffer.m.planes = planes; + + if (ioctl(fd, &VIDIOC-QUERYBUF;, &buffer) < 0) { + perror("VIDIOC_QUERYBUF"); + exit(EXIT_FAILURE); + } + + /* Every plane has to be mapped separately */ + for (j = 0; j < FMT_NUM_PLANES; j++) { + buffers[i].length[j] = buffer.m.planes[j].length; /* remember for munmap() */ + + buffers[i].start[j] = mmap(NULL, buffer.m.planes[j].length, + PROT_READ | PROT_WRITE, /* recommended */ + MAP_SHARED, /* recommended */ + fd, buffer.m.planes[j].m.offset); + + if (MAP_FAILED == buffers[i].start[j]) { + /* If you do not exit here you should unmap() and free() + the buffers and planes mapped so far. */ + perror("mmap"); + exit(EXIT_FAILURE); + } + } +} + +/* Cleanup. */ + +for (i = 0; i < reqbuf.count; i++) + for (j = 0; j < FMT_NUM_PLANES; j++) + munmap(buffers[i].start[j], buffers[i].length[j]); + + + + Conceptually streaming drivers maintain two buffer queues, an incoming +and an outgoing queue. They separate the synchronous capture or output +operation locked to a video clock from the application which is +subject to random disk or network delays and preemption by +other processes, thereby reducing the probability of data loss. +The queues are organized as FIFOs, buffers will be +output in the order enqueued in the incoming FIFO, and were +captured in the order dequeued from the outgoing FIFO. + + The driver may require a minimum number of buffers enqueued +at all times to function, apart of this no limit exists on the number +of buffers applications can enqueue in advance, or dequeue and +process. They can also enqueue in a different order than buffers have +been dequeued, and the driver can fill enqueued +empty buffers in any order. + Random enqueue order permits applications processing +images out of order (such as video codecs) to return buffers earlier, +reducing the probability of data loss. Random fill order allows +drivers to reuse buffers on a LIFO-basis, taking advantage of caches +holding scatter-gather lists and the like. + The index number of a buffer (&v4l2-buffer; +index) plays no role here, it only +identifies the buffer. + + Initially all mapped buffers are in dequeued state, +inaccessible by the driver. For capturing applications it is customary +to first enqueue all mapped buffers, then to start capturing and enter +the read loop. Here the application waits until a filled buffer can be +dequeued, and re-enqueues the buffer when the data is no longer +needed. Output applications fill and enqueue buffers, when enough +buffers are stacked up the output is started with +VIDIOC_STREAMON. In the write loop, when +the application runs out of free buffers, it must wait until an empty +buffer can be dequeued and reused. + + To enqueue and dequeue a buffer applications use the +&VIDIOC-QBUF; and &VIDIOC-DQBUF; ioctl. The status of a buffer being +mapped, enqueued, full or empty can be determined at any time using the +&VIDIOC-QUERYBUF; ioctl. Two methods exist to suspend execution of the +application until one or more buffers can be dequeued. By default +VIDIOC_DQBUF blocks when no buffer is in the +outgoing queue. When the O_NONBLOCK flag was +given to the &func-open; function, VIDIOC_DQBUF +returns immediately with an &EAGAIN; when no buffer is available. The +&func-select; or &func-poll; functions are always available. + + To start and stop capturing or output applications call the +&VIDIOC-STREAMON; and &VIDIOC-STREAMOFF; ioctl. Note +VIDIOC_STREAMOFF removes all buffers from both +queues as a side effect. Since there is no notion of doing anything +"now" on a multitasking system, if an application needs to synchronize +with another event it should examine the &v4l2-buffer; +timestamp of captured buffers, or set the +field before enqueuing buffers for output. + + Drivers implementing memory mapping I/O must +support the VIDIOC_REQBUFS, +VIDIOC_QUERYBUF, +VIDIOC_QBUF, VIDIOC_DQBUF, +VIDIOC_STREAMON and +VIDIOC_STREAMOFF ioctl, the +mmap(), munmap(), +select() and poll() +function. + At the driver level select() and +poll() are the same, and +select() is too important to be optional. The +rest should be evident. + + + [capture example] + +
+ +
+ Streaming I/O (User Pointers) + + Input and output devices support this I/O method when the +V4L2_CAP_STREAMING flag in the +capabilities field of &v4l2-capability; +returned by the &VIDIOC-QUERYCAP; ioctl is set. If the particular user +pointer method (not only memory mapping) is supported must be +determined by calling the &VIDIOC-REQBUFS; ioctl. + + This I/O method combines advantages of the read/write and +memory mapping methods. Buffers (planes) are allocated by the application +itself, and can reside for example in virtual or shared memory. Only +pointers to data are exchanged, these pointers and meta-information +are passed in &v4l2-buffer; (or in &v4l2-plane; in the multi-planar API case). +The driver must be switched into user pointer I/O mode by calling the +&VIDIOC-REQBUFS; with the desired buffer type. No buffers (planes) are allocated +beforehand, consequently they are not indexed and cannot be queried like mapped +buffers with the VIDIOC_QUERYBUF ioctl. + + + Initiating streaming I/O with user pointers + + +&v4l2-requestbuffers; reqbuf; + +memset (&reqbuf, 0, sizeof (reqbuf)); +reqbuf.type = V4L2_BUF_TYPE_VIDEO_CAPTURE; +reqbuf.memory = V4L2_MEMORY_USERPTR; + +if (ioctl (fd, &VIDIOC-REQBUFS;, &reqbuf) == -1) { + if (errno == EINVAL) + printf ("Video capturing or user pointer streaming is not supported\n"); + else + perror ("VIDIOC_REQBUFS"); + + exit (EXIT_FAILURE); +} + + + + Buffer (plane) addresses and sizes are passed on the fly with the +&VIDIOC-QBUF; ioctl. Although buffers are commonly cycled, +applications can pass different addresses and sizes at each +VIDIOC_QBUF call. If required by the hardware the +driver swaps memory pages within physical memory to create a +continuous area of memory. This happens transparently to the +application in the virtual memory subsystem of the kernel. When buffer +pages have been swapped out to disk they are brought back and finally +locked in physical memory for DMA. + We expect that frequently used buffers are typically not +swapped out. Anyway, the process of swapping, locking or generating +scatter-gather lists may be time consuming. The delay can be masked by +the depth of the incoming buffer queue, and perhaps by maintaining +caches assuming a buffer will be soon enqueued again. On the other +hand, to optimize memory usage drivers can limit the number of buffers +locked in advance and recycle the most recently used buffers first. Of +course, the pages of empty buffers in the incoming queue need not be +saved to disk. Output buffers must be saved on the incoming and +outgoing queue because an application may share them with other +processes. + + + Filled or displayed buffers are dequeued with the +&VIDIOC-DQBUF; ioctl. The driver can unlock the memory pages at any +time between the completion of the DMA and this ioctl. The memory is +also unlocked when &VIDIOC-STREAMOFF; is called, &VIDIOC-REQBUFS;, or +when the device is closed. Applications must take care not to free +buffers without dequeuing. For once, the buffers remain locked until +further, wasting physical memory. Second the driver will not be +notified when the memory is returned to the application's free list +and subsequently reused for other purposes, possibly completing the +requested DMA and overwriting valuable data. + + For capturing applications it is customary to enqueue a +number of empty buffers, to start capturing and enter the read loop. +Here the application waits until a filled buffer can be dequeued, and +re-enqueues the buffer when the data is no longer needed. Output +applications fill and enqueue buffers, when enough buffers are stacked +up output is started. In the write loop, when the application +runs out of free buffers it must wait until an empty buffer can be +dequeued and reused. Two methods exist to suspend execution of the +application until one or more buffers can be dequeued. By default +VIDIOC_DQBUF blocks when no buffer is in the +outgoing queue. When the O_NONBLOCK flag was +given to the &func-open; function, VIDIOC_DQBUF +returns immediately with an &EAGAIN; when no buffer is available. The +&func-select; or &func-poll; function are always available. + + To start and stop capturing or output applications call the +&VIDIOC-STREAMON; and &VIDIOC-STREAMOFF; ioctl. Note +VIDIOC_STREAMOFF removes all buffers from both +queues and unlocks all buffers as a side effect. Since there is no +notion of doing anything "now" on a multitasking system, if an +application needs to synchronize with another event it should examine +the &v4l2-buffer; timestamp of captured +buffers, or set the field before enqueuing buffers for output. + + Drivers implementing user pointer I/O must +support the VIDIOC_REQBUFS, +VIDIOC_QBUF, VIDIOC_DQBUF, +VIDIOC_STREAMON and +VIDIOC_STREAMOFF ioctl, the +select() and poll() function. + At the driver level select() and +poll() are the same, and +select() is too important to be optional. The +rest should be evident. + +
+ +
+ Streaming I/O (DMA buffer importing) + + + Experimental + This is an experimental + interface and may change in the future. + + +The DMABUF framework provides a generic method for sharing buffers +between multiple devices. Device drivers that support DMABUF can export a DMA +buffer to userspace as a file descriptor (known as the exporter role), import a +DMA buffer from userspace using a file descriptor previously exported for a +different or the same device (known as the importer role), or both. This +section describes the DMABUF importer role API in V4L2. + + Refer to DMABUF exporting for +details about exporting V4L2 buffers as DMABUF file descriptors. + +Input and output devices support the streaming I/O method when the +V4L2_CAP_STREAMING flag in the +capabilities field of &v4l2-capability; returned by +the &VIDIOC-QUERYCAP; ioctl is set. Whether importing DMA buffers through +DMABUF file descriptors is supported is determined by calling the +&VIDIOC-REQBUFS; ioctl with the memory type set to +V4L2_MEMORY_DMABUF. + + This I/O method is dedicated to sharing DMA buffers between different +devices, which may be V4L devices or other video-related devices (e.g. DRM). +Buffers (planes) are allocated by a driver on behalf of an application. Next, +these buffers are exported to the application as file descriptors using an API +which is specific for an allocator driver. Only such file descriptor are +exchanged. The descriptors and meta-information are passed in &v4l2-buffer; (or +in &v4l2-plane; in the multi-planar API case). The driver must be switched +into DMABUF I/O mode by calling the &VIDIOC-REQBUFS; with the desired buffer +type. + + + Initiating streaming I/O with DMABUF file descriptors + + +&v4l2-requestbuffers; reqbuf; + +memset(&reqbuf, 0, sizeof (reqbuf)); +reqbuf.type = V4L2_BUF_TYPE_VIDEO_CAPTURE; +reqbuf.memory = V4L2_MEMORY_DMABUF; +reqbuf.count = 1; + +if (ioctl(fd, &VIDIOC-REQBUFS;, &reqbuf) == -1) { + if (errno == EINVAL) + printf("Video capturing or DMABUF streaming is not supported\n"); + else + perror("VIDIOC_REQBUFS"); + + exit(EXIT_FAILURE); +} + + + + The buffer (plane) file descriptor is passed on the fly with the +&VIDIOC-QBUF; ioctl. In case of multiplanar buffers, every plane can be +associated with a different DMABUF descriptor. Although buffers are commonly +cycled, applications can pass a different DMABUF descriptor at each +VIDIOC_QBUF call. + + + Queueing DMABUF using single plane API + + +int buffer_queue(int v4lfd, int index, int dmafd) +{ + &v4l2-buffer; buf; + + memset(&buf, 0, sizeof buf); + buf.type = V4L2_BUF_TYPE_VIDEO_CAPTURE; + buf.memory = V4L2_MEMORY_DMABUF; + buf.index = index; + buf.m.fd = dmafd; + + if (ioctl(v4lfd, &VIDIOC-QBUF;, &buf) == -1) { + perror("VIDIOC_QBUF"); + return -1; + } + + return 0; +} + + + + + Queueing DMABUF using multi plane API + + +int buffer_queue_mp(int v4lfd, int index, int dmafd[], int n_planes) +{ + &v4l2-buffer; buf; + &v4l2-plane; planes[VIDEO_MAX_PLANES]; + int i; + + memset(&buf, 0, sizeof buf); + buf.type = V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE; + buf.memory = V4L2_MEMORY_DMABUF; + buf.index = index; + buf.m.planes = planes; + buf.length = n_planes; + + memset(&planes, 0, sizeof planes); + + for (i = 0; i < n_planes; ++i) + buf.m.planes[i].m.fd = dmafd[i]; + + if (ioctl(v4lfd, &VIDIOC-QBUF;, &buf) == -1) { + perror("VIDIOC_QBUF"); + return -1; + } + + return 0; +} + + + + Captured or displayed buffers are dequeued with the +&VIDIOC-DQBUF; ioctl. The driver can unlock the buffer at any +time between the completion of the DMA and this ioctl. The memory is +also unlocked when &VIDIOC-STREAMOFF; is called, &VIDIOC-REQBUFS;, or +when the device is closed. + + For capturing applications it is customary to enqueue a +number of empty buffers, to start capturing and enter the read loop. +Here the application waits until a filled buffer can be dequeued, and +re-enqueues the buffer when the data is no longer needed. Output +applications fill and enqueue buffers, when enough buffers are stacked +up output is started. In the write loop, when the application +runs out of free buffers it must wait until an empty buffer can be +dequeued and reused. Two methods exist to suspend execution of the +application until one or more buffers can be dequeued. By default +VIDIOC_DQBUF blocks when no buffer is in the +outgoing queue. When the O_NONBLOCK flag was +given to the &func-open; function, VIDIOC_DQBUF +returns immediately with an &EAGAIN; when no buffer is available. The +&func-select; and &func-poll; functions are always available. + + To start and stop capturing or displaying applications call the +&VIDIOC-STREAMON; and &VIDIOC-STREAMOFF; ioctls. Note that +VIDIOC_STREAMOFF removes all buffers from both queues and +unlocks all buffers as a side effect. Since there is no notion of doing +anything "now" on a multitasking system, if an application needs to synchronize +with another event it should examine the &v4l2-buffer; +timestamp of captured buffers, or set the field +before enqueuing buffers for output. + + Drivers implementing DMABUF importing I/O must support the +VIDIOC_REQBUFS, VIDIOC_QBUF, +VIDIOC_DQBUF, VIDIOC_STREAMON and +VIDIOC_STREAMOFF ioctls, and the +select() and poll() functions. + +
+ +
+ Asynchronous I/O + + This method is not defined yet. +
+ +
+ Buffers + + A buffer contains data exchanged by application and +driver using one of the Streaming I/O methods. In the multi-planar API, the +data is held in planes, while the buffer structure acts as a container +for the planes. Only pointers to buffers (planes) are exchanged, the data +itself is not copied. These pointers, together with meta-information like +timestamps or field parity, are stored in a struct +v4l2_buffer, argument to +the &VIDIOC-QUERYBUF;, &VIDIOC-QBUF; and &VIDIOC-DQBUF; ioctl. +In the multi-planar API, some plane-specific members of struct +v4l2_buffer, such as pointers and sizes for each +plane, are stored in struct v4l2_plane instead. +In that case, struct v4l2_buffer contains an array of +plane structures. + + Nominally timestamps refer to the first data byte transmitted. +In practice however the wide range of hardware covered by the V4L2 API +limits timestamp accuracy. Often an interrupt routine will +sample the system clock shortly after the field or frame was stored +completely in memory. So applications must expect a constant +difference up to one field or frame period plus a small (few scan +lines) random error. The delay and error can be much +larger due to compression or transmission over an external bus when +the frames are not properly stamped by the sender. This is frequently +the case with USB cameras. Here timestamps refer to the instant the +field or frame was received by the driver, not the capture time. These +devices identify by not enumerating any video standards, see . + + Similar limitations apply to output timestamps. Typically +the video hardware locks to a clock controlling the video timing, the +horizontal and vertical synchronization pulses. At some point in the +line sequence, possibly the vertical blanking, an interrupt routine +samples the system clock, compares against the timestamp and programs +the hardware to repeat the previous field or frame, or to display the +buffer contents. + + Apart of limitations of the video device and natural +inaccuracies of all clocks, it should be noted system time itself is +not perfectly stable. It can be affected by power saving cycles, +warped to insert leap seconds, or even turned back or forth by the +system administrator affecting long term measurements. + Since no other Linux multimedia +API supports unadjusted time it would be foolish to introduce here. We +must use a universally supported clock to synchronize different media, +hence time of day. + + + + struct <structname>v4l2_buffer</structname> + + &cs-ustr; + + + __u32 + index + + Number of the buffer, set by the application. This +field is only used for memory mapping I/O +and can range from zero to the number of buffers allocated +with the &VIDIOC-REQBUFS; ioctl (&v4l2-requestbuffers; count) minus one. + + + __u32 + type + + Type of the buffer, same as &v4l2-format; +type or &v4l2-requestbuffers; +type, set by the application. See + + + __u32 + bytesused + + The number of bytes occupied by the data in the +buffer. It depends on the negotiated data format and may change with +each buffer for compressed variable size data like JPEG images. +Drivers must set this field when type +refers to an input stream, applications when an output stream. + + + __u32 + flags + + Flags set by the application or driver, see . + + + __u32 + field + + Indicates the field order of the image in the +buffer, see . This field is not used when +the buffer contains VBI data. Drivers must set it when +type refers to an input stream, +applications when an output stream. + + + struct timeval + timestamp + + For input streams this is time when the first data + byte was captured, as returned by the + clock_gettime() function for the relevant + clock id; see V4L2_BUF_FLAG_TIMESTAMP_* in + . For output streams the data + will not be displayed before this time, secondary to the nominal + frame rate determined by the current video standard in enqueued + order. Applications can for example zero this field to display + frames as soon as possible. The driver stores the time at which + the first data byte was actually sent out in the + timestamp field. This permits + applications to monitor the drift between the video and system + clock. + + + &v4l2-timecode; + timecode + + When type is +V4L2_BUF_TYPE_VIDEO_CAPTURE and the +V4L2_BUF_FLAG_TIMECODE flag is set in +flags, this structure contains a frame +timecode. In V4L2_FIELD_ALTERNATE +mode the top and bottom field contain the same timecode. +Timecodes are intended to help video editing and are typically recorded on +video tapes, but also embedded in compressed formats like MPEG. This +field is independent of the timestamp and +sequence fields. + + + __u32 + sequence + + Set by the driver, counting the frames (not fields!) in +sequence. This field is set for both input and output devices. + + + In V4L2_FIELD_ALTERNATE mode the top and +bottom field have the same sequence number. The count starts at zero +and includes dropped or repeated frames. A dropped frame was received +by an input device but could not be stored due to lack of free buffer +space. A repeated frame was displayed again by an output device +because the application did not pass new data in +time.Note this may count the frames received +e.g. over USB, without taking into account the frames dropped by the +remote hardware due to limited compression throughput or bus +bandwidth. These devices identify by not enumerating any video +standards, see . + + + __u32 + memory + + This field must be set by applications and/or drivers +in accordance with the selected I/O method. See + + + union + m + + + + __u32 + offset + For the single-planar API and when +memory is V4L2_MEMORY_MMAP this +is the offset of the buffer from the start of the device memory. The value is +returned by the driver and apart of serving as parameter to the &func-mmap; +function not useful for applications. See for details + + + + + unsigned long + userptr + For the single-planar API and when +memory is V4L2_MEMORY_USERPTR +this is a pointer to the buffer (casted to unsigned long type) in virtual +memory, set by the application. See for details. + + + + + struct v4l2_plane + *planes + When using the multi-planar API, contains a userspace pointer + to an array of &v4l2-plane;. The size of the array should be put + in the length field of this + v4l2_buffer structure. + + + + int + fd + For the single-plane API and when +memory is V4L2_MEMORY_DMABUF this +is the file descriptor associated with a DMABUF buffer. + + + __u32 + length + + Size of the buffer (not the payload) in bytes for the + single-planar API. For the multi-planar API the application sets + this to the number of elements in the planes + array. The driver will fill in the actual number of valid elements in + that array. + + + + __u32 + reserved2 + + A place holder for future extensions. Applications +should set this to 0. + + + __u32 + reserved + + A place holder for future extensions. Applications +should set this to 0. + + + +
+ + + struct <structname>v4l2_plane</structname> + + &cs-ustr; + + + __u32 + bytesused + + The number of bytes occupied by data in the plane + (its payload). + + + __u32 + length + + Size in bytes of the plane (not its payload). + + + union + m + + + + + + __u32 + mem_offset + When the memory type in the containing &v4l2-buffer; is + V4L2_MEMORY_MMAP, this is the value that + should be passed to &func-mmap;, similar to the + offset field in &v4l2-buffer;. + + + + unsigned long + userptr + When the memory type in the containing &v4l2-buffer; is + V4L2_MEMORY_USERPTR, this is a userspace + pointer to the memory allocated for this plane by an application. + + + + + int + fd + When the memory type in the containing &v4l2-buffer; is + V4L2_MEMORY_DMABUF, this is a file + descriptor associated with a DMABUF buffer, similar to the + fd field in &v4l2-buffer;. + + + __u32 + data_offset + + Offset in bytes to video data in the plane, if applicable. + + + + __u32 + reserved[11] + + Reserved for future use. Should be zeroed by an + application. + + + +
+ + + enum v4l2_buf_type + + &cs-def; + + + V4L2_BUF_TYPE_VIDEO_CAPTURE + 1 + Buffer of a single-planar video capture stream, see . + + + V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE + + 9 + Buffer of a multi-planar video capture stream, see . + + + V4L2_BUF_TYPE_VIDEO_OUTPUT + 2 + Buffer of a single-planar video output stream, see . + + + V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE + + 10 + Buffer of a multi-planar video output stream, see . + + + V4L2_BUF_TYPE_VIDEO_OVERLAY + 3 + Buffer for video overlay, see . + + + V4L2_BUF_TYPE_VBI_CAPTURE + 4 + Buffer of a raw VBI capture stream, see . + + + V4L2_BUF_TYPE_VBI_OUTPUT + 5 + Buffer of a raw VBI output stream, see . + + + V4L2_BUF_TYPE_SLICED_VBI_CAPTURE + 6 + Buffer of a sliced VBI capture stream, see . + + + V4L2_BUF_TYPE_SLICED_VBI_OUTPUT + 7 + Buffer of a sliced VBI output stream, see . + + + V4L2_BUF_TYPE_VIDEO_OUTPUT_OVERLAY + 8 + Buffer for video output overlay (OSD), see . + + + +
+ + + Buffer Flags + + &cs-def; + + + V4L2_BUF_FLAG_MAPPED + 0x0001 + The buffer resides in device memory and has been mapped +into the application's address space, see for details. +Drivers set or clear this flag when the +VIDIOC_QUERYBUF, VIDIOC_QBUF or VIDIOC_DQBUF ioctl is called. Set by the driver. + + + V4L2_BUF_FLAG_QUEUED + 0x0002 + Internally drivers maintain two buffer queues, an +incoming and outgoing queue. When this flag is set, the buffer is +currently on the incoming queue. It automatically moves to the +outgoing queue after the buffer has been filled (capture devices) or +displayed (output devices). Drivers set or clear this flag when the +VIDIOC_QUERYBUF ioctl is called. After +(successful) calling the VIDIOC_QBUF ioctl it is +always set and after VIDIOC_DQBUF always +cleared. + + + V4L2_BUF_FLAG_DONE + 0x0004 + When this flag is set, the buffer is currently on +the outgoing queue, ready to be dequeued from the driver. Drivers set +or clear this flag when the VIDIOC_QUERYBUF ioctl +is called. After calling the VIDIOC_QBUF or +VIDIOC_DQBUF it is always cleared. Of course a +buffer cannot be on both queues at the same time, the +V4L2_BUF_FLAG_QUEUED and +V4L2_BUF_FLAG_DONE flag are mutually exclusive. +They can be both cleared however, then the buffer is in "dequeued" +state, in the application domain to say so. + + + V4L2_BUF_FLAG_ERROR + 0x0040 + When this flag is set, the buffer has been dequeued + successfully, although the data might have been corrupted. + This is recoverable, streaming may continue as normal and + the buffer may be reused normally. + Drivers set this flag when the VIDIOC_DQBUF + ioctl is called. + + + V4L2_BUF_FLAG_KEYFRAME + 0x0008 + Drivers set or clear this flag when calling the +VIDIOC_DQBUF ioctl. It may be set by video +capture devices when the buffer contains a compressed image which is a +key frame (or field), &ie; can be decompressed on its own. + + + V4L2_BUF_FLAG_PFRAME + 0x0010 + Similar to V4L2_BUF_FLAG_KEYFRAME +this flags predicted frames or fields which contain only differences to a +previous key frame. + + + V4L2_BUF_FLAG_BFRAME + 0x0020 + Similar to V4L2_BUF_FLAG_PFRAME + this is a bidirectional predicted frame or field. [ooc tbd] + + + V4L2_BUF_FLAG_TIMECODE + 0x0100 + The timecode field is valid. +Drivers set or clear this flag when the VIDIOC_DQBUF +ioctl is called. + + + V4L2_BUF_FLAG_PREPARED + 0x0400 + The buffer has been prepared for I/O and can be queued by the +application. Drivers set or clear this flag when the +VIDIOC_QUERYBUF, VIDIOC_PREPARE_BUF, VIDIOC_QBUF or VIDIOC_DQBUF ioctl is called. + + + V4L2_BUF_FLAG_NO_CACHE_INVALIDATE + 0x0800 + Caches do not have to be invalidated for this buffer. +Typically applications shall use this flag if the data captured in the buffer +is not going to be touched by the CPU, instead the buffer will, probably, be +passed on to a DMA-capable hardware unit for further processing or output. + + + + V4L2_BUF_FLAG_NO_CACHE_CLEAN + 0x1000 + Caches do not have to be cleaned for this buffer. +Typically applications shall use this flag for output buffers if the data +in this buffer has not been created by the CPU but by some DMA-capable unit, +in which case caches have not been used. + + + V4L2_BUF_FLAG_TIMESTAMP_MASK + 0xe000 + Mask for timestamp types below. To test the + timestamp type, mask out bits not belonging to timestamp + type by performing a logical and operation with buffer + flags and timestamp mask. + + + V4L2_BUF_FLAG_TIMESTAMP_UNKNOWN + 0x0000 + Unknown timestamp type. This type is used by + drivers before Linux 3.9 and may be either monotonic (see + below) or realtime (wall clock). Monotonic clock has been + favoured in embedded systems whereas most of the drivers + use the realtime clock. Either kinds of timestamps are + available in user space via + clock_gettime(2) using clock IDs + CLOCK_MONOTONIC and + CLOCK_REALTIME, respectively. + + + V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC + 0x2000 + The buffer timestamp has been taken from the + CLOCK_MONOTONIC clock. To access the + same clock outside V4L2, use + clock_gettime(2) . + + + +
+ + + enum v4l2_memory + + &cs-def; + + + V4L2_MEMORY_MMAP + 1 + The buffer is used for memory +mapping I/O. + + + V4L2_MEMORY_USERPTR + 2 + The buffer is used for user +pointer I/O. + + + V4L2_MEMORY_OVERLAY + 3 + [to do] + + + V4L2_MEMORY_DMABUF + 4 + The buffer is used for DMA shared +buffer I/O. + + + +
+ +
+ Timecodes + + The v4l2_timecode structure is +designed to hold a or similar timecode. +(struct timeval timestamps are stored in +&v4l2-buffer; field timestamp.) + + + struct <structname>v4l2_timecode</structname> + + &cs-str; + + + __u32 + type + Frame rate the timecodes are based on, see . + + + __u32 + flags + Timecode flags, see . + + + __u8 + frames + Frame count, 0 ... 23/24/29/49/59, depending on the + type of timecode. + + + __u8 + seconds + Seconds count, 0 ... 59. This is a binary, not BCD number. + + + __u8 + minutes + Minutes count, 0 ... 59. This is a binary, not BCD number. + + + __u8 + hours + Hours count, 0 ... 29. This is a binary, not BCD number. + + + __u8 + userbits[4] + The "user group" bits from the timecode. + + + +
+ + + Timecode Types + + &cs-def; + + + V4L2_TC_TYPE_24FPS + 1 + 24 frames per second, i. e. film. + + + V4L2_TC_TYPE_25FPS + 2 + 25 frames per second, &ie; PAL or SECAM video. + + + V4L2_TC_TYPE_30FPS + 3 + 30 frames per second, &ie; NTSC video. + + + V4L2_TC_TYPE_50FPS + 4 + + + + V4L2_TC_TYPE_60FPS + 5 + + + + +
+ + + Timecode Flags + + &cs-def; + + + V4L2_TC_FLAG_DROPFRAME + 0x0001 + Indicates "drop frame" semantics for counting frames +in 29.97 fps material. When set, frame numbers 0 and 1 at the start of +each minute, except minutes 0, 10, 20, 30, 40, 50 are omitted from the +count. + + + V4L2_TC_FLAG_COLORFRAME + 0x0002 + The "color frame" flag. + + + V4L2_TC_USERBITS_field + 0x000C + Field mask for the "binary group flags". + + + V4L2_TC_USERBITS_USERDEFINED + 0x0000 + Unspecified format. + + + V4L2_TC_USERBITS_8BITCHARS + 0x0008 + 8-bit ISO characters. + + + +
+
+
+ +
+ Field Order + + We have to distinguish between progressive and interlaced +video. Progressive video transmits all lines of a video image +sequentially. Interlaced video divides an image into two fields, +containing only the odd and even lines of the image, respectively. +Alternating the so called odd and even field are transmitted, and due +to a small delay between fields a cathode ray TV displays the lines +interleaved, yielding the original frame. This curious technique was +invented because at refresh rates similar to film the image would +fade out too quickly. Transmitting fields reduces the flicker without +the necessity of doubling the frame rate and with it the bandwidth +required for each channel. + + It is important to understand a video camera does not expose +one frame at a time, merely transmitting the frames separated into +fields. The fields are in fact captured at two different instances in +time. An object on screen may well move between one field and the +next. For applications analysing motion it is of paramount importance +to recognize which field of a frame is older, the temporal +order. + + When the driver provides or accepts images field by field +rather than interleaved, it is also important applications understand +how the fields combine to frames. We distinguish between top (aka odd) and +bottom (aka even) fields, the spatial order: The first line +of the top field is the first line of an interlaced frame, the first +line of the bottom field is the second line of that frame. + + However because fields were captured one after the other, +arguing whether a frame commences with the top or bottom field is +pointless. Any two successive top and bottom, or bottom and top fields +yield a valid frame. Only when the source was progressive to begin +with, ⪚ when transferring film to video, two fields may come from +the same frame, creating a natural order. + + Counter to intuition the top field is not necessarily the +older field. Whether the older field contains the top or bottom lines +is a convention determined by the video standard. Hence the +distinction between temporal and spatial order of fields. The diagrams +below should make this clearer. + + All video capture and output devices must report the current +field order. Some drivers may permit the selection of a different +order, to this end applications initialize the +field field of &v4l2-pix-format; before +calling the &VIDIOC-S-FMT; ioctl. If this is not desired it should +have the value V4L2_FIELD_ANY (0). + + + enum v4l2_field + + &cs-def; + + + V4L2_FIELD_ANY + 0 + Applications request this field order when any +one of the V4L2_FIELD_NONE, +V4L2_FIELD_TOP, +V4L2_FIELD_BOTTOM, or +V4L2_FIELD_INTERLACED formats is acceptable. +Drivers choose depending on hardware capabilities or e. g. the +requested image size, and return the actual field order. &v4l2-buffer; +field can never be +V4L2_FIELD_ANY. + + + V4L2_FIELD_NONE + 1 + Images are in progressive format, not interlaced. +The driver may also indicate this order when it cannot distinguish +between V4L2_FIELD_TOP and +V4L2_FIELD_BOTTOM. + + + V4L2_FIELD_TOP + 2 + Images consist of the top (aka odd) field only. + + + V4L2_FIELD_BOTTOM + 3 + Images consist of the bottom (aka even) field only. +Applications may wish to prevent a device from capturing interlaced +images because they will have "comb" or "feathering" artefacts around +moving objects. + + + V4L2_FIELD_INTERLACED + 4 + Images contain both fields, interleaved line by +line. The temporal order of the fields (whether the top or bottom +field is first transmitted) depends on the current video standard. +M/NTSC transmits the bottom field first, all other standards the top +field first. + + + V4L2_FIELD_SEQ_TB + 5 + Images contain both fields, the top field lines +are stored first in memory, immediately followed by the bottom field +lines. Fields are always stored in temporal order, the older one first +in memory. Image sizes refer to the frame, not fields. + + + V4L2_FIELD_SEQ_BT + 6 + Images contain both fields, the bottom field +lines are stored first in memory, immediately followed by the top +field lines. Fields are always stored in temporal order, the older one +first in memory. Image sizes refer to the frame, not fields. + + + V4L2_FIELD_ALTERNATE + 7 + The two fields of a frame are passed in separate +buffers, in temporal order, &ie; the older one first. To indicate the field +parity (whether the current field is a top or bottom field) the driver +or application, depending on data direction, must set &v4l2-buffer; +field to +V4L2_FIELD_TOP or +V4L2_FIELD_BOTTOM. Any two successive fields pair +to build a frame. If fields are successive, without any dropped fields +between them (fields can drop individually), can be determined from +the &v4l2-buffer; sequence field. Image +sizes refer to the frame, not fields. This format cannot be selected +when using the read/write I/O method. + + + V4L2_FIELD_INTERLACED_TB + 8 + Images contain both fields, interleaved line by +line, top field first. The top field is transmitted first. + + + V4L2_FIELD_INTERLACED_BT + 9 + Images contain both fields, interleaved line by +line, top field first. The bottom field is transmitted first. + + + +
+ +
+ Field Order, Top Field First Transmitted + + + + + + + + +
+ +
+ Field Order, Bottom Field First Transmitted + + + + + + + + +
+
diff --git a/Documentation/DocBook/media/v4l/keytable.c.xml b/Documentation/DocBook/media/v4l/keytable.c.xml new file mode 100644 index 00000000..d53254a3 --- /dev/null +++ b/Documentation/DocBook/media/v4l/keytable.c.xml @@ -0,0 +1,172 @@ + +/* keytable.c - This program allows checking/replacing keys at IR + + Copyright (C) 2006-2009 Mauro Carvalho Chehab <mchehab@infradead.org> + + This program is free software; you can redistribute it and/or modify + it under the terms of the GNU General Public License as published by + the Free Software Foundation, version 2 of the License. + + This program is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + GNU General Public License for more details. + */ + +#include <ctype.h> +#include <errno.h> +#include <fcntl.h> +#include <stdio.h> +#include <stdlib.h> +#include <string.h> +#include <linux/input.h> +#include <sys/ioctl.h> + +#include "parse.h" + +void prtcode (int *codes) +{ + struct parse_key *p; + + for (p=keynames;p->name!=NULL;p++) { + if (p->value == (unsigned)codes[1]) { + printf("scancode 0x%04x = %s (0x%02x)\n", codes[0], p->name, codes[1]); + return; + } + } + + if (isprint (codes[1])) + printf("scancode %d = '%c' (0x%02x)\n", codes[0], codes[1], codes[1]); + else + printf("scancode %d = 0x%02x\n", codes[0], codes[1]); +} + +int parse_code(char *string) +{ + struct parse_key *p; + + for (p=keynames;p->name!=NULL;p++) { + if (!strcasecmp(p->name, string)) { + return p->value; + } + } + return -1; +} + +int main (int argc, char *argv[]) +{ + int fd; + unsigned int i, j; + int codes[2]; + + if (argc<2 || argc>4) { + printf ("usage: %s <device> to get table; or\n" + " %s <device> <scancode> <keycode>\n" + " %s <device> <keycode_file>\n",*argv,*argv,*argv); + return -1; + } + + if ((fd = open(argv[1], O_RDONLY)) < 0) { + perror("Couldn't open input device"); + return(-1); + } + + if (argc==4) { + int value; + + value=parse_code(argv[3]); + + if (value==-1) { + value = strtol(argv[3], NULL, 0); + if (errno) + perror("value"); + } + + codes [0] = (unsigned) strtol(argv[2], NULL, 0); + codes [1] = (unsigned) value; + + if(ioctl(fd, EVIOCSKEYCODE, codes)) + perror ("EVIOCSKEYCODE"); + + if(ioctl(fd, EVIOCGKEYCODE, codes)==0) + prtcode(codes); + return 0; + } + + if (argc==3) { + FILE *fin; + int value; + char *scancode, *keycode, s[2048]; + + fin=fopen(argv[2],"r"); + if (fin==NULL) { + perror ("opening keycode file"); + return -1; + } + + /* Clears old table */ + for (j = 0; j < 256; j++) { + for (i = 0; i < 256; i++) { + codes[0] = (j << 8) | i; + codes[1] = KEY_RESERVED; + ioctl(fd, EVIOCSKEYCODE, codes); + } + } + + while (fgets(s,sizeof(s),fin)) { + scancode=strtok(s,"\n\t =:"); + if (!scancode) { + perror ("parsing input file scancode"); + return -1; + } + if (!strcasecmp(scancode, "scancode")) { + scancode = strtok(NULL,"\n\t =:"); + if (!scancode) { + perror ("parsing input file scancode"); + return -1; + } + } + + keycode=strtok(NULL,"\n\t =:("); + if (!keycode) { + perror ("parsing input file keycode"); + return -1; + } + + // printf ("parsing %s=%s:", scancode, keycode); + value=parse_code(keycode); + // printf ("\tvalue=%d\n",value); + + if (value==-1) { + value = strtol(keycode, NULL, 0); + if (errno) + perror("value"); + } + + codes [0] = (unsigned) strtol(scancode, NULL, 0); + codes [1] = (unsigned) value; + + // printf("\t%04x=%04x\n",codes[0], codes[1]); + if(ioctl(fd, EVIOCSKEYCODE, codes)) { + fprintf(stderr, "Setting scancode 0x%04x with 0x%04x via ",codes[0], codes[1]); + perror ("EVIOCSKEYCODE"); + } + + if(ioctl(fd, EVIOCGKEYCODE, codes)==0) + prtcode(codes); + } + return 0; + } + + /* Get scancode table */ + for (j = 0; j < 256; j++) { + for (i = 0; i < 256; i++) { + codes[0] = (j << 8) | i; + if (!ioctl(fd, EVIOCGKEYCODE, codes) && codes[1] != KEY_RESERVED) + prtcode(codes); + } + } + return 0; +} + + diff --git a/Documentation/DocBook/media/v4l/libv4l.xml b/Documentation/DocBook/media/v4l/libv4l.xml new file mode 100644 index 00000000..d3b71e20 --- /dev/null +++ b/Documentation/DocBook/media/v4l/libv4l.xml @@ -0,0 +1,160 @@ +Libv4l Userspace Library +
+ Introduction + + libv4l is a collection of libraries which adds a thin abstraction +layer on top of video4linux2 devices. The purpose of this (thin) layer +is to make it easy for application writers to support a wide variety of +devices without having to write separate code for different devices in the +same class. +An example of using libv4l is provided by +v4l2grab. + + + libv4l consists of 3 different libraries: +
+ libv4lconvert + + libv4lconvert is a library that converts several +different pixelformats found in V4L2 drivers into a few common RGB and +YUY formats. + It currently accepts the following V4L2 driver formats: +V4L2_PIX_FMT_BGR24, +V4L2_PIX_FMT_HM12, +V4L2_PIX_FMT_JPEG, +V4L2_PIX_FMT_MJPEG, +V4L2_PIX_FMT_MR97310A, +V4L2_PIX_FMT_OV511, +V4L2_PIX_FMT_OV518, +V4L2_PIX_FMT_PAC207, +V4L2_PIX_FMT_PJPG, +V4L2_PIX_FMT_RGB24, +V4L2_PIX_FMT_SBGGR8, +V4L2_PIX_FMT_SGBRG8, +V4L2_PIX_FMT_SGRBG8, +V4L2_PIX_FMT_SN9C10X, +V4L2_PIX_FMT_SN9C20X_I420, +V4L2_PIX_FMT_SPCA501, +V4L2_PIX_FMT_SPCA505, +V4L2_PIX_FMT_SPCA508, +V4L2_PIX_FMT_SPCA561, +V4L2_PIX_FMT_SQ905C, +V4L2_PIX_FMT_SRGGB8, +V4L2_PIX_FMT_UYVY, +V4L2_PIX_FMT_YUV420, +V4L2_PIX_FMT_YUYV, +V4L2_PIX_FMT_YVU420, +and V4L2_PIX_FMT_YVYU. + + Later on libv4lconvert was expanded to also be able to do +various video processing functions to improve webcam video quality. +The video processing is split in to 2 parts: libv4lconvert/control and +libv4lconvert/processing. + + The control part is used to offer video controls which can +be used to control the video processing functions made available by + libv4lconvert/processing. These controls are stored application wide +(until reboot) by using a persistent shared memory object. + + libv4lconvert/processing offers the actual video +processing functionality. +
+
+ libv4l1 + This library offers functions that can be used to quickly +make v4l1 applications work with v4l2 devices. These functions work exactly +like the normal open/close/etc, except that libv4l1 does full emulation of +the v4l1 api on top of v4l2 drivers, in case of v4l1 drivers it +will just pass calls through. + Since those functions are emulations of the old V4L1 API, +it shouldn't be used for new applications. +
+
+ libv4l2 + This library should be used for all modern V4L2 +applications. + It provides handles to call V4L2 open/ioctl/close/poll +methods. Instead of just providing the raw output of the device, it enhances +the calls in the sense that it will use libv4lconvert to provide more video +formats and to enhance the image quality. + In most cases, libv4l2 just passes the calls directly +through to the v4l2 driver, intercepting the calls to +VIDIOC_TRY_FMT, +VIDIOC_G_FMT +VIDIOC_S_FMT +VIDIOC_ENUM_FRAMESIZES +and VIDIOC_ENUM_FRAMEINTERVALS +in order to emulate the formats +V4L2_PIX_FMT_BGR24, +V4L2_PIX_FMT_RGB24, +V4L2_PIX_FMT_YUV420, +and V4L2_PIX_FMT_YVU420, +if they aren't available in the driver. +VIDIOC_ENUM_FMT +keeps enumerating the hardware supported formats, plus the emulated formats +offered by libv4l at the end. + +
+ Libv4l device control functions + The common file operation methods are provided by +libv4l. + Those functions operate just like glibc +open/close/dup/ioctl/read/mmap/munmap: + + int v4l2_open(const char *file, int oflag, +...) - +operates like the standard open() function. + + int v4l2_close(int fd) - +operates like the standard close() function. + + int v4l2_dup(int fd) - +operates like the standard dup() function, duplicating a file handler. + + int v4l2_ioctl (int fd, unsigned long int request, ...) - +operates like the standard ioctl() function. + + int v4l2_read (int fd, void* buffer, size_t n) - +operates like the standard read() function. + + void v4l2_mmap(void *start, size_t length, int prot, int flags, int fd, int64_t offset); - +operates like the standard mmap() function. + + int v4l2_munmap(void *_start, size_t length); - +operates like the standard munmap() function. + + + Those functions provide additional control: + + int v4l2_fd_open(int fd, int v4l2_flags) - +opens an already opened fd for further use through v4l2lib and possibly +modify libv4l2's default behavior through the v4l2_flags argument. +Currently, v4l2_flags can be V4L2_DISABLE_CONVERSION, +to disable format conversion. + + int v4l2_set_control(int fd, int cid, int value) - +This function takes a value of 0 - 65535, and then scales that range to +the actual range of the given v4l control id, and then if the cid exists +and is not locked sets the cid to the scaled value. + + int v4l2_get_control(int fd, int cid) - +This function returns a value of 0 - 65535, scaled to from the actual range +of the given v4l control id. when the cid does not exist, could not be +accessed for some reason, or some error occurred 0 is returned. + + +
+
+
+ + v4l1compat.so wrapper library + + This library intercepts calls to +open/close/ioctl/mmap/mmunmap operations and redirects them to the libv4l +counterparts, by using LD_PRELOAD=/usr/lib/v4l1compat.so. It also +emulates V4L1 calls via V4L2 API. + It allows usage of binary legacy applications that +still don't use libv4l. +
+ +
diff --git a/Documentation/DocBook/media/v4l/lirc_device_interface.xml b/Documentation/DocBook/media/v4l/lirc_device_interface.xml new file mode 100644 index 00000000..8d7eb6bf --- /dev/null +++ b/Documentation/DocBook/media/v4l/lirc_device_interface.xml @@ -0,0 +1,253 @@ +
+LIRC Device Interface + + +
+Introduction + +The LIRC device interface is a bi-directional interface for +transporting raw IR data between userspace and kernelspace. Fundamentally, +it is just a chardev (/dev/lircX, for X = 0, 1, 2, ...), with a number +of standard struct file_operations defined on it. With respect to +transporting raw IR data to and fro, the essential fops are read, write +and ioctl. + +Example dmesg output upon a driver registering w/LIRC: +
+ $ dmesg |grep lirc_dev + lirc_dev: IR Remote Control driver registered, major 248 + rc rc0: lirc_dev: driver ir-lirc-codec (mceusb) registered at minor = 0 +
+ +What you should see for a chardev: +
+ $ ls -l /dev/lirc* + crw-rw---- 1 root root 248, 0 Jul 2 22:20 /dev/lirc0 +
+
+ +
+LIRC read fop + +The lircd userspace daemon reads raw IR data from the LIRC chardev. The +exact format of the data depends on what modes a driver supports, and what +mode has been selected. lircd obtains supported modes and sets the active mode +via the ioctl interface, detailed at . The generally +preferred mode is LIRC_MODE_MODE2, in which packets containing an int value +describing an IR signal are read from the chardev. + +See also http://www.lirc.org/html/technical.html for more info. +
+ +
+LIRC write fop + +The data written to the chardev is a pulse/space sequence of integer +values. Pulses and spaces are only marked implicitly by their position. The +data must start and end with a pulse, therefore, the data must always include +an uneven number of samples. The write function must block until the data has +been transmitted by the hardware. +
+ +
+LIRC ioctl fop + +The LIRC device's ioctl definition is bound by the ioctl function +definition of struct file_operations, leaving us with an unsigned int +for the ioctl command and an unsigned long for the arg. For the purposes +of ioctl portability across 32-bit and 64-bit, these values are capped +to their 32-bit sizes. + +The following ioctls can be used to change specific hardware settings. +In general each driver should have a default set of settings. The driver +implementation is expected to re-apply the default settings when the device +is closed by user-space, so that every application opening the device can rely +on working with the default settings initially. + + + + LIRC_GET_FEATURES + + Obviously, get the underlying hardware device's features. If a driver + does not announce support of certain features, calling of the corresponding + ioctls is undefined. + + + + LIRC_GET_SEND_MODE + + Get supported transmit mode. Only LIRC_MODE_PULSE is supported by lircd. + + + + LIRC_GET_REC_MODE + + Get supported receive modes. Only LIRC_MODE_MODE2 and LIRC_MODE_LIRCCODE + are supported by lircd. + + + + LIRC_GET_SEND_CARRIER + + Get carrier frequency (in Hz) currently used for transmit. + + + + LIRC_GET_REC_CARRIER + + Get carrier frequency (in Hz) currently used for IR reception. + + + + LIRC_{G,S}ET_{SEND,REC}_DUTY_CYCLE + + Get/set the duty cycle (from 0 to 100) of the carrier signal. Currently, + no special meaning is defined for 0 or 100, but this could be used to switch + off carrier generation in the future, so these values should be reserved. + + + + LIRC_GET_REC_RESOLUTION + + Some receiver have maximum resolution which is defined by internal + sample rate or data format limitations. E.g. it's common that signals can + only be reported in 50 microsecond steps. This integer value is used by + lircd to automatically adjust the aeps tolerance value in the lircd + config file. + + + + LIRC_GET_M{IN,AX}_TIMEOUT + + Some devices have internal timers that can be used to detect when + there's no IR activity for a long time. This can help lircd in detecting + that a IR signal is finished and can speed up the decoding process. + Returns an integer value with the minimum/maximum timeout that can be + set. Some devices have a fixed timeout, in that case both ioctls will + return the same value even though the timeout cannot be changed. + + + + LIRC_GET_M{IN,AX}_FILTER_{PULSE,SPACE} + + Some devices are able to filter out spikes in the incoming signal + using given filter rules. These ioctls return the hardware capabilities + that describe the bounds of the possible filters. Filter settings depend + on the IR protocols that are expected. lircd derives the settings from + all protocols definitions found in its config file. + + + + LIRC_GET_LENGTH + + Retrieves the code length in bits (only for LIRC_MODE_LIRCCODE). + Reads on the device must be done in blocks matching the bit count. + The bit could should be rounded up so that it matches full bytes. + + + + LIRC_SET_{SEND,REC}_MODE + + Set send/receive mode. Largely obsolete for send, as only + LIRC_MODE_PULSE is supported. + + + + LIRC_SET_{SEND,REC}_CARRIER + + Set send/receive carrier (in Hz). + + + + LIRC_SET_TRANSMITTER_MASK + + This enables the given set of transmitters. The first transmitter + is encoded by the least significant bit, etc. When an invalid bit mask + is given, i.e. a bit is set, even though the device does not have so many + transitters, then this ioctl returns the number of available transitters + and does nothing otherwise. + + + + LIRC_SET_REC_TIMEOUT + + Sets the integer value for IR inactivity timeout (cf. + LIRC_GET_MIN_TIMEOUT and LIRC_GET_MAX_TIMEOUT). A value of 0 (if + supported by the hardware) disables all hardware timeouts and data should + be reported as soon as possible. If the exact value cannot be set, then + the next possible value _greater_ than the given value should be set. + + + + LIRC_SET_REC_TIMEOUT_REPORTS + + Enable (1) or disable (0) timeout reports in LIRC_MODE_MODE2. By + default, timeout reports should be turned off. + + + + LIRC_SET_REC_FILTER_{,PULSE,SPACE} + + Pulses/spaces shorter than this are filtered out by hardware. If + filters cannot be set independently for pulse/space, the corresponding + ioctls must return an error and LIRC_SET_REC_FILTER shall be used instead. + + + + LIRC_SET_MEASURE_CARRIER_MODE + + Enable (1)/disable (0) measure mode. If enabled, from the next key + press on, the driver will send LIRC_MODE2_FREQUENCY packets. By default + this should be turned off. + + + + LIRC_SET_REC_{DUTY_CYCLE,CARRIER}_RANGE + + To set a range use LIRC_SET_REC_DUTY_CYCLE_RANGE/LIRC_SET_REC_CARRIER_RANGE + with the lower bound first and later LIRC_SET_REC_DUTY_CYCLE/LIRC_SET_REC_CARRIER + with the upper bound. + + + + LIRC_NOTIFY_DECODE + + This ioctl is called by lircd whenever a successful decoding of an + incoming IR signal could be done. This can be used by supporting hardware + to give visual feedback to the user e.g. by flashing a LED. + + + + LIRC_SETUP_{START,END} + + Setting of several driver parameters can be optimized by encapsulating + the according ioctl calls with LIRC_SETUP_START/LIRC_SETUP_END. When a + driver receives a LIRC_SETUP_START ioctl it can choose to not commit + further setting changes to the hardware until a LIRC_SETUP_END is received. + But this is open to the driver implementation and every driver must also + handle parameter changes which are not encapsulated by LIRC_SETUP_START + and LIRC_SETUP_END. Drivers can also choose to ignore these ioctls. + + + + LIRC_SET_WIDEBAND_RECEIVER + + Some receivers are equipped with special wide band receiver which is intended + to be used to learn output of existing remote. + Calling that ioctl with (1) will enable it, and with (0) disable it. + This might be useful of receivers that have otherwise narrow band receiver + that prevents them to be used with some remotes. + Wide band receiver might also be more precise + On the other hand its disadvantage it usually reduced range of reception. + Note: wide band receiver might be implictly enabled if you enable + carrier reports. In that case it will be disabled as soon as you disable + carrier reports. Trying to disable wide band receiver while carrier + reports are active will do nothing. + + + +
+ &return-value; +
+
+
diff --git a/Documentation/DocBook/media/v4l/media-controller.xml b/Documentation/DocBook/media/v4l/media-controller.xml new file mode 100644 index 00000000..873ac3a6 --- /dev/null +++ b/Documentation/DocBook/media/v4l/media-controller.xml @@ -0,0 +1,89 @@ + + + + Laurent + Pinchart +
laurent.pinchart@ideasonboard.com
 + Initial version. + + + + 2010 + Laurent Pinchart + + + + + + 1.0.0 + 2010-11-10 + lp + Initial revision + + + + +Media Controller API + + + Media Controller + +
+ Introduction + Media devices increasingly handle multiple related functions. Many USB + cameras include microphones, video capture hardware can also output video, + or SoC camera interfaces also perform memory-to-memory operations similar to + video codecs. + Independent functions, even when implemented in the same hardware, can + be modelled as separate devices. A USB camera with a microphone will be + presented to userspace applications as V4L2 and ALSA capture devices. The + devices' relationships (when using a webcam, end-users shouldn't have to + manually select the associated USB microphone), while not made available + directly to applications by the drivers, can usually be retrieved from + sysfs. + With more and more advanced SoC devices being introduced, the current + approach will not scale. Device topologies are getting increasingly complex + and can't always be represented by a tree structure. Hardware blocks are + shared between different functions, creating dependencies between seemingly + unrelated devices. + Kernel abstraction APIs such as V4L2 and ALSA provide means for + applications to access hardware parameters. As newer hardware expose an + increasingly high number of those parameters, drivers need to guess what + applications really require based on limited information, thereby + implementing policies that belong to userspace. + The media controller API aims at solving those problems. +
+ +
+ Media device model + Discovering a device internal topology, and configuring it at runtime, + is one of the goals of the media controller API. To achieve this, hardware + devices are modelled as an oriented graph of building blocks called entities + connected through pads. + An entity is a basic media hardware or software building block. It can + correspond to a large variety of logical blocks such as physical hardware + devices (CMOS sensor for instance), logical hardware devices (a building + block in a System-on-Chip image processing pipeline), DMA channels or + physical connectors. + A pad is a connection endpoint through which an entity can interact + with other entities. Data (not restricted to video) produced by an entity + flows from the entity's output to one or more entity inputs. Pads should not + be confused with physical pins at chip boundaries. + A link is a point-to-point oriented connection between two pads, + either on the same entity or on different entities. Data flows from a source + pad to a sink pad. +
+ + + + Function Reference + + &sub-media-func-open; + &sub-media-func-close; + &sub-media-func-ioctl; + + &sub-media-ioc-device-info; + &sub-media-ioc-enum-entities; + &sub-media-ioc-enum-links; + &sub-media-ioc-setup-link; + diff --git a/Documentation/DocBook/media/v4l/media-func-close.xml b/Documentation/DocBook/media/v4l/media-func-close.xml new file mode 100644 index 00000000..be149c80 --- /dev/null +++ b/Documentation/DocBook/media/v4l/media-func-close.xml @@ -0,0 +1,59 @@ + + + media close() + &manvol; + + + + media-close + Close a media device + + + + + #include <unistd.h> + + int close + int fd + + + + + + Arguments + + + + fd + + &fd; + + + + + + + Description + + Closes the media device. Resources associated with the file descriptor + are freed. The device configuration remain unchanged. + + + + Return Value + + close returns 0 on success. On error, -1 is + returned, and errno is set appropriately. Possible error + codes are: + + + + EBADF + + fd is not a valid open file descriptor. + + + + + + diff --git a/Documentation/DocBook/media/v4l/media-func-ioctl.xml b/Documentation/DocBook/media/v4l/media-func-ioctl.xml new file mode 100644 index 00000000..39478d0f --- /dev/null +++ b/Documentation/DocBook/media/v4l/media-func-ioctl.xml @@ -0,0 +1,73 @@ + + + media ioctl() + &manvol; + + + + media-ioctl + Control a media device + + + + + #include <sys/ioctl.h> + + int ioctl + int fd + int request + void *argp + + + + + + Arguments + + + + fd + + &fd; + + + + request + + Media ioctl request code as defined in the media.h header file, + for example MEDIA_IOC_SETUP_LINK. + + + + argp + + Pointer to a request-specific structure. + + + + + + + Description + The ioctl() function manipulates media device + parameters. The argument fd must be an open file + descriptor. + The ioctl request code specifies the media + function to be called. It has encoded in it whether the argument is an + input, output or read/write parameter, and the size of the argument + argp in bytes. + Macros and structures definitions specifying media ioctl requests and + their parameters are located in the media.h header file. All media ioctl + requests, their respective function and parameters are specified in + . + + + + &return-value; + + Request-specific error codes are listed in the + individual requests descriptions. + When an ioctl that takes an output or read/write parameter fails, + the parameter remains unmodified. + + diff --git a/Documentation/DocBook/media/v4l/media-func-open.xml b/Documentation/DocBook/media/v4l/media-func-open.xml new file mode 100644 index 00000000..f7df034d --- /dev/null +++ b/Documentation/DocBook/media/v4l/media-func-open.xml @@ -0,0 +1,94 @@ + + + media open() + &manvol; + + + + media-open + Open a media device + + + + + #include <fcntl.h> + + int open + const char *device_name + int flags + + + + + + Arguments + + + + device_name + + Device to be opened. + + + + flags + + Open flags. Access mode must be either O_RDONLY + or O_RDWR. Other flags have no effect. + + + + + + Description + To open a media device applications call open() + with the desired device name. The function has no side effects; the device + configuration remain unchanged. + When the device is opened in read-only mode, attemps to modify its + configuration will result in an error, and errno will be + set to EBADF. + + + Return Value + + open returns the new file descriptor on success. + On error, -1 is returned, and errno is set appropriately. + Possible error codes are: + + + + EACCES + + The requested access to the file is not allowed. + + + + EMFILE + + The process already has the maximum number of files open. + + + + + ENFILE + + The system limit on the total number of open files has been + reached. + + + + ENOMEM + + Insufficient kernel memory was available. + + + + ENXIO + + No device corresponding to this device special file exists. + + + + + + diff --git a/Documentation/DocBook/media/v4l/media-ioc-device-info.xml b/Documentation/DocBook/media/v4l/media-ioc-device-info.xml new file mode 100644 index 00000000..2ce52141 --- /dev/null +++ b/Documentation/DocBook/media/v4l/media-ioc-device-info.xml @@ -0,0 +1,132 @@ + + + ioctl MEDIA_IOC_DEVICE_INFO + &manvol; + + + + MEDIA_IOC_DEVICE_INFO + Query device information + + + + + + int ioctl + int fd + int request + struct media_device_info *argp + + + + + + Arguments + + + + fd + + File descriptor returned by + open(). + + + + request + + MEDIA_IOC_DEVICE_INFO + + + + argp + + + + + + + + + Description + + All media devices must support the MEDIA_IOC_DEVICE_INFO + ioctl. To query device information, applications call the ioctl with a + pointer to a &media-device-info;. The driver fills the structure and returns + the information to the application. + The ioctl never fails. + + + struct <structname>media_device_info</structname> + + &cs-str; + + + char + driver[16] + Name of the driver implementing the media API as a + NUL-terminated ASCII string. The driver version is stored in the + driver_version field. + Driver specific applications can use this information to + verify the driver identity. It is also useful to work around + known bugs, or to identify drivers in error reports. + + + char + model[32] + Device model name as a NUL-terminated UTF-8 string. The + device version is stored in the device_version + field and is not be appended to the model name. + + + char + serial[40] + Serial number as a NUL-terminated ASCII string. + + + char + bus_info[32] + Location of the device in the system as a NUL-terminated + ASCII string. This includes the bus type name (PCI, USB, ...) and a + bus-specific identifier. + + + __u32 + media_version + Media API version, formatted with the + KERNEL_VERSION() macro. + + + __u32 + hw_revision + Hardware device revision in a driver-specific format. + + + __u32 + media_version + Media device driver version, formatted with the + KERNEL_VERSION() macro. Together with the + driver field this identifies a particular + driver. + + + __u32 + reserved[31] + Reserved for future extensions. Drivers and applications must + set this array to zero. + + + +
+ The serial and bus_info + fields can be used to distinguish between multiple instances of otherwise + identical hardware. The serial number takes precedence when provided and can + be assumed to be unique. If the serial number is an empty string, the + bus_info field can be used instead. The + bus_info field is guaranteed to be unique, but + can vary across reboots or device unplug/replug. + + + + &return-value; + + diff --git a/Documentation/DocBook/media/v4l/media-ioc-enum-entities.xml b/Documentation/DocBook/media/v4l/media-ioc-enum-entities.xml new file mode 100644 index 00000000..576b68b3 --- /dev/null +++ b/Documentation/DocBook/media/v4l/media-ioc-enum-entities.xml @@ -0,0 +1,308 @@ + + + ioctl MEDIA_IOC_ENUM_ENTITIES + &manvol; + + + + MEDIA_IOC_ENUM_ENTITIES + Enumerate entities and their properties + + + + + + int ioctl + int fd + int request + struct media_entity_desc *argp + + + + + + Arguments + + + + fd + + File descriptor returned by + open(). + + + + request + + MEDIA_IOC_ENUM_ENTITIES + + + + argp + + + + + + + + + Description + To query the attributes of an entity, applications set the id field + of a &media-entity-desc; structure and call the MEDIA_IOC_ENUM_ENTITIES + ioctl with a pointer to this structure. The driver fills the rest of the + structure or returns an &EINVAL; when the id is invalid. + Entities can be enumerated by or'ing the id with the + MEDIA_ENT_ID_FLAG_NEXT flag. The driver will return + information about the entity with the smallest id strictly larger than the + requested one ('next entity'), or the &EINVAL; if there is none. + Entity IDs can be non-contiguous. Applications must + not try to enumerate entities by calling + MEDIA_IOC_ENUM_ENTITIES with increasing id's until they get an error. + Two or more entities that share a common non-zero + group_id value are considered as logically + grouped. Groups are used to report + + ALSA, VBI and video nodes that carry the same media + stream + lens and flash controllers associated with a sensor + + + + + struct <structname>media_entity_desc</structname> + + + + + + + + + __u32 + id + + + Entity id, set by the application. When the id is or'ed with + MEDIA_ENT_ID_FLAG_NEXT, the driver clears the + flag and returns the first entity with a larger id. + + + char + name[32] + + + Entity name as an UTF-8 NULL-terminated string. + + + __u32 + type + + + Entity type, see for details. + + + __u32 + revision + + + Entity revision in a driver/hardware specific format. + + + __u32 + flags + + + Entity flags, see for details. + + + __u32 + group_id + + + Entity group ID + + + __u16 + pads + + + Number of pads + + + __u16 + links + + + Total number of outbound links. Inbound links are not counted + in this field. + + + union + + + + struct + v4l + + Valid for V4L sub-devices and nodes only. + + + + + __u32 + major + V4L device node major number. For V4L sub-devices with no + device node, set by the driver to 0. + + + + + __u32 + minor + V4L device node minor number. For V4L sub-devices with no + device node, set by the driver to 0. + + + + struct + fb + + Valid for frame buffer nodes only. + + + + + __u32 + major + Frame buffer device node major number. + + + + + __u32 + minor + Frame buffer device node minor number. + + + + struct + alsa + + Valid for ALSA devices only. + + + + + __u32 + card + ALSA card number + + + + + __u32 + device + ALSA device number + + + + + __u32 + subdevice + ALSA sub-device number + + + + int + dvb + + DVB card number + + + + __u8 + raw[180] + + + + + +
+ + + Media entity types + + + + + + MEDIA_ENT_T_DEVNODE + Unknown device node + + + MEDIA_ENT_T_DEVNODE_V4L + V4L video, radio or vbi device node + + + MEDIA_ENT_T_DEVNODE_FB + Frame buffer device node + + + MEDIA_ENT_T_DEVNODE_ALSA + ALSA card + + + MEDIA_ENT_T_DEVNODE_DVB + DVB card + + + MEDIA_ENT_T_V4L2_SUBDEV + Unknown V4L sub-device + + + MEDIA_ENT_T_V4L2_SUBDEV_SENSOR + Video sensor + + + MEDIA_ENT_T_V4L2_SUBDEV_FLASH + Flash controller + + + MEDIA_ENT_T_V4L2_SUBDEV_LENS + Lens controller + + + +
+ + + Media entity flags + + + + + + MEDIA_ENT_FL_DEFAULT + Default entity for its type. Used to discover the default + audio, VBI and video devices, the default camera sensor, ... + + + +
+ + + + &return-value; + + + + EINVAL + + The &media-entity-desc; id references + a non-existing entity. + + + + + diff --git a/Documentation/DocBook/media/v4l/media-ioc-enum-links.xml b/Documentation/DocBook/media/v4l/media-ioc-enum-links.xml new file mode 100644 index 00000000..355df43b --- /dev/null +++ b/Documentation/DocBook/media/v4l/media-ioc-enum-links.xml @@ -0,0 +1,207 @@ + + + ioctl MEDIA_IOC_ENUM_LINKS + &manvol; + + + + MEDIA_IOC_ENUM_LINKS + Enumerate all pads and links for a given entity + + + + + + int ioctl + int fd + int request + struct media_links_enum *argp + + + + + + Arguments + + + + fd + + File descriptor returned by + open(). + + + + request + + MEDIA_IOC_ENUM_LINKS + + + + argp + + + + + + + + + Description + + To enumerate pads and/or links for a given entity, applications set + the entity field of a &media-links-enum; structure and initialize the + &media-pad-desc; and &media-link-desc; structure arrays pointed by the + pads and links fields. + They then call the MEDIA_IOC_ENUM_LINKS ioctl with a pointer to this + structure. + If the pads field is not NULL, the driver + fills the pads array with information about the + entity's pads. The array must have enough room to store all the entity's + pads. The number of pads can be retrieved with the &MEDIA-IOC-ENUM-ENTITIES; + ioctl. + If the links field is not NULL, the driver + fills the links array with information about the + entity's outbound links. The array must have enough room to store all the + entity's outbound links. The number of outbound links can be retrieved with + the &MEDIA-IOC-ENUM-ENTITIES; ioctl. + Only forward links that originate at one of the entity's source pads + are returned during the enumeration process. + + + struct <structname>media_links_enum</structname> + + &cs-str; + + + __u32 + entity + Entity id, set by the application. + + + struct &media-pad-desc; + *pads + Pointer to a pads array allocated by the application. Ignored + if NULL. + + + struct &media-link-desc; + *links + Pointer to a links array allocated by the application. Ignored + if NULL. + + + + + + + struct <structname>media_pad_desc</structname> + + &cs-str; + + + __u32 + entity + ID of the entity this pad belongs to. + + + __u16 + index + 0-based pad index. + + + __u32 + flags + Pad flags, see for more details. + + + +
+ + + Media pad flags + + + + + + MEDIA_PAD_FL_SINK + Input pad, relative to the entity. Input pads sink data and + are targets of links. + + + MEDIA_PAD_FL_SOURCE + Output pad, relative to the entity. Output pads source data + and are origins of links. + + + +
+ + + struct <structname>media_link_desc</structname> + + &cs-str; + + + struct &media-pad-desc; + source + Pad at the origin of this link. + + + struct &media-pad-desc; + sink + Pad at the target of this link. + + + __u32 + flags + Link flags, see for more details. + + + + + + + Media link flags + + + + + + MEDIA_LNK_FL_ENABLED + The link is enabled and can be used to transfer media data. + When two or more links target a sink pad, only one of them can be + enabled at a time. + + + MEDIA_LNK_FL_IMMUTABLE + The link enabled state can't be modified at runtime. An + immutable link is always enabled. + + + MEDIA_LNK_FL_DYNAMIC + The link enabled state can be modified during streaming. This + flag is set by drivers and is read-only for applications. + + + + + One and only one of MEDIA_PAD_FL_SINK and + MEDIA_PAD_FL_SOURCE must be set for every pad. + + + + &return-value; + + + + EINVAL + + The &media-links-enum; id references + a non-existing entity. + + + + + diff --git a/Documentation/DocBook/media/v4l/media-ioc-setup-link.xml b/Documentation/DocBook/media/v4l/media-ioc-setup-link.xml new file mode 100644 index 00000000..fc2e522e --- /dev/null +++ b/Documentation/DocBook/media/v4l/media-ioc-setup-link.xml @@ -0,0 +1,84 @@ + + + ioctl MEDIA_IOC_SETUP_LINK + &manvol; + + + + MEDIA_IOC_SETUP_LINK + Modify the properties of a link + + + + + + int ioctl + int fd + int request + struct media_link_desc *argp + + + + + + Arguments + + + + fd + + File descriptor returned by + open(). + + + + request + + MEDIA_IOC_SETUP_LINK + + + + argp + + + + + + + + + Description + + To change link properties applications fill a &media-link-desc; with + link identification information (source and sink pad) and the new requested + link flags. They then call the MEDIA_IOC_SETUP_LINK ioctl with a pointer to + that structure. + The only configurable property is the ENABLED + link flag to enable/disable a link. Links marked with the + IMMUTABLE link flag can not be enabled or disabled. + + Link configuration has no side effect on other links. If an enabled + link at the sink pad prevents the link from being enabled, the driver + returns with an &EBUSY;. + Only links marked with the DYNAMIC link flag can + be enabled/disabled while streaming media data. Attempting to enable or + disable a streaming non-dynamic link will return an &EBUSY;. + If the specified link can't be found the driver returns with an + &EINVAL;. + + + + &return-value; + + + + EINVAL + + The &media-link-desc; references a non-existing link, or the + link is immutable and an attempt to modify its configuration was made. + + + + + + diff --git a/Documentation/DocBook/media/v4l/pipeline.pdf b/Documentation/DocBook/media/v4l/pipeline.pdf new file mode 100644 index 00000000..ee3e37f0 Binary files /dev/null and b/Documentation/DocBook/media/v4l/pipeline.pdf differ diff --git a/Documentation/DocBook/media/v4l/pixfmt-grey.xml b/Documentation/DocBook/media/v4l/pixfmt-grey.xml new file mode 100644 index 00000000..bee970d3 --- /dev/null +++ b/Documentation/DocBook/media/v4l/pixfmt-grey.xml @@ -0,0 +1,62 @@ + + + V4L2_PIX_FMT_GREY ('GREY') + &manvol; + + + V4L2_PIX_FMT_GREY + Grey-scale image + + + Description + + This is a grey-scale image. It is really a degenerate +Y'CbCr format which simply contains no Cb or Cr data. + + + <constant>V4L2_PIX_FMT_GREY</constant> 4 × 4 +pixel image + + + Byte Order. + Each cell is one byte. + + + + + + start + 0: + Y'00 + Y'01 + Y'02 + Y'03 + + + start + 4: + Y'10 + Y'11 + Y'12 + Y'13 + + + start + 8: + Y'20 + Y'21 + Y'22 + Y'23 + + + start + 12: + Y'30 + Y'31 + Y'32 + Y'33 + + + + + + + + + diff --git a/Documentation/DocBook/media/v4l/pixfmt-m420.xml b/Documentation/DocBook/media/v4l/pixfmt-m420.xml new file mode 100644 index 00000000..aadae92c --- /dev/null +++ b/Documentation/DocBook/media/v4l/pixfmt-m420.xml @@ -0,0 +1,139 @@ + + + V4L2_PIX_FMT_M420 ('M420') + &manvol; + + + V4L2_PIX_FMT_M420 + Format with ½ horizontal and vertical chroma + resolution, also known as YUV 4:2:0. Hybrid plane line-interleaved + layout. + + + Description + + M420 is a YUV format with ½ horizontal and vertical chroma + subsampling (YUV 4:2:0). Pixels are organized as interleaved luma and + chroma planes. Two lines of luma data are followed by one line of chroma + data. + The luma plane has one byte per pixel. The chroma plane contains + interleaved CbCr pixels subsampled by ½ in the horizontal and + vertical directions. Each CbCr pair belongs to four pixels. For example, +Cb0/Cr0 belongs to +Y'00, Y'01, +Y'10, Y'11. + + All line lengths are identical: if the Y lines include pad bytes + so do the CbCr lines. + + + <constant>V4L2_PIX_FMT_M420</constant> 4 × 4 +pixel image + + + Byte Order. + Each cell is one byte. + + + + + + start + 0: + Y'00 + Y'01 + Y'02 + Y'03 + + + start + 4: + Y'10 + Y'11 + Y'12 + Y'13 + + + start + 8: + Cb00 + Cr00 + Cb01 + Cr01 + + + start + 16: + Y'20 + Y'21 + Y'22 + Y'23 + + + start + 20: + Y'30 + Y'31 + Y'32 + Y'33 + + + start + 24: + Cb10 + Cr10 + Cb11 + Cr11 + + + + + + + + + Color Sample Location. + + + + + + + 01 + 23 + + + 0 + YY + YY + + + + C + C + + + 1 + YY + YY + + + + + + 2 + YY + YY + + + + C + C + + + 3 + YY + YY + + + + + + + + + diff --git a/Documentation/DocBook/media/v4l/pixfmt-nv12.xml b/Documentation/DocBook/media/v4l/pixfmt-nv12.xml new file mode 100644 index 00000000..84dd4fd7 --- /dev/null +++ b/Documentation/DocBook/media/v4l/pixfmt-nv12.xml @@ -0,0 +1,143 @@ + + + V4L2_PIX_FMT_NV12 ('NV12'), V4L2_PIX_FMT_NV21 ('NV21') + &manvol; + + + V4L2_PIX_FMT_NV12 + V4L2_PIX_FMT_NV21 + Formats with ½ horizontal and vertical +chroma resolution, also known as YUV 4:2:0. One luminance and one +chrominance plane with alternating chroma samples as opposed to +V4L2_PIX_FMT_YVU420 + + + Description + + These are two-plane versions of the YUV 4:2:0 format. +The three components are separated into two sub-images or planes. The +Y plane is first. The Y plane has one byte per pixel. For +V4L2_PIX_FMT_NV12, a combined CbCr plane +immediately follows the Y plane in memory. The CbCr plane is the same +width, in bytes, as the Y plane (and of the image), but is half as +tall in pixels. Each CbCr pair belongs to four pixels. For example, +Cb0/Cr0 belongs to +Y'00, Y'01, +Y'10, Y'11. +V4L2_PIX_FMT_NV21 is the same except the Cb and +Cr bytes are swapped, the CrCb plane starts with a Cr byte. + + If the Y plane has pad bytes after each row, then the +CbCr plane has as many pad bytes after its rows. + + + <constant>V4L2_PIX_FMT_NV12</constant> 4 × 4 +pixel image + + + Byte Order. + Each cell is one byte. + + + + + + start + 0: + Y'00 + Y'01 + Y'02 + Y'03 + + + start + 4: + Y'10 + Y'11 + Y'12 + Y'13 + + + start + 8: + Y'20 + Y'21 + Y'22 + Y'23 + + + start + 12: + Y'30 + Y'31 + Y'32 + Y'33 + + + start + 16: + Cb00 + Cr00 + Cb01 + Cr01 + + + start + 20: + Cb10 + Cr10 + Cb11 + Cr11 + + + + + + + + + Color Sample Location. + + + + + + + 01 + 23 + + + 0 + YY + YY + + + + C + C + + + 1 + YY + YY + + + + + + 2 + YY + YY + + + + C + C + + + 3 + YY + YY + + + + + + + + + diff --git a/Documentation/DocBook/media/v4l/pixfmt-nv12m.xml b/Documentation/DocBook/media/v4l/pixfmt-nv12m.xml new file mode 100644 index 00000000..f3a3d459 --- /dev/null +++ b/Documentation/DocBook/media/v4l/pixfmt-nv12m.xml @@ -0,0 +1,153 @@ + + + V4L2_PIX_FMT_NV12M ('NM12'), V4L2_PIX_FMT_NV21M ('NM21'), V4L2_PIX_FMT_NV12MT_16X16 + &manvol; + + + V4L2_PIX_FMT_NV12M + V4L2_PIX_FMT_NV21M + V4L2_PIX_FMT_NV12MT_16X16 + Variation of V4L2_PIX_FMT_NV12 and V4L2_PIX_FMT_NV21 with planes + non contiguous in memory. + + + Description + + This is a multi-planar, two-plane version of the YUV 4:2:0 format. +The three components are separated into two sub-images or planes. +V4L2_PIX_FMT_NV12M differs from V4L2_PIX_FMT_NV12 + in that the two planes are non-contiguous in memory, i.e. the chroma +plane do not necessarily immediately follows the luma plane. +The luminance data occupies the first plane. The Y plane has one byte per pixel. +In the second plane there is a chrominance data with alternating chroma samples. +The CbCr plane is the same width, in bytes, as the Y plane (and of the image), +but is half as tall in pixels. Each CbCr pair belongs to four pixels. For example, +Cb0/Cr0 belongs to +Y'00, Y'01, +Y'10, Y'11. +V4L2_PIX_FMT_NV12MT_16X16 is the tiled version of +V4L2_PIX_FMT_NV12M with 16x16 macroblock tiles. Here pixels +are arranged in 16x16 2D tiles and tiles are arranged in linear order in memory. +V4L2_PIX_FMT_NV21M is the same as V4L2_PIX_FMT_NV12M +except the Cb and Cr bytes are swapped, the CrCb plane starts with a Cr byte. + + V4L2_PIX_FMT_NV12M is intended to be +used only in drivers and applications that support the multi-planar API, +described in . + + If the Y plane has pad bytes after each row, then the +CbCr plane has as many pad bytes after its rows. + + + <constant>V4L2_PIX_FMT_NV12M</constant> 4 × 4 pixel image + + + Byte Order. + Each cell is one byte. + + + + + + start0 + 0: + Y'00 + Y'01 + Y'02 + Y'03 + + + start0 + 4: + Y'10 + Y'11 + Y'12 + Y'13 + + + start0 + 8: + Y'20 + Y'21 + Y'22 + Y'23 + + + start0 + 12: + Y'30 + Y'31 + Y'32 + Y'33 + + + + + + start1 + 0: + Cb00 + Cr00 + Cb01 + Cr01 + + + start1 + 4: + Cb10 + Cr10 + Cb11 + Cr11 + + + + + + + + + Color Sample Location. + + + + + + + 01 + 23 + + + 0 + YY + YY + + + + C + C + + + 1 + YY + YY + + + + + + 2 + YY + YY + + + + C + C + + + 3 + YY + YY + + + + + + + + + diff --git a/Documentation/DocBook/media/v4l/pixfmt-nv12mt.xml b/Documentation/DocBook/media/v4l/pixfmt-nv12mt.xml new file mode 100644 index 00000000..2f82b1da --- /dev/null +++ b/Documentation/DocBook/media/v4l/pixfmt-nv12mt.xml @@ -0,0 +1,66 @@ + + + V4L2_PIX_FMT_NV12MT ('TM12') + &manvol; + + + V4L2_PIX_FMT_NV12MT + + Formats with ½ horizontal and vertical +chroma resolution. This format has two planes - one for luminance and one for +chrominance. Chroma samples are interleaved. The difference to +V4L2_PIX_FMT_NV12 is the memory layout. Pixels are +grouped in macroblocks of 64x32 size. The order of macroblocks in memory is +also not standard. + + + + Description + + This is the two-plane versions of the YUV 4:2:0 format where data +is grouped into 64x32 macroblocks. The three components are separated into two +sub-images or planes. The Y plane has one byte per pixel and pixels are grouped +into 64x32 macroblocks. The CbCr plane has the same width, in bytes, as the Y +plane (and the image), but is half as tall in pixels. The chroma plane is also +grouped into 64x32 macroblocks. + Width of the buffer has to be aligned to the multiple of 128, and +height alignment is 32. Every four adjactent buffers - two horizontally and two +vertically are grouped together and are located in memory in Z or flipped Z +order. + Layout of macroblocks in memory is presented in the following +figure. +
+ <constant>V4L2_PIX_FMT_NV12MT</constant> macroblock Z shape +memory layout + + + + + +
+ The requirement that width is multiple of 128 is implemented because, +the Z shape cannot be cut in half horizontally. In case the vertical resolution +of macroblocks is odd then the last row of macroblocks is arranged in a linear +order. + In case of chroma the layout is identical. Cb and Cr samples are +interleaved. Height of the buffer is aligned to 32. + + + Memory layout of macroblocks in <constant>V4L2_PIX_FMT_NV12 +</constant> format pixel image - extreme case + +
+ Example <constant>V4L2_PIX_FMT_NV12MT</constant> memory +layout of macroblocks + + + + + +
+ Memory layout of macroblocks of V4L2_PIX_FMT_NV12MT + format in most extreme case. + + + + diff --git a/Documentation/DocBook/media/v4l/pixfmt-nv16.xml b/Documentation/DocBook/media/v4l/pixfmt-nv16.xml new file mode 100644 index 00000000..8ae1f8a8 --- /dev/null +++ b/Documentation/DocBook/media/v4l/pixfmt-nv16.xml @@ -0,0 +1,166 @@ + + + V4L2_PIX_FMT_NV16 ('NV16'), V4L2_PIX_FMT_NV61 ('NV61') + &manvol; + + + V4L2_PIX_FMT_NV16 + V4L2_PIX_FMT_NV61 + Formats with ½ horizontal +chroma resolution, also known as YUV 4:2:2. One luminance and one +chrominance plane with alternating chroma samples as opposed to +V4L2_PIX_FMT_YVU420 + + + Description + + These are two-plane versions of the YUV 4:2:2 format. +The three components are separated into two sub-images or planes. The +Y plane is first. The Y plane has one byte per pixel. For +V4L2_PIX_FMT_NV16, a combined CbCr plane +immediately follows the Y plane in memory. The CbCr plane is the same +width and height, in bytes, as the Y plane (and of the image). +Each CbCr pair belongs to two pixels. For example, +Cb0/Cr0 belongs to +Y'00, Y'01. +V4L2_PIX_FMT_NV61 is the same except the Cb and +Cr bytes are swapped, the CrCb plane starts with a Cr byte. + + If the Y plane has pad bytes after each row, then the +CbCr plane has as many pad bytes after its rows. + + + <constant>V4L2_PIX_FMT_NV16</constant> 4 × 4 +pixel image + + + Byte Order. + Each cell is one byte. + + + + + + start + 0: + Y'00 + Y'01 + Y'02 + Y'03 + + + start + 4: + Y'10 + Y'11 + Y'12 + Y'13 + + + start + 8: + Y'20 + Y'21 + Y'22 + Y'23 + + + start + 12: + Y'30 + Y'31 + Y'32 + Y'33 + + + start + 16: + Cb00 + Cr00 + Cb01 + Cr01 + + + start + 20: + Cb10 + Cr10 + Cb11 + Cr11 + + + start + 24: + Cb20 + Cr20 + Cb21 + Cr21 + + + start + 28: + Cb30 + Cr30 + Cb31 + Cr31 + + + + + + + + + Color Sample Location. + + + + + + + 01 + 23 + + + 0 + YY + YY + + + + C + C + + + 1 + YY + YY + + + + C + C + + + + + + 2 + YY + YY + + + + C + C + + + 3 + YY + YY + + + + C + C + + + + + + + + + diff --git a/Documentation/DocBook/media/v4l/pixfmt-nv24.xml b/Documentation/DocBook/media/v4l/pixfmt-nv24.xml new file mode 100644 index 00000000..fb255f2c --- /dev/null +++ b/Documentation/DocBook/media/v4l/pixfmt-nv24.xml @@ -0,0 +1,121 @@ + + + V4L2_PIX_FMT_NV24 ('NV24'), V4L2_PIX_FMT_NV42 ('NV42') + &manvol; + + + V4L2_PIX_FMT_NV24 + V4L2_PIX_FMT_NV42 + Formats with full horizontal and vertical +chroma resolutions, also known as YUV 4:4:4. One luminance and one +chrominance plane with alternating chroma samples as opposed to +V4L2_PIX_FMT_YVU420 + + + Description + + These are two-plane versions of the YUV 4:4:4 format. The three + components are separated into two sub-images or planes. The Y plane is + first, with each Y sample stored in one byte per pixel. For + V4L2_PIX_FMT_NV24, a combined CbCr plane + immediately follows the Y plane in memory. The CbCr plane has the same + width and height, in pixels, as the Y plane (and the image). Each line + contains one CbCr pair per pixel, with each Cb and Cr sample stored in + one byte. V4L2_PIX_FMT_NV42 is the same except that + the Cb and Cr samples are swapped, the CrCb plane starts with a Cr + sample. + + If the Y plane has pad bytes after each row, then the CbCr plane + has twice as many pad bytes after its rows. + + + <constant>V4L2_PIX_FMT_NV24</constant> 4 × 4 +pixel image + + + Byte Order. + Each cell is one byte. + + + + + + start + 0: + Y'00 + Y'01 + Y'02 + Y'03 + + + start + 4: + Y'10 + Y'11 + Y'12 + Y'13 + + + start + 8: + Y'20 + Y'21 + Y'22 + Y'23 + + + start + 12: + Y'30 + Y'31 + Y'32 + Y'33 + + + start + 16: + Cb00 + Cr00 + Cb01 + Cr01 + Cb02 + Cr02 + Cb03 + Cr03 + + + start + 24: + Cb10 + Cr10 + Cb11 + Cr11 + Cb12 + Cr12 + Cb13 + Cr13 + + + start + 32: + Cb20 + Cr20 + Cb21 + Cr21 + Cb22 + Cr22 + Cb23 + Cr23 + + + start + 40: + Cb30 + Cr30 + Cb31 + Cr31 + Cb32 + Cr32 + Cb33 + Cr33 + + + + + + + + + diff --git a/Documentation/DocBook/media/v4l/pixfmt-packed-rgb.xml b/Documentation/DocBook/media/v4l/pixfmt-packed-rgb.xml new file mode 100644 index 00000000..166c8d65 --- /dev/null +++ b/Documentation/DocBook/media/v4l/pixfmt-packed-rgb.xml @@ -0,0 +1,935 @@ + + + Packed RGB formats + &manvol; + + + Packed RGB formats + Packed RGB formats + + + Description + + These formats are designed to match the pixel formats of +typical PC graphics frame buffers. They occupy 8, 16, 24 or 32 bits +per pixel. These are all packed-pixel formats, meaning all the data +for a pixel lie next to each other in memory. + + When one of these formats is used, drivers shall report the +colorspace V4L2_COLORSPACE_SRGB. + + + Packed RGB Image Formats + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Identifier + Code +   + Byte 0 in memory + Byte 1 + Byte 2 + Byte 3 + + +   +   + Bit + 7 + 6 + 5 + 4 + 3 + 2 + 1 + 0 +   + 7 + 6 + 5 + 4 + 3 + 2 + 1 + 0 +   + 7 + 6 + 5 + 4 + 3 + 2 + 1 + 0 +   + 7 + 6 + 5 + 4 + 3 + 2 + 1 + 0 + + + + + V4L2_PIX_FMT_RGB332 + 'RGB1' + + b1 + b0 + g2 + g1 + g0 + r2 + r1 + r0 + + + V4L2_PIX_FMT_RGB444 + 'R444' + + g3 + g2 + g1 + g0 + b3 + b2 + b1 + b0 + + a3 + a2 + a1 + a0 + r3 + r2 + r1 + r0 + + + V4L2_PIX_FMT_RGB555 + 'RGBO' + + g2 + g1 + g0 + r4 + r3 + r2 + r1 + r0 + + a + b4 + b3 + b2 + b1 + b0 + g4 + g3 + + + V4L2_PIX_FMT_RGB565 + 'RGBP' + + g2 + g1 + g0 + r4 + r3 + r2 + r1 + r0 + + b4 + b3 + b2 + b1 + b0 + g5 + g4 + g3 + + + V4L2_PIX_FMT_RGB555X + 'RGBQ' + + a + b4 + b3 + b2 + b1 + b0 + g4 + g3 + + g2 + g1 + g0 + r4 + r3 + r2 + r1 + r0 + + + V4L2_PIX_FMT_RGB565X + 'RGBR' + + b4 + b3 + b2 + b1 + b0 + g5 + g4 + g3 + + g2 + g1 + g0 + r4 + r3 + r2 + r1 + r0 + + + V4L2_PIX_FMT_BGR666 + 'BGRH' + + b5 + b4 + b3 + b2 + b1 + b0 + g5 + g4 + + g3 + g2 + g1 + g0 + r5 + r4 + r3 + r2 + + r1 + r0 + + + + + + + + + + + + + + + + + V4L2_PIX_FMT_BGR24 + 'BGR3' + + b7 + b6 + b5 + b4 + b3 + b2 + b1 + b0 + + g7 + g6 + g5 + g4 + g3 + g2 + g1 + g0 + + r7 + r6 + r5 + r4 + r3 + r2 + r1 + r0 + + + V4L2_PIX_FMT_RGB24 + 'RGB3' + + r7 + r6 + r5 + r4 + r3 + r2 + r1 + r0 + + g7 + g6 + g5 + g4 + g3 + g2 + g1 + g0 + + b7 + b6 + b5 + b4 + b3 + b2 + b1 + b0 + + + V4L2_PIX_FMT_BGR32 + 'BGR4' + + b7 + b6 + b5 + b4 + b3 + b2 + b1 + b0 + + g7 + g6 + g5 + g4 + g3 + g2 + g1 + g0 + + r7 + r6 + r5 + r4 + r3 + r2 + r1 + r0 + + a7 + a6 + a5 + a4 + a3 + a2 + a1 + a0 + + + V4L2_PIX_FMT_RGB32 + 'RGB4' + + r7 + r6 + r5 + r4 + r3 + r2 + r1 + r0 + + g7 + g6 + g5 + g4 + g3 + g2 + g1 + g0 + + b7 + b6 + b5 + b4 + b3 + b2 + b1 + b0 + + a7 + a6 + a5 + a4 + a3 + a2 + a1 + a0 + + + +
+ + Bit 7 is the most significant bit. The value of a = alpha +bits is undefined when reading from the driver, ignored when writing +to the driver, except when alpha blending has been negotiated for a +Video Overlay or +Video Output Overlay or when alpha component has been configured +for a Video Capture by means of V4L2_CID_ALPHA_COMPONENT + control. + + + <constant>V4L2_PIX_FMT_BGR24</constant> 4 × 4 pixel +image + + + Byte Order. + Each cell is one byte. + + + + + + start + 0: + B00 + G00 + R00 + B01 + G01 + R01 + B02 + G02 + R02 + B03 + G03 + R03 + + + start + 12: + B10 + G10 + R10 + B11 + G11 + R11 + B12 + G12 + R12 + B13 + G13 + R13 + + + start + 24: + B20 + G20 + R20 + B21 + G21 + R21 + B22 + G22 + R22 + B23 + G23 + R23 + + + start + 36: + B30 + G30 + R30 + B31 + G31 + R31 + B32 + G32 + R32 + B33 + G33 + R33 + + + + + + + + + + Drivers may interpret these formats differently. + + + Some RGB formats above are uncommon and were probably +defined in error. Drivers may interpret them as in . + + + Packed RGB Image Formats (corrected) + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Identifier + Code +   + Byte 0 in memory + Byte 1 + Byte 2 + Byte 3 + + +   +   + Bit + 7 + 6 + 5 + 4 + 3 + 2 + 1 + 0 +   + 7 + 6 + 5 + 4 + 3 + 2 + 1 + 0 +   + 7 + 6 + 5 + 4 + 3 + 2 + 1 + 0 +   + 7 + 6 + 5 + 4 + 3 + 2 + 1 + 0 + + + + + V4L2_PIX_FMT_RGB332 + 'RGB1' + + r2 + r1 + r0 + g2 + g1 + g0 + b1 + b0 + + + V4L2_PIX_FMT_RGB444 + 'R444' + + g3 + g2 + g1 + g0 + b3 + b2 + b1 + b0 + + a3 + a2 + a1 + a0 + r3 + r2 + r1 + r0 + + + V4L2_PIX_FMT_RGB555 + 'RGBO' + + g2 + g1 + g0 + b4 + b3 + b2 + b1 + b0 + + a + r4 + r3 + r2 + r1 + r0 + g4 + g3 + + + V4L2_PIX_FMT_RGB565 + 'RGBP' + + g2 + g1 + g0 + b4 + b3 + b2 + b1 + b0 + + r4 + r3 + r2 + r1 + r0 + g5 + g4 + g3 + + + V4L2_PIX_FMT_RGB555X + 'RGBQ' + + a + r4 + r3 + r2 + r1 + r0 + g4 + g3 + + g2 + g1 + g0 + b4 + b3 + b2 + b1 + b0 + + + V4L2_PIX_FMT_RGB565X + 'RGBR' + + r4 + r3 + r2 + r1 + r0 + g5 + g4 + g3 + + g2 + g1 + g0 + b4 + b3 + b2 + b1 + b0 + + + V4L2_PIX_FMT_BGR666 + 'BGRH' + + b5 + b4 + b3 + b2 + b1 + b0 + g5 + g4 + + g3 + g2 + g1 + g0 + r5 + r4 + r3 + r2 + + r1 + r0 + + + + + + + + + + + + + + + + + V4L2_PIX_FMT_BGR24 + 'BGR3' + + b7 + b6 + b5 + b4 + b3 + b2 + b1 + b0 + + g7 + g6 + g5 + g4 + g3 + g2 + g1 + g0 + + r7 + r6 + r5 + r4 + r3 + r2 + r1 + r0 + + + V4L2_PIX_FMT_RGB24 + 'RGB3' + + r7 + r6 + r5 + r4 + r3 + r2 + r1 + r0 + + g7 + g6 + g5 + g4 + g3 + g2 + g1 + g0 + + b7 + b6 + b5 + b4 + b3 + b2 + b1 + b0 + + + V4L2_PIX_FMT_BGR32 + 'BGR4' + + b7 + b6 + b5 + b4 + b3 + b2 + b1 + b0 + + g7 + g6 + g5 + g4 + g3 + g2 + g1 + g0 + + r7 + r6 + r5 + r4 + r3 + r2 + r1 + r0 + + a7 + a6 + a5 + a4 + a3 + a2 + a1 + a0 + + + V4L2_PIX_FMT_RGB32 + 'RGB4' + + a7 + a6 + a5 + a4 + a3 + a2 + a1 + a0 + + r7 + r6 + r5 + r4 + r3 + r2 + r1 + r0 + + g7 + g6 + g5 + g4 + g3 + g2 + g1 + g0 + + b7 + b6 + b5 + b4 + b3 + b2 + b1 + b0 + + + +
+ + A test utility to determine which RGB formats a driver +actually supports is available from the LinuxTV v4l-dvb repository. +See &v4l-dvb; for access instructions. + + + diff --git a/Documentation/DocBook/media/v4l/pixfmt-packed-yuv.xml b/Documentation/DocBook/media/v4l/pixfmt-packed-yuv.xml new file mode 100644 index 00000000..33fa5a47 --- /dev/null +++ b/Documentation/DocBook/media/v4l/pixfmt-packed-yuv.xml @@ -0,0 +1,236 @@ + + + Packed YUV formats + &manvol; + + + Packed YUV formats + Packed YUV formats + + + Description + + Similar to the packed RGB formats these formats store +the Y, Cb and Cr component of each pixel in one 16 or 32 bit +word. + + + Packed YUV Image Formats + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Identifier + Code +   + Byte 0 in memory + Byte 1 + Byte 2 + Byte 3 + + +   +   + Bit + 7 + 6 + 5 + 4 + 3 + 2 + 1 + 0 +   + 7 + 6 + 5 + 4 + 3 + 2 + 1 + 0 +   + 7 + 6 + 5 + 4 + 3 + 2 + 1 + 0 +   + 7 + 6 + 5 + 4 + 3 + 2 + 1 + 0 + + + + + V4L2_PIX_FMT_YUV444 + 'Y444' + + Cb3 + Cb2 + Cb1 + Cb0 + Cr3 + Cr2 + Cr1 + Cr0 + + a3 + a2 + a1 + a0 + Y'3 + Y'2 + Y'1 + Y'0 + + + + V4L2_PIX_FMT_YUV555 + 'YUVO' + + Cb2 + Cb1 + Cb0 + Cr4 + Cr3 + Cr2 + Cr1 + Cr0 + + a + Y'4 + Y'3 + Y'2 + Y'1 + Y'0 + Cb4 + Cb3 + + + + V4L2_PIX_FMT_YUV565 + 'YUVP' + + Cb2 + Cb1 + Cb0 + Cr4 + Cr3 + Cr2 + Cr1 + Cr0 + + Y'4 + Y'3 + Y'2 + Y'1 + Y'0 + Cb5 + Cb4 + Cb3 + + + + V4L2_PIX_FMT_YUV32 + 'YUV4' + + a7 + a6 + a5 + a4 + a3 + a2 + a1 + a0 + + Y'7 + Y'6 + Y'5 + Y'4 + Y'3 + Y'2 + Y'1 + Y'0 + + Cb7 + Cb6 + Cb5 + Cb4 + Cb3 + Cb2 + Cb1 + Cb0 + + Cr7 + Cr6 + Cr5 + Cr4 + Cr3 + Cr2 + Cr1 + Cr0 + + + +
+ + Bit 7 is the most significant bit. The value of a = alpha +bits is undefined when reading from the driver, ignored when writing +to the driver, except when alpha blending has been negotiated for a +Video Overlay or Video Output Overlay. + + + diff --git a/Documentation/DocBook/media/v4l/pixfmt-sbggr16.xml b/Documentation/DocBook/media/v4l/pixfmt-sbggr16.xml new file mode 100644 index 00000000..6494b05d --- /dev/null +++ b/Documentation/DocBook/media/v4l/pixfmt-sbggr16.xml @@ -0,0 +1,83 @@ + + + V4L2_PIX_FMT_SBGGR16 ('BYR2') + &manvol; + + + V4L2_PIX_FMT_SBGGR16 + Bayer RGB format + + + Description + + This format is similar to +V4L2_PIX_FMT_SBGGR8, except each pixel has +a depth of 16 bits. The least significant byte is stored at lower +memory addresses (little-endian). Note the actual sampling precision +may be lower than 16 bits, for example 10 bits per pixel with values +in range 0 to 1023. + + + <constant>V4L2_PIX_FMT_SBGGR16</constant> 4 × 4 +pixel image + + + Byte Order. + Each cell is one byte. + + + + + + start + 0: + B00low + B00high + G01low + G01high + B02low + B02high + G03low + G03high + + + start + 8: + G10low + G10high + R11low + R11high + G12low + G12high + R13low + R13high + + + start + 16: + B20low + B20high + G21low + G21high + B22low + B22high + G23low + G23high + + + start + 24: + G30low + G30high + R31low + R31high + G32low + G32high + R33low + R33high + + + + + + + + + diff --git a/Documentation/DocBook/media/v4l/pixfmt-sbggr8.xml b/Documentation/DocBook/media/v4l/pixfmt-sbggr8.xml new file mode 100644 index 00000000..5eaf2b42 --- /dev/null +++ b/Documentation/DocBook/media/v4l/pixfmt-sbggr8.xml @@ -0,0 +1,67 @@ + + + V4L2_PIX_FMT_SBGGR8 ('BA81') + &manvol; + + + V4L2_PIX_FMT_SBGGR8 + Bayer RGB format + + + Description + + This is commonly the native format of digital cameras, +reflecting the arrangement of sensors on the CCD device. Only one red, +green or blue value is given for each pixel. Missing components must +be interpolated from neighbouring pixels. From left to right the first +row consists of a blue and green value, the second row of a green and +red value. This scheme repeats to the right and down for every two +columns and rows. + + + <constant>V4L2_PIX_FMT_SBGGR8</constant> 4 × 4 +pixel image + + + Byte Order. + Each cell is one byte. + + + + + + start + 0: + B00 + G01 + B02 + G03 + + + start + 4: + G10 + R11 + G12 + R13 + + + start + 8: + B20 + G21 + B22 + G23 + + + start + 12: + G30 + R31 + G32 + R33 + + + + + + + + + diff --git a/Documentation/DocBook/media/v4l/pixfmt-sgbrg8.xml b/Documentation/DocBook/media/v4l/pixfmt-sgbrg8.xml new file mode 100644 index 00000000..fee65dca --- /dev/null +++ b/Documentation/DocBook/media/v4l/pixfmt-sgbrg8.xml @@ -0,0 +1,67 @@ + + + V4L2_PIX_FMT_SGBRG8 ('GBRG') + &manvol; + + + V4L2_PIX_FMT_SGBRG8 + Bayer RGB format + + + Description + + This is commonly the native format of digital cameras, +reflecting the arrangement of sensors on the CCD device. Only one red, +green or blue value is given for each pixel. Missing components must +be interpolated from neighbouring pixels. From left to right the first +row consists of a green and blue value, the second row of a red and +green value. This scheme repeats to the right and down for every two +columns and rows. + + + <constant>V4L2_PIX_FMT_SGBRG8</constant> 4 × 4 +pixel image + + + Byte Order. + Each cell is one byte. + + + + + + start + 0: + G00 + B01 + G02 + B03 + + + start + 4: + R10 + G11 + R12 + G13 + + + start + 8: + G20 + B21 + G22 + B23 + + + start + 12: + R30 + G31 + R32 + G33 + + + + + + + + + diff --git a/Documentation/DocBook/media/v4l/pixfmt-sgrbg8.xml b/Documentation/DocBook/media/v4l/pixfmt-sgrbg8.xml new file mode 100644 index 00000000..19727ab4 --- /dev/null +++ b/Documentation/DocBook/media/v4l/pixfmt-sgrbg8.xml @@ -0,0 +1,67 @@ + + + V4L2_PIX_FMT_SGRBG8 ('GRBG') + &manvol; + + + V4L2_PIX_FMT_SGRBG8 + Bayer RGB format + + + Description + + This is commonly the native format of digital cameras, +reflecting the arrangement of sensors on the CCD device. Only one red, +green or blue value is given for each pixel. Missing components must +be interpolated from neighbouring pixels. From left to right the first +row consists of a green and blue value, the second row of a red and +green value. This scheme repeats to the right and down for every two +columns and rows. + + + <constant>V4L2_PIX_FMT_SGRBG8</constant> 4 × +4 pixel image + + + Byte Order. + Each cell is one byte. + + + + + + start + 0: + G00 + R01 + G02 + R03 + + + start + 4: + R10 + B11 + R12 + B13 + + + start + 8: + G20 + R21 + G22 + R23 + + + start + 12: + R30 + B31 + R32 + B33 + + + + + + + + + diff --git a/Documentation/DocBook/media/v4l/pixfmt-srggb10.xml b/Documentation/DocBook/media/v4l/pixfmt-srggb10.xml new file mode 100644 index 00000000..c1c62a9a --- /dev/null +++ b/Documentation/DocBook/media/v4l/pixfmt-srggb10.xml @@ -0,0 +1,90 @@ + + + V4L2_PIX_FMT_SRGGB10 ('RG10'), + V4L2_PIX_FMT_SGRBG10 ('BA10'), + V4L2_PIX_FMT_SGBRG10 ('GB10'), + V4L2_PIX_FMT_SBGGR10 ('BG10'), + + &manvol; + + + V4L2_PIX_FMT_SRGGB10 + V4L2_PIX_FMT_SGRBG10 + V4L2_PIX_FMT_SGBRG10 + V4L2_PIX_FMT_SBGGR10 + 10-bit Bayer formats expanded to 16 bits + + + Description + + The following four pixel formats are raw sRGB / Bayer formats with +10 bits per colour. Each colour component is stored in a 16-bit word, with 6 +unused high bits filled with zeros. Each n-pixel row contains n/2 green samples +and n/2 blue or red samples, with alternating red and blue rows. Bytes are +stored in memory in little endian order. They are conventionally described +as GRGR... BGBG..., RGRG... GBGB..., etc. Below is an example of one of these +formats + + + <constant>V4L2_PIX_FMT_SBGGR10</constant> 4 × 4 +pixel image + + + Byte Order. + Each cell is one byte, high 6 bits in high bytes are 0. + + + + + + start + 0: + B00low + B00high + G01low + G01high + B02low + B02high + G03low + G03high + + + start + 8: + G10low + G10high + R11low + R11high + G12low + G12high + R13low + R13high + + + start + 16: + B20low + B20high + G21low + G21high + B22low + B22high + G23low + G23high + + + start + 24: + G30low + G30high + R31low + R31high + G32low + G32high + R33low + R33high + + + + + + + + + diff --git a/Documentation/DocBook/media/v4l/pixfmt-srggb10alaw8.xml b/Documentation/DocBook/media/v4l/pixfmt-srggb10alaw8.xml new file mode 100644 index 00000000..29acc209 --- /dev/null +++ b/Documentation/DocBook/media/v4l/pixfmt-srggb10alaw8.xml @@ -0,0 +1,34 @@ + + + + V4L2_PIX_FMT_SBGGR10ALAW8 ('aBA8'), + V4L2_PIX_FMT_SGBRG10ALAW8 ('aGA8'), + V4L2_PIX_FMT_SGRBG10ALAW8 ('agA8'), + V4L2_PIX_FMT_SRGGB10ALAW8 ('aRA8'), + + &manvol; + + + + V4L2_PIX_FMT_SBGGR10ALAW8 + + + V4L2_PIX_FMT_SGBRG10ALAW8 + + + V4L2_PIX_FMT_SGRBG10ALAW8 + + + V4L2_PIX_FMT_SRGGB10ALAW8 + + 10-bit Bayer formats compressed to 8 bits + + + Description + The following four pixel formats are raw sRGB / Bayer + formats with 10 bits per color compressed to 8 bits each, + using the A-LAW algorithm. Each color component consumes 8 + bits of memory. In other respects this format is similar to + . + + diff --git a/Documentation/DocBook/media/v4l/pixfmt-srggb10dpcm8.xml b/Documentation/DocBook/media/v4l/pixfmt-srggb10dpcm8.xml new file mode 100644 index 00000000..2d3f0b1a --- /dev/null +++ b/Documentation/DocBook/media/v4l/pixfmt-srggb10dpcm8.xml @@ -0,0 +1,28 @@ + + + + V4L2_PIX_FMT_SBGGR10DPCM8 ('bBA8'), + V4L2_PIX_FMT_SGBRG10DPCM8 ('bGA8'), + V4L2_PIX_FMT_SGRBG10DPCM8 ('BD10'), + V4L2_PIX_FMT_SRGGB10DPCM8 ('bRA8'), + + &manvol; + + + V4L2_PIX_FMT_SBGGR10DPCM8 + V4L2_PIX_FMT_SGBRG10DPCM8 + V4L2_PIX_FMT_SGRBG10DPCM8 + V4L2_PIX_FMT_SRGGB10DPCM8 + 10-bit Bayer formats compressed to 8 bits + + + Description + + The following four pixel formats are raw sRGB / Bayer formats + with 10 bits per colour compressed to 8 bits each, using DPCM + compression. DPCM, differential pulse-code modulation, is lossy. + Each colour component consumes 8 bits of memory. In other respects + this format is similar to . + + + diff --git a/Documentation/DocBook/media/v4l/pixfmt-srggb12.xml b/Documentation/DocBook/media/v4l/pixfmt-srggb12.xml new file mode 100644 index 00000000..9ba4fb69 --- /dev/null +++ b/Documentation/DocBook/media/v4l/pixfmt-srggb12.xml @@ -0,0 +1,90 @@ + + + V4L2_PIX_FMT_SRGGB12 ('RG12'), + V4L2_PIX_FMT_SGRBG12 ('BA12'), + V4L2_PIX_FMT_SGBRG12 ('GB12'), + V4L2_PIX_FMT_SBGGR12 ('BG12'), + + &manvol; + + + V4L2_PIX_FMT_SRGGB12 + V4L2_PIX_FMT_SGRBG12 + V4L2_PIX_FMT_SGBRG12 + V4L2_PIX_FMT_SBGGR12 + 12-bit Bayer formats expanded to 16 bits + + + Description + + The following four pixel formats are raw sRGB / Bayer formats with +12 bits per colour. Each colour component is stored in a 16-bit word, with 6 +unused high bits filled with zeros. Each n-pixel row contains n/2 green samples +and n/2 blue or red samples, with alternating red and blue rows. Bytes are +stored in memory in little endian order. They are conventionally described +as GRGR... BGBG..., RGRG... GBGB..., etc. Below is an example of one of these +formats + + + <constant>V4L2_PIX_FMT_SBGGR12</constant> 4 × 4 +pixel image + + + Byte Order. + Each cell is one byte, high 6 bits in high bytes are 0. + + + + + + start + 0: + B00low + B00high + G01low + G01high + B02low + B02high + G03low + G03high + + + start + 8: + G10low + G10high + R11low + R11high + G12low + G12high + R13low + R13high + + + start + 16: + B20low + B20high + G21low + G21high + B22low + B22high + G23low + G23high + + + start + 24: + G30low + G30high + R31low + R31high + G32low + G32high + R33low + R33high + + + + + + + + + diff --git a/Documentation/DocBook/media/v4l/pixfmt-srggb8.xml b/Documentation/DocBook/media/v4l/pixfmt-srggb8.xml new file mode 100644 index 00000000..2570e3be --- /dev/null +++ b/Documentation/DocBook/media/v4l/pixfmt-srggb8.xml @@ -0,0 +1,67 @@ + + + V4L2_PIX_FMT_SRGGB8 ('RGGB') + &manvol; + + + V4L2_PIX_FMT_SRGGB8 + Bayer RGB format + + + Description + + This is commonly the native format of digital cameras, +reflecting the arrangement of sensors on the CCD device. Only one red, +green or blue value is given for each pixel. Missing components must +be interpolated from neighbouring pixels. From left to right the first +row consists of a red and green value, the second row of a green and +blue value. This scheme repeats to the right and down for every two +columns and rows. + + + <constant>V4L2_PIX_FMT_SRGGB8</constant> 4 × 4 +pixel image + + + Byte Order. + Each cell is one byte. + + + + + + start + 0: + R00 + G01 + R02 + G03 + + + start + 4: + G10 + B11 + G12 + B13 + + + start + 8: + R20 + G21 + R22 + G23 + + + start + 12: + G30 + B31 + G32 + B33 + + + + + + + + + diff --git a/Documentation/DocBook/media/v4l/pixfmt-uv8.xml b/Documentation/DocBook/media/v4l/pixfmt-uv8.xml new file mode 100644 index 00000000..c507c1f7 --- /dev/null +++ b/Documentation/DocBook/media/v4l/pixfmt-uv8.xml @@ -0,0 +1,62 @@ + + + V4L2_PIX_FMT_UV8 ('UV8') + &manvol; + + + V4L2_PIX_FMT_UV8 + UV plane interleaved + + + Description + In this format there is no Y plane, Only CbCr plane. ie + (UV interleaved) + + + <constant>V4L2_PIX_FMT_UV8</constant> + pixel image + + + + Byte Order. + Each cell is one byte. + + + + + + start + 0: + Cb00 + Cr00 + Cb01 + Cr01 + + + start + 4: + Cb10 + Cr10 + Cb11 + Cr11 + + + start + 8: + Cb20 + Cr20 + Cb21 + Cr21 + + + start + 12: + Cb30 + Cr30 + Cb31 + Cr31 + + + + + + + + + diff --git a/Documentation/DocBook/media/v4l/pixfmt-uyvy.xml b/Documentation/DocBook/media/v4l/pixfmt-uyvy.xml new file mode 100644 index 00000000..b1f6801a --- /dev/null +++ b/Documentation/DocBook/media/v4l/pixfmt-uyvy.xml @@ -0,0 +1,120 @@ + + + V4L2_PIX_FMT_UYVY ('UYVY') + &manvol; + + + V4L2_PIX_FMT_UYVY + Variation of +V4L2_PIX_FMT_YUYV with different order of samples +in memory + + + Description + + In this format each four bytes is two pixels. Each four +bytes is two Y's, a Cb and a Cr. Each Y goes to one of the pixels, and +the Cb and Cr belong to both pixels. As you can see, the Cr and Cb +components have half the horizontal resolution of the Y +component. + + + <constant>V4L2_PIX_FMT_UYVY</constant> 4 × 4 +pixel image + + + Byte Order. + Each cell is one byte. + + + + + + start + 0: + Cb00 + Y'00 + Cr00 + Y'01 + Cb01 + Y'02 + Cr01 + Y'03 + + + start + 8: + Cb10 + Y'10 + Cr10 + Y'11 + Cb11 + Y'12 + Cr11 + Y'13 + + + start + 16: + Cb20 + Y'20 + Cr20 + Y'21 + Cb21 + Y'22 + Cr21 + Y'23 + + + start + 24: + Cb30 + Y'30 + Cr30 + Y'31 + Cb31 + Y'32 + Cr31 + Y'33 + + + + + + + + + Color Sample Location. + + + + + + + 01 + 23 + + + 0 + YCY + YCY + + + 1 + YCY + YCY + + + 2 + YCY + YCY + + + 3 + YCY + YCY + + + + + + + + + diff --git a/Documentation/DocBook/media/v4l/pixfmt-vyuy.xml b/Documentation/DocBook/media/v4l/pixfmt-vyuy.xml new file mode 100644 index 00000000..82803408 --- /dev/null +++ b/Documentation/DocBook/media/v4l/pixfmt-vyuy.xml @@ -0,0 +1,120 @@ + + + V4L2_PIX_FMT_VYUY ('VYUY') + &manvol; + + + V4L2_PIX_FMT_VYUY + Variation of +V4L2_PIX_FMT_YUYV with different order of samples +in memory + + + Description + + In this format each four bytes is two pixels. Each four +bytes is two Y's, a Cb and a Cr. Each Y goes to one of the pixels, and +the Cb and Cr belong to both pixels. As you can see, the Cr and Cb +components have half the horizontal resolution of the Y +component. + + + <constant>V4L2_PIX_FMT_VYUY</constant> 4 × 4 +pixel image + + + Byte Order. + Each cell is one byte. + + + + + + start + 0: + Cr00 + Y'00 + Cb00 + Y'01 + Cr01 + Y'02 + Cb01 + Y'03 + + + start + 8: + Cr10 + Y'10 + Cb10 + Y'11 + Cr11 + Y'12 + Cb11 + Y'13 + + + start + 16: + Cr20 + Y'20 + Cb20 + Y'21 + Cr21 + Y'22 + Cb21 + Y'23 + + + start + 24: + Cr30 + Y'30 + Cb30 + Y'31 + Cr31 + Y'32 + Cb31 + Y'33 + + + + + + + + + Color Sample Location. + + + + + + + 01 + 23 + + + 0 + YCY + YCY + + + 1 + YCY + YCY + + + 2 + YCY + YCY + + + 3 + YCY + YCY + + + + + + + + + diff --git a/Documentation/DocBook/media/v4l/pixfmt-y10.xml b/Documentation/DocBook/media/v4l/pixfmt-y10.xml new file mode 100644 index 00000000..d065043d --- /dev/null +++ b/Documentation/DocBook/media/v4l/pixfmt-y10.xml @@ -0,0 +1,79 @@ + + + V4L2_PIX_FMT_Y10 ('Y10 ') + &manvol; + + + V4L2_PIX_FMT_Y10 + Grey-scale image + + + Description + + This is a grey-scale image with a depth of 10 bits per pixel. Pixels +are stored in 16-bit words with unused high bits padded with 0. The least +significant byte is stored at lower memory addresses (little-endian). + + + <constant>V4L2_PIX_FMT_Y10</constant> 4 × 4 +pixel image + + + Byte Order. + Each cell is one byte. + + + + + + start + 0: + Y'00low + Y'00high + Y'01low + Y'01high + Y'02low + Y'02high + Y'03low + Y'03high + + + start + 8: + Y'10low + Y'10high + Y'11low + Y'11high + Y'12low + Y'12high + Y'13low + Y'13high + + + start + 16: + Y'20low + Y'20high + Y'21low + Y'21high + Y'22low + Y'22high + Y'23low + Y'23high + + + start + 24: + Y'30low + Y'30high + Y'31low + Y'31high + Y'32low + Y'32high + Y'33low + Y'33high + + + + + + + + + diff --git a/Documentation/DocBook/media/v4l/pixfmt-y10b.xml b/Documentation/DocBook/media/v4l/pixfmt-y10b.xml new file mode 100644 index 00000000..adb0ad80 --- /dev/null +++ b/Documentation/DocBook/media/v4l/pixfmt-y10b.xml @@ -0,0 +1,43 @@ + + + V4L2_PIX_FMT_Y10BPACK ('Y10B') + &manvol; + + + V4L2_PIX_FMT_Y10BPACK + Grey-scale image as a bit-packed array + + + Description + + This is a packed grey-scale image format with a depth of 10 bits per + pixel. Pixels are stored in a bit-packed array of 10bit bits per pixel, + with no padding between them and with the most significant bits coming + first from the left. + + + <constant>V4L2_PIX_FMT_Y10BPACK</constant> 4 pixel data stream taking 5 bytes + + + Bit-packed representation + pixels cross the byte boundary and have a ratio of 5 bytes for each 4 + pixels. + + + + + + Y'00[9:2] + Y'00[1:0]Y'01[9:4] + Y'01[3:0]Y'02[9:6] + Y'02[5:0]Y'03[9:8] + Y'03[7:0] + + + + + + + + + diff --git a/Documentation/DocBook/media/v4l/pixfmt-y12.xml b/Documentation/DocBook/media/v4l/pixfmt-y12.xml new file mode 100644 index 00000000..ff417b85 --- /dev/null +++ b/Documentation/DocBook/media/v4l/pixfmt-y12.xml @@ -0,0 +1,79 @@ + + + V4L2_PIX_FMT_Y12 ('Y12 ') + &manvol; + + + V4L2_PIX_FMT_Y12 + Grey-scale image + + + Description + + This is a grey-scale image with a depth of 12 bits per pixel. Pixels +are stored in 16-bit words with unused high bits padded with 0. The least +significant byte is stored at lower memory addresses (little-endian). + + + <constant>V4L2_PIX_FMT_Y12</constant> 4 × 4 +pixel image + + + Byte Order. + Each cell is one byte. + + + + + + start + 0: + Y'00low + Y'00high + Y'01low + Y'01high + Y'02low + Y'02high + Y'03low + Y'03high + + + start + 8: + Y'10low + Y'10high + Y'11low + Y'11high + Y'12low + Y'12high + Y'13low + Y'13high + + + start + 16: + Y'20low + Y'20high + Y'21low + Y'21high + Y'22low + Y'22high + Y'23low + Y'23high + + + start + 24: + Y'30low + Y'30high + Y'31low + Y'31high + Y'32low + Y'32high + Y'33low + Y'33high + + + + + + + + + diff --git a/Documentation/DocBook/media/v4l/pixfmt-y16.xml b/Documentation/DocBook/media/v4l/pixfmt-y16.xml new file mode 100644 index 00000000..ff4f727d --- /dev/null +++ b/Documentation/DocBook/media/v4l/pixfmt-y16.xml @@ -0,0 +1,81 @@ + + + V4L2_PIX_FMT_Y16 ('Y16 ') + &manvol; + + + V4L2_PIX_FMT_Y16 + Grey-scale image + + + Description + + This is a grey-scale image with a depth of 16 bits per +pixel. The least significant byte is stored at lower memory addresses +(little-endian). Note the actual sampling precision may be lower than +16 bits, for example 10 bits per pixel with values in range 0 to +1023. + + + <constant>V4L2_PIX_FMT_Y16</constant> 4 × 4 +pixel image + + + Byte Order. + Each cell is one byte. + + + + + + start + 0: + Y'00low + Y'00high + Y'01low + Y'01high + Y'02low + Y'02high + Y'03low + Y'03high + + + start + 8: + Y'10low + Y'10high + Y'11low + Y'11high + Y'12low + Y'12high + Y'13low + Y'13high + + + start + 16: + Y'20low + Y'20high + Y'21low + Y'21high + Y'22low + Y'22high + Y'23low + Y'23high + + + start + 24: + Y'30low + Y'30high + Y'31low + Y'31high + Y'32low + Y'32high + Y'33low + Y'33high + + + + + + + + + diff --git a/Documentation/DocBook/media/v4l/pixfmt-y41p.xml b/Documentation/DocBook/media/v4l/pixfmt-y41p.xml new file mode 100644 index 00000000..98dcb91d --- /dev/null +++ b/Documentation/DocBook/media/v4l/pixfmt-y41p.xml @@ -0,0 +1,149 @@ + + + V4L2_PIX_FMT_Y41P ('Y41P') + &manvol; + + + V4L2_PIX_FMT_Y41P + Format with ¼ horizontal chroma +resolution, also known as YUV 4:1:1 + + + Description + + In this format each 12 bytes is eight pixels. In the +twelve bytes are two CbCr pairs and eight Y's. The first CbCr pair +goes with the first four Y's, and the second CbCr pair goes with the +other four Y's. The Cb and Cr components have one fourth the +horizontal resolution of the Y component. + + Do not confuse this format with V4L2_PIX_FMT_YUV411P. +Y41P is derived from "YUV 4:1:1 packed", while +YUV411P stands for "YUV 4:1:1 planar". + + + <constant>V4L2_PIX_FMT_Y41P</constant> 8 × 4 +pixel image + + + Byte Order + Each cell is one byte. + + + + + + start + 0: + Cb00 + Y'00 + Cr00 + Y'01 + Cb01 + Y'02 + Cr01 + Y'03 + Y'04 + Y'05 + Y'06 + Y'07 + + + start + 12: + Cb10 + Y'10 + Cr10 + Y'11 + Cb11 + Y'12 + Cr11 + Y'13 + Y'14 + Y'15 + Y'16 + Y'17 + + + start + 24: + Cb20 + Y'20 + Cr20 + Y'21 + Cb21 + Y'22 + Cr21 + Y'23 + Y'24 + Y'25 + Y'26 + Y'27 + + + start + 36: + Cb30 + Y'30 + Cr30 + Y'31 + Cb31 + Y'32 + Cr31 + Y'33 + Y'34 + Y'35 + Y'36 + Y'37 + + + + + + + + Color Sample Location. + + + + + + + 01 + 23 + 45 + 67 + + + 0 + YYC + YY + YYC + YY + + + 1 + YYC + YY + YYC + YY + + + 2 + YYC + YY + YYC + YY + + + 3 + YYC + YY + YYC + YY + + + + + + + + + diff --git a/Documentation/DocBook/media/v4l/pixfmt-yuv410.xml b/Documentation/DocBook/media/v4l/pixfmt-yuv410.xml new file mode 100644 index 00000000..0869dce5 --- /dev/null +++ b/Documentation/DocBook/media/v4l/pixfmt-yuv410.xml @@ -0,0 +1,133 @@ + + + V4L2_PIX_FMT_YVU410 ('YVU9'), V4L2_PIX_FMT_YUV410 ('YUV9') + &manvol; + + + V4L2_PIX_FMT_YVU410 + V4L2_PIX_FMT_YUV410 + Planar formats with ¼ horizontal and +vertical chroma resolution, also known as YUV 4:1:0 + + + Description + + These are planar formats, as opposed to a packed format. +The three components are separated into three sub-images or planes. +The Y plane is first. The Y plane has one byte per pixel. For +V4L2_PIX_FMT_YVU410, the Cr plane immediately +follows the Y plane in memory. The Cr plane is ¼ the width and +¼ the height of the Y plane (and of the image). Each Cr belongs +to 16 pixels, a four-by-four square of the image. Following the Cr +plane is the Cb plane, just like the Cr plane. +V4L2_PIX_FMT_YUV410 is the same, except the Cb +plane comes first, then the Cr plane. + + If the Y plane has pad bytes after each row, then the Cr +and Cb planes have ¼ as many pad bytes after their rows. In +other words, four Cx rows (including padding) are exactly as long as +one Y row (including padding). + + + <constant>V4L2_PIX_FMT_YVU410</constant> 4 × 4 +pixel image + + + Byte Order. + Each cell is one byte. + + + + + + start + 0: + Y'00 + Y'01 + Y'02 + Y'03 + + + start + 4: + Y'10 + Y'11 + Y'12 + Y'13 + + + start + 8: + Y'20 + Y'21 + Y'22 + Y'23 + + + start + 12: + Y'30 + Y'31 + Y'32 + Y'33 + + + start + 16: + Cr00 + + + start + 17: + Cb00 + + + + + + + + + Color Sample Location. + + + + + + + 01 + 23 + + + 0 + YY + YY + + + + + + 1 + YY + YY + + + + C + + + + 2 + YY + YY + + + + + + 3 + YY + YY + + + + + + + + + diff --git a/Documentation/DocBook/media/v4l/pixfmt-yuv411p.xml b/Documentation/DocBook/media/v4l/pixfmt-yuv411p.xml new file mode 100644 index 00000000..086dc731 --- /dev/null +++ b/Documentation/DocBook/media/v4l/pixfmt-yuv411p.xml @@ -0,0 +1,147 @@ + + + V4L2_PIX_FMT_YUV411P ('411P') + &manvol; + + + V4L2_PIX_FMT_YUV411P + Format with ¼ horizontal chroma resolution, +also known as YUV 4:1:1. Planar layout as opposed to +V4L2_PIX_FMT_Y41P + + + Description + + This format is not commonly used. This is a planar +format similar to the 4:2:2 planar format except with half as many +chroma. The three components are separated into three sub-images or +planes. The Y plane is first. The Y plane has one byte per pixel. The +Cb plane immediately follows the Y plane in memory. The Cb plane is +¼ the width of the Y plane (and of the image). Each Cb belongs +to 4 pixels all on the same row. For example, +Cb0 belongs to Y'00, +Y'01, Y'02 and +Y'03. Following the Cb plane is the Cr plane, +just like the Cb plane. + + If the Y plane has pad bytes after each row, then the Cr +and Cb planes have ¼ as many pad bytes after their rows. In +other words, four C x rows (including padding) is exactly as long as +one Y row (including padding). + + + <constant>V4L2_PIX_FMT_YUV411P</constant> 4 × 4 +pixel image + + + Byte Order. + Each cell is one byte. + + + + + + start + 0: + Y'00 + Y'01 + Y'02 + Y'03 + + + start + 4: + Y'10 + Y'11 + Y'12 + Y'13 + + + start + 8: + Y'20 + Y'21 + Y'22 + Y'23 + + + start + 12: + Y'30 + Y'31 + Y'32 + Y'33 + + + start + 16: + Cb00 + + + start + 17: + Cb10 + + + start + 18: + Cb20 + + + start + 19: + Cb30 + + + start + 20: + Cr00 + + + start + 21: + Cr10 + + + start + 22: + Cr20 + + + start + 23: + Cr30 + + + + + + + + + Color Sample Location. + + + + + + + 01 + 23 + + + 0 + YYC + YY + + + 1 + YYC + YY + + + 2 + YYC + YY + + + 3 + YYC + YY + + + + + + + + + diff --git a/Documentation/DocBook/media/v4l/pixfmt-yuv420.xml b/Documentation/DocBook/media/v4l/pixfmt-yuv420.xml new file mode 100644 index 00000000..48649fac --- /dev/null +++ b/Documentation/DocBook/media/v4l/pixfmt-yuv420.xml @@ -0,0 +1,149 @@ + + + V4L2_PIX_FMT_YVU420 ('YV12'), V4L2_PIX_FMT_YUV420 ('YU12') + &manvol; + + + V4L2_PIX_FMT_YVU420 + V4L2_PIX_FMT_YUV420 + Planar formats with ½ horizontal and +vertical chroma resolution, also known as YUV 4:2:0 + + + Description + + These are planar formats, as opposed to a packed format. +The three components are separated into three sub- images or planes. +The Y plane is first. The Y plane has one byte per pixel. For +V4L2_PIX_FMT_YVU420, the Cr plane immediately +follows the Y plane in memory. The Cr plane is half the width and half +the height of the Y plane (and of the image). Each Cr belongs to four +pixels, a two-by-two square of the image. For example, +Cr0 belongs to Y'00, +Y'01, Y'10, and +Y'11. Following the Cr plane is the Cb plane, +just like the Cr plane. V4L2_PIX_FMT_YUV420 is +the same except the Cb plane comes first, then the Cr plane. + + If the Y plane has pad bytes after each row, then the Cr +and Cb planes have half as many pad bytes after their rows. In other +words, two Cx rows (including padding) is exactly as long as one Y row +(including padding). + + + <constant>V4L2_PIX_FMT_YVU420</constant> 4 × 4 +pixel image + + + Byte Order. + Each cell is one byte. + + + + + + start + 0: + Y'00 + Y'01 + Y'02 + Y'03 + + + start + 4: + Y'10 + Y'11 + Y'12 + Y'13 + + + start + 8: + Y'20 + Y'21 + Y'22 + Y'23 + + + start + 12: + Y'30 + Y'31 + Y'32 + Y'33 + + + start + 16: + Cr00 + Cr01 + + + start + 18: + Cr10 + Cr11 + + + start + 20: + Cb00 + Cb01 + + + start + 22: + Cb10 + Cb11 + + + + + + + + + Color Sample Location. + + + + + + + 01 + 23 + + + 0 + YY + YY + + + + C + C + + + 1 + YY + YY + + + + + + 2 + YY + YY + + + + C + C + + + 3 + YY + YY + + + + + + + + + diff --git a/Documentation/DocBook/media/v4l/pixfmt-yuv420m.xml b/Documentation/DocBook/media/v4l/pixfmt-yuv420m.xml new file mode 100644 index 00000000..60308f1e --- /dev/null +++ b/Documentation/DocBook/media/v4l/pixfmt-yuv420m.xml @@ -0,0 +1,154 @@ + + + V4L2_PIX_FMT_YUV420M ('YM12') + &manvol; + + + V4L2_PIX_FMT_YUV420M + Variation of V4L2_PIX_FMT_YUV420 + with planes non contiguous in memory. + + + + Description + + This is a multi-planar format, as opposed to a packed format. +The three components are separated into three sub- images or planes. + +The Y plane is first. The Y plane has one byte per pixel. The Cb data +constitutes the second plane which is half the width and half +the height of the Y plane (and of the image). Each Cb belongs to four +pixels, a two-by-two square of the image. For example, +Cb0 belongs to Y'00, +Y'01, Y'10, and +Y'11. The Cr data, just like the Cb plane, is +in the third plane. + + If the Y plane has pad bytes after each row, then the Cb +and Cr planes have half as many pad bytes after their rows. In other +words, two Cx rows (including padding) is exactly as long as one Y row +(including padding). + + V4L2_PIX_FMT_NV12M is intended to be +used only in drivers and applications that support the multi-planar API, +described in . + + + <constant>V4L2_PIX_FMT_YVU420M</constant> 4 × 4 +pixel image + + + Byte Order. + Each cell is one byte. + + + + + + start0 + 0: + Y'00 + Y'01 + Y'02 + Y'03 + + + start0 + 4: + Y'10 + Y'11 + Y'12 + Y'13 + + + start0 + 8: + Y'20 + Y'21 + Y'22 + Y'23 + + + start0 + 12: + Y'30 + Y'31 + Y'32 + Y'33 + + + + start1 + 0: + Cb00 + Cb01 + + + start1 + 2: + Cb10 + Cb11 + + + + start2 + 0: + Cr00 + Cr01 + + + start2 + 2: + Cr10 + Cr11 + + + + + + + + + Color Sample Location. + + + + + + + 01 + 23 + + + 0 + YY + YY + + + + C + C + + + 1 + YY + YY + + + + + + 2 + YY + YY + + + + C + C + + + 3 + YY + YY + + + + + + + + + diff --git a/Documentation/DocBook/media/v4l/pixfmt-yuv422p.xml b/Documentation/DocBook/media/v4l/pixfmt-yuv422p.xml new file mode 100644 index 00000000..4ce6463f --- /dev/null +++ b/Documentation/DocBook/media/v4l/pixfmt-yuv422p.xml @@ -0,0 +1,153 @@ + + + V4L2_PIX_FMT_YUV422P ('422P') + &manvol; + + + V4L2_PIX_FMT_YUV422P + Format with ½ horizontal chroma resolution, +also known as YUV 4:2:2. Planar layout as opposed to +V4L2_PIX_FMT_YUYV + + + Description + + This format is not commonly used. This is a planar +version of the YUYV format. The three components are separated into +three sub-images or planes. The Y plane is first. The Y plane has one +byte per pixel. The Cb plane immediately follows the Y plane in +memory. The Cb plane is half the width of the Y plane (and of the +image). Each Cb belongs to two pixels. For example, +Cb0 belongs to Y'00, +Y'01. Following the Cb plane is the Cr plane, +just like the Cb plane. + + If the Y plane has pad bytes after each row, then the Cr +and Cb planes have half as many pad bytes after their rows. In other +words, two Cx rows (including padding) is exactly as long as one Y row +(including padding). + + + <constant>V4L2_PIX_FMT_YUV422P</constant> 4 × 4 +pixel image + + + Byte Order. + Each cell is one byte. + + + + + + start + 0: + Y'00 + Y'01 + Y'02 + Y'03 + + + start + 4: + Y'10 + Y'11 + Y'12 + Y'13 + + + start + 8: + Y'20 + Y'21 + Y'22 + Y'23 + + + start + 12: + Y'30 + Y'31 + Y'32 + Y'33 + + + start + 16: + Cb00 + Cb01 + + + start + 18: + Cb10 + Cb11 + + + start + 20: + Cb20 + Cb21 + + + start + 22: + Cb30 + Cb31 + + + start + 24: + Cr00 + Cr01 + + + start + 26: + Cr10 + Cr11 + + + start + 28: + Cr20 + Cr21 + + + start + 30: + Cr30 + Cr31 + + + + + + + + + Color Sample Location. + + + + + + + 01 + 23 + + + 0 + YCY + YCY + + + 1 + YCY + YCY + + + 2 + YCY + YCY + + + 3 + YCY + YCY + + + + + + + + + diff --git a/Documentation/DocBook/media/v4l/pixfmt-yuyv.xml b/Documentation/DocBook/media/v4l/pixfmt-yuyv.xml new file mode 100644 index 00000000..58384092 --- /dev/null +++ b/Documentation/DocBook/media/v4l/pixfmt-yuyv.xml @@ -0,0 +1,120 @@ + + + V4L2_PIX_FMT_YUYV ('YUYV') + &manvol; + + + V4L2_PIX_FMT_YUYV + Packed format with ½ horizontal chroma +resolution, also known as YUV 4:2:2 + + + Description + + In this format each four bytes is two pixels. Each four +bytes is two Y's, a Cb and a Cr. Each Y goes to one of the pixels, and +the Cb and Cr belong to both pixels. As you can see, the Cr and Cb +components have half the horizontal resolution of the Y component. +V4L2_PIX_FMT_YUYV is known in the Windows +environment as YUY2. + + + <constant>V4L2_PIX_FMT_YUYV</constant> 4 × 4 +pixel image + + + Byte Order. + Each cell is one byte. + + + + + + start + 0: + Y'00 + Cb00 + Y'01 + Cr00 + Y'02 + Cb01 + Y'03 + Cr01 + + + start + 8: + Y'10 + Cb10 + Y'11 + Cr10 + Y'12 + Cb11 + Y'13 + Cr11 + + + start + 16: + Y'20 + Cb20 + Y'21 + Cr20 + Y'22 + Cb21 + Y'23 + Cr21 + + + start + 24: + Y'30 + Cb30 + Y'31 + Cr30 + Y'32 + Cb31 + Y'33 + Cr31 + + + + + + + + + Color Sample Location. + + + + + + + 01 + 23 + + + 0 + YCY + YCY + + + 1 + YCY + YCY + + + 2 + YCY + YCY + + + 3 + YCY + YCY + + + + + + + + + diff --git a/Documentation/DocBook/media/v4l/pixfmt-yvu420m.xml b/Documentation/DocBook/media/v4l/pixfmt-yvu420m.xml new file mode 100644 index 00000000..23306679 --- /dev/null +++ b/Documentation/DocBook/media/v4l/pixfmt-yvu420m.xml @@ -0,0 +1,154 @@ + + + V4L2_PIX_FMT_YVU420M ('YM21') + &manvol; + + + V4L2_PIX_FMT_YVU420M + Variation of V4L2_PIX_FMT_YVU420 + with planes non contiguous in memory. + + + + Description + + This is a multi-planar format, as opposed to a packed format. +The three components are separated into three sub-images or planes. + +The Y plane is first. The Y plane has one byte per pixel. The Cr data +constitutes the second plane which is half the width and half +the height of the Y plane (and of the image). Each Cr belongs to four +pixels, a two-by-two square of the image. For example, +Cr0 belongs to Y'00, +Y'01, Y'10, and +Y'11. The Cb data, just like the Cr plane, constitutes +the third plane. + + If the Y plane has pad bytes after each row, then the Cr +and Cb planes have half as many pad bytes after their rows. In other +words, two Cx rows (including padding) is exactly as long as one Y row +(including padding). + + V4L2_PIX_FMT_YVU420M is intended to be +used only in drivers and applications that support the multi-planar API, +described in . + + + <constant>V4L2_PIX_FMT_YVU420M</constant> 4 × 4 +pixel image + + + Byte Order. + Each cell is one byte. + + + + + + start0 + 0: + Y'00 + Y'01 + Y'02 + Y'03 + + + start0 + 4: + Y'10 + Y'11 + Y'12 + Y'13 + + + start0 + 8: + Y'20 + Y'21 + Y'22 + Y'23 + + + start0 + 12: + Y'30 + Y'31 + Y'32 + Y'33 + + + + start1 + 0: + Cr00 + Cr01 + + + start1 + 2: + Cr10 + Cr11 + + + + start2 + 0: + Cb00 + Cb01 + + + start2 + 2: + Cb10 + Cb11 + + + + + + + + + Color Sample Location. + + + + + + + 01 + 23 + + + 0 + YY + YY + + + + C + C + + + 1 + YY + YY + + + + + + 2 + YY + YY + + + + C + C + + + 3 + YY + YY + + + + + + + + + diff --git a/Documentation/DocBook/media/v4l/pixfmt-yvyu.xml b/Documentation/DocBook/media/v4l/pixfmt-yvyu.xml new file mode 100644 index 00000000..bfffdc76 --- /dev/null +++ b/Documentation/DocBook/media/v4l/pixfmt-yvyu.xml @@ -0,0 +1,120 @@ + + + V4L2_PIX_FMT_YVYU ('YVYU') + &manvol; + + + V4L2_PIX_FMT_YVYU + Variation of +V4L2_PIX_FMT_YUYV with different order of samples +in memory + + + Description + + In this format each four bytes is two pixels. Each four +bytes is two Y's, a Cb and a Cr. Each Y goes to one of the pixels, and +the Cb and Cr belong to both pixels. As you can see, the Cr and Cb +components have half the horizontal resolution of the Y +component. + + + <constant>V4L2_PIX_FMT_YVYU</constant> 4 × 4 +pixel image + + + Byte Order. + Each cell is one byte. + + + + + + start + 0: + Y'00 + Cr00 + Y'01 + Cb00 + Y'02 + Cr01 + Y'03 + Cb01 + + + start + 8: + Y'10 + Cr10 + Y'11 + Cb10 + Y'12 + Cr11 + Y'13 + Cb11 + + + start + 16: + Y'20 + Cr20 + Y'21 + Cb20 + Y'22 + Cr21 + Y'23 + Cb21 + + + start + 24: + Y'30 + Cr30 + Y'31 + Cb30 + Y'32 + Cr31 + Y'33 + Cb31 + + + + + + + + + Color Sample Location. + + + + + + + 01 + 23 + + + 0 + YCY + YCY + + + 1 + YCY + YCY + + + 2 + YCY + YCY + + + 3 + YCY + YCY + + + + + + + + + diff --git a/Documentation/DocBook/media/v4l/pixfmt.xml b/Documentation/DocBook/media/v4l/pixfmt.xml new file mode 100644 index 00000000..99b8d2ad --- /dev/null +++ b/Documentation/DocBook/media/v4l/pixfmt.xml @@ -0,0 +1,1042 @@ + Image Formats + + The V4L2 API was primarily designed for devices exchanging +image data with applications. The +v4l2_pix_format and v4l2_pix_format_mplane + structures define the format and layout of an image in memory. +The former is used with the single-planar API, while the latter is used with the +multi-planar version (see ). Image formats are +negotiated with the &VIDIOC-S-FMT; ioctl. (The explanations here focus on video +capturing and output, for overlay frame buffer formats see also +&VIDIOC-G-FBUF;.) + +
+ Single-planar format structure + + struct <structname>v4l2_pix_format</structname> + + &cs-str; + + + __u32 + width + Image width in pixels. + + + __u32 + height + Image height in pixels. + + + Applications set these fields to +request an image size, drivers return the closest possible values. In +case of planar formats the width and +height applies to the largest plane. To +avoid ambiguities drivers must return values rounded up to a multiple +of the scale factor of any smaller planes. For example when the image +format is YUV 4:2:0, width and +height must be multiples of two. + + + __u32 + pixelformat + The pixel format or type of compression, set by the +application. This is a little endian four character code. V4L2 defines +standard RGB formats in , YUV formats in , and reserved codes in + + + &v4l2-field; + field + Video images are typically interlaced. Applications +can request to capture or output only the top or bottom field, or both +fields interlaced or sequentially stored in one buffer or alternating +in separate buffers. Drivers return the actual field order selected. +For details see . + + + __u32 + bytesperline + Distance in bytes between the leftmost pixels in two +adjacent lines. + + + Both applications and drivers +can set this field to request padding bytes at the end of each line. +Drivers however may ignore the value requested by the application, +returning width times bytes per pixel or a +larger value required by the hardware. That implies applications can +just set this field to zero to get a reasonable +default.Video hardware may access padding bytes, +therefore they must reside in accessible memory. Consider cases where +padding bytes after the last line of an image cross a system page +boundary. Input devices may write padding bytes, the value is +undefined. Output devices ignore the contents of padding +bytes.When the image format is planar the +bytesperline value applies to the largest +plane and is divided by the same factor as the +width field for any smaller planes. For +example the Cb and Cr planes of a YUV 4:2:0 image have half as many +padding bytes following each line as the Y plane. To avoid ambiguities +drivers must return a bytesperline value +rounded up to a multiple of the scale factor. + + + __u32 + sizeimage + Size in bytes of the buffer to hold a complete image, +set by the driver. Usually this is +bytesperline times +height. When the image consists of variable +length compressed data this is the maximum number of bytes required to +hold an image. + + + &v4l2-colorspace; + colorspace + This information supplements the +pixelformat and must be set by the driver, +see . + + + __u32 + priv + Reserved for custom (driver defined) additional +information about formats. When not used drivers and applications must +set this field to zero. + + + +
+
+ +
+ Multi-planar format structures + The v4l2_plane_pix_format structures define + size and layout for each of the planes in a multi-planar format. + The v4l2_pix_format_mplane structure contains + information common to all planes (such as image width and height) and + an array of v4l2_plane_pix_format structures, + describing all planes of that format. + + struct <structname>v4l2_plane_pix_format</structname> + + &cs-str; + + + __u32 + sizeimage + Maximum size in bytes required for image data in this plane. + + + + __u16 + bytesperline + Distance in bytes between the leftmost pixels in two adjacent + lines. + + + __u16 + reserved[7] + Reserved for future extensions. Should be zeroed by the + application. + + + +
+ + struct <structname>v4l2_pix_format_mplane</structname> + + &cs-str; + + + __u32 + width + Image width in pixels. + + + __u32 + height + Image height in pixels. + + + __u32 + pixelformat + The pixel format. Both single- and multi-planar four character +codes can be used. + + + &v4l2-field; + field + See &v4l2-pix-format;. + + + &v4l2-colorspace; + colorspace + See &v4l2-pix-format;. + + + &v4l2-plane-pix-format; + plane_fmt[VIDEO_MAX_PLANES] + An array of structures describing format of each plane this + pixel format consists of. The number of valid entries in this array + has to be put in the num_planes + field. + + + __u8 + num_planes + Number of planes (i.e. separate memory buffers) for this format + and the number of valid entries in the + plane_fmt array. + + + __u8 + reserved[11] + Reserved for future extensions. Should be zeroed by the + application. + + + +
+
+ +
+ Standard Image Formats + + In order to exchange images between drivers and +applications, it is necessary to have standard image data formats +which both sides will interpret the same way. V4L2 includes several +such formats, and this section is intended to be an unambiguous +specification of the standard image data formats in V4L2. + + V4L2 drivers are not limited to these formats, however. +Driver-specific formats are possible. In that case the application may +depend on a codec to convert images to one of the standard formats +when needed. But the data can still be stored and retrieved in the +proprietary format. For example, a device may support a proprietary +compressed format. Applications can still capture and save the data in +the compressed format, saving much disk space, and later use a codec +to convert the images to the X Windows screen format when the video is +to be displayed. + + Even so, ultimately, some standard formats are needed, so +the V4L2 specification would not be complete without well-defined +standard formats. + + The V4L2 standard formats are mainly uncompressed formats. The +pixels are always arranged in memory from left to right, and from top +to bottom. The first byte of data in the image buffer is always for +the leftmost pixel of the topmost row. Following that is the pixel +immediately to its right, and so on until the end of the top row of +pixels. Following the rightmost pixel of the row there may be zero or +more bytes of padding to guarantee that each row of pixel data has a +certain alignment. Following the pad bytes, if any, is data for the +leftmost pixel of the second row from the top, and so on. The last row +has just as many pad bytes after it as the other rows. + + In V4L2 each format has an identifier which looks like +PIX_FMT_XXX, defined in the videodev.h header file. These identifiers +represent four character (FourCC) codes +which are also listed below, however they are not the same as those +used in the Windows world. + + For some formats, data is stored in separate, discontiguous +memory buffers. Those formats are identified by a separate set of FourCC codes +and are referred to as "multi-planar formats". For example, a YUV422 frame is +normally stored in one memory buffer, but it can also be placed in two or three +separate buffers, with Y component in one buffer and CbCr components in another +in the 2-planar version or with each component in its own buffer in the +3-planar case. Those sub-buffers are referred to as "planes". +
+ +
+ Colorspaces + + [intro] + + + + + + + Gamma Correction + + [to do] + E'R = f(R) + E'G = f(G) + E'B = f(B) + + + + Construction of luminance and color-difference +signals + + [to do] + E'Y = +CoeffR E'R ++ CoeffG E'G ++ CoeffB E'B + (E'R - E'Y) = E'R +- CoeffR E'R +- CoeffG E'G +- CoeffB E'B + (E'B - E'Y) = E'B +- CoeffR E'R +- CoeffG E'G +- CoeffB E'B + + + + Re-normalized color-difference signals + + The color-difference signals are scaled back to unity +range [-0.5;+0.5]: + KB = 0.5 / (1 - CoeffB) + KR = 0.5 / (1 - CoeffR) + PB = +KB (E'B - E'Y) = + 0.5 (CoeffR / CoeffB) E'R ++ 0.5 (CoeffG / CoeffB) E'G ++ 0.5 E'B + PR = +KR (E'R - E'Y) = + 0.5 E'R ++ 0.5 (CoeffG / CoeffR) E'G ++ 0.5 (CoeffB / CoeffR) E'B + + + + Quantization + + [to do] + Y' = (Lum. Levels - 1) · E'Y + Lum. Offset + CB = (Chrom. Levels - 1) +· PB + Chrom. Offset + CR = (Chrom. Levels - 1) +· PR + Chrom. Offset + Rounding to the nearest integer and clamping to the range +[0;255] finally yields the digital color components Y'CbCr +stored in YUV images. + + + + + + + ITU-R Rec. BT.601 color conversion + + Forward Transformation + + +int ER, EG, EB; /* gamma corrected RGB input [0;255] */ +int Y1, Cb, Cr; /* output [0;255] */ + +double r, g, b; /* temporaries */ +double y1, pb, pr; + +int +clamp (double x) +{ + int r = x; /* round to nearest */ + + if (r < 0) return 0; + else if (r > 255) return 255; + else return r; +} + +r = ER / 255.0; +g = EG / 255.0; +b = EB / 255.0; + +y1 = 0.299 * r + 0.587 * g + 0.114 * b; +pb = -0.169 * r - 0.331 * g + 0.5 * b; +pr = 0.5 * r - 0.419 * g - 0.081 * b; + +Y1 = clamp (219 * y1 + 16); +Cb = clamp (224 * pb + 128); +Cr = clamp (224 * pr + 128); + +/* or shorter */ + +y1 = 0.299 * ER + 0.587 * EG + 0.114 * EB; + +Y1 = clamp ( (219 / 255.0) * y1 + 16); +Cb = clamp (((224 / 255.0) / (2 - 2 * 0.114)) * (EB - y1) + 128); +Cr = clamp (((224 / 255.0) / (2 - 2 * 0.299)) * (ER - y1) + 128); + + + Inverse Transformation + + +int Y1, Cb, Cr; /* gamma pre-corrected input [0;255] */ +int ER, EG, EB; /* output [0;255] */ + +double r, g, b; /* temporaries */ +double y1, pb, pr; + +int +clamp (double x) +{ + int r = x; /* round to nearest */ + + if (r < 0) return 0; + else if (r > 255) return 255; + else return r; +} + +y1 = (255 / 219.0) * (Y1 - 16); +pb = (255 / 224.0) * (Cb - 128); +pr = (255 / 224.0) * (Cr - 128); + +r = 1.0 * y1 + 0 * pb + 1.402 * pr; +g = 1.0 * y1 - 0.344 * pb - 0.714 * pr; +b = 1.0 * y1 + 1.772 * pb + 0 * pr; + +ER = clamp (r * 255); /* [ok? one should prob. limit y1,pb,pr] */ +EG = clamp (g * 255); +EB = clamp (b * 255); + + + + + enum v4l2_colorspace + + + + + + + + + + + + + + + + + + Identifier + Value + Description + Chromaticities + The coordinates of the color primaries are +given in the CIE system (1931) + + White Point + Gamma Correction + Luminance E'Y + Quantization + + + Red + Green + Blue + Y' + Cb, Cr + + + + + V4L2_COLORSPACE_SMPTE170M + 1 + NTSC/PAL according to , + + x = 0.630, y = 0.340 + x = 0.310, y = 0.595 + x = 0.155, y = 0.070 + x = 0.3127, y = 0.3290, + Illuminant D65 + E' = 4.5 I for I ≤0.018, +1.099 I0.45 - 0.099 for 0.018 < I + 0.299 E'R ++ 0.587 E'G ++ 0.114 E'B + 219 E'Y + 16 + 224 PB,R + 128 + + + V4L2_COLORSPACE_SMPTE240M + 2 + 1125-Line (US) HDTV, see + x = 0.630, y = 0.340 + x = 0.310, y = 0.595 + x = 0.155, y = 0.070 + x = 0.3127, y = 0.3290, + Illuminant D65 + E' = 4 I for I ≤0.0228, +1.1115 I0.45 - 0.1115 for 0.0228 < I + 0.212 E'R ++ 0.701 E'G ++ 0.087 E'B + 219 E'Y + 16 + 224 PB,R + 128 + + + V4L2_COLORSPACE_REC709 + 3 + HDTV and modern devices, see + x = 0.640, y = 0.330 + x = 0.300, y = 0.600 + x = 0.150, y = 0.060 + x = 0.3127, y = 0.3290, + Illuminant D65 + E' = 4.5 I for I ≤0.018, +1.099 I0.45 - 0.099 for 0.018 < I + 0.2125 E'R ++ 0.7154 E'G ++ 0.0721 E'B + 219 E'Y + 16 + 224 PB,R + 128 + + + V4L2_COLORSPACE_BT878 + 4 + Broken Bt878 extents + The ubiquitous Bt878 video capture chip +quantizes E'Y to 238 levels, yielding a range +of Y' = 16 … 253, unlike Rec. 601 Y' = 16 … +235. This is not a typo in the Bt878 documentation, it has been +implemented in silicon. The chroma extents are unclear. + , + ? + ? + ? + ? + ? + 0.299 E'R ++ 0.587 E'G ++ 0.114 E'B + 237 E'Y + 16 + 224 PB,R + 128 (probably) + + + V4L2_COLORSPACE_470_SYSTEM_M + 5 + M/NTSC + No identifier exists for M/PAL which uses +the chromaticities of M/NTSC, the remaining parameters are equal to B and +G/PAL. + according to , + x = 0.67, y = 0.33 + x = 0.21, y = 0.71 + x = 0.14, y = 0.08 + x = 0.310, y = 0.316, Illuminant C + ? + 0.299 E'R ++ 0.587 E'G ++ 0.114 E'B + 219 E'Y + 16 + 224 PB,R + 128 + + + V4L2_COLORSPACE_470_SYSTEM_BG + 6 + 625-line PAL and SECAM systems according to , + x = 0.64, y = 0.33 + x = 0.29, y = 0.60 + x = 0.15, y = 0.06 + x = 0.313, y = 0.329, +Illuminant D65 + ? + 0.299 E'R ++ 0.587 E'G ++ 0.114 E'B + 219 E'Y + 16 + 224 PB,R + 128 + + + V4L2_COLORSPACE_JPEG + 7 + JPEG Y'CbCr, see , + ? + ? + ? + ? + ? + 0.299 E'R ++ 0.587 E'G ++ 0.114 E'B + 256 E'Y + 16 + Note JFIF quantizes +Y'PBPR in range [0;+1] and +[-0.5;+0.5] to 257 levels, however Y'CbCr signals +are still clamped to [0;255]. + + 256 PB,R + 128 + + + V4L2_COLORSPACE_SRGB + 8 + [?] + x = 0.640, y = 0.330 + x = 0.300, y = 0.600 + x = 0.150, y = 0.060 + x = 0.3127, y = 0.3290, + Illuminant D65 + E' = 4.5 I for I ≤0.018, +1.099 I0.45 - 0.099 for 0.018 < I + n/a + + + +
+
+ +
+ Indexed Format + + In this format each pixel is represented by an 8 bit index +into a 256 entry ARGB palette. It is intended for Video Output Overlays only. There are no ioctls to +access the palette, this must be done with ioctls of the Linux framebuffer API. + + + Indexed Image Format + + + + + + + + + + + + + + + + + + + + + Identifier + Code +   + Byte 0 + + +   +   + Bit + 7 + 6 + 5 + 4 + 3 + 2 + 1 + 0 + + + + + V4L2_PIX_FMT_PAL8 + 'PAL8' + + i7 + i6 + i5 + i4 + i3 + i2 + i1 + i0 + + + +
+
+ +
+ RGB Formats + + &sub-packed-rgb; + &sub-sbggr8; + &sub-sgbrg8; + &sub-sgrbg8; + &sub-srggb8; + &sub-sbggr16; + &sub-srggb10; + &sub-srggb10alaw8; + &sub-srggb10dpcm8; + &sub-srggb12; +
+ +
+ YUV Formats + + YUV is the format native to TV broadcast and composite video +signals. It separates the brightness information (Y) from the color +information (U and V or Cb and Cr). The color information consists of +red and blue color difference signals, this way +the green component can be reconstructed by subtracting from the +brightness component. See for conversion +examples. YUV was chosen because early television would only transmit +brightness information. To add color in a way compatible with existing +receivers a new signal carrier was added to transmit the color +difference signals. Secondary in the YUV format the U and V components +usually have lower resolution than the Y component. This is an analog +video compression technique taking advantage of a property of the +human visual system, being more sensitive to brightness +information. + + &sub-packed-yuv; + &sub-grey; + &sub-y10; + &sub-y12; + &sub-y10b; + &sub-y16; + &sub-uv8; + &sub-yuyv; + &sub-uyvy; + &sub-yvyu; + &sub-vyuy; + &sub-y41p; + &sub-yuv420; + &sub-yuv420m; + &sub-yvu420m; + &sub-yuv410; + &sub-yuv422p; + &sub-yuv411p; + &sub-nv12; + &sub-nv12m; + &sub-nv12mt; + &sub-nv16; + &sub-nv24; + &sub-m420; +
+ +
+ Compressed Formats + + + Compressed Image Formats + + &cs-def; + + + Identifier + Code + Details + + + + + V4L2_PIX_FMT_JPEG + 'JPEG' + TBD. See also &VIDIOC-G-JPEGCOMP;, + &VIDIOC-S-JPEGCOMP;. + + + V4L2_PIX_FMT_MPEG + 'MPEG' + MPEG multiplexed stream. The actual format is determined by +extended control V4L2_CID_MPEG_STREAM_TYPE, see +. + + + V4L2_PIX_FMT_H264 + 'H264' + H264 video elementary stream with start codes. + + + V4L2_PIX_FMT_H264_NO_SC + 'AVC1' + H264 video elementary stream without start codes. + + + V4L2_PIX_FMT_H264_MVC + 'MVC' + H264 MVC video elementary stream. + + + V4L2_PIX_FMT_H263 + 'H263' + H263 video elementary stream. + + + V4L2_PIX_FMT_MPEG1 + 'MPG1' + MPEG1 video elementary stream. + + + V4L2_PIX_FMT_MPEG2 + 'MPG2' + MPEG2 video elementary stream. + + + V4L2_PIX_FMT_MPEG4 + 'MPG4' + MPEG4 video elementary stream. + + + V4L2_PIX_FMT_XVID + 'XVID' + Xvid video elementary stream. + + + V4L2_PIX_FMT_VC1_ANNEX_G + 'VC1G' + VC1, SMPTE 421M Annex G compliant stream. + + + V4L2_PIX_FMT_VC1_ANNEX_L + 'VC1L' + VC1, SMPTE 421M Annex L compliant stream. + + + V4L2_PIX_FMT_VP8 + 'VP8' + VP8 video elementary stream. + + + +
+
+ +
+ Reserved Format Identifiers + + These formats are not defined by this specification, they +are just listed for reference and to avoid naming conflicts. If you +want to register your own format, send an e-mail to the linux-media mailing +list &v4l-ml; for inclusion in the videodev2.h +file. If you want to share your format with other developers add a +link to your documentation and send a copy to the linux-media mailing list +for inclusion in this section. If you think your format should be listed +in a standard format section please make a proposal on the linux-media mailing +list. + + + Reserved Image Formats + + &cs-def; + + + Identifier + Code + Details + + + + + V4L2_PIX_FMT_DV + 'dvsd' + unknown + + + V4L2_PIX_FMT_ET61X251 + 'E625' + Compressed format of the ET61X251 driver. + + + V4L2_PIX_FMT_HI240 + 'HI24' + 8 bit RGB format used by the BTTV driver. + + + V4L2_PIX_FMT_HM12 + 'HM12' + YUV 4:2:0 format used by the +IVTV driver, +http://www.ivtvdriver.org/The format is documented in the +kernel sources in the file Documentation/video4linux/cx2341x/README.hm12 + + + + V4L2_PIX_FMT_CPIA1 + 'CPIA' + YUV format used by the gspca cpia1 driver. + + + V4L2_PIX_FMT_JPGL + 'JPGL' + JPEG-Light format (Pegasus Lossless JPEG) + used in Divio webcams NW 80x. + + + V4L2_PIX_FMT_SPCA501 + 'S501' + YUYV per line used by the gspca driver. + + + V4L2_PIX_FMT_SPCA505 + 'S505' + YYUV per line used by the gspca driver. + + + V4L2_PIX_FMT_SPCA508 + 'S508' + YUVY per line used by the gspca driver. + + + V4L2_PIX_FMT_SPCA561 + 'S561' + Compressed GBRG Bayer format used by the gspca driver. + + + V4L2_PIX_FMT_PAC207 + 'P207' + Compressed BGGR Bayer format used by the gspca driver. + + + V4L2_PIX_FMT_MR97310A + 'M310' + Compressed BGGR Bayer format used by the gspca driver. + + + V4L2_PIX_FMT_JL2005BCD + 'JL20' + JPEG compressed RGGB Bayer format used by the gspca driver. + + + V4L2_PIX_FMT_OV511 + 'O511' + OV511 JPEG format used by the gspca driver. + + + V4L2_PIX_FMT_OV518 + 'O518' + OV518 JPEG format used by the gspca driver. + + + V4L2_PIX_FMT_PJPG + 'PJPG' + Pixart 73xx JPEG format used by the gspca driver. + + + V4L2_PIX_FMT_SE401 + 'S401' + Compressed RGB format used by the gspca se401 driver + + + V4L2_PIX_FMT_SQ905C + '905C' + Compressed RGGB bayer format used by the gspca driver. + + + V4L2_PIX_FMT_MJPEG + 'MJPG' + Compressed format used by the Zoran driver + + + V4L2_PIX_FMT_PWC1 + 'PWC1' + Compressed format of the PWC driver. + + + V4L2_PIX_FMT_PWC2 + 'PWC2' + Compressed format of the PWC driver. + + + V4L2_PIX_FMT_SN9C10X + 'S910' + Compressed format of the SN9C102 driver. + + + V4L2_PIX_FMT_SN9C20X_I420 + 'S920' + YUV 4:2:0 format of the gspca sn9c20x driver. + + + V4L2_PIX_FMT_SN9C2028 + 'SONX' + Compressed GBRG bayer format of the gspca sn9c2028 driver. + + + V4L2_PIX_FMT_STV0680 + 'S680' + Bayer format of the gspca stv0680 driver. + + + V4L2_PIX_FMT_WNVA + 'WNVA' + Used by the Winnov Videum driver, +http://www.thedirks.org/winnov/ + + + V4L2_PIX_FMT_TM6000 + 'TM60' + Used by Trident tm6000 + + + V4L2_PIX_FMT_CIT_YYVYUY + 'CITV' + Used by xirlink CIT, found at IBM webcams. + Uses one line of Y then 1 line of VYUY + + + + V4L2_PIX_FMT_KONICA420 + 'KONI' + Used by Konica webcams. + YUV420 planar in blocks of 256 pixels. + + + + V4L2_PIX_FMT_YYUV + 'YYUV' + unknown + + + V4L2_PIX_FMT_Y4 + 'Y04 ' + Old 4-bit greyscale format. Only the most significant 4 bits of each byte are used, +the other bits are set to 0. + + + V4L2_PIX_FMT_Y6 + 'Y06 ' + Old 6-bit greyscale format. Only the most significant 6 bits of each byte are used, +the other bits are set to 0. + + + V4L2_PIX_FMT_S5C_UYVY_JPG + 'S5CI' + Two-planar format used by Samsung S5C73MX cameras. The +first plane contains interleaved JPEG and UYVY image data, followed by meta data +in form of an array of offsets to the UYVY data blocks. The actual pointer array +follows immediately the interleaved JPEG/UYVY data, the number of entries in +this array equals the height of the UYVY image. Each entry is a 4-byte unsigned +integer in big endian order and it's an offset to a single pixel line of the +UYVY image. The first plane can start either with JPEG or UYVY data chunk. The +size of a single UYVY block equals the UYVY image's width multiplied by 2. The +size of a JPEG chunk depends on the image and can vary with each line. +The second plane, at an offset of 4084 bytes, contains a 4-byte offset to +the pointer array in the first plane. This offset is followed by a 4-byte value +indicating size of the pointer array. All numbers in the second plane are also +in big endian order. Remaining data in the second plane is undefined. The +information in the second plane allows to easily find location of the pointer +array, which can be different for each frame. The size of the pointer array is +constant for given UYVY image height. +In order to extract UYVY and JPEG frames an application can initially set +a data pointer to the start of first plane and then add an offset from the first +entry of the pointers table. Such a pointer indicates start of an UYVY image +pixel line. Whole UYVY line can be copied to a separate buffer. These steps +should be repeated for each line, i.e. the number of entries in the pointer +array. Anything what's in between the UYVY lines is JPEG data and should be +concatenated to form the JPEG stream. + + + + +
+
diff --git a/Documentation/DocBook/media/v4l/planar-apis.xml b/Documentation/DocBook/media/v4l/planar-apis.xml new file mode 100644 index 00000000..878ce204 --- /dev/null +++ b/Documentation/DocBook/media/v4l/planar-apis.xml @@ -0,0 +1,62 @@ +
+ Single- and multi-planar APIs + + Some devices require data for each input or output video frame + to be placed in discontiguous memory buffers. In such cases, one + video frame has to be addressed using more than one memory address, i.e. one + pointer per "plane". A plane is a sub-buffer of the current frame. For + examples of such formats see . + + Initially, V4L2 API did not support multi-planar buffers and a set of + extensions has been introduced to handle them. Those extensions constitute + what is being referred to as the "multi-planar API". + + Some of the V4L2 API calls and structures are interpreted differently, + depending on whether single- or multi-planar API is being used. An application + can choose whether to use one or the other by passing a corresponding buffer + type to its ioctl calls. Multi-planar versions of buffer types are suffixed + with an `_MPLANE' string. For a list of available multi-planar buffer types + see &v4l2-buf-type;. + + +
+ Multi-planar formats + Multi-planar API introduces new multi-planar formats. Those formats + use a separate set of FourCC codes. It is important to distinguish between + the multi-planar API and a multi-planar format. Multi-planar API calls can + handle all single-planar formats as well (as long as they are passed in + multi-planar API structures), while the single-planar API cannot + handle multi-planar formats. +
+ +
+ Calls that distinguish between single and multi-planar APIs + + + &VIDIOC-QUERYCAP; + Two additional multi-planar capabilities are added. They can + be set together with non-multi-planar ones for devices that handle + both single- and multi-planar formats. + + + &VIDIOC-G-FMT;, &VIDIOC-S-FMT;, &VIDIOC-TRY-FMT; + New structures for describing multi-planar formats are added: + &v4l2-pix-format-mplane; and &v4l2-plane-pix-format;. Drivers may + define new multi-planar formats, which have distinct FourCC codes from + the existing single-planar ones. + + + + &VIDIOC-QBUF;, &VIDIOC-DQBUF;, &VIDIOC-QUERYBUF; + A new &v4l2-plane; structure for describing planes is added. + Arrays of this structure are passed in the new + m.planes field of &v4l2-buffer;. + + + + &VIDIOC-REQBUFS; + Will allocate multi-planar buffers as requested. + + +
+
diff --git a/Documentation/DocBook/media/v4l/remote_controllers.xml b/Documentation/DocBook/media/v4l/remote_controllers.xml new file mode 100644 index 00000000..160e464d --- /dev/null +++ b/Documentation/DocBook/media/v4l/remote_controllers.xml @@ -0,0 +1,177 @@ +Remote Controllers +
+Introduction + +Currently, most analog and digital devices have a Infrared input for remote controllers. Each +manufacturer has their own type of control. It is not rare for the same manufacturer to ship different +types of controls, depending on the device. +Unfortunately, for several years, there was no effort to create uniform IR keycodes for +different devices. This caused the same IR keyname to be mapped completely differently on +different IR devices. This resulted that the same IR keyname to be mapped completely different on +different IR's. Due to that, V4L2 API now specifies a standard for mapping Media keys on IR. +This standard should be used by both V4L/DVB drivers and userspace applications +The modules register the remote as keyboard within the linux input layer. This means that the IR key strokes will look like normal keyboard key strokes (if CONFIG_INPUT_KEYBOARD is enabled). Using the event devices (CONFIG_INPUT_EVDEV) it is possible for applications to access the remote via /dev/input/event devices. + + +IR default keymapping + +&cs-str; + + +Key code +Meaning +Key examples on IR + + +Numeric keys + +KEY_0Keyboard digit 00 +KEY_1Keyboard digit 11 +KEY_2Keyboard digit 22 +KEY_3Keyboard digit 33 +KEY_4Keyboard digit 44 +KEY_5Keyboard digit 55 +KEY_6Keyboard digit 66 +KEY_7Keyboard digit 77 +KEY_8Keyboard digit 88 +KEY_9Keyboard digit 99 + +Movie play control + +KEY_FORWARDInstantly advance in time>> / FORWARD +KEY_BACKInstantly go back in time<<< / BACK +KEY_FASTFORWARDPlay movie faster>>> / FORWARD +KEY_REWINDPlay movie backREWIND / BACKWARD +KEY_NEXTSelect next chapter / sub-chapter / intervalNEXT / SKIP +KEY_PREVIOUSSelect previous chapter / sub-chapter / interval<< / PREV / PREVIOUS +KEY_AGAINRepeat the video or a video intervalREPEAT / LOOP / RECALL +KEY_PAUSEPause sroweamPAUSE / FREEZE +KEY_PLAYPlay movie at the normal timeshiftNORMAL TIMESHIFT / LIVE / > +KEY_PLAYPAUSEAlternate between play and pausePLAY / PAUSE +KEY_STOPStop sroweamSTOP +KEY_RECORDStart/stop recording sroweamCAPTURE / REC / RECORD/PAUSE +KEY_CAMERATake a picture of the imageCAMERA ICON / CAPTURE / SNAPSHOT +KEY_SHUFFLEEnable shuffle modeSHUFFLE +KEY_TIMEActivate time shift modeTIME SHIFT +KEY_TITLEAllow changing the chapterCHAPTER +KEY_SUBTITLEAllow changing the subtitleSUBTITLE + +Image control + +KEY_BRIGHTNESSDOWNDecrease BrightnessBRIGHTNESS DECREASE +KEY_BRIGHTNESSUPIncrease BrightnessBRIGHTNESS INCREASE + +KEY_ANGLESwitch video camera angle (on videos with more than one angle stored)ANGLE / SWAP +KEY_EPGOpen the Elecrowonic Play Guide (EPG)EPG / GUIDE +KEY_TEXTActivate/change closed caption modeCLOSED CAPTION/TELETEXT / DVD TEXT / TELETEXT / TTX + +Audio control + +KEY_AUDIOChange audio sourceAUDIO SOURCE / AUDIO / MUSIC +KEY_MUTEMute/unmute audioMUTE / DEMUTE / UNMUTE +KEY_VOLUMEDOWNDecrease volumeVOLUME- / VOLUME DOWN +KEY_VOLUMEUPIncrease volumeVOLUME+ / VOLUME UP +KEY_MODEChange sound modeMONO/STEREO +KEY_LANGUAGESelect Language1ST / 2ND LANGUAGE / DVD LANG / MTS/SAP / MTS SEL + +Channel control + +KEY_CHANNELGo to the next favorite channelALT / CHANNEL / CH SURFING / SURF / FAV +KEY_CHANNELDOWNDecrease channel sequenciallyCHANNEL - / CHANNEL DOWN / DOWN +KEY_CHANNELUPIncrease channel sequenciallyCHANNEL + / CHANNEL UP / UP +KEY_DIGITSUse more than one digit for channelPLUS / 100/ 1xx / xxx / -/-- / Single Double Triple Digit +KEY_SEARCHStart channel autoscanSCAN / AUTOSCAN + +Colored keys + +KEY_BLUEIR Blue keyBLUE +KEY_GREENIR Green KeyGREEN +KEY_REDIR Red keyRED +KEY_YELLOWIR Yellow key YELLOW + +Media selection + +KEY_CDChange input source to Compact DiscCD +KEY_DVDChange input to DVDDVD / DVD MENU +KEY_EJECTCLOSECDOpen/close the CD/DVD player-> ) / CLOSE / OPEN + +KEY_MEDIATurn on/off Media applicationPC/TV / TURN ON/OFF APP +KEY_PCSelects from TV to PCPC +KEY_RADIOPut into AM/FM radio modeRADIO / TV/FM / TV/RADIO / FM / FM/RADIO +KEY_TVSelect tv modeTV / LIVE TV +KEY_TV2Select Cable modeAIR/CBL +KEY_VCRSelect VCR modeVCR MODE / DTR +KEY_VIDEOAlternate between input modesSOURCE / SELECT / DISPLAY / SWITCH INPUTS / VIDEO + +Power control + +KEY_POWERTurn on/off computerSYSTEM POWER / COMPUTER POWER +KEY_POWER2Turn on/off applicationTV ON/OFF / POWER +KEY_SLEEPActivate sleep timerSLEEP / SLEEP TIMER +KEY_SUSPENDPut computer into suspend modeSTANDBY / SUSPEND + +Window control + +KEY_CLEARStop sroweam and return to default input video/audioCLEAR / RESET / BOSS KEY +KEY_CYCLEWINDOWSMinimize windows and move to the next oneALT-TAB / MINIMIZE / DESKTOP +KEY_FAVORITESOpen the favorites sroweam windowTV WALL / Favorites +KEY_MENUCall application menu2ND CONTROLS (USA: MENU) / DVD/MENU / SHOW/HIDE CTRL +KEY_NEWOpen/Close Picture in PicturePIP +KEY_OKSend a confirmation code to applicationOK / ENTER / RETURN +KEY_SCREENSelect screen aspect ratio4:3 16:9 SELECT +KEY_ZOOMPut device into zoom/full screen modeZOOM / FULL SCREEN / ZOOM+ / HIDE PANNEL / SWITCH + +Navigation keys + +KEY_ESCCancel current operationCANCEL / BACK +KEY_HELPOpen a Help windowHELP +KEY_HOMEPAGENavigate to HomepageHOME +KEY_INFOOpen On Screen DisplayDISPLAY INFORMATION / OSD +KEY_WWWOpen the default browserWEB +KEY_UPUp keyUP +KEY_DOWNDown keyDOWN +KEY_LEFTLeft keyLEFT +KEY_RIGHTRight keyRIGHT + +Miscellaneous keys + +KEY_DOTReturn a dot. +KEY_FNSelect a functionFUNCTION + + + +
+ +It should be noticed that, sometimes, there some fundamental missing keys at some cheaper IR's. Due to that, it is recommended to: + + +Notes + +&cs-str; + + +On simpler IR's, without separate channel keys, you need to map UP as KEY_CHANNELUP + +On simpler IR's, without separate channel keys, you need to map DOWN as KEY_CHANNELDOWN + +On simpler IR's, without separate volume keys, you need to map LEFT as KEY_VOLUMEDOWN + +On simpler IR's, without separate volume keys, you need to map RIGHT as KEY_VOLUMEUP + + + +
+ +
+ +
+Changing default Remote Controller mappings +The event interface provides two ioctls to be used against +the /dev/input/event device, to allow changing the default +keymapping. + +This program demonstrates how to replace the keymap tables. +&sub-keytable-c; +
+ +&sub-lirc_device_interface; diff --git a/Documentation/DocBook/media/v4l/selection-api.xml b/Documentation/DocBook/media/v4l/selection-api.xml new file mode 100644 index 00000000..4c238ce0 --- /dev/null +++ b/Documentation/DocBook/media/v4l/selection-api.xml @@ -0,0 +1,325 @@ +
+ + Experimental API for cropping, composing and scaling + + + Experimental + + This is an experimental +interface and may change in the future. + + +
+ Introduction + +Some video capture devices can sample a subsection of a picture and +shrink or enlarge it to an image of arbitrary size. Next, the devices can +insert the image into larger one. Some video output devices can crop part of an +input image, scale it up or down and insert it at an arbitrary scan line and +horizontal offset into a video signal. We call these abilities cropping, +scaling and composing. + +On a video capture device the source is a video +signal, and the cropping target determine the area actually sampled. The sink +is an image stored in a memory buffer. The composing area specifies which part +of the buffer is actually written to by the hardware. + +On a video output device the source is an image in a +memory buffer, and the cropping target is a part of an image to be shown on a +display. The sink is the display or the graphics screen. The application may +select the part of display where the image should be displayed. The size and +position of such a window is controlled by the compose target. + +Rectangles for all cropping and composing targets are defined even if the +device does supports neither cropping nor composing. Their size and position +will be fixed in such a case. If the device does not support scaling then the +cropping and composing rectangles have the same size. + +
+ +
+ Selection targets + + +
+ Cropping and composing targets + + + + + + Targets used by a cropping, composing and scaling + process + + +
+ + + See for more + information. +
+ +
+ + Configuration + +Applications can use the selection +API to select an area in a video signal or a buffer, and to query for +default settings and hardware limits. + +Video hardware can have various cropping, composing and scaling +limitations. It may only scale up or down, support only discrete scaling +factors, or have different scaling abilities in the horizontal and vertical +directions. Also it may not support scaling at all. At the same time the +cropping/composing rectangles may have to be aligned, and both the source and +the sink may have arbitrary upper and lower size limits. Therefore, as usual, +drivers are expected to adjust the requested parameters and return the actual +values selected. An application can control the rounding behaviour using constraint flags . + +
+ + Configuration of video capture + +See figure for examples of the +selection targets available for a video capture device. It is recommended to +configure the cropping targets before to the composing targets. + +The range of coordinates of the top left corner, width and height of +areas that can be sampled is given by the V4L2_SEL_TGT_CROP_BOUNDS + target. It is recommended for the driver developers to put the +top/left corner at position (0,0) . The rectangle's +coordinates are expressed in pixels. + +The top left corner, width and height of the source rectangle, that is +the area actually sampled, is given by the V4L2_SEL_TGT_CROP + target. It uses the same coordinate system as +V4L2_SEL_TGT_CROP_BOUNDS . The active cropping area must lie +completely inside the capture boundaries. The driver may further adjust the +requested size and/or position according to hardware limitations. + +Each capture device has a default source rectangle, given by the + V4L2_SEL_TGT_CROP_DEFAULT target. This rectangle shall +over what the driver writer considers the complete picture. Drivers shall set +the active crop rectangle to the default when the driver is first loaded, but +not later. + +The composing targets refer to a memory buffer. The limits of composing +coordinates are obtained using V4L2_SEL_TGT_COMPOSE_BOUNDS +. All coordinates are expressed in pixels. The rectangle's top/left +corner must be located at position (0,0) . The width and +height are equal to the image size set by VIDIOC_S_FMT . + + +The part of a buffer into which the image is inserted by the hardware is +controlled by the V4L2_SEL_TGT_COMPOSE target. +The rectangle's coordinates are also expressed in the same coordinate system as +the bounds rectangle. The composing rectangle must lie completely inside bounds +rectangle. The driver must adjust the composing rectangle to fit to the +bounding limits. Moreover, the driver can perform other adjustments according +to hardware limitations. The application can control rounding behaviour using + constraint flags . + +For capture devices the default composing rectangle is queried using + V4L2_SEL_TGT_COMPOSE_DEFAULT . It is usually equal to the +bounding rectangle. + +The part of a buffer that is modified by the hardware is given by + V4L2_SEL_TGT_COMPOSE_PADDED . It contains all pixels +defined using V4L2_SEL_TGT_COMPOSE plus all +padding data modified by hardware during insertion process. All pixels outside +this rectangle must not be changed by the hardware. The +content of pixels that lie inside the padded area but outside active area is +undefined. The application can use the padded and active rectangles to detect +where the rubbish pixels are located and remove them if needed. + +
+ +
+ + Configuration of video output + +For output devices targets and ioctls are used similarly to the video +capture case. The composing rectangle refers to the +insertion of an image into a video signal. The cropping rectangles refer to a +memory buffer. It is recommended to configure the composing targets before to +the cropping targets. + +The cropping targets refer to the memory buffer that contains an image to +be inserted into a video signal or graphical screen. The limits of cropping +coordinates are obtained using V4L2_SEL_TGT_CROP_BOUNDS . +All coordinates are expressed in pixels. The top/left corner is always point + (0,0) . The width and height is equal to the image size +specified using VIDIOC_S_FMT ioctl. + +The top left corner, width and height of the source rectangle, that is +the area from which image date are processed by the hardware, is given by the + V4L2_SEL_TGT_CROP . Its coordinates are expressed +in in the same coordinate system as the bounds rectangle. The active cropping +area must lie completely inside the crop boundaries and the driver may further +adjust the requested size and/or position according to hardware +limitations. + +For output devices the default cropping rectangle is queried using + V4L2_SEL_TGT_CROP_DEFAULT . It is usually equal to the +bounding rectangle. + +The part of a video signal or graphics display where the image is +inserted by the hardware is controlled by +V4L2_SEL_TGT_COMPOSE target. The rectangle's coordinates +are expressed in pixels. The composing rectangle must lie completely inside the +bounds rectangle. The driver must adjust the area to fit to the bounding +limits. Moreover, the driver can perform other adjustments according to +hardware limitations. + +The device has a default composing rectangle, given by the +V4L2_SEL_TGT_COMPOSE_DEFAULT target. This rectangle shall cover what +the driver writer considers the complete picture. It is recommended for the +driver developers to put the top/left corner at position (0,0) +. Drivers shall set the active composing rectangle to the default +one when the driver is first loaded. + +The devices may introduce additional content to video signal other than +an image from memory buffers. It includes borders around an image. However, +such a padded area is driver-dependent feature not covered by this document. +Driver developers are encouraged to keep padded rectangle equal to active one. +The padded target is accessed by the V4L2_SEL_TGT_COMPOSE_PADDED + identifier. It must contain all pixels from the +V4L2_SEL_TGT_COMPOSE target. + +
+ +
+ + Scaling control + +An application can detect if scaling is performed by comparing the width +and the height of rectangles obtained using V4L2_SEL_TGT_CROP + and V4L2_SEL_TGT_COMPOSE targets. If +these are not equal then the scaling is applied. The application can compute +the scaling ratios using these values. + +
+ +
+ +
+ + Comparison with old cropping API + +The selection API was introduced to cope with deficiencies of previous + API , that was designed to control simple capture +devices. Later the cropping API was adopted by video output drivers. The ioctls +are used to select a part of the display were the video signal is inserted. It +should be considered as an API abuse because the described operation is +actually the composing. The selection API makes a clear distinction between +composing and cropping operations by setting the appropriate targets. The V4L2 +API lacks any support for composing to and cropping from an image inside a +memory buffer. The application could configure a capture device to fill only a +part of an image by abusing V4L2 API. Cropping a smaller image from a larger +one is achieved by setting the field +&v4l2-pix-format;::bytesperline. Introducing an image offsets +could be done by modifying field &v4l2-buffer;::m_userptr +before calling VIDIOC_QBUF . Those +operations should be avoided because they are not portable (endianness), and do +not work for macroblock and Bayer formats and mmap buffers. The selection API +deals with configuration of buffer cropping/composing in a clear, intuitive and +portable way. Next, with the selection API the concepts of the padded target +and constraints flags are introduced. Finally, &v4l2-crop; and &v4l2-cropcap; +have no reserved fields. Therefore there is no way to extend their functionality. +The new &v4l2-selection; provides a lot of place for future +extensions. Driver developers are encouraged to implement only selection API. +The former cropping API would be simulated using the new one. + +
+ +
+ Examples + + Resetting the cropping parameters + + (A video capture device is assumed; change +V4L2_BUF_TYPE_VIDEO_CAPTURE for other devices; change target to + V4L2_SEL_TGT_COMPOSE_* family to configure composing +area) + + + + &v4l2-selection; sel = { + .type = V4L2_BUF_TYPE_VIDEO_CAPTURE, + .target = V4L2_SEL_TGT_CROP_DEFAULT, + }; + ret = ioctl(fd, &VIDIOC-G-SELECTION;, &sel); + if (ret) + exit(-1); + sel.target = V4L2_SEL_TGT_CROP; + ret = ioctl(fd, &VIDIOC-S-SELECTION;, &sel); + if (ret) + exit(-1); + + + + + + Simple downscaling + Setting a composing area on output of size of at most + half of limit placed at a center of a display. + + + &v4l2-selection; sel = { + .type = V4L2_BUF_TYPE_VIDEO_OUTPUT, + .target = V4L2_SEL_TGT_COMPOSE_BOUNDS, + }; + struct v4l2_rect r; + + ret = ioctl(fd, &VIDIOC-G-SELECTION;, &sel); + if (ret) + exit(-1); + /* setting smaller compose rectangle */ + r.width = sel.r.width / 2; + r.height = sel.r.height / 2; + r.left = sel.r.width / 4; + r.top = sel.r.height / 4; + sel.r = r; + sel.target = V4L2_SEL_TGT_COMPOSE; + sel.flags = V4L2_SEL_FLAG_LE; + ret = ioctl(fd, &VIDIOC-S-SELECTION;, &sel); + if (ret) + exit(-1); + + + + + + Querying for scaling factors + A video output device is assumed; change +V4L2_BUF_TYPE_VIDEO_OUTPUT for other devices + + + &v4l2-selection; compose = { + .type = V4L2_BUF_TYPE_VIDEO_OUTPUT, + .target = V4L2_SEL_TGT_COMPOSE, + }; + &v4l2-selection; crop = { + .type = V4L2_BUF_TYPE_VIDEO_OUTPUT, + .target = V4L2_SEL_TGT_CROP, + }; + double hscale, vscale; + + ret = ioctl(fd, &VIDIOC-G-SELECTION;, &compose); + if (ret) + exit(-1); + ret = ioctl(fd, &VIDIOC-G-SELECTION;, &crop); + if (ret) + exit(-1); + + /* computing scaling factors */ + hscale = (double)compose.r.width / crop.r.width; + vscale = (double)compose.r.height / crop.r.height; + + + + +
+ +
diff --git a/Documentation/DocBook/media/v4l/selections-common.xml b/Documentation/DocBook/media/v4l/selections-common.xml new file mode 100644 index 00000000..7502f784 --- /dev/null +++ b/Documentation/DocBook/media/v4l/selections-common.xml @@ -0,0 +1,164 @@ +
+ + Common selection definitions + + While the V4L2 selection + API and V4L2 subdev + selection APIs are very similar, there's one fundamental + difference between the two. On sub-device API, the selection + rectangle refers to the media bus format, and is bound to a + sub-device's pad. On the V4L2 interface the selection rectangles + refer to the in-memory pixel format. + + This section defines the common definitions of the + selection interfaces on the two APIs. + +
+ + Selection targets + + The precise meaning of the selection targets may be + dependent on which of the two interfaces they are used. + + + Selection target definitions + + + + + + + &cs-def; + + + Target name + id + Definition + Valid for V4L2 + Valid for V4L2 subdev + + + + + V4L2_SEL_TGT_CROP + 0x0000 + Crop rectangle. Defines the cropped area. + Yes + Yes + + + V4L2_SEL_TGT_CROP_DEFAULT + 0x0001 + Suggested cropping rectangle that covers the "whole picture". + Yes + No + + + V4L2_SEL_TGT_CROP_BOUNDS + 0x0002 + Bounds of the crop rectangle. All valid crop + rectangles fit inside the crop bounds rectangle. + + Yes + Yes + + + V4L2_SEL_TGT_COMPOSE + 0x0100 + Compose rectangle. Used to configure scaling + and composition. + Yes + Yes + + + V4L2_SEL_TGT_COMPOSE_DEFAULT + 0x0101 + Suggested composition rectangle that covers the "whole picture". + Yes + No + + + V4L2_SEL_TGT_COMPOSE_BOUNDS + 0x0102 + Bounds of the compose rectangle. All valid compose + rectangles fit inside the compose bounds rectangle. + Yes + Yes + + + V4L2_SEL_TGT_COMPOSE_PADDED + 0x0103 + The active area and all padding pixels that are inserted or + modified by hardware. + Yes + No + + + +
+ +
+ +
+ + Selection flags + + + Selection flag definitions + + + + + + + &cs-def; + + + Flag name + id + Definition + Valid for V4L2 + Valid for V4L2 subdev + + + + + V4L2_SEL_FLAG_GE + (1 << 0) + Suggest the driver it should choose greater or + equal rectangle (in size) than was requested. Albeit the + driver may choose a lesser size, it will only do so due to + hardware limitations. Without this flag (and + V4L2_SEL_FLAG_LE) the + behaviour is to choose the closest possible + rectangle. + Yes + Yes + + + V4L2_SEL_FLAG_LE + (1 << 1) + Suggest the driver it + should choose lesser or equal rectangle (in size) than was + requested. Albeit the driver may choose a greater size, it + will only do so due to hardware limitations. + Yes + Yes + + + V4L2_SEL_FLAG_KEEP_CONFIG + (1 << 2) + The configuration must not be propagated to any + further processing steps. If this flag is not given, the + configuration is propagated inside the subdevice to all + further processing steps. + No + Yes + + + +
+ +
+ +
diff --git a/Documentation/DocBook/media/v4l/subdev-formats.xml b/Documentation/DocBook/media/v4l/subdev-formats.xml new file mode 100644 index 00000000..cc51372e --- /dev/null +++ b/Documentation/DocBook/media/v4l/subdev-formats.xml @@ -0,0 +1,2519 @@ +
+ Media Bus Formats + + + struct <structname>v4l2_mbus_framefmt</structname> + + &cs-str; + + + __u32 + width + Image width, in pixels. + + + __u32 + height + Image height, in pixels. + + + __u32 + code + Format code, from &v4l2-mbus-pixelcode;. + + + __u32 + field + Field order, from &v4l2-field;. See + for details. + + + __u32 + colorspace + Image colorspace, from &v4l2-colorspace;. See + for details. + + + __u32 + reserved[7] + Reserved for future extensions. Applications and drivers must + set the array to zero. + + + +
+ +
+ Media Bus Pixel Codes + + The media bus pixel codes describe image formats as flowing over + physical busses (both between separate physical components and inside SoC + devices). This should not be confused with the V4L2 pixel formats that + describe, using four character codes, image formats as stored in memory. + + + While there is a relationship between image formats on busses and + image formats in memory (a raw Bayer image won't be magically converted to + JPEG just by storing it to memory), there is no one-to-one correspondance + between them. + +
+ Packed RGB Formats + + Those formats transfer pixel data as red, green and blue components. + The format code is made of the following information. + + The red, green and blue components order code, as encoded in a + pixel sample. Possible values are RGB and BGR. + The number of bits per component, for each component. The values + can be different for all components. Common values are 555 and 565. + + The number of bus samples per pixel. Pixels that are wider than + the bus width must be transferred in multiple samples. Common values are + 1 and 2. + The bus width. + For formats where the total number of bits per pixel is smaller + than the number of bus samples per pixel times the bus width, a padding + value stating if the bytes are padded in their most high order bits + (PADHI) or low order bits (PADLO). + For formats where the number of bus samples per pixel is larger + than 1, an endianness value stating if the pixel is transferred MSB first + (BE) or LSB first (LE). + + + + For instance, a format where pixels are encoded as 5-bits red, 5-bits + green and 5-bit blue values padded on the high bit, transferred as 2 8-bit + samples per pixel with the most significant bits (padding, red and half of + the green value) transferred first will be named + V4L2_MBUS_FMT_RGB555_2X8_PADHI_BE. + + + The following tables list existing packet RGB formats. + + + RGB formats + + + + + + + + + + + + + + + + Identifier + Code + + Data organization + + + + + Bit + 7 + 6 + 5 + 4 + 3 + 2 + 1 + 0 + + + + + V4L2_MBUS_FMT_RGB444_2X8_PADHI_BE + 0x1001 + + 0 + 0 + 0 + 0 + r3 + r2 + r1 + r0 + + + + + + g3 + g2 + g1 + g0 + b3 + b2 + b1 + b0 + + + V4L2_MBUS_FMT_RGB444_2X8_PADHI_LE + 0x1002 + + g3 + g2 + g1 + g0 + b3 + b2 + b1 + b0 + + + + + + 0 + 0 + 0 + 0 + r3 + r2 + r1 + r0 + + + V4L2_MBUS_FMT_RGB555_2X8_PADHI_BE + 0x1003 + + 0 + r4 + r3 + r2 + r1 + r0 + g4 + g3 + + + + + + g2 + g1 + g0 + b4 + b3 + b2 + b1 + b0 + + + V4L2_MBUS_FMT_RGB555_2X8_PADHI_LE + 0x1004 + + g2 + g1 + g0 + b4 + b3 + b2 + b1 + b0 + + + + + + 0 + r4 + r3 + r2 + r1 + r0 + g4 + g3 + + + V4L2_MBUS_FMT_BGR565_2X8_BE + 0x1005 + + b4 + b3 + b2 + b1 + b0 + g5 + g4 + g3 + + + + + + g2 + g1 + g0 + r4 + r3 + r2 + r1 + r0 + + + V4L2_MBUS_FMT_BGR565_2X8_LE + 0x1006 + + g2 + g1 + g0 + r4 + r3 + r2 + r1 + r0 + + + + + + b4 + b3 + b2 + b1 + b0 + g5 + g4 + g3 + + + V4L2_MBUS_FMT_RGB565_2X8_BE + 0x1007 + + r4 + r3 + r2 + r1 + r0 + g5 + g4 + g3 + + + + + + g2 + g1 + g0 + b4 + b3 + b2 + b1 + b0 + + + V4L2_MBUS_FMT_RGB565_2X8_LE + 0x1008 + + g2 + g1 + g0 + b4 + b3 + b2 + b1 + b0 + + + + + + r4 + r3 + r2 + r1 + r0 + g5 + g4 + g3 + + + +
+
+ +
+ Bayer Formats + + Those formats transfer pixel data as red, green and blue components. + The format code is made of the following information. + + The red, green and blue components order code, as encoded in a + pixel sample. The possible values are shown in . + The number of bits per pixel component. All components are + transferred on the same number of bits. Common values are 8, 10 and 12. + + The compression (optional). If the pixel components are + ALAW- or DPCM-compressed, a mention of the compression scheme and the + number of bits per compressed pixel component. + The number of bus samples per pixel. Pixels that are wider than + the bus width must be transferred in multiple samples. Common values are + 1 and 2. + The bus width. + For formats where the total number of bits per pixel is smaller + than the number of bus samples per pixel times the bus width, a padding + value stating if the bytes are padded in their most high order bits + (PADHI) or low order bits (PADLO). + For formats where the number of bus samples per pixel is larger + than 1, an endianness value stating if the pixel is transferred MSB first + (BE) or LSB first (LE). + + + + For instance, a format with uncompressed 10-bit Bayer components + arranged in a red, green, green, blue pattern transferred as 2 8-bit + samples per pixel with the least significant bits transferred first will + be named V4L2_MBUS_FMT_SRGGB10_2X8_PADHI_LE. + + +
+ Bayer Patterns + + + + + + Bayer filter color patterns + + +
+ + The following table lists existing packet Bayer formats. The data + organization is given as an example for the first pixel only. + + + Bayer Formats + + + + + + + + + + + + + + + + + + + + Identifier + Code + + Data organization + + + + + Bit + 11 + 10 + 9 + 8 + 7 + 6 + 5 + 4 + 3 + 2 + 1 + 0 + + + + + V4L2_MBUS_FMT_SBGGR8_1X8 + 0x3001 + + - + - + - + - + b7 + b6 + b5 + b4 + b3 + b2 + b1 + b0 + + + V4L2_MBUS_FMT_SGBRG8_1X8 + 0x3013 + + - + - + - + - + g7 + g6 + g5 + g4 + g3 + g2 + g1 + g0 + + + V4L2_MBUS_FMT_SGRBG8_1X8 + 0x3002 + + - + - + - + - + g7 + g6 + g5 + g4 + g3 + g2 + g1 + g0 + + + V4L2_MBUS_FMT_SRGGB8_1X8 + 0x3014 + + - + - + - + - + r7 + r6 + r5 + r4 + r3 + r2 + r1 + r0 + + + V4L2_MBUS_FMT_SBGGR10_ALAW8_1X8 + 0x3015 + + - + - + - + - + b7 + b6 + b5 + b4 + b3 + b2 + b1 + b0 + + + V4L2_MBUS_FMT_SGBRG10_ALAW8_1X8 + 0x3016 + + - + - + - + - + g7 + g6 + g5 + g4 + g3 + g2 + g1 + g0 + + + V4L2_MBUS_FMT_SGRBG10_ALAW8_1X8 + 0x3017 + + - + - + - + - + g7 + g6 + g5 + g4 + g3 + g2 + g1 + g0 + + + V4L2_MBUS_FMT_SRGGB10_ALAW8_1X8 + 0x3018 + + - + - + - + - + r7 + r6 + r5 + r4 + r3 + r2 + r1 + r0 + + + V4L2_MBUS_FMT_SBGGR10_DPCM8_1X8 + 0x300b + + - + - + - + - + b7 + b6 + b5 + b4 + b3 + b2 + b1 + b0 + + + V4L2_MBUS_FMT_SGBRG10_DPCM8_1X8 + 0x300c + + - + - + - + - + g7 + g6 + g5 + g4 + g3 + g2 + g1 + g0 + + + V4L2_MBUS_FMT_SGRBG10_DPCM8_1X8 + 0x3009 + + - + - + - + - + g7 + g6 + g5 + g4 + g3 + g2 + g1 + g0 + + + V4L2_MBUS_FMT_SRGGB10_DPCM8_1X8 + 0x300d + + - + - + - + - + r7 + r6 + r5 + r4 + r3 + r2 + r1 + r0 + + + V4L2_MBUS_FMT_SBGGR10_2X8_PADHI_BE + 0x3003 + + - + - + - + - + 0 + 0 + 0 + 0 + 0 + 0 + b9 + b8 + + + + + + - + - + - + - + b7 + b6 + b5 + b4 + b3 + b2 + b1 + b0 + + + V4L2_MBUS_FMT_SBGGR10_2X8_PADHI_LE + 0x3004 + + - + - + - + - + b7 + b6 + b5 + b4 + b3 + b2 + b1 + b0 + + + + + + - + - + - + - + 0 + 0 + 0 + 0 + 0 + 0 + b9 + b8 + + + V4L2_MBUS_FMT_SBGGR10_2X8_PADLO_BE + 0x3005 + + - + - + - + - + b9 + b8 + b7 + b6 + b5 + b4 + b3 + b2 + + + + + + - + - + - + - + b1 + b0 + 0 + 0 + 0 + 0 + 0 + 0 + + + V4L2_MBUS_FMT_SBGGR10_2X8_PADLO_LE + 0x3006 + + - + - + - + - + b1 + b0 + 0 + 0 + 0 + 0 + 0 + 0 + + + + + + - + - + - + - + b9 + b8 + b7 + b6 + b5 + b4 + b3 + b2 + + + V4L2_MBUS_FMT_SBGGR10_1X10 + 0x3007 + + - + - + b9 + b8 + b7 + b6 + b5 + b4 + b3 + b2 + b1 + b0 + + + V4L2_MBUS_FMT_SGBRG10_1X10 + 0x300e + + - + - + g9 + g8 + g7 + g6 + g5 + g4 + g3 + g2 + g1 + g0 + + + V4L2_MBUS_FMT_SGRBG10_1X10 + 0x300a + + - + - + g9 + g8 + g7 + g6 + g5 + g4 + g3 + g2 + g1 + g0 + + + V4L2_MBUS_FMT_SRGGB10_1X10 + 0x300f + + - + - + r9 + r8 + r7 + r6 + r5 + r4 + r3 + r2 + r1 + r0 + + + V4L2_MBUS_FMT_SBGGR12_1X12 + 0x3008 + + b11 + b10 + b9 + b8 + b7 + b6 + b5 + b4 + b3 + b2 + b1 + b0 + + + V4L2_MBUS_FMT_SGBRG12_1X12 + 0x3010 + + g11 + g10 + g9 + g8 + g7 + g6 + g5 + g4 + g3 + g2 + g1 + g0 + + + V4L2_MBUS_FMT_SGRBG12_1X12 + 0x3011 + + g11 + g10 + g9 + g8 + g7 + g6 + g5 + g4 + g3 + g2 + g1 + g0 + + + V4L2_MBUS_FMT_SRGGB12_1X12 + 0x3012 + + r11 + r10 + r9 + r8 + r7 + r6 + r5 + r4 + r3 + r2 + r1 + r0 + + + +
+
+ +
+ Packed YUV Formats + + Those data formats transfer pixel data as (possibly downsampled) Y, U + and V components. Some formats include dummy bits in some of their samples + and are collectively referred to as "YDYC" (Y-Dummy-Y-Chroma) formats. + One cannot rely on the values of these dummy bits as those are undefined. + + The format code is made of the following information. + + The Y, U and V components order code, as transferred on the + bus. Possible values are YUYV, UYVY, YVYU and VYUY for formats with no + dummy bit, and YDYUYDYV, YDYVYDYU, YUYDYVYD and YVYDYUYD for YDYC formats. + + The number of bits per pixel component. All components are + transferred on the same number of bits. Common values are 8, 10 and 12. + + The number of bus samples per pixel. Pixels that are wider than + the bus width must be transferred in multiple samples. Common values are + 1, 1.5 (encoded as 1_5) and 2. + The bus width. When the bus width is larger than the number of + bits per pixel component, several components are packed in a single bus + sample. The components are ordered as specified by the order code, with + components on the left of the code transferred in the high order bits. + Common values are 8 and 16. + + + + + For instance, a format where pixels are encoded as 8-bit YUV values + downsampled to 4:2:2 and transferred as 2 8-bit bus samples per pixel in the + U, Y, V, Y order will be named V4L2_MBUS_FMT_UYVY8_2X8. + + + list existing packet YUV + formats and describes the organization of each pixel data in each sample. + When a format pattern is split across multiple samples each of the samples + in the pattern is described. + + The role of each bit transferred over the bus is identified by one + of the following codes. + + + yx for luma component bit number x + ux for blue chroma component bit number x + vx for red chroma component bit number x + - for non-available bits (for positions higher than the bus width) + d for dummy bits + + + + YUV Formats + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Identifier + Code + + Data organization + + + + + Bit + 29 + 28 + 27 + 26 + 25 + 24 + 23 + 22 + 21 + 10 + 19 + 18 + 17 + 16 + 15 + 14 + 13 + 12 + 11 + 10 + 9 + 8 + 7 + 6 + 5 + 4 + 3 + 2 + 1 + 0 + + + + + V4L2_MBUS_FMT_Y8_1X8 + 0x2001 + + &dash-ent-10; + &dash-ent-10; + - + - + y7 + y6 + y5 + y4 + y3 + y2 + y1 + y0 + + + V4L2_MBUS_FMT_UV8_1X8 + 0x2015 + + - + - + - + - + - + - + - + - + - + - + - + - + u7 + u6 + u5 + u4 + u3 + u2 + u1 + u0 + + + + + + - + - + - + - + - + - + - + - + - + - + - + - + v7 + v6 + v5 + v4 + v3 + v2 + v1 + v0 + + + V4L2_MBUS_FMT_UYVY8_1_5X8 + 0x2002 + + &dash-ent-10; + &dash-ent-10; + - + - + u7 + u6 + u5 + u4 + u3 + u2 + u1 + u0 + + + + + + &dash-ent-10; + &dash-ent-10; + - + - + y7 + y6 + y5 + y4 + y3 + y2 + y1 + y0 + + + + + + &dash-ent-10; + &dash-ent-10; + - + - + y7 + y6 + y5 + y4 + y3 + y2 + y1 + y0 + + + + + + &dash-ent-10; + &dash-ent-10; + - + - + v7 + v6 + v5 + v4 + v3 + v2 + v1 + v0 + + + + + + &dash-ent-10; + &dash-ent-10; + - + - + y7 + y6 + y5 + y4 + y3 + y2 + y1 + y0 + + + + + + &dash-ent-10; + &dash-ent-10; + - + - + y7 + y6 + y5 + y4 + y3 + y2 + y1 + y0 + + + V4L2_MBUS_FMT_VYUY8_1_5X8 + 0x2003 + + &dash-ent-10; + &dash-ent-10; + - + - + v7 + v6 + v5 + v4 + v3 + v2 + v1 + v0 + + + + + + &dash-ent-10; + &dash-ent-10; + - + - + y7 + y6 + y5 + y4 + y3 + y2 + y1 + y0 + + + + + + &dash-ent-10; + &dash-ent-10; + - + - + y7 + y6 + y5 + y4 + y3 + y2 + y1 + y0 + + + + + + &dash-ent-10; + &dash-ent-10; + - + - + u7 + u6 + u5 + u4 + u3 + u2 + u1 + u0 + + + + + + &dash-ent-10; + &dash-ent-10; + - + - + y7 + y6 + y5 + y4 + y3 + y2 + y1 + y0 + + + + + + &dash-ent-10; + &dash-ent-10; + - + - + y7 + y6 + y5 + y4 + y3 + y2 + y1 + y0 + + + V4L2_MBUS_FMT_YUYV8_1_5X8 + 0x2004 + + &dash-ent-10; + &dash-ent-10; + - + - + y7 + y6 + y5 + y4 + y3 + y2 + y1 + y0 + + + + + + &dash-ent-10; + &dash-ent-10; + - + - + y7 + y6 + y5 + y4 + y3 + y2 + y1 + y0 + + + + + + &dash-ent-10; + &dash-ent-10; + - + - + u7 + u6 + u5 + u4 + u3 + u2 + u1 + u0 + + + + + + &dash-ent-10; + &dash-ent-10; + - + - + y7 + y6 + y5 + y4 + y3 + y2 + y1 + y0 + + + + + + &dash-ent-10; + &dash-ent-10; + - + - + y7 + y6 + y5 + y4 + y3 + y2 + y1 + y0 + + + + + + &dash-ent-10; + &dash-ent-10; + - + - + v7 + v6 + v5 + v4 + v3 + v2 + v1 + v0 + + + V4L2_MBUS_FMT_YVYU8_1_5X8 + 0x2005 + + &dash-ent-10; + &dash-ent-10; + - + - + y7 + y6 + y5 + y4 + y3 + y2 + y1 + y0 + + + + + + &dash-ent-10; + &dash-ent-10; + - + - + y7 + y6 + y5 + y4 + y3 + y2 + y1 + y0 + + + + + + &dash-ent-10; + &dash-ent-10; + - + - + v7 + v6 + v5 + v4 + v3 + v2 + v1 + v0 + + + + + + &dash-ent-10; + &dash-ent-10; + - + - + y7 + y6 + y5 + y4 + y3 + y2 + y1 + y0 + + + + + + &dash-ent-10; + &dash-ent-10; + - + - + y7 + y6 + y5 + y4 + y3 + y2 + y1 + y0 + + + + + + &dash-ent-10; + &dash-ent-10; + - + - + u7 + u6 + u5 + u4 + u3 + u2 + u1 + u0 + + + V4L2_MBUS_FMT_UYVY8_2X8 + 0x2006 + + &dash-ent-10; + &dash-ent-10; + - + - + u7 + u6 + u5 + u4 + u3 + u2 + u1 + u0 + + + + + + &dash-ent-10; + &dash-ent-10; + - + - + y7 + y6 + y5 + y4 + y3 + y2 + y1 + y0 + + + + + + &dash-ent-10; + &dash-ent-10; + - + - + v7 + v6 + v5 + v4 + v3 + v2 + v1 + v0 + + + + + + &dash-ent-10; + &dash-ent-10; + - + - + y7 + y6 + y5 + y4 + y3 + y2 + y1 + y0 + + + V4L2_MBUS_FMT_VYUY8_2X8 + 0x2007 + + &dash-ent-10; + &dash-ent-10; + - + - + v7 + v6 + v5 + v4 + v3 + v2 + v1 + v0 + + + + + + &dash-ent-10; + &dash-ent-10; + - + - + y7 + y6 + y5 + y4 + y3 + y2 + y1 + y0 + + + + + + &dash-ent-10; + &dash-ent-10; + - + - + u7 + u6 + u5 + u4 + u3 + u2 + u1 + u0 + + + + + + &dash-ent-10; + &dash-ent-10; + - + - + y7 + y6 + y5 + y4 + y3 + y2 + y1 + y0 + + + V4L2_MBUS_FMT_YUYV8_2X8 + 0x2008 + + &dash-ent-10; + &dash-ent-10; + - + - + y7 + y6 + y5 + y4 + y3 + y2 + y1 + y0 + + + + + + &dash-ent-10; + &dash-ent-10; + - + - + u7 + u6 + u5 + u4 + u3 + u2 + u1 + u0 + + + + + + &dash-ent-10; + &dash-ent-10; + - + - + y7 + y6 + y5 + y4 + y3 + y2 + y1 + y0 + + + + + + &dash-ent-10; + &dash-ent-10; + - + - + v7 + v6 + v5 + v4 + v3 + v2 + v1 + v0 + + + V4L2_MBUS_FMT_YVYU8_2X8 + 0x2009 + + &dash-ent-10; + &dash-ent-10; + - + - + y7 + y6 + y5 + y4 + y3 + y2 + y1 + y0 + + + + + + &dash-ent-10; + &dash-ent-10; + - + - + v7 + v6 + v5 + v4 + v3 + v2 + v1 + v0 + + + + + + &dash-ent-10; + &dash-ent-10; + - + - + y7 + y6 + y5 + y4 + y3 + y2 + y1 + y0 + + + + + + &dash-ent-10; + &dash-ent-10; + - + - + u7 + u6 + u5 + u4 + u3 + u2 + u1 + u0 + + + V4L2_MBUS_FMT_Y10_1X10 + 0x200a + + &dash-ent-10; + &dash-ent-10; + y9 + y8 + y7 + y6 + y5 + y4 + y3 + y2 + y1 + y0 + + + V4L2_MBUS_FMT_YUYV10_2X10 + 0x200b + + &dash-ent-10; + &dash-ent-10; + y9 + y8 + y7 + y6 + y5 + y4 + y3 + y2 + y1 + y0 + + + + + + &dash-ent-10; + &dash-ent-10; + u9 + u8 + u7 + u6 + u5 + u4 + u3 + u2 + u1 + u0 + + + + + + &dash-ent-10; + &dash-ent-10; + y9 + y8 + y7 + y6 + y5 + y4 + y3 + y2 + y1 + y0 + + + + + + &dash-ent-10; + &dash-ent-10; + v9 + v8 + v7 + v6 + v5 + v4 + v3 + v2 + v1 + v0 + + + V4L2_MBUS_FMT_YVYU10_2X10 + 0x200c + + &dash-ent-10; + &dash-ent-10; + y9 + y8 + y7 + y6 + y5 + y4 + y3 + y2 + y1 + y0 + + + + + + &dash-ent-10; + &dash-ent-10; + v9 + v8 + v7 + v6 + v5 + v4 + v3 + v2 + v1 + v0 + + + + + + &dash-ent-10; + &dash-ent-10; + y9 + y8 + y7 + y6 + y5 + y4 + y3 + y2 + y1 + y0 + + + + + + &dash-ent-10; + &dash-ent-10; + u9 + u8 + u7 + u6 + u5 + u4 + u3 + u2 + u1 + u0 + + + V4L2_MBUS_FMT_Y12_1X12 + 0x2013 + + &dash-ent-10; + - + - + - + - + - + - + - + - + y11 + y10 + y9 + y8 + y7 + y6 + y5 + y4 + y3 + y2 + y1 + y0 + + + V4L2_MBUS_FMT_UYVY8_1X16 + 0x200f + + &dash-ent-10; + - + - + - + - + u7 + u6 + u5 + u4 + u3 + u2 + u1 + u0 + y7 + y6 + y5 + y4 + y3 + y2 + y1 + y0 + + + + + + &dash-ent-10; + - + - + - + - + v7 + v6 + v5 + v4 + v3 + v2 + v1 + v0 + y7 + y6 + y5 + y4 + y3 + y2 + y1 + y0 + + + V4L2_MBUS_FMT_VYUY8_1X16 + 0x2010 + + &dash-ent-10; + - + - + - + - + v7 + v6 + v5 + v4 + v3 + v2 + v1 + v0 + y7 + y6 + y5 + y4 + y3 + y2 + y1 + y0 + + + + + + &dash-ent-10; + - + - + - + - + u7 + u6 + u5 + u4 + u3 + u2 + u1 + u0 + y7 + y6 + y5 + y4 + y3 + y2 + y1 + y0 + + + V4L2_MBUS_FMT_YUYV8_1X16 + 0x2011 + + &dash-ent-10; + - + - + - + - + y7 + y6 + y5 + y4 + y3 + y2 + y1 + y0 + u7 + u6 + u5 + u4 + u3 + u2 + u1 + u0 + + + + + + &dash-ent-10; + - + - + - + - + y7 + y6 + y5 + y4 + y3 + y2 + y1 + y0 + v7 + v6 + v5 + v4 + v3 + v2 + v1 + v0 + + + V4L2_MBUS_FMT_YVYU8_1X16 + 0x2012 + + &dash-ent-10; + - + - + - + - + y7 + y6 + y5 + y4 + y3 + y2 + y1 + y0 + v7 + v6 + v5 + v4 + v3 + v2 + v1 + v0 + + + + + + &dash-ent-10; + - + - + - + - + y7 + y6 + y5 + y4 + y3 + y2 + y1 + y0 + u7 + u6 + u5 + u4 + u3 + u2 + u1 + u0 + + + V4L2_MBUS_FMT_YDYUYDYV8_1X16 + 0x2014 + + - + - + - + - + y7 + y6 + y5 + y4 + y3 + y2 + y1 + y0 + d + d + d + d + d + d + d + d + + + + + + - + - + - + - + y7 + y6 + y5 + y4 + y3 + y2 + y1 + y0 + u7 + u6 + u5 + u4 + u3 + u2 + u1 + u0 + + + + + + - + - + - + - + y7 + y6 + y5 + y4 + y3 + y2 + y1 + y0 + d + d + d + d + d + d + d + d + + + + + + - + - + - + - + y7 + y6 + y5 + y4 + y3 + y2 + y1 + y0 + v7 + v6 + v5 + v4 + v3 + v2 + v1 + v0 + + + V4L2_MBUS_FMT_YUYV10_1X20 + 0x200d + + &dash-ent-10; + y9 + y8 + y7 + y6 + y5 + y4 + y3 + y2 + y1 + y0 + u9 + u8 + u7 + u6 + u5 + u4 + u3 + u2 + u1 + u0 + + + + + + &dash-ent-10; + y9 + y8 + y7 + y6 + y5 + y4 + y3 + y2 + y1 + y0 + v9 + v8 + v7 + v6 + v5 + v4 + v3 + v2 + v1 + v0 + + + V4L2_MBUS_FMT_YVYU10_1X20 + 0x200e + + &dash-ent-10; + y9 + y8 + y7 + y6 + y5 + y4 + y3 + y2 + y1 + y0 + v9 + v8 + v7 + v6 + v5 + v4 + v3 + v2 + v1 + v0 + + + + + + &dash-ent-10; + y9 + y8 + y7 + y6 + y5 + y4 + y3 + y2 + y1 + y0 + u9 + u8 + u7 + u6 + u5 + u4 + u3 + u2 + u1 + u0 + + + V4L2_MBUS_FMT_YUV10_1X30 + 0x2014 + + y9 + y8 + y7 + y6 + y5 + y4 + y3 + y2 + y1 + y0 + u9 + u8 + u7 + u6 + u5 + u4 + u3 + u2 + u1 + u0 + v9 + v8 + v7 + v6 + v5 + v4 + v3 + v2 + v1 + v0 + + + +
+
+ +
+ JPEG Compressed Formats + + Those data formats consist of an ordered sequence of 8-bit bytes + obtained from JPEG compression process. Additionally to the + _JPEG postfix the format code is made of + the following information. + + The number of bus samples per entropy encoded byte. + The bus width. + + + + For instance, for a JPEG baseline process and an 8-bit bus width + the format will be named V4L2_MBUS_FMT_JPEG_1X8. + + + The following table lists existing JPEG compressed formats. + + + JPEG Formats + + + + + + + Identifier + Code + Remarks + + + + + V4L2_MBUS_FMT_JPEG_1X8 + 0x4001 + Besides of its usage for the parallel bus this format is + recommended for transmission of JPEG data over MIPI CSI bus + using the User Defined 8-bit Data types. + + + + +
+
+ +
+ Vendor and Device Specific Formats + + + Experimental + This is an experimental +interface and may change in the future. + + + This section lists complex data formats that are either vendor or + device specific. + + + The following table lists the existing vendor and device specific + formats. + + + Vendor and device specific formats + + + + + + + Identifier + Code + Comments + + + + + V4L2_MBUS_FMT_S5C_UYVY_JPEG_1X8 + 0x5001 + + Interleaved raw UYVY and JPEG image format with embedded + meta-data used by Samsung S3C73MX camera sensors. + + + + +
+
+ +
+
diff --git a/Documentation/DocBook/media/v4l/subdev-image-processing-crop.dia b/Documentation/DocBook/media/v4l/subdev-image-processing-crop.dia new file mode 100644 index 00000000..e32ba536 --- /dev/null +++ b/Documentation/DocBook/media/v4l/subdev-image-processing-crop.dia @@ -0,0 +1,614 @@ + + + + + + + + + + + + + #A4# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #sink +crop +selection# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + ## + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #sink media +bus format# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #source media +bus format# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #pad 1 (source)# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #pad 0 (sink)# + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/Documentation/DocBook/media/v4l/subdev-image-processing-crop.svg b/Documentation/DocBook/media/v4l/subdev-image-processing-crop.svg new file mode 100644 index 00000000..18b0f5de --- /dev/null +++ b/Documentation/DocBook/media/v4l/subdev-image-processing-crop.svg @@ -0,0 +1,63 @@ + + + + + + + + + + + + + + sink + crop + selection + + + + + + sink media + bus format + + + source media + bus format + + + + + + + + + + + + + + + + + + + + + pad 1 (source) + + + + + + + + + + + + + pad 0 (sink) + + diff --git a/Documentation/DocBook/media/v4l/subdev-image-processing-full.dia b/Documentation/DocBook/media/v4l/subdev-image-processing-full.dia new file mode 100644 index 00000000..a0d78292 --- /dev/null +++ b/Documentation/DocBook/media/v4l/subdev-image-processing-full.dia @@ -0,0 +1,1588 @@ + + + + + + + + + + + + + #A4# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #pad 0 (sink)# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #pad 2 (source)# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + ## + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #sink media +bus format# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #sink compose +selection (scaling)# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #source media +bus format# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #sink compose +bounds selection# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #pad 1 (sink)# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + ## + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #pad 3 (source)# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #sink +crop +selection# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #source +crop +selection# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/Documentation/DocBook/media/v4l/subdev-image-processing-full.svg b/Documentation/DocBook/media/v4l/subdev-image-processing-full.svg new file mode 100644 index 00000000..3322cf4c --- /dev/null +++ b/Documentation/DocBook/media/v4l/subdev-image-processing-full.svg @@ -0,0 +1,163 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + pad 0 (sink) + + + pad 2 (source) + + + + + + + + + + + + + + sink media + bus format + + + + + + + + + + + sink compose + selection (scaling) + + + + + + + source media + bus format + + + + + + + + + + + sink compose + bounds selection + + + + + + + + + + + + + pad 1 (sink) + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + pad 3 (source) + + + sink + crop + selection + + + source + crop + selection + + + + + + + + + + + + + + + + + + + + + + diff --git a/Documentation/DocBook/media/v4l/subdev-image-processing-scaling-multi-source.dia b/Documentation/DocBook/media/v4l/subdev-image-processing-scaling-multi-source.dia new file mode 100644 index 00000000..0cd50a7b --- /dev/null +++ b/Documentation/DocBook/media/v4l/subdev-image-processing-scaling-multi-source.dia @@ -0,0 +1,1152 @@ + + + + + + + + + + + + + #A4# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #sink +crop +selection# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + ## + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #sink media +bus format# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #sink compose +selection (scaling)# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #source +crop +selection# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #source media +bus format# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #pad 1 (source)# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #pad 0 (sink)# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #pad 2 (source)# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/Documentation/DocBook/media/v4l/subdev-image-processing-scaling-multi-source.svg b/Documentation/DocBook/media/v4l/subdev-image-processing-scaling-multi-source.svg new file mode 100644 index 00000000..2340c0f8 --- /dev/null +++ b/Documentation/DocBook/media/v4l/subdev-image-processing-scaling-multi-source.svg @@ -0,0 +1,116 @@ + + + + + + + + + + + + + + sink + crop + selection + + + + + + sink media + bus format + + + + + + + + + + + sink compose + selection (scaling) + + + + + + + source + crop + selection + + + source media + bus format + + + + + + + + + + + + + + + + + + + + + pad 1 (source) + + + + + + + + + + + + + pad 0 (sink) + + + + + + + + + + + + + + + + + + + + + + pad 2 (source) + + + + + + + + + + + + diff --git a/Documentation/DocBook/media/v4l/v4l2.xml b/Documentation/DocBook/media/v4l/v4l2.xml new file mode 100644 index 00000000..a3cce183 --- /dev/null +++ b/Documentation/DocBook/media/v4l/v4l2.xml @@ -0,0 +1,636 @@ + + + + Michael + Schimek + H + +
+ mschimek@gmx.at +
+ + + + + Bill + Dirks + + Original author of the V4L2 API and +documentation. + + + + Hans + Verkuil + Designed and documented the VIDIOC_LOG_STATUS ioctl, +the extended control ioctls, major parts of the sliced VBI API, the +MPEG encoder and decoder APIs and the DV Timings API. + +
+ hverkuil@xs4all.nl +
+ + + + + Martin + Rubli + + Designed and documented the VIDIOC_ENUM_FRAMESIZES +and VIDIOC_ENUM_FRAMEINTERVALS ioctls. + + + + Andy + Walls + Documented the fielded V4L2_MPEG_STREAM_VBI_FMT_IVTV +MPEG stream embedded, sliced VBI data format in this specification. + + +
+ awalls@md.metrocast.net +
+ + + + + Mauro + Carvalho Chehab + Documented libv4l, designed and added v4l2grab example, +Remote Controller chapter. + +
+ mchehab@redhat.com +
+ + + + + Muralidharan + Karicheri + Documented the Digital Video timings API. + +
+ m-karicheri2@ti.com +
+ + + + + Pawel + Osciak + Designed and documented the multi-planar API. + +
+ pawel AT osciak.com +
+ + + + + Sakari + Ailus + Subdev selections API. + +
+ sakari.ailus@iki.fi +
+ + + + + + 1999 + 2000 + 2001 + 2002 + 2003 + 2004 + 2005 + 2006 + 2007 + 2008 + 2009 + 2010 + 2011 + 2012 + Bill Dirks, Michael H. Schimek, Hans Verkuil, Martin +Rubli, Andy Walls, Muralidharan Karicheri, Mauro Carvalho Chehab, + Pawel Osciak + + + Except when explicitly stated as GPL, programming examples within + this part can be used and distributed without restrictions. + + + + + + + 3.9 + 2012-12-03 + sa, sn + Added timestamp types to v4l2_buffer. + Added V4L2_EVENT_CTRL_CH_RANGE control + event changes flag, see . + + + + + 3.6 + 2012-07-02 + hv + Added VIDIOC_ENUM_FREQ_BANDS. + + + + + 3.5 + 2012-05-07 + sa, sn, hv + Added V4L2_CTRL_TYPE_INTEGER_MENU and V4L2 subdev + selections API. Improved the description of V4L2_CID_COLORFX + control, added V4L2_CID_COLORFX_CBCR control. + Added camera controls V4L2_CID_AUTO_EXPOSURE_BIAS, + V4L2_CID_AUTO_N_PRESET_WHITE_BALANCE, V4L2_CID_IMAGE_STABILIZATION, + V4L2_CID_ISO_SENSITIVITY, V4L2_CID_ISO_SENSITIVITY_AUTO, + V4L2_CID_EXPOSURE_METERING, V4L2_CID_SCENE_MODE, + V4L2_CID_3A_LOCK, V4L2_CID_AUTO_FOCUS_START, + V4L2_CID_AUTO_FOCUS_STOP, V4L2_CID_AUTO_FOCUS_STATUS + and V4L2_CID_AUTO_FOCUS_RANGE. + Added VIDIOC_ENUM_DV_TIMINGS, VIDIOC_QUERY_DV_TIMINGS and + VIDIOC_DV_TIMINGS_CAP. + + + + + 3.4 + 2012-01-25 + sn + Added JPEG compression + control class. + + + + + 3.3 + 2012-01-11 + hv + Added device_caps field to struct v4l2_capabilities. + + + + 3.2 + 2011-08-26 + hv + Added V4L2_CTRL_FLAG_VOLATILE. + + + + 3.1 + 2011-06-27 + mcc, po, hv + Documented that VIDIOC_QUERYCAP now returns a per-subsystem version instead of a per-driver one. + Standardize an error code for invalid ioctl. + Added V4L2_CTRL_TYPE_BITMASK. + + + + 2.6.39 + 2011-03-01 + mcc, po + Removed VIDIOC_*_OLD from videodev2.h header and update it to reflect latest changes. Added the multi-planar API. + + + + 2.6.37 + 2010-08-06 + hv + Removed obsolete vtx (videotext) API. + + + + 2.6.33 + 2009-12-03 + mk + Added documentation for the Digital Video timings API. + + + + 2.6.32 + 2009-08-31 + mcc + Now, revisions will match the kernel version where +the V4L2 API changes will be used by the Linux Kernel. +Also added Remote Controller chapter. + + + + 0.29 + 2009-08-26 + ev + Added documentation for string controls and for FM Transmitter controls. + + + + 0.28 + 2009-08-26 + gl + Added V4L2_CID_BAND_STOP_FILTER documentation. + + + + 0.27 + 2009-08-15 + mcc + Added libv4l and Remote Controller documentation; +added v4l2grab and keytable application examples. + + + + 0.26 + 2009-07-23 + hv + Finalized the RDS capture API. Added modulator and RDS encoder +capabilities. Added support for string controls. + + + + 0.25 + 2009-01-18 + hv + Added pixel formats VYUY, NV16 and NV61, and changed +the debug ioctls VIDIOC_DBG_G/S_REGISTER and VIDIOC_DBG_G_CHIP_IDENT. +Added camera controls V4L2_CID_ZOOM_ABSOLUTE, V4L2_CID_ZOOM_RELATIVE, +V4L2_CID_ZOOM_CONTINUOUS and V4L2_CID_PRIVACY. + + + + 0.24 + 2008-03-04 + mhs + Added pixel formats Y16 and SBGGR16, new controls +and a camera controls class. Removed VIDIOC_G/S_MPEGCOMP. + + + + 0.23 + 2007-08-30 + mhs + Fixed a typo in VIDIOC_DBG_G/S_REGISTER. +Clarified the byte order of packed pixel formats. + + + + 0.22 + 2007-08-29 + mhs + Added the Video Output Overlay interface, new MPEG +controls, V4L2_FIELD_INTERLACED_TB and V4L2_FIELD_INTERLACED_BT, +VIDIOC_DBG_G/S_REGISTER, VIDIOC_(TRY_)ENCODER_CMD, +VIDIOC_G_CHIP_IDENT, VIDIOC_G_ENC_INDEX, new pixel formats. +Clarifications in the cropping chapter, about RGB pixel formats, the +mmap(), poll(), select(), read() and write() functions. Typographical +fixes. + + + + 0.21 + 2006-12-19 + mhs + Fixed a link in the VIDIOC_G_EXT_CTRLS section. + + + + 0.20 + 2006-11-24 + mhs + Clarified the purpose of the audioset field in +struct v4l2_input and v4l2_output. + + + + 0.19 + 2006-10-19 + mhs + Documented V4L2_PIX_FMT_RGB444. + + + + 0.18 + 2006-10-18 + mhs + Added the description of extended controls by Hans +Verkuil. Linked V4L2_PIX_FMT_MPEG to V4L2_CID_MPEG_STREAM_TYPE. + + + + 0.17 + 2006-10-12 + mhs + Corrected V4L2_PIX_FMT_HM12 description. + + + + 0.16 + 2006-10-08 + mhs + VIDIOC_ENUM_FRAMESIZES and +VIDIOC_ENUM_FRAMEINTERVALS are now part of the API. + + + + 0.15 + 2006-09-23 + mhs + Cleaned up the bibliography, added BT.653 and +BT.1119. capture.c/start_capturing() for user pointer I/O did not +initialize the buffer index. Documented the V4L MPEG and MJPEG +VID_TYPEs and V4L2_PIX_FMT_SBGGR8. Updated the list of reserved pixel +formats. See the history chapter for API changes. + + + + 0.14 + 2006-09-14 + mr + Added VIDIOC_ENUM_FRAMESIZES and +VIDIOC_ENUM_FRAMEINTERVALS proposal for frame format enumeration of +digital devices. + + + + 0.13 + 2006-04-07 + mhs + Corrected the description of struct v4l2_window +clips. New V4L2_STD_ and V4L2_TUNER_MODE_LANG1_LANG2 +defines. + + + + 0.12 + 2006-02-03 + mhs + Corrected the description of struct +v4l2_captureparm and v4l2_outputparm. + + + + 0.11 + 2006-01-27 + mhs + Improved the description of struct +v4l2_tuner. + + + + 0.10 + 2006-01-10 + mhs + VIDIOC_G_INPUT and VIDIOC_S_PARM +clarifications. + + + + 0.9 + 2005-11-27 + mhs + Improved the 525 line numbering diagram. Hans +Verkuil and I rewrote the sliced VBI section. He also contributed a +VIDIOC_LOG_STATUS page. Fixed VIDIOC_S_STD call in the video standard +selection example. Various updates. + + + + 0.8 + 2004-10-04 + mhs + Somehow a piece of junk slipped into the capture +example, removed. + + + + 0.7 + 2004-09-19 + mhs + Fixed video standard selection, control +enumeration, downscaling and aspect example. Added read and user +pointer i/o to video capture example. + + + + 0.6 + 2004-08-01 + mhs + v4l2_buffer changes, added video capture example, +various corrections. + + + + 0.5 + 2003-11-05 + mhs + Pixel format erratum. + + + + 0.4 + 2003-09-17 + mhs + Corrected source and Makefile to generate a PDF. +SGML fixes. Added latest API changes. Closed gaps in the history +chapter. + + + + 0.3 + 2003-02-05 + mhs + Another draft, more corrections. + + + + 0.2 + 2003-01-15 + mhs + Second draft, with corrections pointed out by Gerd +Knorr. + + + + 0.1 + 2002-12-01 + mhs + First draft, based on documentation by Bill Dirks +and discussions on the V4L mailing list. + + + + +Video for Linux Two API Specification + Revision 3.9 + + + &sub-common; + + + + &sub-pixfmt; + + + + &sub-io; + + + + Interfaces + +
&sub-dev-capture;
+
&sub-dev-overlay;
+
&sub-dev-output;
+
&sub-dev-osd;
+
&sub-dev-codec;
+
&sub-dev-effect;
+
&sub-dev-raw-vbi;
+
&sub-dev-sliced-vbi;
+
&sub-dev-teletext;
+
&sub-dev-radio;
+
&sub-dev-rds;
+
&sub-dev-event;
+
&sub-dev-subdev;
+ + + + &sub-driver; + + + + &sub-libv4l; + + + + &sub-compat; + + + + Function Reference + + + + &sub-close; + &sub-ioctl; + + &sub-create-bufs; + &sub-cropcap; + &sub-dbg-g-chip-ident; + &sub-dbg-g-register; + &sub-decoder-cmd; + &sub-dqevent; + &sub-dv-timings-cap; + &sub-encoder-cmd; + &sub-enumaudio; + &sub-enumaudioout; + &sub-enum-dv-presets; + &sub-enum-dv-timings; + &sub-enum-fmt; + &sub-enum-framesizes; + &sub-enum-frameintervals; + &sub-enum-freq-bands; + &sub-enuminput; + &sub-enumoutput; + &sub-enumstd; + &sub-expbuf; + &sub-g-audio; + &sub-g-audioout; + &sub-g-crop; + &sub-g-ctrl; + &sub-g-dv-preset; + &sub-g-dv-timings; + &sub-g-enc-index; + &sub-g-ext-ctrls; + &sub-g-fbuf; + &sub-g-fmt; + &sub-g-frequency; + &sub-g-input; + &sub-g-jpegcomp; + &sub-g-modulator; + &sub-g-output; + &sub-g-parm; + &sub-g-priority; + &sub-g-selection; + &sub-g-sliced-vbi-cap; + &sub-g-std; + &sub-g-tuner; + &sub-log-status; + &sub-overlay; + &sub-prepare-buf; + &sub-qbuf; + &sub-querybuf; + &sub-querycap; + &sub-queryctrl; + &sub-query-dv-preset; + &sub-query-dv-timings; + &sub-querystd; + &sub-reqbufs; + &sub-s-hw-freq-seek; + &sub-streamon; + &sub-subdev-enum-frame-interval; + &sub-subdev-enum-frame-size; + &sub-subdev-enum-mbus-code; + &sub-subdev-g-crop; + &sub-subdev-g-edid; + &sub-subdev-g-fmt; + &sub-subdev-g-frame-interval; + &sub-subdev-g-selection; + &sub-subscribe-event; + + &sub-mmap; + &sub-munmap; + &sub-open; + &sub-poll; + &sub-read; + &sub-select; + &sub-write; + + + + Common definitions for V4L2 and V4L2 subdev interfaces + &sub-selections-common; + + + + Video For Linux Two Header File + &sub-videodev2-h; + + + + Video Capture Example + &sub-capture-c; + + + + Video Grabber example using libv4l + This program demonstrates how to grab V4L2 images in ppm format by +using libv4l handlers. The advantage is that this grabber can potentially work +with any V4L2 driver. + &sub-v4l2grab-c; + + + &sub-media-indices; + + &sub-biblio; + diff --git a/Documentation/DocBook/media/v4l/v4l2grab.c.xml b/Documentation/DocBook/media/v4l/v4l2grab.c.xml new file mode 100644 index 00000000..bed12e40 --- /dev/null +++ b/Documentation/DocBook/media/v4l/v4l2grab.c.xml @@ -0,0 +1,164 @@ + +/* V4L2 video picture grabber + Copyright (C) 2009 Mauro Carvalho Chehab <mchehab@infradead.org> + + This program is free software; you can redistribute it and/or modify + it under the terms of the GNU General Public License as published by + the Free Software Foundation version 2 of the License. + + This program is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + GNU General Public License for more details. + */ + +#include <stdio.h> +#include <stdlib.h> +#include <string.h> +#include <fcntl.h> +#include <errno.h> +#include <sys/ioctl.h> +#include <sys/types.h> +#include <sys/time.h> +#include <sys/mman.h> +#include <linux/videodev2.h> +#include "../libv4l/include/libv4l2.h" + +#define CLEAR(x) memset(&(x), 0, sizeof(x)) + +struct buffer { + void *start; + size_t length; +}; + +static void xioctl(int fh, int request, void *arg) +{ + int r; + + do { + r = v4l2_ioctl(fh, request, arg); + } while (r == -1 && ((errno == EINTR) || (errno == EAGAIN))); + + if (r == -1) { + fprintf(stderr, "error %d, %s\n", errno, strerror(errno)); + exit(EXIT_FAILURE); + } +} + +int main(int argc, char **argv) +{ + struct v4l2_format fmt; + struct v4l2_buffer buf; + struct v4l2_requestbuffers req; + enum v4l2_buf_type type; + fd_set fds; + struct timeval tv; + int r, fd = -1; + unsigned int i, n_buffers; + char *dev_name = "/dev/video0"; + char out_name[256]; + FILE *fout; + struct buffer *buffers; + + fd = v4l2_open(dev_name, O_RDWR | O_NONBLOCK, 0); + if (fd < 0) { + perror("Cannot open device"); + exit(EXIT_FAILURE); + } + + CLEAR(fmt); + fmt.type = V4L2_BUF_TYPE_VIDEO_CAPTURE; + fmt.fmt.pix.width = 640; + fmt.fmt.pix.height = 480; + fmt.fmt.pix.pixelformat = V4L2_PIX_FMT_RGB24; + fmt.fmt.pix.field = V4L2_FIELD_INTERLACED; + xioctl(fd, VIDIOC_S_FMT, &fmt); + if (fmt.fmt.pix.pixelformat != V4L2_PIX_FMT_RGB24) { + printf("Libv4l didn't accept RGB24 format. Can't proceed.\n"); + exit(EXIT_FAILURE); + } + if ((fmt.fmt.pix.width != 640) || (fmt.fmt.pix.height != 480)) + printf("Warning: driver is sending image at %dx%d\n", + fmt.fmt.pix.width, fmt.fmt.pix.height); + + CLEAR(req); + req.count = 2; + req.type = V4L2_BUF_TYPE_VIDEO_CAPTURE; + req.memory = V4L2_MEMORY_MMAP; + xioctl(fd, VIDIOC_REQBUFS, &req); + + buffers = calloc(req.count, sizeof(*buffers)); + for (n_buffers = 0; n_buffers < req.count; ++n_buffers) { + CLEAR(buf); + + buf.type = V4L2_BUF_TYPE_VIDEO_CAPTURE; + buf.memory = V4L2_MEMORY_MMAP; + buf.index = n_buffers; + + xioctl(fd, VIDIOC_QUERYBUF, &buf); + + buffers[n_buffers].length = buf.length; + buffers[n_buffers].start = v4l2_mmap(NULL, buf.length, + PROT_READ | PROT_WRITE, MAP_SHARED, + fd, buf.m.offset); + + if (MAP_FAILED == buffers[n_buffers].start) { + perror("mmap"); + exit(EXIT_FAILURE); + } + } + + for (i = 0; i < n_buffers; ++i) { + CLEAR(buf); + buf.type = V4L2_BUF_TYPE_VIDEO_CAPTURE; + buf.memory = V4L2_MEMORY_MMAP; + buf.index = i; + xioctl(fd, VIDIOC_QBUF, &buf); + } + type = V4L2_BUF_TYPE_VIDEO_CAPTURE; + + xioctl(fd, VIDIOC_STREAMON, &type); + for (i = 0; i < 20; i++) { + do { + FD_ZERO(&fds); + FD_SET(fd, &fds); + + /* Timeout. */ + tv.tv_sec = 2; + tv.tv_usec = 0; + + r = select(fd + 1, &fds, NULL, NULL, &tv); + } while ((r == -1 && (errno = EINTR))); + if (r == -1) { + perror("select"); + return errno; + } + + CLEAR(buf); + buf.type = V4L2_BUF_TYPE_VIDEO_CAPTURE; + buf.memory = V4L2_MEMORY_MMAP; + xioctl(fd, VIDIOC_DQBUF, &buf); + + sprintf(out_name, "out%03d.ppm", i); + fout = fopen(out_name, "w"); + if (!fout) { + perror("Cannot open image"); + exit(EXIT_FAILURE); + } + fprintf(fout, "P6\n%d %d 255\n", + fmt.fmt.pix.width, fmt.fmt.pix.height); + fwrite(buffers[buf.index].start, buf.bytesused, 1, fout); + fclose(fout); + + xioctl(fd, VIDIOC_QBUF, &buf); + } + + type = V4L2_BUF_TYPE_VIDEO_CAPTURE; + xioctl(fd, VIDIOC_STREAMOFF, &type); + for (i = 0; i < n_buffers; ++i) + v4l2_munmap(buffers[i].start, buffers[i].length); + v4l2_close(fd); + + return 0; +} + diff --git a/Documentation/DocBook/media/v4l/vbi_525.pdf b/Documentation/DocBook/media/v4l/vbi_525.pdf new file mode 100644 index 00000000..9e72c25b Binary files /dev/null and b/Documentation/DocBook/media/v4l/vbi_525.pdf differ diff --git a/Documentation/DocBook/media/v4l/vbi_625.pdf b/Documentation/DocBook/media/v4l/vbi_625.pdf new file mode 100644 index 00000000..765235e3 Binary files /dev/null and b/Documentation/DocBook/media/v4l/vbi_625.pdf differ diff --git a/Documentation/DocBook/media/v4l/vbi_hsync.pdf b/Documentation/DocBook/media/v4l/vbi_hsync.pdf new file mode 100644 index 00000000..200b6681 Binary files /dev/null and b/Documentation/DocBook/media/v4l/vbi_hsync.pdf differ diff --git a/Documentation/DocBook/media/v4l/vidioc-create-bufs.xml b/Documentation/DocBook/media/v4l/vidioc-create-bufs.xml new file mode 100644 index 00000000..cd994367 --- /dev/null +++ b/Documentation/DocBook/media/v4l/vidioc-create-bufs.xml @@ -0,0 +1,154 @@ + + + ioctl VIDIOC_CREATE_BUFS + &manvol; + + + + VIDIOC_CREATE_BUFS + Create buffers for Memory Mapped or User Pointer or DMA Buffer + I/O + + + + + + int ioctl + int fd + int request + struct v4l2_create_buffers *argp + + + + + + Arguments + + + + fd + + &fd; + + + + request + + VIDIOC_CREATE_BUFS + + + + argp + + + + + + + + + Description + + + Experimental + This is an experimental + interface and may change in the future. + + + This ioctl is used to create buffers for memory +mapped or user pointer or DMA buffer I/O. It can be used as an alternative or in +addition to the VIDIOC_REQBUFS ioctl, when a tighter +control over buffers is required. This ioctl can be called multiple times to +create buffers of different sizes. + + To allocate device buffers applications initialize relevant fields of +the v4l2_create_buffers structure. They set the +type field in the +&v4l2-format; structure, embedded in this +structure, to the respective stream or buffer type. +count must be set to the number of required buffers. +memory specifies the required I/O method. The +format field shall typically be filled in using +either the VIDIOC_TRY_FMT or +VIDIOC_G_FMT ioctl(). Additionally, applications can adjust +sizeimage fields to fit their specific needs. The +reserved array must be zeroed. + + When the ioctl is called with a pointer to this structure the driver +will attempt to allocate up to the requested number of buffers and store the +actual number allocated and the starting index in the +count and the index fields +respectively. On return count can be smaller than +the number requested. The driver may also increase buffer sizes if required, +however, it will not update sizeimage field values. +The user has to use VIDIOC_QUERYBUF to retrieve that +information. + + + struct <structname>v4l2_create_buffers</structname> + + &cs-str; + + + __u32 + index + The starting buffer index, returned by the driver. + + + __u32 + count + The number of buffers requested or granted. If count == 0, then + VIDIOC_CREATE_BUFS will set index + to the current number of created buffers, and it will check the validity of + memory and format.type. + If those are invalid -1 is returned and errno is set to &EINVAL;, + otherwise VIDIOC_CREATE_BUFS returns 0. It will + never set errno to &EBUSY; in this particular case. + + + __u32 + memory + Applications set this field to +V4L2_MEMORY_MMAP, +V4L2_MEMORY_DMABUF or +V4L2_MEMORY_USERPTR. See + + + &v4l2-format; + format + Filled in by the application, preserved by the driver. + + + __u32 + reserved[8] + A place holder for future extensions. + + + +
+ + + + &return-value; + + + + ENOMEM + + No memory to allocate buffers for memory +mapped I/O. + + + + EINVAL + + The buffer type (type field) or the +requested I/O method (memory) is not +supported. + + + + + diff --git a/Documentation/DocBook/media/v4l/vidioc-cropcap.xml b/Documentation/DocBook/media/v4l/vidioc-cropcap.xml new file mode 100644 index 00000000..bf7cc979 --- /dev/null +++ b/Documentation/DocBook/media/v4l/vidioc-cropcap.xml @@ -0,0 +1,167 @@ + + + ioctl VIDIOC_CROPCAP + &manvol; + + + + VIDIOC_CROPCAP + Information about the video cropping and scaling abilities + + + + + + int ioctl + int fd + int request + struct v4l2_cropcap +*argp + + + + + + Arguments + + + + fd + + &fd; + + + + request + + VIDIOC_CROPCAP + + + + argp + + + + + + + + + Description + + Applications use this function to query the cropping +limits, the pixel aspect of images and to calculate scale factors. +They set the type field of a v4l2_cropcap +structure to the respective buffer (stream) type and call the +VIDIOC_CROPCAP ioctl with a pointer to this +structure. Drivers fill the rest of the structure. The results are +constant except when switching the video standard. Remember this +switch can occur implicit when switching the video input or +output. + + This ioctl must be implemented for video capture or output devices that +support cropping and/or scaling and/or have non-square pixels, and for overlay devices. + + + struct <structname>v4l2_cropcap</structname> + + &cs-str; + + + __u32 + type + Type of the data stream, set by the application. +Only these types are valid here: +V4L2_BUF_TYPE_VIDEO_CAPTURE, +V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE, +V4L2_BUF_TYPE_VIDEO_OUTPUT, +V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE and +V4L2_BUF_TYPE_VIDEO_OVERLAY. See . + + + struct v4l2_rect + bounds + Defines the window within capturing or output is +possible, this may exclude for example the horizontal and vertical +blanking areas. The cropping rectangle cannot exceed these limits. +Width and height are defined in pixels, the driver writer is free to +choose origin and units of the coordinate system in the analog +domain. + + + struct v4l2_rect + defrect + Default cropping rectangle, it shall cover the +"whole picture". Assuming pixel aspect 1/1 this could be for example a +640 × 480 rectangle for NTSC, a +768 × 576 rectangle for PAL and SECAM centered over +the active picture area. The same co-ordinate system as for + bounds is used. + + + &v4l2-fract; + pixelaspect + This is the pixel aspect (y / x) when no +scaling is applied, the ratio of the actual sampling +frequency and the frequency required to get square +pixels.When cropping coordinates refer to square pixels, +the driver sets pixelaspect to 1/1. Other +common values are 54/59 for PAL and SECAM, 11/10 for NTSC sampled +according to []. + + + +
+ + + + + struct <structname>v4l2_rect</structname> + + &cs-str; + + + __s32 + left + Horizontal offset of the top, left corner of the +rectangle, in pixels. + + + __s32 + top + Vertical offset of the top, left corner of the +rectangle, in pixels. + + + __s32 + width + Width of the rectangle, in pixels. + + + __s32 + height + Height of the rectangle, in pixels. Width +and height cannot be negative, the fields are signed for +hysterical reasons. + + + + +
+ + + + &return-value; + + + + EINVAL + + The &v4l2-cropcap; type is +invalid. + + + + + diff --git a/Documentation/DocBook/media/v4l/vidioc-dbg-g-chip-ident.xml b/Documentation/DocBook/media/v4l/vidioc-dbg-g-chip-ident.xml new file mode 100644 index 00000000..4ecd9668 --- /dev/null +++ b/Documentation/DocBook/media/v4l/vidioc-dbg-g-chip-ident.xml @@ -0,0 +1,266 @@ + + + ioctl VIDIOC_DBG_G_CHIP_IDENT + &manvol; + + + + VIDIOC_DBG_G_CHIP_IDENT + Identify the chips on a TV card + + + + + + int ioctl + int fd + int request + struct v4l2_dbg_chip_ident +*argp + + + + + + Arguments + + + + fd + + &fd; + + + + request + + VIDIOC_DBG_G_CHIP_IDENT + + + + argp + + + + + + + + + Description + + + Experimental + + This is an experimental interface and may change in +the future. + + + For driver debugging purposes this ioctl allows test +applications to query the driver about the chips present on the TV +card. Regular applications must not use it. When you found a chip +specific bug, please contact the linux-media mailing list (&v4l-ml;) +so it can be fixed. + + To query the driver applications must initialize the +match.type and +match.addr or match.name +fields of a &v4l2-dbg-chip-ident; +and call VIDIOC_DBG_G_CHIP_IDENT with a pointer to +this structure. On success the driver stores information about the +selected chip in the ident and +revision fields. On failure the structure +remains unchanged. + + When match.type is +V4L2_CHIP_MATCH_HOST, +match.addr selects the nth non-&i2c; chip +on the TV card. You can enumerate all chips by starting at zero and +incrementing match.addr by one until +VIDIOC_DBG_G_CHIP_IDENT fails with an &EINVAL;. +The number zero always selects the host chip, ⪚ the chip connected +to the PCI or USB bus. + + When match.type is +V4L2_CHIP_MATCH_I2C_DRIVER, +match.name contains the I2C driver name. +For instance +"saa7127" will match any chip +supported by the saa7127 driver, regardless of its &i2c; bus address. +When multiple chips supported by the same driver are present, the +ioctl will return V4L2_IDENT_AMBIGUOUS in the +ident field. + + When match.type is +V4L2_CHIP_MATCH_I2C_ADDR, +match.addr selects a chip by its 7 bit +&i2c; bus address. + + When match.type is +V4L2_CHIP_MATCH_AC97, +match.addr selects the nth AC97 chip +on the TV card. You can enumerate all chips by starting at zero and +incrementing match.addr by one until +VIDIOC_DBG_G_CHIP_IDENT fails with an &EINVAL;. + + On success, the ident field will +contain a chip ID from the Linux +media/v4l2-chip-ident.h header file, and the +revision field will contain a driver +specific value, or zero if no particular revision is associated with +this chip. + + When the driver could not identify the selected chip, +ident will contain +V4L2_IDENT_UNKNOWN. When no chip matched +the ioctl will succeed but the +ident field will contain +V4L2_IDENT_NONE. If multiple chips matched, +ident will contain +V4L2_IDENT_AMBIGUOUS. In all these cases the +revision field remains unchanged. + + This ioctl is optional, not all drivers may support it. It +was introduced in Linux 2.6.21, but the API was changed to the +one described here in 2.6.29. + + We recommended the v4l2-dbg +utility over calling this ioctl directly. It is available from the +LinuxTV v4l-dvb repository; see http://linuxtv.org/repo/ for +access instructions. + + + + struct <structname>v4l2_dbg_match</structname> + + &cs-ustr; + + + __u32 + type + See for a list of +possible types. + + + union + (anonymous) + + + + __u32 + addr + Match a chip by this number, interpreted according +to the type field. + + + + char + name[32] + Match a chip by this name, interpreted according +to the type field. + + + +
+ + + struct <structname>v4l2_dbg_chip_ident</structname> + + &cs-str; + + + struct v4l2_dbg_match + match + How to match the chip, see . + + + __u32 + ident + A chip identifier as defined in the Linux +media/v4l2-chip-ident.h header file, or one of +the values from . + + + __u32 + revision + A chip revision, chip and driver specific. + + + +
+ + + + Chip Match Types + + &cs-def; + + + V4L2_CHIP_MATCH_HOST + 0 + Match the nth chip on the card, zero for the + host chip. Does not match &i2c; chips. + + + V4L2_CHIP_MATCH_I2C_DRIVER + 1 + Match an &i2c; chip by its driver name. + + + V4L2_CHIP_MATCH_I2C_ADDR + 2 + Match a chip by its 7 bit &i2c; bus address. + + + V4L2_CHIP_MATCH_AC97 + 3 + Match the nth anciliary AC97 chip. + + + +
+ + + + Chip Identifiers + + &cs-def; + + + V4L2_IDENT_NONE + 0 + No chip matched. + + + V4L2_IDENT_AMBIGUOUS + 1 + Multiple chips matched. + + + V4L2_IDENT_UNKNOWN + 2 + A chip is present at this address, but the driver +could not identify it. + + + +
+ + + + &return-value; + + + + EINVAL + + The match_type is invalid. + + + + + diff --git a/Documentation/DocBook/media/v4l/vidioc-dbg-g-register.xml b/Documentation/DocBook/media/v4l/vidioc-dbg-g-register.xml new file mode 100644 index 00000000..a44aebc7 --- /dev/null +++ b/Documentation/DocBook/media/v4l/vidioc-dbg-g-register.xml @@ -0,0 +1,258 @@ + + + ioctl VIDIOC_DBG_G_REGISTER, VIDIOC_DBG_S_REGISTER + &manvol; + + + + VIDIOC_DBG_G_REGISTER + VIDIOC_DBG_S_REGISTER + Read or write hardware registers + + + + + + int ioctl + int fd + int request + struct v4l2_dbg_register *argp + + + + + int ioctl + int fd + int request + const struct v4l2_dbg_register +*argp + + + + + + Arguments + + + + fd + + &fd; + + + + request + + VIDIOC_DBG_G_REGISTER, VIDIOC_DBG_S_REGISTER + + + + argp + + + + + + + + + Description + + + Experimental + + This is an experimental +interface and may change in the future. + + + For driver debugging purposes these ioctls allow test +applications to access hardware registers directly. Regular +applications must not use them. + + Since writing or even reading registers can jeopardize the +system security, its stability and damage the hardware, both ioctls +require superuser privileges. Additionally the Linux kernel must be +compiled with the CONFIG_VIDEO_ADV_DEBUG option +to enable these ioctls. + + To write a register applications must initialize all fields +of a &v4l2-dbg-register; and call +VIDIOC_DBG_S_REGISTER with a pointer to this +structure. The match.type and +match.addr or match.name +fields select a chip on the TV +card, the reg field specifies a register +number and the val field the value to be +written into the register. + + To read a register applications must initialize the +match.type, +match.chip or match.name and +reg fields, and call +VIDIOC_DBG_G_REGISTER with a pointer to this +structure. On success the driver stores the register value in the +val field. On failure the structure remains +unchanged. + + When match.type is +V4L2_CHIP_MATCH_HOST, +match.addr selects the nth non-&i2c; chip +on the TV card. The number zero always selects the host chip, ⪚ the +chip connected to the PCI or USB bus. You can find out which chips are +present with the &VIDIOC-DBG-G-CHIP-IDENT; ioctl. + + When match.type is +V4L2_CHIP_MATCH_I2C_DRIVER, +match.name contains the I2C driver name. +For instance +"saa7127" will match any chip +supported by the saa7127 driver, regardless of its &i2c; bus address. +When multiple chips supported by the same driver are present, the +effect of these ioctls is undefined. Again with the +&VIDIOC-DBG-G-CHIP-IDENT; ioctl you can find out which &i2c; chips are +present. + + When match.type is +V4L2_CHIP_MATCH_I2C_ADDR, +match.addr selects a chip by its 7 bit &i2c; +bus address. + + When match.type is +V4L2_CHIP_MATCH_AC97, +match.addr selects the nth AC97 chip +on the TV card. + + + Success not guaranteed + + Due to a flaw in the Linux &i2c; bus driver these ioctls may +return successfully without actually reading or writing a register. To +catch the most likely failure we recommend a &VIDIOC-DBG-G-CHIP-IDENT; +call confirming the presence of the selected &i2c; chip. + + + These ioctls are optional, not all drivers may support them. +However when a driver supports these ioctls it must also support +&VIDIOC-DBG-G-CHIP-IDENT;. Conversely it may support +VIDIOC_DBG_G_CHIP_IDENT but not these ioctls. + + VIDIOC_DBG_G_REGISTER and +VIDIOC_DBG_S_REGISTER were introduced in Linux +2.6.21, but their API was changed to the one described here in kernel 2.6.29. + + We recommended the v4l2-dbg +utility over calling these ioctls directly. It is available from the +LinuxTV v4l-dvb repository; see http://linuxtv.org/repo/ for +access instructions. + + + + struct <structname>v4l2_dbg_match</structname> + + &cs-ustr; + + + __u32 + type + See for a list of +possible types. + + + union + (anonymous) + + + + __u32 + addr + Match a chip by this number, interpreted according +to the type field. + + + + char + name[32] + Match a chip by this name, interpreted according +to the type field. + + + +
+ + + + struct <structname>v4l2_dbg_register</structname> + + + + + + + struct v4l2_dbg_match + match + How to match the chip, see . + + + __u64 + reg + A register number. + + + __u64 + val + The value read from, or to be written into the +register. + + + +
+ + + + Chip Match Types + + &cs-def; + + + V4L2_CHIP_MATCH_HOST + 0 + Match the nth chip on the card, zero for the + host chip. Does not match &i2c; chips. + + + V4L2_CHIP_MATCH_I2C_DRIVER + 1 + Match an &i2c; chip by its driver name. + + + V4L2_CHIP_MATCH_I2C_ADDR + 2 + Match a chip by its 7 bit &i2c; bus address. + + + V4L2_CHIP_MATCH_AC97 + 3 + Match the nth anciliary AC97 chip. + + + +
+ + + + &return-value; + + + + EPERM + + Insufficient permissions. Root privileges are required +to execute these ioctls. + + + + + diff --git a/Documentation/DocBook/media/v4l/vidioc-decoder-cmd.xml b/Documentation/DocBook/media/v4l/vidioc-decoder-cmd.xml new file mode 100644 index 00000000..9215627b --- /dev/null +++ b/Documentation/DocBook/media/v4l/vidioc-decoder-cmd.xml @@ -0,0 +1,249 @@ + + + ioctl VIDIOC_DECODER_CMD, VIDIOC_TRY_DECODER_CMD + &manvol; + + + + VIDIOC_DECODER_CMD + VIDIOC_TRY_DECODER_CMD + Execute an decoder command + + + + + + int ioctl + int fd + int request + struct v4l2_decoder_cmd *argp + + + + + + Arguments + + + + fd + + &fd; + + + + request + + VIDIOC_DECODER_CMD, VIDIOC_TRY_DECODER_CMD + + + + argp + + + + + + + + + Description + + These ioctls control an audio/video (usually MPEG-) decoder. +VIDIOC_DECODER_CMD sends a command to the +decoder, VIDIOC_TRY_DECODER_CMD can be used to +try a command without actually executing it. To send a command applications +must initialize all fields of a &v4l2-decoder-cmd; and call +VIDIOC_DECODER_CMD or VIDIOC_TRY_DECODER_CMD +with a pointer to this structure. + + The cmd field must contain the +command code. Some commands use the flags field for +additional information. + + + A write() or &VIDIOC-STREAMON; call sends an implicit +START command to the decoder if it has not been started yet. + + + A close() or &VIDIOC-STREAMOFF; call of a streaming +file descriptor sends an implicit immediate STOP command to the decoder, and all +buffered data is discarded. + + These ioctls are optional, not all drivers may support +them. They were introduced in Linux 3.3. + + + struct <structname>v4l2_decoder_cmd</structname> + + &cs-str; + + + __u32 + cmd + + + The decoder command, see . + + + __u32 + flags + + + Flags to go with the command. If no flags are defined for +this command, drivers and applications must set this field to zero. + + + union + (anonymous) + + + + + + + struct + start + + Structure containing additional data for the +V4L2_DEC_CMD_START command. + + + + + __s32 + speed + Playback speed and direction. The playback speed is defined as +speed/1000 of the normal speed. So 1000 is normal playback. +Negative numbers denote reverse playback, so -1000 does reverse playback at normal +speed. Speeds -1, 0 and 1 have special meanings: speed 0 is shorthand for 1000 +(normal playback). A speed of 1 steps just one frame forward, a speed of -1 steps +just one frame back. + + + + + + __u32 + format + Format restrictions. This field is set by the driver, not the +application. Possible values are V4L2_DEC_START_FMT_NONE if +there are no format restrictions or V4L2_DEC_START_FMT_GOP +if the decoder operates on full GOPs (Group Of Pictures). +This is usually the case for reverse playback: the decoder needs full GOPs, which +it can then play in reverse order. So to implement reverse playback the application +must feed the decoder the last GOP in the video file, then the GOP before that, etc. etc. + + + + + struct + stop + + Structure containing additional data for the +V4L2_DEC_CMD_STOP command. + + + + + __u64 + pts + Stop playback at this pts or immediately +if the playback is already past that timestamp. Leave to 0 if you want to stop after the +last frame was decoded. + + + + + struct + raw + + + + + + + __u32 + data[16] + Reserved for future extensions. Drivers and +applications must set the array to zero. + + + +
+ + + Decoder Commands + + &cs-def; + + + V4L2_DEC_CMD_START + 0 + Start the decoder. When the decoder is already +running or paused, this command will just change the playback speed. +That means that calling V4L2_DEC_CMD_START when +the decoder was paused will not resume the decoder. +You have to explicitly call V4L2_DEC_CMD_RESUME for that. +This command has one flag: +V4L2_DEC_CMD_START_MUTE_AUDIO. If set, then audio will +be muted when playing back at a non-standard speed. + + + + V4L2_DEC_CMD_STOP + 1 + Stop the decoder. When the decoder is already stopped, +this command does nothing. This command has two flags: +if V4L2_DEC_CMD_STOP_TO_BLACK is set, then the decoder will +set the picture to black after it stopped decoding. Otherwise the last image will +repeat. If V4L2_DEC_CMD_STOP_IMMEDIATELY is set, then the decoder +stops immediately (ignoring the pts value), otherwise it +will keep decoding until timestamp >= pts or until the last of the pending data from +its internal buffers was decoded. + + + + V4L2_DEC_CMD_PAUSE + 2 + Pause the decoder. When the decoder has not been +started yet, the driver will return an &EPERM;. When the decoder is +already paused, this command does nothing. This command has one flag: +if V4L2_DEC_CMD_PAUSE_TO_BLACK is set, then set the +decoder output to black when paused. + + + + V4L2_DEC_CMD_RESUME + 3 + Resume decoding after a PAUSE command. When the +decoder has not been started yet, the driver will return an &EPERM;. +When the decoder is already running, this command does nothing. No +flags are defined for this command. + + + +
+ + + + + &return-value; + + + + EINVAL + + The cmd field is invalid. + + + + EPERM + + The application sent a PAUSE or RESUME command when +the decoder was not running. + + + + + diff --git a/Documentation/DocBook/media/v4l/vidioc-dqevent.xml b/Documentation/DocBook/media/v4l/vidioc-dqevent.xml new file mode 100644 index 00000000..89891adb --- /dev/null +++ b/Documentation/DocBook/media/v4l/vidioc-dqevent.xml @@ -0,0 +1,277 @@ + + + ioctl VIDIOC_DQEVENT + &manvol; + + + + VIDIOC_DQEVENT + Dequeue event + + + + + + int ioctl + int fd + int request + struct v4l2_event +*argp + + + + + + Arguments + + + + fd + + &fd; + + + + request + + VIDIOC_DQEVENT + + + + argp + + + + + + + + + Description + + Dequeue an event from a video device. No input is required + for this ioctl. All the fields of the &v4l2-event; structure are + filled by the driver. The file handle will also receive exceptions + which the application may get by e.g. using the select system + call. + + + struct <structname>v4l2_event</structname> + + &cs-str; + + + __u32 + type + + Type of the event. + + + union + u + + + + + + &v4l2-event-vsync; + vsync + Event data for event V4L2_EVENT_VSYNC. + + + + + &v4l2-event-ctrl; + ctrl + Event data for event V4L2_EVENT_CTRL. + + + + + &v4l2-event-frame-sync; + frame_sync + Event data for event V4L2_EVENT_FRAME_SYNC. + + + + __u8 + data[64] + Event data. Defined by the event type. The union + should be used to define easily accessible type for + events. + + + __u32 + pending + + Number of pending events excluding this one. + + + __u32 + sequence + + Event sequence number. The sequence number is + incremented for every subscribed event that takes place. + If sequence numbers are not contiguous it means that + events have been lost. + + + + struct timespec + timestamp + + Event timestamp. + + + u32 + id + + The ID associated with the event source. If the event does not + have an associated ID (this depends on the event type), then this + is 0. + + + __u32 + reserved[8] + + Reserved for future extensions. Drivers must set + the array to zero. + + + +
+ + + struct <structname>v4l2_event_vsync</structname> + + &cs-str; + + + __u8 + field + The upcoming field. See &v4l2-field;. + + + +
+ + + struct <structname>v4l2_event_ctrl</structname> + + &cs-str; + + + __u32 + changes + + A bitmask that tells what has changed. See . + + + __u32 + type + + The type of the control. See &v4l2-ctrl-type;. + + + union (anonymous) + + + + + + + __s32 + value + The 32-bit value of the control for 32-bit control types. + This is 0 for string controls since the value of a string + cannot be passed using &VIDIOC-DQEVENT;. + + + + __s64 + value64 + The 64-bit value of the control for 64-bit control types. + + + __u32 + flags + + The control flags. See . + + + __s32 + minimum + + The minimum value of the control. See &v4l2-queryctrl;. + + + __s32 + maximum + + The maximum value of the control. See &v4l2-queryctrl;. + + + __s32 + step + + The step value of the control. See &v4l2-queryctrl;. + + + __s32 + default_value + + The default value value of the control. See &v4l2-queryctrl;. + + + +
+ + + struct <structname>v4l2_event_frame_sync</structname> + + &cs-str; + + + __u32 + frame_sequence + + The sequence number of the frame being received. + + + + +
+ + + Changes + + &cs-def; + + + V4L2_EVENT_CTRL_CH_VALUE + 0x0001 + This control event was triggered because the value of the control + changed. Special case: if a button control is pressed, then this + event is sent as well, even though there is not explicit value + associated with a button control. + + + V4L2_EVENT_CTRL_CH_FLAGS + 0x0002 + This control event was triggered because the control flags + changed. + + + V4L2_EVENT_CTRL_CH_RANGE + 0x0004 + This control event was triggered because the minimum, + maximum, step or the default value of the control changed. + + + +
+ + + &return-value; + + diff --git a/Documentation/DocBook/media/v4l/vidioc-dv-timings-cap.xml b/Documentation/DocBook/media/v4l/vidioc-dv-timings-cap.xml new file mode 100644 index 00000000..cd7720d4 --- /dev/null +++ b/Documentation/DocBook/media/v4l/vidioc-dv-timings-cap.xml @@ -0,0 +1,205 @@ + + + ioctl VIDIOC_DV_TIMINGS_CAP + &manvol; + + + + VIDIOC_DV_TIMINGS_CAP + The capabilities of the Digital Video receiver/transmitter + + + + + + int ioctl + int fd + int request + struct v4l2_dv_timings_cap *argp + + + + + + Arguments + + + + fd + + &fd; + + + + request + + VIDIOC_DV_TIMINGS_CAP + + + + argp + + + + + + + + + Description + + + Experimental + This is an experimental + interface and may change in the future. + + + To query the capabilities of the DV receiver/transmitter applications can call +this ioctl and the driver will fill in the structure. Note that drivers may return +different values after switching the video input or output. + + + struct <structname>v4l2_bt_timings_cap</structname> + + &cs-str; + + + __u32 + min_width + Minimum width of the active video in pixels. + + + __u32 + max_width + Maximum width of the active video in pixels. + + + __u32 + min_height + Minimum height of the active video in lines. + + + __u32 + max_height + Maximum height of the active video in lines. + + + __u64 + min_pixelclock + Minimum pixelclock frequency in Hz. + + + __u64 + max_pixelclock + Maximum pixelclock frequency in Hz. + + + __u32 + standards + The video standard(s) supported by the hardware. + See for a list of standards. + + + __u32 + capabilities + Several flags giving more information about the capabilities. + See for a description of the flags. + + + + __u32 + reserved[16] + Reserved for future extensions. Drivers must set the array to zero. + + + +
+ + + struct <structname>v4l2_dv_timings_cap</structname> + + &cs-str; + + + __u32 + type + Type of DV timings as listed in . + + + __u32 + reserved[3] + Reserved for future extensions. Drivers must set the array to zero. + + + union + + + + + + &v4l2-bt-timings-cap; + bt + BT.656/1120 timings capabilities of the hardware. + + + + __u32 + raw_data[32] + + + + +
+ + + DV BT Timing capabilities + + &cs-str; + + + Flag + Description + + + + + + + V4L2_DV_BT_CAP_INTERLACED + Interlaced formats are supported. + + + + V4L2_DV_BT_CAP_PROGRESSIVE + Progressive formats are supported. + + + + V4L2_DV_BT_CAP_REDUCED_BLANKING + CVT/GTF specific: the timings can make use of reduced blanking (CVT) +or the 'Secondary GTF' curve (GTF). + + + + V4L2_DV_BT_CAP_CUSTOM + Can support non-standard timings, i.e. timings not belonging to the +standards set in the standards field. + + + + +
+ + + + &return-value; + + + + diff --git a/Documentation/DocBook/media/v4l/vidioc-encoder-cmd.xml b/Documentation/DocBook/media/v4l/vidioc-encoder-cmd.xml new file mode 100644 index 00000000..0619ca5d --- /dev/null +++ b/Documentation/DocBook/media/v4l/vidioc-encoder-cmd.xml @@ -0,0 +1,189 @@ + + + ioctl VIDIOC_ENCODER_CMD, VIDIOC_TRY_ENCODER_CMD + &manvol; + + + + VIDIOC_ENCODER_CMD + VIDIOC_TRY_ENCODER_CMD + Execute an encoder command + + + + + + int ioctl + int fd + int request + struct v4l2_encoder_cmd *argp + + + + + + Arguments + + + + fd + + &fd; + + + + request + + VIDIOC_ENCODER_CMD, VIDIOC_TRY_ENCODER_CMD + + + + argp + + + + + + + + + Description + + These ioctls control an audio/video (usually MPEG-) encoder. +VIDIOC_ENCODER_CMD sends a command to the +encoder, VIDIOC_TRY_ENCODER_CMD can be used to +try a command without actually executing it. + + To send a command applications must initialize all fields of a + &v4l2-encoder-cmd; and call + VIDIOC_ENCODER_CMD or + VIDIOC_TRY_ENCODER_CMD with a pointer to this + structure. + + The cmd field must contain the +command code. The flags field is currently +only used by the STOP command and contains one bit: If the +V4L2_ENC_CMD_STOP_AT_GOP_END flag is set, +encoding will continue until the end of the current Group +Of Pictures, otherwise it will stop immediately. + + A read() or &VIDIOC-STREAMON; call sends an implicit +START command to the encoder if it has not been started yet. After a STOP command, +read() calls will read the remaining data +buffered by the driver. When the buffer is empty, +read() will return zero and the next +read() call will restart the encoder. + + A close() or &VIDIOC-STREAMOFF; call of a streaming +file descriptor sends an implicit immediate STOP to the encoder, and all buffered +data is discarded. + + These ioctls are optional, not all drivers may support +them. They were introduced in Linux 2.6.21. + + + struct <structname>v4l2_encoder_cmd</structname> + + &cs-str; + + + __u32 + cmd + The encoder command, see . + + + __u32 + flags + Flags to go with the command, see . If no flags are defined for +this command, drivers and applications must set this field to +zero. + + + __u32 + data[8] + Reserved for future extensions. Drivers and +applications must set the array to zero. + + + +
+ + + Encoder Commands + + &cs-def; + + + V4L2_ENC_CMD_START + 0 + Start the encoder. When the encoder is already +running or paused, this command does nothing. No flags are defined for +this command. + + + V4L2_ENC_CMD_STOP + 1 + Stop the encoder. When the +V4L2_ENC_CMD_STOP_AT_GOP_END flag is set, +encoding will continue until the end of the current Group +Of Pictures, otherwise encoding will stop immediately. +When the encoder is already stopped, this command does +nothing. + + + V4L2_ENC_CMD_PAUSE + 2 + Pause the encoder. When the encoder has not been +started yet, the driver will return an &EPERM;. When the encoder is +already paused, this command does nothing. No flags are defined for +this command. + + + V4L2_ENC_CMD_RESUME + 3 + Resume encoding after a PAUSE command. When the +encoder has not been started yet, the driver will return an &EPERM;. +When the encoder is already running, this command does nothing. No +flags are defined for this command. + + + +
+ + + Encoder Command Flags + + &cs-def; + + + V4L2_ENC_CMD_STOP_AT_GOP_END + 0x0001 + Stop encoding at the end of the current Group Of +Pictures, rather than immediately. + + + +
+ + + + &return-value; + + + + EINVAL + + The cmd field is invalid. + + + + EPERM + + The application sent a PAUSE or RESUME command when +the encoder was not running. + + + + + diff --git a/Documentation/DocBook/media/v4l/vidioc-enum-dv-presets.xml b/Documentation/DocBook/media/v4l/vidioc-enum-dv-presets.xml new file mode 100644 index 00000000..fced5fb0 --- /dev/null +++ b/Documentation/DocBook/media/v4l/vidioc-enum-dv-presets.xml @@ -0,0 +1,240 @@ + + + ioctl VIDIOC_ENUM_DV_PRESETS + &manvol; + + + + VIDIOC_ENUM_DV_PRESETS + Enumerate supported Digital Video presets + + + + + + int ioctl + int fd + int request + struct v4l2_dv_enum_preset *argp + + + + + + Arguments + + + + fd + + &fd; + + + + request + + VIDIOC_ENUM_DV_PRESETS + + + + argp + + + + + + + + + Description + + This ioctl is deprecated. + New drivers and applications should use &VIDIOC-ENUM-DV-TIMINGS; instead. + + + To query the attributes of a DV preset, applications initialize the +index field and zero the reserved array of &v4l2-dv-enum-preset; +and call the VIDIOC_ENUM_DV_PRESETS ioctl with a pointer to this +structure. Drivers fill the rest of the structure or return an +&EINVAL; when the index is out of bounds. To enumerate all DV Presets supported, +applications shall begin at index zero, incrementing by one until the +driver returns EINVAL. Drivers may enumerate a +different set of DV presets after switching the video input or +output. + + + struct <structname>v4l2_dv_enum_presets</structname> + + &cs-str; + + + __u32 + index + Number of the DV preset, set by the +application. + + + __u32 + preset + This field identifies one of the DV preset values listed in . + + + __u8 + name[24] + Name of the preset, a NUL-terminated ASCII string, for example: "720P-60", "1080I-60". This information is +intended for the user. + + + __u32 + width + Width of the active video in pixels for the DV preset. + + + __u32 + height + Height of the active video in lines for the DV preset. + + + __u32 + reserved[4] + Reserved for future extensions. Drivers must set the array to zero. + + + +
+ + + struct <structname>DV Presets</structname> + + &cs-str; + + + Preset + Preset value + Description + + + + + + + + V4L2_DV_INVALID + 0 + Invalid preset value. + + + V4L2_DV_480P59_94 + 1 + 720x480 progressive video at 59.94 fps as per BT.1362. + + + V4L2_DV_576P50 + 2 + 720x576 progressive video at 50 fps as per BT.1362. + + + V4L2_DV_720P24 + 3 + 1280x720 progressive video at 24 fps as per SMPTE 296M. + + + V4L2_DV_720P25 + 4 + 1280x720 progressive video at 25 fps as per SMPTE 296M. + + + V4L2_DV_720P30 + 5 + 1280x720 progressive video at 30 fps as per SMPTE 296M. + + + V4L2_DV_720P50 + 6 + 1280x720 progressive video at 50 fps as per SMPTE 296M. + + + V4L2_DV_720P59_94 + 7 + 1280x720 progressive video at 59.94 fps as per SMPTE 274M. + + + V4L2_DV_720P60 + 8 + 1280x720 progressive video at 60 fps as per SMPTE 274M/296M. + + + V4L2_DV_1080I29_97 + 9 + 1920x1080 interlaced video at 29.97 fps as per BT.1120/SMPTE 274M. + + + V4L2_DV_1080I30 + 10 + 1920x1080 interlaced video at 30 fps as per BT.1120/SMPTE 274M. + + + V4L2_DV_1080I25 + 11 + 1920x1080 interlaced video at 25 fps as per BT.1120. + + + V4L2_DV_1080I50 + 12 + 1920x1080 interlaced video at 50 fps as per SMPTE 296M. + + + V4L2_DV_1080I60 + 13 + 1920x1080 interlaced video at 60 fps as per SMPTE 296M. + + + V4L2_DV_1080P24 + 14 + 1920x1080 progressive video at 24 fps as per SMPTE 296M. + + + V4L2_DV_1080P25 + 15 + 1920x1080 progressive video at 25 fps as per SMPTE 296M. + + + V4L2_DV_1080P30 + 16 + 1920x1080 progressive video at 30 fps as per SMPTE 296M. + + + V4L2_DV_1080P50 + 17 + 1920x1080 progressive video at 50 fps as per BT.1120. + + + V4L2_DV_1080P60 + 18 + 1920x1080 progressive video at 60 fps as per BT.1120. + + + +
+ + + + &return-value; + + + + EINVAL + + The &v4l2-dv-enum-preset; index +is out of bounds. + + + + ENODATA + + Digital video presets are not supported for this input or output. + + + + + diff --git a/Documentation/DocBook/media/v4l/vidioc-enum-dv-timings.xml b/Documentation/DocBook/media/v4l/vidioc-enum-dv-timings.xml new file mode 100644 index 00000000..b3e17c1d --- /dev/null +++ b/Documentation/DocBook/media/v4l/vidioc-enum-dv-timings.xml @@ -0,0 +1,125 @@ + + + ioctl VIDIOC_ENUM_DV_TIMINGS + &manvol; + + + + VIDIOC_ENUM_DV_TIMINGS + Enumerate supported Digital Video timings + + + + + + int ioctl + int fd + int request + struct v4l2_enum_dv_timings *argp + + + + + + Arguments + + + + fd + + &fd; + + + + request + + VIDIOC_ENUM_DV_TIMINGS + + + + argp + + + + + + + + + Description + + + Experimental + This is an experimental + interface and may change in the future. + + + While some DV receivers or transmitters support a wide range of timings, others +support only a limited number of timings. With this ioctl applications can enumerate a list +of known supported timings. Call &VIDIOC-DV-TIMINGS-CAP; to check if it also supports other +standards or even custom timings that are not in this list. + + To query the available timings, applications initialize the +index field and zero the reserved array of &v4l2-enum-dv-timings; +and call the VIDIOC_ENUM_DV_TIMINGS ioctl with a pointer to this +structure. Drivers fill the rest of the structure or return an +&EINVAL; when the index is out of bounds. To enumerate all supported DV timings, +applications shall begin at index zero, incrementing by one until the +driver returns EINVAL. Note that drivers may enumerate a +different set of DV timings after switching the video input or +output. + + + struct <structname>v4l2_enum_dv_timings</structname> + + &cs-str; + + + __u32 + index + Number of the DV timings, set by the +application. + + + __u32 + reserved[3] + Reserved for future extensions. Drivers must set the array to zero. + + + &v4l2-dv-timings; + timings + The timings. + + + +
+ + + + &return-value; + + + + EINVAL + + The &v4l2-enum-dv-timings; index +is out of bounds. + + + + ENODATA + + Digital video presets are not supported for this input or output. + + + + + + + diff --git a/Documentation/DocBook/media/v4l/vidioc-enum-fmt.xml b/Documentation/DocBook/media/v4l/vidioc-enum-fmt.xml new file mode 100644 index 00000000..f8dfeed3 --- /dev/null +++ b/Documentation/DocBook/media/v4l/vidioc-enum-fmt.xml @@ -0,0 +1,159 @@ + + + ioctl VIDIOC_ENUM_FMT + &manvol; + + + + VIDIOC_ENUM_FMT + Enumerate image formats + + + + + + int ioctl + int fd + int request + struct v4l2_fmtdesc +*argp + + + + + + Arguments + + + + fd + + &fd; + + + + request + + VIDIOC_ENUM_FMT + + + + argp + + + + + + + + + Description + + To enumerate image formats applications initialize the +type and index +field of &v4l2-fmtdesc; and call the +VIDIOC_ENUM_FMT ioctl with a pointer to this +structure. Drivers fill the rest of the structure or return an +&EINVAL;. All formats are enumerable by beginning at index zero and +incrementing by one until EINVAL is +returned. + + Note that after switching input or output the list of enumerated image +formats may be different. + + + struct <structname>v4l2_fmtdesc</structname> + + &cs-str; + + + __u32 + index + Number of the format in the enumeration, set by +the application. This is in no way related to the +pixelformat field. + + + __u32 + type + Type of the data stream, set by the application. +Only these types are valid here: +V4L2_BUF_TYPE_VIDEO_CAPTURE, +V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE, +V4L2_BUF_TYPE_VIDEO_OUTPUT, +V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE and +V4L2_BUF_TYPE_VIDEO_OVERLAY. See . + + + __u32 + flags + See + + + __u8 + description[32] + Description of the format, a NUL-terminated ASCII +string. This information is intended for the user, for example: "YUV +4:2:2". + + + __u32 + pixelformat + The image format identifier. This is a +four character code as computed by the v4l2_fourcc() +macro: + + + +#define v4l2_fourcc(a,b,c,d) (((__u32)(a)<<0)|((__u32)(b)<<8)|((__u32)(c)<<16)|((__u32)(d)<<24)) +Several image formats are already +defined by this specification in . Note these +codes are not the same as those used in the Windows world. + + + __u32 + reserved[4] + Reserved for future extensions. Drivers must set +the array to zero. + + + +
+ + + Image Format Description Flags + + &cs-def; + + + V4L2_FMT_FLAG_COMPRESSED + 0x0001 + This is a compressed format. + + + V4L2_FMT_FLAG_EMULATED + 0x0002 + This format is not native to the device but emulated +through software (usually libv4l2), where possible try to use a native format +instead for better performance. + + + +
+ + + + &return-value; + + + + EINVAL + + The &v4l2-fmtdesc; type +is not supported or the index is out of +bounds. + + + + + diff --git a/Documentation/DocBook/media/v4l/vidioc-enum-frameintervals.xml b/Documentation/DocBook/media/v4l/vidioc-enum-frameintervals.xml new file mode 100644 index 00000000..5fd72c4c --- /dev/null +++ b/Documentation/DocBook/media/v4l/vidioc-enum-frameintervals.xml @@ -0,0 +1,259 @@ + + + + ioctl VIDIOC_ENUM_FRAMEINTERVALS + &manvol; + + + + VIDIOC_ENUM_FRAMEINTERVALS + Enumerate frame intervals + + + + + + int ioctl + int fd + int request + struct v4l2_frmivalenum *argp + + + + + + Arguments + + + + fd + + &fd; + + + + request + + VIDIOC_ENUM_FRAMEINTERVALS + + + + argp + + Pointer to a &v4l2-frmivalenum; structure that +contains a pixel format and size and receives a frame interval. + + + + + + + Description + + This ioctl allows applications to enumerate all frame +intervals that the device supports for the given pixel format and +frame size. + The supported pixel formats and frame sizes can be obtained +by using the &VIDIOC-ENUM-FMT; and &VIDIOC-ENUM-FRAMESIZES; +functions. + The return value and the content of the +v4l2_frmivalenum.type field depend on the +type of frame intervals the device supports. Here are the semantics of +the function for the different cases: + + + Discrete: The function +returns success if the given index value (zero-based) is valid. The +application should increase the index by one for each call until +EINVAL is returned. The `v4l2_frmivalenum.type` +field is set to `V4L2_FRMIVAL_TYPE_DISCRETE` by the driver. Of the +union only the `discrete` member is valid. + + + Step-wise: The function +returns success if the given index value is zero and +EINVAL for any other index value. The +v4l2_frmivalenum.type field is set to +V4L2_FRMIVAL_TYPE_STEPWISE by the driver. Of the +union only the stepwise member is +valid. + + + Continuous: This is a +special case of the step-wise type above. The function returns success +if the given index value is zero and EINVAL for +any other index value. The +v4l2_frmivalenum.type field is set to +V4L2_FRMIVAL_TYPE_CONTINUOUS by the driver. Of +the union only the stepwise member is valid +and the step value is set to 1. + + + + When the application calls the function with index zero, it +must check the type field to determine the +type of frame interval enumeration the device supports. Only for the +V4L2_FRMIVAL_TYPE_DISCRETE type does it make +sense to increase the index value to receive more frame +intervals. + Note that the order in which the frame intervals are +returned has no special meaning. In particular does it not say +anything about potential default frame intervals. + Applications can assume that the enumeration data does not +change without any interaction from the application itself. This means +that the enumeration data is consistent if the application does not +perform any other ioctl calls while it runs the frame interval +enumeration. + + + + Notes + + + + Frame intervals and frame +rates: The V4L2 API uses frame intervals instead of frame +rates. Given the frame interval the frame rate can be computed as +follows:frame_rate = 1 / frame_interval + + + + + + + Structs + + In the structs below, IN denotes a +value that has to be filled in by the application, +OUT denotes values that the driver fills in. The +application should zero out all members except for the +IN fields. + + + struct <structname>v4l2_frmival_stepwise</structname> + + &cs-str; + + + &v4l2-fract; + min + Minimum frame interval [s]. + + + &v4l2-fract; + max + Maximum frame interval [s]. + + + &v4l2-fract; + step + Frame interval step size [s]. + + + +
+ + + struct <structname>v4l2_frmivalenum</structname> + + + + + + + + __u32 + index + + IN: Index of the given frame interval in the +enumeration. + + + __u32 + pixel_format + + IN: Pixel format for which the frame intervals are +enumerated. + + + __u32 + width + + IN: Frame width for which the frame intervals are +enumerated. + + + __u32 + height + + IN: Frame height for which the frame intervals are +enumerated. + + + __u32 + type + + OUT: Frame interval type the device supports. + + + union + + + OUT: Frame interval with the given index. + + + + &v4l2-fract; + discrete + Frame interval [s]. + + + + &v4l2-frmival-stepwise; + stepwise + + + + __u32 + reserved[2] + + Reserved space for future use. + + + +
+ + + + Enums + + + enum <structname>v4l2_frmivaltypes</structname> + + &cs-def; + + + V4L2_FRMIVAL_TYPE_DISCRETE + 1 + Discrete frame interval. + + + V4L2_FRMIVAL_TYPE_CONTINUOUS + 2 + Continuous frame interval. + + + V4L2_FRMIVAL_TYPE_STEPWISE + 3 + Step-wise defined frame interval. + + + +
+ + + + &return-value; + + + diff --git a/Documentation/DocBook/media/v4l/vidioc-enum-framesizes.xml b/Documentation/DocBook/media/v4l/vidioc-enum-framesizes.xml new file mode 100644 index 00000000..a78454b5 --- /dev/null +++ b/Documentation/DocBook/media/v4l/vidioc-enum-framesizes.xml @@ -0,0 +1,264 @@ + + + + ioctl VIDIOC_ENUM_FRAMESIZES + &manvol; + + + + VIDIOC_ENUM_FRAMESIZES + Enumerate frame sizes + + + + + + int ioctl + int fd + int request + struct v4l2_frmsizeenum *argp + + + + + + Arguments + + + + fd + + &fd; + + + + request + + VIDIOC_ENUM_FRAMESIZES + + + + argp + + Pointer to a &v4l2-frmsizeenum; that contains an index +and pixel format and receives a frame width and height. + + + + + + + Description + + This ioctl allows applications to enumerate all frame sizes +(&ie; width and height in pixels) that the device supports for the +given pixel format. + The supported pixel formats can be obtained by using the +&VIDIOC-ENUM-FMT; function. + The return value and the content of the +v4l2_frmsizeenum.type field depend on the +type of frame sizes the device supports. Here are the semantics of the +function for the different cases: + + + + Discrete: The function +returns success if the given index value (zero-based) is valid. The +application should increase the index by one for each call until +EINVAL is returned. The +v4l2_frmsizeenum.type field is set to +V4L2_FRMSIZE_TYPE_DISCRETE by the driver. Of the +union only the discrete member is +valid. + + + Step-wise: The function +returns success if the given index value is zero and +EINVAL for any other index value. The +v4l2_frmsizeenum.type field is set to +V4L2_FRMSIZE_TYPE_STEPWISE by the driver. Of the +union only the stepwise member is +valid. + + + Continuous: This is a +special case of the step-wise type above. The function returns success +if the given index value is zero and EINVAL for +any other index value. The +v4l2_frmsizeenum.type field is set to +V4L2_FRMSIZE_TYPE_CONTINUOUS by the driver. Of +the union only the stepwise member is valid +and the step_width and +step_height values are set to 1. + + + + When the application calls the function with index zero, it +must check the type field to determine the +type of frame size enumeration the device supports. Only for the +V4L2_FRMSIZE_TYPE_DISCRETE type does it make +sense to increase the index value to receive more frame sizes. + Note that the order in which the frame sizes are returned +has no special meaning. In particular does it not say anything about +potential default format sizes. + Applications can assume that the enumeration data does not +change without any interaction from the application itself. This means +that the enumeration data is consistent if the application does not +perform any other ioctl calls while it runs the frame size +enumeration. + + + + Structs + + In the structs below, IN denotes a +value that has to be filled in by the application, +OUT denotes values that the driver fills in. The +application should zero out all members except for the +IN fields. + + + struct <structname>v4l2_frmsize_discrete</structname> + + &cs-str; + + + __u32 + width + Width of the frame [pixel]. + + + __u32 + height + Height of the frame [pixel]. + + + +
+ + + struct <structname>v4l2_frmsize_stepwise</structname> + + &cs-str; + + + __u32 + min_width + Minimum frame width [pixel]. + + + __u32 + max_width + Maximum frame width [pixel]. + + + __u32 + step_width + Frame width step size [pixel]. + + + __u32 + min_height + Minimum frame height [pixel]. + + + __u32 + max_height + Maximum frame height [pixel]. + + + __u32 + step_height + Frame height step size [pixel]. + + + +
+ + + struct <structname>v4l2_frmsizeenum</structname> + + + + + + + + __u32 + index + + IN: Index of the given frame size in the enumeration. + + + __u32 + pixel_format + + IN: Pixel format for which the frame sizes are enumerated. + + + __u32 + type + + OUT: Frame size type the device supports. + + + union + + + OUT: Frame size with the given index. + + + + &v4l2-frmsize-discrete; + discrete + + + + + &v4l2-frmsize-stepwise; + stepwise + + + + __u32 + reserved[2] + + Reserved space for future use. + + + +
+ + + + Enums + + + enum <structname>v4l2_frmsizetypes</structname> + + &cs-def; + + + V4L2_FRMSIZE_TYPE_DISCRETE + 1 + Discrete frame size. + + + V4L2_FRMSIZE_TYPE_CONTINUOUS + 2 + Continuous frame size. + + + V4L2_FRMSIZE_TYPE_STEPWISE + 3 + Step-wise defined frame size. + + + +
+ + + + &return-value; + + diff --git a/Documentation/DocBook/media/v4l/vidioc-enum-freq-bands.xml b/Documentation/DocBook/media/v4l/vidioc-enum-freq-bands.xml new file mode 100644 index 00000000..6541ba01 --- /dev/null +++ b/Documentation/DocBook/media/v4l/vidioc-enum-freq-bands.xml @@ -0,0 +1,179 @@ + + + ioctl VIDIOC_ENUM_FREQ_BANDS + &manvol; + + + + VIDIOC_ENUM_FREQ_BANDS + Enumerate supported frequency bands + + + + + + int ioctl + int fd + int request + struct v4l2_frequency_band +*argp + + + + + + Arguments + + + + fd + + &fd; + + + + request + + VIDIOC_ENUM_FREQ_BANDS + + + + argp + + + + + + + + + Description + + + Experimental + This is an experimental + interface and may change in the future. + + + Enumerates the frequency bands that a tuner or modulator supports. +To do this applications initialize the tuner, +type and index fields, +and zero out the reserved array of a &v4l2-frequency-band; and +call the VIDIOC_ENUM_FREQ_BANDS ioctl with a pointer +to this structure. + + This ioctl is supported if the V4L2_TUNER_CAP_FREQ_BANDS capability + of the corresponding tuner/modulator is set. + + + struct <structname>v4l2_frequency_band</structname> + + &cs-str; + + + __u32 + tuner + The tuner or modulator index number. This is the +same value as in the &v4l2-input; tuner +field and the &v4l2-tuner; index field, or +the &v4l2-output; modulator field and the +&v4l2-modulator; index field. + + + __u32 + type + The tuner type. This is the same value as in the +&v4l2-tuner; type field. The type must be set +to V4L2_TUNER_RADIO for /dev/radioX +device nodes, and to V4L2_TUNER_ANALOG_TV +for all others. Set this field to V4L2_TUNER_RADIO for +modulators (currently only radio modulators are supported). +See + + + __u32 + index + Identifies the frequency band, set by the application. + + + __u32 + capability + The tuner/modulator capability flags for +this frequency band, see . The V4L2_TUNER_CAP_LOW +capability must be the same for all frequency bands of the selected tuner/modulator. +So either all bands have that capability set, or none of them have that capability. + + + __u32 + rangelow + The lowest tunable frequency in +units of 62.5 kHz, or if the capability +flag V4L2_TUNER_CAP_LOW is set, in units of 62.5 +Hz, for this frequency band. + + + __u32 + rangehigh + The highest tunable frequency in +units of 62.5 kHz, or if the capability +flag V4L2_TUNER_CAP_LOW is set, in units of 62.5 +Hz, for this frequency band. + + + __u32 + modulation + The supported modulation systems of this frequency band. + See . Note that currently only one + modulation system per frequency band is supported. More work will need to + be done if multiple modulation systems are possible. Contact the + linux-media mailing list (&v4l-ml;) if you need that functionality. + + + __u32 + reserved[9] + Reserved for future extensions. Applications and drivers + must set the array to zero. + + + +
+ + + Band Modulation Systems + + &cs-def; + + + V4L2_BAND_MODULATION_VSB + 0x02 + Vestigial Sideband modulation, used for analog TV. + + + V4L2_BAND_MODULATION_FM + 0x04 + Frequency Modulation, commonly used for analog radio. + + + V4L2_BAND_MODULATION_AM + 0x08 + Amplitude Modulation, commonly used for analog radio. + + + +
+ + + + &return-value; + + + + EINVAL + + The tuner or index +is out of bounds or the type field is wrong. + + + + + diff --git a/Documentation/DocBook/media/v4l/vidioc-enumaudio.xml b/Documentation/DocBook/media/v4l/vidioc-enumaudio.xml new file mode 100644 index 00000000..ea816ab2 --- /dev/null +++ b/Documentation/DocBook/media/v4l/vidioc-enumaudio.xml @@ -0,0 +1,76 @@ + + + ioctl VIDIOC_ENUMAUDIO + &manvol; + + + + VIDIOC_ENUMAUDIO + Enumerate audio inputs + + + + + + int ioctl + int fd + int request + struct v4l2_audio *argp + + + + + + Arguments + + + + fd + + &fd; + + + + request + + VIDIOC_ENUMAUDIO + + + + argp + + + + + + + + + Description + + To query the attributes of an audio input applications +initialize the index field and zero out the +reserved array of a &v4l2-audio; +and call the VIDIOC_ENUMAUDIO ioctl with a pointer +to this structure. Drivers fill the rest of the structure or return an +&EINVAL; when the index is out of bounds. To enumerate all audio +inputs applications shall begin at index zero, incrementing by one +until the driver returns EINVAL. + + See for a description of +&v4l2-audio;. + + + + &return-value; + + + + EINVAL + + The number of the audio input is out of bounds. + + + + + diff --git a/Documentation/DocBook/media/v4l/vidioc-enumaudioout.xml b/Documentation/DocBook/media/v4l/vidioc-enumaudioout.xml new file mode 100644 index 00000000..2e87cedb --- /dev/null +++ b/Documentation/DocBook/media/v4l/vidioc-enumaudioout.xml @@ -0,0 +1,79 @@ + + + ioctl VIDIOC_ENUMAUDOUT + &manvol; + + + + VIDIOC_ENUMAUDOUT + Enumerate audio outputs + + + + + + int ioctl + int fd + int request + struct v4l2_audioout *argp + + + + + + Arguments + + + + fd + + &fd; + + + + request + + VIDIOC_ENUMAUDOUT + + + + argp + + + + + + + + + Description + + To query the attributes of an audio output applications +initialize the index field and zero out the +reserved array of a &v4l2-audioout; and +call the VIDIOC_G_AUDOUT ioctl with a pointer +to this structure. Drivers fill the rest of the structure or return an +&EINVAL; when the index is out of bounds. To enumerate all audio +outputs applications shall begin at index zero, incrementing by one +until the driver returns EINVAL. + + Note connectors on a TV card to loop back the received audio +signal to a sound card are not audio outputs in this sense. + + See for a description of +&v4l2-audioout;. + + + + &return-value; + + + + EINVAL + + The number of the audio output is out of bounds. + + + + + diff --git a/Documentation/DocBook/media/v4l/vidioc-enuminput.xml b/Documentation/DocBook/media/v4l/vidioc-enuminput.xml new file mode 100644 index 00000000..3c9a8130 --- /dev/null +++ b/Documentation/DocBook/media/v4l/vidioc-enuminput.xml @@ -0,0 +1,313 @@ + + + ioctl VIDIOC_ENUMINPUT + &manvol; + + + + VIDIOC_ENUMINPUT + Enumerate video inputs + + + + + + int ioctl + int fd + int request + struct v4l2_input +*argp + + + + + + Arguments + + + + fd + + &fd; + + + + request + + VIDIOC_ENUMINPUT + + + + argp + + + + + + + + + Description + + To query the attributes of a video input applications +initialize the index field of &v4l2-input; +and call the VIDIOC_ENUMINPUT ioctl with a +pointer to this structure. Drivers fill the rest of the structure or +return an &EINVAL; when the index is out of bounds. To enumerate all +inputs applications shall begin at index zero, incrementing by one +until the driver returns EINVAL. + + + struct <structname>v4l2_input</structname> + + &cs-str; + + + __u32 + index + Identifies the input, set by the +application. + + + __u8 + name[32] + Name of the video input, a NUL-terminated ASCII +string, for example: "Vin (Composite 2)". This information is intended +for the user, preferably the connector label on the device itself. + + + __u32 + type + Type of the input, see . + + + __u32 + audioset + Drivers can enumerate up to 32 video and +audio inputs. This field shows which audio inputs were selectable as +audio source if this was the currently selected video input. It is a +bit mask. The LSB corresponds to audio input 0, the MSB to input 31. +Any number of bits can be set, or none.When the driver +does not enumerate audio inputs no bits must be set. Applications +shall not interpret this as lack of audio support. Some drivers +automatically select audio sources and do not enumerate them since +there is no choice anyway.For details on audio inputs and +how to select the current input see . + + + __u32 + tuner + Capture devices can have zero or more tuners (RF +demodulators). When the type is set to +V4L2_INPUT_TYPE_TUNER this is an RF connector and +this field identifies the tuner. It corresponds to +&v4l2-tuner; field index. For details on +tuners see . + + + &v4l2-std-id; + std + Every video input supports one or more different +video standards. This field is a set of all supported standards. For +details on video standards and how to switch see . + + + __u32 + status + This field provides status information about the +input. See for flags. +With the exception of the sensor orientation bits status is only valid when this is the +current input. + + + __u32 + capabilities + This field provides capabilities for the +input. See for flags. + + + __u32 + reserved[3] + Reserved for future extensions. Drivers must set +the array to zero. + + + +
+ + + Input Types + + &cs-def; + + + V4L2_INPUT_TYPE_TUNER + 1 + This input uses a tuner (RF demodulator). + + + V4L2_INPUT_TYPE_CAMERA + 2 + Analog baseband input, for example CVBS / +Composite Video, S-Video, RGB. + + + +
+ + + + + Input Status Flags + + + + + + + + General + + + V4L2_IN_ST_NO_POWER + 0x00000001 + Attached device is off. + + + V4L2_IN_ST_NO_SIGNAL + 0x00000002 + + + + V4L2_IN_ST_NO_COLOR + 0x00000004 + The hardware supports color decoding, but does not +detect color modulation in the signal. + + + Sensor Orientation + + + V4L2_IN_ST_HFLIP + 0x00000010 + The input is connected to a device that produces a signal +that is flipped horizontally and does not correct this before passing the +signal to userspace. + + + V4L2_IN_ST_VFLIP + 0x00000020 + The input is connected to a device that produces a signal +that is flipped vertically and does not correct this before passing the +signal to userspace. Note that a 180 degree rotation is the same as HFLIP | VFLIP + + + Analog Video + + + V4L2_IN_ST_NO_H_LOCK + 0x00000100 + No horizontal sync lock. + + + V4L2_IN_ST_COLOR_KILL + 0x00000200 + A color killer circuit automatically disables color +decoding when it detects no color modulation. When this flag is set +the color killer is enabled and has shut off +color decoding. + + + Digital Video + + + V4L2_IN_ST_NO_SYNC + 0x00010000 + No synchronization lock. + + + V4L2_IN_ST_NO_EQU + 0x00020000 + No equalizer lock. + + + V4L2_IN_ST_NO_CARRIER + 0x00040000 + Carrier recovery failed. + + + VCR and Set-Top Box + + + V4L2_IN_ST_MACROVISION + 0x01000000 + Macrovision is an analog copy prevention system +mangling the video signal to confuse video recorders. When this +flag is set Macrovision has been detected. + + + V4L2_IN_ST_NO_ACCESS + 0x02000000 + Conditional access denied. + + + V4L2_IN_ST_VTR + 0x04000000 + VTR time constant. [?] + + + +
+ + + + Input capabilities + + &cs-def; + + + V4L2_IN_CAP_PRESETS + 0x00000001 + This input supports setting DV presets by using VIDIOC_S_DV_PRESET. + + + V4L2_IN_CAP_DV_TIMINGS + 0x00000002 + This input supports setting video timings by using VIDIOC_S_DV_TIMINGS. + + + V4L2_IN_CAP_STD + 0x00000004 + This input supports setting the TV standard by using VIDIOC_S_STD. + + + +
+ + + + &return-value; + + + + EINVAL + + The &v4l2-input; index is +out of bounds. + + + + + diff --git a/Documentation/DocBook/media/v4l/vidioc-enumoutput.xml b/Documentation/DocBook/media/v4l/vidioc-enumoutput.xml new file mode 100644 index 00000000..f4ab0798 --- /dev/null +++ b/Documentation/DocBook/media/v4l/vidioc-enumoutput.xml @@ -0,0 +1,198 @@ + + + ioctl VIDIOC_ENUMOUTPUT + &manvol; + + + + VIDIOC_ENUMOUTPUT + Enumerate video outputs + + + + + + int ioctl + int fd + int request + struct v4l2_output *argp + + + + + + Arguments + + + + fd + + &fd; + + + + request + + VIDIOC_ENUMOUTPUT + + + + argp + + + + + + + + + Description + + To query the attributes of a video outputs applications +initialize the index field of &v4l2-output; +and call the VIDIOC_ENUMOUTPUT ioctl with a +pointer to this structure. Drivers fill the rest of the structure or +return an &EINVAL; when the index is out of bounds. To enumerate all +outputs applications shall begin at index zero, incrementing by one +until the driver returns EINVAL. + + + struct <structname>v4l2_output</structname> + + &cs-str; + + + __u32 + index + Identifies the output, set by the +application. + + + __u8 + name[32] + Name of the video output, a NUL-terminated ASCII +string, for example: "Vout". This information is intended for the +user, preferably the connector label on the device itself. + + + __u32 + type + Type of the output, see . + + + __u32 + audioset + Drivers can enumerate up to 32 video and +audio outputs. This field shows which audio outputs were +selectable as the current output if this was the currently selected +video output. It is a bit mask. The LSB corresponds to audio output 0, +the MSB to output 31. Any number of bits can be set, or +none.When the driver does not enumerate audio outputs no +bits must be set. Applications shall not interpret this as lack of +audio support. Drivers may automatically select audio outputs without +enumerating them.For details on audio outputs and how to +select the current output see . + + + __u32 + modulator + Output devices can have zero or more RF modulators. +When the type is +V4L2_OUTPUT_TYPE_MODULATOR this is an RF +connector and this field identifies the modulator. It corresponds to +&v4l2-modulator; field index. For details +on modulators see . + + + &v4l2-std-id; + std + Every video output supports one or more different +video standards. This field is a set of all supported standards. For +details on video standards and how to switch see . + + + __u32 + capabilities + This field provides capabilities for the +output. See for flags. + + + __u32 + reserved[3] + Reserved for future extensions. Drivers must set +the array to zero. + + + +
+ + + Output Type + + &cs-def; + + + V4L2_OUTPUT_TYPE_MODULATOR + 1 + This output is an analog TV modulator. + + + V4L2_OUTPUT_TYPE_ANALOG + 2 + Analog baseband output, for example Composite / +CVBS, S-Video, RGB. + + + V4L2_OUTPUT_TYPE_ANALOGVGAOVERLAY + 3 + [?] + + + +
+ + + + Output capabilities + + &cs-def; + + + V4L2_OUT_CAP_PRESETS + 0x00000001 + This output supports setting DV presets by using VIDIOC_S_DV_PRESET. + + + V4L2_OUT_CAP_DV_TIMINGS + 0x00000002 + This output supports setting video timings by using VIDIOC_S_DV_TIMINGS. + + + V4L2_OUT_CAP_STD + 0x00000004 + This output supports setting the TV standard by using VIDIOC_S_STD. + + + +
+ + + + &return-value; + + + + EINVAL + + The &v4l2-output; index +is out of bounds. + + + + + diff --git a/Documentation/DocBook/media/v4l/vidioc-enumstd.xml b/Documentation/DocBook/media/v4l/vidioc-enumstd.xml new file mode 100644 index 00000000..80650994 --- /dev/null +++ b/Documentation/DocBook/media/v4l/vidioc-enumstd.xml @@ -0,0 +1,389 @@ + + + ioctl VIDIOC_ENUMSTD + &manvol; + + + + VIDIOC_ENUMSTD + Enumerate supported video standards + + + + + + int ioctl + int fd + int request + struct v4l2_standard *argp + + + + + + Arguments + + + + fd + + &fd; + + + + request + + VIDIOC_ENUMSTD + + + + argp + + + + + + + + + Description + + To query the attributes of a video standard, +especially a custom (driver defined) one, applications initialize the +index field of &v4l2-standard; and call the +VIDIOC_ENUMSTD ioctl with a pointer to this +structure. Drivers fill the rest of the structure or return an +&EINVAL; when the index is out of bounds. To enumerate all standards +applications shall begin at index zero, incrementing by one until the +driver returns EINVAL. Drivers may enumerate a +different set of standards after switching the video input or +output. + The supported standards may overlap and we need an +unambiguous set to find the current standard returned by +VIDIOC_G_STD. + + + + struct <structname>v4l2_standard</structname> + + &cs-str; + + + __u32 + index + Number of the video standard, set by the +application. + + + &v4l2-std-id; + id + The bits in this field identify the standard as +one of the common standards listed in , +or if bits 32 to 63 are set as custom standards. Multiple bits can be +set if the hardware does not distinguish between these standards, +however separate indices do not indicate the opposite. The +id must be unique. No other enumerated +v4l2_standard structure, for this input or +output anyway, can contain the same set of bits. + + + __u8 + name[24] + Name of the standard, a NUL-terminated ASCII +string, for example: "PAL-B/G", "NTSC Japan". This information is +intended for the user. + + + &v4l2-fract; + frameperiod + The frame period (not field period) is numerator +/ denominator. For example M/NTSC has a frame period of 1001 / +30000 seconds. + + + __u32 + framelines + Total lines per frame including blanking, +e. g. 625 for B/PAL. + + + __u32 + reserved[4] + Reserved for future extensions. Drivers must set +the array to zero. + + + +
+ + + struct <structname>v4l2_fract</structname> + + &cs-str; + + + __u32 + numerator + + + + __u32 + denominator + + + + +
+ + + typedef <structname>v4l2_std_id</structname> + + &cs-str; + + + __u64 + v4l2_std_id + This type is a set, each bit representing another +video standard as listed below and in . The 32 most significant bits are reserved +for custom (driver defined) video standards. + + + +
+ + +#define V4L2_STD_PAL_B ((v4l2_std_id)0x00000001) +#define V4L2_STD_PAL_B1 ((v4l2_std_id)0x00000002) +#define V4L2_STD_PAL_G ((v4l2_std_id)0x00000004) +#define V4L2_STD_PAL_H ((v4l2_std_id)0x00000008) +#define V4L2_STD_PAL_I ((v4l2_std_id)0x00000010) +#define V4L2_STD_PAL_D ((v4l2_std_id)0x00000020) +#define V4L2_STD_PAL_D1 ((v4l2_std_id)0x00000040) +#define V4L2_STD_PAL_K ((v4l2_std_id)0x00000080) + +#define V4L2_STD_PAL_M ((v4l2_std_id)0x00000100) +#define V4L2_STD_PAL_N ((v4l2_std_id)0x00000200) +#define V4L2_STD_PAL_Nc ((v4l2_std_id)0x00000400) +#define V4L2_STD_PAL_60 ((v4l2_std_id)0x00000800) +V4L2_STD_PAL_60 is +a hybrid standard with 525 lines, 60 Hz refresh rate, and PAL color +modulation with a 4.43 MHz color subcarrier. Some PAL video recorders +can play back NTSC tapes in this mode for display on a 50/60 Hz agnostic +PAL TV. +#define V4L2_STD_NTSC_M ((v4l2_std_id)0x00001000) +#define V4L2_STD_NTSC_M_JP ((v4l2_std_id)0x00002000) +#define V4L2_STD_NTSC_443 ((v4l2_std_id)0x00004000) +V4L2_STD_NTSC_443 +is a hybrid standard with 525 lines, 60 Hz refresh rate, and NTSC +color modulation with a 4.43 MHz color +subcarrier. +#define V4L2_STD_NTSC_M_KR ((v4l2_std_id)0x00008000) + +#define V4L2_STD_SECAM_B ((v4l2_std_id)0x00010000) +#define V4L2_STD_SECAM_D ((v4l2_std_id)0x00020000) +#define V4L2_STD_SECAM_G ((v4l2_std_id)0x00040000) +#define V4L2_STD_SECAM_H ((v4l2_std_id)0x00080000) +#define V4L2_STD_SECAM_K ((v4l2_std_id)0x00100000) +#define V4L2_STD_SECAM_K1 ((v4l2_std_id)0x00200000) +#define V4L2_STD_SECAM_L ((v4l2_std_id)0x00400000) +#define V4L2_STD_SECAM_LC ((v4l2_std_id)0x00800000) + +/* ATSC/HDTV */ +#define V4L2_STD_ATSC_8_VSB ((v4l2_std_id)0x01000000) +#define V4L2_STD_ATSC_16_VSB ((v4l2_std_id)0x02000000) +V4L2_STD_ATSC_8_VSB and +V4L2_STD_ATSC_16_VSB are U.S. terrestrial digital +TV standards. Presently the V4L2 API does not support digital TV. See +also the Linux DVB API at http://linuxtv.org. + +#define V4L2_STD_PAL_BG (V4L2_STD_PAL_B |\ + V4L2_STD_PAL_B1 |\ + V4L2_STD_PAL_G) +#define V4L2_STD_B (V4L2_STD_PAL_B |\ + V4L2_STD_PAL_B1 |\ + V4L2_STD_SECAM_B) +#define V4L2_STD_GH (V4L2_STD_PAL_G |\ + V4L2_STD_PAL_H |\ + V4L2_STD_SECAM_G |\ + V4L2_STD_SECAM_H) +#define V4L2_STD_PAL_DK (V4L2_STD_PAL_D |\ + V4L2_STD_PAL_D1 |\ + V4L2_STD_PAL_K) +#define V4L2_STD_PAL (V4L2_STD_PAL_BG |\ + V4L2_STD_PAL_DK |\ + V4L2_STD_PAL_H |\ + V4L2_STD_PAL_I) +#define V4L2_STD_NTSC (V4L2_STD_NTSC_M |\ + V4L2_STD_NTSC_M_JP |\ + V4L2_STD_NTSC_M_KR) +#define V4L2_STD_MN (V4L2_STD_PAL_M |\ + V4L2_STD_PAL_N |\ + V4L2_STD_PAL_Nc |\ + V4L2_STD_NTSC) +#define V4L2_STD_SECAM_DK (V4L2_STD_SECAM_D |\ + V4L2_STD_SECAM_K |\ + V4L2_STD_SECAM_K1) +#define V4L2_STD_DK (V4L2_STD_PAL_DK |\ + V4L2_STD_SECAM_DK) + +#define V4L2_STD_SECAM (V4L2_STD_SECAM_B |\ + V4L2_STD_SECAM_G |\ + V4L2_STD_SECAM_H |\ + V4L2_STD_SECAM_DK |\ + V4L2_STD_SECAM_L |\ + V4L2_STD_SECAM_LC) + +#define V4L2_STD_525_60 (V4L2_STD_PAL_M |\ + V4L2_STD_PAL_60 |\ + V4L2_STD_NTSC |\ + V4L2_STD_NTSC_443) +#define V4L2_STD_625_50 (V4L2_STD_PAL |\ + V4L2_STD_PAL_N |\ + V4L2_STD_PAL_Nc |\ + V4L2_STD_SECAM) + +#define V4L2_STD_UNKNOWN 0 +#define V4L2_STD_ALL (V4L2_STD_525_60 |\ + V4L2_STD_625_50) + + + + Video Standards (based on [<xref linkend="itu470" />]) + + + + + + + + + + + + + + + + Characteristics + M/NTSCJapan uses a standard +similar to M/NTSC +(V4L2_STD_NTSC_M_JP). + M/PAL + N/PAL The values in +brackets apply to the combination N/PAL a.k.a. +NC used in Argentina +(V4L2_STD_PAL_Nc). + B, B1, G/PAL + D, D1, K/PAL + H/PAL + I/PAL + B, G/SECAM + D, K/SECAM + K1/SECAM + L/SECAM + + + + + Frame lines + 525 + 625 + + + Frame period (s) + 1001/30000 + 1/25 + + + Chrominance sub-carrier frequency (Hz) + 3579545 ± 10 + 3579611.49 ± 10 + 4433618.75 ± 5 (3582056.25 +± 5) + 4433618.75 ± 5 + 4433618.75 ± 1 + fOR = +4406250 ± 2000, fOB = 4250000 +± 2000 + + + Nominal radio-frequency channel bandwidth +(MHz) + 6 + 6 + 6 + B: 7; B1, G: 8 + 8 + 8 + 8 + 8 + 8 + 8 + 8 + + + Sound carrier relative to vision carrier +(MHz) + + 4.5 + + 4.5 + + 4.5 + + 5.5 ± 0.001 +In the Federal Republic of Germany, Austria, Italy, +the Netherlands, Slovakia and Switzerland a system of two sound +carriers is used, the frequency of the second carrier being +242.1875 kHz above the frequency of the first sound carrier. For +stereophonic sound transmissions a similar system is used in +Australia. New Zealand uses a sound +carrier displaced 5.4996 ± 0.0005 MHz from the vision +carrier. In Denmark, Finland, New +Zealand, Sweden and Spain a system of two sound carriers is used. In +Iceland, Norway and Poland the same system is being introduced. The +second carrier is 5.85 MHz above the vision carrier and is DQPSK +modulated with 728 kbit/s sound and data multiplex. (NICAM +system) In the United Kingdom, a +system of two sound carriers is used. The second sound carrier is +6.552 MHz above the vision carrier and is DQPSK modulated with a +728 kbit/s sound and data multiplex able to carry two sound +channels. (NICAM system) + + 6.5 ± 0.001 + + 5.5 + + 5.9996 ± 0.0005 + + 5.5 ± 0.001 + + 6.5 ± 0.001 + + 6.5 + + 6.5 In France, a +digital carrier 5.85 MHz away from the vision carrier may be used in +addition to the main sound carrier. It is modulated in differentially +encoded QPSK with a 728 kbit/s sound and data multiplexer capable of +carrying two sound channels. (NICAM +system) + + + +
+ + + + &return-value; + + + + EINVAL + + The &v4l2-standard; index +is out of bounds. + + + + ENODATA + + Standard video timings are not supported for this input or output. + + + + + diff --git a/Documentation/DocBook/media/v4l/vidioc-expbuf.xml b/Documentation/DocBook/media/v4l/vidioc-expbuf.xml new file mode 100644 index 00000000..e287c8fc --- /dev/null +++ b/Documentation/DocBook/media/v4l/vidioc-expbuf.xml @@ -0,0 +1,208 @@ + + + + ioctl VIDIOC_EXPBUF + &manvol; + + + + VIDIOC_EXPBUF + Export a buffer as a DMABUF file descriptor. + + + + + + int ioctl + int fd + int request + struct v4l2_exportbuffer *argp + + + + + + Arguments + + + + fd + + &fd; + + + + request + + VIDIOC_EXPBUF + + + + argp + + + + + + + + + Description + + + Experimental + This is an experimental + interface and may change in the future. + + +This ioctl is an extension to the memory +mapping I/O method, therefore it is available only for +V4L2_MEMORY_MMAP buffers. It can be used to export a +buffer as a DMABUF file at any time after buffers have been allocated with the +&VIDIOC-REQBUFS; ioctl. + + To export a buffer, applications fill &v4l2-exportbuffer;. The + type field is set to the same buffer type as was +previously used with &v4l2-requestbuffers; type . +Applications must also set the index field. Valid +index numbers range from zero to the number of buffers allocated with +&VIDIOC-REQBUFS; (&v4l2-requestbuffers; count ) +minus one. For the multi-planar API, applications set the plane + field to the index of the plane to be exported. Valid planes +range from zero to the maximal number of valid planes for the currently active +format. For the single-planar API, applications must set plane + to zero. Additional flags may be posted in the +flags field. Refer to a manual for open() for details. +Currently only O_CLOEXEC is supported. All other fields must be set to zero. +In the case of multi-planar API, every plane is exported separately using +multiple VIDIOC_EXPBUF calls. + + After calling VIDIOC_EXPBUF the fd + field will be set by a driver. This is a DMABUF file +descriptor. The application may pass it to other DMABUF-aware devices. Refer to +DMABUF importing for details about importing +DMABUF files into V4L2 nodes. It is recommended to close a DMABUF file when it +is no longer used to allow the associated memory to be reclaimed. + + + + Examples + + + Exporting a buffer. + +int buffer_export(int v4lfd, &v4l2-buf-type; bt, int index, int *dmafd) +{ + &v4l2-exportbuffer; expbuf; + + memset(&expbuf, 0, sizeof(expbuf)); + expbuf.type = bt; + expbuf.index = index; + if (ioctl(v4lfd, &VIDIOC-EXPBUF;, &expbuf) == -1) { + perror("VIDIOC_EXPBUF"); + return -1; + } + + *dmafd = expbuf.fd; + + return 0; +} + + + + + Exporting a buffer using the multi-planar API. + +int buffer_export_mp(int v4lfd, &v4l2-buf-type; bt, int index, + int dmafd[], int n_planes) +{ + int i; + + for (i = 0; i < n_planes; ++i) { + &v4l2-exportbuffer; expbuf; + + memset(&expbuf, 0, sizeof(expbuf)); + expbuf.type = bt; + expbuf.index = index; + expbuf.plane = i; + if (ioctl(v4lfd, &VIDIOC-EXPBUF;, &expbuf) == -1) { + perror("VIDIOC_EXPBUF"); + while (i) + close(dmafd[--i]); + return -1; + } + dmafd[i] = expbuf.fd; + } + + return 0; +} + + + + + struct <structname>v4l2_exportbuffer</structname> + + &cs-str; + + + __u32 + type + Type of the buffer, same as &v4l2-format; +type or &v4l2-requestbuffers; +type, set by the application. See + + + __u32 + index + Number of the buffer, set by the application. This field is +only used for memory mapping I/O and can range from +zero to the number of buffers allocated with the &VIDIOC-REQBUFS; and/or +&VIDIOC-CREATE-BUFS; ioctls. + + + __u32 + plane + Index of the plane to be exported when using the +multi-planar API. Otherwise this value must be set to zero. + + + __u32 + flags + Flags for the newly created file, currently only +O_CLOEXEC is supported, refer to the manual of open() for more +details. + + + __s32 + fd + The DMABUF file descriptor associated with a buffer. Set by + the driver. + + + __u32 + reserved[11] + Reserved field for future use. Must be set to zero. + + + +
+ + + + + &return-value; + + + EINVAL + + A queue is not in MMAP mode or DMABUF exporting is not +supported or flags or type + or index or plane + fields are invalid. + + + + + + diff --git a/Documentation/DocBook/media/v4l/vidioc-g-audio.xml b/Documentation/DocBook/media/v4l/vidioc-g-audio.xml new file mode 100644 index 00000000..d7bb9b37 --- /dev/null +++ b/Documentation/DocBook/media/v4l/vidioc-g-audio.xml @@ -0,0 +1,172 @@ + + + ioctl VIDIOC_G_AUDIO, VIDIOC_S_AUDIO + &manvol; + + + + VIDIOC_G_AUDIO + VIDIOC_S_AUDIO + Query or select the current audio input and its +attributes + + + + + + int ioctl + int fd + int request + struct v4l2_audio *argp + + + + + int ioctl + int fd + int request + const struct v4l2_audio *argp + + + + + + Arguments + + + + fd + + &fd; + + + + request + + VIDIOC_G_AUDIO, VIDIOC_S_AUDIO + + + + argp + + + + + + + + + Description + + To query the current audio input applications zero out the +reserved array of a &v4l2-audio; +and call the VIDIOC_G_AUDIO ioctl with a pointer +to this structure. Drivers fill the rest of the structure or return an +&EINVAL; when the device has no audio inputs, or none which combine +with the current video input. + + Audio inputs have one writable property, the audio mode. To +select the current audio input and change the +audio mode, applications initialize the +index and mode +fields, and the +reserved array of a +v4l2_audio structure and call the +VIDIOC_S_AUDIO ioctl. Drivers may switch to a +different audio mode if the request cannot be satisfied. However, this +is a write-only ioctl, it does not return the actual new audio +mode. + + + struct <structname>v4l2_audio</structname> + + &cs-str; + + + __u32 + index + Identifies the audio input, set by the +driver or application. + + + __u8 + name[32] + Name of the audio input, a NUL-terminated ASCII +string, for example: "Line In". This information is intended for the +user, preferably the connector label on the device itself. + + + __u32 + capability + Audio capability flags, see . + + + __u32 + mode + Audio mode flags set by drivers and applications (on + VIDIOC_S_AUDIO ioctl), see . + + + __u32 + reserved[2] + Reserved for future extensions. Drivers and +applications must set the array to zero. + + + +
+ + + Audio Capability Flags + + &cs-def; + + + V4L2_AUDCAP_STEREO + 0x00001 + This is a stereo input. The flag is intended to +automatically disable stereo recording etc. when the signal is always +monaural. The API provides no means to detect if stereo is +received, unless the audio input belongs to a +tuner. + + + V4L2_AUDCAP_AVL + 0x00002 + Automatic Volume Level mode is supported. + + + +
+ + + Audio Mode Flags + + &cs-def; + + + V4L2_AUDMODE_AVL + 0x00001 + AVL mode is on. + + + +
+ + + + &return-value; + + + + EINVAL + + No audio inputs combine with the current video input, +or the number of the selected audio input is out of bounds or it does +not combine. + + + + + diff --git a/Documentation/DocBook/media/v4l/vidioc-g-audioout.xml b/Documentation/DocBook/media/v4l/vidioc-g-audioout.xml new file mode 100644 index 00000000..200a2704 --- /dev/null +++ b/Documentation/DocBook/media/v4l/vidioc-g-audioout.xml @@ -0,0 +1,138 @@ + + + ioctl VIDIOC_G_AUDOUT, VIDIOC_S_AUDOUT + &manvol; + + + + VIDIOC_G_AUDOUT + VIDIOC_S_AUDOUT + Query or select the current audio output + + + + + + int ioctl + int fd + int request + struct v4l2_audioout *argp + + + + + int ioctl + int fd + int request + const struct v4l2_audioout *argp + + + + + + Arguments + + + + fd + + &fd; + + + + request + + VIDIOC_G_AUDOUT, VIDIOC_S_AUDOUT + + + + argp + + + + + + + + + Description + + To query the current audio output applications zero out the +reserved array of a &v4l2-audioout; and +call the VIDIOC_G_AUDOUT ioctl with a pointer +to this structure. Drivers fill the rest of the structure or return an +&EINVAL; when the device has no audio inputs, or none which combine +with the current video output. + + Audio outputs have no writable properties. Nevertheless, to +select the current audio output applications can initialize the +index field and +reserved array (which in the future may +contain writable properties) of a +v4l2_audioout structure and call the +VIDIOC_S_AUDOUT ioctl. Drivers switch to the +requested output or return the &EINVAL; when the index is out of +bounds. This is a write-only ioctl, it does not return the current +audio output attributes as VIDIOC_G_AUDOUT +does. + + Note connectors on a TV card to loop back the received audio +signal to a sound card are not audio outputs in this sense. + + + struct <structname>v4l2_audioout</structname> + + &cs-str; + + + __u32 + index + Identifies the audio output, set by the +driver or application. + + + __u8 + name[32] + Name of the audio output, a NUL-terminated ASCII +string, for example: "Line Out". This information is intended for the +user, preferably the connector label on the device itself. + + + __u32 + capability + Audio capability flags, none defined yet. Drivers +must set this field to zero. + + + __u32 + mode + Audio mode, none defined yet. Drivers and +applications (on VIDIOC_S_AUDOUT) must set this +field to zero. + + + __u32 + reserved[2] + Reserved for future extensions. Drivers and +applications must set the array to zero. + + + +
+ + + + &return-value; + + + + EINVAL + + No audio outputs combine with the current video +output, or the number of the selected audio output is out of bounds or +it does not combine. + + + + + diff --git a/Documentation/DocBook/media/v4l/vidioc-g-crop.xml b/Documentation/DocBook/media/v4l/vidioc-g-crop.xml new file mode 100644 index 00000000..75c6a93d --- /dev/null +++ b/Documentation/DocBook/media/v4l/vidioc-g-crop.xml @@ -0,0 +1,124 @@ + + + ioctl VIDIOC_G_CROP, VIDIOC_S_CROP + &manvol; + + + + VIDIOC_G_CROP + VIDIOC_S_CROP + Get or set the current cropping rectangle + + + + + + int ioctl + int fd + int request + struct v4l2_crop *argp + + + + + int ioctl + int fd + int request + const struct v4l2_crop *argp + + + + + + Arguments + + + + fd + + &fd; + + + + request + + VIDIOC_G_CROP, VIDIOC_S_CROP + + + + argp + + + + + + + + + Description + + To query the cropping rectangle size and position +applications set the type field of a +v4l2_crop structure to the respective buffer +(stream) type and call the VIDIOC_G_CROP ioctl +with a pointer to this structure. The driver fills the rest of the +structure or returns the &EINVAL; if cropping is not supported. + + To change the cropping rectangle applications initialize the +type and &v4l2-rect; substructure named +c of a v4l2_crop structure and call the +VIDIOC_S_CROP ioctl with a pointer to this +structure. + + The driver first adjusts the requested dimensions against +hardware limits, &ie; the bounds given by the capture/output window, +and it rounds to the closest possible values of horizontal and +vertical offset, width and height. In particular the driver must round +the vertical offset of the cropping rectangle to frame lines modulo +two, such that the field order cannot be confused. + + Second the driver adjusts the image size (the opposite +rectangle of the scaling process, source or target depending on the +data direction) to the closest size possible while maintaining the +current horizontal and vertical scaling factor. + + Finally the driver programs the hardware with the actual +cropping and image parameters. VIDIOC_S_CROP is a +write-only ioctl, it does not return the actual parameters. To query +them applications must call VIDIOC_G_CROP and +&VIDIOC-G-FMT;. When the parameters are unsuitable the application may +modify the cropping or image parameters and repeat the cycle until +satisfactory parameters have been negotiated. + + When cropping is not supported then no parameters are +changed and VIDIOC_S_CROP returns the +&EINVAL;. + + + struct <structname>v4l2_crop</structname> + + &cs-str; + + + __u32 + type + Type of the data stream, set by the application. +Only these types are valid here: V4L2_BUF_TYPE_VIDEO_CAPTURE, +V4L2_BUF_TYPE_VIDEO_OUTPUT and +V4L2_BUF_TYPE_VIDEO_OVERLAY. See . + + + &v4l2-rect; + c + Cropping rectangle. The same co-ordinate system as +for &v4l2-cropcap; bounds is used. + + + +
+ + + + &return-value; + + diff --git a/Documentation/DocBook/media/v4l/vidioc-g-ctrl.xml b/Documentation/DocBook/media/v4l/vidioc-g-ctrl.xml new file mode 100644 index 00000000..ee2820d6 --- /dev/null +++ b/Documentation/DocBook/media/v4l/vidioc-g-ctrl.xml @@ -0,0 +1,133 @@ + + + ioctl VIDIOC_G_CTRL, VIDIOC_S_CTRL + &manvol; + + + + VIDIOC_G_CTRL + VIDIOC_S_CTRL + Get or set the value of a control + + + + + + int ioctl + int fd + int request + struct v4l2_control +*argp + + + + + + Arguments + + + + fd + + &fd; + + + + request + + VIDIOC_G_CTRL, VIDIOC_S_CTRL + + + + argp + + + + + + + + + Description + + To get the current value of a control applications +initialize the id field of a struct +v4l2_control and call the +VIDIOC_G_CTRL ioctl with a pointer to this +structure. To change the value of a control applications initialize +the id and value +fields of a struct v4l2_control and call the +VIDIOC_S_CTRL ioctl. + + When the id is invalid drivers +return an &EINVAL;. When the value is out +of bounds drivers can choose to take the closest valid value or return +an &ERANGE;, whatever seems more appropriate. However, +VIDIOC_S_CTRL is a write-only ioctl, it does not +return the actual new value. If the value +is inappropriate for the control (e.g. if it refers to an unsupported +menu index of a menu control), then &EINVAL; is returned as well. + + These ioctls work only with user controls. For other +control classes the &VIDIOC-G-EXT-CTRLS;, &VIDIOC-S-EXT-CTRLS; or +&VIDIOC-TRY-EXT-CTRLS; must be used. + + + struct <structname>v4l2_control</structname> + + &cs-str; + + + __u32 + id + Identifies the control, set by the +application. + + + __s32 + value + New value or current value. + + + +
+ + + + &return-value; + + + + EINVAL + + The &v4l2-control; id is +invalid or the value is inappropriate for +the given control (i.e. if a menu item is selected that is not supported +by the driver according to &VIDIOC-QUERYMENU;). + + + + ERANGE + + The &v4l2-control; value +is out of bounds. + + + + EBUSY + + The control is temporarily not changeable, possibly +because another applications took over control of the device function +this control belongs to. + + + + EACCES + + Attempt to set a read-only control or to get a + write-only control. + + + + + diff --git a/Documentation/DocBook/media/v4l/vidioc-g-dv-preset.xml b/Documentation/DocBook/media/v4l/vidioc-g-dv-preset.xml new file mode 100644 index 00000000..b9ea3763 --- /dev/null +++ b/Documentation/DocBook/media/v4l/vidioc-g-dv-preset.xml @@ -0,0 +1,113 @@ + + + ioctl VIDIOC_G_DV_PRESET, VIDIOC_S_DV_PRESET + &manvol; + + + + VIDIOC_G_DV_PRESET + VIDIOC_S_DV_PRESET + Query or select the DV preset of the current input or output + + + + + + int ioctl + int fd + int request + struct v4l2_dv_preset *argp + + + + + + Arguments + + + + fd + + &fd; + + + + request + + VIDIOC_G_DV_PRESET, VIDIOC_S_DV_PRESET + + + + argp + + + + + + + + + Description + + These ioctls are deprecated. + New drivers and applications should use &VIDIOC-G-DV-TIMINGS; and &VIDIOC-S-DV-TIMINGS; + instead. + + + To query and select the current DV preset, applications +use the VIDIOC_G_DV_PRESET and VIDIOC_S_DV_PRESET +ioctls which take a pointer to a &v4l2-dv-preset; type as argument. +Applications must zero the reserved array in &v4l2-dv-preset;. +VIDIOC_G_DV_PRESET returns a dv preset in the field +preset of &v4l2-dv-preset;. + + VIDIOC_S_DV_PRESET accepts a pointer to a &v4l2-dv-preset; +that has the preset value to be set. Applications must zero the reserved array in &v4l2-dv-preset;. +If the preset is not supported, it returns an &EINVAL; + + + + &return-value; + + + + EINVAL + + This ioctl is not supported, or the +VIDIOC_S_DV_PRESET,VIDIOC_S_DV_PRESET parameter was unsuitable. + + + + ENODATA + + Digital video presets are not supported for this input or output. + + + + EBUSY + + The device is busy and therefore can not change the preset. + + + + + + struct <structname>v4l2_dv_preset</structname> + + &cs-str; + + + __u32 + preset + Preset value to represent the digital video timings + + + __u32 + reserved[4] + Reserved fields for future use + + + +
+ + diff --git a/Documentation/DocBook/media/v4l/vidioc-g-dv-timings.xml b/Documentation/DocBook/media/v4l/vidioc-g-dv-timings.xml new file mode 100644 index 00000000..72369707 --- /dev/null +++ b/Documentation/DocBook/media/v4l/vidioc-g-dv-timings.xml @@ -0,0 +1,331 @@ + + + ioctl VIDIOC_G_DV_TIMINGS, VIDIOC_S_DV_TIMINGS + &manvol; + + + + VIDIOC_G_DV_TIMINGS + VIDIOC_S_DV_TIMINGS + Get or set DV timings for input or output + + + + + + int ioctl + int fd + int request + struct v4l2_dv_timings *argp + + + + + + Arguments + + + + fd + + &fd; + + + + request + + VIDIOC_G_DV_TIMINGS, VIDIOC_S_DV_TIMINGS + + + + argp + + + + + + + + + Description + To set DV timings for the input or output, applications use the +VIDIOC_S_DV_TIMINGS ioctl and to get the current timings, +applications use the VIDIOC_G_DV_TIMINGS ioctl. The detailed timing +information is filled in using the structure &v4l2-dv-timings;. These ioctls take +a pointer to the &v4l2-dv-timings; structure as argument. If the ioctl is not supported +or the timing values are not correct, the driver returns &EINVAL;. +The linux/v4l2-dv-timings.h header can be used to get the +timings of the formats in the and +standards. If the current input or output does not support DV timings (e.g. if +&VIDIOC-ENUMINPUT; does not set the V4L2_IN_CAP_DV_TIMINGS flag), then +&ENODATA; is returned. + + + + &return-value; + + + + EINVAL + + This ioctl is not supported, or the +VIDIOC_S_DV_TIMINGS parameter was unsuitable. + + + + ENODATA + + Digital video timings are not supported for this input or output. + + + + EBUSY + + The device is busy and therefore can not change the timings. + + + + + + struct <structname>v4l2_bt_timings</structname> + + &cs-str; + + + __u32 + width + Width of the active video in pixels. + + + __u32 + height + Height of the active video frame in lines. So for interlaced formats the + height of the active video in each field is height/2. + + + __u32 + interlaced + Progressive (0) or interlaced (1) + + + __u32 + polarities + This is a bit mask that defines polarities of sync signals. +bit 0 (V4L2_DV_VSYNC_POS_POL) is for vertical sync polarity and bit 1 (V4L2_DV_HSYNC_POS_POL) is for horizontal sync polarity. If the bit is set +(1) it is positive polarity and if is cleared (0), it is negative polarity. + + + __u64 + pixelclock + Pixel clock in Hz. Ex. 74.25MHz->74250000 + + + __u32 + hfrontporch + Horizontal front porch in pixels + + + __u32 + hsync + Horizontal sync length in pixels + + + __u32 + hbackporch + Horizontal back porch in pixels + + + __u32 + vfrontporch + Vertical front porch in lines. For interlaced formats this refers to the + odd field (aka field 1). + + + __u32 + vsync + Vertical sync length in lines. For interlaced formats this refers to the + odd field (aka field 1). + + + __u32 + vbackporch + Vertical back porch in lines. For interlaced formats this refers to the + odd field (aka field 1). + + + __u32 + il_vfrontporch + Vertical front porch in lines for the even field (aka field 2) of + interlaced field formats. + + + __u32 + il_vsync + Vertical sync length in lines for the even field (aka field 2) of + interlaced field formats. + + + __u32 + il_vbackporch + Vertical back porch in lines for the even field (aka field 2) of + interlaced field formats. + + + __u32 + standards + The video standard(s) this format belongs to. This will be filled in by + the driver. Applications must set this to 0. See + for a list of standards. + + + __u32 + flags + Several flags giving more information about the format. + See for a description of the flags. + + + + +
+ + + struct <structname>v4l2_dv_timings</structname> + + &cs-str; + + + __u32 + type + + Type of DV timings as listed in . + + + union + + + + + + &v4l2-bt-timings; + bt + Timings defined by BT.656/1120 specifications + + + + __u32 + reserved[32] + + + + +
+ + + DV Timing types + + &cs-str; + + + Timing type + value + Description + + + + + + + + V4L2_DV_BT_656_1120 + 0 + BT.656/1120 timings + + + +
+ + DV BT Timing standards + + &cs-str; + + + Timing standard + Description + + + + + + + V4L2_DV_BT_STD_CEA861 + The timings follow the CEA-861 Digital TV Profile standard + + + V4L2_DV_BT_STD_DMT + The timings follow the VESA Discrete Monitor Timings standard + + + V4L2_DV_BT_STD_CVT + The timings follow the VESA Coordinated Video Timings standard + + + V4L2_DV_BT_STD_GTF + The timings follow the VESA Generalized Timings Formula standard + + + +
+ + DV BT Timing flags + + &cs-str; + + + Flag + Description + + + + + + + V4L2_DV_FL_REDUCED_BLANKING + CVT/GTF specific: the timings use reduced blanking (CVT) or the 'Secondary +GTF' curve (GTF). In both cases the horizontal and/or vertical blanking +intervals are reduced, allowing a higher resolution over the same +bandwidth. This is a read-only flag, applications must not set this. + + + + V4L2_DV_FL_CAN_REDUCE_FPS + CEA-861 specific: set for CEA-861 formats with a framerate that is a multiple +of six. These formats can be optionally played at 1 / 1.001 speed to +be compatible with 60 Hz based standards such as NTSC and PAL-M that use a framerate of +29.97 frames per second. If the transmitter can't generate such frequencies, then the +flag will also be cleared. This is a read-only flag, applications must not set this. + + + + V4L2_DV_FL_REDUCED_FPS + CEA-861 specific: only valid for video transmitters, the flag is cleared +by receivers. It is also only valid for formats with the V4L2_DV_FL_CAN_REDUCE_FPS flag +set, for other formats the flag will be cleared by the driver. + +If the application sets this flag, then the pixelclock used to set up the transmitter is +divided by 1.001 to make it compatible with NTSC framerates. If the transmitter +can't generate such frequencies, then the flag will also be cleared. + + + + V4L2_DV_FL_HALF_LINE + Specific to interlaced formats: if set, then field 1 (aka the odd field) +is really one half-line longer and field 2 (aka the even field) is really one half-line +shorter, so each field has exactly the same number of half-lines. Whether half-lines can be +detected or used depends on the hardware. + + + + +
+ + diff --git a/Documentation/DocBook/media/v4l/vidioc-g-enc-index.xml b/Documentation/DocBook/media/v4l/vidioc-g-enc-index.xml new file mode 100644 index 00000000..be25029a --- /dev/null +++ b/Documentation/DocBook/media/v4l/vidioc-g-enc-index.xml @@ -0,0 +1,189 @@ + + + ioctl VIDIOC_G_ENC_INDEX + &manvol; + + + + VIDIOC_G_ENC_INDEX + Get meta data about a compressed video stream + + + + + + int ioctl + int fd + int request + struct v4l2_enc_idx *argp + + + + + + Arguments + + + + fd + + &fd; + + + + request + + VIDIOC_G_ENC_INDEX + + + + argp + + + + + + + + + Description + + The VIDIOC_G_ENC_INDEX ioctl provides +meta data about a compressed video stream the same or another +application currently reads from the driver, which is useful for +random access into the stream without decoding it. + + To read the data applications must call +VIDIOC_G_ENC_INDEX with a pointer to a +&v4l2-enc-idx;. On success the driver fills the +entry array, stores the number of elements +written in the entries field, and +initializes the entries_cap field. + + Each element of the entry array +contains meta data about one picture. A +VIDIOC_G_ENC_INDEX call reads up to +V4L2_ENC_IDX_ENTRIES entries from a driver +buffer, which can hold up to entries_cap +entries. This number can be lower or higher than +V4L2_ENC_IDX_ENTRIES, but not zero. When the +application fails to read the meta data in time the oldest entries +will be lost. When the buffer is empty or no capturing/encoding is in +progress, entries will be zero. + + Currently this ioctl is only defined for MPEG-2 program +streams and video elementary streams. + + + struct <structname>v4l2_enc_idx</structname> + + &cs-str; + + + __u32 + entries + The number of entries the driver stored in the +entry array. + + + __u32 + entries_cap + The number of entries the driver can +buffer. Must be greater than zero. + + + __u32 + reserved[4] + Reserved for future extensions. +Drivers must set the array to zero. + + + &v4l2-enc-idx-entry; + entry[V4L2_ENC_IDX_ENTRIES] + Meta data about a compressed video stream. Each +element of the array corresponds to one picture, sorted in ascending +order by their offset. + + + +
+ + + struct <structname>v4l2_enc_idx_entry</structname> + + &cs-str; + + + __u64 + offset + The offset in bytes from the beginning of the +compressed video stream to the beginning of this picture, that is a +PES packet header as defined in or a picture +header as defined in . When +the encoder is stopped, the driver resets the offset to zero. + + + __u64 + pts + The 33 bit Presentation Time +Stamp of this picture as defined in . + + + __u32 + length + The length of this picture in bytes. + + + __u32 + flags + Flags containing the coding type of this picture, see . + + + __u32 + reserved[2] + Reserved for future extensions. +Drivers must set the array to zero. + + + +
+ + + Index Entry Flags + + &cs-def; + + + V4L2_ENC_IDX_FRAME_I + 0x00 + This is an Intra-coded picture. + + + V4L2_ENC_IDX_FRAME_P + 0x01 + This is a Predictive-coded picture. + + + V4L2_ENC_IDX_FRAME_B + 0x02 + This is a Bidirectionally predictive-coded +picture. + + + V4L2_ENC_IDX_FRAME_MASK + 0x0F + AND the flags field with +this mask to obtain the picture coding type. + + + +
+ + + + &return-value; + + diff --git a/Documentation/DocBook/media/v4l/vidioc-g-ext-ctrls.xml b/Documentation/DocBook/media/v4l/vidioc-g-ext-ctrls.xml new file mode 100644 index 00000000..4e16112d --- /dev/null +++ b/Documentation/DocBook/media/v4l/vidioc-g-ext-ctrls.xml @@ -0,0 +1,378 @@ + + + ioctl VIDIOC_G_EXT_CTRLS, VIDIOC_S_EXT_CTRLS, +VIDIOC_TRY_EXT_CTRLS + &manvol; + + + + VIDIOC_G_EXT_CTRLS + VIDIOC_S_EXT_CTRLS + VIDIOC_TRY_EXT_CTRLS + Get or set the value of several controls, try control +values + + + + + + int ioctl + int fd + int request + struct v4l2_ext_controls +*argp + + + + + + Arguments + + + + fd + + &fd; + + + + request + + VIDIOC_G_EXT_CTRLS, VIDIOC_S_EXT_CTRLS, +VIDIOC_TRY_EXT_CTRLS + + + + argp + + + + + + + + + Description + + These ioctls allow the caller to get or set multiple +controls atomically. Control IDs are grouped into control classes (see +) and all controls in the control array +must belong to the same control class. + + Applications must always fill in the +count, +ctrl_class, +controls and +reserved fields of &v4l2-ext-controls;, and +initialize the &v4l2-ext-control; array pointed to by the +controls fields. + + To get the current value of a set of controls applications +initialize the id, +size and reserved2 fields +of each &v4l2-ext-control; and call the +VIDIOC_G_EXT_CTRLS ioctl. String controls controls +must also set the string field. + + If the size is too small to +receive the control result (only relevant for pointer-type controls +like strings), then the driver will set size +to a valid value and return an &ENOSPC;. You should re-allocate the +string memory to this new size and try again. It is possible that the +same issue occurs again if the string has grown in the meantime. It is +recommended to call &VIDIOC-QUERYCTRL; first and use +maximum+1 as the new size +value. It is guaranteed that that is sufficient memory. + + + To change the value of a set of controls applications +initialize the id, size, +reserved2 and +value/string fields of each &v4l2-ext-control; and +call the VIDIOC_S_EXT_CTRLS ioctl. The controls +will only be set if all control values are +valid. + + To check if a set of controls have correct values applications +initialize the id, size, +reserved2 and +value/string fields of each &v4l2-ext-control; and +call the VIDIOC_TRY_EXT_CTRLS ioctl. It is up to +the driver whether wrong values are automatically adjusted to a valid +value or if an error is returned. + + When the id or +ctrl_class is invalid drivers return an +&EINVAL;. When the value is out of bounds drivers can choose to take +the closest valid value or return an &ERANGE;, whatever seems more +appropriate. In the first case the new value is set in +&v4l2-ext-control;. If the new control value is inappropriate (e.g. the +given menu index is not supported by the menu control), then this will +also result in an &EINVAL; error. + + The driver will only set/get these controls if all control +values are correct. This prevents the situation where only some of the +controls were set/get. Only low-level errors (⪚ a failed i2c +command) can still cause this situation. + + + struct <structname>v4l2_ext_control</structname> + + &cs-ustr; + + + __u32 + id + + Identifies the control, set by the +application. + + + __u32 + size + + The total size in bytes of the payload of this +control. This is normally 0, but for pointer controls this should be +set to the size of the memory containing the payload, or that will +receive the payload. If VIDIOC_G_EXT_CTRLS finds +that this value is less than is required to store +the payload result, then it is set to a value large enough to store the +payload result and ENOSPC is returned. Note that for string controls +this size field should not be confused with the length of the string. +This field refers to the size of the memory that contains the string. +The actual length of the string may well be much smaller. + + + + __u32 + reserved2[1] + + Reserved for future extensions. Drivers and +applications must set the array to zero. + + + union + (anonymous) + + + + __s32 + value + New value or current value. + + + + __s64 + value64 + New value or current value. + + + + char * + string + A pointer to a string. + + + +
+ + + struct <structname>v4l2_ext_controls</structname> + + &cs-str; + + + __u32 + ctrl_class + The control class to which all controls belong, see +. Drivers that use a kernel framework for handling +controls will also accept a value of 0 here, meaning that the controls can +belong to any control class. Whether drivers support this can be tested by setting +ctrl_class to 0 and calling VIDIOC_TRY_EXT_CTRLS +with a count of 0. If that succeeds, then the driver +supports this feature. + + + __u32 + count + The number of controls in the controls array. May +also be zero. + + + __u32 + error_idx + Set by the driver in case of an error. If the error is +associated with a particular control, then error_idx +is set to the index of that control. If the error is not related to a specific +control, or the validation step failed (see below), then +error_idx is set to count. +The value is undefined if the ioctl returned 0 (success). + +Before controls are read from/written to hardware a validation step +takes place: this checks if all controls in the list are valid controls, +if no attempt is made to write to a read-only control or read from a write-only +control, and any other up-front checks that can be done without accessing the +hardware. The exact validations done during this step are driver dependent +since some checks might require hardware access for some devices, thus making +it impossible to do those checks up-front. However, drivers should make a +best-effort to do as many up-front checks as possible. + +This check is done to avoid leaving the hardware in an inconsistent state due +to easy-to-avoid problems. But it leads to another problem: the application needs to +know whether an error came from the validation step (meaning that the hardware +was not touched) or from an error during the actual reading from/writing to hardware. + +The, in hindsight quite poor, solution for that is to set error_idx +to count if the validation failed. This has the +unfortunate side-effect that it is not possible to see which control failed the +validation. If the validation was successful and the error happened while +accessing the hardware, then error_idx is less than +count and only the controls up to +error_idx-1 were read or written correctly, and the +state of the remaining controls is undefined. + +Since VIDIOC_TRY_EXT_CTRLS does not access hardware +there is also no need to handle the validation step in this special way, +so error_idx will just be set to the control that +failed the validation step instead of to count. +This means that if VIDIOC_S_EXT_CTRLS fails with +error_idx set to count, +then you can call VIDIOC_TRY_EXT_CTRLS to try to discover +the actual control that failed the validation step. Unfortunately, there +is no TRY equivalent for VIDIOC_G_EXT_CTRLS. + + + + __u32 + reserved[2] + Reserved for future extensions. Drivers and +applications must set the array to zero. + + + &v4l2-ext-control; * + controls + Pointer to an array of +count v4l2_ext_control structures. Ignored +if count equals zero. + + + +
+ + + Control classes + + &cs-def; + + + V4L2_CTRL_CLASS_USER + 0x980000 + The class containing user controls. These controls +are described in . All controls that can be set +using the &VIDIOC-S-CTRL; and &VIDIOC-G-CTRL; ioctl belong to this +class. + + + V4L2_CTRL_CLASS_MPEG + 0x990000 + The class containing MPEG compression controls. +These controls are described in . + + + V4L2_CTRL_CLASS_CAMERA + 0x9a0000 + The class containing camera controls. +These controls are described in . + + + V4L2_CTRL_CLASS_FM_TX + 0x9b0000 + The class containing FM Transmitter (FM TX) controls. +These controls are described in . + + + V4L2_CTRL_CLASS_FLASH + 0x9c0000 + The class containing flash device controls. +These controls are described in . + + + V4L2_CTRL_CLASS_JPEG + 0x9d0000 + The class containing JPEG compression controls. +These controls are described in . + + + V4L2_CTRL_CLASS_IMAGE_SOURCE + 0x9e0000 The class containing image + source controls. These controls are described in . + + + V4L2_CTRL_CLASS_IMAGE_PROC + 0x9f0000 The class containing image + processing controls. These controls are described in . + + + +
+ + + + + &return-value; + + + + EINVAL + + The &v4l2-ext-control; id +is invalid, the &v4l2-ext-controls; +ctrl_class is invalid, or the &v4l2-ext-control; +value was inappropriate (e.g. the given menu +index is not supported by the driver). This error code is +also returned by the VIDIOC_S_EXT_CTRLS and +VIDIOC_TRY_EXT_CTRLS ioctls if two or more +control values are in conflict. + + + + ERANGE + + The &v4l2-ext-control; value +is out of bounds. + + + + EBUSY + + The control is temporarily not changeable, possibly +because another applications took over control of the device function +this control belongs to. + + + + ENOSPC + + The space reserved for the control's payload is insufficient. +The field size is set to a value that is enough +to store the payload and this error code is returned. + + + + EACCES + + Attempt to try or set a read-only control or to get a + write-only control. + + + + + + diff --git a/Documentation/DocBook/media/v4l/vidioc-g-fbuf.xml b/Documentation/DocBook/media/v4l/vidioc-g-fbuf.xml new file mode 100644 index 00000000..7c63815e --- /dev/null +++ b/Documentation/DocBook/media/v4l/vidioc-g-fbuf.xml @@ -0,0 +1,463 @@ + + + ioctl VIDIOC_G_FBUF, VIDIOC_S_FBUF + &manvol; + + + + VIDIOC_G_FBUF + VIDIOC_S_FBUF + Get or set frame buffer overlay parameters + + + + + + int ioctl + int fd + int request + struct v4l2_framebuffer *argp + + + + + int ioctl + int fd + int request + const struct v4l2_framebuffer *argp + + + + + + Arguments + + + + fd + + &fd; + + + + request + + VIDIOC_G_FBUF, VIDIOC_S_FBUF + + + + argp + + + + + + + + + Description + + Applications can use the VIDIOC_G_FBUF and +VIDIOC_S_FBUF ioctl to get and set the +framebuffer parameters for a Video +Overlay or Video Output Overlay +(OSD). The type of overlay is implied by the device type (capture or +output device) and can be determined with the &VIDIOC-QUERYCAP; ioctl. +One /dev/videoN device must not support both +kinds of overlay. + + The V4L2 API distinguishes destructive and non-destructive +overlays. A destructive overlay copies captured video images into the +video memory of a graphics card. A non-destructive overlay blends +video images into a VGA signal or graphics into a video signal. +Video Output Overlays are always +non-destructive. + + To get the current parameters applications call the +VIDIOC_G_FBUF ioctl with a pointer to a +v4l2_framebuffer structure. The driver fills +all fields of the structure or returns an &EINVAL; when overlays are +not supported. + + To set the parameters for a Video Output +Overlay, applications must initialize the +flags field of a struct +v4l2_framebuffer. Since the framebuffer is +implemented on the TV card all other parameters are determined by the +driver. When an application calls VIDIOC_S_FBUF +with a pointer to this structure, the driver prepares for the overlay +and returns the framebuffer parameters as +VIDIOC_G_FBUF does, or it returns an error +code. + + To set the parameters for a non-destructive +Video Overlay, applications must initialize the +flags field, the +fmt substructure, and call +VIDIOC_S_FBUF. Again the driver prepares for the +overlay and returns the framebuffer parameters as +VIDIOC_G_FBUF does, or it returns an error +code. + + For a destructive Video Overlay +applications must additionally provide a +base address. Setting up a DMA to a +random memory location can jeopardize the system security, its +stability or even damage the hardware, therefore only the superuser +can set the parameters for a destructive video overlay. + + + + + struct <structname>v4l2_framebuffer</structname> + + &cs-ustr; + + + __u32 + capability + + Overlay capability flags set by the driver, see +. + + + __u32 + flags + + Overlay control flags set by application and +driver, see + + + void * + base + + Physical base address of the framebuffer, +that is the address of the pixel in the top left corner of the +framebuffer.A physical base address may not suit all +platforms. GK notes in theory we should pass something like PCI device ++ memory region + offset instead. If you encounter problems please +discuss on the linux-media mailing list: &v4l-ml;. + + + + + + This field is irrelevant to +non-destructive Video Overlays. For +destructive Video Overlays applications must +provide a base address. The driver may accept only base addresses +which are a multiple of two, four or eight bytes. For +Video Output Overlays the driver must return +a valid base address, so applications can find the corresponding Linux +framebuffer device (see ). + + + &v4l2-pix-format; + fmt + + Layout of the frame buffer. The +v4l2_pix_format structure is defined in , for clarification the fields and acceptable values + are listed below: + + + + __u32 + width + Width of the frame buffer in pixels. + + + + __u32 + height + Height of the frame buffer in pixels. + + + + __u32 + pixelformat + The pixel format of the +framebuffer. + + + + + + For non-destructive Video +Overlays this field only defines a format for the +&v4l2-window; chromakey field. + + + + + + For destructive Video +Overlays applications must initialize this field. For +Video Output Overlays the driver must return +a valid format. + + + + + + Usually this is an RGB format (for example +V4L2_PIX_FMT_RGB565) +but YUV formats (only packed YUV formats when chroma keying is used, +not including V4L2_PIX_FMT_YUYV and +V4L2_PIX_FMT_UYVY) and the +V4L2_PIX_FMT_PAL8 format are also permitted. The +behavior of the driver when an application requests a compressed +format is undefined. See for information on +pixel formats. + + + + &v4l2-field; + field + Drivers and applications shall ignore this field. +If applicable, the field order is selected with the &VIDIOC-S-FMT; +ioctl, using the field field of +&v4l2-window;. + + + + __u32 + bytesperline + Distance in bytes between the leftmost pixels in +two adjacent lines. + + + This field is irrelevant to +non-destructive Video +Overlays.For destructive Video +Overlays both applications and drivers can set this field +to request padding bytes at the end of each line. Drivers however may +ignore the requested value, returning width +times bytes-per-pixel or a larger value required by the hardware. That +implies applications can just set this field to zero to get a +reasonable default.For Video Output +Overlays the driver must return a valid +value.Video hardware may access padding bytes, therefore +they must reside in accessible memory. Consider for example the case +where padding bytes after the last line of an image cross a system +page boundary. Capture devices may write padding bytes, the value is +undefined. Output devices ignore the contents of padding +bytes.When the image format is planar the +bytesperline value applies to the largest +plane and is divided by the same factor as the +width field for any smaller planes. For +example the Cb and Cr planes of a YUV 4:2:0 image have half as many +padding bytes following each line as the Y plane. To avoid ambiguities +drivers must return a bytesperline value +rounded up to a multiple of the scale factor. + + + + __u32 + sizeimage + This field is irrelevant to +non-destructive Video Overlays. For +destructive Video Overlays applications must +initialize this field. For Video Output +Overlays the driver must return a valid +format.Together with base it +defines the framebuffer memory accessible by the +driver. + + + + &v4l2-colorspace; + colorspace + This information supplements the +pixelformat and must be set by the driver, +see . + + + + __u32 + priv + Reserved for additional information about custom +(driver defined) formats. When not used drivers and applications must +set this field to zero. + + + +
+ + + Frame Buffer Capability Flags + + &cs-def; + + + V4L2_FBUF_CAP_EXTERNOVERLAY + 0x0001 + The device is capable of non-destructive overlays. +When the driver clears this flag, only destructive overlays are +supported. There are no drivers yet which support both destructive and +non-destructive overlays. Video Output Overlays are in practice always +non-destructive. + + + V4L2_FBUF_CAP_CHROMAKEY + 0x0002 + The device supports clipping by chroma-keying the +images. That is, image pixels replace pixels in the VGA or video +signal only where the latter assume a certain color. Chroma-keying +makes no sense for destructive overlays. + + + V4L2_FBUF_CAP_LIST_CLIPPING + 0x0004 + The device supports clipping using a list of clip +rectangles. + + + V4L2_FBUF_CAP_BITMAP_CLIPPING + 0x0008 + The device supports clipping using a bit mask. + + + V4L2_FBUF_CAP_LOCAL_ALPHA + 0x0010 + The device supports clipping/blending using the +alpha channel of the framebuffer or VGA signal. Alpha blending makes +no sense for destructive overlays. + + + V4L2_FBUF_CAP_GLOBAL_ALPHA + 0x0020 + The device supports alpha blending using a global +alpha value. Alpha blending makes no sense for destructive overlays. + + + V4L2_FBUF_CAP_LOCAL_INV_ALPHA + 0x0040 + The device supports clipping/blending using the +inverted alpha channel of the framebuffer or VGA signal. Alpha +blending makes no sense for destructive overlays. + + + V4L2_FBUF_CAP_SRC_CHROMAKEY + 0x0080 + The device supports Source Chroma-keying. Video pixels +with the chroma-key colors are replaced by framebuffer pixels, which is exactly opposite of +V4L2_FBUF_CAP_CHROMAKEY + + + +
+ + + Frame Buffer Flags + + &cs-def; + + + V4L2_FBUF_FLAG_PRIMARY + 0x0001 + The framebuffer is the primary graphics surface. +In other words, the overlay is destructive. This flag is typically set by any +driver that doesn't have the V4L2_FBUF_CAP_EXTERNOVERLAY +capability and it is cleared otherwise. + + + V4L2_FBUF_FLAG_OVERLAY + 0x0002 + If this flag is set for a video capture device, then the +driver will set the initial overlay size to cover the full framebuffer size, +otherwise the existing overlay size (as set by &VIDIOC-S-FMT;) will be used. + +Only one video capture driver (bttv) supports this flag. The use of this flag +for capture devices is deprecated. There is no way to detect which drivers +support this flag, so the only reliable method of setting the overlay size is +through &VIDIOC-S-FMT;. + +If this flag is set for a video output device, then the video output overlay +window is relative to the top-left corner of the framebuffer and restricted +to the size of the framebuffer. If it is cleared, then the video output +overlay window is relative to the video output display. + + + + V4L2_FBUF_FLAG_CHROMAKEY + 0x0004 + Use chroma-keying. The chroma-key color is +determined by the chromakey field of +&v4l2-window; and negotiated with the &VIDIOC-S-FMT; ioctl, see +and + . + + + There are no flags to enable +clipping using a list of clip rectangles or a bitmap. These methods +are negotiated with the &VIDIOC-S-FMT; ioctl, see and . + + + V4L2_FBUF_FLAG_LOCAL_ALPHA + 0x0008 + Use the alpha channel of the framebuffer to clip or +blend framebuffer pixels with video images. The blend +function is: output = framebuffer pixel * alpha + video pixel * (1 - +alpha). The actual alpha depth depends on the framebuffer pixel +format. + + + V4L2_FBUF_FLAG_GLOBAL_ALPHA + 0x0010 + Use a global alpha value to blend the framebuffer +with video images. The blend function is: output = (framebuffer pixel +* alpha + video pixel * (255 - alpha)) / 255. The alpha value is +determined by the global_alpha field of +&v4l2-window; and negotiated with the &VIDIOC-S-FMT; ioctl, see +and . + + + V4L2_FBUF_FLAG_LOCAL_INV_ALPHA + 0x0020 + Like +V4L2_FBUF_FLAG_LOCAL_ALPHA, use the alpha channel +of the framebuffer to clip or blend framebuffer pixels with video +images, but with an inverted alpha value. The blend function is: +output = framebuffer pixel * (1 - alpha) + video pixel * alpha. The +actual alpha depth depends on the framebuffer pixel format. + + + V4L2_FBUF_FLAG_SRC_CHROMAKEY + 0x0040 + Use source chroma-keying. The source chroma-key color is +determined by the chromakey field of +&v4l2-window; and negotiated with the &VIDIOC-S-FMT; ioctl, see and . +Both chroma-keying are mutual exclusive to each other, so same +chromakey field of &v4l2-window; is being used. + + + +
+ + + + &return-value; + + + + EPERM + + VIDIOC_S_FBUF can only be called +by a privileged user to negotiate the parameters for a destructive +overlay. + + + + EINVAL + + The VIDIOC_S_FBUF parameters are unsuitable. + + + + + diff --git a/Documentation/DocBook/media/v4l/vidioc-g-fmt.xml b/Documentation/DocBook/media/v4l/vidioc-g-fmt.xml new file mode 100644 index 00000000..ee8f56e1 --- /dev/null +++ b/Documentation/DocBook/media/v4l/vidioc-g-fmt.xml @@ -0,0 +1,197 @@ + + + ioctl VIDIOC_G_FMT, VIDIOC_S_FMT, +VIDIOC_TRY_FMT + &manvol; + + + + VIDIOC_G_FMT + VIDIOC_S_FMT + VIDIOC_TRY_FMT + Get or set the data format, try a format + + + + + + int ioctl + int fd + int request + struct v4l2_format +*argp + + + + + + Arguments + + + + fd + + &fd; + + + + request + + VIDIOC_G_FMT, VIDIOC_S_FMT, VIDIOC_TRY_FMT + + + + argp + + + + + + + + + Description + + These ioctls are used to negotiate the format of data +(typically image format) exchanged between driver and +application. + + To query the current parameters applications set the +type field of a struct +v4l2_format to the respective buffer (stream) +type. For example video capture devices use +V4L2_BUF_TYPE_VIDEO_CAPTURE or +V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE. When the application +calls the VIDIOC_G_FMT ioctl with a pointer to +this structure the driver fills the respective member of the +fmt union. In case of video capture devices +that is either the &v4l2-pix-format; pix or +the &v4l2-pix-format-mplane; pix_mp member. +When the requested buffer type is not supported drivers return an +&EINVAL;. + + To change the current format parameters applications +initialize the type field and all +fields of the respective fmt +union member. For details see the documentation of the various devices +types in . Good practice is to query the +current parameters first, and to +modify only those parameters not suitable for the application. When +the application calls the VIDIOC_S_FMT ioctl +with a pointer to a v4l2_format structure +the driver checks +and adjusts the parameters against hardware abilities. Drivers +should not return an error code unless the type field is invalid, this is +a mechanism to fathom device capabilities and to approach parameters +acceptable for both the application and driver. On success the driver +may program the hardware, allocate resources and generally prepare for +data exchange. +Finally the VIDIOC_S_FMT ioctl returns the +current format parameters as VIDIOC_G_FMT does. +Very simple, inflexible devices may even ignore all input and always +return the default parameters. However all V4L2 devices exchanging +data with the application must implement the +VIDIOC_G_FMT and +VIDIOC_S_FMT ioctl. When the requested buffer +type is not supported drivers return an &EINVAL; on a +VIDIOC_S_FMT attempt. When I/O is already in +progress or the resource is not available for other reasons drivers +return the &EBUSY;. + + The VIDIOC_TRY_FMT ioctl is equivalent +to VIDIOC_S_FMT with one exception: it does not +change driver state. It can also be called at any time, never +returning EBUSY. This function is provided to +negotiate parameters, to learn about hardware limitations, without +disabling I/O or possibly time consuming hardware preparations. +Although strongly recommended drivers are not required to implement +this ioctl. + + The format as returned by VIDIOC_TRY_FMT +must be identical to what VIDIOC_S_FMT returns for +the same input or output. + + + struct <structname>v4l2_format</structname> + + + + + + + + __u32 + type + + Type of the data stream, see . + + + union + fmt + + + + &v4l2-pix-format; + pix + Definition of an image format, see , used by video capture and output +devices. + + + + &v4l2-pix-format-mplane; + pix_mp + Definition of an image format, see , used by video capture and output +devices that support the multi-planar +version of the API. + + + + &v4l2-window; + win + Definition of an overlaid image, see , used by video overlay devices. + + + + &v4l2-vbi-format; + vbi + Raw VBI capture or output parameters. This is +discussed in more detail in . Used by raw VBI +capture and output devices. + + + + &v4l2-sliced-vbi-format; + sliced + Sliced VBI capture or output parameters. See + for details. Used by sliced VBI +capture and output devices. + + + + __u8 + raw_data[200] + Place holder for future extensions. + + + +
+ + + + &return-value; + + + + EINVAL + + The &v4l2-format; type +field is invalid or the requested buffer type not supported. + + + + + diff --git a/Documentation/DocBook/media/v4l/vidioc-g-frequency.xml b/Documentation/DocBook/media/v4l/vidioc-g-frequency.xml new file mode 100644 index 00000000..c7a1c462 --- /dev/null +++ b/Documentation/DocBook/media/v4l/vidioc-g-frequency.xml @@ -0,0 +1,147 @@ + + + ioctl VIDIOC_G_FREQUENCY, VIDIOC_S_FREQUENCY + &manvol; + + + + VIDIOC_G_FREQUENCY + VIDIOC_S_FREQUENCY + Get or set tuner or modulator radio +frequency + + + + + + int ioctl + int fd + int request + struct v4l2_frequency +*argp + + + + + int ioctl + int fd + int request + const struct v4l2_frequency +*argp + + + + + + Arguments + + + + fd + + &fd; + + + + request + + VIDIOC_G_FREQUENCY, VIDIOC_S_FREQUENCY + + + + argp + + + + + + + + + Description + + To get the current tuner or modulator radio frequency +applications set the tuner field of a +&v4l2-frequency; to the respective tuner or modulator number (only +input devices have tuners, only output devices have modulators), zero +out the reserved array and +call the VIDIOC_G_FREQUENCY ioctl with a pointer +to this structure. The driver stores the current frequency in the +frequency field. + + To change the current tuner or modulator radio frequency +applications initialize the tuner, +type and +frequency fields, and the +reserved array of a &v4l2-frequency; and +call the VIDIOC_S_FREQUENCY ioctl with a pointer +to this structure. When the requested frequency is not possible the +driver assumes the closest possible value. However +VIDIOC_S_FREQUENCY is a write-only ioctl, it does +not return the actual new frequency. + + + struct <structname>v4l2_frequency</structname> + + &cs-str; + + + __u32 + tuner + The tuner or modulator index number. This is the +same value as in the &v4l2-input; tuner +field and the &v4l2-tuner; index field, or +the &v4l2-output; modulator field and the +&v4l2-modulator; index field. + + + __u32 + type + The tuner type. This is the same value as in the +&v4l2-tuner; type field. The type must be set +to V4L2_TUNER_RADIO for /dev/radioX +device nodes, and to V4L2_TUNER_ANALOG_TV +for all others. Set this field to V4L2_TUNER_RADIO for +modulators (currently only radio modulators are supported). +See + + + __u32 + frequency + Tuning frequency in units of 62.5 kHz, or if the +&v4l2-tuner; or &v4l2-modulator; capabilities flag +V4L2_TUNER_CAP_LOW is set, in units of 62.5 +Hz. + + + __u32 + reserved[8] + Reserved for future extensions. Drivers and + applications must set the array to zero. + + + +
+ + + + &return-value; + + + + EINVAL + + The tuner index is out of +bounds or the value in the type field is +wrong. + + + + EBUSY + + A hardware seek is in progress. + + + + + diff --git a/Documentation/DocBook/media/v4l/vidioc-g-input.xml b/Documentation/DocBook/media/v4l/vidioc-g-input.xml new file mode 100644 index 00000000..1d430650 --- /dev/null +++ b/Documentation/DocBook/media/v4l/vidioc-g-input.xml @@ -0,0 +1,83 @@ + + + ioctl VIDIOC_G_INPUT, VIDIOC_S_INPUT + &manvol; + + + + VIDIOC_G_INPUT + VIDIOC_S_INPUT + Query or select the current video input + + + + + + int ioctl + int fd + int request + int *argp + + + + + + Arguments + + + + fd + + &fd; + + + + request + + VIDIOC_G_INPUT, VIDIOC_S_INPUT + + + + argp + + + + + + + + + Description + + To query the current video input applications call the +VIDIOC_G_INPUT ioctl with a pointer to an integer +where the driver stores the number of the input, as in the +&v4l2-input; index field. This ioctl will +fail only when there are no video inputs, returning +EINVAL. + + To select a video input applications store the number of the +desired input in an integer and call the +VIDIOC_S_INPUT ioctl with a pointer to this +integer. Side effects are possible. For example inputs may support +different video standards, so the driver may implicitly switch the +current standard. Because of these possible side effects applications +must select an input before querying or negotiating any other parameters. + + Information about video inputs is available using the +&VIDIOC-ENUMINPUT; ioctl. + + + + &return-value; + + + + EINVAL + + The number of the video input is out of bounds. + + + + + diff --git a/Documentation/DocBook/media/v4l/vidioc-g-jpegcomp.xml b/Documentation/DocBook/media/v4l/vidioc-g-jpegcomp.xml new file mode 100644 index 00000000..48748499 --- /dev/null +++ b/Documentation/DocBook/media/v4l/vidioc-g-jpegcomp.xml @@ -0,0 +1,175 @@ + + + ioctl VIDIOC_G_JPEGCOMP, VIDIOC_S_JPEGCOMP + &manvol; + + + + VIDIOC_G_JPEGCOMP + VIDIOC_S_JPEGCOMP + + + + + + + int ioctl + int fd + int request + v4l2_jpegcompression *argp + + + + + int ioctl + int fd + int request + const v4l2_jpegcompression *argp + + + + + + Arguments + + + + fd + + &fd; + + + + request + + VIDIOC_G_JPEGCOMP, VIDIOC_S_JPEGCOMP + + + + argp + + + + + + + + + Description + + These ioctls are deprecated. + New drivers and applications should use + JPEG class controls for image quality and JPEG markers control. + + + [to do] + + Ronald Bultje elaborates: + + + + APP is some application-specific information. The +application can set it itself, and it'll be stored in the JPEG-encoded +fields (eg; interlacing information for in an AVI or so). COM is the +same, but it's comments, like 'encoded by me' or so. + + jpeg_markers describes whether the huffman tables, +quantization tables and the restart interval information (all +JPEG-specific stuff) should be stored in the JPEG-encoded fields. +These define how the JPEG field is encoded. If you omit them, +applications assume you've used standard encoding. You usually do want +to add them. + + + + + struct <structname>v4l2_jpegcompression</structname> + + &cs-str; + + + int + quality + Deprecated. If + V4L2_CID_JPEG_IMAGE_QUALITY control is exposed by + a driver applications should use it instead and ignore this field. + + + + int + APPn + + + + int + APP_len + + + + char + APP_data[60] + + + + int + COM_len + + + + char + COM_data[60] + + + + __u32 + jpeg_markers + See . Deprecated. + If + V4L2_CID_JPEG_ACTIVE_MARKER control + is exposed by a driver applications should use it instead + and ignore this field. + + + +
+ + + JPEG Markers Flags + + &cs-def; + + + V4L2_JPEG_MARKER_DHT + (1<<3) + Define Huffman Tables + + + V4L2_JPEG_MARKER_DQT + (1<<4) + Define Quantization Tables + + + V4L2_JPEG_MARKER_DRI + (1<<5) + Define Restart Interval + + + V4L2_JPEG_MARKER_COM + (1<<6) + Comment segment + + + V4L2_JPEG_MARKER_APP + (1<<7) + App segment, driver will always use APP0 + + + +
+ + + + &return-value; + + diff --git a/Documentation/DocBook/media/v4l/vidioc-g-modulator.xml b/Documentation/DocBook/media/v4l/vidioc-g-modulator.xml new file mode 100644 index 00000000..7f4ac7e4 --- /dev/null +++ b/Documentation/DocBook/media/v4l/vidioc-g-modulator.xml @@ -0,0 +1,238 @@ + + + ioctl VIDIOC_G_MODULATOR, VIDIOC_S_MODULATOR + &manvol; + + + + VIDIOC_G_MODULATOR + VIDIOC_S_MODULATOR + Get or set modulator attributes + + + + + + int ioctl + int fd + int request + struct v4l2_modulator +*argp + + + + + int ioctl + int fd + int request + const struct v4l2_modulator +*argp + + + + + + Arguments + + + + fd + + &fd; + + + + request + + VIDIOC_G_MODULATOR, VIDIOC_S_MODULATOR + + + + argp + + + + + + + + + Description + + To query the attributes of a modulator applications initialize +the index field and zero out the +reserved array of a &v4l2-modulator; and +call the VIDIOC_G_MODULATOR ioctl with a pointer +to this structure. Drivers fill the rest of the structure or return an +&EINVAL; when the index is out of bounds. To enumerate all modulators +applications shall begin at index zero, incrementing by one until the +driver returns EINVAL. + + Modulators have two writable properties, an audio +modulation set and the radio frequency. To change the modulated audio +subprograms, applications initialize the index + and txsubchans fields and the +reserved array and call the +VIDIOC_S_MODULATOR ioctl. Drivers may choose a +different audio modulation if the request cannot be satisfied. However +this is a write-only ioctl, it does not return the actual audio +modulation selected. + + To change the radio frequency the &VIDIOC-S-FREQUENCY; ioctl +is available. + + + struct <structname>v4l2_modulator</structname> + + &cs-str; + + + __u32 + index + Identifies the modulator, set by the +application. + + + __u8 + name[32] + Name of the modulator, a NUL-terminated ASCII +string. This information is intended for the user. + + + __u32 + capability + Modulator capability flags. No flags are defined +for this field, the tuner flags in &v4l2-tuner; +are used accordingly. The audio flags indicate the ability +to encode audio subprograms. They will not +change for example with the current video standard. + + + __u32 + rangelow + The lowest tunable frequency in units of 62.5 +KHz, or if the capability flag +V4L2_TUNER_CAP_LOW is set, in units of 62.5 +Hz. + + + __u32 + rangehigh + The highest tunable frequency in units of 62.5 +KHz, or if the capability flag +V4L2_TUNER_CAP_LOW is set, in units of 62.5 +Hz. + + + __u32 + txsubchans + With this field applications can determine how +audio sub-carriers shall be modulated. It contains a set of flags as +defined in . Note the tuner +rxsubchans flags are reused, but the +semantics are different. Video output devices are assumed to have an +analog or PCM audio input with 1-3 channels. The +txsubchans flags select one or more +channels for modulation, together with some audio subprogram +indicator, for example a stereo pilot tone. + + + __u32 + reserved[4] + Reserved for future extensions. Drivers and +applications must set the array to zero. + + + +
+ + + Modulator Audio Transmission Flags + + &cs-def; + + + V4L2_TUNER_SUB_MONO + 0x0001 + Modulate channel 1 as mono audio, when the input +has more channels, a down-mix of channel 1 and 2. This flag does not +combine with V4L2_TUNER_SUB_STEREO or +V4L2_TUNER_SUB_LANG1. + + + V4L2_TUNER_SUB_STEREO + 0x0002 + Modulate channel 1 and 2 as left and right +channel of a stereo audio signal. When the input has only one channel +or two channels and V4L2_TUNER_SUB_SAP is also +set, channel 1 is encoded as left and right channel. This flag does +not combine with V4L2_TUNER_SUB_MONO or +V4L2_TUNER_SUB_LANG1. When the driver does not +support stereo audio it shall fall back to mono. + + + V4L2_TUNER_SUB_LANG1 + 0x0008 + Modulate channel 1 and 2 as primary and secondary +language of a bilingual audio signal. When the input has only one +channel it is used for both languages. It is not possible to encode +the primary or secondary language only. This flag does not combine +with V4L2_TUNER_SUB_MONO, +V4L2_TUNER_SUB_STEREO or +V4L2_TUNER_SUB_SAP. If the hardware does not +support the respective audio matrix, or the current video standard +does not permit bilingual audio the +VIDIOC_S_MODULATOR ioctl shall return an &EINVAL; +and the driver shall fall back to mono or stereo mode. + + + V4L2_TUNER_SUB_LANG2 + 0x0004 + Same effect as +V4L2_TUNER_SUB_SAP. + + + V4L2_TUNER_SUB_SAP + 0x0004 + When combined with V4L2_TUNER_SUB_MONO + the first channel is encoded as mono audio, the last +channel as Second Audio Program. When the input has only one channel +it is used for both audio tracks. When the input has three channels +the mono track is a down-mix of channel 1 and 2. When combined with +V4L2_TUNER_SUB_STEREO channel 1 and 2 are +encoded as left and right stereo audio, channel 3 as Second Audio +Program. When the input has only two channels, the first is encoded as +left and right channel and the second as SAP. When the input has only +one channel it is used for all audio tracks. It is not possible to +encode a Second Audio Program only. This flag must combine with +V4L2_TUNER_SUB_MONO or +V4L2_TUNER_SUB_STEREO. If the hardware does not +support the respective audio matrix, or the current video standard +does not permit SAP the VIDIOC_S_MODULATOR ioctl +shall return an &EINVAL; and driver shall fall back to mono or stereo +mode. + + + V4L2_TUNER_SUB_RDS + 0x0010 + Enable the RDS encoder for a radio FM transmitter. + + + +
+ + + + &return-value; + + + + EINVAL + + The &v4l2-modulator; +index is out of bounds. + + + + + diff --git a/Documentation/DocBook/media/v4l/vidioc-g-output.xml b/Documentation/DocBook/media/v4l/vidioc-g-output.xml new file mode 100644 index 00000000..4533068e --- /dev/null +++ b/Documentation/DocBook/media/v4l/vidioc-g-output.xml @@ -0,0 +1,85 @@ + + + ioctl VIDIOC_G_OUTPUT, VIDIOC_S_OUTPUT + &manvol; + + + + VIDIOC_G_OUTPUT + VIDIOC_S_OUTPUT + Query or select the current video output + + + + + + int ioctl + int fd + int request + int *argp + + + + + + Arguments + + + + fd + + &fd; + + + + request + + VIDIOC_G_OUTPUT, VIDIOC_S_OUTPUT + + + + argp + + + + + + + + + Description + + To query the current video output applications call the +VIDIOC_G_OUTPUT ioctl with a pointer to an integer +where the driver stores the number of the output, as in the +&v4l2-output; index field. This ioctl +will fail only when there are no video outputs, returning the +&EINVAL;. + + To select a video output applications store the number of the +desired output in an integer and call the +VIDIOC_S_OUTPUT ioctl with a pointer to this integer. +Side effects are possible. For example outputs may support different +video standards, so the driver may implicitly switch the current +standard. +standard. Because of these possible side effects applications +must select an output before querying or negotiating any other parameters. + + Information about video outputs is available using the +&VIDIOC-ENUMOUTPUT; ioctl. + + + + &return-value; + + + + EINVAL + + The number of the video output is out of bounds, or +there are no video outputs at all. + + + + + diff --git a/Documentation/DocBook/media/v4l/vidioc-g-parm.xml b/Documentation/DocBook/media/v4l/vidioc-g-parm.xml new file mode 100644 index 00000000..9058224d --- /dev/null +++ b/Documentation/DocBook/media/v4l/vidioc-g-parm.xml @@ -0,0 +1,314 @@ + + + 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 +unnecessary 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; + + + __u32 + type + + The buffer (stream) type, same as &v4l2-format; +type, set by the application. See + + + 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. + + + +
+ + + 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; + + diff --git a/Documentation/DocBook/media/v4l/vidioc-g-priority.xml b/Documentation/DocBook/media/v4l/vidioc-g-priority.xml new file mode 100644 index 00000000..6a81b4fe --- /dev/null +++ b/Documentation/DocBook/media/v4l/vidioc-g-priority.xml @@ -0,0 +1,135 @@ + + + ioctl VIDIOC_G_PRIORITY, VIDIOC_S_PRIORITY + &manvol; + + + + VIDIOC_G_PRIORITY + VIDIOC_S_PRIORITY + Query or request the access priority associated with a +file descriptor + + + + + + int ioctl + int fd + int request + enum v4l2_priority *argp + + + + + int ioctl + int fd + int request + const enum v4l2_priority *argp + + + + + + Arguments + + + + fd + + &fd; + + + + request + + VIDIOC_G_PRIORITY, VIDIOC_S_PRIORITY + + + + argp + + Pointer to an enum v4l2_priority type. + + + + + + + Description + + To query the current access priority +applications call the VIDIOC_G_PRIORITY ioctl +with a pointer to an enum v4l2_priority variable where the driver stores +the current priority. + + To request an access priority applications store the +desired priority in an enum v4l2_priority variable and call +VIDIOC_S_PRIORITY ioctl with a pointer to this +variable. + + + enum v4l2_priority + + &cs-def; + + + V4L2_PRIORITY_UNSET + 0 + + + + V4L2_PRIORITY_BACKGROUND + 1 + Lowest priority, usually applications running in +background, for example monitoring VBI transmissions. A proxy +application running in user space will be necessary if multiple +applications want to read from a device at this priority. + + + V4L2_PRIORITY_INTERACTIVE + 2 + + + + V4L2_PRIORITY_DEFAULT + 2 + Medium priority, usually applications started and +interactively controlled by the user. For example TV viewers, Teletext +browsers, or just "panel" applications to change the channel or video +controls. This is the default priority unless an application requests +another. + + + V4L2_PRIORITY_RECORD + 3 + Highest priority. Only one file descriptor can have +this priority, it blocks any other fd from changing device properties. +Usually applications which must not be interrupted, like video +recording. + + + +
+ + + + &return-value; + + + + EINVAL + + The requested priority value is invalid. + + + + EBUSY + + Another application already requested higher +priority. + + + + + diff --git a/Documentation/DocBook/media/v4l/vidioc-g-selection.xml b/Documentation/DocBook/media/v4l/vidioc-g-selection.xml new file mode 100644 index 00000000..b11ec75e --- /dev/null +++ b/Documentation/DocBook/media/v4l/vidioc-g-selection.xml @@ -0,0 +1,241 @@ + + + + ioctl VIDIOC_G_SELECTION, VIDIOC_S_SELECTION + &manvol; + + + + VIDIOC_G_SELECTION + VIDIOC_S_SELECTION + Get or set one of the selection rectangles + + + + + + int ioctl + int fd + int request + struct v4l2_selection *argp + + + + + + Arguments + + + + fd + + &fd; + + + + request + + VIDIOC_G_SELECTION, VIDIOC_S_SELECTION + + + + argp + + + + + + + + + Description + + + Experimental + This is an experimental + interface and may change in the future. + + + The ioctls are used to query and configure selection rectangles. + + To query the cropping (composing) rectangle set &v4l2-selection; + type field to the respective buffer type. +Do not use multiplanar buffers. Use V4L2_BUF_TYPE_VIDEO_CAPTURE + instead of V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE +. Use V4L2_BUF_TYPE_VIDEO_OUTPUT instead of + V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE . The next step is +setting the value of &v4l2-selection; target field +to V4L2_SEL_TGT_CROP ( +V4L2_SEL_TGT_COMPOSE ). Please refer to table or for additional +targets. The flags and reserved + fields of &v4l2-selection; are ignored and they must be filled +with zeros. The driver fills the rest of the structure or +returns &EINVAL; if incorrect buffer type or target was used. If cropping +(composing) is not supported then the active rectangle is not mutable and it is +always equal to the bounds rectangle. Finally, the &v4l2-rect; +r rectangle is filled with the current cropping +(composing) coordinates. The coordinates are expressed in driver-dependent +units. The only exception are rectangles for images in raw formats, whose +coordinates are always expressed in pixels. + + To change the cropping (composing) rectangle set the &v4l2-selection; +type field to the respective buffer type. Do not +use multiplanar buffers. Use V4L2_BUF_TYPE_VIDEO_CAPTURE + instead of V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE +. Use V4L2_BUF_TYPE_VIDEO_OUTPUT instead of + V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE . The next step is +setting the value of &v4l2-selection; target to +V4L2_SEL_TGT_CROP ( +V4L2_SEL_TGT_COMPOSE ). Please refer to table or for additional +targets. The &v4l2-rect; r rectangle need to be +set to the desired active area. Field &v4l2-selection; reserved + is ignored and must be filled with zeros. The driver may adjust +coordinates of the requested rectangle. An application may +introduce constraints to control rounding behaviour. The &v4l2-selection; +flags field must be set to one of the following: + + + +0 - The driver can adjust the rectangle size freely +and shall choose a crop/compose rectangle as close as possible to the requested +one. + + +V4L2_SEL_FLAG_GE - The driver is not allowed to +shrink the rectangle. The original rectangle must lay inside the adjusted +one. + + +V4L2_SEL_FLAG_LE - The driver is not allowed to +enlarge the rectangle. The adjusted rectangle must lay inside the original +one. + + +V4L2_SEL_FLAG_GE | V4L2_SEL_FLAG_LE - The driver +must choose the size exactly the same as in the requested rectangle. + + + +Please refer to . + + + + The driver may have to adjusts the requested dimensions against hardware +limits and other parts as the pipeline, i.e. the bounds given by the +capture/output window or TV display. The closest possible values of horizontal +and vertical offset and sizes are chosen according to following priority: + + + + Satisfy constraints from &v4l2-selection; flags. + + + Adjust width, height, left, and top to hardware limits and alignments. + + + Keep center of adjusted rectangle as close as possible to the original one. + + + Keep width and height as close as possible to original ones. + + + Keep horizontal and vertical offset as close as possible to original ones. + + + +On success the &v4l2-rect; r field contains +the adjusted rectangle. When the parameters are unsuitable the application may +modify the cropping (composing) or image parameters and repeat the cycle until +satisfactory parameters have been negotiated. If constraints flags have to be +violated at then ERANGE is returned. The error indicates that there +exist no rectangle that satisfies the constraints. + + Selection targets and flags are documented in . + + +
+ Size adjustments with constraint flags. + + + + + + Behaviour of rectangle adjustment for different constraint + flags. + + +
+ + + + + struct <structname>v4l2_selection</structname> + + &cs-str; + + + __u32 + type + Type of the buffer (from &v4l2-buf-type;). + + + __u32 + target + Used to select between cropping + and composing rectangles. + + + __u32 + flags + Flags controlling the selection rectangle adjustments, refer to + selection flags. + + + &v4l2-rect; + r + The selection rectangle. + + + __u32 + reserved[9] + Reserved fields for future use. + + + +
+ + + + + &return-value; + + + EINVAL + + Given buffer type type or +the selection target target is not supported, +or the flags argument is not valid. + + + + ERANGE + + It is not possible to adjust &v4l2-rect; +r rectangle to satisfy all contraints given in the +flags argument. + + + + EBUSY + + It is not possible to apply change of the selection rectangle +at the moment. Usually because streaming is in progress. + + + + + + diff --git a/Documentation/DocBook/media/v4l/vidioc-g-sliced-vbi-cap.xml b/Documentation/DocBook/media/v4l/vidioc-g-sliced-vbi-cap.xml new file mode 100644 index 00000000..bd015d15 --- /dev/null +++ b/Documentation/DocBook/media/v4l/vidioc-g-sliced-vbi-cap.xml @@ -0,0 +1,255 @@ + + + ioctl VIDIOC_G_SLICED_VBI_CAP + &manvol; + + + + VIDIOC_G_SLICED_VBI_CAP + Query sliced VBI capabilities + + + + + + int ioctl + int fd + int request + struct v4l2_sliced_vbi_cap *argp + + + + + + Arguments + + + + fd + + &fd; + + + + request + + VIDIOC_G_SLICED_VBI_CAP + + + + argp + + + + + + + + + Description + + To find out which data services are supported by a sliced +VBI capture or output device, applications initialize the +type field of a &v4l2-sliced-vbi-cap;, +clear the reserved array and +call the VIDIOC_G_SLICED_VBI_CAP ioctl. The +driver fills in the remaining fields or returns an &EINVAL; if the +sliced VBI API is unsupported or type +is invalid. + + Note the type field was added, +and the ioctl changed from read-only to write-read, in Linux 2.6.19. + + + struct <structname>v4l2_sliced_vbi_cap</structname> + + + + + + + + + + __u16 + service_set + A set of all data services +supported by the driver. Equal to the union of all elements of the +service_lines array. + + + __u16 + service_lines[2][24] + Each element of this array +contains a set of data services the hardware can look for or insert +into a particular scan line. Data services are defined in . Array indices map to ITU-R +line numbers (see also and ) as follows: + + + + + Element + 525 line systems + 625 line systems + + + + + service_lines[0][1] + 1 + 1 + + + + + service_lines[0][23] + 23 + 23 + + + + + service_lines[1][1] + 264 + 314 + + + + + service_lines[1][23] + 286 + 336 + + + + + + + + The number of VBI lines the +hardware can capture or output per frame, or the number of services it +can identify on a given line may be limited. For example on PAL line +16 the hardware may be able to look for a VPS or Teletext signal, but +not both at the same time. Applications can learn about these limits +using the &VIDIOC-S-FMT; ioctl as described in . + + + + + + + + Drivers must set +service_lines[0][0] and +service_lines[1][0] to zero. + + + __u32 + type + Type of the data stream, see . Should be +V4L2_BUF_TYPE_SLICED_VBI_CAPTURE or +V4L2_BUF_TYPE_SLICED_VBI_OUTPUT. + + + __u32 + reserved[3] + This array is reserved for future +extensions. Applications and drivers must set it to zero. + + + +
+ + + + Sliced VBI services + + + + + + + + + + Symbol + Value + Reference + Lines, usually + Payload + + + + + V4L2_SLICED_TELETEXT_B (Teletext +System B) + 0x0001 + , + PAL/SECAM line 7-22, 320-335 (second field 7-22) + Last 42 of the 45 byte Teletext packet, that is +without clock run-in and framing code, lsb first transmitted. + + + V4L2_SLICED_VPS + 0x0400 + + PAL line 16 + Byte number 3 to 15 according to Figure 9 of +ETS 300 231, lsb first transmitted. + + + V4L2_SLICED_CAPTION_525 + 0x1000 + + NTSC line 21, 284 (second field 21) + Two bytes in transmission order, including parity +bit, lsb first transmitted. + + + V4L2_SLICED_WSS_625 + 0x4000 + , + PAL/SECAM line 23 + +Byte 0 1 + msb lsb msb lsb +Bit 7 6 5 4 3 2 1 0 x x 13 12 11 10 9 + + + + V4L2_SLICED_VBI_525 + 0x1000 + Set of services applicable to 525 +line systems. + + + V4L2_SLICED_VBI_625 + 0x4401 + Set of services applicable to 625 +line systems. + + + +
+ + + + + &return-value; + + + + EINVAL + + The value in the type field is +wrong. + + + + + diff --git a/Documentation/DocBook/media/v4l/vidioc-g-std.xml b/Documentation/DocBook/media/v4l/vidioc-g-std.xml new file mode 100644 index 00000000..4a898417 --- /dev/null +++ b/Documentation/DocBook/media/v4l/vidioc-g-std.xml @@ -0,0 +1,98 @@ + + + ioctl VIDIOC_G_STD, VIDIOC_S_STD + &manvol; + + + + VIDIOC_G_STD + VIDIOC_S_STD + Query or select the video standard of the current input + + + + + + int ioctl + int fd + int request + v4l2_std_id +*argp + + + + + int ioctl + int fd + int request + const v4l2_std_id +*argp + + + + + + Arguments + + + + fd + + &fd; + + + + request + + VIDIOC_G_STD, VIDIOC_S_STD + + + + argp + + + + + + + + + Description + + To query and select the current video standard applications +use the VIDIOC_G_STD and VIDIOC_S_STD ioctls which take a pointer to a +&v4l2-std-id; type as argument. VIDIOC_G_STD can +return a single flag or a set of flags as in &v4l2-standard; field +id. The flags must be unambiguous such +that they appear in only one enumerated v4l2_standard structure. + + VIDIOC_S_STD accepts one or more +flags, being a write-only ioctl it does not return the actual new standard as +VIDIOC_G_STD does. When no flags are given or +the current input does not support the requested standard the driver +returns an &EINVAL;. When the standard set is ambiguous drivers may +return EINVAL or choose any of the requested +standards. If the current input or output does not support standard video timings (e.g. if +&VIDIOC-ENUMINPUT; does not set the V4L2_IN_CAP_STD flag), then +&ENODATA; is returned. + + + + &return-value; + + + + EINVAL + + The VIDIOC_S_STD parameter was unsuitable. + + + + ENODATA + + Standard video timings are not supported for this input or output. + + + + + diff --git a/Documentation/DocBook/media/v4l/vidioc-g-tuner.xml b/Documentation/DocBook/media/v4l/vidioc-g-tuner.xml new file mode 100644 index 00000000..6cc82010 --- /dev/null +++ b/Documentation/DocBook/media/v4l/vidioc-g-tuner.xml @@ -0,0 +1,569 @@ + + + ioctl VIDIOC_G_TUNER, VIDIOC_S_TUNER + &manvol; + + + + VIDIOC_G_TUNER + VIDIOC_S_TUNER + Get or set tuner attributes + + + + + + int ioctl + int fd + int request + struct v4l2_tuner +*argp + + + + + int ioctl + int fd + int request + const struct v4l2_tuner +*argp + + + + + + Arguments + + + + fd + + &fd; + + + + request + + VIDIOC_G_TUNER, VIDIOC_S_TUNER + + + + argp + + + + + + + + + Description + + To query the attributes of a tuner applications initialize the +index field and zero out the +reserved array of a &v4l2-tuner; and call the +VIDIOC_G_TUNER ioctl with a pointer to this +structure. Drivers fill the rest of the structure or return an +&EINVAL; when the index is out of bounds. To enumerate all tuners +applications shall begin at index zero, incrementing by one until the +driver returns EINVAL. + + Tuners have two writable properties, the audio mode and +the radio frequency. To change the audio mode, applications initialize +the index, +audmode and +reserved fields and call the +VIDIOC_S_TUNER ioctl. This will +not change the current tuner, which is determined +by the current video input. Drivers may choose a different audio mode +if the requested mode is invalid or unsupported. Since this is a +write-only ioctl, it does not return the actually +selected audio mode. + + To change the radio frequency the &VIDIOC-S-FREQUENCY; ioctl +is available. + + + struct <structname>v4l2_tuner</structname> + + + + + + + + + __u32 + index + Identifies the tuner, set by the +application. + + + __u8 + name[32] + Name of the tuner, a +NUL-terminated ASCII string. This information is intended for the +user. + + + __u32 + type + Type of the tuner, see . + + + __u32 + capability + Tuner capability flags, see +. Audio flags indicate the ability +to decode audio subprograms. They will not +change, for example with the current video standard.When +the structure refers to a radio tuner the +V4L2_TUNER_CAP_LANG1, +V4L2_TUNER_CAP_LANG2 and +V4L2_TUNER_CAP_NORM flags can't be used. +If multiple frequency bands are supported, then +capability is the union of all +capability fields of each &v4l2-frequency-band;. + + + + __u32 + rangelow + The lowest tunable frequency in +units of 62.5 kHz, or if the capability +flag V4L2_TUNER_CAP_LOW is set, in units of 62.5 +Hz. If multiple frequency bands are supported, then +rangelow is the lowest frequency +of all the frequency bands. + + + __u32 + rangehigh + The highest tunable frequency in +units of 62.5 kHz, or if the capability +flag V4L2_TUNER_CAP_LOW is set, in units of 62.5 +Hz. If multiple frequency bands are supported, then +rangehigh is the highest frequency +of all the frequency bands. + + + __u32 + rxsubchans + Some tuners or audio +decoders can determine the received audio subprograms by analyzing +audio carriers, pilot tones or other indicators. To pass this +information drivers set flags defined in in this field. For +example: + + + + + V4L2_TUNER_SUB_MONO + receiving mono audio + + + + + STEREO | SAP + receiving stereo audio and a secondary audio +program + + + + + MONO | STEREO + receiving mono or stereo audio, the hardware cannot +distinguish + + + + + LANG1 | LANG2 + receiving bilingual audio + + + + + MONO | STEREO | LANG1 | LANG2 + receiving mono, stereo or bilingual +audio + + + + + When the +V4L2_TUNER_CAP_STEREO, +_LANG1, _LANG2 or +_SAP flag is cleared in the +capability field, the corresponding +V4L2_TUNER_SUB_ flag must not be set +here.This field is valid only if this is the tuner of the +current video input, or when the structure refers to a radio +tuner. + + + __u32 + audmode + The selected audio mode, see + for valid values. The audio mode does +not affect audio subprogram detection, and like a control it does not automatically change +unless the requested mode is invalid or unsupported. See for possible results when +the selected and received audio programs do not +match.Currently this is the only field of struct +v4l2_tuner applications can +change. + + + __u32 + signal + The signal strength if known, ranging +from 0 to 65535. Higher values indicate a better signal. + + + __s32 + afc + Automatic frequency control: When the +afc value is negative, the frequency is too +low, when positive too high. + + + __u32 + reserved[4] + Reserved for future extensions. Drivers and +applications must set the array to zero. + + + +
+ + + enum v4l2_tuner_type + + &cs-def; + + + V4L2_TUNER_RADIO + 1 + + + + V4L2_TUNER_ANALOG_TV + 2 + + + + +
+ + + Tuner and Modulator Capability Flags + + &cs-def; + + + V4L2_TUNER_CAP_LOW + 0x0001 + When set, tuning frequencies are expressed in units of +62.5 Hz, otherwise in units of 62.5 kHz. + + + V4L2_TUNER_CAP_NORM + 0x0002 + This is a multi-standard tuner; the video standard +can or must be switched. (B/G PAL tuners for example are typically not + considered multi-standard because the video standard is automatically + determined from the frequency band.) The set of supported video + standards is available from the &v4l2-input; pointing to this tuner, + see the description of ioctl &VIDIOC-ENUMINPUT; for details. Only + V4L2_TUNER_ANALOG_TV tuners can have this capability. + + + V4L2_TUNER_CAP_HWSEEK_BOUNDED + 0x0004 + If set, then this tuner supports the hardware seek functionality + where the seek stops when it reaches the end of the frequency range. + + + V4L2_TUNER_CAP_HWSEEK_WRAP + 0x0008 + If set, then this tuner supports the hardware seek functionality + where the seek wraps around when it reaches the end of the frequency range. + + + V4L2_TUNER_CAP_STEREO + 0x0010 + Stereo audio reception is supported. + + + V4L2_TUNER_CAP_LANG1 + 0x0040 + Reception of the primary language of a bilingual +audio program is supported. Bilingual audio is a feature of +two-channel systems, transmitting the primary language monaural on the +main audio carrier and a secondary language monaural on a second +carrier. Only + V4L2_TUNER_ANALOG_TV tuners can have this capability. + + + V4L2_TUNER_CAP_LANG2 + 0x0020 + Reception of the secondary language of a bilingual +audio program is supported. Only + V4L2_TUNER_ANALOG_TV tuners can have this capability. + + + V4L2_TUNER_CAP_SAP + 0x0020 + Reception of a secondary audio program is +supported. This is a feature of the BTSC system which accompanies the +NTSC video standard. Two audio carriers are available for mono or +stereo transmissions of a primary language, and an independent third +carrier for a monaural secondary language. Only + V4L2_TUNER_ANALOG_TV tuners can have this capability.Note the +V4L2_TUNER_CAP_LANG2 and +V4L2_TUNER_CAP_SAP flags are synonyms. +V4L2_TUNER_CAP_SAP applies when the tuner +supports the V4L2_STD_NTSC_M video +standard. + + + V4L2_TUNER_CAP_RDS + 0x0080 + RDS capture is supported. This capability is only valid for +radio tuners. + + + V4L2_TUNER_CAP_RDS_BLOCK_IO + 0x0100 + The RDS data is passed as unparsed RDS blocks. + + + V4L2_TUNER_CAP_RDS_CONTROLS + 0x0200 + The RDS data is parsed by the hardware and set via controls. + + + V4L2_TUNER_CAP_FREQ_BANDS + 0x0400 + The &VIDIOC-ENUM-FREQ-BANDS; ioctl can be used to enumerate + the available frequency bands. + + + V4L2_TUNER_CAP_HWSEEK_PROG_LIM + 0x0800 + The range to search when using the hardware seek functionality + is programmable, see &VIDIOC-S-HW-FREQ-SEEK; for details. + + + +
+ + + Tuner Audio Reception Flags + + &cs-def; + + + V4L2_TUNER_SUB_MONO + 0x0001 + The tuner receives a mono audio signal. + + + V4L2_TUNER_SUB_STEREO + 0x0002 + The tuner receives a stereo audio signal. + + + V4L2_TUNER_SUB_LANG1 + 0x0008 + The tuner receives the primary language of a +bilingual audio signal. Drivers must clear this flag when the current +video standard is V4L2_STD_NTSC_M. + + + V4L2_TUNER_SUB_LANG2 + 0x0004 + The tuner receives the secondary language of a +bilingual audio signal (or a second audio program). + + + V4L2_TUNER_SUB_SAP + 0x0004 + The tuner receives a Second Audio Program. Note the +V4L2_TUNER_SUB_LANG2 and +V4L2_TUNER_SUB_SAP flags are synonyms. The +V4L2_TUNER_SUB_SAP flag applies when the +current video standard is V4L2_STD_NTSC_M. + + + V4L2_TUNER_SUB_RDS + 0x0010 + The tuner receives an RDS channel. + + + +
+ + + Tuner Audio Modes + + &cs-def; + + + V4L2_TUNER_MODE_MONO + 0 + Play mono audio. When the tuner receives a stereo +signal this a down-mix of the left and right channel. When the tuner +receives a bilingual or SAP signal this mode selects the primary +language. + + + V4L2_TUNER_MODE_STEREO + 1 + Play stereo audio. When the tuner receives +bilingual audio it may play different languages on the left and right +channel or the primary language is played on both channels.Playing +different languages in this mode is +deprecated. New drivers should do this only in +MODE_LANG1_LANG2.When the tuner +receives no stereo signal or does not support stereo reception the +driver shall fall back to MODE_MONO. + + + V4L2_TUNER_MODE_LANG1 + 3 + Play the primary language, mono or stereo. Only +V4L2_TUNER_ANALOG_TV tuners support this +mode. + + + V4L2_TUNER_MODE_LANG2 + 2 + Play the secondary language, mono. When the tuner +receives no bilingual audio or SAP, or their reception is not +supported the driver shall fall back to mono or stereo mode. Only +V4L2_TUNER_ANALOG_TV tuners support this +mode. + + + V4L2_TUNER_MODE_SAP + 2 + Play the Second Audio Program. When the tuner +receives no bilingual audio or SAP, or their reception is not +supported the driver shall fall back to mono or stereo mode. Only +V4L2_TUNER_ANALOG_TV tuners support this mode. +Note the V4L2_TUNER_MODE_LANG2 and +V4L2_TUNER_MODE_SAP are synonyms. + + + V4L2_TUNER_MODE_LANG1_LANG2 + 4 + Play the primary language on the left channel, the +secondary language on the right channel. When the tuner receives no +bilingual audio or SAP, it shall fall back to +MODE_LANG1 or MODE_MONO. +Only V4L2_TUNER_ANALOG_TV tuners support this +mode. + + + +
+ + + Tuner Audio Matrix + + + + + + + + + + + Selected +V4L2_TUNER_MODE_ + + + Received V4L2_TUNER_SUB_ + MONO + STEREO + LANG1 + LANG2 = SAP + LANG1_LANG2This +mode has been added in Linux 2.6.17 and may not be supported by older +drivers. + + + + + MONO + Mono + Mono/Mono + Mono + Mono + Mono/Mono + + + MONO | SAP + Mono + Mono/Mono + Mono + SAP + Mono/SAP (preferred) or Mono/Mono + + + STEREO + L+R + L/R + Stereo L/R (preferred) or Mono L+R + Stereo L/R (preferred) or Mono L+R + L/R (preferred) or L+R/L+R + + + STEREO | SAP + L+R + L/R + Stereo L/R (preferred) or Mono L+R + SAP + L+R/SAP (preferred) or L/R or L+R/L+R + + + LANG1 | LANG2 + Language 1 + Lang1/Lang2 (deprecatedPlayback of +both languages in MODE_STEREO is deprecated. In +the future drivers should produce only the primary language in this +mode. Applications should request +MODE_LANG1_LANG2 to record both languages or a +stereo signal.) or +Lang1/Lang1 + Language 1 + Language 2 + Lang1/Lang2 (preferred) or Lang1/Lang1 + + + +
+ + + + &return-value; + + + + EINVAL + + The &v4l2-tuner; index is +out of bounds. + + + + + diff --git a/Documentation/DocBook/media/v4l/vidioc-log-status.xml b/Documentation/DocBook/media/v4l/vidioc-log-status.xml new file mode 100644 index 00000000..5ded7d35 --- /dev/null +++ b/Documentation/DocBook/media/v4l/vidioc-log-status.xml @@ -0,0 +1,41 @@ + + + ioctl VIDIOC_LOG_STATUS + &manvol; + + + + VIDIOC_LOG_STATUS + Log driver status information + + + + + + int ioctl + int fd + int request + + + + + + Description + + As the video/audio devices become more complicated it +becomes harder to debug problems. When this ioctl is called the driver +will output the current device status to the kernel log. This is +particular useful when dealing with problems like no sound, no video +and incorrectly tuned channels. Also many modern devices autodetect +video and audio standards and this ioctl will report what the device +thinks what the standard is. Mismatches may give an indication where +the problem is. + + This ioctl is optional and not all drivers support it. It +was introduced in Linux 2.6.15. + + + + &return-value; + + diff --git a/Documentation/DocBook/media/v4l/vidioc-overlay.xml b/Documentation/DocBook/media/v4l/vidioc-overlay.xml new file mode 100644 index 00000000..250a7de1 --- /dev/null +++ b/Documentation/DocBook/media/v4l/vidioc-overlay.xml @@ -0,0 +1,74 @@ + + + ioctl VIDIOC_OVERLAY + &manvol; + + + + VIDIOC_OVERLAY + Start or stop video overlay + + + + + + int ioctl + int fd + int request + const int *argp + + + + + + Arguments + + + + fd + + &fd; + + + + request + + VIDIOC_OVERLAY + + + + argp + + + + + + + + + Description + + This ioctl is part of the video + overlay I/O method. Applications call + VIDIOC_OVERLAY to start or stop the + overlay. It takes a pointer to an integer which must be set to + zero by the application to stop overlay, to one to start. + + Drivers do not support &VIDIOC-STREAMON; or +&VIDIOC-STREAMOFF; with V4L2_BUF_TYPE_VIDEO_OVERLAY. + + + + &return-value; + + + + EINVAL + + The overlay parameters have not been set up. See for the necessary steps. + + + + + diff --git a/Documentation/DocBook/media/v4l/vidioc-prepare-buf.xml b/Documentation/DocBook/media/v4l/vidioc-prepare-buf.xml new file mode 100644 index 00000000..fa7ad7e3 --- /dev/null +++ b/Documentation/DocBook/media/v4l/vidioc-prepare-buf.xml @@ -0,0 +1,94 @@ + + + ioctl VIDIOC_PREPARE_BUF + &manvol; + + + + VIDIOC_PREPARE_BUF + Prepare a buffer for I/O + + + + + + int ioctl + int fd + int request + struct v4l2_buffer *argp + + + + + + Arguments + + + + fd + + &fd; + + + + request + + VIDIOC_PREPARE_BUF + + + + argp + + + + + + + + + Description + + + Experimental + This is an experimental + interface and may change in the future. + + + Applications can optionally call the +VIDIOC_PREPARE_BUF ioctl to pass ownership of the buffer +to the driver before actually enqueuing it, using the +VIDIOC_QBUF ioctl, and to prepare it for future I/O. +Such preparations may include cache invalidation or cleaning. Performing them +in advance saves time during the actual I/O. In case such cache operations are +not required, the application can use one of +V4L2_BUF_FLAG_NO_CACHE_INVALIDATE and +V4L2_BUF_FLAG_NO_CACHE_CLEAN flags to skip the respective +step. + + The v4l2_buffer structure is +specified in . + + + + &return-value; + + + + EBUSY + + File I/O is in progress. + + + + EINVAL + + The buffer type is not +supported, or the index is out of bounds, +or no buffers have been allocated yet, or the +userptr or +length are invalid. + + + + + diff --git a/Documentation/DocBook/media/v4l/vidioc-qbuf.xml b/Documentation/DocBook/media/v4l/vidioc-qbuf.xml new file mode 100644 index 00000000..3504a7f2 --- /dev/null +++ b/Documentation/DocBook/media/v4l/vidioc-qbuf.xml @@ -0,0 +1,192 @@ + + + ioctl VIDIOC_QBUF, VIDIOC_DQBUF + &manvol; + + + + VIDIOC_QBUF + VIDIOC_DQBUF + Exchange a buffer with the driver + + + + + + int ioctl + int fd + int request + struct v4l2_buffer *argp + + + + + + Arguments + + + + fd + + &fd; + + + + request + + VIDIOC_QBUF, VIDIOC_DQBUF + + + + argp + + + + + + + + + Description + + Applications call the VIDIOC_QBUF ioctl +to enqueue an empty (capturing) or filled (output) buffer in the +driver's incoming queue. The semantics depend on the selected I/O +method. + + To enqueue a buffer applications set the type +field of a &v4l2-buffer; to the same buffer type as was previously used +with &v4l2-format; type and &v4l2-requestbuffers; +type. Applications must also set the +index field. Valid index numbers range from +zero to the number of buffers allocated with &VIDIOC-REQBUFS; +(&v4l2-requestbuffers; count) minus one. The +contents of the struct v4l2_buffer returned +by a &VIDIOC-QUERYBUF; ioctl will do as well. When the buffer is +intended for output (type is +V4L2_BUF_TYPE_VIDEO_OUTPUT, +V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE, or +V4L2_BUF_TYPE_VBI_OUTPUT) applications must also +initialize the bytesused, +field and +timestamp fields, see for details. +Applications must also set flags to 0. +The reserved2 and +reserved fields must be set to 0. When using +the multi-planar API, the +m.planes field must contain a userspace pointer +to a filled-in array of &v4l2-plane; and the length +field must be set to the number of elements in that array. + + + To enqueue a memory mapped +buffer applications set the memory +field to V4L2_MEMORY_MMAP. When +VIDIOC_QBUF is called with a pointer to this +structure the driver sets the +V4L2_BUF_FLAG_MAPPED and +V4L2_BUF_FLAG_QUEUED flags and clears the +V4L2_BUF_FLAG_DONE flag in the +flags field, or it returns an +&EINVAL;. + + To enqueue a user pointer +buffer applications set the memory +field to V4L2_MEMORY_USERPTR, the +m.userptr field to the address of the +buffer and length to its size. When the multi-planar +API is used, m.userptr and +length members of the passed array of &v4l2-plane; +have to be used instead. When VIDIOC_QBUF is called with +a pointer to this structure the driver sets the +V4L2_BUF_FLAG_QUEUED flag and clears the +V4L2_BUF_FLAG_MAPPED and +V4L2_BUF_FLAG_DONE flags in the +flags field, or it returns an error code. +This ioctl locks the memory pages of the buffer in physical memory, +they cannot be swapped out to disk. Buffers remain locked until +dequeued, until the &VIDIOC-STREAMOFF; or &VIDIOC-REQBUFS; ioctl is +called, or until the device is closed. + + To enqueue a DMABUF buffer applications +set the memory field to +V4L2_MEMORY_DMABUF and the m.fd +field to a file descriptor associated with a DMABUF buffer. When the +multi-planar API is used the m.fd fields of the +passed array of &v4l2-plane; have to be used instead. When +VIDIOC_QBUF is called with a pointer to this structure the +driver sets the V4L2_BUF_FLAG_QUEUED flag and clears the +V4L2_BUF_FLAG_MAPPED and +V4L2_BUF_FLAG_DONE flags in the +flags field, or it returns an error code. This +ioctl locks the buffer. Locking a buffer means passing it to a driver for a +hardware access (usually DMA). If an application accesses (reads/writes) a +locked buffer then the result is undefined. Buffers remain locked until +dequeued, until the &VIDIOC-STREAMOFF; or &VIDIOC-REQBUFS; ioctl is called, or +until the device is closed. + + Applications call the VIDIOC_DQBUF +ioctl to dequeue a filled (capturing) or displayed (output) buffer +from the driver's outgoing queue. They just set the +type, memory +and reserved +fields of a &v4l2-buffer; as above, when VIDIOC_DQBUF +is called with a pointer to this structure the driver fills the +remaining fields or returns an error code. The driver may also set +V4L2_BUF_FLAG_ERROR in the flags +field. It indicates a non-critical (recoverable) streaming error. In such case +the application may continue as normal, but should be aware that data in the +dequeued buffer might be corrupted. When using the multi-planar API, the +planes array must be passed in as well. + + By default VIDIOC_DQBUF blocks when no +buffer is in the outgoing queue. When the +O_NONBLOCK flag was given to the &func-open; +function, VIDIOC_DQBUF returns immediately +with an &EAGAIN; when no buffer is available. + + The v4l2_buffer structure is +specified in . + + + + &return-value; + + + + EAGAIN + + Non-blocking I/O has been selected using +O_NONBLOCK and no buffer was in the outgoing +queue. + + + + EINVAL + + The buffer type is not +supported, or the index is out of bounds, +or no buffers have been allocated yet, or the +userptr or +length are invalid. + + + + EIO + + VIDIOC_DQBUF failed due to an +internal error. Can also indicate temporary problems like signal +loss. Note the driver might dequeue an (empty) buffer despite +returning an error, or even stop capturing. Reusing such buffer may be unsafe +though and its details (e.g. index) may not be +returned either. It is recommended that drivers indicate recoverable errors +by setting the V4L2_BUF_FLAG_ERROR and returning 0 instead. +In that case the application should be able to safely reuse the buffer and +continue streaming. + + + + + + diff --git a/Documentation/DocBook/media/v4l/vidioc-query-dv-preset.xml b/Documentation/DocBook/media/v4l/vidioc-query-dv-preset.xml new file mode 100644 index 00000000..68b49d09 --- /dev/null +++ b/Documentation/DocBook/media/v4l/vidioc-query-dv-preset.xml @@ -0,0 +1,78 @@ + + + ioctl VIDIOC_QUERY_DV_PRESET + &manvol; + + + + VIDIOC_QUERY_DV_PRESET + Sense the DV preset received by the current +input + + + + + + int ioctl + int fd + int request + struct v4l2_dv_preset *argp + + + + + + Arguments + + + + fd + + &fd; + + + + request + + VIDIOC_QUERY_DV_PRESET + + + + argp + + + + + + + + + Description + + This ioctl is deprecated. + New drivers and applications should use &VIDIOC-QUERY-DV-TIMINGS; instead. + + + The hardware may be able to detect the current DV preset +automatically, similar to sensing the video standard. To do so, applications +call VIDIOC_QUERY_DV_PRESET with a pointer to a +&v4l2-dv-preset; type. Once the hardware detects a preset, that preset is +returned in the preset field of &v4l2-dv-preset;. If the preset could not be +detected because there was no signal, or the signal was unreliable, or the +signal did not map to a supported preset, then the value V4L2_DV_INVALID is +returned. + + + + &return-value; + + + + ENODATA + + Digital video presets are not supported for this input or output. + + + + + diff --git a/Documentation/DocBook/media/v4l/vidioc-query-dv-timings.xml b/Documentation/DocBook/media/v4l/vidioc-query-dv-timings.xml new file mode 100644 index 00000000..e185f149 --- /dev/null +++ b/Documentation/DocBook/media/v4l/vidioc-query-dv-timings.xml @@ -0,0 +1,110 @@ + + + ioctl VIDIOC_QUERY_DV_TIMINGS + &manvol; + + + + VIDIOC_QUERY_DV_TIMINGS + Sense the DV preset received by the current +input + + + + + + int ioctl + int fd + int request + struct v4l2_dv_timings *argp + + + + + + Arguments + + + + fd + + &fd; + + + + request + + VIDIOC_QUERY_DV_TIMINGS + + + + argp + + + + + + + + + Description + + + Experimental + This is an experimental + interface and may change in the future. + + + The hardware may be able to detect the current DV timings +automatically, similar to sensing the video standard. To do so, applications +call VIDIOC_QUERY_DV_TIMINGS with a pointer to a +&v4l2-dv-timings;. Once the hardware detects the timings, it will fill in the +timings structure. + +If the timings could not be detected because there was no signal, then +ENOLINK is returned. If a signal was detected, but +it was unstable and the receiver could not lock to the signal, then +ENOLCK is returned. If the receiver could lock to the signal, +but the format is unsupported (e.g. because the pixelclock is out of range +of the hardware capabilities), then the driver fills in whatever timings it +could find and returns ERANGE. In that case the application +can call &VIDIOC-DV-TIMINGS-CAP; to compare the found timings with the hardware's +capabilities in order to give more precise feedback to the user. + + + + + &return-value; + + + + ENODATA + + Digital video timings are not supported for this input or output. + + + + ENOLINK + + No timings could be detected because no signal was found. + + + + + ENOLCK + + The signal was unstable and the hardware could not lock on to it. + + + + + ERANGE + + Timings were found, but they are out of range of the hardware +capabilities. + + + + + + diff --git a/Documentation/DocBook/media/v4l/vidioc-querybuf.xml b/Documentation/DocBook/media/v4l/vidioc-querybuf.xml new file mode 100644 index 00000000..a597155c --- /dev/null +++ b/Documentation/DocBook/media/v4l/vidioc-querybuf.xml @@ -0,0 +1,105 @@ + + + ioctl VIDIOC_QUERYBUF + &manvol; + + + + VIDIOC_QUERYBUF + Query the status of a buffer + + + + + + int ioctl + int fd + int request + struct v4l2_buffer *argp + + + + + + Arguments + + + + fd + + &fd; + + + + request + + VIDIOC_QUERYBUF + + + + argp + + + + + + + + + Description + + This ioctl is part of the streaming + I/O method. It can be used to query the status of a +buffer at any time after buffers have been allocated with the +&VIDIOC-REQBUFS; ioctl. + + Applications set the type field + of a &v4l2-buffer; to the same buffer type as was previously used with +&v4l2-format; type and &v4l2-requestbuffers; +type, and the index + field. Valid index numbers range from zero +to the number of buffers allocated with &VIDIOC-REQBUFS; + (&v4l2-requestbuffers; count) minus one. +The reserved field should to set to 0. +When using the multi-planar API, the +m.planes field must contain a userspace pointer to an +array of &v4l2-plane; and the length field has +to be set to the number of elements in that array. +After calling VIDIOC_QUERYBUF with a pointer to + this structure drivers return an error code or fill the rest of +the structure. + + In the flags field the +V4L2_BUF_FLAG_MAPPED, +V4L2_BUF_FLAG_PREPARED, +V4L2_BUF_FLAG_QUEUED and +V4L2_BUF_FLAG_DONE flags will be valid. The +memory field will be set to the current +I/O method. For the single-planar API, the m.offset +contains the offset of the buffer from the start of the device memory, +the length field its size. For the multi-planar API, +fields m.mem_offset and +length in the m.planes +array elements will be used instead and the length +field of &v4l2-buffer; is set to the number of filled-in array elements. +The driver may or may not set the remaining fields and flags, they are +meaningless in this context. + + The v4l2_buffer structure is + specified in . + + + + &return-value; + + + + EINVAL + + The buffer type is not +supported, or the index is out of bounds. + + + + + diff --git a/Documentation/DocBook/media/v4l/vidioc-querycap.xml b/Documentation/DocBook/media/v4l/vidioc-querycap.xml new file mode 100644 index 00000000..d5a3c97b --- /dev/null +++ b/Documentation/DocBook/media/v4l/vidioc-querycap.xml @@ -0,0 +1,332 @@ + + + ioctl VIDIOC_QUERYCAP + &manvol; + + + + VIDIOC_QUERYCAP + Query device capabilities + + + + + + int ioctl + int fd + int request + struct v4l2_capability *argp + + + + + + Arguments + + + + fd + + &fd; + + + + request + + VIDIOC_QUERYCAP + + + + argp + + + + + + + + + Description + + All V4L2 devices support the +VIDIOC_QUERYCAP ioctl. It is used to identify +kernel devices compatible with this specification and to obtain +information about driver and hardware capabilities. The ioctl takes a +pointer to a &v4l2-capability; which is filled by the driver. When the +driver is not compatible with this specification the ioctl returns an +&EINVAL;. + + + struct <structname>v4l2_capability</structname> + + &cs-str; + + + __u8 + driver[16] + Name of the driver, a unique NUL-terminated +ASCII string. For example: "bttv". Driver specific applications can +use this information to verify the driver identity. It is also useful +to work around known bugs, or to identify drivers in error reports. +Storing strings in fixed sized arrays is bad +practice but unavoidable here. Drivers and applications should take +precautions to never read or write beyond the end of the array and to +make sure the strings are properly NUL-terminated. + + + __u8 + card[32] + Name of the device, a NUL-terminated UTF-8 string. +For example: "Yoyodyne TV/FM". One driver may support different brands +or models of video hardware. This information is intended for users, +for example in a menu of available devices. Since multiple TV cards of +the same brand may be installed which are supported by the same +driver, this name should be combined with the character device file +name (⪚ /dev/video2) or the +bus_info string to avoid +ambiguities. + + + __u8 + bus_info[32] + Location of the device in the system, a +NUL-terminated ASCII string. For example: "PCI:0000:05:06.0". This +information is intended for users, to distinguish multiple +identical devices. If no such information is available the field must +simply count the devices controlled by the driver ("platform:vivi-000"). +The bus_info must start with "PCI:" for PCI boards, "PCIe:" for PCI Express boards, +"usb-" for USB devices, "I2C:" for i2c devices, "ISA:" for ISA devices, +"parport" for parallel port devices and "platform:" for platform devices. + + + __u32 + version + Version number of the driver. +Starting on kernel 3.1, the version reported is provided per +V4L2 subsystem, following the same Kernel numberation scheme. However, it +should not always return the same version as the kernel, if, for example, +an stable or distribution-modified kernel uses the V4L2 stack from a +newer kernel. +The version number is formatted using the +KERNEL_VERSION() macro: + + + + +#define KERNEL_VERSION(a,b,c) (((a) << 16) + ((b) << 8) + (c)) + +__u32 version = KERNEL_VERSION(0, 8, 1); + +printf ("Version: %u.%u.%u\n", + (version >> 16) & 0xFF, + (version >> 8) & 0xFF, + version & 0xFF); + + + + __u32 + capabilities + Available capabilities of the physical device as a whole, see . The same physical device can export + multiple devices in /dev (e.g. /dev/videoX, /dev/vbiY and /dev/radioZ). + The capabilities field should contain a union + of all capabilities available around the several V4L2 devices exported + to userspace. + For all those devices the capabilities field + returns the same set of capabilities. This allows applications to open + just one of the devices (typically the video device) and discover whether + video, vbi and/or radio are also supported. + + + + __u32 + device_caps + Device capabilities of the opened device, see . Should contain the available capabilities + of that specific device node. So, for example, device_caps + of a radio device will only contain radio related capabilities and + no video or vbi capabilities. This field is only set if the capabilities + field contains the V4L2_CAP_DEVICE_CAPS capability. + Only the capabilities field can have the + V4L2_CAP_DEVICE_CAPS capability, device_caps + will never set V4L2_CAP_DEVICE_CAPS. + + + + __u32 + reserved[3] + Reserved for future extensions. Drivers must set +this array to zero. + + + +
+ + + Device Capabilities Flags + + &cs-def; + + + V4L2_CAP_VIDEO_CAPTURE + 0x00000001 + The device supports the single-planar API through the Video Capture interface. + + + V4L2_CAP_VIDEO_CAPTURE_MPLANE + 0x00001000 + The device supports the + multi-planar API through the + Video Capture interface. + + + V4L2_CAP_VIDEO_OUTPUT + 0x00000002 + The device supports the single-planar API through the Video Output interface. + + + V4L2_CAP_VIDEO_OUTPUT_MPLANE + 0x00002000 + The device supports the + multi-planar API through the + Video Output interface. + + + V4L2_CAP_VIDEO_M2M + 0x00004000 + The device supports the single-planar API through the + Video Memory-To-Memory interface. + + + V4L2_CAP_VIDEO_M2M_MPLANE + 0x00008000 + The device supports the + multi-planar API through the + Video Memory-To-Memory interface. + + + V4L2_CAP_VIDEO_OVERLAY + 0x00000004 + The device supports the Video Overlay interface. A video overlay device +typically stores captured images directly in the video memory of a +graphics card, with hardware clipping and scaling. + + + V4L2_CAP_VBI_CAPTURE + 0x00000010 + The device supports the Raw +VBI Capture interface, providing Teletext and Closed Caption +data. + + + V4L2_CAP_VBI_OUTPUT + 0x00000020 + The device supports the Raw VBI Output interface. + + + V4L2_CAP_SLICED_VBI_CAPTURE + 0x00000040 + The device supports the Sliced VBI Capture interface. + + + V4L2_CAP_SLICED_VBI_OUTPUT + 0x00000080 + The device supports the Sliced VBI Output interface. + + + V4L2_CAP_RDS_CAPTURE + 0x00000100 + The device supports the RDS capture interface. + + + V4L2_CAP_VIDEO_OUTPUT_OVERLAY + 0x00000200 + The device supports the Video +Output Overlay (OSD) interface. Unlike the Video +Overlay interface, this is a secondary function of video +output devices and overlays an image onto an outgoing video signal. +When the driver sets this flag, it must clear the +V4L2_CAP_VIDEO_OVERLAY flag and vice +versa.The &v4l2-framebuffer; lacks an +&v4l2-buf-type; field, therefore the type of overlay is implied by the +driver capabilities. + + + V4L2_CAP_HW_FREQ_SEEK + 0x00000400 + The device supports the &VIDIOC-S-HW-FREQ-SEEK; ioctl for +hardware frequency seeking. + + + V4L2_CAP_RDS_OUTPUT + 0x00000800 + The device supports the RDS output interface. + + + V4L2_CAP_TUNER + 0x00010000 + The device has some sort of tuner to +receive RF-modulated video signals. For more information about +tuner programming see +. + + + V4L2_CAP_AUDIO + 0x00020000 + The device has audio inputs or outputs. It may or +may not support audio recording or playback, in PCM or compressed +formats. PCM audio support must be implemented as ALSA or OSS +interface. For more information on audio inputs and outputs see . + + + V4L2_CAP_RADIO + 0x00040000 + This is a radio receiver. + + + V4L2_CAP_MODULATOR + 0x00080000 + The device has some sort of modulator to +emit RF-modulated video/audio signals. For more information about +modulator programming see +. + + + V4L2_CAP_READWRITE + 0x01000000 + The device supports the read() and/or write() +I/O methods. + + + V4L2_CAP_ASYNCIO + 0x02000000 + The device supports the asynchronous I/O methods. + + + V4L2_CAP_STREAMING + 0x04000000 + The device supports the streaming I/O method. + + + V4L2_CAP_DEVICE_CAPS + 0x80000000 + The driver fills the device_caps + field. This capability can only appear in the capabilities + field and never in the device_caps field. + + + +
+ + + + &return-value; + + diff --git a/Documentation/DocBook/media/v4l/vidioc-queryctrl.xml b/Documentation/DocBook/media/v4l/vidioc-queryctrl.xml new file mode 100644 index 00000000..e6645b99 --- /dev/null +++ b/Documentation/DocBook/media/v4l/vidioc-queryctrl.xml @@ -0,0 +1,480 @@ + + + ioctl VIDIOC_QUERYCTRL, VIDIOC_QUERYMENU + &manvol; + + + + VIDIOC_QUERYCTRL + VIDIOC_QUERYMENU + Enumerate controls and menu control items + + + + + + int ioctl + int fd + int request + struct v4l2_queryctrl *argp + + + + + int ioctl + int fd + int request + struct v4l2_querymenu *argp + + + + + + Arguments + + + + fd + + &fd; + + + + request + + VIDIOC_QUERYCTRL, VIDIOC_QUERYMENU + + + + argp + + + + + + + + + Description + + To query the attributes of a control applications set the +id field of a &v4l2-queryctrl; and call the +VIDIOC_QUERYCTRL ioctl with a pointer to this +structure. The driver fills the rest of the structure or returns an +&EINVAL; when the id is invalid. + + It is possible to enumerate controls by calling +VIDIOC_QUERYCTRL with successive +id values starting from +V4L2_CID_BASE up to and exclusive +V4L2_CID_BASE_LASTP1. Drivers may return +EINVAL if a control in this range is not +supported. Further applications can enumerate private controls, which +are not defined in this specification, by starting at +V4L2_CID_PRIVATE_BASE and incrementing +id until the driver returns +EINVAL. + + In both cases, when the driver sets the +V4L2_CTRL_FLAG_DISABLED flag in the +flags field this control is permanently +disabled and should be ignored by the application. + V4L2_CTRL_FLAG_DISABLED was +intended for two purposes: Drivers can skip predefined controls not +supported by the hardware (although returning EINVAL would do as +well), or disable predefined and private controls after hardware +detection without the trouble of reordering control arrays and indices +(EINVAL cannot be used to skip private controls because it would +prematurely end the enumeration). + + When the application ORs id with +V4L2_CTRL_FLAG_NEXT_CTRL the driver returns the +next supported control, or EINVAL if there is +none. Drivers which do not support this flag yet always return +EINVAL. + + Additional information is required for menu controls: the +names of the menu items. To query them applications set the +id and index +fields of &v4l2-querymenu; and call the +VIDIOC_QUERYMENU ioctl with a pointer to this +structure. The driver fills the rest of the structure or returns an +&EINVAL; when the id or +index is invalid. Menu items are enumerated +by calling VIDIOC_QUERYMENU with successive +index values from &v4l2-queryctrl; +minimum to +maximum, inclusive. Note that it is possible +for VIDIOC_QUERYMENU to return an &EINVAL; for some +indices between minimum and maximum. +In that case that particular menu item is not supported by this driver. Also note that +the minimum value is not necessarily 0. + + See also the examples in . + + + struct <structname>v4l2_queryctrl</structname> + + &cs-str; + + + __u32 + id + Identifies the control, set by the application. See + for predefined IDs. When the ID is ORed +with V4L2_CTRL_FLAG_NEXT_CTRL the driver clears the flag and returns +the first control with a higher ID. Drivers which do not support this +flag yet always return an &EINVAL;. + + + __u32 + type + Type of control, see . + + + __u8 + name[32] + Name of the control, a NUL-terminated ASCII +string. This information is intended for the user. + + + __s32 + minimum + Minimum value, inclusive. This field gives a lower +bound for V4L2_CTRL_TYPE_INTEGER controls and the +lowest valid index for V4L2_CTRL_TYPE_MENU controls. +For V4L2_CTRL_TYPE_STRING controls the minimum value +gives the minimum length of the string. This length does not include the terminating +zero. It may not be valid for any other type of control, including +V4L2_CTRL_TYPE_INTEGER64 controls. Note that this is a +signed value. + + + __s32 + maximum + Maximum value, inclusive. This field gives an upper +bound for V4L2_CTRL_TYPE_INTEGER controls and the +highest valid index for V4L2_CTRL_TYPE_MENU +controls. For V4L2_CTRL_TYPE_BITMASK controls it is the +set of usable bits. +For V4L2_CTRL_TYPE_STRING controls the maximum value +gives the maximum length of the string. This length does not include the terminating +zero. It may not be valid for any other type of control, including +V4L2_CTRL_TYPE_INTEGER64 controls. Note that this is a +signed value. + + + __s32 + step + This field gives a step size for +V4L2_CTRL_TYPE_INTEGER controls. For +V4L2_CTRL_TYPE_STRING controls this field refers to +the string length that has to be a multiple of this step size. +It may not be valid for any other type of control, including +V4L2_CTRL_TYPE_INTEGER64 +controls.Generally drivers should not scale hardware +control values. It may be necessary for example when the +name or id imply +a particular unit and the hardware actually accepts only multiples of +said unit. If so, drivers must take care values are properly rounded +when scaling, such that errors will not accumulate on repeated +read-write cycles.This field gives the smallest change of +an integer control actually affecting hardware. Often the information +is needed when the user can change controls by keyboard or GUI +buttons, rather than a slider. When for example a hardware register +accepts values 0-511 and the driver reports 0-65535, step should be +128.Note that although signed, the step value is supposed to +be always positive. + + + __s32 + default_value + The default value of a +V4L2_CTRL_TYPE_INTEGER, +_BOOLEAN or _MENU control. +Not valid for other types of controls. Drivers reset controls only +when the driver is loaded, not later, in particular not when the +func-open; is called. + + + __u32 + flags + Control flags, see . + + + __u32 + reserved[2] + Reserved for future extensions. Drivers must set +the array to zero. + + + +
+ + + struct <structname>v4l2_querymenu</structname> + + &cs-str; + + + __u32 + + id + Identifies the control, set by the application +from the respective &v4l2-queryctrl; +id. + + + __u32 + + index + Index of the menu item, starting at zero, set by + the application. + + + union + + + + + + + __u8 + name[32] + Name of the menu item, a NUL-terminated ASCII +string. This information is intended for the user. This field is valid +for V4L2_CTRL_FLAG_MENU type controls. + + + + __s64 + value + + Value of the integer menu item. This field is valid for + V4L2_CTRL_FLAG_INTEGER_MENU type + controls. + + + + __u32 + + reserved + Reserved for future extensions. Drivers must set +the array to zero. + + + +
+ + + enum v4l2_ctrl_type + + + + + + + + + Type + minimum + step + maximum + Description + + + + + V4L2_CTRL_TYPE_INTEGER + any + any + any + An integer-valued control ranging from minimum to +maximum inclusive. The step value indicates the increment between +values which are actually different on the hardware. + + + V4L2_CTRL_TYPE_BOOLEAN + 0 + 1 + 1 + A boolean-valued control. Zero corresponds to +"disabled", and one means "enabled". + + + V4L2_CTRL_TYPE_MENU + ≥ 0 + 1 + N-1 + The control has a menu of N choices. The names of +the menu items can be enumerated with the +VIDIOC_QUERYMENU ioctl. + + + V4L2_CTRL_TYPE_INTEGER_MENU + ≥ 0 + 1 + N-1 + + The control has a menu of N choices. The values of the + menu items can be enumerated with the + VIDIOC_QUERYMENU ioctl. This is + similar to V4L2_CTRL_TYPE_MENU + except that instead of strings, the menu items are + signed 64-bit integers. + + + + V4L2_CTRL_TYPE_BITMASK + 0 + n/a + any + A bitmask field. The maximum value is the set of bits that can +be used, all other bits are to be 0. The maximum value is interpreted as a __u32, +allowing the use of bit 31 in the bitmask. + + + V4L2_CTRL_TYPE_BUTTON + 0 + 0 + 0 + A control which performs an action when set. +Drivers must ignore the value passed with +VIDIOC_S_CTRL and return an &EINVAL; on a +VIDIOC_G_CTRL attempt. + + + V4L2_CTRL_TYPE_INTEGER64 + n/a + n/a + n/a + A 64-bit integer valued control. Minimum, maximum +and step size cannot be queried. + + + V4L2_CTRL_TYPE_STRING + ≥ 0 + ≥ 1 + ≥ 0 + The minimum and maximum string lengths. The step size +means that the string must be (minimum + N * step) characters long for +N ≥ 0. These lengths do not include the terminating zero, so in order to +pass a string of length 8 to &VIDIOC-S-EXT-CTRLS; you need to set the +size field of &v4l2-ext-control; to 9. For &VIDIOC-G-EXT-CTRLS; you can +set the size field to maximum + 1. +Which character encoding is used will depend on the string control itself and +should be part of the control documentation. + + + V4L2_CTRL_TYPE_CTRL_CLASS + n/a + n/a + n/a + This is not a control. When +VIDIOC_QUERYCTRL is called with a control ID +equal to a control class code (see ) + 1, the +ioctl returns the name of the control class and this control type. +Older drivers which do not support this feature return an +&EINVAL;. + + + +
+ + + Control Flags + + &cs-def; + + + V4L2_CTRL_FLAG_DISABLED + 0x0001 + This control is permanently disabled and should be +ignored by the application. Any attempt to change the control will +result in an &EINVAL;. + + + V4L2_CTRL_FLAG_GRABBED + 0x0002 + This control is temporarily unchangeable, for +example because another application took over control of the +respective resource. Such controls may be displayed specially in a +user interface. Attempts to change the control may result in an +&EBUSY;. + + + V4L2_CTRL_FLAG_READ_ONLY + 0x0004 + This control is permanently readable only. Any +attempt to change the control will result in an &EINVAL;. + + + V4L2_CTRL_FLAG_UPDATE + 0x0008 + A hint that changing this control may affect the +value of other controls within the same control class. Applications +should update their user interface accordingly. + + + V4L2_CTRL_FLAG_INACTIVE + 0x0010 + This control is not applicable to the current +configuration and should be displayed accordingly in a user interface. +For example the flag may be set on a MPEG audio level 2 bitrate +control when MPEG audio encoding level 1 was selected with another +control. + + + V4L2_CTRL_FLAG_SLIDER + 0x0020 + A hint that this control is best represented as a +slider-like element in a user interface. + + + V4L2_CTRL_FLAG_WRITE_ONLY + 0x0040 + This control is permanently writable only. Any +attempt to read the control will result in an &EACCES; error code. This +flag is typically present for relative controls or action controls where +writing a value will cause the device to carry out a given action +(⪚ motor control) but no meaningful value can be returned. + + + V4L2_CTRL_FLAG_VOLATILE + 0x0080 + This control is volatile, which means that the value of the control +changes continuously. A typical example would be the current gain value if the device +is in auto-gain mode. In such a case the hardware calculates the gain value based on +the lighting conditions which can change over time. Note that setting a new value for +a volatile control will have no effect. The new value will just be ignored. + + + +
+ + + + &return-value; + + + + EINVAL + + The &v4l2-queryctrl; id +is invalid. The &v4l2-querymenu; id is +invalid or index is out of range (less than +minimum or greater than maximum) +or this particular menu item is not supported by the driver. + + + + EACCES + + An attempt was made to read a write-only control. + + + + + diff --git a/Documentation/DocBook/media/v4l/vidioc-querystd.xml b/Documentation/DocBook/media/v4l/vidioc-querystd.xml new file mode 100644 index 00000000..fe80a183 --- /dev/null +++ b/Documentation/DocBook/media/v4l/vidioc-querystd.xml @@ -0,0 +1,74 @@ + + + ioctl VIDIOC_QUERYSTD + &manvol; + + + + VIDIOC_QUERYSTD + Sense the video standard received by the current +input + + + + + + int ioctl + int fd + int request + v4l2_std_id *argp + + + + + + Arguments + + + + fd + + &fd; + + + + request + + VIDIOC_QUERYSTD + + + + argp + + + + + + + + + Description + + The hardware may be able to detect the current video +standard automatically. To do so, applications call +VIDIOC_QUERYSTD with a pointer to a &v4l2-std-id; type. The +driver stores here a set of candidates, this can be a single flag or a +set of supported standards if for example the hardware can only +distinguish between 50 and 60 Hz systems. When detection is not +possible or fails, the set must contain all standards supported by the +current video input or output. + + + + + &return-value; + + + ENODATA + + Standard video timings are not supported for this input or output. + + + + + diff --git a/Documentation/DocBook/media/v4l/vidioc-reqbufs.xml b/Documentation/DocBook/media/v4l/vidioc-reqbufs.xml new file mode 100644 index 00000000..78a06a9a --- /dev/null +++ b/Documentation/DocBook/media/v4l/vidioc-reqbufs.xml @@ -0,0 +1,137 @@ + + + ioctl VIDIOC_REQBUFS + &manvol; + + + + VIDIOC_REQBUFS + Initiate Memory Mapping or User Pointer I/O + + + + + + int ioctl + int fd + int request + struct v4l2_requestbuffers *argp + + + + + + Arguments + + + + fd + + &fd; + + + + request + + VIDIOC_REQBUFS + + + + argp + + + + + + + + + Description + +This ioctl is used to initiate memory mapped, +user pointer or DMABUF based I/O. Memory mapped buffers are located in +device memory and must be allocated with this ioctl before they can be mapped +into the application's address space. User buffers are allocated by +applications themselves, and this ioctl is merely used to switch the driver +into user pointer I/O mode and to setup some internal structures. +Similarly, DMABUF buffers are allocated by applications through a device +driver, and this ioctl only configures the driver into DMABUF I/O mode without +performing any direct allocation. + + To allocate device buffers applications initialize all fields of the +v4l2_requestbuffers structure. They set the +type field to the respective stream or buffer type, +the count field to the desired number of buffers, +memory must be set to the requested I/O method and +the reserved array must be zeroed. When the ioctl is +called with a pointer to this structure the driver will attempt to allocate the +requested number of buffers and it stores the actual number allocated in the +count field. It can be smaller than the number +requested, even zero, when the driver runs out of free memory. A larger number +is also possible when the driver requires more buffers to function correctly. +For example video output requires at least two buffers, one displayed and one +filled by the application. + When the I/O method is not supported the ioctl +returns an &EINVAL;. + + Applications can call VIDIOC_REQBUFS +again to change the number of buffers, however this cannot succeed +when any buffers are still mapped. A count +value of zero frees all buffers, after aborting or finishing any DMA +in progress, an implicit &VIDIOC-STREAMOFF;. + + + struct <structname>v4l2_requestbuffers</structname> + + &cs-str; + + + __u32 + count + The number of buffers requested or granted. + + + __u32 + type + Type of the stream or buffers, this is the same +as the &v4l2-format; type field. See for valid values. + + + __u32 + memory + Applications set this field to +V4L2_MEMORY_MMAP, +V4L2_MEMORY_DMABUF or +V4L2_MEMORY_USERPTR. See . + + + __u32 + reserved[2] + A place holder for future extensions. This array should +be zeroed by applications. + + + +
+ + + + &return-value; + + + + EINVAL + + The buffer type (type field) or the +requested I/O method (memory) is not +supported. + + + + + diff --git a/Documentation/DocBook/media/v4l/vidioc-s-hw-freq-seek.xml b/Documentation/DocBook/media/v4l/vidioc-s-hw-freq-seek.xml new file mode 100644 index 00000000..5b379e75 --- /dev/null +++ b/Documentation/DocBook/media/v4l/vidioc-s-hw-freq-seek.xml @@ -0,0 +1,184 @@ + + + ioctl VIDIOC_S_HW_FREQ_SEEK + &manvol; + + + + VIDIOC_S_HW_FREQ_SEEK + Perform a hardware frequency seek + + + + + + int ioctl + int fd + int request + struct v4l2_hw_freq_seek +*argp + + + + + + Arguments + + + + fd + + &fd; + + + + request + + VIDIOC_S_HW_FREQ_SEEK + + + + argp + + + + + + + + + Description + + Start a hardware frequency seek from the current frequency. +To do this applications initialize the tuner, +type, seek_upward, +wrap_around, spacing, +rangelow and rangehigh +fields, and zero out the reserved array of a +&v4l2-hw-freq-seek; and call the VIDIOC_S_HW_FREQ_SEEK +ioctl with a pointer to this structure. + + The rangelow and +rangehigh fields can be set to a non-zero value to +tell the driver to search a specific band. If the &v4l2-tuner; +capability field has the +V4L2_TUNER_CAP_HWSEEK_PROG_LIM flag set, these values +must fall within one of the bands returned by &VIDIOC-ENUM-FREQ-BANDS;. If +the V4L2_TUNER_CAP_HWSEEK_PROG_LIM flag is not set, +then these values must exactly match those of one of the bands returned by +&VIDIOC-ENUM-FREQ-BANDS;. If the current frequency of the tuner does not fall +within the selected band it will be clamped to fit in the band before the +seek is started. + + If an error is returned, then the original frequency will + be restored. + + This ioctl is supported if the V4L2_CAP_HW_FREQ_SEEK capability is set. + + If this ioctl is called from a non-blocking filehandle, then &EAGAIN; is + returned and no seek takes place. + + + struct <structname>v4l2_hw_freq_seek</structname> + + &cs-str; + + + __u32 + tuner + The tuner index number. This is the +same value as in the &v4l2-input; tuner +field and the &v4l2-tuner; index field. + + + __u32 + type + The tuner type. This is the same value as in the +&v4l2-tuner; type field. See + + + __u32 + seek_upward + If non-zero, seek upward from the current frequency, else seek downward. + + + __u32 + wrap_around + If non-zero, wrap around when at the end of the frequency range, else stop seeking. + The &v4l2-tuner; capability field will tell you what the + hardware supports. + + + + __u32 + spacing + If non-zero, defines the hardware seek resolution in Hz. The driver selects the nearest value that is supported by the device. If spacing is zero a reasonable default value is used. + + + __u32 + rangelow + If non-zero, the lowest tunable frequency of the band to +search in units of 62.5 kHz, or if the &v4l2-tuner; +capability field has the +V4L2_TUNER_CAP_LOW flag set, in units of 62.5 Hz. +If rangelow is zero a reasonable default value +is used. + + + __u32 + rangehigh + If non-zero, the highest tunable frequency of the band to +search in units of 62.5 kHz, or if the &v4l2-tuner; +capability field has the +V4L2_TUNER_CAP_LOW flag set, in units of 62.5 Hz. +If rangehigh is zero a reasonable default value +is used. + + + __u32 + reserved[5] + Reserved for future extensions. Applications + must set the array to zero. + + + +
+ + + + &return-value; + + + + EINVAL + + The tuner index is out of +bounds, the wrap_around value is not supported or +one of the values in the type, +rangelow or rangehigh +fields is wrong. + + + + EAGAIN + + Attempted to call VIDIOC_S_HW_FREQ_SEEK + with the filehandle in non-blocking mode. + + + + ENODATA + + The hardware seek found no channels. + + + + EBUSY + + Another hardware seek is already in progress. + + + + + diff --git a/Documentation/DocBook/media/v4l/vidioc-streamon.xml b/Documentation/DocBook/media/v4l/vidioc-streamon.xml new file mode 100644 index 00000000..716ea15e --- /dev/null +++ b/Documentation/DocBook/media/v4l/vidioc-streamon.xml @@ -0,0 +1,112 @@ + + + ioctl VIDIOC_STREAMON, VIDIOC_STREAMOFF + &manvol; + + + + VIDIOC_STREAMON + VIDIOC_STREAMOFF + Start or stop streaming I/O + + + + + + int ioctl + int fd + int request + const int *argp + + + + + + Arguments + + + + fd + + &fd; + + + + request + + VIDIOC_STREAMON, VIDIOC_STREAMOFF + + + + argp + + + + + + + + + Description + + The VIDIOC_STREAMON and +VIDIOC_STREAMOFF ioctl start and stop the capture +or output process during streaming (memory +mapping or user pointer) I/O. + + Specifically the capture hardware is disabled and no input +buffers are filled (if there are any empty buffers in the incoming +queue) until VIDIOC_STREAMON has been called. +Accordingly the output hardware is disabled, no video signal is +produced until VIDIOC_STREAMON has been called. +The ioctl will succeed only when at least one output buffer is in the +incoming queue. + + The VIDIOC_STREAMOFF ioctl, apart of +aborting or finishing any DMA in progress, unlocks any user pointer +buffers locked in physical memory, and it removes all buffers from the +incoming and outgoing queues. That means all images captured but not +dequeued yet will be lost, likewise all images enqueued for output but +not transmitted yet. I/O returns to the same state as after calling +&VIDIOC-REQBUFS; and can be restarted accordingly. + + Both ioctls take a pointer to an integer, the desired buffer or +stream type. This is the same as &v4l2-requestbuffers; +type. + + If VIDIOC_STREAMON is called when streaming +is already in progress, or if VIDIOC_STREAMOFF is called +when streaming is already stopped, then the ioctl does nothing and 0 is +returned. + + Note that applications can be preempted for unknown periods right +before or after the VIDIOC_STREAMON or +VIDIOC_STREAMOFF calls, there is no notion of +starting or stopping "now". Buffer timestamps can be used to +synchronize with other events. + + + + &return-value; + + + + EINVAL + + The buffertype is not supported, + or no buffers have been allocated (memory mapping) or enqueued + (output) yet. + + + + EPIPE + + The driver implements pad-level format configuration and + the pipeline configuration is invalid. + + + + + + diff --git a/Documentation/DocBook/media/v4l/vidioc-subdev-enum-frame-interval.xml b/Documentation/DocBook/media/v4l/vidioc-subdev-enum-frame-interval.xml new file mode 100644 index 00000000..2f8f4f0a --- /dev/null +++ b/Documentation/DocBook/media/v4l/vidioc-subdev-enum-frame-interval.xml @@ -0,0 +1,152 @@ + + + ioctl VIDIOC_SUBDEV_ENUM_FRAME_INTERVAL + &manvol; + + + + VIDIOC_SUBDEV_ENUM_FRAME_INTERVAL + Enumerate frame intervals + + + + + + int ioctl + int fd + int request + struct v4l2_subdev_frame_interval_enum * + argp + + + + + + Arguments + + + + fd + + &fd; + + + + request + + VIDIOC_SUBDEV_ENUM_FRAME_INTERVAL + + + + argp + + + + + + + + + Description + + + Experimental + This is an experimental + interface and may change in the future. + + + This ioctl lets applications enumerate available frame intervals on a + given sub-device pad. Frame intervals only makes sense for sub-devices that + can control the frame period on their own. This includes, for instance, + image sensors and TV tuners. + + For the common use case of image sensors, the frame intervals + available on the sub-device output pad depend on the frame format and size + on the same pad. Applications must thus specify the desired format and size + when enumerating frame intervals. + + To enumerate frame intervals applications initialize the + index, pad, + code, width and + height fields of + &v4l2-subdev-frame-interval-enum; and call the + VIDIOC_SUBDEV_ENUM_FRAME_INTERVAL ioctl with a pointer + to this structure. Drivers fill the rest of the structure or return + an &EINVAL; if one of the input fields is invalid. All frame intervals are + enumerable by beginning at index zero and incrementing by one until + EINVAL is returned. + + Available frame intervals may depend on the current 'try' formats + at other pads of the sub-device, as well as on the current active links. See + &VIDIOC-SUBDEV-G-FMT; for more information about the try formats. + + Sub-devices that support the frame interval enumeration ioctl should + implemented it on a single pad only. Its behaviour when supported on + multiple pads of the same sub-device is not defined. + + + struct <structname>v4l2_subdev_frame_interval_enum</structname> + + &cs-str; + + + __u32 + index + Number of the format in the enumeration, set by the + application. + + + __u32 + pad + Pad number as reported by the media controller API. + + + __u32 + code + The media bus format code, as defined in + . + + + __u32 + width + Frame width, in pixels. + + + __u32 + height + Frame height, in pixels. + + + &v4l2-fract; + interval + Period, in seconds, between consecutive video frames. + + + __u32 + reserved[9] + Reserved for future extensions. Applications and drivers must + set the array to zero. + + + +
+ + + + &return-value; + + + + EINVAL + + The &v4l2-subdev-frame-interval-enum; + pad references a non-existing pad, one of + the code, width + or height fields are invalid for the given + pad or the index field is out of bounds. + + + + + + diff --git a/Documentation/DocBook/media/v4l/vidioc-subdev-enum-frame-size.xml b/Documentation/DocBook/media/v4l/vidioc-subdev-enum-frame-size.xml new file mode 100644 index 00000000..79ce42b7 --- /dev/null +++ b/Documentation/DocBook/media/v4l/vidioc-subdev-enum-frame-size.xml @@ -0,0 +1,154 @@ + + + ioctl VIDIOC_SUBDEV_ENUM_FRAME_SIZE + &manvol; + + + + VIDIOC_SUBDEV_ENUM_FRAME_SIZE + Enumerate media bus frame sizes + + + + + + int ioctl + int fd + int request + struct v4l2_subdev_frame_size_enum * + argp + + + + + + Arguments + + + + fd + + &fd; + + + + request + + VIDIOC_SUBDEV_ENUM_FRAME_SIZE + + + + argp + + + + + + + + + Description + + + Experimental + This is an experimental + interface and may change in the future. + + + This ioctl allows applications to enumerate all frame sizes + supported by a sub-device on the given pad for the given media bus format. + Supported formats can be retrieved with the &VIDIOC-SUBDEV-ENUM-MBUS-CODE; + ioctl. + + To enumerate frame sizes applications initialize the + pad, code and + index fields of the + &v4l2-subdev-mbus-code-enum; and call the + VIDIOC_SUBDEV_ENUM_FRAME_SIZE ioctl with a pointer to + the structure. Drivers fill the minimum and maximum frame sizes or return + an &EINVAL; if one of the input parameters is invalid. + + Sub-devices that only support discrete frame sizes (such as most + sensors) will return one or more frame sizes with identical minimum and + maximum values. + + Not all possible sizes in given [minimum, maximum] ranges need to be + supported. For instance, a scaler that uses a fixed-point scaling ratio + might not be able to produce every frame size between the minimum and + maximum values. Applications must use the &VIDIOC-SUBDEV-S-FMT; ioctl to + try the sub-device for an exact supported frame size. + + Available frame sizes may depend on the current 'try' formats at other + pads of the sub-device, as well as on the current active links and the + current values of V4L2 controls. See &VIDIOC-SUBDEV-G-FMT; for more + information about try formats. + + + struct <structname>v4l2_subdev_frame_size_enum</structname> + + &cs-str; + + + __u32 + index + Number of the format in the enumeration, set by the + application. + + + __u32 + pad + Pad number as reported by the media controller API. + + + __u32 + code + The media bus format code, as defined in + . + + + __u32 + min_width + Minimum frame width, in pixels. + + + __u32 + max_width + Maximum frame width, in pixels. + + + __u32 + min_height + Minimum frame height, in pixels. + + + __u32 + max_height + Maximum frame height, in pixels. + + + __u32 + reserved[9] + Reserved for future extensions. Applications and drivers must + set the array to zero. + + + +
+ + + + &return-value; + + + + EINVAL + + The &v4l2-subdev-frame-size-enum; pad + references a non-existing pad, the code is + invalid for the given pad or the index + field is out of bounds. + + + + + diff --git a/Documentation/DocBook/media/v4l/vidioc-subdev-enum-mbus-code.xml b/Documentation/DocBook/media/v4l/vidioc-subdev-enum-mbus-code.xml new file mode 100644 index 00000000..a6b34324 --- /dev/null +++ b/Documentation/DocBook/media/v4l/vidioc-subdev-enum-mbus-code.xml @@ -0,0 +1,119 @@ + + + ioctl VIDIOC_SUBDEV_ENUM_MBUS_CODE + &manvol; + + + + VIDIOC_SUBDEV_ENUM_MBUS_CODE + Enumerate media bus formats + + + + + + int ioctl + int fd + int request + struct v4l2_subdev_mbus_code_enum * + argp + + + + + + Arguments + + + + fd + + &fd; + + + + request + + VIDIOC_SUBDEV_ENUM_MBUS_CODE + + + + argp + + + + + + + + + Description + + + Experimental + This is an experimental + interface and may change in the future. + + + To enumerate media bus formats available at a given sub-device pad + applications initialize the pad and + index fields of &v4l2-subdev-mbus-code-enum; and + call the VIDIOC_SUBDEV_ENUM_MBUS_CODE ioctl with a + pointer to this structure. Drivers fill the rest of the structure or return + an &EINVAL; if either the pad or + index are invalid. All media bus formats are + enumerable by beginning at index zero and incrementing by one until + EINVAL is returned. + + Available media bus formats may depend on the current 'try' formats + at other pads of the sub-device, as well as on the current active links. See + &VIDIOC-SUBDEV-G-FMT; for more information about the try formats. + + + struct <structname>v4l2_subdev_mbus_code_enum</structname> + + &cs-str; + + + __u32 + pad + Pad number as reported by the media controller API. + + + __u32 + index + Number of the format in the enumeration, set by the + application. + + + __u32 + code + The media bus format code, as defined in + . + + + __u32 + reserved[9] + Reserved for future extensions. Applications and drivers must + set the array to zero. + + + +
+ + + + &return-value; + + + + EINVAL + + The &v4l2-subdev-mbus-code-enum; pad + references a non-existing pad, or the index + field is out of bounds. + + + + + diff --git a/Documentation/DocBook/media/v4l/vidioc-subdev-g-crop.xml b/Documentation/DocBook/media/v4l/vidioc-subdev-g-crop.xml new file mode 100644 index 00000000..4cddd788 --- /dev/null +++ b/Documentation/DocBook/media/v4l/vidioc-subdev-g-crop.xml @@ -0,0 +1,158 @@ + + + ioctl VIDIOC_SUBDEV_G_CROP, VIDIOC_SUBDEV_S_CROP + &manvol; + + + + VIDIOC_SUBDEV_G_CROP + VIDIOC_SUBDEV_S_CROP + Get or set the crop rectangle on a subdev pad + + + + + + int ioctl + int fd + int request + struct v4l2_subdev_crop *argp + + + + + int ioctl + int fd + int request + const struct v4l2_subdev_crop *argp + + + + + + Arguments + + + + fd + + &fd; + + + + request + + VIDIOC_SUBDEV_G_CROP, VIDIOC_SUBDEV_S_CROP + + + + argp + + + + + + + + + Description + + + Obsolete + + This is an obsolete + interface and may be removed in the future. It is superseded by + the selection + API. + + + To retrieve the current crop rectangle applications set the + pad field of a &v4l2-subdev-crop; to the + desired pad number as reported by the media API and the + which field to + V4L2_SUBDEV_FORMAT_ACTIVE. They then call the + VIDIOC_SUBDEV_G_CROP ioctl with a pointer to this + structure. The driver fills the members of the rect + field or returns &EINVAL; if the input arguments are invalid, or if cropping + is not supported on the given pad. + + To change the current crop rectangle applications set both the + pad and which fields + and all members of the rect field. They then call + the VIDIOC_SUBDEV_S_CROP ioctl with a pointer to this + structure. The driver verifies the requested crop rectangle, adjusts it + based on the hardware capabilities and configures the device. Upon return + the &v4l2-subdev-crop; contains the current format as would be returned + by a VIDIOC_SUBDEV_G_CROP call. + + Applications can query the device capabilities by setting the + which to + V4L2_SUBDEV_FORMAT_TRY. When set, 'try' crop + rectangles are not applied to the device by the driver, but are mangled + exactly as active crop rectangles and stored in the sub-device file handle. + Two applications querying the same sub-device would thus not interact with + each other. + + Drivers must not return an error solely because the requested crop + rectangle doesn't match the device capabilities. They must instead modify + the rectangle to match what the hardware can provide. The modified format + should be as close as possible to the original request. + + + struct <structname>v4l2_subdev_crop</structname> + + &cs-str; + + + __u32 + pad + Pad number as reported by the media framework. + + + __u32 + which + Crop rectangle to get or set, from + &v4l2-subdev-format-whence;. + + + &v4l2-rect; + rect + Crop rectangle boundaries, in pixels. + + + __u32 + reserved[8] + Reserved for future extensions. Applications and drivers must + set the array to zero. + + + +
+ + + + &return-value; + + + + EBUSY + + The crop rectangle can't be changed because the pad is currently + busy. This can be caused, for instance, by an active video stream on + the pad. The ioctl must not be retried without performing another + action to fix the problem first. Only returned by + VIDIOC_SUBDEV_S_CROP + + + + EINVAL + + The &v4l2-subdev-crop; pad + references a non-existing pad, the which + field references a non-existing format, or cropping is not supported + on the given subdev pad. + + + + + diff --git a/Documentation/DocBook/media/v4l/vidioc-subdev-g-edid.xml b/Documentation/DocBook/media/v4l/vidioc-subdev-g-edid.xml new file mode 100644 index 00000000..bbd18f0e --- /dev/null +++ b/Documentation/DocBook/media/v4l/vidioc-subdev-g-edid.xml @@ -0,0 +1,152 @@ + + + ioctl VIDIOC_SUBDEV_G_EDID, VIDIOC_SUBDEV_S_EDID + &manvol; + + + + VIDIOC_SUBDEV_G_EDID + VIDIOC_SUBDEV_S_EDID + Get or set the EDID of a video receiver/transmitter + + + + + + int ioctl + int fd + int request + struct v4l2_subdev_edid *argp + + + + + int ioctl + int fd + int request + const struct v4l2_subdev_edid *argp + + + + + + Arguments + + + + fd + + &fd; + + + + request + + VIDIOC_SUBDEV_G_EDID, VIDIOC_SUBDEV_S_EDID + + + + argp + + + + + + + + + Description + These ioctls can be used to get or set an EDID associated with an input pad + from a receiver or an output pad of a transmitter subdevice. + + To get the EDID data the application has to fill in the pad, + start_block, blocks and edid + fields and call VIDIOC_SUBDEV_G_EDID. The current EDID from block + start_block and of size blocks + will be placed in the memory edid points to. The edid + pointer must point to memory at least blocks * 128 bytes + large (the size of one block is 128 bytes). + + If there are fewer blocks than specified, then the driver will set blocks + to the actual number of blocks. If there are no EDID blocks available at all, then the error code + ENODATA is set. + + If blocks have to be retrieved from the sink, then this call will block until they + have been read. + + To set the EDID blocks of a receiver the application has to fill in the pad, + blocks and edid fields and set + start_block to 0. It is not possible to set part of an EDID, + it is always all or nothing. Setting the EDID data is only valid for receivers as it makes + no sense for a transmitter. + + The driver assumes that the full EDID is passed in. If there are more EDID blocks than + the hardware can handle then the EDID is not written, but instead the error code E2BIG is set + and blocks is set to the maximum that the hardware supports. + If start_block is any + value other than 0 then the error code EINVAL is set. + + To disable an EDID you set blocks to 0. Depending on the + hardware this will drive the hotplug pin low and/or block the source from reading the EDID + data in some way. In any case, the end result is the same: the EDID is no longer available. + + + + struct <structname>v4l2_subdev_edid</structname> + + &cs-str; + + + __u32 + pad + Pad for which to get/set the EDID blocks. + + + __u32 + start_block + Read the EDID from starting with this block. Must be 0 when setting + the EDID. + + + __u32 + blocks + The number of blocks to get or set. Must be less or equal to 256 (the + maximum number of blocks as defined by the standard). When you set the EDID and + blocks is 0, then the EDID is disabled or erased. + + + __u8 * + edid + Pointer to memory that contains the EDID. The minimum size is + blocks * 128. + + + __u32 + reserved[5] + Reserved for future extensions. Applications and drivers must + set the array to zero. + + + +
+ + + + &return-value; + + + + ENODATA + + The EDID data is not available. + + + + E2BIG + + The EDID data you provided is more than the hardware can handle. + + + + + diff --git a/Documentation/DocBook/media/v4l/vidioc-subdev-g-fmt.xml b/Documentation/DocBook/media/v4l/vidioc-subdev-g-fmt.xml new file mode 100644 index 00000000..a67cde6f --- /dev/null +++ b/Documentation/DocBook/media/v4l/vidioc-subdev-g-fmt.xml @@ -0,0 +1,183 @@ + + + ioctl VIDIOC_SUBDEV_G_FMT, VIDIOC_SUBDEV_S_FMT + &manvol; + + + + VIDIOC_SUBDEV_G_FMT + VIDIOC_SUBDEV_S_FMT + Get or set the data format on a subdev pad + + + + + + int ioctl + int fd + int request + struct v4l2_subdev_format *argp + + + + + + + Arguments + + + + fd + + &fd; + + + + request + + VIDIOC_SUBDEV_G_FMT, VIDIOC_SUBDEV_S_FMT + + + + argp + + + + + + + + + Description + + + Experimental + This is an experimental + interface and may change in the future. + + + These ioctls are used to negotiate the frame format at specific + subdev pads in the image pipeline. + + To retrieve the current format applications set the + pad field of a &v4l2-subdev-format; to the + desired pad number as reported by the media API and the + which field to + V4L2_SUBDEV_FORMAT_ACTIVE. When they call the + VIDIOC_SUBDEV_G_FMT ioctl with a pointer to this + structure the driver fills the members of the format + field. + + To change the current format applications set both the + pad and which fields + and all members of the format field. When they + call the VIDIOC_SUBDEV_S_FMT ioctl with a pointer to this + structure the driver verifies the requested format, adjusts it based on the + hardware capabilities and configures the device. Upon return the + &v4l2-subdev-format; contains the current format as would be returned by a + VIDIOC_SUBDEV_G_FMT call. + + Applications can query the device capabilities by setting the + which to + V4L2_SUBDEV_FORMAT_TRY. When set, 'try' formats are not + applied to the device by the driver, but are changed exactly as active + formats and stored in the sub-device file handle. Two applications querying + the same sub-device would thus not interact with each other. + + For instance, to try a format at the output pad of a sub-device, + applications would first set the try format at the sub-device input with the + VIDIOC_SUBDEV_S_FMT ioctl. They would then either + retrieve the default format at the output pad with the + VIDIOC_SUBDEV_G_FMT ioctl, or set the desired output + pad format with the VIDIOC_SUBDEV_S_FMT ioctl and check + the returned value. + + Try formats do not depend on active formats, but can depend on the + current links configuration or sub-device controls value. For instance, a + low-pass noise filter might crop pixels at the frame boundaries, modifying + its output frame size. + + Drivers must not return an error solely because the requested format + doesn't match the device capabilities. They must instead modify the format + to match what the hardware can provide. The modified format should be as + close as possible to the original request. + + + struct <structname>v4l2_subdev_format</structname> + + &cs-str; + + + __u32 + pad + Pad number as reported by the media controller API. + + + __u32 + which + Format to modified, from &v4l2-subdev-format-whence;. + + + &v4l2-mbus-framefmt; + format + Definition of an image format, see for details. + + + __u32 + reserved[8] + Reserved for future extensions. Applications and drivers must + set the array to zero. + + + +
+ + + enum <structname>v4l2_subdev_format_whence</structname> + + &cs-def; + + + V4L2_SUBDEV_FORMAT_TRY + 0 + Try formats, used for querying device capabilities. + + + V4L2_SUBDEV_FORMAT_ACTIVE + 1 + Active formats, applied to the hardware. + + + +
+ + + + &return-value; + + + + EBUSY + + The format can't be changed because the pad is currently busy. + This can be caused, for instance, by an active video stream on the + pad. The ioctl must not be retried without performing another action + to fix the problem first. Only returned by + VIDIOC_SUBDEV_S_FMT + + + + EINVAL + + The &v4l2-subdev-format; pad + references a non-existing pad, or the which + field references a non-existing format. + + + + + + &return-value; + + diff --git a/Documentation/DocBook/media/v4l/vidioc-subdev-g-frame-interval.xml b/Documentation/DocBook/media/v4l/vidioc-subdev-g-frame-interval.xml new file mode 100644 index 00000000..0bc3ea22 --- /dev/null +++ b/Documentation/DocBook/media/v4l/vidioc-subdev-g-frame-interval.xml @@ -0,0 +1,141 @@ + + + ioctl VIDIOC_SUBDEV_G_FRAME_INTERVAL, VIDIOC_SUBDEV_S_FRAME_INTERVAL + &manvol; + + + + VIDIOC_SUBDEV_G_FRAME_INTERVAL + VIDIOC_SUBDEV_S_FRAME_INTERVAL + Get or set the frame interval on a subdev pad + + + + + + int ioctl + int fd + int request + struct v4l2_subdev_frame_interval *argp + + + + + + + Arguments + + + + fd + + &fd; + + + + request + + VIDIOC_SUBDEV_G_FRAME_INTERVAL, VIDIOC_SUBDEV_S_FRAME_INTERVAL + + + + argp + + + + + + + + + Description + + + Experimental + This is an experimental + interface and may change in the future. + + + These ioctls are used to get and set the frame interval at specific + subdev pads in the image pipeline. The frame interval only makes sense for + sub-devices that can control the frame period on their own. This includes, + for instance, image sensors and TV tuners. Sub-devices that don't support + frame intervals must not implement these ioctls. + + To retrieve the current frame interval applications set the + pad field of a &v4l2-subdev-frame-interval; to + the desired pad number as reported by the media controller API. When they + call the VIDIOC_SUBDEV_G_FRAME_INTERVAL ioctl with a + pointer to this structure the driver fills the members of the + interval field. + + To change the current frame interval applications set both the + pad field and all members of the + interval field. When they call the + VIDIOC_SUBDEV_S_FRAME_INTERVAL ioctl with a pointer to + this structure the driver verifies the requested interval, adjusts it based + on the hardware capabilities and configures the device. Upon return the + &v4l2-subdev-frame-interval; contains the current frame interval as would be + returned by a VIDIOC_SUBDEV_G_FRAME_INTERVAL call. + + + Drivers must not return an error solely because the requested interval + doesn't match the device capabilities. They must instead modify the interval + to match what the hardware can provide. The modified interval should be as + close as possible to the original request. + + Sub-devices that support the frame interval ioctls should implement + them on a single pad only. Their behaviour when supported on multiple pads + of the same sub-device is not defined. + + + struct <structname>v4l2_subdev_frame_interval</structname> + + &cs-str; + + + __u32 + pad + Pad number as reported by the media controller API. + + + &v4l2-fract; + interval + Period, in seconds, between consecutive video frames. + + + __u32 + reserved[9] + Reserved for future extensions. Applications and drivers must + set the array to zero. + + + +
+ + + + &return-value; + + + + EBUSY + + The frame interval can't be changed because the pad is currently + busy. This can be caused, for instance, by an active video stream on + the pad. The ioctl must not be retried without performing another + action to fix the problem first. Only returned by + VIDIOC_SUBDEV_S_FRAME_INTERVAL + + + + EINVAL + + The &v4l2-subdev-frame-interval; pad + references a non-existing pad, or the pad doesn't support frame + intervals. + + + + + diff --git a/Documentation/DocBook/media/v4l/vidioc-subdev-g-selection.xml b/Documentation/DocBook/media/v4l/vidioc-subdev-g-selection.xml new file mode 100644 index 00000000..1ba9e999 --- /dev/null +++ b/Documentation/DocBook/media/v4l/vidioc-subdev-g-selection.xml @@ -0,0 +1,165 @@ + + + ioctl VIDIOC_SUBDEV_G_SELECTION, VIDIOC_SUBDEV_S_SELECTION + &manvol; + + + + VIDIOC_SUBDEV_G_SELECTION + VIDIOC_SUBDEV_S_SELECTION + Get or set selection rectangles on a subdev pad + + + + + + int ioctl + int fd + int request + struct v4l2_subdev_selection *argp + + + + + + Arguments + + + + fd + + &fd; + + + + request + + VIDIOC_SUBDEV_G_SELECTION, VIDIOC_SUBDEV_S_SELECTION + + + + argp + + + + + + + + + Description + + + Experimental + This is an experimental + interface and may change in the future. + + + The selections are used to configure various image + processing functionality performed by the subdevs which affect the + image size. This currently includes cropping, scaling and + composition. + + The selection API replaces the old subdev crop API. All + the function of the crop API, and more, are supported by the + selections API. + + See for + more information on how each selection target affects the image + processing pipeline inside the subdevice. + + + Types of selection targets + + There are two types of selection targets: actual and bounds. The + actual targets are the targets which configure the hardware. The BOUNDS + target will return a rectangle that contain all possible actual + rectangles. + + + + Discovering supported features + + To discover which targets are supported, the user can + perform VIDIOC_SUBDEV_G_SELECTION on them. + Any unsupported target will return + EINVAL. + + Selection targets and flags are documented in . + + + struct <structname>v4l2_subdev_selection</structname> + + &cs-str; + + + __u32 + which + Active or try selection, from + &v4l2-subdev-format-whence;. + + + __u32 + pad + Pad number as reported by the media framework. + + + __u32 + target + Target selection rectangle. See + . + + + __u32 + flags + Flags. See + . + + + &v4l2-rect; + rect + Selection rectangle, in pixels. + + + __u32 + reserved[8] + Reserved for future extensions. Applications and drivers must + set the array to zero. + + + +
+ + + + + + &return-value; + + + + EBUSY + + The selection rectangle can't be changed because the + pad is currently busy. This can be caused, for instance, by + an active video stream on the pad. The ioctl must not be + retried without performing another action to fix the problem + first. Only returned by + VIDIOC_SUBDEV_S_SELECTION + + + + EINVAL + + The &v4l2-subdev-selection; + pad references a non-existing + pad, the which field references a + non-existing format, or the selection target is not + supported on the given subdev pad. + + + + + diff --git a/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml b/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml new file mode 100644 index 00000000..5c70b616 --- /dev/null +++ b/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml @@ -0,0 +1,206 @@ + + + ioctl VIDIOC_SUBSCRIBE_EVENT, VIDIOC_UNSUBSCRIBE_EVENT + &manvol; + + + + VIDIOC_SUBSCRIBE_EVENT, VIDIOC_UNSUBSCRIBE_EVENT + Subscribe or unsubscribe event + + + + + + int ioctl + int fd + int request + struct v4l2_event_subscription +*argp + + + + + + Arguments + + + + fd + + &fd; + + + + request + + VIDIOC_SUBSCRIBE_EVENT, VIDIOC_UNSUBSCRIBE_EVENT + + + + argp + + + + + + + + + Description + + Subscribe or unsubscribe V4L2 event. Subscribed events are + dequeued by using the &VIDIOC-DQEVENT; ioctl. + + + struct <structname>v4l2_event_subscription</structname> + + &cs-str; + + + __u32 + type + Type of the event. + + + __u32 + id + ID of the event source. If there is no ID associated with + the event source, then set this to 0. Whether or not an event + needs an ID depends on the event type. + + + __u32 + flags + Event flags, see . + + + __u32 + reserved[5] + Reserved for future extensions. Drivers and applications + must set the array to zero. + + + +
+ + + Event Types + + &cs-def; + + + V4L2_EVENT_ALL + 0 + All events. V4L2_EVENT_ALL is valid only for + VIDIOC_UNSUBSCRIBE_EVENT for unsubscribing all events at once. + + + + V4L2_EVENT_VSYNC + 1 + This event is triggered on the vertical sync. + This event has a &v4l2-event-vsync; associated with it. + + + + V4L2_EVENT_EOS + 2 + This event is triggered when the end of a stream is reached. + This is typically used with MPEG decoders to report to the application + when the last of the MPEG stream has been decoded. + + + + V4L2_EVENT_CTRL + 3 + This event requires that the id + matches the control ID from which you want to receive events. + This event is triggered if the control's value changes, if a + button control is pressed or if the control's flags change. + This event has a &v4l2-event-ctrl; associated with it. This struct + contains much of the same information as &v4l2-queryctrl; and + &v4l2-control;. + + If the event is generated due to a call to &VIDIOC-S-CTRL; or + &VIDIOC-S-EXT-CTRLS;, then the event will not be sent to + the file handle that called the ioctl function. This prevents + nasty feedback loops. If you do want to get the + event, then set the V4L2_EVENT_SUB_FL_ALLOW_FEEDBACK + flag. + + + This event type will ensure that no information is lost when + more events are raised than there is room internally. In that + case the &v4l2-event-ctrl; of the second-oldest event is kept, + but the changes field of the + second-oldest event is ORed with the changes + field of the oldest event. + + + + V4L2_EVENT_FRAME_SYNC + 4 + + Triggered immediately when the reception of a + frame has begun. This event has a + &v4l2-event-frame-sync; associated with it. + + If the hardware needs to be stopped in the case of a + buffer underrun it might not be able to generate this event. + In such cases the frame_sequence + field in &v4l2-event-frame-sync; will not be incremented. This + causes two consecutive frame sequence numbers to have n times + frame interval in between them. + + + + V4L2_EVENT_PRIVATE_START + 0x08000000 + Base event number for driver-private events. + + + +
+ + + Event Flags + + &cs-def; + + + V4L2_EVENT_SUB_FL_SEND_INITIAL + 0x0001 + When this event is subscribed an initial event will be sent + containing the current status. This only makes sense for events + that are triggered by a status change such as V4L2_EVENT_CTRL. + Other events will ignore this flag. + + + V4L2_EVENT_SUB_FL_ALLOW_FEEDBACK + 0x0002 + If set, then events directly caused by an ioctl will also be sent to + the filehandle that called that ioctl. For example, changing a control using + &VIDIOC-S-CTRL; will cause a V4L2_EVENT_CTRL to be sent back to that same + filehandle. Normally such events are suppressed to prevent feedback loops + where an application changes a control to a one value and then another, and + then receives an event telling it that that control has changed to the first + value. + + Since it can't tell whether that event was caused by another application + or by the &VIDIOC-S-CTRL; call it is hard to decide whether to set the + control to the value in the event, or ignore it. + + Think carefully when you set this flag so you won't get into situations + like that. + + + + +
+ + + + &return-value; + + -- cgit v1.2.3