Em Mon, 10 Dec 2012 20:24:23 +0100 Frank Schäfer <fschaefer.oss@xxxxxxxxxxxxxx> escreveu: > Am 10.12.2012 18:57, schrieb Antti Palosaari: > > On 12/10/2012 06:13 PM, Devin Heitmueller wrote: > >> On Mon, Dec 10, 2012 at 11:01 AM, Frank Schäfer > >>> Adding a new property to the RC profile certainly seems to be the > >>> cleanest solution. > >>> Do all protocols have paritiy checking ? Otherwise we could add a new > >>> type RC_TYPE_NEC_NO_PARITY. > >>> OTOH, introducing a new bitfield in struct rc_map might be usefull for > >>> other flags, too, in the future... > >> > >> It's probably also worth mentioning that in that mode the device > >> reports four bytes, not two. I guess perhaps if parity is ignored it > >> reports the data in some other format? You will probably have to do > >> some experimentation there. > > > > Uh, current em28xx NEC implementation is locked to traditional 16 bit > > NEC, where is hw checksum used. It is not the current NEC implementation at the driver; it is, instead, a hardware issue. At least on the tests I did in the past with em28xx and remote controllers capable of producing 32 bit keycodes, the NEC hardware decoder inside em28xx were only providing 16 bits. Regards, Mauro -- 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
