On Tue, 2 Nov 2010 16:42:05 -0400, Jarod Wilson <jarod@xxxxxxxxxxxx> wrote: > On Mon, Nov 1, 2010 at 5:56 PM, David HÃrdeman <david@xxxxxxxxxxx> 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@xxxxxxxxxxx> >>> 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 -- 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
