Fixed audio clicking problem which could be heard when using analog tv or composite input
Signed-off-by: Wiktor Grebla <greblus@gmail.com>
Signed-off-by: Douglas Schilling Landgraf <dougsland@linuxtv.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Correct firmware type to MTS
Correct audio routing for composite/s-video
Add DVB-T detection.
This patch uses the eeprom hash method for detection as the vendor/product
ids are also used for the DIGIVOX_AD. This may be a clone of the same
product. Explanatory text has been added prior to the hask look-up in
anticipation that it may help others.
The following has been tested to work:
Analogue TV (PAL-I)
Composite In
DVB-T (UK Crystal Palace)
USB AUDIO
The following has not been tested but probably works:
S-Video In
Signed-off-by: Darron Broad <darron@kewl.org>
Signed-off-by: Douglas Schilling Landgraf <dougsland@linuxtv.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This makes auto gain functional on 04fc:0561.
Signed-off-by: Shane <gnome42@gmail.com>
Signed-off-by: Jean-Francois Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
There is a buffer overflow in drivers/media/video/uvc/uvc_ctrl.c:
INFO: 0xf2c5ce08-0xf2c5ce0b. First byte 0xa1 instead of 0xcc
INFO: Allocated in uvc_query_v4l2_ctrl+0x3c/0x239 [uvcvideo] age=13 cpu=1 pid=4975
...
A fixed size 8-byte buffer is allocated, and a variable size field is read
into it; there is no particular bound on the size of the field (it is
dependent on hardware and configuration) and it can overflow [also
verified by inserting printk's.]
The patch attempts to size the buffer to the correctly.
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Acked-by: Laurent Pinchart <laurent.pinchart@skynet.be>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The array size of 'shadow' still needs to be fixed in order to not overflow when reading register 0x00.
Thanks to Oliver Endriss for pointing that out.
Signed-off-by: Patrick Boettcher <pb@linuxtv.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Different backends have different input busses (saa7146, flexcop).
To reflect that a config-option to the s5h1420-driver was added which makes
the output mode selectable.
Furthermore the s5h1420-driver is now doing the same i2c-method as it was done
before adding support for other i2c-users.
This patch needs to go into the current release of the kernel, as this driver
is currently broken.
(Thanks to Eberhard Kaltenhaeuser for helping out to debug this issue.)
Signed-off-by: Patrick Boettcher <pb@linuxtv.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The functions dvb_dmxdev_section_callback, dvb_dmxdev_ts_callback,
dvb_dmx_swfilter_packet, dvb_dmx_swfilter_packets, dvb_dmx_swfilter and
dvb_dmx_swfilter_204 may be called from both interrupt and process
context. Therefore they need to be protected by spin_lock_irqsave()
instead of spin_lock().
This fixes a deadlock discovered by lockdep.
Signed-off-by: Andreas Oberritter <obi@linuxtv.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2040:5510 is the same hardware as 2040:5500
Signed-off-by: Michael Krufky <mkrufky@linuxtv.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The AMD ATI TV Wonder 600 has an XC3028L and *not* an XC3028, so we need to
load the proper firmware to prevent the device from overheating.
Signed-off-by: Devin Heitmueller <devin.heitmueller@gmail.com>
Signed-off-by: Michael Krufky <mkrufky@linuxtv.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The zr36067 driver is improperly declaring pixel format RGBP twice,
once as "16-bit RGB LE" and once as "16-bit RGB BE". The latter is
actually RGBR. Fix the code to properly map both pixel formats.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Acked-by: Trent Piepho <xyzzy@speakeasy.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
sparc32 allmodconfig:
drivers/media/video/cafe_ccic.c: In function 'cafe_setup_siobuf':
drivers/media/video/cafe_ccic.c:1192: error: implicit declaration of function 'PAGE_ALIGN'
drivers/media/video/cafe_ccic.c: At top level:
drivers/media/video/cafe_ccic.c:1430: error: variable 'cafe_v4l_vm_ops' has initializer but incomplete type
drivers/media/video/cafe_ccic.c:1431: error: unknown field 'open' specified in initializer
drivers/media/video/cafe_ccic.c:1431: warning: excess elements in struct initializer
drivers/media/video/cafe_ccic.c:1431: warning: (near initialization for 'cafe_v4l_vm_ops')
drivers/media/video/cafe_ccic.c:1432: error: unknown field 'close' specified in initializer
drivers/media/video/cafe_ccic.c:1433: warning: excess elements in struct initializer
drivers/media/video/cafe_ccic.c:1433: warning: (near initialization for 'cafe_v4l_vm_ops')
drivers/media/video/cafe_ccic.c: In function 'cafe_v4l_mmap':
drivers/media/video/cafe_ccic.c:1444: error: 'VM_WRITE' undeclared (first use in this function)
drivers/media/video/cafe_ccic.c:1444: error: (Each undeclared identifier is reported only once
drivers/media/video/cafe_ccic.c:1444: error: for each function it appears in.)
drivers/media/video/cafe_ccic.c:1444: error: 'VM_SHARED' undeclared (first use in this function)
drivers/media/video/cafe_ccic.c:1461: error: 'VM_DONTEXPAND' undeclared (first use in this function)
This build breakage is caused by some header file shuffle in linux-next. But
I suggest that this patch be merged ahead of linux-next to avoid bisection
breakage.
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The zr36067 driver should return the actual bytes-per-line value when
queried with ioctl VIDIOC_G_FMT, instead of 0. Otherwise user-space
applications can get confused.
Likewise, with ioctl VIDIOC_S_FMT, we are supposed to fill the
bytes-per-line value. And we shouldn't fail if the caller sets the
initial value to something different from 0. This is perfectly valid
for applications to pre-fill this field with the value they expect.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Restore the default pixel format to YUYV as it used to be before
kernel 2.6.23. It was accidentally changed to BGR3 by commit
603d6f2c8f.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Fix the following crash in the bttv driver:
BUG: unable to handle kernel NULL pointer dereference at 000000000000036c
IP: [<ffffffffa037860a>] radio_open+0x3a/0x170 [bttv]
This happens because radio_open assumes that all present bttv devices
have a radio function. If a bttv device without radio and one with
radio are installed on the same system, and the one without radio is
registered first, then radio_open checks for the radio device number
of a bttv device that has no radio function, and this breaks. All we
have to do to fix it is to skip bttv devices without a radio function.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
CS2102K stop streaming on setlightfreq (50Hz & 60Hz).
Disable it for now until a correct solution is found.
Signed-off-by: Costantino Leandro <le_costantino@pixartargentina.com.ar>
Signed-off-by: Jean-Francois Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Earlier fixes to get the tuner audio working correctly broke the audio
on the Compro VideoMate H900 cards. This is now fixed.
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Exposure was always 0. Thanks to sparse for finding this.
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The device 2040:2950 is a really old variant of the PVR USB2 hardware.
I have just learned of its existence. For the purposes of the pvrusb2
driver, it is functionally identical to the well known 29xxx series
(2040:2900). Amazing that this went undetected for 3+ years.
Signed-off-by: Mike Isely <isely@pobox.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
i2c_client is allocated for us, we should never free it ourselves.
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
While doing some testing using Luca Risolia's sonix driver I noticed that
the video device did not get ACL's set to allow access by locally logged in
users, nor does it show up as a video device in lshal, causing cheese to not
see it.
This turns out to be caused by all of Luca Risolia's drivers not setting
the parent member of the video_device struct. This patch fixes this.
Cc: Luca Risolia <luca.risolia@studio.unibo.it>
Signed-off-by: Hans de Goede <j.w.r.degoede@hhs.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
b2c2-flexcop, dvb/bt8xx and video/bt8xx fails to build on ARM with:
__bad_udelay is specifically designed on ARM to fail when udelay is
called in a bad way. arch/arm/include/asm/delay.h has this to say
about __bad_udelay:
/*
* This function intentionally does not exist; if you see references to
* it, it means that you're calling udelay() with an out of range value.
*
* With currently imposed limits, this means that we support a max delay
* of 2000us. Further limits: HZ<=1000 and bogomips<=3355
*/
extern void __bad_udelay(void);
Solution is to replace udelay by a mdelay and udelay with value less than 2000
Signed-off-by: Thierry MERLE <thierry.merle@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
budget.ko fails to build on ARM with:
ERROR: "__bad_udelay" [drivers/media/dvb/ttpci/budget.ko] undefined!
make[1]: *** [__modpost] Error 1
__bad_udelay is specifically designed on ARM to fail when udelay is
called in a bad way. arch/arm/include/asm/delay.h has this to say
about __bad_udelay:
/*
* This function intentionally does not exist; if you see references to
* it, it means that you're calling udelay() with an out of range value.
*
* With currently imposed limits, this means that we support a max delay
* of 2000us. Further limits: HZ<=1000 and bogomips<=3355
*/
extern void __bad_udelay(void);
Solution is to replace udelay by a mdelay and udelay with value less than 2000
Acked-by: Oliver Endriss <o.endriss@gmx.de>
Signed-off-by: Thierry MERLE <thierry.merle@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
- Adjust hstart in ov7630 on sn9c103 initdata to shift bayer pattern, this is
the same change as done for the other initdata tables in a previous patch.
- Assign usb-id's for the ov7630 + sn9c103 to gspca if gspca and sn9c102
drivers are both enabled.
Signed-off-by: Hans de Goede <j.w.r.degoede@hhs.nl>
Signed-off-by: Jean-Francois Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
-Make raw bayer header size change from 20 to 16 affect rev072a only, my 2
rev012a cams both have a header size of 20
-While testing this I also tested the new exposure setting (good work on
finding the register JF), and after quite a bit of testing have found out the
exact meaning of the register, this patch modifies setexposure to control
the exposure over a much wider range.
Signed-off-by: Hans de Goede <j.w.r.degoede@hhs.nl>
Signed-off-by: Jean-Francois Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
When using the sonixb driver in a dark room and given that the autoexposure
algorithm starts with a setting most suitable for daylight, the picture
produced by the cam may actually be 100% black leading to a avg_lum value of 0,
so an avg_lum value of 0 does not always signal an exposure settings change
(which it normally does). This patch adds a check for the really black image
case and stops dropping all frames as invalid in this case.
Signed-off-by: Hans de Goede <j.w.r.degoede@hhs.nl>
Signed-off-by: Jean-Francois Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This patch makes gspca claim the USB-ID for sn9c101/2 cams with a TAS5110C1B
sensor even if both gspca and sn9c102 are enabled, as these cams are much
better supported under gspca (and extensively tested with gspca).
It also removes an usb-id from sn9c102 for one more unsupported bridge
sensor combo.
Signed-off-by: Hans de Goede <j.w.r.degoede@hhs.nl>
Signed-off-by: Jean-Francois Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
- Add documentation for some known registers
- Add support for vga modes (320x240, 160x120) for sif sensors
- Remove F_RAW sensor flag raw mode should work on any sensor as its a bridge
only thing and keeping the flag was becoming awkward.
- Fixup ov6650 and pas106 auto exposure window settings
Signed-off-by: Hans de Goede <j.w.r.degoede@hhs.nl>
Signed-off-by: Jean-Francois Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This patch fixes a memory leak in an error path.
Reported-by: Adrian Bunk <bunk@kernel.org>
Signed-off-by: Adrian Bunk <bunk@kernel.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
video_device_release() does kfree(), which made the following printk()
doing a use-after-free.
printk() first and release then.
Reported-by: Adrian Bunk <bunk@kernel.org>
Signed-off-by: Adrian Bunk <bunk@kernel.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This adds basic support for the Hauppauge Nova-TD-500 84xxx series.
A future patch will allow for one aerial input to supply both tuners.
With the current code, an aerial must be plugged into each antannae input
in order for both tuners to function.
Signed-off-by: Michael Krufky <mkrufky@linuxtv.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This comment helps to make the code more readable.
Signed-off-by: Michael Krufky <mkrufky@linuxtv.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Some DVB drivers are incorrectly assuming that the size of
i2c_adapter.name is I2C_NAME_SIZE. Here's a fix.
Also change strncpy to strlcpy, as the former is error-prone (and was
indeed incorrectly used.)
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Acked-by: Uwe Bugla <uwe.bugla@gmx.de>
Reviewed-by: Michael Krufky <mkrufky@linuxtv.org>
Signed-off-by: Steven Toth <stoth@hauppauge.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
1) Lower the hstart setting for all sensor by 1 so that we generate
(compressed) BGGR data just like sn9c102 does (instead of GBRG data)
2) Add support for raw bayer output in the lowest resolutions (not enough
bandwidth for higher resolutions), this should work with all sensors but
to be sure only enable it for sensors where it has been tested.
Signed-off-by: Hans de Goede <j.w.r.degoede@hhs.nl>
Signed-off-by: Jean-Francois Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
