Em Mon, 10 Dec 2012 11:13:07 -0500 Devin Heitmueller <dheitmueller@xxxxxxxxxxxxxx> escreveu: > 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. Hmm... that explains why em28xx weren't working properly with NEC extended codes ;) IMO, the better is to set it for NEC, and let the driver to do the parity check, in order to properly handle the variants of the NEC protocol (16, 24 or 32 bits). Due to the way the RC keycode is stored, there's no risk on keeping it disabled, as a keycode generated by a 16-bit NEC remote with a parity error will produce a 24 or 32 bits keycode. Such keycode will be discarded for a keytable with 16 bits keycodes. 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
