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.
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
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
@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?
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.
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.