I have multiple mice connected to my OSX computer. By default, all connected mice seem to act as normal mice, ie, move the cursor, etc. Instead, I would like my app to use one mouse (in this case only my trackpad) as a normal mouse, and then use the x,y input from the other mice for different purposes. I have two questions for this task:
Is it possible for wx to recognize and tell me which mouse generated a given event?
To make the cursor not respond to moving the mouse, I had thought that if I did “wx.Bind(wx.EVT_MOTION, self.OnMotion)”, and then if in “OnMotion” I didn’t call “evt.Skip()”, the event would not propagate and the cursor would not move. Instead, I find that the cursor always moves, whether or not I call “evt.Skip()”. Is there a way to redirect a mouse event so the cursor does not move?
Currently I’m using version ‘3.0.0.0 osx-cocoa (classic)’ on an OSX 10.9.5 on a MacBook Pro and the additional mice are connected through the built-in ports.
I have multiple mice connected to my OSX computer. By default, all connected mice seem to act as normal mice, ie, move the cursor, etc. Instead, I would like my app to use one mouse (in this case only my trackpad) as a normal mouse, and then use the x,y input from the other mice for different purposes. I have two questions for this task:
1) Is it possible for wx to recognize and tell me which mouse generated a given event?
No, not because of a limitation in wx, but because of the design of the operating systems. All inputs from all mice are merged together into one single input queue. There is no source identification. You need drivers to make this kind of thing work.
2) To make the cursor not respond to moving the mouse, I had thought that if I did "wx.Bind(wx.EVT_MOTION, self.OnMotion)", and then if in "OnMotion" I didn't call "evt.Skip()", the event would not propagate and the cursor would not move. Instead, I find that the cursor always moves, whether or not I call "evt.Skip()". Is there a way to redirect a mouse event so the cursor does not move?
There is fundamental, low-level plumbing in the operating systems to make mouse motion consistent and reliable. You are being TOLD that there was mouse motion, but you do not get a chance to VETO that motion. The pointer is going to move. You can’t stop it. Calling Skip simply means that whatever control or window you are managing will not do whatever it would ordinarily have done in response to motion.
···
On Mar 24, 2015, at 10:14 AM, Tom <tom066886@gmail.com> wrote:
—
Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.
You can hide the mouse cursor and you can continuously move the mouse cursor to the same position making it appear the mouse didn’t move, IF you can control the flicker.
Thanks Tim. It’s helpful to know that there’s no wx based solution available to me, and some of the reason why this is.
For those who are interested in how this might be done, I see two possible solutions that aren’t very difficult. For clarity, I’ll specify here that I’m using OSX on a MacBook Pro, and want to use the built-in trackpad (M0) as a normal mouse, and then connect two additional mice (M1 and M2) for x,y inputs that I use for other purposes.
Option 1 (before posting my question I had a crude version of this working so I know it basically works):
Use something like PyHID (http://www.wooji-juice.com/free/pyhid/), or cython-hidapi (https://github.com/gbishop/cython-hidapi) to capture and differential inputs from all three mice. With this approach, all three mice will still drive the mouse cursor which I don’t want M1 and M2 to do, so then I had an approach like DevPlayer suggested to hide and cripple the mouse motion. The downside is that then M0 does no longer acts as a regular mouse. This approach basically works, and one can still press a key to allow regular mouse usage, which technically works but was too cumbersome for my application because of M0 not working. (A variation of this is to use time correlation between PyHID events and EVT_MOTION to know when M0 is being used and then I could unhide the mouse just for those times, but I think that this will still be too much of a hassle for the user. Of course here M0 couldn’t be used simultaneously with M1 and M2 while still keeping everything separate.)
Option 2 (untested but I’ve ordered the parts):
Use two Arduino boards with two USB host shields ( like, http://www.circuitsathome.com/arduino_usb_host_shield_projects ) for M1 and M2, and then use the Arduino boards to convert the HID mouse input signal into regular serial data that I can read through PySerial. Then only M0 will be interpreted by the OS as a mouse, so motion of M1 and M2 can just provide the pure x,y data I need. This will cost about $100, which is worth it for my current application.
Option 2 (untested but I've ordered the parts):
Use two Arduino boards with two USB host shields ( like, http://www.circuitsathome.com/arduino_usb_host_shield_projects ) for
M1 and M2, and then use the Arduino boards to convert the HID mouse
input signal into regular serial data that I can read through
PySerial. Then only M0 will be interpreted by the OS as a mouse, so
motion of M1 and M2 can just provide the pure x,y data I need. This
will cost about $100, which is worth it for my current application.
If you are a hardware-oriented guy, this solution might not appeal to
you, but it is possible to do what you want (on Windows, anyway) by
writing a filter driver to rewrite the descriptors on the M1 and M2
mice, thereby changing the collection from a mouse collection to a
generic HID collection. You could then use the HID library to gain
exclusive access to their reports.
In fact, thinking outside the box a little, for a cross-platform
solution you could use libusb. Libusb replaces the normal driver for a
device with a generic driver. Thus, you would disconnect the mice from
the operating system's mouse queue and control them directly. You would
have to know enough of the HID protocol to communicate with the devices,
but that's not rocket science, and you would have to do that anyway to
translate it to serial in your Arduino hack.
···
--
Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.