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) or just don't make it part of the scancode and use 24 bits. If check_pair_byte = 1, pass the pair byte along unmodified, using all 32 bits for the scancode. Would also require the user to add the remote-specific 32-bit codes though. But we're moving towards keymaps being uploaded from userspace anyway, so perhaps that's not a big deal. Would rather avoid the default keymap having 256 entries for every key for every pair id variant. -- 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
