Ah, thanks. I forgot about that. I do need to add something about either cloning the repo where qmk expects it or changing it after.
For others (until I add it in):
To show qmk’s home directory, the location where it will compile firmware from
qmk config user.qmk_home
To change the location, add = and the fullpath
qmk config user.qmk_home=/[FULL-PATH-TO-REPO]/
You can also choose to specify the Framework GitHub repo when you use the qmk setup command. Right now, though, if the process is new for someone, it’s probably better to pull from the official repo to make sure your environment is setup correctly, since the Framework fork has an old bug in the qmk doctor check.
i found after having to reinstall my OS a few times and setting up QMK each time that when you start to setup all you need to do is create the folders leading to where you want the firmware located and input this in the terminal:
qmk setup -H ‘{your drive letter here}:/Program Files/{all subfolders}/{empty firmware folder}’
this will link your empty folder as the location to look for firmware. then you can copy the firmware into that folder. you can always clone it with the directions previously stated by MJ1 and move it to the folder you want used.
after the setup accepts your home folder location it will run the rest of setup. if the home folder is empty it it will ask to clone qmk/qmk_firmware to the home folder. if the firmware version you need is already inside the folder before setup it detects the files then it just asks to confirm home folder location with no requests for clone. you can do the setup first then go back and do the git clone command with an addition to make sure it doesnt go into a default C drive location:
git clone -b v0.2.9 https://github.com/FrameworkComputer/qmk_firmware.git '{YOUR PATH TO FOLDER LOCATION}'
you can clone first then run setup so it detects the firmware and doesnt ask to clone again. i have to use the single quotation marks because it doesnt work with spaces in folder names unless the quotation marks are added to read the spaces and not think its a seperate portion of the syntax for the command.
you can also have different branches and tell it which branch you want to use. like i have the untouched clone of the firmware and then have a copy that i removed all the other keyboard and macropad or numpad files and only have my keyboard folder so when you compile it doesnt look at any other keyboards.
i had to do this because compile would not work for me. i had to use ‘make’ instead and did not like specifying the keyboard folder to look at. you have to look at what directory you are in by using ‘dir’ and will show all the folders under the directory you are currently in. use ‘cd …’ to go up a folder and 'cd {next folders here} if you need to change the drive you are looking at just put the drive letter like this A:/…/firmware_folder and add whatever folders you need to go down to get the main firmware folder. i used VIA to add the QK_BOOT which is called Reset on the special keycodes tab to the FN layer so i use ‘make’ when ready and when complete go to .build in the main folder and if you only used ‘make’ on one keymap it will be the only one to show there. just copy the .uf2 file and hit the QK_BOOT/Reset key and a new drive will show in file explorer just paste the file in there and the drive will disappear. when you hit the Reset key only the keyboard or numpad or macropad the key is registered on will go into bootloader mode. this means you need to put a reset key on whatever keypad you want to update. After you copy the file and if the keyboard has not turned back on by itself then all you need to do is slide the mousepad out until all the modules turn off and when slide it back the keyboard and other modules will initialize and start working.
with the terminal open and the file explorer waiting i can ‘make’ and reinitialize the keyboard in 3 minutes max. now if there are errors it is another story. lol
Do you mean that the keyboard gets reflashed on every boot? That seems odd… I would expect to be able to flash it once and have that persist indefinitely.
i mean every time you hit the key with QK_BOOT assigned to it. in VIA its not called QK_BOOT but instead Reset. so you can use VIA to give you the assigned keycode to go into the bootloader process where the keyboard uninitializes and makes the storage visible to the computer where you copy the .uf2 into the drive main folder. not any subfolders. then it automatically tries to reinitialize but if it removes the keyboard drive and still not initialized you can remove the mousepad until its not connected to the midplate pins. this will unpower every module you have attached even if they are still in place so then push the mousepad back in and when it connects fully every module initializes and your new setup should be active.
Ahh got it. Yeah that’s a pretty good trick then 
I wanted to remap the right alt and right ctrl to left mouse click and right mouse click, since there are no physical trackpad buttons and it was driving me nuts trying to select text, only to have the cursor jump a little as I was trying to lift my finger off.
Turns out “mousekey” is disabled in the firmware by default - easy enough to switch to “true”, but then I had a whole adventure with the keyboard in bootloader mode - systemd kept unmounting the disk device that the keyboard exposed, immediately after it had just mounted it, so I had to disable udisks2 and manually mount the device - thankfully I didn’t have to figure out specifically WHERE to mount the device, my default /media/$USER dir got picked up right away by qmk flash
Just thought I’d toss the idea out there! This trackpad really is not good enough to not have physical mouse buttons, but at least I could hack this in to help a little.
There are a few issues here. Some arm packages need to be installed on Fedora 40, Make sure all of these are there:
arm-none-eabi-binutils-cs
arm-none-eabi-gcc-cs
arm-none-eabi-gcc-cs-c++
arm-none-eabi-newlib
Hi, I have been spending hours trying to get this to work, to no avail. I appear to be compiling and flashing correctly, but my keyboard doesn’t change. I have checked out the github repo. I have a directory framework-git/qmk_firmware/keyboards/framework and in there I have copied the ansi directory in its entirety and created a “schwager” directory. I have edited my info.json file and given my keyboard a new name, and that name shows up in lsusb. So the keyboard thinks it’s a Schwager.
I edited framework.h and added
#elif KEYBOARD_framework_schwager
#include “schwager.h”
to the #ifdef at the top. (but I don’t think it matters)
Still, when I compile my uf2 in my schwager directory my keymap doesn’t change. I know this because I created a Dvorak layout so it’s radically different.
I have run “find” commands to ensure that I don’t have strange uf2 files lying around. In pretty sure I’m compiling the uf2, right now, that I’m uploading to my laptop.
qmk compile -kb framework/schwager -km default
qmk flash -kb framework/schwager -km default
Those are my commands.
qmk config user.qmk_home # shows:
user.qmk_home=/home/schwager/Projects/Keyboard/keyboards/Framework/qmk_firmware
I have tried to copy the files to the RPI-RP2 as root to flash it after booting the keyboard but that doesn’t change anything.
Linux, windows?
So you mean you’re seeing something like this? (linux)
$ lsusb
Bus 002 Device 002: ID 32ac:0012 Schwager Laptop 16 Keyboard Module - ANSI
If so, are you clearing the keyboard’s persistent memory / EEPROM after flashing?
~edit~
Oh boy, the little how-to I posted never mentioned clearing EEPROM, did it?
If you followed that, apologies. It’s not technically always required, but if you’ve used Via before, then EEPROM should be cleared after flashing. That’s probably why others haven’t run into the problem.
You can clear the EEPROM by commandline using Framework’s qmk_hid tool github.com/FrameworkComputer/qmk_hid
qmk_hid --pid 00XX via --eeprom-reset
Where 00XX is the product ID of the module you want to clear.
0012 Framework Laptop 16 Keyboard Module - ANSI
0013 Framework Laptop 16 RGB Macropad
0014 Framework Laptop 16 Numpad Module
0018 Framework Laptop 16 Keyboard Module - ISO
0019 Framework Laptop 16 Keyboard Module - JIS
You can also do it using Via (keyboard.frame.work)
Resetting the keyboard to factory default / clearing persistent memory.
This will erase any changes you’ve made in Via (keyboard.frame.work). If this is your first time using the site, you’ll have to authorize connection to your keyboard first.
Special sectionQK_CLEAR_EEPROM and press ConfirmAnd my how-to post is past the time limit for editing. Deleting is the only option left for that post.
Sorry, Linux. Fedora 40.
Yes, your lsusb output is correct.
I am not clearing the persistent memory after flashing. Just flashing. Do I need another step?
Sorry, yes. I edited my post right above, just as you posted.
Hmm… What does that do? According to your original post, above, the keyboard will boot off the uf2 file and the new keymap will be enabled…?
Ooof. From the qmk_hid github page:
VIA stores its config in EEPROM (sometimes emulated in flash). When using a different keyboard with the same controller board you’ll want to clear it, otherwise the previously stored VIA config overrides the hardcoded one.
Yeah, your flash probably worked fine. But if you’ve used Via before then it can store a copy of the now old keymap, in persistent memory, which can remain after flashing. And if the new firmware you flashed has Via, and it’s enabled, then it will look for a stored keymap first.
LoL! Well, after a very frustrating afternoon, that did it. Imagine my surprise when my keyboard turned on full blast and all of the sudden “asdf” became “aoeu”! Now I have to figure out what the hell I told my keyboard to do. Fun times!
Well anyway I couldn’t have done it without you so thanks. But yeah, maybe another thread would be good. Or even just a link to a wiki page that could be updated regularly.
Lastly, I swear I swear I never ever downloaded anything via Via before. I have a Kyria and my intention has always been to configure this thing with QMK because I’m used to it and I want to do more fancy tricks with C. So I figured, why bother with Via? I also think there are some key actions that I do that iirc won’t work with Via. Sooo… if I was not supposed to have to clear the EEPROM first, then blow me over with a feather because I don’t know how I might have gotten into this state.
Wow thanks. I’m typing in Dvorak. Nice. My brain thanks you.
Oh, I am sorry. 
I thought about it, but I wasn’t sure if it’s easy to follow / straight forward enough for people new to flashing QMK. And not missing anything important! Like you discovered it was…
I thought only making changes or interacting with Via would cause it write the keymap to EEPROM memory. But I guess not. Or not always. Perhaps anyone else following the how-to, who didn’t run into this, just didn’t have Via included or enabled in their new firmware.
I don’t normally use Via myself, as you said, it’s missing features. It also seems just buggy sometimes. Vial is much better in my opinion. And of course editing QMK files directly for anything else.
So my firmware got loaded and it’s working, but I seem unable to make any further changes to it. I even tried changing some basic letters and they did not seem to take.
I have added a new layer to the keymap.c file and noticed that the .uf2 file grew in size, so I think the uf2 is getting recompiled, but somehow my changes are not seen on the keyboard? I have a key mapped to QK_BOOT, so I:
I wonder if I need to clear the EEPROM every time, or something crazy like that?
Furthermore, I know I didn’t use Via before because when I used it this afternoon I had to jump through hoops to overcome permissions issues. It wasn’t able to touch the keyboard because the permissions weren’t right (previously).
Well, there is the Via GUI, but there is also a Via component in the firmware if you haven’t turned it off.
Try throwing an eeprom clear at it after your flashing
Or if you don’t plan to ever use Via, and feel no need to keep access to it, you could just nuke it from orbit (I just rewatched Aliens).
/qmk_firmware/keyboards/framework/rules.mk
# Only way to be sure. Goodbye Via.
#VIA_ENABLE = yes
RAW_ENABLE = yes
OK, I have shut off the damn Via stuff. I’m still clearing it. I will probably play with that later, once I’m happy with what I’ve done.
Here’s my build script:
cd /home/schwager/Projects/keyboards/Framework/framework-git/qmk_firmware/keyboards/framework
qmk compile -j 4 -kb framework/schwager -km default
echo Output is in /home/schwager/Projects/keyboards/Framework/framework-git/qmk_firmware/
and here’s my flash script:
#!/bin/bash
cd /home/schwager/Projects/keyboards/Framework/framework-git/qmk_firmware/keyboards/framework
#qmk flash -kb framework/ansi -km default
qmk flash -j 4 -kb framework/schwager -km default
#qmk compile -kb framework/schwager -km default
echo Output is in /home/schwager/Projects/keyboards/Framework/framework-git/qmk_firmware/
sleep 2
sudo $HOME/Projects/keyboards/Framework/qmk_hid/target/debug/qmk_hid -v --pid 0012 via --eeprom-reset
I found it easiest to actually build the qmk_hid using cargo; everything else gave me issues:
cd to_an_appropriate_place
git clone https://github.com/FrameworkComputer/qmk_hid.git
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
. $HOME/.cargo/env
cargo run
cargo build