linux.git/include/media/rc-core.h, branch v3.15

[media] rc-core: remove generic scancode filter

2014-04-06T14:30:29+00:00

The generic scancode filtering has questionable value and makes it
impossible to determine from userspace if there is an actual
scancode hw filter present or not.

So revert the generic parts.

Based on a patch from James Hogan , but this
version also makes sure that only the valid sysfs files are created
in the first place.

Signed-off-by: David Härdeman 
Acked-by: James Hogan 
Signed-off-by: Mauro Carvalho Chehab

[media] rc-core: split dev->s_filter

2014-04-06T14:30:25+00:00

Overloading dev->s_filter to do two different functions (set wakeup filters
and generic hardware filters) makes it impossible to tell what the
hardware actually supports, so create a separate dev->s_wakeup_filter and
make the distinction explicit.

Signed-off-by: David Härdeman 
Acked-by: James Hogan 
Signed-off-by: Mauro Carvalho Chehab

[media] rc: add wakeup_protocols sysfs file

2014-03-11T16:28:20+00:00

Add a wakeup_protocols sysfs file which controls the new
rc_dev::enabled_protocols[RC_FILTER_WAKEUP], which is the mask of
protocols that are used for the wakeup filter.

A new RC driver callback change_wakeup_protocol() is called to change
the wakeup protocol mask.

Signed-off-by: James Hogan 
Reviewed-by: Antti Seppälä 
Signed-off-by: Mauro Carvalho Chehab

[media] rc: add allowed/enabled wakeup protocol masks

2014-03-11T16:25:49+00:00

Only a single allowed and enabled protocol mask currently exists in
struct rc_dev, however to support a separate wakeup filter protocol two
of each are needed, ideally as an array.

Therefore make both rc_dev::allowed_protos and rc_dev::enabled_protocols
arrays, update all users to reference the first element
(RC_FILTER_NORMAL), and add a couple more helper functions for drivers
to use for setting the allowed and enabled wakeup protocols.

We also rename allowed_protos to allowed_protocols while we're at it,
which is more consistent with enabled_protocols.

Signed-off-by: James Hogan 
Reviewed-by: Antti Seppälä 
Signed-off-by: Mauro Carvalho Chehab

[media] rc: abstract access to allowed/enabled protocols

2014-03-11T16:24:39+00:00

The allowed and enabled protocol masks need to be expanded to be per
filter type in order to support wakeup filter protocol selection. To
ease that process abstract access to the rc_dev::allowed_protos and
rc_dev::enabled_protocols members with inline functions.

Signed-off-by: James Hogan 
Reviewed-by: Antti Seppälä 
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: add sysfs scancode filtering interface

2014-02-06T11:18:57+00:00

Add and document a generic sysfs based scancode filtering interface for
making use of IR data matching hardware to filter out uninteresting
scancodes. Two filters exist, one for normal operation and one for
filtering scancodes which are permitted to wake the system from suspend.

The following files are added to /sys/class/rc/rc?/:
 - filter: normal scancode filter value
 - filter_mask: normal scancode filter mask
 - wakeup_filter: wakeup scancode filter value
 - wakeup_filter_mask: wakeup scancode filter mask

A new s_filter() driver callback is added which must arrange for the
specified filter to be applied at the right time. Drivers can convert
the scancode filter into a raw IR data filter, which can be applied
immediately or later (for wake up filters).

Signed-off-by: James Hogan 
Cc: Mauro Carvalho Chehab 
Cc: linux-media@vger.kernel.org
Cc: Rob Landley 
Cc: linux-doc@vger.kernel.org
Signed-off-by: Mauro Carvalho Chehab

[media] media: rc: Add rc_open/close and use count to rc_dev

2013-07-31T19:28:01+00:00

This patch adds user count to rc_dev structure, the reason to add this
new member is to allow other code like lirc to open rc device directly.
In the existing code, rc device is only opened by input subsystem which
works ok if we have any input drivers to match. But in case like lirc
where there will be no input driver, rc device will be never opened.
Having this user count variable will be usefull to allow rc device to be
opened from code other than rc-main.
This patch also adds rc_open and rc_close functions for other drivers
like lirc to open and close rc devices. This functions safely increment
and decrement the user count. Other driver wanting to open rc device
should call rc_open and rc_close, rather than directly modifying the
rc_dev structure.

Signed-off-by: Srinivas Kandagatla 
Signed-off-by: Mauro Carvalho Chehab

[media] rc-core: don't treat dev->rc_map.rc_type as a bitmap

2013-03-23T14:25:54+00:00

store_protocols() treats dev->rc_map.rc_type as a bitmap which is wrong for
two reasons. First of all, it is pretty bogus to change the protocol type of
the keymap just because the hardware has been asked to decode a different
protocol.
Second, dev->rc_map.rc_type is an enum (i.e. a single protocol) as pointed
out by James Hogan .
Fix both issues by introducing a separate enabled_protocols member to
struct rc_dev.

Signed-off-by: David Härdeman 
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