#70 LIRC defaulting to ttyACM8 on errors

[Forage]

Hi,

In different scenario's LIRC will try connecting to ttyACM1 to ttyACM8
when an attempt to send something fails on one of the sockets for
whatever reason. If ttyACM1 fails, it will try ttyACM2, etc, up to ttyACM8.

Each subsequent attempt to do the same will result in LIRC only trying
ttyACM8 again. No attempt is made to try the initial ttyACM1 again.

I'm launching lircd with "--device=/dev/ttyACM1". Why does it even
bother trying the other sockets if I specifically tell it which one to use?
If trying the other sockets is desired behaviour, it should at least
start at the initial socket again on a subsequent attempt.

Attached you'll find a log file illustrating the behaviour.

Best regards,

Age Bosma

[Alec Leamas]

This is actually the driver doing it's auto-detect code. I presume you
are using the irtoy driver (?).

I share your view that trying other devices when user specifies a
specific device is a bug. It's not clear that this can be fixed in the
release cycle, though.

OTOH, auto-detection is a major feature in most scenarios.

[Alec Leamas]

Here is an experimental patch. It supports wildcard device names and the special name 'auto'. I really need some feedback, havn't any irtoy hw.

[Forage]

I've got a different device (USB CEC) connected to ttyACM0. The irtoy is connected to ttyACM1.

--device=/dev/ttyACM1 works as expected. It does not try to probe any other devices and uses the one specified.

With --device=auto Lirc finds a device (ttyACM0), determines it not to be a irtoy, stops trying a different device while ttyACM1 is present and tries to send to ttyACM0 anyway.
The same goes for /dev/ttyACM? and /dev/ttyACM*.

Based on this it should be the following instead:
- ttyACM0 not an irtoy? Try the following device (ttyACM1)
- No irtoy device found? Don't try to send to just a device.

I would have expected lircd with --device=auto to give me some debug entries about it going to probe for a suitable device and possibly which one it is going to be after it found it. Both are not the case until irsend it used.

[Alec Leamas]

so... seems that your secret alias is uncloaked :)

Stay tuned, trying to make en enhanced patch.

[Alec Leamas]

New attempt. Only accepts "auto" or a fixed filename.

[Forage]

Great, much better now.

--device=/dev/ttyACM1 works as expected. It does not try to probe any other devices and uses the one specified.

--device=/dev/ttyACM* or --device=/dev/ttyACM? fails. I can a "lircd-0.9.2pre1[468]: Failed to initialize hardware" as expected. It doesn't terminate lircd yet.

--device=auto nicely detects the device, trying all possible /dev/ttyACM? devices.

Attached is a log of the last situation, in case you are interested.
You can see it working. The log isn't as clean as could be though, but that's me being nit-picky:
- "irtoy_getversion" and "please make sure..." doesn't apply when there's no irtoy device connected. No need for that info if there isn't a irtoy device.
- "readlink() failed for ..." and "irtoy: could not create..." for all the other possible devices. If having a check for the existence of such a file first than it can just state either nothing or a "not checking ..." instead of triggering irtoy specific errors.

[Alec Leamas]

OK, I think we stop there. That ttyACM* does not work is by design (this time). "auto" should be sufficient.

The debug logs is something I can live with. They give a quite comprehensive view of the probing. Anyone using -Ddebug should IMHO be prepared to all sorts of noise. perhaps I lower the readlink checks to trace level, though.

Thanks for testing! The untested case is two or more irtoys which should give a warning. But I figure you only have one...

EDIT: Actually, the debug log is an error log. The log output from init_device is LIRC_ERROR, so it will bite an end user. We don't want that.

Revised patch:

[Forage]

Cool.

I wasn't implying that ttyACM* should have worked, I only reported my findings. Since I want to use the auto probing anyway I only care about lirc not doing it when specifying a device ;-)

Indeed, I only got the one device. One is giving me enough trouble already so I won't be getting me a second one ;-P

[Forage]

Here's a new log with device=auto btw.
Both auto and a specific device are functioning.

I'm not too fond of the double lock file list when using auto, but I guess you can't have it all.

[Alec Leamas]

Fix merged as [d9a03f]

[Alec Leamas]

Fix released in 0.9.2pre3, closing.