Closed albfan closed 1 year ago
I reworked the implementation using:
Time since last dominant movement to allow new dominant axis: Set to 0.2s
Probably this settings needs to be customizable
Reworked on top of latest changes.
https://github.com/FreeSpacenav/spnavcfg/pull/33 is open to setup. If treshold for movement or time range for inactivity needs config we can address there
I will try to collect feedback on windows implementation to compare behaviour, but implementation feels correct now
Let me know if any coding style or detail is missing
I haven't tried it yet, but the code changes look nice and succint. At first glance there are minor style differences from how I'd write it, but nothing that would hold back a merge. If you want to collect feedback first, let me know when you think it's final and ready for merging.
Sure, and I will take a look at whole code styling. Give me two days
I test the dominant on windows and this implementation is even smoother.
They call it navigation "dominant" which probably makes sense as this is not only about axis.
I can change that and review the code and this should be ready
I made some minor changes, and I'll go ahead and merge this for now. But I have a question: is it supposed to stop rotations while translating and vise-versa, or should the rotation and translation axis locks be independent? I've never used dominant axis mode before, but this just feels annoying.
It just choose one movement between 6 options (3 translations, 3 rotations)
I pulled out my SGI O2 where I have 3Dconnexion drivers, and tested the dominant axis mode. It does not work like this. There's no need for timers, it just reports only the motion with the largest magnitude at any given time. If we're in the middle of a slow translation on the X axis, and without removing the side-pressure we also tilt the cap harder, it will switch to a rotation immediately.
I can change that implementation then, but, as said this looks smooth than windows, as it continues using same axis or rotation if change is small
The timeouts feel awkward. The original behavior on the SGI felt much better. At the very least we need to try both and compare, but you don't have to do it, I'm just recording issues for future reference. I could try it myself at some point.
Not even near to work, this PR filter dominant axis to apply only its movement
TODOS:
Official driver implementation:
Erratic from this PR:
fixes #63