Bug 3418 - Support for Spacemouse
Summary: Support for Spacemouse
Status: NEW
Alias: None
Product: ThinLinc
Classification: Unclassified
Component: Other (show other bugs)
Version: 3.0.0
Hardware: PC Unknown
: P2 Normal
Target Milestone: LowPrio
Assignee: Peter Åstrand
Depends on:
Blocks: 7102
  Show dependency treegraph
Reported: 2010-02-17 15:38 CET by Peter Åstrand
Modified: 2022-04-13 15:28 CEST (History)
0 users

See Also:
Acceptance Criteria:


Comment 1 Peter Åstrand cendio 2010-02-18 11:11:00 CET
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. 
Comment 3 Peter Åstrand cendio 2013-10-09 08:56:57 CEST
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).


OpenText Corp.
Comment 5 Peter Åstrand cendio 2019-04-30 10:28:10 CEST
This project might be useful:

Comment 8 Pierre Ossman cendio 2022-04-13 15:28:08 CEST
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.
Comment 9 Pierre Ossman cendio 2022-04-13 15:28:33 CEST
The above was tested on Fedora 35.

Note You need to log in before you can comment on or make changes to this bug.