linux-toradex.git/drivers/media/rc/keymaps, branch v3.16.3

[media] rc-core: do not change 32bit NEC scancode format for now

2014-04-06T14:26:04+00:00

This reverts 18bc17448147e93f31cc9b1a83be49f1224657b2 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 
Acked-by: James Hogan 
Signed-off-by: Mauro Carvalho Chehab

[media, edac] Change my email address

2014-02-07T10:03:07+00:00

There are several left overs with my old email address.
Remove their occurrences and add myself at CREDITS, to
allow people to be able to reach me on my new addresses.

Signed-off-by: Mauro Carvalho Chehab

[media] media: rc: change 32bit NEC scancode format

2014-02-06T11:20:07+00:00

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 
Cc: Mauro Carvalho Chehab 
Cc: Jarod Wilson 
Cc: linux-media@vger.kernel.org
Signed-off-by: Mauro Carvalho Chehab

[media] dw2102: Use RC Core instead of the legacy RC (second edition)

2013-12-10T17:22:30+00:00

Use RC Core instead of the legacy RC.
DVBWorld, TBS, TeVii, Prof hardware decode only NEC remotes (one byte code).
Geniatech hardware decode only RC5 (two bytes).
+ New keymap for Geniatech HDStar (SU3000).

Signed-off-by: Evgeny Plehov 
Signed-off-by: Mauro Carvalho Chehab

treewide: Fix common typo in "identify"

2013-10-14T13:31:06+00:00

Correct common misspelling of "identify" as "indentify" throughout
the kernel

Signed-off-by: Maxime Jayat 
Signed-off-by: Jiri Kosina

[media] rc: Add rc-delock-61959

2013-05-21T11:18:19+00:00

This adds the keytable for the remote that comes with the Delock 61959.
NEC protocol with address 0x866b.

Signed-off-by: Jakob Haufe 
Reviewed-by: Antti Palosaari 
Signed-off-by: Hans Verkuil 
Signed-off-by: Mauro Carvalho Chehab

[media] rc: fix single line indentation of keymaps/Makefile

2013-04-15T01:51:41+00:00

Signed-off-by: Antti Palosaari 
Signed-off-by: Mauro Carvalho Chehab

[media] rc: add rc-reddo

2013-04-15T01:48:35+00:00

It is very similar than rc-msi-digivox-iii but new keytable is needed
as there is one existing scancode mapped to different button. Also that
one has less buttons.
NEC extended protocol with address 0x61d6.

Signed-off-by: Antti Palosaari 
Signed-off-by: Mauro Carvalho Chehab

[media] rc/keymaps: add RC keytable for MyGica X8507

2012-12-23T21:42:14+00:00

Add RC-5 remote keytable definition for MyGica X8507.

[mchehab@redhat.com: fixed whitespacing - it seems that Alfredo's emailer mangled
 it]
Signed-off-by: Alfredo J. Delaiti 
Signed-off-by: Mauro Carvalho Chehab

[media] rc-core: add separate defines for protocol bitmaps and numbers

2012-10-27T13:49:51+00:00

The RC_TYPE_* defines are currently used both where a single protocol is
expected and where a bitmap of protocols is expected.

Functions like rc_keydown() and functions which add/remove entries to the
keytable want a single protocol. Future userspace APIs would also
benefit from numeric protocols (rather than bitmap ones). Keytables are
smaller if they can use a small(ish) integer rather than a bitmap.

Other functions or struct members (e.g. allowed_protos,
enabled_protocols, etc) accept multiple protocols and need a bitmap.

Using different types reduces the risk of programmer error. Using a
protocol enum whereever possible also makes for a more future-proof
user-space API as we don't need to worry about a sufficient number of
bits being available (e.g. in structs used for ioctl() calls).

The use of both a number and a corresponding bit is dalso one in e.g.
the input subsystem as well (see all the references to set/clear bit when
changing keytables for example).

This patch separate the different usages in preparation for
upcoming patches.

Where a single protocol is expected, enum rc_type is used; where one or more
protocol(s) are expected, something like u64 is used.

The patch has been rewritten so that the format of the sysfs "protocols"
file is no longer altered (at the loss of some detail). The file itself
should probably be deprecated in the future though.

Signed-off-by: David Härdeman 
Cc: Andy Walls 
Cc: Maxim Levitsky 
Cc: Antti Palosaari 
Cc: Mike Isely 
Signed-off-by: Mauro Carvalho Chehab