Trapping Keyboard/Mouse data
in [Device Drivers]
|
From: genob on 31 Oct 2005 14:20 I am currently working on a product that requires full access to the keyboard and mouse information from the drivers. We are only concerned with USB since we are building custom devices that are running XP Embedded with no PS/2 functionality. My knowledge on this subject: I have written quite a few USB HID drivers for WinCE and quite a few USB drivers for Win2k/XP... I have a really good understanding of the in's and out's of USB so that's not a problem.... Problem: We need to be able to trap all of the input on the device, and make the decision of passing it to windows, or throwing it away... I've tried to understand the whole HID class driver system in Windows XP but it seems like there are dead ends everywhere in the DDK. The question is, what level of driver can I create for the HID subsystem where I can read and stop key events? I keep reading about mini drivers, vs. class drivers, vs. filter driver.... Where is this possible in the HID subsystem? I'm about 2 seconds away from just writing my own hid driver for our device. If I have to write my own driver, how can I get key/mouse data to the high level via kernel mode? Thanks, Geno Bisceglia
From: Ray Trent on 31 Oct 2005 18:08 The easiest thing to do is probably to write a mouclass/kbdclass lower filter driver, as those are easy to install and will catch all mice/keyboards. Alternately, you can write upper or lower filter drivers for your specific devices and install them on those particular devices. The real question becomes what problem you're actually trying to solve. This kind of hack is rarely a good idea. Why do you want to break the user's keyboard and mouse? genob wrote: > I am currently working on a product that requires full access to the > keyboard and mouse information from the drivers. > > We are only concerned with USB since we are building custom devices > that are running XP Embedded with no PS/2 functionality. > > My knowledge on this subject: > > I have written quite a few USB HID drivers for WinCE and quite a few > USB drivers for Win2k/XP... I have a really good understanding of the > in's and out's of USB so that's not a problem.... > > Problem: > > We need to be able to trap all of the input on the device, and make > the decision of passing it to windows, or throwing it away... > > I've tried to understand the whole HID class driver system in Windows > XP but it seems like there are dead ends everywhere in the DDK. > > The question is, what level of driver can I create for the HID > subsystem where I can read and stop key events? I keep reading about > mini drivers, vs. class drivers, vs. filter driver.... Where is this > possible in the HID subsystem? > > I'm about 2 seconds away from just writing my own hid driver for our > device. > > If I have to write my own driver, how can I get key/mouse data to the > high level via kernel mode? > > Thanks, > > Geno Bisceglia -- Ray
From: genob on 1 Nov 2005 10:03 We make devices that are Handicap Accessible devices... We have full control of the OS via our Windows XP Embedded build. We're not really many other apps, but we do need the ability to trap keys from the low level to fully control windows. We've experimented with LLHook functions but the problem is, if they run another Accessible app that uses that function, we will lose control of the device... We have users that scan windows with single switches, or other things like that... I'm fully aware that doing this is a hack, but Windows doesn't provide a way to exclusively trap the keyboard (which makes sense because people can/will write malicious code to take advantage of that). Plus the functions that "sort of work" don't trap CTL-ALT-DELETE or ALT-TAB... the latter key sequence we need so we can easily scan the running apps. Anyway, I'm going to look into kbdclass/mouclass stuff. Thanks for your input! g On Mon, 31 Oct 2005 15:08:52 -0800, Ray Trent <rat(a)nospam.nospam> wrote: >The easiest thing to do is probably to write a mouclass/kbdclass lower >filter driver, as those are easy to install and will catch all >mice/keyboards. Alternately, you can write upper or lower filter drivers >for your specific devices and install them on those particular devices. > >The real question becomes what problem you're actually trying to solve. >This kind of hack is rarely a good idea. Why do you want to break the >user's keyboard and mouse? > >genob wrote: >> I am currently working on a product that requires full access to the >> keyboard and mouse information from the drivers. >> >> We are only concerned with USB since we are building custom devices >> that are running XP Embedded with no PS/2 functionality. >> >> My knowledge on this subject: >> >> I have written quite a few USB HID drivers for WinCE and quite a few >> USB drivers for Win2k/XP... I have a really good understanding of the >> in's and out's of USB so that's not a problem.... >> >> Problem: >> >> We need to be able to trap all of the input on the device, and make >> the decision of passing it to windows, or throwing it away... >> >> I've tried to understand the whole HID class driver system in Windows >> XP but it seems like there are dead ends everywhere in the DDK. >> >> The question is, what level of driver can I create for the HID >> subsystem where I can read and stop key events? I keep reading about >> mini drivers, vs. class drivers, vs. filter driver.... Where is this >> possible in the HID subsystem? >> >> I'm about 2 seconds away from just writing my own hid driver for our >> device. >> >> If I have to write my own driver, how can I get key/mouse data to the >> high level via kernel mode? >> >> Thanks, >> >> Geno Bisceglia
From: Ray Trent on 1 Nov 2005 12:29 You probably want to look at the moufiltr and kbfiltr samples. A mouclass/kbdclass lower filter is much like these except it's installed slightly differently (in the simplest case, just by inserting a value into the appropriate LowerFilters registry keys). genob wrote: > We make devices that are Handicap Accessible devices... We have full > control of the OS via our Windows XP Embedded build. We're not really > many other apps, but we do need the ability to trap keys from the low > level to fully control windows. > > We've experimented with LLHook functions but the problem is, if they > run another Accessible app that uses that function, we will lose > control of the device... > > We have users that scan windows with single switches, or other things > like that... > > I'm fully aware that doing this is a hack, but Windows doesn't provide > a way to exclusively trap the keyboard (which makes sense because > people can/will write malicious code to take advantage of that). Plus > the functions that "sort of work" don't trap CTL-ALT-DELETE or > ALT-TAB... the latter key sequence we need so we can easily scan the > running apps. > > Anyway, I'm going to look into kbdclass/mouclass stuff. > > Thanks for your input! > > g > > > On Mon, 31 Oct 2005 15:08:52 -0800, Ray Trent <rat(a)nospam.nospam> > wrote: > >> The easiest thing to do is probably to write a mouclass/kbdclass lower >> filter driver, as those are easy to install and will catch all >> mice/keyboards. Alternately, you can write upper or lower filter drivers >> for your specific devices and install them on those particular devices. >> >> The real question becomes what problem you're actually trying to solve. >> This kind of hack is rarely a good idea. Why do you want to break the >> user's keyboard and mouse? >> >> genob wrote: >>> I am currently working on a product that requires full access to the >>> keyboard and mouse information from the drivers. >>> >>> We are only concerned with USB since we are building custom devices >>> that are running XP Embedded with no PS/2 functionality. >>> >>> My knowledge on this subject: >>> >>> I have written quite a few USB HID drivers for WinCE and quite a few >>> USB drivers for Win2k/XP... I have a really good understanding of the >>> in's and out's of USB so that's not a problem.... >>> >>> Problem: >>> >>> We need to be able to trap all of the input on the device, and make >>> the decision of passing it to windows, or throwing it away... >>> >>> I've tried to understand the whole HID class driver system in Windows >>> XP but it seems like there are dead ends everywhere in the DDK. >>> >>> The question is, what level of driver can I create for the HID >>> subsystem where I can read and stop key events? I keep reading about >>> mini drivers, vs. class drivers, vs. filter driver.... Where is this >>> possible in the HID subsystem? >>> >>> I'm about 2 seconds away from just writing my own hid driver for our >>> device. >>> >>> If I have to write my own driver, how can I get key/mouse data to the >>> high level via kernel mode? >>> >>> Thanks, >>> >>> Geno Bisceglia > -- Ray
From: genob on 1 Nov 2005 14:21 I've worked with the moufiltr about 2 years ago, and found that I have to install it everytime I plug in a new mouse... i'm sure there is probably a way to do this in an automated fasion... The kbdclass/mouclass seems to be the direction I want to head in... I was able to build the kbdclass driver (sample code from MS), but everytime I overwrite it in WINDOWS/SYSTEM32/DRIVERS and reboot, Windows (XP) keeps replacing it with the original driver.... i'll keep digging :) g On Tue, 01 Nov 2005 09:29:45 -0800, Ray Trent <rat(a)nospam.nospam> wrote: >You probably want to look at the moufiltr and kbfiltr samples. A >mouclass/kbdclass lower filter is much like these except it's installed >slightly differently (in the simplest case, just by inserting a value >into the appropriate LowerFilters registry keys). > >genob wrote: >> We make devices that are Handicap Accessible devices... We have full >> control of the OS via our Windows XP Embedded build. We're not really >> many other apps, but we do need the ability to trap keys from the low >> level to fully control windows. >> >> We've experimented with LLHook functions but the problem is, if they >> run another Accessible app that uses that function, we will lose >> control of the device... >> >> We have users that scan windows with single switches, or other things >> like that... >> >> I'm fully aware that doing this is a hack, but Windows doesn't provide >> a way to exclusively trap the keyboard (which makes sense because >> people can/will write malicious code to take advantage of that). Plus >> the functions that "sort of work" don't trap CTL-ALT-DELETE or >> ALT-TAB... the latter key sequence we need so we can easily scan the >> running apps. >> >> Anyway, I'm going to look into kbdclass/mouclass stuff. >> >> Thanks for your input! >> >> g >> >> >> On Mon, 31 Oct 2005 15:08:52 -0800, Ray Trent <rat(a)nospam.nospam> >> wrote: >> >>> The easiest thing to do is probably to write a mouclass/kbdclass lower >>> filter driver, as those are easy to install and will catch all >>> mice/keyboards. Alternately, you can write upper or lower filter drivers >>> for your specific devices and install them on those particular devices. >>> >>> The real question becomes what problem you're actually trying to solve. >>> This kind of hack is rarely a good idea. Why do you want to break the >>> user's keyboard and mouse? >>> >>> genob wrote: >>>> I am currently working on a product that requires full access to the >>>> keyboard and mouse information from the drivers. >>>> >>>> We are only concerned with USB since we are building custom devices >>>> that are running XP Embedded with no PS/2 functionality. >>>> >>>> My knowledge on this subject: >>>> >>>> I have written quite a few USB HID drivers for WinCE and quite a few >>>> USB drivers for Win2k/XP... I have a really good understanding of the >>>> in's and out's of USB so that's not a problem.... >>>> >>>> Problem: >>>> >>>> We need to be able to trap all of the input on the device, and make >>>> the decision of passing it to windows, or throwing it away... >>>> >>>> I've tried to understand the whole HID class driver system in Windows >>>> XP but it seems like there are dead ends everywhere in the DDK. >>>> >>>> The question is, what level of driver can I create for the HID >>>> subsystem where I can read and stop key events? I keep reading about >>>> mini drivers, vs. class drivers, vs. filter driver.... Where is this >>>> possible in the HID subsystem? >>>> >>>> I'm about 2 seconds away from just writing my own hid driver for our >>>> device. >>>> >>>> If I have to write my own driver, how can I get key/mouse data to the >>>> high level via kernel mode? >>>> >>>> Thanks, >>>> >>>> Geno Bisceglia >>
|
Next
|
Last
Pages: 1 2 Prev: USB Keyboard LED Next: USB_BUS_INTERFACE_HUB_GUID and IRP_MN_QUERY_INTERFACE |