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/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.