At time of writing, the keyboard is just checking key-press events in a hot-loop, burining up unhealthy amounts of energy...
Current thoughts are to have one core dedicated to processing the attached modules (key-presses, mouse-movement, etc.) and the other core is dedicated to connectivity (passing along data, kepping connections alive, etc.)
With the module-core, a rush-to-sleep strategy is probably the way to go. By default, the core is in the deepest sleep it can be without compromising latency, and on any sort of activity, it processes all queued events, and immediately goes back to sleep. The optical sensor might remain busy and in a hot-polling loop for a few ms. Same should be available for the mouse-wheel to facilitate a free-spinner, such as the logitech g502 free-spinner. In any case, that requires R&D.
At time of writing, the keyboard is just checking key-press events in a hot-loop, burining up unhealthy amounts of energy...
Current thoughts are to have one core dedicated to processing the attached modules (key-presses, mouse-movement, etc.) and the other core is dedicated to connectivity (passing along data, kepping connections alive, etc.)
With the module-core, a rush-to-sleep strategy is probably the way to go. By default, the core is in the deepest sleep it can be without compromising latency, and on any sort of activity, it processes all queued events, and immediately goes back to sleep. The optical sensor might remain busy and in a hot-polling loop for a few ms. Same should be available for the mouse-wheel to facilitate a free-spinner, such as the logitech g502 free-spinner. In any case, that requires R&D.