Hauppauge/IR breakage with 2.6.28/2.6.29

Hauppauge/IR breakage with 2.6.28/2.6.29

[Udo A. Steinberg]

[-- Attachment #1: Type: text/plain, Size: 668 bytes --]

Hi,

The following patch
http://kerneltrap.org/mailarchive/git-commits-head/2008/10/13/3643574
that was added between 2.6.27 and 2.6.28 has resulted in my Hauppauge
WinTV IR remote not working anymore. I've tracked down the breakage to:

if (dev!=0x1e && dev!=0x1f) 
  return 0;

in drivers/media/video/ir-kbd-i2c.c

My remote sends with dev=0x0 and is the following model:
http://www.phphuoc.com/reviews/tvtuner_hauppauge_wintv_theater/index_files/image001.jpg

Removing the check results in the remote working again. Is there a way to
convince the remote to send a different dev? Otherwise I guess the check
should be relaxed.

Cheers,

	- Udo

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: Hauppauge/IR breakage with 2.6.28/2.6.29

[Darron Broad]

In message <20090326000932.6aa1a456@laptop.hypervisor.org>, "Udo A. Steinberg" wrote:
>
>Hi,
>
>The following patch
>http://kerneltrap.org/mailarchive/git-commits-head/2008/10/13/3643574
>that was added between 2.6.27 and 2.6.28 has resulted in my Hauppauge
>WinTV IR remote not working anymore. I've tracked down the breakage to:
>
>if (dev!=3D0x1e && dev!=3D0x1f)=20
>  return 0;
>
>in drivers/media/video/ir-kbd-i2c.c
>
>My remote sends with dev=3D0x0 and is the following model:
>http://www.phphuoc.com/reviews/tvtuner_hauppauge_wintv_theater/index_files/=
>image001.jpg
>
>Removing the check results in the remote working again. Is there a way to
>convince the remote to send a different dev? Otherwise I guess the check
>should be relaxed.

You are correct. I happen to have one of those ancient remote
controls myself and it does use device address 0.

Please refer to http://www.sbprojects.com/knowledge/ir/rc5.htm
for an overview of device addresses.

It's something I forget to deal with in that patch. A solution
would be to allow a device address to be a module param to
override the more modern addresses of 0x1e and 0x1f.

I can't remember addresses off the top of my head but I believe
the modern silver remotes use 0x1f and the older black ones
use 0x1e. I think the black one I have came with a now dead
DEC2000.

The problem with reverting the patch is that it makes modern
systems unusable as HTPCs when the television uses RC5. This
is a more important IMHO than supporting what in reality is
an obsolete remote control.

cya!

--

 // /
{:)==={ Darron Broad <darron@kewl.org>
 \\ \ 

Re: Hauppauge/IR breakage with 2.6.28/2.6.29

[Udo A. Steinberg]

[-- Attachment #1: Type: text/plain, Size: 1739 bytes --]

On Thu, 26 Mar 2009 00:26:47 +0000 Darron Broad (DB) wrote:

DB> It's something I forget to deal with in that patch. A solution
DB> would be to allow a device address to be a module param to
DB> override the more modern addresses of 0x1e and 0x1f.
DB> 
DB> I can't remember addresses off the top of my head but I believe
DB> the modern silver remotes use 0x1f and the older black ones
DB> use 0x1e. I think the black one I have came with a now dead
DB> DEC2000.
DB> 
DB> The problem with reverting the patch is that it makes modern
DB> systems unusable as HTPCs when the television uses RC5. This
DB> is a more important IMHO than supporting what in reality is
DB> an obsolete remote control.

Hi,

Maybe there aren't many old remotes out there anymore, but from looking at
the table at http://www.sbprojects.com/knowledge/ir/rc5.htm it appears the
remote is not doing anything wrong by using RC5 address 0x0 to talk to what
could be considered a TV (card).

The more fundamental issue here is that both devices/remotes use the same
RC5 address - not surprising if you own two devices of the same device class.

So I'm all for your suggestion of adding a parameter that will allow the
user to either specify the address(es) to accept or ignore. Which of the
following options would you consider most convenient for the unknowing user?

1) parameter specifies the only device id that ir-kbd-i2c will accept
2) parameter specifies a 32-bit mask of acceptable device ids. Any device id
   whose bit is set will be accepted, others will be filtered
3) parameter specifies a 32-bit mask of device ids to filter. Any device id
   whose bit is set will be filtered, others will be accepted

Cheers,

	- Udo

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: Hauppauge/IR breakage with 2.6.28/2.6.29

[Darron Broad]

In message <20090326023841.40ab3ad1@laptop.hypervisor.org>, "Udo A. Steinberg" wrote:

hi

>On Thu, 26 Mar 2009 00:26:47 +0000 Darron Broad (DB) wrote:
>
>DB> It's something I forget to deal with in that patch. A solution
>DB> would be to allow a device address to be a module param to
>DB> override the more modern addresses of 0x1e and 0x1f.
>DB>=20
>DB> I can't remember addresses off the top of my head but I believe
>DB> the modern silver remotes use 0x1f and the older black ones
>DB> use 0x1e. I think the black one I have came with a now dead
>DB> DEC2000.
>DB>=20
>DB> The problem with reverting the patch is that it makes modern
>DB> systems unusable as HTPCs when the television uses RC5. This
>DB> is a more important IMHO than supporting what in reality is
>DB> an obsolete remote control.
>
>Hi,
>
>Maybe there aren't many old remotes out there anymore, but from looking at
>the table at http://www.sbprojects.com/knowledge/ir/rc5.htm it appears the
>remote is not doing anything wrong by using RC5 address 0x0 to talk to what
>could be considered a TV (card).
>
>The more fundamental issue here is that both devices/remotes use the same
>RC5 address - not surprising if you own two devices of the same device clas=
>s.
>
>So I'm all for your suggestion of adding a parameter that will allow the
>user to either specify the address(es) to accept or ignore. Which of the
>following options would you consider most convenient for the unknowing user?
>
>1) parameter specifies the only device id that ir-kbd-i2c will accept
>2) parameter specifies a 32-bit mask of acceptable device ids. Any device id
>   whose bit is set will be accepted, others will be filtered
>3) parameter specifies a 32-bit mask of device ids to filter. Any device id
>   whose bit is set will be filtered, others will be accepted
>
>Cheers,

A quick think about this gives this idea:

1. have a module parm for device address and if it's '0' then accept ANY
address. this is the old behaviour.

2. if the module param isn't '0' then accept only that address.

cya


--

 // /
{:)==={ Darron Broad <darron@kewl.org>
 \\ \