Hi, I am very new to Windows Driver Development, and am needing help with a class project that I am doing. I have read many resources from Microsoft’s Getting Started with Windows Drivers (https://msdn.microsoft.com/en-us/library/windows/hardware/ff554690(v=vs.85).aspx) as well as from other websites (like CodeProject). I’ve also taken a class where we developed basic Linux drivers. In any case though, I’m very open to corrections and advice on anything I’m lacking at.
Here’s my main question: What would be the general direction to take for implementing a driver that captures pen/digitizer input and taking it for further processing before it reaches the Windows OS and so before it generates pen events? I could be wrong, and here is where I really need help, but I’ve thought of developing a filter driver that will sit on top of \Driver\hidkmdf that could get the pen input data and take it for my own further processing.
Thanks
You want to filter HID created PDOs, whose hardware ID’s start with "HID". From there you can see the data reported to the OS, filter it, alter it, etc. don’t worry about which driver enumerates these PDOs.
d
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
Sent: Wednesday, January 21, 2015 10:42 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Capturing pen/digitizer input
Hi, I am very new to Windows Driver Development, and am needing help with a class project that I am doing. I have read many resources from Microsoft’s Getting Started with Windows Drivers (https://msdn.microsoft.com/en-us/library/windows/hardware/ff554690(v=vs.85).aspx) as well as from other websites (like CodeProject). I’ve also taken a class where we developed basic Linux drivers. In any case though, I’m very open to corrections and advice on anything I’m lacking at.
Here’s my main question: What would be the general direction to take for implementing a driver that captures pen/digitizer input and taking it for further processing before it reaches the Windows OS and so before it generates pen events? I could be wrong, and here is where I really need help, but I’ve thought of developing a filter driver that will sit on top of \Driver\hidkmdf that could get the pen input data and take it for my own further processing.
Thanks
NTDEV is sponsored by OSR
Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
OSR is HIRING!! See http://www.osr.com/careers
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
Thanks so much for the response! I see. When I read your response, I wondered and tried to check Device Manager for the Hardware IDs of the Wacom Tablet device and a HID-compliant pen device. I saw that Wacom Tablet’s hardware ID startedd with "USB", but the pen device (whose location is on the Wacom Tablet and whose driver is provided by Microsoft) started with "HID". I guess this shows how a Microsoft filter driver is on top of a device specific function driver in the device stack? Also, with what you’ve said, that will allow me to not worry about dealing with vendor-specific stuff since at that point all I’m seeing is just generic HID data?
I’m just trying to learn and align what I’ve read about to what I’m seeing :).
Change the view in device manager to “by connection” to see the device tree. You will see the pen is a child of the tablet. Filters didn’t do this, hidclass (the bus driver) did this by enumerating a child device
d
Bent from my phone
From: xxxxx@gmail.commailto:xxxxx
Sent: ?1/?21/?2015 3:08 PM
To: Windows System Software Devs Interest Listmailto:xxxxx
Subject: RE:[ntdev] Capturing pen/digitizer input
Thanks so much for the response! I see. When I read your response, I wondered and tried to check Device Manager for the Hardware IDs of the Wacom Tablet device and a HID-compliant pen device. I saw that Wacom Tablet’s hardware ID startedd with "USB", but the pen device (whose location is on the Wacom Tablet and whose driver is provided by Microsoft) started with "HID". I guess this shows how a Microsoft filter driver is on top of a device specific function driver in the device stack? Also, with what you’ve said, that will allow me to not worry about dealing with vendor-specific stuff since at that point all I’m seeing is just generic HID data?
I’m just trying to learn and align what I’ve read about to what I’m seeing :).
—
NTDEV is sponsored by OSR
Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
OSR is HIRING!! See http://www.osr.com/careers
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer</mailto:xxxxx></mailto:xxxxx>
Wow, I’ve been looking for a way to see the device tree all this time! And when I view the properties of each device node and look at its device stack, I can see the diagram that’s similar to the one illustrated in Microsoft’s getting started pages. Thanks so much!
Back to your first response though… Since the PnP Manager looks in the registry to see which drivers should be a part of each node in the device tree, in my case then, ideally the PnP manager will put my pen input capture filter driver on the device stack of devices whose hardware IDs start with "HID"?
Thanks for all the help so far, I’m learning so much!
Also, would UMDF or KMDF be best for writing this kind of driver? Based on this info: https://social.msdn.microsoft.com/Forums/windowsdesktop/en-US/39bc801f-a523-46ec-95fb-bae4cb39e021/umdf-hid-mousekeyboard-filter?forum=wdk , I don’t think I need any of the KMDF features mentioned there, at least in my limited knowledge. Also, this case: https://social.msdn.microsoft.com/Forums/windowsdesktop/en-US/39bc801f-a523-46ec-95fb-bae4cb39e021/umdf-hid-mousekeyboard-filter?forum=wdk is similar to mine, but might be outdated, especially in light of UMDF 2.0