Re: [PATCH] saa7134: Fix IR support of some ASUS TV-FM 7135 variants

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

Am Freitag, den 29.01.2010, 13:40 -0200 schrieb Mauro Carvalho Chehab:
> Jean Delvare wrote:
> > From: Jean Delvare <khali@xxxxxxxxxxxx>
> > Subject: saa7134: Fix IR support of some ASUS TV-FM 7135 variants
> > 
> > Some variants of the ASUS TV-FM 7135 are handled as the ASUSTeK P7131
> > Analog (card=146). However, by the time we find out, some
> > card-specific initialization is missed. In particular, the fact that
> > the IR is GPIO-based. Set it when we change the card type.
> > 
> > We also have to move the initialization of IR until after the card
> > number has been changed. I hope that this won't cause any problem.
> 
> Hi Jean,
> 
> Moving the initialization will likely cause regressions. The reason why there
> are two init codes there were due to the way the old i2c code used to work.
> This got fixed after the i2c rework, but it caused regressions on that time.
> 
> The proper way would be to just muve the IR initialization on this board
> from init1 to init2, instead of changing it for all other devices.
> 
> cheers,
> Mauro

Mauro, I do agree with you that it is likely better to go a way with
minimum chances for regressions, also given the current testing base and
that only this single card is involved..

Do we end up with something card specific in core code here?
After all, we know this is a no go.

Hartmut and me thought back and forth on how to deal with it for quite
some while, unfortunately Hartmut is not present currently on the list,
but he voted for to have a separate entry for that card finally too.

What we seem to have now is:

1. We don't know, if Jean's patch really would cause regressions,
   but it is likely hard to get all the testing done. No problems with a
   FlyVideo3000 gpio remote at the time Roman suggested it, but I had
   not any i2c remote that time ...

2. The previous situation was, that this analog only card did use the
   entry of the Ausus P7131 Dual forcing card=78 without problems,
   but getting fake support for DVB-T announced and printing results
   of some fall through.

3. If we agree, that unique PCI subsystems should have highest priority
   for auto detection, in such a case, we likely could also set the
   PC-39 remote for the older card with USB remote. IIRC, that should
   survive the later change of the card caused by the work around
   eeprom detection later, and disable IR based on eeprom for the older
   then.

To be honest, as pointed to already in the other thread around this, we
should not try to become better than all others on m$ previously for
some very small gain.

We are already much, much better than drivers there, excluding each
others, don't follow Philips/NXP eeprom rules and so on.

We could just print something like use card=number to get the remote up
too, if people, not reading the lists ;), hope to rely on auto detection
in vain ...

About all the LNA and IR mess we have for other manufactures, nobody
talks about anymore ...

Given what is also in the cruft for bttv, I would not care too much for
that single card on that now also ancient driver, just print what the
user can do to escape and any google would find it quickly too. For Asus
it is a unique problem on that driver so far.

I should have some time on Sunday afternoon for testing, if we should go
that way.

Cheers,
Hermann





 




--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux