keyboardio/chrysalis-firmware-bundle

Firmware sketches for boards supported by Chrysalis

chrysalis-firmware-bundle's Issues

Adjust the Model100 firmware to default to Colormap

It looks like the way we handle LED effects is a frequent source of confusion: people set up colors with Chrysalis, and then wonder why they don't show up. While Chrysalis could do a better job at explaining that they need to switch to the Colormap effect, it would be even better if the keyboard helped them in that regard, too.

What if we defaulted to Colormap, if there is no default LED mode set?

I wouldn't move the plugin in the plugin list, but do something like: if (DefaultLEDModeConfig.isUninitialized()) ColormapEffect.activate();.

Since the palette is all black by default, this would mean that the keyboard behaves the same out of the box as with LEDOff: all LEDs are off. But once a palette & colormap is saved, they'd be active immediately, without having to explicitly switch the mode.

Model01 experimental firmware should have FocusLEDCommands enabled

Consider dropping a layer on the Keyboardio Atreus, to enable LayerNames

The Keyboardio Atreus ships with 10 layers enabled, which take up a lot of EEPROM space (almost half of what's available), and that prevents us to introduce pretty much anything that'd use EEPROM, such as the LayerNames plugin.

If we free'd up a layer, we'd have 96 more bytes immediately, 63 of which we could easily use for LayerNames (for 6 chars / layername on average), and still have some to spare.

This would break backwards compatibility, but perhaps we could do that for a good cause.

SpaceCadet causes shift to work differently

I noticed that turning on SpaceCadet is causing the shift keys to work differently when hold to click. This happens on Model 100.

For example, if I want to select multiple rows in spreadsheets or to select multiple files depending on the context, I would click on something first and then hold the shift key while clicking on the other one to select the multiple items as a range.

This works perfectly fine when SpaceCadet is off. However, when it's on, it would just select the last one as if the shift was not held during the click.

remove AlphaSquareEffect from default sketches

Is your feature request related to a problem? Please describe.

The AlphaSquareEffect plugin is not very legible unless translucent keycaps (or no keycaps) are installed. With the usual mostly-black opaque keycaps, it simply looks like random keys being illuminated. I had trouble figuring out what it was trying to do, until I read the description of the plugin. I still had trouble making out the letters until I happened to activate it while all my keycaps were removed (on the Model 01).

Describe the solution you'd like

Remove the AlphaSquareEffect plugin from the default sketches. This frees up some flash memory on AVR devices, and the effect doesn't look very good (and even maybe looks like an error) with the default keycaps installed.

Describe alternatives you've considered

The plugin could remain in the default sketches, taking up flash memory and looking not especially good in the default hardware configuration.

Additional context

N/A

Add the Steno plugin to the Model100 sketch

The Steno plugin is something interesting, which would be nice to have in the default firmware. Not enabled, of course, just there, available, should someone want to play with it.

Chrysalis could ship with a Steno layer in its library, too.

M100 firmware version 0.11.1+29 prints "locally built"

Updated my M100 to 0.11.1+29 using Chrysalis 0.11.3 and MACRO_VERSION_INFO is printing "Keyboardio Model 100 - Kaleidoscope locally built on Sep 9 2022 at 20:11:01"—it should probably say something more official?

Model01 experimental firmware should have IdleLEDs included-- enhancement request

In the spirit of making Model01 (and Model100???) commonly requested/usefull features more accessable to Chrysalis only users, I'd love to see IdleLEDs included in the experimental firmware.

Enable more plugins in these firmware

To make it easier to discover and play with some of the fancier features of Kaleidoscope, the following plugins should be enabled in these sketches:

• OneShot
• MouseKeys
• SpaceCadet
• Qukeys (for DualUse keys)

Consider enabling the DefaultLEDModeConfig plugin for the Model100

The Model100 firmware ships with a lot of LED effects. It would be nice if it was possible to choose the default one, rather than having the keyboard start up with the first one every time it boots, and having to cycle to the one we want.

The DefaultLEDModeConfig plugin makes this possible, so I think it should be enabled in the default Model100 firmware.

SpaceCadet sometimes ends up being accidentally enabled

We've been getting a number of reports lately with misbehaving shifts, which all ended up being caused by SpaceCadet getting enabled unintentionally.

It should default to off. We should investigate why it gets turned on.

Feature request: Distribute firmware updates via fwupd?

It would be really cool if firmware updates were available for Keyboardio's keyboards via fwupd on Linux.
That would make it really easy to get the latest updates on Linux, since fwupd is pretty well integrated in most desktop Linux distributions out-of-box.
Users could update by checking for updates with fwupd or a higher-level tool like GNOME Firmware, which can provide necessary instructions for the update, such as holding a particular combination of keys when initiating the update.

Since I'm so happy with the defaults of my Keyboardio keyboards, I don't often need the advanced features of Chrysalis. I usually just set my preferred keyboard layout once, and then only use Chrysalis for firmware updates.

I know that System76 does this for their Launch keyboard, as described here.

Migrate to using Kaleidoscope as upstream source for sketches

It turned out that having two copies of firmware sketches - one in Kaleidoscope, one here - is not viable. The original vision was that this repo would be the canonical source, and we'd remove the copies from Kaleidoscope, but that did not came to be, because the examples there are useful.

So instead, we should be using Kaleidoscope as the upstream source, in a way that we do not have a copy of the firmware sketches here, so we don't need to copy things around, and risk things getting out of sync. We do not want to deprecate this repository either, because it's useful for publishing the Chrysalis firmware bundle separately from Kaleidoscope itself.

So the plan is to remove the firmware sketches from here once keyboardio/Kaleidoscope#1293 is dealt with, and pull in Kaleidoscope as a submodule, and either symlink the sketches to the place the tooling here expects, or copy them during build-time. This way we don't have two copies, we can control when we sync (by updating the submodule), and we have more control over which version of Kaleidoscope we compile against (currently, we always compile against master, which is not always desirable).

Our tooling will need updates too, of course.

Add SpaceCadetConfig to the Model100 sketch

Now that we have a plugin that can configure some aspects of SpaceCadet, and Chrysalis has support for it too, lets add the plugin to the Model100 sketch. SpaceCadet would still remain disabled by default, but with the config plugin, it would become possible to turn that around, if one so desires.

Model01 experimental firmware has NumPad LED effect active

When switching to layer 1 while using the experimental firmware, the NumPad LED effect still activates, overriding whatever color scheme is configured in Chrysalis.

Provide a default for Model01 too

While the factory firmware works with Chrysalis out of the box, we can provide an alternative, with a few more experimental things enabled (and some others like testmode, which eats a lot of space, disabled).

No code_of _conducting or contributing file

I can work on this. Just assign it for me to work on.

Add version tag matching firmwares bundled with Chrysalis

It would be super helpful to be able to get the specific version being bundled with Chrysalis.

Model01 experimental firmware is currently too big

As reported in the forum, currently the firmware is too big for the model01.

Sketch uses 29956 bytes (104%) of program storage space. Maximum is 28672 bytes.
Global variables use 1480 bytes (57%) of dynamic memory, leaving 1080 bytes for local variables. Maximum is 2560 bytes.
Sketch too big; see https://support.arduino.cc/hc/en-us/articles/360013825179 for tips on reducing it.

Should use the same tagging conventions as Chrysalis

The firmware bundle should use the same tagging conventions as Chrysalis. We already do this for tagged builds, but not for the development snapshots.

The development snapshots are currently all tagged "snapshot", while Chrysalis uses "vx.y.z-snapshot". We'll need to follow the same convention not only to be more consistent, but because "snapshots" sorts behind "vx.y.z", while "vx.y.z-snapshot" sorts ahead, as far as GitHub is concerned.

Atreus - "GET_DESCRIPTOR" calls are timing out with latest firmware (`0.92.1+94`)

Hey @obra , this is Daniel from keyboard.gg!

Sorry to bug, but I got a report from a user in my Discord that upgrading his firmware of his Atreus leads to it no longer working with my Edgeguard adapter. I decided to do a deep dive to see what exactly the issue is and if I can update my code to support your changes.

After diving in, I can confirm that at least the latest firmware version (0.92.1+94) has changed it's behavior and my calls to GET_DESCRIPTOR are no longer returning as expected (appearing to be timeouts possibly?) Downgrading the firmware to 0.92.0+77 fixes this issue, as videod below.

(Make sure to unmute!)
Part 1 🎥
Part 2 🎥
Part 3 🎥
Part 4 🎥

I noticed a changelog update,

USB protocol Fixes for both AVR-based and GD32-based keyboards that
may eliminate "communications timeout" issues when talking to
Chrysalis from Taylor Yu [email protected]

This in my mind seems low-level enough that it could be the source of what I'm seeing. I'd be happy to share how my adapter is connecting with keyboards in case there's any wonder if it's the source of this issue, but this is also the only time I've seen this behavior pop up on any of the keyboards I've tested.

Going to ping @tlyu in this thread as well in hopes to hear what could be the problem. I think this could be related to this PR.

---

Update as well: When connecting to Windows, I've confirmed there is a timeout error during enumeration before the keyboard even begins to start working. Unsure if there's some deeper root cause here, but the older firmware didn't have this issue.

Older firmware (no timeouts, just responses.)	Newer firmware (timeouts, with a response)

Attaching more videos & Beagle USB captures (each time, the "a" key was pressed repeatedly before disconnecting and stopping.)

🎥 Timeout when plugged directly into Windows
🎥 Timout when plugged into Edgeguard

atreus-0.92.0+77-vs-0.92.1+94-tdc-captures.zip

Add CI workflow to validate sketch files compile and meet the size constraint of the MCU.

Model01's white LED mode uses too much power

See the original report.