Re: [Patch] Kworld 315U remote support

[Mauro Carvalho Chehab <maurochehab@gmail.com>]

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