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

[NathanA]

[video]

What the heck?!?

Try as I might, I cannot make this happen on mine. I re-re-flashed the firmware just to be extra sure, then immediately loaded your layout file into my keyboard. When I hit my Backspace key using your layout where it is programmed for \, I get a \. And when I hit my \ key which your layout has assigned to Backspace, it backspaces.

If you use Vial to assign Backspace to ANY key -- let's pick some random, arbitrary key, like...gosh I dunno, 'P' -- and you press it, you get a \ instead? (Likewise when assigning \ to literally any key and you press it, it backspaces?) Or is this phenomenon limited to these two particular physical keys?

Hate to ask the obvious question, but...there's no chance that some time ago, you remapped \ to Backspace and Backspace to \ on your computer using some other piece of software (one that works independently of the specific keyboard you're using / have plugged in), and you simply forgot about it? Perhaps to deal with some quirk of the layout of the previous keyboard you were using on this computer, before you switched to the F77? That's the most obvious answer I can come up with...

Even if you're sure that you didn't do that, what if you take the F77 and plug it into a completely different computer? Do the keys still do the wrong things & in the exact same way?

If it happens on all computers and you aren't running some other app in the background that's intercepting and remapping keystrokes, then the only other thought I have at the moment is that perhaps there is some very strange EEPROM corruption that's happened on your controller that is somehow causing the firmware to swap those two key values. You could try the "nuclear option" to deal with that:

1. Put your keyboard into bootloader mode & flash the attached eeprom_eraser.hex to it with QMK Toolbox. Give it a few seconds after it is seemingly done.
2. Then click the "Clear EEPROM" button in the bottom-left corner of the QMK Toolbox window.
3. Finally, after all that, re-flash the Vial firmware hex file.

...then check and see if the problem is solved after that.

Talk about bizarre.

[CoolPenguin1]

[video]

What the heck?!?

Try as I might, I cannot make this happen on mine. I re-re-flashed the firmware just to be extra sure, then immediately loaded your layout file into my keyboard. When I hit my Backspace key using your layout where it is programmed for \, I get a \. And when I hit my \ key which your layout has assigned to Backspace, it backspaces.

If you use Vial to assign Backspace to ANY key -- let's pick some random, arbitrary key, like...gosh I dunno, 'P' -- and you press it, you get a \ instead? (Likewise when assigning \ to literally any key and you press it, it backspaces?) Or is this phenomenon limited to these two particular physical keys?

Hate to ask the obvious question, but...there's no chance that some time ago, you remapped \ to Backspace and Backspace to \ on your computer using some other piece of software (one that works independently of the specific keyboard you're using / have plugged in), and you simply forgot about it? Perhaps to deal with some quirk of the layout of the previous keyboard you were using on this computer, before you switched to the F77? That's the most obvious answer I can come up with...

Even if you're sure that you didn't do that, what if you take the F77 and plug it into a completely different computer? Do the keys still do the wrong things & in the exact same way?

If it happens on all computers and you aren't running some other app in the background that's intercepting and remapping keystrokes, then the only other thought I have at the moment is that perhaps there is some very strange EEPROM corruption that's happened on your controller that is somehow causing the firmware to swap those two key values. You could try the "nuclear option" to deal with that:

1. Put your keyboard into bootloader mode & flash the attached eeprom_eraser.hex to it with QMK Toolbox. Give it a few seconds after it is seemingly done.
2. Then click the "Clear EEPROM" button in the bottom-left corner of the QMK Toolbox window.
3. Finally, after all that, re-flash the Vial firmware hex file.

...then check and see if the problem is solved after that.

Talk about bizarre.

It seems to have been a EEPROM corruption since I did the "nuclear option" as you said and it seems to have fixed it.

[NathanA]

It seems to have been a EEPROM corruption since I did the "nuclear option" as you said and it seems to have fixed it.

Awesome; glad to hear that worked. I've gotten in the habit of completely zeroing out flash and EEPROM every time I want to flash a new hex file, just to head off problems like this.

[Ellipse]

Great notes NathanA, especially on the EEPROM erase option - it is interesting that there is no option with atmel flip while flashing the firmware to automatically erase the eeprom to my knowledge. The pandrew utility does have a handy EEPROM erase button.

[NathanA]

The pandrew utility does have a handy EEPROM erase button.

Good point & I had quite forgotten about that. I likely could've directed CoolPenguin1 to zero out his EEPROM using the pandrew utility instead, which would've avoided an entire reflash of the firmware.

I still would love for somebody to tell me what "erase_eeprom.hex" actually does. Nobody can seem to tell me 1) where this file originates (I know it was first distributed by xwhatsit, but where did he come up with it? there's no source code for it anywhere, at least that I can find!), 2) if the act of flashing it is what is zeroing out flash & EEPROM, or if it contains actual code that the microcontroller executes *after* it is flashed that then takes care of wiping the EEPROM, 3) how this differs (if at all) from just clicking the "Clear EEPROM" button in QMK Toolbox.

Since I don't understand exactly how erase_eeprom.hex works, I both continue to flash erase_eeprom.hex + click "Clear EEPROM" after that's done, as well as tell other people to do that. But for all I know, these are both effectively redundant actions. (I will note that if one were to put their controller into bootloader mode and then ONLY click "Clear EEPROM" and NOT flash erase_eeprom.hex beforehand, you are still forced to reflash the QMK/VIA/Vial hex file afterward, so clearly QMK Toolbox's "Clear EEPROM" is doing something more than just a simple EEPROM wipe!)

I suppose that if I understood AVR assembly at all, I might be able to arrive at answers to my own questions, but I know exactly zilch about it...

[sedevidi]

I will note that if one were to put their controller into bootloader mode and then ONLY click "Clear EEPROM" and NOT flash erase_eeprom.hex beforehand, you are still forced to reflash the QMK/VIA/Vial hex file afterward, so clearly QMK Toolbox's "Clear EEPROM" is doing something more than just a simple EEPROM wipe!

This seems to imply that "Clear EEPROM" just flips a boolean/shebang in EEPROM or flash, that instructs the firmware on first or later startup, to clear the EEPROM. I don't see any other way this could work, appart from directly writing to the EEPROM from the USB connection, which does not seem to be possible from what you say.
Maybe a direct USB command like "Please clear the EEPROM right now" exists in QMK, but is disabled by default, for obvious security reasons (ie. any USB host software could reset the keyboard at any time).
(I'm still waiting for my F77, then I'll dig into all this)

[NathanA]

This seems to imply that "Clear EEPROM" just flips a boolean/shebang in EEPROM or flash, that instructs the firmware on first or later startup, to clear the EEPROM.

QMK Toolbox is essentially just a GUI wrapper around dfu-programmer, and if you supply --eeprom parameter to dfu-programmer, it writes the specified file to EEPROM instead of to flash. The "Clear EEPROM" button calls dfu-programmer with this very flag. The file that it writes to EEPROM when you click that button is "reset.eep", a copy of which is located here: https://github.com/qmk/qmk_toolbox/blob ... /reset.eep

Converting that from ihex format to raw binary gives me a 1-byte file whose entire contents is a single byte of value 0. So I suppose it *could* be a flag that it's flipping in EEPROM (the very first byte, though??) that the bootloader is looking for when it starts up. But much more likely I suspect is that changing a single byte requires that you write out an entire page to the EEPROM, so perhaps writing a single 0 to address 0 is all that it takes to effectively wipe it.

I don't see any other way this could work, appart from directly writing to the EEPROM from the USB connection, which does not seem to be possible from what you say.

Unclear what part of what I said led you to think I was making any claims about whether EEPROM could or could not be written to directly (well, relatively speaking...it's the DFU bootloader doing the actual writing, technically) from the USB host. It seems fairly clear from the capabilities of dfu-programmer that this is possible. The part that's been UNclear is 1) why does "Clear EEPROM" seemingly also wipe the flash, too, and not just the EEPROM, and 2) what exactly is the point of the "erase_eeprom.hex" program if writing directly to EEPROM is possible while in bootloader mode?

One thing that I did just notice for the first time, though, while looking at a screenshot of what the QMK Toolbox console shows after "Clear EEPROM" is pressed (guess I haven't been paying close enough attention when doing it on my own 'board!), is that the "dfu-programmer flash --eeprom reset.eep" command is preceded by a "dfu-programmer erase --force" command! ...which I presume erases the flash (where code lives) since "--eeprom" is nowhere to be found on that first execution. My guess is that QMK Toolbox is coded to blindly run "dfu-programmer erase --force" before *any* kind of programming takes place. So that probably explains why flash also gets wiped when "Clear EEPROM" is clicked...blegh.

Maybe a direct USB command like "Please clear the EEPROM right now" exists in QMK,

This does exist, but not so much in QMK itself (which would be a nightmare anyway to do platform-independently I'd guess) as much as it's in the specific QMK "driver" (not sure what else to call it) that pandrew wrote for the capsense keyboard controller. It listens on a back-channel for a "clear EEPROM" command (among others) that his client-side testing utility can issue to the keyboard. If one is worried about the security of this, that particular command could be commented out of the source code (the "UTIL_COMM_ERASE_EEPROM" case in the switch statement in util_comm.c).

[sedevidi]

But much more likely I suspect is that changing a single byte requires that you write out an entire page to the EEPROM, so perhaps writing a single 0 to address 0 is all that it takes to effectively wipe it.

From Wikipedia, Flash and EEPROM are nowadays very similar, except that Flash are erasable by whole pages, which enables high speed and high density, while EEPROM are erasable byte-by-byte, which leads to much lower density and speed, but much better endurance.
So I'd say that flashing a single byte to EEPROM effectively resets a single byte.

Unclear what part of what I said led you to think ... (it's the DFU bootloader doing the actual writing, technically) ...

Correct. That's what I was thinking about.

One thing that I did just notice for the first time, though, while looking at a screenshot of what the QMK Toolbox console shows after "Clear EEPROM" is pressed (guess I haven't been paying close enough attention when doing it on my own 'board!), is that the "dfu-programmer flash --eeprom reset.eep" command is preceded by a "dfu-programmer erase --force" command! ...which I presume erases the flash (where code lives) since "--eeprom" is nowhere to be found on that first execution. My guess is that QMK Toolbox is coded to blindly run "dfu-programmer erase --force" before *any* kind of programming takes place. So that probably explains why flash also gets wiped when "Clear EEPROM" is clicked...blegh.

Reading « Manual page dfu-programmer(1) » (0.6.1-1+b1 on Debian), I can find a "flash-eeprom" command, but no "--eeprom" option to the "flash" command. flash-eeprom "Writes to eeprom memory."
There is also an "erase" (but no documented "--force" option), which "Erases all the flash memory. This is required before the bootloader will perform other commands."
The manual also says "You will normally need to start by issuing the "erase" command; the default security policies prevent extracting firmware, to prevent reverse engineering of what is usually proprietary code."
This might be the reason for the "erase" before anything else. Thus the written EEPROM byte is much probably a "first run boolean" that the QMK firmware uses to initialise all its EEPROM book-keeping.

All this leads me to think that there might be a bug in the VIAL EEPROM book-keeping, which then needs the full Flash and EEPROM erase then reflash to work correctly. Missing the EEPROM erase migh lead to VIAL behaving like CoolPenguin1 described.
Or it's just like the man page says: "erase (Flash + EEPROM) is required before any other command"... or else too many possibility of bugs might arise from misaligned program in Flash vs. data in EEPROM.

[NathanA]

From Wikipedia, Flash and EEPROM are nowadays very similar, except that Flash are erasable by whole pages, which enables high speed and high density, while EEPROM are erasable byte-by-byte, which leads to much lower density and speed, but much better endurance.

Dug up the ATmegaXXU2 datasheet, and apparently the EEPROM on this series does actually consist of 4-byte pages, though provisions are made for single-byte read/write through a page buffer. So, agreed I'm barking up the wrong tree here.

Reading « Manual page dfu-programmer(1) » (0.6.1-1+b1 on Debian), I can find a "flash-eeprom" command, but no "--eeprom" option to the "flash" command. flash-eeprom "Writes to eeprom memory."
There is also an "erase" (but no documented "--force" option), which "Erases all the flash memory. This is required before the bootloader will perform other commands."
The manual also says "You will normally need to start by issuing the "erase" command; the default security policies prevent extracting firmware, to prevent reverse engineering of what is usually proprietary code."
This might be the reason for the "erase" before anything else. Thus the written EEPROM byte is much probably a "first run boolean" that the QMK firmware uses to initialise all its EEPROM book-keeping.

FYI, active development on dfu-programmer appears to have come to a standstill; even so, 0.6.1 is extremely old (April 2013), so kind of nuts that the most current Debian package is still on this version. The last published version from current maintainers was 0.7.2 from February 2015, which is the version that QMK Toolbox ships with. An HTMLized version of the man page from 0.7.2 is available straight from their Github repo, and reveals that the command-line parameters were reworked (likely in 0.7.0), explaining the discrepancy.

But I suspect your conclusion is correct. The man page mentions that "for AT90 and ATmega type devices a chip erase must be performed before other commands become available," so even if you want just to write to EEPROM through the Atmel DFU, apparently you still have to do a complete flash erase. Seems bonkers to me, but...

Reading between the lines, this maybe isn't a 100% hard-and-fast rule, and likely has something to do with the security fuse bits Atmel has made available on this product. The man page goes on later to describe dfu-programmer's "setsecure" option:

"setsecure: Sets the security bit on AVR32 chips. This prevents the content being read back from the chip, except in the same session in which it was programmed. When the security fuse is set, almost nothing will work without first executing the erase command. The only way to clear the security fuse once set is to use a JTAG chip erase, which will also erase the bootloader."

...and then in the Known Issues section near the end:

"To remove any write or read protection from any chips, a full chip erasure is required. For AVR32 chips an erase operation over USB will remove protection until the device is rebooted. To remove the protection more permanently requires a JTAG erase (which will also erase the bootloader)." [emphasis added]

Some Googling around and perusing of other forums (e.g. AVRFreaks) suggests that if you purchase ATmegaXXUx chips from the channel that have been preloaded with Atmel's DFU bootloader, the security bits are also pre-enabled on these products. The only way clear those bits would be to use an ISP/JTAG to erase the entirety of flash, which in turn wipes out the stock DFU bootloader, leaving you with a brick. In theory you could re-burn the (not-open-source) Atmel DFU bootloader back to flash using the same interface but without setting the security bits this time, but that would of course require that you possess a copy of said bootloader. I've managed to find where Atmel has released the binary for the DFU bootloader they wrote for the ATmega32U4, but so far have struck out on the 32U2 version, and it seems unlikely they'd be willing to talk to me unless I'm a direct customer of theirs (likely with a support contract of some kind, maybe even enforcing an NDA first...you know how these companies are, *sigh*). And even if I could dig the bootloader code up, the wcass xwhatsit controller that ships with these keyboards does not (to my knowledge) expose an ISP header. Not that that's a complete impediment to wiring up an ISP to the chip on the board, but it does present an additional challenge. (In theory, you don't actually "need" the Atmel DFU bootloader to have a working keyboard controller. You could just flash QMK itself to the bootable area of flash, foregoing USB DFU ability entirely. It just means that every time you want to reflask QMK or update the keyboard controller firmware, you have to break out your ISP, which is of course way less convenient than reflashing via the USB side.)

(More and more I'm wishing that xwhatsit had simply spent the additional $5-10 or whatever to use the U4 variant of the microcontroller in his design...)

Anyway, tying all of the loose ends together: dfu-programmer man page talks in seeming absolutes about this in certain places, but that's probably just because -- given that dfu-programmer is specifically designed to talk to the Atmel stock DFU bootloader -- the vast, vast majority of people will be using dfu-programmer to interact with AVR chips that have had the security bits pre-set at the factory, and so the reality is that for all intents and purposes, you must first do a complete erase of the flash chip (which then unlocks all read/write functions, but only up until the next reboot) before you can do anything else. And this is why QMK Toolbox performs a flash erase before it can do an "EEPROM wipe".

And circling back around to your theory: it's very likely not writing all 0s (or all FFs) to the whole 1K worth of EEPROM in order to "wipe" it, because QMK itself probably just checks the contents of the first byte in order to determine whether to trust the contents of the rest of EEPROM or not ("bookkeeping", as you say). That way it can avoid unnecessarily exercising/wearing out the EEPROM prematurely. (Of course, scrutiny of the QMK source should be able to confirm or disprove this theory.)

All this leads me to think that there might be a bug in the VIAL EEPROM book-keeping, which then needs the full Flash and EEPROM erase then reflash to work correctly. Missing the EEPROM erase migh lead to VIAL behaving like CoolPenguin1 described.
Or it's just like the man page says: "erase (Flash + EEPROM) is required before any other command"... or else too many possibility of bugs might arise from misaligned program in Flash vs. data in EEPROM.

Since I suspect that the requirement to do an erase before "any other command" is related to the ATmega flash security bits issue & not some kind of data "misalignment", your first proposed theory strikes me as the more likely one. This actually makes all the more sense when you consider that QMK itself I believe hardly uses EEPROM for anything...if you run straight-up QMK on your controller without any VIA or Vial bits, the entire keyboard layout/map is hard-coded in flash: if you want to change it, you have to re-compile and re-flash. So likely either Vial is failing to take into account what little EEPROM "bookkeeping" QMK does, and/or is failing to properly do any of its own.

This is hardly the only Vial-related memory-adjacent bug I've run into, if so. I'm still running up against what seems to be some sort of memory (SRAM) corruption issue in later releases of Vial that to this day is preventing me from making working builds of Vial firmware for the New Model Fs if I use a source tree checkout dated past September 2021 and also enable all of the various dynamic Vial features (Combos + Tapdance + Mousekeys etc.). But this seems to only be a problem when I build recent Vial code specifically for xwhatsit controllers using the pandrew QMK driver, and isn't a problem for other QMK-supported keyboard controllers designed around the ATmega32U2, which suggests that there is a bad interaction specifically between pandrew's code and recent Vial code. But this is another discussion for another time (hopefully soon)...

[I0IParzival]

Hi all! just got today my F77!! I'm currently installing the solenoid but I have two questions I'm not finding being already resolved. First one is the solenoid driver cable does not have all the pins populated, so which ones have to be connected? the ones in the same row as the square or the ones in the other row (square being GND/black right)??


Second one, the pcb cames preloaded with QMK? Does it has the combo to activate the solenoid(FN+Space+T)?

Thanks! I'll report soon with more info

Edit: got it working, if you are wondering the same questions the answers are: 1. Red isolated cable is the one that goes to the square pads. 2. No, the firmaware does not comes preloaded with the solenoid toggle option.

In order to get it working you need to create your own with the HPT_TOG and I recommend the HPT_DWLI and HPT_DWLD as well as by default the solenoid is on the softest position and is quieter than the keyboard, so you have to increase the Dwell time in order to be able to hear it.

The assembly was totally painless of both all the keys(had to reseat a 4-5 of them and one spring) and the solenoid is also really easy to install, just a bit of tetris to see where to place it and all done.
Now if you excuse me I'm going to go hide all the sharp things on the house to not be suddenly killed by my GF.

Edit 2: choose wisely where to place it cause once it is down good luck moving it. Also I think the vintage style sticker in the box looks better than the one on the case, so now there are two stickers on the back of my keyboard

[Ellipse]

Glad your new F77 arrived safely! Your details may not be entirely correct for the currently shipping factory default keyboard firmware.

Everyone for solenoid installation please refer to the manual - solenoid installation section - and solenoid product pages, both on the project web site.

The solenoid toggle is correctly set in the factory firmware but as a note most keyboards have the Right Ctrl key set as the Fn key as the factory default, unless you selected split right shift which has a dedicated Fn key. The dwell time is correctly set in the default firmware to be sufficient for the extra beefy solenoids. If you flash your own QMK firmware then you will need to adjust this yourself as detailed in the manual.

It is correct that I recommend extending the solenoid for full power while the factory default setting is not extended.

[I0IParzival]

Well I was looking for the info about the cable orientation and the only information I was finding it was about connecting the square pad with the other square pad but nothing else and as the connector did not had the 6 cables the orientation was important.

About the HPT_TOG I tried several times but it didn't work, maybe the cable was on the wrong orientation and that's why.

[Ellipse]

Today a bunch of the remaining key sets arrived by express mail from the factory, including the Industrial SSK 12 key sets, many of the remaining international sets (Swedish-Finnish, etc.), and some of the Extra Keys. Another air shipment batch over the coming weeks should have the remaining dye sublimated keys we have been waiting on.

The Industrial SSK 12 Key sets look great - I would say they are even an upgrade over the IBM/Lexmark Model M originals. As always please disregard the colors (cell phone photos). I am glad the factory focused extra effort on making sure these sets look as good as they do, even though this resulted in a delay for these keys. The Front Printing was by far the most difficult part of the dye sublimation and it took more than one year to get it right.

That means that many of the orders containing these sets can start shipping this week!

2022-04-11_11-18-16.jpg (1.69 MiB) Viewed 8335 times

2022-04-11_11-18-24.jpg (961.02 KiB) Viewed 8335 times

2022-04-11_11-18-39.jpg (1.48 MiB) Viewed 8335 times

2022-04-11_11-19-04.jpg (1.57 MiB) Viewed 8335 times

[AnnoyedWalrus]

The Industrial SSK keys looks absolutely delicious, so happy I ordered a set!

[dfischer429]

I received my F77 this week and it was well worth the wait. I love this keyboard. Everything about it in terms of build quality, function, aesthetics, etc., exceeded my expectations. I had no issues getting it set it up and I've been happily using it as my daily driver at work for the last several days.

I am probably a bit of an anomaly in that I'm not really a keyboard collector or enthusiast. I've never owned a mechanical keyboard, and I've spent my entire life typing on the cheapest crap possible without putting much thought into it. Because I work in IT I'm not sure I've ever actually bought a keyboard, I've just used whatever I could get for free at work. I didn't even know what an IBM model F was before I discovered the F77 project. But, when I stumbled across it something about it resonated with me, and I knew I had to have one.

Typing on this thing is just an absolute joy. The way it rings with every keystroke until it's practically singing has really increased my productivity and encouraged me to do more writing. I'm not sure if this is the start of a new obsession, or if the F77 is the pinnacle for me, but I'm glad I took the plunge.

[Ellipse]

Thanks for sharing your experience dfischer429. Glad everything arrived safely!

Everyone please do let others know about the project if you don't mind. I'm hoping the factory can make as many of these keyboards as possible. My thinking is that a lot more folks would be interested in these great old keyboards if they only knew they existed and spent a little time reading up on them and watching some videos on YouTube.

[jandres]

My solenoid isn't working either, and like you I was careful to connect the red wire to the square pin. My new model "F" Keyboard works great, but I can't get the solenoid to work because I can't get the software utility to work.

I've tried every version on the utility, including the newest version off The Buckle Spring, on either two different Macs (both Intel based), as well as a native Windows machine.

Depending on which version of the utility I attempt to run, I either get:

"Multiple beamspring controllers found, please choose one". Two appear on a drop down list, no matter which I select, the utility locks up and I have to force it to quit. This happens on the 6.x and 7.x versions of the utility.

On every other version I immediately get "ibm_capsense_usb_util quit unexpectedly." I even tried to run it in compatibility mode. No luck.

On Windows I immediately get "error: couldn't open device." when I try to run any version of the utility.

There are great tutorials and instructions on how to physically install the driver and solenoid, but it's a little lacking on the software side.

I am working on the assumption that one needs to have the utility running, at least initially for the solenoid to work. In other words, the solenoid doesn't work out of the box as soon as it is properly connected. I assume this simply because mine didn't immediately work once physically installed and it makes sense that there would have to be some utility to turn on/off the solenoid and make other adjustments.

At this point I think my driver is defective or incompatible with the xwhatsit utility. I will probably buy another driver and see if the former is the problem.

It's a great keyboard and I plan on ordering another next month. You don't need the solenoid to use and enjoy the keyboard, but it would be nice for it to work.

Any help would be greatly appreciated!

[NathanA]

My solenoid isn't working either, [...]

jandres,

Did you just receive your keyboard, or have you had it for a while? If you just got it, have you actually re-flashed any firmware on it, or is it still stock/running whatever it shipped with?

There are two very different and distinct firmwares that you can run on these keyboards: the xwhatsit "ibm_capsense" firmware, and various incarnations of QMK (some just raw QMK which doesn't allow for real-time keyboard layout modifications, and some with VIA or Vial support which are both third-party GUI configuration utilities that can change the layout on-the-fly).

Only the very earliest shipments of these keyboards were preloaded with xwhatsit's "ibm_capsense" firmware. At some point in early 2021, Ellipse switched over to flashing new shipments with QMK firmware instead, mostly because xwhatsit typically requires some fine-tuning of the capacitive sensing calibration and can be finicky, while pandrew's work on the QMK port has a very robust auto-self-calibrating algorithm. Switching to QMK made more keyboards "just work" out of the box.

You never come out and say it (and there are various different utilities one COULD be running to configure or test their keyboard: the pandrew utility, VIA or Vial, etc.), but the "utility" you keep referencing sounds like the xwhatsit "ibm_capsense" utility. This utility doesn't know how to interface with and does not work with QMK-based firmwares. So the likely reason that you're getting these errors is because you aren't actually running xwhatsit firmware on your keyboard.

If you insist on using the xwhatsit utility, you will have to re-flash your keyboard with xwhatsit firmware instead of the QMK firmware.

If, however, your only goal is to get your solenoid to work, you have no particular affinity for a specific firmware, and you are still running the out-of-box firmware on a keyboard that you just recently received, then (aside from the fact it won't talk to a keyboard running QMK anyway) you don't need that ibm_capsense utility to get the solenoid working. I don't have a solenoid, but my understanding is that the QMK firmware that ships flashed to the keyboard is already set up out-of-the-box to engage the solenoid properly, should one be connected up correctly to the keyboard controller.

So if yours is not working, my best guess is that whatever the problem is, it ain't a software problem.

[jandres]

Hi Nathan, thanks for your very helpful reply. I just received the keyboard, solenoid and solenoid driver last week. I honestly have no idea what firmware is running on the keyboard and the only reason I am even messing with the xwhatsit utility is that’s what’s referenced in the linked to manual. The firmware is as I received it, I haven’t updated it at all.

I just want the solenoid to work and initially tried to toggle on the solenoid with the combination of keys, control - space - “T” that I read somewhere, assuming that it would work right out of the box. But as I said, that didn’t work, so that is when I started looking into the solenoid utility.

[NathanA]

I just want the solenoid to work and initially tried to toggle on the solenoid with the combination of keys, control - space - “T” that I read somewhere, assuming that it would work right out of the box. But as I said, that didn’t work, so that is when I started looking into the solenoid utility.

'k, then your keyboard 100% is running QMK firmware. The "ibm_capsense" utility isn't a "solenoid" utility as much as it is a utility to let you tweak all aspects of the xwhatsit firmware. That utility will do nothing for you.

I did forget that you would need to trigger the solenoid to "on" even when running QMK. What precise model of F keyboard do you have & what key layout did you order? (F62 or F77? Standard ANSI? HHKB? Split right shift or no?)

[jandres]

F77 Model F Keyboard, standard ANSI, not split right shift.

Thanks again!

[Ellipse]

jandres all of the factory default firmware should have the solenoid enabled by default, without having to make any adjustments.

Did anyone else receiving their new Model F in the past couple weeks have an issue with the solenoid not operating by default, after they installed it?

[NathanA]

jandres all of the factory default firmware should have the solenoid enabled by default, without having to make any adjustments.

Did anyone else receiving their new Model F in the past couple weeks have an issue with the solenoid not operating by default, after they installed it?

So by default, not only is there a key on a function layer mapped to HPT_TOG, but it's also toggled on by default such that you don't have to hit the haptic toggle key before it starts working?

A few posts above on this same page (238), I0IParzival says:

Edit: got it working, if you are wondering the same questions the answers are: 1. Red isolated cable is the one that goes to the square pads. 2. No, the firmaware does not comes preloaded with the solenoid toggle option.

In order to get it working you need to create your own with the HPT_TOG [...]

...by which I take it to mean that he wasn't able to get the solenoid to function until he built himself a QMK hex where he double-checked that he had a key mapped to HPT_TOG.

F77 Model F Keyboard, standard ANSI, not split right shift.

jandres, I can confirm that both the stock F77 ANSI layout with the numpad ("option #2") as well as the one with the more standard nav cluster block ("option #1") are supposed to have a haptic on/off toggle key mapped to Fn+Spacebar+T. But as Ellipse said, Fn is actually Right Ctrl. So what happens if you press and hold RCtrl, then press and hold Spacebar, and while continuing to press both, press and release T? Does the solenoid start working?

[I0IParzival]

Yes, for me RCTRL was FN,m cause I could put it on flash mode, but the solenoid toggle wasn't working till I made my own hex

[jandres]

"So what happens if you press and hold RCtrl, then press and hold Spacebar, and while continuing to press both, press and release T? Does the solenoid start working?"

I just tried this again several times, unfortunately there is no change, the solenoid is still not working.

[Ellipse]

Solenoid issue:

It seems like in the past year, something with the qmk project updates has broken the Model F project solenoid support.

I am hoping that pandrew and some other folks can look into the issues to enable the solenoid to work by default as it was in the prior firmware versions.

I did some testing and found that my current hex files are not working to enable the solenoid as the default option. My current hex files incorporate the qmk project as of November 2021. I also tried updating the files again using a clone of the latest qmk repo from github.

By importing my unchanged layout files to pandrew's QMK configurator web site and flashing that firmware today, the solenoid is enabled by default and works but you need to press the key combination to increase the dwell time as described in the manual. Pandrew's qmk site does use an older version of qmk which does not have this solenoid issue.

[I0IParzival]

Yeah, i used the Pandrew's site to create my hex(first in the web and later with the lmk fork downloaded).

I changed the default dwell time to 25ms and it works fine(but I found that on my other computer that used an USB extension cable it does not have enough power to make the solenoid work properly but that's for sure because of the cheapo extension + long combination of cables

[NathanA]

It seems like in the past year, something with the qmk project updates has broken the Model F project solenoid support.

I am hoping that pandrew and some other folks can look into the issues to enable the solenoid to work by default as it was in the prior firmware versions.

I did some testing and found that my current hex files are not working to enable the solenoid as the default option. My current hex files incorporate the qmk project as of November 2021. I also tried updating the files again using a clone of the latest qmk repo from github.

The haptic/solenoid system in QMK seems to have undergone some extensive rework & refactoring in the last few months. So it's not a huge surprise that something the QMK developers did between April and November might've broken it for the xwhatsit controller keyboards.

I did take a few moments just now to look through a disassembly of your most recent hex files, and can at least confirm that it appears you do have the HPT_TOG key mapping in place. So I don't think the issue is that the haptic toggle key is not mapped to where it should be, but rather that actually toggling haptic to on is ineffective, because the haptic feature itself is what broke, not the toggle switch mapping.

I'll note that even some of the files have moved around in the source tree, and are no longer where you might expect them. For example, your build instructions from back in April 2021 suggest overwriting the haptic.c file located at drivers/haptic/haptic.c with a version from darkcruix's repository. But haptic.c no longer lives in that location in newer releases of QMK, but rather at quantum/haptic.c. So putting darkcruix's version of that file in drivers/haptic isn't actually affecting anything anymore. Haven't done a diff to see what has changed, but my guess is that if you simply overwrote quantum/haptic.c with darkcruix's version from back in early 2021, recent QMK checkouts wouldn't even build properly.

I can confirm at the very minimum that including

Code: Select all

HAPTIC_ENABLE = SOLENOID

in rules.mk is no longer the correct way to enable support; in fact, if you have that line in there, I'm surprised your build doesn't break since "SOLENOID" is not a valid option for that parameter. HAPTIC_ENABLE is now a boolean, and you need to specify the driver to be used separately, like so:

Code: Select all

HAPTIC_ENABLE = yes
HAPTIC_DRIVER = SOLENOID

The question is whether the base QMK solenoid driver and the xwhatsit QMK keyboard driver are on the same page with regard to implementation. Merely making sure that the haptic solenoid driver gets compiled in may not be enough if the changes made to haptic support were significant.

[Ellipse]

Thanks NathanA, that worked! The updated firmware files for QMK can be found here: https://www.modelfkeyboards.com/wp-cont ... -files.zip

For folks having trouble with solenoid stuff I recommend flashing the updated firmware to have the solenoid enabled by default. Please note the file names are the same so I recommend deleting any old firmware files before downloading the latest copy.

The haptic.c is out of date as I no longer updated the haptic.c as it caused issues. I think dark_cruix submitted the haptic patch to QMK and it was accepted, as modifier keys currently do not actuate the solenoid.

[jandres]

Thanks for everyone's help with the solenoid. I'm not really sure where to go from here or even what to ask. I suppose I need to do what Ellipse suggests, and flash my firmware so that the solenoid is on by default. Can anyone post a link or direct me to a site with the simplest method of doing so or provide me with any other advice.

Thanks!