Re: ir-kbd-i2c / rc-hauppauge / linux-3.x broken

Re: ir-kbd-i2c / rc-hauppauge / linux-3.x broken

[Mauro Carvalho Chehab]

On 30-12-2011 10:06, Dorozel Csaba wrote:
> Hi!
> 
> After kernel upgrade from 2.6.38 to any of the 3.x.x series my remote is partly broken (Hauppauge
> WinTV-HVR1110 DVB-T/Hybrid with gray remote (A415-HPG-WE-A)).

(c/c linux-media ML)

> user juuzer # ir-keytable 
> Found /sys/class/rc/rc0/ (/dev/input/event6) with:
>         Driver ir-kbd-i2c, table rc-hauppauge
>         Supported protocols: RC-5 
>         Enabled protocols: RC-5 
>         Repeat delay = 500 ms, repeat period = 125 ms
> user juuzer # ir-keytable -t
> Testing events. Please, press CTRL-C to abort.
> 1325171356.344341: event MSC: scancode = 3b
> 1325171356.344343: event sync
> 1325171356.447358: event MSC: scancode = 3b
> 1325171356.447359: event sync
> 1325171357.786360: event MSC: scancode = 3d
> 1325171357.786362: event sync
> 1325171357.889359: event MSC: scancode = 3d
> 1325171357.889360: event sync
> 1325171363.039366: event MSC: scancode = 01
> 1325171363.039369: event key down: KEY_1 (0x0002)
> 1325171363.039370: event sync
> 11325171363.289389: event key up: KEY_1 (0x0002)
> 1325171363.289390: event sync
> 1325171364.584360: event MSC: scancode = 02
> 1325171364.584364: event key down: KEY_2 (0x0003)
> 1325171364.584365: event sync
> 21325171364.687351: event MSC: scancode = 02
> 1325171364.687353: event sync
> 1325171364.937382: event key up: KEY_2 (0x0003)
> 1325171364.937383: event sync
> 
> So i made some changes in rc-hauppauge.c file. Add/rename/replace some keycodes started with 0x00
> address which keep the compatibility with old black remote and work with my gray one.
> 
> ser juuzer # ir-keytable   
> Found /sys/class/rc/rc0/ (/dev/input/event6) with:
>         Driver ir-kbd-i2c, table rc-hauppauge
>         Supported protocols: RC-5 
>         Enabled protocols: RC-5 
>         Repeat delay = 500 ms, repeat period = 125 ms
> user juuzer # ir-keytable -t
> Testing events. Please, press CTRL-C to abort.
> 1325171718.396566: event MSC: scancode = 3b
> 1325171718.396569: event key down: KEY_SELECT (0x0161)
> 1325171718.396570: event sync
> 1325171718.499571: event MSC: scancode = 3b
> 1325171718.499572: event sync
> 1325171718.749585: event key up: KEY_SELECT (0x0161)
> 1325171718.749586: event sync
> 1325171721.180564: event MSC: scancode = 3d
> 1325171721.180567: event key down: KEY_POWER2 (0x0164)
> 1325171721.180568: event sync
> 1325171721.283562: event MSC: scancode = 3d
> 1325171721.283563: event sync
> 1325171721.533585: event key up: KEY_POWER2 (0x0164)
> 1325171721.533586: event sync
> 1325171731.070564: event MSC: scancode = 01
> 1325171731.070567: event key down: KEY_1 (0x0002)
> 1325171731.070569: event sync
> 11325171731.173562: event MSC: scancode = 01
> 1325171731.173563: event sync
> 1325171731.423587: event key up: KEY_1 (0x0002)
> 1325171731.423588: event sync
> 1325171732.203561: event MSC: scancode = 02
> 1325171732.203565: event key down: KEY_2 (0x0003)
> 1325171732.203566: event sync
> 21325171732.306567: event MSC: scancode = 02
> 1325171732.306569: event sync
> 1325171732.556586: event key up: KEY_2 (0x0003)
> 1325171732.556587: event sync
> 
> Some of  the keycodes have different function on black and gray:
> 
> 0x001f  KEY_TV on black - KEY_EXIT on gray
> 0x002e  KEY_ZOOM on black - KEY_GREEN on gray
> 0x000d  KEY_MUTE on black – KEY_MENU on gray
> 0x001e  KEY_RED on black – KEY_NEXTSONG on gray

Sorry, but your fix is at the wrong place ;) The bug is not inside
the ir-hauppage.c table.

Basically, the bridge driver is not sending the complete RC-5
keycode to the IR core, but just the 8 least siginificant bits.
So, it is loosing the 0x1e00 code for the Hauppauge grey remote.

The fix should be at saa7134-input. It should be something like
the enclosed patch (I'm just guessing there that code3 contains
the MSB bits - you may need to adjust it to match the IR decoder
there):

saa7134-input: Fix get_key_hvr1110() handling

Instead of returning just 8 bits, return the full RC-5 code

Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>

diff --git a/drivers/media/video/saa7134/saa7134-input.c b/drivers/media/video/saa7134/saa7134-input.c
index d4ee24b..29c8efd 100644
--- a/drivers/media/video/saa7134/saa7134-input.c
+++ b/drivers/media/video/saa7134/saa7134-input.c
@@ -249,8 +249,8 @@ static int get_key_hvr1110(struct IR_i2c *ir, u32 *ir_key, u32 *ir_raw)
 		return 0;
 
 	/* return key */
-	*ir_key = code4;
-	*ir_raw = code4;
+	*ir_key = code4 | code3 << 8;
+	*ir_raw = *ir_key;
 	return 1;
 }
 

Re: ir-kbd-i2c / rc-hauppauge / linux-3.x broken

[Dorozel Csaba]

> Basically, the bridge driver is not sending the complete RC-5
> keycode to the IR core, but just the 8 least siginificant bits.
> So, it is loosing the 0x1e00 code for the Hauppauge grey remote.
> 
> The fix should be at saa7134-input. It should be something like
> the enclosed patch (I'm just guessing there that code3 contains
> the MSB bits - you may need to adjust it to match the IR decoder
> there):

I'm absolutly not a programer but an unhappy linux user who want his working remote back.
Know nothing about c code, MSB bits ... After apply your fix looks what happening but remote is
still broken.

user juuzer # ir-keytable -t
Testing events. Please, press CTRL-C to abort.
1325324726.066129: event MSC: scancode = de3d
1325324726.066131: event sync
1325324726.169132: event MSC: scancode = de3d
1325324726.169134: event sync
1325324727.508129: event MSC: scancode = fe3d
1325324727.508131: event sync
1325324727.611132: event MSC: scancode = fe3d
1325324727.611134: event sync
1325324730.084132: event MSC: scancode = de3d
1325324730.084134: event sync
1325324730.187132: event MSC: scancode = de3d

It seems the code3 sometimes return with de (11011110) sometimes fe (11111110). Is it possible
to bitwise left 3 then bitwise right 3 so the result in both case is 1e (00011110) ? Or its totaly
wrong ?

Re: ir-kbd-i2c / rc-hauppauge / linux-3.x broken

[Mauro Carvalho Chehab]

On 31-12-2011 08:15, Dorozel Csaba wrote:
>> Basically, the bridge driver is not sending the complete RC-5
>> keycode to the IR core, but just the 8 least siginificant bits.
>> So, it is loosing the 0x1e00 code for the Hauppauge grey remote.
>>
>> The fix should be at saa7134-input. It should be something like
>> the enclosed patch (I'm just guessing there that code3 contains
>> the MSB bits - you may need to adjust it to match the IR decoder
>> there):
> 
> I'm absolutly not a programer but an unhappy linux user who want his working remote back.
> Know nothing about c code, MSB bits ... After apply your fix looks what happening but remote is
> still broken.
> 
> user juuzer # ir-keytable -t
> Testing events. Please, press CTRL-C to abort.
> 1325324726.066129: event MSC: scancode = de3d
> 1325324726.066131: event sync
> 1325324726.169132: event MSC: scancode = de3d
> 1325324726.169134: event sync
> 1325324727.508129: event MSC: scancode = fe3d
> 1325324727.508131: event sync
> 1325324727.611132: event MSC: scancode = fe3d
> 1325324727.611134: event sync
> 1325324730.084132: event MSC: scancode = de3d
> 1325324730.084134: event sync
> 1325324730.187132: event MSC: scancode = de3d
> 
> It seems the code3 sometimes return with de (11011110) sometimes fe (11111110). Is it possible
> to bitwise left 3 then bitwise right 3 so the result in both case is 1e (00011110) ? Or its totaly
> wrong ?

An RC-5 code is just 14 bits. I found some Hauppauge decoders returning
just 12 bits on some places. It seems that all it needs is to do a
code3 | 0x3f, in order to discard the two most significant bits (MSB).

So, the enclosed patch should fix the issues. Please test.

Regards,
Mauro
-

saa7134-input: Fix get_key_hvr1110() handling

Instead of returning just 8 bits, return the full RC-5 code

Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>

diff --git a/drivers/media/video/saa7134/saa7134-input.c b/drivers/media/video/saa7134/saa7134-input.c
index d4ee24b..29c8efd 100644
--- a/drivers/media/video/saa7134/saa7134-input.c
+++ b/drivers/media/video/saa7134/saa7134-input.c
@@ -249,8 +249,8 @@ static int get_key_hvr1110(struct IR_i2c *ir, u32 *ir_key, u32 *ir_raw)
 		return 0;
 
 	/* return key */
-	*ir_key = code4;
-	*ir_raw = code4;
+	*ir_key = 0x3fff & (code4 | code3 << 8);
+	*ir_raw = *ir_key;
 	return 1;
 }


Regards,
Mauro
> 

Re: ir-kbd-i2c / rc-hauppauge / linux-3.x broken

[Patrick Dickey]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 12/31/2011 05:07 AM, Mauro Carvalho Chehab wrote:
> On 31-12-2011 08:15, Dorozel Csaba wrote:
>>> Basically, the bridge driver is not sending the complete RC-5 
>>> keycode to the IR core, but just the 8 least siginificant
>>> bits. So, it is loosing the 0x1e00 code for the Hauppauge grey
>>> remote.
>>> 
>>> The fix should be at saa7134-input. It should be something
>>> like the enclosed patch (I'm just guessing there that code3
>>> contains the MSB bits - you may need to adjust it to match the
>>> IR decoder there):
>> 
>> I'm absolutly not a programer but an unhappy linux user who want
>> his working remote back. Know nothing about c code, MSB bits ...
>> After apply your fix looks what happening but remote is still
>> broken.
>> 
>> user juuzer # ir-keytable -t Testing events. Please, press CTRL-C
>> to abort. 1325324726.066129: event MSC: scancode = de3d 
>> 1325324726.066131: event sync 1325324726.169132: event MSC:
>> scancode = de3d 1325324726.169134: event sync 1325324727.508129:
>> event MSC: scancode = fe3d 1325324727.508131: event sync 
>> 1325324727.611132: event MSC: scancode = fe3d 1325324727.611134:
>> event sync 1325324730.084132: event MSC: scancode = de3d 
>> 1325324730.084134: event sync 1325324730.187132: event MSC:
>> scancode = de3d
>> 
>> It seems the code3 sometimes return with de (11011110) sometimes
>> fe (11111110). Is it possible to bitwise left 3 then bitwise
>> right 3 so the result in both case is 1e (00011110) ? Or its
>> totaly wrong ?
> 
> An RC-5 code is just 14 bits. I found some Hauppauge decoders
> returning just 12 bits on some places. It seems that all it needs
> is to do a code3 | 0x3f, in order to discard the two most
> significant bits (MSB).
> 
> So, the enclosed patch should fix the issues. Please test.
> 
> Regards, Mauro -
> 
> saa7134-input: Fix get_key_hvr1110() handling
> 
> Instead of returning just 8 bits, return the full RC-5 code
> 
> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
> 
> diff --git a/drivers/media/video/saa7134/saa7134-input.c
> b/drivers/media/video/saa7134/saa7134-input.c index
> d4ee24b..29c8efd 100644 ---
> a/drivers/media/video/saa7134/saa7134-input.c +++
> b/drivers/media/video/saa7134/saa7134-input.c @@ -249,8 +249,8 @@
> static int get_key_hvr1110(struct IR_i2c *ir, u32 *ir_key, u32
> *ir_raw) return 0;
> 
> /* return key */ -	*ir_key = code4; -	*ir_raw = code4; +	*ir_key =
> 0x3fff & (code4 | code3 << 8); +	*ir_raw = *ir_key; return 1; }
> 
> 
> Regards, Mauro
>> 
> 
> -- To unsubscribe from this list: send the line "unsubscribe
> linux-media" in the body of a message to majordomo@vger.kernel.org 
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Will this work regardless of what remote is being used?  Currently I'm
using a Windows Media Center Remote (Hauppauge HVR-1600 provided it)
with a combination of saa7134 (MSI TV@nywhere Plus) and Hauppauge
HVR-1600 tuners. Right now, the Hauppauge works fine (all of this is
in Mythtv 0.24), but the MSI crashes when I change channels.

Have a great day:)
Patrick.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk7+72UACgkQMp6rvjb3CAR2tQCgqSAc55bQyDEe3Z4vu0sUYAne
RrQAoIU89vMVzI8UBH8v+dJxl3RsHj44
=3joI
-----END PGP SIGNATURE-----

Re: ir-kbd-i2c / rc-hauppauge / linux-3.x broken

[Dorozel Csaba]

> An RC-5 code is just 14 bits. I found some Hauppauge decoders returning
> just 12 bits on some places. It seems that all it needs is to do a
> code3 | 0x3f, in order to discard the two most significant bits (MSB).
> 
> So, the enclosed patch should fix the issues. Please test.

Half way .. something still wrong.

user juuzer # ir-keytable -t -d /dev/input/event6
Testing events. Please, press CTRL-C to abort.
1325331995.343188: event MSC: scancode = 3e3d
1325331995.343190: event sync
1325331995.446127: event MSC: scancode = 3e3d
1325331995.446129: event sync
1325331997.504133: event MSC: scancode = 1e3d
1325331997.504135: event key down: KEY_POWER2 (0x0164)
1325331997.504136: event sync
1325331997.607137: event MSC: scancode = 1e3d
1325331997.607138: event sync
1325331997.857161: event key up: KEY_POWER2 (0x0164)
1325331997.857163: event sync
1325331999.973135: event MSC: scancode = 3e3d
1325331999.973136: event sync
1325332000.075130: event MSC: scancode = 3e3d
1325332000.075131: event sync

Re: ir-kbd-i2c / rc-hauppauge / linux-3.x broken

[Mauro Carvalho Chehab]

On 31-12-2011 09:17, Patrick Dickey wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 12/31/2011 05:07 AM, Mauro Carvalho Chehab wrote:
>> On 31-12-2011 08:15, Dorozel Csaba wrote:
>>>> Basically, the bridge driver is not sending the complete RC-5 
>>>> keycode to the IR core, but just the 8 least siginificant
>>>> bits. So, it is loosing the 0x1e00 code for the Hauppauge grey
>>>> remote.
>>>>
>>>> The fix should be at saa7134-input. It should be something
>>>> like the enclosed patch (I'm just guessing there that code3
>>>> contains the MSB bits - you may need to adjust it to match the
>>>> IR decoder there):
>>>
>>> I'm absolutly not a programer but an unhappy linux user who want
>>> his working remote back. Know nothing about c code, MSB bits ...
>>> After apply your fix looks what happening but remote is still
>>> broken.
>>>
>>> user juuzer # ir-keytable -t Testing events. Please, press CTRL-C
>>> to abort. 1325324726.066129: event MSC: scancode = de3d 
>>> 1325324726.066131: event sync 1325324726.169132: event MSC:
>>> scancode = de3d 1325324726.169134: event sync 1325324727.508129:
>>> event MSC: scancode = fe3d 1325324727.508131: event sync 
>>> 1325324727.611132: event MSC: scancode = fe3d 1325324727.611134:
>>> event sync 1325324730.084132: event MSC: scancode = de3d 
>>> 1325324730.084134: event sync 1325324730.187132: event MSC:
>>> scancode = de3d
>>>
>>> It seems the code3 sometimes return with de (11011110) sometimes
>>> fe (11111110). Is it possible to bitwise left 3 then bitwise
>>> right 3 so the result in both case is 1e (00011110) ? Or its
>>> totaly wrong ?
>>
>> An RC-5 code is just 14 bits. I found some Hauppauge decoders
>> returning just 12 bits on some places. It seems that all it needs
>> is to do a code3 | 0x3f, in order to discard the two most
>> significant bits (MSB).
>>
>> So, the enclosed patch should fix the issues. Please test.
>>
>> Regards, Mauro -
>>
>> saa7134-input: Fix get_key_hvr1110() handling
>>
>> Instead of returning just 8 bits, return the full RC-5 code
>>
>> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
>>
>> diff --git a/drivers/media/video/saa7134/saa7134-input.c
>> b/drivers/media/video/saa7134/saa7134-input.c index
>> d4ee24b..29c8efd 100644 ---
>> a/drivers/media/video/saa7134/saa7134-input.c +++
>> b/drivers/media/video/saa7134/saa7134-input.c @@ -249,8 +249,8 @@
>> static int get_key_hvr1110(struct IR_i2c *ir, u32 *ir_key, u32
>> *ir_raw) return 0;
>>
>> /* return key */ -	*ir_key = code4; -	*ir_raw = code4; +	*ir_key =
>> 0x3fff & (code4 | code3 << 8); +	*ir_raw = *ir_key; return 1; }
>>
>>
>> Regards, Mauro
>>>
>>
>> -- To unsubscribe from this list: send the line "unsubscribe
>> linux-media" in the body of a message to majordomo@vger.kernel.org 
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> Will this work regardless of what remote is being used?

No, they're separate issues. That fix is for HVR-1110 IR keycode
handling. It shouldn't affect anything else.

> Currently I'm
> using a Windows Media Center Remote (Hauppauge HVR-1600 provided it)
> with a combination of saa7134 (MSI TV@nywhere Plus) and Hauppauge
> HVR-1600 tuners. Right now, the Hauppauge works fine (all of this is
> in Mythtv 0.24), but the MSI crashes when I change channels.

So, there's some bug at the MSI handling. Please test the latest
media-build kernel and see if the crash condition still exists there.
If so, please open a separate thread describing what's happening and
posting the error logs (from dmesg).


> Have a great day:)
> Patrick.
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> 
> iEYEARECAAYFAk7+72UACgkQMp6rvjb3CAR2tQCgqSAc55bQyDEe3Z4vu0sUYAne
> RrQAoIU89vMVzI8UBH8v+dJxl3RsHj44
> =3joI
> -----END PGP SIGNATURE-----

Re: ir-kbd-i2c / rc-hauppauge / linux-3.x broken

[Mauro Carvalho Chehab]

On 31-12-2011 09:47, Dorozel Csaba wrote:
> 
>> An RC-5 code is just 14 bits. I found some Hauppauge decoders returning
>> just 12 bits on some places. It seems that all it needs is to do a
>> code3 | 0x3f, in order to discard the two most significant bits (MSB).
>>
>> So, the enclosed patch should fix the issues. Please test.
> 
> Half way .. something still wrong.
> 
> user juuzer # ir-keytable -t -d /dev/input/event6
> Testing events. Please, press CTRL-C to abort.
> 1325331995.343188: event MSC: scancode = 3e3d
> 1325331995.343190: event sync
> 1325331995.446127: event MSC: scancode = 3e3d
> 1325331995.446129: event sync
> 1325331997.504133: event MSC: scancode = 1e3d
> 1325331997.504135: event key down: KEY_POWER2 (0x0164)
> 1325331997.504136: event sync
> 1325331997.607137: event MSC: scancode = 1e3d
> 1325331997.607138: event sync
> 1325331997.857161: event key up: KEY_POWER2 (0x0164)
> 1325331997.857163: event sync
> 1325331999.973135: event MSC: scancode = 3e3d
> 1325331999.973136: event sync
> 1325332000.075130: event MSC: scancode = 3e3d
> 1325332000.075131: event sync

Changing the mask to 0x1fff would work, but this may not be the
right fix.

the hole idea is that other RC-5 devices could also be used with
the driver, but if the sub-routine is not doing the right thing, only
this remote will work.

Could you please try this patch, instead? It is just a debug patch,
so it won't fix the issue, but it may help us to identify what's
happening there.

Btw, do you have any other remote controllers producing Philips RC-5
codes? If so, could you also test with them and see what happens?

Regards,
Mauro

diff --git a/drivers/media/video/saa7134/saa7134-input.c b/drivers/media/video/saa7134/saa7134-input.c
index d4ee24b..783d44c 100644
--- a/drivers/media/video/saa7134/saa7134-input.c
+++ b/drivers/media/video/saa7134/saa7134-input.c
@@ -241,6 +241,9 @@ static int get_key_hvr1110(struct IR_i2c *ir, u32 *ir_key, u32 *ir_raw)
 	if (5 != i2c_master_recv(ir->c, buf, 5))
 		return -EIO;
 
+	printk("0x%02x 0x%02x 0x%02x 0x%02x 0x%02x",
+		buf[0], buf[1],buf[2],buf[3],buf[4]);
+
 	cod4	= buf[4];
 	code4	= (cod4 >> 2);
 	code3	= buf[3];

Re: ir-kbd-i2c / rc-hauppauge / linux-3.x broken

[Dorozel Csaba]

 
> Changing the mask to 0x1fff would work, but this may not be the
> right fix.
> 
> the hole idea is that other RC-5 devices could also be used with
> the driver, but if the sub-routine is not doing the right thing, only
> this remote will work.
> 
> Could you please try this patch, instead? It is just a debug patch,
> so it won't fix the issue, but it may help us to identify what's
> happening there.
> 
> Btw, do you have any other remote controllers producing Philips RC-5
> codes? If so, could you also test with them and see what happens?

Haven't got any other remote controllers with Philips RC-5 codes.

With the 0x1fff mask work. If im pushig the buttons to fast or holding donw the output look like
this (don't know is it normal):

ir-keytable -t -d /dev/input/event6
Testing events. Please, press CTRL-C to abort.
1325336612.877133: event MSC: scancode = 1e3d
1325336612.877136: event key down: KEY_POWER2 (0x0164)
1325336612.877137: event sync
1325336612.980130: event MSC: scancode = 1e3d
1325336612.980132: event sync
1325336613.083136: event MSC: scancode = 1e3d
1325336613.083138: event sync
1325336613.186133: event MSC: scancode = 1e3d
1325336613.186134: event sync
1325336613.289133: event MSC: scancode = 1e3d
1325336613.289135: event sync
1325336613.378155: event key down: KEY_POWER2 (0x0164)
1325336613.378156: event sync
1325336613.503153: event key down: KEY_POWER2 (0x0164)
1325336613.503154: event sync
1325336613.539111: event key up: KEY_POWER2 (0x0164)
1325336613.539112: event sync

With the debug patch dmesg is growing this without any remote activity:
[12672.782150] 0x00 0x00 0x00 0x00 0x00
[12672.884991] 0x00 0x00 0x00 0x00 0x00
[12672.987794] 0x00 0x00 0x00 0x00 0x00
[12673.090632] 0x00 0x00 0x00 0x00 0x00
[12673.193465] 0x00 0x00 0x00 0x00 0x00
[12673.296304] 0x00 0x00 0x00 0x00 0x00
...

When pushing fast a button:
[12791.990291] 0x80 0x00 0x00 0xfe 0xf4
[12792.093123] 0x00 0x00 0x00 0x00 0x00
[12792.195971] 0x80 0x00 0x00 0xde 0xf4
[12792.298805] 0x80 0x00 0x00 0xfe 0xf4
[12792.401632] 0x00 0x00 0x00 0x00 0x00
[12792.504472] 0x80 0x00 0x00 0xde 0xf4
[12792.607305] 0x00 0x00 0x00 0x00 0x00
[12792.710145] 0x80 0x00 0x00 0xfe 0xf4
[12792.812977] 0x00 0x00 0x00 0x00 0x00
[12792.915819] 0x00 0x00 0x00 0x00 0x00
[12793.018650] 0x80 0x00 0x00 0xfe 0xf4

When hold down a button:
12892.986456] 0x80 0x00 0x00 0xde 0xf4
[12893.089296] 0x80 0x00 0x00 0xde 0xf4
[12893.192186] 0x80 0x00 0x00 0xde 0xf4
[12893.295031] 0x80 0x00 0x00 0xde 0xf4
[12893.397802] 0x80 0x00 0x00 0xde 0xf4
[12893.500639] 0x80 0x00 0x00 0xde 0xf4
[12893.603474] 0x80 0x00 0x00 0xde 0xf4
[12893.706313] 0x80 0x00 0x00 0xde 0xf4
[12893.809146] 0x00 0x00 0x00 0x00 0x00
[12893.911985] 0x00 0x00 0x00 0x00 0x00
[12894.014822] 0x00 0x00 0x00 0x00 0x00
[12894.118122] 0x80 0x00 0x00 0xde 0xf4
[12894.220492] 0x80 0x00 0x00 0xde 0xf4
[12894.325446] 0x80 0x00 0x00 0xde 0xf4
[12894.428161] 0x80 0x00 0x00 0xde 0xf4
[12894.530999] 0x80 0x00 0x00 0xde 0xf4
[12894.633836] 0x80 0x00 0x00 0xde 0xf4
[12894.736672] 0x80 0x00 0x00 0xde 0xf4
[12894.839506] 0x80 0x00 0x00 0xde 0xf4
[12894.942348] 0x00 0x00 0x00 0x00 0x00
[12895.045178] 0x00 0x00 0x00 0x00 0x00
[12895.148017] 0x00 0x00 0x00 0x00 0x00
[12895.250850] 0x00 0x00 0x00 0x00 0x00

Re: ir-kbd-i2c / rc-hauppauge / linux-3.x broken

[Mauro Carvalho Chehab]

On 31-12-2011 11:22, Dorozel Csaba wrote:
>  
>> Changing the mask to 0x1fff would work, but this may not be the
>> right fix.
>>
>> the hole idea is that other RC-5 devices could also be used with
>> the driver, but if the sub-routine is not doing the right thing, only
>> this remote will work.
>>
>> Could you please try this patch, instead? It is just a debug patch,
>> so it won't fix the issue, but it may help us to identify what's
>> happening there.
>>
>> Btw, do you have any other remote controllers producing Philips RC-5
>> codes? If so, could you also test with them and see what happens?
> 
> Haven't got any other remote controllers with Philips RC-5 codes.
> 
> With the 0x1fff mask work. If im pushig the buttons to fast or holding donw the output look like
> this (don't know is it normal):
> 
> ir-keytable -t -d /dev/input/event6
> Testing events. Please, press CTRL-C to abort.
> 1325336612.877133: event MSC: scancode = 1e3d
> 1325336612.877136: event key down: KEY_POWER2 (0x0164)
> 1325336612.877137: event sync
> 1325336612.980130: event MSC: scancode = 1e3d
> 1325336612.980132: event sync
> 1325336613.083136: event MSC: scancode = 1e3d
> 1325336613.083138: event sync
> 1325336613.186133: event MSC: scancode = 1e3d
> 1325336613.186134: event sync
> 1325336613.289133: event MSC: scancode = 1e3d
> 1325336613.289135: event sync
> 1325336613.378155: event key down: KEY_POWER2 (0x0164)
> 1325336613.378156: event sync
> 1325336613.503153: event key down: KEY_POWER2 (0x0164)
> 1325336613.503154: event sync
> 1325336613.539111: event key up: KEY_POWER2 (0x0164)
> 1325336613.539112: event sync
> 
> With the debug patch dmesg is growing this without any remote activity:
> [12672.782150] 0x00 0x00 0x00 0x00 0x00
> [12672.884991] 0x00 0x00 0x00 0x00 0x00
> [12672.987794] 0x00 0x00 0x00 0x00 0x00
> [12673.090632] 0x00 0x00 0x00 0x00 0x00
> [12673.193465] 0x00 0x00 0x00 0x00 0x00
> [12673.296304] 0x00 0x00 0x00 0x00 0x00
> ...
> 
> When pushing fast a button:
> [12791.990291] 0x80 0x00 0x00 0xfe 0xf4
> [12792.093123] 0x00 0x00 0x00 0x00 0x00
> [12792.195971] 0x80 0x00 0x00 0xde 0xf4
> [12792.298805] 0x80 0x00 0x00 0xfe 0xf4
> [12792.401632] 0x00 0x00 0x00 0x00 0x00
> [12792.504472] 0x80 0x00 0x00 0xde 0xf4
> [12792.607305] 0x00 0x00 0x00 0x00 0x00
> [12792.710145] 0x80 0x00 0x00 0xfe 0xf4
> [12792.812977] 0x00 0x00 0x00 0x00 0x00
> [12792.915819] 0x00 0x00 0x00 0x00 0x00
> [12793.018650] 0x80 0x00 0x00 0xfe 0xf4
> 
> When hold down a button:
> 12892.986456] 0x80 0x00 0x00 0xde 0xf4
> [12893.089296] 0x80 0x00 0x00 0xde 0xf4
> [12893.192186] 0x80 0x00 0x00 0xde 0xf4
> [12893.295031] 0x80 0x00 0x00 0xde 0xf4
> [12893.397802] 0x80 0x00 0x00 0xde 0xf4
> [12893.500639] 0x80 0x00 0x00 0xde 0xf4
> [12893.603474] 0x80 0x00 0x00 0xde 0xf4
> [12893.706313] 0x80 0x00 0x00 0xde 0xf4
> [12893.809146] 0x00 0x00 0x00 0x00 0x00
> [12893.911985] 0x00 0x00 0x00 0x00 0x00
> [12894.014822] 0x00 0x00 0x00 0x00 0x00
> [12894.118122] 0x80 0x00 0x00 0xde 0xf4
> [12894.220492] 0x80 0x00 0x00 0xde 0xf4
> [12894.325446] 0x80 0x00 0x00 0xde 0xf4
> [12894.428161] 0x80 0x00 0x00 0xde 0xf4
> [12894.530999] 0x80 0x00 0x00 0xde 0xf4
> [12894.633836] 0x80 0x00 0x00 0xde 0xf4
> [12894.736672] 0x80 0x00 0x00 0xde 0xf4
> [12894.839506] 0x80 0x00 0x00 0xde 0xf4
> [12894.942348] 0x00 0x00 0x00 0x00 0x00
> [12895.045178] 0x00 0x00 0x00 0x00 0x00
> [12895.148017] 0x00 0x00 0x00 0x00 0x00
> [12895.250850] 0x00 0x00 0x00 0x00 0x00

OK, so, 0x1fff is the proper mask. bytes 1 and 2
are empty. byte 0 bit 8 is used only to indicate
a keypress.

It seems that bit 7 of byte 4 is a parity bit: it
changes its state every time a new key is pressed.

I'll add the patch with a proper documentation at the
kernel driver. Thanks for testing and reporting it!

Regards,
Mauro

[PATCH] [media] saa7134: fix IR handling for HVR-1110

[Mauro Carvalho Chehab]

Return the complete RC-5 code, instead of just the 8 least significant
bits.

Reported-by: Dorozel Csaba <mrjuuzer@upcmail.hu>
Tested-by: Dorozel Csaba <mrjuuzer@upcmail.hu>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>

---

Please, re-test this patch. It is a more detailed version of the
previous one, with a few more documentation, and some cleanups.


 drivers/media/video/saa7134/saa7134-input.c |   23 ++++++++++++++---------
 1 files changed, 14 insertions(+), 9 deletions(-)

diff --git a/drivers/media/video/saa7134/saa7134-input.c b/drivers/media/video/saa7134/saa7134-input.c
index d4ee24b..0e4926a 100644
--- a/drivers/media/video/saa7134/saa7134-input.c
+++ b/drivers/media/video/saa7134/saa7134-input.c
@@ -235,22 +235,27 @@ static int get_key_purpletv(struct IR_i2c *ir, u32 *ir_key, u32 *ir_raw)
 
 static int get_key_hvr1110(struct IR_i2c *ir, u32 *ir_key, u32 *ir_raw)
 {
-	unsigned char buf[5], cod4, code3, code4;
+	unsigned char buf[5], scancode;
 
 	/* poll IR chip */
 	if (5 != i2c_master_recv(ir->c, buf, 5))
 		return -EIO;
 
-	cod4	= buf[4];
-	code4	= (cod4 >> 2);
-	code3	= buf[3];
-	if (code3 == 0)
-		/* no key pressed */
+	/* Check if some key were pressed */
+	if (!(buf[0] & 0x80))
 		return 0;
 
-	/* return key */
-	*ir_key = code4;
-	*ir_raw = code4;
+	/*
+	 * buf[3] & 0x80 is always high.
+	 * buf[3] & 0x40 is a parity bit. A repeat event is marked
+	 * by preserving it into two separate readings
+	 * buf[4] bits 0 and 1, and buf[1] and buf[2] are always
+	 * zero.
+	 */
+	scancode = 0x1fff & ((buf[3] << 8) | (buf[4] >> 2));
+
+	*ir_key = scancode;
+	*ir_raw = scancode;
 	return 1;
 }
 
-- 
1.7.8.352.g876a6

Re: [PATCH] [media] saa7134: fix IR handling for HVR-1110

[Dorozel Csaba]

> Return the complete RC-5 code, instead of just the 8 least significant
> bits.
> 
> Reported-by: Dorozel Csaba <mrjuuzer@upcmail.hu>
> Tested-by: Dorozel Csaba <mrjuuzer@upcmail.hu>
> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
> 
> ---
> 
> Please, re-test this patch. It is a more detailed version of the
> previous one, with a few more documentation, and some cleanups.
> 
> 
>  drivers/media/video/saa7134/saa7134-input.c |   23 ++++++++++++++---------
>  1 files changed, 14 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/media/video/saa7134/saa7134-input.c
> b/drivers/media/video/saa7134/saa7134-input.c index d4ee24b..0e4926a 100644
> --- a/drivers/media/video/saa7134/saa7134-input.c
> +++ b/drivers/media/video/saa7134/saa7134-input.c
> @@ -235,22 +235,27 @@ static int get_key_purpletv(struct IR_i2c *ir, u32 *ir_key, u32 *ir_raw)
>  
>  static int get_key_hvr1110(struct IR_i2c *ir, u32 *ir_key, u32 *ir_raw)
>  {
> -	unsigned char buf[5], cod4, code3, code4;
> +	unsigned char buf[5], scancode;
>  
>  	/* poll IR chip */
>  	if (5 != i2c_master_recv(ir->c, buf, 5))
>  		return -EIO;
>  
> -	cod4	= buf[4];
> -	code4	= (cod4 >> 2);
> -	code3	= buf[3];
> -	if (code3 == 0)
> -		/* no key pressed */
> +	/* Check if some key were pressed */
> +	if (!(buf[0] & 0x80))
>  		return 0;
>  
> -	/* return key */
> -	*ir_key = code4;
> -	*ir_raw = code4;
> +	/*
> +	 * buf[3] & 0x80 is always high.
> +	 * buf[3] & 0x40 is a parity bit. A repeat event is marked
> +	 * by preserving it into two separate readings
> +	 * buf[4] bits 0 and 1, and buf[1] and buf[2] are always
> +	 * zero.
> +	 */
> +	scancode = 0x1fff & ((buf[3] << 8) | (buf[4] >> 2));
> +
> +	*ir_key = scancode;
> +	*ir_raw = scancode;
>  	return 1;
>  }
>  

Something is wrong with this patch.

user linux-current # ir-keytable -t -d /dev/input/event6
Testing events. Please, press CTRL-C to abort.
1325411805.906573: event MSC: scancode = 3d
1325411805.906575: event sync
1325411806.524576: event MSC: scancode = 3d
1325411806.524578: event sync
1325411806.627576: event MSC: scancode = 3d
1325411806.627578: event sync
1325411806.833581: event MSC: scancode = 3d
1325411806.833583: event sync
1325411806.936582: event MSC: scancode = 3d
1325411806.936583: event sync
1325411807.039576: event MSC: scancode = 3d
1325411807.039577: event sync
1325411807.245576: event MSC: scancode = 3d
1325411807.245578: event sync

Re: [PATCH] [media] saa7134: fix IR handling for HVR-1110

[Dorozel Csaba]

> Return the complete RC-5 code, instead of just the 8 least significant
> bits.
> 
> Reported-by: Dorozel Csaba <mrjuuzer@upcmail.hu>
> Tested-by: Dorozel Csaba <mrjuuzer@upcmail.hu>
> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
> 
> ---
> 
> Please, re-test this patch. It is a more detailed version of the
> previous one, with a few more documentation, and some cleanups.
> 
> 
>  drivers/media/video/saa7134/saa7134-input.c |   23 ++++++++++++++---------
>  1 files changed, 14 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/media/video/saa7134/saa7134-input.c
> b/drivers/media/video/saa7134/saa7134-input.c index d4ee24b..0e4926a 100644
> --- a/drivers/media/video/saa7134/saa7134-input.c
> +++ b/drivers/media/video/saa7134/saa7134-input.c
> @@ -235,22 +235,27 @@ static int get_key_purpletv(struct IR_i2c *ir, u32 *ir_key, u32 *ir_raw)
>  
>  static int get_key_hvr1110(struct IR_i2c *ir, u32 *ir_key, u32 *ir_raw)
>  {
> -	unsigned char buf[5], cod4, code3, code4;
> +	unsigned char buf[5], scancode;
>  
>  	/* poll IR chip */
>  	if (5 != i2c_master_recv(ir->c, buf, 5))
>  		return -EIO;
>  
> -	cod4	= buf[4];
> -	code4	= (cod4 >> 2);
> -	code3	= buf[3];
> -	if (code3 == 0)
> -		/* no key pressed */
> +	/* Check if some key were pressed */
> +	if (!(buf[0] & 0x80))
>  		return 0;
>  
> -	/* return key */
> -	*ir_key = code4;
> -	*ir_raw = code4;
> +	/*
> +	 * buf[3] & 0x80 is always high.
> +	 * buf[3] & 0x40 is a parity bit. A repeat event is marked
> +	 * by preserving it into two separate readings
> +	 * buf[4] bits 0 and 1, and buf[1] and buf[2] are always
> +	 * zero.
> +	 */
> +	scancode = 0x1fff & ((buf[3] << 8) | (buf[4] >> 2));
> +
> +	*ir_key = scancode;
> +	*ir_raw = scancode;
>  	return 1;
>  }
>  

A bit strange for me:

This code is failed:
        scancode = 0x1fff & ((buf[3] << 8) | (buf[4] >> 2));
        *ir_key = scancode;
        *ir_raw = scancode;

This code is working:
        *ir_key = 0x1fff & ((buf[3] << 8) | (buf[4] >> 2));
        *ir_raw = *ir_key;

Re: [PATCH] [media] saa7134: fix IR handling for HVR-1110

[Mauro Carvalho Chehab]

On 01-01-2012 12:14, Dorozel Csaba wrote:
> 
>> Return the complete RC-5 code, instead of just the 8 least significant
>> bits.
>>
>> Reported-by: Dorozel Csaba <mrjuuzer@upcmail.hu>
>> Tested-by: Dorozel Csaba <mrjuuzer@upcmail.hu>
>> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
>>
>> ---
>>
>> Please, re-test this patch. It is a more detailed version of the
>> previous one, with a few more documentation, and some cleanups.
>>
>>
>>  drivers/media/video/saa7134/saa7134-input.c |   23 ++++++++++++++---------
>>  1 files changed, 14 insertions(+), 9 deletions(-)
>>
>> diff --git a/drivers/media/video/saa7134/saa7134-input.c
>> b/drivers/media/video/saa7134/saa7134-input.c index d4ee24b..0e4926a 100644
>> --- a/drivers/media/video/saa7134/saa7134-input.c
>> +++ b/drivers/media/video/saa7134/saa7134-input.c
>> @@ -235,22 +235,27 @@ static int get_key_purpletv(struct IR_i2c *ir, u32 *ir_key, u32 *ir_raw)
>>  
>>  static int get_key_hvr1110(struct IR_i2c *ir, u32 *ir_key, u32 *ir_raw)
>>  {
>> -	unsigned char buf[5], cod4, code3, code4;
>> +	unsigned char buf[5], scancode;
>>  
>>  	/* poll IR chip */
>>  	if (5 != i2c_master_recv(ir->c, buf, 5))
>>  		return -EIO;
>>  
>> -	cod4	= buf[4];
>> -	code4	= (cod4 >> 2);
>> -	code3	= buf[3];
>> -	if (code3 == 0)
>> -		/* no key pressed */
>> +	/* Check if some key were pressed */
>> +	if (!(buf[0] & 0x80))
>>  		return 0;
>>  
>> -	/* return key */
>> -	*ir_key = code4;
>> -	*ir_raw = code4;
>> +	/*
>> +	 * buf[3] & 0x80 is always high.
>> +	 * buf[3] & 0x40 is a parity bit. A repeat event is marked
>> +	 * by preserving it into two separate readings
>> +	 * buf[4] bits 0 and 1, and buf[1] and buf[2] are always
>> +	 * zero.
>> +	 */
>> +	scancode = 0x1fff & ((buf[3] << 8) | (buf[4] >> 2));
>> +
>> +	*ir_key = scancode;
>> +	*ir_raw = scancode;
>>  	return 1;
>>  }
>>  
> 
> A bit strange for me:
> 
> This code is failed:
>         scancode = 0x1fff & ((buf[3] << 8) | (buf[4] >> 2));
>         *ir_key = scancode;
>         *ir_raw = scancode;
> 
> This code is working:
>         *ir_key = 0x1fff & ((buf[3] << 8) | (buf[4] >> 2));
>         *ir_raw = *ir_key;


Gah! scancode should be "unsigned int" and not "unsigned char".

Anyway, let's simplify it by removing "scancode". There's no need
for an ancillary var there.

Please test the latest version.

Regards,
Mauro

-

>From 641269f9583c5c3535dff9c66de13a8216f791a5 Mon Sep 17 00:00:00 2001
From: Mauro Carvalho Chehab <mchehab@redhat.com>
Date: Sat, 31 Dec 2011 18:56:24 -0200
Subject: [PATCH] [media] saa7134: fix IR handling for HVR-1110

Return the complete RC-5 code, instead of just the 8 least significant
bits.

Reported-by: Dorozel Csaba <mrjuuzer@upcmail.hu>
Tested-by: Dorozel Csaba <mrjuuzer@upcmail.hu>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>

diff --git a/drivers/media/video/saa7134/saa7134-input.c b/drivers/media/video/saa7134/saa7134-input.c
index d4ee24b..1b15b0d 100644
--- a/drivers/media/video/saa7134/saa7134-input.c
+++ b/drivers/media/video/saa7134/saa7134-input.c
@@ -235,22 +235,25 @@ static int get_key_purpletv(struct IR_i2c *ir, u32 *ir_key, u32 *ir_raw)
 
 static int get_key_hvr1110(struct IR_i2c *ir, u32 *ir_key, u32 *ir_raw)
 {
-	unsigned char buf[5], cod4, code3, code4;
+	unsigned char buf[5];
 
 	/* poll IR chip */
 	if (5 != i2c_master_recv(ir->c, buf, 5))
 		return -EIO;
 
-	cod4	= buf[4];
-	code4	= (cod4 >> 2);
-	code3	= buf[3];
-	if (code3 == 0)
-		/* no key pressed */
+	/* Check if some key were pressed */
+	if (!(buf[0] & 0x80))
 		return 0;
 
-	/* return key */
-	*ir_key = code4;
-	*ir_raw = code4;
+	/*
+	 * buf[3] & 0x80 is always high.
+	 * buf[3] & 0x40 is a parity bit. A repeat event is marked
+	 * by preserving it into two separate readings
+	 * buf[4] bits 0 and 1, and buf[1] and buf[2] are always
+	 * zero.
+	 */
+	*ir_key = 0x1fff & ((buf[3] << 8) | (buf[4] >> 2));
+	*ir_raw = *ir_key;
 	return 1;
 }
 

Re: [PATCH] [media] saa7134: fix IR handling for HVR-1110

[Dorozel Csaba]

> Please test the latest version.

This is it! Work fine for me.

Thanks!