In addition to two mice and a space navigator I’m also using a Wacom intuos pro and if the settings of the tablet were a little more open… the tablet could be used to control the Graddhopper canvas on the second screen. The settings allow mapping the tablet to one of two screens but setting up a gesture for dragging and zooming? I don’t know how…
No matter which device, I think we need to be able to restrict the mapping to one of multiple screens.
For that I guess the wacom tablet is sending also some standard data of a pen/finger touch or pinch/drag. I guess (x2) you should be able to solve this with standard Microsoft libraries.
I do not have any touch-capable screen to do any basic test. (Maybe I have an ultra-cheap tablet somewhere…)
Anyway this is OT. Might be interesting creating a thread for touchscreens and discuss and share the tests there.
You’re probably not understanding what I was saying. I’ve said it many times in the forum over the years, I could probably find other threads where I’ve described it better.
I wouldn’t want to hijack another thread and steer it into a more extreme direction than it is.
Although it would be nice if GH was more compatible with 3D mice, as any microsoft or macintosh program for that matter.
Someday maybe the world will be more compatible with 3D.
I believe, like is V5, we were or do use a “driver” they developed, but I could be wrong.
I prefer 3dconnexions newest ones, but there’s still issues with them.
Maybe true, while I wish more people would have higher magnitude of tendency to desire a world more compatible with 3D mice.
I know of at least 2 spaceball 5000’s that wore out after about 10 yrs.
I’ll add that when using Fusion 360 in parallel with Rhino, the 3DX mouse works fine in Fusion, but no longer works in Rhino when I switch back to it.
The only way to re-activate it in Rhino is to close Fusion, close Rhino and open Rhino back.
This is appalling.
Indeed, this has become a very common problem between different programs using the modern drivers.
If you go back maybe 10 yrs or so I don’t recall separate programs having this issue.
It’s as if rather than 3D mice becoming more compatible with our world, they’ve gotten overly complicated in the way different programs try to get them to work. So there’s always conflicts.
If only they were plug and play like 2D mice.
Maybe we need a new 3D operating system in this world or something. 
I contacted (once again?) 3dconnexion and linked this thread and explained about the grasshopper canva thing.
They replied me and told me: “Grasshopper support for the SpaceMouse had been documented internally for 3Dconnexion in report KAI-2224.”
Let’s wait hopefully.
So they have a paper trace of them working on it ?
Whoa that would be nice !
And a toggle to keep the 3d mouse active in Rhino. Best of both worlds whenever you need it.
Yesterday I did send another email to 3d connexion also asking that.
(I too would prefer moving rhino camera most of the time even when GH is shown…)
I also asked if it was possible to expose current methods and classes from the current .rhp plugin, so we could develop “with” the current plugin, instead developing our own code from scratch from their SDK, thing that would likely collide with their plugin.
I went ahead and even asked if they could simply share their source code (visual studio project?) 
That’s pretty daring of you, hope they will like the guts
I wonder if they ever got back to you?
Using your script as a starting point, and heavily relying on my dear friend Claude.ai, (I only do basic Python) I got it working with their SDK.
It runs smoothly, but 1 “minor” issue: as you suspected, it clashes with their plugin. It takes exclusive ownership of the device –> Rhino times out and doesn’t reconnect automatically –> can only be restarted by restarting Rhino.
The script can run smoothly indefinitely within GH, but it’ll require a rhino restart to work in a viewport again.
Perhaps someone smarter than me has some bright ideas to move this forward? Perhaps a future version of rhino can expose an API for reestablishing a connection with the spacemounse plugin
Please find attached for anyone who wants to have a tinker.
GoingHyperspace v0.1.gh (5.8 KB)
Here’s what I found out : Fusion 360 recently moved to a newer integration method (SDK 4). This allows for much deeper integration (like 3D mouse buttons triggering specific Fusion commands), but it is much “greedier” with the driver focus. When Fusion 360 is open, it essentially tells the driver, “I’m in charge now,” and doesn’t always signal the driver to look for other apps when you switch windows.
The solution is :
I’ll give it a try, Mcneel should really consider that for GH2, huge navigation update.
From memory, the TDx.TDxInput.dll file ships with the 3DxWare driver.
It should be somewhere in the 3Dconnexion folder in Program Files. I think it needed to be placed in either Libraries or Components folder. Maybe, but less certain, it could also be placed in the same folder as the GH file using the script. In any way, it needed to be in a folder that was registered with Grasshopper in order for it to work.
I hope this is more helpful than it feels to me. 
I’d check for you but I haven’t been using the script much, because it’s a bit clunky, and I also never installed the driver on my new computer I got after playing around with this.
From memory, the TDx.TDxInput.dll file ships with the 3DxWare driver.
It should be somewhere in the 3Dconnexion folder in Program Files. I think it needed to be placed in either Libraries or Components folder. Maybe, but less certain, it could also be placed in the same folder as the GH file using the script. In any way, it needed to be in a folder that was registered with Grasshopper in order for it to work.
I hope this is more helpful than it feels to me.
I’d check for you but I haven’t been using the script much, because it’s a bit clunky, and I also never installed the driver on my new computer I got after playing around with this.
EDIT: Confirmed. DLL file should be in the Components folder 