kb01/zmk
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Add @petejohanson comments from Discord as a place holder

Browse source
This commit is contained in:
Ally Parker 2020-12-29 14:39:46 +00:00
parent 526abaef6a
commit d09a2eb469
1 changed files with 14 additions and 2 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

16
docs/docs/development/events.md
View file

@ -1,7 +1,9 @@
--- ---
title: Events title: Events
--- ---
## Overview ## Overview
ZMK uses events to decouple behaviours and to allow new functionality to be added to existing events. ZMK uses events to decouple behaviours and to allow new functionality to be added to existing events.
## Subscribing to events ## Subscribing to events
@ -54,6 +56,9 @@ todo
todo todo
That's for the state of a specific hid usage (keycode) being pressed/released.
Those events would be what you would feed into a WPM calculation.
### `layer_state_changed` ### `layer_state_changed`
todo todo
@ -65,10 +70,17 @@ todo
### `position_state_changed` ### `position_state_changed`
todo todo
A "key position" is a logical identifier for a physical key.
We transform from row/column to single integer position early on.
So the position is the 0-indexed value in the array of physical switches, normally if you started counting from top left corner and went left ttomright, top to bottom.
A keymap is a set of layers, where each layer is an array of bindings for each logical key position.
So, the "earliest event when a key is pressed" is the position state changed. The state being pressed or released.
Once that gets processed by the keymap, mostly the behaviors then generate keycode state changes.
### `sensor_event`
## `sensor_event`
todo todo
### `usb_conn_state_changed` ### `usb_conn_state_changed`
todo
todo