[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: LIRC 0.9 backport to go with backported Linux kernel?

On Mon, 2012-04-16 at 03:47 +0200, Stefan Lippers-Hollmann wrote:
> Hi
> [ sorry to break the threading, but I'm not subscribed to 
>   debian-backports@l.d.o and pkg-lirc-maint@l.d.o hasn't copied this 
>   message yet or it's still stuck in moderation (I can't change that, 
>   please keep me CC'ed, to avoid this) ]

OK, will do.

> On Sun, 15 Apr 2012 23:39:03 +0100, Ben Hutchings wrote
> > On Sun, 2012-04-15 at 23:47 +0200, Stefan Lippers-Hollmann wrote:
> > > On Sunday 15 April 2012, Josh Triplett wrote:
> […]
> > > > Would you consider providing a backport of LIRC 0.9 for squeeze?
> > > 
> > > Due to numerous infratructural changes, in lirc, the upstream kernel,
> > > surrounding packages and lirc packaging, I don't consider lirc to be a
> > > candidate for backporting to squeeze.
> > > - lirc >= 0.9.0~ can only work with kernel >= 2.6.37, there is no 
> > >   compatibility with squeeze's 2.6.32 - even trying to reintroduce a 
> > >   (totally untested) lirc-modules-source would break several devices 
> > >   supported in plain squeeze or plain wheezy+
> > 
> > This is terrible.  Is it really not feasible to do a run-time check?  It
> > should generally be possible for stable userland to work with the kernel
> > from stable, testing or unstable, as there is otherwise no good way to
> > do upgrades.
> This is the fate of out-of-tree modules…

I actually thought lirc was in staging in 2.6.32, but now I see it
wasn't in-tree at all.

> > > - several lirc hardware drivers changed module names and userspace
> > >   API (from traditional lirc, over IR_CORE to RC_CORE - thereby 
> > >   exposing a new dev/input API, instead of -or in addition to- the 
> > >   classic lirc API), when merged into the mainline kernel; this also 
> > >   affects the device nodes exposed to userspace (/dev/lirc0 --> 
> > >   /dev/input/event%d <-- unstable device node)
> > [...]
> > 
> > But this should be covered by liblircclient, shouldn't it?  Why would
> > this matter to applications?
> […]
> Neither applications nor liblircclient care, but it affects the 
> configuration (/etc/lirc/hardware.conf or /etc/default/lirc (current 
> svn HEAD)), so in order to switch between kernels <2.6.37 (or <2.6.36
> for 32 bit architectures) you have to adapt lirc's dæmon configuration.
> "normal" default lircd.conf like
> /usr/share/lirc/remotes/devinput/lircd.conf.devinput
> …and to ensure a stable input device, you also need an additional udev 
> rule like:
> KERNEL=="event*",ATTRS{name}=="i2c IR (Hauppauge)",SYMLINK="input/irremote0"

Now that's good.

But I take it the old drivers don't generate uevents like this?

> Neither the deprecated (actually removed from current lirc versions) 
> lirc_i2c, nor ir-kbd-i2c can be autoprobed and there are no stable 
> by-path or by-id mappings.

That's surprising; the IR device should be a child of the I2C adapter
which would in turn be a child of... some platform device?  But it will
vary between systems, if that's what you mean.

> Applications don't care, liblircclient0 abstracts that transparently, 
> but liblircclient0 requires a properly configured "lirc" package 
> (lircd), in order to access the socket - and this configuration must be
> different between squeeze and wheezy.
> As you see, most of these devices require incompatible configuration 
> changes between squeeze and wheezy, and further might be required to 
> staging modules getting ported to RC_CORE, non-lirc/ non-RC_CORE kernel
> modules being ported from plain event devices to RC_CORE, etc.
> For kernel << 2.6.37, lirc <= 0.8.7 is required
> For kernel >= 2.6.37, we need lirc 0.9~
> liblircclient0 abstracts this nicely from applications using it, but 
> lircd often -but not always- needs to be configured completely 
> differently.

Could you add version checks to the lircd init script and support
parallel installation of lircd 0.8 and 0.9, reading different
configuration files?  I suppose not - you don't want to have both
packages still in wheezy, and it's too late to make the squeeze package
of lirc 0.8 work nicely like this.

> Several kernel modules (e.g. dvb-usb-af9015) were ported
> from plain event devices to RC_CORE indepently of the introduction of
> the introduction of this new RC_CORE subsystem in 2.6.37 (it's a 
> coincidence that af9015 was ported in time for 2.6.37, less actively 
> maintained kernel modules are still waiting to get ported).

Does lircd 0.9 work with the old IR modules in a new kernel?

> Booting back and forth between 2.6.32 and >= 2.6.37 will not be 
> possible without changing the configuration (in many cases) and 
> upgrading/ downgrading lirc - and due to the /run/ transition this is a
> one way street.
> [ That said, lirc is -in most cases- not a critical functionality, this 
>   means you can boot any kernel version you like - lircd's init script 
>   might "just" error out and your IR remote won't work, until you boot 
>   into a supported kernel. It will make booting fail or totally break 
>   the system ]

Yes, that makes this somewhat less critical than udev vs sysfs changes
or block device name changes.

> In many cases the configuration will break between squeeze and wheezy,
> some of them can be auto-migrated (as side effect of #655969), but lirc
> covers way too many -and too diverse- devices to get all cases fixed.

I can see that. :-(  But at least you seem to have comprehensive
documentation to help users.  (I hope you didn't write that all just for


Ben Hutchings
This sentence contradicts itself - no actually it doesn't.

Attachment: signature.asc
Description: This is a digitally signed message part

Reply to: