Thread (4 messages) 4 messages, 2 authors, 2009-09-14

Re: input subsystem question

From: Max Sivkov <hidden>
Date: 2009-09-10 18:15:40

Dmitry Torokhov <dmitry.torokhov <at> gmail.com> writes:
Hi Max,

On Thursday 10 September 2009 01:20:02 am Max Sivkov wrote:
quoted
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).


Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help