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

["David Härdeman" <david@hardeman.nu>]

On Tue, 2 Nov 2010 16:42:05 -0400, Jarod Wilson <jarod@wilsonet.com>
wrote:
> On Mon, Nov 1, 2010 at 5:56 PM, David Härdeman <david@hardeman.nu>
wrote:
>> On Sat, Oct 30, 2010 at 10:32:14PM -0400, Jarod Wilson wrote:
>>> On Sat, Oct 30, 2010 at 7:36 PM, David Härdeman <david@hardeman.nu>
>>> wrote:
>>> > In that case, one solution would be:
>>> >
>>> > * using the full 32 bit scancode
>>> > * add a module parameter to squash the ID byte to zero
>>> > * default the module parameter to true
>>> > * create a keymap suitable for ID = 0x00
>>> >
>>> > Users who really want to distinguish remotes can then change the
>>> > module
>>> > parameter and generate a keymap for their particular ID. Most others
>>> > will be blissfully unaware of this feature.
>>>
>>> I was thinking something similar but slightly different. I think ID =
>>> 0x00 is a valid ID byte, so I was thinking static int pair_id = -1; to
>>> start out. This would be a stand-alone apple-only decoder, so we'd
>>> look for the apple identifier bytes, bail if not found. We'd also look
>>> at the ID byte, and if pair_id is 0-255, we'd bail if the ID byte
>>> didn't match it. The scancode we'd actually use to match the key table
>>> would be just the one command byte. It seems to make sense in my head,
>>> at least.
>>
>> But you'd lose the ability to support two different remotes with
>> different ID's (if you want different mappings in the keymap).
> 
> Hm, true. How likely are people to want to do that, I wonder?
> 
> So alternatively, rather than a pair_id param, could use a
> check_pair_byte param. If 0, then just & 0xff the pair byte, and have
> 0xff there in the default keymap (using all 32 bits for each code)

Yes, that's what I proposed above :) (just & 0x00 the pair byte)

-- 
David Härdeman