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
me!)
Ben.
--
Ben Hutchings
This sentence contradicts itself - no actually it doesn't.
Attachment:
signature.asc
Description: This is a digitally signed message part