lkml.org 
[lkml]   [2009]   [Dec]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC] What are the goals for the architecture of an in-kernel IR system?
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


\
 
 \ /
  Last update: 2009-12-01 08:49    [W:0.226 / U:0.300 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site