On Wed, Nov 25, 2009 at 10:58:29PM +0100, Gerd Hoffmann wrote:

(1) ir code (say rc5) -> keycode conversion looses information.

I think this can easily be addressed by adding a IR event type to the  
input layer, which could look like this:

  input_event->type  = EV_IR
  input_event->code  = IR_RC5
  input_event->value = <rc5 value>

In case the 32bit value is too small we might want send two events  
instead, with ->code being set to IR_<code>_1 and IR_<code>_2

Advantages:
  * Applications (including lircd) can get access to the unmodified
    rc5/rc6/... codes.
  * All the ir-code -> keycode mapping magic can be handled by the
    core input layer then.  All the driver needs to do is to pass on
    the information which keymap should be loaded by default (for the
    bundled remote if any).  The configuration can happen in userspace
    (sysfs attribute + udev + small utility in tools/ir/).
  * lirc drivers which get ir codes from the hardware can be converted
    to pure input layer drivers without regressions.  lircd is not
    required any more.

I think we need to separate 2 kinds of applications since they have
different requirements as far as interface goes:

1. "Reguilar" user-space applications interested in receiving keystrokes
from user and reacting to them. Movie players, CD players, MythTV-like
applications and so on. Those, to my understanding, are not concerned
with the fine details of RC5, RC6, NEC and so forth protocol decoding
and just want to know when to start playing, when to stop and when to
revind. That class of applications is best served by current input layer
since it unifies data coming from IR, keyboards, button devices and so
forth.

2. "System" applications that are interested in protocol decoding. Those
need interface best suited for IR and nothing else. This protocol is
appears is better kept separate from the evdev input protocol. In case
where we rely solely on such userspace application(s) to perform protocol
decoding we should route input events back to kernel through uinput for
consumption by "class 1" applications.


We use this approach for PS/2 (serio allows binding either psmouse/atkbd
or serio_raw to provide alternate interfaces depending on the users
need), USB hid allows raw access as well, maybe we should follow the
suit here.

-- 
Dmitry