tm6000 and ir

tm6000 and ir

[Stefan Ringel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
 
Hi Mauro,

I write actually the ir implementation (tm6000-input.c). Can you give
me any stuff what can help me?

Stefan Ringel
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.12 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
 
iQEcBAEBAgAGBQJMCWoFAAoJEAWtPFjxMvFGvn8H/iJ2Xg4cabtrdDEgQ9WbXA+C
TH6FTsqQ6eOZTkEOUxAkKOWXi+12UGrdqhQC6twqulhPpRi4bJm6kEqM8reeZJCl
EUvqkfQdkqOrnhDnAvj1Q1sp/RLHLjXpCUFOk43f+fwnA2bc3/CJk2uKeMNDtLa7
f1pIN4Eu7+by7K0SPFW3qlmKoTO6bEFmBUCxtrszJFBVVpcpeX4iAoQ693Q5LFCb
FTjPRpKFRdS47WGlXP4jBgC8DQ70KjNCVoXFiqeVbfCDEdYunhjPytxzVkD0Zgij
WXbuTrfpoGIzOJ0QOXr7Fj8XaAMmlEIjzqTeviY/MLUMdOKxpaR4TMHXYkvuQvA=
=loGv
-----END PGP SIGNATURE-----

Re: tm6000 and ir

[Mauro Carvalho Chehab]

Hi Stefan,

Em 04-06-2010 18:03, Stefan Ringel escreveu:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>  
> Hi Mauro,
> 
> I write actually the ir implementation (tm6000-input.c). Can you give
> me any stuff what can help me?

I never tried to implement IR support for tm6000, but if you use the
em28xx-input as reference, it shouldn't be hard to add support for IR.

I suspect that tm6000 have a hardware/firmware IR decoder, probably
capable of handling NEC and RC-5 protocols. 

Probably, all that you need to do is to send some initialization sequence
at tm6000-input and periodically try to get data via URB (for example, you
may run a workqueue or a timer, on every 50 ms, checking for the code 
reception). You may use the rc-empty table on your initial tests and, after
having it working, you'll need to create a keymap table with your IR.

Cheers,
Mauro.

Re: tm6000 and IR

[Dmitri Belimov]

Hi

What about my last patch?? This is OK or bad?
Our customers kick me every day with IR remotes.

With my best regards, Dmitry.

Re: tm6000 and IR

[Stefan Ringel]

Am 14.12.2010 04:23, schrieb Dmitri Belimov:
> Hi
>
> What about my last patch?? This is OK or bad?
> Our customers kick me every day with IR remotes.
>
> With my best regards, Dmitry.
I think, you use the second variant, Dmitry.
Why you doesn't use this key map - RCMAP_BEHOLD.
The power led we can change to a separate function, right. The nec 
initiation looks right and must adding code for tm5600/6000 (going over 
message pipe). rc5 need some code for tm6010 (for tm5600/6000 are the 
hack). And the logic for your remote control is unused  for the second 
variant, but ir->rc_type = rc_type are o.k..
Then the function call usb_set_interface in tm6000_video, can write for 
example:

stop_ir_pipe
usb_set_interface
start_ir_pipe

I will adding vbi_buffer and device in the next, and isoc calculating 
without video_buffer size.

Stefan Ringel

Re: tm6000 and IR

[Dmitri Belimov]

Hi Stefan

> Am 14.12.2010 04:23, schrieb Dmitri Belimov:
> > Hi
> >
> > What about my last patch?? This is OK or bad?
> > Our customers kick me every day with IR remotes.
> >
> > With my best regards, Dmitry.
> I think, you use the second variant, Dmitry.
> Why you doesn't use this key map - RCMAP_BEHOLD.

No this remotes is different. RCMAP_BEHOLD has more buttons and some other scancodes.
People from linux community who was made this keymap and function for reading data from
IR decoder has error with scancode. 
Our true address of scancode is
0x86 0x6B
They wrote 
0x6B 0x86
Need fix some code of the saa7134-input and RCMAP_BEHOLD keytable.

RCMAP_BEHOLD_WANDER same as RCMAP_BEHOLD_COLUMBUS but
from IR decoder the saa7134 received only one byte of scancode.
Need rework saa7134-input too for get address and restore full scancodes for extended NEC full
scancodes.

I'll make it after some time.

> The power led we can change to a separate function, right. 

Ok

> The nec initiation looks right and must adding code for tm5600/6000 (going
> over message pipe).

I haven't USB stick with tm5600/6000 for test. Need people with this TV cards.

> rc5 need some code for tm6010 (for tm5600/6000 are the hack).

I didn't touch this code because I haven't RC5 remotes and tm5600/6000

> And the logic for your remote control is unused  for
> the second variant, but ir->rc_type = rc_type are o.k..

I think your mean is wrong. Our IR remotes send extended NEC it is 4 bytes.
We removed inverted 4 byte and now we have 3 bytes from remotes. I think we
must have full RCMAP with this 3 bytes from remotes. And use this remotes with some
different IR recievers like some TV cards and LIRC-hardware and other.
No need different RCMAP for the same remotes to different IR recievers like now.

If we use second variant I can't use RCMAP_BEHOLD because it has full 3 bytes scancodes. 
As you wrote.

> Then the function call usb_set_interface in tm6000_video, can write
> for example:
> 
> stop_ir_pipe
> usb_set_interface
> start_ir_pipe

Ok, I'll try.

> I will adding vbi_buffer and device in the next, and isoc calculating 
> without video_buffer size.

I try add radio.
 
With my best regards, Dmitry.

Re: tm6000 and IR

[Stefan Ringel]

Am 15.12.2010 08:46, schrieb Dmitri Belimov:
> Hi Stefan
>
>> Am 14.12.2010 04:23, schrieb Dmitri Belimov:
>>> Hi
>>>
>>> What about my last patch?? This is OK or bad?
>>> Our customers kick me every day with IR remotes.
>>>
>>> With my best regards, Dmitry.
>> I think, you use the second variant, Dmitry.
>> Why you doesn't use this key map - RCMAP_BEHOLD.
> No this remotes is different. RCMAP_BEHOLD has more buttons and some other scancodes.
> People from linux community who was made this keymap and function for reading data from
> IR decoder has error with scancode.
> Our true address of scancode is
> 0x86 0x6B
> They wrote
> 0x6B 0x86
> Need fix some code of the saa7134-input and RCMAP_BEHOLD keytable.
>
> RCMAP_BEHOLD_WANDER same as RCMAP_BEHOLD_COLUMBUS but
> from IR decoder the saa7134 received only one byte of scancode.
> Need rework saa7134-input too for get address and restore full scancodes for extended NEC full
> scancodes.
>
> I'll make it after some time.
>
>> The power led we can change to a separate function, right.
> Ok
>
>> The nec initiation looks right and must adding code for tm5600/6000 (going
>> over message pipe).
> I haven't USB stick with tm5600/6000 for test. Need people with this TV cards.
>
then add a todo line.
>> rc5 need some code for tm6010 (for tm5600/6000 are the hack).
> I didn't touch this code because I haven't RC5 remotes and tm5600/6000
>
>> And the logic for your remote control is unused  for
>> the second variant, but ir->rc_type = rc_type are o.k.
but the line ir->rc_type = rc_type; are o.k.

> I think your mean is wrong. Our IR remotes send extended NEC it is 4 bytes.
> We removed inverted 4 byte and now we have 3 bytes from remotes. I think we
> must have full RCMAP with this 3 bytes from remotes. And use this remotes with some
> different IR recievers like some TV cards and LIRC-hardware and other.
> No need different RCMAP for the same remotes to different IR recievers like now.
Your change doesn't work with my terratec remote control !!
> If we use second variant I can't use RCMAP_BEHOLD because it has full 3 bytes scancodes.
> As you wrote.
>
And if you use two bytes rc map table. We have add filter for address 
and commands to pass all. With an external tool can change the map ( 
ir_keytable). Why you will use more than two bytes.
>> Then the function call usb_set_interface in tm6000_video, can write
>> for example:
>>
>> stop_ir_pipe
>> usb_set_interface
>> start_ir_pipe
> Ok, I'll try.
>
>> I will adding vbi_buffer and device in the next, and isoc calculating
>> without video_buffer size.
> I try add radio.
>
> With my best regards, Dmitry.
> --
> 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

Re: tm6000 and IR

[Dmitri Belimov]

Hi Stefan

> >> The nec initiation looks right and must adding code for
> >> tm5600/6000 (going over message pipe).
> > I haven't USB stick with tm5600/6000 for test. Need people with
> > this TV cards.
> >
> then add a todo line.

I'll do it.

> >> rc5 need some code for tm6010 (for tm5600/6000 are the hack).
> > I didn't touch this code because I haven't RC5 remotes and
> > tm5600/6000
> >
> >> And the logic for your remote control is unused  for
> >> the second variant, but ir->rc_type = rc_type are o.k.
> but the line ir->rc_type = rc_type; are o.k.
> 
> > I think your mean is wrong. Our IR remotes send extended NEC it is
> > 4 bytes. We removed inverted 4 byte and now we have 3 bytes from
> > remotes. I think we must have full RCMAP with this 3 bytes from
> > remotes. And use this remotes with some different IR recievers like
> > some TV cards and LIRC-hardware and other. No need different RCMAP
> > for the same remotes to different IR recievers like now.
> Your change doesn't work with my terratec remote control !!

I'll try solve this problem don't worry.

> > If we use second variant I can't use RCMAP_BEHOLD because it has
> > full 3 bytes scancodes. As you wrote.
> >
> And if you use two bytes rc map table. We have add filter for address 
> and commands to pass all. With an external tool can change the map ( 
> ir_keytable). Why you will use more than two bytes.

With my last code this tool is working. When you call change_protocol new
value of address stored. But if a keytable of remotes hasn't full scancodes it
doesn't work

How to main IR core search scancodes in RCMAP keytable?
I think it search full equal scancode value with returned from tm6000.

Example:
defined keytable:
0x86 0x6B 0x00

tm6000 read IR data
0x86 0x00

When return 0x86 0x00 to IR core a key is unknown because
0x86 0x6B 0x00 != 0x86 0x00

I think we can have two different solutions:

1. My variant. When init IR tm6000, get full address from a keytable, store it. After key filtering
restore full scancode and return it to IR core -> 0x86 0x6B 0x00. A keytable must has really full scancodes.

2. More simple. A keytable has only data byte. Get IR data and return only data byte without filtering because
a keytable hasn't this information. This is bad the TV card can do some task by other IR remotes. Or add some place where 
stored filter information and update filter when keytable replaced.

With my best regards, Dmitry.

Re: tm6000 and IR

[Dmitri Belimov]

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

Hi

> > I think your mean is wrong. Our IR remotes send extended NEC it is
> > 4 bytes. We removed inverted 4 byte and now we have 3 bytes from
> > remotes. I think we must have full RCMAP with this 3 bytes from
> > remotes. And use this remotes with some different IR recievers like
> > some TV cards and LIRC-hardware and other. No need different RCMAP
> > for the same remotes to different IR recievers like now.
> Your change doesn't work with my terratec remote control !!

I found what happens. Try my new patch.

What about NEC. Original NEC send
address (inverted address) key (inverted key)
this is realy old standart now all remotes use extended NEC 
(adress high) (address low) key (inverted key)
The trident 5600/6000/6010 use old protocol but didn't test inverted address byte.

I think much better discover really address value and write it to keytable.
For your remotes I add low address byte. This value is incorrent but usefull for tm6000.
When you found correct value update keytable.

> >> Then the function call usb_set_interface in tm6000_video, can write
> >> for example:
> >>
> >> stop_ir_pipe
> >> usb_set_interface
> >> start_ir_pipe
> > Ok, I'll try.

See dmesg. I was add function for start/stop interrupt urbs
All works well.

With my best regards, Dmitry.

[-- Attachment #2: rc-behold-wander.c --]
[-- Type: text/x-c++src, Size: 3028 bytes --]

/* behold-wander.h - Keytable for behold_wander Remote Controller
 *
 * keymap imported from ir-keymaps.c
 *
 * Copyright (c) 2010 by Mauro Carvalho Chehab <mchehab@redhat.com>
 *
 * This program is free software; you can redistribute it and/or modify
 * it under the terms of the GNU General Public License as published by
 * the Free Software Foundation; either version 2 of the License, or
 * (at your option) any later version.
 */

#include <media/rc-map.h>

/* Beholder Intl. Ltd. 2010
 * Dmitry Belimov d.belimov@google.com
 * Keytable is used by BeholdTV Wander/Voyage
 * The "ascii-art picture" below (in comments, first row
 * is the keycode in hex, and subsequent row(s) shows
 * the button labels (several variants when appropriate)
 * helps to descide which keycodes to assign to the buttons.
 */

static struct rc_map_table behold_wander[] = {

	/*  0x13   0x11   0x1C   0x12  *
	 *  Mute  Source  TV/FM  Power *
	 *                             */

	{ 0x866b13, KEY_MUTE },
	{ 0x866b11, KEY_PROPS },
	{ 0x866b1C, KEY_TUNER },	/* KEY_TV/KEY_RADIO	*/
	{ 0x866b12, KEY_POWER },

	/*  0x01    0x02    0x03  0x0D    *
	 *   1       2       3   Stereo   *
	 *                        	  *
	 *  0x04    0x05    0x06  0x19    *
	 *   4       5       6   Snapshot *
	 *                        	  *
	 *  0x07    0x08    0x09  0x10    *
	 *   7       8       9    Zoom 	  *
	 *                                */
	{ 0x866b01, KEY_1 },
	{ 0x866b02, KEY_2 },
	{ 0x866b03, KEY_3 },
	{ 0x866b0D, KEY_SETUP },	  /* Setup key */
	{ 0x866b04, KEY_4 },
	{ 0x866b05, KEY_5 },
	{ 0x866b06, KEY_6 },
	{ 0x866b19, KEY_CAMERA },	/* Snapshot key */
	{ 0x866b07, KEY_7 },
	{ 0x866b08, KEY_8 },
	{ 0x866b09, KEY_9 },
	{ 0x866b10, KEY_ZOOM },

	/*  0x0A    0x00    0x0B       0x0C   *
	 * RECALL    0    ChannelUp  VolumeUp *
	 *                                    */
	{ 0x866b0A, KEY_AGAIN },
	{ 0x866b00, KEY_0 },
	{ 0x866b0B, KEY_CHANNELUP },
	{ 0x866b0C, KEY_VOLUMEUP },

	/*   0x1B      0x1D      0x15        0x18     *
	 * Timeshift  Record  ChannelDown  VolumeDown *
	 *                                            */

	{ 0x866b1B, KEY_TIME },
	{ 0x866b1D, KEY_RECORD },
	{ 0x866b15, KEY_CHANNELDOWN },
	{ 0x866b18, KEY_VOLUMEDOWN },

	/*   0x0E   0x1E     0x0F     0x1A  *
	 *   Stop   Pause  Previouse  Next  *
	 *                                  */

	{ 0x866b0E, KEY_STOP },
	{ 0x866b1E, KEY_PAUSE },
	{ 0x866b0F, KEY_PREVIOUS },
	{ 0x866b1A, KEY_NEXT },

};

static struct rc_map_list behold_wander_map = {
	.map = {
		.scan    = behold_wander,
		.size    = ARRAY_SIZE(behold_wander),
		.rc_type = RC_TYPE_NEC,	/* Legacy IR type */
		.name    = RC_MAP_BEHOLD_WANDER,
	}
};

static int __init init_rc_map_behold_wander(void)
{
	return rc_map_register(&behold_wander_map);
}

static void __exit exit_rc_map_behold_wander(void)
{
	rc_map_unregister(&behold_wander_map);
}

module_init(init_rc_map_behold_wander)
module_exit(exit_rc_map_behold_wander)

MODULE_LICENSE("GPL");
MODULE_AUTHOR("Mauro Carvalho Chehab <mchehab@redhat.com>");

[-- Attachment #3: tm6000_ir_behold_04.diff --]
[-- Type: text/x-patch, Size: 16096 bytes --]

diff --git a/drivers/media/rc/keymaps/Makefile b/drivers/media/rc/keymaps/Makefile
index 3194d39..cf7622f 100644
--- a/drivers/media/rc/keymaps/Makefile
+++ b/drivers/media/rc/keymaps/Makefile
@@ -15,6 +15,7 @@ obj-$(CONFIG_RC_MAP) += rc-adstech-dvb-t-pci.o \
 			rc-azurewave-ad-tu700.o \
 			rc-behold.o \
 			rc-behold-columbus.o \
+			rc-behold-wander.o \
 			rc-budget-ci-old.o \
 			rc-cinergy-1400.o \
 			rc-cinergy.o \
diff --git a/drivers/media/rc/keymaps/rc-nec-terratec-cinergy-xs.c b/drivers/media/rc/keymaps/rc-nec-terratec-cinergy-xs.c
index 26f114c..bbcb698 100644
--- a/drivers/media/rc/keymaps/rc-nec-terratec-cinergy-xs.c
+++ b/drivers/media/rc/keymaps/rc-nec-terratec-cinergy-xs.c
@@ -14,69 +14,76 @@
 
 /* Terratec Cinergy Hybrid T USB XS FM
    Mauro Carvalho Chehab <mchehab@redhat.com>
+
+   TODO: This IR remote use extended NEC protocol
+         the tm6000 can read only 1 and 3 bytes of them
+         the 4 byte is invert of the 3 byte. We unknown the 2 byte.
+         Need test this remotes with much better IR receiver
+         and determine the 2 byte. Now the 2 byte is 0xff for compatibility.
+                             Dmitry Belimov <d.belimov@gmail.com>
  */
 
 static struct rc_map_table nec_terratec_cinergy_xs[] = {
-	{ 0x1441, KEY_HOME},
-	{ 0x1401, KEY_POWER2},
-
-	{ 0x1442, KEY_MENU},		/* DVD menu */
-	{ 0x1443, KEY_SUBTITLE},
-	{ 0x1444, KEY_TEXT},		/* Teletext */
-	{ 0x1445, KEY_DELETE},
-
-	{ 0x1402, KEY_1},
-	{ 0x1403, KEY_2},
-	{ 0x1404, KEY_3},
-	{ 0x1405, KEY_4},
-	{ 0x1406, KEY_5},
-	{ 0x1407, KEY_6},
-	{ 0x1408, KEY_7},
-	{ 0x1409, KEY_8},
-	{ 0x140a, KEY_9},
-	{ 0x140c, KEY_0},
-
-	{ 0x140b, KEY_TUNER},		/* AV */
-	{ 0x140d, KEY_MODE},		/* A.B */
-
-	{ 0x1446, KEY_TV},
-	{ 0x1447, KEY_DVD},
-	{ 0x1449, KEY_VIDEO},
-	{ 0x144a, KEY_RADIO},		/* Music */
-	{ 0x144b, KEY_CAMERA},		/* PIC */
-
-	{ 0x1410, KEY_UP},
-	{ 0x1411, KEY_LEFT},
-	{ 0x1412, KEY_OK},
-	{ 0x1413, KEY_RIGHT},
-	{ 0x1414, KEY_DOWN},
-
-	{ 0x140f, KEY_EPG},
-	{ 0x1416, KEY_INFO},
-	{ 0x144d, KEY_BACKSPACE},
-
-	{ 0x141c, KEY_VOLUMEUP},
-	{ 0x141e, KEY_VOLUMEDOWN},
-
-	{ 0x144c, KEY_PLAY},
-	{ 0x141d, KEY_MUTE},
-
-	{ 0x141b, KEY_CHANNELUP},
-	{ 0x141f, KEY_CHANNELDOWN},
-
-	{ 0x1417, KEY_RED},
-	{ 0x1418, KEY_GREEN},
-	{ 0x1419, KEY_YELLOW},
-	{ 0x141a, KEY_BLUE},
-
-	{ 0x1458, KEY_RECORD},
-	{ 0x1448, KEY_STOP},
-	{ 0x1440, KEY_PAUSE},
-
-	{ 0x1454, KEY_LAST},
-	{ 0x144e, KEY_REWIND},
-	{ 0x144f, KEY_FASTFORWARD},
-	{ 0x145c, KEY_NEXT},
+	{ 0x14ff41, KEY_HOME},
+	{ 0x14ff01, KEY_POWER2},
+
+	{ 0x14ff42, KEY_MENU},		/* DVD menu */
+	{ 0x14ff43, KEY_SUBTITLE},
+	{ 0x14ff44, KEY_TEXT},		/* Teletext */
+	{ 0x14ff45, KEY_DELETE},
+
+	{ 0x14ff02, KEY_1},
+	{ 0x14ff03, KEY_2},
+	{ 0x14ff04, KEY_3},
+	{ 0x14ff05, KEY_4},
+	{ 0x14ff06, KEY_5},
+	{ 0x14ff07, KEY_6},
+	{ 0x14ff08, KEY_7},
+	{ 0x14ff09, KEY_8},
+	{ 0x14ff0a, KEY_9},
+	{ 0x14ff0c, KEY_0},
+
+	{ 0x14ff0b, KEY_TUNER},		/* AV */
+	{ 0x14ff0d, KEY_MODE},		/* A.B */
+
+	{ 0x14ff46, KEY_TV},
+	{ 0x14ff47, KEY_DVD},
+	{ 0x14ff49, KEY_VIDEO},
+	{ 0x14ff4a, KEY_RADIO},		/* Music */
+	{ 0x14ff4b, KEY_CAMERA},		/* PIC */
+
+	{ 0x14ff10, KEY_UP},
+	{ 0x14ff11, KEY_LEFT},
+	{ 0x14ff12, KEY_OK},
+	{ 0x14ff13, KEY_RIGHT},
+	{ 0x14ff14, KEY_DOWN},
+
+	{ 0x14ff0f, KEY_EPG},
+	{ 0x14ff16, KEY_INFO},
+	{ 0x14ff4d, KEY_BACKSPACE},
+
+	{ 0x14ff1c, KEY_VOLUMEUP},
+	{ 0x14ff1e, KEY_VOLUMEDOWN},
+
+	{ 0x14ff4c, KEY_PLAY},
+	{ 0x14ff1d, KEY_MUTE},
+
+	{ 0x14ff1b, KEY_CHANNELUP},
+	{ 0x14ff1f, KEY_CHANNELDOWN},
+
+	{ 0x14ff17, KEY_RED},
+	{ 0x14ff18, KEY_GREEN},
+	{ 0x14ff19, KEY_YELLOW},
+	{ 0x14ff1a, KEY_BLUE},
+
+	{ 0x14ff58, KEY_RECORD},
+	{ 0x14ff48, KEY_STOP},
+	{ 0x14ff40, KEY_PAUSE},
+
+	{ 0x14ff54, KEY_LAST},
+	{ 0x14ff4e, KEY_REWIND},
+	{ 0x14ff4f, KEY_FASTFORWARD},
+	{ 0x14ff5c, KEY_NEXT},
 };
 
 static struct rc_map_list nec_terratec_cinergy_xs_map = {
diff --git a/drivers/staging/tm6000/TODO b/drivers/staging/tm6000/TODO
index 34780fc..135d0ea 100644
--- a/drivers/staging/tm6000/TODO
+++ b/drivers/staging/tm6000/TODO
@@ -1,4 +1,6 @@
 There a few things to do before putting this driver in production:
+	- IR NEC with tm5600/6000 TV cards
+	- IR RC5 with tm5600/6000/6010 TV cards
 	- CodingStyle;
 	- Fix audio;
 	- Fix some panic/OOPS conditions.
diff --git a/drivers/staging/tm6000/tm6000-cards.c b/drivers/staging/tm6000/tm6000-cards.c
index 1c9374a..59ee241 100644
--- a/drivers/staging/tm6000/tm6000-cards.c
+++ b/drivers/staging/tm6000/tm6000-cards.c
@@ -239,6 +239,7 @@ struct tm6000_board tm6000_boards[] = {
 			.demod_reset	= TM6010_GPIO_1,
 			.power_led	= TM6010_GPIO_6,
 		},
+		.ir_codes = RC_MAP_BEHOLD_WANDER,
 	},
 	[TM6010_BOARD_BEHOLD_VOYAGER] = {
 		.name         = "Beholder Voyager TV/FM USB2.0",
@@ -256,6 +257,7 @@ struct tm6000_board tm6000_boards[] = {
 			.tuner_reset	= TM6010_GPIO_0,
 			.power_led	= TM6010_GPIO_6,
 		},
+		.ir_codes = RC_MAP_BEHOLD_WANDER,
 	},
 	[TM6010_BOARD_TERRATEC_CINERGY_HYBRID_XE] = {
 		.name         = "Terratec Cinergy Hybrid XE / Cinergy Hybrid-Stick",
@@ -328,6 +330,47 @@ struct usb_device_id tm6000_id_table[] = {
 	{ },
 };
 
+/* Control power led for show some activity */
+void tm6000_flash_led(struct tm6000_core *dev, u8 state)
+{
+	/* Power LED unconfigured */
+	if (!dev->gpio.power_led)
+		return;
+
+	/* ON Power LED */
+	if (state) {
+		switch (dev->model) {
+		case TM6010_BOARD_HAUPPAUGE_900H:
+		case TM6010_BOARD_TERRATEC_CINERGY_HYBRID_XE:
+		case TM6010_BOARD_TWINHAN_TU501:
+			tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN,
+				dev->gpio.power_led, 0x00);
+			break;
+		case TM6010_BOARD_BEHOLD_WANDER:
+		case TM6010_BOARD_BEHOLD_VOYAGER:
+			tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN,
+				dev->gpio.power_led, 0x01);
+			break;
+		}
+	}
+	/* OFF Power LED */
+	else {
+		switch (dev->model) {
+		case TM6010_BOARD_HAUPPAUGE_900H:
+		case TM6010_BOARD_TERRATEC_CINERGY_HYBRID_XE:
+		case TM6010_BOARD_TWINHAN_TU501:
+			tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN,
+				dev->gpio.power_led, 0x01);
+			break;
+		case TM6010_BOARD_BEHOLD_WANDER:
+		case TM6010_BOARD_BEHOLD_VOYAGER:
+			tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN,
+				dev->gpio.power_led, 0x00);
+			break;
+		}
+	}
+}
+
 /* Tuner callback to provide the proper gpio changes needed for xc5000 */
 int tm6000_xc5000_callback(void *ptr, int component, int command, int arg)
 {
diff --git a/drivers/staging/tm6000/tm6000-input.c b/drivers/staging/tm6000/tm6000-input.c
index e02ea67..cae1f96 100644
--- a/drivers/staging/tm6000/tm6000-input.c
+++ b/drivers/staging/tm6000/tm6000-input.c
@@ -37,6 +37,10 @@ static unsigned int enable_ir = 1;
 module_param(enable_ir, int, 0644);
 MODULE_PARM_DESC(enable_ir, "enable ir (default is enable)");
 
+/* number of 50ms for ON-OFF-ON power led */
+/* show IR activity */
+#define PWLED_OFF 2
+
 #undef dprintk
 
 #define dprintk(fmt, arg...) \
@@ -45,7 +49,7 @@ MODULE_PARM_DESC(enable_ir, "enable ir (default is enable)");
 	}
 
 struct tm6000_ir_poll_result {
-	u16 rc_data;
+	u32 rc_data;
 };
 
 struct tm6000_IR {
@@ -59,6 +63,9 @@ struct tm6000_IR {
 	struct delayed_work	work;
 	u8			wait:1;
 	u8			key:1;
+	u8			pwled:1;
+	u8			pwledcnt;
+	u16			key_addr;
 	struct urb		*int_urb;
 	u8			*urb_data;
 
@@ -89,26 +96,49 @@ static int tm6000_ir_config(struct tm6000_IR *ir)
 	u8 buf[10];
 	int rc;
 
-	/* hack */
-	buf[0] = 0xff;
-	buf[1] = 0xff;
-	buf[2] = 0xf2;
-	buf[3] = 0x2b;
-	buf[4] = 0x20;
-	buf[5] = 0x35;
-	buf[6] = 0x60;
-	buf[7] = 0x04;
-	buf[8] = 0xc0;
-	buf[9] = 0x08;
-
-	rc = tm6000_read_write_usb(dev, USB_DIR_OUT | USB_TYPE_VENDOR |
-		USB_RECIP_DEVICE, REQ_00_SET_IR_VALUE, 0, 0, buf, 0x0a);
-	msleep(100);
-
-	if (rc < 0) {
-		printk(KERN_INFO "IR configuration failed");
-		return rc;
+	switch (ir->rc_type) {
+	case RC_TYPE_NEC:
+		/* Setup IR decoder for NEC standard 12MHz system clock */
+		/* IR_LEADER_CNT = 0.9ms             */
+		tm6000_set_reg(dev, TM6010_REQ07_RD8_IR_LEADER1, 0xaa);
+		tm6000_set_reg(dev, TM6010_REQ07_RD8_IR_LEADER0, 0x30);
+		/* IR_PULSE_CNT = 0.7ms              */
+		tm6000_set_reg(dev, TM6010_REQ07_RD8_IR_PULSE_CNT1, 0x20);
+		tm6000_set_reg(dev, TM6010_REQ07_RD8_IR_PULSE_CNT0, 0xd0);
+		/* Remote WAKEUP = enable */
+		tm6000_set_reg(dev, TM6010_REQ07_RE5_REMOTE_WAKEUP, 0xfe);
+		/* IR_WKUP_SEL = Low byte in decoded IR data */
+		tm6000_set_reg(dev, TM6010_REQ07_RD8_IR_WAKEUP_SEL, 0xff);
+		/* IR_WKU_ADD code */
+		tm6000_set_reg(dev, TM6010_REQ07_RD8_IR_WAKEUP_ADD, 0xff);
+		tm6000_flash_led(dev, 0);
+		msleep(100);
+		tm6000_flash_led(dev, 1);
+		break;
+	default:
+		/* hack */
+		buf[0] = 0xff;
+		buf[1] = 0xff;
+		buf[2] = 0xf2;
+		buf[3] = 0x2b;
+		buf[4] = 0x20;
+		buf[5] = 0x35;
+		buf[6] = 0x60;
+		buf[7] = 0x04;
+		buf[8] = 0xc0;
+		buf[9] = 0x08;
+
+		rc = tm6000_read_write_usb(dev, USB_DIR_OUT | USB_TYPE_VENDOR |
+			USB_RECIP_DEVICE, REQ_00_SET_IR_VALUE, 0, 0, buf, 0x0a);
+		msleep(100);
+
+		if (rc < 0) {
+			printk(KERN_INFO "IR configuration failed");
+			return rc;
+		}
+		break;
 	}
+
 	return 0;
 }
 
@@ -143,10 +173,21 @@ static int default_polling_getkey(struct tm6000_IR *ir,
 		return 0;
 
 	if (&dev->int_in) {
-		if (ir->rc_type == RC_TYPE_RC5)
+		switch (ir->rc_type) {
+		case RC_TYPE_RC5:
 			poll_result->rc_data = ir->urb_data[0];
-		else
-			poll_result->rc_data = ir->urb_data[0] | ir->urb_data[1] << 8;
+			break;
+		case RC_TYPE_NEC:
+			if (ir->urb_data[1] == ((ir->key_addr >> 8) & 0xff)) {
+				poll_result->rc_data = ir->urb_data[0]
+							| ir->key_addr << 8;
+			}
+			break;
+		default:
+			poll_result->rc_data = ir->urb_data[0]
+					| ir->urb_data[1] << 8;
+			break;
+		}
 	} else {
 		tm6000_set_reg(dev, REQ_04_EN_DISABLE_MCU_INT, 2, 0);
 		msleep(10);
@@ -186,6 +227,7 @@ static int default_polling_getkey(struct tm6000_IR *ir,
 
 static void tm6000_ir_handle_key(struct tm6000_IR *ir)
 {
+	struct tm6000_core *dev = ir->dev;
 	int result;
 	struct tm6000_ir_poll_result poll_result;
 
@@ -198,9 +240,22 @@ static void tm6000_ir_handle_key(struct tm6000_IR *ir)
 
 	dprintk("ir->get_key result data=%04x\n", poll_result.rc_data);
 
+	if (ir->pwled) {
+		if (ir->pwledcnt >= PWLED_OFF) {
+			ir->pwled = 0;
+			ir->pwledcnt = 0;
+			tm6000_flash_led(dev, 1);
+		}
+		else
+			ir->pwledcnt += 1;
+	}
+
 	if (ir->key) {
 		rc_keydown(ir->rc, poll_result.rc_data, 0);
 		ir->key = 0;
+		ir->pwled = 1;
+		ir->pwledcnt = 0;
+		tm6000_flash_led(dev, 0);
 	}
 	return;
 }
@@ -234,19 +289,80 @@ int tm6000_ir_change_protocol(struct rc_dev *rc, u64 rc_type)
 {
 	struct tm6000_IR *ir = rc->priv;
 
+	if (!ir)
+		return 0;
+
+	if ((rc->rc_map.scan) && (rc_type == RC_TYPE_NEC))
+		ir->key_addr = ((rc->rc_map.scan[0].scancode >> 8) & 0xffff);
+
 	ir->get_key = default_polling_getkey;
+	ir->rc_type = rc_type;
 
 	tm6000_ir_config(ir);
 	/* TODO */
 	return 0;
 }
 
+int tm6000_ir_int_start(struct tm6000_core *dev)
+{
+	struct tm6000_IR *ir = dev->ir;
+	int pipe, size;
+	int err = -ENOMEM;
+
+
+	if (!ir)
+		return -ENODEV;
+
+	ir->int_urb = usb_alloc_urb(0, GFP_KERNEL);
+
+	pipe = usb_rcvintpipe(dev->udev,
+		dev->int_in.endp->desc.bEndpointAddress
+		& USB_ENDPOINT_NUMBER_MASK);
+
+	size = usb_maxpacket(dev->udev, pipe, usb_pipeout(pipe));
+	dprintk("IR max size: %d\n", size);
+
+	ir->int_urb->transfer_buffer = kzalloc(size, GFP_KERNEL);
+	if (ir->int_urb->transfer_buffer == NULL) {
+		usb_free_urb(ir->int_urb);
+		return err;
+	}
+	dprintk("int interval: %d\n", dev->int_in.endp->desc.bInterval);
+	usb_fill_int_urb(ir->int_urb, dev->udev, pipe,
+		ir->int_urb->transfer_buffer, size,
+		tm6000_ir_urb_received, dev,
+		dev->int_in.endp->desc.bInterval);
+	err = usb_submit_urb(ir->int_urb, GFP_KERNEL);
+	if (err) {
+		kfree(ir->int_urb->transfer_buffer);
+		usb_free_urb(ir->int_urb);
+		return err;
+	}
+	ir->urb_data = kzalloc(size, GFP_KERNEL);
+
+	return 0;
+}
+
+void tm6000_ir_int_stop(struct tm6000_core *dev)
+{
+	struct tm6000_IR *ir = dev->ir;
+
+	if (!ir)
+		return;
+
+	usb_kill_urb(ir->int_urb);
+	kfree(ir->int_urb->transfer_buffer);
+	usb_free_urb(ir->int_urb);
+	ir->int_urb = NULL;
+	kfree(ir->urb_data);
+	ir->urb_data = NULL;
+}
+
 int tm6000_ir_init(struct tm6000_core *dev)
 {
 	struct tm6000_IR *ir;
 	struct rc_dev *rc;
 	int err = -ENOMEM;
-	int pipe, size;
 
 	if (!enable_ir)
 		return -ENODEV;
@@ -276,6 +392,9 @@ int tm6000_ir_init(struct tm6000_core *dev)
 	rc->driver_type = RC_DRIVER_SCANCODE;
 
 	ir->polling = 50;
+	ir->pwled = 0;
+	ir->pwledcnt = 0;
+
 
 	snprintf(ir->name, sizeof(ir->name), "tm5600/60x0 IR (%s)",
 						dev->name);
@@ -298,32 +417,10 @@ int tm6000_ir_init(struct tm6000_core *dev)
 	if (&dev->int_in) {
 		dprintk("IR over int\n");
 
-		ir->int_urb = usb_alloc_urb(0, GFP_KERNEL);
-
-		pipe = usb_rcvintpipe(dev->udev,
-			dev->int_in.endp->desc.bEndpointAddress
-			& USB_ENDPOINT_NUMBER_MASK);
+		err = tm6000_ir_int_start(dev);
 
-		size = usb_maxpacket(dev->udev, pipe, usb_pipeout(pipe));
-		dprintk("IR max size: %d\n", size);
-
-		ir->int_urb->transfer_buffer = kzalloc(size, GFP_KERNEL);
-		if (ir->int_urb->transfer_buffer == NULL) {
-			usb_free_urb(ir->int_urb);
-			goto out;
-		}
-		dprintk("int interval: %d\n", dev->int_in.endp->desc.bInterval);
-		usb_fill_int_urb(ir->int_urb, dev->udev, pipe,
-			ir->int_urb->transfer_buffer, size,
-			tm6000_ir_urb_received, dev,
-			dev->int_in.endp->desc.bInterval);
-		err = usb_submit_urb(ir->int_urb, GFP_KERNEL);
-		if (err) {
-			kfree(ir->int_urb->transfer_buffer);
-			usb_free_urb(ir->int_urb);
+		if (err)
 			goto out;
-		}
-		ir->urb_data = kzalloc(size, GFP_KERNEL);
 	}
 
 	/* ir register */
@@ -352,12 +449,7 @@ int tm6000_ir_fini(struct tm6000_core *dev)
 	rc_unregister_device(ir->rc);
 
 	if (ir->int_urb) {
-		usb_kill_urb(ir->int_urb);
-		kfree(ir->int_urb->transfer_buffer);
-		usb_free_urb(ir->int_urb);
-		ir->int_urb = NULL;
-		kfree(ir->urb_data);
-		ir->urb_data = NULL;
+		tm6000_ir_int_stop(dev);
 	}
 
 	kfree(ir);
diff --git a/drivers/staging/tm6000/tm6000-video.c b/drivers/staging/tm6000/tm6000-video.c
index c5690b2..b06701b 100644
--- a/drivers/staging/tm6000/tm6000-video.c
+++ b/drivers/staging/tm6000/tm6000-video.c
@@ -545,11 +545,16 @@ static int tm6000_prepare_isoc(struct tm6000_core *dev, unsigned int framesize)
 
 	/* De-allocates all pending stuff */
 	tm6000_uninit_isoc(dev);
+	/* Stop interrupt USB pipe */
+	tm6000_ir_int_stop(dev);
 
 	usb_set_interface(dev->udev,
 			  dev->isoc_in.bInterfaceNumber,
 			  dev->isoc_in.bAlternateSetting);
 
+	/* Start interrupt USB pipe */
+	tm6000_ir_int_start(dev);
+
 	pipe = usb_rcvisocpipe(dev->udev,
 			       dev->isoc_in.endp->desc.bEndpointAddress &
 			       USB_ENDPOINT_NUMBER_MASK);
diff --git a/drivers/staging/tm6000/tm6000.h b/drivers/staging/tm6000/tm6000.h
index 46017b6..bf11eee 100644
--- a/drivers/staging/tm6000/tm6000.h
+++ b/drivers/staging/tm6000/tm6000.h
@@ -266,6 +266,7 @@ struct tm6000_fh {
 int tm6000_tuner_callback(void *ptr, int component, int command, int arg);
 int tm6000_xc5000_callback(void *ptr, int component, int command, int arg);
 int tm6000_cards_setup(struct tm6000_core *dev);
+void tm6000_flash_led(struct tm6000_core *dev, u8 state);
 
 /* In tm6000-core.c */
 
@@ -332,6 +333,8 @@ int tm6000_queue_init(struct tm6000_core *dev);
 int tm6000_ir_init(struct tm6000_core *dev);
 int tm6000_ir_fini(struct tm6000_core *dev);
 void tm6000_ir_wait(struct tm6000_core *dev, u8 state);
+int tm6000_ir_int_start(struct tm6000_core *dev);
+void tm6000_ir_int_stop(struct tm6000_core *dev);
 
 /* Debug stuff */
 
diff --git a/include/media/rc-map.h b/include/media/rc-map.h
index 1a3d51d..239a309 100644
--- a/include/media/rc-map.h
+++ b/include/media/rc-map.h
@@ -70,6 +70,7 @@ void rc_map_init(void);
 #define RC_MAP_AVERTV_303                "rc-avertv-303"
 #define RC_MAP_AZUREWAVE_AD_TU700        "rc-azurewave-ad-tu700"
 #define RC_MAP_BEHOLD_COLUMBUS           "rc-behold-columbus"
+#define RC_MAP_BEHOLD_WANDER             "rc-behold-wander"
 #define RC_MAP_BEHOLD                    "rc-behold"
 #define RC_MAP_BUDGET_CI_OLD             "rc-budget-ci-old"
 #define RC_MAP_CINERGY_1400              "rc-cinergy-1400"

Re: tm6000 and IR

[Stefan Ringel]

Am 16.12.2010 10:38, schrieb Dmitri Belimov:
> Hi
>
>>> I think your mean is wrong. Our IR remotes send extended NEC it is
>>> 4 bytes. We removed inverted 4 byte and now we have 3 bytes from
>>> remotes. I think we must have full RCMAP with this 3 bytes from
>>> remotes. And use this remotes with some different IR recievers like
>>> some TV cards and LIRC-hardware and other. No need different RCMAP
>>> for the same remotes to different IR recievers like now.
>> Your change doesn't work with my terratec remote control !!
> I found what happens. Try my new patch.
>
> What about NEC. Original NEC send
> address (inverted address) key (inverted key)
> this is realy old standart now all remotes use extended NEC
> (adress high) (address low) key (inverted key)
> The trident 5600/6000/6010 use old protocol but didn't test inverted address byte.
>
> I think much better discover really address value and write it to keytable.
> For your remotes I add low address byte. This value is incorrent but usefull for tm6000.
> When you found correct value update keytable.
>
That is not acceptable. Have you forgotten what Mauro have written? The 
Terratec rc map are use from other devices. The best are only the 
received data without additional data. And I think the Trident chip send 
only compatibly data (send all extended data like standard data). The 
device decoded the protocols not the driver.
>>>> Then the function call usb_set_interface in tm6000_video, can write
>>>> for example:
>>>>
>>>> stop_ir_pipe
>>>> usb_set_interface
>>>> start_ir_pipe
>>> Ok, I'll try.
> See dmesg. I was add function for start/stop interrupt urbs
> All works well.
>
> With my best regards, Dmitry.

Re: tm6000 and IR

[Dmitri Belimov]

Hi Stefan

> Am 16.12.2010 10:38, schrieb Dmitri Belimov:
> > Hi
> >
> >>> I think your mean is wrong. Our IR remotes send extended NEC it is
> >>> 4 bytes. We removed inverted 4 byte and now we have 3 bytes from
> >>> remotes. I think we must have full RCMAP with this 3 bytes from
> >>> remotes. And use this remotes with some different IR recievers
> >>> like some TV cards and LIRC-hardware and other. No need different
> >>> RCMAP for the same remotes to different IR recievers like now.
> >> Your change doesn't work with my terratec remote control !!
> > I found what happens. Try my new patch.
> >
> > What about NEC. Original NEC send
> > address (inverted address) key (inverted key)
> > this is realy old standart now all remotes use extended NEC
> > (adress high) (address low) key (inverted key)
> > The trident 5600/6000/6010 use old protocol but didn't test
> > inverted address byte.
> >
> > I think much better discover really address value and write it to
> > keytable. For your remotes I add low address byte. This value is
> > incorrent but usefull for tm6000. When you found correct value
> > update keytable.
> >
> That is not acceptable. Have you forgotten what Mauro have written?
> The Terratec rc map are use from other devices.

NO
The RC_MAP_NEC_TERRATEC_CINERGY_XS used only in tm6000 module.
My patch didn't kill support any other devices.

> The best are only the 
> received data without additional data. And I think the Trident chip
> send only compatibly data (send all extended data like standard
> data). The device decoded the protocols not the driver.

You can't use this remotes with normal working IR receivers because this receivers
returned FULL scancodes. Need add one more keytable.

1. With my variant we have one keytable of remote and some workaround in device drivers. 
    And can switch keytable and remotes on the fly (of course when keytable has really value and device driver has workaround)
    
2. With your variant we have some keytables for one remote for different IR recevers. 
    Can't use incompatible keytable with other IR recievers. It is black magic for understanding what remotes is working with this hardware.

I think my variant much better.

With my best regards, Dmitry.

> >>>> Then the function call usb_set_interface in tm6000_video, can
> >>>> write for example:
> >>>>
> >>>> stop_ir_pipe
> >>>> usb_set_interface
> >>>> start_ir_pipe
> >>> Ok, I'll try.
> > See dmesg. I was add function for start/stop interrupt urbs
> > All works well.
> >
> > With my best regards, Dmitry.
> 

Re: tm6000 and IR

[Stefan Ringel]

Am 17.12.2010 02:46, schrieb Dmitri Belimov:
> Hi Stefan
>
>> Am 16.12.2010 10:38, schrieb Dmitri Belimov:
>>> Hi
>>>
>>>>> I think your mean is wrong. Our IR remotes send extended NEC it is
>>>>> 4 bytes. We removed inverted 4 byte and now we have 3 bytes from
>>>>> remotes. I think we must have full RCMAP with this 3 bytes from
>>>>> remotes. And use this remotes with some different IR recievers
>>>>> like some TV cards and LIRC-hardware and other. No need different
>>>>> RCMAP for the same remotes to different IR recievers like now.
>>>> Your change doesn't work with my terratec remote control !!
>>> I found what happens. Try my new patch.
>>>
>>> What about NEC. Original NEC send
>>> address (inverted address) key (inverted key)
>>> this is realy old standart now all remotes use extended NEC
>>> (adress high) (address low) key (inverted key)
>>> The trident 5600/6000/6010 use old protocol but didn't test
>>> inverted address byte.
>>>
>>> I think much better discover really address value and write it to
>>> keytable. For your remotes I add low address byte. This value is
>>> incorrent but usefull for tm6000. When you found correct value
>>> update keytable.
>>>
>> That is not acceptable. Have you forgotten what Mauro have written?
>> The Terratec rc map are use from other devices.
> NO
> The RC_MAP_NEC_TERRATEC_CINERGY_XS used only in tm6000 module.
> My patch didn't kill support any other devices.
That is not true.
>> The best are only the
>> received data without additional data. And I think the Trident chip
>> send only compatibly data (send all extended data like standard
>> data). The device decoded the protocols not the driver.
> You can't use this remotes with normal working IR receivers because this receivers
> returned FULL scancodes. Need add one more keytable.
>
> 1. With my variant we have one keytable of remote and some workaround in device drivers.
>      And can switch keytable and remotes on the fly (of course when keytable has really value and device driver has workaround)
>
> 2. With your variant we have some keytables for one remote for different IR recevers.
>      Can't use incompatible keytable with other IR recievers. It is black magic for understanding what remotes is working with this hardware.
>
> I think my variant much better.
>
> With my best regards, Dmitry.
>
I think your variant is bad.
>>>>>> Then the function call usb_set_interface in tm6000_video, can
>>>>>> write for example:
>>>>>>
>>>>>> stop_ir_pipe
>>>>>> usb_set_interface
>>>>>> start_ir_pipe
>>>>> Ok, I'll try.
>>> See dmesg. I was add function for start/stop interrupt urbs
>>> All works well.
>>>
>>> With my best regards, Dmitry.

Re: tm6000 and IR

[Dmitri Belimov]

On Fri, 17 Dec 2010 06:18:31 +0100
Stefan Ringel <stefan.ringel@arcor.de> wrote:

> Am 17.12.2010 02:46, schrieb Dmitri Belimov:
> > Hi Stefan
> >
> >> Am 16.12.2010 10:38, schrieb Dmitri Belimov:
> >>> Hi
> >>>
> >>>>> I think your mean is wrong. Our IR remotes send extended NEC it
> >>>>> is 4 bytes. We removed inverted 4 byte and now we have 3 bytes
> >>>>> from remotes. I think we must have full RCMAP with this 3 bytes
> >>>>> from remotes. And use this remotes with some different IR
> >>>>> recievers like some TV cards and LIRC-hardware and other. No
> >>>>> need different RCMAP for the same remotes to different IR
> >>>>> recievers like now.
> >>>> Your change doesn't work with my terratec remote control !!
> >>> I found what happens. Try my new patch.
> >>>
> >>> What about NEC. Original NEC send
> >>> address (inverted address) key (inverted key)
> >>> this is realy old standart now all remotes use extended NEC
> >>> (adress high) (address low) key (inverted key)
> >>> The trident 5600/6000/6010 use old protocol but didn't test
> >>> inverted address byte.
> >>>
> >>> I think much better discover really address value and write it to
> >>> keytable. For your remotes I add low address byte. This value is
> >>> incorrent but usefull for tm6000. When you found correct value
> >>> update keytable.
> >>>
> >> That is not acceptable. Have you forgotten what Mauro have written?
> >> The Terratec rc map are use from other devices.
> > NO
> > The RC_MAP_NEC_TERRATEC_CINERGY_XS used only in tm6000 module.
> > My patch didn't kill support any other devices.
> That is not true.

I search "RC_MAP_NEC_TERRATEC_CINERGY_XS" on FULL linux kernel sources.
And found this string in:
include/media/rc-map.h
drivers/staging//tm6000/tm6000-cards.c
drivers/media/rc/keymaps/rc-nec-terratec-cinergy-xs.c

No any other devices didn't use this keymap.

> >> The best are only the
> >> received data without additional data. And I think the Trident chip
> >> send only compatibly data (send all extended data like standard
> >> data). The device decoded the protocols not the driver.
> > You can't use this remotes with normal working IR receivers because
> > this receivers returned FULL scancodes. Need add one more keytable.
> >
> > 1. With my variant we have one keytable of remote and some
> > workaround in device drivers. And can switch keytable and remotes
> > on the fly (of course when keytable has really value and device
> > driver has workaround)
> >
> > 2. With your variant we have some keytables for one remote for
> > different IR recevers. Can't use incompatible keytable with other
> > IR recievers. It is black magic for understanding what remotes is
> > working with this hardware.
> >
> > I think my variant much better.
> >
> > With my best regards, Dmitry.
> >
> I think your variant is bad.

Mauro we need your opinion about this question.

With my best regards, Dmitry.

> >>>>>> Then the function call usb_set_interface in tm6000_video, can
> >>>>>> write for example:
> >>>>>>
> >>>>>> stop_ir_pipe
> >>>>>> usb_set_interface
> >>>>>> start_ir_pipe
> >>>>> Ok, I'll try.
> >>> See dmesg. I was add function for start/stop interrupt urbs
> >>> All works well.
> >>>
> >>> With my best regards, Dmitry.
> 

Re: tm6000 and IR

[Mauro Carvalho Chehab]

Hi Dmitri/Stefan,

Em 17-12-2010 05:08, Dmitri Belimov escreveu:
> On Fri, 17 Dec 2010 06:18:31 +0100
> Stefan Ringel <stefan.ringel@arcor.de> wrote:
> 
>> Am 17.12.2010 02:46, schrieb Dmitri Belimov:
>>> Hi Stefan
>>>
>>>> Am 16.12.2010 10:38, schrieb Dmitri Belimov:
>>>>> Hi
>>>>>
>>>>>>> I think your mean is wrong. Our IR remotes send extended NEC it
>>>>>>> is 4 bytes. We removed inverted 4 byte and now we have 3 bytes
>>>>>>> from remotes. I think we must have full RCMAP with this 3 bytes
>>>>>>> from remotes. And use this remotes with some different IR
>>>>>>> recievers like some TV cards and LIRC-hardware and other. No
>>>>>>> need different RCMAP for the same remotes to different IR
>>>>>>> recievers like now.
>>>>>> Your change doesn't work with my terratec remote control !!
>>>>> I found what happens. Try my new patch.
>>>>>
>>>>> What about NEC. Original NEC send
>>>>> address (inverted address) key (inverted key)
>>>>> this is realy old standart now all remotes use extended NEC
>>>>> (adress high) (address low) key (inverted key)
>>>>> The trident 5600/6000/6010 use old protocol but didn't test
>>>>> inverted address byte.
>>>>>
>>>>> I think much better discover really address value and write it to
>>>>> keytable. For your remotes I add low address byte. This value is
>>>>> incorrent but usefull for tm6000. When you found correct value
>>>>> update keytable.
>>>>>
>>>> That is not acceptable. Have you forgotten what Mauro have written?
>>>> The Terratec rc map are use from other devices.
>>> NO
>>> The RC_MAP_NEC_TERRATEC_CINERGY_XS used only in tm6000 module.
>>> My patch didn't kill support any other devices.
>> That is not true.
> 
> I search "RC_MAP_NEC_TERRATEC_CINERGY_XS" on FULL linux kernel sources.
> And found this string in:
> include/media/rc-map.h
> drivers/staging//tm6000/tm6000-cards.c
> drivers/media/rc/keymaps/rc-nec-terratec-cinergy-xs.c
> 
> No any other devices didn't use this keymap.
> 
>>>> The best are only the
>>>> received data without additional data. And I think the Trident chip
>>>> send only compatibly data (send all extended data like standard
>>>> data). The device decoded the protocols not the driver.
>>> You can't use this remotes with normal working IR receivers because
>>> this receivers returned FULL scancodes. Need add one more keytable.
>>>
>>> 1. With my variant we have one keytable of remote and some
>>> workaround in device drivers. And can switch keytable and remotes
>>> on the fly (of course when keytable has really value and device
>>> driver has workaround)
>>>
>>> 2. With your variant we have some keytables for one remote for
>>> different IR recevers. Can't use incompatible keytable with other
>>> IR recievers. It is black magic for understanding what remotes is
>>> working with this hardware.
>>>
>>> I think my variant much better.
>>>
>>> With my best regards, Dmitry.
>>>
>> I think your variant is bad.
> 
> Mauro we need your opinion about this question.

I'm c/c Jarod, as he has a similar issue with some NEC-based boards 
(Apple "variant").

I also have experienced some cases where the NEC protocol in-hardware
decoder can provide only part of the NEC "extended" range.

I don't have a clear opinion about this issue, but I think that putting
all our brains to think about that, we may have a solution for it.

Let me summarize the issues. Please complete/correct me if is there anything
else.

1) NEC original format is 16 bits. However, some variants use 24 bits for it
(it is called, currently, NEC extended). A few other manufacturers, like Apple,
defines NEC protocol with 32 bits, removing both address and command checksums.

2) NEC raw decoder is capable of decoding the entire NEC code, but it only
accepts 16 or 24 bits, returning the scan code as:

	scancode = address << 8 | command;

for 16 bits, and:

	scancode = address << 16 | not_address <<  8 | command;

for 24 bits. There were some proposals to extend it to something like:

	scancode = address << 24 | not_address << 16 | not_command << 8 | command;
	(or some other bit order)

Or just return the complete 32 bits even for the original NEC protocol. However,
changing it will break the existing userspace decoding tables.

Another way would be to store the length of the scancode, using it as well during
the scancode->keycode translation.

But no patches were merged yet.

3) Some hardware decoders can't return the complete NEC address. There are variants
that returns 8 bits, others that returns 16 bits, and others that return the complete
code.

For hardware that returns only 8 bits, we currently address the issue by using a 
scancode mask. When "scanmask" is set at the rc structs, the scancode->keycode
logic will consider only the bits that are in the mask.

4) Some hardware filters the NEC address, returning only the codes for
some specific vendors.

Despite all discussions, we didn't reach an agreement yet.

There are some points to consider whatever solution we do:

1) A keycode table should be able to work with a generic raw decoder. So, on all
drivers, the bit order and the number of bits for a given protocol should be the same;

2) we should avoid to cause regressions on the existing definitions.

That's said, suggestions to meet the needs are welcome.

Thanks,
Mauro

Re: tm6000 and IR

[Andy Walls]

On Fri, 2010-12-17 at 22:24 -0200, Mauro Carvalho Chehab wrote:


> Despite all discussions, we didn't reach an agreement yet.
> 
> There are some points to consider whatever solution we do:
> 
> 1) A keycode table should be able to work with a generic raw decoder. So, on all
> drivers, the bit order and the number of bits for a given protocol should be the same;
> 
> 2) we should avoid to cause regressions on the existing definitions.
> 
> That's said, suggestions to meet the needs are welcome.

Just to throw out some ideas:

It appears to me that what you are looking at are communications
protocols with

a. a common Physical layer (PHY): a pulse distance protocol with a
common carrier freq, bit symbol encoding, leader pulse, trailer pulse,
and repeat sequence.  The number of bits (and the leader pulse length?)
is allowed to vary.  

b. differing Data Link layers (LL): the data link address can be
different lengths and in different places; so can the data payload, so
can the checks on address and data payload.

For the end user, I would present each PHY/LL combination a different
protocol.  How the kernel implements it internally doesn't matter much.
It could be one raw decoder handling all the PHY/LL combinations that it
can, or one PHY decoder and several LL decoders.

The keytables should probably be working on cooked LL output from the
raw decoder.  I think that will handle a lot of the issues you mention.
The output from a LL could include

	destination address (from the transmitted code),
	source address (useful if different remotes can be detected),
	payload length,
	payload, and
	maybe button up/down.

The LL could swallow the automatic repeats, since they are just part of
the button up/down scheme.

Aside from backward compatibility with existing keytables, I don't see
much point in a decoder trying to flip bits from the PHY layer around to
present a pseudo-PHY layer output.  Don't keytables get updated with the
kernel release anyway, or did they all move to userspace utils?


Anyway, just some thoughts.

Regards,
Andy


> Thanks,
> Mauro

Re: tm6000 and IR

[Stefan Ringel]

Am 18.12.2010 14:56, schrieb Andy Walls:
> On Fri, 2010-12-17 at 22:24 -0200, Mauro Carvalho Chehab wrote:
>
>
>> Despite all discussions, we didn't reach an agreement yet.
>>
>> There are some points to consider whatever solution we do:
>>
>> 1) A keycode table should be able to work with a generic raw decoder. So, on all
>> drivers, the bit order and the number of bits for a given protocol should be the same;
>>
>> 2) we should avoid to cause regressions on the existing definitions.
>>
>> That's said, suggestions to meet the needs are welcome.
> Just to throw out some ideas:
>
> It appears to me that what you are looking at are communications
> protocols with
>
> a. a common Physical layer (PHY): a pulse distance protocol with a
> common carrier freq, bit symbol encoding, leader pulse, trailer pulse,
> and repeat sequence.  The number of bits (and the leader pulse length?)
> is allowed to vary.
>
> b. differing Data Link layers (LL): the data link address can be
> different lengths and in different places; so can the data payload, so
> can the checks on address and data payload.
>
> For the end user, I would present each PHY/LL combination a different
> protocol.  How the kernel implements it internally doesn't matter much.
> It could be one raw decoder handling all the PHY/LL combinations that it
> can, or one PHY decoder and several LL decoders.
>
> The keytables should probably be working on cooked LL output from the
> raw decoder.  I think that will handle a lot of the issues you mention.
> The output from a LL could include
>
> 	destination address (from the transmitted code),
> 	source address (useful if different remotes can be detected),
> 	payload length,
> 	payload, and
> 	maybe button up/down.
>
> The LL could swallow the automatic repeats, since they are just part of
> the button up/down scheme.
>
> Aside from backward compatibility with existing keytables, I don't see
> much point in a decoder trying to flip bits from the PHY layer around to
> present a pseudo-PHY layer output.  Don't keytables get updated with the
> kernel release anyway, or did they all move to userspace utils?
>
>
> Anyway, just some thoughts.
>
> Regards,
> Andy
>
>
>> Thanks,
>> Mauro
>
TM5600, TM6000 and TM6010 IR
==========================

It give two ways to receive data

1. over the control pipe (ep0)
- polling must stop if it loads firmware
- data length are a byte (command)

2. over interrupt pipe (only TM6010)
- data length are two bytes (address << 8 | command)

It has any control registers to configure IR (protocol ...)

TM6010_REQ07_RD8_IR
??, we use 0x2f

TM6010_REQ07_RD8_IR_BSIZE
??

TM6010_REQ07_RD8_IR_WAKEUP_SEL
command mask, I think,   we use here 0xff

TM6010_REQ07_RD8_IR_WAKEUP_ADD
address mask, we use 0xff

TM6010_REQ07_RD8_IR_LEADER1
TM6010_REQ07_RD8_IR_LEADER0
is a 16bit register
for NEC 0xaa30

TM6010_REQ07_RD8_IR_PULSE_CNT1
TM6010_REQ07_RD8_IR_PULSE_CNT0
is a 16bit register
for NEC 0x20d0


Stefan Ringel

Re: tm6000 and IR

[Dmitri Belimov]

Hi

If Apple use full 32-bit scancode we need full raw 32-bit keytable for compatibility.

For this need rework all keytables and all keyread function for add scanmask configuration and
rework single byte scancode code -> key << 8.

Use scanmask and return IR reading bytes on real place.

For tm6000 don't need restore full scancode 
Only address filter

scanmask = 0xff00ff00;
return byte[1] << 24 | byte[0] <<8

With my best regards, Dmitry.

> Hi Dmitri/Stefan,
> 
> Em 17-12-2010 05:08, Dmitri Belimov escreveu:
> > On Fri, 17 Dec 2010 06:18:31 +0100
> > Stefan Ringel <stefan.ringel@arcor.de> wrote:
> > 
> >> Am 17.12.2010 02:46, schrieb Dmitri Belimov:
> >>> Hi Stefan
> >>>
> >>>> Am 16.12.2010 10:38, schrieb Dmitri Belimov:
> >>>>> Hi
> >>>>>
> >>>>>>> I think your mean is wrong. Our IR remotes send extended NEC
> >>>>>>> it is 4 bytes. We removed inverted 4 byte and now we have 3
> >>>>>>> bytes from remotes. I think we must have full RCMAP with this
> >>>>>>> 3 bytes from remotes. And use this remotes with some
> >>>>>>> different IR recievers like some TV cards and LIRC-hardware
> >>>>>>> and other. No need different RCMAP for the same remotes to
> >>>>>>> different IR recievers like now.
> >>>>>> Your change doesn't work with my terratec remote control !!
> >>>>> I found what happens. Try my new patch.
> >>>>>
> >>>>> What about NEC. Original NEC send
> >>>>> address (inverted address) key (inverted key)
> >>>>> this is realy old standart now all remotes use extended NEC
> >>>>> (adress high) (address low) key (inverted key)
> >>>>> The trident 5600/6000/6010 use old protocol but didn't test
> >>>>> inverted address byte.
> >>>>>
> >>>>> I think much better discover really address value and write it
> >>>>> to keytable. For your remotes I add low address byte. This
> >>>>> value is incorrent but usefull for tm6000. When you found
> >>>>> correct value update keytable.
> >>>>>
> >>>> That is not acceptable. Have you forgotten what Mauro have
> >>>> written? The Terratec rc map are use from other devices.
> >>> NO
> >>> The RC_MAP_NEC_TERRATEC_CINERGY_XS used only in tm6000 module.
> >>> My patch didn't kill support any other devices.
> >> That is not true.
> > 
> > I search "RC_MAP_NEC_TERRATEC_CINERGY_XS" on FULL linux kernel
> > sources. And found this string in:
> > include/media/rc-map.h
> > drivers/staging//tm6000/tm6000-cards.c
> > drivers/media/rc/keymaps/rc-nec-terratec-cinergy-xs.c
> > 
> > No any other devices didn't use this keymap.
> > 
> >>>> The best are only the
> >>>> received data without additional data. And I think the Trident
> >>>> chip send only compatibly data (send all extended data like
> >>>> standard data). The device decoded the protocols not the driver.
> >>> You can't use this remotes with normal working IR receivers
> >>> because this receivers returned FULL scancodes. Need add one more
> >>> keytable.
> >>>
> >>> 1. With my variant we have one keytable of remote and some
> >>> workaround in device drivers. And can switch keytable and remotes
> >>> on the fly (of course when keytable has really value and device
> >>> driver has workaround)
> >>>
> >>> 2. With your variant we have some keytables for one remote for
> >>> different IR recevers. Can't use incompatible keytable with other
> >>> IR recievers. It is black magic for understanding what remotes is
> >>> working with this hardware.
> >>>
> >>> I think my variant much better.
> >>>
> >>> With my best regards, Dmitry.
> >>>
> >> I think your variant is bad.
> > 
> > Mauro we need your opinion about this question.
> 
> I'm c/c Jarod, as he has a similar issue with some NEC-based boards 
> (Apple "variant").
> 
> I also have experienced some cases where the NEC protocol in-hardware
> decoder can provide only part of the NEC "extended" range.
> 
> I don't have a clear opinion about this issue, but I think that
> putting all our brains to think about that, we may have a solution
> for it.
> 
> Let me summarize the issues. Please complete/correct me if is there
> anything else.
> 
> 1) NEC original format is 16 bits. However, some variants use 24 bits
> for it (it is called, currently, NEC extended). A few other
> manufacturers, like Apple, defines NEC protocol with 32 bits,
> removing both address and command checksums.
> 
> 2) NEC raw decoder is capable of decoding the entire NEC code, but it
> only accepts 16 or 24 bits, returning the scan code as:
> 
> 	scancode = address << 8 | command;
> 
> for 16 bits, and:
> 
> 	scancode = address << 16 | not_address <<  8 | command;
> 
> for 24 bits. There were some proposals to extend it to something like:
> 
> 	scancode = address << 24 | not_address << 16 | not_command <<
> 8 | command; (or some other bit order)
> 
> Or just return the complete 32 bits even for the original NEC
> protocol. However, changing it will break the existing userspace
> decoding tables.
> 
> Another way would be to store the length of the scancode, using it as
> well during the scancode->keycode translation.
> 
> But no patches were merged yet.
> 
> 3) Some hardware decoders can't return the complete NEC address.
> There are variants that returns 8 bits, others that returns 16 bits,
> and others that return the complete code.
> 
> For hardware that returns only 8 bits, we currently address the issue
> by using a scancode mask. When "scanmask" is set at the rc structs,
> the scancode->keycode logic will consider only the bits that are in
> the mask.
> 
> 4) Some hardware filters the NEC address, returning only the codes for
> some specific vendors.
> 
> Despite all discussions, we didn't reach an agreement yet.
> 
> There are some points to consider whatever solution we do:
> 
> 1) A keycode table should be able to work with a generic raw decoder.
> So, on all drivers, the bit order and the number of bits for a given
> protocol should be the same;
> 
> 2) we should avoid to cause regressions on the existing definitions.
> 
> That's said, suggestions to meet the needs are welcome.
> 
> Thanks,
> Mauro

Re: tm6000 and IR

[Jarod Wilson]

On Mon, Dec 20, 2010 at 02:41:03PM +0900, Dmitri Belimov wrote:
> Hi
> 
> If Apple use full 32-bit scancode we need full raw 32-bit keytable for compatibility.

The Apple format is two bytes for what I guess is vendor ID, one byte for
pairing ID and one byte for the actual command. The actual keytable
*could* get by with just one byte if you didn't care about pairing, two
bytes if you do. But it can also use the full four bytes no problem.

I hacked together a proof-of-concept thing that *does* work for me, but
its not the prettiest thing around:

http://git.kernel.org/?p=linux/kernel/git/jarod/linux-2.6-ir.git;a=shortlog;h=refs/heads/staging

Basically, while loading keys, keep track of the largest one in the table,
and use that knowledge to figure out how to decode the signal. Doesn't
take key removal into account at all though, and has other issues I'm
probably forgetting right now. :)



> For this need rework all keytables and all keyread function for add scanmask configuration and
> rework single byte scancode code -> key << 8.
> 
> Use scanmask and return IR reading bytes on real place.
> 
> For tm6000 don't need restore full scancode 
> Only address filter
> 
> scanmask = 0xff00ff00;
> return byte[1] << 24 | byte[0] <<8
> 
> With my best regards, Dmitry.
> 
> > Hi Dmitri/Stefan,
> > 
> > Em 17-12-2010 05:08, Dmitri Belimov escreveu:
> > > On Fri, 17 Dec 2010 06:18:31 +0100
> > > Stefan Ringel <stefan.ringel@arcor.de> wrote:
> > > 
> > >> Am 17.12.2010 02:46, schrieb Dmitri Belimov:
> > >>> Hi Stefan
> > >>>
> > >>>> Am 16.12.2010 10:38, schrieb Dmitri Belimov:
> > >>>>> Hi
> > >>>>>
> > >>>>>>> I think your mean is wrong. Our IR remotes send extended NEC
> > >>>>>>> it is 4 bytes. We removed inverted 4 byte and now we have 3
> > >>>>>>> bytes from remotes. I think we must have full RCMAP with this
> > >>>>>>> 3 bytes from remotes. And use this remotes with some
> > >>>>>>> different IR recievers like some TV cards and LIRC-hardware
> > >>>>>>> and other. No need different RCMAP for the same remotes to
> > >>>>>>> different IR recievers like now.
> > >>>>>> Your change doesn't work with my terratec remote control !!
> > >>>>> I found what happens. Try my new patch.
> > >>>>>
> > >>>>> What about NEC. Original NEC send
> > >>>>> address (inverted address) key (inverted key)
> > >>>>> this is realy old standart now all remotes use extended NEC
> > >>>>> (adress high) (address low) key (inverted key)
> > >>>>> The trident 5600/6000/6010 use old protocol but didn't test
> > >>>>> inverted address byte.
> > >>>>>
> > >>>>> I think much better discover really address value and write it
> > >>>>> to keytable. For your remotes I add low address byte. This
> > >>>>> value is incorrent but usefull for tm6000. When you found
> > >>>>> correct value update keytable.
> > >>>>>
> > >>>> That is not acceptable. Have you forgotten what Mauro have
> > >>>> written? The Terratec rc map are use from other devices.
> > >>> NO
> > >>> The RC_MAP_NEC_TERRATEC_CINERGY_XS used only in tm6000 module.
> > >>> My patch didn't kill support any other devices.
> > >> That is not true.
> > > 
> > > I search "RC_MAP_NEC_TERRATEC_CINERGY_XS" on FULL linux kernel
> > > sources. And found this string in:
> > > include/media/rc-map.h
> > > drivers/staging//tm6000/tm6000-cards.c
> > > drivers/media/rc/keymaps/rc-nec-terratec-cinergy-xs.c
> > > 
> > > No any other devices didn't use this keymap.
> > > 
> > >>>> The best are only the
> > >>>> received data without additional data. And I think the Trident
> > >>>> chip send only compatibly data (send all extended data like
> > >>>> standard data). The device decoded the protocols not the driver.
> > >>> You can't use this remotes with normal working IR receivers
> > >>> because this receivers returned FULL scancodes. Need add one more
> > >>> keytable.
> > >>>
> > >>> 1. With my variant we have one keytable of remote and some
> > >>> workaround in device drivers. And can switch keytable and remotes
> > >>> on the fly (of course when keytable has really value and device
> > >>> driver has workaround)
> > >>>
> > >>> 2. With your variant we have some keytables for one remote for
> > >>> different IR recevers. Can't use incompatible keytable with other
> > >>> IR recievers. It is black magic for understanding what remotes is
> > >>> working with this hardware.
> > >>>
> > >>> I think my variant much better.
> > >>>
> > >>> With my best regards, Dmitry.
> > >>>
> > >> I think your variant is bad.
> > > 
> > > Mauro we need your opinion about this question.
> > 
> > I'm c/c Jarod, as he has a similar issue with some NEC-based boards 
> > (Apple "variant").
> > 
> > I also have experienced some cases where the NEC protocol in-hardware
> > decoder can provide only part of the NEC "extended" range.
> > 
> > I don't have a clear opinion about this issue, but I think that
> > putting all our brains to think about that, we may have a solution
> > for it.
> > 
> > Let me summarize the issues. Please complete/correct me if is there
> > anything else.
> > 
> > 1) NEC original format is 16 bits. However, some variants use 24 bits
> > for it (it is called, currently, NEC extended). A few other
> > manufacturers, like Apple, defines NEC protocol with 32 bits,
> > removing both address and command checksums.
> > 
> > 2) NEC raw decoder is capable of decoding the entire NEC code, but it
> > only accepts 16 or 24 bits, returning the scan code as:
> > 
> > 	scancode = address << 8 | command;
> > 
> > for 16 bits, and:
> > 
> > 	scancode = address << 16 | not_address <<  8 | command;
> > 
> > for 24 bits. There were some proposals to extend it to something like:
> > 
> > 	scancode = address << 24 | not_address << 16 | not_command <<
> > 8 | command; (or some other bit order)
> > 
> > Or just return the complete 32 bits even for the original NEC
> > protocol. However, changing it will break the existing userspace
> > decoding tables.
> > 
> > Another way would be to store the length of the scancode, using it as
> > well during the scancode->keycode translation.
> > 
> > But no patches were merged yet.
> > 
> > 3) Some hardware decoders can't return the complete NEC address.
> > There are variants that returns 8 bits, others that returns 16 bits,
> > and others that return the complete code.
> > 
> > For hardware that returns only 8 bits, we currently address the issue
> > by using a scancode mask. When "scanmask" is set at the rc structs,
> > the scancode->keycode logic will consider only the bits that are in
> > the mask.
> > 
> > 4) Some hardware filters the NEC address, returning only the codes for
> > some specific vendors.
> > 
> > Despite all discussions, we didn't reach an agreement yet.
> > 
> > There are some points to consider whatever solution we do:
> > 
> > 1) A keycode table should be able to work with a generic raw decoder.
> > So, on all drivers, the bit order and the number of bits for a given
> > protocol should be the same;
> > 
> > 2) we should avoid to cause regressions on the existing definitions.
> > 
> > That's said, suggestions to meet the needs are welcome.
> > 
> > Thanks,
> > Mauro

-- 
Jarod Wilson
jarod@redhat.com