4 ms·

My guess is that the problem with sending events is that if you miss one you're in trouble (in this case it's especially bad if you miss/lose the "key up" messa

by simias 7y ago

My guess is that the problem with sending events is that if you miss one you're in trouble (in this case it's especially bad if you miss/lose the "key up" message). Given the potential complexity of USB topologies making the protocol stateful might have caused more problem than it would've solved. Besides is there any use for NKRO besides being a meme feature for overpriced keyboards? The only use case I can think of is if you play two player games on the same keyboard but doesn't seem very common these days (and you can probably buy a decent gamepad for the price of a NKRO keyboard).

smileybarry 7y ago
While I can't reproduce it at-will I've definitely had occasional input problems in competitive shooter games with 6KRO + 125Hz. A depress would be processed "too late" to accidentally fall into the next window and affect movement then (e.g.: jump in wrong direction). Yes, the key combination probably doesn't go over 6 keys at once and I don't always have ~8-16ms presses but switching over to NKRO + 1000Hz (which are coupled on QMK) would stop this from happening.
SuperPaintMan 7y ago
Stenography! When stroking a chord you can have 6+ keys held down easily. I design and write firmware for QMK powered writers/ergonomic keyboards, and NKRO is absolutely vital if you don't want to resort to serial devices [1]. Plover uses this technique to allow for use of gaming keyboards as a low cost stenographic writer powered by FOSS. [1] https://www.gboards.ca/ https://www.gboards.ca/
derefr 7y ago
Would it be that expensive to put ~4K of RAM in the keyboard’s microcontroller to act as an event queue? Write keydowns/keyups into the buffer; then push (or respond to a poll with) the complete contents of the buffer as a single USB packet; and flush the buffer on ACK. (I presume USB does ACKs?) 4K would be more than enough to buffer all possible key events a pair of human hands could create in a reasonable polling interval (~16ms, i.e. 1 frame for a 60Hz game.) Add a clock chip to the HID device as well, and you could even get finer event-reporting granularity than the OS cares to poll for (i.e. the buffer delivered at (Polling Interval x N)ms, would contain events timestamped for (Interval x (N-1)) ms, (Interval x (N-1) + 1)ms, etc.) The timestamps could just be relative to the beginning of the interval, so they wouldn’t need to take up that many bits at all.
- nitrogen 7y ago
  Some games run their physics engines at a higher framerate than 60, but also any added latency is not going to be acceptable.
- magicalhippo 7y ago
  > then push (or respond to a poll with) the complete contents of the buffer as a single USB packet; and flush the buffer on ACK Two issues. Unless you use USB 2.0 high speed, USB "packets" (transactions) are small[1]. For low speed they can have 8 bytes of data, full speed 64 bytes. USB 2.0 HS is a lot more costly of course. Secondly, keycodes that are sent in the same report have no defined order[2]. Thus if two keys were not present in previous report and are present in current report, the order in which those two keys are pressed are indeterminate to the OS. So that would not be very helpful I think. [1]: http://www.usbmadesimple.co.uk/ums_3.htm http://www.usbmadesimple.co.uk/ums_3.htm (Interrupt Transfers) [2]: https://www.usb.org/document-library/device-class-definition-hid-111 https://www.usb.org/document-library/device-class-definition... (Appendix C)

by simias 7y ago

smileybarry 7y ago

While I can't reproduce it at-will I've definitely had occasional input problems in competitive shooter games with 6KRO + 125Hz. A depress would be processed "too late" to accidentally fall into the next window and affect movement then (e.g.: jump in wrong direction). Yes, the key combination probably doesn't go over 6 keys at once and I don't always have ~8-16ms presses but switching over to NKRO + 1000Hz (which are coupled on QMK) would stop this from happening.

SuperPaintMan 7y ago

Stenography! When stroking a chord you can have 6+ keys held down easily. I design and write firmware for QMK powered writers/ergonomic keyboards, and NKRO is absolutely vital if you don't want to resort to serial devices [1]. Plover uses this technique to allow for use of gaming keyboards as a low cost stenographic writer powered by FOSS. [1] https://www.gboards.ca/ https://www.gboards.ca/

derefr 7y ago

Would it be that expensive to put ~4K of RAM in the keyboard’s microcontroller to act as an event queue? Write keydowns/keyups into the buffer; then push (or respond to a poll with) the complete contents of the buffer as a single USB packet; and flush the buffer on ACK. (I presume USB does ACKs?) 4K would be more than enough to buffer all possible key events a pair of human hands could create in a reasonable polling interval (~16ms, i.e. 1 frame for a 60Hz game.) Add a clock chip to the HID device as well, and you could even get finer event-reporting granularity than the OS cares to poll for (i.e. the buffer delivered at (Polling Interval x N)ms, would contain events timestamped for (Interval x (N-1)) ms, (Interval x (N-1) + 1)ms, etc.) The timestamps could just be relative to the beginning of the interval, so they wouldn’t need to take up that many bits at all.

nitrogen 7y ago
Some games run their physics engines at a higher framerate than 60, but also any added latency is not going to be acceptable.
magicalhippo 7y ago
> then push (or respond to a poll with) the complete contents of the buffer as a single USB packet; and flush the buffer on ACK Two issues. Unless you use USB 2.0 high speed, USB "packets" (transactions) are small[1]. For low speed they can have 8 bytes of data, full speed 64 bytes. USB 2.0 HS is a lot more costly of course. Secondly, keycodes that are sent in the same report have no defined order[2]. Thus if two keys were not present in previous report and are present in current report, the order in which those two keys are pressed are indeterminate to the OS. So that would not be very helpful I think. [1]: http://www.usbmadesimple.co.uk/ums_3.htm http://www.usbmadesimple.co.uk/ums_3.htm (Interrupt Transfers) [2]: https://www.usb.org/document-library/device-class-definition-hid-111 https://www.usb.org/document-library/device-class-definition... (Appendix C)