Messages in this thread Patch in this message | | | From | Ryan Lortie <> | Subject | Re: "Internet Keyboard" support for Linux | Date | Wed, 8 Dec 1999 23:00:58 +0000 |
| |
On Wed, 08 Dec 1999, you wrote: > On Wed, 8 Dec 1999, Alan Cox wrote: > > > The other way is a small modification to the existing keyboard handler code. > > > It could declare a global symbol in the kernel, and if this symbol was set, > > > call the code that it pointed to every time a scancode was being processed, and > > > behave according to the return value of that function. > > > > I think this is the nicer approach, because it can be used for other things like > > that toshiba keyboard problem people are reporting > > The SysRQ handler comes to mind, which reminds me, I got to rewrite > that... > > p |\ _,,,---,,_ Kelly "STrRedWolf" Price > u /,`.-'`' -. ;-;;,_ http://www.FurNation.com/STriker > r |,4- ) )-,_..;\ ( `'-' WolfSkunks for a better Linux Kernel > r '---''(_/--' `-'_) fL
hmm.. Cute cat :)
Anyways, I have a patch around here somewhere for keyboard.c to allow the keyboard-addons to "hook" into the handle_scancode routine.
--- keyboard.c Mon Aug 9 19:05:01 1999 +++ keyboard.c Wed Dec 8 22:16:19 1999 @@ -63,6 +63,9 @@
EXPORT_SYMBOL(handle_scancode);
+static int (* keyboard_addon)( unsigned char scancode, int down ) = 0; +EXPORT_SYMBOL(keyboard_addon); + extern void ctrl_alt_del(void);
struct wait_queue * keypress_wait = NULL; @@ -199,6 +202,10 @@ unsigned char keycode; char up_flag = down ? 0 : 0200; char raw_mode; + + if( keyboard_addon ) + if( keyboard_addon( scancode, down ) ) + return;
do_poke_blanked_console = 1; mark_bh(CONSOLE_BH);
Simply, when the addon handler is loaded, its init_module function will set keyboard_addon to point to its own handler function. If this pointer is setup, handle_scancode will call this handler for each keypress.
If the handler returns non-zero, then the handle_scancode function ends at that point. This prevents those annoying "unknown scancode" messages that the kernel gives.
Kelly: I would like your input about what needs to be done for SysRQ "magic" keys... it would be really neat if this interface could be used for that.
Matthijis: As for your problem, I'm not sure about how to handle "enabling" your keys. I do, however, have an LED on my keyboard (under windows, it blinks with the webbrowser is starting up) The flashing is started by writing 0xeb to port 0x60. It is disabled by writing 0xec. I imagine this could be handled by the addon module. I discovered these codes by writing them one-by-one to port 0x60. Try writing a program to sequentially write 0 to 0xFF and see when the keys go live (you can check with 'showkey -s')
A few concerns I have: Presumably, the addon handler will allow 0xE0s to pass through, but flag them in its own last_scancode variable. With them passing through, the normal keyboard handler is going to be expecting a following chracter (which will get filtered by this - to prevent the unknown scancodes). From what I can see, this behavour is working properly, but it doesn't seem right. Perhaps the keyboard_addon return codes could be expanded further?
Any comments? Ryan
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |