when using lirc-0.7.0_pre7-r1 the min_repeat option in lircd.conf no longer works. It worked fine in lirc-0.7.0_pre7. The patch added in -r1 is breaking this, which is not good. Basically it means any remote which sends infrared signals multiple times per a single button press (numerous sony remotes, pioneer remotes, I'm sure there's tons more) now actually counts as multiple presses in lirc. This is not good at all as it basically means when I'm using an lirc application a single press is counting as 2, or more.
i have notified the original patch author and will dig into the patch asap. Jordan , can you give me some examples of your config file, which remote/driver you use, kernel version, etc? the more information the better. thanks.
I use lirc_serial with an serial device that I built. Here's emerge info: Portage 2.0.51_rc1 (default-x86-2004.2, gcc-3.4.1, glibc-2.3.4.20040808-r0, 2.6.8-ck7 i686) ================================================================= System uname: 2.6.8-ck7 i686 Intel(R) Pentium(R) 4 CPU 2.40GHz Gentoo Base System version 1.5.3 Autoconf: sys-devel/autoconf-2.59-r4 Automake: sys-devel/automake-1.8.5-r1 Binutils: sys-devel/binutils-2.15.90.0.1.1-r3 Headers: sys-kernel/linux-headers-2.4.22 Libtools: sys-devel/libtool-1.5.2-r5 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CFLAGS="-march=pentium4 -O3 -pipe" CHOST="i686-pc-linux-gnu" COMPILER="" CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3.3/share/config:/usr/kde/3.3/env:/usr/kde/3.3/shutdown /usr/kde/3/share/config /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-march=pentium4 -O3 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs ccache sandbox" GENTOO_MIRRORS="http://open-systems.ufl.edu/mirrors/gentoo http://gentoo.oregonstate.edu http://distro.ibiblio.org/pub/Linux/distributions/gentoo" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.us.gentoo.org/gentoo-portage" USE="3dnow X aalib acpi alsa apm avi bitmap-fonts cdr crypt cups dvd encode esd ffmpeg foomaticdb gdbm gif gimpprint gpm gstreamer gtk gtk2 guile java jpeg ldap libg++ libwww lirc mad mikmod mmx mmx2 mozilla moznocompose moznoirc moznomail mpeg ncurses network nls offensive oggvorbis opengl oss pam pdflib perl png ppds python quicktime readline rtc sdl slang spell sse sse2 ssl tcltk tcpd truetype v4l v4l2 x86 xml2 xmms xprint xv zlib" And here's a piece of my lircd.conf: begin remote name 15-2117 bits 12 flags SPACE_ENC|CONST_LENGTH eps 30 aeps 100 header 2448 547 one 1256 530 zero 669 530 gap 45501 min_repeat 3 toggle_bit 0 begin codes POWER 0x0000000000000F00 GUIDE 0x0000000000000280
I got this from the original patch author... so it looks like currently changing the ebuild to only apply the patch when streamzap is the selected driver is the way to fix this, for now, until someone starts hacking on it to fix it. > From: sailor@sailorfrag.net > > Hey > > It's very likely caused by the change in daemons/receive.c that changes > the select() timeout. That's the reason that my patch never made it into > the stock lirc -- I never found a good way around it (without adding > buffering in the kernel that I didn't have time to implement & debug) and > I was told on the mailing list that it would probably break other drivers. > > :-( > > -Adrian
I agree with you there, there's no reason to break this for everyone, just for the people who need it, and in their case it's probably not broken....
i fixed the ebuild to only apply the patch when use="streamzap" is given