Adaptive debounce logic
The debounce filtering reports a key/switch change directly, without any extra delay. After that the debounce logic will filter all further changes, until the key/switch reports the same state for the given count of scans. So a perfect switch will get a short debounce period and a bad key will get a much longer debounce period. The result is an adaptive debouncing period for each switch. This value defines how often the same key/switch state has to be detected in successive reads until the next key state can be reported. In other words this value defines the minimum debouncing period for a switch.
This commit is contained in:
parent
385de70e4d
commit
ad91454574
2 changed files with 38 additions and 28 deletions
|
@ -85,17 +85,20 @@ along with this program. If not, see <http://www.gnu.org/licenses/>.
|
|||
|
||||
#define RGBW 1
|
||||
|
||||
/* "debounce" is measured in keyboard scans. Some users reported
|
||||
* needing values as high as 15, which was at the time around 50ms.
|
||||
/*
|
||||
* The debounce filtering reports a key/switch change directly,
|
||||
* without any extra delay. After that the debounce logic will filter
|
||||
* all further changes, until the key/switch reports the same state for
|
||||
* the given count of scans.
|
||||
* So a perfect switch will get a short debounce period and
|
||||
* a bad key will get a much longer debounce period.
|
||||
* The result is an adaptive debouncing period for each switch.
|
||||
*
|
||||
* If you don't define it here, the matrix code will default to
|
||||
* 5, which is now closer to 10ms, but still plenty according to
|
||||
* manufacturer specs.
|
||||
*
|
||||
* Default is quite high, because of reports with some production
|
||||
* runs seeming to need it. This may change when configuration for
|
||||
* this is more directly exposed.
|
||||
*/
|
||||
#define DEBOUNCE 15
|
||||
#define DEBOUNCE 10
|
||||
|
||||
#define USB_MAX_POWER_CONSUMPTION 500
|
||||
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue