Compiling firmware

Userspace (Recommended)

We've set up a QMK Userspace on our Github page.

Using a userspace makes it easy to compile firmware and keep up with changes. The Halcyon Series makes extensive use of this feature to provide support for the Halcyon Modules. Doing it in this way allows us to develop cool features, while not burdening the QMK maintainers with our custom code.

The process of setting up the userspace is documented in the README in the repository linked below.

Compiling from scratch

If for whatever reason you don't want to use the qmk userspace feature, you can still use the old fashioned way of compiling qmk or vial. We recommend following the QMK documentation for that.

Using the modules using this method requires a bit more work. You will need to copy over the users/halcyon_modules folder from our qmk_userspace repo to the users folder in your own qmk fork.

If you don't want to use any modules you can just not copy over the previously specified folder. The keyboard will work totally fine without it and you can just use the regular qmk documentation for compiling.

If you do want modules then create and add USER_NAME := halcyon_modules to your keymaps rules.mk. When compiling you will need to add -e <halcyon_module>=1 -e TARGET=<filename> to the compile command. Where halcyon_module can be the following:

• HLC_NONE, If you don't have a module installed but you do have a module on the other half.
• HLC_ENCODER, If you have an encoder module installed.
• HLC_TFT_DISPLAY, If you have a tft rgb display installed.
• HLC_CIRQUE_TRACKPAD, If you have a Cirque trackpad installed.

Or any other module you added on your own. For the filename make it so you can differentiate between the different firmware's for the modules. kyria_rev4_vial_encoder for example.

Changing advanced module behavior

If you want to change the behavior of a module that doesn't have any options within vial you will need to change the code in the users/halcyon_modules/<module_name> folder. Within this folder you can change the .c, .h, config.h or rules.mk files to your liking. For the actual configuration options, check out the QMK documentation.

If you want to add any custom .c files you can do so by adding a SRC += <file>.c to your keymaps rules.mk or SRC += $(CURRENT_DIR)/<file>.c to the modules rules.mk

For the modules we added some extra hooks. Mainly the following:

• void module_post_init_kb(void)
• void module_post_init_user(void)
• void module_housekeeping_task_kb(void)
• void module_housekeeping_task_user(void)

These four are added because we already use the keyboard_post_init_kb and housekeeping_task_kb in the main halcyon code. Any module can then use the other hooks to do anything else.

• void display_module_housekeeping_task_kb(bool second_display)
• void display_module_housekeeping_task_user(bool second_display)

Finally we added a display housekeeping task. We added the feature where the keyboard can detect if there are one or two displays connected. Because we always want to show information about layers if we only have one display, where it doesn't matter where the display is located. We use this to determine if the keyboard with display module is the second display or not and draw the content accordingly.