Re: femon patch for dB
Em 29-10-2011 07:39, Randy Dunlap escreveu: > On 10/28/11 22:12, James wrote: >> diff -r d4e8bf5658ce util/femon/femon.c >> --- a/util/femon/femon.cFri Oct 07 01:26:04 2011 +0530 >> +++ b/util/femon/femon.cFri Oct 28 18:52:12 2011 -0400 >> @@ -16,6 +16,9 @@ >> * You should have received a copy of the GNU General Public License >> * along with this program; if not, write to the Free Software >> * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. >> + * >> + * James Lockie: Oct. 2011 >> + * modified to add a switch (-2) to show signal/snr in dB >> */ >> >> >> @@ -37,11 +40,16 @@ >> >> #include >> >> +/* the s5h1409 delivers both fields in 0.1dB increments, while >> + * some demods expect signal to be 0-65535 and SNR to be in 1/256 >> increments > > Looks like thunderbird is being too helpful for us here -- by breaking > a long line where it shouldn't be broken. You can see if > /Documentation/email-clients.txt helps you any with that. This is not a kernel patch, but yes, you're right: there's nothing we can't apply it to dvb-apps as-is. Thunderbird only works well if the html editor is disabled and if the max number of lines is set to 0. I use it here, but I'm currently sending patches directly from git, as it is simpler, if the smtp server is properly configured. There is one plugin for it that fixes those stuff on thunerbird (asalted-patches), but this doesn't work with newer versions of it (well, fixing it is probably a one-line patch like [2] changing the maxVersion). [1] https://hg.mozilla.org/users/clarkbw_gnome.org/asalted-patches/ [2] https://hg.mozilla.org/users/clarkbw_gnome.org/asalted-patches/rev/49d587f60371 Regards, 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: femon patch for dB
On 10/28/11 22:12, James wrote: > diff -r d4e8bf5658ce util/femon/femon.c > --- a/util/femon/femon.cFri Oct 07 01:26:04 2011 +0530 > +++ b/util/femon/femon.cFri Oct 28 18:52:12 2011 -0400 > @@ -16,6 +16,9 @@ > * You should have received a copy of the GNU General Public License > * along with this program; if not, write to the Free Software > * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. > + * > + * James Lockie: Oct. 2011 > + * modified to add a switch (-2) to show signal/snr in dB > */ > > > @@ -37,11 +40,16 @@ > > #include > > +/* the s5h1409 delivers both fields in 0.1dB increments, while > + * some demods expect signal to be 0-65535 and SNR to be in 1/256 > increments Looks like thunderbird is being too helpful for us here -- by breaking a long line where it shouldn't be broken. You can see if /Documentation/email-clients.txt helps you any with that. > +*/ > + > #define FE_STATUS_PARAMS > (DVBFE_INFO_LOCKSTATUS|DVBFE_INFO_SIGNAL_STRENGTH|DVBFE_INFO_BER|DVBFE_INFO_SNR|DVBFE_INFO_UNCORRECTED_BLOCKS) > > static char *usage_str = > "\nusage: femon [options]\n" > -" -H: human readable output\n" > +" -H: human readable output: (signal: 0-65335, snr: > 1/256 increments)\n" > +" -2: human readable output: (signal and snr in .1 dB > increments)\n" same problem as above. > " -A: Acoustical mode. A sound indicates the signal > quality.\n" > " -r: If 'Acoustical mode' is active it tells the > application\n" > " is called remotely via ssh. The sound is heard on > the 'real'\n" > @@ -62,7 +70,7 @@ static void usage(void) > > > static > -int check_frontend (struct dvbfe_handle *fe, int human_readable, > unsigned int count) > +int check_frontend (struct dvbfe_handle *fe, int human_readable, int > db_readable, unsigned int count) and again. > { > struct dvbfe_info fe_info; > unsigned int samples = 0; > @@ -93,31 +101,32 @@ int check_frontend (struct dvbfe_handle > fprintf(stderr, "Problem retrieving frontend information: > %m\n"); > } > > +// print the status code > +printf ("status %c%c%c%c%c | ", > +fe_info.signal ? 'S' : ' ', > +fe_info.carrier ? 'C' : ' ', > +fe_info.viterbi ? 'V' : ' ', > +fe_info.sync ? 'Y' : ' ', > +fe_info.lock ? 'L' : ' ' ); > > +if (db_readable) { > + printf ("signal %3.0fdB | snr %3.0fdB", > +(fe_info.signal_strength * 0.1), > +(fe_info.snr * 0.1) ); > +} else if (human_readable) { > + printf ("signal %3u%% | snr %3u%%", > +(fe_info.signal_strength * 100) / 0x, > +(fe_info.snr * 100) / 0x ); > +} else { > +printf ("signal %04x | snr %04x", > +fe_info.signal_strength, > +fe_info.snr ); > +} > > -if (human_readable) { > - printf ("status %c%c%c%c%c | signal %3u%% | snr > %3u%% | ber %d | unc %d | ", > -fe_info.signal ? 'S' : ' ', > -fe_info.carrier ? 'C' : ' ', > -fe_info.viterbi ? 'V' : ' ', > -fe_info.sync ? 'Y' : ' ', > -fe_info.lock ? 'L' : ' ', > -(fe_info.signal_strength * 100) / 0x, > -(fe_info.snr * 100) / 0x, > -fe_info.ber, > -fe_info.ucblocks); > -} else { > -printf ("status %c%c%c%c%c | signal %04x | snr %04x | ber > %08x | unc %08x | ", > -fe_info.signal ? 'S' : ' ', > -fe_info.carrier ? 'C' : ' ', > -fe_info.viterbi ? 'V' : ' ', > -fe_info.sync ? 'Y' : ' ', > -fe_info.lock ? 'L' : ' ', > -fe_info.signal_strength, > -fe_info.snr, > -fe_info.ber, > -fe_info.ucblocks); > -} > +/* always print ber and ucblocks */ > +printf (" | ber %08x | unc %08x | ", > +fe_info.ber, > +fe_info.ucblocks); > > if (fe_info.lock) > printf("FE_HAS_LOCK"); > @@ -145,7 +154,7 @@ int check_frontend (struct dvbfe_handle > > > static > -int do_mon(unsigned int adapter, unsigned int frontend, int > human_readable, unsigned int count) > +int do_mon(unsigned int adapter, unsigned int frontend, int > human_readable, int db_readable, unsigned int count) and again. > { > int result; > struct dvbfe_handle *fe; > @@ -175,7 +184,7 @@ int do_mon(unsigned int adapter, unsigne > } > printf("FE: %s (%s)\n", fe_info.name, fe_type); > > -result = check_frontend (fe, human_readable, count); > +result = check_frontend (fe, human_readable, db_readable, count); > > dvbfe_close(fe); > > @@ -186,9 +195,10 @@ i
Re: femon patch for dB
diff -r d4e8bf5658ce util/femon/femon.c --- a/util/femon/femon.cFri Oct 07 01:26:04 2011 +0530 +++ b/util/femon/femon.cFri Oct 28 18:52:12 2011 -0400 @@ -16,6 +16,9 @@ * You should have received a copy of the GNU General Public License * along with this program; if not, write to the Free Software * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. + * + * James Lockie: Oct. 2011 + * modified to add a switch (-2) to show signal/snr in dB */ @@ -37,11 +40,16 @@ #include +/* the s5h1409 delivers both fields in 0.1dB increments, while + * some demods expect signal to be 0-65535 and SNR to be in 1/256 increments +*/ + #define FE_STATUS_PARAMS (DVBFE_INFO_LOCKSTATUS|DVBFE_INFO_SIGNAL_STRENGTH|DVBFE_INFO_BER|DVBFE_INFO_SNR|DVBFE_INFO_UNCORRECTED_BLOCKS) static char *usage_str = "\nusage: femon [options]\n" -" -H: human readable output\n" +" -H: human readable output: (signal: 0-65335, snr: 1/256 increments)\n" +" -2: human readable output: (signal and snr in .1 dB increments)\n" " -A: Acoustical mode. A sound indicates the signal quality.\n" " -r: If 'Acoustical mode' is active it tells the application\n" " is called remotely via ssh. The sound is heard on the 'real'\n" @@ -62,7 +70,7 @@ static void usage(void) static -int check_frontend (struct dvbfe_handle *fe, int human_readable, unsigned int count) +int check_frontend (struct dvbfe_handle *fe, int human_readable, int db_readable, unsigned int count) { struct dvbfe_info fe_info; unsigned int samples = 0; @@ -93,31 +101,32 @@ int check_frontend (struct dvbfe_handle fprintf(stderr, "Problem retrieving frontend information: %m\n"); } +// print the status code +printf ("status %c%c%c%c%c | ", +fe_info.signal ? 'S' : ' ', +fe_info.carrier ? 'C' : ' ', +fe_info.viterbi ? 'V' : ' ', +fe_info.sync ? 'Y' : ' ', +fe_info.lock ? 'L' : ' ' ); +if (db_readable) { + printf ("signal %3.0fdB | snr %3.0fdB", +(fe_info.signal_strength * 0.1), +(fe_info.snr * 0.1) ); +} else if (human_readable) { + printf ("signal %3u%% | snr %3u%%", +(fe_info.signal_strength * 100) / 0x, +(fe_info.snr * 100) / 0x ); +} else { +printf ("signal %04x | snr %04x", +fe_info.signal_strength, +fe_info.snr ); +} -if (human_readable) { - printf ("status %c%c%c%c%c | signal %3u%% | snr %3u%% | ber %d | unc %d | ", -fe_info.signal ? 'S' : ' ', -fe_info.carrier ? 'C' : ' ', -fe_info.viterbi ? 'V' : ' ', -fe_info.sync ? 'Y' : ' ', -fe_info.lock ? 'L' : ' ', -(fe_info.signal_strength * 100) / 0x, -(fe_info.snr * 100) / 0x, -fe_info.ber, -fe_info.ucblocks); -} else { -printf ("status %c%c%c%c%c | signal %04x | snr %04x | ber %08x | unc %08x | ", -fe_info.signal ? 'S' : ' ', -fe_info.carrier ? 'C' : ' ', -fe_info.viterbi ? 'V' : ' ', -fe_info.sync ? 'Y' : ' ', -fe_info.lock ? 'L' : ' ', -fe_info.signal_strength, -fe_info.snr, -fe_info.ber, -fe_info.ucblocks); -} +/* always print ber and ucblocks */ +printf (" | ber %08x | unc %08x | ", +fe_info.ber, +fe_info.ucblocks); if (fe_info.lock) printf("FE_HAS_LOCK"); @@ -145,7 +154,7 @@ int check_frontend (struct dvbfe_handle static -int do_mon(unsigned int adapter, unsigned int frontend, int human_readable, unsigned int count) +int do_mon(unsigned int adapter, unsigned int frontend, int human_readable, int db_readable, unsigned int count) { int result; struct dvbfe_handle *fe; @@ -175,7 +184,7 @@ int do_mon(unsigned int adapter, unsigne } printf("FE: %s (%s)\n", fe_info.name, fe_type); -result = check_frontend (fe, human_readable, count); +result = check_frontend (fe, human_readable, db_readable, count); dvbfe_close(fe); @@ -186,9 +195,10 @@ int main(int argc, char *argv[]) { unsigned int adapter = 0, frontend = 0, count = 0; int human_readable = 0; +int db_readable = 0; int opt; - while ((opt = getopt(argc, argv, "rAHa:f:c:")) != -1) { + while ((opt = getopt(argc, argv, "rAH2a:f:c:")) != -1) { switch (opt) { default: @@ -206,6 +216,9 @@ int main(int argc, char *argv[]) case 'H': human_readable = 1; break; +case '2': +db_readable = 1; +b
Re: femon patch for dB
On 10/28/11 17:21, Marek Vasut wrote: >> I added a switch to femon so it displays signal and snr in dB. >> >> The cx23885 driver for my Hauppauge WinTV-HVR1250 reports signal and snr >> in dB. >> >> http://lockie.ca/test/femon.patch.bz2 > > Use git send-email to submit patches to mailing lists, thanks Use anything that will put the patch inline in the body of an email message. Without weird encoding. Thanks. -- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** -- 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: femon patch for dB
> I added a switch to femon so it displays signal and snr in dB. > > The cx23885 driver for my Hauppauge WinTV-HVR1250 reports signal and snr > in dB. > > http://lockie.ca/test/femon.patch.bz2 Use git send-email to submit patches to mailing lists, thanks -- 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 4/5] drivers/media/video/atmel-isi.c: eliminate a null pointer dereference
From: Julia Lawall The variable isi might be null or might be freed at the point of the call to clk_put. pclk contains the value that isi->pclk is expected to point to. The semantic match that finds this problem is as follows: (http://coccinelle.lip6.fr/) // @r@ expression E, E1; identifier f; statement S1,S2,S3; @@ if (E == NULL) { ... when != if (E == NULL || ...) S1 else S2 when != E = E1 *E->f ... when any return ...; } else S3 // Signed-off-by: Julia Lawall --- drivers/media/video/atmel-isi.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/video/atmel-isi.c b/drivers/media/video/atmel-isi.c index 774715d..a3dafd6 100644 --- a/drivers/media/video/atmel-isi.c +++ b/drivers/media/video/atmel-isi.c @@ -1026,7 +1026,7 @@ err_alloc_ctx: err_alloc_descriptors: kfree(isi); err_alloc_isi: - clk_put(isi->pclk); + clk_put(pclk); return ret; } -- 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 5/5] drivers/media/video/davinci/vpbe_display.c: eliminate a null pointer dereference
From: Julia Lawall In the original code, probe_out could be reached when res was null and then when the irq had not yet been requested. In those cases, the call to free_irq is not needed, so move probe_out down and introduce a new label for the case where calling free_irq is useful. The semantic match that finds this problem is as follows: (http://coccinelle.lip6.fr/) // @r@ expression E, E1; identifier f; statement S1,S2,S3; @@ if (E == NULL) { ... when != if (E == NULL || ...) S1 else S2 when != E = E1 *E->f ... when any return ...; } else S3 // Signed-off-by: Julia Lawall --- drivers/media/video/davinci/vpbe_display.c |5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/media/video/davinci/vpbe_display.c b/drivers/media/video/davinci/vpbe_display.c index 8588a86..d98da4b 100644 --- a/drivers/media/video/davinci/vpbe_display.c +++ b/drivers/media/video/davinci/vpbe_display.c @@ -1746,15 +1746,16 @@ static __devinit int vpbe_display_probe(struct platform_device *pdev) for (i = 0; i < VPBE_DISPLAY_MAX_DEVICES; i++) { if (register_device(disp_dev->dev[i], disp_dev, pdev)) { err = -ENODEV; - goto probe_out; + goto probe_out_irq; } } printk(KERN_DEBUG "Successfully completed the probing of vpbe v4l2 device\n"); return 0; -probe_out: +probe_out_irq: free_irq(res->start, disp_dev); +probe_out: for (k = 0; k < VPBE_DISPLAY_MAX_DEVICES; k++) { /* Get the pointer to the layer object */ vpbe_display_layer = disp_dev->dev[k]; -- 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
femon patch for dB
I added a switch to femon so it displays signal and snr in dB. The cx23885 driver for my Hauppauge WinTV-HVR1250 reports signal and snr in dB. http://lockie.ca/test/femon.patch.bz2 -- 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: Switching input during capture
Em 28-10-2011 14:42, Laurent Pinchart escreveu: > Hi Gilles, > > On Friday 28 October 2011 03:31:53 Gilles Gigan wrote: >> Hi, >> I would like to know what is the correct way to switch the current >> video input during capture on a card with a single BT878 chip and 4 >> inputs >> (http://store.bluecherry.net/products/PV%252d143-%252d-4-port-video-captur >> e-card-%2830FPS%29-%252d-OEM.html). I tried doing it in two ways: >> - using VIDIOC_S_INPUT to change the current input. While this works, >> the next captured frame shows video from the old input in its top half >> and video from the new input in the bottom half. This is is likely easy to fix. The driver has already a logic to prevent changing the buffer while in the middle of a buffer filling. I suspect that the BKL removal patches might have broken it somewhat, allowing things like that. basically, it should be as simple as not allowing changing the input at the top half. Please try the enclosed patch. Regards, Mauro - bttv: Avoid switching the video input at the top half. Signed-off-by: Mauro Carvalho Chehab diff --git a/drivers/media/video/bt8xx/bttv-driver.c b/drivers/media/video/bt8xx/bttv-driver.c index 3dd0660..6a3be6f 100644 --- a/drivers/media/video/bt8xx/bttv-driver.c +++ b/drivers/media/video/bt8xx/bttv-driver.c @@ -3978,7 +3978,7 @@ bttv_irq_switch_video(struct bttv *btv) bttv_set_dma(btv, 0); /* switch input */ - if (UNSET != btv->new_input) { + if (! btv->curr.top && UNSET != btv->new_input) { video_mux(btv,btv->new_input); btv->new_input = UNSET; } -- 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
cx23885-alsa + Mygica X8507
Hi For 15 days "alsa cx23885 cleaner" worked well with my Mygica X8507 card and with the 3.0.2 kernel in OpenSuSE 11.4. Please if you are going to add "cx23885-alsa" to kernel, add Mygica X8507 card. Best regards, Alfredo -- Dona tu voz http://www.voxforge.org/es --- /home/alfredo/ISDB/Nuevo Driver/alsa_suport_12_oct_2011/Para_Video4Linux/Kernel/cx23885.h 2011-10-28 16:13:26.011668530 -0300 +++ /home/alfredo/ISDB/Nuevo Driver/alsa_suport_12_oct_2011/Para_Video4Linux/Mi_kernel_para_V4L/cx23885.h 2011-10-17 16:09:23.0 -0300 @@ -86,8 +86,9 @@ #define CX23885_BOARD_GOTVIEW_X5_3D_HYBRID 29 #define CX23885_BOARD_NETUP_DUAL_DVB_T_C_CI_RF 30 #define CX23885_BOARD_LEADTEK_WINFAST_PXDVR3200_H_XC4000 31 #define CX23885_BOARD_MPX885 32 +#define CX23885_BOARD_MYGICA_X8507 33 #define GPIO_0 0x0001 #define GPIO_1 0x0002 #define GPIO_2 0x0004 --- /home/alfredo/ISDB/Nuevo Driver/alsa_suport_12_oct_2011/Para_Video4Linux/Kernel/cx23885-cards.c 2011-10-28 16:11:22.579672203 -0300 +++ /home/alfredo/ISDB/Nuevo Driver/alsa_suport_12_oct_2011/Para_Video4Linux/Mi_kernel_para_V4L/cx23885-cards.c 2011-10-28 15:12:10.14939 -0300 @@ -302,8 +302,39 @@ CX25840_VIN7_CH3, }, }, }, + [CX23885_BOARD_MYGICA_X8507] = { + .name = "Mygica X8507", + .tuner_type = TUNER_XC5000, + .tuner_addr = 0x61, + .tuner_bus = 1, + .porta = CX23885_ANALOG_VIDEO, + .input = { + { + .type = CX23885_VMUX_TELEVISION, + .vmux = CX25840_COMPOSITE2, + .amux = CX25840_AUDIO8, + }, + { + .type = CX23885_VMUX_COMPOSITE1, + .vmux = CX25840_COMPOSITE8, + }, + { + .type = CX23885_VMUX_SVIDEO, + .vmux = CX25840_SVIDEO_LUMA3 | + CX25840_SVIDEO_CHROMA4, + }, + { + .type = CX23885_VMUX_COMPONENT, + .vmux = CX25840_COMPONENT_ON | + CX25840_VIN1_CH1 | + CX25840_VIN6_CH2 | + CX25840_VIN7_CH3, + }, + + }, + }, [CX23885_BOARD_MAGICPRO_PROHDTVE2] = { .name = "Magic-Pro ProHDTV Extreme 2", .tuner_type = TUNER_XC5000, .tuner_addr = 0x61, @@ -606,8 +637,12 @@ .subdevice = 0x8651, .card = CX23885_BOARD_MYGICA_X8506, }, { .subvendor = 0x14f1, + .subdevice = 0x8502, + .card = CX23885_BOARD_MYGICA_X8507, + }, { + .subvendor = 0x14f1, .subdevice = 0x8657, .card = CX23885_BOARD_MAGICPRO_PROHDTVE2, }, { .subvendor = 0x0070, @@ -1067,11 +1102,12 @@ cx23885_gpio_set(dev, GPIO_9); break; case CX23885_BOARD_MYGICA_X8506: case CX23885_BOARD_MAGICPRO_PROHDTVE2: + case CX23885_BOARD_MYGICA_X8507: /* GPIO-0 (0)Analog / (1)Digital TV */ /* GPIO-1 reset XC5000 */ - /* GPIO-2 reset LGS8GL5 / LGS8G75 */ + /* GPIO-2 reset LGS8GL5 / LGS8G75 / MB86A20S */ cx23885_gpio_enable(dev, GPIO_0 | GPIO_1 | GPIO_2, 1); cx23885_gpio_clear(dev, GPIO_1 | GPIO_2); mdelay(100); cx23885_gpio_set(dev, GPIO_0 | GPIO_1 | GPIO_2); @@ -1461,8 +1497,9 @@ case CX23885_BOARD_COMPRO_VIDEOMATE_E800: case CX23885_BOARD_HAUPPAUGE_HVR1270: case CX23885_BOARD_HAUPPAUGE_HVR1850: case CX23885_BOARD_MYGICA_X8506: + case CX23885_BOARD_MYGICA_X8507: case CX23885_BOARD_MAGICPRO_PROHDTVE2: case CX23885_BOARD_HAUPPAUGE_HVR1290: case CX23885_BOARD_LEADTEK_WINFAST_PXTV1200: case CX23885_BOARD_GOTVIEW_X5_3D_HYBRID: --- /home/alfredo/ISDB/Nuevo Driver/alsa_suport_12_oct_2011/Para_Video4Linux/Kernel/cx23885-video.c 2011-10-28 16:13:03.741669193 -0300 +++ /home/alfredo/ISDB/Nuevo Driver/alsa_suport_12_oct_2011/Para_Video4Linux/Mi_kernel_para_V4L/cx23885-video.c 2011-10-17 16:17:09.0 -0300 @@ -491,9 +491,10 @@ INPUT(input)->gpio2, INPUT(input)->gpio3); dev->input = input; if (dev->board == CX23885_BOARD_MYGICA_X8506 || - dev->board == CX23885_BOARD_MAGICPRO_PROHDTVE2) { +
Re: Avermedia TV Pilot
Thank you, for your answer Best Regards, Zbynek Kocur email: zbynek.ko...@fel.cvut.cz web: http://www.fel.cvut.cz Dept. Of Telecommunications Engineering Faculty of Electrical Engineering Czech Technical University in Prague Technicka 2,166 27 Prague 6 Dne 28.10.2011 21:46, Malcolm Priestley napsal(a): > AF903x series are not directly supported by V4L. > > it913x-fe driver is loosely based on the AF903x frontend. In its private > header are some af9035 references. > > At some point af903x may be spun out of the it913x-fe driver. > > However, these devices use one or two controllers in a number of > different interfacing combinations. smime.p7s Description: Elektronický podpis S/MIME
Re: Avermedia TV Pilot
On Fri, 2011-10-28 at 18:02 +0200, Zbyněk Kocur wrote: > Hi, > > I have new Linux DVB-T card from Avermedia. Avermedia TV Pilot but it is > not supported in kernel. Is it possible to support this USB TV DVB-T? It > has a chipset which is currently supported but demodulator is without > support. > > lsusb > Bus 002 Device 007: ID 07ca:0810 AVerMedia Technologies, Inc. > > It has a followed chpsets: > TDA18271(Supported) > CX23102(Supported) > and > AF9030(Not supported :-() > AF903x series are not directly supported by V4L. it913x-fe driver is loosely based on the AF903x frontend. In its private header are some af9035 references. At some point af903x may be spun out of the it913x-fe driver. However, these devices use one or two controllers in a number of different interfacing combinations. Regards Malcolm -- 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
CONFIG_DVB_MAX_ADAPTERS
Hello list, I want to increase the DVB adapter number, I make a little search and I find this files: # grep -r "CONFIG_DVB_MAX_ADAPTERS" . ./s2-liplianin-f5cd7d75370e/linux/drivers/media/dvb/dvb-core/dvbdev.h:#if defined(CONFIG_DVB_MAX_ADAPTERS) && CONFIG_DVB_MAX_ADAPTERS > 0 ./s2-liplianin-f5cd7d75370e/linux/drivers/media/dvb/dvb-core/dvbdev.h: #define DVB_MAX_ADAPTERS CONFIG_DVB_MAX_ADAPTERS ./s2-liplianin-f5cd7d75370e/v4l/dvbdev.h:#if defined(CONFIG_DVB_MAX_ADAPTERS) && CONFIG_DVB_MAX_ADAPTERS > 0 ./s2-liplianin-f5cd7d75370e/v4l/dvbdev.h: #define DVB_MAX_ADAPTERS CONFIG_DVB_MAX_ADAPTERS ./s2-liplianin-f5cd7d75370e/v4l/config-compat.h:#undef CONFIG_DVB_MAX_ADAPTERS ./s2-liplianin-f5cd7d75370e/v4l/config-compat.h:#undef CONFIG_DVB_MAX_ADAPTERS_MODULE ./s2-liplianin-f5cd7d75370e/v4l/config-compat.h:#define CONFIG_DVB_MAX_ADAPTERS 8 ./s2-liplianin-f5cd7d75370e/v4l/.config:CONFIG_DVB_MAX_ADAPTERS=8 ./s2-liplianin-f5cd7d75370e/v4l/.myconfig:CONFIG_DVB_MAX_ADAPTERS := 8 grep: warning: ./s2-liplianin-f5cd7d75370e/v4l/oss: recursive directory loop Where is the best file to change it? I want to increase it to 16, is it possible? Thanks ans best regards. -- Josu Lazkano -- 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
cron job: media_tree daily build: WARNINGS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date:Fri Oct 28 19:00:16 CEST 2011 git hash:a63366b935456dd0984f237642f6d4001dcf8017 gcc version: i686-linux-gcc (GCC) 4.6.1 host hardware:x86_64 host os: 3.0-4.slh.7-amd64 linux-git-armv5: WARNINGS linux-git-armv5-davinci: WARNINGS linux-git-armv5-ixp: WARNINGS linux-git-armv5-omap2: WARNINGS linux-git-i686: WARNINGS linux-git-m32r: OK linux-git-mips: WARNINGS linux-git-powerpc64: WARNINGS linux-git-x86_64: WARNINGS linux-2.6.31.12-i686: WARNINGS linux-2.6.32.6-i686: WARNINGS linux-2.6.33-i686: WARNINGS linux-2.6.34-i686: WARNINGS linux-2.6.35.3-i686: WARNINGS linux-2.6.36-i686: WARNINGS linux-2.6.37-i686: WARNINGS linux-2.6.38.2-i686: WARNINGS linux-2.6.39.1-i686: WARNINGS linux-3.0-i686: WARNINGS linux-3.1-i686: WARNINGS linux-2.6.31.12-x86_64: WARNINGS linux-2.6.32.6-x86_64: WARNINGS linux-2.6.33-x86_64: WARNINGS linux-2.6.34-x86_64: WARNINGS linux-2.6.35.3-x86_64: WARNINGS linux-2.6.36-x86_64: WARNINGS linux-2.6.37-x86_64: WARNINGS linux-2.6.38.2-x86_64: WARNINGS linux-2.6.39.1-x86_64: WARNINGS linux-3.0-x86_64: WARNINGS linux-3.1-x86_64: WARNINGS spec-git: WARNINGS sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.tar.bz2 The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- 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
Avermedia TV Pilot
Hi, I have new Linux DVB-T card from Avermedia. Avermedia TV Pilot but it is not supported in kernel. Is it possible to support this USB TV DVB-T? It has a chipset which is currently supported but demodulator is without support. lsusb Bus 002 Device 007: ID 07ca:0810 AVerMedia Technologies, Inc. It has a followed chpsets: TDA18271(Supported) CX23102(Supported) and AF9030(Not supported :-() Thank you very much. If you have any other question, please write me. Zbynek Kocur -- email: zbynek.ko...@fel.cvut.cz web: http://www.fel.cvut.cz Dept. Of Telecommunications Engineering Faculty of Electrical Engineering Czech Technical University in Prague Technicka 2,166 27 Prague 6 smime.p7s Description: Elektronický podpis S/MIME
Re: Switching input during capture
Hi Gilles, On Friday 28 October 2011 03:31:53 Gilles Gigan wrote: > Hi, > I would like to know what is the correct way to switch the current > video input during capture on a card with a single BT878 chip and 4 > inputs > (http://store.bluecherry.net/products/PV%252d143-%252d-4-port-video-captur > e-card-%2830FPS%29-%252d-OEM.html). I tried doing it in two ways: > - using VIDIOC_S_INPUT to change the current input. While this works, > the next captured frame shows video from the old input in its top half > and video from the new input in the bottom half. > - I tried setting the input field to the new input and flags to > V4L2_BUF_FLAG_INPUT in the struct v4l2_buffer passed to VIDIOC_QBUF > when enqueuing buffers. However, when doing so, the ioctl fails > altogether, and I cannot enqueue any buffers with the > V4L2_BUF_FLAG_INPUT flag set. V4L2_BUF_FLAG_INPUT is (or at least should be) deprecated. It isn't supported by mainline drivers and was a mistake in the first place. > Is there another way of doing it ? or is there a way to synchronise > the input change (when using VIDIOC_S_INPUT) so it happens in between > 2 frames and produces a clean switch ? You will need hardware support for that. -- Regards, Laurent Pinchart -- 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 4/6] v4l2-event: Don't set sev->fh to NULL on unsubcribe
Hi Hans, On Friday 28 October 2011 10:35:54 Hans de Goede wrote: > On 10/27/2011 02:20 PM, Laurent Pinchart wrote: > > On Thursday 27 October 2011 13:18:01 Hans de Goede wrote: > >> 1: There is no reason for this after v4l2_event_unsubscribe releases the > >> spinlock nothing is holding a reference to the sev anymore except for > >> the local reference in the v4l2_event_unsubscribe function. > >> > >> 2: Setting sev->fh to NULL causes problems for the del op added in the > >> next patch of this series, since this op needs a way to get to its own > >> data structures, and typically this will be done by using container_of > >> on an embedded v4l2_fh struct. > >> > >> Signed-off-by: Hans de Goede > > > > Acked-by: Laurent Pinchart > > > > While reviewing the patch I noticed that v4l2_event_unsubscribe_all() > > calls v4l2_event_unsubscribe(), which performs control lookup again. Is > > there a reason for that, instead of handling event unsubscription > > directly in v4l2_event_unsubscribe_all() ? > > I didn't write that part, so I'll let Hans V. answer this question. I know, that's why I still acked your patch :-) -- Regards, Laurent Pinchart -- 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 5/6] v4l2-event: Add v4l2_subscribed_event_ops
Hi, On 10/27/2011 02:30 PM, Laurent Pinchart wrote: Hi Hans, On Thursday 27 October 2011 13:18:02 Hans de Goede wrote: Just like with ctrl events, drivers may want to get called back on listener add / remove for other event types too. Rather then special casing all of this in subscribe / unsubscribe event it is better to use ops for this. Signed-off-by: Hans de Goede --- drivers/media/video/ivtv/ivtv-ioctl.c |2 +- drivers/media/video/omap3isp/ispccdc.c |2 +- drivers/media/video/omap3isp/ispstat.c |2 +- drivers/media/video/pwc/pwc-v4l.c |2 +- drivers/media/video/v4l2-event.c | 42 ++--- drivers/media/video/vivi.c |2 +- include/media/v4l2-event.h | 24 +- Haven't you forgotten to update Documentation/video4linux/v4l2-framework.txt ? I think I have, I'll go and do another revision fixing this. 7 files changed, 54 insertions(+), 22 deletions(-) [snip] diff --git a/drivers/media/video/v4l2-event.c b/drivers/media/video/v4l2-event.c index 3d27300..2dd9252 100644 --- a/drivers/media/video/v4l2-event.c +++ b/drivers/media/video/v4l2-event.c @@ -131,14 +131,14 @@ static void __v4l2_event_queue_fh(struct v4l2_fh *fh, const struct v4l2_event *e sev->first = sev_pos(sev, 1); fh->navailable--; if (sev->elems == 1) { - if (sev->replace) { - sev->replace(&kev->event, ev); + if (sev->ops&& sev->ops->replace) { + sev->ops->replace(&kev->event, ev); copy_payload = false; } - } else if (sev->merge) { + } else if (sev->ops&& sev->ops->merge) { struct v4l2_kevent *second_oldest = sev->events + sev_pos(sev, 0); - sev->merge(&kev->event,&second_oldest->event); + sev->ops->merge(&kev->event,&second_oldest->event); } } @@ -207,8 +207,14 @@ static void ctrls_merge(const struct v4l2_event *old, struct v4l2_event *new) new->u.ctrl.changes |= old->u.ctrl.changes; } +const struct v4l2_subscribed_event_ops ctrl_ops = { Shouldn't this be static const ? You're right I will fix this in the next iteration. + .replace = ctrls_replace, + .merge = ctrls_merge, +}; + int v4l2_event_subscribe(struct v4l2_fh *fh, -struct v4l2_event_subscription *sub, unsigned elems) +struct v4l2_event_subscription *sub, unsigned elems, +const struct v4l2_subscribed_event_ops *ops) { struct v4l2_subscribed_event *sev, *found_ev; struct v4l2_ctrl *ctrl = NULL; @@ -236,9 +242,9 @@ int v4l2_event_subscribe(struct v4l2_fh *fh, sev->flags = sub->flags; sev->fh = fh; sev->elems = elems; + sev->ops = ops; if (ctrl) { - sev->replace = ctrls_replace; - sev->merge = ctrls_merge; + sev->ops =&ctrl_ops; } You can remove the brackets here. I was aiming for minimal diff size here, since this bit will go away in the next patch in the series anyways. spin_lock_irqsave(&fh->vdev->fh_lock, flags); @@ -247,10 +253,22 @@ int v4l2_event_subscribe(struct v4l2_fh *fh, list_add(&sev->list,&fh->subscribed); spin_unlock_irqrestore(&fh->vdev->fh_lock, flags); - /* v4l2_ctrl_add_event uses a mutex, so do this outside the spin lock */ - if (found_ev) + if (found_ev) { kfree(sev); - else if (ctrl) + return 0; /* Already listening */ + } + + if (sev->ops&& sev->ops->add) { + int ret = sev->ops->add(sev); + if (ret) { + sev->ops = NULL; + v4l2_event_unsubscribe(fh, sub); + return ret; + } + } + + /* v4l2_ctrl_add_event uses a mutex, so do this outside the spin lock */ + if (ctrl) v4l2_ctrl_add_event(ctrl, sev); return 0; @@ -307,6 +325,10 @@ int v4l2_event_unsubscribe(struct v4l2_fh *fh, } spin_unlock_irqrestore(&fh->vdev->fh_lock, flags); + + if (sev&& sev->ops&& sev->ops->del) + sev->ops->del(sev); + if (sev&& sev->type == V4L2_EVENT_CTRL) { struct v4l2_ctrl *ctrl = v4l2_ctrl_find(fh->ctrl_handler, sev->id); Regards, Hans -- 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 4/6] v4l2-event: Don't set sev->fh to NULL on unsubcribe
Hi, Thanks for the reviews! On 10/27/2011 02:20 PM, Laurent Pinchart wrote: Hi Hans, On Thursday 27 October 2011 13:18:01 Hans de Goede wrote: 1: There is no reason for this after v4l2_event_unsubscribe releases the spinlock nothing is holding a reference to the sev anymore except for the local reference in the v4l2_event_unsubscribe function. 2: Setting sev->fh to NULL causes problems for the del op added in the next patch of this series, since this op needs a way to get to its own data structures, and typically this will be done by using container_of on an embedded v4l2_fh struct. Signed-off-by: Hans de Goede Acked-by: Laurent Pinchart While reviewing the patch I noticed that v4l2_event_unsubscribe_all() calls v4l2_event_unsubscribe(), which performs control lookup again. Is there a reason for that, instead of handling event unsubscription directly in v4l2_event_unsubscribe_all() ? I didn't write that part, so I'll let Hans V. answer this question. Regards, Hans -- 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: [DVB] Digital Devices Cine CT V6 support
Sébastien RAILLARD (COEXSI) writes: > CineS2 v6 + 2 CAM Readers > > ++ > Tuner 0 -> Input 0 -> || > | Port 0 - TAB 1 | -> Output 0 > Tuner 1 -> Input 1 -> | DVB-S2 | > ++ > Input 2 -> || > | Port 1 - TAB 2 | -> Output 1 > Input 3 -> || > ++ > CAM 0 -> Input 4 -> || > | Port 2 - TAB 3 | -> Output 2 -> CAM 0 > Input 5 -> | CAM | > ++ > CAM 1 -> Input 6 -> || > | Port 3 - TAB 4 | -> Output 3 -> CAM 1 > Input 7 -> | CAM | > ++ > > Two redirections to set : > > * "X0 X2" (input #0 to port #2) > * "X1 X3" (input #1 to port #3) > > Where X is the device number. Correct, except that the CineS2 V6 only has TAB2 and TAB3 on board. Btw., I also added the module parameter adapter_alloc, which lets you specifiy how many adapters are to be allocated: 0 = one adapter per io if modules are present 1 = one adapter for each tab on which a module was detected 2 = one per tab even if no modules were detected 3 = one adapter for all devices of one card If you use adapter_alloc=3 for a config like above (2 tuners 2 CAMS) you will get all the devices in one /dev/dvb/adapterX/ and most programs should now work with CI out of the box (at least with the first tuner) if the redirections are set properly. Regards, Ralph -- 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