Development: How to add support for a device
Getting Started
First you should find, how your card identify yourself on pci (just lspci and lspci -vn). This give you type of main decoder chip
Next, you should try to identify tuner chips that your card uses. There can be tuner chip, demodulator or both hidden in metallic box connected directly to antenna input. Often tuner type is printed under sticker.
You can find a lot of cards on http://bttv-gallery.de - very useful resource about cards identification.
Another useful place to look is windows drivers. They often contains a lot of information about cards hardware.
Development is easy
After that you should download the latest v4l cvs and search for a similar card. Probably something like your card is already supported but has another name. You can copy a similar entry and fill in the values for the new card. For a bttv chip you add to bttv-cards.c and bttv.h, for cx88 - cx88-cards.c and cx88.h, for saa - saa7134-cards.c and saa7134.h
A guide about how to add a remote can be found in the section Remote_controllers. Before writing the patch please doublecheck if there are no such keys in v4l sources already.
Card works - that's cool. You are ready to send a patch to video4linux mailing list.
Don't forget to send info to bttv-gallery
If your card is missing on bttv-gallery, please, send the following info to Gunther Mayer <gunther.mayer () gmx ! net>.
Your contribution will help to improve open source support!
Because there are many cards and variations by different
vendors, the developers need _your_ help to get it all supported.
1st priority:
- picture of the card, the card backside (high resolution pics if feasible)
- lspci -vn
further information:
- picture of remote control (if applicable) and of original package
- list of chips
- list of input connectors
- printings on PCB, printings on stickers on the card
- lspci -v and lspci -vn
- "dmesg" when loading the modules
- if feasible "eeprom" output (from bttv tools)
- if feasible "*.INF" files from the Windows Driver CD
- exact tuner type (possibly this is hidden under the vendor sticker)
- exact model name and model number from package
- in which country do you live/ in which country this card was bought
- which application(s) did you use to test your setup ?
- If some parts of your card seem to work, describe exactly what you did and what you see/hear now.
Even parts of this info will be very helpful!
Finding correct tuner
In more of 90% of all cases something like.. first test one to your norm specific type with older Philips API, then test LG API and if there are still missing channels in UHF test MK3 API types will succeed. To find the exact takeover and radio config might be further steps, but most likely this can be/is covered by one of the existing types already.
At least it will usually take only three tuners to reach this point and if you get "all three API types" don't work, then ...
To check for the tda9887 on MK3 and mt32xx types can be done at once or as a next step. Since also the Philips silicon tuners should be well detected now, we can identify such like the yet unsupported XCeive types quite well. They seem to fail safely upon the initialization sequence with tuner=54 if I got Carsten right. So the really difficult/new ones should show up quickly enough and we can try to prepare a list of typical addresses for new devices like channel decoders, second eeproms, most likely hidden analog demodulators and such.
That the multi and hybrid types can have other issues too, like antenna input/filter/demodulator RF-amplifier switching and the like is above simple analog tuner programming and not yet fully investigated for all new types, but it seems there is some very good progress too.
The takeover suggestions in most datasheets on switch between VHF and UHF aren't related closely to technical specifications and precise measurements. They simply take it from _known_ channels currently in use and select those which are closest from both sides! Most obvious for NTSC-M tuners. If one is missing in the gap, to go right into the middle seems to be still reasonable for me as a next step in such cases, but to finally make the decision on what is empirically reported to work best is legal in lack of further documentation.
Guessing the .gpio values and masks for input
See Remote controllers and GPIO pins.