Re: input subsystem question

[Dmitry Torokhov <dmitry.torokhov@gmail.com>]

On Thu, Sep 10, 2009 at 06:15:18PM +0000, Max Sivkov wrote:
> Dmitry Torokhov <dmitry.torokhov <at> gmail.com> writes:
> 
> > 
> > Hi Max,
> > 
> > On Thursday 10 September 2009 01:20:02 am Max Sivkov wrote:
> > > Hello!
> > > I have a question about using of the input subsystem.
> > > Is there any way to filter input messages from a device (keyboard). I.e. I
> > > need to have ability to pass some messages from the device, and block
> > > others. Could community point me to the right place where I can find how to
> > > do that?
> > 
> > There are different options, we'd need more context...
> > 
> 
> 
> Dmitry,
> 
> Thanks for the response.
> 
> Driver/user mode daemon should get scancodes (events) from the input device
> (keyboard), detect particular scancodes and put them to the internal buffer to
> send to the user space later time.
> 
> I'm stucked here, because after getting event from the input subsystem I will
> need to remove the event from the input queue. 
> As I understood events mechanism is useful if one needs to gather input event's
> (keylogger) w/o modifying input queue.
> 
> Currently my driver for 2.6.x kernels is based on a atkbd driver with some
> modifications, but this method has one big disadvantage: when input subsystem
> developers change something in the input subsystem I have to do the annoying job
> once again (take atkbd.c, add my functionality, rebuild kernel, etc, etc).
> 

If you want to work on keycode level (KEY_* definitions) then you could
use a user-space program that "grabs" input device, filters out the
events it is interested in and injects events that it has no interested
in back into kernel via uinput.

If you want to work with AT keyboard scancodes and intercept them before
they reach atkbd driver - then we currently don't have such an option
although one is desired since some laptop vendors like to inject
non-keyboard data into keyboard stream.

-- 
Dmitry