Adding debouncing filter for mouse wheel up / down
I think it is very common for the mouse wheel to have chattering problems. I think reWASD could be a great tool to add a debouncing filter option since it is able to control/hook the physical output for the input device.
What is chattering (in case of any misunderstanding, this is my version of it):
Overflow:
mouse wheel up five times but returns more than five
Reverse:
wheel up five times but returns wheel down in between
eg. UDUUUU
The D (wheel down) will output by itself(chatting happen). It can happen at any time between the five wheel ups (U), but the logic is it will surely trigger AFTER any of the wheel ups (U).
The solution:
I have no clean answer for the overflow one since it has almost no logic at all, but if wheel up happens, the next wheel up action should not be shorter than 10ms (or even higher). So a time variable (option) to block the next output for the same wheel direction should do it.
For the reverse, the solution is similar: any reverse of wheel action (up to down or down to up) should be blocked when it is shorter than 80ms (a fast switching time gap from up to down is 1xx–125ms anyway; the number is just a concept but I tested it myself).
Normal correct case (three up, two down):
U > U > U > (180ms) D > D
Error caused by chattering (four up):
U > U > (15ms) D > U > U
In short, the inhumanly fast leaked output should be blocked, as it is just an error coming from the mouse itself.
The only tricky thing is that Wheel Up and Wheel Down need to look at each other's trigger time(for the reverse error), while other keys just need to count their own last key-up timing.
I hope this will be an option at least for the mouse wheel.
This option could even be extended to any key if they have chattering issues.(or even add a link relation to the keys if they have the reverse behavior like wheel up/down)
Thanks.
What is chattering (in case of any misunderstanding, this is my version of it):
Overflow:
mouse wheel up five times but returns more than five
Reverse:
wheel up five times but returns wheel down in between
eg. UDUUUU
The D (wheel down) will output by itself(chatting happen). It can happen at any time between the five wheel ups (U), but the logic is it will surely trigger AFTER any of the wheel ups (U).
The solution:
I have no clean answer for the overflow one since it has almost no logic at all, but if wheel up happens, the next wheel up action should not be shorter than 10ms (or even higher). So a time variable (option) to block the next output for the same wheel direction should do it.
For the reverse, the solution is similar: any reverse of wheel action (up to down or down to up) should be blocked when it is shorter than 80ms (a fast switching time gap from up to down is 1xx–125ms anyway; the number is just a concept but I tested it myself).
Normal correct case (three up, two down):
U > U > U > (180ms) D > D
Error caused by chattering (four up):
U > U > (15ms) D > U > U
In short, the inhumanly fast leaked output should be blocked, as it is just an error coming from the mouse itself.
The only tricky thing is that Wheel Up and Wheel Down need to look at each other's trigger time(for the reverse error), while other keys just need to count their own last key-up timing.
I hope this will be an option at least for the mouse wheel.
This option could even be extended to any key if they have chattering issues.(or even add a link relation to the keys if they have the reverse behavior like wheel up/down)
Thanks.
Comment