Re: [PATCH 0/18] linux infrared remote control drivers

From: Jarod Wilson
Date: Tue Sep 09 2008 - 11:27:06 EST

On Tuesday 09 September 2008 08:46:09 Christoph Hellwig wrote:
> On Tue, Sep 09, 2008 at 12:05:45AM -0400, Jarod Wilson wrote:
> > The following patch series adds 17 new drivers for assorted infrared
> > and/or RF remote control receivers and/or transmitters. These drivers
> > have long lived out-of-tree at, packaged as
> > 3rd-party modules by many distributions, and more recently, patched into
> > the kernels of at least Fedora and Ubuntu. The primary maintainer of
> > lirc, Christoph Bartelmus simply hasn't had the time to send these bits
> > upstream, and a few months back, gave me the go-ahead to take on the
> > task.
> Any reason this is a separate subsystem instead of just a bunch new
> drivers for the input subsystem?

IR device handling is often a bit, shall we say, "special", for a number of
devices... Some receivers decode the waveform and give us something sensible
the input layer could use (and some IR receivers do work that way), while
other receivers pass along raw IR codes, which we require the use of the lirc
daemon to decode and convert into something sensible. To complicate the matter
further, a number of devices are either output-only devices, or both input and
output devices.

There's been talk about converting lirc drivers over to using evdev in the
long run, but evdev would need a decent amount of extending to be able to
support everything lircd does right now.

> > Not all drivers have been tested with this codebase and certainly not all
> > devices they support, but its a solid place to start with these
> > in-kernel. Patches are against 2.6.27-rc5-git9 or so, and have been
> > tested running the same, at least in the cases where hardware was
> > available. These patches are also in the latest nightly Fedora rawhide
> > kernel, for those who want instant gratification[3]. Note that you also
> > need the lirc userspace to really do any meaningful testing...
> Can you first only send the actually tested drivers? That way review
> an cleanup can focus on the core and those few and we might get them
> ready for 2.6.28. Other drivers can than be added when testing and
> review is done.

I meant to include that the ordering of the patches was more or less from
most-used/most-tested to least-used/least-tested, and a few of the patches do
include Tested-by: lines in them. Basically, the first four or five drivers
probably cover the majority of users, so getting them in first would provide
the most bang-for-your-buck. But I can certainly re-send with only the tested
drivers after we get through the first round of comments, if that's preferred
over my approach of putting the higher-prio ones to the front of the ordering.

Jarod Wilson

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at