Hi Jon, on 30 Nov 09 at 16:35, Jon Smirl wrote: [...] > It would be interesting to split the lirc daemon. Put the protocol > decoder stuff in one daemon and the scripting support in the other. > The scripting daemon would then be optional. What would be the > relative sizes of the two daemons? > > -------------- > > The LIRC daemon always works with timing data, right? Timing data or hex codes (if decoding is done in hardware). > When it reads > the config files generated by irrecord it internally converts those to > timing data No. > and then matches the incoming data against it. Pattern matching is only done with raw mode config files. The normal case is that lircd is decoding the incoming data using the protocol description found in the config file. > Have you looked at the protocol engine idea? Running the protocol > engines in parallel until a match is achieved. Then map the > vendor/device/command triplet. The protocol engine concept fixes the > problem of Sony remotes in irrecord. No, only rewriting irrecord would fix the problem of Sony remotes. irrecord tries to guess the protocol parameters without any prior knowledge about any protocols. irrecord could also be rewritten to use the protocol engine concept without changing anything in the decoder itself. In fact partly this is already available. You can give irrecord a template config file and it will skip the protocol guessing step. This just would have to be extended so that the template config file could contain several protocol descriptions to match against. I havn't implemented this yet, because I don't care much. Sony remotes do work flawlessly also in raw mode. It's only a problem from the aesthetic view point. > Various Sony remote buttons > transmit in different protocols. irrecord assumes that a remote is > only using a single protocol. Since it can't figure out a protocol it > always records these remotes as raw. With manual intervention you can convert these raw config files afterwards with "irrecord -a". [...] > Button on remote programed to be Mot DVR --> protocol engine --> > Mot/dev/command --> MythTV which is looking for Mot/dev/command > No config files needed. You just move complexity to the application. MythTV would have to know how a Motorola command set looks like. Currently I would tend to an approach like this: - raw interface to userspace using LIRC - fixed set of in-kernel decoders that can handle bundled remotes That would allow zero configuration for simple use cases and full flexibility for more advanced use cases. Christoph -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
