Re: IR device at I2C address 0x7a

2010-01-27 Thread hermann pitton
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 
> > > > > 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 
> > > > > Tested-by: Daro 
> > > > 
> > > > 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.0 +0100
> > > > > +++ v4l-dvb/linux/drivers/media/video/saa7134/saa7134-cards.c 
> > > > > 2010-01-09 16:23:17.0 +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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: IR device at I2C address 0x7a

2010-01-27 Thread 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 
> > > > 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 
> > > > Tested-by: Daro 
> > > 
> > > 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.0 +0100
> > > > +++ v4l-dvb/linux/drivers/media/video/saa7134/saa7134-cards.c   
> > > > 2010-01-09 16:23:17.0 +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.

-- 
Jean Delvare
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: IR device at I2C address 0x7a

2010-01-10 Thread hermann pitton

Am Sonntag, den 10.01.2010, 09:51 +0100 schrieb Jean Delvare:
> On Sun, 10 Jan 2010 00:18:46 +0100, hermann pitton wrote:
> > Hi,
> > 
> > Am Samstag, den 09.01.2010, 17:14 +0100 schrieb Jean Delvare:
> > > On Sat, 09 Jan 2010 13:08:36 +0100, Daro wrote:
> > > > W dniu 06.01.2010 21:21, Jean Delvare pisze:
> > > > > On Wed, 06 Jan 2010 18:58:58 +0100, Daro wrote:
> > > > >> It is not the error message itself that bothers me but the fact that 
> > > > >> IR
> > > > >> remote control device is not detected and I cannot use it (I checked 
> > > > >> it
> > > > >> on Windows and it's working). After finding this thread I thought it
> > > > >> could have had something to do with this error mesage.
> > > > >> Is there something that can be done to get my IR remote control 
> > > > >> working?
> > > > > You could try loading the saa7134 driver with option card=146 and see
> > > > > if it helps.
> > > >
> > > > It works!
> > > > 
> > > > [   15.477875] input: saa7134 IR (ASUSTeK P7131 Analo as 
> > > > /devices/pci:00/:00:1e.0/:05:00.0/input/input8
> > > > 
> > > > Thank you very much fo your help.
> > > 
> > > Then I would suggest the following patch:
> > > 
> > > * * * * *
> > > 
> > > From: Jean Delvare 
> > > 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 
> > > Tested-by: Daro 
> > 
> > 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.0 +0100
> > > +++ v4l-dvb/linux/drivers/media/video/saa7134/saa7134-cards.c 
> > > 2010-01-09 16:23:17.0 +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

> > Only moving saa7134_input_init1(dev) to static int saa7134_hwinit2
> > in saa7134-core.c did help, AFAIK, but I might be wrong.

Maybe some regression was involved for him, at least I followed his
assumption, that in case of auto detection, when first a board without
remote is detected, and then that late is switched to another board with
remote through eeprom detection, input_init1 would not happen again.

> I admit I don't quite get why dev->has_remove should be set early (in
> saa7134_board_init1) given that for one board
> (SAA7134_BOARD_FLYDVB_TRIO) it is set later (in saa7134_board_init2)
> and apparently it works OK. It would make more sense to do it at the
> same time for all boards IMHO, possibly in a separate function to make
> it clearer.
> 
> I am also curious if it wouldn't be even clearer and more efficient to
> store the default value of has_remote in struct saa7134_board. As far
> as I can see, only the SAA7134_BOARD_FLYDVB_TRIO needs a run-time check.

Patches are welcome.

Thanks,
Hermann



--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: IR device at I2C address 0x7a

2010-01-10 Thread Jean Delvare
On Sun, 10 Jan 2010 00:18:46 +0100, hermann pitton wrote:
> Hi,
> 
> Am Samstag, den 09.01.2010, 17:14 +0100 schrieb Jean Delvare:
> > On Sat, 09 Jan 2010 13:08:36 +0100, Daro wrote:
> > > W dniu 06.01.2010 21:21, Jean Delvare pisze:
> > > > On Wed, 06 Jan 2010 18:58:58 +0100, Daro wrote:
> > > >> It is not the error message itself that bothers me but the fact that IR
> > > >> remote control device is not detected and I cannot use it (I checked it
> > > >> on Windows and it's working). After finding this thread I thought it
> > > >> could have had something to do with this error mesage.
> > > >> Is there something that can be done to get my IR remote control 
> > > >> working?
> > > > You could try loading the saa7134 driver with option card=146 and see
> > > > if it helps.
> > >
> > > It works!
> > > 
> > > [   15.477875] input: saa7134 IR (ASUSTeK P7131 Analo as 
> > > /devices/pci:00/:00:1e.0/:05:00.0/input/input8
> > > 
> > > Thank you very much fo your help.
> > 
> > Then I would suggest the following patch:
> > 
> > * * * * *
> > 
> > From: Jean Delvare 
> > 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 
> > Tested-by: Daro 
> 
> 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.0 +0100
> > +++ v4l-dvb/linux/drivers/media/video/saa7134/saa7134-cards.c   
> > 2010-01-09 16:23:17.0 +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.

> Only moving saa7134_input_init1(dev) to static int saa7134_hwinit2
> in saa7134-core.c did help, AFAIK, but I might be wrong.

I admit I don't quite get why dev->has_remove should be set early (in
saa7134_board_init1) given that for one board
(SAA7134_BOARD_FLYDVB_TRIO) it is set later (in saa7134_board_init2)
and apparently it works OK. It would make more sense to do it at the
same time for all boards IMHO, possibly in a separate function to make
it clearer.

I am also curious if it wouldn't be even clearer and more efficient to
store the default value of has_remote in struct saa7134_board. As far
as I can see, only the SAA7134_BOARD_FLYDVB_TRIO needs a run-time check.

-- 
Jean Delvare
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: IR device at I2C address 0x7a

2010-01-09 Thread hermann pitton
Hi,

Am Samstag, den 09.01.2010, 17:14 +0100 schrieb Jean Delvare:
> On Sat, 09 Jan 2010 13:08:36 +0100, Daro wrote:
> > W dniu 06.01.2010 21:21, Jean Delvare pisze:
> > > On Wed, 06 Jan 2010 18:58:58 +0100, Daro wrote:
> > >> It is not the error message itself that bothers me but the fact that IR
> > >> remote control device is not detected and I cannot use it (I checked it
> > >> on Windows and it's working). After finding this thread I thought it
> > >> could have had something to do with this error mesage.
> > >> Is there something that can be done to get my IR remote control working?
> > > You could try loading the saa7134 driver with option card=146 and see
> > > if it helps.
> >
> > It works!
> > 
> > [   15.477875] input: saa7134 IR (ASUSTeK P7131 Analo as 
> > /devices/pci:00/:00:1e.0/:05:00.0/input/input8
> > 
> > Thank you very much fo your help.
> 
> Then I would suggest the following patch:
> 
> * * * * *
> 
> From: Jean Delvare 
> 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 
> Tested-by: Daro 

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.0 +0100
> +++ v4l-dvb/linux/drivers/media/video/saa7134/saa7134-cards.c 2010-01-09 
> 16:23:17.0 +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.

Only moving saa7134_input_init1(dev) to static int saa7134_hwinit2
in saa7134-core.c did help, AFAIK, but I might be wrong.

> > I have another question regarding this driver:
> > 
> > [   21.340316] saa7133[0]: dsp access error
> > [   21.340320] saa7133[0]: dsp access error
> > 
> > Do those messages imply something wrong? Can they have something do do 
> > with the fact I cannot get the sound out of tvtime application directly 
> > and have to use "arecord | aplay" workaround which causes undesirable delay?
> 
> Yes, the message is certainly related to your sound problem. Maybe
> support for your card is incomplete. But I can't help with this, sorry.

That is nice ice to slide on, but from all others with that card
previously not reported so far.

Anyway, it should have also analog audio out, the two pins in the middle
of the white 4pin connector on the PCB are ground. To know that can
avoid troubles using older CD-ROM audio cables and get only one of the
stereo channels.

Cheers,
Hermann




Hermann


--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: IR device at I2C address 0x7a

2010-01-09 Thread Jean Delvare
On Sat, 09 Jan 2010 13:08:36 +0100, Daro wrote:
> W dniu 06.01.2010 21:21, Jean Delvare pisze:
> > On Wed, 06 Jan 2010 18:58:58 +0100, Daro wrote:
> >> It is not the error message itself that bothers me but the fact that IR
> >> remote control device is not detected and I cannot use it (I checked it
> >> on Windows and it's working). After finding this thread I thought it
> >> could have had something to do with this error mesage.
> >> Is there something that can be done to get my IR remote control working?
> > You could try loading the saa7134 driver with option card=146 and see
> > if it helps.
>
> It works!
> 
> [   15.477875] input: saa7134 IR (ASUSTeK P7131 Analo as 
> /devices/pci:00/:00:1e.0/:05:00.0/input/input8
> 
> Thank you very much fo your help.

Then I would suggest the following patch:

* * * * *

From: Jean Delvare 
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 
Tested-by: Daro 
---
 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.0 +0100
+++ v4l-dvb/linux/drivers/media/video/saa7134/saa7134-cards.c   2010-01-09 
16:23:17.0 +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:


* * * * *

> I have another question regarding this driver:
> 
> [   21.340316] saa7133[0]: dsp access error
> [   21.340320] saa7133[0]: dsp access error
> 
> Do those messages imply something wrong? Can they have something do do 
> with the fact I cannot get the sound out of tvtime application directly 
> and have to use "arecord | aplay" workaround which causes undesirable delay?

Yes, the message is certainly related to your sound problem. Maybe
support for your card is incomplete. But I can't help with this, sorry.

-- 
Jean Delvare
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: IR device at I2C address 0x7a

2010-01-09 Thread Daro

W dniu 06.01.2010 21:21, Jean Delvare pisze:

On Wed, 06 Jan 2010 20:10:30 +0100, Daro wrote:
   

W dniu 06.01.2010 19:40, Jean Delvare pisze:
 

On Wed, 06 Jan 2010 18:58:58 +0100, Daro wrote:

   

It is not the error message itself that bothers me but the fact that IR
remote control device is not detected and I cannot use it (I checked it
on Windows and it's working). After finding this thread I thought it
could have had something to do with this error mesage.
Is there something that can be done to get my IR remote control working?

 

Did it ever work on Linux?
   

I have no experience on that. I bought this card just few weeks ago and
tried it only on Karmic Koala.
 

OK.

You could try loading the saa7134 driver with option card=146 and see
if it helps.

   

It works!

[   15.477875] input: saa7134 IR (ASUSTeK P7131 Analo as 
/devices/pci:00/:00:1e.0/:05:00.0/input/input8


Thank you very much fo your help.

I have another question regarding this driver:

[   21.340316] saa7133[0]: dsp access error
[   21.340320] saa7133[0]: dsp access error

Do those messages imply something wrong? Can they have something do do 
with the fact I cannot get the sound out of tvtime application directly 
and have to use "arecord | aplay" workaround which causes undesirable delay?


--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: IR device at I2C address 0x7a

2010-01-07 Thread dave_a
Daro  aster.pl> writes:

> 
> Hi Jean,
> 
> Thank you for your answer.
> It is not the error message itself that bothers me but the fact that IR 
> remote control device is not detected and I cannot use it (I checked it 
> on Windows and it's working). After finding this thread I thought it 
> could have had something to do with this error mesage.
> Is there something that can be done to get my IR remote control working?
> Thanks for your help in advance.
> 
> Best regards
> Darek
> 

Hi Darek,
I use a P7131 Dual with mythbuntu, and the IR remote needed special setup. 
While it's a slightly different model of P7131 yours, it could be worth a try.
In /etc/lirc/hardware.conf I needed the lines:
REMOTE_DRIVER="devinput"
REMOTE_DEVICE="name=saa7134*"
REMOTE_LIRCD_CONF="asus/mycinema.conf"
(remove or comment out any existing REMOTE_DEVICE entries)
The device name (with wildcard) matches on input device name (rather than using
numbered input which could change on reboot)

The remote config (IR codes for remote) go in:
/usr/share/lirc/remotes/asus/mycinema.conf

The button mappings are in another file associated with the specific application
(lircrc for mythtv).

Dave

> W dniu 06.01.2010 15:39, Jean Delvare pisze:
> > Hi Darek,
> >
> > Adding LMML to Cc.
> >
> > On Wed, 23 Dec 2009 18:10:08 +0100, Daro wrote:
> >
> >> I have the problem you described at the mailing list with Asus
> >> MyCinema-P7131/P/FM/AV/RC Analog TV Card:
> >> IR remote control is not detected and "i2c-adapter i2c-3: Invalid 7-bit
> >> address 0x7a" error occurs.
> >> lspci gives the following output:
> >> 04:00.0 Multimedia controller: Philips Semiconductors
> >> SAA7131/SAA7133/SAA7135 Video Broadcast Decoder (rev d1)
> >> dmesg output I enclose in the attachment.
> >> I use:
> >> Linux DOMOWY 2.6.31-16-generic #53-Ubuntu SMP Tue Dec 8 04:02:15 UTC
> >> 2009 x86_64 GNU/Linux
> >>
> >> I would be gratefull for the help on that.
> >> (...)
> >> subsystem: 1043:4845, board: ASUS TV-FM 7135 [card=53,autodetected]
> >> (...)
> >> i2c-adapter i2c-3: Invalid 7-bit address 0x7a
> >> saa7133[0]: P7131 analog only, using entry of ASUSTeK P7131 Analog
> >>  
> > This error message will show on virtually every SAA713x-based board
> > with no known IR setup. It doesn't imply your board has any I2C device
> > at address 0x7a. So chances are that the message is harmless and you
> > can simply ignore it.
> >
> >
> 
> 




--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: IR device at I2C address 0x7a

2010-01-06 Thread Jean Delvare
On Wed, 06 Jan 2010 20:10:30 +0100, Daro wrote:
> W dniu 06.01.2010 19:40, Jean Delvare pisze:
> > On Wed, 06 Jan 2010 18:58:58 +0100, Daro wrote:
> >
> >> It is not the error message itself that bothers me but the fact that IR
> >> remote control device is not detected and I cannot use it (I checked it
> >> on Windows and it's working). After finding this thread I thought it
> >> could have had something to do with this error mesage.
> >> Is there something that can be done to get my IR remote control working?
> >>  
> > Did it ever work on Linux?
> 
> I have no experience on that. I bought this card just few weeks ago and 
> tried it only on Karmic Koala.

OK.

You could try loading the saa7134 driver with option card=146 and see
if it helps.

-- 
Jean Delvare
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: IR device at I2C address 0x7a

2010-01-06 Thread Daro

W dniu 06.01.2010 19:40, Jean Delvare pisze:

On Wed, 06 Jan 2010 18:58:58 +0100, Daro wrote:
   

It is not the error message itself that bothers me but the fact that IR
remote control device is not detected and I cannot use it (I checked it
on Windows and it's working). After finding this thread I thought it
could have had something to do with this error mesage.
Is there something that can be done to get my IR remote control working?
 

Did it ever work on Linux?

   


I have no experience on that. I bought this card just few weeks ago and 
tried it only on Karmic Koala.


--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: IR device at I2C address 0x7a

2010-01-06 Thread Daro

Hi Jean,

Thank you for your answer.
It is not the error message itself that bothers me but the fact that IR 
remote control device is not detected and I cannot use it (I checked it 
on Windows and it's working). After finding this thread I thought it 
could have had something to do with this error mesage.

Is there something that can be done to get my IR remote control working?
Thanks for your help in advance.

Best regards
Darek

W dniu 06.01.2010 15:39, Jean Delvare pisze:

Hi Darek,

Adding LMML to Cc.

On Wed, 23 Dec 2009 18:10:08 +0100, Daro wrote:
   

I have the problem you described at the mailing list with Asus
MyCinema-P7131/P/FM/AV/RC Analog TV Card:
IR remote control is not detected and "i2c-adapter i2c-3: Invalid 7-bit
address 0x7a" error occurs.
lspci gives the following output:
04:00.0 Multimedia controller: Philips Semiconductors
SAA7131/SAA7133/SAA7135 Video Broadcast Decoder (rev d1)
dmesg output I enclose in the attachment.
I use:
Linux DOMOWY 2.6.31-16-generic #53-Ubuntu SMP Tue Dec 8 04:02:15 UTC
2009 x86_64 GNU/Linux

I would be gratefull for the help on that.
(...)
subsystem: 1043:4845, board: ASUS TV-FM 7135 [card=53,autodetected]
(...)
i2c-adapter i2c-3: Invalid 7-bit address 0x7a
saa7133[0]: P7131 analog only, using entry of ASUSTeK P7131 Analog
 

This error message will show on virtually every SAA713x-based board
with no known IR setup. It doesn't imply your board has any I2C device
at address 0x7a. So chances are that the message is harmless and you
can simply ignore it.

   


--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: IR device at I2C address 0x7a

2010-01-06 Thread Jean Delvare
On Wed, 06 Jan 2010 18:58:58 +0100, Daro wrote:
> It is not the error message itself that bothers me but the fact that IR 
> remote control device is not detected and I cannot use it (I checked it 
> on Windows and it's working). After finding this thread I thought it 
> could have had something to do with this error mesage.
> Is there something that can be done to get my IR remote control working?

Did it ever work on Linux?

-- 
Jean Delvare
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: IR device at I2C address 0x7a:

2010-01-06 Thread Jean Delvare
Hi Felix,

On Thu, 31 Dec 2009 08:18:51 +0100, Felix Wolfsteller wrote:
> Sorry to bump into you by mail directly. Feel free to redirect me to
> other channels and/or quote me.

Adding LMML to Cc.

> My tv card (asus digimatrix, card=62, tuner=66; i think) might exhibit
> the issue you discussed and apparently patched
> (http://osdir.com/ml/linux-media/2009-10/msg00078.html).
> At least I am getting the same error message as quoted. For more or
> less extensive hardware details, see:
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/481449
> For the dmesg output containing the "adress 0x7a" line, see latest
> comments on that bug.
> 
> I hope I can help and get helped ;)

This error message will show on virtually every SAA713x-based board
with no known IR setup. It doesn't imply your board has any I2C device
at address 0x7a. So chances are that the message is harmless and you
can simply ignore it.

-- 
Jean Delvare
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: IR device at I2C address 0x7a

2010-01-06 Thread Jean Delvare
Hi Darek,

Adding LMML to Cc.

On Wed, 23 Dec 2009 18:10:08 +0100, Daro wrote:
> I have the problem you described at the mailing list with Asus 
> MyCinema-P7131/P/FM/AV/RC Analog TV Card:
> IR remote control is not detected and "i2c-adapter i2c-3: Invalid 7-bit 
> address 0x7a" error occurs.
> lspci gives the following output:
> 04:00.0 Multimedia controller: Philips Semiconductors 
> SAA7131/SAA7133/SAA7135 Video Broadcast Decoder (rev d1)
> dmesg output I enclose in the attachment.
> I use:
> Linux DOMOWY 2.6.31-16-generic #53-Ubuntu SMP Tue Dec 8 04:02:15 UTC 
> 2009 x86_64 GNU/Linux
> 
> I would be gratefull for the help on that.
> (...)
> subsystem: 1043:4845, board: ASUS TV-FM 7135 [card=53,autodetected]
> (...)
> i2c-adapter i2c-3: Invalid 7-bit address 0x7a
> saa7133[0]: P7131 analog only, using entry of ASUSTeK P7131 Analog

This error message will show on virtually every SAA713x-based board
with no known IR setup. It doesn't imply your board has any I2C device
at address 0x7a. So chances are that the message is harmless and you
can simply ignore it.

-- 
Jean Delvare
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: IR device at I2C address 0x7a

2009-10-02 Thread Jarod Wilson

On Oct 2, 2009, at 4:20 PM, hermann pitton wrote:


Am Freitag, den 02.10.2009, 13:47 +0200 schrieb Jean Delvare:



...
While investigating another issue, I have noticed the following  
message

in the kernel logs of a saa7134 user:

i2c-adapter i2c-0: Invalid 7-bit address 0x7a

The address in question is attempted by an IR device probe, and is  
only
probed on SAA7134 adapters. The problem with this address is that  
it is

reserved by the I2C specification for 10-bit addressing, and is thus
not a valid 7-bit address. Before the conversion of ir-kbd-i2c to the
new-style i2c device driver binding model, device probing was done by
ir-kbd-i2c itself so no check was done by i2c-core for address
validity. But since kernel 2.6.31, probing at address 0x7a will be
denied by i2c-core.

So, SAA7134 adapters with an IR device at 0x7a are currently broken.
Do we know how many devices use this address for IR and which they
are? Tracking the changes in the source code, this address was added
in kernel 2.6.8 by Gerd Knorr:
 
http://git.kernel.org/?p=linux/kernel/git/tglx/history.git;a=commitdiff;h=581f0d1a0ded3e3d4408e5bb7f81b9ee221f6b7a
So this would be used by the "Upmost Purple TV" adapter. Question is,
are there other?


Yes, currently 0x7a is only used by the Upmost Purple TV (Yuan  
Tun800).


Here are some more details.
http://archives.devshed.com/forums/linux-97/troubles-with-yuan-tun900-board-detected-as-upmost-purple-tv-1283673.html

Support for the card and the i2c remote was added by Wang-Chan Chen.

For testers it is useful to know that the card is still not fully
supported.

It has a NEC D64083GF video enhancer converting TV baseband video from
tuner to S-Video and shares the vmux = 7 with the S-Video input.

By default it comes up in external S-Video input mode.
There is a Pericom videomux on it and we don't know how to switch it.

Chen used to boot at first windows, switched there to tuner input and
rebooted to GNU/Linux ...


Some web research has pointed me to the Yuan TUN-900:
 http://www.linuxtv.org/pipermail/linux-dvb/2008-January/023405.html
but it isn't clear to me whether the device at 0x7a on this adapter  
is

the same as the one on the Purple TV. And saa7134-cards says of the
TUN-900: "Remote control not yet implemented" so maybe we can just
ignore it for now.


Yes, that card has a device at 0xf4/0x7a too.
I asked to test the remote with the Upmost Purple TV entry, but never
got a reply. As we know these days, radio amux is wrong too on Yuan
TUN900 card=66.

Last contact to Chen was four years back, but he confirmed that both
cards have the same PCI subsystem. Some bytes in the eeprom, meaning
unknown, are different, though.


If we have to, I could make i2c-core more permissive, but I am rather
reluctant to letting invalid addressed being probed, because you  
never
know how complying chips on the I2C bus will react. I am OK  
supporting
invalid addresses if they really exist out there, but the impact  
should

be limited to the hardware in question.

If we only have to care about the Upmost Purple TV, then the  
following

patch should solve the problem:


For what is known so far.

Acked-by: hermann pitton 


Seems like a sane thing to do to me too, and I've not seen nor heard  
of any other devices that use 0x7a. (Hell, I wasn't even aware of  
these ones 'til now).


Acked-by: Jarod Wilson 


--
Jarod Wilson
ja...@wilsonet.com




--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: IR device at I2C address 0x7a

2009-10-02 Thread hermann pitton
Hi,

Am Freitag, den 02.10.2009, 13:47 +0200 schrieb Jean Delvare:
> Hi all,
> 
> [Executive summary: Upmost Purple TV adapter testers wanted!]

unlikely that anybody with such a card is on the new list currently or
any. I add some old known owners, but mail might bounce.

> While investigating another issue, I have noticed the following message
> in the kernel logs of a saa7134 user:
> 
> i2c-adapter i2c-0: Invalid 7-bit address 0x7a
> 
> The address in question is attempted by an IR device probe, and is only
> probed on SAA7134 adapters. The problem with this address is that it is
> reserved by the I2C specification for 10-bit addressing, and is thus
> not a valid 7-bit address. Before the conversion of ir-kbd-i2c to the
> new-style i2c device driver binding model, device probing was done by
> ir-kbd-i2c itself so no check was done by i2c-core for address
> validity. But since kernel 2.6.31, probing at address 0x7a will be
> denied by i2c-core.
> 
> So, SAA7134 adapters with an IR device at 0x7a are currently broken.
> Do we know how many devices use this address for IR and which they
> are? Tracking the changes in the source code, this address was added
> in kernel 2.6.8 by Gerd Knorr:
>   
> http://git.kernel.org/?p=linux/kernel/git/tglx/history.git;a=commitdiff;h=581f0d1a0ded3e3d4408e5bb7f81b9ee221f6b7a
> So this would be used by the "Upmost Purple TV" adapter. Question is,
> are there other?

Yes, currently 0x7a is only used by the Upmost Purple TV (Yuan Tun800).

Here are some more details.
http://archives.devshed.com/forums/linux-97/troubles-with-yuan-tun900-board-detected-as-upmost-purple-tv-1283673.html

Support for the card and the i2c remote was added by Wang-Chan Chen.

For testers it is useful to know that the card is still not fully
supported.

It has a NEC D64083GF video enhancer converting TV baseband video from
tuner to S-Video and shares the vmux = 7 with the S-Video input.

By default it comes up in external S-Video input mode.
There is a Pericom videomux on it and we don't know how to switch it.

Chen used to boot at first windows, switched there to tuner input and
rebooted to GNU/Linux ...

> Some web research has pointed me to the Yuan TUN-900:
>   http://www.linuxtv.org/pipermail/linux-dvb/2008-January/023405.html
> but it isn't clear to me whether the device at 0x7a on this adapter is
> the same as the one on the Purple TV. And saa7134-cards says of the
> TUN-900: "Remote control not yet implemented" so maybe we can just
> ignore it for now.

Yes, that card has a device at 0xf4/0x7a too.
I asked to test the remote with the Upmost Purple TV entry, but never
got a reply. As we know these days, radio amux is wrong too on Yuan
TUN900 card=66.

Last contact to Chen was four years back, but he confirmed that both
cards have the same PCI subsystem. Some bytes in the eeprom, meaning
unknown, are different, though.

> If we have to, I could make i2c-core more permissive, but I am rather
> reluctant to letting invalid addressed being probed, because you never
> know how complying chips on the I2C bus will react. I am OK supporting
> invalid addresses if they really exist out there, but the impact should
> be limited to the hardware in question.
> 
> If we only have to care about the Upmost Purple TV, then the following
> patch should solve the problem:

For what is known so far.

Acked-by: hermann pitton 

Cheers,
Hermann

> * * * * *
> 
> From: Jean Delvare 
> Subject: saa7134: Fix IR support for Purple TV
> 
> The i2c core prevents us from probing I2C address 0x7a because it's
> not a valid 7-bit address (reserved for 10-bit addressing.) So we must
> stop probing this address, and explicitly list all adapters which use
> it. Under the assumption that only the Upmost Purple TV adapter uses
> this invalid address, this fix should do the trick.
> 
> Signed-off-by: Jean Delvare 
> ---
>  linux/drivers/media/video/saa7134/saa7134-input.c |3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> --- v4l-dvb.orig/linux/drivers/media/video/saa7134/saa7134-input.c
> 2009-10-02 13:26:39.0 +0200
> +++ v4l-dvb/linux/drivers/media/video/saa7134/saa7134-input.c 2009-10-02 
> 13:26:49.0 +0200
> @@ -746,7 +746,7 @@ void saa7134_probe_i2c_ir(struct saa7134
>  {
>  #if LINUX_VERSION_CODE >= KERNEL_VERSION(2, 6, 30)
>   const unsigned short addr_list[] = {
> - 0x7a, 0x47, 0x71, 0x2d,
> + 0x47, 0x71, 0x2d,
>   I2C_CLIENT_END
>   };
>  
> @@ -813,6 +813,7 @@ void saa7134_probe_i2c_ir(struct saa7134
>   dev->init_data.name = "Purple TV";
>   dev->init_data.get_key = get_key_purpletv;
>   dev->init_data.ir_codes = &ir_codes_purpletv_table;
> + info.addr = 0x7a;
>  #endif
>   break;
>   case SAA7134_BOARD_MSI_TVATANYWHERE_PLUS:
> 
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info

IR device at I2C address 0x7a

2009-10-02 Thread Jean Delvare
Hi all,

[Executive summary: Upmost Purple TV adapter testers wanted!]

While investigating another issue, I have noticed the following message
in the kernel logs of a saa7134 user:

i2c-adapter i2c-0: Invalid 7-bit address 0x7a

The address in question is attempted by an IR device probe, and is only
probed on SAA7134 adapters. The problem with this address is that it is
reserved by the I2C specification for 10-bit addressing, and is thus
not a valid 7-bit address. Before the conversion of ir-kbd-i2c to the
new-style i2c device driver binding model, device probing was done by
ir-kbd-i2c itself so no check was done by i2c-core for address
validity. But since kernel 2.6.31, probing at address 0x7a will be
denied by i2c-core.

So, SAA7134 adapters with an IR device at 0x7a are currently broken.
Do we know how many devices use this address for IR and which they
are? Tracking the changes in the source code, this address was added
in kernel 2.6.8 by Gerd Knorr:
  
http://git.kernel.org/?p=linux/kernel/git/tglx/history.git;a=commitdiff;h=581f0d1a0ded3e3d4408e5bb7f81b9ee221f6b7a
So this would be used by the "Upmost Purple TV" adapter. Question is,
are there other?

Some web research has pointed me to the Yuan TUN-900:
  http://www.linuxtv.org/pipermail/linux-dvb/2008-January/023405.html
but it isn't clear to me whether the device at 0x7a on this adapter is
the same as the one on the Purple TV. And saa7134-cards says of the
TUN-900: "Remote control not yet implemented" so maybe we can just
ignore it for now.

If we have to, I could make i2c-core more permissive, but I am rather
reluctant to letting invalid addressed being probed, because you never
know how complying chips on the I2C bus will react. I am OK supporting
invalid addresses if they really exist out there, but the impact should
be limited to the hardware in question.

If we only have to care about the Upmost Purple TV, then the following
patch should solve the problem:

* * * * *

From: Jean Delvare 
Subject: saa7134: Fix IR support for Purple TV

The i2c core prevents us from probing I2C address 0x7a because it's
not a valid 7-bit address (reserved for 10-bit addressing.) So we must
stop probing this address, and explicitly list all adapters which use
it. Under the assumption that only the Upmost Purple TV adapter uses
this invalid address, this fix should do the trick.

Signed-off-by: Jean Delvare 
---
 linux/drivers/media/video/saa7134/saa7134-input.c |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

--- v4l-dvb.orig/linux/drivers/media/video/saa7134/saa7134-input.c  
2009-10-02 13:26:39.0 +0200
+++ v4l-dvb/linux/drivers/media/video/saa7134/saa7134-input.c   2009-10-02 
13:26:49.0 +0200
@@ -746,7 +746,7 @@ void saa7134_probe_i2c_ir(struct saa7134
 {
 #if LINUX_VERSION_CODE >= KERNEL_VERSION(2, 6, 30)
const unsigned short addr_list[] = {
-   0x7a, 0x47, 0x71, 0x2d,
+   0x47, 0x71, 0x2d,
I2C_CLIENT_END
};
 
@@ -813,6 +813,7 @@ void saa7134_probe_i2c_ir(struct saa7134
dev->init_data.name = "Purple TV";
dev->init_data.get_key = get_key_purpletv;
dev->init_data.ir_codes = &ir_codes_purpletv_table;
+   info.addr = 0x7a;
 #endif
break;
case SAA7134_BOARD_MSI_TVATANYWHERE_PLUS:


-- 
Jean Delvare
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html