F104+SSK+122+62+77+50+Ergo orders now open! New Kishsaver+Industrial Model F Keyboards

[Muirium]

However, using a tap dance to facilitate typing '\' is only a first shot at improvements useful for "TeX" users with non-English layouts. It would be nice, if curly and even square braces could be accessed without having to reach out for "Opt/Alt". This could be achieved with a switchable layer, but due to memory space limitations Vial only offers three layers with new Model F's Atmels.

I've explored that way, too. Years ago, I used to pack a lot of inventive macros and layer action like yours into my programmable controllers. Xwhatsit's original firmware is very nice for this, just a pity about the dodgy single threshold! Eventually, I had 95% or so coverage across all my different controllers and converters:

• Xwhatsit's controller for Kishsaver and Beamspring ← the latter being so flaky I seldom used it
• Soarer's converter for AT keyboards
• Soarer's controller in my own custom
• TMK in my Hasu Bluetooth HHKB

Trouble is: none of this worked for USB native keyboards, or indeed my laptop's built in one! This slapped me on the backside when I bought my M1 Mac and got into using it as a portable again. That's when I gave Karabiner a proper shot, and why I migrated my suite of keyboard customisations there. You can do a lot more on the host, both functionally (app-specific rules, running scripts) and materially (no such memory limits as you mentioned).

The key to mods is to put them everywhere. Easier said than done when you're a DT die-hard with more than just a few keyboards you like to use.

[Bjerrk]

Trouble is: none of this worked for USB native keyboards, or indeed my laptop's built in one! This slapped me on the backside when I bought my M1 Mac and got into using it as a portable again. That's when I gave Karabiner a proper shot, and why I migrated my suite of keyboard customisations there. You can do a lot more on the host, both functionally (app-specific rules, running scripts) and materially (no such memory limits as you mentioned).

That's true, but there is something to be said for the keyboard being a fully-configured device on its own. At least, I enjoy that it has all the nifty configurations, even if I plug it into a new/temporary computer.

Hasu's usb_usb converter is brilliant for this, by the way: makes any USB keyboard behave according to your preferences in an instant And only about 50% of people assume you've plugged a keylogger into the PC ...

[Muirium]

Aye, I was on the 'do it in the keyboard' side of the divide in the past, for sure. This was essential back in the day, as I was running a small fleet of obsolete hardware as my hosts! Karabiner on PowerPC? Not likely! When you're running unsupported OS versions, you're well and truly on your own.

For several years, my HHKB here really was my only keyboard. Once I put in Hasu's Bluetooth controller in 2016 or so, I stayed on that board on all my computers, including the iPad Pro I was using for most of my work. No software options at all on iPad, so I was thankful for TMK and did everything in that. Getting so much time on the same keyboard really opened my eyes to just how powerful consistency is in modification. When you can rely on something always being there, you use it hard and good. There's no easier way to be consistent than with just one keyboard, doing those mods itself!

Mind, when I got my M1 Mac in 2020, that changed again. I'm still on the same HHKB here today, but the fiddly tricks are on Karabiner now instead, where they remain no matter what keyboard I have hooked up. But aye, there's definitely something to be said for a solid set of mods you can rely on, whichever path you go to find it.

[Ellipse]

I am posting (with permission) another nice photo, this time with some of the new Extra Keys (some of which recently arrived from the factory: terminal, 4704, Icons, Extras, num pad/right side blocks, front printing), as well as some customized transparent relegendable keys, which allow you to print graphics for both the top and front of the key so you can have a custom key with custom front printing for multi-functionality.

This may be one of the first photos I've seen with a near-original 4704-style configuration!

Here are some details on the fonts used:
"most the numbers are whatever font IBM used. It looks like Public Sans though. The period is Public Sans too. Fira Code for the two slashed zeros, after seeing a picture of a model M style macro pad with that on. Finally, my Wheelwriter uses Prestige Elite at 12 cpi. That's what all the VISA CREDIT stuff is written in. All the words [on the relgendables] are Prestige Elite. I typed it manually on my wheelwriter."

unique - Copy.jpg (899.64 KiB) Viewed 44322 times

[darkcruix]

I am posting (with permission) another nice photo, this time with some of the new Extra Keys (some of which recently arrived from the factory: terminal, 4704, Icons, Extras, num pad/right side blocks, front printing), as well as some customized transparent relegendable keys, which allow you to print graphics for both the top and front of the key so you can have a custom key with custom front printing for multi-functionality.

This may be one of the first photos I've seen with a near-original 4704-style configuration!

This is just stunning. I have one very similar in my rotation. I tried to build the F77 like it would be NOS (I know - not perfect )

IMG_2662.jpg (733.48 KiB) Viewed 44295 times

[Muirium]

Needs a big beige cable.

I've still my original one, lying around unused…

[orAaron]

I recently received my F77, which is beautiful and amazing, and I'm having difficulty toggling between layers in Windows - they work fine on my admin account but it seems to revert to a default setting when I'm logged into a non-admin user.

For example, I'm trying to use numpad layout 5, where 4 is visually shared with Del, 5 with End, 6 with PgDn, etc. When I press my layer toggle key from an admin account, all keys toggle correctly; however, when I do the same from a non-admin account, Del/4 functions as Left Arrow, PgDn/6 as Right Arrow, etc.

Has anyone else experienced/resolved this or have I perhaps misconfigured my hex file?

[yac]

I didn't move any springs over -- and for one reason: they're very different in terms of weighting. You can even feel it when handling individual springs outside the keyboard: the Ellipse ones definitely seem to have a lower spring constant. The Ellipse Model F has quite a low actuation force!

The flippers, on the other hand, I've found to be quite interchangeable. They do not look completely identical, but I've swapped some Ellipse flippers into a Model F XT, and I can't even tell which keys have which flippers when typing on it.

Interesting, just to confirm you've put some Ellipse flippers into a Model F XT and used original Model F XT springs on them? I was told by Ellipse the official recommendation is to keep new flippers with new springs and ditto for old ones. My main gripe with my Model F XT was the spacebar actuation force. It was so hard i frequently didn't press it hard enough, so i learned to really hammer the space bar, something which took some unlearning once i got another keyboard.

[Ellipse]

The factory is air mailing me some of the new inner foam this month but only for the F77 regular (non HHKB variety - good for ANSI/ISO). The expectation is that all F77 regular foam orders will be of this new foam material for the first aid kits and spare foams too.

So if anyone wants to order the new style F77 regular foam it is now OK to do so (to be doubly sure it's ok to put in an order note for "I request the new foam material"). For previous orders you can't pick.

yac please search around for the space bar mod for XT style Model F keyboards posted somewhere a while back - making the stabilizer wire more flat significantly reduces the XT space bar force required.

That is an interesting finding; I didn't think my springs work as well with original flippers for the most part and would not recommend it. I wonder if spring age or corrosion affects the compression force of the original springs and results in higher force.

[BuccoBruce2]

Just got my F77. Am I missing something here or has this not changed yet? No matter what I do, I cannot get NKRO working with my custom keyboard layout. I tried using both "LAYOUT_all" with the appropriate KC_NO mappings as well as "LAYOUT_iso_hhkb_split_shift_split_backspace" which best matches my keyboard. I tried mapping the "Togg NKRO" function as well as the separate On/Off ones to unused layer 2 keys, they do nothing. With or without those keys mapped, the standard LShift+RShift+N MAGIC key combination does not work either. LShift+RShift+N worked out of the box. I am using the correct direct link to the "F77 specific" configurator.

I clicked the "Download Source" button and "COMMAND_ENABLE" is set to on for the "main" rules.mk - so the MAGIC keys should still work unless it is making a layout specific rules.mk without it. The Download Source button seems to return a "base" source tree that has my layout in the root directory as a .json file - before anything has been compiled from it. There's a download keymap.c button, but that returns a .json file as well with this instruction:

Code: Select all

This file is a configurator export. You can compile it directly inside QMK using the command `bin/qmk compile xwhatsit-brand_new_model_f-f77-wcass-bucc.json

I don't need any handholding for setting up a build environment, I've just never compiled QMK myself before.

Anyone?

[BuGless]

Just got my F77. Am I missing something here or has this not changed yet? No matter what I do, I cannot get NKRO working with my custom keyboard layout.

How did you test that it doesn't work?

I tried using both "LAYOUT_all" with the appropriate KC_NO mappings as well as "LAYOUT_iso_hhkb_split_shift_split_backspace" which best matches my keyboard.

That is mostly irrelevant to your problem.

I clicked the "Download Source" button and "COMMAND_ENABLE" is set to on for the "main" rules.mk - so the MAGIC keys should still work unless it is making a layout specific rules.mk without it.

The pandrew-website generated firmware actually has COMMAND_ENABLE=yes

I don't need any handholding for setting up a build environment, I've just never compiled QMK myself before.

Well, what I do to custom compile my QMK is this (default_bugless.json is the mapping file straight from the webconfigurator):

Code: Select all

#!/bin/sh

keyfile=default_bugless.json
kbmodel=xwhatsit/brand_new_model_f/f77
outfile=qmk_firmware/xwhatsit_brand_new_model_f_f77_wcass_bugless.hex

sed -i -e 's/ANY(\(TD_[^)]*\))/\1/g' "$keyfile"  # Fixup custom TD_ macro's from the webconfigurator
./qmk_firmware/bin/qmk json2c "$keyfile" >"qmk_firmware/keyboards/$kbmodel/keymaps/bugless/json2c.h"
./qmk_firmware/bin/qmk compile --keyboard "$kbmodel" --keymap bugless

ls -l "$outfile"

In the keymaps/bugless directory, I have my own rules.mk, and a keymap.c which does an #include "json2c.h"

[Heisenberg122]

Hi everyone,

Recently I got an F77 repro keyboard. I remapped it with QMK.

I'm having an issue with the layer mgmt. When I press the Fn + 1, it registers F1 as it should be in layer 2. But, after releasing the keys (including Fn), the layer doesn't return to layer1. It keeps registering layer2 keys although I don't press Fn key. It looks like, Fn key works as a kind of toggle key. Sorry, but I'm unsure if this is a feature or an issue. So, I don't know how to handle it.

I can share the remapping layout (inside of the JSON that I compiled with the QMK beta online site.) if it's needed.

Is there anyone who knows what the reason is? And how to solve or overcome that issue or feature

[darkcruix]

Hi everyone,

Recently I got an F77 repro keyboard. I remapped it with QMK.

I'm having an issue with the layer mgmt. When I press the Fn + 1, it registers F1 as it should be in layer 2. But, after releasing the keys (including Fn), the layer doesn't return to layer1. It keeps registering layer2 keys although I don't press Fn key. It looks like, Fn key works as a kind of toggle key. Sorry, but I'm unsure if this is a feature or an issue. So, I don't know how to handle it.

I can share the remapping layout (inside of the JSON that I compiled with the QMK beta online site.) if it's needed.

Is there anyone who knows what the reason is? And how to solve or overcome that issue or feature

Did you configure it as momentary MO()?

[BuGless]

It looks like, Fn key works as a kind of toggle key. Sorry, but I'm unsure if this is a feature or an issue. So, I don't know how to handle it.

Most likely cause: the mapping of the Fn key in layer 2 is not set to be transparent KC_TRNS, in which case it will register the press event, but not the release event of that key.

[orAaron]

While we're diagnosing toggles, I have a small update on my own related problem. To simplify my process and reduce room for error, I ditched my custom right-side-block 5 and the problem persists. My process goes like this:

1) Upload "F77_-_ANSI-ISO_-_0-9.json" to the QMK Configurator site, only altering Layer 0 by updating NumLock to TG[1] and, for testing purposes, I also altered Layer 1 by updating the blank key in numpad 5's location to X. I then press Compile and download the firmware.
2) In Pandrew's "2021 11 pandrew QMK utility.exe", click "Erase EEPROM" and then click "Enter Bootloader".
2) In Atmel Flip 3.4.7, click the microchip icon labeled "Select a Target Device" and choose ATmega32u2, 4) Click the USB cable icon labeled "Select a Communication Medium", select USB, and click the Open button.
5) Press Ctrl+L to load a hex file, select "eeprom_eraser.hex" from the QMK folder provided within Ellipse's "QMK-layout-files", run it twice, unplug the keyboard for 10 seconds and plug it back in.
6) Press Ctrl+L to load a hex file, select the output file I just downloaded from the QMK configurator site, run it twice, unplug the keyboard for 10 seconds and plug it back in.

Now, when logged into an admin account and the keyboard is on Layer 0, numpad 5 produces the character 5 and, when on Layer 1, numpad 5 produces the character X; however, when logged into a non-admin account and the keyboard is on Layer 0, numpad 5 produces the character 5 but, when on Layer 1, it produces nothing.

All that said, even when using a non-admin account, any alterations I make to Layer 0 are retained and work fine, as does the unmodified Layer 1 configuration from the original json file. Is there some deeper copy of Layer 1 we can't reprogram using this method? Would I perhaps benefit from exploring VIA instead of QMK or some alternative method? ...Somewhat rhetorical, but does everyone with custom layers just run admin accounts all the time?

[Heisenberg122]

Hi everyone,

Recently I got an F77 repro keyboard. I remapped it with QMK.

I'm having an issue with the layer mgmt. When I press the Fn + 1, it registers F1 as it should be in layer 2. But, after releasing the keys (including Fn), the layer doesn't return to layer1. It keeps registering layer2 keys although I don't press Fn key. It looks like, Fn key works as a kind of toggle key. Sorry, but I'm unsure if this is a feature or an issue. So, I don't know how to handle it.

I can share the remapping layout (inside of the JSON that I compiled with the QMK beta online site.) if it's needed.

Is there anyone who knows what the reason is? And how to solve or overcome that issue or feature

Did you configure it as momentary MO()?

Hi darcruix,

Thank you for your help.

Yes, I checked it out, the key has been configured as MO(1)

[Heisenberg122]

It looks like, Fn key works as a kind of toggle key. Sorry, but I'm unsure if this is a feature or an issue. So, I don't know how to handle it.

Most likely cause: the mapping of the Fn key in layer 2 is not set to be transparent KC_TRNS, in which case it will register the press event, but not the release event of that key.

Hi BuGless,

Thank you for your reply.

Yes, I think it may be the problem. Now I checked it,

Fn key has been;

configured as MO(1) in the first layer
configured as "KC_NO" in the second layer, instead of KC_TRANS

I will try to replace the KC_NO with KC_TRANS and rebuild the hex file.

[Heisenberg122]

It looks like, Fn key works as a kind of toggle key. Sorry, but I'm unsure if this is a feature or an issue. So, I don't know how to handle it.

Most likely cause: the mapping of the Fn key in layer 2 is not set to be transparent KC_TRNS, in which case it will register the press event, but not the release event of that key.

Hi BuGless,

Thank you for your reply.

Yes, I think it may be the problem. Now I checked it,

Fn key has been;

configured as MO(1) in the first layer
configured as "KC_NO" in the second layer, instead of KC_TRANS

I will try to replace the KC_NO with KC_TRANS and rebuild the hex file.

I replaced the KC_NO with KC_TRANS in the second layer mapping section for the Fn key in the layout JSON file, rebuilt the hex file, and flashed it again. Now it seems that there is nothing wrong. Layer management is working as expected. Thank you so much for your help.

[Kugelkopf]

Getting so much time on the same keyboard really opened my eyes to just how powerful consistency is in modification.

I totally agree with you. The sophisticatest techniques lose value, if not smoothly applicable. I'm quite happy with my F77's standard layout except for the missing "Esc" and "Fn" keys. I'll see, if using "RControl" as "Fn" and accessing "Esc" by switching to layer 1 or tapping "^" twice will work out nicely.

The "TeX layer", that will also make typing many programing languages (except for Python) easier is just a voluntary addition to the cake. I'm ommiting the gory details here, because it's meant to overcome problems user's of English keyboard layouts don't know to exist. I'm only adding, that the most unexpected behaviour will probably be the invocation of the cumbersome "\" by typing "j" twice. I hope I'll be able to remember that one.

That's all "fanciness" that came to my mind, and it seems to fit into the Atmel's memory. I had considered "Karabiner", too, that would probably allow to assign custom combinations to a single key (code) when tapped together with "Shift" or "Opt". I have to use my F77 with a number of different X variants as well as a zoo of *nix servers, though, so I'll try to get away with modifications of my keyboard's firmware solely as long as possible.

Using Vial to change one's keyboard configuration on the fly seems invitingly easy. Since it also works from an ordinary account without any administrator rights and because I couldn't detect any effects when playing around with Vial's "lock" and "unlock" options, I wonder if NathanA has compiled his Vial firmware newfxx-vial_20220405.zip with setting

Code: Select all

VIAL_INSECURE = yes

which weren't anything I'd like to keep. If he had mentioned his configuration, I haven't been unable to unearth it from the 253 pages of this thread.

[BuccoBruce2]

How did you test that it doesn't work?

Keytester in QMK Toolbox. When I try my HHKB or another keeb, I can lay my hand flat on the keyboard and see all the keys activate. With a custom QMK layout on the F77, it's never more than 6.

That is mostly irrelevant to your problem.

Was just trying to be thorough in explaining what I tried.

Well, what I do to custom compile my QMK is this (default_bugless.json is the mapping file straight from the webconfigurator):

Code: Select all

#!/bin/sh

keyfile=default_bugless.json
kbmodel=xwhatsit/brand_new_model_f/f77
outfile=qmk_firmware/xwhatsit_brand_new_model_f_f77_wcass_bugless.hex

sed -i -e 's/ANY(\(TD_[^)]*\))/\1/g' "$keyfile"  # Fixup custom TD_ macro's from the webconfigurator
./qmk_firmware/bin/qmk json2c "$keyfile" >"qmk_firmware/keyboards/$kbmodel/keymaps/bugless/json2c.h"
./qmk_firmware/bin/qmk compile --keyboard "$kbmodel" --keymap bugless

ls -l "$outfile"

In the keymaps/bugless directory, I have my own rules.mk, and a keymap.c which does an #include "json2c.h"

I'll give that a shot, thank you very much. Am I correct in assuming that after running that sed command, I can use the included json2c.py script in lieu of adding those headers?

EDIT: Bah, case of not entirely RTFM over here. https://docs.google.com/document/d/1B6Y ... fg2hbOB90/ pretty sure I got it now. Will let you know if NKRO works.

[CliftonR]

Hi all, my wife's long-awaited F77 arrived in mid-May 2022 (ordered early April 2021.) She did the setup herself, watched the videos and followed all the recommended setup procedures (keyboard disconnected, held vertical with top edge down while putting keycaps on, etc.) After I helped set up her desired key-mappings, it was working beautifully and she's been using it very happily for the last month and a half - it reminds her of her old PC/AT keyboard which she'd remembered nostalgically.

However, just in the last few days, it's started having problems where first one key and then another will stop responding. The first one was last Friday, in the numeric keypad '1' position of the right-hand keyblock - it began with spamming multiple 1s each time you hit it and then changed to not responding at all. She fixed that by removing the keycap, checking the spring moved freely, and reseating the keycap, in the proper vertical position. Very soon after, it was the letter 'O' key - that one didn't show the duplicated/spamming behavior, just stopped responding. Both times, removing and reseating the keycap seemed to fix it.

This morning, a few days later, it was the 'Q' key which again began by spamming a half line of 'q's before it stopped responding. Using the 2021 11 pandrew QMK utility, I could see that the key value was stuck in the permanently "on" (red) signal level. On that one at my suggestion, she tried removing the spring to check the free movement of the flipper, and ended up replacing the spring on the flipper as she was concerned the first spring had gotten bent slightly while reinserting it. In less than an hour after the 'Q' key was fixed, the 'S' key stopped working (this time with no spammed keys.)

At that point she put a different keyboard back on the computer for the time being, because she needs to be able to write on it and you won't get far without a letter 's'.

I am not sure where we should be looking for the problem - as you can see from this description, it's happening with keys at opposite ends of the keyboard and no common row or column, it's affecting only one key at a time, and it's fixed by a mechanical procedure, so these all suggest it's probably not a firmware problem, nor a soldering or cable issue. But on the mechanical side I can not think why 4 different random keys would work fine for the first month and a half, and then suddenly need to be pulled and reinstalled or tweaked with to work correctly.

Any ideas what we should be looking into to troubleshoot this?
Regards, Clifton

[BuccoBruce2]

Success!

If anyone else is trying to compile QMK on their own, in addition to the instructions already present in the Model F Manual on the website, part of which are shown below:

code changes to make
config.h in the folder of the keyboard you want to update – in my case, keyboards/xwhatsit/brand_new_model_f/f77/wcass
lines 286-287
#define SOLENOID_DEFAULT_DWELL 20
#define SOLENOID_MIN_DWELL 20

add to end of haptic.c file – new line:

#define HAPTIC_EXCLUSION_KEYS 1

in rules.mk:
line 40:
NKRO_ENABLE = yes # USB Nkey Rollover
add this line at bottom:
LTO_ENABLE = yes # Link Time Optimization – reduces file size

rules.mk
HAPTIC_ENABLE = yes
HAPTIC_DRIVER = SOLENOID

I think you'll also want to remove the

Code: Select all

HAPTIC_ENABLE += SOLENOID

line since those last two lines replace it, and I seem to recall reading in one of the dozen pages I scrolled through earlier that you should.

Code: Select all

Generating: .build/obj_xwhatsit_brand_new_model_f_f77_wcass/src/info_config.h                       [WARNINGS]
 |
 | ERROR xwhatsit/brand_new_model_f/f77/wcass: NO_ACTION_MACRO in config.h is no longer a valid option
 | ERROR xwhatsit/brand_new_model_f/f77/wcass: NO_ACTION_FUNCTION in config.h is no longer a valid option
 | ERROR xwhatsit/brand_new_model_f/f77/wcass: DESCRIPTION in config.h is no longer a valid option

Change config.h accordingly. I just commented those lines out in Notepad. Like so:

Code: Select all

//#define DESCRIPTION QMK firmware for the modelfkeyboards.com reproduction of the IBM Model F keyboards

//#ifndef LINK_TIME_OPTIMIZATION_ENABLE
//  #define NO_ACTION_MACRO
//  #define NO_ACTION_FUNCTION
//#endif

Additionally, you'll see this error:

Code: Select all

Compiling: keyboards/xwhatsit/util_comm.c                                                          keyboards/xwhatsit/util_comm.c:22:10: fatal error: tmk_core/common/eeprom.h: No such file or directory
 #include <tmk_core/common/eeprom.h>

Copy the contents of the tmk_core directory from pandrew's repo into your qmk_firmware folder. Do not overwrite any existing files - they're probably newer. I didn't. Nothing broke.

Now, to see if building it this way - "qmk setup" pulling the latest qmk files and just copying the xwhatsit folders + missing tmk_core files in - allows me to use QMK keycodes that are missing from the beta online configurator, like MAGIC_TOGGLE_CONTROL_CAPSLOCK and MAGIC_TOGGLE_GUI, instead of dealing with e.g. two separate MAGIC_NO_GUI and MAGIC_UNNO_GUI keys or having to map both MAGIC_SWAP_CONTROL_CAPSLOCK and MAGIC_UNSWAP_CONTROL_CAPSLOCK.

Confirmed: it compiled just fine locally with those keycodes included in my keymap and they work! I am now a happy camper: NKRO, HHKB style GUI disable and Ctrl/CL swap, and my Frankenstein ISO/ANSI/JIS.HHKB Arabic layout. I'll post some pictures soon.

For what it's worth, it compiles just fine under MSYS2/MinGW64, no need for a Ubuntu VM if you're on Windows, provided you're familiar with using MSYS2. It flashes just fine using QMK Toolbox on Windows too, I still flashed the eeprom_eraser.hex as instructed. If you're on Windows and you already have MSYS2 installed, I'm assuming you know how to get QMK running in there, but you can either use their QMK MSYS if you don't, or if you don't want multiple MSYS2 environments set up for no reason:

Code: Select all

pacman -Syu
pacman --needed --noconfirm --disable-download-timeout -S git mingw-w64-x86_64-python-qmk
qmk setup

QMK will tell you where it's setting itself up, for me that was C:\Users\Me\qmk_firmware.

cd to some other directory so you don't overwrite it when you clone pandrew's repo. You know your MSYS2 home directory better than I do. cd ../.. took me to c/msys64/home.

Code: Select all

git clone http://purdea.ro/qmk_firmware/

Once that's done, cd to wherever qmk told you it set itself up, make the required changes mentioned above, and then you can just "qmk config user.keyboard=xwhatsit/brand_new_model_f/f77/wcass" and "qmk compile yourkeymap.json" like the manual says to.

Spoiler:

I didn't realize how used to my JIS HHKB I've gotten. I must've typed & instead of ' a dozen times while writing this.

[sedevidi]

If I believe Vial, the combo had sent the same key code (0x5C00) as the "r" key defined on layer 2. Contrary to the former, the latter does enter bootloader mode, though. Hence I wonder, if combos can be used at all to enter bootloader mode running Vial firmware?

IIRC, there is a bug in the Vial firmware, related to a #define or enum, which NathanA explained a while ago: the actual reset/bootloader keycodes have +1 codes, thus the code which should be 0x5C00 may actually be 0x5C01 or so. Please get back up this thread to get the actual explaination and fix...

[sedevidi]

For example, I'm trying to use numpad layout 5, where 4 is visually shared with Del, 5 with End, 6 with PgDn, etc. When I press my layer toggle key from an admin account, all keys toggle correctly; however, when I do the same from a non-admin account, Del/4 functions as Left Arrow, PgDn/6 as Right Arrow, etc.

The only thing that can interfere is the host-based numlock state: admin account is num-locked, while regular account is not.
The solution to this is to use the top-row-numbers for your fake numpad, instead of actual numpad numbers, which really have dual meaning on the host, depending on its numlock state.
The root of the problem is that the keyboard is not aware of the numlock state, and just send the keycode for "that key on the righ-side-block with a 4 and a left arrow printed in it".
NathanA devised the scheme initially a few pages back, and I use it on my F77.

[Kugelkopf]

If I believe Vial, the combo had sent the same key code (0x5C00) as the "r" key defined on layer 2. Contrary to the former, the latter does enter bootloader mode, though. Hence I wonder, if combos can be used at all to enter bootloader mode running Vial firmware?

IIRC, there is a bug in the Vial firmware, related to a #define or enum, which NathanA explained a while ago: the actual reset/bootloader keycodes have +1 codes, thus the code which should be 0x5C00 may actually be 0x5C01 or so. Please get back up this thread to get the actual explaination and fix...

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)?

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.

Thanks for caring! If my hexadecimal arithmetic skills are in the right ballpark, this would mean, "Reset" (0x5C00) would actually be 0x5BFF. Assigning this value to be sent by the combo "LShift" + "b" + "RShift" in Vial did in fact cause my F77 to cease processing keystrokes. It continued to be accessible by Vial, though, while it didn't show up in QMK toolbox. For some additional fun, I've also tried 0x5C00 (as before) and 0x5C01. 0x5C00 produced a short interruption in Vial's display, but no appearance in QMK toolbox (as before), 0x5C01 behaved largely as 0x5BFF, as far as I've checked.

"Reset", 0x5C00 as reported by Vial did activate bootloader mode, when sent using the predefined reset key in layer 2. So may be some setting just forbids bootloader mode to be entered by means of a (Vial) combo?

I've managed to produce one Vial crash during the tests, but failed to jam the MCU's operation to a point, where entering bootloader mode wasn't possible any more using software tools alone. In fact, I didn't notice any harm to the controller's configuration, so my soldering iron to build a reliable hardware bootloader solution remains packed this time. On the other hand, the reason that Vial combos fail to activate bootloader mode remains unclear (at least to me).

[orAaron]

The solution to this is to use the top-row-numbers for your fake numpad, instead of actual numpad numbers

Thank you (and NathanA) so much! This works like charm and perfectly serves my purpose. I was becoming very worried I couldn't actually use my custom layout. You've made my day.

[BuGless]

keyboard disconnected, held vertical with top edge down while putting keycaps on

Even when done like this, it's still possible to have a not quite well-enough seated spring.
When you examine a keycap from below, you'll notice that there is exactly one spot where the spring needs to fit into.
When populating the keyboard with the keycaps, I've had it happen a few times (more than 10 times) that the spring was not perfectly lying center down, but is in fact slightly upward/left/right from the optimal position. When then pressing on the keycap there appears to be a one in ten chance that it will not sit perfectly, and the key will either not work from the get-go, or will start malfunctioning later.

She fixed that by removing the keycap, checking the spring moved freely, and reseating the keycap, in the proper vertical position.

It usually is not that the spring is not moving freely; in most cases the spring was not aligned well enough to the spot it is supposed to lean on under the keycap, and every keypress it dislodges a bit further, until it finally ends up in a position where it does not toggle the flipper any longer (the flipper usually then falls flat and activates permanently). The key will still bounce back (the spring still pushes back), but it will sound different. Try it by putting on the keycap with the spring totally wrong. You should hear the difference between a properly seated spring and a wrongly seated one.

This morning, a few days later, it was the 'Q' key which again began by spamming a half line of 'q's before it stopped responding. Using the 2021 11 pandrew QMK utility, I could see that the key value was stuck in the permanently "on" (red) signal level.

This is typical behaviour. It usually means the spring dislodged (finally) and the flipper falls back to active-only position.

But on the mechanical side I can not think why 4 different random keys would work fine for the first month and a half, and then suddenly need to be pulled and reinstalled or tweaked with to work correctly.

I'd simply recommend pulling all keycaps that eventually misbehave and then reseating the keycap while paying particular attention to the spring position (perfect is straight down), when putting on the keycap try to ensure that the spring will hit the designated spot under the keycap. When in doubt (because you noticed the spring bouncing around just when you pushed down the keycap), pull it right away and try again. Afterwards, check the sound of (pressing) the key.
Most people in this forum have done it this way, and after a while everything keeps working. It's not a recurring problem.

[CliftonR]

Thanks, BuGless! This is extremely helpful, and reassuring that it's not something we can expect to keep recurring once we get it right.

We'll look closely at the spring alignment when reinstalling the 'S' key, and if we see this again on any other keys, we'll check the spring alignment extra carefully before reinstalling the keycap.

[Heisenberg122]

Hi everyone,

I'm having another (but this time is a little more annoying) issue with my brand new F77 keyboard.

I think, there is a significant delay or lag on the spacebar. In the beginning, I thought it was because the spacebar is wobbling/rattling. Then I tuned the space bar metal tabs like in the Model F Manual 4-6, 4-7, 4-8 sections. But the problem still exists.

The symptom of the problem is when I increase my typing speed (I'm a touch typist), the sentence is written like the below;


'The quickb rownf oxj umpso ver thel azyd of.' So, the initial letter of the next word is being registered before the spacebar even though I press the spacebar before the initial letter of the next word.

I'm sure that I'm typing and pressing the keys correctly. So I never have that kind of problem with any other buckling spring or standard keyboards.

Is there anybody who has an idea about that problem?

[Ellipse]

Keeping the original xwhatsit firmware alive:

Is anyone up for creating a "0.9.3 version 2" firmware for the new 33 pin controller I'm testing this week? The changes are that caps is pin 18, pin 19 is Num, and pin 17 is Scroll. Because of these hardware variations, this will have to be a separate firmware version.

Heisenberg122 as noted in the manual that specific issue is probably fixed by tightening the 2 controller ground screws and perhaps adjusting or replacing the spring of the space bar.