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.
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?
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.).
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?
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!
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.
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?
Hi zestoi, been asking when forum 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.
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.
cool, cheers did seem to take a while to get any real interest but what most people want/expect will be a complete mapping for a certain controller etc that they can just run with.
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
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 think. i’m definately not interested if i have to use their app to build tho… any info much appreciated anyway.
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).
surely you’d only need a driver if you wanted to use+swallow events from multiple keyboards? glovepie is able to discern between multiple mice+swallow their events. it can’t for multiple keyboards tho.
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:
i thought that didn’t work - or at least that’s what someone else had reported. i don’t have a second keyboard here to test with. i thought u could swallow keyboard events or you could discern between different keyboards.
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:
[quote]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 [/quote]
slightly OT ofc as this thread isn’t even about keyboards anyway… but if the info i had found out before was wrong then i’ll know better for the next time someone asks about it…
Please don’t feel scrambled but can you estimate how long it will take to develop your driver?
did seem to take a while to get any real interest but what most people want/expect will be a complete mapping for a certain controller etc that they can just run with.