Meeting Notes (2020 07 14)

Meeting Notes

Architecture discussion

• Diagram
• PR 77 - Architecture draft
• Remove render_in delay from Animation.new. We can't think of a use case for this.
  • The initial delay was intended to be the animation implementer's decision.
• Should we model playing animations as a stack?
  • Push/pop animations - When an animation is pushed, the underlying one is paused and the latest plays. (Like a modal)
  • The ability to play/stop animations is needed first; the stack could be added on in another iteration.
• Engine.start_link doesn't need to take an initial animation. Just play the first animation with a call to the play function.
• Issue: New paintables (displays) that register themselves start with black pixels.
  • Any time someone registers the engine can call the paint function as part of registration. #80
  • What happens if the engine doesn't have a last frame or if it crashes and comes back up?
    • It's not noticeable right now; if it is, it looks like a stutter.
    • QMK freezes on the last animation that was animating (what we do right now).
    • Do we want to reinitialize with black pixels?
      • As a user it's probably more desirable for the LEDs to freeze on the last frame than to have them go black.
• Animation config
  • How do you change the config in the running engine?
    • Keep the engine read config function; remove set config.
    • The application holds on to the config and calls the engine's set config function when the config is changed.
    • Maybe have config stored in a read-optimized ETS table, with a config module exposing functions for those operations.
      • Try to keep config an application concern to start with.
  • Currently, animation creates a config for you. It's a black box. Pulling out the config feels kind of wrong.
    • This goes along with how we might want to decompose Animation.
    • Add Animation.get_config?
    • Instantiating an animation takes a %Config{}?
    • Users should be able to set up presets for animations they like and store them somewhere.
    • Animation implementer exposes the initial config settings through keywords for .new?
    • Store the config as keyword lists? But how do we perform validation on that?
    • Does the keyboard layout/config affect an animation config?
      • Yes, the engine is taking the LED layout for start_link.
      • The layout of LEDs get passed into Animation.new.
      • If we pass an animation to engine rather than an animation type, we may not need to also pass LEDs to the engine because it can get them from the animation.
        • The opposite direction is that engine could pass the LED layout to the animation on each render call, but that wouldn't be efficient. Also, almost every animation is using the LED layout in Animation.new.
• Layout
  • Should it be in config.exs?
    • Does that limit interfacing with keyboard-layout-editor raw data in the future?
    • If we proceed with expanding the UI towards the rgb_matrix_simulator, we may want the ability to switch layouts in the UI at runtime.
  • Should layouts be in the animation library?
    • tl;dr We're deferring this convo.
    • Xebow Layout is meant to be a unified layout library that can support layouts of any components.
      • Unified description of a physical keyboard.
  • What if layouts contained one or more layers?
    • Each layer has a similar group of elements (input layer, LED layer).
    • The top-level Layout is then a container of layers.
    • Decouple the elements of one layer knowing about the elements in another layer.
      • BUT, the way layouts currently work contain the mappings between elements as an optimization.
      • Raycast from each LEDs position to where an event (key press) happened.
        • Might not be necessary. The LEDs are always under the keys on mechanical keyboards.
        • The mapping is already calculated at layout initialization time.
  • We can shelve layout architecture for later.

Web UI

• Data transfer for a constant animation is about 130KB/s.
• It's bogging down when multiple browsers are open and the config is being changed.
  • phx-debounce didn't affect this.
  • Move reading the config from the engine to the application and see if it gets better.
    • We could add a second layer of debouncing at this layer if we need to.
• This is going to be the entry point for users and contributors, especially if they don't have the hardware yet.
• Hardware emulation
  • Have the 10-key on a regular keyboard act like pressing keys on the Keyboard.
• Use the key CSS from Excalibur, listed in #78.
• It would be nice to persist the configuration to disk.
• Where do we store the animation name?
  • A name function or macro in the animation implementation? (Parsing the module name is probably less desirable.)
• Animation fields are a point of messiness we need to figure out how to clean up.

Credo

• Just install and run with the standard config.
• How much should we enforce / should we have more lenient standards for an OSS community (than corporations typically use)?
  • If there's a credo blocker, give the contributor the option to fix themselves or have us fix?
  • Merge their PR to master (bypass merge restrictions) and a maintainer commits the fix.
  • Do we want to use a develop branch? (Probably not)
    • Do GitHub releases at known good commits.

Keyboard

• Diagram
• Separate out the Circuits.GPIO (key scan) part from the thing doing the AFK state handling.
• We should be able to open the web UI and emulate the calls to AFK / HID reports.
  • Have a log these go to that you can see.
  • People who don't have the hardware wouldn't be able to see this unless we emulate it.
• This could be part of the application orchestration layer.
  • Diagram
  • Be able to shut down the keyboard application and start up the Simon game.
  • Orchestration layer routes input events (key presses) to the right application.
  • Multiple applications could accept key presses at the same time; it's probably more convenient for only one to receive events at a time.
  • Should Keyboard have public functions to pause/unpause sending HID reports?
  • Hid report gotcha: Don't want to shut down in the middle of holding down a key or else it gets stuck down.

Testing

• Bring the engine tests back.
• Need to write more tests and mock the hardware.
• As we're refactoring, that's a good time to be adding tests around the code that's been modified.

Priorities

1. Refactor the hot path around the API and performance improvements.
2. Build out the web UI.

Action items

• Remove render_in delay from Animation.new. #66
• Any time someone registers the engine can call the paint function as part of registration. #80
• Move reading the config from the engine to the application and see the web UI performance improves.

Resources

Architecture diagram

Keyboard diagram

Orchestration diagram