Ugh. Worse than I thought. AFAIK, RFB doesn't support any kind of
XINPUT-style event structure. The RFB PointerEvent simply encapsulates
a button mask and an X and Y position. A new message type, and possibly
multiple new message types, would be needed to support a 3D mouse.
On 10/8/13 2:55 PM, Nathan Kidd wrote:
> 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
> 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).