WinUSB as a functional driver to replace an existing HIDUSB kernel mode driver

I am looking for the simplest way to replace the driver of an existing USB optical mouse. (This is an experimental project
I know i could write a KMD to replace the driver but reverse engineering and existing device and debugging KMDs is challenging at best
Basically im looking read the opical mouse input data to use for my own purposes without the using it to control the mouse pointer and buttons
Can this be done? If not, what would be the best approach?

Yes, what you want to do is possible with WinUSB. Just write your INF
so that, for the experiment mouse's hardware ID, WinUSB will load. Be
sure to specify a unique device interface GUID in the INF.

On 9/7/2010 7:55 PM, Justin wrote:
> I am looking for the simplest way to replace the driver of an existing USB optical mouse. (This is an experimental project)
> I know i could write a KMD to replace the driver but reverse engineering and existing device and debugging KMDs is challenging at best.
> Basically im looking read the opical mouse input data to use for my own purposes without the using it to control the mouse pointer and buttons.
> Can this be done? If not, what would be the best approach?
>
>

That sounds promising. Its just that i read some where http://www.libusb.org/wiki/windows_backend (a third party wrapper library) that:quot
"HID keyboards and mice will not have read or write access. This is because Windows requires an exclusive access to them, and uses a driver that prevent generic access.

Should this not effect me?

Justin </> wrote:

>That sounds promising. Its just that i read some where http://www.libusb.org/wiki/windows_backend (a third party wrapper library) that:quote
>"HID keyboards and mice will not have read or write access. This is because Windows requires an exclusive access to them, and uses a driver that prevent generic access."
>
>Should this not effect me?

No. The HID stack opens the HID driver for exclusive access, but you will
be replacing the HID driver with your own. You can do whatever you want.

Of course, when you do so, it will no longer be seen as a mouse. You need
to realize that.
--
Tim Roberts,
Providenza & Boekelheide, Inc.

I certainly don't want it to be seen as a mouse
For this project, its turning into a Wah pedal MIDI controller to control amp simulators for an electric guitar
Thanks for you advice! This sounds like much more fun than writing a kernel mode HID filter driver which was my first attempt. Although it seamed possible, its was just taking up so much time.

Thanks Tim and Philip for your excellent help! All i had to do was cobble togetther the basic example from http://msdn.microsoft.com/en-us/libr...174(VS.85).asp
along with the installation instructions
Replaced the HIDs with the particular Microsoft Wheel mouse HID and installed the winusb driver
The guts it in this bit of code. The Device only had one endpoint so there was not much choice thankfully
[code
while(bResult = WinUsb_ReadPipe(hDeviceHandle, *pID, (UCHAR*)&info, sizeof(info), &cbRead, 0)


if(cbRead > 0
printf("X move %d Y move %d buttons %u wheel direction %d\n",info.xmotion,info.ymotion,info.status,info.w heel)

[/code
So thats is the first part of my project completed
I have 2 more parts but i am starting to fear, the bit i thought would be the easiest, is actually the hardest

Now i need to create a virtual MIDI device. This i will use to present my midi events to a port that can be enumerated on the system by a sequencer or virtual instrument that uses MIDI as a controller

I thought i could somehow use winmm.dll to create the virtual device but i cant see how
i can call midiOutShortMsg(...) to send my events. But the virtual instruments are not MIDI out sources so they do not have a device id for a midi out device

The closest I have got is looking at the mpu401 and uart examples in the DDK. But thats scary back to KM again. Yuk. Too hard to debug

You guys are certainly know your stuff, and was wondering if you could give me some advice on the easiest way send my midi events to a midi port that could be selected by a MIDI application

(I could have used MIDI Mapper pre Windows 7 but its Gone to i can't route the events to the consuming application. But i certainly would prefer my own vertual port.)