Wan Tat Chee wrote: > Gerd Knoor said: > > >Configuring at least a matching tuner would be very helpful ... > > Ok. Here's what I've managed to try so far. The following is with > modprobe tuner type=5 debug=1 pal=b (for Phillips PAL tuner) > modprobe saa7134 (with some debug options) That should be enougth to get the tuner working. Creating a new entry in saa7134-core.c would make this a bit more comfortable througth. > Incidentally, scantv doesn't recognize Composite0 as an input option, I > hacked scantv.c to do so to avoid the initial warning that it gives trying > to look for the 'television' input. A approximate tuner_input entry for the card in saa7134_boards will fix this. > Trying other tuner options such as for TEMIC sometimes froze the box such > that a hard reset doesn't always recover. Oops. That shouldn't happen. Anything (Oops?) in the kernel logs? > 2. Should I try tuner types such as for Temic, ALPS, etc. or should > I only try the Phillips tuner types as the ICs in the tuner block > has Phillips TDA9800T and TDA6503AT devices? (Tuner is for PAL BG std) Philips should be fine for now. Even with the wrong tuner you should get least "snow" instead of a bluescreen. > 3. I usually try the different options by doing 'modprobe tuner; modprobe > saa7134' then if it doesn't work, 'rmmod saa7134; rmmod tuner' Fine. Note that saa7134 tries to autoload the tuner module, so be sure to either insmod tuner manually first or make sure the correct options are in /etc/modules.conf > 4. I can modprobe almost any tuner type and the dmesg output indicates > that the specified tuner is registered. Does it mean it actually > detected that the given tuner type exists? No. The tuner module can't verify whenever the type is correct. If we could easily autodetect this, the type= insmod option would be obsolete :-) Gerd -- #define ENOCLUE 125 /* userland programmer induced race condition */
