Re: [PULL] http://linuxtv.org/hg/~awalls/v4l-dvb
On Sunday 02 August 2009 20:02:30 Andy Walls wrote: > Mauro, > > Please pull from http://linuxtv.org/hg/~awalls/v4l-dvb > > for the following 18 changesets. Hi Andy, I'm going to NAK this series, I'm afraid. My apologies, I should have mailed you that my review was delayed a bit. I quickly looked at this and there are several things that need to be corrected first. First of all any control (even private ones) should be added to videodev2.h. That way applications have access to the CIDs if they want to set them explicitly, and it ensures that the CIDs are all unique. BTW, I wonder whether we shouldn't split off all the control ID stuff into a separate header as it is beginning to be a major part of the videodev2.h header. Mauro, what do you think? In addition they should be documented in the spec. It makes it more work, but it ensures that both developers and end-users can actually read about what these controls do. One problem we have with some of the existing private controls is that they are undocumented and that's something we want to avoid. I also have doubts about the wishdom of about the usefulness of adding secondary bass/treble/balance/mute and loudness controls. A secondary volume might be necessary (I would have to reread the thread on that), but the others? What's the point of two bass controls? And are the other cx18_av controls really needed? Aren't these things that it is the responsibility of the driver to setup correctly? And if they are really needed, then we should perhaps start thinking of an 'advanced' control flag to let apps know that such controls might better be added to an 'advanced' control panel. Regards, Hans > > Note that most of these changes add cx18 driver specific controls, > except the last 2. Those changes fix an I2S clock divisor problem in > the cx18 driver and add secondary audio controls to the ivtv driver. > > > 01/18: cx18: Add user control for setting the extra +12 dB of video gain > http://linuxtv.org/hg/~awalls/v4l-dvb?cmd=changeset;node=2ef91a4f42a9 > > 02/18: cx18: Reformat "Extra 12dB Gain" control string to look more natural > http://linuxtv.org/hg/~awalls/v4l-dvb?cmd=changeset;node=82bf413c60d8 > > 03/18: cx18: Add a control query fill function for cx18 specific user controls > http://linuxtv.org/hg/~awalls/v4l-dvb?cmd=changeset;node=22260bf345c1 > > 04/18: cx18: Add cx18_av core Luma Droop Compensation user control > http://linuxtv.org/hg/~awalls/v4l-dvb?cmd=changeset;node=33f8e5621fe3 > > 05/18: cx18: Add cx18_av core Chroma Droop Compensation user control > http://linuxtv.org/hg/~awalls/v4l-dvb?cmd=changeset;node=1ce8fba3d190 > > 06/18: cx18: Add cx18_av core Luma Clamping user control > http://linuxtv.org/hg/~awalls/v4l-dvb?cmd=changeset;node=85e1fc01dd6f > > 07/18: cx18: Add cx18_av core Chroma Clamping user control > http://linuxtv.org/hg/~awalls/v4l-dvb?cmd=changeset;node=a042df5b8281 > > 08/18: cx18: Add cx18_av core Auto Luma Clamping Level user control > http://linuxtv.org/hg/~awalls/v4l-dvb?cmd=changeset;node=311b5969116c > > 09/18: cx18: Add cx18_av core Auto Digital Gain Control user control > http://linuxtv.org/hg/~awalls/v4l-dvb?cmd=changeset;node=4b1af2abd533 > > 10/18: cx18: Add cx18_av Auto Analog Gain Control user control > http://linuxtv.org/hg/~awalls/v4l-dvb?cmd=changeset;node=8f405aeb13f2 > > 11/18: cx18: Add cx18_av core Auto Sync Height Crush user control > http://linuxtv.org/hg/~awalls/v4l-dvb?cmd=changeset;node=6ae9e079 > > 12/18: cx18: Add cx18_av core Luma Clamping Voltage user control > http://linuxtv.org/hg/~awalls/v4l-dvb?cmd=changeset;node=df97564687a8 > > 13/18: cx18 Add cx18_av core Digital Gain Level control; make func file scope > http://linuxtv.org/hg/~awalls/v4l-dvb?cmd=changeset;node=f7713cb28208 > > 14/18: cx18: Add cx18_av core Analog Gain Level user control > http://linuxtv.org/hg/~awalls/v4l-dvb?cmd=changeset;node=750adcd07696 > > 15/18: cx18: Add cx18_av core Sync Tip Height user control > http://linuxtv.org/hg/~awalls/v4l-dvb?cmd=changeset;node=ca30fa94db6e > > 16/18: cx18: Add cx18_av Sync Acquired/Lost Error Threshold user controls > http://linuxtv.org/hg/~awalls/v4l-dvb?cmd=changeset;node=e4b2c5d550b5 > > 17/18: cx18: Ensure I2S output of A/V core clocks 24 bits/sample > http://linuxtv.org/hg/~awalls/v4l-dvb?cmd=changeset;node=ab8e4bd49b05 > > 18/18: ivtv: Add ability to control a secondary audio chip via user controls > http://linuxtv.org/hg/~awalls/v4l-dvb?cmd=changeset;node=c9f13db7a53e > > > cx18/cx18-av-audio.c | 46 +++-- > cx18/cx18-av-core.c | 441 > ++- > cx18/cx18-av-core.h | 46 - > cx18/cx18-controls.c | 76 > ivtv/ivtv-cards.c|2 > ivtv/ivtv-cards.h|1 > ivtv/ivtv-controls.c | 114 + > ivtv/ivtv-driver.c |1 > ivtv/ivtv-driver.h |1 > 9 files changed, 668 insertions(+), 60 deletions(-) > > Thanks, > Andy > > -- Hans Verkuil - vid
Re: [PATCH] to add support for certain Jeilin dual-mode cameras.
On Sun, 2 Aug 2009 17:25:29 +0400
Alexey Klimov wrote:
> > + buffer = kmalloc(JEILINJ_MAX_TRANSFER, GFP_KERNEL |
> > GFP_DMA);
> > + if (!buffer) {
> > + PDEBUG(D_ERR, "Couldn't allocate USB buffer");
> > + goto quit_stream;
> > + }
>
> This clean up on error path looks bad. On quit_stream you have:
>
> > +quit_stream:
> > + mutex_lock(&gspca_dev->usb_lock);
> > + if (gspca_dev->present)
> > + jlj_stop(gspca_dev);
> > + mutex_unlock(&gspca_dev->usb_lock);
> > + kfree(buffer);
>
> kfree() tries to free null buffer after kmalloc for buffer failed.
> Please, check if i'm not wrong.
Hi Alexey,
AFAIK, kfree() checks the pointer.
Cheers.
--
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef | http://moinejf.free.fr/
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] ARM: DaVinci: DM646x Video: Platform and board specific setup
Em Mon, 3 Aug 2009 09:17:06 +0530 "chaithrika" escreveu: > Mauro/Russell, > > The previous version (v2) of this patch is on the linux-next tree. > This patch has some updates done on top of that patch. Should I > post an incremental patch for those changes to the Linux-next tree? > Please suggest. > It is not needed. After having Russell ack, I'll just replace the old patch by the new one. Cheers, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v3] ARM: DaVinci: DM646x Video: Platform and board specific setup
Mauro/Russell,
The previous version (v2) of this patch is on the linux-next tree.
This patch has some updates done on top of that patch. Should I
post an incremental patch for those changes to the Linux-next tree?
Please suggest.
Regards,
Chaithrika
On Mon, Jul 20, 2009 at 13:31:22, Chaithrika U S wrote:
> Platform specific display device setup for DM646x EVM
>
> Add platform device and resource structures. Also define a platform
specific
> clock setup function that can be accessed by the driver to configure the
clock
> and CPLD.
>
> Signed-off-by: Manjunath Hadli
> Signed-off-by: Brijesh Jadav
> Signed-off-by: Chaithrika U S
> Signed-off-by: Kevin Hilman
> ---
> Applies to Davinci GIT tree. Minor updates like change in structure name-
> subdev_info to vpif_subdev_info and correction to VDD3P3V_VID_MASK value.
>
> arch/arm/mach-davinci/board-dm646x-evm.c| 125
+++
> arch/arm/mach-davinci/dm646x.c | 62 +
> arch/arm/mach-davinci/include/mach/dm646x.h | 24 +
> 3 files changed, 211 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-davinci/board-dm646x-evm.c
b/arch/arm/mach-davinci/board-dm646x-evm.c
> index b1bf18c..8c88fd0 100644
> --- a/arch/arm/mach-davinci/board-dm646x-evm.c
> +++ b/arch/arm/mach-davinci/board-dm646x-evm.c
> @@ -63,6 +63,19 @@
> #define DM646X_EVM_PHY_MASK (0x2)
> #define DM646X_EVM_MDIO_FREQUENCY(220) /* PHY bus frequency */
>
> +#define VIDCLKCTL_OFFSET (0x38)
> +#define VSCLKDIS_OFFSET (0x6c)
> +
> +#define VCH2CLK_MASK (BIT_MASK(10) | BIT_MASK(9) | BIT_MASK(8))
> +#define VCH2CLK_SYSCLK8 (BIT(9))
> +#define VCH2CLK_AUXCLK (BIT(9) | BIT(8))
> +#define VCH3CLK_MASK (BIT_MASK(14) | BIT_MASK(13) | BIT_MASK(12))
> +#define VCH3CLK_SYSCLK8 (BIT(13))
> +#define VCH3CLK_AUXCLK (BIT(14) | BIT(13))
> +
> +#define VIDCH2CLK(BIT(10))
> +#define VIDCH3CLK(BIT(11))
> +
> static struct davinci_uart_config uart_config __initdata = {
> .enabled_uarts = (1 << 0),
> };
> @@ -288,6 +301,40 @@ static struct snd_platform_data dm646x_evm_snd_data[]
= {
> },
> };
>
> +static struct i2c_client *cpld_client;
> +
> +static int cpld_video_probe(struct i2c_client *client,
> + const struct i2c_device_id *id)
> +{
> + cpld_client = client;
> + return 0;
> +}
> +
> +static int __devexit cpld_video_remove(struct i2c_client *client)
> +{
> + cpld_client = NULL;
> + return 0;
> +}
> +
> +static const struct i2c_device_id cpld_video_id[] = {
> + { "cpld_video", 0 },
> + { }
> +};
> +
> +static struct i2c_driver cpld_video_driver = {
> + .driver = {
> + .name = "cpld_video",
> + },
> + .probe = cpld_video_probe,
> + .remove = cpld_video_remove,
> + .id_table = cpld_video_id,
> +};
> +
> +static void evm_init_cpld(void)
> +{
> + i2c_add_driver(&cpld_video_driver);
> +}
> +
> static struct i2c_board_info __initdata i2c_info[] = {
> {
> I2C_BOARD_INFO("24c256", 0x50),
> @@ -300,6 +347,9 @@ static struct i2c_board_info __initdata i2c_info[] =
{
> {
> I2C_BOARD_INFO("cpld_reg0", 0x3a),
> },
> + {
> + I2C_BOARD_INFO("cpld_video", 0x3B),
> + },
> };
>
> static struct davinci_i2c_platform_data i2c_pdata = {
> @@ -307,11 +357,85 @@ static struct davinci_i2c_platform_data i2c_pdata =
{
> .bus_delay = 0 /* usec */,
> };
>
> +static int set_vpif_clock(int mux_mode, int hd)
> +{
> + int val = 0;
> + int err = 0;
> + unsigned int value;
> + void __iomem *base = IO_ADDRESS(DAVINCI_SYSTEM_MODULE_BASE);
> +
> + if (!cpld_client)
> + return -ENXIO;
> +
> + /* disable the clock */
> + value = __raw_readl(base + VSCLKDIS_OFFSET);
> + value |= (VIDCH3CLK | VIDCH2CLK);
> + __raw_writel(value, base + VSCLKDIS_OFFSET);
> +
> + val = i2c_smbus_read_byte(cpld_client);
> + if (val < 0)
> + return val;
> +
> + if (mux_mode == 1)
> + val &= ~0x40;
> + else
> + val |= 0x40;
> +
> + err = i2c_smbus_write_byte(cpld_client, val);
> + if (err)
> + return err;
> +
> + value = __raw_readl(base + VIDCLKCTL_OFFSET);
> + value &= ~(VCH2CLK_MASK);
> + value &= ~(VCH3CLK_MASK);
> +
> + if (hd >= 1)
> + value |= (VCH2CLK_SYSCLK8 | VCH3CLK_SYSCLK8);
> + else
> + value |= (VCH2CLK_AUXCLK | VCH3CLK_AUXCLK);
> +
> + __raw_writel(value, base + VIDCLKCTL_OFFSET);
> +
> + /* enable the clock */
> + value = __raw_readl(base + VSCLKDIS_OFFSET);
> + value &= ~(VIDCH3CLK | VIDCH2CLK);
> + __raw_writel(value, base + VSCLKDIS_OFFSET);
> +
> + return 0;
> +}
> +
> +static const struct vpif_subdev_info dm646x_vpif_subdev[] = {
> + {
> + .addr = 0x2A,
> +
Re: Terratec Cinergy HibridT XS
On Sat, Aug 1, 2009 at 6:48 PM, Valerio Messina wrote: > Valerio Messina ha scritto: >> >> Devin Heitmueller ha scritto: >>> >>> Ah, good news: the patch I wrote that adds support for the remote >>> control is still around: >>> >>> http://linuxtv.org/hg/~dheitmueller/v4l-dvb-terratec-xs/rev/92885f66ac68 >>> >>> I will prep this into a new tree and issue a pull request when I get >>> back in town on Sunday. >> >> hi, >> I tried to apply the patch, recompile, install and reboot. >> Same results, IR does not send digit to text editor or Kaffeine. >> >> What other can I do for further help/testing? > > I tried another thing. > I unzipped a 2009-01-29 version of > http://mcentral.de/hg/~mrec/v4l-dvb-kernel > the last I used on Ubuntu 8.10, not really updated but worked, > recompiled for the new Ubuntu kernel > 2.6.28-14-generic > install and reboot. > This one work, IR send digit to text editor and Kaffeine. > Now I remember, with past Ubuntu version I used mcentral modules, and not > linuxtv ones. This is why IR worked for me. > > I uploaded this shot of the disappeared mercurial repositories here: > http://sharebee.com/fed68f5f > all in all is all GPL code. > > I looked at the code, and see that 'v4l-dvb-kernel' consist of less files, > in particular are 296 files, while 'v4l-dvb' are 7916, probably because > there are only em28xx related files. > The source tree have some different organization. > I see that: > v4l-dvb/linux/include/media/ir-common.h > and > v4l-dvb/linux/drivers/media/common/ir-keymaps.c > does not exist > > v4l-dvb/linux/drivers/media/video/em28xx/em28xx-cards.c > is located here: > v4l-dvb-kernel/em28xx-cards.c > and diff report lot lot of differencies. > > hope this helps integrating IR support, > Valerio > > -- > To unsubscribe from this list: send the line "unsubscribe linux-media" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Valerio, I'll get my patched merged (and make sure I didn't miss something). There is no need for the mcentral.de tree. I had the whole thing working so perhaps the code that enabled the IR support was in a separate patch. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: USB devices supporting raw or sliced VBI for closed captioning?
Am Sonntag, den 02.08.2009, 10:24 +0200 schrieb Markus Rechberger: > On Sun, Aug 2, 2009 at 2:49 AM, hermann pitton wrote: > > > > Am Samstag, den 01.08.2009, 03:45 +0200 schrieb Markus Rechberger: > >> Hi, > >> > >> On Sat, Aug 1, 2009 at 1:20 AM, Steve Castellotti > >> wrote: > >> > > >> >I was wondering if anyone could please point me at a list or > >> > similar > >> > resource for USB capture devices which support raw (or sliced) VBI > >> > access for producing a closed caption transcript through software such > >> > as zbvi-ntsc-cc or ccextractor? Specifically I'm wanting a device > >> > capable of S-Video, Composite, or even Component input, not just ATSC, > >> > as most USB devices seem focused around these days. > >> > > >> >I've managed to get this working with various ivtv and saa713x > >> > based > >> > PCI devices, but aren't aware of any USB implementations of chipsets > >> > which use those drivers. > >> > > >> > > >> >Searching online, I found this archived message: > >> > > >> > http://lists.zerezo.com/video4linux/msg16402.html > >> > > >> > which states: > >> > > >> >> some em2840 and newer devices are able to capture raw vbi in > >> >> linux (sliced vbi isn't possible yet) > >> >> em2820, em2800, em2750 do not support vbi at all. > >> > > >> > > >> >Checking the em28xx driver homepage for recent models, I found > >> > this > >> > entry: > >> > > >> > http://mcentral.de/wiki/index.php5/Em2880 > >> > > >> >> officially the em2880 is em2840 + DVB_T > >> > > >> > > >> >which implies that not only is the "em2880" series a "newer" > >> > device, > >> > but it should in fact already contain the "em2840" chip specifically > >> > mentioned. > >> > > >> > > >> >Later on that same page, in the list of devices: > >> > > >> > ATI/AMD TV Wonder 600 > >> > > >> > > >> >and on the manufacturer's page: > >> > > >> > http://ati.amd.com/products/tvwonder600/usb/index.html > >> > > >> > > >> >Under the list of "Input Connectors": > >> > > >> >> S-video input with adapter > >> > > >> > > >> > > >> >Picking up one of these devices, I attempted to tune into the > >> > S-Video > >> > feed and check the /dev/vbi0 device, but received the same error message > >> > as I do with all other em28xx devices encountered thus far: > >> > > >> >> Cannot capture vbi data with v4l interface: > >> >> /dev/vbi0 (AMD ATI TV Wonder HD 600) is not a raw vbi device. > >> > > >> > > >> > > >> >Can anyone please point me in the right direction? > >> > > >> >I would much prefer to be certain the next purchase is supported. > >> > > >> > > >> > > >> > Thanks! > >> > > >> > >> we do support Raw VBI for our devices, Sundtek MediaTV Pro for closed > >> captioning. > >> Alternatively we also have full support for ATSC-analogTV USB devices > >> for the US market ([em288x]-[AVFB4910]-[Trident drx-J]-[tda18271]) the > >> european product which we are selling is also capable of decoding NTSC > >> closed caption. > >> > >> http://sundtek.de/shop/Digital-TV-Sticks-oxid/Sundtek-MediaTV-Pro.html > >> (this is just the information about the > >> European/DVB-T/DVB-C/analogTV(raw VBI) device, we do not have the > >> US/ATSC/analogTV(rawVBI) product listed there, although we do offer it > >> to business customers) We support it from Linux 2.6.15 on. > >> > >> Best Regards, > >> Markus Rechberger > > > > Hi, > > > > anything new about how to deal with commercial advertising on lists, > > depending totally on our source? > > > > Please have a look. > > The question was about a device, and I doubt that you can get a device > for free anywhere. If so there shouldn't be any other company names in > drivers, > or named on the mailinglist (to be fair) which do not support Linux. > > Best Regards, > Markus Markus, that is of course not the question at all. All questions are about your above sundtek.de link, especially about what you announce in the user support forum for now. Given, that Conexant did provide a GPLed driver for cx231xx USB devices recently, you are intentionally going into the other direction. I don't even claim, that you should point to this driver too, if it goes about vbi and closed caption support on USB devices, it has it, BUT you have gone closed source with your driver, deliver the linux driver to your customers only, if they are identified by the serial number of the device you did sell them. I expect the worst for all further usage conditions. So, you do not only hide the vbi support you have on em28xx devices now to us, but likely made it even hard to "hack" such devices intentionally. In the same row is, that you announce advanced "direct" audio support with "tvtime" and soon more features with other GNU/Linux applications exclusively on your hardware and drivers and don't give back to all working on them over years. That is exactly what nobody wants and an abuse of all other contributors. Since you do all this intentionall
Re: [PATCH] to add support for certain Jeilin dual-mode cameras. (resubmit)
On Sun, 2 Aug 2009, Jean-Francois Moine wrote:
On Sat, 1 Aug 2009 16:56:06 -0500 (CDT)
Theodore Kilgore wrote:
Several cameras are supported here, which all share the same USB
Vendor:Product number when started up in streaming mode. All of these
cameras use bulk transport for streaming, and all of them produce
frames in JPEG format.
Hi Theodore,
Your patch seems ok, but:
- there is no kfree(sd->jpeg_hdr). Should be in stop0().
- as there is only one vend:prod, one line is enough in gspca.txt.
May you fix this and resend?
Thanks.
--
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef | http://moinejf.free.fr/
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Jean-Francois,
The version below should meet your objections. The memory for the header
is freed, and I keep only one entry for the USB ID in gspca.txt. After
some deliberation, I decided to keep the entry for the Sakar camera
(belongs to Andy Walls), as that seems to be the one which was most
recently purchased.
At the same time, I hope very much that the points which I have raised
in my previous response in regard to documentation can be seriously
discussed. As I see it, there is a problem about documentation.
Theodore Kilgore
Patch follows.
Signed-off-by: Theodore Kilgore
diff -r d189fb4be712 linux/Documentation/video4linux/gspca.txt
--- a/linux/Documentation/video4linux/gspca.txt Wed Jul 29 10:01:54 2009 +0200
+++ b/linux/Documentation/video4linux/gspca.txt Sun Aug 02 14:12:25 2009 -0500
@@ -239,6 +239,7 @@
pac7311093a:2629 Genious iSlim 300
pac7311093a:262a Webcam 300k
pac7311093a:262c Philips SPC 230 NC
+jeilinj0979:0280 Sakar 57379
zc3xx 0ac8:0302 Z-star Vimicro zc0302
vc032x 0ac8:0321 Vimicro generic vc0321
vc032x 0ac8:0323 Vimicro Vc0323
diff -r d189fb4be712 linux/drivers/media/video/gspca/Kconfig
--- a/linux/drivers/media/video/gspca/Kconfig Wed Jul 29 10:01:54 2009 +0200
+++ b/linux/drivers/media/video/gspca/Kconfig Sun Aug 02 14:12:25 2009 -0500
@@ -47,6 +47,15 @@
To compile this driver as a module, choose M here: the
module will be called gspca_finepix.
+config USB_GSPCA_JEILINJ
+ tristate "Jeilin JPEG USB V4L2 driver"
+ depends on VIDEO_V4L2 && USB_GSPCA
+ help
+ Say Y here if you want support for cameras based on this Jeilin chip.
+
+ To compile this driver as a module, choose M here: the
+ module will be called gspca_jeilinj.
+
config USB_GSPCA_MARS
tristate "Mars USB Camera Driver"
depends on VIDEO_V4L2 && USB_GSPCA
diff -r d189fb4be712 linux/drivers/media/video/gspca/Makefile
--- a/linux/drivers/media/video/gspca/Makefile Wed Jul 29 10:01:54 2009 +0200
+++ b/linux/drivers/media/video/gspca/Makefile Sun Aug 02 14:12:25 2009 -0500
@@ -2,6 +2,7 @@
obj-$(CONFIG_USB_GSPCA_CONEX)+= gspca_conex.o
obj-$(CONFIG_USB_GSPCA_ETOMS)+= gspca_etoms.o
obj-$(CONFIG_USB_GSPCA_FINEPIX) += gspca_finepix.o
+obj-$(CONFIG_USB_GSPCA_JEILINJ) += gspca_jeilinj.o
obj-$(CONFIG_USB_GSPCA_MARS) += gspca_mars.o
obj-$(CONFIG_USB_GSPCA_MR97310A) += gspca_mr97310a.o
obj-$(CONFIG_USB_GSPCA_OV519)+= gspca_ov519.o
@@ -30,6 +31,7 @@
gspca_conex-objs:= conex.o
gspca_etoms-objs:= etoms.o
gspca_finepix-objs := finepix.o
+gspca_jeilinj-objs := jeilinj.o
gspca_mars-objs := mars.o
gspca_mr97310a-objs := mr97310a.o
gspca_ov519-objs:= ov519.o
diff -r d189fb4be712 linux/drivers/media/video/gspca/jeilinj.c
--- /dev/null Thu Jan 01 00:00:00 1970 +
+++ b/linux/drivers/media/video/gspca/jeilinj.c Sun Aug 02 14:12:25 2009 -0500
@@ -0,0 +1,388 @@
+/*
+ * Jeilinj subdriver
+ *
+ * Supports some Jeilin dual-mode cameras which use bulk transport and
+ * download raw JPEG data.
+ *
+ * Copyright (C) 2009 Theodore Kilgore
+ *
+ * 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
+ * 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., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#define MODULE_NAME "jeilinj"
+
+#include
+#include "gspca.h"
+#include "jpeg.h"
+
+MODULE_AUTHOR("Theodore Kilgore ");
+MODULE_DESCRIPTION("GSPCA/JEILINJ USB Camera Driv
[PATCH] Rework the RTL2831 remote control handler to reuse dibusb.
Hi. This patch is against the rtl2831-r2 tree.
This patch is really just a proof of concept, that the dibusb handler
code can handle the rtl2831 remote codes. I have both types of device
and noticed that the remotes are interchangable, and it turns out the
code tables are too, but for a quirk in the way the rtl driver looks
up the values (it uses the wrong fields in keybuf.)
Is there any progress on getting the rtl2831 driver ready for
inclusion into the mainline?
# HG changeset patch
# User Alistair Buxton
# Date 1249239142 -3600
# Node ID 83476a81ce48824891f64cebfd293239acafc878
# Parent 1557237aa2ebb25d807e4af251fdf08b182660fb
RTL2831: Rework the RTL2831 remote control code to reuse the dibusb
remote control handler.
1. Add the extra codes of the AzureWave AD-TU800 remote to the dibusb
code table. This remote
uses the same NEC codes as the dibusb remotes, but with extra buttons.
As a bonus, this makes
the AzureWave remote work with dibusb devices too.
2. Make rtd2831u_rc_query() use dvb_usb_nec_rc_key_to_event() instead
of it's own slightly
broken implementation.
3. Fix up the Conceptronic keycode table. This is NEC compatible but
uses different codes to
the dibusb_rc_keys[]. The fields are switched around to make the table
compatible with
dvb_usb_nec_rc_key_to_event().
4. Fudge the keybuf when using RC5 table.
5. Fix all the drivers that use dibusb_rc_keys[] with the new length.
diff -r 1557237aa2eb -r 83476a81ce48
linux/drivers/media/dvb/dvb-usb/dibusb-common.c
--- a/linux/drivers/media/dvb/dvb-usb/dibusb-common.c Tue May 19
22:29:10 2009 +0200
+++ b/linux/drivers/media/dvb/dvb-usb/dibusb-common.c Sun Aug 02
19:52:22 2009 +0100
@@ -351,6 +351,31 @@
{ 0x00, 0x48, KEY_INFO }, /* Preview */
{ 0x00, 0x04, KEY_LIST }, /* RecordList */
{ 0x00, 0x0f, KEY_TEXT }, /* Teletext */
+ /* additional keys for the azurewave remote */
+ { 0x00, 0x4a, KEY_UNKNOWN }, /* Clear */
+ { 0x00, 0x13, KEY_BACK },
+ { 0x00, 0x4b, KEY_UP },
+ { 0x00, 0x51, KEY_DOWN },
+ { 0x00, 0x4e, KEY_LEFT },
+ { 0x00, 0x52, KEY_RIGHT },
+ { 0x00, 0x4f, KEY_ENTER },
+ { 0x00, 0x4c, KEY_PAUSE },
+ { 0x00, 0x41, KEY_PREVIOUSSONG }, /* |< */
+ { 0x00, 0x42, KEY_NEXTSONG }, /* >| */
+ { 0x00, 0x54, KEY_CAMERA }, /* capture (has picture of camera on it) */
+ { 0x00, 0x50, KEY_UNKNOWN }, /* SAP */
+ { 0x00, 0x47, KEY_UNKNOWN }, /* PIP */
+ { 0x00, 0x4d, KEY_UNKNOWN }, /* fullscreen */
+ { 0x00, 0x43, KEY_SUBTITLE },
+ { 0x00, 0x49, KEY_UNKNOWN }, /* L/R */
+ { 0x00, 0x07, KEY_POWER2 }, /* hibernate */
+ { 0x00, 0x08, KEY_VIDEO_NEXT },
+ { 0x00, 0x45, KEY_ZOOMIN },
+ { 0x00, 0x46, KEY_ZOOMOUT },
+ { 0x00, 0x18, KEY_RED },
+ { 0x00, 0x53, KEY_GREEN },
+ { 0x00, 0x5e, KEY_YELLOW },
+ { 0x00, 0x5f, KEY_BLUE },
/* Key codes for the KWorld/ADSTech/JetWay remote. */
{ 0x86, 0x12, KEY_POWER },
{ 0x86, 0x0f, KEY_SELECT }, /* source */
diff -r 1557237aa2eb -r 83476a81ce48 linux/drivers/media/dvb/dvb-usb/dibusb-mb.c
--- a/linux/drivers/media/dvb/dvb-usb/dibusb-mb.c Tue May 19 22:29:10
2009 +0200
+++ b/linux/drivers/media/dvb/dvb-usb/dibusb-mb.c Sun Aug 02 19:52:22
2009 +0100
@@ -213,7 +213,7 @@
.rc_interval = DEFAULT_RC_INTERVAL,
.rc_key_map = dibusb_rc_keys,
- .rc_key_map_size = 111, /* wow, that is ugly ... I want to load it
to the driver dynamically */
+ .rc_key_map_size = 135, /* wow, that is ugly ... I want to load it
to the driver dynamically */
.rc_query = dibusb_rc_query,
.i2c_algo = &dibusb_i2c_algo,
@@ -297,7 +297,7 @@
.rc_interval = DEFAULT_RC_INTERVAL,
.rc_key_map = dibusb_rc_keys,
- .rc_key_map_size = 111, /* wow, that is ugly ... I want to load it
to the driver dynamically */
+ .rc_key_map_size = 135, /* wow, that is ugly ... I want to load it
to the driver dynamically */
.rc_query = dibusb_rc_query,
.i2c_algo = &dibusb_i2c_algo,
@@ -361,7 +361,7 @@
.rc_interval = DEFAULT_RC_INTERVAL,
.rc_key_map = dibusb_rc_keys,
- .rc_key_map_size = 111, /* wow, that is ugly ... I want to load it
to the driver dynamically */
+ .rc_key_map_size = 135, /* wow, that is ugly ... I want to load it
to the driver dynamically */
.rc_query = dibusb_rc_query,
.i2c_algo = &dibusb_i2c_algo,
@@ -418,7 +418,7 @@
.rc_interval = DEFAULT_RC_INTERVAL,
.rc_key_map = dibusb_rc_keys,
- .rc_key_map_size = 111, /* wow, that is ugly ... I want to load it
to the driver dynamically */
+ .rc_key_map_size = 135, /* wow, that is ugly ... I want to load it
to the driver dynamically */
.rc_query = dibusb_rc_query,
.i2c_algo = &dibusb_i2c_algo,
diff -r 1557237aa2eb -r
Re: correct implementation of FE_READ_UNCORRECTED_BLOCKS
On Sun, Aug 02, 2009 at 02:11:38PM -0400, Andy Walls wrote:
> On Sun, 2009-08-02 at 20:56 +0300, Aleksandr V. Piskunov wrote:
> > Oops, sent it way too fast. Anyway.
> >
> > DVB API documentation says:
> > "This ioctl call returns the number of uncorrected blocks detected by
> > the device driver during its lifetime Note that the counter will
> > wrap to zero after its maximum count has been reached."
> >
> > Does it mean that correct implementation of frontend driver should
> > keep its own counter of UNC blocks and increment it every time hardware
> > reports such block?
>
> No, but a frontend driver may wish to keep a software counter that is
> wider than the hardware register counter, in case the hardware register
> rolls over too frequently.
>
>
> > >From what I see, a lot of current frontend drivers simply dump a value
> > from some hardware register. For example zl10353 I got here reports
> > some N unc blocks and then gets back to reporting zero.
>
> To support the use case of multiple user apps trying to collect UNC
> block statistics, the driver should not zero out the UNC block counter
> when read. If the hardware zeros it automatically, then one probably
> should maintain a software counter in the driver.
>
Here is a patch that makes zl10353 a bit more DVB API compliant:
FE_READ_UNCORRECTED_BLOCKS - keep a counter of UNC blocks
FE_GET_FRONTEND - return last set frequency instead of zero
Signed-off-by: Aleksandr V. Piskunov
--- v4l-dvb/linux/drivers/media/dvb/frontends/zl10353.c.orig2009-08-02
15:38:28.133464216 +0300
+++ v4l-dvb/linux/drivers/media/dvb/frontends/zl10353.c 2009-08-02
16:03:00.305465369 +0300
@@ -39,6 +39,8 @@ struct zl10353_state {
struct zl10353_config config;
enum fe_bandwidth bandwidth;
+ u32 ucblocks;
+ u32 frequency;
};
static int debug;
@@ -204,6 +206,8 @@ static int zl10353_set_parameters(struct
u16 tps = 0;
struct dvb_ofdm_parameters *op = ¶m->u.ofdm;
+ state->frequency = param->frequency;
+
zl10353_single_write(fe, RESET, 0x80);
udelay(200);
zl10353_single_write(fe, 0xEA, 0x01);
@@ -469,7 +473,7 @@ static int zl10353_get_parameters(struct
break;
}
- param->frequency = 0;
+ param->frequency = state->frequency;
op->bandwidth = state->bandwidth;
param->inversion = INVERSION_AUTO;
@@ -549,9 +553,13 @@ static int zl10353_read_snr(struct dvb_f
static int zl10353_read_ucblocks(struct dvb_frontend *fe, u32 *ucblocks)
{
struct zl10353_state *state = fe->demodulator_priv;
+ u32 ubl = 0;
+
+ ubl = zl10353_read_register(state, RS_UBC_1) << 8 |
+ zl10353_read_register(state, RS_UBC_0);
- *ucblocks = zl10353_read_register(state, RS_UBC_1) << 8 |
- zl10353_read_register(state, RS_UBC_0);
+ state->ucblocks += ubl;
+ *ucblocks = state->ucblocks;
return 0;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PULL] http://linuxtv.org/hg/~tmerle/v4l-dvb
Hi Mauro, please pull from http://linuxtv.org/hg/~tmerle/v4l-dvb the following patch from Eberhard Mattes: - dvb-usb: fix tuning with Cinergy T2 http://linuxtv.org/hg/~tmerle/v4l-dvb/rev/75be92928287 Eberhard, thanks for this bugfix, I did not have time nor hardware to work on that and you did a great investigation job. cinergyT2-fe.c |1 + 1 file changed, 1 insertion(+) Cheers, Thierry -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] to add support for certain Jeilin dual-mode cameras.
On Sun, 2 Aug 2009, Jean-Francois Moine wrote: On Sat, 1 Aug 2009 16:56:06 -0500 (CDT) Theodore Kilgore wrote: Several cameras are supported here, which all share the same USB Vendor:Product number when started up in streaming mode. All of these cameras use bulk transport for streaming, and all of them produce frames in JPEG format. Hi Theodore, Your patch seems ok, but: - there is no kfree(sd->jpeg_hdr). Should be in stop0(). OK. Will do, and resend, as asked. But before I do that, there is the second item. It seems to raise questions of policy. I think it is appropriate to raise that question for general discussion. - as there is only one vend:prod, one line is enough in gspca.txt. This is a question about which I have been curious for quite some time, and I think that now is a good time to ask it. Just what policy do we have about this? The information which links brand and model to driver ought to be presented somewhere. If it does not go into gspca.txt then where exactly is the appropriate place to put said information? As to these three particular cameras, perhaps one should take into account here the fact that what we actually have here is three "different" cameras, put on the market by three different vendors, and in at least two different parts of the world. The Sakar camera and the Cobra camera are for sale in the US. The FlyOne camera is for sale in Germany and perhaps in some other parts of Europe. Furthermore, in stillcam mode they are all three of them standard mass storage devices, but they have different IDs from what is listed here (good for them about that!) and the stillcam IDs are distinct, too. So in other words they are not the same camera, at all, in spite of the fact that they all use the same ID when set up in webcam mode. A more general consideration is that the buyer of a camera is not helped at all by knowing that a particular chipset combination is supported. No. The buyer can only go by the make and model which are printed on the outside of the plastic bubble pack. So what exactly are we, the developers, to do in order to make the relevant information available to the public? There is some wiki, of course. But it seems to me the wiki itself ought to refer to the gspca.txt file, among other things. I do think that one of the easy ways to address the above issue of helping the camera purchaser would be to agree that gspca.txt ought to contain the information for each individual camera which is supported. This would make the file longer, but it is in my opinion a small price to pay, when the goal is to have complete information, put in a central place. In going over the gspca.txt file, I also see that the jeilinj entries are the only place where there is a "duplicate" entry, so that I am at this time in non-conformity. But, on checking, I also see that the SQ905 cameras (2770:9120) and the SQ905C cameras (2770:905c) are not listed at all in gspca.txt. This could be claimed as an example of my ignorance that I am supposed to put something there. But it is also related to the fact that -- there are twenty-five (25) cameras listed in libgphoto2/camlibs/sq905/library.c, which were reported to me as working with that particular stillcam driver. This list does not include several other cameras that I only heard about vaguely, or that I do not even know about at all because nobody ever reported them to me. So if I am supposed to pick just one of these, then which one do I list in gspca.txt, when as far as I know they all ought to work with the gspca sq905 driver? and, as for the SQ905C cameras -- there are seventeen (17) cameras listed in libgphoto2/camlibs/digigr8/library.c, which were reported to me as working with that particular stillcam driver. This list does not include several other cameras that I only heard about vaguely, or that I do not even know about at all because nobody ever reported them to me. If I am supposed to pick just one of these, then which one do I list in gspca.txt, when as far as I know they all ought to work with the gspca sq905c driver? For the above reasons, I have up to this point not listed any of these cameras in gspca.txt at all, as supported. Probably that is not the right thing to do, either? Now, in addition to the above, there is another problem which will hit very soon, probably soon after the time that Thomas Kaiser gets back from his vacation and starts to work again. This is the matter of the mr97310a driver, which is almost finished now. What we have there is a list of cameras which are all functionally identical as still cameras, but as webcams the functionality differs in minor details. Here is what happens: 08ca:0111 Aiptek Pencam VGA+ (supported, listed in gspca.txt) 093a:010f several cameras, some functionally identical to the Aiptek camera, and some which as webcams require a different init procedure and use different control procedur
[cron job] v4l-dvb daily build 2.6.22 and up: WARNINGS, 2.6.16-2.6.21: ERRORS
This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below. Results of the daily build of v4l-dvb: date:Sun Aug 2 19:00:02 CEST 2009 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 12375:b15490457d60 gcc version: gcc (GCC) 4.3.1 hardware:x86_64 host os: 2.6.26 linux-2.6.22.19-armv5: OK linux-2.6.23.12-armv5: OK linux-2.6.24.7-armv5: OK linux-2.6.25.11-armv5: OK linux-2.6.26-armv5: OK linux-2.6.27-armv5: OK linux-2.6.28-armv5: OK linux-2.6.29.1-armv5: OK linux-2.6.30-armv5: OK linux-2.6.31-rc5-armv5: OK linux-2.6.27-armv5-ixp: WARNINGS linux-2.6.28-armv5-ixp: WARNINGS linux-2.6.29.1-armv5-ixp: WARNINGS linux-2.6.30-armv5-ixp: WARNINGS linux-2.6.31-rc5-armv5-ixp: WARNINGS linux-2.6.28-armv5-omap2: WARNINGS linux-2.6.29.1-armv5-omap2: WARNINGS linux-2.6.30-armv5-omap2: WARNINGS linux-2.6.31-rc5-armv5-omap2: WARNINGS linux-2.6.22.19-i686: WARNINGS linux-2.6.23.12-i686: WARNINGS linux-2.6.24.7-i686: WARNINGS linux-2.6.25.11-i686: WARNINGS linux-2.6.26-i686: WARNINGS linux-2.6.27-i686: WARNINGS linux-2.6.28-i686: WARNINGS linux-2.6.29.1-i686: WARNINGS linux-2.6.30-i686: WARNINGS linux-2.6.31-rc5-i686: WARNINGS linux-2.6.23.12-m32r: OK linux-2.6.24.7-m32r: OK linux-2.6.25.11-m32r: OK linux-2.6.26-m32r: OK linux-2.6.27-m32r: OK linux-2.6.28-m32r: OK linux-2.6.29.1-m32r: OK linux-2.6.30-m32r: OK linux-2.6.31-rc5-m32r: OK linux-2.6.30-mips: WARNINGS linux-2.6.31-rc5-mips: WARNINGS linux-2.6.27-powerpc64: WARNINGS linux-2.6.28-powerpc64: WARNINGS linux-2.6.29.1-powerpc64: WARNINGS linux-2.6.30-powerpc64: WARNINGS linux-2.6.31-rc5-powerpc64: WARNINGS linux-2.6.22.19-x86_64: WARNINGS linux-2.6.23.12-x86_64: WARNINGS linux-2.6.24.7-x86_64: WARNINGS linux-2.6.25.11-x86_64: WARNINGS linux-2.6.26-x86_64: WARNINGS linux-2.6.27-x86_64: WARNINGS linux-2.6.28-x86_64: WARNINGS linux-2.6.29.1-x86_64: WARNINGS linux-2.6.30-x86_64: WARNINGS linux-2.6.31-rc5-x86_64: WARNINGS sparse (linux-2.6.30): OK sparse (linux-2.6.31-rc5): OK linux-2.6.16.61-i686: ERRORS linux-2.6.17.14-i686: ERRORS linux-2.6.18.8-i686: ERRORS linux-2.6.19.5-i686: ERRORS linux-2.6.20.21-i686: WARNINGS linux-2.6.21.7-i686: WARNINGS linux-2.6.16.61-x86_64: ERRORS linux-2.6.17.14-x86_64: ERRORS linux-2.6.18.8-x86_64: ERRORS linux-2.6.19.5-x86_64: ERRORS linux-2.6.20.21-x86_64: WARNINGS linux-2.6.21.7-x86_64: WARNINGS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Sunday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Sunday.tar.bz2 The V4L2 specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/v4l2.html The DVB API specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/dvbapi.pdf -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: correct implementation of FE_READ_UNCORRECTED_BLOCKS
On Sun, 2009-08-02 at 20:56 +0300, Aleksandr V. Piskunov wrote: > Oops, sent it way too fast. Anyway. > > DVB API documentation says: > "This ioctl call returns the number of uncorrected blocks detected by > the device driver during its lifetime Note that the counter will > wrap to zero after its maximum count has been reached." > > Does it mean that correct implementation of frontend driver should > keep its own counter of UNC blocks and increment it every time hardware > reports such block? No, but a frontend driver may wish to keep a software counter that is wider than the hardware register counter, in case the hardware register rolls over too frequently. > >From what I see, a lot of current frontend drivers simply dump a value > from some hardware register. For example zl10353 I got here reports > some N unc blocks and then gets back to reporting zero. To support the use case of multiple user apps trying to collect UNC block statistics, the driver should not zero out the UNC block counter when read. If the hardware zeros it automatically, then one probably should maintain a software counter in the driver. Regards, Andy -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PULL] http://linuxtv.org/hg/~awalls/v4l-dvb
Mauro, Please pull from http://linuxtv.org/hg/~awalls/v4l-dvb for the following 18 changesets. Note that most of these changes add cx18 driver specific controls, except the last 2. Those changes fix an I2S clock divisor problem in the cx18 driver and add secondary audio controls to the ivtv driver. 01/18: cx18: Add user control for setting the extra +12 dB of video gain http://linuxtv.org/hg/~awalls/v4l-dvb?cmd=changeset;node=2ef91a4f42a9 02/18: cx18: Reformat "Extra 12dB Gain" control string to look more natural http://linuxtv.org/hg/~awalls/v4l-dvb?cmd=changeset;node=82bf413c60d8 03/18: cx18: Add a control query fill function for cx18 specific user controls http://linuxtv.org/hg/~awalls/v4l-dvb?cmd=changeset;node=22260bf345c1 04/18: cx18: Add cx18_av core Luma Droop Compensation user control http://linuxtv.org/hg/~awalls/v4l-dvb?cmd=changeset;node=33f8e5621fe3 05/18: cx18: Add cx18_av core Chroma Droop Compensation user control http://linuxtv.org/hg/~awalls/v4l-dvb?cmd=changeset;node=1ce8fba3d190 06/18: cx18: Add cx18_av core Luma Clamping user control http://linuxtv.org/hg/~awalls/v4l-dvb?cmd=changeset;node=85e1fc01dd6f 07/18: cx18: Add cx18_av core Chroma Clamping user control http://linuxtv.org/hg/~awalls/v4l-dvb?cmd=changeset;node=a042df5b8281 08/18: cx18: Add cx18_av core Auto Luma Clamping Level user control http://linuxtv.org/hg/~awalls/v4l-dvb?cmd=changeset;node=311b5969116c 09/18: cx18: Add cx18_av core Auto Digital Gain Control user control http://linuxtv.org/hg/~awalls/v4l-dvb?cmd=changeset;node=4b1af2abd533 10/18: cx18: Add cx18_av Auto Analog Gain Control user control http://linuxtv.org/hg/~awalls/v4l-dvb?cmd=changeset;node=8f405aeb13f2 11/18: cx18: Add cx18_av core Auto Sync Height Crush user control http://linuxtv.org/hg/~awalls/v4l-dvb?cmd=changeset;node=6ae9e079 12/18: cx18: Add cx18_av core Luma Clamping Voltage user control http://linuxtv.org/hg/~awalls/v4l-dvb?cmd=changeset;node=df97564687a8 13/18: cx18 Add cx18_av core Digital Gain Level control; make func file scope http://linuxtv.org/hg/~awalls/v4l-dvb?cmd=changeset;node=f7713cb28208 14/18: cx18: Add cx18_av core Analog Gain Level user control http://linuxtv.org/hg/~awalls/v4l-dvb?cmd=changeset;node=750adcd07696 15/18: cx18: Add cx18_av core Sync Tip Height user control http://linuxtv.org/hg/~awalls/v4l-dvb?cmd=changeset;node=ca30fa94db6e 16/18: cx18: Add cx18_av Sync Acquired/Lost Error Threshold user controls http://linuxtv.org/hg/~awalls/v4l-dvb?cmd=changeset;node=e4b2c5d550b5 17/18: cx18: Ensure I2S output of A/V core clocks 24 bits/sample http://linuxtv.org/hg/~awalls/v4l-dvb?cmd=changeset;node=ab8e4bd49b05 18/18: ivtv: Add ability to control a secondary audio chip via user controls http://linuxtv.org/hg/~awalls/v4l-dvb?cmd=changeset;node=c9f13db7a53e cx18/cx18-av-audio.c | 46 +++-- cx18/cx18-av-core.c | 441 ++- cx18/cx18-av-core.h | 46 - cx18/cx18-controls.c | 76 ivtv/ivtv-cards.c|2 ivtv/ivtv-cards.h|1 ivtv/ivtv-controls.c | 114 + ivtv/ivtv-driver.c |1 ivtv/ivtv-driver.h |1 9 files changed, 668 insertions(+), 60 deletions(-) Thanks, Andy -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: correct implementation of FE_READ_UNCORRECTED_BLOCKS
Oops, sent it way too fast. Anyway. DVB API documentation says: "This ioctl call returns the number of uncorrected blocks detected by the device driver during its lifetime Note that the counter will wrap to zero after its maximum count has been reached." Does it mean that correct implementation of frontend driver should keep its own counter of UNC blocks and increment it every time hardware reports such block? >From what I see, a lot of current frontend drivers simply dump a value from some hardware register. For example zl10353 I got here reports some N unc blocks and then gets back to reporting zero. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
correct implementation of FE_READ_UNCORRECTED_BLOCKS
DVB API documentation says: "This ioctl call returns the number of uncorrected blocks detected by the device driver during its lifetime Note that the counter will wrap to zero after its maximum count has been reached. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PULL] http://kernellabs.com/hg/~mkrufky/sms1xxx-warning
On Sun, Aug 2, 2009 at 5:29 AM, Hans Verkuil wrote: > On Saturday 01 August 2009 06:40:01 Patch from Michael Krufky wrote: >> The patch number 12374 was added via Michael Krufky >> to http://linuxtv.org/hg/v4l-dvb master development tree. >> > Hi Mike, > > The daily build now has this warning: > > /marune/build/v4l-dvb-master/v4l/sms-cards.c: In function 'sms_board_event': > /marune/build/v4l-dvb-master/v4l/sms-cards.c:120: warning: unused variable > 'board' > > And 'board' is indeed no longer used. Can you make a patch fixing this? > I suspect that it can just be removed. Thanks for pointing this out, Hans. In fact, the entire function is not being used, but I am under the impression that Siano wants to use it in the future. For now I have #if 0'd the extraneous variables. Mauro, Please pull from: http://kernellabs.com/hg/~mkrufky/sms1xxx-warning for: - sms1xxx: fix build warning: unused variable 'board' sms-cards.c |2 ++ 1 file changed, 2 insertions(+) Thanks again, Mike -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: stb0899 i2c communication broken after suspend
Am Freitag, 31. Juli 2009 18:44:13 schrieb Julian Scheel: > I made an interesting observation with the stb0899 drivers. If the > system was in suspend to ram state (no matter if dvb modules were > unloaded before or not) the i2c communication of stb0899 driver and > chipset seems to be somewhat broken. Tuning to dvb-s channels still > works as expected, but tuning to dvb-s2 channels is completely broken. > The system log shows this error on the first tuning approach: > stb0899_write_s2reg ERR (1), Device=[0xf3fc], Base Address=[0x0460], > Offset=[0xf34c], Data=[0x], status=-121 I actually played around a bit more and figured out, that after a reload of the i2c_core module the s2 channels start working again after suspend. But as this module is needed by many others (like nvidia, so X server has to be stopped to unload it), it can't be simply reloaded. Now the question is whether the issue is in i2c_core itself or in the way that stb0899-drivers use i2c_core. Especially I am wondering why only the s2 channels fail, isn't for the dvb-s2 channels i2c communication used as well? -Julian -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] to add support for certain Jeilin dual-mode cameras.
Hello, Theodore
On Sun, Aug 2, 2009 at 1:56 AM, Theodore
Kilgore wrote:
> Several cameras are supported here, which all share the same USB
> Vendor:Product number when started up in streaming mode. All of these
> cameras use bulk transport for streaming, and all of them produce frames in
> JPEG format.
>
> Patch follows.
>
> Signed-off-by Theodore Kilgore
>
> --
> diff -r d189fb4be712 linux/Documentation/video4linux/gspca.txt
> --- a/linux/Documentation/video4linux/gspca.txt Wed Jul 29 10:01:54 2009
> +0200
> +++ b/linux/Documentation/video4linux/gspca.txt Sat Aug 01 15:42:02 2009
> -0500
> @@ -239,6 +239,9 @@
> pac7311 093a:2629 Genious iSlim 300
> pac7311 093a:262a Webcam 300k
> pac7311 093a:262c Philips SPC 230 NC
> +jeilinj 0979:0280 Cobra DMC 300
> +jeilinj 0979:0280 FlyCamOne
> +jeilinj 0979:0280 Sakar 57379
> zc3xx 0ac8:0302 Z-star Vimicro zc0302
> vc032x 0ac8:0321 Vimicro generic vc0321
> vc032x 0ac8:0323 Vimicro Vc0323
> diff -r d189fb4be712 linux/drivers/media/video/gspca/Kconfig
> --- a/linux/drivers/media/video/gspca/Kconfig Wed Jul 29 10:01:54 2009
> +0200
> +++ b/linux/drivers/media/video/gspca/Kconfig Sat Aug 01 15:42:02 2009
> -0500
> @@ -47,6 +47,15 @@
> To compile this driver as a module, choose M here: the
> module will be called gspca_finepix.
>
> +config USB_GSPCA_JEILINJ
> + tristate "Jeilin JPEG USB V4L2 driver"
> + depends on VIDEO_V4L2 && USB_GSPCA
> + help
> + Say Y here if you want support for cameras based on this Jeilin
> chip.
> +
> + To compile this driver as a module, choose M here: the
> + module will be called gspca_jeilinj.
> +
> config USB_GSPCA_MARS
> tristate "Mars USB Camera Driver"
> depends on VIDEO_V4L2 && USB_GSPCA
> diff -r d189fb4be712 linux/drivers/media/video/gspca/Makefile
> --- a/linux/drivers/media/video/gspca/Makefile Wed Jul 29 10:01:54 2009
> +0200
> +++ b/linux/drivers/media/video/gspca/Makefile Sat Aug 01 15:42:02 2009
> -0500
> @@ -2,6 +2,7 @@
> obj-$(CONFIG_USB_GSPCA_CONEX) += gspca_conex.o
> obj-$(CONFIG_USB_GSPCA_ETOMS) += gspca_etoms.o
> obj-$(CONFIG_USB_GSPCA_FINEPIX) += gspca_finepix.o
> +obj-$(CONFIG_USB_GSPCA_JEILINJ) += gspca_jeilinj.o
> obj-$(CONFIG_USB_GSPCA_MARS) += gspca_mars.o
> obj-$(CONFIG_USB_GSPCA_MR97310A) += gspca_mr97310a.o
> obj-$(CONFIG_USB_GSPCA_OV519) += gspca_ov519.o
> @@ -30,6 +31,7 @@
> gspca_conex-objs := conex.o
> gspca_etoms-objs := etoms.o
> gspca_finepix-objs := finepix.o
> +gspca_jeilinj-objs := jeilinj.o
> gspca_mars-objs := mars.o
> gspca_mr97310a-objs := mr97310a.o
> gspca_ov519-objs := ov519.o
> diff -r d189fb4be712 linux/drivers/media/video/gspca/jeilinj.c
> --- /dev/null Thu Jan 01 00:00:00 1970 +
> +++ b/linux/drivers/media/video/gspca/jeilinj.c Sat Aug 01 15:42:02 2009
> -0500
> @@ -0,0 +1,387 @@
> +/*
> + * Jeilinj subdriver
> + *
> + * Supports some Jeilin dual-mode cameras which use bulk transport and
> + * download raw JPEG data.
> + *
> + * Copyright (C) 2009 Theodore Kilgore
> + *
> + * 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
> + * 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., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
> + */
> +
> +#define MODULE_NAME "jeilinj"
> +
> +#include
> +#include "gspca.h"
> +#include "jpeg.h"
> +
> +MODULE_AUTHOR("Theodore Kilgore ");
> +MODULE_DESCRIPTION("GSPCA/JEILINJ USB Camera Driver");
> +MODULE_LICENSE("GPL");
> +
> +/* Default timeouts, in ms */
> +#define JEILINJ_CMD_TIMEOUT 500
> +#define JEILINJ_DATA_TIMEOUT 1000
> +
> +/* Maximum transfer size to use. */
> +#define JEILINJ_MAX_TRANSFER 0x200
> +
> +#define FRAME_HEADER_LEN 0x10
> +
> +/* Structure to hold all of our device specific stuff */
> +struct sd {
> + struct gspca_dev gspca_dev; /* !! must be the first item */
> + const struct v4l2_pix_format *cap_mode;
> + /* Driver stuff */
> + struct work_struct work_struct;
> + struct workqueue_struct *work_thread;
> + u8 quality; /* image quality */
> + u8 jpegqual; /* webcam quality */
> + u8 *jpeg_hdr;
> +};
> +
> + struct jlj_command {
> + unsigned char in
Re: [linuxtv-commits] [hg:v4l-dvb] gspca - vc032x: H and V flip controls added for mi13x0_soc sensors.
On Sun, 2 Aug 2009 11:33:25 +0200 Hans Verkuil wrote: > he daily build produces this warning: > > /marune/build/v4l-dvb-master/v4l/vc032x.c: In function 'sethvflip': > /marune/build/v4l-dvb-master/v4l/vc032x.c:3138: warning: statement > with no effect /marune/build/v4l-dvb-master/v4l/vc032x.c:3141: > warning: statement with no effect > > And looking at the code those warnings are correct. I think you > wanted to do 'hflip = !hflip'. > > Can you take a look at this? Hi Hans, Sorry, I did not see that. It is fixed. Many thanks. -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PULL] http://linuxtv.org/hg/~jfrancois/v4l-dvb/
Hi Mauro, Please pull from http://linuxtv.org/hg/~jfrancois/v4l-dvb for the following 2 changesets: 01/02: gspca - main: Remove vidioc_s_std(). http://linuxtv.org/hg/~jfrancois/v4l-dvb?cmd=changeset;node=810eb52aaedc 02/02: gspca - vc032x: Bad h/v flip controls when inverted by default. http://linuxtv.org/hg/~jfrancois/v4l-dvb?cmd=changeset;node=835a204432f0 gspca.c |7 --- vc032x.c |4 ++-- 2 files changed, 2 insertions(+), 9 deletions(-) Thanks. -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb
Hi Mauro, Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb for the following: - v4l: introduce string control support. - v4l2-spec: document the new string control type. - v4l2-ctl: modulator bug fixes - v4l2-ctl: add support for string controls This is the last piece of the v4l2 core support that is needed for Eduardo's FM transmitter driver. Thanks, Hans diffstat: linux/drivers/media/video/v4l2-common.c |2 linux/drivers/media/video/v4l2-compat-ioctl32.c | 93 +--- linux/drivers/media/video/v4l2-ioctl.c | 10 linux/include/linux/videodev2.h |6 v4l2-apps/util/v4l2-ctl.cpp | 257 +++- v4l2-spec/Makefile |1 v4l2-spec/compat.sgml |3 v4l2-spec/controls.sgml |5 v4l2-spec/v4l2.sgml |4 v4l2-spec/vidioc-g-ext-ctrls.sgml | 72 +- v4l2-spec/vidioc-queryctrl.sgml | 42 ++- 11 files changed, 335 insertions(+), 160 deletions(-) -- Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linuxtv-commits] [hg:v4l-dvb] gspca - vc032x: H and V flip controls added for mi13x0_soc sensors.
On Friday 31 July 2009 01:05:04 Patch from Jean-Francois Moine wrote:
> The patch number 12354 was added via Jean-Francois Moine
> to http://linuxtv.org/hg/v4l-dvb master development tree.
>
> Kernel patches in this development tree may be modified to be backward
> compatible with older kernels. Compatibility modifications will be
> removed before inclusion into the mainstream Kernel
>
> If anyone has any objections, please let us know by sending a message to:
> Linux Media Mailing List
>
> --
>
> From: Jean-Francois Moine
> gspca - vc032x: H and V flip controls added for mi13x0_soc sensors.
>
>
> Also, H/V flip default values adjusted according to the webcam IDs.
>
> Priority: normal
>
> Signed-off-by: Jean-Francois Moine
>
>
> ---
>
> linux/drivers/media/video/gspca/vc032x.c | 109 +--
> 1 file changed, 63 insertions(+), 46 deletions(-)
>
> diff -r c9c025650ce7 -r 266dc538f544 linux/drivers/media/video/gspca/vc032x.c
> --- a/linux/drivers/media/video/gspca/vc032x.cMon Jul 27 10:52:27
> 2009 +0200
> +++ b/linux/drivers/media/video/gspca/vc032x.cMon Jul 27 11:00:03
> 2009 +0200
> @@ -3121,33 +3127,44 @@
> return 0;
> }
>
> -/* for OV7660 and OV7670 only */
> +/* some sensors only */
> static void sethvflip(struct gspca_dev *gspca_dev)
> {
> struct sd *sd = (struct sd *) gspca_dev;
> - __u8 data;
> + u8 data[2], hflip, vflip;
>
> + hflip = sd->hflip;
> + if (sd->flags & FL_HFLIP)
> + hflip != hflip;
> + vflip = sd->vflip;
> + if (sd->flags & FL_VFLIP)
> + vflip != vflip;
Hi Jean-Francois,
The daily build produces this warning:
/marune/build/v4l-dvb-master/v4l/vc032x.c: In function 'sethvflip':
/marune/build/v4l-dvb-master/v4l/vc032x.c:3138: warning: statement with no
effect
/marune/build/v4l-dvb-master/v4l/vc032x.c:3141: warning: statement with no
effect
And looking at the code those warnings are correct. I think you wanted to do
'hflip = !hflip'.
Can you take a look at this?
Thanks,
Hans
--
Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linuxtv-commits] [hg:v4l-dvb] sms1xxx: fix broken Hauppauge devices
On Saturday 01 August 2009 06:40:01 Patch from Michael Krufky wrote: > The patch number 12374 was added via Michael Krufky > to http://linuxtv.org/hg/v4l-dvb master development tree. > > Kernel patches in this development tree may be modified to be backward > compatible with older kernels. Compatibility modifications will be > removed before inclusion into the mainstream Kernel > > If anyone has any objections, please let us know by sending a message to: > Linux Media Mailing List > > -- > > From: Michael Krufky > sms1xxx: fix broken Hauppauge devices > > > The current GPIO configuration breaks all Hauppauge devices. > > The code being removed affects Hauppauge devices only, > and is the cause of the breakage. > > Priority: high > > Signed-off-by: Michael Krufky Hi Mike, The daily build now has this warning: /marune/build/v4l-dvb-master/v4l/sms-cards.c: In function 'sms_board_event': /marune/build/v4l-dvb-master/v4l/sms-cards.c:120: warning: unused variable 'board' And 'board' is indeed no longer used. Can you make a patch fixing this? I suspect that it can just be removed. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Terratec Cinergy HibridT XS
Valerio Messina ha scritto: I do not know if is correct that linuxtv.org link to a web site with unsupported product/commercial. Please change the link in page: http://www.linuxtv.org/wiki/index.php/TerraTec_Cinergy_Hybrid_T_USB_XS take note that also the page at: http://www.linuxtv.org/wiki/index.php/TerraTec three "with a patch" link to: http://mcentral.de/wiki/index.php/Em2880 where its links, say (Pinnacle, Hauppauge, Terratec) are all unsupported device, but sundtek. Valerio -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] to add support for certain Jeilin dual-mode cameras.
On Sat, 1 Aug 2009 16:56:06 -0500 (CDT) Theodore Kilgore wrote: > Several cameras are supported here, which all share the same USB > Vendor:Product number when started up in streaming mode. All of these > cameras use bulk transport for streaming, and all of them produce > frames in JPEG format. Hi Theodore, Your patch seems ok, but: - there is no kfree(sd->jpeg_hdr). Should be in stop0(). - as there is only one vend:prod, one line is enough in gspca.txt. May you fix this and resend? Thanks. -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: USB devices supporting raw or sliced VBI for closed captioning?
On Sun, Aug 2, 2009 at 2:49 AM, hermann pitton wrote: > > Am Samstag, den 01.08.2009, 03:45 +0200 schrieb Markus Rechberger: >> Hi, >> >> On Sat, Aug 1, 2009 at 1:20 AM, Steve Castellotti wrote: >> > >> > I was wondering if anyone could please point me at a list or similar >> > resource for USB capture devices which support raw (or sliced) VBI >> > access for producing a closed caption transcript through software such >> > as zbvi-ntsc-cc or ccextractor? Specifically I'm wanting a device >> > capable of S-Video, Composite, or even Component input, not just ATSC, >> > as most USB devices seem focused around these days. >> > >> > I've managed to get this working with various ivtv and saa713x based >> > PCI devices, but aren't aware of any USB implementations of chipsets >> > which use those drivers. >> > >> > >> > Searching online, I found this archived message: >> > >> > http://lists.zerezo.com/video4linux/msg16402.html >> > >> > which states: >> > >> >> some em2840 and newer devices are able to capture raw vbi in >> >> linux (sliced vbi isn't possible yet) >> >> em2820, em2800, em2750 do not support vbi at all. >> > >> > >> > Checking the em28xx driver homepage for recent models, I found this >> > entry: >> > >> > http://mcentral.de/wiki/index.php5/Em2880 >> > >> >> officially the em2880 is em2840 + DVB_T >> > >> > >> > which implies that not only is the "em2880" series a "newer" device, >> > but it should in fact already contain the "em2840" chip specifically >> > mentioned. >> > >> > >> > Later on that same page, in the list of devices: >> > >> > ATI/AMD TV Wonder 600 >> > >> > >> > and on the manufacturer's page: >> > >> > http://ati.amd.com/products/tvwonder600/usb/index.html >> > >> > >> > Under the list of "Input Connectors": >> > >> >> S-video input with adapter >> > >> > >> > >> > Picking up one of these devices, I attempted to tune into the >> > S-Video >> > feed and check the /dev/vbi0 device, but received the same error message >> > as I do with all other em28xx devices encountered thus far: >> > >> >> Cannot capture vbi data with v4l interface: >> >> /dev/vbi0 (AMD ATI TV Wonder HD 600) is not a raw vbi device. >> > >> > >> > >> > Can anyone please point me in the right direction? >> > >> > I would much prefer to be certain the next purchase is supported. >> > >> > >> > >> > Thanks! >> > >> >> we do support Raw VBI for our devices, Sundtek MediaTV Pro for closed >> captioning. >> Alternatively we also have full support for ATSC-analogTV USB devices >> for the US market ([em288x]-[AVFB4910]-[Trident drx-J]-[tda18271]) the >> european product which we are selling is also capable of decoding NTSC >> closed caption. >> >> http://sundtek.de/shop/Digital-TV-Sticks-oxid/Sundtek-MediaTV-Pro.html >> (this is just the information about the >> European/DVB-T/DVB-C/analogTV(raw VBI) device, we do not have the >> US/ATSC/analogTV(rawVBI) product listed there, although we do offer it >> to business customers) We support it from Linux 2.6.15 on. >> >> Best Regards, >> Markus Rechberger > > Hi, > > anything new about how to deal with commercial advertising on lists, > depending totally on our source? > > Please have a look. The question was about a device, and I doubt that you can get a device for free anywhere. If so there shouldn't be any other company names in drivers, or named on the mailinglist (to be fair) which do not support Linux. Best Regards, Markus -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] dvb-usb: fix tuning with Cinergy T2
Initialize param.flags. Signed-off-by: Eberhard Mattes --- Not setting param.flags was the real cause of the inability of the Cinergy T2 driver to tune under certain circumstances. Moving stuff from the stack to the heap did not really solve the problem. As there are several other drivers which pass buffers on the stack to the USB layer, I leave fixing that to others. This patch is against 2.6.30. --- a/drivers/media/dvb/dvb-usb/cinergyT2-fe.c 2009-06-10 05:05:27.0 +0200 +++ b/drivers/media/dvb/dvb-usb/cinergyT2-fe.c 2009-08-02 09:28:55.0 +0200 @@ -275,6 +275,7 @@ static int cinergyt2_fe_set_frontend(str param.tps = cpu_to_le16(compute_tps(fep)); param.freq = cpu_to_le32(fep->frequency / 1000); param.bandwidth = 8 - fep->u.ofdm.bandwidth - BANDWIDTH_8_MHZ; + param.flags = 0; err = dvb_usb_generic_rw(state->d, (char *)¶m, sizeof(param), -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
