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. -- -Chris Harrington Phone: 612.598.3650 -- 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
