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
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
