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 -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
