search

FreeSpacenav / spacenavd

Free user-space driver for 6-dof space-mice.
http://spacenav.sourceforge.net
GNU General Public License v3.0
273 stars 55 forks source link

Tried to add 6dof device flags to a device with 0 axes #72

Closed afhp-2020 closed 1 year ago

afhp-2020 commented 2 years ago

Hello,

Trying to use a SpaceExplorer on FreeBSD 13.1-RELEASE.

I pulled the latest libspnav and spacenavd from github on 2022-09-04. Both compiled without a fuss (I can't build snpavcfg but that's an issue for later).

However, running the daemon manually I get the following message:

Spacenav daemon v1.1
reading config file: /usr/local/etc/spnavrc
Device detection, checking "/dev/uhid*"
checking "/dev/uhid0"... found usb device [46d:c627]: "SpaceExplorer" (/dev/uhid0) 
found usb device: [46d:c627]: "SpaceExplorer" (/dev/uhid0 )
adding device (id: 0).
BUG: Tried to add 6dof device flags to a device with 0 axes. Please report this as a bug
using device:  (/dev/uhid0)
trying to open X11 display ":0"
   XAUTHORITY=/home/alexisp/.Xauthority
Using XTEST to send key events
adding dev event for device: /dev/uhid0

The test programs provided with libspnav all compiled and work fine (simple, cube, fly).

The device is not detected by either FreeCAD, blender or OpenSCAD, I don't know at this point whether it's related to the above issue of declaring 0 axes or something else entirely.

jtsiomb commented 2 years ago

If the example programs work, that means everything works correctly on the spacenavd side. The 0 axis thing is probably because the FreeBSD USB code is very rudimentary at this point, and probably does not set the number of axes to the device data structure. Any help from FreeBSD users in improving the USB code would be greatly appreciated.

This should not stop the device from being read correctly though, because when axis events arrive, spacenavd just forwards them to applications. The number of axes field is only for information which can be supplied to applications if they ask for it.

It could be the case that the programs you tried ask for the number of axes and if it's zero they ignore input, but the API for requesting such information is very new, and I doubt these programs were all updated to use it so quickly.

I'm leaving this bug report open, as a reminder to improve the FreeBSD USB code, but I'd suggest picking one of the programs you mentioned and trying to find out why they don't work on FreeBSD with the input spacenavd clearly provides (since the example programs all work). It could very well be the case they expect to receive 6dof input from spacenavd only on GNU/Linux, under the false assumption that it's the only supported platform. It was the only supported platform for USB devices for quite a long time, but serial devices used to work for ages.

afhp-2020 commented 2 years ago

Glad to learn that the 0 axis thing is a minor issue and shouldn't be blocking.

As the examples worked I figured that the whole driver side was fine and that the problem was on the client software side. I'll look into that.

Meanwhile I'll be glad to help with FreeBSD in any way I can.

jtsiomb commented 1 year ago

It's not the proper solution, but for now (commit aebe1999a632866cd754fdc973ab189b52b4fa77) I've hardcoded 6 axes and 2 buttons for USB devices on FreeBSD. The daemon will still send events for higher numbered buttons if they exist, which might still cause issues to client programs, but it's arguably better than reporting 0 axes and 0 buttons. Ideally the code should be improved to detect the correct number of axes and buttons.

Closing this bug report, but the call for FreeBSD contributors to improve the USB code remains.