linux-toradex.git/include/media/rc-map.h, branch v3.11.2

[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: 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

[media] patch for Asus My Cinema PS3-100 (1043:48cd)

2012-05-20T19:05:02+00:00

Signed-off-by: Remi Schwartz 
Signed-off-by: Mauro Carvalho Chehab

[media] ati_remote: add keymap for Medion X10 OR2x remotes

2012-05-20T14:40:06+00:00

Add another Medion X10 remote keymap. This is for the Medion OR2x
remotes with the Windows MCE button.

The receiver shipped with this remote has the same USB ID as the other
Medion receivers, but the name is different and is therefore used to
detect this variant.

Signed-off-by: Anssi Hannula 
Signed-off-by: Mauro Carvalho Chehab

[media] ati_remote: add support for Medion X10 Digitainer remote

2012-04-11T05:05:46+00:00

Add support for another Medion X10 remote. This was apparently
originally used with the Medion Digitainer box, but is now sold
separately without any Digitainer labeling.

A peculiarity of this remote is a scrollwheel in place of up/down
buttons. Each direction is mapped to 8 different scancodes, each
corresponding to 1..8 notches, allowing multiple notches to the same
direction to be transmitted in a single scancode. The driver transforms
the multi-notch scancodes to multiple events of the single-notch
scancode.
(0x70..0x77 = 1..8 notches down, 0x78..0x7f = 1..8 notches up)

Since the scrollwheel scancodes are the same that are used for mouse on
some other X10 (ati_remote) remotes, the driver will now check whether
the active keymap has a keycode defined for the single-notch scancode
when a mouse/scrollwheel scancode (0x70..0x7f) is received. If set,
scrollwheel is assumed, otherwise mouse is assumed.

This remote ships with a different receiver than the already supported
Medion X10 remote, but they share the same USB ID. The only difference
in the USB descriptors is that the Digitainer receiver has the Remote
Wakeup bit set in bmAttributes of the Configuration Descriptor.
Therefore that is used to select the default keymap.

Thanks to Stephan Raue from OpenELEC (www.openelec.tv) for providing me
both a Medion X10 Digitainer remote+receiver and an already supported
Medion X10 remote+receiver. Thanks to Martin Beyss for providing some
useful information about the remote (including the "Digitainer" name).
This patch has been tested by both of them and myself.

Signed-off-by: Anssi Hannula 
Tested-by: Stephan Raue 
Tested-by: Martin Beyss 
Signed-off-by: Mauro Carvalho Chehab

[media] Add support for KWorld PC150-U ATSC hybrid tuner card

2012-03-08T14:01:25+00:00

[mchehab@redhat.com: CodingStyle fixes]
Signed-off-by: Kyle Strickland 
Signed-off-by: Mauro Carvalho Chehab

[media] IT913X Version 1 and Version 2 keymaps

2012-02-14T16:07:46+00:00

IT913X V1 V2 keymaps

Signed-off-by: Malcolm Priestley 
Signed-off-by: Mauro Carvalho Chehab

[media] rc-videomate-m1f.c Rename to match remote controler name

2012-01-11T01:38:19+00:00

This remote was added with support for card Compro VideoMate M1F.

This remote is shipped with various Compro cards, not this one only.

Furthermore this remote can be bought separately under name Compro
VideoMate K100.
    http://compro.com.tw/en/product/k100/k100.html

So give it a proper name.

[mchehab@redhat.com: Fix the Makefile]
Signed-off-by: Samuel Rakitničan 
Signed-off-by: Mauro Carvalho Chehab