Talk:Tuners: Supported Tuners

Discussion of tuner database organization
We have a lengthy list of supported tuners, which are named by their labels and some values for them in common structure in tuner-core.c. The values are:

1. Ranges for UHF, VHF
2. Config bytes to switch ranges
3. IF frequency

Also some info is spread in the code:

1. Radio IF freqency
2. Radio config byte
3. Status byte format
4. Switching for hybrid tuners
....

The current state of organization is not optimal for the following reason: we have a lot of duplicated entries and user that has new unknown tuner often should try them all. Also changes made for one tuner don't change others of the same type.

Suggestions on what should we keep:

• We should certainly keep backward compatibility (configs with tuner=n) should still work.

• We should keep tuner names (user often sees the label on the tuner box and that label can clearly identify the tuner api and etc.) Also label has another meaningful information, for example FM1216 has radio, FQ1216 has not. We should still be able for each card identify the exact tuner it has.

Questions:

• What values currently recorded can become part of API instead of tuner part? For example, Mauro pointed that IF frequency can be easily determined by current norm (623 for PAL, 725 for NTSC). Config byte seems similar for all cards. The minor exceptions we have may be reason of just incorrect testing (tuner may also work for 0x8e, but it was not tested).

The ranges also can be part of API and one determine them by standard. They aren't part of the tuner.

• Is presense of tda9887 and it's config just a property of tuner (like presence of tda8290 for tda8275)?

• The i2c address of tuner also looks interesting -- we should record info about tuners that are visible on 2 addresses at once.

• One of possibilities that comes to to mind - introduce api=..option to tuner that will just set tuner api without specification of tuner type. Actually, this leads one to wonder why option type=n for tuner module was semi-deprecated. It strikes one as being more clear and useful than option tuner=n for bttv or saa module.

Probably, if we'll have all this just documented like Hermann wrote above (we certainly should put that marvelous text on the wiki in the page about addition of the new card) that would be enough.