macOS Big Sur and Monterey - Pre-release Driver Available
Moderator: Moderators
-
- Posts: 49
- Joined: Sun Dec 19, 2010 11:46 am
- Location: Veenendaal, The Netherlands
Re: macOS Big Sur - Beta Driver Available
Here with my SpaceMouse Pro Wireless with driver 10.7.0 (3333), MacOS 11.4 and Maya 2022, the SM just stops working randomly in Maya multiple times a day. I'll be working and all of a sudden my viewports won't respond anymore. If I then open systemprefferences and check the demos in there, they'll work perfectly fine.
Maya itself works fine, I can do everything else, just not use the SpaceMouse. Restarting Maya fixes it.
I mentioned unplugging and reconnecting the USB receiver, above, but I tried that just now and it didn't fix it, while restarting Maya did.
I'm now questioning if unplugging it actually worked before, or if that might have fixed something else? Not sure. I'll keep an eye on it and report back.
Same with button presses. I'm not sure if the buttons keep working and it's just the knob/camera movement or if the entire thing doesn't respond anymore.
Maya itself works fine, I can do everything else, just not use the SpaceMouse. Restarting Maya fixes it.
I mentioned unplugging and reconnecting the USB receiver, above, but I tried that just now and it didn't fix it, while restarting Maya did.
I'm now questioning if unplugging it actually worked before, or if that might have fixed something else? Not sure. I'll keep an eye on it and report back.
Same with button presses. I'm not sure if the buttons keep working and it's just the knob/camera movement or if the entire thing doesn't respond anymore.
It's time to roll the dice...
-
- Posts: 46
- Joined: Thu Feb 11, 2021 11:43 pm
Re: macOS Big Sur - Beta Driver Available
No error message. Moving the control knob does nothing to the viewport. The same as reported by @RVeldhuyzen below.
I really need stability as working in this situation is not sustainable.
Greg
-
- Posts: 49
- Joined: Sun Dec 19, 2010 11:46 am
- Location: Veenendaal, The Netherlands
Re: macOS Big Sur - Beta Driver Available
Okay, a little extra info.
When this happens it's just the knob, all the buttons continue to function. And the viewports can still be manipulated through conventional means (Alt+click, etc).
This might be anecdote/a coincidence, but I just had this happen the exact moment Maya autosaved. I was working, Maya did an autosave as I was moving the knob and after Maya was done saving the knob didn't work anymore.
Maya autosaves every 5 minutes for me, and since it doesn't happen every 5 minutes it might be the combination of moving the knob and the auto save at the same time?
I'll try and see if I can reproduces it on purpose.
It's time to roll the dice...
-
- Posts: 49
- Joined: Sun Dec 19, 2010 11:46 am
- Location: Veenendaal, The Netherlands
Re: macOS Big Sur - Beta Driver Available
Yes, movement while saving is definitely where the issue is. You can reproduce it by jiggling the knob and pressing CMD+S.
It's not autosave, just saving while the knob is moving. The file needs a little time to save, I can't get it to work in an empty scene, but a larger one does it without fail if the knob moves a bit WHILE it is saving. If the knob is tilted and stays in more or less the same position while saving nothing happens. But if I change directions while saving or just randomly jiggle it while saving it stops working.
Hope this helps
It's not autosave, just saving while the knob is moving. The file needs a little time to save, I can't get it to work in an empty scene, but a larger one does it without fail if the knob moves a bit WHILE it is saving. If the knob is tilted and stays in more or less the same position while saving nothing happens. But if I change directions while saving or just randomly jiggle it while saving it stops working.
Hope this helps
It's time to roll the dice...
Re: macOS Big Sur - Beta Driver Available
That's interesting. Thank you for sharing this information. We'll look into it.RVeldhuyzen wrote: ↑Tue Jun 15, 2021 1:16 am Yes, movement while saving is definitely where the issue is. You can reproduce it by jiggling the knob and pressing CMD+S.
-
- Posts: 49
- Joined: Sun Dec 19, 2010 11:46 am
- Location: Veenendaal, The Netherlands
Re: macOS Big Sur - Beta Driver Available
No problem, hope it helpsngomes wrote: ↑Tue Jun 15, 2021 1:32 amThat's interesting. Thank you for sharing this information. We'll look into it.RVeldhuyzen wrote: ↑Tue Jun 15, 2021 1:16 am Yes, movement while saving is definitely where the issue is. You can reproduce it by jiggling the knob and pressing CMD+S.
It's time to roll the dice...
-
- Posts: 46
- Joined: Thu Feb 11, 2021 11:43 pm
Re: macOS Big Sur - Beta Driver Available
I can reproduce the behavior noted by RVeldhuyzen. Lose the ability to navigate in the viewports with the control knob if using the knob to navigate while saving.ngomes wrote: ↑Tue Jun 15, 2021 1:32 amThat's interesting. Thank you for sharing this information. We'll look into it.RVeldhuyzen wrote: ↑Tue Jun 15, 2021 1:16 am Yes, movement while saving is definitely where the issue is. You can reproduce it by jiggling the knob and pressing CMD+S.
Greg
Re: macOS Big Sur - Beta Driver Available
Hi, first time SpaceMouse user so maybe I'm missing something obvious.
I'm using the SM-wireless on OSX BigSur on a specced out 16" mbp with the latest 3DC Beta drivers.
After installing the driver (I have done so twice now. instal>uninstall>instal) any movement of the knob makes the mouse cursor jump to the top left of the screen and click the "apple" icon briefly. Pressing it down opens widgets and so on..it seems to be mapped to random key and mouse functions.
Both connected with a cable and wireless produce the same result and this behaviour is in all programs, or rather it seems like it doesn't register any programs at all.
In the 3DC system settings under "tools" it says "Device not found" so maybe thats why? But the device is being picked up by the OS somehow, and mapping to certain clicks etc, so I'm not sure why the driver doesn't see it.
One caveat is I'm connecting it via a usb hub in my monitor, once i get a usb-c adapter I'll test plugging it directly into the laptop.
Anyway..is there anything I'm missing? Maybe some setup steps I haven't done or something?
I'm using the SM-wireless on OSX BigSur on a specced out 16" mbp with the latest 3DC Beta drivers.
After installing the driver (I have done so twice now. instal>uninstall>instal) any movement of the knob makes the mouse cursor jump to the top left of the screen and click the "apple" icon briefly. Pressing it down opens widgets and so on..it seems to be mapped to random key and mouse functions.
Both connected with a cable and wireless produce the same result and this behaviour is in all programs, or rather it seems like it doesn't register any programs at all.
In the 3DC system settings under "tools" it says "Device not found" so maybe thats why? But the device is being picked up by the OS somehow, and mapping to certain clicks etc, so I'm not sure why the driver doesn't see it.
One caveat is I'm connecting it via a usb hub in my monitor, once i get a usb-c adapter I'll test plugging it directly into the laptop.
Anyway..is there anything I'm missing? Maybe some setup steps I haven't done or something?
Re: macOS Big Sur - Beta Driver Available
This is a tell-tale sign the driver isn't able to access the device. Instead the system is using the device data to control the mouse pointer.
See if rebooting allows the driver to access the device. If the issue persists, then there's something on your system that prevents the driver from accessing the hardware.
Re: macOS Big Sur - Beta Driver Available
Remember when you do the install to have system preferences/security open you'll need to allow drivers and stuff
-
- Posts: 1
- Joined: Wed Jul 07, 2021 5:43 pm
Re: macOS Big Sur - Beta Driver Available
Summary: The Big Sur driver (10.7.0 r3333 Beta16) conflicts with VRPN
When it's installed, the vrpn_server cannot access the SpaceMouse Wireless.
VRPN is very awesome - it allows you to send your SpaceMouse data values to a remote host (yay Covid). It generalises almost ALL input devices into a standard format, and then makes them available across the internet in the sense of deviceXX@hostname - it also generalises input devices, so you as a programmer can just talk about a button, without having to know the exact "sort" of particular button it is. So good!
We have a problem with VRPN & the spaceMouse on OSX.
(unrelated aside: we would ALSO love Google Earth to work again!! note, in linux, when google decided to giveup further development, it seems they stopped use of the 3DConnexion driver, and preferred the Open Source version: spacenavd. From the user perspective, we just want things to work.. I wonder "how bad" things might be if 3DConnexion just released their driver on github - so we don't need to beg for fixes? ... Perhaps we could help fix it? anyway)
Before & After logs appear below. This was sent today via the feedback request form on: https://3dconnexion.com/uk/support/faq/ ... 1-big-sur/
Mac mini (2018) with OSX Big Sur 11.4
3DConnexion Driver: Version 10.7.0 r3333 – Beta 16 – published on 11/05/2021
We have the new-style and old-style SpaceMouse Wireless. The new-style has a different dongle which allows multiple (up to 4?) SMs to connect. The old-style (which i use here) has a dongle where only 1 SM connects.
To know if you have a new or old spaceMouse wireless, check the Vendor/Product values:
In some cases you need the decimal value. int(0xc62f) is 50735, int(0xc652) is 50770, int(0x256f) is 9583
We use (and need) VRPN - mostly on linux, but recently wanted it to work on OSX. In particular, we wanted the newer style SM (c652 dongle) to work. In the case below, i'm using the old dongle (c62f).
Unfortunately, VRPN has been changed a bit lately - the space mouse sends 12-bytes - it seems someone didn't know this, and produced a new version which limits things to 4-bytes, or thereabouts. Look-out. I'm expecting it to be fixed as soon as some other SpaceMouse users report the break! Worse, though, the new dongle adds a byte (to indicate which SM). So, actually, VRPN needs a mod to handle this extra byte. Total is 13-bytes.
We have made the simple mod (which affects the vrpn/vrpn_3DConnexion.C file) & will soon send a Pull Request to the VRPN github site https://github.com/vrpn/vrpn
Meantime! (apologies for the long post) it seems the OSX Driver blocks access to the SM? We don't have a lot of experience with OSX devices. It's so much simpler in linux! "every device is treated as a file" ... Does the 3DConnexion driver "consume" the data stream from the SM, or can it share?
VRPN has been compiled with the following options, set in CMake-gui.. XCode needs to be installed. The following commands will build you a VRPN server. Usually we test with 2 windows. One runs the. The other window pretends to be a client running . however, there is a simpler test where you just run in one terminal.
To do this, you need to know the decimal values for the spacemouse (being 9583 and 50735). You'll see this in the BEFORE / AFTER VRPN tests below
Here's how to make VRPN onthe Mac, btw:
BEFORE:
Now the 3DConnexion driver is installed, and the mac mini rebooted. The same test is run:
AFTER
When it's installed, the vrpn_server cannot access the SpaceMouse Wireless.
VRPN is very awesome - it allows you to send your SpaceMouse data values to a remote host (yay Covid). It generalises almost ALL input devices into a standard format, and then makes them available across the internet in the sense of deviceXX@hostname - it also generalises input devices, so you as a programmer can just talk about a button, without having to know the exact "sort" of particular button it is. So good!
We have a problem with VRPN & the spaceMouse on OSX.
(unrelated aside: we would ALSO love Google Earth to work again!! note, in linux, when google decided to giveup further development, it seems they stopped use of the 3DConnexion driver, and preferred the Open Source version: spacenavd. From the user perspective, we just want things to work.. I wonder "how bad" things might be if 3DConnexion just released their driver on github - so we don't need to beg for fixes? ... Perhaps we could help fix it? anyway)
Before & After logs appear below. This was sent today via the feedback request form on: https://3dconnexion.com/uk/support/faq/ ... 1-big-sur/
Mac mini (2018) with OSX Big Sur 11.4
3DConnexion Driver: Version 10.7.0 r3333 – Beta 16 – published on 11/05/2021
We have the new-style and old-style SpaceMouse Wireless. The new-style has a different dongle which allows multiple (up to 4?) SMs to connect. The old-style (which i use here) has a dongle where only 1 SM connects.
To know if you have a new or old spaceMouse wireless, check the Vendor/Product values:
Code: Select all
In both cases, the Vendor=256f (decimal 9583)
old receiver id = c62f (dec 50735)
new receiver id = c652 (dec 50770)
We use (and need) VRPN - mostly on linux, but recently wanted it to work on OSX. In particular, we wanted the newer style SM (c652 dongle) to work. In the case below, i'm using the old dongle (c62f).
Unfortunately, VRPN has been changed a bit lately - the space mouse sends 12-bytes - it seems someone didn't know this, and produced a new version which limits things to 4-bytes, or thereabouts. Look-out. I'm expecting it to be fixed as soon as some other SpaceMouse users report the break! Worse, though, the new dongle adds a byte (to indicate which SM). So, actually, VRPN needs a mod to handle this extra byte. Total is 13-bytes.
We have made the simple mod (which affects the vrpn/vrpn_3DConnexion.C file) & will soon send a Pull Request to the VRPN github site https://github.com/vrpn/vrpn
Meantime! (apologies for the long post) it seems the OSX Driver blocks access to the SM? We don't have a lot of experience with OSX devices. It's so much simpler in linux! "every device is treated as a file" ... Does the 3DConnexion driver "consume" the data stream from the SM, or can it share?
VRPN has been compiled with the following options, set in CMake-gui.. XCode needs to be installed. The following commands will build you a VRPN server. Usually we test with 2 windows. One runs the
Code: Select all
vrpn_server
Code: Select all
vrpn_print_device
Code: Select all
vrpn_HID_device_watcher
To do this, you need to know the decimal values for the spacemouse (being 9583 and 50735). You'll see this in the BEFORE / AFTER VRPN tests below
Here's how to make VRPN onthe Mac, btw:
Code: Select all
% brew install --cask cmake
% brew install hidapi
% git clone https://github.com/vrpn/vrpn
% mkdir Build
% cd Build
% cmake-gui ../vrpn
Build Native linux style Makefile
press configure
enable:
VRPN_HIDAPI_USE_LIBUSB
VRPN_USE_HID
VRPN_HID_DEBUGGING
disabled:
VRPN_USE_LOCAL_HIDAPI
VRPN_USE_LIBUSB_1_0
Press configure, configure, generate to have cmake-gui create the Makefile. Then quit.
% make
% make install
BEFORE:
Code: Select all
Script started on Thu Jul 8 09:48:42 2021
bens-Mac-mini vrpn % vrpn_HID_device_watcher 9583 50735
Will accept HID device number 0 that has vendor:product 256f:c62f
vrpn_HidInterface::reconnect(): Found 3Dconnexion SpaceMouse Wireless Receiver (256f:c62f) at path IOService:/AppleACPIPlatformExpert/PCI0@0/AppleACPIPCI/XHC1@14/XHC1@14000000/HS14@14600000/SpaceMouse Wireless Receiver@14600000/IOUSBHostInterface@0/AppleUserUSBHostHIDDevice - will attempt to open.
vrpn_HidInterface::reconnect(): Device successfully opened.
HID initialized.
Connected: HID device vendor ID 9583, product ID 50735, aka 256f:c62f
Entering update loop.
13 bytes: 01 00 00 00 00 3E 00 00 00 00 00 00 00
13 bytes: 01 00 00 00 00 3E 00 00 00 00 00 00 00
13 bytes: 01 00 00 00 00 2D 00 00 00 00 00 00 00
13 bytes: 01 00 00 00 00 05 00 00 00 00 00 00 00
13 bytes: 01 00 00 00 00 00 00 00 00 00 00 00 00
13 bytes: 01 00 00 00 00 00 00 00 00 00 00 00 00
13 bytes: 01 00 00 00 00 00 00 00 00 00 00 00 00
13 bytes: 01 00 00 00 00 00 00 00 00 00 00 00 00
3 bytes: 17 48 00
3 bytes: 03 01 00
3 bytes: 03 00 00
3 bytes: 03 02 00
3 bytes: 03 00 00
13 bytes: 01 00 00 00 00 00 00 00 00 00 00 02 00
13 bytes: 01 00 00 00 00 00 00 00 00 00 00 0A 00
13 bytes: 01 00 00 00 00 01 00 00 00 00 00 1A 00
13 bytes: 01 00 00 00 00 03 00 00 00 00 00 21 00
13 bytes: 01 00 00 00 00 08 00 00 00 00 00 29 00
13 bytes: 01 00 00 00 00 0A 00 00 00 00 00 2F 00
13 bytes: 01 00 00 00 00 0C 00 00 00 00 00 35 00
13 bytes: 01 00 00 00 00 0C 00 00 00 00 00 36 00
13 bytes: 01 00 00 00 00 01 00 00 00 00 00 24 00
13 bytes: 01 05 00 00 00 00 00 00 00 00 00 1F 00
13 bytes: 01 0D 00 00 00 00 00 00 00 00 00 06 00
13 bytes: 01 00 00 00 00 00 00 00 00 00 00 00 00
:
13 bytes: 01 00 00 F1 FF 10 00 FD FF 00 00 C2 FF
13 bytes: 01 00 00 EF FF 0C 00 00 00 00 00 C8 FF
13 bytes: 01 00 00 F0 FF 01 00 00 00 00 00 D0 FF
13 bytes: 01 00 00 F2 FF 00 00 00 00 00 00 F4 FF
13 bytes: 01 00 00 00 00 00 00 00 00 00 00 00 00
13 bytes: 01 00 00 00 00 00 00 00 00 00 00 00 00
13 bytes: 01 00 00 00 00 00 00 00 00 00 00 00 00
13 bytes: 01 00 00 00 00 00 00 00 00 00 00 00 00
^C
ben@bens-Mac-mini logs %
AFTER
Code: Select all
ben@bens-Mac-mini logs % vrpn_HID_device_watcher 9583 50735
Will accept HID device number 0 that has vendor:product 256f:c62f
vrpn_HidInterface::reconnect(): Found 3Dconnexion SpaceMouse Wireless Receiver (256f:c62f) at path IOService:/AppleACPIPlatformExpert/PCI0@0/AppleACPIPCI/XHC1@14/XHC1@14000000/HS14@14600000/SpaceMouse Wireless Receiver@14600000/IOUSBHostInterface@0/AppleUserUSBHostHIDDevice - will attempt to open.
vrpn_HidInterface::reconnect(): Could not open device IOService:/AppleACPIPlatformExpert/PCI0@0/AppleACPIPCI/XHC1@14/XHC1@14000000/HS14@14600000/SpaceMouse Wireless Receiver@14600000/IOUSBHostInterface@0/AppleUserUSBHostHIDDevice
vrpn_HidInterface::reconnect(): error message: hid_error is not implemented yet
HID initialized.
Could not connect.
Re: macOS Big Sur - Beta Driver Available
Google has looked into this and 3D mouse support will soon be available. We discussed this issue elsewhere in this topic (see here).
What are you looking to see fixed?so we don't need to beg for fixes? ... Perhaps we could help fix it?
I think you are referring to a device we name "Universal Receiver". It can pair up to five CadMouse or SpaceMouse devices.The new-style has a different dongle which allows multiple (up to 4?) SMs to connect.
The more recent SpaceMouse devices use a "long" report. This is 13 bytes, yes.Total is 13-bytes.
This is new in macOS 11. Our driver daemon now has to get an exclusive "hold" of the device. Failing to do this has the system using the device data to control the mouse pointer. In older versions of the operating system, our daemon didn't need to "grab" device exclusively since we used a kernel extension to prevent the erroneous behaviour. Apple deprecated kernel extensions in macOS 10.15 and support was removed in macOS 11.it seems the OSX Driver blocks access to the SM?
To test this, kill the daemon process ("3DconnexionHelper") before attempting to connect to the device. Killing the daemon prevents other applications from using the device (since the daemon works as a broker).
Re: macOS Big Sur - Beta Driver Available
so we don't need to beg for fixes? ... Perhaps we could help fix it?
The Space Mouse is still basically useless for Zbrush 8 months after the release of Big Sur, that's pretty crazy.What are you looking to see fixed?
I just posted mine to eBay, for a loss I'm sure.
Re: macOS Big Sur - Beta Driver Available
Is there a release of 10.7.x available that I'm not seeing? The beta was 8+ months ago…
Re: macOS Big Sur - Beta Driver Available
This is wild. Still rocking basic functions after 10 months. I guess 3D Connexion doesn't make enough money on Mac users to justify the continued support of their products. I have 3 of their products and 1 of them is good for the garbage after the last update.
I'm thinking about contracting out the development of a working driver. We should start a kick starter. Everyone pitch in 20 bucks and get it done : )
I'm thinking about contracting out the development of a working driver. We should start a kick starter. Everyone pitch in 20 bucks and get it done : )