Auto-Repeat Intervall -> doesn't return to zero? #108
Comments
Zero values are only reported every HIDUPDATERATESLOW_MS As a linux users I have some troubles with not repeated rotations, when the values don't change, see FreeSpacenav/spacenavd#108. Therefore I introduced a small jiggling on the last bit.
How do you know the mouse is reporting zero values?
Interval is spelled with a single 'L'.
It's possible, but I don't think so. When motion input is received it's zeroed out if it's within the deadzone threshold before any further processing, and auto-repeat checks if the previous event is out of deadzone by making sure it's not all zeroes otherwise the daemon sleeps indefinitely waiting for new input. See: |
You need to install Qt 5. That bug report (FreeSpacenav/spnavcfg#43) is about making it build with Qt 6, which is possible but takes some hacking of the build process. spnavcfg is a Qt5 application for now, Qt6 is unsupported. |
|
Thanks for your usefull feedback again!
As we write the arduino code by ourself, I can see, that 0x0000 is send to the USB API within the arduino.
Thanks for the good hint. I got it working and the gui for the configuration was brilliant for debugging, as I can see the resulting values for the axis, that are handled on the PC. Here, I found that my values didn't return to zero, but to 6 !? The comment is just wrong... 0xFEAA is -342!? argh! I corrected our HID descriptor to a symmetric range from -350 to +350 and the values return to zero. Yeah The spnavcfg shows the values from -500 to +500? Do I assume correctly, that they are just mapped from the logical min to logical max from the HID descriptor or is there more magic? The auto-repeat is finally stopping after 1s with zero values. Great! Is every value repeated regardless if there is new data sent? How are new, but equal data treated? I'm asking, because when I'm activating auto-repeat now, the usual motion is faster than necessary, even if the same data is sent every 10 ms from my device. |
The values are whatever the device sends, multiplied by sensitivity, both global and per-axis.
If the last motion event had any non-zero values (after deadzone clamping), it is repeated roughly as often as the repeat interval specifies. If a new motion event arrives, it gets immediately sent out, and becomes the new "last motion event" to be repeated after the repeat interval elapses again.
The daemon sends out all inputs as they arrive, but libspnav provides a function to discard all pending events of a given type ( Btw I'm closing this issue as it's not really a spacenavd bug, but feel free to continue asking questions here if you need more details. |
|
Thanks again for the good answer and your absolutely right, that the "issue" is not a bug. I got hold off an old, used SpaceNavigator and observed the behavior and noticed two main things: The SpaceNavigator is reporting translations (report id 1) and rotations (report id 2) every 8 ms, if there are non-zero values. Before stopping to transmit this value, if return to zero, the zeroes are sent three times ... I will try to imitate this behavior with our DIY approach and check if spacenavd responds to our imitation as to the real mouse. Another interesting part in the HID Descriptor (full report below, if other persons are interested) In our inherited code fragment (maybe from a SpaceMouse Pro ... i doubt that in the meantime): I tried both versions and observed different behavior in FreeCad and the spnavcfg. Is there a different handling for those different input definitions in spacenavd or do I need to read the USB specifications to get the meaning from this? ;) |
Indeed there is, and this relates back to one of your previous questions. I did not remember this but if the device sends absolute events, the value goes through a remapping function that brings it to the range [-500, 500] before further processing and sensitivity adjustment. See: https://github.com/FreeSpacenav/spacenavd/blob/master/src/dev_usb_linux.c#L294 I probably did this to normalize the values reported by different devices, but I have no recollection about how the specific range was chosen. When I wrote the first version of spacenavd, I only had a space navigator, and the first version of spacenavd only worked with "relative" inputs because that was what the space navigator emitted. I'm saying "relative" in quotes because they weren't really relative, they were just reported as such, but the values were always absolute displacements per axis. 3Dconnexion probably realized at some stage that reporting them as "relative" is incorrect, and changed to absolute in newer devices. Specifically the commit which added EV_ABS handling in spacenavd came from a bug report of a "space pilot" user (commit df57ada). I'm pretty sure all modern 3Dconnexion devices report absolute axis usage. Edit: you've seen this before, but here's the hid descriptor of a spacemouse wireless: https://pastebin.com/GD5mEKW6 |
|
Ah, yes. The remapping to +/- 500 explains my observations. I have implemented a state machine which sends the data every 8 ms, with three zero packages at the end of non-zero data. I staying with the absolute reporting as inherited and suggested, because there seems no benefit in changing this. I still have the problem, that under FreeCAD the parts stays still, when only equal non-zero data are sent. And second, I played around with the auto-repeat interval in spnavcfg and observed the mechanism working in general. The shorter the time duration, the higher the effect, as the packages get sent more often. Interestingly - maybe even a bug? - If I raise auto-repeat from 250 to 500, even higher to 800, to 900 I observe weaking response. But if i set it to the maximum=1000 the behavior is the same as with 0 or off. Is this intended? Otherwise you could just limit the value in spnavcfg to be less than 1000. |
My final conclusion to this is as follows: My emulated "SpaceMouse Pro Wireless (cabled)" (or at least our inherited) hid report descriptor reports absolute values When using spacenavd and the simple example, cube or even in FreeCAD:
Solution: Change our emulated mouse to Relative Positions, even if this is not "up to date". But it avoids the necessity to jiggle the values. |
Changed from absolute to relative values to avoid the need for jiggling the values. This is needed because equal absolute inputs are ignored in linux. Check the discussion in spacenavd for more informations: FreeSpacenav/spacenavd#108 (comment)
|
You lost me with your last two messages. I clearly don't understand something about what you're observing here. It might be me, but I don't find your description about what happens when you fiddle with the repeat interval clear at all. As I said previously, the intended behaviour when the repeat interval is enabled, is that even if the device stops sending events entirely when motionless out of deadzone, spacenavd repeats the last motion event roughly every X milliseconds. I can't understand from your description if what you're observing is something different, and what that is.
No, auto-repeat is always off by default at the moment. It might be a good idea to change that for some devices.
If that's true, that might be a bug. The intended behaviour when repeat interval is set to 1000, is to send motion events every second. I don't think that's a very useful setting, but that's what it's supposed to do. Also there is no maximum, you can set it in the config file to whatever interval you want.
To be clear, it delcares its reports as relative, but they're not. It's still sending absolute positions. As for the differences in handling of absolute and relative HID reports, if there is a difference it must be in the kernel, aside from the remapping I mentioned there's nothing else spacenavd does differently between the two. |
|
Sry, for my unclear explanations. My main problem was, that auto-repeat is neither the cause, nor the solution for my problem. But I didn't knew that ... As we found out in our last posts, I struggled with the (probable) kernel behavior of hiding data, if the (declared as) absolute value doesn't change. (Which is common in our emulated mouse) In search for a solution, I activated auto-repeat with an intervall of e.g. 250 ms and observed:
Conclusion: Thank you very much for the good answers and links which led me in the right direction, to solve my problem. |
Based on the reverse engineered SpaceNavigator, see SpaceNavigator.md, this commit introduces a little state machine, which sends new data over the usb interface with a constant rate every 8 ms. This is not to be configured by every user and therefore not in the config_sample.h. If no data is to sent, the zero data are sent three times before stopping the transmissions. * Introduced debounced keyState for key evaluation * Changed the HID descriptor to a symmetric logical range of +/- 350. It has been -342 to +350, despite the comment saying it to be -350 all the time. 0xFEA2 = 350, not 0xFEAA. ?! * Changed HID report from absolute to relative values to avoid the need for jiggling the values. This is needed because equal absolute inputs are ignored in linux. Check the discussion in spacenavd for more informations: FreeSpacenav/spacenavd#108 (comment)
Here is an issue from the DIY spacemouse again.
I found the problem, that in FreeCAD the model is stop moving, when the spacemouse is off-centered hold still.
A quick and dirty solution is toggle the last digit with every reported event, which actually works.
But I read through the docs and issues here and found #87 with all referenced issues.
When I start the spacenav daemon, open a new model in freecad and don't touch the mouse: the model stays still.
When I use the mouse: the model moves.
When I let go of the mouse: The model still moves, because the auto-repeat seems to repeat the last input. Even though the mouse is actually reporting zero values. (I can debug the sent values in our DIY approach and we use a proper deadzone filtering)
Is it possible that the deadzone detection in the auto-repeat mechanism is buggy with the consequence, that the mouse is not returning to zero, but is always auto-repeating the last non-zero values?
Do I need to configure more dead-zone values in the config file to get the correct behavior?
I'm using:
repeat-intervall = 250For completeness, here to output of the log file
The text was updated successfully, but these errors were encountered: