looking for guidance and suggestions

Hi everyone,
I would like to use moufiltr to accomplish the following task.
After user presses a button (say right button), the filter driver starts to
generate (fake) mouse movement data (say moving the cursor along a closed
square loop). It's not difficult to detect the button and add cursor
movement data in moufiltr, the difficult is how to send these data in a
steady stream (roughly a few packets per second) endlessly UNTIL the user
presses a button (or moves the mouse) OR for certain period of time. Any
suggestions?

Ray
Tue May 31 15:28:44 CDT 2005

Well, if this is all you want to do, then a moufiltr-like driver is
probably overkill. All of these things can be done more easily in
user-mode using a keyboard hook and SendInput.

However, assuming there's something you want to do that actually will
eventually require a mouse filter driver (such as removing mouse data
from the queue), then it should be relatively easy.

KeSetTimer will give you a DPC at a specified timeout, from which you
can call the mouclass service callback to send your data and reset the
timer. Since you already have a mouse filter in place, noticing the
second button press should be easy. Stopping the injected motion should
also be easy: set a flag and don't restart the timer the next time your
DPC comes around. If you want an additional timeout, keep track of the
number of times the DPC is called.

Liang Fu wrote:
> Hi everyone,
> I would like to use moufiltr to accomplish the following task.
> After user presses a button (say right button), the filter driver starts to
> generate (fake) mouse movement data (say moving the cursor along a closed
> square loop). It's not difficult to detect the button and add cursor
> movement data in moufiltr, the difficult is how to send these data in a
> steady stream (roughly a few packets per second) endlessly UNTIL the user
> presses a button (or moves the mouse) OR for certain period of time. Any
> suggestions?
>
>

--
../ray\..

Liang
Thu Jun 02 10:48:10 CDT 2005

Ray,
Thank you very much for your suggestion (a complete solution, actually). I
have two related questions which also have general implication.
1. I will need to create some temporary mouse data packets (MOUSE_INPUT_DATA
type) for the fake data. Should I create them in DPC or create a static one
(say in DeviceExtension) and reuse? Would the former cause any memory
problem?
2. I will probably need to update the flag and count (that control the fake
packet sending and are stored in DeviceExtension) from independent routines
(ServiceCallback and DPC). Do I need to concern about synchronization?
Thanks
Liang Fu

"Ray Trent" <ratrent@nospam.nospam> wrote in message
news:O5YE98hZFHA.720@TK2MSFTNGP15.phx.gbl...
> Well, if this is all you want to do, then a moufiltr-like driver is
> probably overkill. All of these things can be done more easily in
> user-mode using a keyboard hook and SendInput.
>
> However, assuming there's something you want to do that actually will
> eventually require a mouse filter driver (such as removing mouse data
> from the queue), then it should be relatively easy.
>
> KeSetTimer will give you a DPC at a specified timeout, from which you
> can call the mouclass service callback to send your data and reset the
> timer. Since you already have a mouse filter in place, noticing the
> second button press should be easy. Stopping the injected motion should
> also be easy: set a flag and don't restart the timer the next time your
> DPC comes around. If you want an additional timeout, keep track of the
> number of times the DPC is called.
>
> Liang Fu wrote:
> > Hi everyone,
> > I would like to use moufiltr to accomplish the following task.
> > After user presses a button (say right button), the filter driver starts
to
> > generate (fake) mouse movement data (say moving the cursor along a
closed
> > square loop). It's not difficult to detect the button and add cursor
> > movement data in moufiltr, the difficult is how to send these data in a
> > steady stream (roughly a few packets per second) endlessly UNTIL the
user
> > presses a button (or moves the mouse) OR for certain period of time. Any
> > suggestions?
> >
> >
>
> --
> ../ray\..

Doron
Thu Jun 02 12:09:10 CDT 2005

you can just declare the MOUSE_INPUT_DATA array on the stack in the DPC. no
need to put it into the device extension, by putting it in the device
extension, you are requiring more synchronization if more then one thread at
a time uses the extension.

Yes, you should synchronize access to Flag and Count fields in the device
extension if more then one function at time can access these values.
Certainly the service callback can be running at the same time as the DPC

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.


"Liang Fu" <liang_fu_dr@hotmail.com> wrote in message
news:eR6fDr4ZFHA.4040@TK2MSFTNGP14.phx.gbl...
> Ray,
> Thank you very much for your suggestion (a complete solution, actually). I
> have two related questions which also have general implication.
> 1. I will need to create some temporary mouse data packets
> (MOUSE_INPUT_DATA
> type) for the fake data. Should I create them in DPC or create a static
> one
> (say in DeviceExtension) and reuse? Would the former cause any memory
> problem?
> 2. I will probably need to update the flag and count (that control the
> fake
> packet sending and are stored in DeviceExtension) from independent
> routines
> (ServiceCallback and DPC). Do I need to concern about synchronization?
> Thanks
> Liang Fu
>
> "Ray Trent" <ratrent@nospam.nospam> wrote in message
> news:O5YE98hZFHA.720@TK2MSFTNGP15.phx.gbl...
>> Well, if this is all you want to do, then a moufiltr-like driver is
>> probably overkill. All of these things can be done more easily in
>> user-mode using a keyboard hook and SendInput.
>>
>> However, assuming there's something you want to do that actually will
>> eventually require a mouse filter driver (such as removing mouse data
>> from the queue), then it should be relatively easy.
>>
>> KeSetTimer will give you a DPC at a specified timeout, from which you
>> can call the mouclass service callback to send your data and reset the
>> timer. Since you already have a mouse filter in place, noticing the
>> second button press should be easy. Stopping the injected motion should
>> also be easy: set a flag and don't restart the timer the next time your
>> DPC comes around. If you want an additional timeout, keep track of the
>> number of times the DPC is called.
>>
>> Liang Fu wrote:
>> > Hi everyone,
>> > I would like to use moufiltr to accomplish the following task.
>> > After user presses a button (say right button), the filter driver
>> > starts
> to
>> > generate (fake) mouse movement data (say moving the cursor along a
> closed
>> > square loop). It's not difficult to detect the button and add cursor
>> > movement data in moufiltr, the difficult is how to send these data in a
>> > steady stream (roughly a few packets per second) endlessly UNTIL the
> user
>> > presses a button (or moves the mouse) OR for certain period of time.
>> > Any
>> > suggestions?
>> >
>> >
>>
>> --
>> ../ray\..
>
>

Liang
Thu Jun 02 13:24:49 CDT 2005

Doron,
Thanks for your help.
What are the IRQL levels of the moufiltr ServiceCallback and the timer
triggered DPC?
Thanks,
Liang Fu

"Doron Holan [MS]" <doronh@nospam.microsoft.com> wrote in message
news:%23317LX5ZFHA.612@TK2MSFTNGP12.phx.gbl...
> you can just declare the MOUSE_INPUT_DATA array on the stack in the DPC.
no
> need to put it into the device extension, by putting it in the device
> extension, you are requiring more synchronization if more then one thread
at
> a time uses the extension.
>
> Yes, you should synchronize access to Flag and Count fields in the device
> extension if more then one function at time can access these values.
> Certainly the service callback can be running at the same time as the DPC
>
> 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.
>
>
> "Liang Fu" <liang_fu_dr@hotmail.com> wrote in message
> news:eR6fDr4ZFHA.4040@TK2MSFTNGP14.phx.gbl...
> > Ray,
> > Thank you very much for your suggestion (a complete solution, actually).
I
> > have two related questions which also have general implication.
> > 1. I will need to create some temporary mouse data packets
> > (MOUSE_INPUT_DATA
> > type) for the fake data. Should I create them in DPC or create a static
> > one
> > (say in DeviceExtension) and reuse? Would the former cause any memory
> > problem?
> > 2. I will probably need to update the flag and count (that control the
> > fake
> > packet sending and are stored in DeviceExtension) from independent
> > routines
> > (ServiceCallback and DPC). Do I need to concern about synchronization?
> > Thanks
> > Liang Fu
> >
> > "Ray Trent" <ratrent@nospam.nospam> wrote in message
> > news:O5YE98hZFHA.720@TK2MSFTNGP15.phx.gbl...
> >> Well, if this is all you want to do, then a moufiltr-like driver is
> >> probably overkill. All of these things can be done more easily in
> >> user-mode using a keyboard hook and SendInput.
> >>
> >> However, assuming there's something you want to do that actually will
> >> eventually require a mouse filter driver (such as removing mouse data
> >> from the queue), then it should be relatively easy.
> >>
> >> KeSetTimer will give you a DPC at a specified timeout, from which you
> >> can call the mouclass service callback to send your data and reset the
> >> timer. Since you already have a mouse filter in place, noticing the
> >> second button press should be easy. Stopping the injected motion should
> >> also be easy: set a flag and don't restart the timer the next time your
> >> DPC comes around. If you want an additional timeout, keep track of the
> >> number of times the DPC is called.
> >>
> >> Liang Fu wrote:
> >> > Hi everyone,
> >> > I would like to use moufiltr to accomplish the following task.
> >> > After user presses a button (say right button), the filter driver
> >> > starts
> > to
> >> > generate (fake) mouse movement data (say moving the cursor along a
> > closed
> >> > square loop). It's not difficult to detect the button and add cursor
> >> > movement data in moufiltr, the difficult is how to send these data in
a
> >> > steady stream (roughly a few packets per second) endlessly UNTIL the
> > user
> >> > presses a button (or moves the mouse) OR for certain period of time.
> >> > Any
> >> > suggestions?
> >> >
> >> >
> >>
> >> --
> >> ../ray\..
> >
> >
>
>

Doron
Sat Jun 04 01:23:14 CDT 2005

the callback is called at DISPATCH_LEVEL, DPCs are always run at
DISPATCH_LEVEL. a simple test call to KeGetCurrentIrql() in your code would
have told you this

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.


"Liang Fu" <liang_fu_dr@hotmail.com> wrote in message
news:%23zBtmC6ZFHA.1384@TK2MSFTNGP09.phx.gbl...
> Doron,
> Thanks for your help.
> What are the IRQL levels of the moufiltr ServiceCallback and the timer
> triggered DPC?
> Thanks,
> Liang Fu
>
> "Doron Holan [MS]" <doronh@nospam.microsoft.com> wrote in message
> news:%23317LX5ZFHA.612@TK2MSFTNGP12.phx.gbl...
>> you can just declare the MOUSE_INPUT_DATA array on the stack in the DPC.
> no
>> need to put it into the device extension, by putting it in the device
>> extension, you are requiring more synchronization if more then one thread
> at
>> a time uses the extension.
>>
>> Yes, you should synchronize access to Flag and Count fields in the device
>> extension if more then one function at time can access these values.
>> Certainly the service callback can be running at the same time as the DPC
>>
>> 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.
>>
>>
>> "Liang Fu" <liang_fu_dr@hotmail.com> wrote in message
>> news:eR6fDr4ZFHA.4040@TK2MSFTNGP14.phx.gbl...
>> > Ray,
>> > Thank you very much for your suggestion (a complete solution,
>> > actually).
> I
>> > have two related questions which also have general implication.
>> > 1. I will need to create some temporary mouse data packets
>> > (MOUSE_INPUT_DATA
>> > type) for the fake data. Should I create them in DPC or create a static
>> > one
>> > (say in DeviceExtension) and reuse? Would the former cause any memory
>> > problem?
>> > 2. I will probably need to update the flag and count (that control the
>> > fake
>> > packet sending and are stored in DeviceExtension) from independent
>> > routines
>> > (ServiceCallback and DPC). Do I need to concern about synchronization?
>> > Thanks
>> > Liang Fu
>> >
>> > "Ray Trent" <ratrent@nospam.nospam> wrote in message
>> > news:O5YE98hZFHA.720@TK2MSFTNGP15.phx.gbl...
>> >> Well, if this is all you want to do, then a moufiltr-like driver is
>> >> probably overkill. All of these things can be done more easily in
>> >> user-mode using a keyboard hook and SendInput.
>> >>
>> >> However, assuming there's something you want to do that actually will
>> >> eventually require a mouse filter driver (such as removing mouse data
>> >> from the queue), then it should be relatively easy.
>> >>
>> >> KeSetTimer will give you a DPC at a specified timeout, from which you
>> >> can call the mouclass service callback to send your data and reset the
>> >> timer. Since you already have a mouse filter in place, noticing the
>> >> second button press should be easy. Stopping the injected motion
>> >> should
>> >> also be easy: set a flag and don't restart the timer the next time
>> >> your
>> >> DPC comes around. If you want an additional timeout, keep track of the
>> >> number of times the DPC is called.
>> >>
>> >> Liang Fu wrote:
>> >> > Hi everyone,
>> >> > I would like to use moufiltr to accomplish the following task.
>> >> > After user presses a button (say right button), the filter driver
>> >> > starts
>> > to
>> >> > generate (fake) mouse movement data (say moving the cursor along a
>> > closed
>> >> > square loop). It's not difficult to detect the button and add cursor
>> >> > movement data in moufiltr, the difficult is how to send these data
>> >> > in
> a
>> >> > steady stream (roughly a few packets per second) endlessly UNTIL the
>> > user
>> >> > presses a button (or moves the mouse) OR for certain period of time.
>> >> > Any
>> >> > suggestions?
>> >> >
>> >> >
>> >>
>> >> --
>> >> ../ray\..
>> >
>> >
>>
>>
>
>

Liang
Mon Jun 06 11:27:41 CDT 2005

Thanks,
I have experimented with the idea. I noticed that the Timer\DPC caused
many calls to MouFilter_InternIoCtl with control code = 0xf0000, and these
calls seem to come randomly (per every 1, 4, or 15 calls of DPC). Is this
normal?

A few questions about synchronization, please let me know whether I
understand the concept correctly.
1) Since both ServiceCallback and DPC are of the same IRQL, the
synchronization is needed only for multiple CPU computers.
2) I can effectively protect the consistency of shared resources by setting
synchronization (say using spin locks) whenever I update (write to) the
shared fields, but I don't need to do it when read from them.

Thanks in advance,
Liang Fu

"Doron Holan [MS]" <doronh@nospam.microsoft.com> wrote in message
news:%239tzj3MaFHA.3032@TK2MSFTNGP10.phx.gbl...
> the callback is called at DISPATCH_LEVEL, DPCs are always run at
> DISPATCH_LEVEL. a simple test call to KeGetCurrentIrql() in your code
would
> have told you this
>
> 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.
>
>
> "Liang Fu" <liang_fu_dr@hotmail.com> wrote in message
> news:%23zBtmC6ZFHA.1384@TK2MSFTNGP09.phx.gbl...
> > Doron,
> > Thanks for your help.
> > What are the IRQL levels of the moufiltr ServiceCallback and the timer
> > triggered DPC?
> > Thanks,
> > Liang Fu
> >
> > "Doron Holan [MS]" <doronh@nospam.microsoft.com> wrote in message
> > news:%23317LX5ZFHA.612@TK2MSFTNGP12.phx.gbl...
> >> you can just declare the MOUSE_INPUT_DATA array on the stack in the
DPC.
> > no
> >> need to put it into the device extension, by putting it in the device
> >> extension, you are requiring more synchronization if more then one
thread
> > at
> >> a time uses the extension.
> >>
> >> Yes, you should synchronize access to Flag and Count fields in the
device
> >> extension if more then one function at time can access these values.
> >> Certainly the service callback can be running at the same time as the
DPC
> >>
> >> 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.
> >>
> >>
> >> "Liang Fu" <liang_fu_dr@hotmail.com> wrote in message
> >> news:eR6fDr4ZFHA.4040@TK2MSFTNGP14.phx.gbl...
> >> > Ray,
> >> > Thank you very much for your suggestion (a complete solution,
> >> > actually).
> > I
> >> > have two related questions which also have general implication.
> >> > 1. I will need to create some temporary mouse data packets
> >> > (MOUSE_INPUT_DATA
> >> > type) for the fake data. Should I create them in DPC or create a
static
> >> > one
> >> > (say in DeviceExtension) and reuse? Would the former cause any memory
> >> > problem?
> >> > 2. I will probably need to update the flag and count (that control
the
> >> > fake
> >> > packet sending and are stored in DeviceExtension) from independent
> >> > routines
> >> > (ServiceCallback and DPC). Do I need to concern about
synchronization?
> >> > Thanks
> >> > Liang Fu
> >> >
> >> > "Ray Trent" <ratrent@nospam.nospam> wrote in message
> >> > news:O5YE98hZFHA.720@TK2MSFTNGP15.phx.gbl...
> >> >> Well, if this is all you want to do, then a moufiltr-like driver is
> >> >> probably overkill. All of these things can be done more easily in
> >> >> user-mode using a keyboard hook and SendInput.
> >> >>
> >> >> However, assuming there's something you want to do that actually
will
> >> >> eventually require a mouse filter driver (such as removing mouse
data
> >> >> from the queue), then it should be relatively easy.
> >> >>
> >> >> KeSetTimer will give you a DPC at a specified timeout, from which
you
> >> >> can call the mouclass service callback to send your data and reset
the
> >> >> timer. Since you already have a mouse filter in place, noticing the
> >> >> second button press should be easy. Stopping the injected motion
> >> >> should
> >> >> also be easy: set a flag and don't restart the timer the next time
> >> >> your
> >> >> DPC comes around. If you want an additional timeout, keep track of
the
> >> >> number of times the DPC is called.
> >> >>
> >> >> Liang Fu wrote:
> >> >> > Hi everyone,
> >> >> > I would like to use moufiltr to accomplish the following task.
> >> >> > After user presses a button (say right button), the filter driver
> >> >> > starts
> >> > to
> >> >> > generate (fake) mouse movement data (say moving the cursor along a
> >> > closed
> >> >> > square loop). It's not difficult to detect the button and add
cursor
> >> >> > movement data in moufiltr, the difficult is how to send these data
> >> >> > in
> > a
> >> >> > steady stream (roughly a few packets per second) endlessly UNTIL
the
> >> > user
> >> >> > presses a button (or moves the mouse) OR for certain period of
time.
> >> >> > Any
> >> >> > suggestions?
> >> >> >
> >> >> >
> >> >>
> >> >> --
> >> >> ../ray\..
> >> >
> >> >
> >>
> >>
> >
> >
>
>

Liang
Thu Jun 09 15:03:46 CDT 2005

I really need help on this one.
As I mentioned in my previous post, Timer\DPC caused
many calls to MouFilter_InternIoCtl with control code = 0xf0000. These calls
substantially slow down the response of mouse, rendering the usefulness of
Timer (the time intervals were randomly and sluggish). I spent considerable
time searching DDK documents trying to figure out what this internal control
code means but I couldn't fined the definition. I think my inexperience in
this field is the only thing to blame, but I would greatly appreciate if
someone who had used this timer and experienced same problem could help me.
"Doron Holan [MS]" <doronh@nospam.microsoft.com> wrote in message
news:%239tzj3MaFHA.3032@TK2MSFTNGP10.phx.gbl...
> the callback is called at DISPATCH_LEVEL, DPCs are always run at
> DISPATCH_LEVEL. a simple test call to KeGetCurrentIrql() in your code
would
> have told you this
>
> 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.
>
>
> "Liang Fu" <liang_fu_dr@hotmail.com> wrote in message
> news:%23zBtmC6ZFHA.1384@TK2MSFTNGP09.phx.gbl...
> > Doron,
> > Thanks for your help.
> > What are the IRQL levels of the moufiltr ServiceCallback and the timer
> > triggered DPC?
> > Thanks,
> > Liang Fu
> >
> > "Doron Holan [MS]" <doronh@nospam.microsoft.com> wrote in message
> > news:%23317LX5ZFHA.612@TK2MSFTNGP12.phx.gbl...
> >> you can just declare the MOUSE_INPUT_DATA array on the stack in the
DPC.
> > no
> >> need to put it into the device extension, by putting it in the device
> >> extension, you are requiring more synchronization if more then one
thread
> > at
> >> a time uses the extension.
> >>
> >> Yes, you should synchronize access to Flag and Count fields in the
device
> >> extension if more then one function at time can access these values.
> >> Certainly the service callback can be running at the same time as the
DPC
> >>
> >> 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.
> >>
> >>
> >> "Liang Fu" <liang_fu_dr@hotmail.com> wrote in message
> >> news:eR6fDr4ZFHA.4040@TK2MSFTNGP14.phx.gbl...
> >> > Ray,
> >> > Thank you very much for your suggestion (a complete solution,
> >> > actually).
> > I
> >> > have two related questions which also have general implication.
> >> > 1. I will need to create some temporary mouse data packets
> >> > (MOUSE_INPUT_DATA
> >> > type) for the fake data. Should I create them in DPC or create a
static
> >> > one
> >> > (say in DeviceExtension) and reuse? Would the former cause any memory
> >> > problem?
> >> > 2. I will probably need to update the flag and count (that control
the
> >> > fake
> >> > packet sending and are stored in DeviceExtension) from independent
> >> > routines
> >> > (ServiceCallback and DPC). Do I need to concern about
synchronization?
> >> > Thanks
> >> > Liang Fu
> >> >
> >> > "Ray Trent" <ratrent@nospam.nospam> wrote in message
> >> > news:O5YE98hZFHA.720@TK2MSFTNGP15.phx.gbl...
> >> >> Well, if this is all you want to do, then a moufiltr-like driver is
> >> >> probably overkill. All of these things can be done more easily in
> >> >> user-mode using a keyboard hook and SendInput.
> >> >>
> >> >> However, assuming there's something you want to do that actually
will
> >> >> eventually require a mouse filter driver (such as removing mouse
data
> >> >> from the queue), then it should be relatively easy.
> >> >>
> >> >> KeSetTimer will give you a DPC at a specified timeout, from which
you
> >> >> can call the mouclass service callback to send your data and reset
the
> >> >> timer. Since you already have a mouse filter in place, noticing the
> >> >> second button press should be easy. Stopping the injected motion
> >> >> should
> >> >> also be easy: set a flag and don't restart the timer the next time
> >> >> your
> >> >> DPC comes around. If you want an additional timeout, keep track of
the
> >> >> number of times the DPC is called.
> >> >>
> >> >> Liang Fu wrote:
> >> >> > Hi everyone,
> >> >> > I would like to use moufiltr to accomplish the following task.
> >> >> > After user presses a button (say right button), the filter driver
> >> >> > starts
> >> > to
> >> >> > generate (fake) mouse movement data (say moving the cursor along a
> >> > closed
> >> >> > square loop). It's not difficult to detect the button and add
cursor
> >> >> > movement data in moufiltr, the difficult is how to send these data
> >> >> > in
> > a
> >> >> > steady stream (roughly a few packets per second) endlessly UNTIL
the
> >> > user
> >> >> > presses a button (or moves the mouse) OR for certain period of
time.
> >> >> > Any
> >> >> > suggestions?
> >> >> >
> >> >> >
> >> >>
> >> >> --
> >> >> ../ray\..
> >> >
> >> >
> >>
> >>
> >
> >
>
>

Doron
Fri Jun 10 02:00:43 CDT 2005

well, look in ntddmou.h. it will list all the internal ioctls which are
send, you need to look for the usage of the IOCTL() macro, not pure hex
values

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.


"Liang Fu" <liang_fu_dr@hotmail.com> wrote in message
news:ugxxi6SbFHA.3144@TK2MSFTNGP14.phx.gbl...
>I really need help on this one.
> As I mentioned in my previous post, Timer\DPC caused
> many calls to MouFilter_InternIoCtl with control code = 0xf0000. These
> calls
> substantially slow down the response of mouse, rendering the usefulness of
> Timer (the time intervals were randomly and sluggish). I spent
> considerable
> time searching DDK documents trying to figure out what this internal
> control
> code means but I couldn't fined the definition. I think my inexperience in
> this field is the only thing to blame, but I would greatly appreciate if
> someone who had used this timer and experienced same problem could help
> me.
> "Doron Holan [MS]" <doronh@nospam.microsoft.com> wrote in message
> news:%239tzj3MaFHA.3032@TK2MSFTNGP10.phx.gbl...
>> the callback is called at DISPATCH_LEVEL, DPCs are always run at
>> DISPATCH_LEVEL. a simple test call to KeGetCurrentIrql() in your code
> would
>> have told you this
>>
>> 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.
>>
>>
>> "Liang Fu" <liang_fu_dr@hotmail.com> wrote in message
>> news:%23zBtmC6ZFHA.1384@TK2MSFTNGP09.phx.gbl...
>> > Doron,
>> > Thanks for your help.
>> > What are the IRQL levels of the moufiltr ServiceCallback and the timer
>> > triggered DPC?
>> > Thanks,
>> > Liang Fu
>> >
>> > "Doron Holan [MS]" <doronh@nospam.microsoft.com> wrote in message
>> > news:%23317LX5ZFHA.612@TK2MSFTNGP12.phx.gbl...
>> >> you can just declare the MOUSE_INPUT_DATA array on the stack in the
> DPC.
>> > no
>> >> need to put it into the device extension, by putting it in the device
>> >> extension, you are requiring more synchronization if more then one
> thread
>> > at
>> >> a time uses the extension.
>> >>
>> >> Yes, you should synchronize access to Flag and Count fields in the
> device
>> >> extension if more then one function at time can access these values.
>> >> Certainly the service callback can be running at the same time as the
> DPC
>> >>
>> >> 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.
>> >>
>> >>
>> >> "Liang Fu" <liang_fu_dr@hotmail.com> wrote in message
>> >> news:eR6fDr4ZFHA.4040@TK2MSFTNGP14.phx.gbl...
>> >> > Ray,
>> >> > Thank you very much for your suggestion (a complete solution,
>> >> > actually).
>> > I
>> >> > have two related questions which also have general implication.
>> >> > 1. I will need to create some temporary mouse data packets
>> >> > (MOUSE_INPUT_DATA
>> >> > type) for the fake data. Should I create them in DPC or create a
> static
>> >> > one
>> >> > (say in DeviceExtension) and reuse? Would the former cause any
>> >> > memory
>> >> > problem?
>> >> > 2. I will probably need to update the flag and count (that control
> the
>> >> > fake
>> >> > packet sending and are stored in DeviceExtension) from independent
>> >> > routines
>> >> > (ServiceCallback and DPC). Do I need to concern about
> synchronization?
>> >> > Thanks
>> >> > Liang Fu
>> >> >
>> >> > "Ray Trent" <ratrent@nospam.nospam> wrote in message
>> >> > news:O5YE98hZFHA.720@TK2MSFTNGP15.phx.gbl...
>> >> >> Well, if this is all you want to do, then a moufiltr-like driver is
>> >> >> probably overkill. All of these things can be done more easily in
>> >> >> user-mode using a keyboard hook and SendInput.
>> >> >>
>> >> >> However, assuming there's something you want to do that actually
> will
>> >> >> eventually require a mouse filter driver (such as removing mouse
> data
>> >> >> from the queue), then it should be relatively easy.
>> >> >>
>> >> >> KeSetTimer will give you a DPC at a specified timeout, from which
> you
>> >> >> can call the mouclass service callback to send your data and reset
> the
>> >> >> timer. Since you already have a mouse filter in place, noticing the
>> >> >> second button press should be easy. Stopping the injected motion
>> >> >> should
>> >> >> also be easy: set a flag and don't restart the timer the next time
>> >> >> your
>> >> >> DPC comes around. If you want an additional timeout, keep track of
> the
>> >> >> number of times the DPC is called.
>> >> >>
>> >> >> Liang Fu wrote:
>> >> >> > Hi everyone,
>> >> >> > I would like to use moufiltr to accomplish the following task.
>> >> >> > After user presses a button (say right button), the filter driver
>> >> >> > starts
>> >> > to
>> >> >> > generate (fake) mouse movement data (say moving the cursor along
>> >> >> > a
>> >> > closed
>> >> >> > square loop). It's not difficult to detect the button and add
> cursor
>> >> >> > movement data in moufiltr, the difficult is how to send these
>> >> >> > data
>> >> >> > in
>> > a
>> >> >> > steady stream (roughly a few packets per second) endlessly UNTIL
> the
>> >> > user
>> >> >> > presses a button (or moves the mouse) OR for certain period of
> time.
>> >> >> > Any
>> >> >> > suggestions?
>> >> >> >
>> >> >> >
>> >> >>
>> >> >> --
>> >> >> ../ray\..
>> >> >
>> >> >
>> >>
>> >>
>> >
>> >
>>
>>
>
>

Tim
Fri Jun 10 23:58:20 CDT 2005

"Liang Fu" <liang_fu_dr@hotmail.com> wrote:
>
>I really need help on this one.
>As I mentioned in my previous post, Timer\DPC caused
>many calls to MouFilter_InternIoCtl with control code = 0xf0000. These calls
>substantially slow down the response of mouse, rendering the usefulness of
>Timer (the time intervals were randomly and sluggish). I spent considerable
>time searching DDK documents trying to figure out what this internal control
>code means but I couldn't fined the definition.

How did you search? You won't find "f0000" anywhere, because ioctls are
built up by fields using a macro.

You should check what this expands to:

#define IOCTL_MOUSE_QUERY_ATTRIBUTES CTL_CODE(FILE_DEVICE_MOUSE, 0,
METHOD_BUFFERED, FILE_ANY_ACCESS)
--
- Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc

Liang
Mon Jun 13 09:02:49 CDT 2005

Thanks Tim,
Yes, IOCTL_MOUSE_QUERY_ATTRIBUTES is the one. I was looking for Hex F0000,
after Doron told me to check the micros I identified this code. But what I
don't understand is why the system wants to query the mouse attributes
(frequently) when the timer/dpc is running, and it seems not related to what
the dpc does (even if the dpc does nothing) but rather related to the length
of dueTime. For around -100000, I get lees or no such calls, away from this
value in either direction, lots of calls.
Thanks everyone.

"Tim Roberts" <timr@probo.com> wrote in message
news:uorka19cbs3rm23ou9ddnc294ok99evj0c@4ax.com...
> "Liang Fu" <liang_fu_dr@hotmail.com> wrote:
> >
> >I really need help on this one.
> >As I mentioned in my previous post, Timer\DPC caused
> >many calls to MouFilter_InternIoCtl with control code = 0xf0000. These
calls
> >substantially slow down the response of mouse, rendering the usefulness
of
> >Timer (the time intervals were randomly and sluggish). I spent
considerable
> >time searching DDK documents trying to figure out what this internal
control
> >code means but I couldn't fined the definition.
>
> How did you search? You won't find "f0000" anywhere, because ioctls are
> built up by fields using a macro.
>
> You should check what this expands to:
>
> #define IOCTL_MOUSE_QUERY_ATTRIBUTES CTL_CODE(FILE_DEVICE_MOUSE, 0,
> METHOD_BUFFERED, FILE_ANY_ACCESS)
> --
> - Tim Roberts, timr@probo.com
> Providenza & Boekelheide, Inc

Doron
Mon Jun 13 22:02:44 CDT 2005

what are you seeing in the Flags field of MOUSE_INPUT_DATA? are you sure it
is zeroed first? If MOUSE_ATTRIBUTES_CHANGED is set, the attributes are
requried.

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.


"Liang Fu" <liang_fu_dr@hotmail.com> wrote in message
news:%231hNfDCcFHA.1392@TK2MSFTNGP14.phx.gbl...
> Thanks Tim,
> Yes, IOCTL_MOUSE_QUERY_ATTRIBUTES is the one. I was looking for Hex F0000,
> after Doron told me to check the micros I identified this code. But what I
> don't understand is why the system wants to query the mouse attributes
> (frequently) when the timer/dpc is running, and it seems not related to
> what
> the dpc does (even if the dpc does nothing) but rather related to the
> length
> of dueTime. For around -100000, I get lees or no such calls, away from
> this
> value in either direction, lots of calls.
> Thanks everyone.
>
> "Tim Roberts" <timr@probo.com> wrote in message
> news:uorka19cbs3rm23ou9ddnc294ok99evj0c@4ax.com...
>> "Liang Fu" <liang_fu_dr@hotmail.com> wrote:
>> >
>> >I really need help on this one.
>> >As I mentioned in my previous post, Timer\DPC caused
>> >many calls to MouFilter_InternIoCtl with control code = 0xf0000. These
> calls
>> >substantially slow down the response of mouse, rendering the usefulness
> of
>> >Timer (the time intervals were randomly and sluggish). I spent
> considerable
>> >time searching DDK documents trying to figure out what this internal
> control
>> >code means but I couldn't fined the definition.
>>
>> How did you search? You won't find "f0000" anywhere, because ioctls are
>> built up by fields using a macro.
>>
>> You should check what this expands to:
>>
>> #define IOCTL_MOUSE_QUERY_ATTRIBUTES CTL_CODE(FILE_DEVICE_MOUSE, 0,
>> METHOD_BUFFERED, FILE_ANY_ACCESS)
>> --
>> - Tim Roberts, timr@probo.com
>> Providenza & Boekelheide, Inc
>
>

Liang
Tue Jun 14 12:30:54 CDT 2005

Doron,
That's the problem!
Thank you so much for your help.
Liang Fu

"Doron Holan [MS]" <doronh@nospam.microsoft.com> wrote in message
news:OmABK2IcFHA.2424@TK2MSFTNGP09.phx.gbl...
> what are you seeing in the Flags field of MOUSE_INPUT_DATA? are you sure
it
> is zeroed first? If MOUSE_ATTRIBUTES_CHANGED is set, the attributes are
> requried.
>
> 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.
>
>
> "Liang Fu" <liang_fu_dr@hotmail.com> wrote in message
> news:%231hNfDCcFHA.1392@TK2MSFTNGP14.phx.gbl...
> > Thanks Tim,
> > Yes, IOCTL_MOUSE_QUERY_ATTRIBUTES is the one. I was looking for Hex
F0000,
> > after Doron told me to check the micros I identified this code. But what
I
> > don't understand is why the system wants to query the mouse attributes
> > (frequently) when the timer/dpc is running, and it seems not related to
> > what
> > the dpc does (even if the dpc does nothing) but rather related to the
> > length
> > of dueTime. For around -100000, I get lees or no such calls, away from
> > this
> > value in either direction, lots of calls.
> > Thanks everyone.
> >
> > "Tim Roberts" <timr@probo.com> wrote in message
> > news:uorka19cbs3rm23ou9ddnc294ok99evj0c@4ax.com...
> >> "Liang Fu" <liang_fu_dr@hotmail.com> wrote:
> >> >
> >> >I really need help on this one.
> >> >As I mentioned in my previous post, Timer\DPC caused
> >> >many calls to MouFilter_InternIoCtl with control code = 0xf0000. These
> > calls
> >> >substantially slow down the response of mouse, rendering the
usefulness
> > of
> >> >Timer (the time intervals were randomly and sluggish). I spent
> > considerable
> >> >time searching DDK documents trying to figure out what this internal
> > control
> >> >code means but I couldn't fined the definition.
> >>
> >> How did you search? You won't find "f0000" anywhere, because ioctls
are
> >> built up by fields using a macro.
> >>
> >> You should check what this expands to:
> >>
> >> #define IOCTL_MOUSE_QUERY_ATTRIBUTES CTL_CODE(FILE_DEVICE_MOUSE, 0,
> >> METHOD_BUFFERED, FILE_ANY_ACCESS)
> >> --
> >> - Tim Roberts, timr@probo.com
> >> Providenza & Boekelheide, Inc
> >
> >
>
>