flowchartsman wrote: ↑27 May 2022, 21:37
Given that
0x5CDE on the "E" key, maybe that was meant to be
QK_CLEAR_EEPROM (
0x5CDF) instead? Still not clear what would have gone on 'D'. Maybe
QK_DEBUG_TOGGLE (
0x5C01)?
Hmm, much to discuss surrounding the various issues you've brought up...
First, I should point out for y'all's benefit that the latest version of my Vial hex files that I posted only contain the firmware images and nothing else, as it was just a minor update that I was hoping to expose to wider testing. But the
last major update I posted prior to that included a bunch of other stuff in it, like a (primitive) build script, the modified pandrew utility (for Windows...have gotten one built also for MacOS, hoping to post soon), and finally all of Ellipse's QMK keyboard layout JSON files converted over to .vil files for Vial.
So re: your PM to me, the F77 .hex file defaults to standard ANSI format. If you have HHKB or whatever & find some keys aren't working or doing what you expected, you should grab that main Vial archive and load your preferred layout into your keyboard from the corresponding .vil...since the whole point of Vial is to be able to change your layout on-the-fly without subjecting yourself to an entire recompile and reflash loop, I thought this was a more straightforward approach than (IMO) needlessly generating one entire .hex per layout.
Re: the layer 2 D key, it looks like you guessed right: 0x5C01 was what Ellipse had programmed to that key. I haven't messed with QMK debug mode though so not sure what to expect when it's pressed. It might also require CONSOLE_ENABLE to be DEFINEd during QMK build which I don't do for my Vial hexes, because not enough memory and/or available USB endpoints with all of the other features enabled.
(darn you, ATmega32U2...)
By the way, in the future if you ever bork an existing default key assignment, you failed to take note of what it was first, and want to restore it, just save your work-in-progress existing layout to a .vil file & then either wipe the EEPROM (which will restore the default layout built into the firmware) or reload the correct .vil from my large 7zip package. Find the key in question, make a note of what it's mapped to, then reload your saved .vil back into your keyboard and set that key to the "right" value (assuming you care to after you find out what it was).
Finally, you are correct: Fn+Space+E should be EEPROM_ERASE, which is normally 0x5CDF. So I took a look, and it turns out that in my Vial builds, EEPROM_ERASE actually is 0x5CDE. So it still does what it should when you press it, but Vial shows a value for that key that you wouldn't expect (& had it been set to 0x5CDF would *not* have done an EEPROM wipe). This looks to be a VIA bug, and since Vial is built atop the QMK VIA (firmware-side) code, it inherited this bug. Looks like the problem is due to this #ifdef block nested inside the quantum_keycodes enum in quantum_keycodes.h:
Code: Select all
MI_VEL_0, // 5C92
#ifdef VIA_ENABLE
MI_VEL_1 = MI_VEL_0,
#else
MI_VEL_1, // 5C93
#endif
MI_VEL_2, // 5C94
Since VIA_ENABLE causes MI_VEL_1 to = MI_VEL_0 which is 5C92, the numbering within the enum restarts at that point, causing all value assignments past that point to be off by 1. It's possible it has been fixed in later versions; I'd have to check. If not, best explanation is that probably nobody ever noticed since as long as one references either the enum names or C preprocessor constants rather than the raw values, everything still "works", and most people probably just keep their keymap exports to themselves rather than share them, or if they do share them they're likely sharing them with others who are running the same firmware on the same keyboard model that they are, so there would rarely be a problem.
Easy fix is just to make the value of MI_VEL_2 within the enum explicit:
...though of course if I fix this in future builds then I'll have to re-issue new .vils, and anybody loading .vils from either before or after the fix onto the opposite firmware won't have working EEPROM_RESET key (& possibly others!) until they go in and manually redefine them, heh.
Come to think of it...I wonder if this explains past issues with people running Vial & having trouble adjusting their solenoid settings with the Fn shortcuts. The haptic (HPT_xxx) keys would have been affected by this, so if they had loaded on Vial
without clearing their EEPROM, and the key map from the previous firmware actually had the "correct" values for the haptic dwell time toggles in place...hmmmmm...
