Re: Status of lirc. should I create new reciever driver against it?

[Jon S. <jon...@gm...>]

On Fri, May 29, 2009 at 5:50 PM, Christoph Bartelmus <li...@ba...> wrote:
> Hi!
>
> Maxim Levitsky "max...@gm..." wrote:
> [...]
>> I want to write a kernel driver for this device, but I don't know if I
>> need to write it against lirc, or recently posted on LKML in-kernel IR
>> framework.
> [...]
>> What are your suggestions?
>
> Just implement a LIRC driver.
>
> The last suggestion that seemed to be accepted was that the IR data is
> received by the LIRC drivers and is passed to a in-kernel decoder if the
> user configures it so. Otherwise it's passed to lircd in user-space.
>
> The in-kernel decoder code was far from complete and I still have concerns
> that it can work in all situations.

Let's work on the design of this. My embedded systems they are using
remotes that transmit the common protocols, the in-kernel state
machine handles them fine. I also agree that there are weird device
and protocols that the in-kernel statement won't handle. I also agree
that there are user space implementations like the IR receiver via a
sound card.

There are a whole lot of things that haven't been designed. For
example what does a minimal in-kernel IR device driver look like? What
is it's sysfs interface? I attempted to make these drivers as small as
possible.  There is a sysfs attribute that holds the raw input from
the device, etc. I just did a first version of this model, it needs
more design effort. For example it would be simple to add an attribute
that stops the device pulses from being forwarded to the state machine
and require use of the user space decoder.

My goal would be to handle the 90% of common hardware/remotes with the
in-kernel solution and then pass the rest off to user space. The
in-kernel solution is only about 30KB of code.

Last documentation I posted:

New release of in-kernel IR support implementing evdev support. The
goal of in-kernel IR is to integrate IR events into the evdev input
event queue and maintain ordering of events from all input devices.
Still looking for help with this project.

Git tree: git://github.com/jonsmirl/digispeaker.git

ir-core is now a module. Minimal IR code is built into input, that
code can't be separated from input. The rest of the core IR code is
moved to a module. The IR code in input will be passive if IR-core
isn't loaded.

Now uses configfs to build mappings from remote buttons to key
strokes. When ir-core loads it creates /config/remotes. Make a
directory for each remote you have; this will cause a new input
devices to be created. Inside these directories make a directory for
each key on the remote. In the key directory attributes fill in the
protocol, device, command, keycode. Since this is configfs all of this
can be easily scripted.

Now when a key is pressed on a remote, the configfs directories are
searched for a match on protocol, device, command. If a matches is
found, a key stroke corresponding to keycode is created and sent on
the input device that was created when the directory for the remote
was made.

The configfs directories are pretty flexible. You can use them to map
multiple remotes to the same key stroke, or send a single button push
to multiple apps.

To do the mapping it uses configfs (part of the kernel).  The main
directory is remotes. You use a shell script to build mappings between
the IR event and key stroke.

mkdir /config/remotes/sony
 -- this creates a new evdev device
mkdir remotes/sony/one
echo 7 >remotes/sony/one/procotol
echo 264 >remotes/sony/one/command
echo 2 >remotes/sony/one/keycode

This transforms a button push of 1 on my remote into a key stroke for KEY_1

 *   configfs root
 *   --remotes
 *   ----specific remote
 *   ------keymap
 *   --------protocol
 *   --------device
 *   --------command
 *   --------keycode
 *   ------repeat keymaps
 *   --------....
 *   ----another remote
 *   ------more keymaps

You can map the 1 button from multiple remote to KEY_1 if you want. Or
you can use a single remote to create multiple virtual keyboards.

>From last release...

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.

The in-kernel code is tiny, about 20K including a driver.

>From last post...
Note that user space IR device drivers can use the existing support in
evdev to inject events into the input queue.

Send and receive are implemented. Received IR messages are decoded and
sent to user space as input messages. Send is done via an IOCTL on the
input device.

Two drivers are supplied. mceusb2 implements send and receive support
for the Microsoft USB IR dongle.

The GPT driver implements receive only support for a GPT pin - GPT is
a GPIO with a timer attached.

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.




>
> Christoph
>
> ------------------------------------------------------------------------------
> Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
> is a gathering of tech-side developers & brand creativity professionals. Meet
> the minds behind Google Creative Lab, Visual Complexity, Processing, &
> iPhoneDevCamp as they present alongside digital heavyweights like Barbarian
> Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com
>



-- 
Jon Smirl
jon...@gm...