On Friday 13 September 2013, Rob Owens wrote:
> On Wed, Sep 11, 2013 at 12:38 PM, Rob Owens <robowens13@...> wrote:
> > Does anybody have an idea what could cause a working lircd.conf to stop
> > working upon upgrade from 0.8.3 to 0.9.0?
> > My IR blaster's LED is lighting, but the dish receiver is not responding.
> > I assume that means the IR codes are somehow being sent differently in
> > 0.9.0 than they were in 0.8.3.
> While I am still curious about why my lircd.conf file worked on 0.8.3 but
> not 0.9.0, I have created a new lircd.conf (using irrecord) which is giving
With my distribution maintainer hat, this news is quite relieving, as
this proves that this interpretation of IR signals changed in the
upstream code, rather than being an unintended breakage caused by the
> me better results. ...Better in that it actually changes the channels some
> of the time. When I'm satisfied that I have a good lircd.conf, I will post
While not intended, changes to the driver might change which IR codes
lirc receives (this happened with pinsys several years ago, I haven't
noticed this with lirc_serial, but I can only test this as plain
receiver). Debugging, or rather bisecting the problem, to identify the
problematic commit will be pretty hard in this case, as not only the
kernel modules needs considerable changes to compile against both
involved kernels, but also because the ABI between lirc kernel modules
and lirc userspace changed when lirc was merged into staging.
So if you can help it, the more pragmatic approach would be to generate
a new configuration file and forget about the problem ;)