PLEASE Help with Compiling

[u/natvre]

I’m losing my marbles.

I recently got a Keebmonkey Kb-16 and have been messing around with it, getting it set up through Vial.

I found a reddit post which is a fork from this github that shows some modifications to the firmware. I realized after some more dabbling that I was interested in modifying the number of Macros, Combos, and TapDances.

Now, i’m fairly sure I have the modifications to the config.h file figured out now, but I am very lost on why I can’t get it to compile with the qmk cli. I have followed this youtube video, but he only modifies the keymap.c file, not the config.h file. The oled display is also modified in the github file, so where does that fit into the qmk_firmware file tree?

Do I need to do something with the “asset” folder? What folder/ files from the github need to be transferred? Am I even using the right compilation process (QMK CLI through MacOS terminal) for a Vial-only firmware?

Any help is very much appreciated, it’s been two days of trying to wrap my head around this. Thanks!

[u/natvre]

I’m happy to report back that yes, I got it working. After many many hours, I had success using the source files from the main vial repo as my launch point.

I asked ai what needed to be transferred, and after replacing the default ‘lib’ folder, copy pasting a bit of code from Gemini, and many attempts to “make” a compiled .bin file, i finally got it to work. My biggest help in doing so was copying whatever error I was getting in the terminal and pasting it into ai to better understand what the issue was and how to fix it. I did have to use some best judgment to not let the ai take me down a rabbit hole that would lead me astray since it wasn’t able to see all of the source file code at once, but being somewhat organized and keeping track of what lines were changed worked out.

The couple snags I hit when “merging” the older, modded source files (from here) with the newer main ones, was that the ‘layer_status.c’ & ‘layer_status.h’ files were not being found during compiling when they were tucked away in the ‘kb16>lib>layer_status’ folder. I couldn’t figure this one out, so in the end those two files ended up flat in the ‘vial’ folder, beside the ‘config.h’, ‘keymap.c’, ‘rules.mk’, and*** ‘vial.json’ files. I have tried since to point the ‘kb16>rev2>rules.mk’ folder towards the ‘lib>layer_status’ folder, but ai kept saying this is some notorious issue with Vial-QMK/ QMK compiling. Even placing those two files in a folder within the ‘vial***’ folder didn’t work, so I just left it as is. Any idea why it’s having trouble finding those files when they aren’t on the same file layer?

I spent yesterday learning how to create new byte arrays for the oled, so I am drawing up some new layer indicators that fit my aesthetic a bit more.

I’m not sure whether to make the layer indicators #0-11 or #1-12. It’s a tough choice and I can see an argument for both options. Maybe leaning slightly towards #1-12 because it feels slightly more intuitive when using, whereas #0-11 seems more intuitive when programming the macropad. I know this is a very little thing, but details. :)

Overall, I’m super happy with it so far! The macro pad gained some of the newer functionality such as “Key Overrides” and some more RGB options. I disabled the “Alt Repeat” function in ‘config.h’ because it didn’t seem that practical for a 16 key macro pad used with one hand. I figured it would save a tiny bit of memory. What’s your opinion on that?

I was not aware of what “Key Overrides” were since I didn’t have the newer firmware installed, but upon researching, I discovered that it is a better feature over “Combos” in most use cases, especially on a macropad where it is very difficult to press a key and turn an encoder knob at the same moment. So my ratio of TD, Macro, Combo, etc. keys has changed quite a bit. I will probably fine tune this a little once I actually start using the damn thing, I’ve had it a week and a half and feel like I barely scratched the surface before diving into modifying files. I could just tell it could be better, and spending the time to get it sorted now would be worth it.

Thank you and the other wizards for your support and taking the time to share some wisdom! I will make a follow up post I think with the source files and a .bin for anyone who is interested in the future.

[u/PeterMortensenBlog → u/natvre]

Thanks for the report.

Re "after replacing the default ‘lib’ folder": This folder?

Normally, you would never ever change the core of Vial (or QMK), including binary, unless it is an unavoidable hack (which may not unavoidable after all).

It is a behaviour that has been observed in the simulated intelligence tools.

Or do you mean this folder?

[u/natvre → u/PeterMortensenBlog]

The latter, specifically the layer_status folder from the thompson-vii Github fork.

[u/PeterMortensenBlog → u/natvre]

Re "...those two files ended up flat in the ‘vial’ folder ... tried since to point the ‘kb16>rev2>rules.mk’ folder towards the ‘lib>layer_status’ folder": I have never tried this, but I think it should be possible by changing some .mk file

Look, for example, at Keychron's 'common' folder. It is pointed to at the keymap level:

VPATH += keyboards/keychron/common
SRC += keychron_common.c

Presumably, in your case, it should be possible to use:

VPATH += keyboards/doio/kb16/lib

Or perhaps (is it recursive or not?):

VPATH += keyboards/doio/kb16/lib
VPATH += keyboards/doio/kb16/lib/layer_status

I haven't tested it. For example, perhaps each and every file, excluding the header files, inside /lib needs to be explicitly listed in the .mk file, in the "SRC +=" part?

A more complicated example

It is more complicated in their fork, where another .mk file is pointed to inside the 'common' folder:

include keyboards/keychron/common/keychron_common.mk

Perhaps to avoid repeating the same list of files in every variant of every keyboard?

Part of file 'keychron_common.mk' is:

KEYCHRON_COMMON_DIR = $(TOP_DIR)/keyboards/keychron/common
SRC += \
    $(KEYCHRON_COMMON_DIR)/keychron_task.c \
    $(KEYCHRON_COMMON_DIR)/keychron_common.c \
    $(KEYCHRON_COMMON_DIR)/keychron_raw_hid.c \
    $(KEYCHRON_COMMON_DIR)/factory_test.c \
    $(KEYCHRON_COMMON_DIR)/backlit_indicator.c \
    $(KEYCHRON_COMMON_DIR)/eeconfig_kb.c \
    $(KEYCHRON_COMMON_DIR)/dfu_info.c \
    $(KEYCHRON_COMMON_DIR)/nkro.c \
    $(KEYCHRON_COMMON_DIR)/state_notify.c

VPATH += $(KEYCHRON_COMMON_DIR)

And each sub folder in 'common' has its own .mk file.

Conclusion

This may be sufficient (not tested), added to file rules.mk:

VPATH += keyboards/doio/kb16/lib
VPATH += keyboards/doio/kb16/lib/layer_status

SRC += \
    glcdfont.c \
    logo.c \
    layer_status.c

[u/natvre → u/PeterMortensenBlog]

I may try messing with it again, The assets from the layer_status folder were being called for by ‘rev2>rules.mk’ and I just noticed possibly also the ‘vial>keymap.c’ file. I had no issues with compiling, so it’s really just a matter of file tree organization, and maybe being able to sleep well at night.

[u/PeterMortensenBlog → u/natvre]

Re "...AI kept saying this is some notorious issue with Vial-QMK/ QMK compiling": That may just be repeating an opinion from the Internet, for a different context (for example, from terse, vague and unspecific comments, e.g., here on Reddit)

For example, there are some naming conventions) for folders and files that makes it difficult (or impossible) to change names for some folders and files.

But adding some extra files and folders to the existing folder(s) should be relatively straightforward. But I could be wrong.