Re: [linux-dvb] TT S-1401 problem with kernel 2.6.24 ???

[hermann pitton <hermann-pitton@arcor.de>]

Am Donnerstag, den 03.04.2008, 22:18 -0300 schrieb Mauro Carvalho
Chehab:
> On Fri, 04 Apr 2008 01:23:22 +0200
> hermann pitton <hermann-pitton@arcor.de> wrote:
> 
> > Am Donnerstag, den 03.04.2008, 01:38 +0200 schrieb hermann pitton:
> > > Hi again,
> > > 
> > > Am Mittwoch, den 02.04.2008, 22:47 +0400 schrieb Andrew Junev:
> > > > Hello Hermann,
> > > > 
> > > > Thanks a lot for this detailed explanation!
> > > > I really appreciate your help!
> > > > 
> > > > One small question: does it mean that kernels 2.6.24.5 or 2.6.24.6
> > > > _should_ have this patch already included?
> > > > 
> > > 
> > > seems we hang in current stable kernel rules.
> > > 
> > > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob_plain;f=Documentation/stable_kernel_rules.txt;hb=HEAD
> > > 
> > > If we go back to 2.6.23 level, that patch might have less than 100 lines
> > > with context, but we break the
> > > 
> > >  - It must fix only one thing
> > > 
> > > rule, since we break the 2.6.24 LifeView Trio DVB-S support too then.
> > > 
> > > Seems sombody with such a device should reopen the bug on Bugzilla ...
> > > 
> > 
> > Hi Guys,
> > 
> > should we really let hang it like this on 2.6.24?
> > 
> > I'm not that happy with a recommendation for the distributions to pick
> > something out of it.
> > 
> > If we should go back to 2.6.23 level, so far nobody seems to have
> > realized a improvement for the LifeView Trio stuff, I'm not against it.
> > 
> > The changeset in question to revert is mercurial 6579.
> > 
> > If nobody else is interested and no comments, I also don't care anymore.
> 
> I don't see why to revert changeset 6579. On changeset 7186, an option were added at the frontend structure, to allow specify if diseqc requires a modulated signal or not. It is just a matter of changing the struct. Something like:
> 
>  static struct tda10086_config dvbs_card1 = {
>         .demod_address = 0x0e,
>         .invert = 0,
>         .diseqc_tone = 0,	/* Non-modulated tone - The default behavior after changeset 6579 */
>  };
> 
>  static struct tda10086_config dvbs_card2 = {
>         .demod_address = 0x0e,
>         .invert = 0,
>         .diseqc_tone = 1,	/* modulated tone - The default behavior before changeset 6579 */
>  };
> 
> The problem seems to be related to this struct:
> 
> static struct tda10086_config flydvbs = {
>         .demod_address = 0x0e,
>         .invert = 0,
>         .diseqc_tone = 0,
> };
> 
> is currently in use by several variants:
> 	SAA7134_BOARD_FLYDVB_TRIO,
> 	SAA7134_BOARD_MEDION_MD8800_QUADRO,
> 	SAA7134_BOARD_FLYDVBS_LR300,
> 	SAA7134_BOARD_PHILIPS_SNAKE,
> 	SAA7134_BOARD_MD7134_BRIDGE_2.
> 
> Probably, some of those boards need .diseqc_tone=1 while others require .diseqc_tone=0.
> 
> What are the boards that are currently broken?
> 
> Cheers,
> Mauro

Mauro,

as far I can see on v4l-dvb master, none. On 2.6.25 none. On 2.6.26 we
will have some new fun.

What Hartmut added is fully sufficient.

The problen is only on 2.6.24.something currently.

We can't add the necessarry fix currently, because above 100 lines
including context are not allowed bullshit we have to face. To go below
it, 2.6.23, means to break the Trio DVB-S stuff you took in from
Bugzilla. It is not the first time that something goes wrong here and I
really don't like the _pisszilla_ ;;) at all.

Too much comes easily in to just please and do a favour, but not on
devel and crosschecked level.

We have the right point I think, we can't accept some idiotic 100 lines
restriction including context here for a fix.

Cheers,
Hermann




--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list