[Pkg-lirc-maint] LIRC 0.9 backport to go with backported Linux kernel?

Mon Apr 16 03:45:00 UTC 2012

Hi

On Monday 16 April 2012, Ben Hutchings wrote:
> On Mon, 2012-04-16 at 03:47 +0200, Stefan Lippers-Hollmann wrote:
[…]
> > 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?
[…]
> > "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?

The old drivers didn't use uevents at all, but exposed their key events
through /dev/lirc0 (/dev/lirc/0 in devfs days, usually /dev/lirc on a 
static /dev/ …), using the lirc protocol - which in turn get processed
by the lirc dæmon and are made available through the /run/lirc/lircd
socket, which will can be read by applications through liblircclient0.

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

Most likely, but neither the deprecated lirc_i2c, nor ir-kbd-i2c 
currently have any ID matching implemented. Personally I have access 
to a single/ ancient (more than 10 years old) card using this method, 
where I could look for some unique string to match against, but there 
are several others I have no special knowledge about.

00:12.0 Multimedia video controller [0400]: Brooktree Corporation Bt878 Video Capture [109e:036e] (rev 02)
        Subsystem: Hauppauge computer works Inc. WinTV Series [0070:13eb]
        Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-
        Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 132 (4000ns min, 10000ns max)
        Interrupt: pin A routed to IRQ 21
        Region 0: Memory at e0000000 (32-bit, prefetchable) [size=4K]
        Kernel driver in use: bttv

00:12.1 Multimedia controller [0480]: Brooktree Corporation Bt878 Audio Capture [109e:0878] (rev 02)
        Subsystem: Hauppauge computer works Inc. WinTV Series [0070:13eb]
        Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-
        Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 64 (1000ns min, 63750ns max)
        Interrupt: pin A routed to IRQ 21
        Region 0: Memory at e0001000 (32-bit, prefetchable) [size=4K]
        Kernel driver in use: snd_bt87x

While I try to get my hands on various lirc devices representing the 
major/ most interesting or common device classes, it's impossible to 
even think about getting a representative collection, even less to 
check them for potential regressions regularly.

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

While I can, and will, add version checks to lirc's init script for the
running linux kernel, making two different versions co-installable 
would be very nasty (and definately not a wanted configuration for 
wheezy, due to all the other changes upstream and in the packaging).

That said, for userspace drivers, the running kernel version doesn't 
matter - but in most cases running 0.9.x is wanted for these (be it
because support was added post 0.8.3, be it bug- or eventual security 
fixes in 0.9~, be it just consistency) - dealing with several 
co-installed lircd dæmon versions would not be nice, to say the least.

> [...]
> > 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?

It does work with the >= 2.6.37 staging modules, however it does not 
work with <= 0.8.7 out-of-tree modules, previously provided by 
lirc-modules-source. That said, the most current lirc-modules-source 
ever uploaded to Debian was 0.8.3-5, of which most modules (I'd almost 
guess all) will not build against kernel >= 2.6.33. Kernel 2.6.37-1 was
the first kernel you uploaded to unstable (and later migrating to 
testing) after the squeeze freeze on 2011-02-15, we followed suit with 
lirc 0.9.0~pre1-1 on 2011-02-20.

While RedHat was pushing for lirc to get merged mainline since (very)
late in the squeeze development cycle, IR_CORE and finally RC_CORE
didn't stabilise, nor get merged, until 2.6.36 - with many changes 
required to gain acceptance. So while it was known that the lirc 
situation would hopefully improve past squeeze, the details were only 
fleshed out much too late to prepare for these in squeeze.

> > 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!)

I'm trying to autoconvert the existing configuration as good as 
possible (the affected conffiles are not overlapping 
/etc/lirc/hardware.conf [not touched, if modified] --> 
/etc/default/lirc [new in 0.9.0-1], so this is possible without 
violating policy), but there are many devices where this guessing won't
be possible. Likewise expanding the documentation is another topic on 
the to-do list for lirc 0.9.0-1 (partly depending on how much this 
can be automated), unfortunately this can't cope with all cases either,
be it due to the sheer number of different devices/ modules - or 
because I simply don't know about the specifics for a given 
device(-class), e.g. [1].

Regards
	Stefan Lippers-Hollmann

[1]	while I knew that devices which concurrently support several IR 
	protocols, like [rc-6] and [lirc] at once, might experience multiple 
	key presses and would most likely need adaptions, I didn't know 
	how to deal with devices like these (no Debian bug report for this 
	problem), before obtaining one of those myself
	http://lists.alioth.debian.org/pipermail/pkg-lirc-changes/2012-January/000587.html
	uploading this fix is blocked by #655969
-------------- 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/0f5a2c76/attachment-0001.pgp>