On 15.02.19 02:30, daaron wrote:

The inputdriver was merged into master, so it should now be part of the
development snapshots of all operating systems. The documentation just
does not reflect that.

Also most development was/is done under linux, so if you have any issue
under MacOS, do not hesitate to ask for help.

With kind regards,

Michael Frey

Hi Michael,

Thanks - that’s great news. So how do I activate it / make it work?

Hi All,

Is there anyone who’s gotten 3D mouse support to work with OpenSCAD on a Mac?

I don't think anyone has worked on this on Mac specifically.
Any help to test it and/or write documentation/tutorials would be very helpful.

If you offer some insights into what you've tried so far and what works and doesn't work, perhaps someone here can help you further.

-Marius

I'd be delighted to help test and document this. So far, I've installed the
2019.1.30 snapshot build. In the Axis preferences pane, there are five
items under "Driver selection." Three are grayed out: SpaceNav, Joystick,
and DBus. The other two, HIDAPI and QGamepad, have no effect when selected.

I tried enabling "input-driver-dbus" on the features pane (and restarted),
but it did not enable DBus on the Axis pane nor have any other noticeable
effect.

Michael Frey suggested that inputdriver "should now be part of the
development snapshots of all operating systems" but I haven't found any
evidence of this in my installation.

I've installed the software/drivers that came with my 3Dconnexion
SpaceMouse, so I know the hardware works. But I haven't been able to get
OpenSCAD to respond to it in any way.

Apart from the above, I don't know what else to try. Anyone have any
suggestions?

On Wed, Feb 20, 2019 at 7:14 AM Marius Kintel marius@kintel.net wrote:

On 20.02.19 20:29, D. A. Karp wrote:

QGamepad is "best with a XBox 360 controller".

Note that I do not consider that good hardware, but QGamepad has a lot
of quirks specific to that Microsoft Hardware, making it borderline
unusable with other gamepads.

(I still like QGamepad as it is easy to develop with cross platform and
makes sense for Windows and also works for MacOSX with an XBox360
controller)

dbus is interprocess communcation protocol.

You need an other software to use dbus.
Currently, there is no end user software for dbus, so it is a developer
feature only currently.

In other words: Not relevant for just using a 3D-mice.

That could be a hint of what is going on.

For a spacemouse, you should active HIDAPI, stop the 3Dconnexion driver
and restart OpenSCAD.

At least this is how it works under Windows.

The HIDAPI driver directly talks to the SpaceMouse.

If the original driver is also running, the original driver blocks
OpenSCADs low level driver.

To be clear: OpenSCAD is not using an official 3Dconnexion protocol or
driver. OpenSCAD has its own driver and directly talks to the 3D-Mice.
Having the official driver running prevents that.

Now comes the worrying part:

I had the HIDAPI driver working at one point working on my Ubuntu Linux
machine.

Under Linux, programs that want to directly talk to a HID (human
interface device) need super user privileges.

meaning, starting openscad with

sudo ./openscad

which is worrying in many ways.

I do understand why linux does not want user space programs to take over
control over a HID. (If a user space program could directly talk to a
HID like keyboard, the user space programm could privilege escalate by
waiting for super user terminal)

I wonder if MacOSX has a similar protection the same reason(s). I also
wonder when Microsoft sees the issue in that, blocking our HIDAPI driver
under Windows - but given Microsoft track record for Windows 10 updates,
Microsoft breaking things by accident seams more likely then improving
security by intention.

To my understanding that is correct.

I would at, the most work was done under linux building on the joystick
driver with a gamepad.

A lot of things are generic once the input device is recognized and
working, but if not, it gets tricky.

The HIDAPI is partially operating system dependent, so having one Mice
working fine under linux does not mean it will work under Windows.

We do not have a documentation for the 3DConnex Device protocols - so
reversing the protocol contains trail and error.

Hardware (3D-Mice) is expensive (and every generation, sometimes even
variants with in a generation like wireless devices, have protocol
quirks), making things even harder.

With kind regards,

Michael Frey

On Wed, Feb 20, 2019 at 2:59 PM Michael Frey michael.frey@gmx.ch wrote:

I haven't tried the input devices stuff personally, but I think if you just
make sure your user is added to the group "input" , it should work without
requiring sudo

By the way, a quick way to troubleshoot this sort of permissions issue in
general, before resorting to running your program with sudo,  is to "ls -la
/dev/input" or whatever device file is giving you trouble, and you can see
the group its assigned to.

Alternatively you can modify the device permissions with a udev rule, but i
think they should be already set for reasonable group permissions.
Here's an article that shows setting udev rule:
https://puredata.info/docs/faq/how-can-i-set-permissions-so-hid-can-read-devices-in-gnu-linux

On Wed, Feb 20, 2019 at 3:16 PM Hans L thehans@gmail.com wrote:

Thanks for your help Torsten!  So I uninstalled the 3DConnexion software and rebooted. The spacemouse is now apparently being treated as a normal mouse everywhere, including OpenSCAD: twist zooms, other gestures pan. In other words, it's not working.

In Lib & Build Info, I see "InputDrivers: HidApiInputDriver" (image attached)

So are you saying that all I should need is the latest snapshot (I have 2019.2.20) and the HIDAPI option enabled? Am I missing something?

Thanks, Michael. The HIDAPI driver that comes with OpenSCAD - do I need to do anything beyond enabling HIDAPI in the Axis preferences pane to activate/install the driver?

On 21.02.19 20:10, D. A. Karp wrote:

It's more likely that it's an unknown receiver so the
driver does not find the device. We can check via the
USB info that should show the VENDORID and PRODUCTID.
We have a similar issue in discussion (for Windows)
with a device which calls itself "Universal Receiver".
(https://github.com/openscad/openscad/pull/2734)

Looks like the screenshots didn't make it, I think there
are some limits on attachment file size so maybe Nabble
stripped those out?

ciao,
Torsten.

Hi Torsten,

In OpenSCAD's Library Info, it does not identify my hardware like it does on yours. And in the Hardware pane of About This Mac, the entry for my spacemouse is similar to yours, but the product ID is different. I have the Spacemouse Compact, not the wireless. Could that be the problem?

On 23.02.19 19:31, D. A. Karp wrote:

Yes, we did not have that device yet. I've added it to the list
hoping it will use the same data as the other devices.
We'll need to check with a new snapshot if it works now. If not,
I have to get the debug stuff in shape for official inclusion
so we can track what's going on...

ciao,
Torsten.

Is there anything I can do now to help test it, or should I just wait for the next snapshot?

On Feb 23, 2019, at 14:03, D. A. Karp daaron@gmail.com wrote:

I'll build one today and let you know.

-Marius

Thanks, Marius. Just tried 2019.02.23 - it now recognizes the Spacemouse (see screenshot) but I get no response whatsoever when I move the mouse. Anything else I can try?

On 24.02.19 01:02, D. A. Karp wrote:

Aww, that means it's sending data different from the other known
devices.

I'll get the tracing code into shape for actually shipping it, so
far it was only meant for some special testing...
So please hold on for a bit, there should be a version shortly that
(hopefully) dumps the info about the device into a file so we can
see how to support this device.

ciao,
Torsten.