Date:	Thu, 26 Nov 2009 22:58:59 -0500
From:	Jon Smirl <jonsmirl@...il.com>
To:	Jarod Wilson <jarod@...sonet.com>
Cc:	linux-media@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-input@...r.kernel.org
Subject: Re: [IR-RFC PATCH v4 0/6] In-kernel IR support using evdev

On Thu, Nov 26, 2009 at 10:12 PM, Jarod Wilson <jarod@...sonet.com> wrote:
>> Raw mode. There are three sysfs attributes - ir_raw, ir_carrier,
>> ir_xmitter. Read from ir_raw to get the raw timing data from the IR
>> device. Set carrier and active xmitters and then copy raw data to
>> ir_raw to send. These attributes may be better on a debug switch. You
>> would use raw mode when decoding a new protocol. After you figure out
>> the new protocol, write an in-kernel encoder/decoder for it.
>
> Also neglected to recall there was raw IR data access too. However, a few
> things... One, this is, in some sense, cheating, as its not an input layer
> interface being used. :) Granted though, it *is* an existing kernel
> interface being used, instead of adding a new one. Two, there's no userspace
> to do anything with it at this time. I mean, sure, in theory, writing it
> wouldn't be that hard, but we can already do the same thing using the lirc
> interface, and already have userspace code for it. I think users need/desire
> to use raw IR modes may be more prevalent that most people think.

I would view raw mode as a developer interface which would be used to
implement a new protocol decode engine.  There is an assumption in my
design that all IR timings can be decoded/constructed by a protocol
engine.  Sure we may end up with 40 protocol engines, but they are
only about 50 lines of code. You could put each engine into a loadable
module if you want.

You see raw data used a lot with Sony remotes. Sony remotes mix
multiple protocols in a single remote. The irrecord program does not
understand these mixed protocols and generates a raw mode config file.
The mixed protocols don't bother the protocol state machine system.
This happens with other mixed protocol remotes too.

> Two drivers are supplied. mceusb2 implements send and receive support
>> for the Microsoft USB IR dongle.
>
> I'd be game to try hacking up the lirc_mceusb driver (which has, since your
> work was done, merged mce v1 and v2 transceiver support) to support both
> your in-kernel interface and the lirc interface as an example of the hybrid
> approach I'm thinking of.
>
>> Code is only lightly tested. Encoders and decoders have not been
>> written for all protocols. Repeat is not handled for any protocol. I'm
>> looking for help. There are 15 more existing LIRC drivers.
>
> And there's the hangup for me. The lirc drivers and interface have been
> pretty heavily battle-tested over years and years in the field. And there
> are those 15 more drivers that already work with the lirc interface. I'm
> woefully short on time to work on any porting myself, and about to get even
> shorter with some new responsibilities at work requiring even more of my
> attention.
>
> If we go with a hybrid approach, all those existing drivers can be brought
> in supporting just the lirc interface initially, and have in-kernel decode
> support added as folks have time to work on them, if it actually makes sense
> for those devices.
>
> Just trying to find a happy middle ground that minimizes regressions for
> users *and* gives us maximum flexibility.

You are going to have to choose. Recreate the problems of type
specific devices like /dev/mouse and /dev/kbd that evdev was created
to fix, or skip those type specific devices and go straight to evdev.
We've known for years the /dev/mouse was badly broken. How many more
years is it going to be before it can be removed? /dev/lirc has the
same type of problems that /dev/mouse has. The only reason that
/dev/lirc works now is because there is a single app that uses it.

Also, implementing a new evdev based system in the kernel in no way
breaks existing lirc installations. Just don't load the new
implementation and everything works exactly the same way as before.

I'd go the evdev only route for in-kernel and leave existing lirc out
of tree. Existing lirc will continue to work. This is probably the
most stable strategy, even more so than a hybrid approach. The
in-kernel implementation will then be free to evolve without the
constraint of legacy APIs. As people become happy with it they can
switch over.


-- 
Jon Smirl
jonsmirl@...il.com
--
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/

Powered by blists - more mailing lists