[Patch] Kworld 315U remote support

[Patch] Kworld 315U remote support

[Franklin Meng]

This patch adds remote support for the Kworld 315U device

Note: I believe I got most of the mappings correct.  Though the
source and shutdown button probably could be mapped to something
better.  

To be done: Still need to get the Kworld analog patch resubmitted.
There are still some stuff I want to test with the analog patch before
I resubmit it.  Hopefully this patch will work ok.

Please let me know if there are any issues applying the patch

Signed-off-by: Franklin Meng <fmeng2002@yahoo.com>

diff -r 28f5eca12bb0 linux/drivers/media/IR/ir-keymaps.c
--- a/linux/drivers/media/IR/ir-keymaps.c	Sat Feb 06 23:49:31 2010 -0200
+++ b/linux/drivers/media/IR/ir-keymaps.c	Sun Feb 07 11:35:39 2010 -0800
@@ -3501,3 +3501,52 @@
 	.size = ARRAY_SIZE(ir_codes_winfast_usbii_deluxe),
 };
 EXPORT_SYMBOL_GPL(ir_codes_winfast_usbii_deluxe_table);
+
+/* Kworld 315U
+*/
+static struct ir_scancode ir_codes_kworld_315u[] = {
+	{ 0x43, KEY_POWER },
+	{ 0x01, KEY_TUNER },	/* source */
+	{ 0x0b, KEY_ZOOM },
+	{ 0x03, KEY_POWER2 },	/* shutdown */
+
+	{ 0x04, KEY_1 },
+	{ 0x08, KEY_2 },
+	{ 0x02, KEY_3 },
+	{ 0x09, KEY_CHANNELUP },
+
+	{ 0x0f, KEY_4 },
+	{ 0x05, KEY_5 },
+	{ 0x06, KEY_6 },
+	{ 0x07, KEY_CHANNELDOWN },
+
+	{ 0x0c, KEY_7 },
+	{ 0x0d, KEY_8 },
+	{ 0x0a, KEY_9 },
+	{ 0x0e, KEY_VOLUMEUP },
+
+	{ 0x10, KEY_LAST },
+	{ 0x11, KEY_0 },
+	{ 0x12, KEY_ENTER },
+	{ 0x13, KEY_VOLUMEDOWN },
+
+	{ 0x14, KEY_RECORD },
+	{ 0x15, KEY_STOP },
+	{ 0x16, KEY_PLAY },
+	{ 0x17, KEY_MUTE },
+
+	{ 0x18, KEY_UP },
+	{ 0x19, KEY_DOWN },
+	{ 0x1a, KEY_LEFT },
+	{ 0x1b, KEY_RIGHT },
+
+	{ 0x1c, KEY_RED },
+	{ 0x1d, KEY_GREEN },
+	{ 0x1e, KEY_YELLOW },
+	{ 0x1f, KEY_BLUE },
+};
+struct ir_scancode_table ir_codes_kworld_315u_table = {
+	.scan = ir_codes_kworld_315u,
+	.size = ARRAY_SIZE(ir_codes_kworld_315u),
+};
+EXPORT_SYMBOL_GPL(ir_codes_kworld_315u_table);
diff -r 28f5eca12bb0 linux/drivers/media/video/em28xx/em28xx-cards.c
--- a/linux/drivers/media/video/em28xx/em28xx-cards.c	Sat Feb 06 23:49:31 2010 -0200
+++ b/linux/drivers/media/video/em28xx/em28xx-cards.c	Sun Feb 07 11:35:39 2010 -0800
@@ -1322,6 +1322,7 @@
 		.tda9887_conf	= TDA9887_PRESENT,
 		.decoder	= EM28XX_SAA711X,
 		.has_dvb	= 1,
+		.ir_codes	= &ir_codes_kworld_315u_table,
 		.dvb_gpio	= em2882_kworld_315u_digital,
 		.xclk		= EM28XX_XCLK_FREQUENCY_12MHZ,
 		.i2c_speed	= EM28XX_I2C_CLK_WAIT_ENABLE,
diff -r 28f5eca12bb0 linux/include/media/ir-common.h
--- a/linux/include/media/ir-common.h	Sat Feb 06 23:49:31 2010 -0200
+++ b/linux/include/media/ir-common.h	Sun Feb 07 11:35:39 2010 -0800
@@ -163,4 +163,5 @@
 extern struct ir_scancode_table ir_codes_gadmei_rm008z_table;
 extern struct ir_scancode_table ir_codes_nec_terratec_cinergy_xs_table;
 extern struct ir_scancode_table ir_codes_winfast_usbii_deluxe_table;
+extern struct ir_scancode_table ir_codes_kworld_315u_table;
 #endif




      

Re: [Patch] Kworld 315U remote support

[Mauro Carvalho Chehab]

Franklin Meng wrote:
> This patch adds remote support for the Kworld 315U device
> 
> Note: I believe I got most of the mappings correct.  Though the
> source and shutdown button probably could be mapped to something
> better.  
> 
> To be done: Still need to get the Kworld analog patch resubmitted.
> There are still some stuff I want to test with the analog patch before
> I resubmit it.  Hopefully this patch will work ok.
> 
> Please let me know if there are any issues applying the patch

Hi Franklin,

Could you please add a table with the full scan code?

There are currently two examples of such tables:
	ir_codes_rc5_hauppauge_new_table - for RC5 keycodes
	ir_codes_nec_terratec_cinergy_xs_table - for NEC keycodes


Basically, a full scan code has a 2-byte code instead of 1-byte,
and you need to specify the protocol at the table, like:

struct ir_scancode_table ir_codes_nec_terratec_cinergy_xs_table = {
        .scan = ir_codes_nec_terratec_cinergy_xs,
        .size = ARRAY_SIZE(ir_codes_nec_terratec_cinergy_xs),
        .ir_type = IR_TYPE_NEC,
};

The em28xx is already prepared to properly handle the protocol.

the advantage of using a full table is that it is easy to replace
the keytable and even the protocol if someone wants to use a different
Remote Controller to control the device.

As you've declared this xclk:

                .xclk           = EM28XX_XCLK_FREQUENCY_12MHZ,

I suspect that your keycode is of the type NEC.


Cheers,
Mauro

Re: [Patch] Kworld 315U remote support

[Franklin Meng]

Mauro, 

I tried out the ir_type change to the code and when I set it to IR_TYPE_NEC, I see messages in the log indicating that the key was not recognized.  Using IR_TYPE_OTHER seems to work ok.

My guess is that if I modify the keycodes IR_TYPE_NEC will work as well.  Can I just use IR_TYPE_OTHER?  That seems like the most straight forward approach with the least amount of changes.  

Thanks,
Franklin Meng

--- On Mon, 2/8/10, Mauro Carvalho Chehab <maurochehab@gmail.com> wrote:

> From: Mauro Carvalho Chehab <maurochehab@gmail.com>
> Subject: Re: [Patch] Kworld 315U remote support
> To: "Franklin Meng" <fmeng2002@yahoo.com>
> Cc: "Douglas Schilling" <dougsland@gmail.com>, "maillist" <linux-media@vger.kernel.org>
> Date: Monday, February 8, 2010, 5:13 AM
> Franklin Meng wrote:
> > This patch adds remote support for the Kworld 315U
> device
> > 
> > Note: I believe I got most of the mappings
> correct.  Though the
> > source and shutdown button probably could be mapped to
> something
> > better.  
> > 
> > To be done: Still need to get the Kworld analog patch
> resubmitted.
> > There are still some stuff I want to test with the
> analog patch before
> > I resubmit it.  Hopefully this patch will work
> ok.
> > 
> > Please let me know if there are any issues applying
> the patch
> 
> Hi Franklin,
> 
> Could you please add a table with the full scan code?
> 
> There are currently two examples of such tables:
>     ir_codes_rc5_hauppauge_new_table - for
> RC5 keycodes
>     ir_codes_nec_terratec_cinergy_xs_table -
> for NEC keycodes
> 
> 
> Basically, a full scan code has a 2-byte code instead of
> 1-byte,
> and you need to specify the protocol at the table, like:
> 
> struct ir_scancode_table
> ir_codes_nec_terratec_cinergy_xs_table = {
>         .scan =
> ir_codes_nec_terratec_cinergy_xs,
>         .size =
> ARRAY_SIZE(ir_codes_nec_terratec_cinergy_xs),
>         .ir_type = IR_TYPE_NEC,
> };
> 
> The em28xx is already prepared to properly handle the
> protocol.
> 
> the advantage of using a full table is that it is easy to
> replace
> the keytable and even the protocol if someone wants to use
> a different
> Remote Controller to control the device.
> 
> As you've declared this xclk:
> 
>                
> .xclk           =
> EM28XX_XCLK_FREQUENCY_12MHZ,
> 
> I suspect that your keycode is of the type NEC.
> 
> 
> Cheers,
> 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
> 


      

Re: [Patch] Kworld 315U remote support

[Mauro Carvalho Chehab]

Franklin Meng wrote:
> Mauro, 
> 
> I tried out the ir_type change to the code and when I set it to IR_TYPE_NEC, I see messages in the log indicating that the key was not recognized.  Using IR_TYPE_OTHER seems to work ok.
> 
> My guess is that if I modify the keycodes IR_TYPE_NEC will work as well.

If it is displaying a log, it means that the protocol is NEC.
All you need is to add the 8 most significant bits to the table. In general,
this code is common to all keystrokes.

For example, this is the legacy keymap table for Hauppauge IR:

static struct ir_scancode ir_codes_hauppauge_new[] = {
        /* Keys 0 to 9 */
        { 0x00, KEY_0 },
        { 0x01, KEY_1 },
        { 0x02, KEY_2 },
        { 0x03, KEY_3 },
        { 0x04, KEY_4 },

The new table is:

static struct ir_scancode ir_codes_rc5_hauppauge_new[] = {
        /* Keys 0 to 9 */
        { 0x1e00, KEY_0 },
        { 0x1e01, KEY_1 },
        { 0x1e02, KEY_2 },
        { 0x1e03, KEY_3 },
        { 0x1e04, KEY_4 },

You'll notice that the only difference is that the code now has
"0x1e00" added to all keys, and that the new table has the
protocol properly indicated.

> Can I just use IR_TYPE_OTHER?  That seems like the most straight forward approach with the least amount of changes.  

The usage of IR_TYPE_OTHER disables some new API's that are shown
to userspace, that allows the replacement of the IR for a better one.

Due to that, the usage of IR_TYPE_OTHER is deprecated. 

We should really get rid of  all those legacy keymaps that don't 
inform the IR protocol, not allowing that the key sequences and protocols 
to  be properly seen on userspace and eventually replaced, if the user
wants to buy a powerful remote and associate other keys to his IR.

So, please don't use IR_TYPE_OTHER.

Cheers,
Mauro