vial-kb / vial-qmk Goto Github PK
View Code? Open in Web Editor NEWQMK fork with Vial-specific features.
Home Page: https://get.vial.today/
License: GNU General Public License v2.0
QMK fork with Vial-specific features.
Home Page: https://get.vial.today/
License: GNU General Public License v2.0
The joystick moves the cursor with true analog input with the Vial firmware flashed, but the mouse button presses do not register even after mapped to the Libra Mini in Vial.
On arch (and maybe some other rolling release distros) the current version of gcc is 12.1, and there's a bug ( https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105523 ) which results in a bunch of error: array subscript 0 is outside array bounds of ...
here and there. The problem is solved in the main qmk_firmware repo with 3 new lines of code in platforms/avr/platform.mk
.
Basically, it'd be geat if you reflect the changes made with the following pull request:
And for now those who have the same problem can just go to the files section and copy-paste those 3 lines in the corresponding file.
These keymaps are currently failing to build on merge-2023-06-03
. If we cannot fix them before the next merge (~2 weeks) they will be deleted from vial-qmk.
handwired/3dpcb
@jkutianskipassword
@ll3macornakb/vero
@rachmansyahbshandwired/prkl30
@CountKeepohineybush/h60
@WrinkleKrinklesilumkb/primus75
@cebby2420keychron/q7/ansi
@adophoxiaplanck/rev6_drop
@dijidijistudiokestra/galatea
@WrinkleKrinklesSee https://github.com/vial-kb/vial-qmk/actions/runs/5305999907
QMK merged some improvements for the joystick implementation in January: qmk/qmk_firmware#19052
This changed some variables which makes it harder to maintain configurations for qmk and qmk-vial.
Because of these changes following current QMK documentation on how to implement joysticks does not work with Vial any more and will result in failed builds and there is no Vial-specific documentation describing the current implementation in vial. This currently makes it harder to port new devices with Joysticks or analog inputs to Vial.
Here is a summary of improvements copied from the original pull requests:
Is it possible to merge these changes in Vial?
I'm facing a strange behavior on my sofle keyboard. I have enabled RGBLIGHT_LAYERS_OVERRIDE_RGB_OFF, so RGB turns ON for layers when the RGB is OFF.
This is my config.h regarding RGBLIGHT
#ifdef RGBLIGHT_ENABLE
#define RGBLIGHT_SLEEP /* If defined, the RGB lighting will be switched off when the host goes to sleep */
#define RGBLIGHT_LAYERS
#define RGBLIGHT_MAX_LAYERS 4
#define RGBLIGHT_LAYERS_OVERRIDE_RGB_OFF
#define RGBLIGHT_LAYERS_RETAIN_VAL
#define RGB_DI_PIN D3
#define RGBLED_NUM 72
#define RGBLIGHT_LIMIT_VAL 150
#define RGB_SPLIT {36,36}
#define SPLIT_TRANSPORT_MIRROR
#define RGBLIGHT_SPLIT
#define RGBLIGHT_EFFECT_RGB_TEST
#define RGBLIGHT_DEFAULT_HUE 180
#define RGBLIGHT_HUE_STEP 10
#define RGBLIGHT_SAT_STEP 10
#define RGBLIGHT_VAL_STEP 10
#endif
This is my rules.mk
MCU = atmega32u4
BOOTLOADER = halfkay
OLED_ENABLE = yes
OLED_DRIVER = SSD1306
ENCODER_ENABLE = yes
ENCODER_MAP_ENABLE = yes
VIA_ENABLE = yes
VIAL_ENABLE = yes
RGBLIGHT_ENABLE = yes # Enable WS2812 RGB underlight/underglow
SPLIT_KEYBOARD = yes
WPM_ENABLE = yes
EXTRAKEY_ENABLE = yes # Audio control and System control
LTO_ENABLE = yes
VIAL_INSECURE = yes
MOUSEKEY_ENABLE = yes # Mouse keys
# SPLIT_TRANSPORT = custom
QMK_SETTINGS = no
GRAVE_ESC_ENABLE = no
MAGIC_ENABLE = no
COMBO_ENABLE = no
ONE_SHOT_KEYS_ENABLE = no
AUTO_SHIFT_ENABLE = no
KEY_OVERRIDE_ENABLE = no
COMMAND_ENABLE = no # Commands for debug and configuration
CONSOLE_ENABLE = no # Console for debug
SPACE_CADET_ENABLE = no
MIDI_ENABLE = no
RGB_MATRIX_ENABLE = no
BACKLIGTH_ENABLE = no # Enable keyboard backlight functionality
VERBOSE = no
# Do not enable SLEEP_LED_ENABLE with backligth. it uses the same timer as BACKLIGHT_ENABLE
SLEEP_LED_ENABLE = no # Breathing sleep LED during USB suspend
#BACKLIGHT_DRIVER = pwm
BLUETOOTH_ENABLE = no # Enable Bluetooth
AUDIO_ENABLE = no # Audio output
TAP_DANCE_ENABLE = no
AVR_USE_MINIMAL_PRINTF = yes
The problem is that the RGB only turns ON, on the side where the USB cable is plugged and does not "mirror" to the other side.
Ex: I have USB plugged to the left side (defined as master), RGB OFF. I press a layer key and the light goes ON, but only on the left side, the right side (slave) stays with RGB OFF.
It was supposed to send the same data to the slave, but it just won't turn them ON, but if the leds are ON, then by pressing a layer key, RGB layer leds change color on both sides.
Any ideas on what I am missing??
Never had this error before, with dumbpad (I did MR here) and bento, but it happen for my Feker
refer to this fork commit for the code aad635d
After a recent update the oled stopped working on corne keyboard.
Setting the Value (as in HSV) of Underglow Color currently sets the Underglow Brightness for the entire keyboard (and vice versa).
This behavior prevents the user from setting different brightness/Value for individual LEDs using Lighting Layers, instead forcing the same value for the entire keyboard.
Suggestion: Underglow Brightness should work as an additional multiplier applied to LED brightness/Value instead of setting it directly. This way it would control the overall brightness while preserving the relative difference between LEDs.
I'm using the vial appimage, with an ergohaven k02 keyboard, and am unable to get unicode keycodes.
For reference, on an older keyboard (atreus62), I compile & apply qmk directly. In that keymap.c, I have the following:
void matrix_init_user(){
set_unicode_input_mode(UC_LNX);
};
This enables me to use keycodes which emit unicode, eg: UC(0x03bb) gives "λ".
How do I configure this with vial?
Thanks in advance :)
Build the code for a 3x3 macropad that uses a raspberry pi pico as MCU fails. To make sure it was not caused by my code I also tried to build vial_example/vial_rp2040:vial but that fails with the same errors.
The following error shows up several times:
./lib/pico-sdk/src/rp2_common/pico_bootrom/include/pico/bootrom.h:120:59: error: array subscript 0 is outside array bounds of 'uint16_t[0]' {aka 'short unsigned int[]'} [-Werror=array-bounds]
120 | #define rom_hword_as_ptr(rom_address) (void *)(uintptr_t)(*(uint16_t *)rom_address)
| ~^~~~~~~~~~~~~~~~~~~~~~~~~
./lib/pico-sdk/src/rp2_common/pico_bootrom/include/pico/bootrom.h:130:41: note: in expansion of macro 'rom_hword_as_ptr'
130 | uint16_t *func_table = (uint16_t *) rom_hword_as_ptr(0x14);
| ^~~~~~~~~~~~~~~~
Keyboard: vial_example/vial_rp2040:vial
Revision (if applicable): -
Operating system: manjaro linux (archlinux based)
qmk doctor
output:
~/repos/vial-qmk (ijskegel =) > qmk doctor
Ψ QMK Doctor is checking your environment.
Ψ CLI version: 1.1.1
Ψ QMK home: /home/patrick/repos/vial-qmk
Ψ Detected Linux.
Ψ Git branch: ijskegel
⚠ The official repository does not seem to be configured as git remote "upstream".
Ψ All dependencies are installed.
Ψ Found arm-none-eabi-gcc version 12.2.0
Ψ Found avr-gcc version 8.5.0
Ψ Found avrdude version 7.0
Ψ Found dfu-util version 0.11
Ψ Found dfu-programmer version 0.7.2
Ψ Submodules are up to date.
Ψ Submodule status:
Ψ - lib/chibios: 2022-06-11 09:09:45 +0000 -- (f836d24b0)
Ψ - lib/chibios-contrib: 2022-07-27 10:46:15 +0200 -- (d03aa9cc)
Ψ - lib/googletest: 2021-06-11 06:37:43 -0700 -- (e2239ee6)
Ψ - lib/lufa: 2022-08-26 12:09:55 +1000 -- (549b97320)
Ψ - lib/pico-sdk: 2022-05-17 19:19:01 +0200 -- (07edde8)
Ψ - lib/printf: 2022-06-29 23:59:58 +0300 -- (c2e3b4e)
Ψ - lib/vusb: 2022-06-13 09:18:17 +1000 -- (819dbc1)
Ψ QMK is ready to go, but minor problems were found
Any keyboard related software installed?
no
Updating to the same lib/pico-sdk submodule version as used in qmk solves the issue.
This works for me:
cd lib/pico-sdk
git checkout 8d56ea332b3734cef0a8e61f7d61f2422bd539b1
cd ../..
make vial_example/vial_rp2040:vial
Can't the knob switch layers? For example setting TO(1) output is N TO(2) output is O. The buttons are used to switch layers normally, the knobs cannot
As per site docs I should see Tap dance
and `QMK settings tabs but none of them are present.
Keyboard: Sofle
Revision (if applicable):V2
Operating system: MacOSX
qmk doctor
output:
(Paste output here)
Any keyboard related software installed?
Keyboard:
Revision (if applicable):
Operating system:
qmk doctor
output:
(Paste output here)
Any keyboard related software installed?
I made a homemade ATmega32U4 MCU keyboard and recently added a CAT24C512 EEPROM ( used with previous OLEDs on the I2C bus ) to expand the functionality of Macros.
But after rebuilding the firmware, it was found that the keyboard was unusable.
After multiple attempts, I found that OLED and eeprom functions seem to be still normal,
But the preset key layers and values will switch quickly and randomly, and the RGB function will no longer be available.
At this point, if the key value is pressed, the entire keyboard will immediately hang without any response.
I used the exclusion method to uninstall all the separable functions one by one, and finally found out that it was Vial's problem.
Vial caused the keyboard to go crazy after enabling Combos and Key Overrides functions.
After completely disabling these two functions, eeprom, oled, RGB, and the remaining button functions can all be used normally.
Since the last merge of upstream QMK, VIA and Vial JSON files have been added to the gitignore.
Line 99 in d399418
git add vial.json -f
Can we remove this line from the gitignore to make our lives easier?
In the current source, vial tap dance is handled by reading ROM directly to fetch its data. Would it be faster, easier to customize (code wise) and less taxing on the eeprom if:
Vial cannot save the selected qmk rgb lighting effect? After re-plugging and unplugging, it turns red again.
Just started using this on a new keyboard, and after 15 macros there is no way to add more.
I'm not sure if this is already something someone is working on, but I was hoping to use more macros than that - like 40+ for CLI command shortcuts.
Similar story with layers, I was hoping to have 4 or 5 layers just for those commands shortcuts and then other ones for symbols and normal things like that.
With QMK I could write unlimited macros and layers, even with configurator you would get 15 layers, and some of the settings in vial refer to those additional layers, so maybe I'm just missing a way to pass that to the vial GUI, or some backdoor that goes around the GUI.
Don't know if there's a quick fix for this or not or if this is expected behaviour
my goal here was to use layers as a means to change my overrides on my key combos, but what I found was all key combos seem to live in layer 0, so when going into the key override menu you need to enable the overrides for layer 0 even if the combo is being triggered on layer x
Really appreciate any comments or thoughts on this issue
Is following behavior of tap-hold is correct?
E.g.) normaly alt, shift on tap_hold.
|<--tapping term-->|
alt __|‾|___|‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾
'a' ______________|‾|________|‾|___
'a' 'A'
If it's not the intention, I think it's better and natural behavior to fix this part as follows:
if (state->pressed) return DOUBLE_HOLD;
else if (state->interrupted) return DOUBLE_SINGLE_TAP;
else return DOUBLE_TAP;
After flashing the keyboard with the firmware vial, the displays stay off when switching on.
A locked keyboard does not offer many of the immediately assumable security benefits of what seems to be advertised. When you come into VIAL and hear that you can lock your keyboard from modifications, that sounds great and dandy. My primary concern is silent matrix readout by an application that can talk to the keyboard over RAWHID. In reality this could extend to anything including Slack talking to your keyboard, and reading out its matrix. From reading out a keyboards matrix, you can start to assume some key placement, and start extracting messages, passwords, etc.
When VIAL keyboards are "locked" the matrix is still able to be read out, macros are able to be deleted, key maps are able to be changed.
This exposes you to silent keylogging from applications, and breaking keyboard functionality by a program that decides to overwrite all your layers.
Perhaps this has not been done in practice but nothing is stopping a program from doing something like this, and having the lock function actually lock the keyboard configuration would make a lot of sense.
What locking a keyboard should do, or at least allow us to toggle as an option, is restrict the matrix being read out to the pc to output only the keys defined in VIAL_UNLOCK_COMBO_ROWS and VIAL_UNLOCK_COMBO_COLS. While the keyboard is locked VIAL should also prevent writing to the keymap, or deleting macros.
You may say "but vial cannot read the matrix when the keyboard is locked"
Sure. But via can. https://usevia.app/#/
First time I flash vial firmware, compiled with default settings, which include security feature. Now I played with my custom keyboard settings and try to flash it again via qmk, but controller is not writable, even if I boot to bootloader via vial application.
I use crkbd/rev1 split keyboard and this setup require to flash firmware for both splits.
I need more detailed instruction for split keyboards
$ qmk flash -kb crkbd/rev1 -km crandel
Ψ Compiling keymap with make --jobs=1 crkbd/rev1:crandel:flash
Making crkbd/rev1 with keymap crandel and target flash
avr-gcc (GCC) 12.2.0
Copyright (C) 2022 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Size before:
text data bss dec hex filename
0 26098 0 26098 65f2 crkbd_rev1_crandel.hex
Compiling: quantum/via.c [OK]
Linking: .build/crkbd_rev1_crandel.elf [OK]
Creating load file for flashing: .build/crkbd_rev1_crandel.hex [OK]
Copying crkbd_rev1_crandel.hex to qmk_firmware folder [OK]
Checking file size of crkbd_rev1_crandel.hex [OK]
* The firmware size is fine - 26098/28672 (91%, 2574 bytes free)
Waiting for USB serial port - reset your controller now (Ctrl+C to cancel)...................................
Device /dev/ttyACM1 has appeared; assuming it is the controller.
Waiting for /dev/ttyACM1 to become writable....................
Keyboard: crkbd
Revision (if applicable): rev1
Operating system: Arch Linux
qmk doctor
output:
$ qmk doctor
Ψ QMK Doctor is checking your environment.
Ψ CLI version: 1.1.1
Ψ QMK home: /data/vial-qmk
Ψ Detected Linux.
Ψ Git branch: vial
Ψ All dependencies are installed.
Ψ Found arm-none-eabi-gcc version 12.2.0
Ψ Found avr-gcc version 12.2.0
⚠ We do not recommend avr-gcc newer than 8. Downgrading to 8.x is recommended.
Ψ Found avrdude version 7.0
Ψ Found dfu-util version 0.11
Ψ Found dfu-programmer version 0.7.2
Ψ Submodules are up to date.
Ψ Submodule status:
Ψ - lib/chibios: 2022-06-11 09:09:45 +0000 -- (f836d24b0)
Ψ - lib/chibios-contrib: 2022-07-27 10:46:15 +0200 -- (d03aa9cc)
Ψ - lib/googletest: 2021-06-11 06:37:43 -0700 -- (e2239ee6)
Ψ - lib/lufa: 2022-08-26 12:09:55 +1000 -- (549b97320)
Ψ - lib/pico-sdk: 2022-05-17 19:19:01 +0200 -- (07edde8)
Ψ - lib/printf: 2022-06-29 23:59:58 +0300 -- (c2e3b4e)
Ψ - lib/vusb: 2022-06-13 09:18:17 +1000 -- (819dbc1)
Ψ QMK is ready to go, but minor problems were found
Any keyboard related software installed?
Hi, if I select another keyboard layout then QWERTY (german in my case) the keyboard layout itself does work fully as expected. Other features, like Space Cadet Shift, Ctrl. etc. dont work as expected. In german layout the ( )
change to 8
and 9
, so LCtrtl
goes to )
. Is it possible to fix that? I tried to set a any
keycode with LCtl_T
but cant enter multiple keycodes then.
when trying to compile custom firmware from QMK with or without vial specific keymaps it is unable to compile due to errors with platforms/chibios/drivers/wear_leveling/wear_leveling_rp2040_flash.c
Keyboard: WeAct RP2040 microcontroller
Operating system: Debian Sid
qmk doctor
output:
Ψ QMK Doctor is checking your environment.
Ψ CLI version: 1.1.1
Ψ QMK home: /home/rus/vial-qmk
Ψ Detected Linux.
⚠ Missing or outdated udev rules for 'atmel-dfu' boards. Run 'sudo cp /home/rus/vial-qmk/util/udev/50-qmk.rules /etc/udev/rules.d/'.
⚠ Missing or outdated udev rules for 'kiibohd' boards. Run 'sudo cp /home/rus/vial-qmk/util/udev/50-qmk.rules /etc/udev/rules.d/'.
⚠ Missing or outdated udev rules for 'stm32-dfu' boards. Run 'sudo cp /home/rus/vial-qmk/util/udev/50-qmk.rules /etc/udev/rules.d/'.
⚠ Missing or outdated udev rules for 'apm32-dfu' boards. Run 'sudo cp /home/rus/vial-qmk/util/udev/50-qmk.rules /etc/udev/rules.d/'.
⚠ Missing or outdated udev rules for 'gd32v-dfu' boards. Run 'sudo cp /home/rus/vial-qmk/util/udev/50-qmk.rules /etc/udev/rules.d/'.
⚠ Missing or outdated udev rules for 'bootloadhid' boards. Run 'sudo cp /home/rus/vial-qmk/util/udev/50-qmk.rules /etc/udev/rules.d/'.
⚠ Missing or outdated udev rules for 'usbasploader' boards. Run 'sudo cp /home/rus/vial-qmk/util/udev/50-qmk.rules /etc/udev/rules.d/'.
⚠ Missing or outdated udev rules for 'usbtinyisp' boards. Run 'sudo cp /home/rus/vial-qmk/util/udev/50-qmk.rules /etc/udev/rules.d/'.
⚠ Missing or outdated udev rules for 'md-boot' boards. Run 'sudo cp /home/rus/vial-qmk/util/udev/50-qmk.rules /etc/udev/rules.d/'.
⚠ Detected ModemManager without the necessary udev rules. Please either disable it or set the appropriate udev rules if you are using a Pro Micro.
⚠ Missing or outdated udev rules for 'caterina' boards. Run 'sudo cp /home/rus/vial-qmk/util/udev/50-qmk.rules /etc/udev/rules.d/'.
⚠ Missing or outdated udev rules for 'hid-bootloader' boards. Run 'sudo cp /home/rus/vial-qmk/util/udev/50-qmk.rules /etc/udev/rules.d/'.
Ψ Git branch: vial
⚠ Git has unstashed/uncommitted changes.
⚠ The official repository does not seem to be configured as git remote "upstream".
Ψ All dependencies are installed.
Ψ Found arm-none-eabi-gcc version 12.2.1
Ψ Found avr-gcc version 5.4.0
Ψ Found avrdude version 6.3-20171130
Ψ Found dfu-util version 0.11
Ψ Found dfu-programmer version 0.6.1
Ψ Submodules are up to date.
Ψ Submodule status:
Ψ - lib/chibios: 2022-06-11 09:09:45 +0000 -- (f836d24b0)
Ψ - lib/chibios-contrib: 2022-07-27 10:46:15 +0200 -- (d03aa9cc)
Ψ - lib/googletest: 2021-06-11 06:37:43 -0700 -- (e2239ee6)
Ψ - lib/lufa: 2022-08-26 12:09:55 +1000 -- (549b97320)
Ψ - lib/pico-sdk: 2022-05-17 19:19:01 +0200 -- (07edde8)
Ψ - lib/printf: 2022-06-29 23:59:58 +0300 -- (c2e3b4e)
Ψ - lib/vusb: 2022-06-13 09:18:17 +1000 -- (819dbc1)
Ψ QMK is ready to go, but minor problems were found
Any keyboard related software installed?
NO
Making domovoyalex/ergodos with keymap vial
arm-none-eabi-gcc (15:12.2.rel1-1) 12.2.1 20221205
Copyright (C) 2022 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Compiling: .build/obj_domovoyalex_ergodos/src/default_keyboard.c [OK]
Compiling: quantum/keymap_introspection.c [OK]
Compiling: quantum/quantum.c [OK]
Compiling: quantum/bitwise.c [OK]
Compiling: quantum/led.c [OK]
Compiling: quantum/action.c [OK]
Compiling: quantum/action_layer.c [OK]
Compiling: quantum/action_tapping.c [OK]
Compiling: quantum/action_util.c [OK]
Compiling: quantum/eeconfig.c [OK]
Compiling: quantum/keyboard.c [OK]
Compiling: quantum/keymap_common.c [OK]
Compiling: quantum/keycode_config.c [OK]
Compiling: quantum/sync_timer.c [OK]
Compiling: quantum/logging/debug.c [OK]
Compiling: quantum/logging/sendchar.c [OK]
Compiling: quantum/logging/print.c [OK]
Compiling: quantum/bootmagic/bootmagic_lite.c [OK]
Compiling: quantum/bootmagic/magic.c [OK]
Compiling: quantum/matrix_common.c [OK]
Compiling: quantum/matrix.c [OK]
Compiling: quantum/debounce/sym_defer_g.c [OK]
Compiling: quantum/main.c [OK]
Compiling: lib/printf/src/printf/printf.c [OK]
Compiling: quantum/mousekey.c [OK]
Compiling: drivers/eeprom/eeprom_driver.c [OK]
Compiling: drivers/eeprom/eeprom_wear_leveling.c [OK]
Compiling: quantum/wear_leveling/wear_leveling.c [OK]
Compiling: platforms/chibios/drivers/wear_leveling/wear_leveling_rp2040_flash.c In file included from platforms/chibios/drivers/wear_leveling/wear_leveling_rp2040_flash.c:9:
In function 'rom_func_lookup_inline',
inlined from 'pico_program_bulk' at platforms/chibios/drivers/wear_leveling/wear_leveling_rp2040_flash.c:129:91:
./lib/pico-sdk/src/rp2_common/pico_bootrom/include/pico/bootrom.h:120:59: error: array subscript 0 is outside array bounds of 'uint16_t[0]' {aka 'short unsigned int[]'} [-Werror=array-bounds]
120 | #define rom_hword_as_ptr(rom_address) (void *)(uintptr_t)(*(uint16_t *)rom_address)
| ~^~~~~~~~~~~~~~~~~~~~~~~~~
./lib/pico-sdk/src/rp2_common/pico_bootrom/include/pico/bootrom.h:129:66: note: in expansion of macro 'rom_hword_as_ptr'
129 | rom_table_lookup_fn rom_table_lookup = (rom_table_lookup_fn) rom_hword_as_ptr(0x18);
| ^~~~~~~~~~~~~~~~
./lib/pico-sdk/src/rp2_common/pico_bootrom/include/pico/bootrom.h:120:59: error: array subscript 0 is outside array bounds of 'uint16_t[0]' {aka 'short unsigned int[]'} [-Werror=array-bounds]
120 | #define rom_hword_as_ptr(rom_address) (void *)(uintptr_t)(*(uint16_t *)rom_address)
| ~^~~~~~~~~~~~~~~~~~~~~~~~~
./lib/pico-sdk/src/rp2_common/pico_bootrom/include/pico/bootrom.h:130:41: note: in expansion of macro 'rom_hword_as_ptr'
130 | uint16_t *func_table = (uint16_t *) rom_hword_as_ptr(0x14);
| ^~~~~~~~~~~~~~~~
In function 'rom_func_lookup_inline',
inlined from 'pico_program_bulk' at platforms/chibios/drivers/wear_leveling/wear_leveling_rp2040_flash.c:130:83:
./lib/pico-sdk/src/rp2_common/pico_bootrom/include/pico/bootrom.h:120:59: error: array subscript 0 is outside array bounds of 'uint16_t[0]' {aka 'short unsigned int[]'} [-Werror=array-bounds]
120 | #define rom_hword_as_ptr(rom_address) (void *)(uintptr_t)(*(uint16_t *)rom_address)
| ~^~~~~~~~~~~~~~~~~~~~~~~~~
./lib/pico-sdk/src/rp2_common/pico_bootrom/include/pico/bootrom.h:129:66: note: in expansion of macro 'rom_hword_as_ptr'
129 | rom_table_lookup_fn rom_table_lookup = (rom_table_lookup_fn) rom_hword_as_ptr(0x18);
| ^~~~~~~~~~~~~~~~
./lib/pico-sdk/src/rp2_common/pico_bootrom/include/pico/bootrom.h:120:59: error: array subscript 0 is outside array bounds of 'uint16_t[0]' {aka 'short unsigned int[]'} [-Werror=array-bounds]
120 | #define rom_hword_as_ptr(rom_address) (void *)(uintptr_t)(*(uint16_t *)rom_address)
| ~^~~~~~~~~~~~~~~~~~~~~~~~~
./lib/pico-sdk/src/rp2_common/pico_bootrom/include/pico/bootrom.h:130:41: note: in expansion of macro 'rom_hword_as_ptr'
130 | uint16_t *func_table = (uint16_t *) rom_hword_as_ptr(0x14);
| ^~~~~~~~~~~~~~~~
In function 'rom_func_lookup_inline',
inlined from 'pico_program_bulk' at platforms/chibios/drivers/wear_leveling/wear_leveling_rp2040_flash.c:131:86:
./lib/pico-sdk/src/rp2_common/pico_bootrom/include/pico/bootrom.h:120:59: error: array subscript 0 is outside array bounds of 'uint16_t[0]' {aka 'short unsigned int[]'} [-Werror=array-bounds]
120 | #define rom_hword_as_ptr(rom_address) (void *)(uintptr_t)(*(uint16_t *)rom_address)
| ~^~~~~~~~~~~~~~~~~~~~~~~~~
./lib/pico-sdk/src/rp2_common/pico_bootrom/include/pico/bootrom.h:129:66: note: in expansion of macro 'rom_hword_as_ptr'
129 | rom_table_lookup_fn rom_table_lookup = (rom_table_lookup_fn) rom_hword_as_ptr(0x18);
| ^~~~~~~~~~~~~~~~
./lib/pico-sdk/src/rp2_common/pico_bootrom/include/pico/bootrom.h:120:59: error: array subscript 0 is outside array bounds of 'uint16_t[0]' {aka 'short unsigned int[]'} [-Werror=array-bounds]
120 | #define rom_hword_as_ptr(rom_address) (void *)(uintptr_t)(*(uint16_t *)rom_address)
| ~^~~~~~~~~~~~~~~~~~~~~~~~~
./lib/pico-sdk/src/rp2_common/pico_bootrom/include/pico/bootrom.h:130:41: note: in expansion of macro 'rom_hword_as_ptr'
130 | uint16_t *func_table = (uint16_t *) rom_hword_as_ptr(0x14);
| ^~~~~~~~~~~~~~~~
cc1: all warnings being treated as errors
[ERRORS]
|
|
|
make[1]: *** [builddefs/common_rules.mk:362: .build/obj_domovoyalex_ergodos_vial/wear_leveling_rp2040_flash.o] Error 1
Make finished with errors
make: *** [Makefile:414: domovoyalex/ergodos:vial] Error 1
using keymap : https://github.com/linkpy/vial-qmk/tree/vial/keyboards/splitkb/aurora/sofle_v2/keymaps/vial
i enabled rgb matrix animations and for example for the reactive solid splash one, pressing a key on the right hand will make the splash animation propagate to the left hand, but not the other way around: the animation doesnt propagate to the right hand when i press a key on the left hand.
to reproduice
example :
(note: in this video the left hand doesnt have backlight leds but only underglow one)
The keychron K2 V2 is supported by the sonixQMK branch, please add support for this keyboard in Vial.
The Keychron K2/K2V2 is supported on the SonixQMK branch and is also supported on VIA from their branch, Vial works for keymapping and macro with the via sideload option, but no RGB control. I'm open to provide any help needed as I own this specific keyboard.
I have a cidooo's V87pro
I want to use tab dance
Unfortunately, however, via does not support that feature, but only vial.
So I'm going to flash with vial.
I prepared these three files, but there are errors.
how can I comfile and use vial?
No response
No response
No response
No response
No response
No response
No response
The Libra Mini definition in Vial expects productId 0x4C24, but currently-shipping boards have productId 0x4C23. The existing definition is otherwise fully compatible with 0x4C23 boards.
Keyboard: Libra Mini
Revision (if applicable): 0x4C23 putative rev. 2
Operating system: n/a
qmk doctor
output: n/a
Any keyboard related software installed?
n/a
Files currently working with 0x4C23 boards: https://gist.github.com/sehrgut/622edc0f0e3a75bcff367c4cff2a436a
using keymap : https://github.com/linkpy/vial-qmk/tree/vial/keyboards/splitkb/aurora/sofle_v2/keymaps/vial
with qmk settings enabled, changing tapping term doesnt do anything (even setting it to a very high value like 1000ms doesnt seem to have any impact on the actual tap-hold behaviours).
i only tested this with LT_n keys.
to reproduice :
Please forgive me if I'm doing something obvious wrong.
I'm compiling vial-enabled QMK for my Avalanche v4 keyboard, and I've been following the guide here.
I am using a Pro Micro mcu with 28627 bytes of program memory available. My initial compilation was over 40k.
After turning off all optional Vial features, and enabling LTO, the resulting hex file is still too big:
* The firmware is too large! 30352/28672 (1680 bytes over)
My keymaps/vial/rules.mk
file:
VIA_ENABLE = yes VIAL_ENABLE = yes RGBLIGHT_ENABLE = yes ENCODER_MAP_ENABLE = yes LTO_ENABLE = yes QMK_SETTINGS = no TAP_DANCE_ENABLE = no COMBO_ENABLE = no KEY_OVERRIDE_ENABLE = no
My keymaps/vial/rules.mk
file:
#pragma once #define VIAL_KEYBOARD_UID {0x23, 0x3D, 0x32, 0xDD, 0xC0, 0x95, 0x33, 0xF4} #define VIAL_UNLOCK_COMBO_ROWS { 0, 1 } #define VIAL_UNLOCK_COMBO_COLS { 0, 5 } #define VIAL_COMBO_ENTRIES 1 #define VIAL_KEY_OVERRIDE_ENTRIES 1 #define DYNAMIC_KEYMAP_LAYER_COUNT 1
Is it because I'm using ENCODER_MAP? Or due to RGBLIGHT_ENABLE?
when i set a combos that input is W+LALT and output is an anykey LALT(KC_UP), it should ouput ALT+UP, but it output that ALT+UP, UP.
Keyboard:
Revision (if applicable):
Operating system:
qmk doctor
output:
(Paste output here)
Any keyboard related software installed?
Some keyboards have been moved to different folders in upstream QMK and this change hasn't been reflect in vial-qmk yet.
Write raw code in keymap.c
#ifdef RAW_ENABLE
void raw_hid_receive(uint8_t *data, uint8_t length) {
if (data[0] == 1) {
// default_layer_set(data[1]);
layer_move(data[1]);
}
raw_hid_send(data, length);
}
#endif
When i run qmk compile -kb crkbd -km vial
, and disable via and vial, It works well.
#VIA_ENABLE = yes
#VIAL_ENABLE = yes
But When i enable via and vial. It works error.
VIA_ENABLE = yes
VIAL_ENABLE = yes
error information:
Size before:
text data bss dec hex filename
0 25414 0 25414 6346 crkbd_rev1_vial.hex
Compiling: quantum/keymap_introspection.c [OK]
Compiling: quantum/via.c [OK]
Linking: .build/crkbd_rev1_vial.elf [ERRORS]
|
| d:/app/keyboard/qmk_msys/qmk_msys/mingw64/bin/../lib/gcc/avr/8.5.0/../../../../avr/bin/ld.exe: .build/obj_crkbd_rev1_vial/quantum/via.o (symbol from plugin): in function `via_eeprom_is_valid':
| (.text+0x0): multiple definition of `raw_hid_receive'; .build/obj_crkbd_rev1_vial/quantum/keymap_introspection.o (symbol from plugin):(.text+0x0): first defined here
| collect2.exe: error: ld returned 1 exit status
|
make[1]: *** [builddefs/common_rules.mk:271:.build/crkbd_rev1_vial.elf] 错误 1
Make finished with errors
make: *** [Makefile:392:crkbd/rev1:vial] 错误 1
Is raw and via incompatible?
If TO(XX) exceeds 16 floors, an error will occur. For example, if 32 floors are enabled by config, if TO(0) is selected in vial, the actual output is TO(16), TO(1) is TO(17)...There is no within 16 floors this mistake
I set wpm_enable = yes in my rule.mk,but get_current_wpm() is always 0, in old version is good working, is something change for vial-qmk broken it up?
I'm using KDE Neon (Ubuntu-based), and I'm unable to sleep the PC while the VIAL-programmed keyboard is plugged into USB.
Currently to support vial with a keyboard the following needs to be done
What would be nice to have is to be able to add a keyboard variant that contains both the vial.json and config.h.
For example currently when you've got 2 keymaps supporting VIAL it look like this.
This would require the vial.json and config.h to be created 2 times
keyboards/ ├─ pieterv24/ │ ├─ testboard/ │ │ ├─ keymaps/ │ │ │ ├─ default/ │ │ │ │ ├─ keymap.c │ │ │ ├─ pieterv24/ │ │ │ │ ├─ config.h │ │ │ │ ├─ keymap.c │ │ │ │ ├─ rules.mk │ │ │ │ ├─ vial.json │ │ │ ├─ vial/ │ │ │ │ ├─ keymap.c │ │ │ │ ├─ rules.mk │ │ │ │ ├─ vial.json │ │ │ │ ├─ config.h │ │ ├─ config.h │ │ ├─ info.json │ │ ├─ readme.md │ │ ├─ rules.mk │ │ ├─ testboard.c │ │ ├─ testboard.h
My proposal would be to allow the following
keyboards/ ├─ pieterv24/ │ ├─ testboard/ │ │ ├─ keymaps/ │ │ │ ├─ default/ │ │ │ │ ├─ keymap.c │ │ │ ├─ pieterv24/ │ │ │ │ ├─ keymap.c │ │ │ │ ├─ rules.mk │ │ ├─ vial/ │ │ │ ├─ vial.json │ │ │ ├─ config.h │ │ ├─ readme.md │ │ ├─ rules.mk │ │ ├─ testboard.c │ │ ├─ testboard.h
In this configuration the idea would be that you could compile each keymap as a vial compatible keymap.
For example like this:
make pieterv24/testboard/vial:default
make pieterv24/testboard/vial:pieterv24
or without vial like:
make pieterv24/testboard:default
make pieterv24/testboard:pieterv24
The README.md is still from QMK. Changing it to talk about Vial, and link to Vial resources, would help folks better understand what your project is, and why your fork is different.
Is there a way to always have the OLED screen always on? Option to adjust timeouts or toggle the screen would be helpful.
Is there a way to have the OLED screen to always be on? Or at least an option to have a timeout or always on?
https://github.com/vial-kb/vial-qmk/tree/vial/keyboards/doio/kb16
add Alt+Gui pairs(left and right versions) in quantum and toggle shift lock key (like LShift and Rshift keys).
Alt+Gui combo keys don't exist. Had to customize those keys to function the way I needed.
I'm utilizing the knobs on my DOIO KB 16 keyboard to navigate to specific areas in text. Then I'd highlight the text with shift, so I can cut/copy/paste whatever it is. Originally I made it so that it'd always highlight with shift+arrow keys, but I don't always need things to be highlighted. Would be super convenient if there was a shift toggle function for this reason.
Regarding the shift key toggle, I've looked up and tried for hours in different apps to get the shift key to resemble what I need. Basically I need the Shift key to be press forever, until I press it again to turn it off.
Great job on all the work that has been done. Thank you!
Hi, I found linkage error during creating a pull request for my board(akira-60), and I encounter the same error with other board using the same chip(stm32f042x), the linkage error seems saying there are no enough RAM to fit on the board, but I can compile the board successfully on the qmk/qmk_firmware master.
Linkage Error of the existing board using stm32f042x
Linking: .build/chavdai40_rev1_default.elf [ERRORS]
|
| /usr/local/Cellar/arm-gcc-bin@8/8-2019-q3-update_1/bin/../lib/gcc/arm-none-eabi/8.3.1/../../../../arm-none-eabi/bin/ld:rules_memory.ld:314 cannot move location counter backwards (from 0000000020001da8 to 0000000020001800)
| collect2: error: ld returned 1 exit status
Compliation Result from qmk/qmk_firmware master
Creating binary load file for flashing: .build/ekow_akira_default.bin [OK]
Creating load file for flashing: .build/ekow_akira_default.hex [OK]
Size after:
text data bss dec hex filename
0 21898 0 21898 558a ekow_akira_default.bin
Keyboard: chavdai40/rev1
Revision (if applicable):
Operating system:
qmk doctor
output:
Ψ QMK Doctor is checking your environment.
Ψ CLI version: 1.0.0
Ψ QMK home: /Users/bigtreehouse/model_routine/keyboard/vial-qmk
Ψ Detected macOS 11.4.
⚠ QMK home does not appear to be a Git repository! (no .git folder)
Ψ CLI installed in virtualenv.
Ψ All dependencies are installed.
Ψ Found arm-none-eabi-gcc version 8.3.1
Ψ Found avr-gcc version 8.4.0
Ψ Found avrdude version 6.3
Ψ Found dfu-util version 0.11
Ψ Found dfu-programmer version 0.7.2
Ψ Submodules are up to date.
Ψ QMK is ready to go, but minor problems were found
Any keyboard related software installed?
The leader key function that exists in the QMK main branch implemented inside of Vial
Documentation here: QMK Leader Key
I recently ported the Adelais rev4 PCB to Vial (#408) and I'd like to do the same for the Adelais en ciel Rev3 PCB but I've run into an issue. All the Adelais PCBs (both regular RGB and per key RGB) share the same keymap folder but each requires a unique vial.json file. I wouldn't be able to submit a PR for the Adelais en ciel PCB port without overwriting the vial.json for the other PCB.
I can create the PR and submit if it that would help demonstrate the issue.
I'm not sure how common this is across QMK or if this is a one off.
I have some custom keycodes that change the speed of scrolling. I would like to save the user set speeds to be saved to the EEPROM but it does not look like VIAL has the feature_eeprom in it yet. Is there a different way that this is handled by VIAL?
https://github.com/qmk/qmk_firmware/blob/master/docs/feature_eeprom.md
多个不明确 映射到矩阵位置的,相同的配置 qmk下编译出来编码器可以用,也能via修改,vial-qmk直接编码器无反应不行,已经添加了VIAL_ENCODERS_ENABLE = yes
Multiple encoders that are not explicitly mapped to the matrix position can be used or modified via the encoder compiled under the same configuration qmk. The via qmk direct encoder has no response, and via has been added_ ENCODERS_ ENABLE = yes
I am facing this weird issue in vial where the matrix is not loading.
I was experimenting on a custom layout and got this error, First I thought I made some formatting error.
But after I rolled back to the previous working layout this error kept on popping. I replaced all the project files from vial and still getting this error. Tried reinstalling Vial but still no luck.
Any leads?
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.