v2: copy of buffer data from userspace done inside this plugin/driver,
keeping the actual drivers minimal, and more flexible in what we can
deliver to them later on (they may be fed from within kernelspace later
on, by an in-kernel IR encoder).
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
With this change, it is now possible to do something like:
su -c 'echo "none +rc-5 +nec" > /sys/class/rc/rc1/protocols'
This prevents the need of multiple opens, one for each protocol change,
and makes userspace application easier.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Writing "none" to /dev/class/rc/rc*/protocols will disable all protocols.
This allows an easier setup, from userspace, as userspace applications don't
need to disable protocol per protocol, before enabling a different set of
protocols.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
While rc-5 and rc-6 protocols are generally abreviated as "rc5" and "rc6",
previous sysfs nodes uses rc-5 and rc-6 for the Philips protocols. This is
consistent with the protocol nomenclature given by the original Philips
spec: "Remote control system RC-5" (doc. Nr. 9398 706 23011).
Also, rc5 is the name of a widely known cryptography protocol.
So, the better is to keep referring to those protocols as "rc-5" and "rc-6".
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Instead of using "magic" sizes for protocol names, replace them by an
array, and use strlen().
No functional changes.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
With the current logic, each raw decoder needs to add a copy of the exact
same sysfs code. This is both unnecessary and also means that (re)loading
an IR driver after raw decoder modules have been loaded won't work as
expected.
This patch moves that logic into ir-raw-event and adds a single sysfs
file per device.
Reading that file returns something like:
"rc5 [rc6] nec jvc [sony]"
(with enabled protocols in [] brackets)
Writing either "+protocol" or "-protocol" to that file will
enable or disable the according protocol decoder.
An additional benefit is that the disabling of a decoder will be
remembered across module removal/insertion so a previously
disabled decoder won't suddenly be activated again. The default
setting is to enable all decoders.
This is also necessary for the next patch which moves even more decoder
state into the central raw decoding structs.
Signed-off-by: David Härdeman <david@hardeman.nu>
Acked-by: Jarod Wilson <jarod@redhat.com>
Tested-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
It makes IR to work again for dm1105 and, possibly, others.
Signed-off-by: Igor M. Liplianin <liplianin@me.by>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Pulse-distance is not a protocol, it is a line coding (used by some protocols,
like NEC). Looking at the uses of IR_TYPE_PD, the real protocol seems to be
NEC in all cases (drivers/media/video/cx88/cx88-input.c is the only user).
So, remove IR_TYPE_PD while it is still easy to do so.
Signed-off-by: David Härdeman <david@hardeman.nu>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Fix some confusing comments in drivers/media/IR/*
Signed-off-by: David Härdeman <david@hardeman.nu>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Fix a double initialization of the same spinlock in drivers/media/IR/rc-map.c.
Signed-off-by: David Härdeman <david@hardeman.nu>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This patch adds a Sony12/15/20 decoder to ir-core.
Signed-off-by: David Härdeman <david@hardeman.nu>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This patch adds an RC6 decoder (modes 0 and 6A) to ir-core.
Signed-off-by: David Härdeman <david@hardeman.nu>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
ir-core.h has the kABI to be used by the bridge drivers, when needing to register
IR protocols and pass IR events. However, the same file also contains IR subsystem
internal calls, meant to be used inside ir-core and between ir-core and the raw
decoders.
Better to move those functions to an internal header, for some reasons:
1) Header will be a little more cleaner;
2) It avoids the need of recompile everything (bridge/hardware drivers, etc),
just because a new decoder were added, or some other internal change were needed;
3) Better organize the ir-core API, splitting the functions that are internal to
IR core and the ancillary drivers (decoders, lirc_dev) from the features that
should be exported to IR subsystem clients.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
drivers/media/IR/ir-sysfs.c: In function ‘store_protocol’:
drivers/media/IR/ir-sysfs.c:93: warning: suggest parentheses around assignment used as truth value
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Hardware decoders have a more limited set of decoders than software ones.
In general, they support just one protocol at a given time, but allow
changing between a few options.
Rename the previous badly named "current_protocol" as just "protocol",
meaning the current protocol(s) accepted by the driver, and
add a "support_protocols" to represent the entire universe of supported
protocols by that specific hardware.
As commented on http://lwn.net/Articles/378884/, the "one file, one value"
rule doesn't fit nor does make much sense for bitmap or enum values. So, the
supported_protocols will enum all supported protocols, and the protocol
will present all active protocols.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Some devices have in-hardware Remote Controller decoder, while others
need a software decoder to get the IR code. As each software decoder
can be enabled/disabled individually, allowing multiple protocol
decoding capability.
On the other hand, hardware decoders have a limited protocol
support, often being able of decoding just one protocol each time.
So, each type needs a different set of capabilities to control the
supported protocol(s).
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
When the remote controller class is anyway being renamed from ir to rc
this would be a good time to also rename the devices from rcrcvX to rcX.
I know we haven't reached any agreement on whether transmission will
eventually be handled by the same device, but this change will at
least make the device name non-receive-specific which will make it
possible in the future (and if a different approach is finally
agreed upon, the device name still works).
Signed-off-by: David Härdeman <david@hardeman.nu>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Instead of using the ugly keymap sequences, use the new rc-*.ko keymap
files. For now, it is still needed to have one keymap loaded, for the
RC code to work. Later patches will remove this depenency.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
IR is an alias for Infrared Remote, while RC is an alias for Remote
Controller.
While currently all implementations are with Infrared Remote Controller,
this subsystem is not meant to be used only by IR type of RC's. So,
as discussed on both linux-media and linux-input, the better is to
rename the subsystem as Remote Controller.
While, currently, the only application that uses the /sys/class/irrcv is
ir-keytable application, and its sysfs support works only with the
current linux-next code, it is still possible to change the userspace API
without the risk of breaking applications. So, better to rename this
sooner than later.
Later patches will be needed to rename the files and to move them away
from drivers/media, but this is not a critical issue. So, for now,
let's just change the name of the sysfs class/nodes.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Instead of hardcoding the protocols into ir-core, add a register interface
for the IR protocol decoders, and convert ir-nec-decoder into a client of
ir-core.
With this approach, it is possible to dynamically load the needed IR protocols,
and to add a RAW IR interface module, registered as one IR raw protocol decoder.
This patch opens a way to register a lirc_dev interface to work as an userspace
IR protocol decoder.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Now, both driver and keytable names are exported to userspace. This
will help userspace to decide when a table need to be replaced
by another one.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Change the ir-sysfs approach to create irrcv0 as a device, instead of
using class_dev. Also, change the way input is registered, in order
to make its parent to be the irrcv device.
Due to this change, now the event device is created under
/sys/class/ir/irrcv class:
/sys/class/irrcv/irrcv0/
|-- current_protocol
|-- device -> ../../../1-3
|-- input9
| |-- capabilities
| | |-- abs
...
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
percpu.h is included by sched.h and module.h and thus ends up being
included when building most .c files. percpu.h includes slab.h which
in turn includes gfp.h making everything defined by the two files
universally available and complicating inclusion dependencies.
percpu.h -> slab.h dependency is about to be removed. Prepare for
this change by updating users of gfp and slab facilities include those
headers directly instead of assuming availability. As this conversion
needs to touch large number of source files, the following script is
used as the basis of conversion.
http://userweb.kernel.org/~tj/misc/slabh-sweep.py
The script does the followings.
* Scan files for gfp and slab usages and update includes such that
only the necessary includes are there. ie. if only gfp is used,
gfp.h, if slab is used, slab.h.
* When the script inserts a new include, it looks at the include
blocks and try to put the new include such that its order conforms
to its surrounding. It's put in the include block which contains
core kernel includes, in the same order that the rest are ordered -
alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
doesn't seem to be any matching order.
* If the script can't find a place to put a new include (mostly
because the file doesn't have fitting include block), it prints out
an error message indicating which .h file needs to be added to the
file.
The conversion was done in the following steps.
1. The initial automatic conversion of all .c files updated slightly
over 4000 files, deleting around 700 includes and adding ~480 gfp.h
and ~3000 slab.h inclusions. The script emitted errors for ~400
files.
2. Each error was manually checked. Some didn't need the inclusion,
some needed manual addition while adding it to implementation .h or
embedding .c file was more appropriate for others. This step added
inclusions to around 150 files.
3. The script was run again and the output was compared to the edits
from #2 to make sure no file was left behind.
4. Several build tests were done and a couple of problems were fixed.
e.g. lib/decompress_*.c used malloc/free() wrappers around slab
APIs requiring slab.h to be added manually.
5. The script was run on all .h files but without automatically
editing them as sprinkling gfp.h and slab.h inclusions around .h
files could easily lead to inclusion dependency hell. Most gfp.h
inclusion directives were ignored as stuff from gfp.h was usually
wildly available and often used in preprocessor macros. Each
slab.h inclusion directive was examined and added manually as
necessary.
6. percpu.h was updated not to include slab.h.
7. Build test were done on the following configurations and failures
were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my
distributed build env didn't work with gcov compiles) and a few
more options had to be turned off depending on archs to make things
build (like ipr on powerpc/64 which failed due to missing writeq).
* x86 and x86_64 UP and SMP allmodconfig and a custom test config.
* powerpc and powerpc64 SMP allmodconfig
* sparc and sparc64 SMP allmodconfig
* ia64 SMP allmodconfig
* s390 SMP allmodconfig
* alpha SMP allmodconfig
* um on x86_64 SMP allmodconfig
8. percpu.h modifications were reverted so that it could be applied as
a separate patch and serve as bisection point.
Given the fact that I had only a couple of failures from tests on step
6, I'm fairly confident about the coverage of this conversion patch.
If there is a breakage, it's likely to be something in one of the arch
headers which should be easily discoverable easily on most builds of
the specific arch.
Signed-off-by: Tejun Heo <tj@kernel.org>
Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
This patch fixes the declaration of the sysfs attributes for IR's, which
must be a NULL-terminated array of struct attribute *.
Without this patch, my machine crashes when inserting a DVB card.
Signed-off-by: Francesco Lavra <francescolavra@interfree.it>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
As currently most drivers don't define ir_dev->props, we shouldn't assume
that this field is defined.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
When preparing the linux-next patches, I got those errors:
include/media/ir-core.h:29: warning: left shift count >= width of type
In file included from include/media/ir-common.h:29,
from drivers/media/video/ir-kbd-i2c.c:50:
drivers/media/video/ir-kbd-i2c.c: In function ‘ir_probe’:
drivers/media/video/ir-kbd-i2c.c:324: warning: left shift count >= width of type
Unfortunately, enum is 32 bits on i386. As we define IR_TYPE_OTHER as 1<<63,
it won't work on non 64 bits arch.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Add sysfs skeleton to export remote controller information via
/sys/class/irrcv.
For now, the code doesn't do much. It just exports an attribute that
is meant to report and control the IR protocol used by the keytable.
However, the callbacks for this new attribute weren't set yet.
Also, it lacks symlinks to the used event interface.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
