On 03/23/2011 01:00 AM, Mauro Carvalho Chehab wrote:
Em 22-03-2011 19:12, Malcolm Priestley escreveu:
On Tue, 2011-03-22 at 02:43 +0200, Antti Palosaari wrote:
Anyhow, my opinion is still that we *should* make all NEC remotes as 32
bit and leave handling of NEC 16, NEC 24, NEC 32 to NEC decoder. For
example AF9015 current NEC handling is too complex for that reason... I
don't like how it is implemented currently.
One of the reasons for using 32 bit was interference from other consumer
remotes. It appears, these near identical bubble remotes originate from
a Chinese factory and supplied with the same product with completely
different key mapping.
I am not sure how many of these remotes are common to other devices.
Drivers should get the 32 bit codes form NEC when hardware provides it.
What we currently do is to identify if the code has 16, 24 or 32 bits,
but it is probably better to always handle them as if they have 32 bits.
That's how af9015 driver handles it currently.
if (buf[14] == (u8) ~buf[15]) {
if (buf[12] == (u8) ~buf[13]) {
/* 16 bit NEC standard */
priv->rc_keycode = buf[12] << 8 | buf[14];
} else {
/* 24 bit NEC extended*/
priv->rc_keycode = buf[12] << 16 | buf[13] << 8 | buf[14];
}
} else {
/* 32 bit NEC full scancode */
priv->rc_keycode = buf[12] << 24 | buf[13] << 16 | buf[14] << 8 |
buf[15];
}
I think there is no any better currently.
Antti
--
http://palosaari.fi/
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
