#279 lircd not picking up devices after first client connect

[Matthias Reichl]

I noticed that lircd (0.9.4d and trunk) isn't properly picking up devices that appear after the first client (lircd-uinput, irw, ...) connected. This can happen if systemd starts lircd/lircd-uinput before the device is available on the system (eg USB DVB receivers with integrated IR receiver).

With the default driver the behaviour is a bit odd, after all clients have disconnected and another client connects lircd will retry driver init in 1 second intervals. With the pinsys driver init is never retried.

Reproducing/simulating this is rather easy, just start lircd with a non-existant device. eg:

./sbin/lircd -n -D10 --driver=default --device=/does/not/exist -o /tmp/lircd.socket ../my.lircd.conf

Debugging revealed that the culprit seems to be driver.fd being initialized to 0. Most of the lirc code checks for drv.fd != -1, also the reconnect code in lircd.cpp responsible for setting the poll timeout to 1 second or -1.

With the default driver there's another (unwanted) side effect, default_deinit then closes stdin. After that it sets drv.fd to -1, thus reconnect works once the driver (which was never fully inited) got deinited.

As a quick workaround I initialized drv.fd to -1 in hw_coose_driver, this resulted in reconnect working properly with the default and pinsys drivers (haven't tested with other drivers):

--- a/lib/drv_admin.c
+++ b/lib/drv_admin.c
@@ -300,6 +300,7 @@ int hw_choose_driver(const char* name)

        if (name == NULL) {
                memcpy(&drv, &drv_null, sizeof(struct driver));
+               drv.fd = -1;
                return 0;
        }
        if (strcasecmp(name, "dev/input") == 0)
@@ -308,6 +309,7 @@ int hw_choose_driver(const char* name)
        found = for_each_driver(match_hw_name, (void*)name, NULL);
        if (found != (struct driver*)NULL) {
                memcpy(&drv, found, sizeof(struct driver));
+               drv.fd = -1;
                return 0;
        }
        return -1;

I'm not sure though if this is the correct fix, maybe initial .fd value should be controlled by the drivers or maybe that should be handled by applications like lircd.

[Alec Leamas]

I cannot see anything else then that thsi is a plain bug. Also, the fix looks perfectly sane.

Thanks for reporting, debugging + patch! Fixed in [0ba10e]

EDIT: There have been multiple issues concerning the inital connect - see also [#274].