Bazecor VS Raise-Firmware

Sadly I agree. Splits are great. I am eagerly awaiting my ortholinear split keyboard from https://dygma.com/ - no affiliation other than being a customer of their first keyboard, the raise and having the defy on order.

Maybe it's just me, but I think the proliferation of mechanical keyboards brings people closer to the fringe where custom keyboards, layouts, parts and pcbs are the norm for the pursuit of perfection.

Windows | Mac Arm | Mac Intel | Linux

The software is open-source and you can fork it if you want. Here's the link to our Github: https://github.com/Dygmalab/Bazecor 😊

I have tried passing the disable shm flag without any luck (disable-dev-shm-usage). The repo is https://github.com/Dygmalab/Bazecor/tree/blacksmith

Dygma Raise or Defy.

Bazecor 1.1.2 Firmware v1.0.9beta

This bug is still not fixed after 2 years and it's very disappointing. I use OSL for almost all layers except for macro layer, which I use Shift to Layer.

Found this https://github.com/Dygmalab/Bazecor/issues/90 where someone figured out F20 is triggering XF86AudioMidMute in Linux. So, this may not need any custom QMK firmware at all, and could be as easy as assigning F20 to some key with VIA and see if that does what you need. F20 is available in the VIA Configure (keyboard icon) Tab under Special down on the lower left side.

I can point you to there https://github.com/Dygmalab/Raise-Firmware

Getting the Dygma Raise firmware to compile was mostly easy thanks to the Github instructions for the Dygma Firmware https://github.com/Dygmalab/Raise-Firmware. I'm on Windows and the documentation seems a little sparse for Windows compared to Mac/Linux which made me nervous that it might not work but it works great with Arduino IDE. The one hiccup I hit was a compilation error related to a "{build.version_flags}" not being defined. I worked around the issue by removing the reference to it in boards.txt. Looks like that was introduced in the linked commit, would be great if somebody from Dygma could take a look so others trying to build the firmware themselves don't also hit this: https://github.com/Dygmalab/Kaleidoscope-Bundle-Dygma/commit/8b526fca1841d70e30682128f0f35292d8cd7e94

 I was reading DygmaLab git repository and found this! It probably means ortholinear Raise is almost ready for sale? I find it interesting how they have 16 thumb keys in 2 rows.

By APIs do you mean the interface to the keyboard itself? The firmware used in v1 introduces “super keys” in place of “tapdance”, but if you are interacting directly with the keyboard you might want to take a look at the beta firmware on GitHub to understand the changes it makes https://github.com/Dygmalab/Raise-Firmware/blob/superkeys/Raise-Firmware.ino

You can ask our developer in our GitHub.

after this line you can put your code to alter it's behaviour or enable it in some keys of the default map above -> https://github.com/Dygmalab/Raise-Firmware/blob/master/Raise-Firmware.ino#L261

They are pushed to the repos in their own branch called fixFreeze2, to compile your own firmware you have to follow the instructions Here

To know the correlation between the position of the map sent and the actual keys in the keyboard, look here. There you should have everything you need, including the color map section. And all the documentation required is linked on the firmware repo 😊