On Thu, Feb 25, 2010 at 08:58:14AM +0100, Mario 'BitKoenig' Holbe wrote:

> I have a Hauppauge remote which is driven by lircd. When inputlircd is
> started after lircd, I cannot control clients anymore with this remote.
[...]
> 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.

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.

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

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.

-- 
Met vriendelijke groet / with kind regards,
      Guus Sliepen <g...@debian.org>

Attachment: signature.asc
Description: Digital signature

Reply via email to