Talk:Tuners: Supported Tuners: Difference between revisions
Jump to navigation
Jump to search
m (Discussion of tuner database organization moved to Tuners: Discussion of tuner database organization: name) |
(some edits) |
||
| Line 1: | Line 1: | ||
We have a lengthy [[Tuners: Supported Tuners|list of supported tuners]], which are named by their labels and |
|||
some values for them in common structure in tuner-core.c. The values |
some values for them in common structure in tuner-core.c. The values |
||
are: |
are: |
||
| Line 15: | Line 15: | ||
.... |
.... |
||
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. |
|||
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 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. |
|||
| ⚫ | |||
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: |
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). |
|||
| ⚫ | |||
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 |
|||
| ⚫ | |||
Is presense of tda9887 and it's config just a property of tuner (like |
* Is presense of tda9887 and it's config just a property of tuner (like presence of tda8290 for tda8275)? |
||
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. |
|||
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. |
|||
One of possibilities that have just came to my mind - introduce api=.. |
|||
option to tuner that will just set tuner api without specification of |
|||
tuner type. Actually, I was always wondering, why option type=n for |
|||
tuner module was semi-deprecated. For me it seems 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 |
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. |
||
above (we certainly should put that marvelous text on the wiki in the |
|||
page about addition of the new card) that would be enough. |
|||
Revision as of 19:01, 11 January 2008
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.