help: Can't get DViCO FusionHDTV DVB-T Dual Digital 4 to work with new kernels
Been grappling with this problem for a while now.. I am using stock linux kernel 2.6.28.9 together with Mythtv (SVN trunk) For some reason I cannot use 2.6.29.x or 2.6.30.x (latest version I tried is 2.6.30.5). Everytime i start mythbackend, the console is littered with the following messages, and the keyboard input freezes sporadically. the messages as below: dvb-usb: recv bulk message failed: -110 cxusb: i2c read failed i googled for a solution and it seems some got around this by inserted the IR receiver, I tried but it still doesn't work. is this a mythtv problem or cxusb issue? Please help, any pointers appreciated. regards, -- 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] Report only 32kHz for ALSA
Am Dienstag, den 18.08.2009, 21:24 +0200 schrieb Oldřich Jedlička: > There are several reasons: > > - SAA7133/35 uses DDEP (DemDec Easy Programming mode), which works in 32kHz >only > - SAA7134 for TV mode uses DemDec mode (32kHz) > - Radio works in 32kHz only > - When recording 48kHz from Line1/Line2, switching of capture source to TV >means switching to 32kHz without any frequency translation > > Signed-off-by: Oldřich Jedlička As discussed previously, this is an improvement within our current chip specific capabilities. Thanks. Acked-by: hermann pitton > diff --git a/linux/drivers/media/video/saa7134/saa7134-alsa.c > b/linux/drivers/media/video/saa7134/saa7134-alsa.c > index c09ec3e..504186a 100644 > --- a/linux/drivers/media/video/saa7134/saa7134-alsa.c > +++ b/linux/drivers/media/video/saa7134/saa7134-alsa.c > @@ -440,6 +440,16 @@ snd_card_saa7134_capture_pointer(struct > snd_pcm_substream * substream) > > /* > * ALSA hardware capabilities definition > + * > + * Report only 32kHz for ALSA: > + * > + * - SAA7133/35 uses DDEP (DemDec Easy Programming mode), which works in > 32kHz > + *only > + * - SAA7134 for TV mode uses DemDec mode (32kHz) > + * - Radio works in 32kHz only > + * - When recording 48kHz from Line1/Line2, switching of capture source to > TV > + *means > + *switching to 32kHz without any frequency translation > */ > > static struct snd_pcm_hardware snd_card_saa7134_capture = > @@ -453,9 +463,9 @@ static struct snd_pcm_hardware snd_card_saa7134_capture = > SNDRV_PCM_FMTBIT_U8 | \ > SNDRV_PCM_FMTBIT_U16_LE | \ > SNDRV_PCM_FMTBIT_U16_BE, > - .rates =SNDRV_PCM_RATE_32000 | SNDRV_PCM_RATE_48000, > + .rates =SNDRV_PCM_RATE_32000, > .rate_min = 32000, > - .rate_max = 48000, > + .rate_max = 32000, > .channels_min = 1, > .channels_max = 2, > .buffer_bytes_max = (256*1024), > -- -- 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 v4] ARM: DaVinci: DM646x Video: Platform and board specific setup
Russell,
Could you please ack this patch from Chaithrika if you agree with these changes?
I have another set of patches waiting to be submitted and is dependent on this
patch. So you response will be helpful to speed up the process.
Regards,
Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
email: m-kariche...@ti.com
>-Original Message-
>From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
>ow...@vger.kernel.org] On Behalf Of Subrahmanya, Chaithrika
>Sent: Wednesday, August 05, 2009 1:36 AM
>To: Subrahmanya, Chaithrika; r...@arm.linux.org.uk; li...@arm.linux.org.uk
>Cc: mche...@infradead.org; hverk...@xs4all.nl; linux-media@vger.kernel.org;
>davinci-linux-open-sou...@linux.davincidsp.com; 'Manjunath Hadli'; Jadav,
>Brijesh R; 'Kevin Hilman'
>Subject: RE: [PATCH v4] ARM: DaVinci: DM646x Video: Platform and board
>specific setup
>
>Russell,
>
>Requesting your ack on this patch.
>
>Regards,
>Chaithrika
>
>On Wed, Aug 05, 2009 at 20:17:42, Chaithrika U S wrote:
>> Platform specific display device setup for DM646x EVM
>>
>> Add platform device and resource structures. Also define a platform
>specific
>> clock setup function that can be accessed by the driver to configure the
>clock
>> and CPLD.
>>
>> Signed-off-by: Manjunath Hadli
>> Signed-off-by: Brijesh Jadav
>> Signed-off-by: Chaithrika U S
>> Signed-off-by: Kevin Hilman
>> ---
>> Applies to Davinci GIT tree. Minor updates like change in structure name-
>> subdev_info to vpif_subdev_info and correction to VDD3P3V_VID_MASK value.
>>
>> arch/arm/mach-davinci/board-dm646x-evm.c| 125
>+++
>> arch/arm/mach-davinci/dm646x.c | 62 +
>> arch/arm/mach-davinci/include/mach/dm646x.h | 24 +
>> 3 files changed, 211 insertions(+), 0 deletions(-)
>>
>> diff --git a/arch/arm/mach-davinci/board-dm646x-evm.c
>b/arch/arm/mach-davinci/board-dm646x-evm.c
>> index b1bf18c..8c88fd0 100644
>> --- a/arch/arm/mach-davinci/board-dm646x-evm.c
>> +++ b/arch/arm/mach-davinci/board-dm646x-evm.c
>> @@ -63,6 +63,19 @@
>> #define DM646X_EVM_PHY_MASK (0x2)
>> #define DM646X_EVM_MDIO_FREQUENCY (220) /* PHY bus frequency */
>>
>> +#define VIDCLKCTL_OFFSET(0x38)
>> +#define VSCLKDIS_OFFSET (0x6c)
>> +
>> +#define VCH2CLK_MASK(BIT_MASK(10) | BIT_MASK(9) |
>> BIT_MASK(8))
>> +#define VCH2CLK_SYSCLK8 (BIT(9))
>> +#define VCH2CLK_AUXCLK (BIT(9) | BIT(8))
>> +#define VCH3CLK_MASK(BIT_MASK(14) | BIT_MASK(13) |
>> BIT_MASK(12))
>> +#define VCH3CLK_SYSCLK8 (BIT(13))
>> +#define VCH3CLK_AUXCLK (BIT(14) | BIT(13))
>> +
>> +#define VIDCH2CLK (BIT(10))
>> +#define VIDCH3CLK (BIT(11))
>> +
>> static struct davinci_uart_config uart_config __initdata = {
>> .enabled_uarts = (1 << 0),
>> };
>> @@ -288,6 +301,40 @@ static struct snd_platform_data
>dm646x_evm_snd_data[]
>= {
>> },
>> };
>>
>> +static struct i2c_client *cpld_client;
>> +
>> +static int cpld_video_probe(struct i2c_client *client,
>> +const struct i2c_device_id *id)
>> +{
>> +cpld_client = client;
>> +return 0;
>> +}
>> +
>> +static int __devexit cpld_video_remove(struct i2c_client *client)
>> +{
>> +cpld_client = NULL;
>> +return 0;
>> +}
>> +
>> +static const struct i2c_device_id cpld_video_id[] = {
>> +{ "cpld_video", 0 },
>> +{ }
>> +};
>> +
>> +static struct i2c_driver cpld_video_driver = {
>> +.driver = {
>> +.name = "cpld_video",
>> +},
>> +.probe = cpld_video_probe,
>> +.remove = cpld_video_remove,
>> +.id_table = cpld_video_id,
>> +};
>> +
>> +static void evm_init_cpld(void)
>> +{
>> +i2c_add_driver(&cpld_video_driver);
>> +}
>> +
>> static struct i2c_board_info __initdata i2c_info[] = {
>> {
>> I2C_BOARD_INFO("24c256", 0x50),
>> @@ -300,6 +347,9 @@ static struct i2c_board_info __initdata i2c_info[] =
>{
>> {
>> I2C_BOARD_INFO("cpld_reg0", 0x3a),
>> },
>> +{
>> +I2C_BOARD_INFO("cpld_video", 0x3B),
>> +},
>> };
>>
>> static struct davinci_i2c_platform_data i2c_pdata = {
>> @@ -307,11 +357,85 @@ static struct davinci_i2c_platform_data i2c_pdata =
>{
>> .bus_delay = 0 /* usec */,
>> };
>>
>> +static int set_vpif_clock(int mux_mode, int hd)
>> +{
>> +int val = 0;
>> +int err = 0;
>> +unsigned int value;
>> +void __iomem *base = IO_ADDRESS(DAVINCI_SYSTEM_MODULE_BASE);
>> +
>> +if (!cpld_client)
>> +return -ENXIO;
>> +
>> +/* disable the clock */
>> +value = __raw_readl(base + VSCLKDIS_OFFSET);
>> +value |= (VIDCH3CLK | VIDCH2CLK);
>> +__raw_writel(value, base + VSCLKDIS_OFFSET);
>> +
>> +val = i2c_smbus_read_byte(cpld_client);
>> +if (val < 0)
>> +return val;
>> +
>> +if (mux_mode == 1)
>> +val &= ~0x40;
>> +el
RE: [PATCH v1 - 1/5] DaVinci - restructuring code to support vpif capture driver
Mauro, Here are the patches from Chaithrika that I am referring to. http://www.mail-archive.com/linux-media@vger.kernel.org/msg08254.html http://www.mail-archive.com/linux-media@vger.kernel.org/msg07676.html Let me know once they are merged... Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 new phone: 301-407-9583 Old Phone : 301-515-3736 (will be deprecated) email: m-kariche...@ti.com >-Original Message- >From: Mauro Carvalho Chehab [mailto:mche...@infradead.org] >Sent: Tuesday, August 18, 2009 1:28 PM >To: Karicheri, Muralidharan >Cc: Mauro Carvalho Chehab; linux-media@vger.kernel.org; davinci-linux-open- >sou...@linux.davincidsp.com; khil...@deeprootsystems.com; Hans Verkuil >Subject: Re: [PATCH v1 - 1/5] DaVinci - restructuring code to support vpif >capture driver > >Em Tue, 18 Aug 2009 11:06:54 -0500 >"Karicheri, Muralidharan" escreveu: > >> Mauro, >> >> I need to send a set of patches for adding vpif capture driver. Currently >the linux-next doesn't have the last patch from Chaithrika applied for vpif >display. Is it possible to apply this asap so that I can create the vpif >capture patch today? > >Sure. Could you please point me what's the patchwork ID(s)[1] of the patch >you need >me to apply at our development tree and at linux-next? > [1] http://patchwork.kernel.org/project/linux-media/list/ > >Cheers, >Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Winfast TV USB 2
On Tue, Aug 18, 2009 at 4:31 PM, Marc Arndt wrote: > Good day, > > I see the following when I plug in my Winfast TV USB 2 card, can you > please assist? The correct card is card 7 > > Sincerely, > > Marc Hello Marc, Do you actually know that the card=7 modprobe option works? The device profile for card 7 has a valid USB ID (0413:6023), suggesting that you might have a different version of the board. Can you take the unit apart and take some hi-resolution pictures of the PCB? That will tell us whether it is actually the same hardware. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-dvb] Anysee E30 C Plus + MPEG-4?
> Hi, > > I recently got the USB DVB-C tuner mentioned in the subject. > Everything seems to work fine, except that the MPEG-4 HD channels have no > video, only sound. Regular SD channels broadcasted in MPEG-2 are flawless. > > The tuner can receive MPEG-4 streams; decoder is not built in but Mplayer > would do the job if it could get the data. I have also tried in Window$ and > HD channels are working properly. > > I used w_scan to scan through the channels and it found almost everything > that the Win scanner did (one block is missing in linux though, probably > due to different scanning parameters needed but the win one is dumb and > won't tell me any useful information). > > My kernel: 2.6.30.5 > > Excerpt from dmesg: > dvb-usb: found a 'Anysee DVB USB2.0' in warm state. > dvb-usb: will pass the complete MPEG2 transport stream to the software > demuxer. DVB: registering new adapter (Anysee DVB USB2.0) > anysee: firmware version:0.1.2 hardware id:15 > DVB: registering adapter 0 frontend 0 (Philips TDA10023 DVB-C)... > input: IR-receiver inside an USB DVB receiver as /class/input/input3 > dvb-usb: schedule remote query interval to 200 msecs. > dvb-usb: Anysee DVB USB2.0 successfully initialized and connected. > > Any ideas on how I could start with my investigations? I took a quick peek > into the driver source but no story of mpeg 2/4 differences there. > > regards, > s. > > --- > > | Make it idiot proof and someone will make a better idiot. | > > --- I don't know if this helps but from my experience xine or any xine based player always did a better job with respect to dvb. Maybe you want to give it a try. Good luck, -- Luís Silva -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Update ALSA capture controls according to selected source.
The patch introduces new snd_saa7134_capsrc_set (code taken from
snd_saa7134_capsrc_put) that updates also the ALSA capture controls during
snd_card_saa7134_capture_prepare and snd_saa7134_capsrc_put.
There can be much more work done in order to unify the control of the card
(now the card's capture source is tuned/switched in saa7134-video.c too), but
I don't have enough time. This work could be a starting point, but it can be
applied as-is too (it doesn't need any further work to make it working).
Do whatever you want to do with the patch :-)
Signed-off-by: Oldřich Jedlička
diff --git a/linux/drivers/media/video/saa7134/saa7134-alsa.c
b/linux/drivers/media/video/saa7134/saa7134-alsa.c
index 2fa90c9..9767ad4 100644
--- a/linux/drivers/media/video/saa7134/saa7134-alsa.c
+++ b/linux/drivers/media/video/saa7134/saa7134-alsa.c
@@ -41,6 +41,7 @@ MODULE_PARM_DESC(debug,"enable debug messages [alsa]");
*/
/* defaults */
+#define MIXER_ADDR_UNSELECTED -1
#define MIXER_ADDR_TVTUNER 0
#define MIXER_ADDR_LINE1 1
#define MIXER_ADDR_LINE2 2
@@ -69,7 +70,9 @@ typedef struct snd_card_saa7134 {
struct snd_card *card;
spinlock_t mixer_lock;
int mixer_volume[MIXER_ADDR_LAST+1][2];
- int capture_source[MIXER_ADDR_LAST+1][2];
+ int capture_source_addr;
+ int capture_source[2];
+ struct snd_kcontrol *capture_ctl[MIXER_ADDR_LAST+1];
struct pci_dev *pci;
struct saa7134_dev *dev;
@@ -319,6 +322,104 @@ static int dsp_buffer_free(struct saa7134_dev *dev)
return 0;
}
+/*
+ * Setting the capture source and updating the ALSA controls
+ */
+static int snd_saa7134_capsrc_set(struct snd_kcontrol * kcontrol,
+ int left, int right, bool force_notify)
+{
+ snd_card_saa7134_t *chip = snd_kcontrol_chip(kcontrol);
+ int change = 0, addr = kcontrol->private_value;
+ int active, old_addr;
+ u32 anabar, xbarin;
+ int analog_io, rate;
+ struct saa7134_dev *dev;
+
+ dev = chip->dev;
+
+ spin_lock_irq(&chip->mixer_lock);
+
+ active = left != 0 || right != 0;
+ old_addr = chip->capture_source_addr;
+
+ /* The active capture source cannot be deactivated */
+ if (active) {
+ change = old_addr != addr ||
+chip->capture_source[0] != left ||
+chip->capture_source[1] != right;
+
+ chip->capture_source[0] = left;
+ chip->capture_source[1] = right;
+ chip->capture_source_addr = addr;
+ dev->dmasound.input = addr;
+ }
+ spin_unlock_irq(&chip->mixer_lock);
+
+ if (change) {
+ switch (dev->pci->device) {
+
+ case PCI_DEVICE_ID_PHILIPS_SAA7134:
+ switch (addr) {
+ case MIXER_ADDR_TVTUNER:
+ saa_andorb(SAA7134_AUDIO_FORMAT_CTRL, 0xc0,
0xc0);
+ saa_andorb(SAA7134_SIF_SAMPLE_FREQ, 0x03,
0x00);
+ break;
+ case MIXER_ADDR_LINE1:
+ case MIXER_ADDR_LINE2:
+ analog_io = (MIXER_ADDR_LINE1 == addr) ? 0x00 :
0x08;
+ rate = (32000 == dev->dmasound.rate) ? 0x01 :
0x03;
+ saa_andorb(SAA7134_ANALOG_IO_SELECT, 0x08,
analog_io);
+ saa_andorb(SAA7134_AUDIO_FORMAT_CTRL, 0xc0,
0x80);
+ saa_andorb(SAA7134_SIF_SAMPLE_FREQ, 0x03,
rate);
+ break;
+ }
+
+ break;
+ case PCI_DEVICE_ID_PHILIPS_SAA7133:
+ case PCI_DEVICE_ID_PHILIPS_SAA7135:
+ xbarin = 0x03; // adc
+ anabar = 0;
+ switch (addr) {
+ case MIXER_ADDR_TVTUNER:
+ xbarin = 0; // Demodulator
+ anabar = 2; // DACs
+ break;
+ case MIXER_ADDR_LINE1:
+ anabar = 0; // aux1, aux1
+ break;
+ case MIXER_ADDR_LINE2:
+ anabar = 9; // aux2, aux2
+ break;
+ }
+
+ /* output xbar always main channel */
+ saa_dsp_writel(dev, SAA7133_DIGITAL_OUTPUT_SEL1, 0x10);
+
+ if (left || right) { // We've got data, turn the input on
+ saa_dsp_writel(dev, SAA7133_DIGITAL_INPUT_XBAR1, xbarin);
+ saa_writel(SAA7133_ANALOG_IO_SELECT, anabar);
+ } else {
+ saa_dsp_writel(dev, SAA7133_DIGITAL_INPUT_XBAR1, 0);
+ saa_writel(SAA7133_ANALOG_IO_SELECT, 0);
+ }
+ break;
+ }
+ }
+
+ if (change) {
+ if
Re: [linux-dvb] Anysee E30 C Plus + MPEG-4?
On Tue, 18 Aug 2009, Pásztor Szilárd wrote: > direction so I'm a step further now. With scan -vv I could find the video PIDs > for the HD channels and indeed they were missing in my channels.conf (values > were 0) as scan detected them as "OTHER", but with a "type 0x1b" addition with > which I don't know what to do for the time being... Okay, so you are using a `channels.conf' file, which is used for tuning directly by `mplayer' into a particular service. The `scan' utility you use does not recognise the H.264 video service as a video stream, which is why you don't get that as your video PID. A common problem, I would guess. > After adding the correct PID values, mplayer still can't demux the incoming > stream but the video is there, and with -dumpvideo a h264 elementary stream > gets produced in the file that can be played back if I specify -demuxer > h264es on the command line. What are beyond me now are: > 1) how can mplayer not demux the stream if it can dump the video out > (shouldn't a video dump involve a demux operation before all?) `mplayer' does not (yet?) understand native H.264 video. Whether this is purely an `mplayer' limitation, or something which also will affect other players, I cannot say -- I haven't looked into this. As a result, even if you have both the video and audio PIDs in your stream, you still need the additional PID from which `mplayer' can get the needed identification of the video as H.264. This is found in the PMT PID (for BBC-HD in my example, 258 or whatever 3-digit PID was there -- my memory is going...) I said it before and I'll say it again, what `mplayer' needs is -- I mean, I don't know if it would be possible for `mplayer' to identify the video as H.264, but for me, it needs this additional PID stream to do that. That is something for the `mplayer' developers or for someone more familiar with H.264 in DVB to answer. I'm guessing your `channels.conf' file is simple with one field for video and one for audio, but no extra fields. If this is the case, then what you will need to do as a test would be to write more of the stream to a file; the example I gave in my earlier reply for BBC-HD is what I pass to `dvbstream'. Then `mplayer' should be able to play this file with no problems. > 2) is it a missing feature of mplayer that no metastream is processed that > would carry the necessary information about the muxed streams? It would be Like I say, I don't know if the video stream alone contains the needed info that in theory `mplayer' could identify it as H.264. Although it is outside of your reception as is BBC-HD via satellite, the british ITV HD service is broadcast as H.264 but without a stream identifying it as such. As a result, I've had to hack `mplayer' to treat the video as such in order to be able to watch the recordings I've made. Note that my observations are made about `mplayer' from almost a year ago, and if there have been changes made since, such as a more comprehensive `channels.conf' file, I'm not aware of them. Hope this helps to understand your problem a bit better... barry bouwsma -- 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] Anysee E30 C Plus + MPEG-4?
Thanks for the comprehensive answer. Mr. Thommeret's hint about the missing video PID pushed me into the right direction so I'm a step further now. With scan -vv I could find the video PIDs for the HD channels and indeed they were missing in my channels.conf (values were 0) as scan detected them as "OTHER", but with a "type 0x1b" addition with which I don't know what to do for the time being... After adding the correct PID values, mplayer still can't demux the incoming stream but the video is there, and with -dumpvideo a h264 elementary stream gets produced in the file that can be played back if I specify -demuxer h264es on the command line. What are beyond me now are: 1) how can mplayer not demux the stream if it can dump the video out (shouldn't a video dump involve a demux operation before all?) 2) is it a missing feature of mplayer that no metastream is processed that would carry the necessary information about the muxed streams? It would be adequate for me if I could specify a demuxer to use but it seems impossible in just one step - which I currently don't understand because an elementary stream is dumped as video. s. BOUWSMA Barry: > `mplayer' assumes a MPEG-2 video stream by default unless it is > told otherwise by the additional metadata carried outside the > video PID stream. That means you need to feed mplayer with not > only the video and audio streams, but also the PMT stream which > identifies the video as H.264. - | Friends may come and go but enemies accumulate. | - -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Report only 32kHz for ALSA
There are several reasons: - SAA7133/35 uses DDEP (DemDec Easy Programming mode), which works in 32kHz only - SAA7134 for TV mode uses DemDec mode (32kHz) - Radio works in 32kHz only - When recording 48kHz from Line1/Line2, switching of capture source to TV means switching to 32kHz without any frequency translation Signed-off-by: Oldřich Jedlička diff --git a/linux/drivers/media/video/saa7134/saa7134-alsa.c b/linux/drivers/media/video/saa7134/saa7134-alsa.c index c09ec3e..504186a 100644 --- a/linux/drivers/media/video/saa7134/saa7134-alsa.c +++ b/linux/drivers/media/video/saa7134/saa7134-alsa.c @@ -440,6 +440,16 @@ snd_card_saa7134_capture_pointer(struct snd_pcm_substream * substream) /* * ALSA hardware capabilities definition + * + * Report only 32kHz for ALSA: + * + * - SAA7133/35 uses DDEP (DemDec Easy Programming mode), which works in 32kHz + *only + * - SAA7134 for TV mode uses DemDec mode (32kHz) + * - Radio works in 32kHz only + * - When recording 48kHz from Line1/Line2, switching of capture source to TV + *means + *switching to 32kHz without any frequency translation */ static struct snd_pcm_hardware snd_card_saa7134_capture = @@ -453,9 +463,9 @@ static struct snd_pcm_hardware snd_card_saa7134_capture = SNDRV_PCM_FMTBIT_U8 | \ SNDRV_PCM_FMTBIT_U16_LE | \ SNDRV_PCM_FMTBIT_U16_BE, - .rates =SNDRV_PCM_RATE_32000 | SNDRV_PCM_RATE_48000, + .rates =SNDRV_PCM_RATE_32000, .rate_min = 32000, - .rate_max = 48000, + .rate_max = 32000, .channels_min = 1, .channels_max = 2, .buffer_bytes_max = (256*1024), -- 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] Anysee E30 C Plus + MPEG-4?
2009/8/18 Pásztor Szilárd : > Thanks for the comprehensive answer. > Mr. Thommeret's hint about the missing video PID pushed me into the right > direction so I'm a step further now. With scan -vv I could find the video PIDs > for the HD channels and indeed they were missing in my channels.conf (values > were 0) as scan detected them as "OTHER", but with a "type 0x1b" addition with > which I don't know what to do for the time being... > > After adding the correct PID values, mplayer still can't demux the incoming > stream but the video is there, and with -dumpvideo a h264 elementary stream > gets produced in the file that can be played back if I specify -demuxer > h264es on the command line. What are beyond me now are: > 1) how can mplayer not demux the stream if it can dump the video out > (shouldn't a video dump involve a demux operation before all?) > 2) is it a missing feature of mplayer that no metastream is processed that > would carry the necessary information about the muxed streams? It would be > adequate for me if I could specify a demuxer to use but it seems impossible in > just one step - which I currently don't understand because an elementary > stream is dumped as video. > You might try: dvbstream -o 8192 | mplayer -cache 10240 - this forwards the entire stream to mplayer, you can switch the channels with [tab] Regards, Markus -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[cron job] v4l-dvb daily build 2.6.22 and up: ERRORS, 2.6.16-2.6.21: ERRORS
This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below. Results of the daily build of v4l-dvb: date:Tue Aug 18 19:00:03 CEST 2009 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 12458:3f7e382dfae5 gcc version: gcc (GCC) 4.3.1 hardware:x86_64 host os: 2.6.26 linux-2.6.22.19-armv5: OK linux-2.6.23.12-armv5: OK linux-2.6.24.7-armv5: OK linux-2.6.25.11-armv5: OK linux-2.6.26-armv5: OK linux-2.6.27-armv5: OK linux-2.6.28-armv5: OK linux-2.6.29.1-armv5: OK linux-2.6.30-armv5: OK linux-2.6.31-rc5-armv5: OK linux-2.6.27-armv5-ixp: OK linux-2.6.28-armv5-ixp: OK linux-2.6.29.1-armv5-ixp: OK linux-2.6.30-armv5-ixp: OK linux-2.6.31-rc5-armv5-ixp: OK linux-2.6.28-armv5-omap2: OK linux-2.6.29.1-armv5-omap2: OK linux-2.6.30-armv5-omap2: OK linux-2.6.31-rc5-armv5-omap2: OK linux-2.6.22.19-i686: ERRORS linux-2.6.23.12-i686: ERRORS linux-2.6.24.7-i686: OK linux-2.6.25.11-i686: OK linux-2.6.26-i686: OK linux-2.6.27-i686: OK linux-2.6.28-i686: OK linux-2.6.29.1-i686: WARNINGS linux-2.6.30-i686: WARNINGS linux-2.6.31-rc5-i686: OK linux-2.6.23.12-m32r: ERRORS linux-2.6.24.7-m32r: OK linux-2.6.25.11-m32r: OK linux-2.6.26-m32r: OK linux-2.6.27-m32r: OK linux-2.6.28-m32r: OK linux-2.6.29.1-m32r: OK linux-2.6.30-m32r: OK linux-2.6.31-rc5-m32r: OK linux-2.6.30-mips: WARNINGS linux-2.6.31-rc5-mips: OK linux-2.6.27-powerpc64: OK linux-2.6.28-powerpc64: OK linux-2.6.29.1-powerpc64: WARNINGS linux-2.6.30-powerpc64: WARNINGS linux-2.6.31-rc5-powerpc64: OK linux-2.6.22.19-x86_64: ERRORS linux-2.6.23.12-x86_64: ERRORS linux-2.6.24.7-x86_64: OK linux-2.6.25.11-x86_64: OK linux-2.6.26-x86_64: OK linux-2.6.27-x86_64: OK linux-2.6.28-x86_64: OK linux-2.6.29.1-x86_64: WARNINGS linux-2.6.30-x86_64: WARNINGS linux-2.6.31-rc5-x86_64: OK sparse (linux-2.6.30): OK sparse (linux-2.6.31-rc5): OK linux-2.6.16.61-i686: ERRORS linux-2.6.17.14-i686: ERRORS linux-2.6.18.8-i686: ERRORS linux-2.6.19.5-i686: ERRORS linux-2.6.20.21-i686: ERRORS linux-2.6.21.7-i686: ERRORS linux-2.6.16.61-x86_64: ERRORS linux-2.6.17.14-x86_64: ERRORS linux-2.6.18.8-x86_64: ERRORS linux-2.6.19.5-x86_64: ERRORS linux-2.6.20.21-x86_64: ERRORS linux-2.6.21.7-x86_64: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Tuesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Tuesday.tar.bz2 The V4L2 specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/v4l2.html The DVB API specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/dvbapi.pdf -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v1 - 1/5] DaVinci - restructuring code to support vpif capture driver
Em Tue, 18 Aug 2009 11:06:54 -0500 "Karicheri, Muralidharan" escreveu: > Mauro, > > I need to send a set of patches for adding vpif capture driver. Currently the > linux-next doesn't have the last patch from Chaithrika applied for vpif > display. Is it possible to apply this asap so that I can create the vpif > capture patch today? Sure. Could you please point me what's the patchwork ID(s)[1] of the patch you need me to apply at our development tree and at linux-next? [1] http://patchwork.kernel.org/project/linux-media/list/ Cheers, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-dvb] Anysee E30 C Plus + MPEG-4?
Le Tuesday 18 August 2009 17:08:20 Pásztor Szilárd, vous avez écrit : > Hi, > > I recently got the USB DVB-C tuner mentioned in the subject. > Everything seems to work fine, except that the MPEG-4 HD channels have no > video, only sound. Regular SD channels broadcasted in MPEG-2 are flawless. > > The tuner can receive MPEG-4 streams; decoder is not built in but Mplayer > would do the job if it could get the data. I have also tried in Window$ and > HD channels are working properly. > > I used w_scan to scan through the channels and it found almost everything > that the Win scanner did (one block is missing in linux though, probably > due to different scanning parameters needed but the win one is dumb and > won't tell me any useful information). > > My kernel: 2.6.30.5 > > Excerpt from dmesg: > dvb-usb: found a 'Anysee DVB USB2.0' in warm state. > dvb-usb: will pass the complete MPEG2 transport stream to the software > demuxer. DVB: registering new adapter (Anysee DVB USB2.0) > anysee: firmware version:0.1.2 hardware id:15 > DVB: registering adapter 0 frontend 0 (Philips TDA10023 DVB-C)... > input: IR-receiver inside an USB DVB receiver as /class/input/input3 > dvb-usb: schedule remote query interval to 200 msecs. > dvb-usb: Anysee DVB USB2.0 successfully initialized and connected. > > Any ideas on how I could start with my investigations? I took a quick peek > into the driver source but no story of mpeg 2/4 differences there. Not a driver issue. Maybe mplayer doesn't autodetect h264, or maybe the h264 stream's pid is missing in your channels.conf -- Christophe Thommeret -- 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 v1 - 1/5] DaVinci - restructuring code to support vpif capture driver
Mauro, I need to send a set of patches for adding vpif capture driver. Currently the linux-next doesn't have the last patch from Chaithrika applied for vpif display. Is it possible to apply this asap so that I can create the vpif capture patch today? Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 new phone: 301-407-9583 Old Phone : 301-515-3736 (will be deprecated) email: m-kariche...@ti.com >-Original Message- >From: Hans Verkuil [mailto:hverk...@xs4all.nl] >Sent: Tuesday, August 18, 2009 2:51 AM >To: Karicheri, Muralidharan >Cc: linux-media@vger.kernel.org; davinci-linux-open- >sou...@linux.davincidsp.com; khil...@deeprootsystems.com >Subject: Re: [PATCH v1 - 1/5] DaVinci - restructuring code to support vpif >capture driver > >On Tuesday 18 August 2009 08:49:13 Hans Verkuil wrote: >> On Tuesday 18 August 2009 01:23:10 Karicheri, Muralidharan wrote: >> > Hans, >> > >> > I have re-send vpfe capture patch. I will re-send vpif patches tomorrow. >> >> These patches apply fine. I'll merge them in my v4l-dvb-dm646x tree >tonight. > >Oops, wrong tree. It's v4l-dvb-vpif. > >Regards, > > Hans > >-- >Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
CX24123 no FE_HAS_LOCK/tuning failed
Hi John, Rex, As an extra data-point: John's patch worked fine for me (Quad LNB with integrated switch for Astra-28.2E). I'd really like to build on John's patch to work up a full fix. To do this I'm trying to track down a cx24123 datasheet. I don't suppose either of you guys has a pdf? cheers, Andrew -- 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
em28xx and tuner eb1a:2881 -> temporary solution
28xx #0: Config register raw data: 0x58 [10864.517385] em28xx #0: AC97 vendor ID = 0x [10864.517914] em28xx #0: AC97 features = 0x6a90 [10864.517920] em28xx #0: Empia 202 AC97 audio processor detected [10864.728935] em28xx #0: v4l2 driver version 0.1.2 [10864.800468] em28xx #0: V4L2 device registered as /dev/video1 and /dev/vbi0 [10864.822120] usbcore: registered new interface driver em28xx [10864.822129] em28xx driver loaded [10864.865858] em28xx #0/2: xc3028 attached [10864.865861] DVB: registering new adapter (em28xx #0) [10864.866164] Successfully loaded em28xx-dvb " Thanks for the your support and if there are news you contact me. Regards, Emanuele -- Caselle da 1GB, trasmetti allegati fino a 3GB e in piu' IMAP, POP3 e SMTP autenticato? GRATIS solo con Email.it: http://www.email.it/f Sponsor: Ricevi e invia messaggi di posta, instant messaging e rimani in contatto ovunque ti trovi direttamente dal cellulare, con m.email. Provalo gratuitamente Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=8920&d=20090818 -- 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] au0828: experimental support for Syntek Teledongle [05e1:0400]
On Tue, Aug 18, 2009 at 7:00 AM, Johannes Stezenbach wrote: > I would be interested to know if someone _actually_ managed > to break their hardware by using buggy drivers. The short answer is *absolutely*. /me takes off "driver developer hat" and puts on "hardware developer hat" In a world of flash, eeproms, and software programmable clocks, there are all sorts of ways where a driver bug can damage the hardware. Looking for some simple examples? 1. Think of the "overclocking" community and what happens when they reconfigure a GPU's software controlled clock to perform beyond its maximum expected rating without extra cooling. 2. Think of all the reports of corrupted eeproms you read about on the mailing list. Sure, in many cases a good developer can hack a way to reprogram the eeprom in software, but in many cases the board won't even come up, so you end up with an RMA. It's not "damaged" in the more traditional sense, but the net effect is the same - the board is rendered inoperable and has to be sent back to the manufacturer. 3. Try loading the xc3028 tuner firmware onto the low power version of the chip (xc3028l). It took me a minute before I realized the smell of burning plastic was coming from my tuner. Don't get me wrong, in many cases things can be designed into the hardware to mitigate the effects of software bugs. In any hardware design, your goal is to minimize the return rate, so you build failsafes for the most likely to occur problems. However, in many cases this adds additional cost to the BOM, and you make educated decisions about the probability of certain classes of failure and instead build the reliability into the driver instead (making sure that the Windows driver can *never* put the hardware into a state). A random open source developer doesn't know what these sorts of decisions were, and would not be able to replicate the corresponding checks in a Linux driver. 4. Ever see a user complaint of how a tuner runs "hot" under Linux compared to the same device running under Windows? Almost certainly an improperly GPIO configuration which resulted in a condition such as having the digital demod powered on at the same time as the analog decoder. Sure, it will work for a while but you're running the device outside of the expected thermal profile and shortening the life of the hardware. The above are just a few *simple* examples. The nastier ones are often too difficult to explain in less than fifty words. > IANAL but > I think that consumer electronics hardware which can be damaged by > software is broken by design. A vendor selling such hardware is > stupid because people would return the broken hardware and get > a replacement. I don't see how a vendor could proof that the device > was not damaged by an obscure bug in the Windows driver to get > around their responsibility to replace broken hardware within > the warranty period. Yeah, you're right. Usually they cannot tell right away and will perform an RMA. And the board will end up on a lab bench with a hardware engineering isolating which component failed, and then working with the driver developer trying to figure out how the hell their Windows driver put the board in such a state. The risk of trusting some random Linux developer's driver work is a reason why some vendors don't want to support Linux. If I were a vendor, and I endorsed a Linux driver written by someone without the appropriate knowledge of the hardware, I could end up with large number of product returns, and I would incur the cost of those losses. Also, in many cases the board doesn't burn out immediately. But because of crappy drivers it takes three or four months to burn out, and the result is a board that is designed to run without problems for tens of thousands of hours dies in a significantly shorter time. Good device driver developers realize and accept this risk whenever they attempt to write a reverse engineered driver. I certainly don't want to discourage people from learning how to write Linux drivers for tuners, but caveat emptor - you can end up permanently damaging your hardware. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 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
[Request for testing] new dib0700 code (was: Re: dib0700 diversity support)
Dear Patrick, Am Dienstag, den 18.08.2009, 12:27 +0200 schrieb Patrick Boettcher: > On Tue, 18 Aug 2009, Paul Menzel wrote: > > Am Dienstag, den 18.08.2009, 10:54 +0200 schrieb Patrick Boettcher: > >> On Fri, 14 Aug 2009, Paul Menzel wrote: > I'll post a request for testing soon. > >>> > >>> I am looking forward to it. > >> > >> Can you please try the drivers from here: > >> http://linuxtv.org/hg/~pb/v4l-dvb/ > > > > I installed it as described in [1]. > > > ># clone > >make > >sudo make install > >sudo make unload > ># insert stick again > > > > [1] http://sidux.com/module-Wikula-history-tag-TerraTec.html […] > > Ok, I do not know how to test this objectively. Not knowing what how to > > do this, I just insert the console output of Kaffeine while scanning for > > channels. See the end of this message. Are those values showing the signal strength? > > In summary I would they I did not see any difference in quality between > > the two versions at a bad reception spot. I thought the signal bar > > showed values increased by 2?4 %, so a little bit better. > > Can be weather conditions I tested both version in a 30 minutes time frame. > The SNR could give a clue how far you are away from receiving, but it is > currently not implemented. > > I hate to request it, but can you try the windows driver with the device > without touching the antenna at that point. Like that we can exclude any Well, I cannot do it right now. But I can test it the Wednesday next week. I hope this is alright. Maybe some other people can test it sooner. (I therefore changed the subject.) Thanks, Paul signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [linux-dvb] au0828: experimental support for Syntek Teledongle [05e1:0400]
On Mon, Aug 17, 2009 at 04:59:42PM -0400, Michael Krufky wrote: > > variations, nobody has ever verified that the GPIO programming is safe > to use, and there is no way to prevent the potentially harmful code > from running on the wrong device. > > I, personally, do not want the responsibility of explaining to users > that their usb sticks may be damaged because of code that got merged I would be interested to know if someone _actually_ managed to break their hardware by using buggy drivers. IANAL but I think that consumer electronics hardware which can be damaged by software is broken by design. A vendor selling such hardware is stupid because people would return the broken hardware and get a replacement. I don't see how a vendor could proof that the device was not damaged by an obscure bug in the Windows driver to get around their responsibility to replace broken hardware within the warranty period. Johannes -- 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: dib0700 diversity support
On Tue, 18 Aug 2009, Nicolas Will wrote: Patrick Boettcher wrote: On Tue, 18 Aug 2009, Nicolas Will wrote: This change should improve reception conditions for devices based on the DiB0070-tuner (DiB7070P e.g) . We tried this driver with our reference boards and it works well, but sometimes DiBcom's customers are adding things, DiBcom is not really aware of. That's why there is a risk that it breaks supports for some cards. Well, breakage is easier to notice! I can test on the Nova-T 500. For you _nothing_ should change. The Nova-T is using dib3000mc+mt2060. If it does not work for you any longer, something else is broken. If it works better for you, it's simply magic. Well then, I'll step out of the way and leave the testing to relevant people! So why does dib0070 appear in my lsmod? Because the dib0700 is using it for some layouts it supports. And it requires all modules to be loaded in case such a device is plugged. -- Patrick Boettcher - 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: dib0700 diversity support
Patrick Boettcher wrote: On Tue, 18 Aug 2009, Nicolas Will wrote: This change should improve reception conditions for devices based on the DiB0070-tuner (DiB7070P e.g) . We tried this driver with our reference boards and it works well, but sometimes DiBcom's customers are adding things, DiBcom is not really aware of. That's why there is a risk that it breaks supports for some cards. Well, breakage is easier to notice! I can test on the Nova-T 500. For you _nothing_ should change. The Nova-T is using dib3000mc+mt2060. If it does not work for you any longer, something else is broken. If it works better for you, it's simply magic. Well then, I'll step out of the way and leave the testing to relevant people! So why does dib0070 appear in my lsmod? Nico -- 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: dib0700 diversity support
On Tue, 18 Aug 2009, Nicolas Will wrote: This change should improve reception conditions for devices based on the DiB0070-tuner (DiB7070P e.g) . We tried this driver with our reference boards and it works well, but sometimes DiBcom's customers are adding things, DiBcom is not really aware of. That's why there is a risk that it breaks supports for some cards. Well, breakage is easier to notice! I can test on the Nova-T 500. For you _nothing_ should change. The Nova-T is using dib3000mc+mt2060. If it does not work for you any longer, something else is broken. If it works better for you, it's simply magic. -- Patrick 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: dib0700 diversity support
Patrick Boettcher wrote: Hi Nicolas, On Tue, 18 Aug 2009, Nicolas Will wrote: Patrick Boettcher wrote: Hi Paul, On Fri, 14 Aug 2009, Paul Menzel wrote: I'll post a request for testing soon. I am looking forward to it. Can you please try the drivers from here: http://linuxtv.org/hg/~pb/v4l-dvb/ In the best case they improve the situation for you. In the worst case (not wanted :) ) it will degrade. Hi Patrick, Could you give us a summary of what changes are included in you tree, what we should expect, what we should test for and report on? Yeah, sorry, I'm not very professional: bo! ;o) Let's list first the commits: DiB8000: fix channel search parameter initialization DiB0700: add support for STK807XP and STK807XPVR DiB8000: added support for DiBcom ISDB-T/ISDB-Tsb demodulator DiB8000 DiB0070: Indenting driver with indent -linux DiB0070: Update to latest internal release As you can see, there are a lot of new things, the most important for users of existing devices is the 'DiB0070: Update to latest internal release' . This change should improve reception conditions for devices based on the DiB0070-tuner (DiB7070P e.g) . Fine. Now, how do I measure this objectively so that I can give you meaningful results (before/after)? My system is currntly working fine, using a hg clone from quite a few months ago, so if things are not directly visible... We tried this driver with our reference boards and it works well, but sometimes DiBcom's customers are adding things, DiBcom is not really aware of. That's why there is a risk that it breaks supports for some cards. Well, breakage is easier to notice! I can test on the Nova-T 500. n...@favia:~$ lsmod | grep dib dvb_usb_dib070054536 16 dib7000p 27400 1 dvb_usb_dib0700 dib7000m 24964 1 dvb_usb_dib0700 dvb_usb27148 2 dvb_usb_dtt200u,dvb_usb_dib0700 dib3000mc 22280 3 dvb_usb_dib0700 dibx000_common 12292 3 dib7000p,dib7000m,dib3000mc dib007016772 1 dvb_usb_dib0700 Nico -- 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: dib0700 diversity support
Hi On Tue, 18 Aug 2009, Paul Menzel wrote: Dear Patrick, Am Dienstag, den 18.08.2009, 10:54 +0200 schrieb Patrick Boettcher: On Fri, 14 Aug 2009, Paul Menzel wrote: I'll post a request for testing soon. I am looking forward to it. Can you please try the drivers from here: http://linuxtv.org/hg/~pb/v4l-dvb/ I installed it as described in [1]. # clone make sudo make install sudo make unload # insert stick again [1] http://sidux.com/module-Wikula-history-tag-TerraTec.html Thanks for your work. Do I also need to update the firmware file? No. Ok, I do not know how to test this objectively. Not knowing what how to do this, I just insert the console output of Kaffeine while scanning for channels. See the end of this message. In summary I would they I did not see any difference in quality between the two versions at a bad reception spot. I thought the signal bar showed values increased by 2?4 %, so a little bit better. Can be weather conditions The SNR could give a clue how far you are away from receiving, but it is currently not implemented. I hate to request it, but can you try the windows driver with the device without touching the antenna at that point. Like that we can exclude any -- Patrick Boettcher - 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: dib0700 diversity support
Dear Patrick, Am Dienstag, den 18.08.2009, 10:54 +0200 schrieb Patrick Boettcher: > On Fri, 14 Aug 2009, Paul Menzel wrote: > >> I'll post a request for testing soon. > > > > I am looking forward to it. > > Can you please try the drivers from here: > http://linuxtv.org/hg/~pb/v4l-dvb/ I installed it as described in [1]. # clone make sudo make install sudo make unload # insert stick again [1] http://sidux.com/module-Wikula-history-tag-TerraTec.html Thanks for your work. Do I also need to update the firmware file? > In the best case they improve the situation for you. In the worst case > (not wanted :) ) it will degrade. Ok, I do not know how to test this objectively. Not knowing what how to do this, I just insert the console output of Kaffeine while scanning for channels. See the end of this message. In summary I would they I did not see any difference in quality between the two versions at a bad reception spot. I thought the signal bar showed values increased by 2–4 %, so a little bit better. I will test later at a better reception point. Thanks for your work, Paul ### Old Version 2.6.30.4, amd64 ### • tested channel between 40 and 44 % signal shown by Kaffeine /dev/dvb/adapter0/frontend0 : opened ( DiBcom 7000PC ) /dev/dvb/adapter1/frontend0 : opened ( DiBcom 7000PC ) 0 EPG plugins loaded for device 0:0. 0 EPG plugins loaded for device 1:0. Loaded epg data : 0 events (0 msecs) Tuning to: TSID:769-SID:16408 / autocount: 0 DvbCam::probe(): /dev/dvb/adapter0/ca0: : Datei oder Verzeichnis nicht gefunden Using DVB device 0:0 "DiBcom 7000PC" tuning DVB-T to 65800 Hz inv:2 bw:0 fecH:9 fecL:9 mod:6 tm:2 gi:4 hier:4 . LOCKED. NOUT: 1 dvbEvents 0:0 started Tuning delay: 850 ms pipe opened demux_wavpack: (open_wv_file:127) open_wv_file: non-seekable inputs aren't supported yet. xine pipe opened /home/paul/.kaxtv.ts DvbCam::probe(): /dev/dvb/adapter1/ca0: : Datei oder Verzeichnis nicht gefunden Invalid section length or timeout: pid=17 Invalid section length or timeout: pid=0 dvbsi: The end :) Channels found: 0 Asked to stop pipe closed Live stopped dvbstream::run() end dvbEvents 0:0 ended fdDvr closed Frontend closed Using DVB device 0:0 "DiBcom 7000PC" tuning DVB-T to 17750 Hz inv:2 bw:1 fecH:9 fecL:9 mod:6 tm:2 gi:4 hier:4 ... LOCKED. Transponders: 1/57 scanMode=0 it's dvb 2! Invalid section length or timeout: pid=17 Invalid section length or timeout: pid=0 Frontend closed Using DVB device 0:0 "DiBcom 7000PC" tuning DVB-T to 18450 Hz inv:2 bw:1 fecH:9 fecL:9 mod:6 tm:2 gi:4 hier:4 ... Not able to lock to the signal on the given frequency Frontend closed dvbsi: Cant tune DVB Using DVB device 0:0 "DiBcom 7000PC" tuning DVB-T to 19150 Hz inv:2 bw:1 fecH:9 fecL:9 mod:6 tm:2 gi:4 hier:4 ... Not able to lock to the signal on the given frequency Frontend closed dvbsi: Cant tune DVB Using DVB device 0:0 "DiBcom 7000PC" tuning DVB-T to 19850 Hz inv:2 bw:1 fecH:9 fecL:9 mod:6 tm:2 gi:4 hier:4 ... Not able to lock to the signal on the given frequency Frontend closed dvbsi: Cant tune DVB Using DVB device 0:0 "DiBcom 7000PC" tuning DVB-T to 20550 Hz inv:2 bw:1 fecH:9 fecL:9 mod:6 tm:2 gi:4 hier:4 ... Not able to lock to the signal on the given frequency Frontend closed dvbsi: Cant tune DVB Using DVB device 0:0 "DiBcom 7000PC" tuning DVB-T to 21250 Hz inv:2 bw:1 fecH:9 fecL:9 mod:6 tm:2 gi:4 hier:4 ... Not able to lock to the signal on the given frequency Frontend closed dvbsi: Cant tune DVB Using DVB device 0:0 "DiBcom 7000PC" tuning DVB-T to 21950 Hz inv:2 bw:1 fecH:9 fecL:9 mod:6 tm:2 gi:4 hier:4 ... Not able to lock to the signal on the given frequency Frontend closed dvbsi: Cant tune DVB Using DVB device 0:0 "DiBcom 7000PC" tuning DVB-T to 22650 Hz inv:2 bw:1 fecH:9 fecL:9 mod:6 tm:2 gi:4 hier:4 ... Not able to lock to the signal on the given frequency Frontend closed dvbsi: Cant tune DVB Using DVB device 0:0 "DiBcom 7000PC" tuning DVB-T to 47400 Hz inv:2 bw:0 fecH:9 fecL:9 mod:6 tm:2 gi:4 hier:4 ... Not able to lock to the signal on the given frequency Frontend closed dvbsi: Cant tune DVB Using DVB device 0:0 "DiBcom 7000PC" tuning DVB-T to 48200 Hz inv:2 bw:0 fecH:9 fecL:9 mod:6 tm:2 gi:4 hier:4 ... Not able to lock to the signal on the given frequency Frontend closed dvbsi: Cant tune DVB Using DVB device 0:0 "DiBcom 7000PC" tuning DVB-T to 49000 Hz inv:2 bw:0 fecH:9 fecL:9 mod:6 tm:2 gi:4 hier:4 ... Not able to lock to the signal on the given frequency Frontend closed dvbsi: Cant tune DVB Using DVB device 0:0 "DiBcom 7000PC" tuning DVB-T to 49800 Hz inv:2 bw:0 fecH:9 fecL:9 mod:6 tm:2 gi:4 hier:4 ... Not able to lock to the signal on the given frequency Frontend closed dvbsi: Cant tune DVB Using DVB device 0:0 "DiBcom 7000PC" tuning DVB-T to 50600 Hz inv
Re: dib0700 diversity support
Hi Nicolas, On Tue, 18 Aug 2009, Nicolas Will wrote: Patrick Boettcher wrote: Hi Paul, On Fri, 14 Aug 2009, Paul Menzel wrote: I'll post a request for testing soon. I am looking forward to it. Can you please try the drivers from here: http://linuxtv.org/hg/~pb/v4l-dvb/ In the best case they improve the situation for you. In the worst case (not wanted :) ) it will degrade. Hi Patrick, Could you give us a summary of what changes are included in you tree, what we should expect, what we should test for and report on? Yeah, sorry, I'm not very professional: Let's list first the commits: DiB8000: fix channel search parameter initialization DiB0700: add support for STK807XP and STK807XPVR DiB8000: added support for DiBcom ISDB-T/ISDB-Tsb demodulator DiB8000 DiB0070: Indenting driver with indent -linux DiB0070: Update to latest internal release As you can see, there are a lot of new things, the most important for users of existing devices is the 'DiB0070: Update to latest internal release' . This change should improve reception conditions for devices based on the DiB0070-tuner (DiB7070P e.g) . We tried this driver with our reference boards and it works well, but sometimes DiBcom's customers are adding things, DiBcom is not really aware of. That's why there is a risk that it breaks supports for some cards. -- Patrick 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: dib0700 diversity support
Patrick Boettcher wrote: Hi Paul, On Fri, 14 Aug 2009, Paul Menzel wrote: I'll post a request for testing soon. I am looking forward to it. Can you please try the drivers from here: http://linuxtv.org/hg/~pb/v4l-dvb/ In the best case they improve the situation for you. In the worst case (not wanted :) ) it will degrade. Hi Patrick, Could you give us a summary of what changes are included in you tree, what we should expect, what we should test for and report on? Thanks! Nico -- 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: Unable to get IR Remote working (Hauppauge HVR-1110/1120(?))
Hello All I have a Hauppauge HVR-1100 up and running. The V4L modules detect it as a HVR-1120 (dmesg & lsmod attached). I'm using the v4l source, checked out yesterday evening. TV/Radio works fine with mythtv. However, there is no sign of the IR remote. The saa7134 module detects an IR receiver, however no device nodes or entries in /proc/bus/input/devices are created (also attached). I'm using the latest LIRC source, also checked out from the repository yesterday. I tried lirc_i2c as found in some how-to's. dev/input will obviously not work (no input device created). Can anyone guide me into the right direction, or tell me how to debug this further? Thank you and kind regards Flavio Curti -- http://no-way.org/ [0.] Initializing cgroup subsys cpuset [0.] Initializing cgroup subsys cpu [0.] Linux version 2.6.30-02063004-generic (r...@zinc) (gcc version 4.2.3 (Ubuntu 4.2.3-2ubuntu7)) #02063004 SMP Fri Jul 31 10:59:10 UTC 2009 [0.] KERNEL supported cpus: [0.] Intel GenuineIntel [0.] AMD AuthenticAMD [0.] NSC Geode by NSC [0.] Cyrix CyrixInstead [0.] Centaur CentaurHauls [0.] Transmeta GenuineTMx86 [0.] Transmeta TransmetaCPU [0.] UMC UMC UMC UMC [0.] BIOS-provided physical RAM map: [0.] BIOS-e820: ?M4?M4? - ?M49f800 (usable) [0.] BIOS-e820: ?M49f800 - ?M4?M4k (reserved) [0.] BIOS-e820: ?M4?M4 - ?M4?M5? (reserved) [0.] BIOS-e820: ?M4?M5? - ?M4?~? (usable) [0.] BIOS-e820: ?M4?~? - ?M4?~? (ACPI NVS) [0.] BIOS-e820: ?M4?~? - ?M4?~?? (ACPI data) [0.] BIOS-e820: ?M4?4? - ?M4?4? (reserved) [0.] BIOS-e820: ?M4??4? - ?M4??4? (reserved) [0.] BIOS-e820: ?M4 - ?M4?M4? (reserved) [0.] DMI 2.3 present. [0.] Phoenix BIOS detected: BIOS may corrupt low RAM, working around it. [0.] e820 update range: ?M4?M4? - ?M4?M4? (usable) ==> (reserved) [0.] last_pfn = 0x37ef0 max_arch_pfn = 0x10 [0.] MTRR default type: uncachable [0.] MTRR fixed ranges enabled: [0.] 0-9 write-back [0.] A-B uncachable [0.] C-C7FFF write-protect [0.] C8000-F uncachable [0.] MTRR variable ranges enabled: [0.] 0 base ?M4 mask FFE write-back [0.] 1 base 002 mask FFF write-back [0.] 2 base 003 mask FFF8 write-back [0.] 3 base 0037F0 mask F0 uncachable [0.] 4 disabled [0.] 5 disabled [0.] 6 disabled [0.] 7 disabled [0.] Scanning 0 areas for low memory corruption [0.] modified physical RAM map: [0.] modified: ?M4?M4? - ?M4?M4? (reserved) [0.] modified: ?M4?M4? - ?M49f800 (usable) [0.] modified: ?M49f800 - ?M4?M4k (reserved) [0.] modified: ?M4?M4 - ?M4?M5? (reserved) [0.] modified: ?M4?M5? - ?M4?~? (usable) [0.] modified: ?M4?~? - ?M4?~? (ACPI NVS) [0.] modified: ?M4?~? - ?M4?~?? (ACPI data) [0.] modified: ?M4?4? - ?M4?4? (reserved) [0.] modified: ?M4??4? - ?M4??4? (reserved) [0.] modified: ?M4 - ?M4?M4? (reserved) [0.] init_memory_mapping: ?M4?M4?-?M4?~?} [0.] ?M4 - ?4 page 4k [0.] ?4 - 003740 page 2M [0.] 003740 - 00377fe000 page 4k [0.] kernel direct mapping tables up to 377fe000 @ 1-15000 [0.] RAMDISK: 37798000 - 37edf89a [0.] Allocated new RAMDISK: 0083a000 - 00f8189a [0.] Move RAMDISK from ?M4?~?? - ?37edf899 to 0083a000 - 00f81899 [0.] ACPI: RSDP 000f6d00 00014 (v00 Nvidia) [0.] ACPI: RSDT 37ef3040 00034 (v01 Nvidia AWRDACPI 42302E31 AWRD ?) [0.] ACPI: FACP 37ef30c0 00074 (v01 Nvidia AWRDACPI 42302E31 AWRD ?) [0.] ACPI: DSDT 37ef3180 06E72 (v01 NVIDIA AWRDACPI ? MSFT 010E) [0.] ACPI: FACS 37ef 00040 [0.] ACPI: SSDT 37efa100 00115 (v01 PTLTD POWERNOW 1 LTP 1) [0.] ACPI: MCFG 37efa280 0003C (v01 Nvidia AWRDACPI 42302E31 AWRD ?) [0.] ACPI: APIC 37efa040 0007C (v01 Nvidia AWRDACPI 42302E31 AWRD ?) [0.] ACPI: Local APIC address 0xfee0 [0.] 6MB HIGHMEM available. [0.] 887MB LOWMEM available. [0.] mapped low ram: 0 - 377fe000 [0.] low ram: 0 - 377fe000 [0.] node 0 low ram: ? - 377fe000 [0.] node 0 bootmap ? - 00017f00 [0.] (9 early reservations) ==> bootmem [?M4 - 00377fe000] [0.] #0 [?M4 - ?M5] BIOS data page ==> [?M4 - ?M5] [0.] #1 [?M5 - ?M6]EX TRAMPOLINE ==> [?M5 - ?M6] [0.] #2 [?M: - ?M;] TRAMPOLINE ==> [?M: - ?M;] [0.] #3 [?]4 - 835454]TEXT DATA BSS ==> [?]4 - 835454] [0.] #4 [09f800 - ?]4]BIOS reserved ==> [09f800 - ?]4] [0.] #5 [??? - 839145] BRK ==> [??? - 839145] [0.] #6 [?Mt - ?Mu] PGTABLE ==> [?Mt - ?Mu] [0.] #7 [??? - f8189a] NEW RAMDISK ==> [??? - f8189a] [0.] #8 [?Mu - ?M|] BOOTMAP ==> [?Mu - ?M|] [0.] found SMP MP-table at [c00f5270] f5270 [0.] Zone PFN ranges: [0.] DMA 0x10 -> 0x? [0.] Normal
Re: dib0700 diversity support
Hi Paul, On Fri, 14 Aug 2009, Paul Menzel wrote: I'll post a request for testing soon. I am looking forward to it. Can you please try the drivers from here: http://linuxtv.org/hg/~pb/v4l-dvb/ In the best case they improve the situation for you. In the worst case (not wanted :) ) it will degrade. -- Patrick 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
