Hi Jean, Am Mittwoch, den 27.01.2010, 10:38 +0100 schrieb Jean Delvare: > Hi Hermann, > > Sorry for the late answer. > > On Sun, 10 Jan 2010 22:55:05 +0100, hermann pitton wrote: > > Am Sonntag, den 10.01.2010, 09:51 +0100 schrieb Jean Delvare: > > > On Sun, 10 Jan 2010 00:18:46 +0100, hermann pitton wrote: > > > > Am Samstag, den 09.01.2010, 17:14 +0100 schrieb Jean Delvare: > > > > > Then I would suggest the following patch: > > > > > > > > > > * * * * * > > > > > > > > > > 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. > > > > > > > > > > Signed-off-by: Jean Delvare <khali@xxxxxxxxxxxx> > > > > > Tested-by: Daro <ghost-rider@xxxxxxxx> > > > > > > > > just to note it, the ASUS TV-FM 7135 with USB remote is different to the > > > > Asus My Cinema P7134 Analog only, not only for the remote, but also for > > > > inputs, but they have the same PCI subsystem. > > > > > > > > > --- > > > > > linux/drivers/media/video/saa7134/saa7134-cards.c | 1 + > > > > > 1 file changed, 1 insertion(+) > > > > > > > > > > --- v4l-dvb.orig/linux/drivers/media/video/saa7134/saa7134-cards.c 2009-12-11 09:47:47.000000000 +0100 > > > > > +++ v4l-dvb/linux/drivers/media/video/saa7134/saa7134-cards.c 2010-01-09 16:23:17.000000000 +0100 > > > > > @@ -7257,6 +7257,7 @@ int saa7134_board_init2(struct saa7134_d > > > > > printk(KERN_INFO "%s: P7131 analog only, using " > > > > > "entry of %s\n", > > > > > dev->name, saa7134_boards[dev->board].name); > > > > > + dev->has_remote = SAA7134_REMOTE_GPIO; > > > > > } > > > > > break; > > > > > case SAA7134_BOARD_HAUPPAUGE_HVR1150: > > > > > > > > > > > > > > > * * * * * > > > > > > > > Must have been broken at that time, IIRC. > > > > > > What must have been broken, and when? You are confusing. > > > > Sorry, I missed that thread until now. > > The above patch was tried previously by Roman. > > > > For the record, here is a link. > > http://www.spinics.net/lists/vfl/msg38869.html > > Thanks for the pointer, this was very helpful. I had missed the fact > that the call to saa7134_input_init1() was before the card number > change. So indeed my patch was insufficient. > > Roman's strategy to move saa7134_input_init1() to the late init section > seems good to me. Honestly, I can't think of a good reason to init the > remote control early. I doubt that anything else depends on that. > > I'll send an updated patch shortly. thanks for your time looking closer into it. Unfortunately I did not have any during the last two months. If we pass all the testing, your here announced and later following patch should be the best possible solution, as it stands now. To give some historical notes, Gerd did try to avoid eeprom detection on the saa7134 driver, likely hoping to see better PCI subsystem use by the manufacturers, since bttv was already very complex and difficult to maintain with all the specific detection stuff and workarounds. However, Hartmut Hackmann and me had to discover, that we still see the same disease with some saa713x OEMs, the same PCI subsystem for very different cards ... Hence we started with some eeprom detection, known now for having caused trouble already through all the ever ongoing changing init procedures we always have and very bad for transparent maintenance. For all, and for Asus specifically, this is still a unique case on the saa713x driver, IIRC. The rest is fine on Asus. To print something for that card like "for IR you have to set the card=number" should be also still enough. To remind, we run into those problems, because OEMs don't follow the rules of the chip manufacturer, excluding others by will on their m$ drivers, when initially buying greater amounts of chips. So we always run only after the tsunamis and it is not worth it, to give those breaking rules previously, some kind of moral instance to get their devices better detected on GNU/Linux later. Anyway, let's try. 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
