The rc_proto field should list the exact variant used by the remote. This
does not change the decoder used, but helps with using keymaps for
transmit purposes.
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
RC_TYPE is confusing and it's just the protocol. So rename it.
Suggested-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Sean Young <sean@mess.org>
Acked-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
There are two different encodings used for nec32:
- The ir-nec-decoder.c decoder treats it as 32 bit msb first.
- The img-ir decoder/encoder, winbond wakeup, dib0700, ir-ctl userspace,
treat nec32 analogous to necx and nec: 4 bytes, each lsb first. So this
format reverses the 4 bytes.
There are arguments to be had for both formats, but we should not use
different formats in different parts of the kernel. Selecting the second
format introduces the least code churn. It does mean that the TiVo keymap
needs updating.
This change was submitted before as "18bc174 [media] media: rc: change
32bit NEC scancode format", which was reverted because it was unclear
what scancode rc drivers produce. There are now more examples of drivers
which produce nec32 in lsb format.
The TiVo keymap is verified against the Nero Liquid TiVo remote. The
keymap is not for the Tivo DVR remote, which uses rc-5.
Signed-off-by: Sean Young <sean@mess.org>
Cc: James Hogan <james.hogan@imgtec.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
This reverts 18bc174481 and changes
the code at img-ir-nec.c to use the order used by the other NEC decoders.
The original patch ignored the fact that NEC32 scancodes are generated not
only in the NEC raw decoder but also directly in some drivers. Whichever
approach is chosen it should be consistent across drivers and this patch
needs more discussion.
Furthermore, I'm convinced that we have to stop playing games trying to
decipher the "meaning" of NEC scancodes (what's the customer/vendor/address,
which byte is the MSB, etc).
Signed-off-by: David Härdeman <david@hardeman.nu>
Acked-by: James Hogan <james.hogan@imgtec.com>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
Change 32bit NEC scancode format (used by Apple and TiVo remotes) to
encode the data with the correct bit order. Previously the raw bits were
used without being bit reversed, now each 16bit half is bit reversed
compared to before.
So for the raw NEC data:
(LSB/First) 0xAAaaCCcc (MSB/Last)
(where traditionally AA=address, aa=~address, CC=command, cc=~command)
We now generate the scancodes:
(MSB) 0x0000AACC (LSB) (normal NEC)
(MSB) 0x00AAaaCC (LSB) (extended NEC, address check wrong)
(MSB) 0xaaAAccCC (LSB) (32-bit NEC, command check wrong)
Note that the address byte order in 32-bit NEC scancodes is different to
that of the extended NEC scancodes. I chose this way as it maintains the
order of the bits in the address/command fields, and CC is clearly
intended to be the LSB of the command if the TiVo codes are anything to
go by so it makes sense for AA to also be the LSB.
The TiVo keymap is updated accordingly.
Signed-off-by: James Hogan <james.hogan@imgtec.com>
Cc: Mauro Carvalho Chehab <m.chehab@samsung.com>
Cc: Jarod Wilson <jarod@redhat.com>
Cc: linux-media@vger.kernel.org
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
A pending cleanup will mean that module.h won't be implicitly
everywhere anymore. Make sure the modular drivers in clocksource
are actually calling out for <module.h> explicitly in advance.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Sean Young