C Header Split: Public vs Internal

[petejohanson]

As we plan for versioning, we need to be diligent about what C API we consider public, with stability guarantees, changes triggering major version changes, etc.

To that effect, we need to split our headers into public and internal headers, to clearly differentiate these things.

Suggested public API/headers:

• Behaviors driver API
• Event manager API
• Events themselves

Maybe Public:

• HID
• Endpoints
• Some display widgets APIs?
• behavior queue?

Private:

• Keymaps
• Physical Layouts
• matrix transforms
• Backlight
• Underglow
• PM?

[caksoylar]

IMO the public API would be used by these types of modules mainly (referring to the categorization in #2456):

• Custom behaviors
• Custom status screens
• Other types of indicators like rgbled-widget

I think the following should be public for use in custom behaviors, other than your suggested public ones:

• behavior queue (in "maybe" above, needed for macro-like behaviors)
• some keymap APIs like fetching active layers, setting layers on/off

For custom status screens and status indicators:

• Display widget creation APIs
• again, some keymap APIs related to layers
• selected endpoint

In the future we might want to consider adding hooks for custom lighting status effects, like the ones that could be used by Glove80 magic key to display status indicators. I assume this requires re-architecting underglow a bit, to allow for loading external effects. In that case I can see related APIs being public too.

[joelspadin]

Rather than rearchitecting underglow a bit to allow loading external effects, it might be less work in the long run to do nothing now and later rearchitect it completely with a generic lighting system that can handle things like per-key lighting as well. I think a lighting effect driver API would be a much more flexible way to handle custom lighting.