Keyboard Filtering/Injecting

B

BlueCoder

I'm interested in a creating a macro input system.

I want to be able to detect the state of keyboards and be able to filter block them.

Is there any established API for keyboard filtering? What about key injection? I looked in ports/sysutils and didn't see anything.

On the simple side what I'm imagining could be used for mapping keys to a game controller. I could just create a virtual keyboard for that but I might also want to monitor key states and perform different actions depending on them. On the more complex side what I'm imagining could be used with terminal filters and application detection for remapping keys dynamically per application.

I'm pretty much thinking I need to hack the console and tty drivers and expose some custom ioctrls of my own.

Thanks for any insights.

P.S. And yes obviously whatever I come up with will need root privileges to function and or install.
 
Syscons I'm guessing takes it's input form atkbd0. (Not sure about usb keyboards.)

Then kbd0 which is actually an X driver takes it's input from atkbd0.

I want to filter everything so I'll need to be at the atkbd0 level.

In fact I want to be able to distinguish and filter multiple keyboards separately.

But after that I need to be able to detect/deduce the active/focus application; where the keystrokes are being redirected to. Be it a syscons/tty console app or an X app.

Then based on the application type I can determine which key codes are actually sent to which application. For remote applications there would obviously need to be a daemon service involved.

TTY apps might be the trickiest. I would like to have a mutating TTY. Key codes are translated into tty codes by the syscons driver. TTY codes are arbitrary so I should be able to switch between "TTY types" on the fly.

The reason I would want to switch tty types would be assumptions made by tty apps. Some TTY types map keys one way, others another. Some apps might not even use termcap/terminfo or have a key bindings file. It just complicated. I think it would be more manageable to let each console app work in it's own optimal terminal type and come preset with it's key-bindings for that terminal. It would be like a program telling me it spoke English or French. So instead of the terminal specifying the language, the program does. The program is then free to make assumptions.

What I'm proposing is not more complicated, in fact it simplifies things. Right now with console programs you have to more or less tune key-bindings for each and every program and learn their key binding syntax. It's just easier to not need to have users setup bindings and let the programs work in a default mode. Then if you layer my macro software underneath you can script keys to generate whatever single or multi key code sequence you want in the "tty language" the application prefers.

Thanks for reading my ramblings.
 
So you'll actually go at the driver level ... you could make some kind of "rootkit" (there's a book on it, actually) or actually go easier and replace the driver with your own.
In any case that does require root privileges and are major words because of the worries of a panic and the understanding that KBI may break.

I'm starting to get comfortable on developing on FreeBSD, but driver development is waaay out of my reach.
You could ask for pointers on freebsd-hackers

Regards
 
I know the first thing everyone thinks of is a rootkit or a key logger. What I really want is a macro system. Console and X together.

And as far as driver development I don't know why people assume kernel programming is harder than user mode programs. I have some experience with Microsoft Windows drivers. More often than not it's actually easier since you are limited by the kernel API's. It's the debugging that is a little tricky but again your dealing with a much smaller API than user space so there are only so many things that can be wrong. Understanding what is going on and coordinating everything is almost always the meat of any problems.
 
BlueCoder said:
And as far as driver development I don't know why people assume kernel programming is harder than user mode programs.
Click to expand...
  • Most people are unaccustomed to having only the kernel API system calls (and possibly some internal routines) available.
  • Consequently, the programming is more low-level than in userland. Depending on what one is trying to do, one may have to basically "reinvent" standard library calls.
  • Debugging is trickier (although a virtual machine goes a long way).
  • In userland one can get away with not checking return values and gracefully handling error situations. Not that such constitutes good programming practice, but one can often get away with it. In the kernel, not so much. One really needs to diligently check return codes and handle them properly.
Note that you don't necessarily have to agree with all of the above. They are common reasons why people find kernel programming harder than userland programming, but they may or may not be your reasons. For example, if you already are in the habit of doing proper error checking you'll probably not agree with the last reason.
 
I know the first thing everyone thinks of is a rootkit or a key logger. What I really want is a macro system. Console and X together.
Click to expand...

Sorry, but if your requirement is to go at the driver level, then that's the answer ... anything else is wanting a toaster to wash your clothes.

And as far as driver development I don't know why people assume kernel programming is harder than user mode programs.
Click to expand...

Not harder per se, but is an added responsibility ... if your userspace binary fails, you can re-launch it in a heart beat; if your kernel-space binary fails (which is somewhat expectable if you just start developing drivers on a platform), then *may the force be with you*

Regards.
 
You must log in or register to reply here.
Back
Top