Prev: hal!KfLowerIrql change data in system memory for SCSI miniport
Next: HBA have direct accesss to SrbExtension?
From: Justin on 7 Sep 2010 22:55
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?


From: Justin on 8 Sep 2010 19:11
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?


From: Tim Roberts on 9 Sep 2010 02:07
Justin <user(a)msgroups.net/> 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, timr(a)probo.com
Providenza & Boekelheide, Inc.
From: justin_romaine on 9 Sep 2010 02:28
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.


From: justin_romaine on 15 Sep 2010 02:01
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/library/ff540174(VS.85).aspx
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.wheel);
}
[/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.)


 | 
Pages: 1
Prev: hal!KfLowerIrql change data in system memory for SCSI miniport
Next: HBA have direct accesss to SrbExtension?