How to figure out sending key events?

[AndunHH]

Hi,
I really love this project as it is the only way to include spacemouses on linux, which I found so far!

I'm working on a DIY spacemouse, similiar to the other topic already discussed here: #74

Our approach is based on four joysticks at an arduino with some keys, which got quite famous in 3d printing community:
open-source-spacemouse-space-mushroom-remix

I tried to get the source code together under proper source code control and opened this repository: https://github.com/AndunHH/spacemouse

We are emulating the wired spacemouse pro, as suggested in #74.

But sending the key events is quite random. ... I'm pretty sure, we mixed the API up, because we don't understand it. ;)

I already tried to get the clue by reading through the source code and came up to https://github.com/FreeSpacenav/libspnav/blob/d98eb8c927ec1f8f588e51e8412042d70a62dcd9/src/spnav.c#L404
But I'm still stuck, because I'm missing the basic concept / data type or enum definitions what needs to be send.

Our approach is obviously lacking some basic understanding! ;)

Can someone get my a link to a proper instruction where I can get some knowledge what the proper interface should be to send different keys without guessing around?

Thanks in advance!

[jtsiomb]

Looking at what libspnav does to figure out what to do on the hardware level, is not going to help you. There are too many layers in between. Unfortunately I have not made a HID device myself, not am I familiar with that arduino HID library, so I can't see what you're doing wrong just by looking at the code. If you're sure your report descriptor is correct, try running wireshark to see what gets actually sent over the wire, to check that your firmware doesn't send something incorrect.

On second reading you're saying you're emulating a spacemouse pro. I suggest trying some other device like the space explorer instead. The spacemouse pro is one of a few devices which report strange button event numbers, or at least that's how they end up after passing hrough linux evdev, and spacenavd has a special routine to unscramble them. If you're reporting regular sequencial keys (as you should) that routine thinking it's talking to a spacemouse pro will run and scramble them up instead.
See the devices which have a bnhack* to avoid: https://github.com/FreeSpacenav/spacenavd/blob/master/src/dev.c#L58

[AndunHH]

The link to the bnhack routine is fantastic, I wasn't aware of it after first scrolling digging through the code. Thx!

I don't have a real space mouse myself, therefore cannot Wireshark the USB connections. Sadly... (In that case, I probably wouldn't mess around building an DIY solution)

As some people want to use it as a drop in replacement on windows, I stay with that mouse first.

Do you or does somebody has a hint for me, where to find the expected datatypes? I found that the buttons have a type, press and nmb variable, but maybe I'm just wrong, sending them as unsigned int, when you say that negative numbers get mixed up. I'll try encoding the buttons as signed integers instead and report back.

Thanks for the heads up, where going in the right direction!

[jtsiomb]

No I meant to use wireshark on your device, to make sure what you intend to send for each button press, is what is actually sent.

As some people want to use it as a drop in replacement on windows, I stay with that mouse first.

Get it working first using the simplest possible device to emulate, and then worry about driver support on windows and how to modify the button masks for the newer devices.

Do you or does somebody has a hint for me, where to find the expected datatypes?

The HID report descriptor defines what you're supposed to send. The bug report you mentioned earlier has a sample device descriptor from one 3dconnexion device. You can compare with yours to find out if you're using the correct report formats.

[AndunHH]

Thanks for your hints in the right direction. I managed to send the proper bits as buttons in https://github.com/AndunHH/spacemouse/releases/tag/v0.6.0

What remains is finding the pins and codes that the windows driver is recognizing for all of the emulated buttons. This we will be found later on. Thanks for the helpful discussion here!