Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

From: Jarod Wilson
Date: Wed Nov 25 2009 - 13:07:39 EST


On Nov 25, 2009, at 12:40 PM, Krzysztof Halasa wrote:

> lirc@xxxxxxxxxxxx (Christoph Bartelmus) writes:
>
>> I'm not sure what two ways you are talking about. With the patches posted
>> by Jarod, nothing has to be changed in userspace.
>> Everything works, no code needs to be written and tested, everybody is
>> happy.
>
> The existing drivers use input layer. Do you want part of the tree to
> use existing lirc interface while the other part uses their own
> in-kernel (badly broken for example) code to do precisely the same
> thing?

Took me a minute to figure out exactly what you were talking about. You're referring to the current in-kernel decoding done on an ad-hoc basis for assorted remotes bundled with capture devices, correct?

Admittedly, unifying those and the lirc driven devices hasn't really been on my radar.

> We can have a good code for both, or we can end up with "badly broken"
> media drivers and incompatible, suboptimal existing lirc interface
> (though most probably much better in terms of quality, especially after
> Jarod's work).

Well, is there any reason most of those drivers with currently-in-kernel-but-badly-broken decoding can't be converted to use the lirc interface if its merged into the kernel? And/or, everything could converge on a new in-kernel decoding infra that wasn't badly broken. Sure, there may be two separate ways of doing essentially the same thing for a while, but meh. The lirc way works NOW for an incredibly wide variety of receivers, transmitters, IR protocols, etc.

I do concur that Just Works decoding for bundled remotes w/o having to configure anything would be nice, and one way to go about doing that certainly is via in-kernel IR decoding. But at the same time, the second you want to use something other than a bundled remote, things fall down, and having to do a bunch of setkeycode ops seems less optimal than simply dropping an appropriate lircd.conf in place.

--
Jarod Wilson
jarod@xxxxxxxxxxxx



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