On Wed, 2005-08-10 at 11:09 -0400, Matthew J. Bodkin wrote:
> On Mon, 2005-08-08 at 21:24, Fredrik Tolf wrote:
> > Hi list!
> Hi Fredrik,
> > ...
> > Its purpose is primarily to keep a synchronized state,
> > so that different programs using liblirc_client don't get into different
> > states just because they were started at different times.
> I haven't heard of this utility before - I assume you're referring to
> the lircrc defined 'mode's.
Yes, indeed that is what I'm referring to. That's right... they were
called "modes", not "states". :)
> Would this mean that client programs would not need to read lircrc
> files themselves, and instead the lirccd daemon (or equivalent) would
> read it and handle client connections & states? Or just that LIRC would
> centralize the state handling?
Here's how it works more exactly: My liblirc_client, upon entering
lirc_init, attempts to connect to a socket called ~/.lircc instead
of /dev/lircd. If it gets an error while trying to do that, it reads the
first line of ~/.lircrc and matches it against a certain pre-compiled
regex (by default "cd:[[:blank:]]*(([^#]|\\#)+)(#|$)"). If it matches,
it uses the match to start a client daemon of that name. If it doesn't,
it uses a pre-compiled list of client daemons to attempt to start. After
it has started the specified daemon, it re-attempts to connect.
When started, the client daemon parses the user's ~/.lircrc in its
entirety, and liblirc_client never touches it, except for the first line
in the case the client daemon isn't already running. The client daemon
connects to lircd and reads its output. It also has a protocol for
communicating with liblirc_client through the ~/.lircc socket. This
protocol has several purposes: First of all, it allows the client daemon
to send commands to the programs that are using liblirc_client. The
programs will receive these commands just as they would using LIRC's
standard liblirc_client (using lirc_nextcode and lirc_code2char), only
it is the client daemon's sole discretion which commands to send (the
programs don't receive the raw keypresses anymore, unless they
explicitly request them).
After some previous discussion of a client daemon previously on this
list, the protocol has some other features as well, though -- primarily
to allow a program to "capture" the button stream from lircd, so that no
other programs can see it. It was thought of as a feature for a GUI
configurator which has a "get key" button. It would allow a user to
configure a key on the remote without other programs responding to it as
they normally would.
If I didn't mention so previously, the new liblirc_client that I have
written is binary backwards compatible with the one that comes with
LIRC, but has some more functionality as well.
> It sounds like your client layer would help considerably. Here's some
> interest and a vote for a unified LIRC state machine.
I see I forgot to post the link to lirccd in my first message. Here it
In the package I have there, both the new library and my client daemon
is included. As I mentioned in the previous message, I'm not currently
suggesting my client daemon for inclusion in LIRC (since, although it's
more capable, it's not compatible with the current ~/.lircrc file
format), but only the library. Thus, the library is already written and
seems to work perfectly (at least for me). It's only the backwards
compatible client daemon that would need to be written, if anything.