On Fri, Oct 29, 2010 at 11:46:02AM -0200, Mauro Carvalho Chehab wrote: > Em 29-10-2010 01:15, Jarod Wilson escreveu: > > On Thu, Oct 28, 2010 at 11:11:31PM -0400, Jarod Wilson wrote: > >> I've got one of those tiny little 6-button Apple remotes here, now it can > >> be decoded in-kernel (tested w/an mceusb transceiver). > > > > Oh yeah, RFC, because I'm not sure if we should have a more generic "skip > > the checksum check" support -- I seem to recall discussion about it in the > > not so recent past. And a decoder hack for one specific remote is just > > kinda ugly... > > Yeah, I have the same doubt. One possibility would be to simply report a 32 bits > code, if the check fails. I don't doubt that we'll find other remotes with > a "NEC relaxed" protocol, with no checksum at all. So the Apple remotes do something funky... One of the four bytes is a remote identifier byte, which is used for pairing the remote to a specific device, and you can change the ID byte by simply holding down buttons on the remote. We could ignore the ID byte, and just match all Apple remotes, or we could add some sort of pairing support where we require the right ID byte in order to do scancode -> keycode mapping... But in the match all case, I think we need the NEC extended scancode (e.g. 0xee8703 for KEY_MENU on my remote), while in the match paired case, we need the full 4-byte/32-bit code... Offhand, I'm not quite sure how to cleanly handle both cases. When using lirc, the full 32-bits are used, and you either have your config with exact matches (remote ID byte included), or you add an ignore mask, which tells scancode matching to just ignore the ID byte. -- Jarod Wilson jarod@xxxxxxxxxx -- 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
