I expected the SpaceMouse Pro to report 256 buttons like the SpaceMouse
Enterprise, and was too cautious in dropping the remapping otherwise. It
turns out it reports 15 buttons, but still produces disjointed button
numbers. So remove the check and just log the reported number of buttons
before remapping for future debugging.
The FreeBSD USB code is incomplete, and doesn't really to device
parameter detection yet, leaving the number of buttons and axes 0. This
might cause problems with programs expecting (reasonably) 6 axes, and
"some" buttons. So let's hardcode 6 and 2 respectively until the code is
improved.
Some times, or some devices do not seem to send a CR before the first
initialization line (@1), and would not get picked up by spacenavd,
which was matching "\r@1". Removing the CR from the test should not
introduce false positives, as I don't think magellan devices send any
similar strings, so it should be safe to just look for "@1".
Also some devices seem to take a little too long to initialize and miss
our initialization string. Adding a 1second sleep after opening the
device seems to help.
Thanks to Benjamin Bergman for debugging and reporting this.
Some old USB devices report themselves as joysticks, which prompts linux
to start their button number from BN_JOYSTICK (0x120) instead of BN_MISC
(0x100). Spacenavd previously assumed the later and subtracted 256 from
button numbers, which causes an offset of 32 to all button events on the
Magellan SpaceMouse USB. This fix adds a bnbase field to the device
structure, which is detected and set automatically in the button
counting loop.
New 3dconnexion devices seem to all use the same dongle with USB id
256f:c526. That includes at least the SpaceMouse Wireless and the
CadMouse Wireless. This is a set of hacks to guess what's connected
and act accordingly:
- Drop the CadMouse (num_axes == 0)
- Enable the button hack if it's a SpaceMouse Pro Wireless
- Detect SpaceMouse Wirless and update name/type.
Also added a test for the assumption that devices marked for button
remapping always report 255-256 buttons. If that's not the case undo the
button-hack and ask the user to report it as a bug.
Some devices are reporting arbitrary non-contiguous button numbers,
while spacenavd expects a contiguous range. Those devices also report
256 buttons regardless of the true number.
Introduced a button remapping hack for problematic devices, which
hardcode the correct number of buttons and arbitrarilly remaps them to a
continuous 0-base range. This should fix the button number issues with
the SpaceMouse Enterprise and SpaceMouse Pro.
Also added a second level of verbosity, to lighten the logging output
under normal `-v` conditions.
swap-by-default logic. Whether the low level axis mappings are
consistent for some of the devices are just guesswork at this point
until we get more data.
- fixed serial_dev_open over-writing the device name with "serial device"
- hotplug does not need to call init_devices now that we split them up,
it's best to call init_serial_devices instead.
- preparing for reworking the string passing mechanism in protocol v1
- changed the meaning of swap-yz to make it more intuitive, I'll fix the
USB devices handling which are backwards later at the device level.
- implemented SCFG_SERDEV/GCFG_SERDEV requests (AF_UNIX protocol).
spacenavd would enter an infinite loop if at the time when a client
disconnected, errno happened to be EINTR.
- allow axis mappings to be -1, to unmap a device axis.