Shane Saxon

Excellent, very helpful details and will proccede accordingly! I can't speak much to how Linux 'maps the HID packets... evdev interface'. Perhaps with the 'HID report descriptors', I started down a similar path with the msw code, but then came across people showing that (on Windows) the 3Dx HID descriptors are sometimes erroneous, (depending on device firmware etc.) Which I found to at least be true for Space Navigator button packet size, hid.dwSizeHid reports 7 bytes for all events (and same issue...

Now in terms of contiguous buttons, yes let's do this! However, at this point we are scrambling the button id's across models. So regardless of the (below) logic, the X11 behavior should take precedence and be mirrored to maintain cross-platform consistency. So the key question remains, what is the X11 key-map for the SM Pro and/or SM Enterprise? Best I can determine, the SM Pro (original and Wireless) and SM Enterprise are the only 2 devices with gaps in the raw button values. Both have a deviant...

In terms of original (forementioned) GLUT API docs, they do say: "The button parameter will be the button number (starting at one)." - original GLUT API It does say 'starting at one', but nothing about the buttons being contiguous. The FreeGLUT API (sec 12.17) added the non-contiguous button constants fore-mentioned, and referenced here: http://freeglut.sourceforge.net/docs/api.php#WindowCallback Now I see no reason to split hairs regarding the original GLUT docs, and the current FreeGLUT ones clearly...

The contiguous button approach presents a few challenges, which could be considered as follows: 1) It is inconsistent with the (currently) defined FreeGLUT API, which has non-contiguous button defines: GLUT_SPACEBALL_BUTTON_A (0x00000001) GLUT_SPACEBALL_BUTTON_B (0x00000002) GLUT_SPACEBALL_BUTTON_C (0x00000004) GLUT_SPACEBALL_BUTTON_D (0x00000008) GLUT_SPACEBALL_BUTTON_E (0x00000010) 2) It is problematic to the end-user, as different devices will behave differently with the same labelled keys. 3)...

The contiguous button approach presents a few challenges, which could be considered as follows: 1) It is inconsistent with the (currently) defined FreeGLUT API, which has non-contiguous button defines: GLUT_SPACEBALL_BUTTON_A (0x00000001) GLUT_SPACEBALL_BUTTON_B (0x00000002) GLUT_SPACEBALL_BUTTON_C (0x00000004) GLUT_SPACEBALL_BUTTON_D (0x00000008) GLUT_SPACEBALL_BUTTON_E (0x00000010) 2) It is problematic to the end-user, as different devices will behave differently with the same labelled keys. 3)...

I found that my init problem is a bug in glutDeviceGet(GLUT_HAS_SPACEBALL), where it reports zero during startup, even after glutShowWindow() is called. I fixed the bug by modifying fgPlatformHasSpaceball() to include: if (!fg_sball_initialized) fgPlatformInitializeSpaceball(); A small victory that is super helpful, as I have completely unbolted the proprietary 3Dconnexion SDK.... Hurrah for open source! The Good the Bad and the Ugly - special buttons edition: I (just) noticed that the 3DX sdk has...

I found that my init problem is a bug in glutDeviceGet(GLUT_HAS_SPACEBALL), where it reports zero during startup, even after glutShowWindow() is called. I fixed the bug by modifying fgPlatformHasSpaceball() to include: if (!fg_sball_initialized) fgPlatformInitializeSpaceball(); A small victory, but super helpful as I have completely unbolted the proprietary 3Dconnexion SDK.... Hurrah for open source! The Good the Bad and the Ugly - special buttons editon: I (just) noticed that the 3DX sdk has a file...

Well that sounds sensible. I can think of two possible approaches: 1) A set of lists, one for each PID with button count and all button integer values, (for reassigning them to a contigous set of button id's). For the multi-button devices we would need to create these lists for: Space Pilot, Space Explorer, Space Pilot Pro, Space Mouse Pro and SpaceMouse Enterprise. The rest we can just assume are 2 buttons. 2) Perhaps we can use the MSW (RID_DEVICE_INFO_HID) UsagePage(s), to programmatically determine...