HID Mouse Filter driver, developing
HID Mouse Filter driver, developing Posted on: 15.04.2011 by DJ MENSAH Hi all, I have a quick question:Would anyone (with experience) be interested to write a small upper level mouse filter driver with these features: - custom setup (like in hidUSBf) so that only certain mice can be selected - filtering mouse input (preventing it form getting to cursor) and routing it to some sort of IPC channel (I'm open for suggestions) - each mouse device must have unique ID (simple int or use separate IPC data channel) - possibly a hi-res timestamp attached to each update (since it seems that in windows, on the application side, not all 1ms has the same length) That's it mostly. Hope I haven't forgotten anything. I have tried building this filter with some Windows API combo but that just feelt dirty, unstable and seems like timings vary too much. | |
| Chasidy Heckenbach 27.10.2011 |
Originally Posted by fogmaster
i've started on some midimasher code now to support hid devices - but using hidapi-0.7.0 (new version released yesterday) so it's cross platform. does mean i can't get at the mouse or keyboard stuff tho, but i mostly want it for gamepad support. did like the idea of using it for my usb touchpad too tho... as you guys obviously know more about hid than me... was wondering if you could help me a bit. i'm a bit stuck atm on what feature reports to issue to work out what the capabilities of the attached device is. my gamepad just sends back 8 bytes when i try to read from it - and i can see what bits change for each button - but i presume different devices (and esp diff classes) are going to give me back totally different data? |
| Chasidy Heckenbach 25.10.2011 |
Originally Posted by ToS
with mice i know that you definitely can swallow mouse data and also discern which mouse the data came from. this is what i had posted before, when the same issue was brought up in another thread:
seems that with glovepie and keyboards you can do either....
* treat input from each keyboard differently, convert to midi etc, but the actual keypress still gets sent out too (as a keypress) * swallow the keyboard input and *only* send out midi - but then you can't differentiate between each keyboard |
| Chasidy Heckenbach 24.10.2011 |
Originally Posted by ToS
|
| Chasidy Heckenbach 22.10.2011 |
Originally Posted by ToS
i'm pretty happy with it's stability and feature set now - and will at least be creating a new thread with a multi page launchpad mapping soon. but that's not really the point of midi masher ofc - it's so people can create/modify their own ones. be easier to have a more complete example as a starting point tho - esp as i haven't really documented any of the api |
| Chasidy Heckenbach 21.10.2011 |
Originally Posted by ToS
i did play about with the hidapi lib a bit and might be adding hid support into midimasher tho i have plenty of other stuff i want to code first. glovepie does work really well - and it doesn't eat up too much cpu - just depends if its too much or not i guess. it's very easy to configure. |
| DJ MENSAH 25.07.2012 | Just run some tests last evening and Interception works great so far. |
| DJ MENSAH 04.01.2012 | Holy mother of MIDI! Thank you so much, this looks just like the thing I was looking for. |
| Mellissa Vladimirov 03.01.2012 | This tool (http://oblita.com/Interception) uses kernel mode components but has a simple C user mode interface, with it you may identify in a simpler way from which device an event is coming, and still, change it the way you want. |
| Chasidy Heckenbach 27.10.2011 |
Originally Posted by fogmaster
i've started on some midimasher code now to support hid devices - but using hidapi-0.7.0 (new version released yesterday) so it's cross platform. does mean i can't get at the mouse or keyboard stuff tho, but i mostly want it for gamepad support. did like the idea of using it for my usb touchpad too tho... as you guys obviously know more about hid than me... was wondering if you could help me a bit. i'm a bit stuck atm on what feature reports to issue to work out what the capabilities of the attached device is. my gamepad just sends back 8 bytes when i try to read from it - and i can see what bits change for each button - but i presume different devices (and esp diff classes) are going to give me back totally different data? |
| Charline Alderton 27.10.2011 | Hi ToS, sorry for late response. For now the RawInput method is ok for me. But canceling these mouse events would be fine. On startup my program uses GetRawInputDeviceList and GetRawInputDeviceInfo to filter the connected devices for Vid an Pid. if the right device is found the devicehandle is stored. In window callback procedure i only use the input data if the device handle is equal to the stored handle. The answer on why i don't use GlovePIE is i didn't know it Unfortunately i was to busy to test it recently. |
| Chasidy Heckenbach 25.10.2011 |
Originally Posted by ToS
with mice i know that you definitely can swallow mouse data and also discern which mouse the data came from. this is what i had posted before, when the same issue was brought up in another thread:
seems that with glovepie and keyboards you can do either....
* treat input from each keyboard differently, convert to midi etc, but the actual keypress still gets sent out too (as a keypress) * swallow the keyboard input and *only* send out midi - but then you can't differentiate between each keyboard |
| DJ MENSAH 25.10.2011 | Actually, it's the same situation both for mice and keyboard with filtering/driver/exclusive-locking. GlovePIE can filter keybaord data, it goes something like: write('z') = swallow(keyboard2.y); |
| Chasidy Heckenbach 24.10.2011 |
Originally Posted by ToS
|
| DJ MENSAH 24.10.2011 | Most usefull info would be: windows locks HID Keyb & Mice exclusively for itself. That's why driver must be written to be able to swallow/alter input data. Alas, if you don't need to discern between different input devices (but who needs that anyway), you can just use Low level hook, which will allow you to cancel events (not sure about altering event data). |
| Chasidy Heckenbach 23.10.2011 | since this thread got me interested in hid again i had a play with the hidapi library. no problem listing devices or reading/dumping button presses from my gamepad or touchpad when in numpad mode - but windows seems to be swallowing the mouse data when the touchpad is in normal mode - and i don't get any data at all. i'm probably doing something stupid as not spent too much time on it - would be handy if it would work via the hidapi - as then would be platform independant. alternatively... u have any good starting points for source code to just do this from windows for some userland code - not for a driver. i did install some free version of some micro$oft visual-something-c++ which came with various examples i believe. i'm definately not interested if i have to use their app to build tho... any info much appreciated anyway. |
| DJ MENSAH 23.10.2011 | fogmaster, how is that RawInput working out? |
| Chasidy Heckenbach 22.10.2011 |
Originally Posted by ToS
i'm pretty happy with it's stability and feature set now - and will at least be creating a new thread with a multi page launchpad mapping soon. but that's not really the point of midi masher ofc - it's so people can create/modify their own ones. be easier to have a more complete example as a starting point tho - esp as i haven't really documented any of the api |
| DJ MENSAH 22.10.2011 | That's one of the reasons I'm into writing a driver filter, to avoid complications (if possible at all). I'm really glad your midimasher gained traction. Maybe I did not write anything into the related thread but I'm subscribed to it for at least a month. |
| Chasidy Heckenbach 21.10.2011 |
Originally Posted by ToS
i did play about with the hidapi lib a bit and might be adding hid support into midimasher tho i have plenty of other stuff i want to code first. glovepie does work really well - and it doesn't eat up too much cpu - just depends if its too much or not i guess. it's very easy to configure. |
| DJ MENSAH 21.10.2011 | Hi zestoi, been asking when community
regulars are gonna join this thread. Among others, I'm eagerly waiting for nem0nic. As far as the GlovePIE is concerned, I had no idea that adds a lot of overhed but I did assumed that it is not as fast as I'd like. That's why I'm not using it for my project, which requires quite a bit of math and logic as real-time as possible. But for transfering mouse data to midi directly, I don't see much complexity there. Maybe it kills with refreshing the mouse cursor back to original position, or maybe it is a combo like mine, with rawInput and LL_Hook. |
| Chasidy Heckenbach 20.10.2011 |
Originally Posted by ToS
i used it to swallow the input from a usb touchpad and convert to midi. maybe i just made the script too complex. |
| DJ MENSAH 20.10.2011 | I will know that only when I start working on it (which did not happen yet). Btw, why aren't you using GlovePIE for your project? |
| Charline Alderton 19.10.2011 | ok, for now i decided to filter the rawinput according to the device handle. So my programm gets the input only from trackball but the cursor still moved by all mice and trackball. Thats enough for testing but a better solution would be nice. I am looking forward to to read from you Please don't feel scrambled but can you estimate how long it will take to develop your driver? Best regards |
| DJ MENSAH 16.10.2011 | Ok, the solution was a combo of RawInput and LL_MouseHook. Each in it's own separate process talking trough a named pipe. RawInput can discern between devices so it deceides which mouse is to be blocked, sends the info to Hook process which is allowed to "cancel" mouse events. Why Microsoft did not allow RawInput to cancel events, beats me but it's quite stupid. I'd like to help you with the driver but right now I'm stuck too with KMDF. |
| Charline Alderton 15.10.2011 | but you get the relativ xy-movement and can prevent that the values are used for the windows cursor? That would be great! Especially in user mode program! I intend to use a trackball for controlling the pan tilt movement of moving lights. I have already written am programm that overwrites some bytes in the process memory of the "grandma onPC" software. Now i need the xy-values of a usb trackball to overwrite the bytes of the simulated trackball in "grandma onPC". Can you help me with your current version of the driver? Best regards! |
| DJ MENSAH 15.10.2011 | Yes but that method is not time-accurate, I was not able to get the messages in each exact milisecond. |
| Charline Alderton 14.10.2011 | you are right. In my opinion a kernel mode driver is the only way to realize it too but in your first post you wrote that you tried to build this filter with some Windows API combo but is unstable. Which functions did you use? |
| DJ MENSAH 15.10.2011 | I haven't done much with driver filter as I'm having some troubles with initial research (both hardware and software related). I'm starting the work on kernel mode driver filter as soon as possible(I don't believe demo-moufiltr will be used.). |
| Charline Alderton 13.10.2011 | Hi Tos, i am interested in your filter driver. It is almost the solution i am looking for. I tried to build a lower level driver using the ddk samples but it does not work yet. The timestamp is not necessary for my aplication but i need the xy-data of a special mouse to use it in my program. This special device should not be used for the windows mouse cursor. Have you already finished your project? Would you share your sources? Would a cooperation be intersting for you? Best regards! |
<< Back to Reviews of DJ equipment Reply