I've done some research, and Pierre and I have discussed this. On the positive side is that the http://spacenav.sourceforge.net project is nice, and that the communication is fairly simple. Thus, getting a solution for Linux clients and Linux applications can probably be done in a week or so. However, since we are aiming for support in Windows Terminal Servers and VirtualBox as well, they must be considered when designing the over-the-wire protocol. This will likely take a substantial amount of time.
Some information from the VirtualGL mailing list: Date: Tue, 08 Oct 2013 15:55:33 -0400 From: Nathan Kidd <nathan-ml@spicycrypto.ca> Reply-To: VirtualGL Users <virtualgl-users@lists.sourceforge.net> To: VirtualGL Users <virtualgl-users@lists.sourceforge.net> Subject: Re: [VirtualGL-Users] 3D mouse virtualization with TurboVNC On 10/07/2013 05:32 PM, DRC wrote: > On 10/7/13 3:56 PM, Karthikeyan Balu wrote: >>> I’m not sure whether their drivers support access from Virtual display >>> servers ? and I guess TurboVNC being able to simulate these inputs comes >>> next. Any experience. > 3DConnexion unfortunately does things at a fairly low level, rather than using, for > instance, the X Input Extension or some other mechanism that would be > easier for TurboVNC to implement. AFAIK, their "driver" on the Linux > side is basically tapping into USB directly and then translating the > device movements to raw mouse inputs, and they must be feeding them into > the X server using XTest or some other mechanism that TurboVNC already > supports. To make this work (we do it with Exceed onDemand), one needs to: 1. On Windows desktop client, link to 3dConnexion's SDK (awful, buggy drivers) to read the input device events. Historically one did this on a separate thread (did I mention awful, buggy drivers?). 2. Deliver event info to X server. If RFB is supporting any XINPUT events there is a standard (see 3dConnexion SDK) way to pack the axis/period info into a DeviceValuator. 3. From X server, using a choice of XINPUT or older Magellan protocol (magic atom queried by apps, Client Events) deliver events to X clients that requested them. Preferably you do both because often apps support only one of them. And then bear in mind that there is a variant "Spaceball" protocol, different from Magellan, that apps like Catia use. I've been unable to find any documentation on how that is supposed to work (and, sadly, Dassault seems less interested in interoperability). -Nathan -- OpenText Corp.
This project might be useful: https://github.com/vrpn/vrpn/wiki
I did a quick test of the three different devices we have here, and the results aren't great: * SpacePilot: shows up in xinput as a mouse, i.e. two axes and nine buttons mapped to standard mouse buttons * SpaceTraveler: no xinput at all * SpaceExplorer: no xinput at all All three are correctly discovered by the kernel though and all 6 axes are functional on the evdev device. Buttons don't really map to anything sane, but they all seem to give events at least.
The above was tested on Fedora 35.
