Activity for LIRC
-
David Chmelik created ticket #388
udev rule breaks operating systems
-
Ximin Luo created merge request #54 on Git
lircd.service must depend on lircd.socket, otherwise starting the former fails to recreate the socket file
-
Sean Young committed [e3c8fa] on Git
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
-
womiha posted a comment on ticket #387
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 <[email protected]> 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
-
Bruno Magenta Joga created ticket #386
Issue with SONY12.lircd.conf and SONY20.lircd.conf — Incorrect bits and pre_data_bits configuration
-
Jim Kaiser posted a comment on ticket #382
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.
-
Bengt Martensson posted a comment on ticket #334
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.
-
Check for /dev/input using AC_CHECK_FILE.
-
This hack is not needed anymore with newer systemd
-
tools: Do not embed build date and kernel version in various files.
-
Python 3.7 is required now
-
asyncio.get_event_loop() can return an error in python 3.14
-
Skipped the last commit but all others have been applied. See https://sourceforge.net/p/lirc/mailman/lirc-list/thread/aEXwdkZ3FywEG-P6%40gofer.mess.org/
-
Correct inverted behavior of irtext2udp, with regard to pulses/spaces
-
Clarify and correct documentation of the UDP protocol
-
Revert "udp: High bit set in udp protocol means pulse"
-
Paul Fox posted a comment on ticket #370
Some conversation would have been useful before closing this. The fix is incorrect, in that it changes lirc's udp device protocol, which has been the same for decades. Anyone using this protocol to talk to lirc, other than with irtext2udp, will see their systems fail when lirc is next released.
-
Building lirc for rasperry pi 4
-
lircd stopped recognizing codes
-
downstream bug is resolved
-
irtext2udp broken for large pulse durations
-
dup of 370
-
UDP protocol: bugs in documentation, and irtext2udp
-
udp: High bit set in udp protocol means pulse
-
irtext2udp needs to send the entire protocol message
-
A simpler solution is to fix plugins/udp.c I've applied your first patch and a fix to plugins/udp.c.
-
Zibri posted a comment on ticket #345
I see the same problem. any news?
-
Reno Dakota created ticket #385
ubuntu builds ignore `--with-systemdsystemunitdir`
-
Clean up uname process with pclose
-
The ' '.join(keys) indicates that it is a list. Also, the parameter is called keys and not key. Also when you look at lirctool.py, it's a clearly a list there. I think the documentation string and type hint is wrong.
-
Fix default.so plugin’s undefined symbol: major
-
time.clock() error building python-pkg/lirc/client.py
-
Already fixed in master and 0.10.2
-
Milan Vit modified a comment on merge request #53
It is Friday, my dudes! … nah, this only really works with Wednesday, doesn’t it…
-
It is Friday my dudes! … nah, this only really works with Wednesday, doesn’t it…
-
Happy Friday! Any chance we can move forward with this merge request? 🙏
-
Good morning! It’s Friday again 🙏
-
Good morning! A weekly bump 🙏
-
Good morning! Apologies for the bump, but is there something I could do in order to get this merged and released?
-
Fix default.so plugin’s undefined symbol: major
-
BTW, if I don't use the hack, I get buffer overflow while generating IR pattern. From ftdi.c: static int tx_baud_rate = 65536; [..] [..] The FT232R also becomes unusable if you set the * tx_baud_rate to values other than 65536. Even if the hack were not required, these two bits of code seem very weird. What real world device has a baud rate of exactly 65536? My device at least certainly works with txbaud=15200 and it is not "unusable" contrary to the comment. The Linux gpio_ir_tx driver defaults...
-
FTDI plugin has unobvious configuration requirement
-
FTDI plugin requires txbaud hack
-
I see that the Milestone for this fix is Future. However, the changed daemons/lircd.cpp file may be found here. I downloaded and replaced the copy in the 0.10.2 distribution tarball with this one and irsend no longer hangs when using --count=2 (or greater). Thank you for the fix!
-
After changing the Type=notice to Type=simple in lircd.service, the daemon starts and stays running using sudo systemctl start lircd. irsend --count=4 xxx yyy works. This was based on using ./configure --bindir=/bin --sbindir=/usr/sbin --libexecdir=/usr/libexec --sysconfdir=/etc --libdir=/var/lib --datarootdir=/usr/share on a RasPi 4 running Raspberry OS. Now on to trying the installation on an x86 box running ubuntu.
-
When starting lircd.service with systemctl it always adds the --nodaemon flag and times out after about 2 minutes. (See the systemctl status output just above). It then deletes the /var/run/lirc directory. The socket is up and stable. (I removed the --runstatedir=/var/run directive from ./configure since run is automatically appended to --localstatedir=/var) lirc_options.conf has nodaemon = False but that appears to be ignored. My other items like device and driver and effective_user all are observed....
-
When starting lircd with systemctl it always adds the --nodaemon flag and times out after about 2 minutes. (See the systemctl status output just above). It then deletes the /var/run/lirc directory. The socket is up and stable. lirc_options.conf has nodaemon = False but that appears to be ignored. My other items like device and driver and effective_user all are observed. Once I made /run writable by other and created the lirc directory, I can run lircd from the command line as a regular user. I'm...
-
Making LIRC for RasPi 4, 64bit RaspOS Fails, and ./configuration Options
-
The bug talks about /usr/src/iguanair/software/lirc-drv-iguanair/iguanair.c which is part of the igaunair software, not lirc. This is not something we maintain: https://github.com/iguanaworks/iguanair/blob/master/software/lirc-drv-iguanair/iguanair.c Having said that I don't really follow what the problem is. I cannot find log level in that file.
1 >
