Re: RFCv2: Media controller proposal
Hi (repeating my preamble from a previous post) This is a general comment to the whole media controller work: having given a talk at the ELC-E in Grenoble on soc-camera, I mentioned briefly a few related RFCs, including this one. I've got a couple of comments back, including the following ones (which is to say, opinions are not mine and may or may not be relevant, I'm just fulfilling my promise to pass them on;)): 1) what about DVB? Wouldn't they also benefit from such an API? I wasn't able to reply to the question, whether the DVB folks know about this and have a chance to take part in the discussion and eventually use this API? 2) what I am even less sure about is, whether ALSA / ASoC have been mentioned as possible users of MC, or, at least, possible sources for ideas. ASoC has definitely been mentioned as an audio analog of soc-camera, so, I'll be looking at that - at least at their documentation - to see if I can borrow some of their ideas:-) Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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: capture-example.c crash on close_device()
I'm still having trouble with capture-example.c completely locking up my system. The same os image on other hardware works fine. Where do I start looking? What can I do to debug this issue? Sean Sean wrote: Hi, I have compiled kernel 2.6.30 from kernel.org, and I have also compiled capture-example.c from the mercurial depository. These work on laptop hardware, but on my DMP e-box 2300SX (with vortex86 cpu), capture-example.c crashes the system. Complete lockup, no keyboard, etc. I turned on all debuging in gspca_main, i.e. options gspca_main debug=0x1FF. I also put print statements in capture-example.c in main() before each function call. Here is the output below. Has anyone had this problem? --- # capture-example -r snip gspca: packet [28] o:28644 l:126 gspca: add t:2 l:126 gspca: packet [31] o:31713 l:630 pac207: SOF found, bytes to analyze: 630. Frame starts at byte #19 gspca: add t:3 l:14 gspca: frame complete len:26496 q:1 i:0 o:1 gspca: add t:1 l:0 gspca: add t:2 l:600 gspca: poll gspca: read (202752) gspca: dqbuf gspca: frame wait q:1 i:0 o:0 gspca: autogain: lum: 252, desired: 102, steps: 5 gspca: dqbuf 1 gspca: qbuf 1 gspca: qbuf q:0 i:0 o:0 .stop_capturing() uninit_device() close_device() gspca: capture-example close gspca: kill transfer gspca: isoc irq gspca: isoc irq gspca: isoc irq -- 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 -- 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:
Em Mon, 26 Oct 2009 15:33:50 +0100 Hasse Hagen Johansen hasse-linuxme...@hagenjohansen.dk escreveu: subscribe linux-media You should send subscribe emails to majord...@vger.kernel.org instead. -- 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 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: failure to submit first post
Em Mon, 26 Oct 2009 21:24:03 +0800 KS Ng ksn...@gmail.com escreveu: This is a resend with the patch attached. KS Ng wrote: Hi, I've registered to linux-media mailing list a couple of days ago and attempted to do my first posting yesterday with subject Support for Magicpro proHDTV Dual DMB-TH adapter. However I can't see my posting even though I've replied to the email requesting confirmation. Would you please kindly have a look! Please take a look at: http://linuxtv.org/hg/v4l-dvb/raw-file/tip/README.patches for some comments about how to submit a patch. Basically, you'll need to send a patch with a short description at the subject, a more complete description at the body and add your Signed-off-by: there. Also, please run checkpatch before submitting it, since it will point you the CodingStyle troubles that your code have. There are several coding styles there, being harder for people to analyse your code. In the case of tuner_init_pkts, is this a firmware or just register sets? If it is a firmware, it should be split from the code, due to legal issues. Basically, some lawyers believe that, if you distribute a firmware inside of the source code of a GPL'd code, you're bound to distribute also the firmware source code, due to GPL. Cheers, Mauro. Thanks, K.S. Ng email: ksn...@gmail.com 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: Hint request for driver change
Em Mon, 26 Oct 2009 11:45:41 +0100 Massimo Del Fedele m...@veneto.com escreveu: Hi, I'm trying to support the analog part of Pinnacle PCTV310e, which is an ULI M9207 based card; by now I added the support for the digital side patching the M920x driver; in order to add the analog part the driver should be almost completely rewritten, and it'll take more source files, so it should have a separate folder. Shall I make a new driver (with different name, as m920x-new) or simply remove old one and add the new ? It is better to not rename it, to avoid confusion. Ciao Max -- 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 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
[RFC] Media controller: next round of patches
Hi everybody, I've committed 26 media controller patches to http://linuxtv.org/hg/~pinchartl/v4l-dvb-mc-uvc. The code is in an early development phase, so I need to rework the patches and rebase the tree very often. Hg doesn't provide a rebase operation and linuxtv.org can't host git trees yet (AFAIK), so I've settled on quilt+hg. Patches are thus provided as a quilt series on top of the v4l-dvb repository head (at clone time). The first 16 patches come directly from Hans' v4l-dvb-mc tree (including Devin's patches). The remaining patches are based on the 14 patches I've already posted. Compared to the previous RFC/PATCH, this series adds - video_device refactoring - subdev device node support - better subdev support in the UVC driver As always feedback will be greatly appreciated, especially if you believe I'm headed in the wrong direction. If you don't have much time please comment on the video_device refactoring first. -- 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
V4L2_MEMORY_USERPTR support in videobuf-core
Hello, could anybody confirm that there is no full/working support for USERPTR in current videobuf-core? That is the conclusion I came up with after a more thorough investigation. I am currently working to fix that, and will hopefully be posting patches in the coming days/weeks. Is there any other development effort underway related to this problem? Best regards -- Pawel Osciak Linux Platform Group Samsung Poland RD Center -- 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: failure to submit first post
Hi Mauro, Thanks for your attention! I also believe packets under tuner_init_pkts constitute the firmware of the device. I'll see how to construct a firmware file instead of coding them inline, and I'll re-submit once I've figured that out. Cheers, K.S. Ng Mauro Carvalho Chehab wrote: Em Mon, 26 Oct 2009 21:24:03 +0800 KS Ng ksn...@gmail.com escreveu: This is a resend with the patch attached. KS Ng wrote: Hi, I've registered to linux-media mailing list a couple of days ago and attempted to do my first posting yesterday with subject Support for Magicpro proHDTV Dual DMB-TH adapter. However I can't see my posting even though I've replied to the email requesting confirmation. Would you please kindly have a look! Please take a look at: http://linuxtv.org/hg/v4l-dvb/raw-file/tip/README.patches for some comments about how to submit a patch. Basically, you'll need to send a patch with a short description at the subject, a more complete description at the body and add your Signed-off-by: there. Also, please run checkpatch before submitting it, since it will point you the CodingStyle troubles that your code have. There are several coding styles there, being harder for people to analyse your code. In the case of tuner_init_pkts, is this a firmware or just register sets? If it is a firmware, it should be split from the code, due to legal issues. Basically, some lawyers believe that, if you distribute a firmware inside of the source code of a GPL'd code, you're bound to distribute also the firmware source code, due to GPL. Cheers, Mauro. Thanks, K.S. Ng email: ksn...@gmail.com 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] add support for IR on FlyDVB Trio (saa7134)
Hi Kukáš,
Your patch were line-wrapped, so, I can't apply it. Could you please re-submit
if it weren't already merged?
Cheers,
Mauro.
Em Thu, 10 Sep 2009 14:12:07 +0200
Lukáš Karas lukas.ka...@centrum.cz escreveu:
Hi all, here is patch for driver saa7134, that add support for IR reciever
on card LifeView FlyDVB Trio.
I tested it on kernel 2.6.30
Signed-off-by: Lukas Karas lukas.ka...@centrum.cz
diff -uprN video.13c47deee3b1/ir-kbd-i2c.c video/ir-kbd-i2c.c
--- video.13c47deee3b1/ir-kbd-i2c.c 2009-09-07 15:38:46.0 +0200
+++ video/ir-kbd-i2c.c2009-09-08 22:23:34.0 +0200
@@ -438,6 +438,7 @@ static int ir_probe(struct i2c_client *c
ir_type = IR_TYPE_RC5;
ir_codes= ir_codes_fusionhdtv_mce_table;
break;
+ case 0x0b:
case 0x7a:
case 0x47:
case 0x71:
@@ -467,7 +468,7 @@ static int ir_probe(struct i2c_client *c
ir_codes= ir_codes_avermedia_cardbus_table;
break;
default:
- dprintk(1, DEVNAME : Unsupported i2c address 0x%02x\n, addr);
+ dprintk(1, Unsupported i2c address 0x%02x\n, addr);
err = -ENODEV;
goto err_out_free;
}
@@ -514,7 +515,7 @@ static int ir_probe(struct i2c_client *c
/* Make sure we are all setup before going on */
if (!name || !ir-get_key || !ir_codes) {
- dprintk(1, DEVNAME : Unsupported device at address 0x%02x\n,
+ dprintk(1, Unsupported device at address 0x%02x\n,
addr);
err = -ENODEV;
goto err_out_free;
@@ -722,6 +723,30 @@ static int ir_probe(struct i2c_adapter *
ir_attach(adap, msg[0].addr, 0, 0);
}
+ /* special case for LifeView FlyDVB Trio */
+ if (adap-id == I2C_HW_SAA7134) {
+ u8 temp = 0;
+ msg.buf = temp;
+ msg.addr = 0x0b;
+ msg.len = 1;
+ msg.flags = 0;
+
+ /* send weak up message to pic16C505 chip @ LifeView FlyDVB
Trio */
+ if (1 != i2c_transfer(adap,msg,1)) {
+ dprintk(1,send wake up byte to pic16C505 failed\n);
+ }else{
+ msg.flags = I2C_M_RD;
+ rc = i2c_transfer(adap, msg, 1);
+ dprintk(1, probe 0x%02x @ %s: %s\n,
+ msg.addr, adap-name,
+ (1 == rc) ? yes : no);
+ if (1 == rc)
+ ir_attach(adap, msg.addr, 0, 0);
+ }
+ msg.len = 0;
+ msg.flags = I2C_M_RD;
+ }
+
return 0;
}
#else
diff -uprN video.13c47deee3b1/saa7134/saa7134-cards.c video/saa7134/saa7134-
cards.c
--- video.13c47deee3b1/saa7134/saa7134-cards.c2009-09-07
15:38:46.0
+0200
+++ video/saa7134/saa7134-cards.c 2009-09-09 00:45:09.0 +0200
@@ -7212,9 +7212,27 @@ int saa7134_board_init2(struct saa7134_d
}
case SAA7134_BOARD_FLYDVB_TRIO:
{
+ u8 temp = 0;
+ int rc;
u8 data[] = { 0x3c, 0x33, 0x62};
struct i2c_msg msg = {.addr=0x09, .flags=0, .buf=data, .len =
sizeof(data)};
i2c_transfer(dev-i2c_adap, msg, 1);
+
+ /* send weak up message to pic16C505 chip @ LifeView FlyDVB
Trio */
+ msg.buf = temp;
+ msg.addr = 0x0b;
+ msg.len = 1;
+ if (1 != i2c_transfer(dev-i2c_adap,msg,1)) {
+ printk(KERN_WARNING %s: send wake up byte to pic16C505
+ (IR chip) failed\n, dev-name);
+ }else{
+ msg.flags = I2C_M_RD;
+ rc = i2c_transfer(dev-i2c_adap, msg, 1);
+ printk(KERN_INFO %s: probe IR chip @ i2c 0x%02x: %s\n,
+dev-name, msg.addr,(1 == rc) ? yes :
no);
+if (rc == 1)
+dev-has_remote = SAA7134_REMOTE_I2C;
+ }
break;
}
case SAA7134_BOARD_ADS_DUO_CARDBUS_PTV331:
diff -uprN video.13c47deee3b1/saa7134/saa7134-input.c video/saa7134/saa7134-
input.c
--- video.13c47deee3b1/saa7134/saa7134-input.c2009-09-07
15:38:46.0
+0200
+++ video/saa7134/saa7134-input.c 2009-09-08 22:56:02.0 +0200
@@ -132,6 +132,72 @@ static int build_key(struct saa7134_dev
/* - Chip specific I2C key builders - */
+static int get_key_flydvb_trio(struct IR_i2c *ir, u32 *ir_key, u32 *ir_raw)
+{
+ int gpio;
+ int attempt = 0;
+ unsigned char b;
+
+ /* We need this to access GPI Used by the saa_readl macro. */
+#if LINUX_VERSION_CODE KERNEL_VERSION(2, 6, 30)
+
Re: V4L2_MEMORY_USERPTR support in videobuf-core
Em Tue, 27 Oct 2009 11:59:54 +0100 Pawel Osciak p.osc...@samsung.com escreveu: Hello, could anybody confirm that there is no full/working support for USERPTR in current videobuf-core? That is the conclusion I came up with after a more thorough investigation. I am currently working to fix that, and will hopefully be posting patches in the coming days/weeks. Is there any other development effort underway related to this problem? Hi Pawel, The last time I tested the support for userptr at videobuf-core, it were working on x86 plataforms. On that time, I used vivi with videobuf-dma-sg for such tests (it were before its conversion to use videobuf-vmalloc). As support for userptr on videobuf-vmalloc is missing, vivi can't be used for such tests anymore (a good contribution would be to add userptr support on videobuf-vmalloc). Maybe you're suffering some platform-specific issues. 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] add support for IR on FlyDVB Trio (saa7134)
Hi Mauro,
That isn't problem. Would it help you, if I send this patch as attachment?
Regards,
Lukas
Dne Út 27. října 2009 13:06:22 jste napsal(a):
Hi Kukáš,
Your patch were line-wrapped, so, I can't apply it. Could you please
re-submit if it weren't already merged?
Cheers,
Mauro.
Em Thu, 10 Sep 2009 14:12:07 +0200
Lukáš Karas lukas.ka...@centrum.cz escreveu:
Hi all, here is patch for driver saa7134, that add support for IR
reciever on card LifeView FlyDVB Trio.
I tested it on kernel 2.6.30
Signed-off-by: Lukas Karas lukas.ka...@centrum.cz
diff -uprN video.13c47deee3b1/ir-kbd-i2c.c video/ir-kbd-i2c.c
--- video.13c47deee3b1/ir-kbd-i2c.c 2009-09-07 15:38:46.0 +0200
+++ video/ir-kbd-i2c.c 2009-09-08 22:23:34.0 +0200
@@ -438,6 +438,7 @@ static int ir_probe(struct i2c_client *c
ir_type = IR_TYPE_RC5;
ir_codes= ir_codes_fusionhdtv_mce_table;
break;
+ case 0x0b:
case 0x7a:
case 0x47:
case 0x71:
@@ -467,7 +468,7 @@ static int ir_probe(struct i2c_client *c
ir_codes= ir_codes_avermedia_cardbus_table;
break;
default:
- dprintk(1, DEVNAME : Unsupported i2c address 0x%02x\n, addr);
+ dprintk(1, Unsupported i2c address 0x%02x\n, addr);
err = -ENODEV;
goto err_out_free;
}
@@ -514,7 +515,7 @@ static int ir_probe(struct i2c_client *c
/* Make sure we are all setup before going on */
if (!name || !ir-get_key || !ir_codes) {
- dprintk(1, DEVNAME : Unsupported device at address 0x%02x\n,
+ dprintk(1, Unsupported device at address 0x%02x\n,
addr);
err = -ENODEV;
goto err_out_free;
@@ -722,6 +723,30 @@ static int ir_probe(struct i2c_adapter *
ir_attach(adap, msg[0].addr, 0, 0);
}
+ /* special case for LifeView FlyDVB Trio */
+ if (adap-id == I2C_HW_SAA7134) {
+ u8 temp = 0;
+ msg.buf = temp;
+ msg.addr = 0x0b;
+ msg.len = 1;
+ msg.flags = 0;
+
+ /* send weak up message to pic16C505 chip @ LifeView FlyDVB
Trio */
+ if (1 != i2c_transfer(adap,msg,1)) {
+ dprintk(1,send wake up byte to pic16C505 failed\n);
+ }else{
+ msg.flags = I2C_M_RD;
+ rc = i2c_transfer(adap, msg, 1);
+ dprintk(1, probe 0x%02x @ %s: %s\n,
+ msg.addr, adap-name,
+ (1 == rc) ? yes : no);
+ if (1 == rc)
+ ir_attach(adap, msg.addr, 0, 0);
+ }
+ msg.len = 0;
+ msg.flags = I2C_M_RD;
+ }
+
return 0;
}
#else
diff -uprN video.13c47deee3b1/saa7134/saa7134-cards.c
video/saa7134/saa7134- cards.c
--- video.13c47deee3b1/saa7134/saa7134-cards.c 2009-09-07
15:38:46.0 +0200
+++ video/saa7134/saa7134-cards.c 2009-09-09 00:45:09.0 +0200
@@ -7212,9 +7212,27 @@ int saa7134_board_init2(struct saa7134_d
}
case SAA7134_BOARD_FLYDVB_TRIO:
{
+ u8 temp = 0;
+ int rc;
u8 data[] = { 0x3c, 0x33, 0x62};
struct i2c_msg msg = {.addr=0x09, .flags=0, .buf=data, .len =
sizeof(data)}; i2c_transfer(dev-i2c_adap, msg, 1);
+
+ /* send weak up message to pic16C505 chip @ LifeView FlyDVB
Trio */
+ msg.buf = temp;
+ msg.addr = 0x0b;
+ msg.len = 1;
+ if (1 != i2c_transfer(dev-i2c_adap,msg,1)) {
+ printk(KERN_WARNING %s: send wake up byte to pic16C505
+ (IR chip) failed\n, dev-name);
+ }else{
+ msg.flags = I2C_M_RD;
+ rc = i2c_transfer(dev-i2c_adap, msg, 1);
+ printk(KERN_INFO %s: probe IR chip @ i2c 0x%02x: %s\n,
+ dev-name, msg.addr,(1 == rc) ? yes :
no);
+ if (rc == 1)
+ dev-has_remote = SAA7134_REMOTE_I2C;
+ }
break;
}
case SAA7134_BOARD_ADS_DUO_CARDBUS_PTV331:
diff -uprN video.13c47deee3b1/saa7134/saa7134-input.c
video/saa7134/saa7134- input.c
--- video.13c47deee3b1/saa7134/saa7134-input.c 2009-09-07
15:38:46.0 +0200
+++ video/saa7134/saa7134-input.c 2009-09-08 22:56:02.0 +0200
@@ -132,6 +132,72 @@ static int build_key(struct saa7134_dev
/* - Chip specific I2C key builders
- */
+static int get_key_flydvb_trio(struct IR_i2c *ir, u32 *ir_key, u32
*ir_raw) +{
+ int gpio;
+ int attempt = 0;
+ unsigned char b;
+
+ /* We need this to access
Re: RFCv2: Media controller proposal
On Tue, Oct 27, 2009 at 4:04 AM, Guennadi Liakhovetski g.liakhovet...@gmx.de wrote: Hi (repeating my preamble from a previous post) This is a general comment to the whole media controller work: having given a talk at the ELC-E in Grenoble on soc-camera, I mentioned briefly a few related RFCs, including this one. I've got a couple of comments back, including the following ones (which is to say, opinions are not mine and may or may not be relevant, I'm just fulfilling my promise to pass them on;)): 1) what about DVB? Wouldn't they also benefit from such an API? I wasn't able to reply to the question, whether the DVB folks know about this and have a chance to take part in the discussion and eventually use this API? The extent to which DVB applies is that the DVB devices will appear in the MC enumeration. This will allow userland to be able to see hybrid devices where both DVB and analog are tied to the same tuner and cannot be used at the same time. 2) what I am even less sure about is, whether ALSA / ASoC have been mentioned as possible users of MC, or, at least, possible sources for ideas. ASoC has definitely been mentioned as an audio analog of soc-camera, so, I'll be looking at that - at least at their documentation - to see if I can borrow some of their ideas:-) ALSA devices will definitely be available, although at this point I have no reason to believe this will require changes the ALSA code itself. All of the changes involve enumeration within v4l to find the correct ALSA device associated with the tuner and report the correct card number. The ALSA case is actually my foremost concern with regards to the MC API, since it will solve the problem related to applications such as tvtime figuring out which ALSA device to playback audio on. 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: Hauppage HVR-2250 Tuning problems
Steven Toth wrote the driver and has a status page here... http://www.steventoth.net/blog/products/hvr-2250/ you may want to contact him directly, keeping in mind he does this out of love and doesn't get paid for support :) (Although Hauppauge should pay him something for the amount of work he does on their products IMHO). Good Luck Kind words, thank you. :) - Steve -- Steven Toth - 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
Nova 500 T won't tune, kernel issue?
Hi, I have 2 versions of the Hauppauge Nova 500 T dual tuner device, both the single and dual RF input versions. Under kernel 2.6.23 using the latest drivers, they both tune fine. Under kernel 2.6.28, with the same drivers, they won't tune and I see this message when trying to tune: kernel: dvb-usb: could not submit URB no. 0 - get them all back I can conclude that devices are not faulty as they work with one kernel version and fail with another. Can anyone point me in the right direction? Many thanks, Lou -- 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: Hauppage HVR-2250 Tuning problems
Steve, Thanks for responding. I created the channels.conf file and ran the azap command you suggested. In both cases I get something that looks like this: $ azap -r c112 using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' tuning to 72300 Hz video pid 0x0120, audio pid 0x0121 status 00 | signal | snr | ber | unc | status 00 | signal | snr | ber | unc | status 00 | signal | snr | ber | unc | status 00 | signal | snr | ber | unc | status 00 | signal | snr | ber | unc | status 00 | signal | snr | ber | unc | status 00 | signal | snr | ber | unc | status 00 | signal | snr | ber | unc | status 00 | signal | snr | ber | unc | status 1f | signal 0172 | snr 0172 | ber | unc | FE_HAS_LOCK status 1f | signal 0190 | snr 0190 | ber | unc | FE_HAS_LOCK status 00 | signal | snr 0190 | ber | unc | status 00 | signal | snr 0190 | ber | unc | status 00 | signal | snr 0190 | ber | unc | status 00 | signal | snr 0190 | ber | unc | status 00 | signal | snr | ber | unc | status 00 | signal | snr | ber | unc | status 00 | signal | snr | ber | unc | status 00 | signal | snr | ber | unc | status 00 | signal | snr | ber | unc | status 00 | signal | snr | ber | unc | status 00 | signal | snr | ber | unc | status 00 | signal | snr | ber | unc | status 00 | signal | snr | ber | unc | status 00 | signal | snr | ber | unc | status 00 | signal | snr | ber | unc | status 00 | signal | snr | ber | unc | status 00 | signal | snr | ber | unc | status 00 | signal | snr | ber | unc | status 00 | signal | snr | ber | unc | status 00 | signal | snr | ber | unc | status 1f | signal 0190 | snr 0190 | ber | unc | FE_HAS_LOCK status 00 | signal 0190 | snr 0190 | ber | unc | status 00 | signal 0190 | snr 0190 | ber | unc | status 07 | signal 0190 | snr 0190 | ber | unc | status 07 | signal 0190 | snr 0190 | ber | unc | status 07 | signal 0190 | snr 0190 | ber | unc | status 00 | signal 0190 | snr 0190 | ber | unc | status 00 | signal 0190 | snr 0190 | ber | unc | status 00 | signal 0190 | snr 0190 | ber | unc | status 00 | signal 0190 | snr 0190 | ber | unc | Does that mean the signal is going in and out? Any suggestions? Thanks again. I really appreciate the work you've done on the driver for this card, and that you're willing to take the time to help out. Thanks to Mr. Sillyname, also, for adding another data point. --dan On Tue, Oct 27, 2009 at 8:17 AM, Steven Toth st...@kernellabs.com wrote: I have done some searching online, and that's what led me to scan, dvbscan and scte65scan, but none of the suggestions I've found so far seem to help. Does anyone have any suggestions as to where I can go from here? Could there be something wrong with the card itself? Are there any diagnostics I could run? Thanks in advance for any help that anyone can offer. Dan, I'm not aware of any digital cable issues currently. 1) Do you have any other tvtuners that can validate your signal is working correctly? Specifically, for a number of identifiable frequencies? 2) Is your cable plant standard cable, IRC, or HRC? 3) I suggest you put together a rudamentary $HOME/.azap/channels.conf and experiment with azap, that works really well for me. Here's a sample from my development channels.conf: c112:72300:QAM_256:288:289:713 c86:59700:QAM_256:288:289:713 Try this with azap -r c86 or c112, what happens? - Steve -- Steven Toth - 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 -- 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 2/6 v5] Support for TVP7002 in dm365 board
Santiago, Kevin,
-Original Message-
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Monday, October 26, 2009 5:35 PM
To: santiago.nu...@ridgerun.com
Cc: Narnakaje, Snehaprabha; davinci-linux-open-
sou...@linux.davincidsp.com; todd.fisc...@ridgerun.com; linux-
me...@vger.kernel.org
Subject: Re: [PATCH 2/6 v5] Support for TVP7002 in dm365 board
Santiago Nunez-Corrales snu...@ridgerun.com writes:
Kevin Hilman wrote:
santiago.nu...@ridgerun.com writes:
From: Santiago Nunez-Corrales santiago.nu...@ridgerun.com
This patch provides support for TVP7002 in architecture definitions
within DM365.
Signed-off-by: Santiago Nunez-Corrales santiago.nu...@ridgerun.com
---
arch/arm/mach-davinci/board-dm365-evm.c | 170
++-
1 files changed, 166 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-davinci/board-dm365-evm.c b/arch/arm/mach-
davinci/board-dm365-evm.c
index a1d5e7d..6c544d3 100644
--- a/arch/arm/mach-davinci/board-dm365-evm.c
+++ b/arch/arm/mach-davinci/board-dm365-evm.c
@@ -38,6 +38,11 @@
#include mach/common.h
#include mach/mmc.h
#include mach/nand.h
+#include mach/gpio.h
+#include linux/videodev2.h
+#include media/tvp514x.h
+#include media/tvp7002.h
+#include media/davinci/videohd.h
static inline int have_imager(void)
@@ -48,8 +53,11 @@ static inline int have_imager(void)
static inline int have_tvp7002(void)
{
- /* REVISIT when it's supported, trigger via Kconfig */
+#ifdef CONFIG_VIDEO_TVP7002
+ return 1;
+#else
return 0;
+#endif
I've said this before, but I'll say it again. I don't like the
#ifdef-on-Kconfig-option here.
Can you add a probe hook to the platform_data so that when the tvp7002
is found it can call pdata-probe() which could then set a flag
for use by have_tvp7002().
This will have he same effect without the ifdef since if the driver
is not compiled in, its probe can never be triggered.
Kevin
Kevin,
I've been working on this particular implementation. This
board-dm365-evm.c is specific to the board, therefore I don't still
get the point of not having those values wired to the board file, but
I know it'd be nice to have the CPLD configuration triggered upon
TVP7002 detection. I see two options:
Having them in the board file is appropriate, what I object to is the
selection by Kconfig. Run-time detection is always preferred when
possible.
We have this CPLD init API - evm_init_cpld() called from the dm365_evm_init()
function. The CPLD init API was trying to initialize the CPLD, based on the
default configuration. I believe David Brownell had this placeholder for
have_imager() and have_tvp7002() APIs since, we have different CPLD settings
for the imager, tvp7002 and tvp5146 for the video input source.
1. Do the callback function inside pdata and initialize it at driver
load time (tvp7002_probe). Set tvp5146 as default and override when
driver loads (and restore when unloads).
This is the preferred option to me.
We can decide on the default video input source to be TVP5146. However we do
not need a new callback function. We already have the VPFE .setup_input
callback API dm365evm_setup_video_input() for the same purpose. The VPFE
.setup_input API is called when each of the decoders (sub-devices) registered
with VPFE capture driver. It is also called when the application decides on an
input source and switches between the input sources.
So, TVP5146 remains as the default video input source, only until VPFE probe is
called, which registers the all decoders (sub-devices) defined in the VPFE
platform data. This also means that the last decoder in the VPFE platform data
remains active after boot-up. One can change the order in the VPFE platform
data if a particular input source needs to remain active after boot-up. Note
that application can always switch the input-source at run time.
I quickly tried removing the have_imager() construct in the evm_init_cpld() and
here is the output -
Starting kernel ...
Uncompressing
Linux...
done, booting the kernel.
Linux version 2.6.32-rc2-davinci1-dirty
...
CPU: Testing write buffer coherency: ok
DaVinci: 8 gpio irqs
NET: Registered protocol family 16
EVM: tvp5146 SD video input
bio: create slab bio-0 at 0
SCSI subsystem initialized
...
vpfe_init
vpfe-capture: vpss clock vpss_master enabled
vpfe-capture vpfe-capture: v4l2 device registered
vpfe-capture vpfe-capture: video device registered
EVM: switch to tvp5146 SD video input
tvp514x 1-005d: tvp514x 1-005d decoder driver registered !!
vpfe-capture vpfe-capture: v4l2 sub device tvp5146 registered
EVM: switch to tvp7002 HD video input
tvp7002 1-005c: tvp7002 1-005c decoder driver registered !!
vpfe-capture vpfe-capture: v4l2 sub device tvp7002
Re: [PATCH 2/6 v5] Support for TVP7002 in dm365 board
Sneha,
So, if I got it right, have_tvp7002 is unnecessary since that
initialization is done via the CPLD interface. Therefore, all I need to
do is actually remove the logic for the device from board-dm365-evm.h.
Am I right? If so, should I also remove the logic for tvp5146?
Regards,
Narnakaje, Snehaprabha wrote:
Santiago, Kevin,
-Original Message-
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Monday, October 26, 2009 5:35 PM
To: santiago.nu...@ridgerun.com
Cc: Narnakaje, Snehaprabha; davinci-linux-open-
sou...@linux.davincidsp.com; todd.fisc...@ridgerun.com; linux-
me...@vger.kernel.org
Subject: Re: [PATCH 2/6 v5] Support for TVP7002 in dm365 board
Santiago Nunez-Corrales snu...@ridgerun.com writes:
Kevin Hilman wrote:
santiago.nu...@ridgerun.com writes:
From: Santiago Nunez-Corrales santiago.nu...@ridgerun.com
This patch provides support for TVP7002 in architecture definitions
within DM365.
Signed-off-by: Santiago Nunez-Corrales santiago.nu...@ridgerun.com
---
arch/arm/mach-davinci/board-dm365-evm.c | 170
++-
1 files changed, 166 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-davinci/board-dm365-evm.c b/arch/arm/mach-
davinci/board-dm365-evm.c
index a1d5e7d..6c544d3 100644
--- a/arch/arm/mach-davinci/board-dm365-evm.c
+++ b/arch/arm/mach-davinci/board-dm365-evm.c
@@ -38,6 +38,11 @@
#include mach/common.h
#include mach/mmc.h
#include mach/nand.h
+#include mach/gpio.h
+#include linux/videodev2.h
+#include media/tvp514x.h
+#include media/tvp7002.h
+#include media/davinci/videohd.h
static inline int have_imager(void)
@@ -48,8 +53,11 @@ static inline int have_imager(void)
static inline int have_tvp7002(void)
{
- /* REVISIT when it's supported, trigger via Kconfig */
+#ifdef CONFIG_VIDEO_TVP7002
+ return 1;
+#else
return 0;
+#endif
I've said this before, but I'll say it again. I don't like the
#ifdef-on-Kconfig-option here.
Can you add a probe hook to the platform_data so that when the tvp7002
is found it can call pdata-probe() which could then set a flag
for use by have_tvp7002().
This will have he same effect without the ifdef since if the driver
is not compiled in, its probe can never be triggered.
Kevin
Kevin,
I've been working on this particular implementation. This
board-dm365-evm.c is specific to the board, therefore I don't still
get the point of not having those values wired to the board file, but
I know it'd be nice to have the CPLD configuration triggered upon
TVP7002 detection. I see two options:
Having them in the board file is appropriate, what I object to is the
selection by Kconfig. Run-time detection is always preferred when
possible.
We have this CPLD init API - evm_init_cpld() called from the dm365_evm_init()
function. The CPLD init API was trying to initialize the CPLD, based on the
default configuration. I believe David Brownell had this placeholder for
have_imager() and have_tvp7002() APIs since, we have different CPLD settings
for the imager, tvp7002 and tvp5146 for the video input source.
1. Do the callback function inside pdata and initialize it at driver
load time (tvp7002_probe). Set tvp5146 as default and override when
driver loads (and restore when unloads).
This is the preferred option to me.
We can decide on the default video input source to be TVP5146. However we do
not need a new callback function. We already have the VPFE .setup_input
callback API dm365evm_setup_video_input() for the same purpose. The VPFE
.setup_input API is called when each of the decoders (sub-devices) registered
with VPFE capture driver. It is also called when the application decides on an
input source and switches between the input sources.
So, TVP5146 remains as the default video input source, only until VPFE probe is
called, which registers the all decoders (sub-devices) defined in the VPFE
platform data. This also means that the last decoder in the VPFE platform data
remains active after boot-up. One can change the order in the VPFE platform
data if a particular input source needs to remain active after boot-up. Note
that application can always switch the input-source at run time.
I quickly tried removing the have_imager() construct in the evm_init_cpld() and
here is the output -
Starting kernel ...
Uncompressing
Linux...
done, booting the kernel.
Linux version 2.6.32-rc2-davinci1-dirty
...
CPU: Testing write buffer coherency: ok
DaVinci: 8 gpio irqs
NET: Registered protocol family 16
EVM: tvp5146 SD video input
bio: create slab bio-0 at 0
SCSI subsystem initialized
...
vpfe_init
vpfe-capture: vpss clock vpss_master enabled
vpfe-capture vpfe-capture: v4l2 device registered
vpfe-capture vpfe-capture: video device
RE: [PATCH 2/6 v5] Support for TVP7002 in dm365 board
-Original Message-
From: Santiago Nunez-Corrales [mailto:snu...@ridgerun.com]
Sent: Tuesday, October 27, 2009 11:54 AM
To: Narnakaje, Snehaprabha
Cc: Kevin Hilman; davinci-linux-open-sou...@linux.davincidsp.com;
todd.fisc...@ridgerun.com; linux-media@vger.kernel.org
Subject: Re: [PATCH 2/6 v5] Support for TVP7002 in dm365 board
Sneha,
So, if I got it right, have_tvp7002 is unnecessary since that
initialization is done via the CPLD interface. Therefore, all I need to
do is actually remove the logic for the device from board-dm365-evm.h.
Am I right? If so, should I also remove the logic for tvp5146?
Santiago,
Yes, have_tvp7002 is not necessary. In fact evm_init_cpld() is also not
necessary from video input source selection perspective. At this point, you can
remove have_tvp7002() and keep the default as TVP5146. The evm_init_cpld()
requires some cleanup for have_imager() as well. I am expecting Murali to
provide patches for this sometime soon.
This brings up another concern. Your board setup related patches are dependent
on one of the old patches from Neil Sikka - to add TVP5146 capture support.
That patch is not in the mainline yet and requires re-submission by Murali.
I suggest you complete the TVP7002 sub-device driver (tvp7002.c and tvp7002.h),
submit patches and follow up with the approval in the V4L2 community.
Patches corresponding to VPFE and DM365 board setup can be handled by Murali,
working with you.
Thanks
Sneha
Regards,
Narnakaje, Snehaprabha wrote:
Santiago, Kevin,
-Original Message-
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Monday, October 26, 2009 5:35 PM
To: santiago.nu...@ridgerun.com
Cc: Narnakaje, Snehaprabha; davinci-linux-open-
sou...@linux.davincidsp.com; todd.fisc...@ridgerun.com; linux-
me...@vger.kernel.org
Subject: Re: [PATCH 2/6 v5] Support for TVP7002 in dm365 board
Santiago Nunez-Corrales snu...@ridgerun.com writes:
Kevin Hilman wrote:
santiago.nu...@ridgerun.com writes:
From: Santiago Nunez-Corrales santiago.nu...@ridgerun.com
This patch provides support for TVP7002 in architecture definitions
within DM365.
Signed-off-by: Santiago Nunez-Corrales santiago.nu...@ridgerun.com
---
arch/arm/mach-davinci/board-dm365-evm.c | 170
++-
1 files changed, 166 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-davinci/board-dm365-evm.c
b/arch/arm/mach-
davinci/board-dm365-evm.c
index a1d5e7d..6c544d3 100644
--- a/arch/arm/mach-davinci/board-dm365-evm.c
+++ b/arch/arm/mach-davinci/board-dm365-evm.c
@@ -38,6 +38,11 @@
#include mach/common.h
#include mach/mmc.h
#include mach/nand.h
+#include mach/gpio.h
+#include linux/videodev2.h
+#include media/tvp514x.h
+#include media/tvp7002.h
+#include media/davinci/videohd.h
static inline int have_imager(void)
@@ -48,8 +53,11 @@ static inline int have_imager(void)
static inline int have_tvp7002(void)
{
- /* REVISIT when it's supported, trigger via Kconfig */
+#ifdef CONFIG_VIDEO_TVP7002
+ return 1;
+#else
return 0;
+#endif
I've said this before, but I'll say it again. I don't like the
#ifdef-on-Kconfig-option here.
Can you add a probe hook to the platform_data so that when the
tvp7002
is found it can call pdata-probe() which could then set a flag
for use by have_tvp7002().
This will have he same effect without the ifdef since if the driver
is not compiled in, its probe can never be triggered.
Kevin
Kevin,
I've been working on this particular implementation. This
board-dm365-evm.c is specific to the board, therefore I don't still
get the point of not having those values wired to the board file, but
I know it'd be nice to have the CPLD configuration triggered upon
TVP7002 detection. I see two options:
Having them in the board file is appropriate, what I object to is the
selection by Kconfig. Run-time detection is always preferred when
possible.
We have this CPLD init API - evm_init_cpld() called from the
dm365_evm_init() function. The CPLD init API was trying to initialize the
CPLD, based on the default configuration. I believe David Brownell had
this placeholder for have_imager() and have_tvp7002() APIs since, we have
different CPLD settings for the imager, tvp7002 and tvp5146 for the video
input source.
1. Do the callback function inside pdata and initialize it at driver
load time (tvp7002_probe). Set tvp5146 as default and override when
driver loads (and restore when unloads).
This is the preferred option to me.
We can decide on the default video input source to be TVP5146. However
we do not need a new callback function. We already have the VPFE
.setup_input callback API dm365evm_setup_video_input() for the same
purpose. The VPFE .setup_input API is called when each of the decoders
(sub-devices)
Re: Hauppage HVR-2250 Tuning problems
On Tue, Oct 27, 2009 at 10:55 AM, dan danwalke...@gmail.com wrote: Steve, Thanks for responding. I created the channels.conf file and ran the azap command you suggested. In both cases I get something that looks like this: $ azap -r c112 using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' tuning to 72300 Hz video pid 0x0120, audio pid 0x0121 status 00 | signal | snr | ber | unc | status 00 | signal | snr | ber | unc | status 00 | signal | snr | ber | unc | status 00 | signal | snr | ber | unc | status 00 | signal | snr | ber | unc | status 00 | signal | snr | ber | unc | status 00 | signal | snr | ber | unc | status 00 | signal | snr | ber | unc | status 00 | signal | snr | ber | unc | status 1f | signal 0172 | snr 0172 | ber | unc | FE_HAS_LOCK status 1f | signal 0190 | snr 0190 | ber | unc | FE_HAS_LOCK Are you amping up or splitting the signal in any way? If so, for test purposes remove anything that can degrade or improve RF. It looks like the tuner gets into lock briefly but falls out, implying abnormal RF conditions. When it locks you have perfect SNR, kind of implying that the signal may be too strong. Additionally, for all your testing, repeat the tests on tuner#2 by azap -a1 -r c112. Additionally, try channel 83 or edit the conf file and add some lower channels in the 40-80 range where the RF characteristics would be wildly different. I'd like to see how the card performs in these circumstances for you. Regards, -- Steven Toth - 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: [PATCH 2/6 v5] Support for TVP7002 in dm365 board
Understood. I will send my refactoring according to community revisions
I have up to now and wait for integration with Murali. I have some
questions before fully using his DV interfaces.
Regards,
Narnakaje, Snehaprabha wrote:
-Original Message-
From: Santiago Nunez-Corrales [mailto:snu...@ridgerun.com]
Sent: Tuesday, October 27, 2009 11:54 AM
To: Narnakaje, Snehaprabha
Cc: Kevin Hilman; davinci-linux-open-sou...@linux.davincidsp.com;
todd.fisc...@ridgerun.com; linux-media@vger.kernel.org
Subject: Re: [PATCH 2/6 v5] Support for TVP7002 in dm365 board
Sneha,
So, if I got it right, have_tvp7002 is unnecessary since that
initialization is done via the CPLD interface. Therefore, all I need to
do is actually remove the logic for the device from board-dm365-evm.h.
Am I right? If so, should I also remove the logic for tvp5146?
Santiago,
Yes, have_tvp7002 is not necessary. In fact evm_init_cpld() is also not
necessary from video input source selection perspective. At this point, you can
remove have_tvp7002() and keep the default as TVP5146. The evm_init_cpld()
requires some cleanup for have_imager() as well. I am expecting Murali to
provide patches for this sometime soon.
This brings up another concern. Your board setup related patches are dependent
on one of the old patches from Neil Sikka - to add TVP5146 capture support.
That patch is not in the mainline yet and requires re-submission by Murali.
I suggest you complete the TVP7002 sub-device driver (tvp7002.c and tvp7002.h),
submit patches and follow up with the approval in the V4L2 community.
Patches corresponding to VPFE and DM365 board setup can be handled by Murali,
working with you.
Thanks
Sneha
Regards,
Narnakaje, Snehaprabha wrote:
Santiago, Kevin,
-Original Message-
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Monday, October 26, 2009 5:35 PM
To: santiago.nu...@ridgerun.com
Cc: Narnakaje, Snehaprabha; davinci-linux-open-
sou...@linux.davincidsp.com; todd.fisc...@ridgerun.com; linux-
me...@vger.kernel.org
Subject: Re: [PATCH 2/6 v5] Support for TVP7002 in dm365 board
Santiago Nunez-Corrales snu...@ridgerun.com writes:
Kevin Hilman wrote:
santiago.nu...@ridgerun.com writes:
From: Santiago Nunez-Corrales santiago.nu...@ridgerun.com
This patch provides support for TVP7002 in architecture definitions
within DM365.
Signed-off-by: Santiago Nunez-Corrales santiago.nu...@ridgerun.com
---
arch/arm/mach-davinci/board-dm365-evm.c | 170
++-
1 files changed, 166 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-davinci/board-dm365-evm.c
b/arch/arm/mach-
davinci/board-dm365-evm.c
index a1d5e7d..6c544d3 100644
--- a/arch/arm/mach-davinci/board-dm365-evm.c
+++ b/arch/arm/mach-davinci/board-dm365-evm.c
@@ -38,6 +38,11 @@
#include mach/common.h
#include mach/mmc.h
#include mach/nand.h
+#include mach/gpio.h
+#include linux/videodev2.h
+#include media/tvp514x.h
+#include media/tvp7002.h
+#include media/davinci/videohd.h
static inline int have_imager(void)
@@ -48,8 +53,11 @@ static inline int have_imager(void)
static inline int have_tvp7002(void)
{
- /* REVISIT when it's supported, trigger via Kconfig */
+#ifdef CONFIG_VIDEO_TVP7002
+ return 1;
+#else
return 0;
+#endif
I've said this before, but I'll say it again. I don't like the
#ifdef-on-Kconfig-option here.
Can you add a probe hook to the platform_data so that when the
tvp7002
is found it can call pdata-probe() which could then set a flag
for use by have_tvp7002().
This will have he same effect without the ifdef since if the driver
is not compiled in, its probe can never be triggered.
Kevin
Kevin,
I've been working on this particular implementation. This
board-dm365-evm.c is specific to the board, therefore I don't still
get the point of not having those values wired to the board file, but
I know it'd be nice to have the CPLD configuration triggered upon
TVP7002 detection. I see two options:
Having them in the board file is appropriate, what I object to is the
selection by Kconfig. Run-time detection is always preferred when
possible.
We have this CPLD init API - evm_init_cpld() called from the
dm365_evm_init() function. The CPLD init API was trying to initialize the
CPLD, based on the default configuration. I believe David Brownell had
this placeholder for have_imager() and have_tvp7002() APIs since, we have
different CPLD settings for the imager, tvp7002 and tvp5146 for the video
input source.
1. Do the callback function inside pdata and initialize it at driver
load time (tvp7002_probe). Set tvp5146 as default and override when
driver loads (and restore when unloads).
This is the preferred option to me.
We can decide on the default
[PULL] http://udev.netup.ru/hg/v4l-dvb-commits
Mauro, Please pull from http://udev.netup.ru/hg/v4l-dvb-commits for the following 4 changesets: 01/04: stv6110: add configurable gain http://udev.netup.ru/hg/v4l-dvb-commits?cmd=changeset;node=655c21f61eb3 02/04: stv0900: fix diseqc support for NetUP card http://udev.netup.ru/hg/v4l-dvb-commits?cmd=changeset;node=7682b35a0526 03/04: stv0900: config definition for single/dual mode http://udev.netup.ru/hg/v4l-dvb-commits?cmd=changeset;node=71fb9ae3e3f7 04/04: stv0900 cut3.0 additions http://udev.netup.ru/hg/v4l-dvb-commits?cmd=changeset;node=958ba6f1a1f8 dvb/frontends/stv0900.h |1 dvb/frontends/stv0900_core.c | 281 +++ dvb/frontends/stv0900_init.h | 63 +++ dvb/frontends/stv0900_priv.h |7 dvb/frontends/stv0900_reg.h | 769 --- dvb/frontends/stv0900_sw.c | 669 ++--- dvb/frontends/stv6110.c | 13 dvb/frontends/stv6110.h |1 video/cx23885/cx23885-dvb.c | 11 9 files changed, 978 insertions(+), 837 deletions(-) Thanks, Igor -- 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 0/4 v5] Support for TVP7002 in DM365
This series of patches provide support for the TVP7002 decoder in DM365. Support includes: * Inclusion of the chip in v4l2 definitions * Definition in board specific data structures * Linking within the VPFE architecture * Definition of TVP7002 specific data structures * Kconfig and Makefile support This series corrects many issued pointed out by Snehaprabha Narnakaje, Muralidharan Karicheri, Vaibhav Hiremath and Hans Verkuil and solves testing problems. Tested on DM365 TI EVM with resolutions 720p, 10...@60, 576P and 480P with video capture application. Includes latest revisions from Hans. This driver depends upon board-dm365-evm.c and vpfe_capture.c to be ready for complete integration. -- Santiago Nunez-Corrales, Eng. RidgeRun Engineering, LLC Guayabos, Curridabat San Jose, Costa Rica +(506) 2271 1487 +(506) 8313 0536 http://www.ridgerun.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
[PULL] http://udev.netup.ru/hg/v4l-dvb-commits
Mauro, Please pull from http://udev.netup.ru/hg/v4l-dvb-commits for the following 5 changesets: 01/05: stv6110: add configurable gain http://udev.netup.ru/hg/v4l-dvb-commits?cmd=changeset;node=655c21f61eb3 02/05: stv0900: fix diseqc support for NetUP card http://udev.netup.ru/hg/v4l-dvb-commits?cmd=changeset;node=7682b35a0526 03/05: stv0900: config definition for single/dual mode http://udev.netup.ru/hg/v4l-dvb-commits?cmd=changeset;node=71fb9ae3e3f7 04/05: stv0900 cut3.0 additions http://udev.netup.ru/hg/v4l-dvb-commits?cmd=changeset;node=958ba6f1a1f8 05/05: Change str snr scale for stv0900/903 and Netup Dual DVB-S2 card. http://udev.netup.ru/hg/v4l-dvb-commits?cmd=changeset;node=5d0eb726d7cd dvb/frontends/stv0900.h |1 dvb/frontends/stv0900_core.c | 306 - dvb/frontends/stv0900_init.h | 63 +++ dvb/frontends/stv0900_priv.h |7 dvb/frontends/stv0900_reg.h | 769 --- dvb/frontends/stv0900_sw.c | 669 ++--- dvb/frontends/stv6110.c | 13 dvb/frontends/stv6110.h |1 video/cx23885/cx23885-dvb.c | 11 9 files changed, 999 insertions(+), 841 deletions(-) Thanks, Igor -- 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: V4L2_MEMORY_USERPTR support in videobuf-core
Hi Pavel, On Tuesday 27 October 2009 17:17:59 Pawel Osciak wrote: Hi Mauro, thank you for your reply. On Tuesday, October 27, 2009 1:36 PM Mauro Carvalho Chehab [mailto:mche...@infradead.org] wrote: could anybody confirm that there is no full/working support for USERPTR in current videobuf-core? That is the conclusion I came up with after a more thorough investigation. I am currently working to fix that, and will hopefully be posting patches in the coming days/weeks. Is there any other development effort underway related to this problem? (...) The last time I tested the support for userptr at videobuf-core, it were working on x86 plataforms. On that time, I used vivi with videobuf-dma-sg for such tests (it were before its conversion to use videobuf-vmalloc). As support for userptr on videobuf-vmalloc is missing, vivi can't be used for such tests anymore (a good contribution would be to add userptr support on videobuf-vmalloc). I might be missing something, but for me the path looks as follows (sources: kernel, LWN articles, V4L2 API Specification): 1. open, query, format, other stuff, unimportant 2. VIDEOBUF_REQBUFS - pass type and set memory to V4L2_MEMORY_USERPTR only. 3. VIDEOBUF_QUERYBUFS - only for memory-mapped I/O, so not called. 4. VIDEOBUF_QBUF - pass type, memory, userptr and length fields only. As the API Specification states in section 3.3: No buffers are allocated beforehands, consequently they are not indexed and cannot be queried like mapped buffers with the VIDIOC_QUERYBUF ioctl. But when one calls QBUF, videobuf_qbuf() uses b-index for all types of memory. I have found no mention in the API Specs about passing/returning indexes in USERPTR, quite the contrary, they actually state that indexes are not used in that mode for neither REQBUFS nor QBUF at all. I'm not sure about the history of this issue, but it's a specification problem in my opinion. Most (if not all) drivers that support USERPTR require a number of buffers to be specified when calling VIDEOBUF_REQBUFS and use indexes like they would for MMAP buffers. Even if that was the case though, would an application be supposed to arbitrarily choose what index to pass? If so, how would it know what range is valid? And even if it would, the next check: (buf-state != VIDEOBUF_NEEDS_INIT buf_state != VIDEOBUF_IDLE) would most probably fail anyway. How to enqueue and handle multiple userptr buffers? You should set the number of buffers are VIDIOC_REQBUFS time and handle QBUF/DQBUF like you would for MMAP buffers. -- 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: [Linux-uvc-devel] again Logitech QuickCam Pro for Notebooks 046d:0991
On Monday 26 October 2009 15:06:41 Hans de Goede wrote: On 10/26/2009 12:52 PM, Alexey Fisher wrote: Am Sonntag, den 25.10.2009, 14:21 +0100 schrieb Hans de Goede: [snip] fwiw I'm a v4l kernel developer, but I'm not involved in the UVC driver, I'm however a contributor to cheese, I thought that my input that cheese would give up even if the driver has a long enough timeout would be helpful. To try and see if this (the cheese timeout is the issue), you will need to re-compile cheese from source, after unpacking cheese, edit src/cheese-webcam.c and goto line 716 (in 2.28.0) And change the 10 * GST_SECOND there in something bigger. I also see that I'm mistaken and the timeout in cheese is not 3 but 10 seconds, it might have changed recently, or my memory has been playing tricks on me. I still believe this might be the cause, the trace you have posted seems consistent with cheese's behaviour. Also noticed that there never is a successfull DQBUF the first time cheese opens the device. If cheese (or rather gstreamer) does not manage to DQBUF the first time, then cheese will not work with the device. There is a limitation in gstreamer (or maybe in the way cheese uses it) where gstreamer needs to be streaming before cheese can tell the properties of the cam. If the stream does not start within the first 10 seconds, then cheese will fail to get the properties. If you go to cheese's edit - preferences menu, and your cam has no resolutions listed there (the resolution drop down is grayed out). This is what is happening. As for empathy, I'm not familiar with that. But if we can get cheese to work first I'm sure that that would be a good step in the right direction. Hallo Hans, thank you for your constructive response, I increased timeout to 15 seconds i now i can't reproduce camera freeze, i'll play with it more to be sure. There is still one issue with it - on cold start the image is zoomed in. I need to close cheese and open it again to get normal zoom. The resolution seems to be the same. Zoomed in ? Really ? As far as I know the QuickCam Pro for Notebooks has no optical or digital zoom. Could you please send me lsusb's output for your device ? That definitely sounds like a camera bug, but maybe we can do something on the driver side (like forcing a resolution change even if not necessary) to work around this. Laurent ? The driver already sends a video format and resolution set request to the device when starting the video stream. Note re-adding the mailing list and Laurent to the CC, they somehow got dropped. Thanks. -- 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
Lifeview hybrid saa7134 pci driver not working anymore pt2
pt1 is here http://linuxtv.org/pipermail/linux-dvb/2009-August/032334.html I have a Lifeview Hybrid Pci card and since around August 2009 the driver doesn't work in 64bit linux but works only in 32bit linux. Now, I am using vanilla 2.6.31.5 source with latest mercurial v4b-dvb snapshot. I tried today again in my 64bit system to see if the driver works but again I discovered that it just doesn't work. I am using the same firmware on both 32 and 64bit linux installations and in 32bits I have no problem, everything works. I am choosing the same options in both 32 and 64bit installations. The error that I get is in the attachement. It complains about firmware but the firmware is exactly the same with my 32bit installation where things work. What's wrong with the saa7134 driver ? Linux video capture interface: v2.00 saa7130/34: v4l2 driver version 0.2.15 loaded ACPI: PCI Interrupt Link [APC2] enabled at IRQ 17 saa7134 :05:07.0: PCI INT A - Link[APC2] - GSI 17 (level, low) - IRQ 17 saa7133[0]: found at :05:07.0, rev: 209, irq: 17, latency: 32, mmio: 0xd000 saa7133[0]: subsystem: 5168:3306, board: LifeView FlyDVB-T Hybrid Cardbus/MSI TV @nywhere A/D NB [card=94,autodetected] saa7133[0]: board init: gpio is 21 IRQ 17/saa7133[0]: IRQF_DISABLED is not guaranteed on shared IRQs saa7133[0]: i2c eeprom 00: 68 51 06 33 54 20 1c 00 43 43 a9 1c 55 d2 b2 92 saa7133[0]: i2c eeprom 10: 00 00 62 08 ff 20 ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom 20: 01 40 01 03 03 01 01 03 08 ff 01 16 ff ff ff ff saa7133[0]: i2c eeprom 30: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom 40: ff 21 00 c2 96 10 05 01 01 16 32 15 ff ff ff ff saa7133[0]: i2c eeprom 50: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom 60: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom 70: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom 80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom 90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[0]: i2c eeprom f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff i2c-adapter i2c-2: Invalid 7-bit address 0x7a tuner 2-004b: chip found @ 0x96 (saa7133[0]) tda829x 2-004b: setting tuner address to 61 tda829x 2-004b: type set to tda8290+75a saa7133[0]: registered device video0 [v4l2] saa7133[0]: registered device vbi0 saa7133[0]: registered device radio0 saa7134 ALSA driver for DMA sound loaded IRQ 17/saa7133[0]: IRQF_DISABLED is not guaranteed on shared IRQs saa7133[0]/alsa: saa7133[0] at 0xd000 irq 17 registered as card -1 dvb_init() allocating 1 frontend DVB: registering new adapter (saa7133[0]) DVB: registering adapter 0 frontend 0 (Philips TDA10046H DVB-T)... tda1004x: setting up plls for 48MHz sampling clock tda1004x: found firmware revision ea -- invalid tda1004x: trying to boot from eeprom tda1004x: found firmware revision ea -- invalid tda1004x: waiting for firmware upload... saa7134 :05:07.0: firmware: requesting dvb-fe-tda10046.fw tda1004x: Error during firmware upload tda1004x: found firmware revision ea -- invalid tda1004x: firmware upload failed tda827x_probe_version: could not read from tuner at addr: 0xc2
AirLink101 USB capture device
Hi, I have an Airlink101 ATVUSB02 capture device that is currently not working. The product page can be found at http://www.airlink101.com/products/atvusb02.php. I am using Ubuntu 8.10(Intrepid), kernel 2.6.27-15-generic, and as-of 10/27/09, the latest v4l-dvb. dmesg: [ 491.352065] usb 3-1: new high speed USB device using ehci_hcd and address 2 [ 491.492075] usb 3-1: configuration #1 chosen from 1 choice [ 491.850968] Linux video capture interface: v2.00 [ 491.914702] em28xx: New device @ 480 Mbps (eb1a:2800, interface 0, class 0) [ 491.917479] em28xx #0: em28xx chip ID = 7 [ 492.068059] em28xx #0: board has no eeprom [ 492.068098] em28xx #0: Identified as Unknown EM2800 video grabber (card=0) [ 501.352045] em28xx #0: Your board has no unique USB ID and thus need a hint to be detected. [ 501.352089] em28xx #0: You may try to use card=n insmod option to workaround that. [ 501.352096] em28xx #0: Please send an email with this log to: [ 501.352102] em28xx #0: V4L Mailing List linux-media@vger.kernel.org [ 501.352108] em28xx #0: Board eeprom hash is 0x [ 501.352113] em28xx #0: Board i2c devicelist hash is 0x1b800080 [ 501.352119] em28xx #0: Here is a list of valid choices for the card=n insmod option: [ 501.352127] em28xx #0: card=0 - Unknown EM2800 video grabber [ 501.352134] em28xx #0: card=1 - Unknown EM2750/28xx video grabber [ 501.352140] em28xx #0: card=2 - Terratec Cinergy 250 USB [ 501.352145] em28xx #0: card=3 - Pinnacle PCTV USB 2 [ 501.352151] em28xx #0: card=4 - Hauppauge WinTV USB 2 [ 501.352156] em28xx #0: card=5 - MSI VOX USB 2.0 [ 501.352161] em28xx #0: card=6 - Terratec Cinergy 200 USB [ 501.352167] em28xx #0: card=7 - Leadtek Winfast USB II [ 501.352172] em28xx #0: card=8 - Kworld USB2800 [ 501.352178] em28xx #0: card=9 - Pinnacle Dazzle DVC 90/100/101/107 / Kaiser Baas Video to DVD maker / Kworld DVD Maker 2 [ 501.352186] em28xx #0: card=10 - Hauppauge WinTV HVR 900 [ 501.352192] em28xx #0: card=11 - Terratec Hybrid XS [ 501.352197] em28xx #0: card=12 - Kworld PVR TV 2800 RF [ 501.352203] em28xx #0: card=13 - Terratec Prodigy XS [ 501.352208] em28xx #0: card=14 - SIIG AVTuner-PVR / Pixelview Prolink PlayTV USB 2.0 [ 501.352216] em28xx #0: card=15 - V-Gear PocketTV [ 501.352221] em28xx #0: card=16 - Hauppauge WinTV HVR 950 [ 501.352226] em28xx #0: card=17 - Pinnacle PCTV HD Pro Stick [ 501.352232] em28xx #0: card=18 - Hauppauge WinTV HVR 900 (R2) [ 501.352238] em28xx #0: card=19 - EM2860/SAA711X Reference Design [ 501.352244] em28xx #0: card=20 - AMD ATI TV Wonder HD 600 [ 501.352250] em28xx #0: card=21 - eMPIA Technology, Inc. GrabBeeX + Video Encoder [ 501.352257] em28xx #0: card=22 - EM2710/EM2750/EM2751 webcam grabber [ 501.352263] em28xx #0: card=23 - Huaqi DLCW-130 [ 501.352268] em28xx #0: card=24 - D-Link DUB-T210 TV Tuner [ 501.352273] em28xx #0: card=25 - Gadmei UTV310 [ 501.352279] em28xx #0: card=26 - Hercules Smart TV USB 2.0 [ 501.352284] em28xx #0: card=27 - Pinnacle PCTV USB 2 (Philips FM1216ME) [ 501.352291] em28xx #0: card=28 - Leadtek Winfast USB II Deluxe [ 501.352297] em28xx #0: card=29 - NULL [ 501.352302] em28xx #0: card=30 - Videology 20K14XUSB USB2.0 [ 501.352307] em28xx #0: card=31 - Usbgear VD204v9 [ 501.352313] em28xx #0: card=32 - Supercomp USB 2.0 TV [ 501.352318] em28xx #0: card=33 - NULL [ 501.352323] em28xx #0: card=34 - Terratec Cinergy A Hybrid XS [ 501.352329] em28xx #0: card=35 - Typhoon DVD Maker [ 501.352334] em28xx #0: card=36 - NetGMBH Cam [ 501.352339] em28xx #0: card=37 - Gadmei UTV330 [ 501.352344] em28xx #0: card=38 - Yakumo MovieMixer [ 501.352350] em28xx #0: card=39 - KWorld PVRTV 300U [ 501.352355] em28xx #0: card=40 - Plextor ConvertX PX-TV100U [ 501.352361] em28xx #0: card=41 - Kworld 350 U DVB-T [ 501.352366] em28xx #0: card=42 - Kworld 355 U DVB-T [ 501.352371] em28xx #0: card=43 - Terratec Cinergy T XS [ 501.352377] em28xx #0: card=44 - Terratec Cinergy T XS (MT2060) [ 501.352382] em28xx #0: card=45 - Pinnacle PCTV DVB-T [ 501.352388] em28xx #0: card=46 - Compro, VideoMate U3 [ 501.352393] em28xx #0: card=47 - KWorld DVB-T 305U [ 501.352398] em28xx #0: card=48 - KWorld DVB-T 310U [ 501.352404] em28xx #0: card=49 - MSI DigiVox A/D [ 501.352409] em28xx #0: card=50 - MSI DigiVox A/D II [ 501.352414] em28xx #0: card=51 - Terratec Hybrid XS Secam [ 501.352420] em28xx #0: card=52 - DNT DA2 Hybrid [ 501.352425] em28xx #0: card=53 - Pinnacle Hybrid Pro [ 501.352430] em28xx #0: card=54 - Kworld VS-DVB-T 323UR [ 501.352436] em28xx #0: card=55 - Terratec Hybrid XS (em2882) [ 501.352442] em28xx #0: card=56 - Pinnacle Hybrid Pro (2) [ 501.352448] em28xx #0: card=57 - Kworld PlusTV HD Hybrid 330 [ 501.352454] em28xx #0: card=58 - Compro
Re: [PATCH 0/7] kfifo: new API v0.6
One thing is that the new API is not compatible with the old one. I had a look at the current user of the old kfifo API and it is was easy to adapt it to the new API. These are the files which currently use the kfifo API: drivers/char/nozomi.c drivers/char/sonypi.c drivers/infiniband/hw/cxgb3/cxio_resource.c drivers/media/video/meye.c drivers/net/wireless/libertas/main.c drivers/platform/x86/fujitsu-laptop.c drivers/platform/x86/sony-laptop.c drivers/scsi/libiscsi.c drivers/scsi/libiscsi_tcp.c drivers/scsi/libsrp.c drivers/usb/host/fhci.h net/dccp/probe.c drivers/usb/serial/usb-serial.c drivers/usb/serial/generic.c Here's a V4L-DVB cx23885 module change, that is on its way upstream, that uses kfifo as is: http://linuxtv.org/hg/v4l-dvb/rev/a2d8d3d88c6d Do you really have to break the old API? 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
Probelms to tune pci dvb-s card
Hello All, I spent the last 4 days reading mailing lists and testing stuff in my Mythbuntu installation. I have a x86 machine running the latest Mythbuntu version, attached a DM1105 PCI DVB-S card. I read other trails from people having different kind of problems to tune or lock a freq on this card... I am having similar problems, I try to tune to well known and tested frequesncies and S Rates, with out luck This is what I get tuninmg to a tested freq, there is an unencrypted channel on this tp: *** mas...@main:~/DVB$ dvbtune -f 12092000 -s 2 -p H Using DVB card ST STV0299 DVB-S tuning DVB-S to L-Band:0, Pol:H Srate=2000, 22kHz=off ERROR setting tone : Connection timed out polling Getting frontend event FE_STATUS: polling Getting frontend event FE_STATUS: FE_HAS_SIGNAL polling polling polling polling *** In a different terminal, I ran dvbsnoop to check parameters, and here what I get: *** mas...@main:~/DVB$ dvbsnoop -s feinfo dvbsnoop V1.4.50 -- http://dvbsnoop.sourceforge.net/ - FrontEnd Info... - Device: /dev/dvb/adapter0/frontend0 Basic capabilities: Name: ST STV0299 DVB-S Frontend-type: QPSK (DVB-S) Frequency (min): 950.000 MHz Frequency (max): 2150.000 MHz Frequency stepsiz: 0.125 MHz Frequency tolerance: 0.000 MHz Symbol rate (min): 1.00 MSym/s Symbol rate (max): 45.00 MSym/s Symbol rate tolerance: 500 ppm Notifier delay: 0 ms Frontend capabilities: auto inversion FEC 1/2 FEC 2/3 FEC 3/4 FEC 5/6 FEC 7/8 FEC AUTO QPSK Current parameters: Frequency: 1492.000 MHz Inversion: ON Symbol rate: 37.334000 MSym/s FEC: FEC 2/3 * Looks like the frequency parameter set by dvbtune are not taken by the card. I also tested with szap, with well known freq,SR, VPID, etc, with the same result, nothing appears in /dev/dvb/adapter0/dvr0 Any ideas about what to test is highly appreacited Greetings from Ecuador... -- 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 0/7] kfifo: new API v0.6
Em Wed, 28 Oct 2009 04:20:49 +0100 Andi Kleen a...@firstfloor.org escreveu: With respect to the kfifo series of patches: Acked-by: Mauro Carvalho Chehab mche...@redhat.com Here's a V4L-DVB cx23885 module change, that is on its way upstream, that uses kfifo as is: http://linuxtv.org/hg/v4l-dvb/rev/a2d8d3d88c6d Do you really have to break the old API? That was extensively discussed in the original patch kit submission, and yes there are good reasons. You will just have to adapt the driver if it gets in after the new kfifo patches; if kfifo gets in later it'll have to adapt it. I agree. The current kfifo implementation is very limited that can't be used on several places. Changing its implementation to be generic enough requires changing the API, since, on several places, we don't want to have a spinlock. So, as we'll need to change the API anyway, better to do it at the right way. That's said, i7core_edac will also need the new kfifo API for 2.6.33, so I'll have to handle this upstream change anyway. So, the faster this change went into upstream, the better, since I'll hold my pull requests to happen after it. Since I'll have 2 -git trees depending on this change (i7core_edac and v4l-dvb), the better is if you could put the kfifo code on a git tree that won't be rebased. This way, we can make our trees based on kfifo -git tree, having everything rebased there to avoid any merge or bisect conflict (in my case, cx23885 will need to be rebased, and i7core_edac will need kfifo -git objects for a new NMI-aware fifo implementation using kfifo) 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: Hauppage HVR-2250 Tuning problems
I do have 2 2-way splitters between the card in the wall. I tried hooking the card straight to the cable outlet on the wall and ran some more tests. It's a little difficult, because there's only one cable outlet in my whole apartment, and it means doing some re-arranging and being offline while I'm running the tests. I'm not sure if there was any change. Here's the output from azap for a few channels. I added one in the 40 range, like you asked, and I also added another frequency that my TV is able tune, 71700. $ azap -r c112 using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' tuning to 72300 Hz video pid 0x0120, audio pid 0x0121 status 00 | signal | snr | ber | unc | status 00 | signal | snr | ber | unc | status 00 | signal | snr | ber | unc | status 1f | signal 0110 | snr 0113 | ber | unc | FE_HAS_LOCK status 00 | signal 0110 | snr | ber | unc | status 00 | signal 0110 | snr | ber | unc | status 00 | signal | snr | ber | unc | status 00 | signal | snr | ber | unc | status 00 | signal | snr | ber | unc | status 07 | signal 0190 | snr 0190 | ber | unc | status 00 | signal 0190 | snr 0190 | ber | unc | status 00 | signal 0190 | snr 0190 | ber | unc | status 07 | signal 0190 | snr 0190 | ber | unc | status 00 | signal 0190 | snr 0190 | ber | unc | status 00 | signal 0190 | snr 0190 | ber | unc | status 00 | signal 0190 | snr 0190 | ber | unc | status 00 | signal 0190 | snr 0190 | ber | unc | status 00 | signal 0190 | snr 0190 | ber | unc | status 00 | signal 0190 | snr 0190 | ber | unc | status 00 | signal 0190 | snr 0190 | ber | unc | status 00 | signal 0190 | snr 0190 | ber | unc | status 00 | signal | snr 0190 | ber | unc | status 07 | signal 0190 | snr 0190 | ber | unc | status 07 | signal 0190 | snr 0190 | ber | unc | status 07 | signal 0190 | snr 0190 | ber | unc | status 00 | signal 0190 | snr 0190 | ber | unc | status 00 | signal 0190 | snr 0190 | ber | unc | status 00 | signal 0190 | snr 0190 | ber | unc | status 00 | signal 0190 | snr 0190 | ber | unc | status 00 | signal | snr 0190 | ber | unc | status 00 | signal | snr 0190 | ber | unc | status 07 | signal 0190 | snr 0190 | ber | unc | status 00 | signal 0190 | snr 0190 | ber | unc | status 00 | signal 0190 | snr 0190 | ber | unc | status 00 | signal 0190 | snr 0190 | ber | unc | status 00 | signal 0190 | snr 0190 | ber | unc | $ azap -r c45 using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' tuning to 41700 Hz video pid 0x0120, audio pid 0x0121 status 00 | signal | snr | ber | unc | status 00 | signal | snr | ber | unc | status 00 | signal | snr | ber | unc | status 00 | signal | snr | ber | unc | status 1f | signal 0121 | snr | ber | unc | FE_HAS_LOCK status 1f | signal 0190 | snr 0190 | ber | unc | FE_HAS_LOCK status 00 | signal 0190 | snr 0190 | ber | unc | status 00 | signal 0190 | snr 0190 | ber | unc | status 00 | signal 0190 | snr 0190 | ber | unc | status 00 | signal 0190 | snr 0190 | ber | unc | status 00 | signal 0190 | snr 0190 | ber | unc | status 00 | signal 0190 | snr | ber | unc | status 00 | signal 0190 | snr | ber | unc | status 00 | signal 0190 | snr | ber | unc | status 00 | signal 0190 | snr | ber | unc | status 00 | signal 0190 | snr | ber | unc | status 00 | signal | snr | ber | unc | status 00 | signal | snr | ber | unc | status 00 | signal | snr | ber | unc | status 00 | signal | snr | ber | unc | status 00 | signal | snr | ber | unc | status 00 | signal | snr | ber | unc | status 00 | signal | snr | ber | unc | status 00 | signal | snr | ber | unc | status 07 | signal 0190 | snr 0190 | ber | unc | status 00 | signal 0190 | snr 0190 | ber | unc |
