diff options
Diffstat (limited to 'Documentation/video4linux')
| -rw-r--r-- | Documentation/video4linux/CARDLIST.bttv | 2 | ||||
| -rw-r--r-- | Documentation/video4linux/CARDLIST.saa7134 | 3 | ||||
| -rw-r--r-- | Documentation/video4linux/CQcam.txt | 6 | ||||
| -rw-r--r-- | Documentation/video4linux/Zoran | 4 | ||||
| -rw-r--r-- | Documentation/video4linux/bttv/Insmod-options | 2 | ||||
| -rw-r--r-- | Documentation/video4linux/cx2341x/fw-decoder-api.txt | 58 | ||||
| -rw-r--r-- | Documentation/video4linux/cx2341x/fw-decoder-regs.txt | 815 | ||||
| -rw-r--r-- | Documentation/video4linux/cx2341x/fw-dma.txt | 16 | ||||
| -rw-r--r-- | Documentation/video4linux/cx2341x/fw-encoder-api.txt | 52 | ||||
| -rw-r--r-- | Documentation/video4linux/cx2341x/fw-memory.txt | 10 | ||||
| -rw-r--r-- | Documentation/video4linux/et61x251.txt | 7 | ||||
| -rw-r--r-- | Documentation/video4linux/sn9c102.txt | 246 | ||||
| -rw-r--r-- | Documentation/video4linux/zc0301.txt | 10 |
13 files changed, 1049 insertions, 182 deletions
diff --git a/Documentation/video4linux/CARDLIST.bttv b/Documentation/video4linux/CARDLIST.bttv index 4efa4645885..fc2fe9bc671 100644 --- a/Documentation/video4linux/CARDLIST.bttv +++ b/Documentation/video4linux/CARDLIST.bttv @@ -126,7 +126,7 @@ 125 -> MATRIX Vision Sigma-SQ 126 -> MATRIX Vision Sigma-SLC 127 -> APAC Viewcomp 878(AMAX) -128 -> DViCO FusionHDTV DVB-T Lite [18ac:db10] +128 -> DViCO FusionHDTV DVB-T Lite [18ac:db10,18ac:db11] 129 -> V-Gear MyVCD 130 -> Super TV Tuner 131 -> Tibet Systems 'Progress DVR' CS16 diff --git a/Documentation/video4linux/CARDLIST.saa7134 b/Documentation/video4linux/CARDLIST.saa7134 index f6201cc37ec..a12246a9bf2 100644 --- a/Documentation/video4linux/CARDLIST.saa7134 +++ b/Documentation/video4linux/CARDLIST.saa7134 @@ -104,3 +104,6 @@ 103 -> Compro Videomate DVB-T200A 104 -> Hauppauge WinTV-HVR1110 DVB-T/Hybrid [0070:6701] 105 -> Terratec Cinergy HT PCMCIA [153b:1172] +106 -> Encore ENLTV [1131:2342,1131:2341,3016:2344] +107 -> Encore ENLTV-FM [1131:230f] +108 -> Terratec Cinergy HT PCI [153b:1175] diff --git a/Documentation/video4linux/CQcam.txt b/Documentation/video4linux/CQcam.txt index ade8651e244..04986efb731 100644 --- a/Documentation/video4linux/CQcam.txt +++ b/Documentation/video4linux/CQcam.txt @@ -197,10 +197,10 @@ Use the ../../Maintainers file, particularly the VIDEO FOR LINUX and PARALLEL PORT SUPPORT sections The video4linux page: - http://roadrunner.swansea.linux.org.uk/v4l.shtml + http://linuxtv.org -The video4linux2 page: - http://millennium.diads.com/bdirks/v4l2.htm +The V4L2 API spec: + http://v4l2spec.bytesex.org/ Some web pages about the quickcams: http://www.dkfz-heidelberg.de/Macromol/wedemann/mini-HOWTO-cqcam.html diff --git a/Documentation/video4linux/Zoran b/Documentation/video4linux/Zoran index deb218f77ad..85c575ac4fb 100644 --- a/Documentation/video4linux/Zoran +++ b/Documentation/video4linux/Zoran @@ -339,9 +339,9 @@ Information - video4linux/mjpeg extensions: (also see below) Information - video4linux2: -http://www.thedirks.org/v4l2/ +http://linuxtv.org +http://v4l2spec.bytesex.org/ /usr/include/linux/videodev2.h -http://www.bytesex.org/v4l/ More information on the video4linux/mjpeg extensions, by Serguei Miridonovi and Rainer Johanni: diff --git a/Documentation/video4linux/bttv/Insmod-options b/Documentation/video4linux/bttv/Insmod-options index bb7c2cac791..5ef75787f83 100644 --- a/Documentation/video4linux/bttv/Insmod-options +++ b/Documentation/video4linux/bttv/Insmod-options @@ -57,7 +57,7 @@ bttv.o i2c_udelay= Allow reduce I2C speed. Default is 5 usecs (meaning 66,67 Kbps). The default is the maximum supported speed by kernel bitbang - algoritm. You may use lower numbers, if I2C + algorithm. You may use lower numbers, if I2C messages are lost (16 is known to work on all supported cards). diff --git a/Documentation/video4linux/cx2341x/fw-decoder-api.txt b/Documentation/video4linux/cx2341x/fw-decoder-api.txt index 78bf5f21e51..8c317b7a4fc 100644 --- a/Documentation/video4linux/cx2341x/fw-decoder-api.txt +++ b/Documentation/video4linux/cx2341x/fw-decoder-api.txt @@ -21,7 +21,7 @@ Param[0] 0 based frame number in GOP to begin playback from. Param[1] Specifies the number of muted audio frames to play before normal - audio resumes. + audio resumes. (This is not implemented in the firmware, leave at 0) ------------------------------------------------------------------------------- @@ -32,6 +32,10 @@ Description playback stops at specified PTS. Param[0] Display 0=last frame, 1=black + Note: this takes effect immediately, so if you want to wait for a PTS, + then use '0', otherwise the screen goes to black at once. + You can call this later (even if there is no playback) with a 1 value + to set the screen to black. Param[1] PTS low Param[2] @@ -60,8 +64,12 @@ Param[0] 31 Speed: '0' slow '1' fast + Note: n is limited to 2. Anything higher does not result in + faster playback. Instead the host should start dropping frames. Param[1] Direction: 0=forward, 1=reverse + Note: to make reverse playback work you have to write full GOPs in + reverse order. Param[2] Picture mask: 1=I frames @@ -69,13 +77,16 @@ Param[2] 7=I, P, B frames Param[3] B frames per GOP (for reverse play only) + Note: for reverse playback the Picture Mask should be set to I or I, P. + Adding B frames to the mask will result in corrupt video. This field + has to be set to the correct value in order to keep the timing correct. Param[4] Mute audio: 0=disable, 1=enable Param[5] Display 0=frame, 1=field Param[6] Specifies the number of muted audio frames to play before normal audio - resumes. + resumes. (Not implemented in the firmware, leave at 0) ------------------------------------------------------------------------------- @@ -212,6 +223,7 @@ Description Select audio mode Param[0] Dual mono mode action + 0=Stereo, 1=Left, 2=Right, 3=Mono, 4=Swap, -1=Unchanged Param[1] Stereo mode action: 0=Stereo, 1=Left, 2=Right, 3=Mono, 4=Swap, -1=Unchanged @@ -224,7 +236,10 @@ Description Setup firmware to notify the host about a particular event. Counterpart to API 0xD5 Param[0] - Event: 0=Audio mode change between stereo and dual channel + Event: 0=Audio mode change between mono, (joint) stereo and dual channel. + Event: 3=Decoder started + Event: 4=Unknown: goes off 10-15 times per second while decoding. + Event: 5=Some sync event: goes off once per frame. Param[1] Notification 0=disabled, 1=enabled Param[2] @@ -273,43 +288,6 @@ Param[3] ------------------------------------------------------------------------------- -Name CX2341X_DEC_SET_AUDIO_OUTPUT -Enum 27/0x1B -Description - Select audio output format -Param[0] - Bitmask: - 0:1 Data size: - '00' 16 bit - '01' 20 bit - '10' 24 bit - 2:7 Unused - 8:9 Mode: - '00' 2 channels - '01' 4 channels - '10' 6 channels - '11' 6 channels with one line data mode - (for left justified MSB first mode, 20 bit only) - 10:11 Unused - 12:13 Channel format: - '00' right justified MSB first mode - '01' left justified MSB first mode - '10' I2S mode - 14:15 Unused - 16:21 Right justify bit count - 22:31 Unused - -------------------------------------------------------------------------------- - -Name CX2341X_DEC_SET_AV_DELAY -Enum 28/0x1C -Description - Set audio/video delay in 90Khz ticks -Param[0] - 0=A/V in sync, negative=audio lags, positive=video lags - -------------------------------------------------------------------------------- - Name CX2341X_DEC_SET_PREBUFFERING Enum 30/0x1E Description diff --git a/Documentation/video4linux/cx2341x/fw-decoder-regs.txt b/Documentation/video4linux/cx2341x/fw-decoder-regs.txt new file mode 100644 index 00000000000..db2366c634e --- /dev/null +++ b/Documentation/video4linux/cx2341x/fw-decoder-regs.txt @@ -0,0 +1,815 @@ +PVR350 Video decoder registers 0x02002800 -> 0x02002B00 +======================================================= + +This list has been worked out through trial and error. There will be mistakes +and omissions. Some registers have no obvious effect so it's hard to say what +they do, while others interact with each other, or require a certain load +sequence. Horizontal filter setup is one example, with six registers working +in unison and requiring a certain load sequence to correctly configure. The +indexed colour palette is much easier to set at just two registers, but again +it requires a certain load sequence. + +Some registers are fussy about what they are set to. Load in a bad value & the +decoder will fail. A firmware reload will often recover, but sometimes a reset +is required. For registers containing size information, setting them to 0 is +generally a bad idea. For other control registers i.e. 2878, you'll only find +out what values are bad when it hangs. + +-------------------------------------------------------------------------------- +2800 + bit 0 + Decoder enable + 0 = disable + 1 = enable +-------------------------------------------------------------------------------- +2804 + bits 0:31 + Decoder horizontal Y alias register 1 +--------------- +2808 + bits 0:31 + Decoder horizontal Y alias register 2 +--------------- +280C + bits 0:31 + Decoder horizontal Y alias register 3 +--------------- +2810 + bits 0:31 + Decoder horizontal Y alias register 4 +--------------- +2814 + bits 0:31 + Decoder horizontal Y alias register 5 +--------------- +2818 + bits 0:31 + Decoder horizontal Y alias trigger + + These six registers control the horizontal aliasing filter for the Y plane. + The first five registers must all be loaded before accessing the trigger + (2818), as this register actually clocks the data through for the first + five. + + To correctly program set the filter, this whole procedure must be done 16 + times. The actual register contents are copied from a lookup-table in the + firmware which contains 4 different filter settings. + +-------------------------------------------------------------------------------- +281C + bits 0:31 + Decoder horizontal UV alias register 1 +--------------- +2820 + bits 0:31 + Decoder horizontal UV alias register 2 +--------------- +2824 + bits 0:31 + Decoder horizontal UV alias register 3 +--------------- +2828 + bits 0:31 + Decoder horizontal UV alias register 4 +--------------- +282C + bits 0:31 + Decoder horizontal UV alias register 5 +--------------- +2830 + bits 0:31 + Decoder horizontal UV alias trigger + + These six registers control the horizontal aliasing for the UV plane. + Operation is the same as the Y filter, with 2830 being the trigger + register. + +-------------------------------------------------------------------------------- +2834 + bits 0:15 + Decoder Y source width in pixels + + bits 16:31 + Decoder Y destination width in pixels +--------------- +2838 + bits 0:15 + Decoder UV source width in pixels + + bits 16:31 + Decoder UV destination width in pixels + + NOTE: For both registers, the resulting image must be fully visible on + screen. If the image exceeds the right edge both the source and destination + size must be adjusted to reflect the visible portion. For the source width, + you must take into account the scaling when calculating the new value. +-------------------------------------------------------------------------------- + +283C + bits 0:31 + Decoder Y horizontal scaling + Normally = Reg 2854 >> 2 +--------------- +2840 + bits 0:31 + Decoder ?? unknown - horizontal scaling + Usually 0x00080514 +--------------- +2844 + bits 0:31 + Decoder UV horizontal scaling + Normally = Reg 2854 >> 2 +--------------- +2848 + bits 0:31 + Decoder ?? unknown - horizontal scaling + Usually 0x00100514 +--------------- +284C + bits 0:31 + Decoder ?? unknown - Y plane + Usually 0x00200020 +--------------- +2850 + bits 0:31 + Decoder ?? unknown - UV plane + Usually 0x00200020 +--------------- +2854 + bits 0:31 + Decoder 'master' value for horizontal scaling +--------------- +2858 + bits 0:31 + Decoder ?? unknown + Usually 0 +--------------- +285C + bits 0:31 + Decoder ?? unknown + Normally = Reg 2854 >> 1 +--------------- +2860 + bits 0:31 + Decoder ?? unknown + Usually 0 +--------------- +2864 + bits 0:31 + Decoder ?? unknown + Normally = Reg 2854 >> 1 +--------------- +2868 + bits 0:31 + Decoder ?? unknown + Usually 0 + + Most of these registers either control horizontal scaling, or appear linked + to it in some way. Register 2854 contains the 'master' value & the other + registers can be calculated from that one. You must also remember to + correctly set the divider in Reg 2874. + + To enlarge: + Reg 2854 = (source_width * 0x00200000) / destination_width + Reg 2874 = No divide + + To reduce from full size down to half size: + Reg 2854 = (source_width/2 * 0x00200000) / destination width + Reg 2874 = Divide by 2 + + To reduce from half size down to quarter size: + Reg 2854 = (source_width/4 * 0x00200000) / destination width + Reg 2874 = Divide by 4 + + The result is always rounded up. + +-------------------------------------------------------------------------------- +286C + bits 0:15 + Decoder horizontal Y buffer offset + + bits 15:31 + Decoder horizontal UV buffer offset + + Offset into the video image buffer. If the offset is gradually incremented, + the on screen image will move left & wrap around higher up on the right. + +-------------------------------------------------------------------------------- +2870 + bits 0:15 + Decoder horizontal Y output offset + + bits 16:31 + Decoder horizontal UV output offset + + Offsets the actual video output. Controls output alignment of the Y & UV + planes. The higher the value, the greater the shift to the left. Use + reg 2890 to move the image right. + +-------------------------------------------------------------------------------- +2874 + bits 0:1 + Decoder horizontal Y output size divider + 00 = No divide + 01 = Divide by 2 + 10 = Divide by 3 + + bits 4:5 + Decoder horizontal UV output size divider + 00 = No divide + 01 = Divide by 2 + 10 = Divide by 3 + + bit 8 + Decoder ?? unknown + 0 = Normal + 1 = Affects video output levels + + bit 16 + Decoder ?? unknown + 0 = Normal + 1 = Disable horizontal filter + +-------------------------------------------------------------------------------- +2878 + bit 0 + ?? unknown + + bit 1 + osd on/off + 0 = osd off + 1 = osd on + + bit 2 + Decoder + osd video timing + 0 = NTSC + 1 = PAL + + bits 3:4 + ?? unknown + + bit 5 + Decoder + osd + Swaps upper & lower fields + +-------------------------------------------------------------------------------- +287C + bits 0:10 + Decoder & osd ?? unknown + Moves entire screen horizontally. Starts at 0x005 with the screen + shifted heavily to the right. Incrementing in steps of 0x004 will + gradually shift the screen to the left. + + bits 11:31 + ?? unknown + + Normally contents are 0x00101111 (NTSC) or 0x1010111d (PAL) + +-------------------------------------------------------------------------------- +2880 -------- ?? unknown +2884 -------- ?? unknown +-------------------------------------------------------------------------------- +2888 + bit 0 + Decoder + osd ?? unknown + 0 = Normal + 1 = Misaligned fields (Correctable through 289C & 28A4) + + bit 4 + ?? unknown + + bit 8 + ?? unknown + + Warning: Bad values will require a firmware reload to recover. + Known to be bad are 0x000,0x011,0x100,0x111 +-------------------------------------------------------------------------------- +288C + bits 0:15 + osd ?? unknown + Appears to affect the osd position stability. The higher the value the + more unstable it becomes. Decoder output remains stable. + + bits 16:31 + osd ?? unknown + Same as bits 0:15 + +-------------------------------------------------------------------------------- +2890 + bits 0:11 + Decoder output horizontal offset. + + Horizontal offset moves the video image right. A small left shift is + possible, but it's better to use reg 2870 for that due to its greater + range. + + NOTE: Video corruption will occur if video window is shifted off the right + edge. To avoid this read the notes for 2834 & 2838. +-------------------------------------------------------------------------------- +2894 + bits 0:23 + Decoder output video surround colour. + + Contains the colour (in yuv) used to fill the screen when the video is + running in a window. +-------------------------------------------------------------------------------- +2898 + bits 0:23 + Decoder video window colour + Contains the colour (in yuv) used to fill the video window when the + video is turned off. + + bit 24 + Decoder video output + 0 = Video on + 1 = Video off + + bit 28 + Decoder plane order + 0 = Y,UV + 1 = UV,Y + + bit 29 + Decoder second plane byte order + 0 = Normal (UV) + 1 = Swapped (VU) + + In normal usage, the first plane is Y & the second plane is UV. Though the + order of the planes can be swapped, only the byte order of the second plane + can be swapped. This isn't much use for the Y plane, but can be useful for + the UV plane. + +-------------------------------------------------------------------------------- +289C + bits 0:15 + Decoder vertical field offset 1 + + bits 16:31 + Decoder vertical field offset 2 + + Controls field output vertical alignment. The higher the number, the lower + the image on screen. Known starting values are 0x011E0017 (NTSC) & + 0x01500017 (PAL) +-------------------------------------------------------------------------------- +28A0 + bits 0:15 + Decoder & osd width in pixels + + bits 16:31 + Decoder & osd height in pixels + + All output from the decoder & osd are disabled beyond this area. Decoder + output will simply go black outside of this region. If the osd tries to + exceed this area it will become corrupt. +-------------------------------------------------------------------------------- +28A4 + bits 0:11 + osd left shift. + + Has a range of 0x770->0x7FF. With the exception of 0, any value outside of + this range corrupts the osd. +-------------------------------------------------------------------------------- +28A8 + bits 0:15 + osd vertical field offset 1 + + bits 16:31 + osd vertical field offset 2 + + Controls field output vertical alignment. The higher the number, the lower + the image on screen. Known starting values are 0x011E0017 (NTSC) & + 0x01500017 (PAL) +-------------------------------------------------------------------------------- +28AC -------- ?? unknown + | + V +28BC -------- ?? unknown +-------------------------------------------------------------------------------- +28C0 + bit 0 + Current output field + 0 = first field + 1 = second field + + bits 16:31 + Current scanline + The scanline counts from the top line of the first field + through to the last line of the second field. +-------------------------------------------------------------------------------- +28C4 -------- ?? unknown + | + V +28F8 -------- ?? unknown +-------------------------------------------------------------------------------- +28FC + bit 0 + ?? unknown + 0 = Normal + 1 = Breaks decoder & osd output +-------------------------------------------------------------------------------- +2900 + bits 0:31 + Decoder vertical Y alias register 1 +--------------- +2904 + bits 0:31 + Decoder vertical Y alias register 2 +--------------- +2908 + bits 0:31 + Decoder vertical Y alias trigger + + These three registers control the vertical aliasing filter for the Y plane. + Operation is similar to the horizontal Y filter (2804). The only real + difference is that there are only two registers to set before accessing + the trigger register (2908). As for the horizontal filter, the values are + taken from a lookup table in the firmware, and the procedure must be + repeated 16 times to fully program the filter. +-------------------------------------------------------------------------------- +290C + bits 0:31 + Decoder vertical UV alias register 1 +--------------- +2910 + bits 0:31 + Decoder vertical UV alias register 2 +--------------- +2914 + bits 0:31 + Decoder vertical UV alias trigger + + These three registers control the vertical aliasing filter for the UV + plane. Operation is the same as the Y filter, with 2914 being the trigger. +-------------------------------------------------------------------------------- +2918 + bits 0:15 + Decoder Y source height in pixels + + bits 16:31 + Decoder Y destination height in pixels +--------------- +291C + bits 0:15 + Decoder UV source height in pixels divided by 2 + + bits 16:31 + Decoder UV destination height in pixels + + NOTE: For both registers, the resulting image must be fully visible on + screen. If the image exceeds the bottom edge both the source and + destination size must be adjusted to reflect the visible portion. For the + source height, you must take into account the scaling when calculating the + new value. +-------------------------------------------------------------------------------- +2920 + bits 0:31 + Decoder Y vertical scaling + Normally = Reg 2930 >> 2 +--------------- +2924 + bits 0:31 + Decoder Y vertical scaling + Normally = Reg 2920 + 0x514 +--------------- +2928 + bits 0:31 + Decoder UV vertical scaling + When enlarging = Reg 2930 >> 2 + When reducing = Reg 2930 >> 3 +--------------- +292C + bits 0:31 + Decoder UV vertical scaling + Normally = Reg 2928 + 0x514 +--------------- +2930 + bits 0:31 + Decoder 'master' value for vertical scaling +--------------- +2934 + bits 0:31 + Decoder ?? unknown - Y vertical scaling +--------------- +2938 + bits 0:31 + Decoder Y vertical scaling + Normally = Reg 2930 +--------------- +293C + bits 0:31 + Decoder ?? unknown - Y vertical scaling +--------------- +2940 + bits 0:31 + Decoder UV vertical scaling + When enlarging = Reg 2930 >> 1 + When reducing = Reg 2930 +--------------- +2944 + bits 0:31 + Decoder ?? unknown - UV vertical scaling +--------------- +2948 + bits 0:31 + Decoder UV vertical scaling + Normally = Reg 2940 +--------------- +294C + bits 0:31 + Decoder ?? unknown - UV vertical scaling + + Most of these registers either control vertical scaling, or appear linked + to it in some way. Register 2930 contains the 'master' value & all other + registers can be calculated from that one. You must also remember to + correctly set the divider in Reg 296C + + To enlarge: + Reg 2930 = (source_height * 0x00200000) / destination_height + Reg 296C = No divide + + To reduce from full size down to half size: + Reg 2930 = (source_height/2 * 0x00200000) / destination height + Reg 296C = Divide by 2 + + To reduce from half down to quarter. + Reg 2930 = (source_height/4 * 0x00200000) / destination height + Reg 296C = Divide by 4 + +-------------------------------------------------------------------------------- +2950 + bits 0:15 + Decoder Y line index into display buffer, first field + + bits 16:31 + Decoder Y vertical line skip, first field +-------------------------------------------------------------------------------- +2954 + bits 0:15 + Decoder Y line index into display buffer, second field + + bits 16:31 + Decoder Y vertical line skip, second field +-------------------------------------------------------------------------------- +2958 + bits 0:15 + Decoder UV line index into display buffer, first field + + bits 16:31 + Decoder UV vertical line skip, first field +-------------------------------------------------------------------------------- +295C + bits 0:15 + Decoder UV line index into display buffer, second field + + bits 16:31 + Decoder UV vertical line skip, second field +-------------------------------------------------------------------------------- +2960 + bits 0:15 + Decoder destination height minus 1 + + bits 16:31 + Decoder destination height divided by 2 +-------------------------------------------------------------------------------- +2964 + bits 0:15 + Decoder Y vertical offset, second field + + bits 16:31 + Decoder Y vertical offset, first field + + These two registers shift the Y plane up. The higher the number, the + greater the shift. +-------------------------------------------------------------------------------- +2968 + bits 0:15 + Decoder UV vertical offset, second field + + bits 16:31 + Decoder UV vertical offset, first field + + These two registers shift the UV plane up. The higher the number, the + greater the shift. +-------------------------------------------------------------------------------- +296C + bits 0:1 + Decoder vertical Y output size divider + 00 = No divide + 01 = Divide by 2 + 10 = Divide by 4 + + bits 8:9 + Decoder vertical UV output size divider + 00 = No divide + 01 = Divide by 2 + 10 = Divide by 4 +-------------------------------------------------------------------------------- +2970 + bit 0 + Decoder ?? unknown + 0 = Normal + 1 = Affect video output levels + + bit 16 + Decoder ?? unknown + 0 = Normal + 1 = Disable vertical filter + +-------------------------------------------------------------------------------- +2974 -------- ?? unknown + | + V +29EF -------- ?? unknown +-------------------------------------------------------------------------------- +2A00 + bits 0:2 + osd colour mode + 001 = 16 bit (565) + 010 = 15 bit (555) + 011 = 12 bit (444) + 100 = 32 bit (8888) + 101 = 8 bit indexed + + bits 4:5 + osd display bpp + 01 = 8 bit + 10 = 16 bit + 11 = 32 bit + + bit 8 + osd global alpha + 0 = Off + 1 = On + + bit 9 + osd local alpha + 0 = Off + 1 = On + + bit 10 + osd colour key + 0 = Off + 1 = On + + bit 11 + osd ?? unknown + Must be 1 + + bit 13 + osd colour space + 0 = ARGB + 1 = AYVU + + bits 16:31 + osd ?? unknown + Must be 0x001B (some kind of buffer pointer ?) + + When the bits-per-pixel is set to 8, the colour mode is ignored and + assumed to be 8 bit indexed. For 16 & 32 bits-per-pixel the colour depth + is honoured, and when using a colour depth that requires fewer bytes than + allocated the extra bytes are used as padding. So for a 32 bpp with 8 bit + index colour, there are 3 padding bytes per pixel. It's also possible to + select 16bpp with a 32 bit colour mode. This results in the pixel width + being doubled, but the color key will not work as expected in this mode. + + Colour key is as it suggests. You designate a colour which will become + completely transparent. When using 565, 555 or 444 colour modes, the + colour key is always 16 bits wide. The colour to key on is set in Reg 2A18. + + Local alpha is a per-pixel 256 step transparency, with 0 being transparent + and 255 being solid. This is only available in 32 bit & 8 bit indexed + colour modes. + + Global alpha is a 256 step transparency that applies to the entire osd, + with 0 being transparent & 255 being solid. + + It's possible to combine colour key, local alpha & global alpha. +-------------------------------------------------------------------------------- +2A04 + bits 0:15 + osd x coord for left edge + + bits 16:31 + osd y coord for top edge +--------------- +2A08 + bits 0:15 + osd x coord for right edge + + bits 16:31 + osd y coord for bottom edge + + For both registers, (0,0) = top left corner of the display area. These + registers do not control the osd size, only where it's positioned & how + much is visible. The visible osd area cannot exceed the right edge of the + display, otherwise the osd will become corrupt. See reg 2A10 for + setting osd width. +-------------------------------------------------------------------------------- +2A0C + bits 0:31 + osd buffer index + + An index into the osd buffer. Slowly incrementing this moves the osd left, + wrapping around onto the right edge +-------------------------------------------------------------------------------- +2A10 + bits 0:11 + osd buffer 32 bit word width + + Contains the width of the osd measured in 32 bit words. This means that all + colour modes are restricted to a byte width which is divisible by 4. +-------------------------------------------------------------------------------- +2A14 + bits 0:15 + osd height in pixels + + bits 16:32 + osd line index into buffer + osd will start displaying from this line. +-------------------------------------------------------------------------------- +2A18 + bits 0:31 + osd colour key + + Contains the colour value which will be transparent. +-------------------------------------------------------------------------------- +2A1C + bits 0:7 + osd global alpha + + Contains the global alpha value (equiv ivtvfbctl --alpha XX) +-------------------------------------------------------------------------------- +2A20 -------- ?? unknown + | + V +2A2C -------- ?? unknown +-------------------------------------------------------------------------------- +2A30 + bits 0:7 + osd colour to change in indexed palette +--------------- +2A34 + bits 0:31 + osd colour for indexed palette + + To set the new palette, first load the index of the colour to change into + 2A30, then load the new colour into 2A34. The full palette is 256 colours, + so the index range is 0x00-0xFF +-------------------------------------------------------------------------------- +2A38 -------- ?? unknown +2A3C -------- ?? unknown +-------------------------------------------------------------------------------- +2A40 + bits 0:31 + osd ?? unknown + + Affects overall brightness, wrapping around to black +-------------------------------------------------------------------------------- +2A44 + bits 0:31 + osd ?? unknown + + Green tint +-------------------------------------------------------------------------------- +2A48 + bits 0:31 + osd ?? unknown + + Red tint +-------------------------------------------------------------------------------- +2A4C + bits 0:31 + osd ?? unknown + + Affects overall brightness, wrapping around to black +-------------------------------------------------------------------------------- +2A50 + bits 0:31 + osd ?? unknown + + Colour shift +-------------------------------------------------------------------------------- +2A54 + bits 0:31 + osd ?? unknown + + Colour shift +-------------------------------------------------------------------------------- +2A58 -------- ?? unknown + | + V +2AFC -------- ?? unknown +-------------------------------------------------------------------------------- +2B00 + bit 0 + osd filter control + 0 = filter off + 1 = filter on + + bits 1:4 + osd ?? unknown + +-------------------------------------------------------------------------------- + +v0.3 - 2 February 2007 - Ian Armstrong (ian@iarmst.demon.co.uk) + diff --git a/Documentation/video4linux/cx2341x/fw-dma.txt b/Documentation/video4linux/cx2341x/fw-dma.txt index 8123e262d5b..be52b6fd1e9 100644 --- a/Documentation/video4linux/cx2341x/fw-dma.txt +++ b/Documentation/video4linux/cx2341x/fw-dma.txt @@ -22,6 +22,8 @@ urged to choose a smaller block size and learn the scatter-gather technique. Mailbox #10 is reserved for DMA transfer information. +Note: the hardware expects little-endian data ('intel format'). + Flow ==== @@ -64,7 +66,7 @@ addresses are the physical memory location of the target DMA buffer. Each S-G array element is a struct of three 32-bit words. The first word is the source address, the second is the destination address. Both take up the -entire 32 bits. The lowest 16 bits of the third word is the transfer byte +entire 32 bits. The lowest 18 bits of the third word is the transfer byte count. The high-bit of the third word is the "last" flag. The last-flag tells the card to raise the DMA_DONE interrupt. From hard personal experience, if you forget to set this bit, the card will still "work" but the stream will @@ -78,8 +80,8 @@ Array Element: - 32-bit Source Address - 32-bit Destination Address -- 16-bit reserved (high bit is the last flag) -- 16-bit byte count +- 14-bit reserved (high bit is the last flag) +- 18-bit byte count DMA Transfer Status =================== @@ -87,8 +89,8 @@ DMA Transfer Status Register 0x0004 holds the DMA Transfer Status: Bit -4 Scatter-Gather array error -3 DMA write error -2 DMA read error -1 write completed 0 read completed +1 write completed +2 DMA read error +3 DMA write error +4 Scatter-Gather array error diff --git a/Documentation/video4linux/cx2341x/fw-encoder-api.txt b/Documentation/video4linux/cx2341x/fw-encoder-api.txt index 15df0df57dd..242104ce5b6 100644 --- a/Documentation/video4linux/cx2341x/fw-encoder-api.txt +++ b/Documentation/video4linux/cx2341x/fw-encoder-api.txt @@ -213,16 +213,6 @@ Param[1] ------------------------------------------------------------------------------- -Name CX2341X_ENC_SET_3_2_PULLDOWN -Enum 177/0xB1 -Description - 3:2 pulldown properties -Param[0] - 0=enabled - 1=disabled - -------------------------------------------------------------------------------- - Name CX2341X_ENC_SET_VBI_LINE Enum 183/0xB7 Description @@ -332,9 +322,7 @@ Param[0] '01'=JointStereo '10'=Dual '11'=Mono - Note: testing seems to indicate that Mono and possibly - JointStereo are not working (default to stereo). - Dual does work, though. + Note: the cx23415 cannot decode Joint Stereo properly. 10:11 Mode Extension used in joint_stereo mode. In Layer I and II they indicate which subbands are in @@ -413,16 +401,34 @@ Name CX2341X_ENC_SET_PGM_INDEX_INFO Enum 199/0xC7 Description Sets the Program Index Information. + The information is stored as follows: + + struct info { + u32 length; // Length of this frame + u32 offset_low; // Offset in the file of the + u32 offset_high; // start of this frame + u32 mask1; // Bits 0-1 are the type mask: + // 1=I, 2=P, 4=B + u32 pts; // The PTS of the frame + u32 mask2; // Bit 0 is bit 32 of the pts. + }; + u32 table_ptr; + struct info index[400]; + + The table_ptr is the encoder memory address in the table were + *new* entries will be written. Note that this is a ringbuffer, + so the table_ptr will wraparound. Param[0] Picture Mask: 0=No index capture 1=I frames 3=I,P frames 7=I,P,B frames + (Seems to be ignored, it always indexes I, P and B frames) Param[1] Elements requested (up to 400) Result[0] - Offset in SDF memory of the table. + Offset in the encoder memory of the start of the table. Result[1] Number of allocated elements up to a maximum of Param[1] @@ -492,12 +498,14 @@ Name CX2341X_ENC_GET_PREV_DMA_INFO_MB_9 Enum 203/0xCB Description Returns information on the previous DMA transfer in conjunction with - bit 27 of the interrupt mask. Uses mailbox 9. + bit 27 or 18 of the interrupt mask. Uses mailbox 9. Result[0] Status bits: - Bit 0 set indicates transfer complete - Bit 2 set indicates transfer error - Bit 4 set indicates linked list error + 0 read completed + 1 write completed + 2 DMA read error + 3 DMA write error + 4 Scatter-Gather array error Result[1] DMA type Result[2] @@ -672,7 +680,7 @@ Description the value. Param[0] Command number: - 1=set initial SCR value when starting encoding. + 1=set initial SCR value when starting encoding (works). 2=set quality mode (apparently some test setting). 3=setup advanced VIM protection handling (supposedly only for the cx23416 for raw YUV). @@ -681,7 +689,11 @@ Param[0] 4=generate artificial PTS timestamps 5=USB flush mode 6=something to do with the quantization matrix - 7=set navigation pack insertion for DVD + 7=set navigation pack insertion for DVD: adds 0xbf (private stream 2) + packets to the MPEG. The size of these packets is 2048 bytes (including + the header of 6 bytes: 0x000001bf + length). The payload is zeroed and + it is up to the application to fill them in. These packets are apparently + inserted every four frames. 8=enable scene change detection (seems to be a failure) 9=set history parameters of the video input module 10=set input field order of VIM diff --git a/Documentation/video4linux/cx2341x/fw-memory.txt b/Documentation/video4linux/cx2341x/fw-memory.txt index ef0aad3f88f..9d736fe8de6 100644 --- a/Documentation/video4linux/cx2341x/fw-memory.txt +++ b/Documentation/video4linux/cx2341x/fw-memory.txt @@ -1,6 +1,8 @@ This document describes the cx2341x memory map and documents some of the register space. +Note: the memory long words are little-endian ('intel format'). + Warning! This information was figured out from searching through the memory and registers, this information may not be correct and is certainly not complete, and was not derived from anything more than searching through the memory space with @@ -67,7 +69,7 @@ DMA Registers 0x000-0xff: 0x84 - first write linked list reg, for pci memory addr 0x88 - first write linked list reg, for length of buffer in memory addr (|0x80000000 or this for last link) - 0x8c-0xcc - rest of write linked list reg, 8 sets of 3 total, DMA goes here + 0x8c-0xdc - rest of write linked list reg, 8 sets of 3 total, DMA goes here from linked list addr in reg 0x0c, firmware must push through or something. 0xe0 - first (and only) read linked list reg, for pci memory addr @@ -123,12 +125,8 @@ Bit 29 Encoder VBI capture 28 Encoder Video Input Module reset event 27 Encoder DMA complete -26 -25 Decoder copy protect detection event -24 Decoder audio mode change detection event -23 +24 Decoder audio mode change detection event (through event notification) 22 Decoder data request -21 Decoder I-Frame? done 20 Decoder DMA complete 19 Decoder VBI re-insertion 18 Decoder DMA err (linked-list bad) diff --git a/Documentation/video4linux/et61x251.txt b/Documentation/video4linux/et61x251.txt index 1bdee8f85b9..1247566c4de 100644 --- a/Documentation/video4linux/et61x251.txt +++ b/Documentation/video4linux/et61x251.txt @@ -23,7 +23,7 @@ Index 1. Copyright ============ -Copyright (C) 2006 by Luca Risolia <luca.risolia@studio.unibo.it> +Copyright (C) 2006-2007 by Luca Risolia <luca.risolia@studio.unibo.it> 2. Disclaimer @@ -135,8 +135,9 @@ And finally: 6. Module loading ================= To use the driver, it is necessary to load the "et61x251" module into memory -after every other module required: "videodev", "usbcore" and, depending on -the USB host controller you have, "ehci-hcd", "uhci-hcd" or "ohci-hcd". +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: diff --git a/Documentation/video4linux/sn9c102.txt b/Documentation/video4linux/sn9c102.txt index 8cda472db36..2913da3d087 100644 --- a/Documentation/video4linux/sn9c102.txt +++ b/Documentation/video4linux/sn9c102.txt @@ -1,5 +1,5 @@ - SN9C10x PC Camera Controllers + SN9C1xx PC Camera Controllers Driver for Linux ============================= @@ -53,20 +53,14 @@ Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. 4. Overview and features ======================== -This driver attempts to support the video interface of the devices mounting the -SONiX SN9C101, SN9C102 and SN9C103 PC Camera Controllers. - -It's worth to note that SONiX has never collaborated with the author during the -development of this project, despite several requests for enough detailed -specifications of the register tables, compression engine and video data format -of the above chips. Nevertheless, these informations are no longer necessary, -because all the aspects related to these chips are known and have been -described in detail in this documentation. +This driver attempts to support the video interface of the devices assembling +the SONiX SN9C101, SN9C102, SN9C103, SN9C105 and SN9C120 PC Camera Controllers +("SN9C1xx" from now on). 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 SN9C10x driver can be found at the following URL: +The latest version of the SN9C1xx driver can be found at the following URL: http://www.linux-projects.org/ Some of the features of the driver are: @@ -85,11 +79,11 @@ Some of the features of the driver are: high compression quality (see also "Notes for V4L2 application developers" and "Video frame formats" paragraphs); - full support for the capabilities of many of the possible image sensors that - can be connected to the SN9C10x bridges, including, for instance, red, green, + can be connected to the SN9C1xx bridges, including, for instance, red, green, blue and global gain adjustments and exposure (see "Supported devices" paragraph for details); - use of default color settings for sunlight conditions; -- dynamic I/O interface for both SN9C10x and image sensor control and +- dynamic I/O interface for both SN9C1xx and image sensor control and monitoring (see "Optional device control through 'sysfs'" paragraph); - dynamic driver control thanks to various module parameters (see "Module parameters" paragraph); @@ -130,8 +124,8 @@ necessary: CONFIG_USB_UHCI_HCD=m CONFIG_USB_OHCI_HCD=m -The SN9C103 controller also provides a built-in microphone interface. It is -supported by the USB Audio driver thanks to the ALSA API: +The SN9C103, SN9c105 and SN9C120 controllers also provide a built-in microphone +interface. It is supported by the USB Audio driver thanks to the ALSA API: # Sound # @@ -155,18 +149,27 @@ And finally: 6. Module loading ================= To use the driver, it is necessary to load the "sn9c102" module into memory -after every other module required: "videodev", "usbcore" and, depending on -the USB host controller you have, "ehci-hcd", "uhci-hcd" or "ohci-hcd". +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 sn9c102 -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: +Note that the module is called "sn9c102" for historic reasons, althought it +does not just support the SN9C102. + +At this point all the devices supported by the driver and connected to the USB +ports should be recognized. You can invoke "dmesg" to analyze kernel messages +and verify that the loading process has gone well: [user@localhost home]$ dmesg +or, to isolate all the kernel messages generated by the driver: + + [user@localhost home]$ dmesg | grep sn9c102 + 7. Module parameters ==================== @@ -198,10 +201,11 @@ Default: 0 ------------------------------------------------------------------------------- Name: frame_timeout Type: uint array (min = 0, max = 64) -Syntax: <n[,...]> -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. +Syntax: <0|n[,...]> +Description: Timeout for a video frame in seconds before returning an I/O + error; 0 for infinity. This parameter is specific for each + detected camera and can be changed at runtime thanks to the + /sys filesystem interface. Default: 2 ------------------------------------------------------------------------------- Name: debug @@ -223,20 +227,21 @@ Default: 2 8. Optional device control through "sysfs" [1] ========================================== If the kernel has been compiled with the CONFIG_VIDEO_ADV_DEBUG option enabled, -it is possible to read and write both the SN9C10x and the image sensor +it is possible to read and write both the SN9C1xx and the image sensor registers by using the "sysfs" filesystem interface. Every time a supported device is recognized, a write-only file named "green" is created in the /sys/class/video4linux/videoX directory. You can set the green channel's gain by writing the desired value to it. The value may range from 0 -to 15 for SN9C101 or SN9C102 bridges, from 0 to 127 for SN9C103 bridges. -Similarly, only for SN9C103 controllers, blue and red gain control files are -available in the same directory, for which accepted values may range from 0 to -127. +to 15 for the SN9C101 or SN9C102 bridges, from 0 to 127 for the SN9C103, +SN9C105 and SN9C120 bridges. +Similarly, only for the SN9C103, SN9C105 and SN9120 controllers, blue and red +gain control files are available in the same directory, for which accepted +values may range from 0 to 127. There are other four entries in the directory above for each registered camera: "reg", "val", "i2c_reg" and "i2c_val". The first two files control the -SN9C10x bridge, while the other two control the sensor chip. "reg" and +SN9C1xx 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. Note that "i2c_reg" and "i2c_val" will not @@ -259,61 +264,84 @@ Now let's set the green gain's register of the SN9C101 or SN9C102 chips to 2: [root@localhost #] echo 0x11 > reg [root@localhost #] echo 2 > val -Note that the SN9C10x always returns 0 when some of its registers are read. +Note that the SN9C1xx always returns 0 when some of its registers are read. To avoid race conditions, all the I/O accesses to the above files are serialized. - The sysfs interface also provides the "frame_header" entry, which exports the frame header of the most recent requested and captured video frame. The header -is always 18-bytes long and is appended to every video frame by the SN9C10x +is always 18-bytes long and is appended to every video frame by the SN9C1xx controllers. As an example, this additional information can be used by the user application for implementing auto-exposure features via software. -The following table describes the frame header: - -Byte # Value Description ------- ----- ----------- -0x00 0xFF Frame synchronisation pattern. -0x01 0xFF Frame synchronisation pattern. -0x02 0x00 Frame synchronisation pattern. -0x03 0xC4 Frame synchronisation pattern. -0x04 0xC4 Frame synchronisation pattern. -0x05 0x96 Frame synchronisation pattern. -0x06 0xXX Unknown meaning. The exact value depends on the chip; - possible values are 0x00, 0x01 and 0x20. -0x07 0xXX Variable value, whose bits are ff00uzzc, where ff is a - frame counter, u is unknown, zz is a size indicator - (00 = VGA, 01 = SIF, 10 = QSIF) and c stands for - "compression enabled" (1 = yes, 0 = no). -0x08 0xXX Brightness sum inside Auto-Exposure area (low-byte). -0x09 0xXX Brightness sum inside Auto-Exposure area (high-byte). - For a pure white image, this number will be equal to 500 - times the area of the specified AE area. For images - that are not pure white, the value scales down according - to relative whiteness. -0x0A 0xXX Brightness sum outside Auto-Exposure area (low-byte). -0x0B 0xXX Brightness sum outside Auto-Exposure area (high-byte). - For a pure white image, this number will be equal to 125 - times the area outside of the specified AE area. For - images that are not pure white, the value scales down - according to relative whiteness. - according to relative whiteness. - -The following bytes are used by the SN9C103 bridge only: - -0x0C 0xXX Unknown meaning -0x0D 0xXX Unknown meaning -0x0E 0xXX Unknown meaning -0x0F 0xXX Unknown meaning -0x10 0xXX Unknown meaning -0x11 0xXX Unknown meaning +The following table describes the frame header exported by the SN9C101 and +SN9C102: + +Byte # Value or bits Description +------ ------------- ----------- +0x00 0xFF Frame synchronisation pattern +0x01 0xFF Frame synchronisation pattern +0x02 0x00 Frame synchronisation pattern +0x03 0xC4 Frame synchronisation pattern +0x04 0xC4 Frame synchronisation pattern +0x05 0x96 Frame synchronisation pattern +0x06 [3:0] Read channel gain control = (1+R_GAIN/8) + [7:4] Blue channel gain control = (1+B_GAIN/8) +0x07 [ 0 ] Compression mode. 0=No compression, 1=Compression enabled + [2:1] Maximum scale factor for compression + [ 3 ] 1 = USB fifo(2K bytes) is full + [ 4 ] 1 = Digital gain is finish + [ 5 ] 1 = Exposure is finish + [7:6] Frame index +0x08 [7:0] Y sum inside Auto-Exposure area (low-byte) +0x09 [7:0] Y sum inside Auto-Exposure area (high-byte) + where Y sum = (R/4 + 5G/16 + B/8) / 32 +0x0A [7:0] Y sum outside Auto-Exposure area (low-byte) +0x0B [7:0] Y sum outside Auto-Exposure area (high-byte) + where Y sum = (R/4 + 5G/16 + B/8) / 128 +0x0C 0xXX Not used +0x0D 0xXX Not used +0x0E 0xXX Not used +0x0F 0xXX Not used +0x10 0xXX Not used +0x11 0xXX Not used + +The following table describes the frame header exported by the SN9C103: + +Byte # Value or bits Description +------ ------------- ----------- +0x00 0xFF Frame synchronisation pattern +0x01 0xFF Frame synchronisation pattern +0x02 0x00 Frame synchronisation pattern +0x03 0xC4 Frame synchronisation pattern +0x04 0xC4 Frame synchronisation pattern +0x05 0x96 Frame synchronisation pattern +0x06 [6:0] Read channel gain control = (1/2+R_GAIN/64) +0x07 [6:0] Blue channel gain control = (1/2+B_GAIN/64) + [7:4] +0x08 [ 0 ] Compression mode. 0=No compression, 1=Compression enabled + [2:1] Maximum scale factor for compression + [ 3 ] 1 = USB fifo(2K bytes) is full + [ 4 ] 1 = Digital gain is finish + [ 5 ] 1 = Exposure is finish + [7:6] Frame index +0x09 [7:0] Y sum inside Auto-Exposure area (low-byte) +0x0A [7:0] Y sum inside Auto-Exposure area (high-byte) + where Y sum = (R/4 + 5G/16 + B/8) / 32 +0x0B [7:0] Y sum outside Auto-Exposure area (low-byte) +0x0C [7:0] Y sum outside Auto-Exposure area (high-byte) + where Y sum = (R/4 + 5G/16 + B/8) / 128 +0x0D [1:0] Audio frame number + [ 2 ] 1 = Audio is recording +0x0E [7:0] Audio summation (low-byte) +0x0F [7:0] Audio summation (high-byte) +0x10 [7:0] Audio sample count +0x11 [7:0] Audio peak data in audio frame The AE area (sx, sy, ex, ey) in the active window can be set by programming the -registers 0x1c, 0x1d, 0x1e and 0x1f of the SN9C10x controllers, where one unit +registers 0x1c, 0x1d, 0x1e and 0x1f of the SN9C1xx controllers, where one unit corresponds to 32 pixels. -[1] Part of the meaning of the frame header has been documented by Bertrik - Sikken. +[1] The frame headers exported by the SN9C105 and SN9C120 are not described. 9. Supported devices @@ -323,15 +351,19 @@ 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 SN9C10x PC camera controllers: +devices assembling the SN9C1xx PC camera controllers: Vendor ID Product ID --------- ---------- +0x0471 0x0327 +0x0471 0x0328 0x0c45 0x6001 0x0c45 0x6005 0x0c45 0x6007 0x0c45 0x6009 0x0c45 0x600d +0x0c45 0x6011 +0x0c45 0x6019 0x0c45 0x6024 0x0c45 0x6025 0x0c45 0x6028 @@ -342,6 +374,7 @@ Vendor ID Product ID 0x0c45 0x602d 0x0c45 0x602e 0x0c45 0x6030 +0x0c45 0x603f 0x0c45 0x6080 0x0c45 0x6082 0x0c45 0x6083 @@ -368,24 +401,40 @@ Vendor ID Product ID 0x0c45 0x60bb 0x0c45 0x60bc 0x0c45 0x60be +0x0c45 0x60c0 +0x0c45 0x60c8 +0x0c45 0x60cc +0x0c45 0x60ea +0x0c45 0x60ec +0x0c45 0x60fa +0x0c45 0x60fb +0x0c45 0x60fc +0x0c45 0x60fe +0x0c45 0x6130 +0x0c45 0x613a +0x0c45 0x613b +0x0c45 0x613c +0x0c45 0x613e 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: +until now only the ones that assemble the following image sensors are +supported; kernel messages will always tell you whether this is the case (see +"Module loading" paragraph): Model Manufacturer ----- ------------ HV7131D Hynix Semiconductor, Inc. MI-0343 Micron Technology, Inc. OV7630 OmniVision Technologies, Inc. +OV7660 OmniVision Technologies, Inc. PAS106B PixArt Imaging, Inc. PAS202BCA PixArt Imaging, Inc. PAS202BCB PixArt Imaging, Inc. TAS5110C1B Taiwan Advanced Sensor Corporation TAS5130D1B Taiwan Advanced Sensor Corporation -All the available control settings of each image sensor are supported through -the V4L2 interface. +Some of the available control settings of each image sensor are supported +through the V4L2 interface. Donations of new models for further testing and support would be much appreciated. Non-available hardware will not be supported by the author of this @@ -429,12 +478,15 @@ supplied by this driver). 11. Video frame formats [1] ======================= -The SN9C10x PC Camera Controllers can send images in two possible video -formats over the USB: either native "Sequential RGB Bayer" or Huffman -compressed. The latter is used to achieve high frame rates. The current video -format may be selected or queried from the user application by calling the -VIDIOC_S_FMT or VIDIOC_G_FMT ioctl's, as described in the V4L2 API -specifications. +The SN9C1xx PC Camera Controllers can send images in two possible video +formats over the USB: either native "Sequential RGB Bayer" or compressed. +The compression is used to achieve high frame rates. With regard to the +SN9C101, SN9C102 and SN9C103, the compression is based on the Huffman encoding +algorithm described below, while the SN9C105 and SN9C120 the compression is +based on the JPEG standard. +The current video format may be selected or queried from the user application +by calling the VIDIOC_S_FMT or VIDIOC_G_FMT ioctl's, as described in the V4L2 +API specifications. The name "Sequential Bayer" indicates the organization of the red, green and blue pixels in one video frame. Each pixel is associated with a 8-bit long @@ -447,14 +499,14 @@ G[m] R[m+1] G[m+2] R[m+2] ... G[2m-2] R[2m-1] ... G[n(m-2)] R[n(m-1)] The above matrix also represents the sequential or progressive read-out mode of -the (n, m) Bayer color filter array used in many CCD/CMOS image sensors. +the (n, m) Bayer color filter array used in many CCD or CMOS image sensors. -One compressed video frame consists of a bitstream that encodes for every R, G, -or B pixel the difference between the value of the pixel itself and some -reference pixel value. Pixels are organised in the Bayer pattern and the Bayer -sub-pixels are tracked individually and alternatingly. For example, in the -first line values for the B and G1 pixels are alternatingly encoded, while in -the second line values for the G2 and R pixels are alternatingly encoded. +The Huffman compressed video frame consists of a bitstream that encodes for +every R, G, or B pixel the difference between the value of the pixel itself and +some reference pixel value. Pixels are organised in the Bayer pattern and the +Bayer sub-pixels are tracked individually and alternatingly. For example, in +the first line values for the B and G1 pixels are alternatingly encoded, while +in the second line values for the G2 and R pixels are alternatingly encoded. The pixel reference value is calculated as follows: - the 4 top left pixels are encoded in raw uncompressed 8-bit format; @@ -470,8 +522,9 @@ The pixel reference value is calculated as follows: decoding. The algorithm purely describes the conversion from compressed Bayer code used -in the SN9C10x chips to uncompressed Bayer. Additional steps are required to -convert this to a color image (i.e. a color interpolation algorithm). +in the SN9C101, SN9C102 and SN9C103 chips to uncompressed Bayer. Additional +steps are required to convert this to a color image (i.e. a color interpolation +algorithm). The following Huffman codes have been found: 0: +0 (relative to reference pixel value) @@ -506,13 +559,18 @@ order): - Philippe Coval for having helped testing the PAS202BCA image sensor; - Joao Rodrigo Fuzaro, Joao Limirio, Claudio Filho and Caio Begotti for the donation of a webcam; +- Dennis Heitmann for the donation of a webcam; - Jon Hollstrom for the donation of a webcam; +- Nick McGill for the donation of a webcam; - Carlos Eduardo Medaglia Dyonisio, who added the support for the PAS202BCB image sensor; - Stefano Mozzi, who donated 45 EU; - Andrew Pearce for the donation of a webcam; +- John Pullan for the donation of a webcam; - Bertrik Sikken, who reverse-engineered and documented the Huffman compression - algorithm used in the SN9C10x controllers and implemented the first decoder; + algorithm used in the SN9C101, SN9C102 and SN9C103 controllers and + implemented the first decoder; - Mizuno Takafumi for the donation of a webcam; - an "anonymous" donator (who didn't want his name to be revealed) for the donation of a webcam. +- an anonymous donator for the donation of four webcams. diff --git a/Documentation/video4linux/zc0301.txt b/Documentation/video4linux/zc0301.txt index f406f5e8004..befdfdacdc5 100644 --- a/Documentation/video4linux/zc0301.txt +++ b/Documentation/video4linux/zc0301.txt @@ -23,7 +23,7 @@ Index 1. Copyright ============ -Copyright (C) 2006 by Luca Risolia <luca.risolia@studio.unibo.it> +Copyright (C) 2006-2007 by Luca Risolia <luca.risolia@studio.unibo.it> 2. Disclaimer @@ -125,8 +125,9 @@ And finally: 6. Module loading ================= To use the driver, it is necessary to load the "zc0301" module into memory -after every other module required: "videodev", "usbcore" and, depending on -the USB host controller you have, "ehci-hcd", "uhci-hcd" or "ohci-hcd". +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: @@ -211,12 +212,11 @@ Vendor ID Product ID 0x041e 0x4036 0x041e 0x403a 0x0458 0x7007 -0x0458 0x700C +0x0458 0x700c 0x0458 0x700f 0x046d 0x08ae 0x055f 0xd003 0x055f 0xd004 -0x046d 0x08ae 0x0ac8 0x0301 0x0ac8 0x301b 0x0ac8 0x303b |