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

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


[ 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) ]

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…

lirc needed significant refactoring to enter the mainline kernel
and RC_CORE was born - this broke the ABI between out-of-tree lirc
kernel modules and in-tree RC_CORE kernel modules. RC_CORE is
stable since 2.6.37 (present since 2.6.36, but there it had bugs in its
interface for 64 bit archtiectures).

> If not, this incompatibility must be mentioned in the package
> description.

I have now added an according change to lirc's long description[1], 
lirc's NEWS file already had an according statement[2] (which will 
most likely still be expanded) and will look into further refinements 
(init script, eventual an udev like (but non-fatal) postinst warning).

> [...]
> > - 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.
Applications built upon liblircclient0 themselves do not care, but 
won't work, unless lircd knows which device nodes or protocols to use.

I'll now take a look at several common device classes, picking out 
representative devices for each of them.

* lirc_i2c *
Before squeeze, these devices (usually found on Hauppauge analogue and 
digital TV cards, you just connect an IR receiver via 2.5mm jacks to 
the card) were covered by lirc_i2c, a typical configuration for these


lircd.conf probably needed to be something like 

In wheezy (also possible in squeeze, to some extent), you need a 
different configuration:


"normal" default lircd.conf like

…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"

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.

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.

* lirc_mceusb *
First of all we need to distinguish between lirc_mceusb and 
lirc_mcesub2, because two very similar device generations were covered 
by different kernel modules in the squeeze era. mceusb devices follow 
the USB receiver/ transceiver devices introduced by Microsoft for their
Windows XP Media Centre Edition. Disclaimer, I've never tested these 
devices (lirc_mceusb2 in this case) in the kernel << 2.6.37 timeframe, 
so this squeeze configuration might not be 100% correct:


it probably needed something like 
/usr/share/lirc/remotes/mceusb/lircd.conf.mceusb as button mapping in 

In wheezy, there are several completely different configurations 
possible (+ additionally using ir-keytable and avoiding the lirc dæmon 

$ cat /sys/class/rc/rc0/protocols 
rc-5 nec rc-6 jvc sony sanyo mce_kbd [lirc]

These are the supported protocols, rc-6 is usually selected as default 
as the transceiver ships with a RC-6 based remote, given that the 
kernel module "mceusb.ko" is auto-probed, you get "nice" device nodes
and normal input events without even using lirc (see ir-keytable for 
non-lirc usage/ configuration)

If you want to use lirc, e.g. because your application needs lirc 
events, there are two orthogonal configuration options:

dev/input (using the RC-6 protocol, decoded by RC_CORE's 


and a "normal" default lircd.conf like

or using the lirc protocol, e.g. because you want to remap buttons or 
use a totally different remote, which isn't supported natively 
(!= rc-5) && (!= nec) && (!= rc-6) && (!= jvc) && (!= sony) && (!= sanyo) && (!= mce_kbd)


and a custom lircd.conf (see irrecord(1)).

[ for completeness' sake, you can also totally bypass using lirc by 
  configuring and using your device through inputlirc instead, or using
  ir-keytable directly ]

…and again, applications don't care about kernel or lirc versions, 
liblircclient0 abstracts that well and in a compatible way, but once 
more liblircclient0 makes the application attach to the socket created 
by lircd - and lircd needs a different configuration for squeeze and 

* staging lirc drivers *

For staging lirc drivers, like lirc_bt829, lirc_igorplugusb, 
lirc_imon, lirc_parallel, lirc_sasem, lirc_serial, lirc_sir, 
lirc_ttusbir or lirc_zilog, nothing really changes. They're
pretty much identical to their corresponding modules previously 
distributed by lirc-modules-source, but may have changed names, got 
added (lirc_parallel) or removed (lirc_gpio, lirc_mceusb{,2}, etc.)


Should still work, most of them will not be auto-probed though.
manual (add module name to /etc/modules):
- lirc_bt829
- lirc_parallel
- lirc_sasem
- lirc_serial (needs setserial, /dev/ttyS0 uart none)
- lirc_sir (needs setserial, /dev/ttyS1 uart none)
- lirc_zilog

- lirc_igorplugusb
- lirc_imon
- lirc_ttusbir

However all of these need to get rewritten for RC_CORE and may totally 
change behaviour once that happens.

* lirc userspace drivers *

These are totally independent of kernel versions and completely 
provided by the lirc package in userspace, I take "samsung" (a USB IR 
receiver) as example, configuration is identical for both squeeze and 


but once more, we have no stable device node, as this USB device gets 
exposed to userspace as /dev/usb/hiddev0, once more an udev rule is
needed to get a stable device node:
SUBSYSTEM=="usb", ATTRS{idVendor}=="0419", ATTRS{idProduct}=="0001", SYMLINK+="usb/rc_samsung"

* non-lirc/ non-RC_CORE kernel modules *

These usually expose an event device to userspace, often emulating 
keyboard events, this covered for example the IR receiver inside 
dvb-usb-af9015 DVB-T receivers in squeeze times. Usually only 
configurable though inputlirc, as it could get exclusive hold of its
(event-) device, in order to avoid spurious key presses. Again this
device node is not stable and needs a udev rule.

Taking af9015 as example once more, it got ported over to RC_CORE in 
kernel 2.6.37, thereby making it accesible to ir_keytable and directly
configurable by lirc


lircd can usually use the default 
/usr/share/lirc/remotes/devinput/lircd.conf.devinput, ir_keytable can
configure button remappings or different remotes using the NEC 

udev rule

* IR remotes indistinguishably emulating USB keyboard/ mouse *

Yes, even these exist - and are "nice" to configure…
Usually you require inputlirc, in order to get exclusive access to the 
event device and to avoid getting spurious key presses. Once more
udev rules, several this time, will be required:

SUBSYSTEM=="input",ATTRS{idVendor}=="05a4",ATTRS{idProduct}=="9881",IMPORT{program}="input_id %p"

lircd.conf can be "random".


An additional hurdle, some of these devices only work with their 
bundled IR remote, while others can be paired with very different ones,
as long as the IR frequency matches roughly or the employed RC_CORE
protocols are matching.


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. 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).
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 ]

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.

Right now lirc supports:
- >100 in-kernel modules somehow related to RC_CORE (rough guess, based
  on 3.3.2)
  none of these were using RC_CORE in squeeze, which didn't exist before 
  2.6.36, many of them weren't supported at all
- 9 staging drivers
- 47 userspace drivers
- numerous devices emulating USB keyboards/ mice
- several devices we don't support in lirc, due to lacking -dev 
  packages (like IRMan or IguanaIR (#524403)).

For some users the upgrade will be smooth, ideally they won't notice 
anything changing (most of the userspace drivers should continue to 
"just work™", the changes I've been working on in response to #655969
[4] will make it more likely that lirc might work mostly out of the box
for those devices whose RC_CORE modules can be auto-loaded by udev.
For many use cases and devices lirc might not even be needed anymore
(RC_CORE && ir_keytable). But there will remain a percentage of users
that will have to do manual configuration changes.

	Stefan Lippers-Hollmann

[1]	http://lists.alioth.debian.org/pipermail/pkg-lirc-changes/2012-April/000600.html
[2]	Vcs-Svn: svn://anonscm.debian.org/svn/pkg-lirc/lirc/trunk/
	Vcs-Browser: http://anonscm.debian.org/viewvc/pkg-lirc/lirc/trunk/
[3]	http://anonscm.debian.org/viewvc/pkg-lirc/lirc/trunk/debian/NEWS?view=markup
[4]	http://anonscm.debian.org/viewvc/pkg-lirc/lirc/trunk/debian/lirc.default?view=markup

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

Reply to: