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.
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
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
XMP: Fix repeats
lircd bypass device does not copy properties or axis limits
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...
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.
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.
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
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)