Previously this function was confusing because the loop/retry condition
`ret > 0` was far from the code that would set `ret` and `ret` could be the
return value from either `write` to lircd or `ftdi_read` from the hardware.

For easier debugging.

This can happen on first use of the device after rebooting.  This
previously caused lirc to hang with the ftdi subprocess stuck in a loop of
erroring and retrying.

...by closing the ftdi device before attempting to reopen it.  Otherwise
you get stuck in an infinite loop as `ftdi_usb_open_desc` will fail as the
device is already open.  I can't understand how this retry logic ever could
have worked for any errors apart from:

* Open failing
* Unplugging and replugging the ftdi device

Signals longer than 125ms would cause "buffer overflow while generating
IR pattern".

212992 is just over twice as long as the signal I need to send. At the
default tx_baud_rate it allows signals up to 406ms long. It is the same
as WMEM_MAX on my system (the socket send buffer maximum size) in case
we want to use socketpair(2) and SOCK_DGRAM instead of pipe(2) in the
future.

We set the pipe buffer size to avoid extra context switches.

This reverts commit 534fd8a.

As far as I can tell these config files are only used by the tool
"lirc-setup", which we don't use. I need to disable this because the
makefile downloads these config files from sourceforge at build time,
and sourceforge is down right now (and has been down for ~19 hours).

This will be helpful to distinguish between FTDI devices when there are
multiple of them attached to the same machine.  You can use udev to create
a well known symlink name pointing at the `/dev/bus/usb/BBB/DDD` device
node and pass that as `--device` to lirc.

This isn't perfect: If you're not using udev and you have created a device
node yourself (with mknod) whose name doesn't end in `/BBB/DDD` then this
will fail.  Fixing that edge case would require patching libusb, but it
shouldn't come up in practice.

We still support the alternative syntax of identifying a device by
product/vendor/serial.  We can distinguish between the two syntaxes as
absolute filenames always start with a `/`.

The library used to be called libsystemd-daemon, now it's just libsystemd
since systemd v209.

This allows systemd to detect the case where we've failed to startup
due to a failure to parse our config files.

Run the tests with:

    pytest-3 -vv test/test_release_mask.py

I was confused about the interactions between lircd.c and transmit.c --
they both manipulate `remote->repeat_countdown` and there are loads of
global variables involved (such as `repeat_remote`). This test proves
that if you set a count (with `irsend --count=... send_once`) it doesn't
override `min_repeat` if it's smaller than `min_repeat`, and vice versa.
This wasn't obvious to me from reading the code so I wrote a test to
satisfy myself. I will add further tests to this file in a future
commit, when I'll be adding a feature to lirc.

I've used python because it's much easier than bash. I've used [pytest],
which is a widely used Python testing framework, because it makes it
easy to test lots of combinations, like I've done here with
`parametrize`. You can install pytest from PyPI (`pip3 install pytest`)
or from your Linux distro (on Ubuntu: `sudo apt install python3-pytest`).

As far as I can tell the existing tests in `test/tests` are for testing
signal *decoding*; and this is the first integration test (that actually
runs `lircd` rather than `irsimsend` or some such) for testing
signal *sending*.

[pytest]: https://pytest.org/

The remote control for some set-top boxes (notably Vodafone, but also a
few others), send repeat signals that are identical to the original
signal, but the very last repeat has one bit toggled, meaning "key
released". The shortest possible keypress consists of the original
signal + this "release" signal.

So far we were emulating this behaviour with repeat_mask and
min_repeat=1 (so the one and only repeat signal is also the final
repeat, and it has the "release bit" toggled via repeat_mask), but that
doesn't work for long presses (send_start + wait + send_stop). Instead a
long press would look like a single "key pressed" signal followed by
many "key released" signals, and the set-top box interprets this as many
different keypresses.

This commit implements a solution by adding a new config option called
"release_mask". If specified, lircd will always send one extra
signal (after all the "min_repeats") with the specified bits toggled. So
far I have only implemented this for sending, not for
receiving/decoding. If you need to receive these signals, you could
probably use "ignore_mask" instead, but I haven't tested it.

Fixes dynamic linking issues when loading this plugin.

To fix build problems on Ubuntu 18.04.

…gnals

lircd used to use SIGALRM for timers via `setitimer`, etc.  Dealing with
signals correctly and without races is incredibly difficult.  Instead of
using `setitimer` we keep a global `repeat_deadline` specifying the next
time at which a repeat should be sent.

This seems to resolve some race conditions around repeats.

We no longer use it as of the previous commit.