summaryrefslogtreecommitdiffstats
path: root/quantum/quantum_keycodes.h
diff options
context:
space:
mode:
authorSeebs <seebs@seebs.net>2017-12-05 17:55:05 +0100
committerJack Humbert <jack.humb@gmail.com>2017-12-10 06:40:41 +0100
commitd1feb8744aeb14f4ff024507b25d224e77de60a0 (patch)
tree6160b4a9b4fea7a277eebc97872574bbac10b941 /quantum/quantum_keycodes.h
parent6d1b45fb84d4f57193fd1db5bd9307842f03f7e9 (diff)
downloadqmk_firmware-d1feb8744aeb14f4ff024507b25d224e77de60a0.tar.gz
qmk_firmware-d1feb8744aeb14f4ff024507b25d224e77de60a0.tar.xz
Don't "unselect" left-hand rows
"unselecting" left-hand rows is a wasted i2c transaction. On the left-hand side, the ergodox uses a GPIO expander. It does *not* change "direction" (input/output) of pins, it just sets pins high or low. But all the pins are written at once. There's no way to change just one pin's value; you send a full byte of all eight row pins. (Not all of them are in use, but that doesn't matter.) So every pin is either +V or ground. This is in contrast with the right-hand side, which is using input mode to make pins be neutral. So there's no need to "deselect" the rows on the left side at all. To select row 0, you set the GPIO register for the rows to 0xFE. The previous code would then set it back to 0xFF, then set it to 0xFD on the next cycle. But we can just omit the intervening step, and set it to 0xFD next cycle, and get the same results. And yes, I tested that the keyboard still works. On my system, scan rate as reported by DEBUG_SCAN_RATE goes from 445 or so to 579 or so, thus, from ~2.24ms to ~1.73ms. Signed-off-by: seebs <seebs@seebs.net>
Diffstat (limited to 'quantum/quantum_keycodes.h')
0 files changed, 0 insertions, 0 deletions