Re: [PATCH] lirc for 2.5/2.6 kernels - 20030802

[Johannes Stezenbach <js@convergence.de>]

Gerd Knorr wrote:
> 
> > We can drop /dev/lirc*, and use input events with received codes, but I
> > think that lircd is still needed to translate them into userland
> > commands...
> 
> That translation isn't done by lircd, but by the lirc_client library.
> This is no reason for keeping lircd as event dispatcher, the input layer
> would do equally well (with liblirc_client picking up events from
> /dev/input/event<x> instead of lircd).

IMHO there's one problem:

If a remote control has e.g. a "1" key this doesn't mean that a user
wants a "1" to be written into your editor while editing source code.
The "1" key on a remote control simply has a differnt _meaning_ than
the "1" key on your keyboard -- depending of course on what the user
thinks this key should mean.

- users should be able to prevent remote keys from being fed into
  the normal keyboard input queue; non lirc aware programs should
  not recieve these events
  (OTOH, if you use an IR keyboard...)
- IR events should reach the applications independant of X keyboard
  focus (well, maybe; the user should be able to decide)

With the current input subsystem, the only possiblity is lircd
grabbing the remote events with EVIOCGRAB, and passing them
on to the applications.


Johannes