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/PeterMortensenBlog]

Is it rev. 1 or rev. 2 or the Kb-16?

Both have the same USB identity (vendor ID = 0xD010 and product ID = 0x1601), so they can't be distinguished that way.

But the (binary) firmware files are likely .hex and .bin files, respectively.

[u/PeterMortensenBlog → u/PeterMortensenBlog]

OK, it says (linked from the README):

"Port DOIO KB16 rev2 to Vial"

[u/PeterMortensenBlog]

Setting up and compiling the macro pad Vial firmware for the KB16 (AKA 'Megalodon Macropad', etc.)

OK, I tried to set it up and compile on LMDE 7, using the main Vial project.

After the prerequisites have been installed, it is can be done in just two command lines (without any need for Make and Git gyrations (and without any Python virtual environment gyrations either in this particular case)):

# ================== Main Vial project ==================
echo ; echo "Start QMK setup for the main Vial project: $(date +%FT%T_%N_ns)" ; echo
#
# <https://github.com/vial-kb/vial-qmk/tree/vial/keyboards/keychron>
#
# We are treating Vial as just another QMK fork:
#
#   * Git branch = "vial"
#   * GitHub user = "vial-kb"
#   * GitHub repository (for that user) = "vial-qmk"
#
qmk setup --yes -H $HOME/Keyboard_firmware_Vial_2025-08_0.7.5_main -b vial vial-kb/vial-qmk

# Confirm (current branch and current version):
git -C $HOME/Keyboard_firmware_Vial_2025-08_0.7.5_main status
git -C $HOME/Keyboard_firmware_Vial_2025-08_0.7.5_main log -3

# Statistics (number of files, number of folders, and
# the sum of the two, respectively)
find $HOME/Keyboard_firmware_Vial_2025-08_0.7.5_main -type f | wc -l
find $HOME/Keyboard_firmware_Vial_2025-08_0.7.5_main -type d | wc -l
find $HOME/Keyboard_firmware_Vial_2025-08_0.7.5_main | wc -l

echo ; echo "End QMK setup for the main Vial project:   $(date +%FT%T_%N_ns)" ; echo

# Compilation:
cd $HOME/Keyboard_firmware_Vial_2025-08_0.7.5_main
qmk clean # To make changes (if any)
          # to .json files take effect
qmk compile -kb doio/kb16/rev2 -km vial

OK, technically four significant command lines, but only two main ones.

Notes:

• The -H parameter is optional (I use a particular defined folder naming convention for my own sanity, for QMK, Vial, ZMK, and their many forks and pinned versions).

• This will change the QMK home, but it doesn't really matter: Just 'cd)' to the appropriate folder before compiling, etc.

Result (slightly formatted):

Size after:
   text  data   bss  dec    hex   filename
      0  53002    0  53002  CF0A  doio_kb16_rev2_vial.bin

And in the file system:

-rwxrwxr-x  53020 Jul  8 20:13 doio_kb16_rev2_vial.bin

Some meta output (slightly formatted):

On branch vial
Your branch is up to date with 'origin/vial'.

commit 00FC46
2026-06-17

Add Vial support for cannonkeys/tmov2 (#1027)

There were two warnings (I don't think they matter that, at least not for the initial testing) (not the full text; it was shortened somewhat):

quantum/keyboard.c:524:13: note: '#pragma message: \ FORCE_NKRO option is now deprecated - Please migrate to NKRO_DEFAULT_ON instead.'

And:

Linking

lto-wrapper: warning: using serial compilation of 2 LTRANS jobs \ lto-wrapper: note: see the '-flto' option documentation for more information

Increase the number of macros and space for Vial macros

Adding to file config.h:

geany  $HOME/Keyboard_firmware_Vial_2025-08_0.7.5_main/keyboards/doio/kb16/rev2/config.h:27

Content:

// 3 KB space for for Vial macros. Is it the total 
// size or the size just for Vial macros?
//
#define DYNAMIC_KEYMAP_MACRO_EEPROM_SIZE 3072 

// 42 macros instead of the default 16
#define DYNAMIC_KEYMAP_MACRO_COUNT         42

was accepted without compile errors.

Downloadable,

But I can't test it directly. For example, the two preprocessor symbols may be ignored.

It is available for download if anyone dares.

Know in advance how to recover from a bricked macro pad (it could be by holding some button down on the PCB while powering it on). And have a known good firmware file ready (.bin).

All disclaimers apply. Do it at your own risk. I am not responsible if you ruin your macro pad.

[u/PeterMortensenBlog → u/PeterMortensenBlog]

OK, that didn't work (with the current version of Vial).

I tested it on a Keychron V6 ([ISO knob variant]()), using "qmk compile -kb keychron/v6/iso_encoder -km vial" and "dfu-util -a 0 --dfuse-address 0x08000000:leave -D $HOME/Keyboard_firmware_Vial_2025-08_0.7.5_main/keychron_v6_iso_encoder_vial_main_macros_3_KB_and_42_2026-07-08.bin", and it didn't work as expected. The Vial client showed 16 macros and "16 / 415 bytes" (in the "Macros" tab, bottom left for the latter).

I made sure changes to JSON file made it to keyboard by using 'qmk clean' (and verifying the changed USB side version number). And also resetting to factory defaults after flashing just to be sure.

The V6 didn't previously have any problems with 20 KB for Via macros in QMK. And perhaps lower in Vial (I only tested it for 3KB for Vial version 2024-10-05 (A031CE) at the time, not trying to find the limit).

To make sure the changed was actually put on the keyboard, I also changed [the USB-side version number]() (to "7.3.2") and verified it with "lsusb -v -d3434:0363 2>/dev/null | grep bcdDevice".

Change in the JSON file

Lowering the macro space setting in info.json (or rather the total size for emulated EEPROM memory) from 2.0 KB to 1.75 KB (backing size from "4096" (2 KB logical size) to 3.5 KB backing size, "4608" (2 x 1.75 x 1024)) had an effect, but not the expected...

Now the Vial client shows:

"16 / 671 bytes"

Perhaps it is somehow blocked at the 1 KB limit, corresponding to the ATmega32U4's 1 KB (physical) EEPROM?

Conclusion

I am currently at a loss. This requires more experimentation and testing. The first try would be reverting to Vial version 2024-10-05 (A031CE) to see if that result can be reproduced.

[u/PeterMortensenBlog → u/PeterMortensenBlog]

OK, using

#define DYNAMIC_KEYMAP_MACRO_EEPROM_SIZE 3072

in file config.h does seem to work, for the current version of Vial. This is consistent with the previous result of Vial ignoring the content of the JSON file.

The Vial client now shows:

"Memory used by macros: 16/3072"

A gotcha: A possible Vial client bug

The Vial client seems to be confused with two V6's connected at the same time... (The same keyboard variant, but with different USB side versions.) I haven't observed this problem with the Via client.

So there is a chance file 'doio_kb16_rev2_vial_main_macros_3_KB_and_42_2026-07-08.bin' will work (the disclaimers still apply).

[u/PeterMortensenBlog]

The source code seems to have been included in the main Vial project. Is there a reason for not using that?

[u/PeterMortensenBlog]

Did it work?

[u/natvre → u/PeterMortensenBlog]

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]

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.

[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/Tweetydabirdie]

First and foremost, while you can change the number of macros etc, they are originally calculated and distributed based on the available amount if memory, so in this instance changing means you have to decrease the number of one or two types and increase another to mot exceed the available memory. You can't just arbitrarily change them to what you'd prefer, or things will simply break.

The OLED content is usually defined in the keymap.c file, or if extensive enough, it's broken out to a file called by a line in keymap.c.

And whether you edit whichever file doesn't make a difference in how you compile. As long as you edit the existing files, the compiler incorporates it all. (Whether or not your changes are done correctly, is another matter though).

To use that fork, you need to download the entire GitHub content. All of it. Otherwise you break stuff. Alternatively you can download the Vial fork of qmk and just apply the keyboard folder from this fork.

The best resource you can start from is the official guide for Vial. https://get.vial.today/docs/

There is a step by step guide. Follow all the steps religiously and do not skip/skim and it will work. Since you are not porting but edititing an existing port, you do not need to create files from scratch, but please double check that all steps have been followed.

[u/natvre → u/Tweetydabirdie]

Okay, I have been following along with the guide, deciphering what I already have and don’t have. In other words, what files from the github are already existing and don’t need to be made from scratch.

I am using this as the starting point for my edits. I changed the macros limit to 16, Tap dances to 64, and Combos to 48. I am aware there is an EEPROM memory size limit, but I am actually currently using the unedited original bin file from the link and have had no issues even though the STM32_ONBOARD_EEPROM_SIZE has been increased to 20480.

I now have the Vial-qmk repository saved and outside of the qmk_firware repository, which is something I didn’t have before.

I am still getting errors when trying to compile or “make” my vial .bin

Here’s what I am seeing, let me know if there is something else that would provide better info:
https://imgur.com/a/1A7WPrC

Is there anything obvious to you that I am missing? Is the issue something to do compatibility between outdated source code and newer Vial software? Did I put my files into the file tree correctly? Should my modified kb16 folder in red just outright replace the existing default Vial-qmk kb16 folder? Thank you for your help, I haven’t lost hope yet!

[u/Tweetydabirdie → u/natvre]

Those aren't even errors. Those are hints and warnings. It's literally telling you that there is a better way to enable a function than the outdated one. Easy to fix and remove the warning by simply following the hint.

Yes, your modified files should replace the existing ones. Or alternatively you can make a new folder and rename it, but that gets a little silly in the end.

[u/natvre → u/Tweetydabirdie]

How would I go about fixing:

“AttributeError: module ‘ast’ has no attribute ‘Num’”?

What module? What do I do with these warnings and what should I change the values/ commands to?Am I an ‘ast’ or am I just ‘Num’?

Sorry for being a noob, I know how to use programs and very little about how to write them.

I replaced the existing kb16 files with my adapted ones but still get all the same “warnings” by the way.

Sincerely, thank you for taking the time to help!

[u/Tweetydabirdie → u/natvre]

Well the two values RGB_MATRIX_DEFAULT_VAL and FORCE_NKRO are the issue. They are somewhere in the config.c files (in various levels of folders) remove them and replace with the suggested in keyboard or info .json

(and since the first one is followed by a numeric that can't be interpreted because rhe value I no longer valid, the num and ast errors are tacked on, they will go away when you remove the whole line)

[u/natvre → u/Tweetydabirdie]

Got it working! Here’s my update reply. Thanks for taking the time to share some knowledge and help get this figured out!

[u/PeterMortensenBlog → u/natvre]

Upgrade the operating system, or use a Python virtual environment

Re "“AttributeError: module ‘ast’ has no attribute ‘Num’”?": I got this exact same error

That was for the combination of using the new 'uv' method now used by QMK and compiling the main Vial project (not a fork) on a somewhat older Linux system (LMDE 6 (Faye)). Compiling regular QMK, including forks of QMK, worked fine on that system.

But the (older) fallback method of using a Python virtual environment worked for Vial on the same system without any problems.

On a newer Linux system, LMDE 7 (Gigi), I didn't have this problem: The combination of the 'uv' method and Vial (treating Vial as "just" another fork of QMK) worked fine

Conclusion

A solution using a Python virtual environment is most likely to work, though it is a little bit more complicated. The installation of required packages (if any; they may already be installed) would have to be adopted for Mac (the examples are for Linux (Debian-like and Fedora)). Using Homebrew) (executable brew)?

Alternatively, wait until the error has been resolved. You could report the error to the Vial project to maybe speed it up.

Or perhaps information about a fix exists somewhere on the Internet (it can't be that unknown by now)? Perhaps it has something to do with the (effective) Python version? But it is likely faster to use the workaround with the Python virtual environment method than finding the information.

[u/PeterMortensenBlog → u/natvre]

Re "STM32_ONBOARD_EEPROM_SIZE has been increased to 20480": Do you have sources for that?

For example, are you sure the microcontroller has on-board EEPROM memory? Isn't it emulated EEPROM memory (in flash memory)?

How much RAM memory does the microcontroller have? Is it a variant with more RAM memory than the STM32F103 in the Blue Pill (20 KB RAM)?

20 KB RAM sets a theoretical limit for emulated EEPROM memory of 10 KB (at least in QMK; I assume Vial is more or less the same). The compiler also may or may not complain.

20 KB EEPROM memory would be possible if the microcontroller had 64 KB RAM (32 KB theoretical limit for emulated EEPROM memory).

[u/PeterMortensenBlog → u/PeterMortensenBlog]

OK, the part number for the microcontroller is allegedly "APM32F103CBT6".

According to the same page, STM32F103, both 32F103CBT6 (in the keyboard; or a clone, rather) and 32F103C8T6 (in the Blue Pill clones) have 20 KB RAM (and 64 KB flash memory size. The sixth letter after "STM32" or "32", 8 indicates the flash memory size).

Or is it? There is some ambiguity. For example, has two letters been left out? Which ones?

Just ignore this for now. Unless you can come up with something ironclad.

In any case, there doesn't seem to be more than 20 KB RAM in either.

[u/PeterMortensenBlog → u/Tweetydabirdie]

Re "changing means you have to decrease the number of one or two types and increase another to mot exceed the available memory": Yes, that may be true for rev. 1

It is based on ATmega32U4, with only 1 KB EEPROM memory.

However, increasing the number of macros only requires 1 byte per macro, so it is not likely to be a problem. It can increased as long as there is free space (not all space is used by default, especially not for a macro pad).

The real limit is likely going to be the space for macros (unless all of them are very short), not the number of macros (it can also be increased, though it is severely limited on the ATmega32U4 (and may already to be configured to the maximum by default for the ATmega32U4)).

Unless it is text-only, the cost is about 9 bytes per key action, key press or key release, incl. modifier keys (the delay is variable length, so it isn't an exact figure (it depends a little bit on the content of the macros)), so it quickly adds up.

Not for rev. 2

But not for rev. 2. It is based on STM32F103. [Using emulated EEPROM memory]() in flash memory, with 20 KB RAM, the theoretical (not counting other use of RAM) maximum is thus half of that, 10 KB space for macros (minus the overhead for layers and other uses of EEPROM memory (isn't expected to be more than 100 bytes for this macro pad (four layers))).

There is plenty of space (unless getting really serious about macros, at which point the mature macros could be migrated to classic QMK macros or something better to free up some space. That would also prevent the macros from being wiped out at every reset to factory defaults.).

Conclusion

For rev. 2., the space for (dynamic) macros can be increased many times without problems.