Re: ps2 keyboard filter hook

Re: ps2 keyboard filter hook

[Andries.Brouwer]

>> One of these centuries we must replace the present keyboard
>> and console stuff, probably by something very similar to
>> Vojtech's input device stuff, and we must make sure that
>> the new code is powerful enough to last for a few years again.

> Why only something similar to the input suite and not the (full)
> input suite?

You misread the above. No restriction is intended.

Re: ps2 keyboard filter hook

[Dan Streetman]

On Sat, Jun 16, Mike A. Harris wrote:

>I find it very odd indeed with IBM's big voice of open source
>praise, yada yada, and what Lou has said in the past, that there
>would be any question at all of wether it would be open source or
>not.  Isn't big blue behind open source?  Or is it just for
>publicity?  Makes me wonder now...

This is a bit of a late reply, but I think maybe I wasn't clear in my first
statement that I couldn't get the driver opened.

The driver isn't mine; I just wrote the hooks.  The actual driver's
author doesn't want it released as Open Source, and all other team members
(besides me) are unconvinced that it will be useful to anyone to release it
(i.e., they're asking "why" instead of "why not").

So it's local approval that is my particular problem; I'm sure that if we had
asked for approval from the company-wide decision makers, they would have given
it.  From the limited experience I've had with them, they are very pro-OSS.

-- 
Dan Streetman
ddstreet@us.ibm.com
--------------------------------------------------
186,282 miles per second:
It isn't just a good idea, it's the law!

Re: ps2 keyboard filter hook

[Dan Streetman]

>I find it very odd indeed with IBM's big voice of open source
>praise, yada yada, and what Lou has said in the past, that there
>would be any question at all of wether it would be open source or
>not.  Isn't big blue behind open source?  Or is it just for
>publicity?  Makes me wonder now...

Yes, IBM is definately behind OSS, but that doesn't mean everything is suddenly
opened...and for many people, it's still got to have a 'business' (or legal)
reason to be made open (apart from the technical benefits of OSS)...

IBM is one of the biggest companies around, and obviously everyone can't do a
mental 180 in a short period of time...;-)

Although I just got here a year ago, so I don't really know what it was like in
the 'old days' :)

>Must be some real good rocket science in that interface that
>theres no way on earth someone else could come up with it for it
>to be important IP to protect.  Makes me wonder what's hiding
>behind it...

I actually think that in this case (and possibly many others) it's not a case
of wanting to 'protect' amazing code or design, but more that people are used to
working a certain way (closed), and it's hard to change.  They still have a
'reflex' that tells them to keep it closed, and need a good business (or legal)
reason to open it...instead of asking 'why not?' they ask 'why?'.

In this specific case, the obvious benefits like peer review, increased user and
developer base, etc. were ignored; they thought the user and/or developer base
(any retail company or ISV) was too specific and/or small.

--
Dan Streetman
ddstreet@us.ibm.com
--------------------------------------------------
186,282 miles per second:
It isn't just a good idea, it's the law!

Re: ps2 keyboard filter hook

[Michael Rothwell]

On 15 Jun 2001 16:03:32 -0400, ddstreet@us.ibm.com wrote:
> 
> IBM Retail Store Solutions dept has certain PS/2 keyboards which extend the
> standard PS/2 specification in order to support addition hardware built into the
> keyboard (such as a Magnetic Strip Reader, Keylock, Tone generator, extra keys,
> -Dan

I'm facing a similar problem with the "Qoder" barcode scanner. I have to
have a keyboard hook. The "right" way seem to be to use the input api.
Unfortunately, this means that current kernels can't use the driver w/o
a patch (the input api patch). The ugly way is to patch the keyboard
driver. I'm doing both.

However, I wrote a REALLY SIMPLE hook tht supported exactly my needs,
since it's in the category of "ugly hack waiting for input api." Maybe
I'll write a version for your hook.

I wonder when the input api stuff for ps/2 devices will be a part of the
mainstream kernel...

--
Michael Rothwell
rothwell@holly-springs.nc.us

Re: ps2 keyboard filter hook

[Christoph Hellwig]

In article <UTC200106161253.OAA311473.aeb@vlet.cwi.nl> you wrote:
> One of these centuries we must replace the present keyboard
> and console stuff, probably by something very similar to
> Vojtech's input device stuff, and we must make sure that
> the new code is powerful enough to last for a few years again.

Why only something similar to the input suite and not the (full)
input suite?  It works really nice here and unlike the current
keyboard cruft it is actually very clean.

	Christoph

-- 
Of course it doesn't work. We've performed a software upgrade.

Re: ps2 keyboard filter hook

[Andries.Brouwer]

>> patch to allow other drivers to register with the PS/2 driver as 'filters'

> Didn't we just conclude a discussion here on linux-kernel, which said
> that patches which simply add hooks allowing proprietary extensions are
> not accepted into the kernel?

There is a certain need for this kind of patches.
I have seen similar stuff for the blind, or for disabled
people who for example can use only one hand.
Also for people who use a combined keyboard/barcode reader.
Hooks for drivers that do something special have other uses
than for proprietary extensions.

It is good to see what people want.
One of these centuries we must replace the present keyboard
and console stuff, probably by something very similar to
Vojtech's input device stuff, and we must make sure that
the new code is powerful enough to last for a few years again.

Andries

Re: ps2 keyboard filter hook

[Mike A. Harris]

On Fri, 15 Jun 2001, Dan Streetman wrote:

>Date: Fri, 15 Jun 2001 17:03:38 -0400 (EDT)
>From: Dan Streetman <ddstreet@us.ibm.com>
>To: Jeff Garzik <jgarzik@mandrakesoft.com>
>Cc: Linux Kernel <linux-kernel@vger.kernel.org>
>Content-Type: TEXT/PLAIN; charset=US-ASCII
>Subject: Re: ps2 keyboard filter hook
>
>
>>Didn't we just conclude a discussion here on linux-kernel, which said
>>that patches which simply add hooks allowing proprietary extensions are
>>not accepted into the kernel?
>
>Yes (I assume you mean the whole 'sockreg' register/unregister thread(s)...;-)
>
>I never intended to get that patch in.  In fact I would be shocked (and a bit
>horrified) if it was accepted.
>
>But management doesn't listen to me when I say it will never get accepted so I
>had to make a token effort of submitting it to prove it won't get accepted.
>
>And I did try hard to convince them to release the actual driver but it didn't
>work.

I find it very odd indeed with IBM's big voice of open source
praise, yada yada, and what Lou has said in the past, that there
would be any question at all of wether it would be open source or
not.  Isn't big blue behind open source?  Or is it just for
publicity?  Makes me wonder now...

Must be some real good rocket science in that interface that
theres no way on earth someone else could come up with it for it
to be important IP to protect.  Makes me wonder what's hiding
behind it...


----------------------------------------------------------------------
    Mike A. Harris  -  Linux advocate  -  Open Source advocate
       Opinions and viewpoints expressed are solely my own.
----------------------------------------------------------------------
DISCLAIMER - These opoi^H^H "damn", ^H, [esc :q :qq !q "shoot!" :Q! "Whaddya
mean, Not an editor command?" :wq! ^C^C^C !STOP ^bye ^quit :quit! !halt ...
^w^q :!w :wq! ^D :qq!! ^STOP [HALT!   HALT!!! "Why's it doing this?" :stopit!
:wwqq!! ^Z ^L ^ESC STOP  :bye  bye  bye! "Hey, what's this red button d..."

Re: ps2 keyboard filter hook

[Vojtech Pavlik]

On Fri, Jun 15, 2001 at 06:14:05PM -0400, Dan Streetman wrote:
> 
> >> Vojtech, could you comment on if the above is possible using the input
> >layer?
> >
> >Yes, and quite easily it'll fit into the input layer. Basically the way
> >to do it would be to open the PS/2 port in the filter driver (thus
> >disabling the normal keyboard driver to open it) and then register a new
> >PS/2 port which the normal keyboard driver would attach to.
> 
> Sweet!  Thanks.
> 
> I assume this (along with the linux-console stuff) won't make it into the 2.4
> kernel for a while though, until after it's been in 2.5 for a while?

It's planned for 2.5.0. If it'll make it back to 2.4.x, I can only hope.

-- 
Vojtech Pavlik
SuSE Labs

Re: ps2 keyboard filter hook

[Dan Streetman]

>> Vojtech, could you comment on if the above is possible using the input
>layer?
>
>Yes, and quite easily it'll fit into the input layer. Basically the way
>to do it would be to open the PS/2 port in the filter driver (thus
>disabling the normal keyboard driver to open it) and then register a new
>PS/2 port which the normal keyboard driver would attach to.

Sweet!  Thanks.

I assume this (along with the linux-console stuff) won't make it into the 2.4
kernel for a while though, until after it's been in 2.5 for a while?

Thanks again!

-- 
Dan Streetman
ddstreet@us.ibm.com
--------------------------------------------------
186,282 miles per second:
It isn't just a good idea, it's the law!

Re: ps2 keyboard filter hook

[Vojtech Pavlik]

On Fri, Jun 15, 2001 at 05:30:03PM -0400, Dan Streetman wrote:
> 
> >X11 likes to talk direct to the PS/2 port.  I actually think you should
> >instead
> >talk to Vojtech for the mainstream kernel about the input device work. It
> >sounds much cleaner and more close to what you need
> 
> Ah, I didn't realize the input layer was handling PS/2 stuff...?  Although I am
> not sure it would work; the special needs of these keyboards requires the driver
> to do some bizarre things, such as:
> 
> - change scancodes.  I was and still am shocked by this.  I will say that it is
>   a 'legacy feature' that I'm told is due having to deal with Windoze...
> - consume scancodes.  The keyboard uses normal scancodes for the extra hardware
>   as well as normal keys, so if the driver can't filter them out large amounts
>   of strange characters will appear when (e.g.) a credit card is swiped.
> - send large amounts of bytes (multi-KB) to the PS/2 port (I think this
>   may be possible).
> 
> The filtering needs to be done fairly early (I think), or the keyboard state may
> get corrupted by seemingly random 'normal' scancodes coming in (for non-raw
> modes)...
> 
> Vojtech, could you comment on if the above is possible using the input layer?

Yes, and quite easily it'll fit into the input layer. Basically the way
to do it would be to open the PS/2 port in the filter driver (thus
disabling the normal keyboard driver to open it) and then register a new
PS/2 port which the normal keyboard driver would attach to.

See the input CVS (http://www.suse.cz/development/input/quick.html)

-- 
Vojtech Pavlik
SuSE Labs

Re: ps2 keyboard filter hook

[Dan Streetman]

>X11 likes to talk direct to the PS/2 port.  I actually think you should
>instead
>talk to Vojtech for the mainstream kernel about the input device work. It
>sounds much cleaner and more close to what you need

Ah, I didn't realize the input layer was handling PS/2 stuff...?  Although I am
not sure it would work; the special needs of these keyboards requires the driver
to do some bizarre things, such as:

- change scancodes.  I was and still am shocked by this.  I will say that it is
  a 'legacy feature' that I'm told is due having to deal with Windoze...
- consume scancodes.  The keyboard uses normal scancodes for the extra hardware
  as well as normal keys, so if the driver can't filter them out large amounts
  of strange characters will appear when (e.g.) a credit card is swiped.
- send large amounts of bytes (multi-KB) to the PS/2 port (I think this
  may be possible).

The filtering needs to be done fairly early (I think), or the keyboard state may
get corrupted by seemingly random 'normal' scancodes coming in (for non-raw
modes)...

Vojtech, could you comment on if the above is possible using the input layer?

-- 
Dan Streetman
ddstreet@us.ibm.com
--------------------------------------------------
186,282 miles per second:
It isn't just a good idea, it's the law!

Re: ps2 keyboard filter hook

[Dan Streetman]

>Didn't we just conclude a discussion here on linux-kernel, which said
>that patches which simply add hooks allowing proprietary extensions are
>not accepted into the kernel?

Yes (I assume you mean the whole 'sockreg' register/unregister thread(s)...;-)

I never intended to get that patch in.  In fact I would be shocked (and a bit
horrified) if it was accepted.

But management doesn't listen to me when I say it will never get accepted so I
had to make a token effort of submitting it to prove it won't get accepted.

And I did try hard to convince them to release the actual driver but it didn't
work.

-- 
Dan Streetman
ddstreet@us.ibm.com
----------------------------------------
186,282 miles per second:
It isn't just a good idea, it's the law!

Re: ps2 keyboard filter hook

[Alan Cox]

> The registered drivers are called (in order of registration) for every scancode,
> and they may change or consume the scancode (or allow it to pass).  Also the
> 'filters' are given a function to send an variable-sized buffer to the keyboard
> output port; this function is synchronized using a semaphore which also
> coordinates with pckbd_leds().

X11 likes to talk direct to the PS/2 port.  I actually think you should instead
talk to Vojtech for the mainstream kernel about the input device work. It 
sounds much cleaner and more close to what you need

Re: ps2 keyboard filter hook

[Jeff Garzik]

ddstreet@us.ibm.com wrote:
> In order to use these keyboards, a the standard PS/2 driver needs to behave a
> bit differently; thus attached is a modifcation to the PS/2 driver which allows
> other drivers to register with the PS/2 driver as 'filters'.  There is a
> arbitrary max number of 'filters' set to 1, which is a compile-time define.
> The registered drivers are called (in order of registration) for every scancode,
> and they may change or consume the scancode (or allow it to pass).  Also the
> 'filters' are given a function to send an variable-sized buffer to the keyboard
> output port; this function is synchronized using a semaphore which also
> coordinates with pckbd_leds().

Didn't we just conclude a discussion here on linux-kernel, which said
that patches which simply add hooks allowing proprietary extensions are
not accepted into the kernel?

-- 
Jeff Garzik      | Andre the Giant has a posse.
Building 1024    |
MandrakeSoft     |

ps2 keyboard filter hook

[ddstreet]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1152 bytes --]


IBM Retail Store Solutions dept has certain PS/2 keyboards which extend the
standard PS/2 specification in order to support addition hardware built into the
keyboard (such as a Magnetic Strip Reader, Keylock, Tone generator, extra keys,
extra LEDs, etc).  This addition hardware behaves in a manner that makes it
unusable if driven by a standard PS/2 driver (sadly, due to the fact that its
design is "IP" I can't elaborate on how or why it is incompatible with the
standard PS/2 specification).

In order to use these keyboards, a the standard PS/2 driver needs to behave a
bit differently; thus attached is a modifcation to the PS/2 driver which allows
other drivers to register with the PS/2 driver as 'filters'.  There is a
arbitrary max number of 'filters' set to 1, which is a compile-time define.
The registered drivers are called (in order of registration) for every scancode,
and they may change or consume the scancode (or allow it to pass).  Also the
'filters' are given a function to send an variable-sized buffer to the keyboard
output port; this function is synchronized using a semaphore which also
coordinates with pckbd_leds().

-Dan

[-- Attachment #2: patch-ps2filter --]
[-- Type: TEXT/PLAIN, Size: 8347 bytes --]

diff -urN 2.4.5-clean/Documentation/Configure.help linux/Documentation/Configure.help
--- 2.4.5-clean/Documentation/Configure.help	Thu May 24 18:03:06 2001
+++ linux/Documentation/Configure.help	Fri Jun 15 13:34:18 2001
@@ -13274,6 +13274,21 @@
   If you are unsure, say N and read the HOWTO nevertheless: it will
   tell you what you have.
 
+PS/2 Keyboard Filter support
+CONFIG_PC_KEYB_FILTER
+  This enables filter support in the PS/2 keyboard driver.  With
+  this enabled, other drivers will be able to register with the
+  PS/2 driver and filter all incoming scancodes.  This is useful
+  for keyboards which extend the PS/2 keyboard standard with
+  non-standard scancodes which should not be normally routed to
+  the current console.
+
+  This option does not actually filter any scancodes, it only
+  allows other drivers (who will do the filtering) to register
+  with the PS/2 driver.
+
+  If unsure, say N.
+
 QIC-02 tape support
 CONFIG_QIC02_TAPE
   If you have a non-SCSI tape drive like that, say Y. Or, if you want
diff -urN 2.4.5-clean/drivers/char/Config.in linux/drivers/char/Config.in
--- 2.4.5-clean/drivers/char/Config.in	Tue Mar  6 22:44:34 2001
+++ linux/drivers/char/Config.in	Fri Jun 15 13:34:18 2001
@@ -105,6 +105,11 @@
 
 source drivers/char/joystick/Config.in
 
+mainmenu_option next_comment
+comment 'Keyboards'
+bool 'PS/2 Keyboard Filter support' CONFIG_PC_KEYB_FILTER
+endmenu
+
 tristate 'QIC-02 tape support' CONFIG_QIC02_TAPE
 if [ "$CONFIG_QIC02_TAPE" != "n" ]; then
    bool '  Do you want runtime configuration for QIC-02' CONFIG_QIC02_DYNCONF
diff -urN 2.4.5-clean/drivers/char/Makefile linux/drivers/char/Makefile
--- 2.4.5-clean/drivers/char/Makefile	Wed May 16 13:27:02 2001
+++ linux/drivers/char/Makefile	Fri Jun 15 13:34:18 2001
@@ -21,7 +21,7 @@
 # All of the (potential) objects that export symbols.
 # This list comes from 'grep -l EXPORT_SYMBOL *.[hc]'.
 
-export-objs     :=	busmouse.o console.o keyboard.o sysrq.o \
+export-objs     :=	busmouse.o console.o keyboard.o pc_keyb.o sysrq.o \
 			misc.o pty.o random.o selection.o serial.o \
 			tty_io.o
 
diff -urN 2.4.5-clean/drivers/char/pc_keyb.c linux/drivers/char/pc_keyb.c
--- 2.4.5-clean/drivers/char/pc_keyb.c	Fri Apr  6 13:42:55 2001
+++ linux/drivers/char/pc_keyb.c	Fri Jun 15 13:34:18 2001
@@ -13,6 +13,11 @@
  * Code fixes to handle mouse ACKs properly.
  * C. Scott Ananian <cananian@alumni.princeton.edu> 1999-01-29.
  *
+ * Added optional scancode filtering, used in keyboards which
+ * (incompatibly) extend the standard PS/2 specification.
+ * Also added synchronized output writing using a semaphore.
+ * Dan Streetman <ddstreet@us.ibm.com> 2001-03-14
+ *
  */
 
 #include <linux/config.h>
@@ -32,6 +37,7 @@
 #include <linux/slab.h>
 #include <linux/kbd_kern.h>
 #include <linux/smp_lock.h>
+#include <linux/module.h>
 
 #include <asm/keyboard.h>
 #include <asm/bitops.h>
@@ -60,6 +66,7 @@
 
 static void kbd_write_command_w(int data);
 static void kbd_write_output_w(int data);
+static void kb_wait(void);
 #ifdef CONFIG_PSMOUSE
 static void aux_write_ack(int val);
 static void __aux_write_ack(int val);
@@ -68,7 +75,7 @@
 static spinlock_t kbd_controller_lock = SPIN_LOCK_UNLOCKED;
 static unsigned char handle_kbd_event(void);
 
-/* used only by send_data - set by keyboard_interrupt */
+/* used by send_data and send_data_buffer - set by keyboard_interrupt */
 static volatile unsigned char reply_expected;
 static volatile unsigned char acknowledge;
 static volatile unsigned char resend;
@@ -94,6 +101,104 @@
 #define MAX_RETRIES	60		/* some aux operations take long time*/
 #endif /* CONFIG_PSMOUSE */
 
+#ifdef CONFIG_PC_KEYB_FILTER
+/* Use an array (instead of a linked list) to save time in_interrupt() */
+static struct pc_keyb_filter *filters[PC_KEYB_MAX_FILTERS];
+static int num_filters = 0;
+
+static DECLARE_MUTEX(kbd_output_sema);
+static spinlock_t pc_keyb_filter_lock = SPIN_LOCK_UNLOCKED;
+
+static int send_data_buffer( unsigned char *buffer, unsigned int len, unsigned int *xferred, unsigned int retries, unsigned int timeout )
+{
+	const unsigned int timeout_jiffies = ( (timeout * HZ) + 999 ) / 1000;
+	int i;
+	unsigned int xfer = 0;
+
+	if (xferred) *xferred = 0;
+
+	if (down_interruptible(&kbd_output_sema))
+		return -EINTR;
+	for (i=0; i<len; i++) {
+		do {
+			timeout = timeout_jiffies;
+			acknowledge = resend = 0;
+			reply_expected = 1;
+			kbd_write_output_w( (int)buffer[i] );
+			while (timeout-- && !resend && !acknowledge) {
+				set_current_state(TASK_INTERRUPTIBLE);
+				if (schedule_timeout(1) && signal_pending(current)) {
+					set_current_state(TASK_RUNNING);
+					up(&kbd_output_sema);
+					return -EINTR;
+				}
+				set_current_state(TASK_RUNNING);
+			}
+#ifdef KBD_REPORT_TIMEOUTS
+			if (0 >= timeout)
+				printk( __FILE__ ": Timeout - AT keyboard not present?\n" );
+#endif
+		} while (retries-- && !acknowledge && resend);
+		if (acknowledge) {
+			xfer++;
+			if (xferred) *xferred = xfer;
+		} else {
+#ifdef KBD_REPORT_TIMEOUTS
+			if (resend)
+				printk( __FILE__ ": Too many NACKs - Noisy keyboard cable?\n" );
+#endif
+			break;
+		}
+	}
+	up(&kbd_output_sema);
+
+	return len == xfer ? 0 : -ETIMEDOUT;
+}
+#endif /* CONFIG_PC_KEYB_FILTER */
+
+int register_pc_keyb_filter( struct pc_keyb_filter *filter )
+{
+#ifdef CONFIG_PC_KEYB_FILTER
+	unsigned long flags;
+	int retval = 0;
+
+	spin_lock_irqsave(&pc_keyb_filter_lock, flags);
+	if (PC_KEYB_MAX_FILTERS > num_filters) {
+		filters[num_filters++] = filter;
+		filter->write_data = send_data_buffer;
+	} else {
+		retval = -EDQUOT;
+	}
+	spin_unlock_irqrestore(&pc_keyb_filter_lock, flags);
+	return retval;
+#else
+	return -ENOSYS;
+#endif
+}
+
+void unregister_pc_keyb_filter( struct pc_keyb_filter *filter )
+{
+#ifdef CONFIG_PC_KEYB_FILTER
+	unsigned long flags;
+	int i, found = 0;
+
+	spin_lock_irqsave(&pc_keyb_filter_lock, flags);
+	filter->write_data = NULL;
+	for (i=0; i<num_filters; i++) {
+		if (filters[i] == filter)
+			found = 1;
+		if (found && i+1<PC_KEYB_MAX_FILTERS)
+			filters[i] = filters[i+1];
+	}
+	if (found)
+		filters[num_filters--] = NULL;
+	spin_unlock_irqrestore(&pc_keyb_filter_lock, flags);
+#endif
+}
+
+EXPORT_SYMBOL(register_pc_keyb_filter);
+EXPORT_SYMBOL(unregister_pc_keyb_filter);
+
 /*
  * Wait for keyboard controller input buffer to drain.
  *
@@ -428,6 +533,18 @@
 
 static inline void handle_keyboard_event(unsigned char scancode)
 {
+#ifdef CONFIG_PC_KEYB_FILTER
+	int i;
+
+	spin_lock(&pc_keyb_filter_lock);
+	for (i=0; i<num_filters; i++) {
+		if (filters[i]->filter_scancode( &scancode )) {
+			spin_unlock(&pc_keyb_filter_lock);
+			return;
+		}
+	}
+	spin_unlock(&pc_keyb_filter_lock);
+#endif /* CONFIG_PC_KEYB_FILTER */
 #ifdef CONFIG_VT
 	kbd_exists = 1;
 	if (do_acknowledge(scancode))
@@ -527,10 +644,17 @@
 
 void pckbd_leds(unsigned char leds)
 {
+#ifdef CONFIG_PC_KEYB_FILTER
+	if (down_interruptible(&kbd_output_sema))
+		return;
+#endif
 	if (kbd_exists && (!send_data(KBD_CMD_SET_LEDS) || !send_data(leds))) {
 		send_data(KBD_CMD_ENABLE);	/* re-enable kbd if any errors */
 		kbd_exists = 0;
 	}
+#ifdef CONFIG_PC_KEYB_FILTER
+	up(&kbd_output_sema);
+#endif
 }
 
 /*
diff -urN 2.4.5-clean/include/linux/pc_keyb.h linux/include/linux/pc_keyb.h
--- 2.4.5-clean/include/linux/pc_keyb.h	Mon Oct 11 13:15:40 1999
+++ linux/include/linux/pc_keyb.h	Fri Jun 15 13:34:18 2001
@@ -6,6 +6,11 @@
  *	(c) 1997 Martin Mares <mj@atrey.karlin.mff.cuni.cz>
  */
 
+#ifndef __PC_KEYB_H
+#define __PC_KEYB_H
+
+#ifdef __KERNEL__
+
 /*
  *	Configuration Switches
  */
@@ -128,3 +133,17 @@
 	struct fasync_struct *fasync;
 	unsigned char buf[AUX_BUF_SIZE];
 };
+
+#define PC_KEYB_MAX_FILTERS		1
+
+struct pc_keyb_filter {
+	int (*filter_scancode)( unsigned char *scancode );
+	int (*write_data)( unsigned char *data, unsigned int length, unsigned int *xferred, unsigned int retries, unsigned int timeout );
+};
+
+int register_pc_keyb_filter( struct pc_keyb_filter *filter );
+void unregister_pc_keyb_filter( struct pc_keyb_filter *filter );
+
+#endif /* __KERNEL__ */
+
+#endif /* __PC_KEYB_H */