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

[Jon Smirl]

On Sun, Nov 29, 2009 at 7:01 AM, Christoph Bartelmus <lirc@xxxxxxxxxxxx> wrote:
> Hi Jon,
>
> on 27 Nov 09 at 12:49, Jon Smirl wrote:
> [...]
>> Christoph, take what you know from all of the years of working on LIRC
>> and design the perfect in-kernel system. This is the big chance to
>> redesign IR support and get rid of any past mistakes. Incorporate any
>> useful chunks of code and knowledge from the existing LIRC into the
>> new design. Drop legacy APIs, get rid of daemons, etc. You can do this
>> redesign in parallel with existing LIRC. Everyone can continue using
>> the existing code while the new scheme is being built. Think of it as
>> LIRC 2.0. You can lead this design effort, you're the most experience
>> developer in the IR area.
>
> This is a very difficult thing for me to do. I must admit that I'm very
> biased.
> Because lircd is the only userspace application that uses the LIRC kernel
> interface, we never had any problems changing the interface when needed.
> I can't say there's much legacy stuff inside. I'm quite happy with the
> interface.
> The other thing is that I can't really move the decoder from userspace to
> kernel because there are way too many userspace drivers that do require a
> userspace decoder. LIRC also is running on FreeBSD, MacOS and even Cygwin.
> So letting the userspace drivers take advantage of a potential Linux in-
> kernel decoder is not an option for me either.
> I'm having my 'LIRC maintainer' hat on mostly during this discussion and I
> do understand that from Linux kernel perspective things look different.

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? When it reads
the config files generated by irrecord it internally converts those to
timing data and then matches the incoming data against it.

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. 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.

If the IR data is being decoded in a protocol engine it becomes
possible to get rid of the need to configure IR in some cases. Apps
like MythTV could pretend like they are a common piece of electronics
hardware - say a Motorola DVR.  MythTV can then look for the
vendor/device/command triplet from a Motorola DVR. Set your
programmable remote to send the Motorola DVR commands and everything
will "just work".

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.

Make a command in MythTV to switch to emulating a different DVR if you
happen to own this one. Take this a step further and register a MythTV
profile with the various IR databases.




>
>> Take advantage of this window to make a
>> design that is fully integrated with Linux - put IR on equal footing
>> with the keyboard and mouse as it should be.
>
> That's a question that I have not answered for myself concludingly.
> Is a remote control really on exactly the same level as a keyboard or
> mouse?
>
> Christoph
>



-- 
Jon Smirl
jonsmirl@xxxxxxxxx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/