Skip to content
This repository was archived by the owner on Dec 14, 2023. It is now read-only.
This repository was archived by the owner on Dec 14, 2023. It is now read-only.

A better way to override the short name #70

@algernon

Description

@algernon

There's a function in PluggableUSB called getShortName(), which is used to send a response to an ISERIAL descriptor request. We use this to send a device-specific name back, like kbio01, atreus, etc. The way we accomplish this overrideability is by marking HID_::getShortName() as a weak symbol, and overriding it with our custom function that calls Kaleidoscope.device().getShortName(). Thus, the linker will use our override for HID_::getShortName().

This has a number of downsides, including that of not being particularly clean, and requiring us to inject the override somewhere into the firmware, which we currently do by doing it as part of the KEYMAPS() macro - something completely unrelated.

So, I was thinking about what would be a better way to accomplish the same thing? One that doesn't require us to do a link-time function override, nor using an unrelated macro to accomplish the override.

I see two paths that might be worth exploring:

A shortName member variable

Using a member variable, and an appropriate setter has the benefit of being very flexible, and allows us to change the shortname at any time, during runtime. The downside of it is that with the shortname no longer being constant, this is slightly more code and data used. It's trivial to implement, though, and can be entirely backwards compatible.

Inheritance

Another option, which is considerably more complicated, would be to not initialize a HID object, but only ship the class in the library, and defer the instantiation to users of the library, such as Kaleidoscope. We could then update Kaleidoscope's driver::hid::KeyboardioHID to subclass KeyboardioHID, and override getShortName() there, at the c++ level, rather than at link time.

This has the advantage of the short name still being constant. The downside is that the library would no longer be a drop-in replacement for Arduino's HID, but slightly more Kaleidoscope-specific, and it breaks backwards compatibility, as users of the library will have to instantiate a HID object themselves. With our major user being Kaleidoscope, I believe that such a breakage is acceptable.

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions