Then, my bug description becomes a feature request :-)
The man page lircd.conf(5) says: LIRC was designed to collect IR data and save it in a private, compact, yet human readable format with the purpose of being able to re-transmit (or re-recognize) these signals. It was not designed with the goal of providing a well documented and tested configuration file format that could be used e.g., to generate arbitrary IR signals or to convert them to other formats. The configuration file should thus not be considered a public interface to LIRC. So if you are...
Thanks for the fast reply :-) Sorry for the detailed explanation. Let me rephrase it to a bug: I have a remote for a Philips TV. When I press the volume up key on this remote, mode2 shows an RC-6 signal (pulses and spaces) with a payload of 0x0010. Unfortunately, irrecord always creates a config file with flags RC6 and 0x...FFEF for the volume up key. Suspected issue: Receiving RC-6 signals in LIRC does not correctly decode Manchester encoded signals. Receiving in LIRC does not distinguish between...
This is not a ticket in the formal sense -- it does not describe a bug/misbehavior nor a suggested improvement -- so it can be just closed. Rather it is an attempt to understand. I will try to give some (hopefully) helpful suggestions next. Trying to use Lirc to understand IR protocols is not a good idea. May I suggest that you try IrScrutinizer instead? You probably already have a /dev/lirc* device, so in IrScrutinizer select that device as "hardware". Thus you can capture and decode IR signal from...
Inverted RC-6 decoding
Issue with SONY12.lircd.conf and SONY20.lircd.conf — Incorrect bits and pre_data_bits configuration
For SIRC 12-bit, use: bits="12" and pre-bits="12" For SIRC 15-bit, use: bits="15" and pre-bits="15" For SIRC 20-bit, use: bits="20" and pre-bits="20" The lircd.conf files are fine. To me it sounds like there is a bug in the IRplus android app.
TBH, I am in two minds about this. There are a few more bugs I want to fix, and I'd like to do a 0.10.3 release. I hope that will be some time this year. I'll continue to do merge bug fixes but it will be sporadic, just it has been in the past. Not really fast paced so it's fine where it is. On the other, hand gitlab is pretty nice and allows us to things like CI. You can set the project to be moved on sourceforge, so the existing URLs to lirc will just redirect to the new gitlab. We would also need...
@seanyoung: Thanks for your answer. For me, there are more developers on GitHub. You can create a mirror to link GitHub and Gitlab :)
Given the not very active state of the project, and the lack of planned future developments, the smartest thing may be to just keep it as it is. Think of how many links on the Internet that will break. For example lirc.org... But in the end, I think that the ones who are active (Sean?) should decide.
I think we're in agreement that gitlab would be preferable to github. gitlab is open source infrastructure and github is not.
I propose to the team to move on GitHub, it is possible? Thanks in advance.
Making LIRC for RasPi 4, 64bit RaspOS Fails, and ./configuration Options
The issue: First, the Failure: ./doc/index.html is linked to the non-existent: ./doc/html/index.html The correct link seems to be to ./doc/html-source/index.html Has been resolved by commit https://sourceforge.net/p/lirc/git/ci/468ed28dbe1caaa86c052fe5fe02e55f2d1c4ca3/ lircd can only control a single device, so what you are trying to do is impossible. set_transmitters only works for a single IR device with multiple output.
loglevel/debug configuration mess
Fixed in commit https://sourceforge.net/p/lirc/git/ci/34822d2f8cea5e20d42576f57b854e55c30b68a8/
Use loglevel from lirc_options.conf, not debug
lircd sends client infinite repeats on first first few ir events
We need a lot more information to track this down. What is your lircd.conf file, what remote are you using? Your ubuntu version and lircd is rather old so please reopen this issue if you are still having problems with the latest version of lirc.
I am all for moving lirc to gitlab. We can get hosting on https://gitlab.freedesktop.org/ Any objections to moving the repo?
Merge /u/dnsmcbr/lirc/ branch irtoy_macfixes into master
Namespace commonly named functions to allow compilation on macos
Fix dangling symlink
Remove obsolete autoconf macros
Namespace commonly named functions to allow compilation on macos
Thank you very much!
Merge /u/heitbaum/lirc/ branch const into master
retain const qualifier from pointer
retain const qualifier from pointer
RFE: Create XML filters
This is not a feature we intend to implement. Sure, a new format might be great but XML comes with many of its own problems. That's not the answer.
IR receiver refuses to work on a new hardware
Fixed in the kernel years ago
Endless loop when disconnecting irtoy at runtime
lirc assumes that the hardware is there and does not disappear. I don't think doing an exit in drivrer code is correct. The main event poll loop should realise there is nothing it is waiting for and simply exit the loop. Fixing this correctly requires re-writing a lot of code. Patches are welcome but as lirc is really in bug-fix only mode this is more than we are willing to do.
mplay.c control flow error prevents proper device initialization
Fixed by https://sourceforge.net/p/lirc/git/ci/ee807c63ea43642b5292a9f953fe50babfdc1df2/
udev rule breaks operating systems
Fixed in https://sourceforge.net/p/lirc/git/ci/0dd49bacb6ecc6c3dbd72228bdbdfe9c8e577272/
Use /bin/sh rather than /usr/bin/sh
On 1/6/26 2:12 PM, Sean Young wrote: How do I reproduce this issue? Install on any GNU/Linux only using standard /bin/sh. Insert USB devices such as small wi-fi, bluetooth adapters. What distribution do I use and how do install lirc? Slackware GNU/Linux, for example. You can follow your own instructions or use (as root/sudo) SlackBuild package building script (which follows your instructions): http://slackbuilds.org/repository/15.0/system/lirc/ . Afterwards (as root) installpkg /tmp/lirc*z . I recall...
How do I reproduce this issue? What distribution do I use and how do install lirc? I'd like to make sure your fix actually works. This path has been in use way even before usr-merge became a thing, I think.
udev rule breaks operating systems
lircd.service must depend on lircd.socket, otherwise starting the former fails to recreate the socket file
lirc_log: Ensure that log_perror_err(NULL) is handled correctly
plugins/devinput: Report error when unable to read from input device
Remove compiler warnings
Remove compiler warnings
Monual Moncaso IR (mplay) corrupted by merge error
Thank you
Here is my test report. TL;DR: The bugfix makes the plugin work again. However, I had to manually patch some makefiles (problems with include paths, unevaluated variables). All below here is my test log... The local working copy looks as follows: easyvdr@easyVDR:/opt/lirc$ git show commit ee807c63ea43642b5292a9f953fe50babfdc1df2 (HEAD -> testfix, origin/master, origin/HEAD, master) Author: Wolfgang Hauck <womiha@users.sourceforge.net> Date: Sun Aug 3 20:34:55 2025 +0100 Partial revert of commit 00e11da0ea30ce83cb9472bfd01c9f72f589bebc...
Sean, thank you for considering my report. I am going to test the fix. Please give me a week until I get back to you. See you soon, Wolfgang.
I've committed your fix. Please can you make sure the lirc code in git works correctly for you, there are have been other changes too which are not in 0.10.1. Many thanks, Sean
Partial revert of commit 00e11da0ea30ce83cb9472bfd01c9f72f589bebc
Hi Sean, thanks for your quick reaction. The version from 0.10.1 definitely does not work. I am forced to use that version, as it comes with Ubuntu "20.04 focal" from easyVDR 5. A long, long time ago I published a patch in an Ubuntu forum. Somewhen somebody somehow made the patch available to LIRC. I think, the patch first appeared in 0.9.3 (see below). There, it works. So, I am not sure about the merge history. Please bare with me, I am neither familiar with SourceForge nor with the project structure...
Looking at the git history, I can't see a merge error. What I can see is that you are suggesting a revert of commit 00e11da0ea30ce83cb9472bfd01c9f72f589bebc, right? Having said all that the control flow in this function is .. unusual. I can see that in each else if (...) another part is executed of the happy path, and the body is only executed on error; on success we go to the next else if. So that commit does look broken. That make sure that is right, can you say what goes wrong - and what error...
Monual Moncaso IR (mplay) corrupted by merge error
Issue with SONY12.lircd.conf and SONY20.lircd.conf — Incorrect bits and pre_data_bits configuration
Thanks for the 10.2 referral. Sorry for veering off a bit here. I've seen set_transmitters. What I don't understand is how to define multiple devices and drivers in (presumably) lirc_options.conf. I suppose those would be transmitter 1 2, etc. based on the order defined? I may also need to connect to another upstream machine. Here's my conf file. [lircd] nodaemon = False driver = usb_uirt_raw #devinput device = /dev/serial/by-id/usb-FTDI_USB-UIRT-if00-port0 #auto output = /var/run/lirc/lircd pidfile...
Looks like you are running debian oldstable. Trixie has lirc 0.10.2, so if you move to that version you will get lirc 0.10.2. You can set the transmitters with irsend set_transmitters ....
Here's what I see for that library: sudo apt list | grep libsystemd-dev librust-libsystemd-dev/oldstable 0.2.1-2 arm64 librust-libsystemd-dev/oldstable 0.2.1-2 armhf libsystemd-dev/oldstable-security 247.3-7+deb11u6 arm64 libsystemd-dev/oldstable-security 247.3-7+deb11u6 armhf I guess the library's installed. Maybe there's a permissions issue? I need to use sudo a lot. Anyway, as per my 2023-10-14 note above. I got it working. Actually, the IR messages are generated on an upstream ubuntu x86 machine...
Here's what I see for that library: sudo apt list | grep libsystemd-dev librust-libsystemd-dev/oldstable 0.2.1-2 arm64 librust-libsystemd-dev/oldstable 0.2.1-2 armhf libsystemd-dev/oldstable-security 247.3-7+deb11u6 arm64 libsystemd-dev/oldstable-security 247.3-7+deb11u6 armhf I guess the library's installed. Maybe there's a permissions issue? I need to use sudo a lot. Anyway, as per my 2023-10-14 note above. I got it working. Actually, the IR messages are generated on an upstream ubuntu x86 machine...
Here's what I see for that library: sudo apt list | grep libsystemd-dev librust-libsystemd-dev/oldstable 0.2.1-2 arm64 librust-libsystemd-dev/oldstable 0.2.1-2 armhf libsystemd-dev/oldstable-security 247.3-7+deb11u6 arm64 libsystemd-dev/oldstable-security 247.3-7+deb11u6 armhf I guess the library's installed. Maybe there's a permissions issue? I need to use sudo a lot. Anyway, as per my 2023-10-14 note above. I got it working. Actually, the IR messages are generated on an upstream ubuntu x86 machine...
Here's what I see for that library: sudo apt list | grep libsystemd-dev librust-libsystemd-dev/oldstable 0.2.1-2 arm64 librust-libsystemd-dev/oldstable 0.2.1-2 armhf libsystemd-dev/oldstable-security 247.3-7+deb11u6 arm64 libsystemd-dev/oldstable-security 247.3-7+deb11u6 armhf I guess the library's installed. Maybe there's a permissions issue? I need to use sudo a lot. Anyway, as per my 2023-10-14 note above. I got it working. Actually, the IR messages are generated on an upstream ubuntu x86 machine...
Here's what I see for that library: sudo apt list | grep libsystemd-dev librust-libsystemd-dev/oldstable 0.2.1-2 arm64 librust-libsystemd-dev/oldstable 0.2.1-2 armhf libsystemd-dev/oldstable-security 247.3-7+deb11u6 arm64 libsystemd-dev/oldstable-security 247.3-7+deb11u6 armhf I guess the library's installed. Maybe there's a permissions issue? I need to use sudo a lot. Anyway, as per my 2023-10-14 note above. I got it working. Actually, the IR messages are generated on an upstream ubuntu x86 machine...
Actually it turns out, receive did not implement this. I've fixed the receive side in commit 1dc29314729f193b148d10f4ac575582d303ab24
Receive does not parse post without post_data and pre without pre_data
'pre' and 'post' in *.conf is ignored if no 'pre_data', 'post_data'
Fixed in commit 52550a56db638d521ddcb5ba6bc20389acf5f178
Fix typo
Transmit pre when no pre_data is present, and post with no post_data
Actually, I think the code is buggy. For receive, the pre is parsed if there are no pre_bits, same for post without any post bits. So, transmit is buggy compared to receive. This should be fixed.
10.1: fails to build sometimes with parallel make
I've tested this and fixing this doesn't break any lircd.conf file I can have. I think it makes sense to fix it - it's just very unexpected, I think.
I've tested this and fixing this doesn't break and lircd.conf file I can have. I think it makes sense to fix it - it's just very unexpected, I think.
Looks like you don't have systemd development libraries installed - lircd should send ready notifications to systemd, but only if HAVE_SYSTEMD is set by ./configure Do you have the libsystemd-dev package installed and what is the output of ./configure?
I understand that usually a dependency is missing when parallel make fails. However, I don't understand how that helps with resolving this ticket. I can't reproduce the problem so I can't fix it.
I do not care for Lirc anymore, but I do have extensive experience with parallel make. I have learned that "parallel make fails" always (?) means that the dependencies are incomplete. Complete the dependencies and parallel make will succed.
I can't reproduce this problem. Is this still an issue?
audio_alsa: Fix memory leak
Forgetting to free the allocated memory of `snd_device_name_get_hint()` can cause memory leak
Fixed in commit aaf355e02b13c717e077f4b4efad2f86e5880276
Bug in SendCommand in client.py
Fix in commit ae278ac63b6ec4c322752ca6631645465a6c41e9
default driver "asleep"
I can't reproduce it, no reports since 2019 so close this issue. Please comment/reopen if there are still issues.
python: Fix type hint
lirc is not really suitable for controlling an AC. You could try cir or IrpTransmogrifier.
irsed to use raw codes to support AC units
lirc is not really suitable for controlling an AC. You could try cir or IrpTransmogrifier.
Driver `default' not found or not loadable
No update in two years, closing
lrcrcd spins on poll with 0 duration timeout
This problem does not exist in the current tree. I guess this ticket just refers to out of date code.
support passing MODINFO to configure
Merged
ubuntu builds ignore `--with-systemdsystemunitdir`
Similar fix merged
doxyfile: Don't include full pathname
Patch configure.ac to support passing MODINFO.