Why no mention of Dygmalab Raise under avr/?


and such files there, since this is another keyboard that uses Kaleidoscope:

why isn’t it just includede in the main repo or such? Because it isn’t actually produced yet?

Dygma’s Raise is based on an ARM MCU, and so that they can iterate faster, some of the repos were forked. We synced in the past, and we’re going to re-sync in the not too distant future too (it’s on my TODO list for 2019 Q1). We need to figure out a few things about our current tooling and setup to make that sync easier, and to be able to - eventually - include the Raise with Kaleidoscope by default.

For example, our current CLI builder (kaleidoscope-builder) is quite closely tied to the Model01, using it with any other board is a bit of a pain. So I’m working on a new build system that has first-class support for different hardware. (See Kaleidoscope#497, I will post progress updates there later today.)

I was the one who convinced Dygma way back when they were experimenting with the Shortcut to go with Kaleidoscope, and I helped them with a few things. I’ve been keeping an eye on their repos, and we’re in regular contact too. I think all involved parties agree that at the end, we’d like to see Dygma’s stuff in Kaleidoscope proper. We’re not there yet, but work’s underway to make it happen.

In short, the reason is that Dygma needed to move faster than we were able to keep up with, so a few things got forked. The plan is to sync up soon enough.

As a side note, Chrysalis will be supporting the Dygma Raise too, along with the Model01. Dygma contributed significant amounts of ideas and mockups to Chrysalis too.

1 Like

A bit more info: Dygma’s Raise has both per-key LEDs and an underglow. That’s something stock Kaleidoscope does not support yet. We have a long-standing issue about this (#376), and I have a board underway with underglow only, to help me figure out the best way to support both. We will likely have to rethink a number of things around how we handle LEDs, which doesn’t make syncing any easier.

  1. Your new board with the underglow only is the new ErgoDox EZ?
  2. Underglows have only one RGB value right? I mean the whole underglow can show only one colour? Or does it also have addressable components? If former, then easier and we just add a function for setting that value without worrying about or affecting existing addressed LED handling.

Nope, it’s a KBDFans KBD4x. I looked for something reasonably cheap with underglow only, just for porting purposes. The new EZ (Glow) has per-key RGBs for some of the keys (that will be an interesting thing to support too!); the EZ Shine has two LED strips, one per half. I want to support those scenarios too, at some point.

Underglow is typically RGB. The one-color thing is backlight, if my terminology is correct. The underglow stuff I’m looking to support has addressable components. Single-color backlight would indeed be easy. Even RGB backlight too, as long as we set the whole thing together (iow, without addressable components).

There’s plenty of work left in this area, I think. I don’t think we want to cram it all into LEDControl (which should be eventually renamed, I believe). Mind you, this is stuff I’m just toying with at the moment, there’s no official roadmap yet.