Re: [IR-RFC PATCH v4 0/6] In-kernel IR support using evdev

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



First up, thank you for reposting this. I believe several of us were keeping this code in mind for the in-kernel decoding portion of this discussion, but it hadn't been stated outright in the recent threads here.

On 11/26/2009 08:34 PM, Jon Smirl wrote:
This is a repost of the LIRC input patch series I wrote a year ago.
Many of the ideas being discussed in the currect "Should we create a
raw input interface for IR's?" thread have already been implemented
in this code.

---------------------------------------------------

All of this kernel code is tiny, about 20K including a driver.

Basic flow works like this:

patch: Minimal changes to the core input system
Add a new IR data type to the input framework

patch: Core IR module
In-kernel decoding of core IR protocols - RC5, RC6, etc
This only converts from protocol pulse timing to common command format.
Check out: http://www.sbprojects.com/knowledge/ir/sirc.htm

I think we can definitely take advantage of this for the in-kernel side of the initial hybrid approach I think we're converging on.

patch: Configfs support for IR
Decoded core protocols pass through a translation map based on configfs
When core protocol matches an entry in configfs it is turned into a
keycode event.

This part... Not so wild about. The common thought I'm seeing from people is that we should be using setkeycode to load keymaps. I mean, sure, I suppose this could be abstracted away so the user never sees it, but it seems to be reinventing a way to set up key mapping when setkeycode already exists, and is used by a number of existing IR devices in the v4l/dvb subsystem (as well as misc things like the ati rf remotes, iirc). Is there some distinct advantage to going this route vs. setkeycode that I'm missing?

patch: Microsoft mceusb2 driver for in-kernel IR subsystem
Example mceusb IR input driver

Bah. I completely forgot you'd actually did have transmit code too.

...
Raw IR pulse data is available in a FIFO via sysfs. You can use this
to figure out new remote protocols.

Two input events are generated
1) an event for the decoded raw IR protocol
2) a keycode event if the decoded raw IR protocol matches an entry in
the configfs

You can also send pulses.
...
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.

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.

--
Jarod Wilson
jarod@xxxxxxxxxxxx
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux