- 26 Feb, 2010 40 commits
-
-
Andy Walls authored
This change fixes up saa7127_s_std() generate SECAM out, if the user has requested a 50 Hz video standard set that only contains a request for SECAM standards and not PAL. Only the SAA712[89] chips can generate SECAM, the SAA712[67] chips cannot. I was unclear on the burst start and end values - I couldn't figure out the units - so I left them the same as for the PAL systems. A the video decoders on both a PVR-350 (SAA7115) and an HVR-1600 (CX23418) identify the SECAM signal generated by a SAA7129 with this patch as SECAM. Signed-off-by: Andy Walls <awalls@radix.net> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
-
Sergey Bolshakov authored
Fix the "xceive_pin" setting from "15" to "1" for the PVR2100 -- the same as the PVR3100H. This properly resets the XC2028 tuner on the PVR2100. Sergey's original email report: Hi. Seems cx18 module has incorrect .xceive_pin value for card, as i see lots of i2c errors in dmesg from xc2028. i'm using 2.6.32.2, my hardware is: 00:09.0 Multimedia video controller [0400]: Conexant Systems, Inc. CX23418 Single-Chip MPEG-2 Encoder with Integrated Analog Video/Broadcast Audio Decoder [14f1:5b7a] Subsystem: LeadTek Research Inc. Device [107d:6f27] Flags: bus master, medium devsel, latency 64, IRQ 17 Memory at f0000000 (32-bit, non-prefetchable) [size=64M] Capabilities: [44] Vital Product Data Capabilities: [4c] Power Management version 2 Kernel driver in use: cx18 Kernel modules: cx18 Following fixes this problem for me, the rest seems working: Reported-by: Sergey Bolshakov <sbolshakov@altlinux.ru> Tested-by: Sergey Bolshakov <sbolshakov@altlinux.ru> Signed-off-by: Andy Walls <awalls@radix.net> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
-
Andy Walls authored
The CX18_CPU_SET_INDEXTABLE command was being called with the wrong number of arguments causing the index table frame type selection mask to be set wrong. Now the IDX stream properly sends entries for I, P, and B frames. Signed-off-by: Andy Walls <awalls@radix.net> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
-
Andy Walls authored
Signed-off-by: Andy Walls <awalls@radix.net> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
-
Andy Walls authored
VIDIOC_G_ENC_INDEX support see the light of day. Some notes: 1. With default capture parameters, the CX23418 seems to transfer 192 index entries (4.5 kB worth) at 10 second intervals. 2. Index streams don't seem to be supported for MPEG 2 TS streams 3. The index entries seem to claim every frame is a B-Frame. Possible firmware bug. 4. The cx18 driver does not try to capture an index stream when inserting sliced VBI into the MPEg stream as the offsets would need fixup. Signed-off-by: Andy Walls <awalls@radix.net> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
-
Andy Walls authored
According to the v4l2 spec, very old MPEG index entries needs to be discarded in favor of newer index entries. This change ensures the firmware always has buffers for index entries at the expense of the oldest unread buffers. Signed-off-by: Andy Walls <awalls@radix.net> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
-
Andy Walls authored
This change starts the IDX stream along with the MPG stream as an internal use (only) stream much like the VBI stream can be started as an internal use stream for inserting sliced VBI packets. The IDX stream is not started automatically with an MPEG strem if the IDX stream is disabled (no buffers allocated) or if sliced VBI insertion is being performed by the cx18 driver. The cx18 driver doing sliced VBI insertion makes the offsets in the IDX stream inaccurate for the final MPEG stream presented to user space. Since fixing the IDX offsets ourselves is not easy and we cannot easily do what ivtv does to fix the offsets, we'll make sliced VBI insertion and MPEG Index capture mutually exclusive for now. Signed-off-by: Andy Walls <awalls@radix.net> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
-
Andy Walls authored
This change allows the IDX stream to be started and stopped as any other stream even though it has no associated device node. This is needed for cx18 driver internal use. Also always tell the CX23418 to generate index entries when an analog capture starts and the IDX stream has had buffers allocated (i.e. is enabled). Signed-off-by: Andy Walls <awalls@radix.net> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
-
Andy Walls authored
Fix a long standing memory leak of stream buffers for streams that did not have a struct video_device allocated: namely the TS and IDX streams. Signed-off-by: Andy Walls <awalls@radix.net> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
-
Andy Walls authored
Signed-off-by: Andy Walls <awalls@radix.net> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
-
Andy Walls authored
Update the module options related to INDEX stream buffer allocation. A single CX2341[5678] index entry is only 24 bytes. Large buffers for the IDX stream will prevent the CX23418 from transferring index data over at all. Buffers of around 1.5 kB or 64 index entries seem to be just fine. We'll default to 63 buffers/MDLs as that is the firmware limit per stream and IDX stream buffers are not high rate. There is no reason on earth to allocate the previous 1 MB default of buffer space for the IDX stream. This is in anticipation of implementing the G_ENC_INDEX ioctl() in the cx18 driver. Signed-off-by: Andy Walls <awalls@radix.net> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
-
Marton Nemeth authored
The ctrls field of struct sd_desc is declared as const in gspca.h. It is worth to initialize the content also with constant values. Signed-off-by: Marton Nemeth <nm127@freemail.hu> Signed-off-by: Jean-Francois Moine <moinejf@free.fr> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
-
Márton Németh authored
The function callbacks in sd_desc are defined at compile time and they do not change at runtime. Make the sd_desc initializations const. Signed-off-by: Márton Németh <nm127@freemail.hu> Signed-off-by: Jean-Francois Moine <moinejf@free.fr> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
-
Jean-Francois Moine authored
The USB video interface was checked as having the number zero, but some webcams have other values. The test is now done on the interface class which may be either 255 (vendor spec) or 0 (class per interface). Signed-off-by: Jean-Francois Moine <moinejf@free.fr> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
-
Jean-Francois Moine authored
- adapt the start sequences from the info file of the ms-win driver of the webcams 046d:08a2/046d:08aa (lvWIMv.inf) - disable the brightness for this sensor Signed-off-by: Jean-Francois Moine <moinejf@free.fr> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
-
Jean-Francois Moine authored
The previous calculation gave bad gamma tables. Signed-off-by: Jean-Francois Moine <moinejf@free.fr> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
-
Jean-Francois Moine authored
- sharpness - brightness for adcm1700 - adjust brightness/exposure for adcm1700 - add some comments Signed-off-by: Jean-Francois Moine <moinejf@free.fr> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
-
Jean-Francois Moine authored
- new sensor POxxxx (unknown ID) - no probe - new controls - table for the disabled controls Signed-off-by: Jean-Francois Moine <moinejf@free.fr> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
-
Jean-Francois Moine authored
Signed-off-by: Jean-Francois Moine <moinejf@free.fr> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
-
Jean-Francois Moine authored
- have 2 tables for sensor probe - with the same ID, the sensor mi1320 is found with the bridge vc0321, the sensor mi1320_soc with the bridge vc0323 - add some comments Signed-off-by: Jean-Francois Moine <moinejf@free.fr> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
-
Antoine Jacquet authored
Added a new initialization method for Aiptek DV T300. Addresses http://bugzilla.kernel.org/show_bug.cgi?id=13708Tested-by: Hámorszky Balázs <balihb@gmail.com> Signed-off-by: Antoine Jacquet <royale@zerezo.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
-
Erik Andrén authored
Currently all probed sensor types are emitted in the kernel log, generating unnecessary noise. Be less verbose and only report what sensor is found (if any) Signed-off-by: Erik Andrén <erik.andren@gmail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
-
Erik Andrén authored
Signed-off-by: Erik Andrén <erik.andren@gmail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
-
Mauro Carvalho Chehab authored
When printing that an iocl were called, report the ioctl number. Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
-
Mauro Carvalho Chehab authored
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
-
Jean-Francois Moine authored
Signed-off-by: Jean-Francois Moine <moinejf@free.fr> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
-
Jean-Francois Moine authored
Tested-by: Francesco Lavra <francescolavra@interfree.it> Signed-off-by: Jean-Francois Moine <moinejf@free.fr> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
-
Jean-Francois Moine authored
The webcam 0ac8:303b may have the sensors HV7131B or HV7131R(c). This changeset checks the HV7131 type. Signed-off-by: Jean-Francois Moine <moinejf@free.fr> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
-
Luis Maia authored
This ID was found in a webcam 0ac8:301b. Signed-off-by: Luis Maia <lmaia@royalhat.org> Signed-off-by: Jean-Francois Moine <moinejf@free.fr> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
-
Jean-Francois Moine authored
This flag permits subdrivers to create specific transfer URBs. Signed-off-by: Jean-Francois Moine <moinejf@free.fr> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
-
Jean-Francois Moine authored
Signed-off-by: Jean-Francois Moine <moinejf@free.fr> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
-
Mauro Carvalho Chehab authored
/home/v4l/buildtest/v4l-dvb-master/v4l/ir-keytable.c: In function 'ir_setkeycode': /home/v4l/buildtest/v4l-dvb-master/v4l/ir-keytable.c:190: warning: 'newkeymap' may be used uninitialized in this function Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
-
Mauro Carvalho Chehab authored
Now, if RF is locked but demod is not locked, it will report: >>> tuning status == 0x03 This happens, for example, if the device is on DVB-T, and the video standard is ISDB-T. Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
-
Mauro Carvalho Chehab authored
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
-
Mauro Carvalho Chehab authored
After taking a look at the driver's history and doing some tests with DVB and ISDB-T, it was noticed that the stats were incomplete, for ISDB-T, and weren't working for DVB. Fixed the code and added a debug code to print the complete stats at dmesg. This debug is useful to improve the stats of this driver. Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
-
Mauro Carvalho Chehab authored
Bandwidth is in Hz, not in kHz. Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
-
Mauro Carvalho Chehab authored
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
-
Mauro Carvalho Chehab authored
Cc: Patrick Boettcher <pboettcher@kernellabs.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
-
Mauro Carvalho Chehab authored
Based on a patch originally written by Michael Krufky <mkrufky@linuxtv.org> for a preliminar S2API spec. The patch were ported to the S2API and had the ISDB-T API additions to honor the auto mode, while keep allowing manual tuning. Tested with both the original dvb-apps and the new dvb-apps-isdbt scan, that uses a different channel.conf and uses S2API with ISDB-T extensions. Thanks-to: Michael Krufky <mkrufky@linuxtv.org> for his first version Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
-
Mauro Carvalho Chehab authored
Siano series of patches seemed to cause a regression on reporting DTV statistics. Due to that, signal indication weren't received, preventing applications like scan to work. Tested with ISDB-T signals and got the same scan result as with a dib0700/dib8000 device. Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
-