kbfiltr question

How do I get the DeviceID (which keyboard) from inside the kbfiltr driver?

I am connecting multiple keyboard devices (USB barcode scanners), and
installing
a kbfiltr driver to intercept the input, which works great. Now I want to
be able to
tell which keyboard each keystroke is coming from. I get a UnitID from
InputDataStart
but this number changes every time I plug and unplug the usb keyboard (this
number
also resets on reboot). I need something more like the InstanceID that is
unique
for identical devices (same make/model device) and does not change when you
plug and unplug it. NOTE: I understand the Instance ID changes if you
plug the keyboard into a different USB port, I am not worried about this
case, but
plugging and unplugging from the SAME port does not change the InstanceID.

I am an experienced c# programmer, but am very new to C and device drivers.

I have read through ~90% of the DDK, but am still unsure how to move
forward.

Any help would be appreciated.

-Steven (Louis)

Maxim
Tue Sep 12 10:37:21 CDT 2006

> also resets on reboot). I need something more like the InstanceID that is
> unique
> for identical devices (same make/model device) and does not change when

Hardware ID is identical for identical devices.

Instance ID is the Unique ID from the USB config descriptor, it does not depend
on a port to which the keyboard is plugged. If the keyboard has no Unique ID in
the config descriptor - then Instance ID is some random junk, not dependent on
a port anyway.

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com

sleeper
Tue Sep 12 13:59:37 CDT 2006

Hey Louis, I am trying to intercept input from the keyboard as well and
I am having some difficulties. Would you be able to post some of the
changes that you made to the kbfiltr driver ? Also, the kbfiltr driver
in the Windows DDK is a lower filter driver correct? I need to
intercept keys from the i8042 PS2 controller, by default this is what
the kbfiltr driver is attaching to correct?

Thanks ahead of time.

Louis
Tue Sep 12 15:17:55 CDT 2006

Sleeper,

The kbdfiltr project with the DDK should work, right out of the box for you.
The inf file is set up for PS2 already.

If you want to cancel a particular keystroke then:

*InputDataConsumed = 1;
// and don't call the (*(PSERVICE_CALLBACK_ROUTINE) devExt-> .....

I believe that kbfiltr is an upper device filter.

Hope this helps.

-Louis


"sleeper" <TheFakeJon@gmail.com> wrote in message
news:1158087577.286841.304000@i42g2000cwa.googlegroups.com...
> Hey Louis, I am trying to intercept input from the keyboard as well and
> I am having some difficulties. Would you be able to post some of the
> changes that you made to the kbfiltr driver ? Also, the kbfiltr driver
> in the Windows DDK is a lower filter driver correct? I need to
> intercept keys from the i8042 PS2 controller, by default this is what
> the kbfiltr driver is attaching to correct?
>
> Thanks ahead of time.
>

Jonathan
Tue Sep 12 16:51:37 CDT 2006

Hey Louis,

do you know if there are any samples of keyboard filters that are lower
filter drivers? I thought kbfiltr was a lower filter driver because it
attaches directly to the i8042 controller. I wrote an upper filter not
too long ago and I attached directly to the keyboardclass device
driver.

I am a bit confused...

soviet_bloke
Tue Sep 12 17:55:17 CDT 2006


Hi mate

> do you know if there are any samples of keyboard filters that are lower
> filter drivers? I thought kbfiltr was a lower filter driver because it
> attaches directly to the i8042 controller. I wrote an upper filter not
> too long ago and I attached directly to the keyboardclass device

> I am a bit confused...

There is nothing confusing here - lower-level filters attach themselves
to port drivers, class drivers attach themselves to these filters, and
upper-level filter drivers attach themselves to class drivers. In other
words, terms "lower-level" and "upper-level"
describe the position of a filter driver on the stack in relation to
the class driver. In our case, kbdfilter is below kbdclass driver on
the stack, so that it is lower-level driver, and the one that you have
attached to kbdclass driver is upper-level one

Anton Bassov

Jonathan wrote:
> Hey Louis,
>
> do you know if there are any samples of keyboard filters that are lower
> filter drivers? I thought kbfiltr was a lower filter driver because it
> attaches directly to the i8042 controller. I wrote an upper filter not
> too long ago and I attached directly to the keyboardclass device
> driver.
>
> I am a bit confused...

Doron
Tue Sep 12 22:14:47 CDT 2006

the position is not always relative to the class driver. there are also
device level filters, the ordering is

[class upper filters]
[device upper filters]
FDO
[device lower filters]
[class lower filters]

kbfiltr is meant to be a device upper or class upper filter (below
kbdclass).

Using the UnitId is not good, nobody sets the value (all keyboards use 0).
The driver itself should not care about the device instance path, the app
that opens the device via a device interface can distinguish between each
instance of the interface using the device instance path.

d


--
Please do not send e-mail directly to this alias. this alias is for
newsgroup purposes only.
This posting is provided "AS IS" with no warranties, and confers no rights.


<soviet_bloke@hotmail.com> wrote in message
news:1158101716.810991.10340@i42g2000cwa.googlegroups.com...
>
> Hi mate
>
>> do you know if there are any samples of keyboard filters that are lower
>> filter drivers? I thought kbfiltr was a lower filter driver because it
>> attaches directly to the i8042 controller. I wrote an upper filter not
>> too long ago and I attached directly to the keyboardclass device
>
>> I am a bit confused...
>
> There is nothing confusing here - lower-level filters attach themselves
> to port drivers, class drivers attach themselves to these filters, and
> upper-level filter drivers attach themselves to class drivers. In other
> words, terms "lower-level" and "upper-level"
> describe the position of a filter driver on the stack in relation to
> the class driver. In our case, kbdfilter is below kbdclass driver on
> the stack, so that it is lower-level driver, and the one that you have
> attached to kbdclass driver is upper-level one
>
> Anton Bassov
>
> Jonathan wrote:
>> Hey Louis,
>>
>> do you know if there are any samples of keyboard filters that are lower
>> filter drivers? I thought kbfiltr was a lower filter driver because it
>> attaches directly to the i8042 controller. I wrote an upper filter not
>> too long ago and I attached directly to the keyboardclass device
>> driver.
>>
>> I am a bit confused...
>

soviet_bloke
Tue Sep 12 23:03:33 CDT 2006

Doron,

Certainly, my description is meant to be kind of indication , rather
than precise definition. In fact, it is not so easy to give a precise
definition of upper-level and lower-level filters, in the first place.
For example, how would you describe the filter in between Usbstor.sys
and Disk.sys - both are class drivers, and the latter is attached to
the former......


Anton Bassov


Doron Holan [MS] wrote:
> the position is not always relative to the class driver. there are also
> device level filters, the ordering is
>
> [class upper filters]
> [device upper filters]
> FDO
> [device lower filters]
> [class lower filters]
>
> kbfiltr is meant to be a device upper or class upper filter (below
> kbdclass).
>
> Using the UnitId is not good, nobody sets the value (all keyboards use 0).
> The driver itself should not care about the device instance path, the app
> that opens the device via a device interface can distinguish between each
> instance of the interface using the device instance path.
>
> d
>
>
> --
> Please do not send e-mail directly to this alias. this alias is for
> newsgroup purposes only.
> This posting is provided "AS IS" with no warranties, and confers no rights.
>
>
> <soviet_bloke@hotmail.com> wrote in message
> news:1158101716.810991.10340@i42g2000cwa.googlegroups.com...
> >
> > Hi mate
> >
> >> do you know if there are any samples of keyboard filters that are lower
> >> filter drivers? I thought kbfiltr was a lower filter driver because it
> >> attaches directly to the i8042 controller. I wrote an upper filter not
> >> too long ago and I attached directly to the keyboardclass device
> >
> >> I am a bit confused...
> >
> > There is nothing confusing here - lower-level filters attach themselves
> > to port drivers, class drivers attach themselves to these filters, and
> > upper-level filter drivers attach themselves to class drivers. In other
> > words, terms "lower-level" and "upper-level"
> > describe the position of a filter driver on the stack in relation to
> > the class driver. In our case, kbdfilter is below kbdclass driver on
> > the stack, so that it is lower-level driver, and the one that you have
> > attached to kbdclass driver is upper-level one
> >
> > Anton Bassov
> >
> > Jonathan wrote:
> >> Hey Louis,
> >>
> >> do you know if there are any samples of keyboard filters that are lower
> >> filter drivers? I thought kbfiltr was a lower filter driver because it
> >> attaches directly to the i8042 controller. I wrote an upper filter not
> >> too long ago and I attached directly to the keyboardclass device
> >> driver.
> >>
> >> I am a bit confused...
> >

Doron
Tue Sep 12 23:39:22 CDT 2006

you are confusing clas, which admitedly is overloaded. in terms of layers
in a pnp stack, a class driver is a dirver that is loaded by the
"UpperFilters" and "LowerFilters" reg values in the class keys in the
registry. this is the same class that the device's INF specifies.
kbdclass, mouclass, disk are all class drivers of this type.

A class driver like usbstor (or usbhub) is a driver that implements a
certain device class specification (that is usually standard). usbstor is
the FDO, as is usbhub.

d

--
Please do not send e-mail directly to this alias. this alias is for
newsgroup purposes only.
This posting is provided "AS IS" with no warranties, and confers no rights.


<soviet_bloke@hotmail.com> wrote in message
news:1158120213.112162.68950@i42g2000cwa.googlegroups.com...
> Doron,
>
> Certainly, my description is meant to be kind of indication , rather
> than precise definition. In fact, it is not so easy to give a precise
> definition of upper-level and lower-level filters, in the first place.
> For example, how would you describe the filter in between Usbstor.sys
> and Disk.sys - both are class drivers, and the latter is attached to
> the former......
>
>
> Anton Bassov
>
>
> Doron Holan [MS] wrote:
>> the position is not always relative to the class driver. there are also
>> device level filters, the ordering is
>>
>> [class upper filters]
>> [device upper filters]
>> FDO
>> [device lower filters]
>> [class lower filters]
>>
>> kbfiltr is meant to be a device upper or class upper filter (below
>> kbdclass).
>>
>> Using the UnitId is not good, nobody sets the value (all keyboards use
>> 0).
>> The driver itself should not care about the device instance path, the app
>> that opens the device via a device interface can distinguish between each
>> instance of the interface using the device instance path.
>>
>> d
>>
>>
>> --
>> Please do not send e-mail directly to this alias. this alias is for
>> newsgroup purposes only.
>> This posting is provided "AS IS" with no warranties, and confers no
>> rights.
>>
>>
>> <soviet_bloke@hotmail.com> wrote in message
>> news:1158101716.810991.10340@i42g2000cwa.googlegroups.com...
>> >
>> > Hi mate
>> >
>> >> do you know if there are any samples of keyboard filters that are
>> >> lower
>> >> filter drivers? I thought kbfiltr was a lower filter driver because
>> >> it
>> >> attaches directly to the i8042 controller. I wrote an upper filter
>> >> not
>> >> too long ago and I attached directly to the keyboardclass device
>> >
>> >> I am a bit confused...
>> >
>> > There is nothing confusing here - lower-level filters attach themselves
>> > to port drivers, class drivers attach themselves to these filters, and
>> > upper-level filter drivers attach themselves to class drivers. In other
>> > words, terms "lower-level" and "upper-level"
>> > describe the position of a filter driver on the stack in relation to
>> > the class driver. In our case, kbdfilter is below kbdclass driver on
>> > the stack, so that it is lower-level driver, and the one that you have
>> > attached to kbdclass driver is upper-level one
>> >
>> > Anton Bassov
>> >
>> > Jonathan wrote:
>> >> Hey Louis,
>> >>
>> >> do you know if there are any samples of keyboard filters that are
>> >> lower
>> >> filter drivers? I thought kbfiltr was a lower filter driver because
>> >> it
>> >> attaches directly to the i8042 controller. I wrote an upper filter
>> >> not
>> >> too long ago and I attached directly to the keyboardclass device
>> >> driver.
>> >>
>> >> I am a bit confused...
>> >
>

soviet_bloke
Wed Sep 13 01:18:19 CDT 2006

Doron,

> A class driver like usbstor (or usbhub) is a driver that implements a
> certain device class specification (that is usually standard). usbstor is
> the FDO, as is usbhub.

I am afraid usbhub is COMPLETELY irrelevant in this discussion -it just
enumerates devices, connected to USB, and reports them to PnP Manager.
Therefore, it is more of a bus driver, rather than FDO.....

Anton Bassov

Doron Holan [MS] wrote:
> you are confusing clas, which admitedly is overloaded. in terms of layers
> in a pnp stack, a class driver is a dirver that is loaded by the
> "UpperFilters" and "LowerFilters" reg values in the class keys in the
> registry. this is the same class that the device's INF specifies.
> kbdclass, mouclass, disk are all class drivers of this type.
>
> A class driver like usbstor (or usbhub) is a driver that implements a
> certain device class specification (that is usually standard). usbstor is
> the FDO, as is usbhub.
>
> d
>
> --
> Please do not send e-mail directly to this alias. this alias is for
> newsgroup purposes only.
> This posting is provided "AS IS" with no warranties, and confers no rights.
>
>
> <soviet_bloke@hotmail.com> wrote in message
> news:1158120213.112162.68950@i42g2000cwa.googlegroups.com...
> > Doron,
> >
> > Certainly, my description is meant to be kind of indication , rather
> > than precise definition. In fact, it is not so easy to give a precise
> > definition of upper-level and lower-level filters, in the first place.
> > For example, how would you describe the filter in between Usbstor.sys
> > and Disk.sys - both are class drivers, and the latter is attached to
> > the former......
> >
> >
> > Anton Bassov
> >
> >
> > Doron Holan [MS] wrote:
> >> the position is not always relative to the class driver. there are also
> >> device level filters, the ordering is
> >>
> >> [class upper filters]
> >> [device upper filters]
> >> FDO
> >> [device lower filters]
> >> [class lower filters]
> >>
> >> kbfiltr is meant to be a device upper or class upper filter (below
> >> kbdclass).
> >>
> >> Using the UnitId is not good, nobody sets the value (all keyboards use
> >> 0).
> >> The driver itself should not care about the device instance path, the app
> >> that opens the device via a device interface can distinguish between each
> >> instance of the interface using the device instance path.
> >>
> >> d
> >>
> >>
> >> --
> >> Please do not send e-mail directly to this alias. this alias is for
> >> newsgroup purposes only.
> >> This posting is provided "AS IS" with no warranties, and confers no
> >> rights.
> >>
> >>
> >> <soviet_bloke@hotmail.com> wrote in message
> >> news:1158101716.810991.10340@i42g2000cwa.googlegroups.com...
> >> >
> >> > Hi mate
> >> >
> >> >> do you know if there are any samples of keyboard filters that are
> >> >> lower
> >> >> filter drivers? I thought kbfiltr was a lower filter driver because
> >> >> it
> >> >> attaches directly to the i8042 controller. I wrote an upper filter
> >> >> not
> >> >> too long ago and I attached directly to the keyboardclass device
> >> >
> >> >> I am a bit confused...
> >> >
> >> > There is nothing confusing here - lower-level filters attach themselves
> >> > to port drivers, class drivers attach themselves to these filters, and
> >> > upper-level filter drivers attach themselves to class drivers. In other
> >> > words, terms "lower-level" and "upper-level"
> >> > describe the position of a filter driver on the stack in relation to
> >> > the class driver. In our case, kbdfilter is below kbdclass driver on
> >> > the stack, so that it is lower-level driver, and the one that you have
> >> > attached to kbdclass driver is upper-level one
> >> >
> >> > Anton Bassov
> >> >
> >> > Jonathan wrote:
> >> >> Hey Louis,
> >> >>
> >> >> do you know if there are any samples of keyboard filters that are
> >> >> lower
> >> >> filter drivers? I thought kbfiltr was a lower filter driver because
> >> >> it
> >> >> attaches directly to the i8042 controller. I wrote an upper filter
> >> >> not
> >> >> too long ago and I attached directly to the keyboardclass device
> >> >> driver.
> >> >>
> >> >> I am a bit confused...
> >> >
> >

Louis
Wed Sep 13 06:50:18 CDT 2006

Doron,

Thank you, I believe this helps clear up my confusion on how to get the
InstanceID (from within the application that will connect to the device
interface.)

Could you please point me to some information or examples that would show
how to:

1. Generate the appropriate interface functions in kbfiltr.
2. How to connect to the device (through this driver) in a C# application
(I'm sure it would be using PInvoke, but how would I hook in, what
functions?)

I have read the DDK through a couple of times, but am still quite hazy on
how it all works together.

I appreciate all your help.

Thank you.

-Louis

"Doron Holan [MS]" <doronh@nospam.microsoft.com> wrote in message
news:upTWGLu1GHA.4228@TK2MSFTNGP06.phx.gbl...
> the position is not always relative to the class driver. there are also
> device level filters, the ordering is
>
> [class upper filters]
> [device upper filters]
> FDO
> [device lower filters]
> [class lower filters]
>
> kbfiltr is meant to be a device upper or class upper filter (below
> kbdclass).
>
> Using the UnitId is not good, nobody sets the value (all keyboards use 0).
> The driver itself should not care about the device instance path, the app
> that opens the device via a device interface can distinguish between each
> instance of the interface using the device instance path.
>
> d
>
>
> --
> Please do not send e-mail directly to this alias. this alias is for
> newsgroup purposes only.
> This posting is provided "AS IS" with no warranties, and confers no
> rights.
>
>
> <soviet_bloke@hotmail.com> wrote in message
> news:1158101716.810991.10340@i42g2000cwa.googlegroups.com...
>>
>> Hi mate
>>
>>> do you know if there are any samples of keyboard filters that are lower
>>> filter drivers? I thought kbfiltr was a lower filter driver because it
>>> attaches directly to the i8042 controller. I wrote an upper filter not
>>> too long ago and I attached directly to the keyboardclass device
>>
>>> I am a bit confused...
>>
>> There is nothing confusing here - lower-level filters attach themselves
>> to port drivers, class drivers attach themselves to these filters, and
>> upper-level filter drivers attach themselves to class drivers. In other
>> words, terms "lower-level" and "upper-level"
>> describe the position of a filter driver on the stack in relation to
>> the class driver. In our case, kbdfilter is below kbdclass driver on
>> the stack, so that it is lower-level driver, and the one that you have
>> attached to kbdclass driver is upper-level one
>>
>> Anton Bassov
>>
>> Jonathan wrote:
>>> Hey Louis,
>>>
>>> do you know if there are any samples of keyboard filters that are lower
>>> filter drivers? I thought kbfiltr was a lower filter driver because it
>>> attaches directly to the i8042 controller. I wrote an upper filter not
>>> too long ago and I attached directly to the keyboardclass device
>>> driver.
>>>
>>> I am a bit confused...
>>
>
>

Maxim
Wed Sep 13 08:45:29 CDT 2006

> changes that you made to the kbfiltr driver ? Also, the kbfiltr driver
> in the Windows DDK is a lower filter driver correct? I need to

kbfiltr sample contains 2 parts - one is generic keyboard filter (upper), and
another is PS/2 specific part, which talks to PS/2 hardware via the IOCTLs
provided by i8042prt and function pointer exchange.

The i8042-specific part is provided mainly for the hardware daisy-chained to
PS/2 port, or for heavily non-standard PS/2 keyboards.

If you want to filter keypresses - then just throw away all PS/2 specifics from
kbfiltr and install it as upper class filter for Keyboard class, but below
kbdclass (which is a mandatory upper filter for any keyboard stack).

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com

Maxim
Wed Sep 13 08:47:41 CDT 2006

> the class driver. In our case, kbdfilter is below kbdclass driver on
> the stack, so that it is lower-level driver

No. Kbfiltr is below kbdclass, but kbdclass is an upper filter by itself. The
functional driver for keyboard stack is either kbdhid or i8042prt. The PDO
driver (bus driver) is either hidclass or ACPI or root (the latter 2 cases are
for PS/2 hardware).

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com

Maxim
Wed Sep 13 08:50:06 CDT 2006

> [class upper filters]
> [device upper filters]
> FDO
> [device lower filters]
> [class lower filters]

No, device lower filters are lower then class lower filters. For instance,
IMAPI is a device lower filter for CD stacks, and no class lower filter can
occur below IMAPI and filter the IMAPI-generated requests.

One need a device lower filter, installed for each device below IMAPI, to
filter IMAPI's requests.

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com

Maxim
Wed Sep 13 08:52:14 CDT 2006

> For example, how would you describe the filter in between Usbstor.sys
> and Disk.sys - both are class drivers, and the latter is attached to
> the former......

USBSTOR is a functional driver for USB devnode, and is also a bus driver which
creates a LUN PDO - as each storage port should do. Look at Device Manager's
tree for the USB-attached disk device - flash pendrive or external hard disk.

So, in LUN PDO stack, USBSTOR is a bus driver, your filter will be lower
filter, and Disk+ClassPnP couple is a functional driver.

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com

Maxim
Wed Sep 13 08:54:10 CDT 2006

> I am afraid usbhub is COMPLETELY irrelevant in this discussion -it just
> enumerates devices, connected to USB, and reports them to PnP Manager.
> Therefore, it is more of a bus driver, rather than FDO.....

Both. It is a FDO on the devnode for hub itself, and is a bus driver for
devices attached to this hub.

In fact, nearly any bus driver is also a functional driver (in the parent
devnode), sometimes an upper filter driver in the same devnode.

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com

Louis
Wed Sep 13 09:35:44 CDT 2006

What I'm trying to do is:

1. Intercept all input from the USB scanners.
I can get and cancel the key presses in the KbFilter_ServiceCallback
from the DDK example. I do not want the keystrokes to be handled
by windows. One of the objectives is to have all other applications
ignore input from the barcode scanners.

2. Package the keystrokes as a character and an Instance ID (instances
of the same make/model USB Scanner).

3. Send this information on to a GUI application I write in C#.

It sounds like I should let the GUI application (C#) handle getting the
InstanceID's
through the DeviceInterface.

How do I communicate with the kbfiltr driver from my GUI application?

Ideally, I would want the driver to notify my C# application with every
keystroke.

Do I implement a function that handles "IRP_MJ_DEVICE_CONTROL"?

Would I poll the driver for data (I'd rather not poll, but this is fine if
there is no
other solution)?

Right now the keystrokes are handled (written to DbgPrint) in the handler
for "IRP_MJ_INTERNAL_DEVICE_CONTROL"

How do I get the keystrokes from there to somewhere I can pass them on to
the
GUI application?

From C#, when I am connected to the device, is there a way to get to the
InstanceID
in the registry with the information available from the connection to the
device?

Any help would be appreciated.

Thanks,

-Louis

Doron
Wed Sep 13 09:53:46 CDT 2006

anton, you have a bit of learning to do. just b/c usbhub is a bus driver
does not mean it is not an FDO. the way a hub works is defined by a class
specification and the driver conforms to that spec for detecting and
enumerating device changes

d

--
Please do not send e-mail directly to this alias. this alias is for
newsgroup purposes only.
This posting is provided "AS IS" with no warranties, and confers no rights.


<soviet_bloke@hotmail.com> wrote in message
news:1158128299.703913.150110@i42g2000cwa.googlegroups.com...
> Doron,
>
>> A class driver like usbstor (or usbhub) is a driver that implements a
>> certain device class specification (that is usually standard). usbstor
>> is
>> the FDO, as is usbhub.
>
> I am afraid usbhub is COMPLETELY irrelevant in this discussion -it just
> enumerates devices, connected to USB, and reports them to PnP Manager.
> Therefore, it is more of a bus driver, rather than FDO.....
>
> Anton Bassov
>
> Doron Holan [MS] wrote:
>> you are confusing clas, which admitedly is overloaded. in terms of
>> layers
>> in a pnp stack, a class driver is a dirver that is loaded by the
>> "UpperFilters" and "LowerFilters" reg values in the class keys in the
>> registry. this is the same class that the device's INF specifies.
>> kbdclass, mouclass, disk are all class drivers of this type.
>>
>> A class driver like usbstor (or usbhub) is a driver that implements a
>> certain device class specification (that is usually standard). usbstor
>> is
>> the FDO, as is usbhub.
>>
>> d
>>
>> --
>> Please do not send e-mail directly to this alias. this alias is for
>> newsgroup purposes only.
>> This posting is provided "AS IS" with no warranties, and confers no
>> rights.
>>
>>
>> <soviet_bloke@hotmail.com> wrote in message
>> news:1158120213.112162.68950@i42g2000cwa.googlegroups.com...
>> > Doron,
>> >
>> > Certainly, my description is meant to be kind of indication , rather
>> > than precise definition. In fact, it is not so easy to give a precise
>> > definition of upper-level and lower-level filters, in the first place.
>> > For example, how would you describe the filter in between Usbstor.sys
>> > and Disk.sys - both are class drivers, and the latter is attached to
>> > the former......
>> >
>> >
>> > Anton Bassov
>> >
>> >
>> > Doron Holan [MS] wrote:
>> >> the position is not always relative to the class driver. there are
>> >> also
>> >> device level filters, the ordering is
>> >>
>> >> [class upper filters]
>> >> [device upper filters]
>> >> FDO
>> >> [device lower filters]
>> >> [class lower filters]
>> >>
>> >> kbfiltr is meant to be a device upper or class upper filter (below
>> >> kbdclass).
>> >>
>> >> Using the UnitId is not good, nobody sets the value (all keyboards use
>> >> 0).
>> >> The driver itself should not care about the device instance path, the
>> >> app
>> >> that opens the device via a device interface can distinguish between
>> >> each
>> >> instance of the interface using the device instance path.
>> >>
>> >> d
>> >>
>> >>
>> >> --
>> >> Please do not send e-mail directly to this alias. this alias is for
>> >> newsgroup purposes only.
>> >> This posting is provided "AS IS" with no warranties, and confers no
>> >> rights.
>> >>
>> >>
>> >> <soviet_bloke@hotmail.com> wrote in message
>> >> news:1158101716.810991.10340@i42g2000cwa.googlegroups.com...
>> >> >
>> >> > Hi mate
>> >> >
>> >> >> do you know if there are any samples of keyboard filters that are
>> >> >> lower
>> >> >> filter drivers? I thought kbfiltr was a lower filter driver
>> >> >> because
>> >> >> it
>> >> >> attaches directly to the i8042 controller. I wrote an upper filter
>> >> >> not
>> >> >> too long ago and I attached directly to the keyboardclass device
>> >> >
>> >> >> I am a bit confused...
>> >> >
>> >> > There is nothing confusing here - lower-level filters attach
>> >> > themselves
>> >> > to port drivers, class drivers attach themselves to these filters,
>> >> > and
>> >> > upper-level filter drivers attach themselves to class drivers. In
>> >> > other
>> >> > words, terms "lower-level" and "upper-level"
>> >> > describe the position of a filter driver on the stack in relation to
>> >> > the class driver. In our case, kbdfilter is below kbdclass driver on
>> >> > the stack, so that it is lower-level driver, and the one that you
>> >> > have
>> >> > attached to kbdclass driver is upper-level one
>> >> >
>> >> > Anton Bassov
>> >> >
>> >> > Jonathan wrote:
>> >> >> Hey Louis,
>> >> >>
>> >> >> do you know if there are any samples of keyboard filters that are
>> >> >> lower
>> >> >> filter drivers? I thought kbfiltr was a lower filter driver
>> >> >> because
>> >> >> it
>> >> >> attaches directly to the i8042 controller. I wrote an upper filter
>> >> >> not
>> >> >> too long ago and I attached directly to the keyboardclass device
>> >> >> driver.
>> >> >>
>> >> >> I am a bit confused...
>> >> >
>> >
>

Doron
Wed Sep 13 09:52:57 CDT 2006

download KMDF, http://www.microsoft.com/whdc/driver/wdf/KMDF_pkg.mspx (or
get the WDK), and look at the KMDF kbfiltr example. it enumerates a PDO for
each keyboard. each pdo can have a device interface. KMDF allows you to
easily pend an IOCTL and complete it when you have data. much easier then
WDM

d

--
Please do not send e-mail directly to this alias. this alias is for
newsgroup purposes only.
This posting is provided "AS IS" with no warranties, and confers no rights.


"Louis Cypher" <louiscypher@dodgeit.com> wrote in message
news:%2321KaG01GHA.328@TK2MSFTNGP06.phx.gbl...
> What I'm trying to do is:
>
> 1. Intercept all input from the USB scanners.
> I can get and cancel the key presses in the
> KbFilter_ServiceCallback
> from the DDK example. I do not want the keystrokes to be handled
> by windows. One of the objectives is to have all other
> applications
> ignore input from the barcode scanners.
>
> 2. Package the keystrokes as a character and an Instance ID (instances
> of the same make/model USB Scanner).
>
> 3. Send this information on to a GUI application I write in C#.
>
> It sounds like I should let the GUI application (C#) handle getting the
> InstanceID's
> through the DeviceInterface.
>
> How do I communicate with the kbfiltr driver from my GUI application?
>
> Ideally, I would want the driver to notify my C# application with every
> keystroke.
>
> Do I implement a function that handles "IRP_MJ_DEVICE_CONTROL"?
>
> Would I poll the driver for data (I'd rather not poll, but this is fine if
> there is no
> other solution)?
>
> Right now the keystrokes are handled (written to DbgPrint) in the handler
> for "IRP_MJ_INTERNAL_DEVICE_CONTROL"
>
> How do I get the keystrokes from there to somewhere I can pass them on to
> the
> GUI application?
>
> From C#, when I am connected to the device, is there a way to get to the
> InstanceID
> in the registry with the information available from the connection to the
> device?
>
> Any help would be appreciated.
>
> Thanks,
>
> -Louis
>

Ian
Wed Sep 13 11:54:11 CDT 2006

On 12/09/2006 12:48, Louis Cypher wrote:
> How do I get the DeviceID (which keyboard) from inside the kbfiltr driver?
>
> I am connecting multiple keyboard devices (USB barcode scanners), and
> installing
> a kbfiltr driver to intercept the input, which works great. Now I want to
> be able to
> tell which keyboard each keystroke is coming from. I get a UnitID from
> InputDataStart
> but this number changes every time I plug and unplug the usb keyboard (this
> number
> also resets on reboot). I need something more like the InstanceID that is
> unique
> for identical devices (same make/model device) and does not change when you
> plug and unplug it. NOTE: I understand the Instance ID changes if you
> plug the keyboard into a different USB port, I am not worried about this
> case, but
> plugging and unplugging from the SAME port does not change the InstanceID.

If Windows can tell uniquely identify a particular keyboard (by USB
serial number, if it has one), you should be able to distinguish it from
similar devices. Experiment with DevicePropertyPhysicalDeviceObjectName
and DevicePropertyDriverKeyName. The latter would only be unique while
the device remains installed (but not necessarily connected), as a
subsequently installed device could take on the
DevicePropertyDriverKeyName of a device previously uninstalled.

soviet_bloke
Wed Sep 13 13:40:22 CDT 2006

Doron,

> anton, you have a bit of learning to do. just b/c usbhub is a bus driver
> does not mean it is not an FDO. the way a hub works is defined by a class
> specification and the driver conforms to that spec for detecting and
> enumerating device changes

In fact, I just love learning things, but MSDN is so confusing when it
comes to terminology....

What I have learnt from this particular discussion is that I should use
terms "bus driver" and "class driver" if and only if I speak about PnP
sequence. When speaking about what the driver in question actually
does, as long as it implements some certain device class
specification, I should refer to it as to " function driver", no matter
if it acts as a class driver or as a bus one for the devices that it
manages



Anton Bassov


Doron Holan [MS] wrote:
> anton, you have a bit of learning to do. just b/c usbhub is a bus driver
> does not mean it is not an FDO. the way a hub works is defined by a class
> specification and the driver conforms to that spec for detecting and
> enumerating device changes
>
> d
>
> --
> Please do not send e-mail directly to this alias. this alias is for
> newsgroup purposes only.
> This posting is provided "AS IS" with no warranties, and confers no rights.
>
>
> <soviet_bloke@hotmail.com> wrote in message
> news:1158128299.703913.150110@i42g2000cwa.googlegroups.com...
> > Doron,
> >
> >> A class driver like usbstor (or usbhub) is a driver that implements a
> >> certain device class specification (that is usually standard). usbstor
> >> is
> >> the FDO, as is usbhub.
> >
> > I am afraid usbhub is COMPLETELY irrelevant in this discussion -it just
> > enumerates devices, connected to USB, and reports them to PnP Manager.
> > Therefore, it is more of a bus driver, rather than FDO.....
> >
> > Anton Bassov
> >
> > Doron Holan [MS] wrote:
> >> you are confusing clas, which admitedly is overloaded. in terms of
> >> layers
> >> in a pnp stack, a class driver is a dirver that is loaded by the
> >> "UpperFilters" and "LowerFilters" reg values in the class keys in the
> >> registry. this is the same class that the device's INF specifies.
> >> kbdclass, mouclass, disk are all class drivers of this type.
> >>
> >> A class driver like usbstor (or usbhub) is a driver that implements a
> >> certain device class specification (that is usually standard). usbstor
> >> is
> >> the FDO, as is usbhub.
> >>
> >> d
> >>
> >> --
> >> Please do not send e-mail directly to this alias. this alias is for
> >> newsgroup purposes only.
> >> This posting is provided "AS IS" with no warranties, and confers no
> >> rights.
> >>
> >>
> >> <soviet_bloke@hotmail.com> wrote in message
> >> news:1158120213.112162.68950@i42g2000cwa.googlegroups.com...
> >> > Doron,
> >> >
> >> > Certainly, my description is meant to be kind of indication , rather
> >> > than precise definition. In fact, it is not so easy to give a precise
> >> > definition of upper-level and lower-level filters, in the first place.
> >> > For example, how would you describe the filter in between Usbstor.sys
> >> > and Disk.sys - both are class drivers, and the latter is attached to
> >> > the former......
> >> >
> >> >
> >> > Anton Bassov
> >> >
> >> >
> >> > Doron Holan [MS] wrote:
> >> >> the position is not always relative to the class driver. there are
> >> >> also
> >> >> device level filters, the ordering is
> >> >>
> >> >> [class upper filters]
> >> >> [device upper filters]
> >> >> FDO
> >> >> [device lower filters]
> >> >> [class lower filters]
> >> >>
> >> >> kbfiltr is meant to be a device upper or class upper filter (below
> >> >> kbdclass).
> >> >>
> >> >> Using the UnitId is not good, nobody sets the value (all keyboards use
> >> >> 0).
> >> >> The driver itself should not care about the device instance path, the
> >> >> app
> >> >> that opens the device via a device interface can distinguish between
> >> >> each
> >> >> instance of the interface using the device instance path.
> >> >>
> >> >> d
> >> >>
> >> >>
> >> >> --
> >> >> Please do not send e-mail directly to this alias. this alias is for
> >> >> newsgroup purposes only.
> >> >> This posting is provided "AS IS" with no warranties, and confers no
> >> >> rights.
> >> >>
> >> >>
> >> >> <soviet_bloke@hotmail.com> wrote in message
> >> >> news:1158101716.810991.10340@i42g2000cwa.googlegroups.com...
> >> >> >
> >> >> > Hi mate
> >> >> >
> >> >> >> do you know if there are any samples of keyboard filters that are
> >> >> >> lower
> >> >> >> filter drivers? I thought kbfiltr was a lower filter driver
> >> >> >> because
> >> >> >> it
> >> >> >> attaches directly to the i8042 controller. I wrote an upper filter
> >> >> >> not
> >> >> >> too long ago and I attached directly to the keyboardclass device
> >> >> >
> >> >> >> I am a bit confused...
> >> >> >
> >> >> > There is nothing confusing here - lower-level filters attach
> >> >> > themselves
> >> >> > to port drivers, class drivers attach themselves to these filters,
> >> >> > and
> >> >> > upper-level filter drivers attach themselves to class drivers. In
> >> >> > other
> >> >> > words, terms "lower-level" and "upper-level"
> >> >> > describe the position of a filter driver on the stack in relation to
> >> >> > the class driver. In our case, kbdfilter is below kbdclass driver on
> >> >> > the stack, so that it is lower-level driver, and the one that you
> >> >> > have
> >> >> > attached to kbdclass driver is upper-level one
> >> >> >
> >> >> > Anton Bassov
> >> >> >
> >> >> > Jonathan wrote:
> >> >> >> Hey Louis,
> >> >> >>
> >> >> >> do you know if there are any samples of keyboard filters that are
> >> >> >> lower
> >> >> >> filter drivers? I thought kbfiltr was a lower filter driver
> >> >> >> because
> >> >> >> it
> >> >> >> attaches directly to the i8042 controller. I wrote an upper filter
> >> >> >> not
> >> >> >> too long ago and I attached directly to the keyboardclass device
> >> >> >> driver.
> >> >> >>
> >> >> >> I am a bit confused...
> >> >> >
> >> >
> >

Doron
Wed Sep 13 21:51:28 CDT 2006

thanks for the correction, class lower filters are layered on top of device
lower filters.

d

--
Please do not send e-mail directly to this alias. this alias is for
newsgroup purposes only.
This posting is provided "AS IS" with no warranties, and confers no rights.


"Maxim S. Shatskih" <maxim@storagecraft.com> wrote in message
news:ezYoFuz1GHA.3644@TK2MSFTNGP03.phx.gbl...
>> [class upper filters]
>> [device upper filters]
>> FDO
>> [device lower filters]
>> [class lower filters]
>
> No, device lower filters are lower then class lower filters. For instance,
> IMAPI is a device lower filter for CD stacks, and no class lower filter
> can
> occur below IMAPI and filter the IMAPI-generated requests.
>
> One need a device lower filter, installed for each device below IMAPI, to
> filter IMAPI's requests.
>
> --
> Maxim Shatskih, Windows DDK MVP
> StorageCraft Corporation
> maxim@storagecraft.com
> http://www.storagecraft.com
>

Louis
Thu Sep 14 09:01:04 CDT 2006

Hey, I feel like I'm making some progress with the WDM user
mode filter driver.

However I'm having trouble using 'malloc' and 'free'. It passes the
compile, but I get a:

1>kbfiltr.obj : error LNK2019: unresolved external symbol __imp__free
referenced in function _KbFilter_ServiceCallback@16
1>kbfiltr.obj : error LNK2019: unresolved external symbol __imp__malloc
referenced in function _KbFilter_ServiceCallback@16

In the link step.

Here's part of the code. Any ideas what I'm missing. Just so you know, I
am opening the registry
to retrieve the Device Instance ID so that I can associate keystrokes with a
specific device. I can
then send these keystroke characters to a C# application.

#include <stdlib.h>

...


HANDLE hKey;
NTSTATUS status;
int lBuff;
char* outBuffer;

//Open the registry key for this device
status = IoOpenDeviceRegistryKey( DeviceObject,
PLUGPLAY_REGKEY_DEVICE,
STANDARD_RIGHTS_ALL,
&hKey);

//Get the buffer size
status = ZwQueryKey( &hKey,
0,
0,
0,
&lBuff);

//Allocate space for the registry key information
outBuffer = (char*)malloc(lBuff);

status = ZwQueryKey( &hKey,
0,
outBuffer,
lBuff,
&lBuff);

//Close the handle
status = ZwCloseKey(&hKey);

//... Do something with the registry information here...

free(outBuffer);

...

Doron
Thu Sep 14 09:58:18 CDT 2006

free/malloc do not exist in the kernel. ExAllocatePoolWithTag/ExFreePool is
what you should use. if you want to read a reg value, you need to use
ZwQueryValueKey, not ZwQueryKey. You should really look at KMDF, alot of
this is simplified for you. Also, you cannot access the registry from the
service callback, you can only touch the registry at IRQL == PASSIVE_LEVEL

d

--
Please do not send e-mail directly to this alias. this alias is for
newsgroup purposes only.
This posting is provided "AS IS" with no warranties, and confers no rights.


"Louis Cypher" <louiscypher@dodgeit.com> wrote in message
news:u7LKsXA2GHA.4108@TK2MSFTNGP04.phx.gbl...
> Hey, I feel like I'm making some progress with the WDM user
> mode filter driver.
>
> However I'm having trouble using 'malloc' and 'free'. It passes the
> compile, but I get a:
>
> 1>kbfiltr.obj : error LNK2019: unresolved external symbol __imp__free
> referenced in function _KbFilter_ServiceCallback@16
> 1>kbfiltr.obj : error LNK2019: unresolved external symbol __imp__malloc
> referenced in function _KbFilter_ServiceCallback@16
>
> In the link step.
>
> Here's part of the code. Any ideas what I'm missing. Just so you know, I
> am opening the registry
> to retrieve the Device Instance ID so that I can associate keystrokes with
> a specific device. I can
> then send these keystroke characters to a C# application.
>
> #include <stdlib.h>
>
> ...
>
>
> HANDLE hKey;
> NTSTATUS status;
> int lBuff;
> char* outBuffer;
>
> //Open the registry key for this device
> status = IoOpenDeviceRegistryKey( DeviceObject,
>
> PLUGPLAY_REGKEY_DEVICE,
>
> STANDARD_RIGHTS_ALL,
> &hKey);
>
> //Get the buffer size
> status = ZwQueryKey( &hKey,
> 0,
> 0,
> 0,
> &lBuff);
>
> //Allocate space for the registry key information
> outBuffer = (char*)malloc(lBuff);
>
> status = ZwQueryKey( &hKey,
> 0,
> outBuffer,
> lBuff,
> &lBuff);
>
> //Close the handle
> status = ZwCloseKey(&hKey);
>
> //... Do something with the registry information here...
>
> free(outBuffer);
>
> ...
>

Maxim
Thu Sep 14 10:22:15 CDT 2006

How can kbfiltr be user mode?

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com

"Louis Cypher" <louiscypher@dodgeit.com> wrote in message
news:u7LKsXA2GHA.4108@TK2MSFTNGP04.phx.gbl...
> Hey, I feel like I'm making some progress with the WDM user
> mode filter driver.
>
> However I'm having trouble using 'malloc' and 'free'. It passes the
> compile, but I get a:
>
> 1>kbfiltr.obj : error LNK2019: unresolved external symbol __imp__free
> referenced in function _KbFilter_ServiceCallback@16
> 1>kbfiltr.obj : error LNK2019: unresolved external symbol __imp__malloc
> referenced in function _KbFilter_ServiceCallback@16
>
> In the link step.
>
> Here's part of the code. Any ideas what I'm missing. Just so you know, I
> am opening the registry
> to retrieve the Device Instance ID so that I can associate keystrokes with a
> specific device. I can
> then send these keystroke characters to a C# application.
>
> #include <stdlib.h>
>
> ...
>
>
> HANDLE hKey;
> NTSTATUS status;
> int lBuff;
> char* outBuffer;
>
> //Open the registry key for this device
> status = IoOpenDeviceRegistryKey( DeviceObject,
>
PLUGPLAY_REGKEY_DEVICE,
>
STANDARD_RIGHTS_ALL,
> &hKey);
>
> //Get the buffer size
> status = ZwQueryKey( &hKey,
> 0,
> 0,
> 0,
> &lBuff);
>
> //Allocate space for the registry key information
> outBuffer = (char*)malloc(lBuff);
>
> status = ZwQueryKey( &hKey,
> 0,
> outBuffer,
> lBuff,
> &lBuff);
>
> //Close the handle
> status = ZwCloseKey(&hKey);
>
> //... Do something with the registry information here...
>
> free(outBuffer);
>
> ...
>
>