Re: [PULL] http://www.kernellabs.com/hg/~stoth/cx23885-mpx
On 7/31/10 2:28 PM, Andy Walls wrote:
On Sat, 2010-07-31 at 12:31 -0400, Steven Toth wrote:
Mauro,
Please pull from http://www.kernellabs.com/hg/~stoth/cx23885-mpx
A pretty large patch set which adds a number of important features to
the cx23885 driver.
I have a few cx25840 related comments:
1. Please don't abuse CX25840_AUDIOn and make it mean something other
than its current usage of specifying which input the SIF audio is coming
in on. The cx25840 module has enough confusion in it already. Let's
not overload the current enumerations.
Also the current cx25840 keys off of CX25840_AUDIOn vs
CX25840_AUDIO_SERIAL to set up a number of things: sample rate
convertors and the Baseband Path 1 routing for the CX23885 family at
least.
It would be better to add new enumaerated values for CX23885_AUDIO_LR1,
or whatever, to achieve your desired audio input configuration tasks.
Noted. Thanks for the feedback Andy.
2. The raw VBI startup you added in the cx25840 module is not going to
serve you well. It is true that it is harmless to existing
non-CX2388[578] boards. However, any app action that causes
cx25840_std_setup() to be called will change register 0x474 to probably
something you are not expecting.
It's held up very well in testing. With ntsc-zv-vbi and mencoder I'm not seeing
any issues. It could be that the API sequence is working in the customer favor
but non-the-less I don't have any open bugs against VBI.
It should be made clear that VBI never previous worked on the cx23885, for any
cards.
It would be better for you, in the long run, to fix up
cx25840_std_setup() and cx25840_s_raw_fmt() to suit your needs, rather
than a one off setting in the init function..
(I will admit the setup of the vblank, voffset, etc. in the cx25840 is
not trivial, due to the way the ivtv driver likes to capture raw vbi
lines and sliced vbi as if it were raw vbi data. I puzzled most of it
out and fixed it up in the cx18 driver to be more sensible. It took a
bit of staring at the BT878 data sheet to figure out the timing of the
VBI slicer too, since the data is missing from later data sheets.)
Ack. VBI via the cx25840 is a mess generally.
However, the cx25840 driver is close enough to the avcore that doing a
cx23885-avcore.c and largely closing all of the source code from cx25840 is an
exercise in growing the linuxtv tree for little value.
3. This caught my eye:
8 + if (is_cx2388x(state)) {
9 + /* for cx23885 volume doesn't work,
10 + * the calculation always results in
11 + * e4 regardless.
12 + */
13 + cx25840_write(client, 0x8d4, volume);
14 + } else
15 + cx25840_write(client, 0x8d4, 228 - (vol * 2));
Why is the result always 0xe4? Is that what the register always reads
back?
Yes.
Note that your change won't have an intuitive effect, because you
dropped the '-' sign in front of the volume. The user's slider control
will likely work in reverse: up is soft, down is loud.
This is a mistake on my end, although it represents no known regression given
that 0xe4 note and the lact of audio support in the kernel prior to this
patchset for the cx23885.
I can say the V4L2 control to cx25840 volume scale mapping is a little
funny. Here is documentation on the mapping from V4L2 volume control
values to dB to cx25840 register values:
http://linuxtv.org/hg/v4l-dvb/file/9652f85e688a/linux/drivers/media/video/cx18/cx18-alsa-mixer.c#l38
Thanks.
It is non-linear at the bottom end with a reg value of 228 = 0xe4 for
3/16ths of the entire range. This is due to the cx25840 module's desire
to keep volume levels at the same perceptible level between the MSP400
and the CX2584x chips for users with multiple ivtv cards in their
machine. (Yet another ivtv legacy.)
You ought to look at what values are coming from the V4L2 volume control
slider and see what's wrong. A V4L2 volume control value in the range
0xee00-0xeeff should correspond to 0 dB gain.
It's been a while but form memory I added debug to the function and passed the
volume control and found the register values (and calculations to be way off),
certainly not what I expected. I figured this was an issue outside of the realm
of the cx23885 and thus isolated my change to the cx23885 only, not effecting
any other products.
Regards,
- 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
[PULL] http://kernellabs.com/hg/~stoth/saa7164-v4l
Mauro, Analog Encoder and VBI support in the SAA7164 tree, for the HVR2200 and HVR2250 cards. Please pull from http://www.kernellabs.com/hg/~stoth/saa7164-v4l - saa7164: basic definitions for -encoder.c - saa7164: Add some encoder firmwares message types and structs - saa7164: convert buffering structs to be more generic - saa7164: add various encoder message functions - saa7164: Implement encoder irq handling in a deferred work queue. - saa7164: command dequeue fixup to clean the bus after error. - saa7164: allow the encoder GOP structure to be configured - saa7164: generate a fixed kernel warning if the irq is 'late' - saa7164: add support for encoder CBR and VBR optionally. - saa7164: allow the IBP reference distance to be configurable - saa7164: implement encoder peak bitrate feature - saa7164: allow encoder output format to be user configurable - saa7164: allow variable length GOP sizes and switch encoder default to CBR - saa7164: patches to monitor TS payload for inconsistencies - saa7164: allow the number of encoder buffers to be user configurable - saa7164: measure via histograms various irq and queue latencies - saa7164: add guard bytes around critical buffers to detect failure. - saa7164: buffer crc checks and ensure we use the correct PCIe IO memcpy func - saa7164: adjust the PS pack size handling to fill buffers 100% - saa7164: Implement resolution control firmware command - saa7164: mundane buffer debugging changes to track issues - saa7164: irqhandler cleanup and helper function added - saa7164: code cleanup - saa7164: allow DMA engin buffers to vary in size between analog and digital - saa7164: New firmware changes, new size, new filename - saa7164: Avoid spurious error after firmware starts - saa7164: rename a structure for readability - saa7164: add NTSC VBI support - saa7164: add firmware debug message collection and procfs changes - saa7164: VBI irq cleanup and V4L VBI raw pitch adjustments - saa7164: Monitor the command bus and check for inconsistencies - saa7164: enforce the march 10th firmware is used. - saa7164: collect/show the firmware debugging via a thread - saa7164: monitor the RISC cpu load via a thread - saa7164: video_is_registered() func change - saa7164: change debug to saa_debug - saa7164: Add missing saa7164-vbi.c file. - saa7164: fix vbi compiler warnings - saa7164: if 0/1 cleanups b/linux/drivers/media/video/saa7164/saa7164-encoder.c | 23 b/linux/drivers/media/video/saa7164/saa7164-vbi.c | 1459 ++ linux/drivers/media/video/saa7164/Makefile|4 linux/drivers/media/video/saa7164/saa7164-api.c | 1143 - linux/drivers/media/video/saa7164/saa7164-buffer.c| 204 linux/drivers/media/video/saa7164/saa7164-bus.c | 231 - linux/drivers/media/video/saa7164/saa7164-cards.c | 56 linux/drivers/media/video/saa7164/saa7164-cmd.c | 21 linux/drivers/media/video/saa7164/saa7164-core.c | 2103 ++ linux/drivers/media/video/saa7164/saa7164-dvb.c | 109 linux/drivers/media/video/saa7164/saa7164-encoder.c | 1872 linux/drivers/media/video/saa7164/saa7164-fw.c| 35 linux/drivers/media/video/saa7164/saa7164-i2c.c |2 linux/drivers/media/video/saa7164/saa7164-reg.h | 70 linux/drivers/media/video/saa7164/saa7164-types.h | 183 linux/drivers/media/video/saa7164/saa7164-vbi.c | 53 linux/drivers/media/video/saa7164/saa7164.h | 328 + 17 files changed, 6421 insertions(+), 1475 deletions(-) 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
[PULL] http://www.kernellabs.com/hg/~stoth/cx23885-mpx
Mauro, Please pull from http://www.kernellabs.com/hg/~stoth/cx23885-mpx - cx23885: prepare the cx23885 makefile for alsa support - cx23885: merge mijhail's header changes for alsa - cx23885: ALSA support - cx23885: core changes requireed for ALSA - cx23885: add definitions for HVR1500 to support audio - cx23885: correct the contrast, saturation and hue controls - cx23885: hooks the alsa changes into the video subsystem - cx23885: convert call clients into subdevices - cx23885: replaced spinlock with mutex - cx23885: minor function renaming to ensure uniformity - cx23885: setup the dma mapping for raw audio support - cx23885: mute the audio during channel change - cx23885: add two additional defines to simplify VBI register bitmap handling - cx23885: initial support for VBI with the cx23885 - cx23885: initialize VBI support in the core, add IRQ support, register vbi device - cx23885: minor printk cleanups and device registration - cx25840: enable raw cc processing only for the cx23885 hardware - cx23885: vbi line window adjustments - cx23885: add vbi buffer formatting, window changes and video core changes - cx23885: Ensure the VBI pixel format is established correctly. - cx23885: convert from snd_card_new() to snd_card_create() - cx23885: ensure video is streaming before allowing vbi to stream - cx23885: vbi related codingstyle cleanups - cx23885: removal of VBI and earlier VBI printk debugging - cx23885: removal of redundant code, this is no longer required. - cx23885: remove channel dump diagnostics when a vbi buffer times out. - cx23885: Ensure VBI buffers timeout quickly - bugfix for vbi hangs during streaming. - cx23885: coding style violation cleanups - cx23885: Convert a mutex back to a spinlock - cx23885: Name an internal i2c part and declare a bitfield by name - cx25840: Enable support for non-tuner LR1/LR2 audio inputs - cx23885: Allow the audio mux config to be specified on a per input basis. - cx23885: remove a line of debug - cx23885: Enable audio line in support from the back panel - cx25840: Ensure AUDIO6 and AUDIO7 trigger line-in baseband use. - cx23885: Initial support for the MPX-885 mini-card - cx23885: fixes related to maximum number of inputs and range checking - cx23885: add generic functions for dealing with audio input selection - cx23885: hook the audio selection functions into the main driver - cx23885: v4l2 api compliance, set the audioset field correctly - cx23885: Removed a spurious function cx23885_set_scale(). - cx23885: Avoid stopping the risc engine during buffer timeout. - cx23885: Avoid incorrect error handling and reporting - cx23885: Stop the risc video fifo before reconfiguring it. b/linux/drivers/media/video/cx23885/cx23885-alsa.c | 542 + linux/Documentation/video4linux/CARDLIST.cx23885 |1 linux/drivers/media/video/cx23885/Makefile |2 linux/drivers/media/video/cx23885/cx23885-alsa.c | 28 linux/drivers/media/video/cx23885/cx23885-cards.c | 53 linux/drivers/media/video/cx23885/cx23885-core.c | 127 +- linux/drivers/media/video/cx23885/cx23885-i2c.c|1 linux/drivers/media/video/cx23885/cx23885-reg.h|3 linux/drivers/media/video/cx23885/cx23885-vbi.c| 96 + linux/drivers/media/video/cx23885/cx23885-video.c | 556 ++ linux/drivers/media/video/cx23885/cx23885.h| 65 + linux/drivers/media/video/cx25840/cx25840-audio.c |9 linux/drivers/media/video/cx25840/cx25840-core.c | 21 13 files changed, 1257 insertions(+), 247 deletions(-) A pretty large patch set which adds a number of important features to the cx23885 driver. Some early patches for the HVR1500 with add support for analog audio (very rough, much rework on these). The University of California sponsored work for the HVR1800 and HVR1850 and raw video and raw audio and VBI support. The Belac Group sponsored changes related to the MPX cx23885 8 input design, adding raw video and audio support. Mencoder now works correctly with the raw video and audio portions of the driver. GStreamer now works correctly using the v4l interfaces from the driver, live video and audio viewing are now possible. NTSC-ZZ-VBI now works correctly for RAW VBI decoding (although TVTime still refuses to work correctly - tvtime bug) Regards, - 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
Re: Unknown CX23885 device
On 7/27/10 3:21 PM, Christian Iversen wrote: (please CC, I'm not subscribed yet) Hey Linux-DVB people I'm trying to make an as-of-yet unsupported CX23885 device work in Linux. http://kernellabs.com/hg/~stoth/cx23885-mpx/ Try this and if necessary module option card=29. Any good? - 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
Re: Status of the patches under review at LMML (60 patches)
> == Waiting for Steven Toth review == > > Feb, 6 2010: cx23885: Enable Message Signaled Interrupts(MSI). > http://patchwork.kernel.org/patch/77492 > May, 5 2010: tda10048: fix the uncomplete function tda10048_read_ber > http://patchwork.kernel.org/patch/97058 > May, 6 2010: tda10048: fix bitmask for the transmission mode > http://patchwork.kernel.org/patch/97340 > May, 6 2010: tda10048: clear the uncorrected packet registers when saturated > http://patchwork.kernel.org/patch/97341 > May, 6 2010: dvb_frontend: fix typos in comments and one function > http://patchwork.kernel.org/patch/97343 Mauro, I'm fine with all of these. Signed-off-by: Steven Toth -- 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: buffer management
Now, on each video interrupt, I know which SG list i need to read from. At this stage i do need to copy the buffers associated with each of the SG lists at once. In this scenario, I don't see how videobuf could be used, while I keep getting this feeling that a simple copy_to_user of the entire buffer could do the whole job in a better way, since the buffers themselves are already managed and initialized already. Am I correct in thinking so, or is it that I am overlooking something ? Manu, SAA7164 suffers from this. If you find a solution I'd love to hear it. Regards, - 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
Re: is the list down?
On 6/2/10 1:09 PM, Jed wrote: nope got that, but not getting other people's emails. weird. ;) -- 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] dvb_frontend: fix typos in comments and one function
This and your other two patches are in
http://www.kernellabs.com/hg/~stoth/saa7164-dev
They look good to me.
- Steve
On Thu, May 6, 2010 at 8:30 AM, Guillaume Audirac
wrote:
> Hello,
>
> Trivial patch for typos.
>
>
>
>
>
> Signed-off-by: Guillaume Audirac
> ---
> drivers/media/dvb/dvb-core/dvb_frontend.c | 10 +-
> 1 files changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/media/dvb/dvb-core/dvb_frontend.c
> b/drivers/media/dvb/dvb-core/dvb_frontend.c
> index 55ea260..e12a0f9 100644
> --- a/drivers/media/dvb/dvb-core/dvb_frontend.c
> +++ b/drivers/media/dvb/dvb-core/dvb_frontend.c
> @@ -460,7 +460,7 @@ static void dvb_frontend_swzigzag(struct dvb_frontend
> *fe)
> if ((fepriv->state & FESTATE_SEARCHING_FAST) || (fepriv->state &
> FESTATE_RETUNE)) {
> fepriv->delay = fepriv->min_delay;
>
> - /* peform a tune */
> + /* perform a tune */
> retval = dvb_frontend_swzigzag_autotune(fe,
> fepriv->check_wrapped);
> if (retval < 0) {
> @@ -783,7 +783,7 @@ static int dvb_frontend_start(struct dvb_frontend *fe)
> return 0;
> }
>
> -static void dvb_frontend_get_frequeny_limits(struct dvb_frontend *fe,
> +static void dvb_frontend_get_frequency_limits(struct dvb_frontend *fe,
> u32 *freq_min, u32 *freq_max)
> {
> *freq_min = max(fe->ops.info.frequency_min,
> fe->ops.tuner_ops.info.frequency_min);
> @@ -807,7 +807,7 @@ static int dvb_frontend_check_parameters(struct
> dvb_frontend *fe,
> u32 freq_max;
>
> /* range check: frequency */
> - dvb_frontend_get_frequeny_limits(fe, &freq_min, &freq_max);
> + dvb_frontend_get_frequency_limits(fe, &freq_min, &freq_max);
> if ((freq_min && parms->frequency < freq_min) ||
> (freq_max && parms->frequency > freq_max)) {
> printk(KERN_WARNING "DVB: adapter %i frontend %i frequency %u
> out of
> range (%u..%u)\n",
> @@ -1620,7 +1620,7 @@ static int dvb_frontend_ioctl_legacy(struct inode
> *inode, struct file *file,
> case FE_GET_INFO: {
> struct dvb_frontend_info* info = parg;
> memcpy(info, &fe->ops.info, sizeof(struct dvb_frontend_info));
> - dvb_frontend_get_frequeny_limits(fe, &info->frequency_min,
> &info->frequency_max);
> + dvb_frontend_get_frequency_limits(fe, &info->frequency_min,
> &info->frequency_max);
>
> /* Force the CAN_INVERSION_AUTO bit on. If the frontend doesn't
> * do it, it is done for it. */
> @@ -1719,7 +1719,7 @@ static int dvb_frontend_ioctl_legacy(struct inode
> *inode, struct file *file,
> * (stv0299 for instance) take longer than 8msec to
> * respond to a set_voltage command. Those switches
> * need custom routines to switch properly. For all
> - * other frontends, the following shoule work ok.
> + * other frontends, the following should work ok.
> * Dish network legacy switches (as used by Dish500)
> * are controlled by sending 9-bit command words
> * spaced 8msec apart.
> --
> 1.6.3.3
>
>
> --
> Guillaume
>
> --
> 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
>
--
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: Time to merge support for new HVR-2200?
On 5/7/10 1:23 PM, RoboSK wrote: -sorry, my bad (use reply and dont check target email...) -i im from Europe/PAL system - it is supported ? No. -- 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: Time to merge support for new HVR-2200?
On 5/7/10 12:03 PM, RoboSK wrote: Hi, is supported Analog (PAL) part - or only DVB-T ? re-added the mailing list, don't direct mail. DVB-T or ATSC/QAM depending on where you are. -- 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: Hauppauge HVR-4400
Why'd they have to go & use a completely different architecture, lame. It's just business, get used to it. If you don't like their stuff then buy a different product. Vote with your wallet. That's the power you have as a consumer. -- 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: Time to merge support for new HVR-2200?
On 5/7/10 8:30 AM, Francis Barber wrote: Hello Steven, I was just what your plans are to submit the latest patches from http://www.kernellabs.com/hg/saa7164-stable to the main linuxtv repository? It would be great to have these in the main kernel. Hi Frank. Yeah, I actually have a large number of patches for the HVR22xx and the CX2388x sitting up on kernellabs.com I'm hoping to get these out for pull this weekend. Another dev is also working on the TDA10048 fixes so the plan is to pull these into saa7164-dev, test using a generator and (all being well) promote these into a unified tree. Regards, - 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
Re: Avermedia AverTV Capture HD support
On 5/6/10 9:30 AM, deb wrote: On 05/06/2010 01:50 PM, Omer Uner GUCLU wrote: Hello All, I have AverMedia AverTV Capture HD card. This is a hibrid card. How can I use capture interface in Linux I can help to develop a driver Isn't there a Linux driver for your card on avermedia web site ? Hmm. No idea, have you looked? Do they have a driver? -- 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: Avermedia AverTV Capture HD support
On Thu, May 6, 2010 at 8:44 AM, Omer Uner GUCLU wrote: > Steven, > > I do not know this card is same with you. lspci output is like that. > > 02:00.0 Multimedia video controller: Device 1a0a:6200 (rev 01) Don't remove the mailing list cc, I've added it back. Unless you have the datasheet for the TM6200 PCIe bridge then this cannot happen, last I checked it was not freely available. So, I do not think this is possible. 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] dvb_frontend: fix typos in comments and one function
On Thu, May 6, 2010 at 8:30 AM, Guillaume Audirac wrote: > Hello, > > Trivial patch for typos. Thanks Guillaume. I've had an open TDA10048 bug on my list for quite a while, I think you've already made reference to this in an earlier email. Essentially I'm told my a number of Australian users that the 10048 isn't broad-locking when tuned +- 167Khz away from the carrier, which it should definitely do. If you're in the mood for patching the 10048 and want to find and flip the broad-locking bit then I'd be certainly thrilled to test this. :) 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: Avermedia AverTV Capture HD support
> Hello All, Hi, > I have AverMedia AverTV Capture HD card. This is a hibrid card. How > can I use capture interface in Linux > I can help to develop a driver > Thanks, Assuming I'm thinking about the same card, last I checked the TM6200 PCIe bridge didn't have a freely available public datasheet. Can you help with this? 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: Philips/NXP channel decoders
> I am starting first in diving into the tda10048 driver (DVB-T) to become > familiar with the API. In case you know some existing issues, please > report them to me, I would be glad to investigate and help. > > Last but not least, I don't have any hardware yet, is it blocking to > eventually send patches ? I can test your TDA10048 patches and add sign-off for merge. Looking at the list it appears that you have a few nice cleanups. I'll draw all of these together this weekend and run some tests. 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] tda10048: fix the uncomplete function tda10048_read_ber
> Completes the bit-error-rate read function with the CBER register (before > Viterbi decoder). The returned value is 1e8*actual_ber to be positive. > Also includes some typo mistakes. > > Signed-off-by: Guillaume Audirac Thanks Guillaume, I have a pile of other patches I'm ready to present for merge so I'll pull this into one of my dev trees and present this for merge also of course, I'll test it first! :) Thanks again for working on this. Regards, - 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
Re: Hauppauge HVR-4400
On 5/4/10 10:45 AM, Jed wrote: Oh wow I didn't know Hauppauge had released some new models above the 2200. http://www.hauppauge.co.uk/site/products/prods_hvr_internal.html Is this 4400 exactly the same as the HVR-2200, aside from the demodulator used for it's DVB-S/S2? I hope so, that way work being done on the 2200 can flow onto this! (cept for DVB-S/S2) It's completely different. -- 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: [PULL] http://kernellabs.com/hg/~dheitmueller/ngene2-bullshit
>> That's said, if I understood Devin wrong or if you now have plans to add some >> real code at the new ngene-av and ngene-eeprom files, that's fine for me. >> I'll happily accept a patch that moves that code to another file and enable >> the code to read eeprom and to use the AV part, even if you do it on separate >> patches, inside the same pull request. > > Hmm... this were badly written, partially due to a typo. So let me re-phrase > it: > > If my understanding from Devin's chat were wrong and if you actually have > plans to add some > working code at the new ngene-av and ngene-eeprom files, that's fine for me. > I'll happily accept a patch that moves that code to another file and enable > the code to read eeprom and to use the AV part, even if you do it on separate > patches, inside the same pull request. Correct, we plan to make significant changes to -av and -eeprom files (including the final removal of dead code). Pretty much every file in the ngene driver is getting major rework 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: [PULL] http://kernellabs.com/hg/~dheitmueller/ngene2-bullshit
That said, if getting even trivial changes like moving a few functions around are going to be met with such resistance and come at an enormous cost, it's *very* tempting to just host it locally and not submit it upstream at all. Mauro, It makes no sense to have Kernel Labs work out of tree. Clearly in some cases this makes a lot of short term sense but rarely does this scale long term. I can speak to this from first hand experience. Generally it leads to bit-rot and unhappy developers, unhappy community and unhappy users. We are cleanup up the existing tree and fixing major oops prior to a massive amount of analog work. We've spent the time partitioning the code (like all of the other drivers) into sub-units -video.c, -dvb.c as this simplifies peer-to-peer remote development. It breeds commonality between drivers and eases long-term support for developers familiar with other drivers. The end goal is to show a clear and concise series of patches showing migration from the driver as-is to something much more stable and commercial grade. We can demonstrate a clean implementation and have near-zero development conflicts. I see no failure on our part. I see this as positive and pro-active peer-to-peer remote development practices. In fairness to you, I also understand your comments and they are also valid concerns. We are mindful of your authority and aware of your needs to keep the tree clean and optimal. On balance I think we both want the same end goal. Good code, clean patches, understandable small changes showing slow evolution. I hope you can see a way forward for the ngene tree that doesn't mean we are forced to house it away from linuxtv.org. This would be a great pity and against the spirit of community development. Best, - Steve -- Steven Toth - Kernel Labs http://www.kernellabs.com +1.646.355.8490 -- 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: DNTV Dual Hybrid (7164) PCIe
On 3/11/10 11:47 AM, Jed wrote: Happy to do this, so long as I can get it back eventually? Assuming you want me to continue supporting that product then I generally keep hold of the hardware indefinitely, else 2-3 driver patches from now your card will no longer be regression tested and could stop working. -- 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: DNTV Dual Hybrid (7164) PCIe
On 3/11/10 11:26 AM, Jed wrote: Hi Kernellabs, I'm thinking of getting this: http://forums.dvbowners.com/index.php?showtopic=11720 It seems very similar to the HVR-2200 yet has component-in. Do you reckon your module/s might support it? Thank-you! Highly likely the drivers will not support it. Each card has unique firmware identifiers that need to be added manually to the driver. If you'd like to provide me a card then I'd consider adding support. - Steve -- Steven Toth - Kernel Labs http://www.kernellabs.com +1.646.355.8490 -- 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: Hauppauge WinTV-HVR-2200 - support analog ?
On 3/10/10 2:12 PM, RoboSK wrote: Hi, support "drivers" for linux analog part WinTV-HVR-2200 ? if yes is possible watch/record two analog source at the same time ? 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 No analog support, only DTV. - Steve -- Steven Toth - Kernel Labs http://www.kernellabs.com +1.646.355.8490 -- 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: Hw capabilities of the HVR-2200
On 3/9/10 12:16 PM, Jed wrote: 19/09/09 Jed wrote: 2) Component input for the A/V-in Yes, this exists on the HVR2250 product only. Ah shite, are you sure? If you look at the specs for the reference card it was there, did they take it out at the last minute? It's not feature Hauppauge supports on the HVR2200 today. I have a suspicion this may change but I'm neither confirming, denying or announcing anything. It would make sense to officially support component cables on the HVR2200 since the silicon supports it. If/when it does I'm sure it will be mentioned in the forums or on the HVR2200 product packaging. Hi Steve, when you said this is not a feature Hauppauge supports. Did you mean it's not fully enabled physically in the PCB... Or is it just something they need to add support for in the driver? If the latter do you know if their policy has changed or is about to? No idea, I have no answer. 3) Hw encode bypass for A/V-in No idea. Regardless of whether it does or does not I wouldn't plan to add basic raw TV support to the driver, without going through the encoder. Why do you rule it out unequivocally, is it just because I've annoyed you? :-( Raw analog TV isn't a high priority feature on my mental check-list. Analog TV via the encoder is much more interesting and applicable to many people. Assuming that progress has been made on analogue to h.263/mpeg4/VC-1/DivX/Xvid via the A/V-in encoder. Is this still considered a low priority? Raw analog is still very low down any list I have for the HVR22xx driver. Has progress been made on hw encode via A/V-in? I'm "finally" putting my entire system together soon, can't wait! Looking forward to seeing how everything has progressed. I'll be sure to do some donations once I'm up & running! The current driver supports DTV only. I have no ETA for analog on the HVR22xx driver. If you need analog support then the HVR22xx isn't the right product for you. Regards, -- Steven Toth - Kernel Labs http://www.kernellabs.com +1.646.355.8490 -- 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: cx23885
On 2/15/10 5:56 PM, Michael wrote: Well, this did not work. The cx23885 driver was not included in kernel 2.6.21, so no diff. The diff of the 2.6.21 cx25840 is twice as big as the 2.6.31 diff. :-( If anybody can give me a hint, what to include in a patch and what was old stuff that has jsut changed in 2.6.31, I'd be grateful. Attached is the diff of cx23885, the commell version against kernel 2.6.31.4. I'm downloading kernel 2.6.21 now and make a diff with these drivers. Start by patching the current cx23885 driver with all of the switch statements related to the new board CX23885_BOARD_MPX885. -cards.c -core.c etc. I already see some issues in their MPX885 additions, driving wrong gpios and assuming the encoder is attached - but it's a good start. -- Steven Toth - Kernel Labs http://www.kernellabs.com +1.646.355.8490 -- 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: cx23885
One thing I found pretty fast is that they added in cx23885-card.c: This looks promising. But maybe it is a start. What do you think? I repeat I my original comment below. Feel free to submit patches. ^^^ indeed, good luck. Regards, -- Steven Toth - Kernel Labs http://www.kernellabs.com +1.646.355.8490 -- 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: cx23885
Well if tvtime runs then mplayer will most probably, too. The question is, what means "with some work" :-) If you haven't worked on the cx23885 driver in the past, and you're not accustomed to developing tv/video drivers then you're going to struggle, massively. Not that I'm trying to discourage, on the contrary, the more driver developers the better. In reality this isn't something you can fix with an evenings work. However, if you would like to take a shot then look at the existing support for the HVR1800 board in the cx23885 tree. Specifically look at the raw video support in the cx23885-video.c file and you'll also want to investigate the cx25840 driver for configuring the A/V subsystem. Feel free to submit patches. Regards, - Steve -- Steven Toth - Kernel Labs http://www.kernellabs.com +1.646.355.8490 -- 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: cx23885
On 2/15/10 10:21 AM, Michael wrote: Steven Toth wrote: Is this because the driver does not have the right capabilities or is it "just" a PCI-id missing in the driver? A mixture of both, analog support in the 885 driver is limited. Generally, yes - start by adding the PCI id. So, does this imply that you see a chance to get this card running? :-) If so, I will order one card and try. There is not much I want to do with the card. It should simply digitize an external camera signal. I want to display it with mplayer. It should, however, be reliable and not crash the system or drop the stream or whatever. So far, it seems that this is the only mini-pcie video digitizer card that exists. I would have taken a bttv based one instead, but as there is none... The hardware has no mpeg encoder, so if by digitizer you mean raw high bitrate video frames then yes, and if mplayer is capable of supporting the v4l mmap interfaces then yes. (I've have zero experience of mplayer with raw video - not sure if this works). It feels like a reach, the design looks like a 'same-old' cx23885/7/8 which you could potentially use in tvtime - with some work. -- Steven Toth - Kernel Labs http://www.kernellabs.com +1.646.355.8490 -- 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: cx23885
On 2/15/10 8:15 AM, Michael wrote: Hi Andy Does anybody know whether this card is currently supported Likely no. I have not checked the source to be sure. Is this because the driver does not have the right capabilities or is it "just" a PCI-id missing in the driver? A mixture of both, analog support in the 885 driver is limited. Generally, yes - start by adding the PCI id. The latter would be quite easy to add, I guess. and if yes, is it by cx88 or by cx23885? http://www.commell.com.tw/Product/Surveillance/MPX-885.htm It is based on the Connexant 23885 chip but uses an Mini-PCIe interface. cx88 handles PCI bridge chips: CX2388[0123] cx23885 handles PCIe bridge chips: CX2388[578] > From the picture of the card from the datasheet it has a CX23885 chip. That means, if a driver might support it, then the cx23885 driver not the cx88, correct? Correct. -- Steven Toth - Kernel Labs http://www.kernellabs.com +1.646.355.8490 -- 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: New Hauppauge HVR-2200 Revision?
>> Anyway, apart from the problems noted above it is fine. I'm not sure what >> the criteria is for merging support for this card into the main repository, >> but I would view it as worthy of merging even with these problems >> outstanding. >> >> Many thanks, >> Frank. >> > Interestingly, so far it only seems to affect the second adapter. The first > one is still working. > Odd. Francis, I find the whole ber/unc values puzzling, essentially they shouldn't happen assuming a good clean DVB-T signal. I'm going to look into this very shortly, along with a broad locking feature I want to change in the demod. I've had one or two other people comment on the -stable tree and in general they're pretty happy, including myself, which means that I'll be generating a pull request to have these changes merged very shortly (1-2 weeks). Regards, - 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
Re: New Hauppauge HVR-2200 Revision?
I was also wondering if it might help to use the latest firmware? I got the drivers from here http://www.hauppauge.com/site/support/support_hvr2250.html. Looking at your extract script, it is trivial to get the saa7164 firmware but I've no idea how you calculated the offsets tda10048 firmware. Would you have any pointers on this? I've been testing new saa7164 firmware recently and I'm ok with it, I plan to push those changes into saa7164-stable in the next few days. TDA10048 firmware rev'ing - I haven't yet looked at, although it's on my todo list. Anyway, apart from the problems noted above it is fine. I'm not sure what the criteria is for merging support for this card into the main repository, but I would view it as worthy of merging even with these problems outstanding. Many thanks, Frank. Interestingly, so far it only seems to affect the second adapter. The first one is still working. Curious. -- Steven Toth - Kernel Labs http://www.kernellabs.com +1.646.355.8490 -- 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: New Hauppauge HVR-2200 Revision?
http://www.kernellabs.com/blog/?page_id=17 Firmware links from here. - Steve On Sat, Jan 23, 2010 at 7:03 PM, Francis Barber wrote: > On 24/01/2010 7:29 AM, Steven Toth wrote: >> >> I put some new patches into the saa7164-stable earlier today. These >> will probably help. >> >> www.kernellabs.com/hg/saa7164-stable >> >> Let me know. >> >> Regards, >> >> - Steve >> >> > > Thanks, I will give this a try later today. > > Presumably I should use the firmware from version 7.6.27.27323 (although > there doesn't seem to be any firmware corresponding to dvb-fe-tda10048 with > this download)? > > Regards, > Frank. > -- 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: New Hauppauge HVR-2200 Revision?
I put some new patches into the saa7164-stable earlier today. These will probably help. www.kernellabs.com/hg/saa7164-stable Let me know. Regards, - Steve -- Steven Toth - Kernel Labs http://www.kernellabs.com On Sat, Jan 23, 2010 at 6:17 PM, Francis Barber wrote: > On 23/01/2010 11:00 PM, Steven Toth wrote: >>> >>> I'm a confused by 8940 because this isn't listed in the hcw89.inf file on >>> the CD that shipped with the product (driver version 7.6.1.27118). They >>> list 8900, 8901, 8980, 8991, 8993, 89A0, and 89A1. I downloaded the >>> latest >>> drivers from the website (7.6.27.27223) and this adds 8951 and 8953, but >>> still not 8940. >>> >>> The firmware shipped with 7.6.1.27118 is the same as is available on your >>> website, although they have updated it for 7.6.27.27223. >>> >> >> >>> >>> If there is any other information that would be helpful please let me >>> know. >>> >> >> Does this actually work under windows? It sounds like the driver >> doesn't support it? >> >> Regards, >> >> > > As expected, the card didn't work in Windows with either of those driver > versions. However, hauppauge.com has different drivers to hauppauge.co.uk! > The latest HVR2250 drivers from hauppauge.com, version 7.6.27.27323, > include 8940 in the inf file. This version installs fine on Windows. > > Regards, > Frank. > -- 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: New Hauppauge HVR-2200 Revision?
> I'm a confused by 8940 because this isn't listed in the hcw89.inf file on > the CD that shipped with the product (driver version 7.6.1.27118). They > list 8900, 8901, 8980, 8991, 8993, 89A0, and 89A1. I downloaded the latest > drivers from the website (7.6.27.27223) and this adds 8951 and 8953, but > still not 8940. > > The firmware shipped with 7.6.1.27118 is the same as is available on your > website, although they have updated it for 7.6.27.27223. > If there is any other information that would be helpful please let me know. Does this actually work under windows? It sounds like the driver doesn't support it? 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] cx23885: Wrong command printed in cmd_to_str()
Thanks Roel. Acked-By: Steven Toth - Steve -- Steven Toth - Kernel Labs http://www.kernellabs.com On Tue, Jan 19, 2010 at 7:47 PM, Roel Kluin wrote: > The wrong command was printed for case CX2341X_ENC_SET_DNR_FILTER_MODE, > and a typo in case CX2341X_ENC_SET_PCR_ID. > > Signed-off-by: Roel Kluin > --- > Or is this intended? > > diff --git a/drivers/media/video/cx23885/cx23885-417.c > b/drivers/media/video/cx23885/cx23885-417.c > index 88c0d24..2ab97ad 100644 > --- a/drivers/media/video/cx23885/cx23885-417.c > +++ b/drivers/media/video/cx23885/cx23885-417.c > @@ -681,7 +681,7 @@ static char *cmd_to_str(int cmd) > case CX2341X_ENC_SET_VIDEO_ID: > return "SET_VIDEO_ID"; > case CX2341X_ENC_SET_PCR_ID: > - return "SET_PCR_PID"; > + return "SET_PCR_ID"; > case CX2341X_ENC_SET_FRAME_RATE: > return "SET_FRAME_RATE"; > case CX2341X_ENC_SET_FRAME_SIZE: > @@ -693,7 +693,7 @@ static char *cmd_to_str(int cmd) > case CX2341X_ENC_SET_ASPECT_RATIO: > return "SET_ASPECT_RATIO"; > case CX2341X_ENC_SET_DNR_FILTER_MODE: > - return "SET_DNR_FILTER_PROPS"; > + return "SET_DNR_FILTER_MODE"; > case CX2341X_ENC_SET_DNR_FILTER_PROPS: > return "SET_DNR_FILTER_PROPS"; > case CX2341X_ENC_SET_CORING_LEVELS: > -- > 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 > -- 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: CI USB
> BTW, Hauppauge's WinTV-CI looked much more promissing. > At least when I started reading whole thread about it here: > http://www.mail-archive.com/linux-...@linuxtv.org/msg28113.html > > Unfortunatelly, last Steve's note about not getting anything > (even any answer) has disappointed me fully. And because > google is quiet about any progress on it I pressume > no any docu nor driver was released later on. The whole project went badly wrong when the hardware vendor promised documentation then failed to deliver. My mistake for trusting them in the first place. I had considered running a driver reverse engineering tutorial project via kernellabs.com. Perhaps a 4 part series of writings, tools and instructions that describe how to reverse engineer USB drivers and culminates in a working skeleton driver for the WinTV CI that could be used. I doubt I could make this happen without a project sponsor so if you know any companies that would be willing to sponsor a project like this then I'd certainly be interested in helping. 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: [linux-dvb] Hauppauge PVR-150 Vertical sync issue?
> So it looks like the problem is restricted to my mythbuntu box. Congrats, that's better news. -- 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: scan/scan-s2 doesn't tune, but dvbtune does?
On Fri, Dec 18, 2009 at 2:23 PM, Michael Akey wrote: > Steven Toth wrote: >> >> On Tue, Dec 15, 2009 at 4:53 AM, Lou Otway >> wrote: >> >>> >>> Michael Akey wrote: >>> >>>> >>>> I can't get the scan/scan-s2 utilities to lock any transponders (DVB-S). >>>> My test satellite is AMC1 103W, the Pentagon Channel tp. This is >>>> probably >>>> some simple user error on my part, but I can't figure it out. I have a >>>> Corotor II with polarity changed via serial command to an external IRD. >>>> C/Ku is switched by 22KHz tone, voltage is always 18V. Ku is with tone >>>> off, C with tone on. Speaking of which, is there a way to manually set >>>> the >>>> tone from the arguments on the scan utilities? >>>> >>>> Here's what I've tried and the results: >>>> >>>> $ ./scan-s2 -a 0 -v -o zap -l 10750 INIT >>>> API major 5, minor 0 >>>> scanning INIT >>>> using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' >>>> initial transponder DVB-S 1210 H 2000 AUTO AUTO AUTO >>>> initial transponder DVB-S2 1210 H 2000 AUTO AUTO AUTO >>>> --> Using DVB-S >>>> >>>>>>> >>>>>>> tune to: 12100:h:0:2 >>>>>>> >>>> >>>> DVB-S IF freq is 135 >>>> >>>>>>> >>>>>>> tuning status == 0x03 >>>>>>> tuning status == 0x01 >>>>>>> tuning status == 0x03 >>>>>>> tuning status == 0x01 >>>>>>> tuning status == 0x03 >>>>>>> tuning status == 0x00 >>>>>>> tuning status == 0x01 >>>>>>> tuning status == 0x03 >>>>>>> tuning status == 0x00 >>>>>>> tuning status == 0x00 >>>>>>> >>>> >>>> WARNING: >>> tuning failed!!! >>>> >>>>>>> >>>>>>> tune to: 12100:h:0:2 (tuning failed) >>>>>>> >>>> >>>> DVB-S IF freq is 135 >>>> >>>>>>> >>>>>>> tuning status == 0x03 >>>>>>> tuning status == 0x01 >>>>>>> tuning status == 0x00 >>>>>>> tuning status == 0x00 >>>>>>> >>>> >>>> ...snip... >>>> >>>> Same thing happens if I use just 'scan' and not 'scan-s2.' >>>> >>>> If I use dvbtune, it works though.. >>>> >>>> $ dvbtune -f 135 -p H -s 2 -c 0 -tone 0 -m >>>> Using DVB card "Conexant CX24116/CX24118" >>>> tuning DVB-S to L-Band:0, Pol:H Srate=2000, 22kHz=off >>>> polling >>>> Getting frontend event >>>> FE_STATUS: >>>> polling >>>> Getting frontend event >>>> FE_STATUS: FE_HAS_SIGNAL FE_HAS_LOCK FE_HAS_CARRIER FE_HAS_VITERBI >>>> FE_HAS_SYNC >>>> Bit error rate: 0 >>>> Signal strength: 51648 >>>> SNR: 26215 >>>> FE_STATUS: FE_HAS_SIGNAL FE_HAS_LOCK FE_HAS_CARRIER FE_HAS_VITERBI >>>> FE_HAS_SYNC >>>> Signal=51648, Verror=0, SNR=26215dB, BlockErrors=0, (S|L|C|V|SY|) >>>> Signal=51776, Verror=0, SNR=26624dB, BlockErrors=0, (S|L|C|V|SY|) >>>> >>>> The tuning file 'INIT' contains only the following line: >>>> S 1210 H 2000 AUTO >>>> >>>> I'm using v4l-dvb drivers from the main repo as of about a week ago. I >>>> am >>>> running kernel 2.6.32 on Debian testing. Any help is appreciated ..and >>>> hopefully it's just a simple flub on my part! >>>> >>>> --Mike >>>> >>> >>> Try using a non-auto FEC and rolloff. >>> >>> Some devices won't accept auto for these parameters. >>> >> >> Michael, >> >> The silicon in question doesn't do automatic FEC detection. Be sure to >> specify which FEC you need for the sat. If in doubt, walk through them >> all manually. Pilot auto detect is done in s/w was was added a long >> time ago. >> >> - Steve >> >> > > Steve et al, > > It would appear that it does in fact do auto FEC since I don't specify it > with dvbtune and it works just fine (with both my Prof 7300 and 7301.) I > think it's a tone issue, but then again, why does attempting to scan > something on both bands C and Ku (tone on, and tone off respectively) not > work? I figured if it's a tone issue that only one band would work. > > I tried setting the FEC and even the delivery system (S1 rather than S) and > it makes no difference. I could try the DVB-S2 NBC mux on that satellite > too.. but I'm not sure why that would make a difference. > > If you folks have any other ideas, let me know. Thanks for your responses > so far! It doesn't do auto FEC in S2 mode, only S mode. -- 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: scan/scan-s2 doesn't tune, but dvbtune does?
On Tue, Dec 15, 2009 at 4:53 AM, Lou Otway wrote: > > > Michael Akey wrote: >> >> I can't get the scan/scan-s2 utilities to lock any transponders (DVB-S). >> My test satellite is AMC1 103W, the Pentagon Channel tp. This is probably >> some simple user error on my part, but I can't figure it out. I have a >> Corotor II with polarity changed via serial command to an external IRD. >> C/Ku is switched by 22KHz tone, voltage is always 18V. Ku is with tone >> off, C with tone on. Speaking of which, is there a way to manually set the >> tone from the arguments on the scan utilities? >> >> Here's what I've tried and the results: >> >> $ ./scan-s2 -a 0 -v -o zap -l 10750 INIT >> API major 5, minor 0 >> scanning INIT >> using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' >> initial transponder DVB-S 1210 H 2000 AUTO AUTO AUTO >> initial transponder DVB-S2 1210 H 2000 AUTO AUTO AUTO >> --> Using DVB-S >> >>> tune to: 12100:h:0:2 >> DVB-S IF freq is 135 >> >>> tuning status == 0x03 >> >>> tuning status == 0x01 >> >>> tuning status == 0x03 >> >>> tuning status == 0x01 >> >>> tuning status == 0x03 >> >>> tuning status == 0x00 >> >>> tuning status == 0x01 >> >>> tuning status == 0x03 >> >>> tuning status == 0x00 >> >>> tuning status == 0x00 >> WARNING: >>> tuning failed!!! >> >>> tune to: 12100:h:0:2 (tuning failed) >> DVB-S IF freq is 135 >> >>> tuning status == 0x03 >> >>> tuning status == 0x01 >> >>> tuning status == 0x00 >> >>> tuning status == 0x00 >> ...snip... >> >> Same thing happens if I use just 'scan' and not 'scan-s2.' >> >> If I use dvbtune, it works though.. >> >> $ dvbtune -f 135 -p H -s 2 -c 0 -tone 0 -m >> Using DVB card "Conexant CX24116/CX24118" >> tuning DVB-S to L-Band:0, Pol:H Srate=2000, 22kHz=off >> polling >> Getting frontend event >> FE_STATUS: >> polling >> Getting frontend event >> FE_STATUS: FE_HAS_SIGNAL FE_HAS_LOCK FE_HAS_CARRIER FE_HAS_VITERBI >> FE_HAS_SYNC >> Bit error rate: 0 >> Signal strength: 51648 >> SNR: 26215 >> FE_STATUS: FE_HAS_SIGNAL FE_HAS_LOCK FE_HAS_CARRIER FE_HAS_VITERBI >> FE_HAS_SYNC >> Signal=51648, Verror=0, SNR=26215dB, BlockErrors=0, (S|L|C|V|SY|) >> Signal=51776, Verror=0, SNR=26624dB, BlockErrors=0, (S|L|C|V|SY|) >> >> The tuning file 'INIT' contains only the following line: >> S 1210 H 2000 AUTO >> >> I'm using v4l-dvb drivers from the main repo as of about a week ago. I am >> running kernel 2.6.32 on Debian testing. Any help is appreciated ..and >> hopefully it's just a simple flub on my part! >> >> --Mike > > Try using a non-auto FEC and rolloff. > > Some devices won't accept auto for these parameters. Michael, The silicon in question doesn't do automatic FEC detection. Be sure to specify which FEC you need for the sat. If in doubt, walk through them all manually. Pilot auto detect is done in s/w was was added a long time ago. - 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
Re: Success for Compro E650F analog television and alsa sound.
On Sun, Dec 6, 2009 at 9:00 PM, Igor M. Liplianin wrote: > Hi Steve > > I'm able to watch now analog television with Compro E650F. > I rich this by merging your cx23885-alsa tree and adding some modifications > for Compro card definition. > Actually, I take it from Mygica definition, only tuner type and DVB port is > different. > Tested with Tvtime. > > tvtime | arecord -D hw:2,0 -r 32000 -c 2 -f S16_LE | aplay - > > My tv card is third for alsa, so parameter -D for arecord is hw:2,0. > SECAM works well also. > I didn't test component input, though it present in my card. Thanks Igor, I'll merge this into the cx23885-alsa tree in the next couple of days. 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: cx25840: GPIO settings wrong for HVR-1850 IR Tx
On Sat, Nov 28, 2009 at 1:35 AM, Andy Walls wrote: > On Fri, 2009-11-27 at 16:11 -0500, Andy Walls wrote: > > >> Steve and Hans, >> >> Any ideas? >> >> I know on the list I had bantered around a configure, enable, set, get >> etc v4l2_subdev ops for gpio, but I can't remember the details nor the >> requirements. >> >> The cx25840 module really needs a way for the cx23885 bridge driver to >> set GPIOs cleanly. > > Nevermind, I've slapped something together at > > http://linuxtv.org/hg/~awalls/cx23885-ir > > for setting up the IO pin multiplexing in the CX23888 A/V core from the > bridge driver. > > It does what I need. Reading GPIOs or setting GPIOs without setting up > the pin config isn't implemented, as I didn't need it. However, it > should be easier to implement that now. Hi Andy, I looked over this today and from the 10,000 ft view I think it's going to work nicely as a replacement for the current HVR1700 workaround and also for the IR pin requirements. Reviewed-by: Steven Toth Regards, - 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
Re: [PATCH/RFC v2] V4L core cleanups HG tree
>>> I can't wait for an explicit ack from all maintainers (mostly because I >>> don't know you all), so I'll send a pull request in a week if there's no >>> blocking issue. I'd like this to get in 2.6.33 if possible. > > I have a pile of testing in the next few days. In light of Devin's > OOPS I'll test the cx88 and cx23885 changes and report back by sunday. > > Thanks for the cleanups Laurent. I'm fine with the cx88 and cx23885 changes. Acked-By: Steven Toth -- 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/RFC v2] V4L core cleanups HG tree
On Wed, Nov 25, 2009 at 11:21 AM, Laurent Pinchart wrote: > Hopefully CC'ing the au0828, cx231xx, cx23885, s2255 and cx25821 maintainers. > > Could you please ack patch http://linuxtv.org/hg/~pinchartl/v4l-dvb- > cleanup/rev/7a762df57149 ? The patch should be committed to v4l-dvb in time > for 2.6.33. > > On Wednesday 18 November 2009 13:54:06 Laurent Pinchart wrote: >> Hi everybody, >> >> the V4L cleanup patches are now available from >> >> http://linuxtv.org/hg/~pinchartl/v4l-dvb-cleanup >> >> The tree will be rebased if needed (or rather dropped and recreated as hg >> doesn't provide a rebase operation), so please don't pull from it yet if >> you don't want to have to throw the patches away manually later. >> >> I've incorporated the comments received so far and went through all the >> patches to spot bugs that could have sneaked in. >> >> Please test the code against the driver(s) you maintain. The changes are >> small, *should* not create any issue, but the usual bug can still sneak in. >> >> I can't wait for an explicit ack from all maintainers (mostly because I >> don't know you all), so I'll send a pull request in a week if there's no >> blocking issue. I'd like this to get in 2.6.33 if possible. I have a pile of testing in the next few days. In light of Devin's OOPS I'll test the cx88 and cx23885 changes and report back by sunday. Thanks for the cleanups Laurent. Regards, - 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
Re: Help needed with Hauppauge WinTV HVR-4000
On Thu, Nov 26, 2009 at 6:12 AM, Alan Ferrero wrote: > Hi! > > I posted yesterday the following message to the mythtv-users mailing > list, but they answered me it's more suitable to post it in your mailing > list. > > Alan > > Hi! > > I REALLY need some help with the Hauppauge WinTV HVR-4000 > (http://www.hauppauge.it/site/products/data_hvr4000.html). > > Days ago I installed Mythbuntu 9.10 (64 bit) on my HTPC, but I soon > found out the tv card didn't work. > Later, I learned that both firmware and driver included in Karmic were > bugged and didn't work. > So I followed the instructions reported at > http://www.linuxtv.org/wiki/index.php/Hauppauge_WinTV-HVR-4000 to > install firmware 1.20.79.0 and instructions reported at > https://bugs.launchpad.net/mythbuntu/+bug/439163?comments=all to install > the patched driver (from: http://hg.kewl.org/v4l-dvb-20091103/). > > The end result? Nothing! > > Unfortunately, my HVR-4000 doesn't work yet! Test it on windows, the hardware could be faulty. -- 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: [linux-dvb] Hauppauge PVR-150 Vertical sync issue?
On Tue, Nov 24, 2009 at 6:43 PM, Andy Walls wrote: > On Tue, 2009-11-24 at 13:05 -0500, Robert Longfield wrote: >> I have a PVR-150 card running on mythbuntu 9 and it appears that my >> card is suffering a vertical (and possibly a horizontal) sync issue. >> >> The video jumps around, shifts from side to side, up and down and when >> it shifts the video wraps. I'm including a link to a screen shot >> showing the vertical sync problem >> >> http://imagebin.ca/view/6fS-14Yi.html > > It looks like you have strong singal reflections in your cable due to > impedance mismatches, a bad splitter, a bad cable or connector, etc. > > Please read: > > http://www.ivtvdriver.org/index.php/Howto:Improve_signal_quality > > and take steps to ensure you've got a good cabling plant in your home. Was it previously working well then went bad? Does the problem occur when using the svideo/composite inputs? Does the problem only occur after the unit has been running for sometime? If the problem repro's under windows call Hauppauge tech support. -- 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: Hauppage HVR-2250 Tuning problems
> Is this useful info? I've got the whole log, and haven't updated the > code yet. I'm willing to do tests, compile other changesets, etc. Hi Ross, Thanks for writing. Do you have an AMD based system? -- 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: Hauppage HVR-2250 Tuning problems
On Fri, Oct 30, 2009 at 2:19 PM, dan wrote: > I sort of hinted that I would like to try that and he didn't seem very > excited about the idea. I think I'll just RMA the card and hope I > have better luck with the replacement. Fair enough. > Thanks again for all your help! You're welcome. - 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
Re: Hauppage HVR-2250 Tuning problems
On Fri, Oct 30, 2009 at 1:43 PM, dan wrote: > Steven, > > I tried adding some 2 way splitters for attenuation. Each one was > -3dB, and I got up to about 5 total, with no change. > > I didn't get a chance to try under windows (for various reasons mostly > related to time and lack of a Windows install CD), but I did get some > evidence that it might be the card. I have a friend at work with the > same card which he has been using without problems for a while now (in > Fedora 10). He took my card home and swapped it for his working card > and it didn't work. He said that he got a message saying that the > card couldn't lock and that he could either try waiting longer or try > another channel. He did both and he still couldn't get a lock. > Unless there is some other reason that you can't just swap two working > HVR-2250s in a working system and have the system still work, I'm > inclined to believe I got a bad one. > > --dan > > > On Wed, Oct 28, 2009 at 8:12 AM, Steven Toth wrote: >> On Wed, Oct 28, 2009 at 10:08 AM, Steven Toth wrote: >>> On Wed, Oct 28, 2009 at 1:44 AM, dan wrote: >>>> 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. >>> >>> Removing splitters proves it's probably not a weak signal issue (also >>> the SNR or 39 on the TV). Can you apply some attenuation to reduce >>> the overall rf strength? I'm thinking it's too hot. >>> >>> Something must be using your second tuner, mythtv maybe? >> >> Oh, and please try the card under windows ideally on the same PC using >> the same antenna feed, to rule out any card specific issues. >> >> -- >> Steven Toth - Kernel Labs >> http://www.kernellabs.com >> > Urgh. It sounds like a card specific problem. Of course, installing your friends card in your system to completely confirm the suspicion would be perfect. 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: Hauppage HVR-2250 Tuning problems
On Wed, Oct 28, 2009 at 10:08 AM, Steven Toth wrote: > On Wed, Oct 28, 2009 at 1:44 AM, dan wrote: >> 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. > > Removing splitters proves it's probably not a weak signal issue (also > the SNR or 39 on the TV). Can you apply some attenuation to reduce > the overall rf strength? I'm thinking it's too hot. > > Something must be using your second tuner, mythtv maybe? Oh, and please try the card under windows ideally on the same PC using the same antenna feed, to rule out any card specific issues. -- 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: Hauppage HVR-2250 Tuning problems
On Wed, Oct 28, 2009 at 1:44 AM, dan wrote: > 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. Removing splitters proves it's probably not a weak signal issue (also the SNR or 39 on the TV). Can you apply some attenuation to reduce the overall rf strength? I'm thinking it's too hot. Something must be using your second tuner, mythtv maybe? -- 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: Hauppage HVR-2250 Tuning problems
On Tue, Oct 27, 2009 at 10:55 AM, dan 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: 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
Re: Hauppage HVR-2250 Tuning problems
>> 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
Re: Details about DVB frontend API
> We did discuss this briefly during the v4l-dvb mini-summit and I know Mike > Krufky knew what to do about this, but for the life of me I can't remember > what it was. I should have made a note of it... > > Mike, can you refresh my memory? You are correct Hans. Mike has some patches that begin to address this for the ATSC products, standardizing some of the unit measurements. Very clean, easy to review and merge. -- 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: Bug in HVR1300. Found part of a patch, if reverted bug seems to be gone
> there seems to be a bug in cx88 (HVR1300) that is responsible for not > switching channels, and not being able to scan. > Complete description can be found on launchpad: Noted. Thanks -- 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: Status of CX25821 PCI-E capture driver
On Fri, Oct 16, 2009 at 8:46 AM, Donald Bailey wrote: > I recently picked up a 16 port DVR card from China which uses two CX25821 > chips. I compiled the staging driver for it and was able to load it > successfully with kernel 2.6.32-rc2. But I can't find any /dev devices to > get at the inputs. I created a character device with a major/minor of 81/0 > but am unable to open it. We're planning to do some work inside KernelLabs on that particular driver. We have access to hardware and are looking to stabilize and improve the overall quality of the driver to a commercial production grade. I don't have any timescales as this is currently and unfunded project but you're not alone, the driver does need some major improvements. 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: Bug in HVR1300. Found part of a patch, if reverted bug seems to be gone [spam-bayes][heur][spf]
On Mon, Oct 12, 2009 at 4:48 PM, Frank Sagurna wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Hi list, > > there seems to be a bug in cx88 (HVR1300) that is responsible for not > switching channels, and not being able to scan. > Complete description can be found on launchpad: > > https://bugs.launchpad.net/mythtv/+bug/439163 (starting from comment #16) > > Anyway, i digged it down to this patch: > http://www.mail-archive.com/linuxtv-comm...@linuxtv.org/msg02195.html > > When reverting the following part of the patch it starts working again: > > snip-- Thanks Frank. I'll pick up this patch and start the merge process. Regards, - Steve -- 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] Fix wrong sizeof
linux/drivers/media/video/saa7164/saa7164-cmd.c |2 +- Acked-By: Steven Toth -- 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: cx23885 audio
On 10/1/09 11:52 PM, David T.L. Wong wrote: Hi all, It there any cx23885 audio support on current v4l-dvb tree, Or any development tree for cx23885 audio? http://www.kernellabs.com/blog/?p=788 I'm about to start on this. -- 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: BUG: cx23885_video_register() uninitialized value passed to v4l2_subdev_call()
On 10/1/09 3:06 AM, David T. L. Wong wrote: Hi all, A potential bug is found in cx23885_video_register(). A tuner_setup struct is passed to v4l2_subdev_call(), but that struct is not fully initialized, especially for tuner_callback member, and eventually tuner_s_type_addr() copy that wrong pointer. It would particularly cause seg. fault for xc5000 tuner for analog frontend when it calls fe->callback at xc5000_TunerReset(). Thanks for raising this. I also discovered this last Saturday. I have a patch for this which I expect to merge shortly. Regards, 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
Re: [PATCH] media/video: adding __init/__exit macros to various drivers
On 9/30/09 9:26 AM, Karicheri, Muralidharan wrote: drivers/media/video/saa7164/saa7164-core.c drivers/media/video/cx23885/cx23885-core.c Acked-By: Steven Toth -- 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: CX23885 card Analog/Digital Switch
On 9/28/09 11:54 AM, David T. L. Wong wrote: Hello List, cx23885 card Magic-Pro ProHDTV Extreme 2, has a cx23885 GPIO pin to select Analog TV+Radio or Digital TV. How should I add that GPIO setting code into cx23885? The current model that all operations goes to FE instead of card is not very appropriate to model this case. I thought of adding a callback code for the tuner (XC5000), but my case is that this behavior is card specific, but not XC5000 generic. Is there any "Input Selection" hook / callback mechanism to notify the card, the device. Digital TV is about to have mkrufky's ioctl override patch merged so that the bridge can be informed before/after a dtv frontend is opened, this is an entry point for you. The bridge can flip the GPIO on demand based on current hardware state. Analog tv entry point could be the hooked into one of the video open ops, such as video_open(). Likewise, the bridge would be involved. -- 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: HVR1800 ATSC regression - Fails to attach DVB
On 9/27/09 3:08 PM, Andy Walls wrote: On Sun, 2009-09-27 at 11:19 -0400, Steven Toth wrote: I'm seeing a regression in tip. A Hauppauge HVR1800 model 78521 fails to have its demod for DTV attached correctly, resulting in a total loss of ATSC/QAM support. I'm looking into this. Thanks, but I don't think this was tip... Sorry for the noise, I had two bad piece of hardware. Please ignore. -- 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: [PULL] http://linuxtv.org/hg/~awalls/cx23888-ir-part1
Please pull from http://linuxtv.org/hg/~awalls/cx23888-ir-part1 Regression testing has highlighted the 885/7/8 detection isn't reliable, causing a regression for HVR1800 - total loss of sync. (It's detected as a 885). Hardcoding the detect to return the correct type (887) causes the driver to work correctly for video (audio untested). This is very good news. I'm installing a mix of 885/7/8 boards now looking for a better detection solution. I'm hoping to have a patch available in the next couple of hours. FYI -- 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
HVR1800 ATSC regression - Fails to attach DVB
I'm seeing a regression in tip. A Hauppauge HVR1800 model 78521 fails to have its demod for DTV attached correctly, resulting in a total loss of ATSC/QAM support. I'm looking into this. -- 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: [PULL] http://linuxtv.org/hg/~awalls/cx23888-ir-part1
On 9/27/09 10:10 AM, Andy Walls wrote: On Sun, 2009-09-27 at 21:42 +0800, David T. L. Wong wrote: Andy Walls wrote: Mauro, Please pull from http://linuxtv.org/hg/~awalls/cx23888-ir-part1 for the following 8 changesets: 01/08: v4l2-chip-ident: Add ID's needed for the cx23885 and cx25840 modules http://linuxtv.org/hg/~awalls/cx23888-ir-part1?cmd=changeset;node=5b2b33f2e3d7 02/08: cx23885: Fix support for v4l2-dbg access to CX2388[578] and CX23417 regs http://linuxtv.org/hg/~awalls/cx23888-ir-part1?cmd=changeset;node=f652c361b61d 03/08: cx23885: Add skeleton v4l2_subdev for the CX23888 integrated IR controller http://linuxtv.org/hg/~awalls/cx23888-ir-part1?cmd=changeset;node=f153c30da5c5 04/08: cx25840: Improve detection of CX2388[578] A/V cores http://linuxtv.org/hg/~awalls/cx23888-ir-part1?cmd=changeset;node=0efbeb807ff0 05/08: cx25840: Convert chip/core family checks to static inline functions http://linuxtv.org/hg/~awalls/cx23888-ir-part1?cmd=changeset;node=80d278a74d8a 06/08: cx25840: Separate set_audclk_freq functionality for the different chips http://linuxtv.org/hg/~awalls/cx23888-ir-part1?cmd=changeset;node=5f58b345e32e 07/08: cx25840: Init PLLs properly for CX2388[578] A/V cores http://linuxtv.org/hg/~awalls/cx23888-ir-part1?cmd=changeset;node=b1ebfabe9c60 08/08: cx23885: Enable HVR-1850 CX23888 A/V core to get VID_CLK running for IR http://linuxtv.org/hg/~awalls/cx23888-ir-part1?cmd=changeset;node=7d99cae94fe5 I am submitting this CX23888 IR work in two parts, instead of one complete set, for two reasons: 1. Steve is waiting on these particular cx25840 module changes to move forward on work for analog video for some cards supported by the cx23885 driver. I don't want to hold up that work. Thank you. Thanks, Andy Andy and the List, I just tested your tree for the cx23885 card MagicPro ProHDTV Extreme 2. I can get it works for Composite PAL. Thanks Andy. Without your patch, PLL doesn't lock well, video not sync. David, Although fixing analog video wasn't my objective, it is good to hear that things have improved. I needed the VID PLL working properly because the IR controller in the CX2388[58] chips use it as a reference clock. Because of that, analog video got a minor fix up as a side effect. Yes, one of the nice side benefits is the video fixups, much appreciated. I'm going to regression test the HVR1800 (cx23887) now. 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: Preliminary working HVR-1850 IR hardware and grey Hauppauge RC-5 remote
On 9/19/09 10:20 PM, Andy Walls wrote: Steve, I've finally have a working implementation of the the HVR-1850 IR receiver and the grey Hauppauge RC-5 remote with in kernel (non-LIRC) IR input to key press events. If you feel adventurous, give it a try for testing the IR receiver: http://www.linuxtv.org/hg/~awalls/cx23888-ir Very nice, excellent work. Sorry, my weekend was crazy so I never managed to test your tree, even though I saw your email. Today and tomorrow won't be much better as I'll be preparing to head out to LPC. A couple of things on my mind currently: 1. I'd like to test this asap and give you some feedback. This is a very welcome addition to the cx23885/25840 driver codebase. In reality this could be a week or so. 2. Once you have your patch-sets in order I'd like to pull those patches and do some HVR1850 analog encoder work. I have some small patches pending that should immediately allow me to start testing various aspects of analog. (Unrelated to your IR work but highly related to the fact you're fixed up the clocks inside the 25840 nicely). 3. Getting RC5 IR support on the existing HVR1800/HVR1250 would be _really_ nice and from the sound of it an incremental step built on the current work. I think from memory you only have HVR1600 and HVR1850 Hauppauge boards. Is this correct? I want to bring a couple of 'samples' to LPC for you Assuming you're interested. Let me know as my luggage space will be tight. 4. I'm hoping we'll sample a beer or two in Portland ;) 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: [PULL] http://www.kernellabs.com/hg/~stoth/saa7164-dev
>> > drivers/media/video/saa7164/saa7164-buffer.c: In function >> > ‘saa7164_buffer_alloc’: >> > drivers/media/video/saa7164/saa7164-buffer.c:110: warning: cast to pointer >> > from integer of different size >> > drivers/media/video/saa7164/saa7164-buffer.c:112: warning: cast to pointer >> > from integer of different size >> >> Last I checked prior to merge the only 64bit'ism was the warning for the >> call to >> the kernel software demux. Let me look into this today. > > Fixed. The error where with i386. Thanks Mauro, - 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
Re: Hw capabilities of the HVR-2200
On 9/18/09 2:13 PM, Jed wrote: 2) Component input for the A/V-in Yes, this exists on the HVR2250 product only. Ah shite, are you sure? If you look at the specs for the reference card it was there, did they take it out at the last minute? It's not feature Hauppauge supports on the HVR2200 today. I have a suspicion this may change but I'm neither confirming, denying or announcing anything. It would make sense to officially support component cables on the HVR2200 since the silicon supports it. If/when it does I'm sure it will be mentioned in the forums or on the HVR2200 product packaging. So I garner from that, that you don't intend to add support for anything (including extra encoding abilities that they don't support in Windows) unless Hauppauge officially does? No, I was referring specifically to your component 'are you sure?' question. I've said many times on and off this mailing list that I'd like to add support for all of the encoder a/v codecs, regardless of the windows driver and it's capabilities. Timeframe for this is unknown. -- 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: Hw capabilities of the HVR-2200
2) Component input for the A/V-in Yes, this exists on the HVR2250 product only. Ah shite, are you sure? If you look at the specs for the reference card it was there, did they take it out at the last minute? It's not feature Hauppauge supports on the HVR2200 today. I have a suspicion this may change but I'm neither confirming, denying or announcing anything. It would make sense to officially support component cables on the HVR2200 since the silicon supports it. If/when it does I'm sure it will be mentioned in the forums or on the HVR2200 product packaging. 3) Hw encode bypass for A/V-in No idea. Regardless of whether it does or does not I wouldn't plan to add basic raw TV support to the driver, without going through the encoder. Why do you rule it out unequivocally, is it just because I've annoyed you? :-( Raw analog TV isn't a high priority feature on my mental check-list. Analog TV via the encoder is much more interesting and applicable to many people. -- 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: [PULL] http://www.kernellabs.com/hg/~stoth/saa7164-dev
On 9/18/09 4:27 AM, Hot Wheelz wrote: Hi Mauro, What about saa7162 How far from being complete is that? For some reason this email went specifically to me, not Mauro (who I've cc'd in). The saa7164 tree does not support he saa7162, it was never designed to do so. 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: Hw capabilities of the HVR-2200
On 9/18/09 12:24 PM, Jed wrote: **a repost because of earlier issues in getting emails to the list** Hi Kernellabs or anyone involved with driver development of the HVR-2200... Hello. I know this is a lng way down the priority list of features to be added, if ever! But I'm wanting to know if the *possibility* is there 'hardware-wise' for the following: 1) h.263/mpeg4/VC-1/DivX/Xvid hardware encode of A/V-in Yes, this exists in hardware on the SAA7164 and therefore the HVR2200 and HVR2250. 2) Component input for the A/V-in Yes, this exists on the HVR2250 product only. 3) Hw encode bypass for A/V-in No idea. Regardless of whether it does or does not I wouldn't plan to add basic raw TV support to the driver, without going through the encoder. 4) Is Hw encode purely for A/V-in? (hauppauge's site suggests otherwise but it may be a typo) Yes. -- 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: [PULL] http://www.kernellabs.com/hg/~stoth/saa7164-dev
On 9/18/09 12:24 AM, Mauro Carvalho Chehab wrote: Em Thu, 17 Sep 2009 20:05:14 -0400 Steven Toth escreveu: Mauro, Please pull from http://www.kernellabs.com/hg/~stoth/saa7164-dev - SAA7164: Remove the SAA7164 bus id, no longer required. - SAA7164: Remove the i2c client_attach/detach support, no longer required. - SAA7164: Removed bus registration messages from driver startup drivers/media/video/saa7164/saa7164-i2c.c | 62 -- include/linux/i2c-id.h|1 2 files changed, 1 insertion(+), 62 deletions(-) These fix the i2c attach/detach compilation error and the id assignment we'd previously discussed, as well as reducing slightly the driver verbosity during i2c bus registration. Ok, now it compiles, but there are still two warnings against upstream, with x86_64: drivers/media/video/saa7164/saa7164-buffer.c: In function ‘saa7164_buffer_alloc’: drivers/media/video/saa7164/saa7164-buffer.c:110: warning: cast to pointer from integer of different size drivers/media/video/saa7164/saa7164-buffer.c:112: warning: cast to pointer from integer of different size Last I checked prior to merge the only 64bit'ism was the warning for the call to the kernel software demux. Let me look into this today. - 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
[PULL] http://www.kernellabs.com/hg/~stoth/saa7164-dev
Mauro, Please pull from http://www.kernellabs.com/hg/~stoth/saa7164-dev - SAA7164: Remove the SAA7164 bus id, no longer required. - SAA7164: Remove the i2c client_attach/detach support, no longer required. - SAA7164: Removed bus registration messages from driver startup drivers/media/video/saa7164/saa7164-i2c.c | 62 -- include/linux/i2c-id.h|1 2 files changed, 1 insertion(+), 62 deletions(-) These fix the i2c attach/detach compilation error and the id assignment we'd previously discussed, as well as reducing slightly the driver verbosity during i2c bus registration. Thanks, -- 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: HVR-2200 Australia DVB-T
WIN TV Canberra:76750:INVERSION_AUTO:BANDWIDTH_7_MHZ:FEC_3_4:FEC_3_4:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_16:HIERARCHY_NONE:33:36:1 r...@kaylee:~/.tzap# tzap "WIN TV Canberra" using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' reading channels from file '/root/.tzap/channels.conf' tuning to 76750 Hz video pid 0x0021, audio pid 0x0024 status 00 | signal a9a9 | snr 002e | ber | unc | status 00 | signal | snr | ber | unc | status 00 | signal | snr | ber | unc | status 00 | signal | snr | ber | unc | Any help would be appreciated. Sounds like a tuning issue. Either the Antenna is bad or the channels.conf doesn't represent the actual center frequency or the channel or the tuner / demod code is buggy. Other people are having success with DVB-T HVR2200 so it's either a bug that gets exposed by your environment or something else. mkrufky has some tuner improvements pending for merge which are not in the saa7164 tree yet, you might want to hold for a few days for these. The other thing to double check is that the freqs in your channels conf do actually represent the center of the DVB-T channel. I suspect they do, but double check for good measure using the official Australian DVB-T antenna docs. -- 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: PCI/e with dual DVB-T + AV-in (HVR-2200?)
On 9/11/09 12:11 PM, Jed wrote: Yeah I realised after seeing your 2nd email that Hauppauge only says mpeg2 because that's all the Windows dvr does! :-D I also noticed on the website that it only talks about hw encode being for the analog rf tuners, is there no hw encode for av-in?! It seems to be other way round for most other cards Having the *option* to bypass hw encode whether it be on the analog rf-in or av-in would be a very handy feature! Because one could instead use CPU/GPGPU resources (if suited) and more flexible software, or even dedicated encoder/transcoder addon devices. Or in the case of video editing leave it raw for easier editing, and then transocde it as required... Hi, I came across these two pdf's which seem to suggest that the references cards that the hvr-2200/2250 are based-on can do component in! Could it be that (like the limitation with hw encode in Windows to mpeg2) component in is also not advertised, simply because it's not supported in Windows? Assuming the cards are based-on the reference cards, then the hardware support seems to be there! Can someone please address my earlier points above too if you have an answer/opinion? Thanks heaps! Jed Hi Kernellabs or anyone involved with driver development of the HVR-2200, I know this is long wy down the priority list of features to be added, if ever! But I'm wanting to know if the *possibility* is there 'hardware-wise' for the following: 1) h.263/mpeg4/VC-1/DivX/Xvid hardware encode of A/V-in 2) Component input for the A/V-in 3) Hw encode bypass for A/V-in 4) Is Hw encode purely for A/V-in? (hauppauge's site seems to suggest otherwise but it may be a typo) 5) If not then questions 1) & 3) also apply to RF-in! I've attached the reference cards spec. sheets again for your perusal. I would be proactive in providing as much feed-back as needed for the dev. of such features. Most Sincerely, Jed For some inexplicable reason my last two posts have not appeared on the ML, it seems I've been scrubbed! Hence I'm forwarding straight to you to answer or forward to colleagues to answer when possible. Oh, I saw your posting to the list. It's in my inbox, along with many other emails I'd like to respond to over the next few weeks. Nothing personal, I'm just too busy right now to deal with your ongoing daily list of questions. Please post all your questions to the ML and people will respond when they can, if they can. -- 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: PCI/e with dual DVB-T + AV-in?
Huh, but Hauppaguge site says hvr-2200 only does mpeg2 encode? My rationale was more flexibility by using software encode and free cpu cycles, I think it would be appealing to quite a few ;-) That's correct, the Windows driver does mpeg2 encode only. All of the other codecs are available by default. -- 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: PCI/e with dual DVB-T + AV-in?
On 9/8/09 4:04 PM, Jed wrote: Hi Ya'll, Going on response levels thus far I'm not expecting much :-D but I was wondering if someone could possibly help me out here. Is there anything with half-decent driver support that is PCI/e, and has dual DVB-T + A/V-in?* As a bonus it would be dual Hybrid and have hardware encode, but I wouldn't expect either to work at this stage. I'm still trawling through mail-lists & wiki's etc, so I may yet find the best solution, but I was hoping some might already know. Any advice or even just a response to chastise me is greatly appreciated! :-D Cheers, Jed *Is HVR-2200 the only option? I wish there was something with better AV-in but it might end-up being my final choice. Jed wrote: I've stopped looking for an alternative card, going to have a crack at getting my 7162-based device working. Still, any suggestions in the meantime are most welcome! I've also decided AV-in isn't that important... So just a known, nicely working PCI/e + dual DVB-T card, having the other features is nice but they needn't be working yet. Wish me luck! :-D HVR2200 is in well supported now for digital-only. It is a dual tuner board using a PCI-E interface. It has A/V capabilities that are not *yet* supported in Linux. Don't know when A/V will be supported, but it will probably happen, eventually. It is a dual hybrid, and it does do hardware encode. (although not yet in Linux) This probably is the device for you. To follow the development more closely, see the blog on kernellabs.com I hope this helps. Regards, Mike Hi saa7164 devs, once(if) the software support is in place for A/V-in... Do you know if it'd be possible to bypass hw encode and dump uncompressed HD/SD with this card? Or is it limited hardware-wise to even do this? Cheers, Jed Hi, could I possibly get a response to this please? No idea, I have yet to look into this. All things considered I doubt it's worth spending time on raw analog when the goal for most people is to have the mpeg2/4/wmv hardware encoder working. -- 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: [RFC] Allow bridge drivers to have better control over DVB frontend operations
I pushed the change to let dvb-usb drivers specify an fe_ioctl_override callback within the dvb_usb_adapter_properties structure. Please check the repository for the latest changesets. I plan to ask Mauro to merge this tree at some point over this next week -- If anybody else has comments, please chime in :-) I'm good with this RFC, it adds feature that enable the bridge (opt-in) to make intelligent decisions on behalf of complex products related to resource usage and tuning, something we've needed for a while. Acked-By: Steven Toth -- 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: [linuxtv-commits] [hg:v4l-dvb] cx25840: fix determining the firmware name
What is the exact benefit we're after here by making things common between all these cores? Code reuse is not a benefit, if it leads to more expensive maintenance. We'll, it diverged for the 23885 because the register addressed change for some registers, it's not the same part. Certainly for the video decoder, not necessarily for the audio encoder. I know Andy knows this, I'm just pointing it out for the record. This, coupled with the 'don't screw up other boards' approach leads to a unified driver, not so much internally. The 25840 driver does 'just enough' to get by, Andy has taken it to the next level and done the stuff that I should have done for the cx23885 merge (although I did 'just enough' to get by). The notion of flexible clocks pays big dividends thanks to Andy, but is largely a positive change that falls outside of this discussion topic (firmware filename). I had considered moving the cx18-av code from the cx18 module into the cx25840 module, but could never find a reason to undertake all the work. Memory footprint isn't a good reason: desktop PC memory is cheap and embedded systems would likely only use one type of card anyway. The return on investment seems like it would be less than 0. Hmm. You should check out the cx23102 driver, whole crap, massive cx25840 overlap, massive superset in terms of functionality. OK. I'm done ranting... A great pity, you were getting me fired up along the same train of thought :) Andy, you have the support and full access to the resources of KernelLabs if you need help (directly or indirectly) with regression testing. Your work is very positive and a much needed overhaul. Mauro, my pitch: Let's leave the firmwares unique for the time being, which indeed they are. So, leave the firmware detection code as is, it's working for everyone. Let's rethink this discussion after Andy's massive patch series. It sounds like the cx25840 driver is 'getting a new owner' and we'll look at the driver differently once the overhaul is complete. -- 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
ML delivery failures
Hi, I have the traffic from this list going to a gmail account. I normally use thunderbird to respond to emails and never have issues posting to the ML. If I'm away from thunderbird and try to respond via the google apps gmail interface my mails always get bounced from vger's mail daemon, claiming that the message has a html sub-part, and is considered spam or an outlook virus - thus rejected. It's happened a few times, again today when responding to Simon's comment about the relationship between the 716x and the 7162 driver. I don't see any obvious 'use-non-html' formatting setting in gmail. Perhaps someone else has seen this issue or knows of a workaround? Comments / feedback appreciated. 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
Fwd: [PULL] http://www.kernellabs.com/hg/~stoth/saa7164-merge
Oops, this went to the wrong list. Original Message Subject: [PULL] http://www.kernellabs.com/hg/~stoth/saa7164-merge Date: Thu, 03 Sep 2009 23:35:29 -0400 From: Steven Toth To: Linux Kernel Mailing List , Mauro Carvalho Chehab Hello Mauro, This patch series adds support for the NXP SAA7164 PCIe A/V bridge used by the Hauppauge HVR-2200 and HVR-2250 series of products. Support is limited to DVB-T / ATSC / QAM digital TV only. The driver has been in development (on and off) for around a year and the KernelLabs saa7164-stable tree (from which this patch set was prepared) has been in testing worldwide since approx May(?) 2009. The project page including links for firmware downloads, MythTV and Wiki instructions is here: http://www.kernellabs.com/blog/?page_id=17 Two general observations with the tree: 1. The driver is a little verbose during initial module load, I need to trim a few lines of debug. 2. During 64bit compile I have one compile time warning to be addressed. Both of these will be resolved shortly and should not stop the driver being merged and made available to a much wider range of testers. So, please pull from http://www.kernellabs.com/hg/~stoth/saa7164-merge - Add the SAA7164 I2C bus identifier - SAA7164: Add support for the NXP SAA7164 silicon - SAA7164: Fix some 32/64bit compile time warnings - SAA7164: Adjust I/F's to the TDA10048 enabling DVB-T lock - SAA7164: Email address change - SAA7164: Remove volatiles for PCI writes (coding style violation) - SAA7164: Increase firmware load tolerance - SAA7164: OOPS avoidance during interrupt handling - SAA7164: Removed spurious I2C errors during driver load with DVB-T boards. - SAA7164: Fix the 88021 definition to work with production boards. - SAA7164: Fixed the missing eeprom parse on a specific board. - SAA7164: Fix IRQ related system hang when firmware is not found. - SAA7164: Fix i2c eeprom read errors during load (some boards). - SAA7164: Ensure we specify I/F's for all bandwidths - SAA7164: Added waitsecs module parameter - SAA7164: Cleanup a printk - SAA7164: Increase the firmware command timeout to avoid firmware errors. - SAA7164: Removed a duplicate call to address any PCI quirks. - SAA7164: IRQ / message timeout related change - SAA7164: Removed spurious debug - SAA7164: HVR2250 changes related to attach time tuner configuration - SAA7164: Remove meaningless if'0 code - SAA7164: Minor i2c assignment cleanup - SAA7164: Ensure the HVR-2200 second tuner is configured in slave mode. - SAA7164: Add support for a new HVR-2250 hardware revision b/linux/Documentation/video4linux/CARDLIST.saa7164 |8 b/linux/drivers/media/video/saa7164/Kconfig | 19 b/linux/drivers/media/video/saa7164/Makefile | 12 b/linux/drivers/media/video/saa7164/saa7164-api.c| 778 + b/linux/drivers/media/video/saa7164/saa7164-buffer.c | 162 ++ b/linux/drivers/media/video/saa7164/saa7164-bus.c| 448 + b/linux/drivers/media/video/saa7164/saa7164-cards.c | 600 +++ b/linux/drivers/media/video/saa7164/saa7164-cmd.c| 529 ++ b/linux/drivers/media/video/saa7164/saa7164-core.c | 797 ++ b/linux/drivers/media/video/saa7164/saa7164-dvb.c| 594 +++ b/linux/drivers/media/video/saa7164/saa7164-fw.c | 632 +++ b/linux/drivers/media/video/saa7164/saa7164-i2c.c| 202 ++ b/linux/drivers/media/video/saa7164/saa7164-reg.h| 183 ++ b/linux/drivers/media/video/saa7164/saa7164-types.h | 287 +++ b/linux/drivers/media/video/saa7164/saa7164.h| 405 + b/v4l/scripts/saa7164.pl | 57 linux/Documentation/video4linux/CARDLIST.saa7164 |5 linux/drivers/media/video/Kconfig|2 linux/drivers/media/video/Makefile |1 linux/drivers/media/video/saa7164/saa7164-api.c |6 linux/drivers/media/video/saa7164/saa7164-buffer.c | 15 linux/drivers/media/video/saa7164/saa7164-bus.c |6 linux/drivers/media/video/saa7164/saa7164-cards.c| 74 linux/drivers/media/video/saa7164/saa7164-cmd.c | 47 linux/drivers/media/video/saa7164/saa7164-core.c | 98 - linux/drivers/media/video/saa7164/saa7164-dvb.c | 70 linux/drivers/media/video/saa7164/saa7164-fw.c | 10 linux/drivers/media/video/saa7164/saa7164.h | 18 linux/include/linux/i2c-id.h |1 v4l/scripts/cardlist |3 v4l/scripts/fix_dvb_customise.pl |3 v4l/versions.txt |1 32 files changed, 5956 insertions(+), 117 deletions(-) Thanks, -- 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 Mor
Re: hvr-1800 disabling audio on pvr-500?
Sigh... I'll see if I have time to fix this today or tomorrow. This might help: http://www.kernellabs.com/hg/~stoth/cx25840-fw/rev/38c5fb14c770 -- 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: Hauppauge 2250 - second tuner is only half working
On 8/25/09 10:18 PM, s...@cyberseth.com wrote: Well my card is out the door already. So it'll be a week or so till i can try again. I'll give it a pretty thorough run down when i get the new card, maybe I can dig up a repro. This is probably just a red herring, but FWIW I had never cold booted the machine (except monday morning when i yanked the card). I warm booted plenty, but i frequently would run full us-Cable scan's on both tuners. Some time last week when repo's pushed out 2.6.28-15, i had at least one warm boot in there where i had the modules/firmware missing. I reinstalled (dist-clean, make, make install), rebooted, and tried again and found it was working (well, for a little while until that spontaneous reboot). Fair enough. Another user is preparing remote access so I can take a look at the problem first hand. With any look we'll see the issue and have a patch by the time your replacement board comes back. - 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
Re: Hauppauge 2250 - second tuner is only half working
On 8/25/09 7:23 PM, Steven Toth wrote: On 8/25/09 6:59 PM, Steven Toth wrote: After reading Steven Toth's reply I tried adding 1 and then 2 2-way splitters before the 2250 input. No joy. I also tried feeding the cable directly into the 2250 with no splitters. Again - no joy. Any other ideas? Most likely this is dependent on what frequency the other tuner is tuned to, especially since Seth indicated it worked for a short time. And, again, I don't see the issue but two other people do. RMA is probably not the answer. When you next get a chance to test please use azap and keep track of what frequency the first tuner is currently tuned to even if tuner#1 is technically no longer streaming. I suspect varying the frequency on tuner#1 will vary your test results. OK, I can repro the issue. Tuning tuner 1 to 669 works, then tune tuner2 to 669 no lock. Set tuner #1 to 579 is locks, then tuner2 automatically also goes into lock. So, it depends on where tuner#1 was previously tuned to. I'll look into this. Save yourself the trouble of the RMA if it hasn't already shipped. I was able to repro the issue once however during patching the issue went away, never to return - regardless of whether the patch was active or not. I even ran a series of cold boots to try and repro the behavior but I cannot. I have seen the issue and I believe it exists, I just cannot get a reliable repro. If you can test tuner 1 on selected frequencies then test tuner 2 always against channel 103 (669MHz) and find a reliable repro case then I'll take another look. Annoying. -- 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: Hauppauge 2250 - second tuner is only half working
On 8/25/09 6:59 PM, Steven Toth wrote: After reading Steven Toth's reply I tried adding 1 and then 2 2-way splitters before the 2250 input. No joy. I also tried feeding the cable directly into the 2250 with no splitters. Again - no joy. Any other ideas? Most likely this is dependent on what frequency the other tuner is tuned to, especially since Seth indicated it worked for a short time. And, again, I don't see the issue but two other people do. RMA is probably not the answer. When you next get a chance to test please use azap and keep track of what frequency the first tuner is currently tuned to even if tuner#1 is technically no longer streaming. I suspect varying the frequency on tuner#1 will vary your test results. OK, I can repro the issue. Tuning tuner 1 to 669 works, then tune tuner2 to 669 no lock. Set tuner #1 to 579 is locks, then tuner2 automatically also goes into lock. So, it depends on where tuner#1 was previously tuned to. I'll look into this. Save yourself the trouble of the RMA if it hasn't already shipped. -- 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: Hauppauge 2250 - second tuner is only half working
After reading Steven Toth's reply I tried adding 1 and then 2 2-way splitters before the 2250 input. No joy. I also tried feeding the cable directly into the 2250 with no splitters. Again - no joy. Any other ideas? Most likely this is dependent on what frequency the other tuner is tuned to, especially since Seth indicated it worked for a short time. And, again, I don't see the issue but two other people do. RMA is probably not the answer. When you next get a chance to test please use azap and keep track of what frequency the first tuner is currently tuned to even if tuner#1 is technically no longer streaming. I suspect varying the frequency on tuner#1 will vary your test results. -- 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] cx23885: fix support for TBS 6920 card
On 8/19/09 7:20 PM, Konstantin Dimitrov wrote: fix: GPIO initialization for TBS 6920 fix: wrong I2C address for demod on TBS 6920 fix: wrong I2C bus number for demod on TBS 6920 fix: wrong "gen_ctrl_val" value for TS1 port on TBS 6920 (and some other cards) add: module_param "lnb_pwr_ctrl" as option to choose between "type 0" and "type 1" of LNB power control (two TBS 6920 boards no matter that they are marked as the same hardware revision may have different types of LNB power control) fix: LNB power control function for type 0 doesn't preserve the previous GPIO state, which is critical add: LNB power control function for type 1 Signed-off-by: Bob Liu Signed-off-by: Konstantin Dimitrov I got a weird HTML related email bounce from vger when I responded originally to this via gmail. Maybe this time via thunderbird will bring success. ... Hmm. A custom hanging off of a gpio to something that looks like an i2c power control device. I want to review some of these generic (and no-so-generic) changes before we merge this patch. Is the datasheet for the LNB power control device available to the public? I'd like to understand some of the register details. Thanks, -- 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: Hauppauge 2250 - second tuner is only half working
On a side note - Thank you very much for hacking on the saa7164 - other than this frequency glitch its been working great for me! You're welcome! :) -- 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: Hauppauge 2250 - second tuner is only half working
I'd really appreciate any help or guidance on this problem as i'm fully perplexed by it. Hey Seth, I ran the same tests on my cable system (channel 103) on 669Mhz and had no issue, and my snr's reported as (0x172 and 0x17c). One possibility is that you're overwhelming the frontend. Try adding a small mount of attenuation to the signal for test purposes. Hard to believe but this is where I'd start looking. -- 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: Linux Plumbers Conference 2009: V4L2 API discussions
On 8/7/09 6:36 PM, VDR User wrote: It has been months now since the discussion about actually making (a unified) STR/SNR useful. Is this going to be addressed at the conference? It's one of those things that would be greatly useful for users/applications but seemingly has gotten neglected. Regards, Derek I'm reasonably sure I'll be attending, in which case I'd like to raise this for discussion and generate a proposal. -- 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
[PULL] http://www.kernellabs.com/hg/~stoth/hvr1300
Mauro, Please pull from http://www.kernellabs.com/hg/~stoth/hvr1300 - cx88: HVR1300 ensure switching from Encoder to DVB-T and back is reliable cx88-mpeg.c |4 1 file changed, 4 insertions(+) Thanks, -- 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: SAA7164 - Analogue Support on HVR devices
On 7/30/09 9:26 AM, ld...@hubstar.net wrote: Steven Toth wrote: On 7/30/09 6:32 AM, Lou Otway wrote: First I'd like to say thanks to the maintainers of the various HVR drivers, the amount of work that goes in is much appreciated. I notice from www.kernellabs.com that progress on the digital side for SAA7164 devices is going well and a stable driver is nearly ready. I, like many people, would really like to have analogue support for these devices, is there any news on when this functionality might be available? Thank you. If you read back far enough with the SAA7164 related posts you'll see that finalizing DTV is the primary focus, everything else is up for review once this task is complete. Hi I don't have this card, but I have some other hauppauge cards. What is meant by analogue support? From my perspective I understand if TV analogue is dropping priority but for me the Composite/Svideo analogue on Hauppauge cards is more important - since I use them to hook up to my Satellite boxes. Do you count that as analogue too? Yes. -- 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] cx23885-417: fix setting tvnorms
On 7/30/09 1:46 AM, Joseph Yasi wrote: Currently, the VIDIOC_S_STD ioctl just returns -EINVAL regardless of the norm passed. This patch sets cx23885_mpeg_template.tvnorms and cx23885_mpeg_template.current_norm so that the VIDIOC_S_STD will work. Signed-off-by: Joseph A. Yasi Joseph, thank you for raising this. We have this change and a few others already stacked up in this tree: http://www.kernellabs.com/hg/~mkrufky/cx23885-api/rev/0391fb200be2 The end result is to get MythTV using the HVR1800 analog encoder correctly. The tree itself is considered experimental but during testing we had noticed the same issue, so, again, thank you for raising the same issue. Two people reporting the same issue is always better than none. - 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
Re: SAA7164 - Analogue Support on HVR devices
On 7/30/09 6:32 AM, Lou Otway wrote: First I'd like to say thanks to the maintainers of the various HVR drivers, the amount of work that goes in is much appreciated. I notice from www.kernellabs.com that progress on the digital side for SAA7164 devices is going well and a stable driver is nearly ready. I, like many people, would really like to have analogue support for these devices, is there any news on when this functionality might be available? Thank you. If you read back far enough with the SAA7164 related posts you'll see that finalizing DTV is the primary focus, everything else is up for review once this task is complete. -- 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
[PULL] http://www.kernellabs.com/hg/~stoth/hvr1700
Mauro, Please pull from http://www.kernellabs.com/hg/~stoth/hvr1700 - cx25840: Bugfix for no DVB-T on the Hauppauge HVR-1700 cx25840-core.c | 15 +-- cx25840-firmware.c | 13 - 2 files changed, 21 insertions(+), 7 deletions(-) This fixes a HVR1700 related regression, which occurred after the subdev conversion. In essence the order of initialization changed and I have to preserve GPIO settings before we load the firmware. Thanks to Sohail for raising this and mkrufky for doing the early analysis. -- 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: em28xx driver crashes device
On 7/24/09 1:34 PM, cyber.bogh wrote: Am Freitag 24 Juli 2009 18:42:58 schrieben Sie: This mailing list, the freenode irc channels #v4l and #linuxtv, the V4L and the LinuxTV mailing lists were created for discussing open source development related to the kernel linux media drivers, the usability of those drivers and related open source themes. Anything related to binary only userspace stuff is completely out of topic and shouldn't be posted on the above places. Markus, The Linux community supports it's in-kernel dvb / v4l trees using this channel. Your attempt to use these channels to de-value the in-kernel driver and your agenda to promote your (partially) closed source alternative it is off topic. Toth, But in fact you show that you are a mismatch as far as human qualifications are concerned. This is indeed high praise coming from such a fine and noble gentlemen like yourself. I find myself truly humbled, nay, honored that you've chosen to grace us with your presence and thoughts today. I'm probably not alone when I say that we look forward to your monumental words of wisdom, charm and enlightenment that you've recently chosen to share with us all. You have a true gift and I can only hope that you continue to share it with us all. Happy Christmas, please give my regards to the wife and kids. -- 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: em28xx driver crashes device
This mailing list, the freenode irc channels #v4l and #linuxtv, the V4L and the LinuxTV mailing lists were created for discussing open source development related to the kernel linux media drivers, the usability of those drivers and related open source themes. Anything related to binary only userspace stuff is completely out of topic and shouldn't be posted on the above places. Markus, The Linux community supports it's in-kernel dvb / v4l trees using this channel. Your attempt to use these channels to de-value the in-kernel driver and your agenda to promote your (partially) closed source alternative it is off topic. This is not the first time people have had to say this. You're only damaging your reputation further using tactics like this. -- 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] dvb: make digital side of pcHDTV HD-3000 functional again
On 7/21/09 9:48 PM, Bob Hepple wrote: On Tue, 21 Jul 2009 21:35:47 -0400 Jarod Wilson wrote: So its either I have *two* machines with bad, but only slightly bad, and in the same way, PCI slots which seem to work fine with any other card I have (uh, unlikely), ... not unlikely if the two machines are similar - many motherboards have borked PCI slots in one way or another - design faults or idiosyncratic interpretation of the PCI standard. I've seen it with HP, Compaq, Digital m/bs just to name big names, smaller mfrs also get it wrong. Sometimes just using another slot helps. Sometimes you need to try a totally different motherboard. Maybe wrong to 'blame' the m/b mfr - it could just as easily be an out-of-spec or creatively interpreted PCI standard on the card. My guess is that the eeprom was trashed. -- 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
