Re: lirccd

[Fredrik T. <fr...@do...>]

Joydeep Bakshi writes:
 > Hi Fredrik ,
 > nice to hear u again. I was interested on ur lirccd and also mail u off-list. 
 > but then some features were missing. anyhow could u please explain a little 
 > bit that how lirccd is superior than lircd ?

Well, the simple answer to that question is that it isn't. In fact,
lirccd isn't meant to be a replacement for lircd, it's meant to be
placed "between" lircd and the rest of the programs that use LIRC. It
sits there and takes care of the messages from lircd (ie. the raw
keypresses), and its main purpose in life is to translate these raw
keypresses into messages that are meaningful for each program.

The project as it stands now is a full replacement for the library
liblirc_client, which is currently implemented completely in each
client program's process. Since the different client programs don't
communicate anything with each other or so, it can easily happen that
they get "out-of-sync", ie. that if you start one program and enter a
certain state (as implemented in your ~/.lircrc), and after that start
another LIRC-enabled program, they will be in different states, and
buttons on your remote will mean different things to them.

My project solves that by making liblirc_client a library for
communicating with lirccd (also, if you start a LIRC-enabled program
and lirccd isn't already running, it liblirc_client will start it for
you). Since lirccd handles all keypress translations, all programs
will always receive the same messages.

That's the first, immediate, advantage. There are also several
others. The most important one is that lirccd uses a much more
flexible configuration file format than the current liblirc_client
does. For example, I have implemented a full MP3 player in it (it
doesn't decode MP3 files itself, but uses mpg123, but it perfectly
well controls the whole thing), which I use every day. You can check
out the config examples on the project's home page to see what it's
all about. The project's home page is on:

http://www.dolda2000.com/~fredrik/lirccd/

Briefly, lirccd uses a programmatical configuration file format,
calling a C-like script for each keypress received from lircd. If you
only wish to implement simple events in the style of the current
liblirc_client, you need not worry, it's quite simple. Check out
sample 1 on the home page for an example. However, many more things
can also be done. It is also important to note that while the current
liblirc_client library uses a flat state layout, lirccd uses a
hierarchical system, which at least I consider advantagous, since it
allows for more combinations. I plan to extend the language with
commands for jumping directly between states as well (so that it can
be flat if you want it to).

Anyhow, please note that there is a clear distinction between lircd
and lirccd. lirccd communicates with the kernel modules and/or the
hardware and translates what it gets from them into readable button
names, while lirccd takes these button names from lircd and translates
them into messages that are meaningful for each individual program.

In this new version of lirccd, it is also possible for client programs
to specifically request to have keypress events directly relayed to
them from lircd if they would wish. They can also completely capture
the stream from lircd, in order to implement eg. GUI configurators
(think "Click this button to record a keypress"; you wouldn't want
other programs receiving that keypress as well).

Note that liblirc_client and lirccd are still seperated. There is
nothing in my new liblirc_client implementation that binds it
specifically to my lirccd. You can, if you wish, implement a new
client daemon that behaves differently, and have liblirc_client
communicate with it, as long as it implements the protocol
correctly. Of course, I don't see why you would want that, when there
is my lirccd instead ;-).

 > may I use mplayer, xmms etc with it or need additional plugins ?

Most certainly. I put a lot of effort into making the new
liblirc_client fully binary compatible with the current
one. Therefore, you should be able to use virtually any program that
is using the current liblirc_client. Of course, the exception is those
that actually use the raw keypresses from lircd; they would have to be
rewritten. Fortunately, I don't think many (if any) programs do that,
in favor of letting .lircrc do the job.

Admittedly, the only program that I've actually used with this is
mplayer, but I have studied the programs that currently come with the
LIRC distribution for how they use liblirc_client, so I would be
surprised if it was not compatible.

Fredrik Tolf