Activity for LIRC
-
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
-
Ximin Luo posted a comment on ticket #383
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
-
Jim Kaiser posted a comment on ticket #315
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
-
Sean Young posted a comment on ticket #310
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.
-
lib: irrecord: Fix free memory write
-
Please don't use the debian or ubuntu branch, they are out of date. Just use the master branch and report any issues you have on that branch.
-
xmode2: Incorrect unit for -t option.
-
xmode2: No IR data shown after wrap.
-
xmode2: Error message "?: too many arguments".
-
xmode2: Incorrect unit for -t option.
-
xmode2: Show correct unit for -t option.
-
xmode2: Don't use progname before it is set up.
-
xmode2: Fix window wrap.
-
xmode2: Fix typo in could't
-
Thomas Betker created ticket #381
xmode2: Incorrect unit for -t option.
-
xmode2: Error message "?: too many arguments".
-
xmode2: No IR data shown after wrap.
-
I've tried to reproduce this again. I do not have a pi zero, I have pi model 3b. I have used the 32 bit raspbian (11 bullseye) though (clean image). Some observations. 1. For a git clean use -fdx, you're missing the d which removes directories 2. Rather than autoreconf --install run ./autoget.sh. 3. How have you configured the library path to include /usr/local/lib? 4. Can you provide the entire build output please, so all the output from configure, make, and all the commands. Thanks. Sean
-
David Röthlisberger created merge request #52 on Git
XMP: Fix repeats
-
Jeff LaBundy created ticket #378
lircd bypass device does not copy properties or axis limits
-
Lee Ballard posted a comment on ticket #376
Still seeing the issue when I change plugindir to /usr/local/lib/lirc/plugins. These are the build steps I use: tmux git clean -xf autoreconf --install mkdir _build cd _build ../configure make sudo make install sudo lirc-postinstall ./python-pkg/lirc/config.py It's specific to the "default" driver and it may be specific to ARM 32 bit or Pi 1B+. Have you tried to reproduce on Pi Zero? pi@raspberrypi:/usr/local/lib/lirc/plugins $ sudo /usr/local/sbin/lircd --nodaemon -U /usr/local/lib/lirc/plugins...
-
JanB posted a comment on ticket #377
On note When trying this; (note the debin) git clone --recursive -b debian git://git.code.sf.net/p/lirc/git lirc-pkg while make i also get this error; dpkg-source: error: LC_ALL=C patch -t -F 0 -N -p1 -u -V never -E -b -B .pc/0002-lib-curl_poll.h-Ensure-build-on-unconfiguredclients.patch/ --reject-file=- < lirc-0.9.4d/debian/patches/0002-lib-curl_poll.h-Ensure-build-on-unconfiguredclients.patch subprocess returned exit status 1 patching file lib/curl_poll.h Reversed (or previously applied) patch...
-
Hi and thanks for answering, apt install -y python3-yaml pypi2deb doxygen kmod make gcc g++ binutils autoconf automake libtool pkg-config xsltproc python3 git git clone --recursive -b ubuntu git://git.code.sf.net/p/lirc/git lirc-pkg cd lirc-pkg make After some error abouut unmet dependendecies ; sudo apt install -y libudev-dev dh-systemd libusb-1.0-0-dev libx11-dev man2html-base libftdi1-dev libftdi-dev libsystemd-dev make ---and there it stops while trying to sign
-
I have not built debian packages before, but your error suggests that you are signing as Alex Leamas without his private key, which is of course impossible. Can you give the exact steps to reproduce this problem. What command line are you using to build the package?
-
I've tried to reproduce this but it works fine for me. The problem is that in your lirc_options.conf you have: plugindir = /usr/local/lib/arm-linux-gnueabihf/lirc/plugins That should be plugindir = /usr/local/lib/lirc/plugins Unless you have configured your build differently. If this does not help please let us know your exact ./configure command line and following steps. I have no idea where /usr/local/lib/arm-linux-gnueabihf/lirc/plugins comes from.
-
Building lirc for rasperry pi 4
-
Driver `default' not found or not loadable
-
Driver `default' not found or not loadable
-
Remove pointless typedef lirc_t to int
-
That is clear.
-
Christoph Bartelmus posted a comment on merge request #51
Please don't remove the typedef. It reminds you that a variable contains timing information and you need to use the given macros to extract the microseconds value. Using int or int32_t won't make much difference in real-world scenarios. There's no danger that this code is used on 16-bit platforms.
-
Rather than int, we could use int32_t. Typedefs for integer types does not really give you anything in C, just another name for the same primitive. They're almost completely banned in the linux kernel, see https://www.kernel.org/doc/html/latest/process/coding-style.html#typedefs I don't feel particularly strongly about this, happy to drop.
-
Bengt Martensson posted a comment on merge request #51
When I looked into the Lirc sources some years ago, I became the impression that lirc_t (what a criminally bad name!) was intended to represent a duration, the amount in micro seconds in the lower bits, with some information (flash or gap, timeout, don't recall) coded into some on the upper bits. There are even some macros defined for extracting. (For me, it feels natural to have used a class for this, but ...). And whatever you do, do no use non-portable "int"!
-
Remove pointless typedef lirc_t to int
-
Transmit second code rather than repeat header
-
irsend / lircd hang when using repeats
-
irsend / lircd hang when using repeats
-
https://sourceforge.net/p/lirc/git/merge-requests/50/ merged, should be fixed
-
Two questions
-
We have made a new release recently. This has been discussed under https://sourceforge.net/p/lirc/tickets/364/
-
lirc_init does not close socket if connect fails
-
Do not leak filedescriptor on connect failure
-
fixed in commit 392acc46dfa26a820d3021badf438335a77f6179
-
lirc installation on RaspBerry PI
-
Hello, When you download the tarball from https://sourceforge.net/projects/lirc/files/LIRC/ you are NOT downloading the git version. There is no reason to run ./autogen.sh. You can use the ./configure script which is provided, as the documentation makes clear.
-
lircd.conf: Line comments starting with whitespace should be valid
-
I've found the remote here: https://i.ebayimg.com/images/g/Q80AAOSwMf1Znu7N/s-l640.jpg The button clearly says # with the text Search above it. So, the intent was not to comment out this button, but to call it #/search. If we parsed lines with leading whitespace starting with # as comments, then there would be no way to call buttons #.
-
This breaks compatibility. For example https://sourceforge.net/p/lirc-remotes/code/ci/master/tree/remotes/expressvu/301_501_3100_5100_58xx_59xx.lircd.conf has a button called #/search. There are a few more examples of this. If we change the parser to accept leading whitespace before # for comments, then this file will be parsed differently. For all those examples, I don't know if the intent was to comment out /search (also in the other examples) or the intent was to call it #/search. Either way I...
-
Python bindings broken because config.py not installed
-
Fix merged
-
systemd support: Notify systemd on successful startup
-
plugins: zotac: fix poll timeout
-
plugin zotac broken
-
Fixed merged.
-
--connect/-c: argumetn parsing error.
-
lirc client with Raspberry Pi gpio kernel driver
-
A similar patch has been applied.
-
SONY remote control with gpio-ir-recv using LIRC
-
Since this ticket is almost four years old, please let us know if this still an issue and we can reopen.
-
It looks like gpio-ir-recv is not configured correctly. The Sony protocol should start with a 2400 pulse and 600 space, yet you get the reverse (2400 space and 600 pulse). I suspect that the pin should be inverted.
-
pthread_t is an opaque type, therefore typecast it to avoid warnings on musl
-
Alternative fix merged, see commit f7dfb99e657e0bd8cec891d0ac397f12a01405bb
-
pthread_t is pointer type on musl
-
Not compatible with PyYAML 6.0
-
Should be fixed
-
send once on conf with min repeat is failing because it thinks it is repeating
-
https://sourceforge.net/p/lirc/git/merge-requests/50/ merged, should be fixed
-
Use pyyaml safe_load instead of load
-
Alternative fix has been merged. Let us know if there is still is a problem
-
Remove unused files
-
Update to latest version from https://www.lirc.org/
-
lirc.org: Remove non-free advertising.
-
Constant length transmit should take pending space into account
-
Fix transmit of pcmak.lircd.conf
-
Add support for FTDI FT232H
-
Add support for FTDI FT232H
-
Cristiano De Alti modified a comment on merge request #40
Wow, only four years ;-) In my case this applies to an FTDI C232HM-EDHSL-0 USB to MPSSE Serial cable 5.0V - 0.5m that my company purchased from a reputable distributor in Italy. I still have it with the original FTDI branded bag.
-
Wow, only four years ;-) In my case this applies to an FTDI C232HM-EDHSL-0 cable that my company purchased from a reputable distributor in Italy.
-
The built in driver for Irtoy / Irdroid in LIRC makes the modules to lock from time to time, which require to replug the Irdroy/Irdroid and restart LIRC
-
Fixed in 0.10.2
-
New release?
-
0.10.2 was released recently
-
The nabble link doesn't work but this appears to be the same thread: http://developer.intra2net.com/mailarchive/html/libftdi/2016/msg00001.html (archive: https://web.archive.org/web/20180115232835/http://developer.intra2net.com/mailarchive/html/libftdi/2016/msg00001.html ) There's an unresolved question in that thread about whether that was a counterfeit chip, but I could easily believe that a genuine FTDI chip has weird undocumented clock behaviour in bit-bang mode (see my experience with FT232R:...
-
Upstream three patches needed to support recent linux kernels
-
This patch: 1. Fix timings for gpio-ir We already have similar fixes for this. This patch is obsolete. Please test again against latest master. These two are merged already: 4. Make devinput.c Y2038 safe and suport never 32-bit kernels 5. lib/lirc_log.c: Don't use broken LOG_CONS syslog flag
-
migrate struct input_event.time to .input_event_sec and .input_event_usec
-
migrate struct input_event.time to .input_event_sec and .input_event_usec
-
Partially revert 0ab24de56 to fix python-pkg (#339)
1 >