Fixes a regression in VIDIOC_QUERYMENU introduced when the __s64 value
field was added to the union. On a 64-bit system this will change the
size of this v4l2_querymenu structure from 44 to 48 bytes, thus
breaking the ABI. By adding the packed attribute it is working again.

Tested on both 64 and 32 bit systems.
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Acked-by: NSakari Ailus <sakari.ailus@iki.fi>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Create a new control type called V4L2_CTRL_TYPE_INTEGER_MENU. Integer menu
controls are just like menu controls but the menu items are 64-bit integers
rather than strings.
Signed-off-by: NSakari Ailus <sakari.ailus@iki.fi>
Acked-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Tested-by: NSylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Make the VIDIOC_G/S_SELECTION ioctls documentation more consistent
with the rest of media Docbook, use capital letters where necessary
and correct few minor errors.
Signed-off-by: NSylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

The V4L2_CID_JPEG_CLASS control class is intended to expose various
adjustable parameters of JPEG encoders and decoders. Following controls
are defined:

 - V4L2_CID_JPEG_CHROMA_SUBSAMPLING,
 - V4L2_CID_JPEG_RESTART_INTERVAL,
 - V4L2_CID_JPEG_COMPRESSION_QUALITY,
 - V4L2_CID_JPEG_ACTIVE_MARKER.

This covers only a part of relevant standard specifications. More
controls should be added in future if required.

The purpose of V4L2_CID_JPEG_CLASS class is also to replace some
functionality covered by VIDIOC_S/G_JPEGCOMP ioctls, i.e. the JPEG
markers presence and compression quality control. The applications
and drivers should switch from the ioctl to control based API, as
described in the subsequent patches for the Media API DocBook.
Signed-off-by: NSylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

As discussed during the 2011 V4L-DVB workshop we want to create a proper V4L2
decoder API that replaces the DVBv5 API that has been used until now.

This adds the four controls necessary to be able to switch ivtv over to this
new API.
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

As discussed during the 2011 V4L-DVB workshop, the API in dvb/video.h should
be replaced by a proper V4L2 API. This patch turns the VIDEO_(TRY_)DECODER_CMD
ioctls into proper V4L2 ioctls.
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

If V4L2_CAP_DEVICE_CAPS is set, then the new device_caps field is filled with
the capabilities of the opened device node.

The capabilities field traditionally contains the capabilities of the physical
device, being a superset of all capabilities available at the several device
nodes. E.g., if you open /dev/video0, then if it contains VBI caps then that means
that there is a corresponding vbi node as well. And the capabilities field of
both the video and vbi nodes should contain identical caps.

However, it would be very useful to also have a capabilities field that contains
just the caps for the currently open device, hence the new CAP bit and field.
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

This patch introduces new api for a precise control of cropping and composing
features for video devices. The new ioctls are VIDIOC_S_SELECTION and
VIDIOC_G_SELECTION.
Signed-off-by: NTomasz Stanislawski <t.stanislaws@samsung.com>
Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

If ctrls->count is too high the multiplication could overflow and
array_size would be lower than expected.  Mauro and Hans Verkuil
suggested that we cap it at 1024.  That comes from the maximum
number of controls with lots of room for expantion.

$ grep V4L2_CID include/linux/videodev2.h | wc -l
211

Cc: stable <stable@vger.kernel.org>
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Written by Theodore Kilgore

With minor changes by Hans de Goede:
-Code style fixes
-Correct the verbose level on various PDEBUG messages
-Make error messages use pr_err instead of PDEBUG
-Document the jl20 pixel format
Signed-off-by: NTheodore Kilgore <kilgota@auburn.edu>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

The V4L2_CID_ALPHA_COMPONENT control is intended for the video capture
or memory-to-memory devices that are capable of setting up the per-pixel
alpha component to some arbitrary value. It allows to set the alpha
component for all pixels to an arbitrary value.
Signed-off-by: NSylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>
Acked-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Flash controllers can report over-current and indicator fault
conditions. Define flash fault control bits for them.
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: NSakari Ailus <sakari.ailus@maxwell.research.nokia.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

NV24 and NV42 are planar YCbCr 4:4:4 and YCrCb 4:4:4 formats with a
luma plane followed by an interleaved chroma plane.
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: NMauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: NFlorian Tobias Schandinat <FlorianSchandinat@gmx.de>

V4L2_CID_POWER_LINE_FREQUENCY control allows applications to instruct
a driver what is the power line frequency so an appropriate filter
can be used by the device to cancel flicker by compensating the light
intensity ripple. Currently in the menu we have entries for 50 Hz and
60 Hz and for entirely disabling the anti-flicker filter.
However some devices are capable of automatically detecting the
frequency, so add V4L2_CID_POWER_LINE_FREQUENCY_AUTO entry for them.
Signed-off-by: NSylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>
Acked-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Signed-off-by: NGuennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

A possibility to preallocate and initialise buffers of different sizes
in V4L2 is required for an efficient implementation of a snapshot
mode. This patch adds two new ioctl()s: VIDIOC_CREATE_BUFS and
VIDIOC_PREPARE_BUF and defines respective data structures.
Signed-off-by: NGuennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Reorganize the standards macro and add a few more, that will be
used on msp3400 in order to allow it to detect the audio standard.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Add a new VOLATILE control flag that is set for volatile controls.
That way applications know whether the value of the control is volatile
(i.e. can change continuously) or not.

Until now this was an internal property, but it is useful to know in
userspace as well.

A typical use case is the gain value when autogain is on. In that case the
hardware will continuously adjust the gain based various environmental
factors.

This patch just adds and documents the flag, it's not yet used.
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Acked-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Define a frame sync event to tell user space when the reception of a frame
starts.
Signed-off-by: NSakari Ailus <sakari.ailus@iki.fi>
Acked-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Add control definitions and documentation for controls
specific to codec devices.
Signed-off-by: NKamil Debski <k.debski@samsung.com>
Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Add fourcc definitions and documentation for the following
compressed formats: H264, H264 without start codes,
MPEG1/2/4 ES, XVID, VC1 Annex G and Annex L compliant.
Signed-off-by: NKamil Debski <k.debski@samsung.com>
Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Add a control class and a set of controls to support LED and Xenon flash
devices. An example of such a device is the adp1653.
Signed-off-by: NSakari Ailus <sakari.ailus@iki.fi>
Acked-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Reviewed-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: NSakari Ailus <sakari.ailus@iki.fi>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Normally no control events will go to the filehandle that called the
VIDIOC_S_CTRL/VIDIOC_S_EXT_CTRLS ioctls. This is to prevent a feedback
loop.

This can now be overridden by setting the new V4L2_EVENT_SUB_FL_ALLOW_FEEDBACK
flag.

Based on suggestions from Mauro Carvalho Chehab <mchehab@redhat.com> and
Laurent Pinchart <laurent.pinchart@ideasonboard.com>.
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Whenever a control changes value or state an event is sent to anyone
that subscribed to it.

This functionality is useful for control panels but also for applications
that need to wait for (usually status) controls to change value.
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

M420 is a hybrid YUV 4:2:0 packet/planar format. Two Y lines are
followed by an interleaved U/V line.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
[laurent.pinchart@ideasonboard.com: split into v4l/uvcvideo patches]
[laurent.pinchart@ideasonboard.com: add documentation]
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Add a 10 bits per pixel greyscale format in a bit-packed array representation,
naming it Y10B. Such pixel format is supplied for instance by the Kinect
sensor device.
Signed-off-by: NAntonio Ospite <ospite@studenti.unina.it>
Signed-off-by: NJean-François Moine <moinejf@free.fr>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Y12 is a grey-scale format with a depth of 12 bits per pixel stored in
16-bit words.
Signed-off-by: NMichael Jones <michael.jones@matrix-vision.de>
Acked-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

[mchehab@redhat.com: Fix a few CodingStyle issues]
Tested-by: NKjell Claesson <kjell.claesson@epost.tidanet.se>
Tested-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NJean-François Moine <moinejf@free.fr>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Add FCCs for the following pixel formats:

- V4L2_PIX_FMT_SBGGR12
- V4L2_PIX_FMT_SGBRG12
- V4L2_PIX_FMT_SGRBG12
- V4L2_PIX_FMT_SRGGB12
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: NHans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Some ioctl's were defined wrong on 2.6.2 and 2.6.6, using the wrong
type of R/W arguments. They were fixed, but the old ioctl names are
still there, maintained to avoid breaking binary compatibility:

There's no sense on preserving those forever, as it is very doubtful
that someone would try to use a such old binary with a modern kernel.
Removing them will allow us to remove some magic done at the V4L ioctl
handler.

Note that any application compiled with a videodev2.h from 2.6.7 or later
will be using the correct ioctls.
Signed-off-by: NHans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Add definitions for format with color planes non-contiguous
in physical memory. These formats apply only if the V4L2 multiplane
extension is used.

V4L2_PIX_FMT_NV12M   - 2-plane Y/CbCr
V4L2_PIX_FMT_NV12MT  - 2-plane Y/CbCr tiled (64x32 pixel macroblocks)
V4L2_PIX_FMT_YUV420M - 3-plane Y/Cb/Cr
Signed-off-by: NSylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Multi-planar API is as a backwards-compatible extension of the V4L2 API,
which allows video buffers to consist of one or more planes. Planes are
separate memory buffers; each has its own mapping, backed by usually
separate physical memory buffers.

Many different uses for the multi-planar API are possible, examples
include:
- embedded devices requiring video components to be placed in physically
separate buffers, e.g. for Samsung S3C/S5P SoC series' video codec,
Y and interleaved Cb/Cr components reside in buffers in different
memory banks;
- applications may receive (or choose to store) video data of one video
buffer in separate memory buffers; such data would have to be temporarily
copied together into one buffer before passing it to a V4L2 device;
- applications or drivers may want to pass metadata related to a buffer and
it may not be possible to place it in the same buffer, together with video
data.

[mchehab@redhat.com: CodingStyle fixes]
Signed-off-by: NPawel Osciak <p.osciak@samsung.com>
Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>
Reviewed-by: NMarek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: NMarek Szyprowski <m.szyprowski@samsung.com>
Reviewed-by: NHans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Add spacing field to v4l2_hw_freq_seek.

Add V4L2_TUNER_CAP_RDS_BLOCK_IO, which indicates that the tuner/
transmitter if capable of transmitting/receiving RDS blocks.

Add V4L2_TUNER_CAP_RDS_CONTROLS capability, which indicates that the
RDS data is handled as values of predefined controls like radio text,
program ID and so on.
Signed-off-by: NMatti J. Aaltonen <matti.j.aaltonen@nokia.com>
Acked-by: NHans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

This function is an internal API and belongs in v4l2-common.h, not
videodev.h. The return pointer and probe argument should be const as well.
Signed-off-by: NHans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Many video drivers implement a fixed set of frame formats and thus face a task
of finding the best match for a user-requested format. Implementing this in a
generic function has also an advantage, that different drivers with similar
supported format sets will select the same format for the user, which improves
consistency across drivers.
Signed-off-by: NGuennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Some media devices (microscopes) may have one or many illuminators.
This patch makes them controlable by the applications.
Acked-by: NHans Verkuil <hverkuil@xs4all.nl>
Acked-by: NAndy Walls <awalls@md.metrocast.net>
Signed-off-by: NJean-François Moine <moinejf@free.fr>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

This new driver replaces the (known to not work / crash) usbvideo konicawc
driver.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

The old usbvideo ibmcam driver needs to be replaced with a v4l2 driver
preferably using the gspca webcam framework rather then the old usbvideo
framework.

This new gspca sub driver sets a first step in that direction. The ibmcam
driver supports 4 different model webcams. This new driver (for now) only
supports Model 3 cameras, as my test cam is a Model 3 cam, or so I thought.

Upon reading:
http://www.linux-usb.org/ibmcam/
I learned that the IBM Netcamera Pro I have even though having the same
usb id and the same bcd version is different from the Model 3 cameras
supported by the ibmcam driver. So this new gscpa subdriver supports Model 3
cameras (untested), and the IBM Netcamera Pro. Currently use with the
IBM Netcamera Pro requires a module parameter. I hope to be able to
autodetect which is which in the future.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>