Re: [RFC PATCH 0/2] Apple remote support

[Jarod Wilson <jarod@wilsonet.com>]

On Nov 5, 2010, at 10:04 AM, Christopher Harrington wrote:

> On Fri, Nov 5, 2010 at 08:27, David Härdeman <david@hardeman.nu> 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@wilsonet.com