Both VIA and Vial require modifications on top of the existing QMK firmware.
No longer accurate.
It might have been accurate when he posted it, but it’s certainly outdated now. And he doesn’t say what “speed” is supposed to mean. All options preform just as fast. I presume he means time it takes to reconfigure, but just listing “speed” is much too unclear.
1 Like
I’m going to necro this thread, because I just got my framework today and RIGHT off the bat the features I’m using on my Ergodex a LOT. (Tapdance) don’t seem to be supported in VIA. (Well limited support KP_LSPO etc. Not arbitrary keybinds. Now I could try and compile flash things, but /sigh I found Vial with support, and if we map the JSON from VIA to Vial maybe maybe it will work? (The web does detect the macropad, just doesn’t have the JSON to load the view??? Maybe other issues…)
I’m top of this, is it my imagination, or is layer 0 reserved for the num pad? I don’t know what happened but the macropad boots onto layer 1, and I can’t swap to layer 0, no clue what is up, maybe I need to bind a reset keybinding…
Yeah, Via doesn’t have tapdance. Whereas Vial does have tapdance, plus combos, key overrides, and a range of qmk settings. I use Vial on my 15 button mouse, where I couldn’t even live without tapdance anymore.
You could enter your tapdances directly into qmk, but having it available in a GUI is much nicer.
For LSPO, you mean Space Cadet- Left Shift, Parenthesis Open? Haven’t used it myself, but Vial is supposed to support it https://github.com/vial-kb/vial-qmk/blob/vial/docs/feature_space_cadet.md, and tapdance can also do it.
Do you mean, like, sideloading a draft keyboard definition in Via? I’m afraid more is needed for Vial. Porting guide - Vial
Which keyboards were you looking to do? ANSI, ISO, keypad, macropad?
I made an ANSI vial layout .json which you could use, so you don’t have to do that part of the porting at least. Feature Request: Num Lock on boot, Schematics for Keyboards (to build vial support) - #7 by MJ1
Now, Framework has made a few changes in their QMK fork that you should bring over to a Vial build, but I don’t know how many are absolutely necessary. For example, there is Airplane mode button support which Framework added, but if you don’t use that, then you might not bother bringing it over.
You can’t switch layers at all? The macropad uses numlock. So if your OS turns numlock on or off for any reason, that will control your macropad layer. Perhaps that’s happening?
Otherwise, yeah, maybe Via’s memory got screwed up & it’s stuck. For resetting, note that Via does not accept the EE_CLR alias, you need to use the full QK_CLEAR_EEPROM.
I bet it is numlock, I bet I pressed it on accident, and the next layer doesn’t have it so you can’t switch back. I’ll look!!
I can change layers, but I can’t get to layer 0 no matter what I do. TO(0) does nothing, >TO(2) works fine.
Yes KP-LSOP is the space cadet l-shift ( combo.
It was the numlock, I pressed it, to get to layer1 didn’t realize it, bound that key over to move to layer 3 or whatever, then was super confused why I couldn’t get back to layer 0.
As far as tapdance and the like, That is a real shame, tap dance is a great way to get to layers while over loading a normal key. I’ll play with it more, see what I can dig up.
If you want to set up tapdance directly in qmk, here is a little guide on building for the Framework keyboards.
Custom QMK firmware? - #14 by MJ1
1 Like
I was able to clone * vial-qmk
git clone --recurse-submodules https://github.com/vial-kb/vial-qmk
Then remote attach * qmk_framework
git remote add qmk-framework https://github.com/FrameworkComputer/qmk_firmware.git
Then create a branch vial-framework
git branch vial-framework
git checkout vial-framework
Fetch the framework changes, so they can be merged onto vial…
git fetch qmk-framework
Then merge the correct framework branch on top of vial.
git merge qmk-framework/fl16-v0.2.8-prep
Surprisingly the ONLY conflicts where some github action yaml files!!!
I assume I just need to now add the correct json, and do the proper port process to the keyboard file in framework/macropad???
2 Likes
Framework’s changes aren’t in the main branch.
You’ll want to use the latest release instead. It’s currently v0.2.9. Custom QMK firmware? - #14 by MJ1
fl16-v0.2.8-prep
That is why I used the branch that the 0.29 tag points to.
I’m not sure what changes there has been since fl16-v0.2.8-prep, but I’d assume it’s not exactly the same as the v0.2.9 release.
Here is v0.2.9 github.com/FrameworkComputer/qmk_firmware/tree/v0.2.9
I guess there might not be any changes between fl16-v0.2.8-prep and v0.2.9?
I’ll
double check, but 9388622 seems to be in the commit history
I think you’re right. Sorry. They do seem identical.
I banged out a macropad .json. This is for Build support 1 - Create JSON - Vial
/keyboards/framework/macropad/keymaps/vial/vial.json
{
"name": "Framework Laptop 16 RGB Macropad",
"vendorId": "0x32AC",
"productId": "0x0013",
"lighting": "vialrgb",
"matrix": {
"rows": 4,
"cols": 8
},
"layouts": {
"keymap": [
[
{
"h": 0.75
},
"2,1",
{
"x": 0.25,
"h": 0.75
},
"2,2",
{
"x": 0.25,
"h": 0.75
},
"3,4",
{
"x": 0.25,
"h": 0.75
},
"2,4"
],
[
{
"h": 1.25
},
"0,0",
{
"x": 0.25,
"h": 1.25
},
"0,4",
{
"x": 0.25,
"h": 1.25
},
"1,1",
{
"x": 0.25,
"h": 1.25
},
"1,6"
],
[
{
"y": 0.5,
"h": 1.25
},
"0,1",
{
"x": 0.25,
"h": 1.25
},
"0,5",
{
"x": 0.25,
"h": 1.25
},
"1,2",
{
"x": 0.25,
"h": 1.25
},
"2,5"
],
[
{
"y": 0.5,
"h": 1.25
},
"0,2",
{
"x": 0.25,
"h": 1.25
},
"0,6",
{
"x": 0.25,
"h": 1.25
},
"1,3",
{
"x": 0.25,
"h": 1.25
},
"1,7"
],
[
{
"y": 0.5,
"h": 1.25
},
"0,3",
{
"x": 0.25,
"h": 1.25
},
"0,7",
{
"x": 0.25,
"h": 1.25
},
"1,4",
{
"x": 0.25,
"h": 1.25
},
"2,6"
],
[
{
"y": 0.5,
"h": 1.25
},
"1,0",
{
"x": 0.25,
"h": 1.25
},
"2,7",
{
"x": 0.25,
"h": 1.25
},
"1,5",
{
"x": 0.25,
"h": 1.25
},
"2,0"
]
]
}
}
Here it is tested with File > Load dummy JSON...
Here is a macropad Vial config.h (untested).
/keyboards/framework/macropad/keymaps/vial/config.h
/* SPDX-License-Identifier: GPL-2.0-or-later */
#pragma once
#define VIAL_KEYBOARD_UID {0xD8, 0xE7, 0xC9, 0x76, 0x08, 0x89, 0x28, 0x14}
/* Set Vial unlock key combo */
// top left key: 3,2, plus top right key: 3,5
#define VIAL_UNLOCK_COMBO_ROWS { 3, 3 }
#define VIAL_UNLOCK_COMBO_COLS { 2, 5 }
/* Increase layer & macro counts for Vial */
#define DYNAMIC_KEYMAP_LAYER_COUNT 8 // default is 4
#define DYNAMIC_KEYMAP_MACRO_COUNT 32 // default is 16?
And here is a macropad Vial rules.mk (untested).
I am not sure if RGB_MATRIX_DRIVER needs to be defined here.
/keyboards/framework/macropad/keymaps/vial/rules.mk
# MCU name #
MCU = RP2040
BOOTLOADER = rp2040
# Vial options #
VIA_ENABLE = yes # needed for Vial
VIAL_ENABLE = yes
#VIAL_INSECURE = yes # Disable Vial's secure unlock combo. Locked options: changing macros, reboot to bootloader menu option, Assigning RESET keycode
# RGB matrix #
RGB_MATRIX_ENABLE = yes
VIALRGB_ENABLE = yes
For the vial keymap, just copy over the default macropad one, as they say get.vial.today/docs/porting-to-vial.html#2-create-a-new-vial-keymap
And I think that should be it.
I suspect you’re going to have some issues compiling, as I think (at the least) there were some significant changes to naming for the RGB controllers. Hope you can work through them, though – an up-to-date version of the code base would be helpful for other reasons as well!
They just made the drivers lowercase, just swapping it out to lowercase fixed that issue.
I just need to figure out the quantum.c issues now.
Well, it compiled… Checking if it works…
Uhhh, actually what happens if I bork this? What is the recovery method???