On Nov 5, 2010, at 10:04 AM, Christopher Harrington wrote: > On Fri, Nov 5, 2010 at 08:27, David Härdeman <david@xxxxxxxxxxx> wrote: >> If you're referring to the pain caused by changing existing keytables >> (thereby breaking custom keytables), I think it's inevitable. Throwing away >> information is not a good solution. >> >> As this subsystem progresses, there's going to be more and more reports of >> remotes which, intentionally or unintentionally, do not follow the NEC >> "standard" (I use that word in the most liberal sense). Using the full 32 >> bits allows us to support them without any module parameters or code >> changes. >> >> Which solution do you suggest? > > What about reporting two key events: One with the Apple ID masked, and > one with the Apple ID retained? The "default" keymap could then match > the masked IDs, with the option of the user changing their keymaps to > ignore the masked one and only "pair" with the specific IDs they're > looking for? > > As a bonus, they will be able to watch incoming scancodes to see the > ID they might want to pair with, even though those scancodes would be > ignored. Interesting idea. But I think that 99% of the time, sending two scancodes is unnecessary overhead. I've got some reworked code I still need to test out which simply spits out the Apple remote's pair ID into dmesg w/core ir debugging enabled. If we're not pairing, its masked out in the full 32-bit scancode sent along, but still available via dmesg. If we are pairing, the pair byte is included in the full 32-bit scancode sent along. -- Jarod Wilson jarod@xxxxxxxxxxxx -- 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
