[Pkg-lirc-maint] LIRC 0.9 backport to go with backported Linux kernel?
Stefan Lippers-Hollmann
s.L-H at gmx.de
Mon Apr 16 01:47:31 UTC 2012
Hi
[ sorry to break the threading, but I'm not subscribed to
debian-backports at l.d.o and pkg-lirc-maint at 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
was:
LOAD_MODULES=true
DRIVER="default"
DEVICE="/dev/lirc0"
MODULES="lirc_i2c"
lircd.conf probably needed to be something like
/usr/share/lirc/remotes/hauppauge/lircd.conf.hauppauge
In wheezy (also possible in squeeze, to some extent), you need a
different configuration:
LOAD_MODULES=true
DRIVER="dev/input"
DEVICE="/dev/input/irremote0"
MODULES="ir-kbd-i2c"
"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"
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:
DRIVER="default"
DEVICE="/dev/lirc0"
it probably needed something like
/usr/share/lirc/remotes/mceusb/lircd.conf.mceusb as button mapping in
lircd.conf
In wheezy, there are several completely different configurations
possible (+ additionally using ir-keytable and avoiding the lirc dæmon
alltogether)
$ 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
/dev/input/by-id/usb-SMK_CORPORATION_MCE_TRANCEIVR_Emulator_Device_2006_PA070620045513C-event-if00
/dev/input/by-path/pci-0000:00:1a.0-usb-0:1.6:1.0-event
/dev/input/event3
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
"ir_rc6_decoder.ko":
DRIVER="dev/input"
DEVICE="/dev/input/by-id/usb-SMK_CORPORATION_MCE_TRANCEIVR_Emulator_Device_2006_PA070620045513C-event-if00"
and a "normal" default lircd.conf like
/usr/share/lirc/remotes/devinput/lircd.conf.devinput
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)
DRIVER="default"
DEVICE="/dev/lirc0"
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
wheezy.
************************
* 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.)
DRIVER="default"
DEVICE="/dev/lirc0"
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
auto-probed:
- 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
wheezy:
DRIVER="samsung"
DEVICE="/dev/usb/rc_samsung"
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
DRIVER="dev/input"
DEVICE="/dev/input/irremote0"
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
protocol.
udev rule
SUBSYSTEM=="input",ATTRS{idVendor}=="0ccd",ATTRS{idProduct}=="0097",ENV{.INPUT_CLASS}="ir",SYMLINK="input/irremote0"
**************************************************************
* 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"
SUBSYSTEM=="input",ATTRS{idVendor}=="05a4",ATTRS{idProduct}=="9881",ENV{ID_INPUT_KEYBOARD}=="1",SYMLINK="input/irremote0"
SUBSYSTEM=="input",ATTRS{idVendor}=="05a4",ATTRS{idProduct}=="9881",ENV{ID_INPUT_MOUSE}=="1",SYMLINK="input/irremote1"
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.
Regards
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.alioth.debian.org/pipermail/pkg-lirc-maint/attachments/20120416/0c8f023d/attachment.pgp>
More information about the Pkg-lirc-maint
mailing list