#571313 inputlirc: inhibits lircd(-driven remotes)

Package:
inputlirc
Source:
inputlirc
Description:
Zeroconf LIRC daemon using input event devices
Submitter:
"Mario 'BitKoenig' Holbe"
Date:
2010-02-25 14:51:03 UTC
Severity:
important
#571313#5
Date:
2010-02-25 07:58:14 UTC
From:
To:
Package: inputlirc
Version: 16-1
Severity: important

Hello,

I have a Hauppauge remote which is driven by lircd. When inputlircd is
started after lircd, I cannot control clients anymore with this remote.

This is easily reproducible provided you have a lircd-driven device:

# /etc/init.d/lirc start
Loading LIRC modules:.
Starting remote control daemon(s) : LIRC :.
Starting remote control mouse daemon : LIRCMD :.
#

$ xawtv
	---> At this point I can control xawtv via remote
$

# /etc/init.d/inputlirc start
Starting inputlirc
#

$ xawtv
	---> At this point the remote doesn't affect xawtv anymore
$

# /etc/init.d/lirc restart
Stopping remote control mouse daemon: LIRCMD:.
Stopping remote control daemon(s): LIRC:.
Loading LIRC modules:.
Starting remote control daemon(s) : LIRC :.
Starting remote control mouse daemon : LIRCMD :.
#

$ xawtv
	---> At this point I can control xawtv via remote again
$

It seems like once inputlircd is started, it inhibits lircd from
/dev/lircd, i.e. clients cannot connect to lircd anymore via /dev/lircd.
I assume, the same applies vice-versa, but cannot test it myself since I
have no multimedia-keyboard currently available on the machine where the
remote is connected to.

The usual Debian-way to handle this issue would be to conflict with the
lirc package. However, since the devices handled by lirc and inputlirc
are mutually exclusive, none of the packages is a true substitution for
the other and users can easily have a set of devices for which they need
both packages. Thus, a more co-operative solution would probably be
better.

Most likely this is something to forward upstream.


Thanks for your work & regards
   Mario
#571313#10
Date:
2010-02-25 13:48:26 UTC
From:
To:
[...]

Yes, it indeed will replace /dev/lircd (which is actually a UNIX socket, not a
device file), with its own /dev/lircd. Clients that are still running will
still be handled by the normal lircd, new clients will see inputlircd.

It is not the Debian-way to conflict in this case, that is only when two
packages cannot be installed at the same time because they would overwrite each
other's binaries or configuration files for example. The two packages can
happily coexist. Yes, they do use the same UNIX socket name by default (you can
change this with the -d option in inputlirc), and one client cannot connect to
two daemons at the same time. In your case, the original lircd can also read
input device files. This requires a bit more effort, and you should look at
lircd's documentation for that, but that would allow you to use both your
regular and inputdev remotes simultaneously.

I'll also see if I can add some logic to inputlircd to detect if another lirc
daemon is still running, and exit with a warning.
#571313#15
Date:
2010-02-25 14:35:16 UTC
From:
To:
Good hint, thanks.

That would be great.

	fuser /dev/lircd
could do the trick: it returns 0 if the socket exists and is in use, and
1 if the socket does not exist or is not in use.

Small patch attached. A little bit dirty, but it works :) It does not
work if somebody configures -d in /etc/default/inputlirc to a different
socket name - parsing things like
	-d /dev/foo/bar
	-c -d /dev/foo/bar -f
	-cd /dev/foo/bar -f
in shell is not that nice - works, but ... :)


regards
   Mario
#571313#20
Date:
2010-02-25 14:50:35 UTC
From:
To:
Forgot to mention: you need to depend on psmisc then.


Mario