[Pkg-lirc-maint] Bug#617417: Bug#617417: liblircclient0: Breaks inputlirc.

Stefan Lippers-Hollmann s.L-H at gmx.de
Tue Mar 8 23:46:24 UTC 2011


severity 617417 normal
tags 617417 + unreproducible
tags 617417 + moreinfo
thanks

Hi

On Tuesday 08 March 2011, Christian Ohm wrote:
> Package: liblircclient0
> Version: 0.9.0~pre1-1
> Severity: critical
> Justification: breaks unrelated software
> 
> Hello,
> 
> After the update to version 0.9.0..., inputlircd doesn't work anymore (in
> mplayer), with the following message in /var/log/syslog:

inputlircd isn't linked to /usr/lib/liblirc_client.so.0:
$ ldd ./usr/sbin/inputlircd 
        linux-vdso.so.1 =>  (0x00007fffe3ff1000)
        libc.so.6 => /lib/libc.so.6 (0x00007f9eccc3e000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f9eccfb7000)
so I find it difficult to believe that up-/ or downgrading 
liblircclient0 can make a difference. Looking at the diff between 
0.8.3-5 and 0.9.0~pre1 and their symbol tables doesn't suggest any ABI 
breakage either.

> inputlircd: Error processing event from js0: Success

hmm, what kind of device is js0, a joystick?

> mplayer gives its usual output when there's no lirc device:
> 
> mplayer: could not connect to socket

While I have no inputlirc setup, using lirc 0.9.0~pre1-1 directly 
(incl. dev/input driven devices) in combination with mplayer seems to
work fine, e.g.:

$ head -n 20 ~/.lircrc
begin
	button = KEY_HOME
	prog = mplayer
	config = vo_fullscreen
	repeat = 0
end

begin
	button = KEY_VOLUMEUP
	prog = mplayer
	config = volume 1
	repeat = 1
end

begin
	button = KEY_VOLUMEDOWN
	prog = mplayer
	config = volume -1
	repeat = 1
end

> Just downgrading to 0.8.3-5 makes it work again.
[...]

Did you downgrade just liblircclient0 or also lirc, your version output
below suggests the later?


The upgrade to lirc 0.9~ is a major change, as lirc upstream had to do 
many changes to get lirc modules into the mainline kernel (staging) and
to define the new common RC_CORE subsystem together with the v4l 
subsystem maintainers. In order to improve out-of-the-box behaviour of 
lirc and input devices, the lirc key definitions of the shipped example 
lircd.confs /usr/share/lirc/remotes/) have been harmonized[1] to follow
those of the input subsystem, which, depending on your kind of 
configuration and physical device, might require reconfiguration of 
your lirc clients for the new keycodes. 

Please also keep in mind that in kernels >= 2.6.36 the implementation
of several previously custom input drivers for IR devices have be 
ported over to the new RC_CORE subsystem, which may affects the emitted
scancodes for several devices (lirc_i2c --> ir-kbd-i2c or cx88xx in 
2.6.38, for example). Likewise /usr/bin/ir-keytable (packaged in 
ir-keytable) now needs to be used to override the keytables for devices
decoded in kernelspace.


If you can rule out a change of emitted keycodes with the new kernel- 
or lirc packages, please send me the related configuration files, so I 
can try to reproduce the issue locally - in particular:
	/etc/lirc/hardware.conf
	/etc/lirc/lircd.conf
	/etc/default/inputlirc
	~/.lircrc

What does "/usr/bin/irw" (packaged in lirc) say, if you use the remote?
Any output with "/usr/bin/evtest /dev/input/js0" (lirc and/ or 
inputlirc needs to be stopped, /usr/bin/evtest is packages in evtest).

Regards
	Stefan Lippers-Hollmann

[1]	http://lirc.git.sourceforge.net/git/gitweb.cgi?p=lirc/lirc;a=commitdiff;h=d8e64b052b4e5a572131f6844b5ec3ab1bc8f6ec
	http://lirc.git.sourceforge.net/git/gitweb.cgi?p=lirc/lirc;a=commitdiff;h=a86cd108db0d85e13b7de929bec10d970a1ec010





More information about the Pkg-lirc-maint mailing list