Issue with IrToy and Linux

[bengtmartensson]

The Linux kernel 5.9 radically changed the way IrToy (and its copy IrDroid) is supported under Linux.

Short version: For kernel version >= 5.9 the IrToy hardware does not work. Instead, use the /dev/lirc hardware. However, frequency measurement does not work there.

Long version: see the HarcHardware project.

[pjotrek-b]

I understand.

However, I have the situation, where I'm using 2 irToys (yes! I still got some 😎) - on 2 different systems (both Xubuntu 20.04.6) - and one of them uses /dev/ttyACM0, (kernel v5.4) and the other one /dev/lirc0 (kernel drivers v5.15).

I cannot use the same irScrutinizer version (2.3.0 vs 2.4.1).
One remote (nec protocol) works perfectly on 2.4.1, but undecodable-signal on 2.3.0.

Is there any chance to have irToy support kept-alive in current irS versions?
If I'm not mistaken, they should be able to co-exist, since only 1 hardware option could be chosen, depending on the underlying driver/device situation...

Thank you! 😄

[bengtmartensson]

HarcHardware (which is a component project of IrScrutinizer) still supports the IrToy using the /dev/ttyACM0 interface. (Since some time, the binary distro of IrScrutinizer installs a command harchardware; you can also call the appimage using the name harchardware (for example using a link).) For example, you can use the command

harchardware --irtoy  receive --decode

Background: IrScrutinizer is a program for analysis and generation of IrSignals, not daily use. Thus, support of the largest possible number of hardware is not really a priority. IrScrutinizer is not Homeassistant. Unfortunately, IrScrutinizer does not have a nice plugin mechanism for adding new hardware.

Main reason for removing the native IrToy support is that it would be very hard to support. Actually, as I see it, the main problem with the current situation is that Windows users have no way to use IrToy. As I said, HarcHardware still contains the support, and the GUI support is "resting" in Git, and can be re-instated with a relatively low effort. @seanyoung mentions in his first post to bengtmartensson/HarcHardware#25 that the old method may come back, but to my knowledge, this has not (yet?) happened.

[seanyoung]

I haven't come up with an acceptable design for attaching and detaching kernel drivers to ttys yet. This is a hard problem, and it's been around since a long time. I don't expect this to land any time soon, it's more of a wish for now. tty drivers are only for old hardware. You can rebuild your v5.15 kernel without CONFIG_IR_TOY and you will get an /dev/ttyACM0 interface like with v5.4.

I think the most interesting approach to this is figuring out the problem with the irtoy driver (or the way it is used). If we can identify that then we can get a patch added to the stable tree.

What does the recording of the nec remote look like, compared to what you get with kernel v5.4?

[bengtmartensson]

@seanyoung : Thank you for the answer; I have been planning to ask that question for quite some time.

I think the most interesting approach to this is figuring out the problem with the irtoy driver (or the way it is used). If we can identify that then we can get a patch added to the stable tree.

Sorry, I am lost here. The IrToy uses a serial-over-USB terminal connection, which is not really state of the art. (For example, Java does not contain an official serial package, although there are several inofficial ones.) But what do you mean by "the problem with the irtoy driver"?

[pjotrek-b]

@bengtmartensson : Thanks for the insider tip with "harchardware"!

And I totally understand I'm not trying to use irScrutinizer for conveniently controlling my favorite IR controlled device from the sofa 😁 - and I totally get that irS is a super-professional tool for "all-things-IR-codes".

I'm using it (in combination with LIRC) in the context of digital-long-term-preservation: We need to work with old gear (eg VHS), where the original remote was lost in time, or we debug if-and-how a remote we still have (found) works, etc.

Thank you (and LIRC) soooo much for all of your work, and all the documentation and insights on IR remote-controls in general.

[pjotrek-b]

@seanyoung: Right now, the /dev/lirc0 kernel-driver (5.15) works fine with the remotes I have here (including NEC-protocol).

Don't bother about my use case at all!

I simply wanted to know more information about how-and-why irToy support was removed in irScrutinizer, since I'm planning to keep using IR on Linux for a long time. And I've got my answers - and a working setup.
Thank you!

[bengtmartensson]

@pjotrek-b : I am happy that you are happy. Nice to hear about your application. Here are some thoughts:

• Please check out http://www.harctoolbox.org/arduino_nano.html for an alternative to irtoy.
• My advice is to stay clear of Lirc. About 25 years old and not really developend any more, very bad design (even when new). (Yes, I have read your post in the IrToy forum -- I am "barf" there.) Possible alternatives may be Linux kernel decoding/encoding.
• Check out my projects DevSlashLirc and JGirs; maybe it can be of interest.

[pjotrek-b]

Oh, I'd love to build your Arduino-Nano hardware! 🤩
Especially, since I'm looking for an IR setup (soft+hardware) that may (finally) stay stable for years to come.

Very sad to hear your advice on Lirc... sigh
(I've been using it since 2006. I was the one who submitted the 5x5 hole PCB layout image back then 😁)

By "Linux decoding/encoding" as alternative to Lirc, you mean something like what ir-keytable seems to be using as backend?

[pjotrek-b]

btw: Your JGirs link above has a typo (".html" at the end).
I presume you mean: https://github.com/bengtmartensson/JGirs

[bengtmartensson]

Oh, I'd love to build your Arduino-Nano hardware! 🤩

Looking forward to you feedback. IMHO, my IR library Infrared4Arduino has a few advantages in comparison to the widely spread IRremote.

Very sad to hear your advice on Lirc... sigh (I've been using it since 2006. I was the one who submitted the 5x5 hole PCB layout image back then 😁)

I have submitted a number of PR and suggestions, see the sourceforge repository and the mailing list. So I think I am entitled to say "Lirc sucks"... But feel free to ignore it if you want...

By "Linux decoding/encoding" as alternative to Lirc, you mean something like what ir-keytable seems to be using as backend?

This may be a good place to start. But I am not an expert here, Sean is.

[pjotrek-b]

Thanks! 😄