From: Fredrik T. <fr...@do...> - 2005-08-10 02:24:19
|
Hi list! I couple of years ago (2003, I believe), I was bugging this list about a program of mine, lirccd. I don't know if any of you remember it, but lirccd (LIRC Client Daemon) is a little daemon that sits in between lircd and any program using liblirc_client. 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 can well understand that lirccd shouldn't be included as part of LIRC, particularly since it uses a very different configuration file format than liblirc_client does. However, I do believe that using the liblirc_client that comes as part of lirccd as a replacement for LIRC's liblirc_client would be a good thing for LIRC. The liblirc_client in lirccd always connects to a client daemon through a standardized protocol (in order to allow coexistence of several client daemons, even on the same system), instead of connecting to lircd and managing the state as part of the library. If a client daemon that reads the standard ~/.lircrc file format and acts as the standard liblirc_client could be written, that would still solve the synchronization problem of liblirc_client, and it would allow people to use other client daemons more easily. I haven't written such a client daemon, mostly because I don't even know the standard ~/.lircrc file format (I haven't used it since I wrote lirccd in late 2002). However, if you agree with me that this is a good idea, I'd be willing to read through the standard liblirc_client source and implement such a client daemon. Since I wouldn't use it myself, though, I'd like to know that you think it's a good idea before I write it. Thanks for your attention! Fredrik Tolf |
From: Matthew J. B. <mat...@in...> - 2005-08-10 15:09:24
|
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. > ... > If a client daemon that reads > the standard ~/.lircrc file format and acts as the standard > liblirc_client could be written, that would still solve the > synchronization problem of liblirc_client, and it would allow people to > use other client daemons more easily. 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? > I haven't written such a client daemon, mostly because I don't even know > the standard ~/.lircrc file format (I haven't used it since I wrote > lirccd in late 2002). However, if you agree with me that this is a good > idea, I'd be willing to read through the standard liblirc_client source > and implement such a client daemon. Since I wouldn't use it myself, > though, I'd like to know that you think it's a good idea before I write > it. I've done some work using LIRC as a base to more seamlessly integrate MythTV with the other electronics in an entertainment system. So for example, the user can choose "Watch VHS Tape" from the Myth Menu and then the system is setup for VCR viewing and irexec's basically 'remap' or translate a Hauppauge remote to the VCR functions. It works great from the user's perspective... The hidden trouble has been with the LIRC states. In this example, we need to tell Myth that we're entering 'VCR' mode/state when the menu selection is made. Coordinating the killing and spawning of irexecs for VCR-mode, DVD-mode, Radio-mode, etc has been a messy way of getting around isolated states. It sounds like your client layer would help considerably. Here's some interest and a vote for a unified LIRC state machine. > Thanks for your attention! > > Fredrik Tolf Thanks, - Matt |
From: Fredrik T. <fr...@do...> - 2005-08-10 18:08:16
|
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 is: <http://www.dolda2000.com/~fredrik/lirccd/> 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. Fredrik Tolf |
From: <li...@ba...> - 2005-08-10 20:11:57
|
Hi! Fredrik Tolf "fr...@do..." wrote: [...] > and implement such a client daemon. Since I wouldn't use it myself, > though, I'd like to know that you think it's a good idea before I write > it. In the meantime I have already started to implement such a client daemon. The concept will be 100% backwards compatible and it will allow to use different client daemons without having to replace the lirc_client library. Basically, when reading the config file it will look for a sha-bang and start the according client daemon or connect to it's socket if it already is running. I'm using e.g.: #! /usr/local/bin/lirc_clientd The current state of the implementation is that the client daemon is started and clients can connect to it. But I still have to implement the protocol between clients and the daemon. I planned to use the same protocol as in your lirccd. Christoph |
From: Fredrik T. <fr...@do...> - 2005-08-11 03:38:19
|
On Wed, 2005-08-10 at 22:08 +0200, Christoph Bartelmus wrote: > Hi! > > Fredrik Tolf "fr...@do..." wrote: > [...] > > and implement such a client daemon. Since I wouldn't use it myself, > > though, I'd like to know that you think it's a good idea before I write > > it. > > In the meantime I have already started to implement such a client > daemon. Nice! :) > The concept will be 100% backwards compatible and it will allow to use > different client daemons without having to replace the lirc_client > library. In that case, you ought to be able to just use the liblirc_client that I've written. It, too, is 100% backwards binary compatible (to my knowledge, at least), and it allows for different client daemons without replacing the library. > Basically, when reading the config file it will look for a sha-bang and > start the according client daemon or connect to it's socket if it > already is running. > I'm using e.g.: > #! /usr/local/bin/lirc_clientd There is a problem with that, though -- in my liblirc_client implementation, I've used a format which is language-independent. For example, my client daemon feeds ~/.lircrc through the C preprocessor, which would choke on a sha-bang line. Instead, I'm using a regex which can cope with whatever comment style is in use in the client daemon's language. For example, my ~/.lircrc begins with this line: /* cd: /usr/local/bin/lirccd# */ It is matched against the following, hard-wired regex, and the first submatch is taken as the name of the client daemon: cd:[[:blank:]]*(([^#]|\\#)+)(#|$) > The current state of the implementation is that the client daemon is > started and clients can connect to it. But I still have to implement the > protocol between clients and the daemon. I planned to use the same > protocol as in your lirccd. Since you were planning to use the same protocol either way, you may want to take code from lirccd.c in my client daemon, which implements the client daemon side of the protocol. Alternatively, if there's a way I can get a hold of your client daemon, I can implement the protocol for you. As I mentioned above, my liblirc_client is already backwards compatible and independent of client daemon, so you don't have any particular complaints about it, you could just re-use it as is. I forgot to link to my client daemon in my original message, so here's the link: <http://www.dolda2000.com/~fredrik/lirccd/> Fredrik Tolf |
From: <li...@ba...> - 2005-08-11 18:48:39
|
Hi! Fredrik Tolf "fr...@do..." wrote: [...] > In that case, you ought to be able to just use the liblirc_client that > I've written. It, too, is 100% backwards binary compatible (to my > knowledge, at least), and it allows for different client daemons without > replacing the library. Does it have support for the lircrc config file format built-in? Does it support multiple independent config files? [...] >> The current state of the implementation is that the client daemon is >> started and clients can connect to it. But I still have to implement the >> protocol between clients and the daemon. I planned to use the same >> protocol as in your lirccd. > Since you were planning to use the same protocol either way, you may > want to take code from lirccd.c in my client daemon, which implements > the client daemon side of the protocol. I'll have a look. > Alternatively, if there's a way > I can get a hold of your client daemon, I can implement the protocol for > you. I'm not yet sure about the concept. Once this is clear the actual coding won't be difficult. If you want I can send you my current code. Christoph |
From: Fredrik T. <fr...@do...> - 2005-08-11 23:30:31
|
On Thu, 2005-08-11 at 20:24 +0200, Christoph Bartelmus wrote: > Hi! > > Fredrik Tolf "fr...@do..." wrote: > [...] > > In that case, you ought to be able to just use the liblirc_client that > > I've written. It, too, is 100% backwards binary compatible (to my > > knowledge, at least), and it allows for different client daemons without > > replacing the library. > > Does it have support for the lircrc config file format built-in? No, of course not. Isn't the entire point of creating a client daemon to move the file format out of liblirc_client? That's why I thought that I (or someone) would write a client daemon that would be compatible with the lircrc config file format, which would be the client daemon started by liblirc_client by default (if, and only if, no client daemon is already running, this library starts it automatically), if no other one is specified. > Does it support multiple independent config files? I'm not sure what that means. Are you referring to the ability to use other filenames than ~/.lircrc? > [...] > I'm not yet sure about the concept. Once this is clear the actual coding > won't be difficult. What part of the concept? > If you want I can send you my current code. If it's not any trouble for you, I might as well have a look at it. Fredrik Tolf |