bengtmartensson / devslashlirc

Object oriented access to /dev/lirc-hardware from C++ and Java

DevSlashLirc — Object oriented access to /dev/lirc-hardware.

API documentation

• C++
• Java

Introduction

This library makes objects from /dev/lirc-hardware. These objects have properties like canSend etc., indicating the capabilities of the currently connected hardwarec, and methods like send and receive for sending and receiving. See the examples in src/test/c++.

As opposed to standard C/Lirc, where a device is opened, and it "turns out" that it is "mode2" or "lirccode", here the user has to decide if he wants a mode2 or lirccode device, and open it with the appropriate class. This will fail if the connected hardware does not have the expected properties. For this, there are the concrete classes Mode2LircDevice (modeling a "mode2" device, i.e. with the possibility of handling IR signals with "arbitrary" timings), and LircCodeLircDevice (modeling a "LircCode" device, i.e. one that can only use IR signals from its own set, and codes them on an integer, representing the IR signal.) The latter class is presently not completely implemented.

The classes may be instantiated multiple times, but of course only one can open a particular device file at a particular time.

The core library is written in C++, using classes and the stdc++ library. There are no other dependencies. In particular, there is no dependency of the Lirc sources, includes, or libraries. Only media/lirc.h, see man 4 lirc, which is considered belonging to the kernel, is included. The C++ code is documented using doxygen.

The C++-code uses the ("non-portable") #pragma once instead of the traditional include guards.

The C++ code is compiled into a shared library. This can be linked into application programs (see the test programs in src/test/c++) or used as a JNI library for accessing it from Java. Also a static library is built.

As man 4 lirc shows, there is a large number of hardly ever implemented properties supported. I have followed the "agile" commandment maximize the amount of work not done, and simply ignored the ones not useful or not commonly implemented.

As mentioned, there are also Java bindings using JNI. With some extra effort, bindings from other languages can be added, for example using SWIG. Contributions are welcome, (see issue #1).

The code should compile on any platform supporting /dev/lirc, possibly after adapting the Makefile (see issue #2).

A natural extension would be to extend the library to support Lirc plugin drivers. This is discussed in issue #3). There is also a branch containing some work in this directon, lircdriver.

Maven is used to compile the Java parts. A Makefile compiles the C++ code, and also invokes the Maven process. Redundantly, to build, just issue the command

 make lib

On an x86_64, this will build the libraries for x86_32 and x86_64. To build for another architecture without using a cross compiler, log in to an appropriate host, cd to src/main/c++, and issue the command

make clean all

on that host. Then copy the thus created libdevslashlirc.so to a desired location.

The command

make doc

creates the Doxygen and Javadoc documentation.

The code is entirely written from scratch (not counting the branch lircdriver).

Usage

There is no "install". Just copy the so file, the jar file, and possibly the *.h files to anywhere you like. (Or use maven instead for the jar file.)

For C++ (or a similar language), just link with the shared library libdevslashlirc.so (alternatively the static library libdevslashlirc.a) in the usual manner.

For Java, copy libdevslashlirc.so to an "arbitrary" location. In the Java code, that library must be loaded with org.harctoolbox.devslashlirc.LircHardware.loadLibrary(). There are two possibilites:

1. Either call loadLibrary() without arguments, (see src/test/java/org/harctoolbox/devslashlirc/Mode2LircDeviceNGTest.java for an example), in which case the actual directory has to be given to the JVM using the -Djava.library.path option (like java -Djava.library.path=/usr/local/lib ...), or,

2. Call loadLibrary(File) with argument, either the path name of the library, or the path name of the containing directory. For example LircHardware.loadLibrary(new File("/home/trump/covfefe/libdevslashlirc.so")).

devslashlirc's Issues

Compile the driver on an raspberry pi :)

apt-get install maven oracle-java7-jdk
exchange the makefile i attached in /src/main/c++
Id had to change/add some includes

Makefile.zip

The only thing id got stuck is to install the built. Could you please help me with that?
It would be quite awesome to use the driver on a raspberry pi because the current liblirc isnt ported currently for the Rpi.

Support carrier measurement and "wide band receiver"

IIRC, I checked them when the project was new, and they did not work then. This appears to have changed since then. (Tested with a HP MCE USB dongle.)

Bindings for more languages, using e.g. SWIG

Implemente packaging and CI

Support Lirc plugin drivers

A natural extension would be to support Lirc dynamically loaded drivers, "plugins". I have actually spent quite some time on this, contained in the branch lircdriver. There are massive problems, basically due to the bad design of the Lirc drivers, resulting (among other things) in loader problems. The C++ version works reasonably, while the Java bindings suffer from loader problems, and does not find symbols. Possibly it is a Java problem?

Put API-Doc on Github pages and on harctoolbox.org

Changes for removal of javah

In newer Java distros, the program javah is replace by a -h option of javac, see http://openjdk.java.net/jeps/313. Unfortunately, the syntax has changed too.

open fails on Fedora 25.

This is the the problem of bengtmartensson/IrScrutinizer#177

Deploy to Maven Central Repository

Use Autotools for configuration

Use GNU autotools as in e.g. https://github.com/bengtmartensson/java-readline

Pack a fallback version of media/lirc.h for the case that the system's is not found.

Remove interfaces ILircCode and IMode2.

Both interfaces are used from exactly one class each, and thus serve no real purpose.

Set up API documentation as gh-pages

Both C++ (Doxygen) and Javadoc.
Cf. bengtmartensson/IrpTransmogrifier#105

Reading requests get out-of-phase

reading for example delivers already finished IR sequence.

write(2)-errors to /dev/lirc are not transmitted to Java

JNIEXPORT void JNICALL Java_org_harctoolbox_devslashlirc_Mode2LircDevice_sendNative(....) returns void, may be enough to change to jboolean.

The following signals is too long (?), and fails silently using IrScrutinizer

0000 006C 002A 0000 015B 00AD 0016 0016 0016 0041 0016 0016 0016 0041 0016 0041 0016 0041 0016 0041 0016 0016 0016 0041 0016 0016 0016 0041 0016 0016 0016 0016 0016 0016 0016 0016 0016 0041 0016 0041 0016 0041 0016 0016 0016 0041 0016 0041 0016 0016 0016 0016 0016 0016 0016 0016 0016 0016 0016 0041 0016 0016 0016 0016 0016 0041 0016 0041 0016 0041 0016 05F7 015B 0057 0016 0E6C 015B 0057 0016 0E6C 015B 0057 0016 0E6C 015B 0057 0016 0E6C

Implement begin- and ending timeouts compatibel with Girs and HarcHardware

It the lirc hardware does not support it, use read timeouts with poll(2) or select(2). Use LIRC_SET_REC_TIMEOUT and LIRC_SET_REC_TIMEOUT_REPORTS.

Note: Girs and HardHardware as well as poll uses values in milliseconds, Lirc microseconds.

Translate to modern C++

... probably C++17.

Should compile with -pedantic.

Fix/check timing on final silence

Silly method presently deployed in bool Mode2LircDevice::send(const lirc_t *data, unsigned length).

Problems with repeating NEC1-signals, for example from IrScrutinizer: timing of final gap of into is off.

Release 1.0.0

Basically declaring stand as "1.0.0"