linux-kernel - Re: [RFC] What are the goals for the architecture of an in-kernel IR system?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <BE3edeNXqgB@lirc>
Date:	01 Dec 2009 08:45:00 +0100
From:	lirc@...telmus.de (Christoph Bartelmus)
To:	jonsmirl@...il.com
Cc:	superm1@...ntu.com
Subject: Re: [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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/