Custom QMK firmware?

Framework Laptop 16
43

Which keyboard should I use as a base?
qmk compile -kb <what-kb-template-to-start-with> -km default

I do not see a “framework” directory under framework_qmk/keyboards/. I note that Mr Schwager above based his on ansi, but I’m not finding a template for that either. What shape is the matrix? cols/rows.

44

Which branch did you download?
v0.2.9 is the on one you want (at the time of this post).

git clone -b v0.2.9 https://github.com/FrameworkComputer/qmk_firmware.git

See here: Custom QMK firmware? - #14 by MJ1
plus this: Custom QMK firmware? - #31 by MJ1

1 Like
45

Thanks. I made the mistake of checking out master and expecting it to be there. Or at least see ‘v0.2.9’ as a branch. I think v0.2.9 is technically a tag.

I had some “fun” by using the python tool uv for a virtualenv which, at least on master, broke the qmk install and provided a time sink. Is there a suitable respository of knowledge to log our experiences for others to pick over. Or is this it?

46

We don’t have anything really ideal.
For some things: framewiki.net
For linux related info, the arch wiki is great, as it usually is. With lots of info that also applies outside of arch. wiki.archlinux.org/title/Category:Framework
And for most other things, the forum here.

Also for general FW firmware there is an issue tracker on their github: github.com/FrameworkComputer/SoftwareFirmwareIssueTracker

1 Like
47

I have worked on a modified firmware for my Numpad.

It’s small stuff, really. Esc + Backspace for backlight control, and Esc + equal for breathing toggle.
Because the default bind to Numlock creates two problems:

  1. You need to handle NumLock states.
  2. The Enter and + key wont function in the “alternative” mode for navigation
  3. There’s no way to tell

This use the tap .. whatever. It’s not elegant, I want it to be as basic as possible, but there isnt much I can do.

There’s still no way to tell the state of the Numlock. The RGB Macropad solve this issue because you can set per-key RGB, you can just set the numlock one to be a whatever. But this one is the whole thing. I might do a (fast-ish) breathing toggle or something.

I will need to clean up and post the thing as a fork and pull request it. Though Framework’s backlight just doesn’t work.

Why don’t we just have a “backlight disable” pin instead of the whatever funky comminication with EC going on? It doesnt even disable the laptop “butt types”, quite a massive issue. Though it could also been happening on other laptops, but the soft chassis is not helping.

@ViPERPHiSH
I can’t say much beyond “just use Linux and build your own QMK firmware via terminal”. It’s way easier than on Windows, where you have to install 5 different things, and the built-in Python.

Shoehorning command line tools and pretend it’s a GUI in Windows is just pain.

2 Likes
48

so i tried dropping in the file for the ANSI keyboard, and it copies over, then the “drive” vanishes, less than a second later, then the drive reappears.

49

Hmm. What’s its state now? If it’s still showing as a drive, you can try restarting it by disconnecting & reconnecting. If not working after that, can you link to the file you dragged over to it?

50

https://github.com/FrameworkComputer/qmk_firmware/releases/download/v0.2.9/framework_ansi_default_v0.2.9.uf2

tried removing the keyboard module, tried full system reboots earlier, nothing seems to work.
and it always shows as a system drive.

Edit, it seems to be working now

51

Update: after i turned off my computer last night and went to bed, i turned it on again this morning and it forgot the firmware, flashing new firmware fixed it.

would you know why it forgets the firmware when powering down?

52

This is the most interesting. Have you flashed the … reset sketch?

Framework use QMK supporting VIA. So upon power up it immediately put the keybind into “EEPROM” (which is not EEPROM its just a section of PROGMEM but pretended to be EEPROM). And it cause weird behavior when you flash something with this PROGMEM not empty.

There is a giant “erase everything” sketch (26MB ish). You should do that before you flash any “new” firmware.

53

Are you on windows or linux?
As @Xavier_Jiang said, a Via keymap left in EEPROM persistent memory would be most likely. Try clearing it.

Clearing the keyboard's persistent memory / EEPROM (click to show)

This will erase any and all changes you’ve made in Via (keyboard.frame.work) and return the keyboard’s firmware to it default state. If the firmware is the original that came with the keyboard, then it will return to factory default.

• Clearing EEPROM from Via.
If this is your first time using the site, you’ll have to authorize connection to your keyboard first.

  1. Go to keyboard.frame.work.
  2. Select a key to remap by clicking on it, the key will start to slowly flash
  3. In the key selection area below, click on the Special section
  4. Select the Any keycode, found at the bottom
  5. Enter QK_CLEAR_EEPROM and press Confirm
  6. On the keyboard, press the key you just remapped
  7. Reload keyboard.frame.work for it to show the change

• Clearing EEPROM outside of Via.
Framework created a utility called qmk_hid which also offers the option of clearing the EEPROM, github.com/FrameworkComputer/qmk_hid. There is a Windows point-and-click GUI, a Linux python3 GUI, and a Linux commandline tool, github.com/FrameworkComputer/qmk_hid/releases.

Funny, I never noticed that erase_flash.uf2 along with the firmware files. Seems odd that FW tells users to use that, causing extra wear to the flash, rather than use the Clear EEPROM function built into qmk. FW’s own qmk-hid utility has an option to clear EEPROM. And for windows users FW provides flasher .exe’s for each keyboard. Does it not offer an option to clear the EEPROM before flashing?

54

My approach (since Via is very limited in functionality) is to just not touch anything Via. I dont know if clearing the EEPROM via Via just reset it to the value stored in PROGMEM or if it actually erases the entire EEPROM. I suspect the former, because the writing-to-eeprom happen on power on.

So. When I was modifying my firmware, I first flash erase_flash (regardless of whatever), then I flash the modified firmware. If my modified firmware don’t work, it doesn’t matter. flash erase_flash again, rince repeat.

I wish we can just bomb the Via support and remove it to keep code clean, and just update our code to use QMK Configurator. Or recompile.

But it is one of the many thousand forks of QMK. So. Code maintainability be damned.

It is important to note that you will lose keyboard capability when erase_flash is flashed to chip. It will just act dumb. Like a unprogrammed Arduino. Which is basically what it is.

55

QK_CLEAR_EEPROM is not a Via function. It’s a QMK built-in code, you are only using Via to place it on a key so you can trigger it. github.com/qmk/qmk_firmware/blob/master/docs/quantum_keycodes.md.

You can disable Via.

./keyboards/framework/rules.mk

VIA_ENABLE = no

I’ve never been a fan of Via myself, I don’t use it. But Via support is not part of a fork, it’s been in QMK mainline for a long time. Perhaps someday we’ll get XAP and Via will die off.

1 Like