diff options
| author | Jarod Wilson <jarod@redhat.com> | 2011-03-22 17:23:15 -0300 |
|---|---|---|
| committer | Mauro Carvalho Chehab <mchehab@redhat.com> | 2011-03-22 19:24:23 -0300 |
| commit | 4be22b6a7f2f2b7eb6f7aab8902068a367cda8ba (patch) | |
| tree | 57d31d0608de4a5eae9e4433911a2d56518abc68 /Documentation/video4linux/hauppauge-wintv-cx88-ir.txt | |
| parent | 7d9a46f9d5e0bea8e862143be73df2bbc9acb2a3 (diff) | |
| download | kernel_samsung_smdk4412-4be22b6a7f2f2b7eb6f7aab8902068a367cda8ba.zip kernel_samsung_smdk4412-4be22b6a7f2f2b7eb6f7aab8902068a367cda8ba.tar.gz kernel_samsung_smdk4412-4be22b6a7f2f2b7eb6f7aab8902068a367cda8ba.tar.bz2 | |
[media] rc: interim support for 32-bit NEC-ish scancodes
The Apple and TiVo remotes I've got use an NEC-ish protocol, but rather
than a command/not_command pair, they have what appear to be vendor ID
bytes. This change makes the NEC decoder warn if the command/not_command
checksum fails, but then passes along a full 32-bit scancode for keymap
lookup. This change should make no difference for existing keymaps,
since they simply won't have 32-bit scancodes, but allows for a 32-bit
keymap. At the moment, that'll have to be uploaded by the user, but I've
got Apple and TiVo remote keymaps forthcoming.
In the long run (2.6.40, hopefully), we should probably just always use
all 32 bits for all NEC keymaps, but this should get us by for 2.6.39.
(Note that a few of the TiVo keys actuallly *do* pass the command
checksum, so for now, the keymap for this remote will have to be a mix
of 24-bit and 32-bit scancodes, but so be it).
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Diffstat (limited to 'Documentation/video4linux/hauppauge-wintv-cx88-ir.txt')
0 files changed, 0 insertions, 0 deletions