Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results

Sept/Oct 2019 Issue of The NT Insider available


Download PDF here: http://insider.osr.com/2019/ntinsider_2019_01.pdf

It’s a particularly BIG issue, too: 40 pages of technical goodness, ranging from WDF to Minifilters. Check it out.
Before Posting...
Please check out the Community Guidelines in the Announcements and Administration Category.

How do I make a driver that is able to accept DeviceIoControl and change the behavior of the mouse?

jguo5258jguo5258 Member Posts: 22

How do I make a driver that is able to both accept DeviceIoControl and change the behavior of the mouse? I've thought about a filter driver, but if I made a mouse filter driver, it wouldn't be able to accept deviceIoControl from my own application. But if I made my own normal driver, it wouldn't be able to change mouse behavior.

Comments

  • Doron_HolanDoron_Holan Member - All Emails Posts: 10,444

    You want to use the moufiltr example as your starting point. It demonstrates how to attach to the mouse stack and expose a raw PDO so that your application can communicate with the driver. https://github.com/Microsoft/Windows-driver-samples/tree/master/input/moufiltr

    d
  • anton_bassovanton_bassov Member Posts: 5,052

    if I made a mouse filter driver, it wouldn't be able to accept deviceIoControl from my own application.

    Please note that, from the IO Manager's perspective, you send IOCTLs not to a driver per se but to a particular DEVICE_OBJECT that it creates (or, to be more precise, to the named DO at the bottom of the stack that the DO in question is attached to). Although a filtering device that is attached to to the stack has to be nameless, there is absolutely nothing that holds you back from creating its corresponding named DO that is not on any PnP stack. Once this device is named you can open a handle to it from your app so that you can send IOCTLs to it, effectively controlling the behavior of its corresponding filter DO....

    Anton Bassov

  • jguo5258jguo5258 Member Posts: 22

    @anton_bassov said:

    if I made a mouse filter driver, it wouldn't be able to accept deviceIoControl from my own application.

    Please note that, from the IO Manager's perspective, you send IOCTLs not to a driver per se but to a particular DEVICE_OBJECT that it creates (or, to be more precise, to the named DO at the bottom of the stack that the DO in question is attached to). Although a filtering device that is attached to to the stack has to be nameless, there is absolutely nothing that holds you back from creating its corresponding named DO that is not on any PnP stack. Once this device is named you can open a handle to it from your app so that you can send IOCTLs to it, effectively controlling the behavior of its corresponding filter DO....

    Anton Bassov

    @Doron_Holan said:
    You want to use the moufiltr example as your starting point. It demonstrates how to attach to the mouse stack and expose a raw PDO so that your application can communicate with the driver. https://github.com/Microsoft/Windows-driver-samples/tree/master/input/moufiltr

    There seems to be another issue. From what I've heard, CSRSS constantly sends an I/O request to keyboard and mouse driver stacks. If there is always some read request from csrss, then how would my own deviceiocontrol able to be compleed?

  • Martin_DrábMartin_Dráb Member - All Emails Posts: 66

    There seems to be another issue. From what I've heard, CSRSS constantly sends an I/O request to keyboard and mouse driver stacks. If there is always some read request from csrss, then how would my own deviceiocontrol able to be compleed?

    You driver just processes the read and IOCL requests independently and in parallel.

    Raw Input Thread sends read requests to keyboard and mouse device stacks. Such a read request is completed when a keyboard/mouse event occurs.

    Martin Dráb

  • Tim_RobertsTim_Roberts Member - All Emails Posts: 13,102

    I don't think you're reading the responses you're getting.

    Yes, the operating system opens keyboard and mouse devices for exclusive access. You can't even get a file handle, much less submit an ioctl.

    HOWEVER, as Anton correctly pointed out, that's only for the HID device object. A single driver can create multiple device objects, and they all have their own lifetimes. Doron, who spent many years as a developer for the HID drivers, pointed out that the moufiltr example creates a separate raw PDO for this purpose. Regardless of what the system is doing with the other device objects, you can open that one and send whatever requests you want.

    Drivers do not handle requests one by one. You can be handling many requests at once, whether from a single device object or multiple device objects.

    Go look at the sample.

    Tim Roberts, [email protected]
    Providenza & Boekelheide, Inc.

Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Upcoming OSR Seminars
Writing WDF Drivers 21 Oct 2019 OSR Seminar Space & ONLINE
Internals & Software Drivers 18 Nov 2019 Dulles, VA
Kernel Debugging 30 Mar 2020 OSR Seminar Space
Developing Minifilters 27 Apr 2020 OSR Seminar Space & ONLINE