From f818b358dc94c845490dfc8a9771492e5311fe9e Mon Sep 17 00:00:00 2001 From: Nicolas THERY Date: Fri, 26 Oct 2012 09:01:55 -0300 Subject: [media] Documentation: fix outdated statement re. v4l2 Fix tense used for describing struct v4l2_fh as it has been added a while ago. Signed-off-by: Nicolas Thery Signed-off-by: Mauro Carvalho Chehab --- Documentation/video4linux/v4l2-framework.txt | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/video4linux/v4l2-framework.txt b/Documentation/video4linux/v4l2-framework.txt index 32bfe926e8d7..0a1ef671c9d4 100644 --- a/Documentation/video4linux/v4l2-framework.txt +++ b/Documentation/video4linux/v4l2-framework.txt @@ -68,8 +68,7 @@ Structure of the framework The framework closely resembles the driver structure: it has a v4l2_device struct for the device instance data, a v4l2_subdev struct to refer to sub-device instances, the video_device struct stores V4L2 device node data -and in the future a v4l2_fh struct will keep track of filehandle instances -(this is not yet implemented). +and the v4l2_fh struct keeps track of filehandle instances. The V4L2 framework also optionally integrates with the media framework. If a driver sets the struct v4l2_device mdev field, sub-devices and video nodes -- cgit v1.2.3-59-g8ed1b From c196f6ee61e42df9acec797ab41a0c8d87e8aa2e Mon Sep 17 00:00:00 2001 From: Manjunath Hadli Date: Thu, 18 Oct 2012 07:54:59 -0300 Subject: [media] media: add new mediabus format enums for dm365 add new enum entries for supporting the media-bus formats on dm365. These include some bayer and some non-bayer formats. V4L2_MBUS_FMT_YDYUYDYV8_1X16 and V4L2_MBUS_FMT_UV8_1X8 are used internal to the hardware by the resizer. V4L2_MBUS_FMT_SBGGR10_ALAW8_1X8 represents the bayer ALAW format that is supported by dm365 hardware. Signed-off-by: Manjunath Hadli Signed-off-by: Lad, Prabhakar Acked-by: Sakari Ailus Acked-by: Laurent Pinchart Acked-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab --- Documentation/DocBook/media/v4l/subdev-formats.xml | 250 ++++++++++++++++++++- include/uapi/linux/v4l2-mediabus.h | 10 +- 2 files changed, 252 insertions(+), 8 deletions(-) (limited to 'Documentation') diff --git a/Documentation/DocBook/media/v4l/subdev-formats.xml b/Documentation/DocBook/media/v4l/subdev-formats.xml index a0a936455fae..6f341d1eca1a 100644 --- a/Documentation/DocBook/media/v4l/subdev-formats.xml +++ b/Documentation/DocBook/media/v4l/subdev-formats.xml @@ -353,9 +353,9 @@ The number of bits per pixel component. All components are transferred on the same number of bits. Common values are 8, 10 and 12. - If the pixel components are DPCM-compressed, a mention of the - DPCM compression and the number of bits per compressed pixel component. - + 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. @@ -504,6 +504,74 @@ 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 @@ -853,10 +921,16 @@ Packed YUV Formats Those data formats transfer pixel data as (possibly downsampled) Y, U - and V components. The format code is made of the following information. + 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. + 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. @@ -877,7 +951,21 @@ U, Y, V, Y order will be named V4L2_MBUS_FMT_UYVY8_2X8. - The following table lisst existing packet YUV formats. + 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 @@ -965,6 +1053,56 @@ y1y0 + + 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 @@ -2415,6 +2553,106 @@ 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 diff --git a/include/uapi/linux/v4l2-mediabus.h b/include/uapi/linux/v4l2-mediabus.h index 7d64e0e1a18b..e860f55820ec 100644 --- a/include/uapi/linux/v4l2-mediabus.h +++ b/include/uapi/linux/v4l2-mediabus.h @@ -47,8 +47,9 @@ enum v4l2_mbus_pixelcode { V4L2_MBUS_FMT_RGB565_2X8_BE = 0x1007, V4L2_MBUS_FMT_RGB565_2X8_LE = 0x1008, - /* YUV (including grey) - next is 0x2014 */ + /* YUV (including grey) - next is 0x2016 */ V4L2_MBUS_FMT_Y8_1X8 = 0x2001, + V4L2_MBUS_FMT_UV8_1X8 = 0x2015, V4L2_MBUS_FMT_UYVY8_1_5X8 = 0x2002, V4L2_MBUS_FMT_VYUY8_1_5X8 = 0x2003, V4L2_MBUS_FMT_YUYV8_1_5X8 = 0x2004, @@ -65,14 +66,19 @@ enum v4l2_mbus_pixelcode { V4L2_MBUS_FMT_VYUY8_1X16 = 0x2010, V4L2_MBUS_FMT_YUYV8_1X16 = 0x2011, V4L2_MBUS_FMT_YVYU8_1X16 = 0x2012, + V4L2_MBUS_FMT_YDYUYDYV8_1X16 = 0x2014, V4L2_MBUS_FMT_YUYV10_1X20 = 0x200d, V4L2_MBUS_FMT_YVYU10_1X20 = 0x200e, - /* Bayer - next is 0x3015 */ + /* Bayer - next is 0x3019 */ V4L2_MBUS_FMT_SBGGR8_1X8 = 0x3001, V4L2_MBUS_FMT_SGBRG8_1X8 = 0x3013, V4L2_MBUS_FMT_SGRBG8_1X8 = 0x3002, V4L2_MBUS_FMT_SRGGB8_1X8 = 0x3014, + V4L2_MBUS_FMT_SBGGR10_ALAW8_1X8 = 0x3015, + V4L2_MBUS_FMT_SGBRG10_ALAW8_1X8 = 0x3016, + V4L2_MBUS_FMT_SGRBG10_ALAW8_1X8 = 0x3017, + V4L2_MBUS_FMT_SRGGB10_ALAW8_1X8 = 0x3018, V4L2_MBUS_FMT_SBGGR10_DPCM8_1X8 = 0x300b, V4L2_MBUS_FMT_SGBRG10_DPCM8_1X8 = 0x300c, V4L2_MBUS_FMT_SGRBG10_DPCM8_1X8 = 0x3009, -- cgit v1.2.3-59-g8ed1b From 028986fe0edab3ca7f14a9fe92f3e492304b3eec Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Wed, 19 Dec 2012 13:00:27 -0200 Subject: [media] DocBook: fix an index reference Error: no ID for constraint linkend: V4L2-PIX-FMT-NV12MT-16X16. Signed-off-by: Mauro Carvalho Chehab --- Documentation/DocBook/media/v4l/pixfmt-nv12m.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/DocBook/media/v4l/pixfmt-nv12m.xml b/Documentation/DocBook/media/v4l/pixfmt-nv12m.xml index a990b34d911a..f3a3d459fcdf 100644 --- a/Documentation/DocBook/media/v4l/pixfmt-nv12m.xml +++ b/Documentation/DocBook/media/v4l/pixfmt-nv12m.xml @@ -6,7 +6,7 @@ V4L2_PIX_FMT_NV12M V4L2_PIX_FMT_NV21M - V4L2_PIX_FMT_NV12MT_16X16 + V4L2_PIX_FMT_NV12MT_16X16 Variation of V4L2_PIX_FMT_NV12 and V4L2_PIX_FMT_NV21 with planes non contiguous in memory. -- cgit v1.2.3-59-g8ed1b From 05ad6fc1d54f106d5b8c598e2f9b59b12f3fb476 Mon Sep 17 00:00:00 2001 From: Manjunath Hadli Date: Thu, 18 Oct 2012 07:58:02 -0300 Subject: [media] v4l2: add new pixel formats supported on dm365 add new macro V4L2_PIX_FMT_SGRBG10ALAW8 and associated formats to represent Bayer format frames compressed by A-LAW algorithm, add V4L2_PIX_FMT_UV8 to represent storage of CbCr data (UV interleaved) only. Signed-off-by: Manjunath Hadli Signed-off-by: Lad, Prabhakar Acked-by: Sakari Ailus Acked-by: Laurent Pinchart Signed-off-by: Mauro Carvalho Chehab --- .../DocBook/media/v4l/pixfmt-srggb10alaw8.xml | 34 ++++++++++++ Documentation/DocBook/media/v4l/pixfmt-uv8.xml | 62 ++++++++++++++++++++++ Documentation/DocBook/media/v4l/pixfmt.xml | 2 + include/uapi/linux/videodev2.h | 8 +++ 4 files changed, 106 insertions(+) create mode 100644 Documentation/DocBook/media/v4l/pixfmt-srggb10alaw8.xml create mode 100644 Documentation/DocBook/media/v4l/pixfmt-uv8.xml (limited to 'Documentation') diff --git a/Documentation/DocBook/media/v4l/pixfmt-srggb10alaw8.xml b/Documentation/DocBook/media/v4l/pixfmt-srggb10alaw8.xml new file mode 100644 index 000000000000..c934192e98ce --- /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-uv8.xml b/Documentation/DocBook/media/v4l/pixfmt-uv8.xml new file mode 100644 index 000000000000..c507c1f73cd0 --- /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.xml b/Documentation/DocBook/media/v4l/pixfmt.xml index bf94f417592c..99b8d2ad6e4f 100644 --- a/Documentation/DocBook/media/v4l/pixfmt.xml +++ b/Documentation/DocBook/media/v4l/pixfmt.xml @@ -673,6 +673,7 @@ access the palette, this must be done with ioctls of the Linux framebuffer API.< &sub-srggb8; &sub-sbggr16; &sub-srggb10; + &sub-srggb10alaw8; &sub-srggb10dpcm8; &sub-srggb12; @@ -701,6 +702,7 @@ information. &sub-y12; &sub-y10b; &sub-y16; + &sub-uv8; &sub-yuyv; &sub-uyvy; &sub-yvyu; diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h index 3cf3e946e331..39d2cecdf38c 100644 --- a/include/uapi/linux/videodev2.h +++ b/include/uapi/linux/videodev2.h @@ -334,6 +334,9 @@ struct v4l2_pix_format { /* Palette formats */ #define V4L2_PIX_FMT_PAL8 v4l2_fourcc('P', 'A', 'L', '8') /* 8 8-bit palette */ +/* Chrominance formats */ +#define V4L2_PIX_FMT_UV8 v4l2_fourcc('U', 'V', '8', ' ') /* 8 UV 4:4 */ + /* Luminance+Chrominance formats */ #define V4L2_PIX_FMT_YVU410 v4l2_fourcc('Y', 'V', 'U', '9') /* 9 YVU 4:1:0 */ #define V4L2_PIX_FMT_YVU420 v4l2_fourcc('Y', 'V', '1', '2') /* 12 YVU 4:2:0 */ @@ -386,6 +389,11 @@ struct v4l2_pix_format { #define V4L2_PIX_FMT_SGBRG12 v4l2_fourcc('G', 'B', '1', '2') /* 12 GBGB.. RGRG.. */ #define V4L2_PIX_FMT_SGRBG12 v4l2_fourcc('B', 'A', '1', '2') /* 12 GRGR.. BGBG.. */ #define V4L2_PIX_FMT_SRGGB12 v4l2_fourcc('R', 'G', '1', '2') /* 12 RGRG.. GBGB.. */ + /* 10bit raw bayer a-law compressed to 8 bits */ +#define V4L2_PIX_FMT_SBGGR10ALAW8 v4l2_fourcc('a', 'B', 'A', '8') +#define V4L2_PIX_FMT_SGBRG10ALAW8 v4l2_fourcc('a', 'G', 'A', '8') +#define V4L2_PIX_FMT_SGRBG10ALAW8 v4l2_fourcc('a', 'g', 'A', '8') +#define V4L2_PIX_FMT_SRGGB10ALAW8 v4l2_fourcc('a', 'R', 'A', '8') /* 10bit raw bayer DPCM compressed to 8 bits */ #define V4L2_PIX_FMT_SBGGR10DPCM8 v4l2_fourcc('b', 'B', 'A', '8') #define V4L2_PIX_FMT_SGBRG10DPCM8 v4l2_fourcc('b', 'G', 'A', '8') -- cgit v1.2.3-59-g8ed1b From 454547fb8217ac82de82fdffe0c2a41d8cd47bf4 Mon Sep 17 00:00:00 2001 From: Guennadi Liakhovetski Date: Fri, 5 Oct 2012 12:33:45 -0300 Subject: [media] media: soc-camera: update documentation Update soc-camera documentation to reflect the current camera host API and the use of the common V4L2 subdev API. Signed-off-by: Guennadi Liakhovetski Signed-off-by: Mauro Carvalho Chehab --- Documentation/video4linux/soc-camera.txt | 146 ++++++++++++++++--------------- 1 file changed, 75 insertions(+), 71 deletions(-) (limited to 'Documentation') diff --git a/Documentation/video4linux/soc-camera.txt b/Documentation/video4linux/soc-camera.txt index 3f87c7da4ca2..f62fcdbc8b9f 100644 --- a/Documentation/video4linux/soc-camera.txt +++ b/Documentation/video4linux/soc-camera.txt @@ -9,32 +9,36 @@ The following terms are used in this document: of connecting to a variety of systems and interfaces, typically uses i2c for control and configuration, and a parallel or a serial bus for data. - camera host - an interface, to which a camera is connected. Typically a - specialised interface, present on many SoCs, e.g., PXA27x and PXA3xx, SuperH, + specialised interface, present on many SoCs, e.g. PXA27x and PXA3xx, SuperH, AVR32, i.MX27, i.MX31. - camera host bus - a connection between a camera host and a camera. Can be - parallel or serial, consists of data and control lines, e.g., clock, vertical + parallel or serial, consists of data and control lines, e.g. clock, vertical and horizontal synchronization signals. Purpose of the soc-camera subsystem ----------------------------------- -The soc-camera subsystem provides a unified API between camera host drivers and -camera sensor drivers. It implements a V4L2 interface to the user, currently -only the mmap method is supported. +The soc-camera subsystem initially provided a unified API between camera host +drivers and camera sensor drivers. Later the soc-camera sensor API has been +replaced with the V4L2 standard subdev API. This also made camera driver re-use +with non-soc-camera hosts possible. The camera host API to the soc-camera core +has been preserved. -This subsystem has been written to connect drivers for System-on-Chip (SoC) -video capture interfaces with drivers for CMOS camera sensor chips to enable -the reuse of sensor drivers with various hosts. The subsystem has been designed -to support multiple camera host interfaces and multiple cameras per interface, -although most applications have only one camera sensor. +Soc-camera implements a V4L2 interface to the user, currently only the "mmap" +method is supported by host drivers. However, the soc-camera core also provides +support for the "read" method. + +The subsystem has been designed to support multiple camera host interfaces and +multiple cameras per interface, although most applications have only one camera +sensor. Existing drivers ---------------- -As of 2.6.27-rc4 there are two host drivers in the mainline: pxa_camera.c for -PXA27x SoCs and sh_mobile_ceu_camera.c for SuperH SoCs, and four sensor drivers: -mt9m001.c, mt9m111.c, mt9v022.c and a generic soc_camera_platform.c driver. This -list is not supposed to be updated, look for more examples in your tree. +As of 3.7 there are seven host drivers in the mainline: atmel-isi.c, +mx1_camera.c (broken, scheduled for removal), mx2_camera.c, mx3_camera.c, +omap1_camera.c, pxa_camera.c, sh_mobile_ceu_camera.c, and multiple sensor +drivers under drivers/media/i2c/soc_camera/. Camera host API --------------- @@ -45,38 +49,37 @@ soc_camera_host_register(struct soc_camera_host *); function. The host object can be initialized as follows: -static struct soc_camera_host pxa_soc_camera_host = { - .drv_name = PXA_CAM_DRV_NAME, - .ops = &pxa_soc_camera_host_ops, -}; + struct soc_camera_host *ici; + ici->drv_name = DRV_NAME; + ici->ops = &camera_host_ops; + ici->priv = pcdev; + ici->v4l2_dev.dev = &pdev->dev; + ici->nr = pdev->id; All camera host methods are passed in a struct soc_camera_host_ops: -static struct soc_camera_host_ops pxa_soc_camera_host_ops = { +static struct soc_camera_host_ops camera_host_ops = { .owner = THIS_MODULE, - .add = pxa_camera_add_device, - .remove = pxa_camera_remove_device, - .suspend = pxa_camera_suspend, - .resume = pxa_camera_resume, - .set_fmt_cap = pxa_camera_set_fmt_cap, - .try_fmt_cap = pxa_camera_try_fmt_cap, - .init_videobuf = pxa_camera_init_videobuf, - .reqbufs = pxa_camera_reqbufs, - .poll = pxa_camera_poll, - .querycap = pxa_camera_querycap, - .try_bus_param = pxa_camera_try_bus_param, - .set_bus_param = pxa_camera_set_bus_param, + .add = camera_add_device, + .remove = camera_remove_device, + .set_fmt = camera_set_fmt_cap, + .try_fmt = camera_try_fmt_cap, + .init_videobuf2 = camera_init_videobuf2, + .poll = camera_poll, + .querycap = camera_querycap, + .set_bus_param = camera_set_bus_param, + /* The rest of host operations are optional */ }; .add and .remove methods are called when a sensor is attached to or detached -from the host, apart from performing host-internal tasks they shall also call -sensor driver's .init and .release methods respectively. .suspend and .resume -methods implement host's power-management functionality and its their -responsibility to call respective sensor's methods. .try_bus_param and -.set_bus_param are used to negotiate physical connection parameters between the -host and the sensor. .init_videobuf is called by soc-camera core when a -video-device is opened, further video-buffer management is implemented completely -by the specific camera host driver. The rest of the methods are called from +from the host. .set_bus_param is used to configure physical connection +parameters between the host and the sensor. .init_videobuf2 is called by +soc-camera core when a video-device is opened, the host driver would typically +call vb2_queue_init() in this method. Further video-buffer management is +implemented completely by the specific camera host driver. If the host driver +supports non-standard pixel format conversion, it should implement a +.get_formats and, possibly, a .put_formats operations. See below for more +details about format conversion. The rest of the methods are called from respective V4L2 operations. Camera API @@ -84,37 +87,21 @@ Camera API Sensor drivers can use struct soc_camera_link, typically provided by the platform, and used to specify to which camera host bus the sensor is connected, -and arbitrarily provide platform .power and .reset methods for the camera. -soc_camera_device_register() and soc_camera_device_unregister() functions are -used to add a sensor driver to or remove one from the system. The registration -function takes a pointer to struct soc_camera_device as the only parameter. -This struct can be initialized as follows: - - /* link to driver operations */ - icd->ops = &mt9m001_ops; - /* link to the underlying physical (e.g., i2c) device */ - icd->control = &client->dev; - /* window geometry */ - icd->x_min = 20; - icd->y_min = 12; - icd->x_current = 20; - icd->y_current = 12; - icd->width_min = 48; - icd->width_max = 1280; - icd->height_min = 32; - icd->height_max = 1024; - icd->y_skip_top = 1; - /* camera bus ID, typically obtained from platform data */ - icd->iface = icl->bus_id; - -struct soc_camera_ops provides .probe and .remove methods, which are called by -the soc-camera core, when a camera is matched against or removed from a camera -host bus, .init, .release, .suspend, and .resume are called from the camera host -driver as discussed above. Other members of this struct provide respective V4L2 -functionality. - -struct soc_camera_device also links to an array of struct soc_camera_data_format, -listing pixel formats, supported by the camera. +and optionally provide platform .power and .reset methods for the camera. This +struct is provided to the camera driver via the I2C client device platform data +and can be obtained, using the soc_camera_i2c_to_link() macro. Care should be +taken, when using soc_camera_vdev_to_subdev() and when accessing struct +soc_camera_device, using v4l2_get_subdev_hostdata(): both only work, when +running on an soc-camera host. The actual camera driver operation is implemented +using the V4L2 subdev API. Additionally soc-camera camera drivers can use +auxiliary soc-camera helper functions like soc_camera_power_on() and +soc_camera_power_off(), which switch regulators, provided by the platform and call +board-specific power switching methods. soc_camera_apply_board_flags() takes +camera bus configuration capability flags and applies any board transformations, +e.g. signal polarity inversion. soc_mbus_get_fmtdesc() can be used to obtain a +pixel format descriptor, corresponding to a certain media-bus pixel format code. +soc_camera_limit_side() can be used to restrict beginning and length of a frame +side, based on camera capabilities. VIDIOC_S_CROP and VIDIOC_S_FMT behaviour ---------------------------------------- @@ -153,8 +140,25 @@ implemented. User window geometry is kept in .user_width and .user_height fields in struct soc_camera_device and used by the soc-camera core and host drivers. The core updates these fields upon successful completion of a .s_fmt() call, but if these -fields change elsewhere, e.g., during .s_crop() processing, the host driver is +fields change elsewhere, e.g. during .s_crop() processing, the host driver is responsible for updating them. +Format conversion +----------------- + +V4L2 distinguishes between pixel formats, as they are stored in memory, and as +they are transferred over a media bus. Soc-camera provides support to +conveniently manage these formats. A table of standard transformations is +maintained by soc-camera core, which describes, what FOURCC pixel format will +be obtained, if a media-bus pixel format is stored in memory according to +certain rules. E.g. if V4L2_MBUS_FMT_YUYV8_2X8 data is sampled with 8 bits per +sample and stored in memory in the little-endian order with no gaps between +bytes, data in memory will represent the V4L2_PIX_FMT_YUYV FOURCC format. These +standard transformations will be used by soc-camera or by camera host drivers to +configure camera drivers to produce the FOURCC format, requested by the user, +using the VIDIOC_S_FMT ioctl(). Apart from those standard format conversions, +host drivers can also provide their own conversion rules by implementing a +.get_formats and, if required, a .put_formats methods. + -- Author: Guennadi Liakhovetski -- cgit v1.2.3-59-g8ed1b From 1202ecdc24fc88d5b144824f55ec9c8899591caf Mon Sep 17 00:00:00 2001 From: Sakari Ailus Date: Sun, 21 Oct 2012 16:02:47 -0300 Subject: [media] v4l: Define video buffer flags for timestamp types Define video buffer flags for different timestamp types. Everything up to now have used either realtime clock or monotonic clock, without a way to tell which clock the timestamp was taken from. Also document that the clock source of the timestamp in the timestamp field depends on buffer flags. [mchehab@redhat.com: fix a few wrong references to Kernel 3.8 - as this patch is meant for 3.9] Signed-off-by: Sakari Ailus Acked-by: Laurent Pinchart Acked-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab --- Documentation/DocBook/media/v4l/compat.xml | 12 +++++++ Documentation/DocBook/media/v4l/io.xml | 53 +++++++++++++++++++++++------- Documentation/DocBook/media/v4l/v4l2.xml | 12 ++++++- include/uapi/linux/videodev2.h | 4 +++ 4 files changed, 69 insertions(+), 12 deletions(-) (limited to 'Documentation') diff --git a/Documentation/DocBook/media/v4l/compat.xml b/Documentation/DocBook/media/v4l/compat.xml index 3dd9e78815d1..ebd2bfd1ee8e 100644 --- a/Documentation/DocBook/media/v4l/compat.xml +++ b/Documentation/DocBook/media/v4l/compat.xml @@ -2477,6 +2477,18 @@ that used it. It was originally scheduled for removal in 2.6.35. +
+ V4L2 in Linux 3.9 + + + Added timestamp types to + flags field in + v4l2_buffer. See . + + +
+
Relation of V4L2 to other Linux multimedia APIs diff --git a/Documentation/DocBook/media/v4l/io.xml b/Documentation/DocBook/media/v4l/io.xml index 388a34032653..09e8dcf5e9c4 100644 --- a/Documentation/DocBook/media/v4l/io.xml +++ b/Documentation/DocBook/media/v4l/io.xml @@ -741,17 +741,19 @@ applications when an output stream. struct timeval timestamp - For input streams this is the -system time (as returned by the gettimeofday() -function) when the first data byte was captured. 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. + 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; @@ -1114,6 +1116,35 @@ 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) . +
diff --git a/Documentation/DocBook/media/v4l/v4l2.xml b/Documentation/DocBook/media/v4l/v4l2.xml index 4d110b1ad3e9..8fe29427c8e4 100644 --- a/Documentation/DocBook/media/v4l/v4l2.xml +++ b/Documentation/DocBook/media/v4l/v4l2.xml @@ -139,6 +139,16 @@ structs, ioctls) must be noted in more detail in the history chapter (compat.xml), along with the possible impact on existing drivers and applications. --> + + 3.9 + 2012-12-03 + sa + Added timestamp types to + v4l2_buffer, see . + + + 3.6 2012-07-02 @@ -472,7 +482,7 @@ and discussions on the V4L mailing list. Video for Linux Two API Specification - Revision 3.6 + Revision 3.9 &sub-common; diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h index 39d2cecdf38c..94cbe26e9f00 100644 --- a/include/uapi/linux/videodev2.h +++ b/include/uapi/linux/videodev2.h @@ -701,6 +701,10 @@ struct v4l2_buffer { /* Cache handling flags */ #define V4L2_BUF_FLAG_NO_CACHE_INVALIDATE 0x0800 #define V4L2_BUF_FLAG_NO_CACHE_CLEAN 0x1000 +/* Timestamp type */ +#define V4L2_BUF_FLAG_TIMESTAMP_MASK 0xe000 +#define V4L2_BUF_FLAG_TIMESTAMP_UNKNOWN 0x0000 +#define V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC 0x2000 /** * struct v4l2_exportbuffer - export of video buffer as DMABUF file descriptor -- cgit v1.2.3-59-g8ed1b From fe4abb550f68ace5bbc23030c968c138c6a69759 Mon Sep 17 00:00:00 2001 From: Sakari Ailus Date: Fri, 16 Nov 2012 17:42:12 -0300 Subject: [media] v4l: There's no __unsigned Correct a typo. v4l2_plane.m.userptr is unsigned long, not __unsigned long. Signed-off-by: Sakari Ailus Acked-by: Laurent Pinchart Signed-off-by: Mauro Carvalho Chehab --- Documentation/DocBook/media/v4l/io.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/DocBook/media/v4l/io.xml b/Documentation/DocBook/media/v4l/io.xml index 09e8dcf5e9c4..2c4646d504c2 100644 --- a/Documentation/DocBook/media/v4l/io.xml +++ b/Documentation/DocBook/media/v4l/io.xml @@ -905,7 +905,7 @@ should set this to 0. - __unsigned long + unsigned long userptr When the memory type in the containing &v4l2-buffer; is V4L2_MEMORY_USERPTR, this is a userspace -- cgit v1.2.3-59-g8ed1b From b01189b85b7653a51ebe851fc4d70702cebfed3c Mon Sep 17 00:00:00 2001 From: Sylwester Nawrocki Date: Wed, 28 Nov 2012 14:40:32 -0300 Subject: [media] V4L: DocBook: Add V4L2_MBUS_FMT_YUV10_1X30 media bus pixel code This patch adds definition of media bus code for YUV pixel format transferred in 30-bit samples where each component has 10 bits width. [mchehab@redhat.com: fix a merge conflict at v4l2-mediabus.h] Signed-off-by: Sylwester Nawrocki Signed-off-by: Kyungmin Park Signed-off-by: Mauro Carvalho Chehab --- Documentation/DocBook/media/v4l/subdev-formats.xml | 716 ++++++--------------- Documentation/DocBook/media_api.tmpl | 1 + include/uapi/linux/v4l2-mediabus.h | 3 +- 3 files changed, 195 insertions(+), 525 deletions(-) (limited to 'Documentation') diff --git a/Documentation/DocBook/media/v4l/subdev-formats.xml b/Documentation/DocBook/media/v4l/subdev-formats.xml index 6f341d1eca1a..cc51372ed5e0 100644 --- a/Documentation/DocBook/media/v4l/subdev-formats.xml +++ b/Documentation/DocBook/media/v4l/subdev-formats.xml @@ -973,27 +973,37 @@ - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Identifier @@ -1005,6 +1015,16 @@ Bit + 29 + 28 + 27 + 26 + 25 + 24 + 23 + 22 + 21 + 10 19 18 17 @@ -1032,16 +1052,8 @@ V4L2_MBUS_FMT_Y8_1X8 0x2001 - - - - - - - - - - - - - - - - - - - - + &dash-ent-10; + &dash-ent-10; - - y7 @@ -1107,16 +1119,8 @@ V4L2_MBUS_FMT_UYVY8_1_5X8 0x2002 - - - - - - - - - - - - - - - - - - - - + &dash-ent-10; + &dash-ent-10; - - u7 @@ -1132,16 +1136,8 @@ - - - - - - - - - - - - - - - - - - - - + &dash-ent-10; + &dash-ent-10; - - y7 @@ -1157,16 +1153,8 @@ - - - - - - - - - - - - - - - - - - - - + &dash-ent-10; + &dash-ent-10; - - y7 @@ -1182,16 +1170,8 @@ - - - - - - - - - - - - - - - - - - - - + &dash-ent-10; + &dash-ent-10; - - v7 @@ -1207,16 +1187,8 @@ - - - - - - - - - - - - - - - - - - - - + &dash-ent-10; + &dash-ent-10; - - y7 @@ -1232,16 +1204,8 @@ - - - - - - - - - - - - - - - - - - - - + &dash-ent-10; + &dash-ent-10; - - y7 @@ -1257,16 +1221,8 @@ V4L2_MBUS_FMT_VYUY8_1_5X8 0x2003 - - - - - - - - - - - - - - - - - - - - + &dash-ent-10; + &dash-ent-10; - - v7 @@ -1282,16 +1238,8 @@ - - - - - - - - - - - - - - - - - - - - + &dash-ent-10; + &dash-ent-10; - - y7 @@ -1307,16 +1255,8 @@ - - - - - - - - - - - - - - - - - - - - + &dash-ent-10; + &dash-ent-10; - - y7 @@ -1332,16 +1272,8 @@ - - - - - - - - - - - - - - - - - - - - + &dash-ent-10; + &dash-ent-10; - - u7 @@ -1357,16 +1289,8 @@ - - - - - - - - - - - - - - - - - - - - + &dash-ent-10; + &dash-ent-10; - - y7 @@ -1382,16 +1306,8 @@ - - - - - - - - - - - - - - - - - - - - + &dash-ent-10; + &dash-ent-10; - - y7 @@ -1407,16 +1323,8 @@ V4L2_MBUS_FMT_YUYV8_1_5X8 0x2004 - - - - - - - - - - - - - - - - - - - - + &dash-ent-10; + &dash-ent-10; - - y7 @@ -1432,16 +1340,8 @@ - - - - - - - - - - - - - - - - - - - - + &dash-ent-10; + &dash-ent-10; - - y7 @@ -1457,16 +1357,8 @@ - - - - - - - - - - - - - - - - - - - - + &dash-ent-10; + &dash-ent-10; - - u7 @@ -1482,16 +1374,8 @@ - - - - - - - - - - - - - - - - - - - - + &dash-ent-10; + &dash-ent-10; - - y7 @@ -1507,16 +1391,8 @@ - - - - - - - - - - - - - - - - - - - - + &dash-ent-10; + &dash-ent-10; - - y7 @@ -1532,16 +1408,8 @@ - - - - - - - - - - - - - - - - - - - - + &dash-ent-10; + &dash-ent-10; - - v7 @@ -1557,16 +1425,8 @@ V4L2_MBUS_FMT_YVYU8_1_5X8 0x2005 - - - - - - - - - - - - - - - - - - - - + &dash-ent-10; + &dash-ent-10; - - y7 @@ -1582,16 +1442,8 @@ - - - - - - - - - - - - - - - - - - - - + &dash-ent-10; + &dash-ent-10; - - y7 @@ -1607,16 +1459,8 @@ - - - - - - - - - - - - - - - - - - - - + &dash-ent-10; + &dash-ent-10; - - v7 @@ -1632,16 +1476,8 @@ - - - - - - - - - - - - - - - - - - - - + &dash-ent-10; + &dash-ent-10; - - y7 @@ -1657,16 +1493,8 @@ - - - - - - - - - - - - - - - - - - - - + &dash-ent-10; + &dash-ent-10; - - y7 @@ -1682,16 +1510,8 @@ - - - - - - - - - - - - - - - - - - - - + &dash-ent-10; + &dash-ent-10; - - u7 @@ -1707,16 +1527,8 @@ V4L2_MBUS_FMT_UYVY8_2X8 0x2006 - - - - - - - - - - - - - - - - - - - - + &dash-ent-10; + &dash-ent-10; - - u7 @@ -1732,16 +1544,8 @@ - - - - - - - - - - - - - - - - - - - - + &dash-ent-10; + &dash-ent-10; - - y7 @@ -1754,19 +1558,11 @@ y0 - - - - - - - - - - - - - - - - - - - - - - - + + + + &dash-ent-10; + &dash-ent-10; - - v7 @@ -1782,16 +1578,8 @@ - - - - - - - - - - - - - - - - - - - - + &dash-ent-10; + &dash-ent-10; - - y7 @@ -1807,16 +1595,8 @@ V4L2_MBUS_FMT_VYUY8_2X8 0x2007 - - - - - - - - - - - - - - - - - - - - + &dash-ent-10; + &dash-ent-10; - - v7 @@ -1832,16 +1612,8 @@ - - - - - - - - - - - - - - - - - - - - + &dash-ent-10; + &dash-ent-10; - - y7 @@ -1857,16 +1629,8 @@ - - - - - - - - - - - - - - - - - - - - + &dash-ent-10; + &dash-ent-10; - - u7 @@ -1882,16 +1646,8 @@ - - - - - - - - - - - - - - - - - - - - + &dash-ent-10; + &dash-ent-10; - - y7 @@ -1907,16 +1663,8 @@ V4L2_MBUS_FMT_YUYV8_2X8 0x2008 - - - - - - - - - - - - - - - - - - - - + &dash-ent-10; + &dash-ent-10; - - y7 @@ -1932,16 +1680,8 @@ - - - - - - - - - - - - - - - - - - - - + &dash-ent-10; + &dash-ent-10; - - u7 @@ -1957,16 +1697,8 @@ - - - - - - - - - - - - - - - - - - - - + &dash-ent-10; + &dash-ent-10; - - y7 @@ -1982,16 +1714,8 @@ - - - - - - - - - - - - - - - - - - - - + &dash-ent-10; + &dash-ent-10; - - v7 @@ -2007,16 +1731,8 @@ V4L2_MBUS_FMT_YVYU8_2X8 0x2009 - - - - - - - - - - - - - - - - - - - - + &dash-ent-10; + &dash-ent-10; - - y7 @@ -2032,16 +1748,8 @@ - - - - - - - - - - - - - - - - - - - - + &dash-ent-10; + &dash-ent-10; - - v7 @@ -2057,16 +1765,8 @@ - - - - - - - - - - - - - - - - - - - - + &dash-ent-10; + &dash-ent-10; - - y7 @@ -2082,16 +1782,8 @@ - - - - - - - - - - - - - - - - - - - - + &dash-ent-10; + &dash-ent-10; - - u7 @@ -2107,16 +1799,8 @@ V4L2_MBUS_FMT_Y10_1X10 0x200a - - - - - - - - - - - - - - - - - - - - + &dash-ent-10; + &dash-ent-10; y9 y8 y7 @@ -2132,16 +1816,8 @@ V4L2_MBUS_FMT_YUYV10_2X10 0x200b - - - - - - - - - - - - - - - - - - - - + &dash-ent-10; + &dash-ent-10; y9 y8 y7 @@ -2157,16 +1833,8 @@ - - - - - - - - - - - - - - - - - - - - + &dash-ent-10; + &dash-ent-10; u9 u8 u7 @@ -2182,16 +1850,8 @@ - - - - - - - - - - - - - - - - - - - - + &dash-ent-10; + &dash-ent-10; y9 y8 y7 @@ -2207,16 +1867,8 @@ - - - - - - - - - - - - - - - - - - - - + &dash-ent-10; + &dash-ent-10; v9 v8 v7 @@ -2232,16 +1884,8 @@ V4L2_MBUS_FMT_YVYU10_2X10 0x200c - - - - - - - - - - - - - - - - - - - - + &dash-ent-10; + &dash-ent-10; y9 y8 y7 @@ -2257,16 +1901,8 @@ - - - - - - - - - - - - - - - - - - - - + &dash-ent-10; + &dash-ent-10; v9 v8 v7 @@ -2282,16 +1918,8 @@ - - - - - - - - - - - - - - - - - - - - + &dash-ent-10; + &dash-ent-10; y9 y8 y7 @@ -2307,16 +1935,8 @@ - - - - - - - - - - - - - - - - - - - - + &dash-ent-10; + &dash-ent-10; u9 u8 u7 @@ -2332,6 +1952,7 @@ V4L2_MBUS_FMT_Y12_1X12 0x2013 + &dash-ent-10; - - - @@ -2357,6 +1978,7 @@ V4L2_MBUS_FMT_UYVY8_1X16 0x200f + &dash-ent-10; - - - @@ -2382,6 +2004,7 @@ + &dash-ent-10; - - - @@ -2407,6 +2030,7 @@ V4L2_MBUS_FMT_VYUY8_1X16 0x2010 + &dash-ent-10; - - - @@ -2432,6 +2056,7 @@ + &dash-ent-10; - - - @@ -2457,6 +2082,7 @@ V4L2_MBUS_FMT_YUYV8_1X16 0x2011 + &dash-ent-10; - - - @@ -2482,6 +2108,7 @@ + &dash-ent-10; - - - @@ -2507,6 +2134,7 @@ V4L2_MBUS_FMT_YVYU8_1X16 0x2012 + &dash-ent-10; - - - @@ -2532,6 +2160,7 @@ + &dash-ent-10; - - - @@ -2657,6 +2286,7 @@ V4L2_MBUS_FMT_YUYV10_1X20 0x200d + &dash-ent-10; y9 y8 y7 @@ -2682,6 +2312,7 @@ + &dash-ent-10; y9 y8 y7 @@ -2707,6 +2338,7 @@ V4L2_MBUS_FMT_YVYU10_1X20 0x200e + &dash-ent-10; y9 y8 y7 @@ -2732,6 +2364,32 @@ + &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 @@ -2752,6 +2410,16 @@ u2 u1 u0 + v9 + v8 + v7 + v6 + v5 + v4 + v3 + v2 + v1 + v0 diff --git a/Documentation/DocBook/media_api.tmpl b/Documentation/DocBook/media_api.tmpl index f2413acfe241..1f6593deb995 100644 --- a/Documentation/DocBook/media_api.tmpl +++ b/Documentation/DocBook/media_api.tmpl @@ -22,6 +22,7 @@ http://linuxtv.org/repo/"> +----------"> ]> diff --git a/include/uapi/linux/v4l2-mediabus.h b/include/uapi/linux/v4l2-mediabus.h index e860f55820ec..b9b7bea04537 100644 --- a/include/uapi/linux/v4l2-mediabus.h +++ b/include/uapi/linux/v4l2-mediabus.h @@ -47,7 +47,7 @@ enum v4l2_mbus_pixelcode { V4L2_MBUS_FMT_RGB565_2X8_BE = 0x1007, V4L2_MBUS_FMT_RGB565_2X8_LE = 0x1008, - /* YUV (including grey) - next is 0x2016 */ + /* YUV (including grey) - next is 0x2017 */ V4L2_MBUS_FMT_Y8_1X8 = 0x2001, V4L2_MBUS_FMT_UV8_1X8 = 0x2015, V4L2_MBUS_FMT_UYVY8_1_5X8 = 0x2002, @@ -69,6 +69,7 @@ enum v4l2_mbus_pixelcode { V4L2_MBUS_FMT_YDYUYDYV8_1X16 = 0x2014, V4L2_MBUS_FMT_YUYV10_1X20 = 0x200d, V4L2_MBUS_FMT_YVYU10_1X20 = 0x200e, + V4L2_MBUS_FMT_YUV10_1X30 = 0x2016, /* Bayer - next is 0x3019 */ V4L2_MBUS_FMT_SBGGR8_1X8 = 0x3001, -- cgit v1.2.3-59-g8ed1b From 23e8321624076317e9ffd6df949a5a3a5e59b448 Mon Sep 17 00:00:00 2001 From: Hans de Goede Date: Thu, 29 Nov 2012 07:06:22 -0300 Subject: [media] Documentation/media: Remove docs for obsoleted and removed v4l1 drivers When the v4l1 drivers were removed, there docs were forgotten. Signed-off-by: Hans de Goede Signed-off-by: Mauro Carvalho Chehab --- Documentation/video4linux/et61x251.txt | 315 ----------------------- Documentation/video4linux/ibmcam.txt | 323 ----------------------- Documentation/video4linux/m5602.txt | 12 - Documentation/video4linux/ov511.txt | 288 --------------------- Documentation/video4linux/se401.txt | 54 ---- Documentation/video4linux/stv680.txt | 53 ---- Documentation/video4linux/w9968cf.txt | 458 --------------------------------- Documentation/video4linux/zc0301.txt | 270 ------------------- 8 files changed, 1773 deletions(-) delete mode 100644 Documentation/video4linux/et61x251.txt delete mode 100644 Documentation/video4linux/ibmcam.txt delete mode 100644 Documentation/video4linux/m5602.txt delete mode 100644 Documentation/video4linux/ov511.txt delete mode 100644 Documentation/video4linux/se401.txt delete mode 100644 Documentation/video4linux/stv680.txt delete mode 100644 Documentation/video4linux/w9968cf.txt delete mode 100644 Documentation/video4linux/zc0301.txt (limited to 'Documentation') diff --git a/Documentation/video4linux/et61x251.txt b/Documentation/video4linux/et61x251.txt deleted file mode 100644 index e0cdae491858..000000000000 --- a/Documentation/video4linux/et61x251.txt +++ /dev/null @@ -1,315 +0,0 @@ - - ET61X[12]51 PC Camera Controllers - Driver for Linux - ================================= - - - Documentation - - - -Index -===== -1. Copyright -2. Disclaimer -3. License -4. Overview and features -5. Module dependencies -6. Module loading -7. Module parameters -8. Optional device control through "sysfs" -9. Supported devices -10. Notes for V4L2 application developers -11. Contact information - - -1. Copyright -============ -Copyright (C) 2006-2007 by Luca Risolia - - -2. Disclaimer -============= -Etoms is a trademark of Etoms Electronics Corp. -This software is not developed or sponsored by Etoms Electronics. - - -3. License -========== -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; either version 2 of the License, or -(at your option) any later version. - -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. - -You should have received a copy of the GNU General Public License -along with this program; if not, write to the Free Software -Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. - - -4. Overview and features -======================== -This driver supports the video interface of the devices mounting the ET61X151 -or ET61X251 PC Camera Controllers. - -It's worth to note that Etoms Electronics has never collaborated with the -author during the development of this project; despite several requests, -Etoms Electronics also refused to release enough detailed specifications of -the video compression engine. - -The driver relies on the Video4Linux2 and USB core modules. It has been -designed to run properly on SMP systems as well. - -The latest version of the ET61X[12]51 driver can be found at the following URL: -http://www.linux-projects.org/ - -Some of the features of the driver are: - -- full compliance with the Video4Linux2 API (see also "Notes for V4L2 - application developers" paragraph); -- available mmap or read/poll methods for video streaming through isochronous - data transfers; -- automatic detection of image sensor; -- support for any window resolutions and optional panning within the maximum - pixel area of image sensor; -- image downscaling with arbitrary scaling factors from 1 and 2 in both - directions (see "Notes for V4L2 application developers" paragraph); -- two different video formats for uncompressed or compressed data in low or - high compression quality (see also "Notes for V4L2 application developers" - paragraph); -- full support for the capabilities of every possible image sensors that can - be connected to the ET61X[12]51 bridges, including, for instance, red, green, - blue and global gain adjustments and exposure control (see "Supported - devices" paragraph for details); -- use of default color settings for sunlight conditions; -- dynamic I/O interface for both ET61X[12]51 and image sensor control (see - "Optional device control through 'sysfs'" paragraph); -- dynamic driver control thanks to various module parameters (see "Module - parameters" paragraph); -- up to 64 cameras can be handled at the same time; they can be connected and - disconnected from the host many times without turning off the computer, if - the system supports hotplugging; -- no known bugs. - - -5. Module dependencies -====================== -For it to work properly, the driver needs kernel support for Video4Linux and -USB. - -The following options of the kernel configuration file must be enabled and -corresponding modules must be compiled: - - # Multimedia devices - # - CONFIG_VIDEO_DEV=m - -To enable advanced debugging functionality on the device through /sysfs: - - # Multimedia devices - # - CONFIG_VIDEO_ADV_DEBUG=y - - # USB support - # - CONFIG_USB=m - -In addition, depending on the hardware being used, the modules below are -necessary: - - # USB Host Controller Drivers - # - CONFIG_USB_EHCI_HCD=m - CONFIG_USB_UHCI_HCD=m - CONFIG_USB_OHCI_HCD=m - -And finally: - - # USB Multimedia devices - # - CONFIG_USB_ET61X251=m - - -6. Module loading -================= -To use the driver, it is necessary to load the "et61x251" module into memory -after every other module required: "videodev", "v4l2_common", "compat_ioctl32", -"usbcore" and, depending on the USB host controller you have, "ehci-hcd", -"uhci-hcd" or "ohci-hcd". - -Loading can be done as shown below: - - [root@localhost home]# modprobe et61x251 - -At this point the devices should be recognized. You can invoke "dmesg" to -analyze kernel messages and verify that the loading process has gone well: - - [user@localhost home]$ dmesg - - -7. Module parameters -==================== -Module parameters are listed below: -------------------------------------------------------------------------------- -Name: video_nr -Type: short array (min = 0, max = 64) -Syntax: <-1|n[,...]> -Description: Specify V4L2 minor mode number: - -1 = use next available - n = use minor number n - You can specify up to 64 cameras this way. - For example: - video_nr=-1,2,-1 would assign minor number 2 to the second - registered camera and use auto for the first one and for every - other camera. -Default: -1 -------------------------------------------------------------------------------- -Name: force_munmap -Type: bool array (min = 0, max = 64) -Syntax: <0|1[,...]> -Description: Force the application to unmap previously mapped buffer memory - before calling any VIDIOC_S_CROP or VIDIOC_S_FMT ioctl's. Not - all the applications support this feature. This parameter is - specific for each detected camera. - 0 = do not force memory unmapping - 1 = force memory unmapping (save memory) -Default: 0 -------------------------------------------------------------------------------- -Name: frame_timeout -Type: uint array (min = 0, max = 64) -Syntax: -Description: Timeout for a video frame in seconds. This parameter is - specific for each detected camera. This parameter can be - changed at runtime thanks to the /sys filesystem interface. -Default: 2 -------------------------------------------------------------------------------- -Name: debug -Type: ushort -Syntax: -Description: Debugging information level, from 0 to 3: - 0 = none (use carefully) - 1 = critical errors - 2 = significant information - 3 = more verbose messages - Level 3 is useful for testing only, when only one device - is used at the same time. It also shows some more information - about the hardware being detected. This module parameter can be - changed at runtime thanks to the /sys filesystem interface. -Default: 2 -------------------------------------------------------------------------------- - - -8. Optional device control through "sysfs" -========================================== -If the kernel has been compiled with the CONFIG_VIDEO_ADV_DEBUG option enabled, -it is possible to read and write both the ET61X[12]51 and the image sensor -registers by using the "sysfs" filesystem interface. - -There are four files in the /sys/class/video4linux/videoX directory for each -registered camera: "reg", "val", "i2c_reg" and "i2c_val". The first two files -control the ET61X[12]51 bridge, while the other two control the sensor chip. -"reg" and "i2c_reg" hold the values of the current register index where the -following reading/writing operations are addressed at through "val" and -"i2c_val". Their use is not intended for end-users, unless you know what you -are doing. Remember that you must be logged in as root before writing to them. - -As an example, suppose we were to want to read the value contained in the -register number 1 of the sensor register table - which is usually the product -identifier - of the camera registered as "/dev/video0": - - [root@localhost #] cd /sys/class/video4linux/video0 - [root@localhost #] echo 1 > i2c_reg - [root@localhost #] cat i2c_val - -Note that if the sensor registers cannot be read, "cat" will fail. -To avoid race conditions, all the I/O accesses to the files are serialized. - - -9. Supported devices -==================== -None of the names of the companies as well as their products will be mentioned -here. They have never collaborated with the author, so no advertising. - -From the point of view of a driver, what unambiguously identify a device are -its vendor and product USB identifiers. Below is a list of known identifiers of -devices mounting the ET61X[12]51 PC camera controllers: - -Vendor ID Product ID ---------- ---------- -0x102c 0x6151 -0x102c 0x6251 -0x102c 0x6253 -0x102c 0x6254 -0x102c 0x6255 -0x102c 0x6256 -0x102c 0x6257 -0x102c 0x6258 -0x102c 0x6259 -0x102c 0x625a -0x102c 0x625b -0x102c 0x625c -0x102c 0x625d -0x102c 0x625e -0x102c 0x625f -0x102c 0x6260 -0x102c 0x6261 -0x102c 0x6262 -0x102c 0x6263 -0x102c 0x6264 -0x102c 0x6265 -0x102c 0x6266 -0x102c 0x6267 -0x102c 0x6268 -0x102c 0x6269 - -The following image sensors are supported: - -Model Manufacturer ------ ------------ -TAS5130D1B Taiwan Advanced Sensor Corporation - -All the available control settings of each image sensor are supported through -the V4L2 interface. - - -10. Notes for V4L2 application developers -========================================= -This driver follows the V4L2 API specifications. In particular, it enforces two -rules: - -- exactly one I/O method, either "mmap" or "read", is associated with each -file descriptor. Once it is selected, the application must close and reopen the -device to switch to the other I/O method; - -- although it is not mandatory, previously mapped buffer memory should always -be unmapped before calling any "VIDIOC_S_CROP" or "VIDIOC_S_FMT" ioctl's. -The same number of buffers as before will be allocated again to match the size -of the new video frames, so you have to map the buffers again before any I/O -attempts on them. - -Consistently with the hardware limits, this driver also supports image -downscaling with arbitrary scaling factors from 1 and 2 in both directions. -However, the V4L2 API specifications don't correctly define how the scaling -factor can be chosen arbitrarily by the "negotiation" of the "source" and -"target" rectangles. To work around this flaw, we have added the convention -that, during the negotiation, whenever the "VIDIOC_S_CROP" ioctl is issued, the -scaling factor is restored to 1. - -This driver supports two different video formats: the first one is the "8-bit -Sequential Bayer" format and can be used to obtain uncompressed video data -from the device through the current I/O method, while the second one provides -"raw" compressed video data (without frame headers not related to the -compressed data). The current compression quality may vary from 0 to 1 and can -be selected or queried thanks to the VIDIOC_S_JPEGCOMP and VIDIOC_G_JPEGCOMP -V4L2 ioctl's. - - -11. Contact information -======================= -The author may be contacted by e-mail at . - -GPG/PGP encrypted e-mail's are accepted. The GPG key ID of the author is -'FCE635A4'; the public 1024-bit key should be available at any keyserver; -the fingerprint is: '88E8 F32F 7244 68BA 3958 5D40 99DA 5D2A FCE6 35A4'. diff --git a/Documentation/video4linux/ibmcam.txt b/Documentation/video4linux/ibmcam.txt deleted file mode 100644 index a51055211e62..000000000000 --- a/Documentation/video4linux/ibmcam.txt +++ /dev/null @@ -1,323 +0,0 @@ -README for Linux device driver for the IBM "C-It" USB video camera - -INTRODUCTION: - -This driver does not use all features known to exist in -the IBM camera. However most of needed features work well. - -This driver was developed using logs of observed USB traffic -which was produced by standard Windows driver (c-it98.sys). -I did not have data sheets from Xirlink. - -Video formats: - 128x96 [model 1] - 176x144 - 320x240 [model 2] - 352x240 [model 2] - 352x288 -Frame rate: 3 - 30 frames per second (FPS) -External interface: USB -Internal interface: Video For Linux (V4L) -Supported controls: -- by V4L: Contrast, Brightness, Color, Hue -- by driver options: frame rate, lighting conditions, video format, - default picture settings, sharpness. - -SUPPORTED CAMERAS: - -Xirlink "C-It" camera, also known as "IBM PC Camera". -The device uses proprietary ASIC (and compression method); -it is manufactured by Xirlink. See http://xirlinkwebcam.sourceforge.net, -http://www.ibmpccamera.com, or http://www.c-itnow.com/ for details and pictures. - -This very chipset ("X Chip", as marked at the factory) -is used in several other cameras, and they are supported -as well: - -- IBM NetCamera -- Veo Stingray - -The Linux driver was developed with camera with following -model number (or FCC ID): KSX-XVP510. This camera has three -interfaces, each with one endpoint (control, iso, iso). This -type of cameras is referred to as "model 1". These cameras are -no longer manufactured. - -Xirlink now manufactures new cameras which are somewhat different. -In particular, following models [FCC ID] belong to that category: - -XVP300 [KSX-X9903] -XVP600 [KSX-X9902] -XVP610 [KSX-X9902] - -(see http://www.xirlink.com/ibmpccamera/ for updates, they refer -to these new cameras by Windows driver dated 12-27-99, v3005 BETA) -These cameras have two interfaces, one endpoint in each (iso, bulk). -Such type of cameras is referred to as "model 2". They are supported -(with exception of 352x288 native mode). - -Some IBM NetCameras (Model 4) are made to generate only compressed -video streams. This is great for performance, but unfortunately -nobody knows how to decompress the stream :-( Therefore, these -cameras are *unsupported* and if you try to use one of those, all -you get is random colored horizontal streaks, not the image! -If you have one of those cameras, you probably should return it -to the store and get something that is supported. - -Tell me more about all that "model" business --------------------------------------------- - -I just invented model numbers to uniquely identify flavors of the -hardware/firmware that were sold. It was very confusing to use -brand names or some other internal numbering schemes. So I found -by experimentation that all Xirlink chipsets fall into four big -classes, and I called them "models". Each model is programmed in -its own way, and each model sends back the video in its own way. - -Quirks of Model 2 cameras: -------------------------- - -Model 2 does not have hardware contrast control. Corresponding V4L -control is implemented in software, which is not very nice to your -CPU, but at least it works. - -This driver provides 352x288 mode by switching the camera into -quasi-352x288 RGB mode (800 Kbits per frame) essentially limiting -this mode to 10 frames per second or less, in ideal conditions on -the bus (USB is shared, after all). The frame rate -has to be programmed very conservatively. Additional concern is that -frame rate depends on brightness setting; therefore the picture can -be good at one brightness and broken at another! I did not want to fix -the frame rate at slowest setting, but I had to move it pretty much down -the scale (so that framerate option barely matters). I also noticed that -camera after first powering up produces frames slightly faster than during -consecutive uses. All this means that if you use 352x288 (which is -default), be warned - you may encounter broken picture on first connect; -try to adjust brightness - brighter image is slower, so USB will be able -to send all data. However if you regularly use Model 2 cameras you may -prefer 176x144 which makes perfectly good I420, with no scaling and -lesser demands on USB (300 Kbits per second, or 26 frames per second). - -Another strange effect of 352x288 mode is the fine vertical grid visible -on some colored surfaces. I am sure it is caused by me not understanding -what the camera is trying to say. Blame trade secrets for that. - -The camera that I had also has a hardware quirk: if disconnected, -it needs few minutes to "relax" before it can be plugged in again -(poorly designed USB processor reset circuit?) - -[Veo Stingray with Product ID 0x800C is also Model 2, but I haven't -observed this particular flaw in it.] - -Model 2 camera can be programmed for very high sensitivity (even starlight -may be enough), this makes it convenient for tinkering with. The driver -code has enough comments to help a programmer to tweak the camera -as s/he feels necessary. - -WHAT YOU NEED: - -- A supported IBM PC (C-it) camera (model 1 or 2) - -- A Linux box with USB support (2.3/2.4; 2.2 w/backport may work) - -- A Video4Linux compatible frame grabber program such as xawtv. - -HOW TO COMPILE THE DRIVER: - -You need to compile the driver only if you are a developer -or if you want to make changes to the code. Most distributions -precompile all modules, so you can go directly to the next -section "HOW TO USE THE DRIVER". - -The ibmcam driver uses usbvideo helper library (module), -so if you are studying the ibmcam code you will be led there. - -The driver itself consists of only one file in usb/ directory: -ibmcam.c. This file is included into the Linux kernel build -process if you configure the kernel for CONFIG_USB_IBMCAM. -Run "make xconfig" and in USB section you will find the IBM -camera driver. Select it, save the configuration and recompile. - -HOW TO USE THE DRIVER: - -I recommend to compile driver as a module. This gives you an -easier access to its configuration. The camera has many more -settings than V4L can operate, so some settings are done using -module options. - -To begin with, on most modern Linux distributions the driver -will be automatically loaded whenever you plug the supported -camera in. Therefore, you don't need to do anything. However -if you want to experiment with some module parameters then -you can load and unload the driver manually, with camera -plugged in or unplugged. - -Typically module is installed with command 'modprobe', like this: - -# modprobe ibmcam framerate=1 - -Alternatively you can use 'insmod' in similar fashion: - -# insmod /lib/modules/2.x.y/usb/ibmcam.o framerate=1 - -Module can be inserted with camera connected or disconnected. - -The driver can have options, though some defaults are provided. - -Driver options: (* indicates that option is model-dependent) - -Name Type Range [default] Example --------------- -------------- -------------- ------------------ -debug Integer 0-9 [0] debug=1 -flags Integer 0-0xFF [0] flags=0x0d -framerate Integer 0-6 [2] framerate=1 -hue_correction Integer 0-255 [128] hue_correction=115 -init_brightness Integer 0-255 [128] init_brightness=100 -init_contrast Integer 0-255 [192] init_contrast=200 -init_color Integer 0-255 [128] init_color=130 -init_hue Integer 0-255 [128] init_hue=115 -lighting Integer 0-2* [1] lighting=2 -sharpness Integer 0-6* [4] sharpness=3 -size Integer 0-2* [2] size=1 - -Options for Model 2 only: - -Name Type Range [default] Example --------------- -------------- -------------- ------------------ -init_model2_rg Integer 0..255 [0x70] init_model2_rg=128 -init_model2_rg2 Integer 0..255 [0x2f] init_model2_rg2=50 -init_model2_sat Integer 0..255 [0x34] init_model2_sat=65 -init_model2_yb Integer 0..255 [0xa0] init_model2_yb=200 - -debug You don't need this option unless you are a developer. - If you are a developer then you will see in the code - what values do what. 0=off. - -flags This is a bit mask, and you can combine any number of - bits to produce what you want. Usually you don't want - any of extra features this option provides: - - FLAGS_RETRY_VIDIOCSYNC 1 This bit allows to retry failed - VIDIOCSYNC ioctls without failing. - Will work with xawtv, will not - with xrealproducer. Default is - not set. - FLAGS_MONOCHROME 2 Activates monochrome (b/w) mode. - FLAGS_DISPLAY_HINTS 4 Shows colored pixels which have - magic meaning to developers. - FLAGS_OVERLAY_STATS 8 Shows tiny numbers on screen, - useful only for debugging. - FLAGS_FORCE_TESTPATTERN 16 Shows blue screen with numbers. - FLAGS_SEPARATE_FRAMES 32 Shows each frame separately, as - it was received from the camera. - Default (not set) is to mix the - preceding frame in to compensate - for occasional loss of Isoc data - on high frame rates. - FLAGS_CLEAN_FRAMES 64 Forces "cleanup" of each frame - prior to use; relevant only if - FLAGS_SEPARATE_FRAMES is set. - Default is not to clean frames, - this is a little faster but may - produce flicker if frame rate is - too high and Isoc data gets lost. - FLAGS_NO_DECODING 128 This flag turns the video stream - decoder off, and dumps the raw - Isoc data from the camera into - the reading process. Useful to - developers, but not to users. - -framerate This setting controls frame rate of the camera. This is - an approximate setting (in terms of "worst" ... "best") - because camera changes frame rate depending on amount - of light available. Setting 0 is slowest, 6 is fastest. - Beware - fast settings are very demanding and may not - work well with all video sizes. Be conservative. - -hue_correction This highly optional setting allows to adjust the - hue of the image in a way slightly different from - what usual "hue" control does. Both controls affect - YUV colorspace: regular "hue" control adjusts only - U component, and this "hue_correction" option similarly - adjusts only V component. However usually it is enough - to tweak only U or V to compensate for colored light or - color temperature; this option simply allows more - complicated correction when and if it is necessary. - -init_brightness These settings specify _initial_ values which will be -init_contrast used to set up the camera. If your V4L application has -init_color its own controls to adjust the picture then these -init_hue controls will be used too. These options allow you to - preconfigure the camera when it gets connected, before - any V4L application connects to it. Good for webcams. - -init_model2_rg These initial settings alter color balance of the -init_model2_rg2 camera on hardware level. All four settings may be used -init_model2_sat to tune the camera to specific lighting conditions. These -init_model2_yb settings only apply to Model 2 cameras. - -lighting This option selects one of three hardware-defined - photosensitivity settings of the camera. 0=bright light, - 1=Medium (default), 2=Low light. This setting affects - frame rate: the dimmer the lighting the lower the frame - rate (because longer exposition time is needed). The - Model 2 cameras allow values more than 2 for this option, - thus enabling extremely high sensitivity at cost of frame - rate, color saturation and imaging sensor noise. - -sharpness This option controls smoothing (noise reduction) - made by camera. Setting 0 is most smooth, setting 6 - is most sharp. Be aware that CMOS sensor used in the - camera is pretty noisy, so if you choose 6 you will - be greeted with "snowy" image. Default is 4. Model 2 - cameras do not support this feature. - -size This setting chooses one of several image sizes that are - supported by this driver. Cameras may support more, but - it's difficult to reverse-engineer all formats. - Following video sizes are supported: - - size=0 128x96 (Model 1 only) - size=1 160x120 - size=2 176x144 - size=3 320x240 (Model 2 only) - size=4 352x240 (Model 2 only) - size=5 352x288 - size=6 640x480 (Model 3 only) - - The 352x288 is the native size of the Model 1 sensor - array, so it's the best resolution the camera can - yield. The best resolution of Model 2 is 176x144, and - larger images are produced by stretching the bitmap. - Model 3 has sensor with 640x480 grid, and it works too, - but the frame rate will be exceptionally low (1-2 FPS); - it may be still OK for some applications, like security. - Choose the image size you need. The smaller image can - support faster frame rate. Default is 352x288. - -For more information and the Troubleshooting FAQ visit this URL: - - http://www.linux-usb.org/ibmcam/ - -WHAT NEEDS TO BE DONE: - -- The button on the camera is not used. I don't know how to get to it. - I know now how to read button on Model 2, but what to do with it? - -- Camera reports its status back to the driver; however I don't know - what returned data means. If camera fails at some initialization - stage then something should be done, and I don't do that because - I don't even know that some command failed. This is mostly Model 1 - concern because Model 2 uses different commands which do not return - status (and seem to complete successfully every time). - -- Some flavors of Model 4 NetCameras produce only compressed video - streams, and I don't know how to decode them. - -CREDITS: - -The code is based in no small part on the CPiA driver by Johannes Erdfelt, -Randy Dunlap, and others. Big thanks to them for their pioneering work on that -and the USB stack. - -I also thank John Lightsey for his donation of the Veo Stingray camera. diff --git a/Documentation/video4linux/m5602.txt b/Documentation/video4linux/m5602.txt deleted file mode 100644 index 4450ab13f37b..000000000000 --- a/Documentation/video4linux/m5602.txt +++ /dev/null @@ -1,12 +0,0 @@ -This document describes the ALi m5602 bridge connected -to the following supported sensors: -OmniVision OV9650, -Samsung s5k83a, -Samsung s5k4aa, -Micron mt9m111, -Pixel plus PO1030 - -This driver mimics the windows drivers, which have a braindead implementation sending bayer-encoded frames at VGA resolution. -In a perfect world we should be able to reprogram the m5602 and the connected sensor in hardware instead, supporting a range of resolutions and pixelformats - -Anyway, have fun and please report any bugs to m560x-driver-devel@lists.sourceforge.net diff --git a/Documentation/video4linux/ov511.txt b/Documentation/video4linux/ov511.txt deleted file mode 100644 index b3326b167ada..000000000000 --- a/Documentation/video4linux/ov511.txt +++ /dev/null @@ -1,288 +0,0 @@ -------------------------------------------------------------------------------- -Readme for Linux device driver for the OmniVision OV511 USB to camera bridge IC -------------------------------------------------------------------------------- - -Author: Mark McClelland -Homepage: http://alpha.dyndns.org/ov511 - -INTRODUCTION: - -This is a driver for the OV511, a USB-only chip used in many "webcam" devices. -Any camera using the OV511/OV511+ and the OV6620/OV7610/20/20AE should work. -Video capture devices that use the Philips SAA7111A decoder also work. It -supports streaming and capture of color or monochrome video via the Video4Linux -API. Most V4L apps are compatible with it. Most resolutions with a width and -height that are a multiple of 8 are supported. - -If you need more information, please visit the OV511 homepage at the above URL. - -WHAT YOU NEED: - -- If you want to help with the development, get the chip's specification docs at - http://www.ovt.com/omniusbp.html - -- A Video4Linux compatible frame grabber program (I recommend vidcat and xawtv) - vidcat is part of the w3cam package: http://mpx.freeshell.net/ - xawtv is available at: http://linux.bytesex.org/xawtv/ - -HOW TO USE IT: - -Note: These are simplified instructions. For complete instructions see: - http://alpha.dyndns.org/ov511/install.html - -You must have first compiled USB support, support for your specific USB host -controller (UHCI or OHCI), and Video4Linux support for your kernel (I recommend -making them modules.) Make sure "Enforce bandwidth allocation" is NOT enabled. - -Next, (as root): - - modprobe usbcore - modprobe usb-uhci modprobe usb-ohci - modprobe videodev - modprobe ov511 - -If it is not already there (it usually is), create the video device: - - mknod /dev/video0 c 81 0 - -Optionally, symlink /dev/video to /dev/video0 - -You will have to set permissions on this device to allow you to read/write -from it: - - chmod 666 /dev/video - chmod 666 /dev/video0 (if necessary) - -Now you are ready to run a video app! Both vidcat and xawtv work well for me -at 640x480. - -[Using vidcat:] - - vidcat -s 640x480 -p c > test.jpg - xview test.jpg - -[Using xawtv:] - -From the main xawtv directory: - - make clean - ./configure - make - make install - -Now you should be able to run xawtv. Right click for the options dialog. - -MODULE PARAMETERS: - - You can set these with: insmod ov511 NAME=VALUE - There is currently no way to set these on a per-camera basis. - - NAME: autobright - TYPE: integer (Boolean) - DEFAULT: 1 - DESC: Brightness is normally under automatic control and can't be set - manually by the video app. Set to 0 for manual control. - - NAME: autogain - TYPE: integer (Boolean) - DEFAULT: 1 - DESC: Auto Gain Control enable. This feature is not yet implemented. - - NAME: autoexp - TYPE: integer (Boolean) - DEFAULT: 1 - DESC: Auto Exposure Control enable. This feature is not yet implemented. - - NAME: debug - TYPE: integer (0-6) - DEFAULT: 3 - DESC: Sets the threshold for printing debug messages. The higher the value, - the more is printed. The levels are cumulative, and are as follows: - 0=no debug messages - 1=init/detection/unload and other significant messages - 2=some warning messages - 3=config/control function calls - 4=most function calls and data parsing messages - 5=highly repetitive mesgs - - NAME: snapshot - TYPE: integer (Boolean) - DEFAULT: 0 - DESC: Set to 1 to enable snapshot mode. read()/VIDIOCSYNC will block until - the snapshot button is pressed. Note: enabling this mode disables - /proc/video/ov511//button - - NAME: cams - TYPE: integer (1-4 for OV511, 1-31 for OV511+) - DEFAULT: 1 - DESC: Number of cameras allowed to stream simultaneously on a single bus. - Values higher than 1 reduce the data rate of each camera, allowing two - or more to be used at once. If you have a complicated setup involving - both OV511 and OV511+ cameras, trial-and-error may be necessary for - finding the optimum setting. - - NAME: compress - TYPE: integer (Boolean) - DEFAULT: 0 - DESC: Set this to 1 to turn on the camera's compression engine. This can - potentially increase the frame rate at the expense of quality, if you - have a fast CPU. You must load the proper compression module for your - camera before starting your application (ov511_decomp or ov518_decomp). - - NAME: testpat - TYPE: integer (Boolean) - DEFAULT: 0 - DESC: This configures the camera's sensor to transmit a colored test-pattern - instead of an image. This does not work correctly yet. - - NAME: dumppix - TYPE: integer (0-2) - DEFAULT: 0 - DESC: Dumps raw pixel data and skips post-processing and format conversion. - It is for debugging purposes only. Options are: - 0: Disable (default) - 1: Dump raw data from camera, excluding headers and trailers - 2: Dumps data exactly as received from camera - - NAME: led - TYPE: integer (0-2) - DEFAULT: 1 (Always on) - DESC: Controls whether the LED (the little light) on the front of the camera - is always off (0), always on (1), or only on when driver is open (2). - This is not supported with the OV511, and might only work with certain - cameras (ones that actually have the LED wired to the control pin, and - not just hard-wired to be on all the time). - - NAME: dump_bridge - TYPE: integer (Boolean) - DEFAULT: 0 - DESC: Dumps the bridge (OV511[+] or OV518[+]) register values to the system - log. Only useful for serious debugging/development purposes. - - NAME: dump_sensor - TYPE: integer (Boolean) - DEFAULT: 0 - DESC: Dumps the sensor register values to the system log. Only useful for - serious debugging/development purposes. - - NAME: printph - TYPE: integer (Boolean) - DEFAULT: 0 - DESC: Setting this to 1 will dump the first 12 bytes of each isoc frame. This - is only useful if you are trying to debug problems with the isoc data - stream (i.e.: camera initializes, but vidcat hangs until Ctrl-C). Be - warned that this dumps a large number of messages to your kernel log. - - NAME: phy, phuv, pvy, pvuv, qhy, qhuv, qvy, qvuv - TYPE: integer (0-63 for phy and phuv, 0-255 for rest) - DEFAULT: OV511 default values - DESC: These are registers 70h - 77h of the OV511, which control the - prediction ranges and quantization thresholds of the compressor, for - the Y and UV channels in the horizontal and vertical directions. See - the OV511 or OV511+ data sheet for more detailed descriptions. These - normally do not need to be changed. - - NAME: lightfreq - TYPE: integer (0, 50, or 60) - DEFAULT: 0 (use sensor default) - DESC: Sets the sensor to match your lighting frequency. This can reduce the - appearance of "banding", i.e. horizontal lines or waves of light and - dark that are often caused by artificial lighting. Valid values are: - 0 - Use default (depends on sensor, most likely 60 Hz) - 50 - For European and Asian 50 Hz power - 60 - For American 60 Hz power - - NAME: bandingfilter - TYPE: integer (Boolean) - DEFAULT: 0 (off) - DESC: Enables the sensor´s banding filter exposure algorithm. This reduces - or stabilizes the "banding" caused by some artificial light sources - (especially fluorescent). You might have to set lightfreq correctly for - this to work right. As an added bonus, this sometimes makes it - possible to capture your monitor´s output. - - NAME: fastset - TYPE: integer (Boolean) - DEFAULT: 0 (off) - DESC: Allows picture settings (brightness, contrast, color, and hue) to take - effect immediately, even in the middle of a frame. This reduces the - time to change settings, but can ruin frames during the change. Only - affects OmniVision sensors. - - NAME: force_palette - TYPE: integer (Boolean) - DEFAULT: 0 (off) - DESC: Forces the palette (color format) to a specific value. If an - application requests a different palette, it will be rejected, thereby - forcing it to try others until it succeeds. This is useful for forcing - greyscale mode with a color camera, for example. Supported modes are: - 0 (Allows all the following formats) - 1 VIDEO_PALETTE_GREY (Linear greyscale) - 10 VIDEO_PALETTE_YUV420 (YUV 4:2:0 Planar) - 15 VIDEO_PALETTE_YUV420P (YUV 4:2:0 Planar, same as 10) - - NAME: backlight - TYPE: integer (Boolean) - DEFAULT: 0 (off) - DESC: Setting this flag changes the exposure algorithm for OmniVision sensors - such that objects in the camera's view (i.e. your head) can be clearly - seen when they are illuminated from behind. It reduces or eliminates - the sensor's auto-exposure function, so it should only be used when - needed. Additionally, it is only supported with the OV6620 and OV7620. - - NAME: unit_video - TYPE: Up to 16 comma-separated integers - DEFAULT: 0,0,0... (automatically assign the next available minor(s)) - DESC: You can specify up to 16 minor numbers to be assigned to ov511 devices. - For example, "unit_video=1,3" will make the driver use /dev/video1 and - /dev/video3 for the first two devices it detects. Additional devices - will be assigned automatically starting at the first available device - node (/dev/video0 in this case). Note that you cannot specify 0 as a - minor number. This feature requires kernel version 2.4.5 or higher. - - NAME: remove_zeros - TYPE: integer (Boolean) - DEFAULT: 0 (do not skip any incoming data) - DESC: Setting this to 1 will remove zero-padding from incoming data. This - will compensate for the blocks of corruption that can appear when the - camera cannot keep up with the speed of the USB bus (eg. at low frame - resolutions). This feature is always enabled when compression is on. - - NAME: mirror - TYPE: integer (Boolean) - DEFAULT: 0 (off) - DESC: Setting this to 1 will reverse ("mirror") the image horizontally. This - might be necessary if your camera has a custom lens assembly. This has - no effect with video capture devices. - - NAME: ov518_color - TYPE: integer (Boolean) - DEFAULT: 0 (off) - DESC: Enable OV518 color support. This is off by default since it doesn't - work most of the time. If you want to try it, you must also load - ov518_decomp with the "nouv=0" parameter. If you get improper colors or - diagonal lines through the image, restart your video app and try again. - Repeat as necessary. - -WORKING FEATURES: - o Color streaming/capture at most widths and heights that are multiples of 8. - o Monochrome (use force_palette=1 to enable) - o Setting/getting of saturation, contrast, brightness, and hue (only some of - them work the OV7620 and OV7620AE) - o /proc status reporting - o SAA7111A video capture support at 320x240 and 640x480 - o Compression support - o SMP compatibility - -HOW TO CONTACT ME: - -You can email me at mark@alpha.dyndns.org . Please prefix the subject line -with "OV511: " so that I am certain to notice your message. - -CREDITS: - -The code is based in no small part on the CPiA driver by Johannes Erdfelt, -Randy Dunlap, and others. Big thanks to them for their pioneering work on that -and the USB stack. Thanks to Bret Wallach for getting camera reg IO, ISOC, and -image capture working. Thanks to Orion Sky Lawlor, Kevin Moore, and Claudio -Matsuoka for their work as well. diff --git a/Documentation/video4linux/se401.txt b/Documentation/video4linux/se401.txt deleted file mode 100644 index bd6526ec8dd7..000000000000 --- a/Documentation/video4linux/se401.txt +++ /dev/null @@ -1,54 +0,0 @@ -Linux driver for SE401 based USB cameras - -Copyright, 2001, Jeroen Vreeken - - -INTRODUCTION: - -The SE401 chip is the used in low-cost usb webcams. -It is produced by Endpoints Inc. (www.endpoints.com). -It interfaces directly to a cmos image sensor and USB. The only other major -part in a se401 based camera is a dram chip. - -The following cameras are known to work with this driver: - -Aox se401 (non-branded) cameras -Philips PVCV665 USB VGA webcam 'Vesta Fun' -Kensington VideoCAM PC Camera Model 67014 -Kensington VideoCAM PC Camera Model 67015 -Kensington VideoCAM PC Camera Model 67016 -Kensington VideoCAM PC Camera Model 67017 - - -WHAT YOU NEED: - -- USB support -- VIDEO4LINUX support - -More information about USB support for linux can be found at: -http://www.linux-usb.org - - -MODULE OPTIONS: - -When the driver is compiled as a module you can also use the 'flickerless' -option. With it exposure is limited to values that do not interfere with the -net frequency. Valid options for this option are 0, 50 and 60. (0=disable, -50=50hz, 60=60hz) - - -KNOWN PROBLEMS: - -The driver works fine with the usb-ohci and uhci host controller drivers, -the default settings also work with usb-uhci. But sending more than one bulk -transfer at a time with usb-uhci doesn't work yet. -Users of usb-ohci and uhci can safely enlarge SE401_NUMSBUF in se401.h in -order to increase the throughput (and thus framerate). - - -HELP: - -The latest info on this driver can be found at: -http://members.chello.nl/~j.vreeken/se401/ -And questions to me can be send to: -pe1rxq@amsat.org diff --git a/Documentation/video4linux/stv680.txt b/Documentation/video4linux/stv680.txt deleted file mode 100644 index e3de33645308..000000000000 --- a/Documentation/video4linux/stv680.txt +++ /dev/null @@ -1,53 +0,0 @@ -Linux driver for STV0680 based USB cameras - -Copyright, 2001, Kevin Sisson - - -INTRODUCTION: - -STMicroelectronics produces the STV0680B chip, which comes in two -types, -001 and -003. The -003 version allows the recording and downloading -of sound clips from the camera, and allows a flash attachment. Otherwise, -it uses the same commands as the -001 version. Both versions support a -variety of SDRAM sizes and sensors, allowing for a maximum of 26 VGA or 20 -CIF pictures. The STV0680 supports either a serial or a usb interface, and -video is possible through the usb interface. - -The following cameras are known to work with this driver, although any -camera with Vendor/Product codes of 0553/0202 should work: - -Aiptek Pencam (various models) -Nisis QuickPix 2 -Radio Shack 'Kid's digital camera' (#60-1207) -At least one Trust Spycam model -Several other European brand models - -WHAT YOU NEED: - -- USB support -- VIDEO4LINUX support - -More information about USB support for linux can be found at: -http://www.linux-usb.org - - -MODULE OPTIONS: - -When the driver is compiled as a module, you can set a "swapRGB=1" -option, if necessary, for those applications that require it -(such as xawtv). However, the driver should detect and set this -automatically, so this option should not normally be used. - - -KNOWN PROBLEMS: - -The driver seems to work better with the usb-ohci than the usb-uhci host -controller driver. - -HELP: - -The latest info on this driver can be found at: -http://personal.clt.bellsouth.net/~kjsisson or at -http://stv0680-usb.sourceforge.net - -Any questions to me can be send to: kjsisson@bellsouth.net diff --git a/Documentation/video4linux/w9968cf.txt b/Documentation/video4linux/w9968cf.txt deleted file mode 100644 index 9649450f3b90..000000000000 --- a/Documentation/video4linux/w9968cf.txt +++ /dev/null @@ -1,458 +0,0 @@ - - W996[87]CF JPEG USB Dual Mode Camera Chip - Driver for Linux 2.6 (basic version) - ========================================= - - - Documentation - - - -Index -===== -1. Copyright -2. Disclaimer -3. License -4. Overview -5. Supported devices -6. Module dependencies -7. Module loading -8. Module parameters -9. Contact information -10. Credits - - -1. Copyright -============ -Copyright (C) 2002-2004 by Luca Risolia - - -2. Disclaimer -============= -Winbond is a trademark of Winbond Electronics Corporation. -This software is not sponsored or developed by Winbond. - - -3. License -========== -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; either version 2 of the License, or -(at your option) any later version. - -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. - -You should have received a copy of the GNU General Public License -along with this program; if not, write to the Free Software -Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. - - -4. Overview -=========== -This driver supports the video streaming capabilities of the devices mounting -Winbond W9967CF and Winbond W9968CF JPEG USB Dual Mode Camera Chips. OV681 -based cameras should be supported as well. - -The driver is divided into two modules: the basic one, "w9968cf", is needed for -the supported devices to work; the second one, "w9968cf-vpp", is an optional -module, which provides some useful video post-processing functions like video -decoding, up-scaling and colour conversions. - -Note that the official kernels do neither include nor support the second -module for performance purposes. Therefore, it is always recommended to -download and install the latest and complete release of the driver, -replacing the existing one, if present. - -The latest and full-featured version of the W996[87]CF driver can be found at: -http://www.linux-projects.org. Please refer to the documentation included in -that package, if you are going to use it. - -Up to 32 cameras can be handled at the same time. They can be connected and -disconnected from the host many times without turning off the computer, if -your system supports the hotplug facility. - -To change the default settings for each camera, many parameters can be passed -through command line when the module is loaded into memory. - -The driver relies on the Video4Linux, USB and I2C core modules. It has been -designed to run properly on SMP systems as well. An additional module, -"ovcamchip", is mandatory; it provides support for some OmniVision image -sensors connected to the W996[87]CF chips; if found in the system, the module -will be automatically loaded by default (provided that the kernel has been -compiled with the automatic module loading option). - - -5. Supported devices -==================== -At the moment, known W996[87]CF and OV681 based devices are: -- Aroma Digi Pen VGA Dual Mode ADG-5000 (unknown image sensor) -- AVerMedia AVerTV USB (SAA7111A, Philips FI1216Mk2 tuner, PT2313L audio chip) -- Creative Labs Video Blaster WebCam Go (OmniVision OV7610 sensor) -- Creative Labs Video Blaster WebCam Go Plus (OmniVision OV7620 sensor) -- Lebon LDC-035A (unknown image sensor) -- Ezonics EZ-802 EZMega Cam (OmniVision OV8610C sensor) -- OmniVision OV8610-EDE (OmniVision OV8610 sensor) -- OPCOM Digi Pen VGA Dual Mode Pen Camera (unknown image sensor) -- Pretec Digi Pen-II (OmniVision OV7620 sensor) -- Pretec DigiPen-480 (OmniVision OV8610 sensor) - -If you know any other W996[87]CF or OV681 based cameras, please contact me. - -The list above does not imply that all those devices work with this driver: up -until now only webcams that have an image sensor supported by the "ovcamchip" -module work. Kernel messages will always tell you whether this is case. - -Possible external microcontrollers of those webcams are not supported: this -means that still images cannot be downloaded from the device memory. - -Furthermore, it's worth to note that I was only able to run tests on my -"Creative Labs Video Blaster WebCam Go". Donations of other models, for -additional testing and full support, would be much appreciated. - - -6. Module dependencies -====================== -For it to work properly, the driver needs kernel support for Video4Linux, USB -and I2C, and the "ovcamchip" module for the image sensor. Make sure you are not -actually using any external "ovcamchip" module, given that the W996[87]CF -driver depends on the version of the module present in the official kernels. - -The following options of the kernel configuration file must be enabled and -corresponding modules must be compiled: - - # Multimedia devices - # - CONFIG_VIDEO_DEV=m - - # I2C support - # - CONFIG_I2C=m - -The I2C core module can be compiled statically in the kernel as well. - - # OmniVision Camera Chip support - # - CONFIG_VIDEO_OVCAMCHIP=m - - # USB support - # - CONFIG_USB=m - -In addition, depending on the hardware being used, only one of the modules -below is necessary: - - # USB Host Controller Drivers - # - CONFIG_USB_EHCI_HCD=m - CONFIG_USB_UHCI_HCD=m - CONFIG_USB_OHCI_HCD=m - -And finally: - - # USB Multimedia devices - # - CONFIG_USB_W9968CF=m - - -7. Module loading -================= -To use the driver, it is necessary to load the "w9968cf" module into memory -after every other module required. - -Loading can be done this way, from root: - - [root@localhost home]# modprobe usbcore - [root@localhost home]# modprobe i2c-core - [root@localhost home]# modprobe videodev - [root@localhost home]# modprobe w9968cf - -At this point the pertinent devices should be recognized: "dmesg" can be used -to analyze kernel messages: - - [user@localhost home]$ dmesg - -There are a lot of parameters the module can use to change the default -settings for each device. To list every possible parameter with a brief -explanation about them and which syntax to use, it is recommended to run the -"modinfo" command: - - [root@locahost home]# modinfo w9968cf - - -8. Module parameters -==================== -Module parameters are listed below: -------------------------------------------------------------------------------- -Name: ovmod_load -Type: bool -Syntax: <0|1> -Description: Automatic 'ovcamchip' module loading: 0 disabled, 1 enabled. - If enabled, 'insmod' searches for the required 'ovcamchip' - module in the system, according to its configuration, and - loads that module automatically. This action is performed as - once soon as the 'w9968cf' module is loaded into memory. -Default: 1 -------------------------------------------------------------------------------- -Name: simcams -Type: int -Syntax: -Description: Number of cameras allowed to stream simultaneously. - n may vary from 0 to 32. -Default: 32 -------------------------------------------------------------------------------- -Name: video_nr -Type: int array (min = 0, max = 32) -Syntax: <-1|n[,...]> -Description: Specify V4L minor mode number. - -1 = use next available - n = use minor number n - You can specify up to 32 cameras this way. - For example: - video_nr=-1,2,-1 would assign minor number 2 to the second - recognized camera and use auto for the first one and for every - other camera. -Default: -1 -------------------------------------------------------------------------------- -Name: packet_size -Type: int array (min = 0, max = 32) -Syntax: -Description: Specify the maximum data payload size in bytes for alternate - settings, for each device. n is scaled between 63 and 1023. -Default: 1023 -------------------------------------------------------------------------------- -Name: max_buffers -Type: int array (min = 0, max = 32) -Syntax: -Description: For advanced users. - Specify the maximum number of video frame buffers to allocate - for each device, from 2 to 32. -Default: 2 -------------------------------------------------------------------------------- -Name: double_buffer -Type: bool array (min = 0, max = 32) -Syntax: <0|1[,...]> -Description: Hardware double buffering: 0 disabled, 1 enabled. - It should be enabled if you want smooth video output: if you - obtain out of sync. video, disable it, or try to - decrease the 'clockdiv' module parameter value. -Default: 1 for every device. -------------------------------------------------------------------------------- -Name: clamping -Type: bool array (min = 0, max = 32) -Syntax: <0|1[,...]> -Description: Video data clamping: 0 disabled, 1 enabled. -Default: 0 for every device. -------------------------------------------------------------------------------- -Name: filter_type -Type: int array (min = 0, max = 32) -Syntax: <0|1|2[,...]> -Description: Video filter type. - 0 none, 1 (1-2-1) 3-tap filter, 2 (2-3-6-3-2) 5-tap filter. - The filter is used to reduce noise and aliasing artifacts - produced by the CCD or CMOS image sensor. -Default: 0 for every device. -------------------------------------------------------------------------------- -Name: largeview -Type: bool array (min = 0, max = 32) -Syntax: <0|1[,...]> -Description: Large view: 0 disabled, 1 enabled. -Default: 1 for every device. -------------------------------------------------------------------------------- -Name: upscaling -Type: bool array (min = 0, max = 32) -Syntax: <0|1[,...]> -Description: Software scaling (for non-compressed video only): - 0 disabled, 1 enabled. - Disable it if you have a slow CPU or you don't have enough - memory. -Default: 0 for every device. -Note: If 'w9968cf-vpp' is not present, this parameter is set to 0. -------------------------------------------------------------------------------- -Name: decompression -Type: int array (min = 0, max = 32) -Syntax: <0|1|2[,...]> -Description: Software video decompression: - 0 = disables decompression - (doesn't allow formats needing decompression). - 1 = forces decompression - (allows formats needing decompression only). - 2 = allows any permitted formats. - Formats supporting (de)compressed video are YUV422P and - YUV420P/YUV420 in any resolutions where width and height are - multiples of 16. -Default: 2 for every device. -Note: If 'w9968cf-vpp' is not present, forcing decompression is not - allowed; in this case this parameter is set to 2. -------------------------------------------------------------------------------- -Name: force_palette -Type: int array (min = 0, max = 32) -Syntax: <0|9|10|13|15|8|7|1|6|3|4|5[,...]> -Description: Force picture palette. - In order: - 0 = Off - allows any of the following formats: - 9 = UYVY 16 bpp - Original video, compression disabled - 10 = YUV420 12 bpp - Original video, compression enabled - 13 = YUV422P 16 bpp - Original video, compression enabled - 15 = YUV420P 12 bpp - Original video, compression enabled - 8 = YUVY 16 bpp - Software conversion from UYVY - 7 = YUV422 16 bpp - Software conversion from UYVY - 1 = GREY 8 bpp - Software conversion from UYVY - 6 = RGB555 16 bpp - Software conversion from UYVY - 3 = RGB565 16 bpp - Software conversion from UYVY - 4 = RGB24 24 bpp - Software conversion from UYVY - 5 = RGB32 32 bpp - Software conversion from UYVY - When not 0, this parameter will override 'decompression'. -Default: 0 for every device. Initial palette is 9 (UYVY). -Note: If 'w9968cf-vpp' is not present, this parameter is set to 9. -------------------------------------------------------------------------------- -Name: force_rgb -Type: bool array (min = 0, max = 32) -Syntax: <0|1[,...]> -Description: Read RGB video data instead of BGR: - 1 = use RGB component ordering. - 0 = use BGR component ordering. - This parameter has effect when using RGBX palettes only. -Default: 0 for every device. -------------------------------------------------------------------------------- -Name: autobright -Type: bool array (min = 0, max = 32) -Syntax: <0|1[,...]> -Description: Image sensor automatically changes brightness: - 0 = no, 1 = yes -Default: 0 for every device. -------------------------------------------------------------------------------- -Name: autoexp -Type: bool array (min = 0, max = 32) -Syntax: <0|1[,...]> -Description: Image sensor automatically changes exposure: - 0 = no, 1 = yes -Default: 1 for every device. -------------------------------------------------------------------------------- -Name: lightfreq -Type: int array (min = 0, max = 32) -Syntax: <50|60[,...]> -Description: Light frequency in Hz: - 50 for European and Asian lighting, 60 for American lighting. -Default: 50 for every device. -------------------------------------------------------------------------------- -Name: bandingfilter -Type: bool array (min = 0, max = 32) -Syntax: <0|1[,...]> -Description: Banding filter to reduce effects of fluorescent - lighting: - 0 disabled, 1 enabled. - This filter tries to reduce the pattern of horizontal - light/dark bands caused by some (usually fluorescent) lighting. -Default: 0 for every device. -------------------------------------------------------------------------------- -Name: clockdiv -Type: int array (min = 0, max = 32) -Syntax: <-1|n[,...]> -Description: Force pixel clock divisor to a specific value (for experts): - n may vary from 0 to 127. - -1 for automatic value. - See also the 'double_buffer' module parameter. -Default: -1 for every device. -------------------------------------------------------------------------------- -Name: backlight -Type: bool array (min = 0, max = 32) -Syntax: <0|1[,...]> -Description: Objects are lit from behind: - 0 = no, 1 = yes -Default: 0 for every device. -------------------------------------------------------------------------------- -Name: mirror -Type: bool array (min = 0, max = 32) -Syntax: <0|1[,...]> -Description: Reverse image horizontally: - 0 = no, 1 = yes -Default: 0 for every device. -------------------------------------------------------------------------------- -Name: monochrome -Type: bool array (min = 0, max = 32) -Syntax: <0|1[,...]> -Description: The image sensor is monochrome: - 0 = no, 1 = yes -Default: 0 for every device. -------------------------------------------------------------------------------- -Name: brightness -Type: long array (min = 0, max = 32) -Syntax: -Description: Set picture brightness (0-65535). - This parameter has no effect if 'autobright' is enabled. -Default: 31000 for every device. -------------------------------------------------------------------------------- -Name: hue -Type: long array (min = 0, max = 32) -Syntax: -Description: Set picture hue (0-65535). -Default: 32768 for every device. -------------------------------------------------------------------------------- -Name: colour -Type: long array (min = 0, max = 32) -Syntax: -Description: Set picture saturation (0-65535). -Default: 32768 for every device. -------------------------------------------------------------------------------- -Name: contrast -Type: long array (min = 0, max = 32) -Syntax: -Description: Set picture contrast (0-65535). -Default: 50000 for every device. -------------------------------------------------------------------------------- -Name: whiteness -Type: long array (min = 0, max = 32) -Syntax: -Description: Set picture whiteness (0-65535). -Default: 32768 for every device. -------------------------------------------------------------------------------- -Name: debug -Type: int -Syntax: -Description: Debugging information level, from 0 to 6: - 0 = none (use carefully) - 1 = critical errors - 2 = significant information - 3 = configuration or general messages - 4 = warnings - 5 = called functions - 6 = function internals - Level 5 and 6 are useful for testing only, when only one - device is used. -Default: 2 -------------------------------------------------------------------------------- -Name: specific_debug -Type: bool -Syntax: <0|1> -Description: Enable or disable specific debugging messages: - 0 = print messages concerning every level <= 'debug' level. - 1 = print messages concerning the level indicated by 'debug'. -Default: 0 -------------------------------------------------------------------------------- - - -9. Contact information -====================== -I may be contacted by e-mail at . - -I can accept GPG/PGP encrypted e-mail. My GPG key ID is 'FCE635A4'. -My public 1024-bit key should be available at your keyserver; the fingerprint -is: '88E8 F32F 7244 68BA 3958 5D40 99DA 5D2A FCE6 35A4'. - - -10. Credits -========== -The development would not have proceed much further without having looked at -the source code of other drivers and without the help of several persons; in -particular: - -- the I2C interface to kernel and high-level image sensor control routines have - been taken from the OV511 driver by Mark McClelland; - -- memory management code has been copied from the bttv driver by Ralph Metzler, - Marcus Metzler and Gerd Knorr; - -- the low-level I2C read function has been written by Frederic Jouault; - -- the low-level I2C fast write function has been written by Piotr Czerczak. diff --git a/Documentation/video4linux/zc0301.txt b/Documentation/video4linux/zc0301.txt deleted file mode 100644 index b41c83cf09f4..000000000000 --- a/Documentation/video4linux/zc0301.txt +++ /dev/null @@ -1,270 +0,0 @@ - - ZC0301 and ZC0301P Image Processor and Control Chip - Driver for Linux - =================================================== - - - Documentation - - - -Index -===== -1. Copyright -2. Disclaimer -3. License -4. Overview and features -5. Module dependencies -6. Module loading -7. Module parameters -8. Supported devices -9. Notes for V4L2 application developers -10. Contact information -11. Credits - - -1. Copyright -============ -Copyright (C) 2006-2007 by Luca Risolia - - -2. Disclaimer -============= -This software is not developed or sponsored by Z-Star Microelectronics Corp. -Trademarks are property of their respective owner. - - -3. License -========== -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; either version 2 of the License, or -(at your option) any later version. - -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. - -You should have received a copy of the GNU General Public License -along with this program; if not, write to the Free Software -Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. - - -4. Overview and features -======================== -This driver supports the video interface of the devices mounting the ZC0301 or -ZC0301P Image Processors and Control Chips. - -The driver relies on the Video4Linux2 and USB core modules. It has been -designed to run properly on SMP systems as well. - -The latest version of the ZC0301[P] driver can be found at the following URL: -http://www.linux-projects.org/ - -Some of the features of the driver are: - -- full compliance with the Video4Linux2 API (see also "Notes for V4L2 - application developers" paragraph); -- available mmap or read/poll methods for video streaming through isochronous - data transfers; -- automatic detection of image sensor; -- video format is standard JPEG; -- dynamic driver control thanks to various module parameters (see "Module - parameters" paragraph); -- up to 64 cameras can be handled at the same time; they can be connected and - disconnected from the host many times without turning off the computer, if - the system supports hotplugging; - - -5. Module dependencies -====================== -For it to work properly, the driver needs kernel support for Video4Linux and -USB. - -The following options of the kernel configuration file must be enabled and -corresponding modules must be compiled: - - # Multimedia devices - # - CONFIG_VIDEO_DEV=m - - # USB support - # - CONFIG_USB=m - -In addition, depending on the hardware being used, the modules below are -necessary: - - # USB Host Controller Drivers - # - CONFIG_USB_EHCI_HCD=m - CONFIG_USB_UHCI_HCD=m - CONFIG_USB_OHCI_HCD=m - -The ZC0301 controller also provides a built-in microphone interface. It is -supported by the USB Audio driver thanks to the ALSA API: - - # Sound - # - CONFIG_SOUND=y - - # Advanced Linux Sound Architecture - # - CONFIG_SND=m - - # USB devices - # - CONFIG_SND_USB_AUDIO=m - -And finally: - - # V4L USB devices - # - CONFIG_USB_ZC0301=m - - -6. Module loading -================= -To use the driver, it is necessary to load the "zc0301" module into memory -after every other module required: "videodev", "v4l2_common", "compat_ioctl32", -"usbcore" and, depending on the USB host controller you have, "ehci-hcd", -"uhci-hcd" or "ohci-hcd". - -Loading can be done as shown below: - - [root@localhost home]# modprobe zc0301 - -At this point the devices should be recognized. You can invoke "dmesg" to -analyze kernel messages and verify that the loading process has gone well: - - [user@localhost home]$ dmesg - - -7. Module parameters -==================== -Module parameters are listed below: -------------------------------------------------------------------------------- -Name: video_nr -Type: short array (min = 0, max = 64) -Syntax: <-1|n[,...]> -Description: Specify V4L2 minor mode number: - -1 = use next available - n = use minor number n - You can specify up to 64 cameras this way. - For example: - video_nr=-1,2,-1 would assign minor number 2 to the second - registered camera and use auto for the first one and for every - other camera. -Default: -1 -------------------------------------------------------------------------------- -Name: force_munmap -Type: bool array (min = 0, max = 64) -Syntax: <0|1[,...]> -Description: Force the application to unmap previously mapped buffer memory - before calling any VIDIOC_S_CROP or VIDIOC_S_FMT ioctl's. Not - all the applications support this feature. This parameter is - specific for each detected camera. - 0 = do not force memory unmapping - 1 = force memory unmapping (save memory) -Default: 0 -------------------------------------------------------------------------------- -Name: frame_timeout -Type: uint array (min = 0, max = 64) -Syntax: -Description: Timeout for a video frame in seconds. This parameter is - specific for each detected camera. This parameter can be - changed at runtime thanks to the /sys filesystem interface. -Default: 2 -------------------------------------------------------------------------------- -Name: debug -Type: ushort -Syntax: -Description: Debugging information level, from 0 to 3: - 0 = none (use carefully) - 1 = critical errors - 2 = significant information - 3 = more verbose messages - Level 3 is useful for testing only, when only one device - is used at the same time. It also shows some information - about the hardware being detected. This module parameter can be - changed at runtime thanks to the /sys filesystem interface. -Default: 2 -------------------------------------------------------------------------------- - - -8. Supported devices -==================== -None of the names of the companies as well as their products will be mentioned -here. They have never collaborated with the author, so no advertising. - -From the point of view of a driver, what unambiguously identify a device are -its vendor and product USB identifiers. Below is a list of known identifiers of -devices mounting the ZC0301 Image Processor and Control Chips: - -Vendor ID Product ID ---------- ---------- -0x041e 0x4017 -0x041e 0x401c -0x041e 0x401e -0x041e 0x401f -0x041e 0x4022 -0x041e 0x4034 -0x041e 0x4035 -0x041e 0x4036 -0x041e 0x403a -0x0458 0x7007 -0x0458 0x700c -0x0458 0x700f -0x046d 0x08ae -0x055f 0xd003 -0x055f 0xd004 -0x0ac8 0x0301 -0x0ac8 0x301b -0x0ac8 0x303b -0x10fd 0x0128 -0x10fd 0x8050 -0x10fd 0x804e - -The list above does not imply that all those devices work with this driver: up -until now only the ones that mount the following image sensors are supported; -kernel messages will always tell you whether this is the case: - -Model Manufacturer ------ ------------ -PAS202BCB PixArt Imaging, Inc. -PB-0330 Photobit Corporation - - -9. Notes for V4L2 application developers -======================================== -This driver follows the V4L2 API specifications. In particular, it enforces two -rules: - -- exactly one I/O method, either "mmap" or "read", is associated with each -file descriptor. Once it is selected, the application must close and reopen the -device to switch to the other I/O method; - -- although it is not mandatory, previously mapped buffer memory should always -be unmapped before calling any "VIDIOC_S_CROP" or "VIDIOC_S_FMT" ioctl's. -The same number of buffers as before will be allocated again to match the size -of the new video frames, so you have to map the buffers again before any I/O -attempts on them. - - -10. Contact information -======================= -The author may be contacted by e-mail at . - -GPG/PGP encrypted e-mail's are accepted. The GPG key ID of the author is -'FCE635A4'; the public 1024-bit key should be available at any keyserver; -the fingerprint is: '88E8 F32F 7244 68BA 3958 5D40 99DA 5D2A FCE6 35A4'. - - -11. Credits -=========== -- Information about the chip internals needed to enable the I2C protocol have - been taken from the documentation of the ZC030x Video4Linux1 driver written - by Andrew Birkett ; -- The initialization values of the ZC0301 controller connected to the PAS202BCB - and PB-0330 image sensors have been taken from the SPCA5XX driver maintained - by Michel Xhaard ; -- Stanislav Lechev donated one camera. -- cgit v1.2.3-59-g8ed1b From f6b70ec509a393a966d1307f3e8a89341ee9e7f1 Mon Sep 17 00:00:00 2001 From: Antonio Ospite Date: Mon, 10 Dec 2012 17:37:16 -0300 Subject: [media] get_dvb_firmware: add entry for the vp7049 firmware Add an entry to download the dvb-usb-vp7049-0.95.fw firmware for the Twinhan vp7049 and similar devices. Known devices of this kind are: Twinhan/Azurewave DTV-DVB UDTT7049 Digicom Digitune-S Think Xtra Hollywood DVB-T USB2.0 Signed-off-by: Antonio Ospite Signed-off-by: Mauro Carvalho Chehab --- Documentation/dvb/get_dvb_firmware | 15 ++++++++++++++- 1 file changed, 14 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/dvb/get_dvb_firmware b/Documentation/dvb/get_dvb_firmware index 32bc56b13b1c..0cdb1570ffb4 100755 --- a/Documentation/dvb/get_dvb_firmware +++ b/Documentation/dvb/get_dvb_firmware @@ -23,7 +23,7 @@ use IO::Handle; @components = ( "sp8870", "sp887x", "tda10045", "tda10046", "tda10046lifeview", "av7110", "dec2000t", "dec2540t", - "dec3000s", "vp7041", "dibusb", "nxt2002", "nxt2004", + "dec3000s", "vp7041", "vp7049", "dibusb", "nxt2002", "nxt2004", "or51211", "or51132_qam", "or51132_vsb", "bluebird", "opera1", "cx231xx", "cx18", "cx23885", "pvrusb2", "mpc718", "af9015", "ngene", "az6027", "lme2510_lg", "lme2510c_s7395", @@ -289,6 +289,19 @@ sub vp7041 { $outfile; } +sub vp7049 { + my $fwfile = "dvb-usb-vp7049-0.95.fw"; + my $url = "http://ao2.it/sites/default/files/blog/2012/11/06/linux-support-digicom-digitune-s-vp7049-udtt7049/$fwfile"; + my $hash = "5609fd295168aea88b25ff43a6f79c36"; + + checkstandard(); + + wgetfile($fwfile, $url); + verify($fwfile, $hash); + + $fwfile; +} + sub dibusb { my $url = "http://www.linuxtv.org/downloads/firmware/dvb-usb-dibusb-5.0.0.11.fw"; my $outfile = "dvb-dibusb-5.0.0.11.fw"; -- cgit v1.2.3-59-g8ed1b From 8cd7085ff460ead3aba6174052a408f4ad52ac36 Mon Sep 17 00:00:00 2001 From: Martin Blumenstingl Date: Tue, 1 Jan 2013 08:54:26 -0300 Subject: [media] get_dvb_firmware: Fix the location of firmware for Terratec HTC Fix firmware download for the Terratec Cinergy HTC Stick HD. The file was moved on the server. Signed-off-by: Martin Blumenstingl Signed-off-by: Mauro Carvalho Chehab --- Documentation/dvb/get_dvb_firmware | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/dvb/get_dvb_firmware b/Documentation/dvb/get_dvb_firmware index 0cdb1570ffb4..5d5ee4c13fa6 100755 --- a/Documentation/dvb/get_dvb_firmware +++ b/Documentation/dvb/get_dvb_firmware @@ -690,7 +690,7 @@ sub drxk_terratec_h5 { } sub drxk_terratec_htc_stick { - my $url = "http://ftp.terratec.de/Receiver/Cinergy_HTC_Stick/Updates/"; + my $url = "http://ftp.terratec.de/Receiver/Cinergy_HTC_Stick/Updates/History/"; my $zipfile = "Cinergy_HTC_Stick_Drv_5.09.1202.00_XP_Vista_7.exe"; my $hash = "6722a2442a05423b781721fbc069ed5e"; my $tmpdir = tempdir(DIR => "/tmp", CLEANUP => 0); -- cgit v1.2.3-59-g8ed1b From 8ac7a9493a4380a8a886fbfe311ab00bc424ca0f Mon Sep 17 00:00:00 2001 From: Hans Verkuil Date: Fri, 7 Sep 2012 04:46:39 -0300 Subject: [media] v4l2-ctrls: add a notify callback Sometimes platform/bridge drivers need to be notified when a control from a sub-device changes value. In order to support this a notify callback was added. [dheitmueller@kernellabs.com: fix merge conflict in v4l2-ctrls.c] Signed-off-by: Hans Verkuil Signed-off-by: Devin Heitmueller Signed-off-by: Mauro Carvalho Chehab --- Documentation/video4linux/v4l2-controls.txt | 22 ++++++++++++++-------- drivers/media/v4l2-core/v4l2-ctrls.c | 18 ++++++++++++++++++ include/media/v4l2-ctrls.h | 25 +++++++++++++++++++++++++ 3 files changed, 57 insertions(+), 8 deletions(-) (limited to 'Documentation') diff --git a/Documentation/video4linux/v4l2-controls.txt b/Documentation/video4linux/v4l2-controls.txt index cfe52c798d74..676f87366025 100644 --- a/Documentation/video4linux/v4l2-controls.txt +++ b/Documentation/video4linux/v4l2-controls.txt @@ -715,14 +715,20 @@ a control of this type whenever the first control belonging to a new control class is added. -Proposals for Extensions -======================== +Adding Notify Callbacks +======================= + +Sometimes the platform or bridge driver needs to be notified when a control +from a sub-device driver changes. You can set a notify callback by calling +this function: -Some ideas for future extensions to the spec: +void v4l2_ctrl_notify(struct v4l2_ctrl *ctrl, + void (*notify)(struct v4l2_ctrl *ctrl, void *priv), void *priv); -1) Add a V4L2_CTRL_FLAG_HEX to have values shown as hexadecimal instead of -decimal. Useful for e.g. video_mute_yuv. +Whenever the give control changes value the notify callback will be called +with a pointer to the control and the priv pointer that was passed with +v4l2_ctrl_notify. Note that the control's handler lock is held when the +notify function is called. -2) It is possible to mark in the controls array which controls have been -successfully written and which failed by for example adding a bit to the -control ID. Not sure if it is worth the effort, though. +There can be only one notify function per control handler. Any attempt +to set another notify function will cause a WARN_ON. diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c b/drivers/media/v4l2-core/v4l2-ctrls.c index f6ee201d9347..fa02363e7db4 100644 --- a/drivers/media/v4l2-core/v4l2-ctrls.c +++ b/drivers/media/v4l2-core/v4l2-ctrls.c @@ -1204,6 +1204,8 @@ static void new_to_cur(struct v4l2_fh *fh, struct v4l2_ctrl *ctrl, send_event(fh, ctrl, (changed ? V4L2_EVENT_CTRL_CH_VALUE : 0) | (update_inactive ? V4L2_EVENT_CTRL_CH_FLAGS : 0)); + if (ctrl->call_notify && changed && ctrl->handler->notify) + ctrl->handler->notify(ctrl, ctrl->handler->notify_priv); } } @@ -2725,6 +2727,22 @@ int v4l2_ctrl_s_ctrl_int64(struct v4l2_ctrl *ctrl, s64 val) } EXPORT_SYMBOL(v4l2_ctrl_s_ctrl_int64); +void v4l2_ctrl_notify(struct v4l2_ctrl *ctrl, v4l2_ctrl_notify_fnc notify, void *priv) +{ + if (ctrl == NULL) + return; + if (notify == NULL) { + ctrl->call_notify = 0; + return; + } + if (WARN_ON(ctrl->handler->notify && ctrl->handler->notify != notify)) + return; + ctrl->handler->notify = notify; + ctrl->handler->notify_priv = priv; + ctrl->call_notify = 1; +} +EXPORT_SYMBOL(v4l2_ctrl_notify); + static int v4l2_ctrl_add_event(struct v4l2_subscribed_event *sev, unsigned elems) { struct v4l2_ctrl *ctrl = v4l2_ctrl_find(sev->fh->ctrl_handler, sev->id); diff --git a/include/media/v4l2-ctrls.h b/include/media/v4l2-ctrls.h index 96509119f28f..c4cc04136074 100644 --- a/include/media/v4l2-ctrls.h +++ b/include/media/v4l2-ctrls.h @@ -53,6 +53,8 @@ struct v4l2_ctrl_ops { int (*s_ctrl)(struct v4l2_ctrl *ctrl); }; +typedef void (*v4l2_ctrl_notify_fnc)(struct v4l2_ctrl *ctrl, void *priv); + /** struct v4l2_ctrl - The control structure. * @node: The list node. * @ev_subs: The list of control event subscriptions. @@ -72,6 +74,8 @@ struct v4l2_ctrl_ops { * set this flag directly. * @has_volatiles: If set, then one or more members of the cluster are volatile. * Drivers should never touch this flag. + * @call_notify: If set, then call the handler's notify function whenever the + * control's value changes. * @manual_mode_value: If the is_auto flag is set, then this is the value * of the auto control that determines if that control is in * manual mode. So if the value of the auto control equals this @@ -119,6 +123,7 @@ struct v4l2_ctrl { unsigned int is_private:1; unsigned int is_auto:1; unsigned int has_volatiles:1; + unsigned int call_notify:1; unsigned int manual_mode_value:8; const struct v4l2_ctrl_ops *ops; @@ -177,6 +182,10 @@ struct v4l2_ctrl_ref { * control is needed multiple times, so this is a simple * optimization. * @buckets: Buckets for the hashing. Allows for quick control lookup. + * @notify: A notify callback that is called whenever the control changes value. + * Note that the handler's lock is held when the notify function + * is called! + * @notify_priv: Passed as argument to the v4l2_ctrl notify callback. * @nr_of_buckets: Total number of buckets in the array. * @error: The error code of the first failed control addition. */ @@ -187,6 +196,8 @@ struct v4l2_ctrl_handler { struct list_head ctrl_refs; struct v4l2_ctrl_ref *cached; struct v4l2_ctrl_ref **buckets; + v4l2_ctrl_notify_fnc notify; + void *notify_priv; u16 nr_of_buckets; int error; }; @@ -525,6 +536,20 @@ static inline void v4l2_ctrl_unlock(struct v4l2_ctrl *ctrl) mutex_unlock(ctrl->handler->lock); } +/** v4l2_ctrl_notify() - Function to set a notify callback for a control. + * @ctrl: The control. + * @notify: The callback function. + * @priv: The callback private handle, passed as argument to the callback. + * + * This function sets a callback function for the control. If @ctrl is NULL, + * then it will do nothing. If @notify is NULL, then the notify callback will + * be removed. + * + * There can be only one notify. If another already exists, then a WARN_ON + * will be issued and the function will do nothing. + */ +void v4l2_ctrl_notify(struct v4l2_ctrl *ctrl, v4l2_ctrl_notify_fnc notify, void *priv); + /** v4l2_ctrl_g_ctrl() - Helper function to get the control's value from within a driver. * @ctrl: The control. * -- cgit v1.2.3-59-g8ed1b From 24b9f50170f55a3179c6f6d51022eb7d50502d05 Mon Sep 17 00:00:00 2001 From: Sylwester Nawrocki Date: Thu, 3 Jan 2013 12:30:30 -0300 Subject: [media] V4L: Remove deprecated image centering controls It has been over 3 years since the V4L2_CID_[HV]CENTER were deprecated. Clean up the DocBook and remove the V4L2_CID_VCENTER_DEPRECATED, V4L2_CID_VCENTER_DEPRECATED control related paragraphs. Remove the V4L2_CID_[HV]CENTER controls definitions from v4l2-controls.h, these controls are not used by any driver in the mainline now. Signed-off-by: Sylwester Nawrocki Signed-off-by: Mauro Carvalho Chehab --- Documentation/DocBook/media/v4l/controls.xml | 23 ----------------------- drivers/media/v4l2-core/v4l2-ctrls.c | 2 -- include/uapi/linux/v4l2-controls.h | 4 ---- 3 files changed, 29 deletions(-) (limited to 'Documentation') diff --git a/Documentation/DocBook/media/v4l/controls.xml b/Documentation/DocBook/media/v4l/controls.xml index 7fe5be1d3bbb..9e8f85498678 100644 --- a/Documentation/DocBook/media/v4l/controls.xml +++ b/Documentation/DocBook/media/v4l/controls.xml @@ -203,29 +203,6 @@ and should not be used in new drivers and applications. boolean Mirror the picture vertically. - - V4L2_CID_HCENTER_DEPRECATED (formerly V4L2_CID_HCENTER) - integer - Horizontal image centering. This control is -deprecated. New drivers and applications should use the Camera class controls -V4L2_CID_PAN_ABSOLUTE, -V4L2_CID_PAN_RELATIVE and -V4L2_CID_PAN_RESET instead. - - - V4L2_CID_VCENTER_DEPRECATED - (formerly V4L2_CID_VCENTER) - integer - Vertical image centering. Centering is intended to -physically adjust cameras. For image cropping see -, for clipping . This -control is deprecated. New drivers and applications should use the -Camera class controls -V4L2_CID_TILT_ABSOLUTE, -V4L2_CID_TILT_RELATIVE and -V4L2_CID_TILT_RESET instead. - V4L2_CID_POWER_LINE_FREQUENCY enum diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c b/drivers/media/v4l2-core/v4l2-ctrls.c index fa02363e7db4..7b486ac3f4d9 100644 --- a/drivers/media/v4l2-core/v4l2-ctrls.c +++ b/drivers/media/v4l2-core/v4l2-ctrls.c @@ -577,8 +577,6 @@ const char *v4l2_ctrl_get_name(u32 id) case V4L2_CID_GAIN: return "Gain"; case V4L2_CID_HFLIP: return "Horizontal Flip"; case V4L2_CID_VFLIP: return "Vertical Flip"; - case V4L2_CID_HCENTER: return "Horizontal Center"; - case V4L2_CID_VCENTER: return "Vertical Center"; case V4L2_CID_POWER_LINE_FREQUENCY: return "Power Line Frequency"; case V4L2_CID_HUE_AUTO: return "Hue, Automatic"; case V4L2_CID_WHITE_BALANCE_TEMPERATURE: return "White Balance Temperature"; diff --git a/include/uapi/linux/v4l2-controls.h b/include/uapi/linux/v4l2-controls.h index f56c945cecd4..4dc0822700fe 100644 --- a/include/uapi/linux/v4l2-controls.h +++ b/include/uapi/linux/v4l2-controls.h @@ -88,10 +88,6 @@ #define V4L2_CID_HFLIP (V4L2_CID_BASE+20) #define V4L2_CID_VFLIP (V4L2_CID_BASE+21) -/* Deprecated; use V4L2_CID_PAN_RESET and V4L2_CID_TILT_RESET */ -#define V4L2_CID_HCENTER (V4L2_CID_BASE+22) -#define V4L2_CID_VCENTER (V4L2_CID_BASE+23) - #define V4L2_CID_POWER_LINE_FREQUENCY (V4L2_CID_BASE+24) enum v4l2_power_line_frequency { V4L2_CID_POWER_LINE_FREQUENCY_DISABLED = 0, -- cgit v1.2.3-59-g8ed1b From 1c612e9a1cf712bd7845e3adb4961e3ef8eaf8aa Mon Sep 17 00:00:00 2001 From: Prabhakar Lad Date: Wed, 2 Jan 2013 02:08:15 -0300 Subject: [media] s5p-fimc: Fix typo of URL pointing to Media Controller API's Signed-off-by: Lad, Prabhakar Signed-off-by: Mauro Carvalho Chehab --- Documentation/video4linux/fimc.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/video4linux/fimc.txt b/Documentation/video4linux/fimc.txt index fd02d9a4930a..25f4d3402722 100644 --- a/Documentation/video4linux/fimc.txt +++ b/Documentation/video4linux/fimc.txt @@ -58,7 +58,7 @@ Not currently supported: 4.1. Media device interface The driver supports Media Controller API as defined at -http://http://linuxtv.org/downloads/v4l-dvb-apis/media_common.html +http://linuxtv.org/downloads/v4l-dvb-apis/media_common.html The media device driver name is "SAMSUNG S5P FIMC". The purpose of this interface is to allow changing assignment of FIMC instances -- cgit v1.2.3-59-g8ed1b From 978ae2247fac3b330ecd1095823001d2c08c7efd Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Fri, 11 Jan 2013 13:01:37 -0200 Subject: [media] extract_xc3028.pl: fix permissions This is an executable file. Change permissions to reflect it. Signed-off-by: Mauro Carvalho Chehab --- Documentation/video4linux/extract_xc3028.pl | 0 1 file changed, 0 insertions(+), 0 deletions(-) mode change 100644 => 100755 Documentation/video4linux/extract_xc3028.pl (limited to 'Documentation') diff --git a/Documentation/video4linux/extract_xc3028.pl b/Documentation/video4linux/extract_xc3028.pl old mode 100644 new mode 100755 -- cgit v1.2.3-59-g8ed1b From 9569793a79836320c33d400c686dcb78f886bdad Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Sun, 6 Jan 2013 12:22:06 -0300 Subject: [media] dvb: Add DVBv5 statistics properties The DVBv3 statistics parameters are limited on several ways: - It doesn't provide any way to indicate the used measure, so userspace need to guess how to calculate/use it; - Only a limited set of stats are supported; - Can't be called in a way to require them to be filled all at once (atomic reads from the hardware), with may cause troubles on interpreting them on userspace; - On some OFDM delivery systems, the carriers can be independently modulated, having different properties. Currently, there's no way to report per-layer stats. To address the above issues, adding a new DVBv5-based stats API. While here, correct inner code nomenclature on a few places. Reviewed-by: Antti Palosaari Signed-off-by: Mauro Carvalho Chehab --- Documentation/DocBook/media/dvb/dvbapi.xml | 2 +- Documentation/DocBook/media/dvb/dvbproperty.xml | 180 +++++++++++++++++++++++- Documentation/DocBook/media/dvb/frontend.xml | 2 +- include/uapi/linux/dvb/frontend.h | 79 ++++++++++- include/uapi/linux/dvb/version.h | 2 +- 5 files changed, 260 insertions(+), 5 deletions(-) (limited to 'Documentation') diff --git a/Documentation/DocBook/media/dvb/dvbapi.xml b/Documentation/DocBook/media/dvb/dvbapi.xml index 757488b24f4f..0197bcc7842d 100644 --- a/Documentation/DocBook/media/dvb/dvbapi.xml +++ b/Documentation/DocBook/media/dvb/dvbapi.xml @@ -84,7 +84,7 @@ Added ISDB-T test originally written by Patrick Boettcher LINUX DVB API -Version 5.8 +Version 5.10 &sub-intro; diff --git a/Documentation/DocBook/media/dvb/dvbproperty.xml b/Documentation/DocBook/media/dvb/dvbproperty.xml index 957e3acaae8e..4a5eaeed0b9e 100644 --- a/Documentation/DocBook/media/dvb/dvbproperty.xml +++ b/Documentation/DocBook/media/dvb/dvbproperty.xml @@ -7,14 +7,41 @@ the capability ioctls weren't implemented yet via the new way. The typical usage for the FE_GET_PROPERTY/FE_SET_PROPERTY API is to replace the ioctl's were the struct dvb_frontend_parameters were used. +
+DTV stats type + +struct dtv_stats { + __u8 scale; /* enum fecap_scale_params type */ + union { + __u64 uvalue; /* for counters and relative scales */ + __s64 svalue; /* for 1/1000 dB measures */ + }; +} __packed; + +
+
+DTV stats type + +#define MAX_DTV_STATS 4 + +struct dtv_fe_stats { + __u8 len; + struct dtv_stats stat[MAX_DTV_STATS]; +} __packed; + +
+
DTV property type /* Reserved fields should be set to 0 */ + struct dtv_property { __u32 cmd; + __u32 reserved[3]; union { __u32 data; + struct dtv_fe_stats st; struct { __u8 data[32]; __u32 len; @@ -440,7 +467,7 @@ typedef enum fe_delivery_system { <constant>DTV-ISDBT-LAYER*</constant> parameters ISDB-T channels can be coded hierarchically. As opposed to DVB-T in ISDB-T hierarchical layers can be decoded simultaneously. For that - reason a ISDB-T demodulator has 3 viterbi and 3 reed-solomon-decoders. + reason a ISDB-T demodulator has 3 Viterbi and 3 Reed-Solomon decoders. ISDB-T has 3 hierarchical layers which each can use a part of the available segments. The total number of segments over all layers has to 13 in ISDB-T. @@ -850,6 +877,147 @@ enum fe_interleaving { use the special macro LNA_AUTO to set LNA auto
+ +
+ Frontend statistics indicators + The values are returned via dtv_property.stat. + If the property is supported, dtv_property.stat.len is bigger than zero. + For most delivery systems, dtv_property.stat.len + will be 1 if the stats is supported, and the properties will + return a single value for each parameter. + It should be noticed, however, that new OFDM delivery systems + like ISDB can use different modulation types for each group of + carriers. On such standards, up to 3 groups of statistics can be + provided, and dtv_property.stat.len is updated + to reflect the "global" metrics, plus one metric per each carrier + group (called "layer" on ISDB). + So, in order to be consistent with other delivery systems, the first + value at dtv_property.stat.dtv_stats + array refers to the global metric. The other elements of the array + represent each layer, starting from layer A(index 1), + layer B (index 2) and so on. + The number of filled elements are stored at dtv_property.stat.len. + Each element of the dtv_property.stat.dtv_stats array consists on two elements: + + svalue or uvalue, where + svalue is for signed values of the measure (dB measures) + and uvalue is for unsigned values (counters, relative scale) + scale - Scale for the value. It can be: +
+ + FE_SCALE_NOT_AVAILABLE - The parameter is supported by the frontend, but it was not possible to collect it (could be a transitory or permanent condition) + FE_SCALE_DECIBEL - parameter is a signed value, measured in 1/1000 dB + FE_SCALE_RELATIVE - parameter is a unsigned value, where 0 means 0% and 65535 means 100%. + FE_SCALE_COUNTER - parameter is a unsigned value that counts the occurrence of an event, like bit error, block error, or lapsed time. + +
+ + +
+ <constant>DTV_STAT_SIGNAL_STRENGTH</constant> + Indicates the signal strength level at the analog part of the tuner or of the demod. + Possible scales for this metric are: + + FE_SCALE_NOT_AVAILABLE - it failed to measure it, or the measurement was not complete yet. + FE_SCALE_DECIBEL - signal strength is in 0.0001 dBm units, power measured in miliwatts. This value is generally negative. + FE_SCALE_RELATIVE - The frontend provides a 0% to 100% measurement for power (actually, 0 to 65535). + +
+
+ <constant>DTV_STAT_CNR</constant> + Indicates the Signal to Noise ratio for the main carrier. + Possible scales for this metric are: + + FE_SCALE_NOT_AVAILABLE - it failed to measure it, or the measurement was not complete yet. + FE_SCALE_DECIBEL - Signal/Noise ratio is in 0.0001 dB units. + FE_SCALE_RELATIVE - The frontend provides a 0% to 100% measurement for Signal/Noise (actually, 0 to 65535). + +
+
+ <constant>DTV_STAT_PRE_ERROR_BIT_COUNT</constant> + Measures the number of bit errors before the forward error correction (FEC) on the inner coding block (before Viterbi, LDPC or other inner code). + This measure is taken during the same interval as DTV_STAT_PRE_TOTAL_BIT_COUNT. + In order to get the BER (Bit Error Rate) measurement, it should be divided by + DTV_STAT_PRE_TOTAL_BIT_COUNT. + This measurement is monotonically increased, as the frontend gets more bit count measurements. + The frontend may reset it when a channel/transponder is tuned. + Possible scales for this metric are: + + FE_SCALE_NOT_AVAILABLE - it failed to measure it, or the measurement was not complete yet. + FE_SCALE_COUNTER - Number of error bits counted before the inner coding. + +
+
+ <constant>DTV_STAT_PRE_TOTAL_BIT_COUNT</constant> + Measures the amount of bits received before the inner code block, during the same period as + DTV_STAT_PRE_ERROR_BIT_COUNT measurement was taken. + It should be noticed that this measurement can be smaller than the total amount of bits on the transport stream, + as the frontend may need to manually restart the measurement, loosing some data between each measurement interval. + This measurement is monotonically increased, as the frontend gets more bit count measurements. + The frontend may reset it when a channel/transponder is tuned. + Possible scales for this metric are: + + FE_SCALE_NOT_AVAILABLE - it failed to measure it, or the measurement was not complete yet. + FE_SCALE_COUNTER - Number of bits counted while measuring + DTV_STAT_PRE_ERROR_BIT_COUNT. + +
+
+ <constant>DTV_STAT_POST_ERROR_BIT_COUNT</constant> + Measures the number of bit errors after the forward error correction (FEC) done by inner code block (after Viterbi, LDPC or other inner code). + This measure is taken during the same interval as DTV_STAT_POST_TOTAL_BIT_COUNT. + In order to get the BER (Bit Error Rate) measurement, it should be divided by + DTV_STAT_POST_TOTAL_BIT_COUNT. + This measurement is monotonically increased, as the frontend gets more bit count measurements. + The frontend may reset it when a channel/transponder is tuned. + Possible scales for this metric are: + + FE_SCALE_NOT_AVAILABLE - it failed to measure it, or the measurement was not complete yet. + FE_SCALE_COUNTER - Number of error bits counted after the inner coding. + +
+
+ <constant>DTV_STAT_POST_TOTAL_BIT_COUNT</constant> + Measures the amount of bits received after the inner coding, during the same period as + DTV_STAT_POST_ERROR_BIT_COUNT measurement was taken. + It should be noticed that this measurement can be smaller than the total amount of bits on the transport stream, + as the frontend may need to manually restart the measurement, loosing some data between each measurement interval. + This measurement is monotonically increased, as the frontend gets more bit count measurements. + The frontend may reset it when a channel/transponder is tuned. + Possible scales for this metric are: + + FE_SCALE_NOT_AVAILABLE - it failed to measure it, or the measurement was not complete yet. + FE_SCALE_COUNTER - Number of bits counted while measuring + DTV_STAT_POST_ERROR_BIT_COUNT. + +
+
+ <constant>DTV_STAT_ERROR_BLOCK_COUNT</constant> + Measures the number of block errors after the outer forward error correction coding (after Reed-Solomon or other outer code). + This measurement is monotonically increased, as the frontend gets more bit count measurements. + The frontend may reset it when a channel/transponder is tuned. + Possible scales for this metric are: + + FE_SCALE_NOT_AVAILABLE - it failed to measure it, or the measurement was not complete yet. + FE_SCALE_COUNTER - Number of error blocks counted after the outer coding. + +
+
+ <constant>DTV-STAT_TOTAL_BLOCK_COUNT</constant> + Measures the total number of blocks received during the same period as + DTV_STAT_ERROR_BLOCK_COUNT measurement was taken. + It can be used to calculate the PER indicator, by dividing + DTV_STAT_ERROR_BLOCK_COUNT + by DTV-STAT-TOTAL-BLOCK-COUNT. + Possible scales for this metric are: + + FE_SCALE_NOT_AVAILABLE - it failed to measure it, or the measurement was not complete yet. + FE_SCALE_COUNTER - Number of blocks counted while measuring + DTV_STAT_ERROR_BLOCK_COUNT. + +
+
+
Properties used on terrestrial delivery systems
@@ -871,6 +1039,7 @@ enum fe_interleaving { DTV_HIERARCHY DTV_LNA + In addition, the DTV QoS statistics are also valid.
DVB-T2 delivery system @@ -895,6 +1064,7 @@ enum fe_interleaving { DTV_STREAM_ID DTV_LNA + In addition, the DTV QoS statistics are also valid.
ISDB-T delivery system @@ -948,6 +1118,7 @@ enum fe_interleaving { DTV_ISDBT_LAYERC_SEGMENT_COUNT DTV_ISDBT_LAYERC_TIME_INTERLEAVING + In addition, the DTV QoS statistics are also valid.
ATSC delivery system @@ -961,6 +1132,7 @@ enum fe_interleaving { DTV_MODULATION DTV_BANDWIDTH_HZ + In addition, the DTV QoS statistics are also valid.
ATSC-MH delivery system @@ -988,6 +1160,7 @@ enum fe_interleaving { DTV_ATSCMH_SCCC_CODE_MODE_C DTV_ATSCMH_SCCC_CODE_MODE_D + In addition, the DTV QoS statistics are also valid.
DTMB delivery system @@ -1007,6 +1180,7 @@ enum fe_interleaving { DTV_INTERLEAVING DTV_LNA + In addition, the DTV QoS statistics are also valid.
@@ -1028,6 +1202,7 @@ enum fe_interleaving { DTV_INNER_FEC DTV_LNA + In addition, the DTV QoS statistics are also valid.
DVB-C Annex B delivery system @@ -1043,6 +1218,7 @@ enum fe_interleaving { DTV_INVERSION DTV_LNA + In addition, the DTV QoS statistics are also valid.
@@ -1062,6 +1238,7 @@ enum fe_interleaving { DTV_VOLTAGE DTV_TONE + In addition, the DTV QoS statistics are also valid. Future implementations might add those two missing parameters: DTV_DISEQC_MASTER @@ -1077,6 +1254,7 @@ enum fe_interleaving { DTV_ROLLOFF DTV_STREAM_ID + In addition, the DTV QoS statistics are also valid.
Turbo code delivery system diff --git a/Documentation/DocBook/media/dvb/frontend.xml b/Documentation/DocBook/media/dvb/frontend.xml index 426c2526a454..df39ba395df0 100644 --- a/Documentation/DocBook/media/dvb/frontend.xml +++ b/Documentation/DocBook/media/dvb/frontend.xml @@ -230,7 +230,7 @@ typedef enum fe_status { The frontend has found a DVB signal FE_HAS_VITERBI -The frontend FEC code is stable +The frontend FEC inner coding (Viterbi, LDPC or other inner code) is stable FE_HAS_SYNC Syncronization bytes was found diff --git a/include/uapi/linux/dvb/frontend.h b/include/uapi/linux/dvb/frontend.h index c12d452cb40d..c56d77c496a5 100644 --- a/include/uapi/linux/dvb/frontend.h +++ b/include/uapi/linux/dvb/frontend.h @@ -365,7 +365,17 @@ struct dvb_frontend_event { #define DTV_INTERLEAVING 60 #define DTV_LNA 61 -#define DTV_MAX_COMMAND DTV_LNA +/* Quality parameters */ +#define DTV_STAT_SIGNAL_STRENGTH 62 +#define DTV_STAT_CNR 63 +#define DTV_STAT_PRE_ERROR_BIT_COUNT 64 +#define DTV_STAT_PRE_TOTAL_BIT_COUNT 65 +#define DTV_STAT_POST_ERROR_BIT_COUNT 66 +#define DTV_STAT_POST_TOTAL_BIT_COUNT 67 +#define DTV_STAT_ERROR_BLOCK_COUNT 68 +#define DTV_STAT_TOTAL_BLOCK_COUNT 69 + +#define DTV_MAX_COMMAND DTV_STAT_TOTAL_BLOCK_COUNT typedef enum fe_pilot { PILOT_ON, @@ -452,11 +462,78 @@ struct dtv_cmds_h { __u32 reserved:30; /* Align */ }; +/** + * Scale types for the quality parameters. + * @FE_SCALE_NOT_AVAILABLE: That QoS measure is not available. That + * could indicate a temporary or a permanent + * condition. + * @FE_SCALE_DECIBEL: The scale is measured in 0.0001 dB steps, typically + * used on signal measures. + * @FE_SCALE_RELATIVE: The scale is a relative percentual measure, + * ranging from 0 (0%) to 0xffff (100%). + * @FE_SCALE_COUNTER: The scale counts the occurrence of an event, like + * bit error, block error, lapsed time. + */ +enum fecap_scale_params { + FE_SCALE_NOT_AVAILABLE = 0, + FE_SCALE_DECIBEL, + FE_SCALE_RELATIVE, + FE_SCALE_COUNTER +}; + +/** + * struct dtv_stats - Used for reading a DTV status property + * + * @value: value of the measure. Should range from 0 to 0xffff; + * @scale: Filled with enum fecap_scale_params - the scale + * in usage for that parameter + * + * For most delivery systems, this will return a single value for each + * parameter. + * It should be noticed, however, that new OFDM delivery systems like + * ISDB can use different modulation types for each group of carriers. + * On such standards, up to 8 groups of statistics can be provided, one + * for each carrier group (called "layer" on ISDB). + * In order to be consistent with other delivery systems, the first + * value refers to the entire set of carriers ("global"). + * dtv_status:scale should use the value FE_SCALE_NOT_AVAILABLE when + * the value for the entire group of carriers or from one specific layer + * is not provided by the hardware. + * st.len should be filled with the latest filled status + 1. + * + * In other words, for ISDB, those values should be filled like: + * u.st.stat.svalue[0] = global statistics; + * u.st.stat.scale[0] = FE_SCALE_DECIBELS; + * u.st.stat.value[1] = layer A statistics; + * u.st.stat.scale[1] = FE_SCALE_NOT_AVAILABLE (if not available); + * u.st.stat.svalue[2] = layer B statistics; + * u.st.stat.scale[2] = FE_SCALE_DECIBELS; + * u.st.stat.svalue[3] = layer C statistics; + * u.st.stat.scale[3] = FE_SCALE_DECIBELS; + * u.st.len = 4; + */ +struct dtv_stats { + __u8 scale; /* enum fecap_scale_params type */ + union { + __u64 uvalue; /* for counters and relative scales */ + __s64 svalue; /* for 0.0001 dB measures */ + }; +} __attribute__ ((packed)); + + +#define MAX_DTV_STATS 4 + +struct dtv_fe_stats { + __u8 len; + struct dtv_stats stat[MAX_DTV_STATS]; +} __attribute__ ((packed)); + struct dtv_property { __u32 cmd; __u32 reserved[3]; union { __u32 data; + struct dtv_fe_stats st; struct { __u8 data[32]; __u32 len; diff --git a/include/uapi/linux/dvb/version.h b/include/uapi/linux/dvb/version.h index 827cce7e33e3..e53e2ad4444f 100644 --- a/include/uapi/linux/dvb/version.h +++ b/include/uapi/linux/dvb/version.h @@ -24,6 +24,6 @@ #define _DVBVERSION_H_ #define DVB_API_VERSION 5 -#define DVB_API_VERSION_MINOR 9 +#define DVB_API_VERSION_MINOR 10 #endif /*_DVBVERSION_H_*/ -- cgit v1.2.3-59-g8ed1b From 2ccbe779bcdee130ea7f1525670dc9d60318a981 Mon Sep 17 00:00:00 2001 From: Sylwester Nawrocki Date: Sat, 19 Jan 2013 15:51:55 -0300 Subject: [media] v4l2-ctrl: Add helper function for the controls range update This patch adds a helper function that allows to modify range, i.e. minimum, maximum, step and default value of a v4l2 control, after the control has been created and initialized. This is helpful in situations when range of a control depends on user configurable parameters, e.g. camera sensor absolute exposure time depending on an output image resolution and frame rate. v4l2_ctrl_modify_range() function allows to modify range of an INTEGER, BOOL, MENU, INTEGER_MENU and BITMASK type controls. Based on a patch from Hans Verkuil http://patchwork.linuxtv.org/patch/8654. Signed-off-by: Sylwester Nawrocki Acked-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab --- Documentation/DocBook/media/v4l/compat.xml | 4 + Documentation/DocBook/media/v4l/v4l2.xml | 4 +- Documentation/DocBook/media/v4l/vidioc-dqevent.xml | 6 + drivers/media/v4l2-core/v4l2-ctrls.c | 143 +++++++++++++++------ include/media/v4l2-ctrls.h | 20 +++ include/uapi/linux/videodev2.h | 1 + 6 files changed, 138 insertions(+), 40 deletions(-) (limited to 'Documentation') diff --git a/Documentation/DocBook/media/v4l/compat.xml b/Documentation/DocBook/media/v4l/compat.xml index ebd2bfd1ee8e..104a1a2b8849 100644 --- a/Documentation/DocBook/media/v4l/compat.xml +++ b/Documentation/DocBook/media/v4l/compat.xml @@ -2486,6 +2486,10 @@ that used it. It was originally scheduled for removal in 2.6.35. v4l2_buffer. See . + + Added V4L2_EVENT_CTRL_CH_RANGE control event + changes flag. See . +
diff --git a/Documentation/DocBook/media/v4l/v4l2.xml b/Documentation/DocBook/media/v4l/v4l2.xml index 8fe29427c8e4..c3851a2fb50d 100644 --- a/Documentation/DocBook/media/v4l/v4l2.xml +++ b/Documentation/DocBook/media/v4l/v4l2.xml @@ -142,10 +142,12 @@ applications. --> 3.9 2012-12-03 - sa + sa, sn Added timestamp types to v4l2_buffer, see . + Added V4L2_EVENT_CTRL_CH_RANGE control + event changes flag, see . diff --git a/Documentation/DocBook/media/v4l/vidioc-dqevent.xml b/Documentation/DocBook/media/v4l/vidioc-dqevent.xml index 98a856f9ec30..89891adb928a 100644 --- a/Documentation/DocBook/media/v4l/vidioc-dqevent.xml +++ b/Documentation/DocBook/media/v4l/vidioc-dqevent.xml @@ -261,6 +261,12 @@ 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. + diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c b/drivers/media/v4l2-core/v4l2-ctrls.c index 7b486ac3f4d9..3f27571b814d 100644 --- a/drivers/media/v4l2-core/v4l2-ctrls.c +++ b/drivers/media/v4l2-core/v4l2-ctrls.c @@ -1158,8 +1158,7 @@ static int new_to_user(struct v4l2_ext_control *c, } /* Copy the new value to the current value. */ -static void new_to_cur(struct v4l2_fh *fh, struct v4l2_ctrl *ctrl, - bool update_inactive) +static void new_to_cur(struct v4l2_fh *fh, struct v4l2_ctrl *ctrl, u32 ch_flags) { bool changed = false; @@ -1183,8 +1182,8 @@ static void new_to_cur(struct v4l2_fh *fh, struct v4l2_ctrl *ctrl, ctrl->cur.val = ctrl->val; break; } - if (update_inactive) { - /* Note: update_inactive can only be true for auto clusters. */ + if (ch_flags & V4L2_EVENT_CTRL_CH_FLAGS) { + /* Note: CH_FLAGS is only set for auto clusters. */ ctrl->flags &= ~(V4L2_CTRL_FLAG_INACTIVE | V4L2_CTRL_FLAG_VOLATILE); if (!is_cur_manual(ctrl->cluster[0])) { @@ -1194,14 +1193,13 @@ static void new_to_cur(struct v4l2_fh *fh, struct v4l2_ctrl *ctrl, } fh = NULL; } - if (changed || update_inactive) { + if (changed || ch_flags) { /* If a control was changed that was not one of the controls modified by the application, then send the event to all. */ if (!ctrl->is_new) fh = NULL; send_event(fh, ctrl, - (changed ? V4L2_EVENT_CTRL_CH_VALUE : 0) | - (update_inactive ? V4L2_EVENT_CTRL_CH_FLAGS : 0)); + (changed ? V4L2_EVENT_CTRL_CH_VALUE : 0) | ch_flags); if (ctrl->call_notify && changed && ctrl->handler->notify) ctrl->handler->notify(ctrl, ctrl->handler->notify_priv); } @@ -1257,6 +1255,41 @@ static int cluster_changed(struct v4l2_ctrl *master) return diff; } +/* Control range checking */ +static int check_range(enum v4l2_ctrl_type type, + s32 min, s32 max, u32 step, s32 def) +{ + switch (type) { + case V4L2_CTRL_TYPE_BOOLEAN: + if (step != 1 || max > 1 || min < 0) + return -ERANGE; + /* fall through */ + case V4L2_CTRL_TYPE_INTEGER: + if (step <= 0 || min > max || def < min || def > max) + return -ERANGE; + return 0; + case V4L2_CTRL_TYPE_BITMASK: + if (step || min || !max || (def & ~max)) + return -ERANGE; + return 0; + case V4L2_CTRL_TYPE_MENU: + case V4L2_CTRL_TYPE_INTEGER_MENU: + if (min > max || def < min || def > max) + return -ERANGE; + /* Note: step == menu_skip_mask for menu controls. + So here we check if the default value is masked out. */ + if (step && ((1 << def) & step)) + return -EINVAL; + return 0; + case V4L2_CTRL_TYPE_STRING: + if (min > max || min < 0 || step < 1 || def) + return -ERANGE; + return 0; + default: + return 0; + } +} + /* Validate a new control */ static int validate_new(const struct v4l2_ctrl *ctrl, struct v4l2_ext_control *c) @@ -1529,30 +1562,21 @@ static struct v4l2_ctrl *v4l2_ctrl_new(struct v4l2_ctrl_handler *hdl, { struct v4l2_ctrl *ctrl; unsigned sz_extra = 0; + int err; if (hdl->error) return NULL; /* Sanity checks */ if (id == 0 || name == NULL || id >= V4L2_CID_PRIVATE_BASE || - (type == V4L2_CTRL_TYPE_INTEGER && step == 0) || - (type == V4L2_CTRL_TYPE_BITMASK && max == 0) || (type == V4L2_CTRL_TYPE_MENU && qmenu == NULL) || - (type == V4L2_CTRL_TYPE_INTEGER_MENU && qmenu_int == NULL) || - (type == V4L2_CTRL_TYPE_STRING && max == 0)) { - handler_set_err(hdl, -ERANGE); - return NULL; - } - if (type != V4L2_CTRL_TYPE_BITMASK && max < min) { + (type == V4L2_CTRL_TYPE_INTEGER_MENU && qmenu_int == NULL)) { handler_set_err(hdl, -ERANGE); return NULL; } - if ((type == V4L2_CTRL_TYPE_INTEGER || - type == V4L2_CTRL_TYPE_MENU || - type == V4L2_CTRL_TYPE_INTEGER_MENU || - type == V4L2_CTRL_TYPE_BOOLEAN) && - (def < min || def > max)) { - handler_set_err(hdl, -ERANGE); + err = check_range(type, min, max, step, def); + if (err) { + handler_set_err(hdl, err); return NULL; } if (type == V4L2_CTRL_TYPE_BITMASK && ((def & ~max) || min || step)) { @@ -2426,8 +2450,8 @@ EXPORT_SYMBOL(v4l2_ctrl_g_ctrl_int64); /* Core function that calls try/s_ctrl and ensures that the new value is copied to the current value on a set. Must be called with ctrl->handler->lock held. */ -static int try_or_set_cluster(struct v4l2_fh *fh, - struct v4l2_ctrl *master, bool set) +static int try_or_set_cluster(struct v4l2_fh *fh, struct v4l2_ctrl *master, + bool set, u32 ch_flags) { bool update_flag; int ret; @@ -2465,7 +2489,8 @@ static int try_or_set_cluster(struct v4l2_fh *fh, /* If OK, then make the new values permanent. */ update_flag = is_cur_manual(master) != is_new_manual(master); for (i = 0; i < master->ncontrols; i++) - new_to_cur(fh, master->cluster[i], update_flag && i > 0); + new_to_cur(fh, master->cluster[i], ch_flags | + ((update_flag && i > 0) ? V4L2_EVENT_CTRL_CH_FLAGS : 0)); return 0; } @@ -2592,7 +2617,7 @@ static int try_set_ext_ctrls(struct v4l2_fh *fh, struct v4l2_ctrl_handler *hdl, } while (!ret && idx); if (!ret) - ret = try_or_set_cluster(fh, master, set); + ret = try_or_set_cluster(fh, master, set, 0); /* Copy the new values back to userspace. */ if (!ret) { @@ -2638,10 +2663,9 @@ EXPORT_SYMBOL(v4l2_subdev_s_ext_ctrls); /* Helper function for VIDIOC_S_CTRL compatibility */ static int set_ctrl(struct v4l2_fh *fh, struct v4l2_ctrl *ctrl, - struct v4l2_ext_control *c) + struct v4l2_ext_control *c, u32 ch_flags) { struct v4l2_ctrl *master = ctrl->cluster[0]; - int ret; int i; /* String controls are not supported. The user_to_new() and @@ -2651,12 +2675,6 @@ static int set_ctrl(struct v4l2_fh *fh, struct v4l2_ctrl *ctrl, if (ctrl->type == V4L2_CTRL_TYPE_STRING) return -EINVAL; - ret = validate_new(ctrl, c); - if (ret) - return ret; - - v4l2_ctrl_lock(ctrl); - /* Reset the 'is_new' flags of the cluster */ for (i = 0; i < master->ncontrols; i++) if (master->cluster[i]) @@ -2670,10 +2688,22 @@ static int set_ctrl(struct v4l2_fh *fh, struct v4l2_ctrl *ctrl, update_from_auto_cluster(master); user_to_new(c, ctrl); - ret = try_or_set_cluster(fh, master, true); - cur_to_user(c, ctrl); + return try_or_set_cluster(fh, master, true, ch_flags); +} - v4l2_ctrl_unlock(ctrl); +/* Helper function for VIDIOC_S_CTRL compatibility */ +static int set_ctrl_lock(struct v4l2_fh *fh, struct v4l2_ctrl *ctrl, + struct v4l2_ext_control *c) +{ + int ret = validate_new(ctrl, c); + + if (!ret) { + v4l2_ctrl_lock(ctrl); + ret = set_ctrl(fh, ctrl, c, 0); + if (!ret) + cur_to_user(c, ctrl); + v4l2_ctrl_unlock(ctrl); + } return ret; } @@ -2691,7 +2721,7 @@ int v4l2_s_ctrl(struct v4l2_fh *fh, struct v4l2_ctrl_handler *hdl, return -EACCES; c.value = control->value; - ret = set_ctrl(fh, ctrl, &c); + ret = set_ctrl_lock(fh, ctrl, &c); control->value = c.value; return ret; } @@ -2710,7 +2740,7 @@ int v4l2_ctrl_s_ctrl(struct v4l2_ctrl *ctrl, s32 val) /* It's a driver bug if this happens. */ WARN_ON(!type_is_int(ctrl)); c.value = val; - return set_ctrl(NULL, ctrl, &c); + return set_ctrl_lock(NULL, ctrl, &c); } EXPORT_SYMBOL(v4l2_ctrl_s_ctrl); @@ -2721,7 +2751,7 @@ int v4l2_ctrl_s_ctrl_int64(struct v4l2_ctrl *ctrl, s64 val) /* It's a driver bug if this happens. */ WARN_ON(ctrl->type != V4L2_CTRL_TYPE_INTEGER64); c.value64 = val; - return set_ctrl(NULL, ctrl, &c); + return set_ctrl_lock(NULL, ctrl, &c); } EXPORT_SYMBOL(v4l2_ctrl_s_ctrl_int64); @@ -2741,6 +2771,41 @@ void v4l2_ctrl_notify(struct v4l2_ctrl *ctrl, v4l2_ctrl_notify_fnc notify, void } EXPORT_SYMBOL(v4l2_ctrl_notify); +int v4l2_ctrl_modify_range(struct v4l2_ctrl *ctrl, + s32 min, s32 max, u32 step, s32 def) +{ + int ret = check_range(ctrl->type, min, max, step, def); + struct v4l2_ext_control c; + + switch (ctrl->type) { + case V4L2_CTRL_TYPE_INTEGER: + case V4L2_CTRL_TYPE_BOOLEAN: + case V4L2_CTRL_TYPE_MENU: + case V4L2_CTRL_TYPE_INTEGER_MENU: + case V4L2_CTRL_TYPE_BITMASK: + if (ret) + return ret; + break; + default: + return -EINVAL; + } + v4l2_ctrl_lock(ctrl); + ctrl->minimum = min; + ctrl->maximum = max; + ctrl->step = step; + ctrl->default_value = def; + c.value = ctrl->cur.val; + if (validate_new(ctrl, &c)) + c.value = def; + if (c.value != ctrl->cur.val) + ret = set_ctrl(NULL, ctrl, &c, V4L2_EVENT_CTRL_CH_RANGE); + else + send_event(NULL, ctrl, V4L2_EVENT_CTRL_CH_RANGE); + v4l2_ctrl_unlock(ctrl); + return ret; +} +EXPORT_SYMBOL(v4l2_ctrl_modify_range); + static int v4l2_ctrl_add_event(struct v4l2_subscribed_event *sev, unsigned elems) { struct v4l2_ctrl *ctrl = v4l2_ctrl_find(sev->fh->ctrl_handler, sev->id); diff --git a/include/media/v4l2-ctrls.h b/include/media/v4l2-ctrls.h index c4cc04136074..91125b6f05a5 100644 --- a/include/media/v4l2-ctrls.h +++ b/include/media/v4l2-ctrls.h @@ -518,6 +518,26 @@ void v4l2_ctrl_activate(struct v4l2_ctrl *ctrl, bool active); */ void v4l2_ctrl_grab(struct v4l2_ctrl *ctrl, bool grabbed); +/** v4l2_ctrl_modify_range() - Update the range of a control. + * @ctrl: The control to update. + * @min: The control's minimum value. + * @max: The control's maximum value. + * @step: The control's step value + * @def: The control's default value. + * + * Update the range of a control on the fly. This works for control types + * INTEGER, BOOLEAN, MENU, INTEGER MENU and BITMASK. For menu controls the + * @step value is interpreted as a menu_skip_mask. + * + * An error is returned if one of the range arguments is invalid for this + * control type. + * + * This function assumes that the control handler is not locked and will + * take the lock itself. + */ +int v4l2_ctrl_modify_range(struct v4l2_ctrl *ctrl, + s32 min, s32 max, u32 step, s32 def); + /** v4l2_ctrl_lock() - Helper function to lock the handler * associated with the control. * @ctrl: The control to lock. diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h index 94cbe26e9f00..928799c2e2d9 100644 --- a/include/uapi/linux/videodev2.h +++ b/include/uapi/linux/videodev2.h @@ -1822,6 +1822,7 @@ struct v4l2_event_vsync { /* Payload for V4L2_EVENT_CTRL */ #define V4L2_EVENT_CTRL_CH_VALUE (1 << 0) #define V4L2_EVENT_CTRL_CH_FLAGS (1 << 1) +#define V4L2_EVENT_CTRL_CH_RANGE (1 << 2) struct v4l2_event_ctrl { __u32 changes; -- cgit v1.2.3-59-g8ed1b From 22331a5e0a493f8edfbd504bb58bd03d308ddb0c Mon Sep 17 00:00:00 2001 From: Laurent Pinchart Date: Mon, 7 Jan 2013 16:30:24 -0300 Subject: [media] DocBook: media: struct v4l2_capability card field is a UTF-8 string The struct v4l2_capability card field stores the device name. That name can be hardcoded in drivers, or be retrieved directly from the device. The later is very common with USB devices. As several devices already report names that include non-ASCII characters, update the field description to use UTF-8. Signed-off-by: Laurent Pinchart Acked-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab --- Documentation/DocBook/media/v4l/vidioc-querycap.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/DocBook/media/v4l/vidioc-querycap.xml b/Documentation/DocBook/media/v4l/vidioc-querycap.xml index 4c70215ae03f..d5a3c97b206a 100644 --- a/Documentation/DocBook/media/v4l/vidioc-querycap.xml +++ b/Documentation/DocBook/media/v4l/vidioc-querycap.xml @@ -76,7 +76,7 @@ make sure the strings are properly NUL-terminated. __u8 card[32] - Name of the device, a NUL-terminated ASCII string. + 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 -- cgit v1.2.3-59-g8ed1b From 07b64b837d90cf20fad6b4965aa1fecdb4a88e9b Mon Sep 17 00:00:00 2001 From: Hans Verkuil Date: Fri, 11 Jan 2013 08:18:55 -0300 Subject: [media] DocBook: fix various validation errors Fixed the following errors (with exception of the SVG errors): GEN /home/hans/work/src/v4l/media-git/Documentation/DocBook//v4l2.xml rm -rf Documentation/DocBook/index.html; echo '

Linux Kernel HTML Documentation

' >> Documentation/DocBook/index.html && echo '

Kernel Version: 3.8.0-rc1

' >> Documentation/DocBook/index.html && cat Documentation/DocBook/media_api.html >> Documentation/DocBook/index.html /tmp/x.xml:883: element revremark: validity error : Element structname is not declared in revremark list of possible children /tmp/x.xml:883: element revremark: validity error : Element xref is not declared in revremark list of possible children /tmp/x.xml:9580: element xref: validity error : Element xref was declared EMPTY this one has content /tmp/x.xml:13508: element link: validity error : Element link does not carry attribute linkend /tmp/x.xml:13508: element link: validity error : No declaration for attribute linked of element link /tmp/x.xml:16986: element imagedata: validity error : Value "SVG" for attribute format of imagedata is not among the enumerated set /tmp/x.xml:17003: element imagedata: validity error : Value "SVG" for attribute format of imagedata is not among the enumerated set /tmp/x.xml:17022: element imagedata: validity error : Value "SVG" for attribute format of imagedata is not among the enumerated set Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab --- Documentation/DocBook/media/v4l/common.xml | 2 +- Documentation/DocBook/media/v4l/io.xml | 4 ++-- .../DocBook/media/v4l/pixfmt-srggb10alaw8.xml | 2 +- Documentation/DocBook/media/v4l/v4l2.xml | 4 +--- Documentation/DocBook/media/v4l/vidioc-expbuf.xml | 28 ++++++++++------------ 5 files changed, 17 insertions(+), 23 deletions(-) (limited to 'Documentation') diff --git a/Documentation/DocBook/media/v4l/common.xml b/Documentation/DocBook/media/v4l/common.xml index 73c6847436c9..ae06afbbb3a9 100644 --- a/Documentation/DocBook/media/v4l/common.xml +++ b/Documentation/DocBook/media/v4l/common.xml @@ -609,7 +609,7 @@ to zero and the VIDIOC_G_STD, Applications can make use of the and flags to determine whether the video standard ioctls are available for the device. -&ENOTTY;. + 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 diff --git a/Documentation/DocBook/media/v4l/io.xml b/Documentation/DocBook/media/v4l/io.xml index 2c4646d504c2..e6c58559ca6b 100644 --- a/Documentation/DocBook/media/v4l/io.xml +++ b/Documentation/DocBook/media/v4l/io.xml @@ -477,7 +477,7 @@ rest should be evident. Experimental - This is an experimental + This is an experimental interface and may change in the future. @@ -488,7 +488,7 @@ 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 + 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 diff --git a/Documentation/DocBook/media/v4l/pixfmt-srggb10alaw8.xml b/Documentation/DocBook/media/v4l/pixfmt-srggb10alaw8.xml index c934192e98ce..29acc2098cc2 100644 --- a/Documentation/DocBook/media/v4l/pixfmt-srggb10alaw8.xml +++ b/Documentation/DocBook/media/v4l/pixfmt-srggb10alaw8.xml @@ -29,6 +29,6 @@ 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/v4l2.xml b/Documentation/DocBook/media/v4l/v4l2.xml index c3851a2fb50d..a3cce18384e9 100644 --- a/Documentation/DocBook/media/v4l/v4l2.xml +++ b/Documentation/DocBook/media/v4l/v4l2.xml @@ -143,9 +143,7 @@ applications. --> 3.9 2012-12-03 sa, sn - Added timestamp types to - v4l2_buffer, see . + Added timestamp types to v4l2_buffer. Added V4L2_EVENT_CTRL_CH_RANGE control event changes flag, see . diff --git a/Documentation/DocBook/media/v4l/vidioc-expbuf.xml b/Documentation/DocBook/media/v4l/vidioc-expbuf.xml index 72dfbd20a802..e287c8fc803b 100644 --- a/Documentation/DocBook/media/v4l/vidioc-expbuf.xml +++ b/Documentation/DocBook/media/v4l/vidioc-expbuf.xml @@ -83,15 +83,14 @@ 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 + Examples - - Exporting a buffer. - + + Exporting a buffer. + int buffer_export(int v4lfd, &v4l2-buf-type; bt, int index, int *dmafd) { &v4l2-exportbuffer; expbuf; @@ -108,12 +107,12 @@ int buffer_export(int v4lfd, &v4l2-buf-type; bt, int index, int *dmafd) return 0; } - - + + - - Exporting a buffer using the multi-planar API. - + + 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) { @@ -137,12 +136,9 @@ int buffer_export_mp(int v4lfd, &v4l2-buf-type; bt, int index, return 0; } - - -
- + + - struct <structname>v4l2_exportbuffer</structname> -- cgit v1.2.3-59-g8ed1b From 0568aeeeef467ac6e22d5d549cd50e8c93abf959 Mon Sep 17 00:00:00 2001 From: Hans Verkuil Date: Fri, 11 Jan 2013 10:33:30 -0300 Subject: [media] DocBook: improve the error_idx field documentation The documentation of the error_idx field was incomplete and confusing. This patch improves it. Signed-off-by: Hans Verkuil Acked-by: Laurent Pinchart Signed-off-by: Mauro Carvalho Chehab --- .../DocBook/media/v4l/vidioc-g-ext-ctrls.xml | 47 ++++++++++++++++++---- 1 file changed, 40 insertions(+), 7 deletions(-) (limited to 'Documentation') diff --git a/Documentation/DocBook/media/v4l/vidioc-g-ext-ctrls.xml b/Documentation/DocBook/media/v4l/vidioc-g-ext-ctrls.xml index 0a4b90fcf2da..42ffbff6d37e 100644 --- a/Documentation/DocBook/media/v4l/vidioc-g-ext-ctrls.xml +++ b/Documentation/DocBook/media/v4l/vidioc-g-ext-ctrls.xml @@ -199,13 +199,46 @@ also be zero. __u32 error_idx - Set by the driver in case of an error. If it is equal -to count, then no actual changes were made to -controls. In other words, the error was not associated with setting a particular -control. If it is another value, then only the controls up to error_idx-1 -were modified and control error_idx is the one that -caused the error. The error_idx value is undefined -if the ioctl returned 0 (success). + 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 -- cgit v1.2.3-59-g8ed1b From 00b230fe2310d7a0b338a8e339995e0cf3f5e977 Mon Sep 17 00:00:00 2001 From: Hans Verkuil Date: Fri, 11 Jan 2013 10:49:12 -0300 Subject: [media] DocBook: mention that EINVAL can be returned for invalid menu indices The documentation suggested that if the control value is wrong only ERANGE can be returned. But in some cases (an invalid menu index) EINVAL can also be returned. Clarify this. Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab --- Documentation/DocBook/media/v4l/vidioc-g-ctrl.xml | 8 ++++++-- Documentation/DocBook/media/v4l/vidioc-g-ext-ctrls.xml | 10 +++++++--- 2 files changed, 13 insertions(+), 5 deletions(-) (limited to 'Documentation') diff --git a/Documentation/DocBook/media/v4l/vidioc-g-ctrl.xml b/Documentation/DocBook/media/v4l/vidioc-g-ctrl.xml index 12b1d0503e26..ee2820d6ca66 100644 --- a/Documentation/DocBook/media/v4l/vidioc-g-ctrl.xml +++ b/Documentation/DocBook/media/v4l/vidioc-g-ctrl.xml @@ -64,7 +64,9 @@ 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. +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 @@ -99,7 +101,9 @@ application. EINVAL The &v4l2-control; id is -invalid. +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;). diff --git a/Documentation/DocBook/media/v4l/vidioc-g-ext-ctrls.xml b/Documentation/DocBook/media/v4l/vidioc-g-ext-ctrls.xml index 42ffbff6d37e..4e16112df992 100644 --- a/Documentation/DocBook/media/v4l/vidioc-g-ext-ctrls.xml +++ b/Documentation/DocBook/media/v4l/vidioc-g-ext-ctrls.xml @@ -106,7 +106,9 @@ value or if an error is returned. &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;. +&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 @@ -331,8 +333,10 @@ These controls are described in EINVAL The &v4l2-ext-control; id -is invalid or the &v4l2-ext-controls; -ctrl_class is invalid. This error code is +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. -- cgit v1.2.3-59-g8ed1b From c240ac9bc7470d4d060df3688b8e590cbbab9eb5 Mon Sep 17 00:00:00 2001 From: Antonio Ospite Date: Mon, 28 Jan 2013 17:45:31 -0300 Subject: [media] Documentation/media-framework.txt: fix a sentence Signed-off-by: Antonio Ospite Signed-off-by: Mauro Carvalho Chehab --- Documentation/media-framework.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/media-framework.txt b/Documentation/media-framework.txt index 802875413873..77bd0a42f19d 100644 --- a/Documentation/media-framework.txt +++ b/Documentation/media-framework.txt @@ -336,7 +336,7 @@ Calls to media_entity_pipeline_start() can be nested. The pipeline pointer must be identical for all nested calls to the function. media_entity_pipeline_start() may return an error. In that case, it will -clean up any the changes it did by itself. +clean up any of the changes it did by itself. When stopping the stream, drivers must notify the entities with -- cgit v1.2.3-59-g8ed1b From 9690fd80d3fb1bbfe04d7e1d8dde0cfd353c7b8d Mon Sep 17 00:00:00 2001 From: Vadim Frolov Date: Wed, 30 Jan 2013 05:14:59 -0300 Subject: [media] saa7134: Add capture card Hawell HW-9004V1 This patch adds new capture board Hawell HW-9004V1. This card has 4 SAA71300 chips. In order to work it is needed to initialize its registers (gpio mask and value). The value of these registers were dumped under Windows using flytest. Signed-off-by: Vadim Frolov Signed-off-by: Mauro Carvalho Chehab --- Documentation/video4linux/CARDLIST.saa7134 | 1 + drivers/media/pci/saa7134/saa7134-cards.c | 17 +++++++++++++++++ drivers/media/pci/saa7134/saa7134.h | 1 + 3 files changed, 19 insertions(+) (limited to 'Documentation') diff --git a/Documentation/video4linux/CARDLIST.saa7134 b/Documentation/video4linux/CARDLIST.saa7134 index 94d9025aa82d..b3ad68309109 100644 --- a/Documentation/video4linux/CARDLIST.saa7134 +++ b/Documentation/video4linux/CARDLIST.saa7134 @@ -189,3 +189,4 @@ 188 -> Sensoray 811/911 [6000:0811,6000:0911] 189 -> Kworld PC150-U [17de:a134] 190 -> Asus My Cinema PS3-100 [1043:48cd] +191 -> Hawell HW-9004V1 diff --git a/drivers/media/pci/saa7134/saa7134-cards.c b/drivers/media/pci/saa7134/saa7134-cards.c index bc08f1dbc293..dc68cf1070f7 100644 --- a/drivers/media/pci/saa7134/saa7134-cards.c +++ b/drivers/media/pci/saa7134/saa7134-cards.c @@ -5773,6 +5773,23 @@ struct saa7134_board saa7134_boards[] = { .gpio = 0x0000000, }, }, + [SAA7134_BOARD_HAWELL_HW_9004V1] = { + /* Hawell HW-9004V1 */ + /* Vadim Frolov */ + .name = "Hawell HW-9004V1", + .audio_clock = 0x00200000, + .tuner_type = UNSET, + .radio_type = UNSET, + .tuner_addr = ADDR_UNSET, + .radio_addr = ADDR_UNSET, + .gpiomask = 0x618E700, + .inputs = {{ + .name = name_comp1, + .vmux = 3, + .amux = LINE1, + .gpio = 0x6010000, + } }, + }, }; diff --git a/drivers/media/pci/saa7134/saa7134.h b/drivers/media/pci/saa7134/saa7134.h index f804324e07fd..71eefef5e324 100644 --- a/drivers/media/pci/saa7134/saa7134.h +++ b/drivers/media/pci/saa7134/saa7134.h @@ -333,6 +333,7 @@ struct saa7134_card_ir { #define SAA7134_BOARD_SENSORAY811_911 188 #define SAA7134_BOARD_KWORLD_PC150U 189 #define SAA7134_BOARD_ASUSTeK_PS3_100 190 +#define SAA7134_BOARD_HAWELL_HW_9004V1 191 #define SAA7134_MAXBOARDS 32 #define SAA7134_INPUT_MAX 8 -- cgit v1.2.3-59-g8ed1b From 20e3dbef8e7acf679ba179e1a077303e3f76f975 Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Fri, 8 Feb 2013 14:51:36 -0200 Subject: [media] Documentation: update V4L cardlists Signed-off-by: Mauro Carvalho Chehab --- Documentation/video4linux/CARDLIST.au0828 | 2 +- Documentation/video4linux/CARDLIST.cx23885 | 2 ++ Documentation/video4linux/CARDLIST.em28xx | 3 ++- 3 files changed, 5 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/video4linux/CARDLIST.au0828 b/Documentation/video4linux/CARDLIST.au0828 index a8a65753e544..55a21deab7db 100644 --- a/Documentation/video4linux/CARDLIST.au0828 +++ b/Documentation/video4linux/CARDLIST.au0828 @@ -1,5 +1,5 @@ 0 -> Unknown board (au0828) - 1 -> Hauppauge HVR950Q (au0828) [2040:7200,2040:7210,2040:7217,2040:721b,2040:721e,2040:721f,2040:7280,0fd9:0008,2040:7260,2040:7213] + 1 -> Hauppauge HVR950Q (au0828) [2040:7200,2040:7210,2040:7217,2040:721b,2040:721e,2040:721f,2040:7280,0fd9:0008,2040:7260,2040:7213,2040:7270] 2 -> Hauppauge HVR850 (au0828) [2040:7240] 3 -> DViCO FusionHDTV USB (au0828) [0fe9:d620] 4 -> Hauppauge HVR950Q rev xxF8 (au0828) [2040:7201,2040:7211,2040:7281] diff --git a/Documentation/video4linux/CARDLIST.cx23885 b/Documentation/video4linux/CARDLIST.cx23885 index 1299b5e82d7f..9f056d512e35 100644 --- a/Documentation/video4linux/CARDLIST.cx23885 +++ b/Documentation/video4linux/CARDLIST.cx23885 @@ -36,3 +36,5 @@ 35 -> TeVii S471 [d471:9022] 36 -> Hauppauge WinTV-HVR1255 [0070:2259] 37 -> Prof Revolution DVB-S2 8000 [8000:3034] + 38 -> Hauppauge WinTV-HVR4400 [0070:c108,0070:c138,0070:c12a,0070:c1f8] + 39 -> AVerTV Hybrid Express Slim HC81R [1461:d939] diff --git a/Documentation/video4linux/CARDLIST.em28xx b/Documentation/video4linux/CARDLIST.em28xx index d99262dda533..3f12865b2a88 100644 --- a/Documentation/video4linux/CARDLIST.em28xx +++ b/Documentation/video4linux/CARDLIST.em28xx @@ -76,7 +76,7 @@ 76 -> KWorld PlusTV 340U or UB435-Q (ATSC) (em2870) [1b80:a340] 77 -> EM2874 Leadership ISDBT (em2874) 78 -> PCTV nanoStick T2 290e (em28174) - 79 -> Terratec Cinergy H5 (em2884) [0ccd:008e,0ccd:00ac,0ccd:10a2,0ccd:10ad] + 79 -> Terratec Cinergy H5 (em2884) [0ccd:10a2,0ccd:10ad] 80 -> PCTV DVB-S2 Stick (460e) (em28174) 81 -> Hauppauge WinTV HVR 930C (em2884) [2040:1605] 82 -> Terratec Cinergy HTC Stick (em2884) [0ccd:00b2] @@ -84,3 +84,4 @@ 84 -> MaxMedia UB425-TC (em2874) [1b80:e425] 85 -> PCTV QuatroStick (510e) (em2884) [2304:0242] 86 -> PCTV QuatroStick nano (520e) (em2884) [2013:0251] + 87 -> Terratec Cinergy HTC USB XS (em2884) [0ccd:008e,0ccd:00ac] -- cgit v1.2.3-59-g8ed1b From 4db45af5ecdd5a989b5da2e05e37746dffaec0be Mon Sep 17 00:00:00 2001 From: Alexey Klimov Date: Mon, 11 Feb 2013 19:04:51 -0300 Subject: [media] radio-si470x doc: add info about v4l2-ctl and sox+alsa Patch adds information about using v4l2-ctl utility to tune the si470x radio and example how to use sox+alsa to redirect sound from radio sound device to another sound device. Signed-off-by: Alexey Klimov Signed-off-by: Mauro Carvalho Chehab --- Documentation/video4linux/si470x.txt | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/video4linux/si470x.txt b/Documentation/video4linux/si470x.txt index 3a7823e01b4d..98c32925eb39 100644 --- a/Documentation/video4linux/si470x.txt +++ b/Documentation/video4linux/si470x.txt @@ -53,6 +53,9 @@ Testing is usually done with most application under Debian/testing: - kradio - Comfortable Radio Application for KDE - radio - ncurses-based radio application - mplayer - The Ultimate Movie Player For Linux +- v4l2-ctl - Collection of command line video4linux utilities +For example, you can use: +v4l2-ctl -d /dev/radio0 --set-ctrl=volume=10,mute=0 --set-freq=95.21 --all There is also a library libv4l, which can be used. It's going to have a function for frequency seeking, either by using hardware functionality as in radio-si470x @@ -75,8 +78,10 @@ commands. Please adjust the audio devices to your needs (/dev/dsp* and hw:x,x). If you just want to test audio (very poor quality): cat /dev/dsp1 > /dev/dsp -If you use OSS try: +If you use sox + OSS try: sox -2 --endian little -r 96000 -t oss /dev/dsp1 -t oss /dev/dsp +or using sox + alsa: +sox --endian little -c 2 -S -r 96000 -t alsa hw:1 -t alsa -r 96000 hw:0 If you use arts try: arecord -D hw:1,0 -r96000 -c2 -f S16_LE | artsdsp aplay -B - -- cgit v1.2.3-59-g8ed1b From 2fd7f398d32a0d490d28de75b613263502918e51 Mon Sep 17 00:00:00 2001 From: Sebastian Hesselbarth Date: Fri, 8 Feb 2013 18:47:30 -0300 Subject: [media] media: rc: gpio-ir-recv: add support for device tree parsing This patch adds device tree parsing for gpio_ir_recv platform_data and the mandatory binding documentation. It basically follows what we already have for e.g. gpio_keys. All required device tree properties are OS independent but an optional property allows linux specific support for rc maps. Signed-off-by: Sebastian Hesselbarth Reviewed-by: Sylwester Nawrocki Signed-off-by: Mauro Carvalho Chehab --- .../devicetree/bindings/media/gpio-ir-receiver.txt | 16 +++++++ drivers/media/rc/gpio-ir-recv.c | 52 ++++++++++++++++++++++ 2 files changed, 68 insertions(+) create mode 100644 Documentation/devicetree/bindings/media/gpio-ir-receiver.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/media/gpio-ir-receiver.txt b/Documentation/devicetree/bindings/media/gpio-ir-receiver.txt new file mode 100644 index 000000000000..56e726ef4bf2 --- /dev/null +++ b/Documentation/devicetree/bindings/media/gpio-ir-receiver.txt @@ -0,0 +1,16 @@ +Device-Tree bindings for GPIO IR receiver + +Required properties: + - compatible: should be "gpio-ir-receiver". + - gpios: specifies GPIO used for IR signal reception. + +Optional properties: + - linux,rc-map-name: Linux specific remote control map name. + +Example node: + + ir: ir-receiver { + compatible = "gpio-ir-receiver"; + gpios = <&gpio0 19 1>; + linux,rc-map-name = "rc-rc6-mce"; + }; diff --git a/drivers/media/rc/gpio-ir-recv.c b/drivers/media/rc/gpio-ir-recv.c index 382f362b69af..8b82ae9bd686 100644 --- a/drivers/media/rc/gpio-ir-recv.c +++ b/drivers/media/rc/gpio-ir-recv.c @@ -16,6 +16,7 @@ #include #include #include +#include #include #include #include @@ -30,6 +31,45 @@ struct gpio_rc_dev { bool active_low; }; +#ifdef CONFIG_OF +/* + * Translate OpenFirmware node properties into platform_data + */ +static int gpio_ir_recv_get_devtree_pdata(struct device *dev, + struct gpio_ir_recv_platform_data *pdata) +{ + struct device_node *np = dev->of_node; + enum of_gpio_flags flags; + int gpio; + + gpio = of_get_gpio_flags(np, 0, &flags); + if (gpio < 0) { + if (gpio != -EPROBE_DEFER) + dev_err(dev, "Failed to get gpio flags (%d)\n", gpio); + return gpio; + } + + pdata->gpio_nr = gpio; + pdata->active_low = (flags & OF_GPIO_ACTIVE_LOW); + /* probe() takes care of map_name == NULL or allowed_protos == 0 */ + pdata->map_name = of_get_property(np, "linux,rc-map-name", NULL); + pdata->allowed_protos = 0; + + return 0; +} + +static struct of_device_id gpio_ir_recv_of_match[] = { + { .compatible = "gpio-ir-receiver", }, + { }, +}; +MODULE_DEVICE_TABLE(of, gpio_ir_recv_of_match); + +#else /* !CONFIG_OF */ + +#define gpio_ir_recv_get_devtree_pdata(dev, pdata) (-ENOSYS) + +#endif + static irqreturn_t gpio_ir_recv_irq(int irq, void *dev_id) { struct gpio_rc_dev *gpio_dev = dev_id; @@ -66,6 +106,17 @@ static int gpio_ir_recv_probe(struct platform_device *pdev) pdev->dev.platform_data; int rc; + if (pdev->dev.of_node) { + struct gpio_ir_recv_platform_data *dtpdata = + devm_kzalloc(&pdev->dev, sizeof(*dtpdata), GFP_KERNEL); + if (!dtpdata) + return -ENOMEM; + rc = gpio_ir_recv_get_devtree_pdata(&pdev->dev, dtpdata); + if (rc) + return rc; + pdata = dtpdata; + } + if (!pdata) return -EINVAL; @@ -191,6 +242,7 @@ static struct platform_driver gpio_ir_recv_driver = { .driver = { .name = GPIO_IR_DRIVER_NAME, .owner = THIS_MODULE, + .of_match_table = of_match_ptr(gpio_ir_recv_of_match), #ifdef CONFIG_PM .pm = &gpio_ir_recv_pm_ops, #endif -- cgit v1.2.3-59-g8ed1b