[lkml]   [2003]   [Aug]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] lirc for 2.5/2.6 kernels - 20030802
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.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:47    [W:0.124 / U:0.316 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site