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

[Ellipse]

Great photos del20nd! Thanks for posting your review.

The manual mentions that the vertical stabilizers should have the larger ear on the right side for all keys except the ISO enter key, which has the larger ear on the left side. There is a photo that shows the normal orientation (larger ear on the right side) below the following text in the manual:

"The vertical stabilizer inserts are installed also as pictured for the number pad 2U Vertical keys, but must be installed differently for ISO Enter! The product photo shows each photo in the “right side up” orientation so for ISO Enter you’d just install the vertical (black) insert 180 degrees rotated from the photo, so that the larger “ear” of the insert is on the left." I added some more details to the manual to reiterate this point.

Can you show a photo of what you meant with the flat silicone gasket? That seems like a good idea to consider to remove an insert without the Wilde tool linked to previously.

pilcher please do share photos of the mod when it is completed! You'd have to cut through the aluminum case somehow. I explained on a recent page on this thread why the key sets cannot be installed, so the downside is that the springs may move out of place while the keyboard is bounced around in shipping.

YALE70 based on one or two issues of damaged boxes I have started taping the sides as well. So far no reports of box destruction with the additional tape. Also I am now putting as much as possible below the keyboard including the dot matrix page and green booklet to minimize the small bags moving around too much since they are lightweight. But we must always continue to expect shipping damage to be a possibility since the keycaps cannot be installed, and more of these results will be reported when hundreds of packages are going out in such a short time span.

And here is another great setup photo that a forum member let me know about: https://www.reddit.com/r/MechKeyboards/ ... nts_at_it/

[del20nd]

Again, I'm happy with what was delivered overall. I understand the reasons for not delivering a fully assembled board, but do wish that, at the very least, the stabilizers came tested and preinstalled, especially if there's undocumented variation in the orientation which they have to be installed. Getting them wrong can be a costly and annoying time sink. There's always a chance that you'll have to disassemble the keyboard either way, springs can come dislodged in shipping, etc, but I feel that just taking this one step would greatly reduce the risk.

My biggest "complaint" about shipping is that several of my springs were actually damaged by being mashed against the barrels. I had to remove those springs and straighten them out as much as I could, which inevitably isn't perfect (although I did ultimately get all of the keys working). I'm hesitant to suggest that the keyboards should be shipped with the springs not installed, because it would make setup quite a bit more work, but it would prevent the springs from being damaged in this way.

Mine did as well. I had a few damaged keycaps too because UPS decided to play package football with the delivery (all eight pounds of it). These were all quickly replaced, but I do have some ideas on additional measures that could be taken to hopefully mitigate stuff like this from occurring on future shipments.

The loose component bags should be secured: I think them shifting around inside the box during transit is a big reason why springs are getting bent and whatnot. I would tie down, rubber band, or tape the bags to the keyboard so they can't move. I'd also try protecting the exposed barrels/springs with a thin sheet of cardboard or packing foam, so that the bags aren't resting directly on the springs.

Finally, I would also tape over the side gaps on the top of the box. Only the long bottom gap was taped over and in my case, I think something caught in one of those side gaps and completely ripped the end of the package open. The carrier had taped over the opening before I received the package.

Otherwise, I think the foam endcaps are fine - I don't think the box needs any additional padding, but given the limited interior space of the box, hopefully those ideas at least make it less likely that reckless carrier handling ends up causing actual damage to the keyboard or the components.

Guess I got lucky here. No damage to the springs or keycaps, but quite a few nice dents to the box.

[del20nd]

Great photos del20nd! Thanks for posting your review.

The manual mentions that the vertical stabilizers should have the larger ear on the right side for all keys except the ISO enter key, which has the larger ear on the left side. There is a photo that shows the normal orientation (larger ear on the right side) below the following text in the manual:

"The vertical stabilizer inserts are installed also as pictured for the number pad 2U Vertical keys, but must be installed differently for ISO Enter! The product photo shows each photo in the “right side up” orientation so for ISO Enter you’d just install the vertical (black) insert 180 degrees rotated from the photo, so that the larger “ear” of the insert is on the left." I added some more details to the manual to reiterate this point.

Can you show a photo of what you meant with the flat silicone gasket? That seems like a good idea to consider to remove an insert without the Wilde tool linked to previously.

pilcher please do share photos of the mod when it is completed! You'd have to cut through the aluminum case somehow. I explained on a recent page on this thread why the key sets cannot be installed, so the downside is that the springs may move out of place while the keyboard is bounced around in shipping.

YALE70 based on one or two issues of damaged boxes I have started taping the sides as well. So far no reports of box destruction with the additional tape. Also I am now putting as much as possible below the keyboard including the dot matrix page and green booklet to minimize the small bags moving around too much since they are lightweight. But we must always continue to expect shipping damage to be a possibility since the keycaps cannot be installed, and more of these results will be reported when hundreds of packages are going out in such a short time span.

Thanks for the feedback.

That I'm saying is that I had to install the ISO enter key with the ear to the right side, counter to instructions, for it to work. When the ear was installed facing towards the left as instructed, the enter key bound badly. It works perfectly with the ear pointing towards the right.

The flat silicone gasket is something I had left over from another project. It's something I made by taking black silicone gasket maker from Harbor Freight, flattening between two pieces of waxed paper to about the thickness of a credit card, and letting dry overnight. I've used these flat sheets to cut out washers and silicone feet for other projects, so here I just tore off a piece of scrap.

[del20nd]

While the setup process was mostly straightforward to anyone that's dealt with rehabbing original Model F's, I did run into one frustrating issue with the black vertical key stabilizers. In the instructions it's explicitly stated that the stabilizer for the ISO enter should be keyed such that the large ear is pointing towards the left, 180 degrees rotated from the images in the guide. When I keyed it this way, it didn't work. It turned out that it worked perfectly when it was keyed the same way as the '+' key, with the large ear pointing toward the right. That was frustrating because the instruction didn't mention the variation, and getting that wrong can easily mean a complete teardown of the keyboard. I did have to pause the setup for a night to stop myself from doing something stupid to try to brute force the stabilizer. It was very frustrating in the moment.

Interesting. I didn't have to reverse the orientation of the vertical key stabilizers, but it did take a lot of force to get them in. (I found that the end of a normal sized Sharpie is the perfect size to push them in without permanently denting one's thumb.) Now I'm wondering if mine are in backwards.

In my experience if the stabilizer is in backwards then the stabilized key will bind. If your keys aren't binding it's probably right. My black stabilizers also took a lot of force to get flush: I pushed them down with an oversized flat headed screw.

[YALE70]

Are you referring to the post on the top case for the solenoid (the other post on the top case is for the USB cable's p clip strain relief)? That hole should be 6-32 thread and there should have been a 6-32 bolt provided. I suggest testing the hole with another 6-32 bolt. I have installed a number of solenoids and drivers for these boards and have not noticed any issues. The solenoid driver should not be mounted to any points on the bottom of the case.

It is the post for the solenoid driver, yes. I used the larger of the screws provided - the two smaller screws being used to secure the the solenoid to the bottom plate. I should have some more 6-32 machine screws kicking around so I'll verify this once I have another opportunity to open the keyboard up.

Alright, I took another look at the solenoid driver post on my keyboard and it is indeed too large for the provided 6-32 screw. Tried a few 6-32 PC case screws as well and no dice. I'm assuming it was tapped during manufacturing but the threads looked pretty tore up even before I tried getting the screws to bite. I checked with my calipers and measured a 3.61 mm ID for the post while the screws were ~3.40 mm OD. Not a huge deal now since I just put a M4x6 screw with a 1 mm washer into it and it seems to be holding strong.

[pilcher]

I am getting inconsistent registrations of my "F" key (oh the irony!). Most of the time it works just fine, but it occasionally doesn't register, or it registers twice. I've already tried twisting the spring around and even swapping it with the spring from another key. The signal level also looks OK.

What else can I try?

[pilcher]

Also, has anyone been able to get the pandrew utility to work on Linux? I've managed to build it (tried both hidapi variants), and it doesn't detect my keyboard, even when run as root.

EDIT: FWIW, Vial detects my keyboard just fine (even as a non-root user).

[del20nd]

I am getting inconsistent registrations of my "F" key (oh the irony!). Most of the time it works just fine, but it occasionally doesn't register, or it registers twice. I've already tried twisting the spring around and even swapping it with the spring from another key. The signal level also looks OK.

What else can I try?

Did you do a full disassembly when you swapped the spring? Try swapping barrels or feet (maybe one of them has a defect), or see if maybe a small piece of debris worked its way down into the assembly?

[Ordinary Witch]

Also, has anyone been able to get the pandrew utility to work on Linux? I've managed to build it (tried both hidapi variants), and it doesn't detect my keyboard, even when run as root.

EDIT: FWIW, Vial detects my keyboard just fine (even as a non-root user).

just to make sure; there are two variants of the utility. the one meant for the new firmware is here. I don't remember where the older one meant for pandrew's original firmware is anymore, but you'll need the right one for your firmware, which is probably the one I linked to since you're using vial

[dr_xadium]

I have a question about the solenoid in the F104 (I had it preinstalled for me) - it's doing an odd thing where it works for an extended period of time, and then after a while it will start to "bind" (I think it is failing to retract). I then have to thwap the side of the case lightly, and it thocks (when I assume it retracts), and works normally again until it binds again.

It's an intermittent issue - sometimes it won't do it for days and other times it will happen almost constantly, jamming for a few words and then restarting, or stopping completely unless I thwack the case.

Could it be the solenoid is not getting enough power? I have it plugged in directly to the laptop USB port. Do I need to reposition it in the case?

[Ellipse]

pilcher my guess is you are not reinstalling the spring correctly, in the correct 12 o'clock position as well as with the spring about 1mm away from the 12 o'clock position of the barrel when the keyboard is held vertically, space bar end up. If the spring is too high up (too close to the 6 o'clock barrel position), buckling errors will occur as you mentioned. I also recommend swapping the keycap with another keycap to see if the F keycap itself was somehow deformed or damaged.

As reported to me through another GH/DT forum member's great research back when the project was just getting started 8 or 9 years ago:

It is important for the spring to be close to the 12 o'clock position of the barrel (as shown below) when the keyboard is held vertically, space bar end up, because the click is not strong otherwise and click errors are more likely to occur.

It is also important for the spring to be close to the 6 o'clock position of the barrel when the keyboard is held vertically, number/function row end up, because the key press will cause the spring to buzz if not in this position. This means that the spring cannot touch the 12 o'clock position because then the spring will be too far away from the 6 o'clock position when the keyboard is flipped to the right side up position.

And finally, springs that are installed too much left or too much right compared to the vertical center will cause errors with installation such as keys not working reliably.

dr_xadium I would check that the solenoid bracket is not angled in a way that the cylinder makes contact with it, as that may be causing your issue (just adjust the 2 solenoid bracket screws). However I think the issue is likely the quality and quantity of power output from your laptop USB ports. To test this, you could unplug and replug in the keyboard after the solenoid stops working, to see if this unplug and replug causes the solenoid to operate normally afterwards. There may also be some USB power saving settings that can be adjusted in your operating system. Maybe the opposite of the normal advice would be best on some underpowered laptop ports: to use a powered USB hub.

2021-06-11_12-20-56.jpg (79.52 KiB) Viewed 5056 times

2021-06-11_12-14-15 original XT spring location flipper.jpg (1.2 MiB) Viewed 5056 times

[NathanA]

Lastly, the "LShift + RShift + N" command for enabling NKRO that was specified in the manual did not appear to work for me. I ended up just mapping it in Vial to Layer 2 as "Fn + Space + N".

I believe NKRO is enabled by default for NathanA firmware and not enabled for the previous pandrew firmware

Yeah, my NKRO didn't appear to be enabled by default when I initially tested it so that's when I ran into trouble trying to enable it.

It is not enabled by default. The NKRO feature is built into the firmware, but by default the keyboard runs in 6KRO mode, for reasons of broadest compatibility (NKRO doesn't always work 100% with certain machines or in certain contexts, so needs to be enabled by the user just in case their particular machine or circumstance would result in a non-functioning keyboard if the keyboard was in NKRO mode).

Any reference to any key combination that involves LShift+RShift+<key> is NOT supported in these Vial firmwares. These key combos are called "Command" keys in QMK, and although pandrew's QMK firmwares enabled this feature, there simply is not enough room in the 32KB of flash memory that the ATmega32U2 possesses to fit both it as well as all of the other features that Vial brought to the table. So it had to go. (By the way, this was also true of the darkcruix VIA firmwares! Those firmwares didn't have Command keys enabled in them, either.)

For virtually every Command combo shortcut, though, there is an equivalent Magic key code that you can arbitrarily assign to any key of your choice (using Vial, of course!). There were a very small handful of F77 layouts included with the New Model F Vial firmware distribution where I had, like you (@YALE70), assigned MAGIC_TOGGLE_NKRO to the key occupying the 'N' space on Layer 2 (so Fn + Space + N), but I had not gone through all of the other default layouts for all of the other keyboard models to do the same thing. It seems like a sane default key assignment, so I'll try to remember to make this a default for all keymaps included in the next release.

But, yes, ANY LShift+RShift+<key> combo is not valid on either VIA or Vial firmwares, just for the original QMK firmwares. LShift+RShift+B for example will not kick you to bootloader mode; the default key assignment for that across all keyboard models is Fn + Space + R (which, for the record, wasn't picked by me; I think the 'R" stands for Reset), though naturally, you can re-assign that to any key on any layer of your liking.

[NathanA]

Also, has anyone been able to get the pandrew utility to work on Linux? I've managed to build it (tried both hidapi variants), and it doesn't detect my keyboard, even when run as root.

And where did you obtain the sources to build it?

If you pulled from pandrew's repo, that version is not going to detect a keyboard running Vial firmware, since the USB Vendor ID and Product ID doesn't match what it is expecting. If you download the New Model F Vial firmware bundle, it includes unified diff patches that will result in a working version. But for your convenience, I've gone ahead and split the util-specific patches out of the main diff file & am attaching them to this response.

just to make sure; there are two variants of the utility. the one meant for the new firmware is here. I don't remember where the older one meant for pandrew's original firmware is anymore, but you'll need the right one for your firmware

Most of this is correct, but for clarification:

1) I don't build and distribute copies of Vial-compatible pandrew-util for Linux, only for Windows and Mac. This is just because of how wildly-diverse the Linux distribution ecosystem is. If you run Linux, sorry, but you're going to have to figure out how to build it yourself. (Though I've happily gone ahead and made one-off builds in the past for others as I've had spare time; just let me know which distribution, version of that distribution, and CPU architecture you are running & I'll see what I can do.) Fortunately, pandrew's build instructions are good. The Qt framework is what takes the most time to build and is the most complicated piece of this, so highly recommended you use a pre-built copy of the Qt development library wherever possible.

2) My patched version of pandrew-util works both for keyboards running Vial firmware as well as those running the original QMK firmware.

[del20nd]

Great photos del20nd! Thanks for posting your review.

The manual mentions that the vertical stabilizers should have the larger ear on the right side for all keys except the ISO enter key, which has the larger ear on the left side. There is a photo that shows the normal orientation (larger ear on the right side) below the following text in the manual:

"The vertical stabilizer inserts are installed also as pictured for the number pad 2U Vertical keys, but must be installed differently for ISO Enter! The product photo shows each photo in the “right side up” orientation so for ISO Enter you’d just install the vertical (black) insert 180 degrees rotated from the photo, so that the larger “ear” of the insert is on the left." I added some more details to the manual to reiterate this point.

Can you show a photo of what you meant with the flat silicone gasket? That seems like a good idea to consider to remove an insert without the Wilde tool linked to previously.

pilcher please do share photos of the mod when it is completed! You'd have to cut through the aluminum case somehow. I explained on a recent page on this thread why the key sets cannot be installed, so the downside is that the springs may move out of place while the keyboard is bounced around in shipping.

YALE70 based on one or two issues of damaged boxes I have started taping the sides as well. So far no reports of box destruction with the additional tape. Also I am now putting as much as possible below the keyboard including the dot matrix page and green booklet to minimize the small bags moving around too much since they are lightweight. But we must always continue to expect shipping damage to be a possibility since the keycaps cannot be installed, and more of these results will be reported when hundreds of packages are going out in such a short time span.

Thanks for the feedback.

That I'm saying is that I had to install the ISO enter key with the ear to the right side, counter to instructions, for it to work. When the ear was installed facing towards the left as instructed, the enter key bound badly. It works perfectly with the ear pointing towards the right.

The flat silicone gasket is something I had left over from another project. It's something I made by taking black silicone gasket maker from Harbor Freight, flattening between two pieces of waxed paper to about the thickness of a credit card, and letting dry overnight. I've used these flat sheets to cut out washers and silicone feet for other projects, so here I just tore off a piece of scrap.

Just for reference, this is how I have the black stabilizers installed. This was the only configuration that worked for me:



If I flip the ISO enter's stabilizer 180 degrees the key binds so badly that it doesn't return to the home position. As shown there's no binding.

[mbarszcz]

Just wanted to thank you Ellipse for all your effort you put into making these new Model F keyboards a reality. I've been following this project for many years now and had an original F122 that started with the original xwhatsit firmware which never quite worked right for me despite constantly fiddling with it. Several years ago I switched to the beta QMK firmware which has been great, but it was quite fussy to configure at the time.

While I know there are a lot of people that like the crazy small and unusual layouts, since before the project even began I just wanted a Model M layout with the Model F key mechanisms. All the keys, normal size. I was thrilled when the project got to the point where you started producing them. I finally got mine in the mail and spent the afternoon carefully putting the little pieces of floss in it just like my F122, putting it all together and very carefully putting the stickers on. Since this was a "special" model M for me, I decided to make it look like the Industrial M, complete with the requisite square black IBM badge in the corner.

The keys and firmware all worked perfectly right out of the box. No fiddly keys, no fiddly springs, no endless tweaking of sensitivities and thresholds, no bending and reseating the backplates, barrels and foam, no grounding issues, it all just worked as reliably as any other keyboard. Given how sensitive the capacitive sensing on the Model F is to imperfections, I think what you've managed to reliably manufacturer at this level of quality is truly commendable. Couple that with the Vial firmware and its amazing how far things have come over the past few years with all the manual firmware flashing that I used to have to do on my F122. It makes for a very polished experience.

Now I just need to get the icon set to finish it off.

The quality, the look, and the feel of this keyboard is exactly what I was looking for, great job.

photo_2024-10-26_12-42-34.jpg (176.12 KiB) Viewed 4765 times

[pilcher]

pilcher my guess is you are not reinstalling the spring correctly, in the correct 12 o'clock position as well as with the spring about 1mm away from the 12 o'clock position of the barrel when the keyboard is held vertically, space bar end up. If the spring is too high up (too close to the 6 o'clock barrel position), buckling errors will occur as you mentioned. I also recommend swapping the keycap with another keycap to see if the F keycap itself was somehow deformed or damaged.

As reported to me through another GH/DT forum member's great research back when the project was just getting started 8 or 9 years ago:

It is important for the spring to be close to the 12 o'clock position of the barrel (as shown below) when the keyboard is held vertically, space bar end up, because the click is not strong otherwise and click errors are more likely to occur.

It is also important for the spring to be close to the 6 o'clock position of the barrel when the keyboard is held vertically, number/function row end up, because the key press will cause the spring to buzz if not in this position. This means that the spring cannot touch the 12 o'clock position because then the spring will be too far away from the 6 o'clock position when the keyboard is flipped to the right side up position.

And finally, springs that are installed too much left or too much right compared to the vertical center will cause errors with installation such as keys not working reliably.

You beat me to it.

I connected the keyboard up to my kids' Windows machine, so I could run the signal level monitor, and that allowed me to confirm that the flipper does, in fact, work properly. Armed with that knowledge, I re-re-re-re-re-...-installed the spring, and I was finally able to get it working properly. So I won't need to take apart the inner assembly, which is good news, because I still don't see where the pliers can grip the two plates on the classic F104 in order to slide them apart.

I have a couple of takeaways from this.

• I don't know that it's really possible to determine if the spring and keycap are installed correctly just from the sound & feel. Personally, I would recommend that folks use the signal monitor when doing the initial keycap installation.

• Installing the springs onto the flippers is really, really difficult, and that's even more true when the springs have been damaged in shipping.

Also, I wasn't able to get the Linux version of the signal monitor to recognize the keyboard. Assuming that NathanA's post is correct, this is because the git repository referenced in the manual doesn't contain the necessary patches to recognize Vial-based keyboards. You probably want to update the manual accordingly.

Thanks!

[pilcher]

And where did you obtain the sources to build it?

If you pulled from pandrew's repo, that version is not going to detect a keyboard running Vial firmware, since the USB Vendor ID and Product ID doesn't match what it is expecting. If you download the New Model F Vial firmware bundle, it includes unified diff patches that will result in a working version. But for your convenience, I've gone ahead and split the util-specific patches out of the main diff file & am attaching them to this response.

I pulled it from

Code: Select all

http://purdea.ro/qmk_firmware/

. AFAICT, this is where the manual says to get it, but I can't get your patch to apply to that tree.

[NathanA]

Assuming that NathanA's post is correct, [...]

I'm the one who compiled all of the Vial firmwares, and who patched the util to be compatible with them, so yes, I'm pretty sure I know what I am talking about (at least when it comes to this).

I pulled it from

Code: Select all

http://purdea.ro/qmk_firmware/

. AFAICT, this is where the manual says to get it, but I can't get your patch to apply to that tree.

Sigh, I wondered if that might be the case but didn't check it before quickly firing off a reply.

I don't think that historically-speaking pandrew checks in frequent updates to the app, but I suppose it's possible that some minor updates or tweaks have taken place since I put that patch together which broke the ability to cleanly apply the patch.

I publish all of the source code changes I made in order to assemble working Vial firmwares for these keyboards, but I do so as patches/diffs. The development was forked off of pandrew's repo at a very specific time/check-in, so you have to roll back to that point in time if you want your clone of the repo to be in a state where that patch can cleanly apply.

Within the download package is included a (extremely primitive) shell script which checks the source code needed out of the pandrew and Vial repos, applies my diffs, and then builds all of the keyboard firmware binaries. (Given the complexity and the number of target host platforms, it does not attempt a build of the util; that's still left to you.) So frankly, what you should do is download that package from the website, and the follow the instructions for building in the README in order to set up your build environment. This will leave you with a source build tree that is in the exact state that you need & with the exact version of the files that you need in order to build a copy of the utility that includes support for these keyboards.

[Rotti]

Hey guys. I am using a Rev 2 Xwhatsit controller with an original Kishy that I have had working for many years now. I did have the original buzzer board and am trying to get the solenoid working. It does technically function but is very weak. With the default firmware from the "beta" side of QMK, the keys that I found that are supposed to adjust the dwell time for the solenoid do not seem to be working. On the keymap there isn't any thing mapped to that key combo, nor do I see any option to add them or anything to turn it on or off. Am I missing something, or do I really need to deep dive into adjusting the rules.mk and such and compile locally?

Well, I flashed the firmware listed above a couple posts, and now the keymap is WAY off, and can't get back into bootloader mode. Shorting the PROG pads is not putting into bootloader mode for QMK toolbox to see it to reflash.

Ok, got it working and reflashed back to a basic firmware from QMK. Still working trying to get the solenoid working better.

[pilcher]

Within the download package is included a (extremely primitive) shell script which checks the source code needed out of the pandrew and Vial repos, applies my diffs, and then builds all of the keyboard firmware binaries. (Given the complexity and the number of target host platforms, it does not attempt a build of the util; that's still left to you.) So frankly, what you should do is download that package from the website, and the follow the instructions for building in the README in order to set up your build environment. This will leave you with a source build tree that is in the exact state that you need & with the exact version of the files that you need in order to build a copy of the utility that includes support for these keyboards.

OK, I've made some progress. The utility now sees the keyboard, but when I try to start the signal level monitor, I get an error pop-up that says:

Unknown keyboard (you may need to update the util version)!

I tried to run the command to add a new keyboard:

python2 generate_layout.py > kbd_defs.cpp

I was able to work around a couple of errors (failing to locate avr/io.h and util/delay.h) by creating a couple of symlinks in my /usr/include directory, but now it's failing to find sequencer.h, which seems to be within the firmware tree, so I have no idea how to fix that.

And now the utility won't build at all, because kbd_defs.cpp is trashed. Sigh.

[NathanA]

OK, I've made some progress. The utility now sees the keyboard, but when I try to start the signal level monitor, I get an error pop-up that says:

Unknown keyboard (you may need to update the util version)!

I tried to run the command to add a new keyboard:

python2 generate_layout.py > kbd_defs.cpp

Yes, this step from pandrew's build instructions is necessary.

I was able to work around a couple of errors (failing to locate avr/io.h and util/delay.h) by creating a couple of symlinks in my /usr/include directory, but now it's failing to find sequencer.h, which seems to be within the firmware tree, so I have no idea how to fix that.

All 3 header files you reference have nothing to do with building the utility, so I'm not sure where you are running into these errors. (The first two are part of the avr-gcc standard library, and the third is part of QMK itself.) Perhaps you are seeing these during the execution of build.sh when it tries to compile all of the keyboard firmwares. If so, then just ignore them for now...this doesn't impact building the utility at all. If at some future date you have a desire to build the actual firmware, we can cross the bridge of debugging whatever problem you have there whenever you come to that. (My off-the-cuff guess is that avr-gcc plus associated libraries/toolkits are either not quite installed correctly, or you are running a much newer version that perhaps this older QMK source tree is not compatible with. But, again, irrelevant for the task at hand.)

EDIT: Okay, I see what's going on. The generate_layout.py script apparently traverses through all of the header files, I guess to resolve certain constants. So something wrong with avr-gcc installation can in fact break this.

I actually did include a pre-generated version of the kbd_defs.cpp file in diff form which includes all of the definitions for the new keyboard models; it just doesn't get applied automatically since the build script doesn't attempt a build of the utility (and since typically, if you have a properly functioning build environment, the generate_layout.py script works just fine anyway). To utilize it, re-run build.sh to get yourself a fresh build tree, then from your 'qmk_firmware' directory, run:

Code: Select all

patch -p1 < /YOUR/PATH/TO/THE/newfxx-vial-package/src/pandrew-util-new_kbd_defs_r5.diff

Then try your util build again.

[NathanA]

Hey guys. I am using a Rev 2 Xwhatsit controller with an original Kishy that I have had working for many years now. I did have the original buzzer board and am trying to get the solenoid working. It does technically function but is very weak. With the default firmware from the "beta" side of QMK, the keys that I found that are supposed to adjust the dwell time for the solenoid do not seem to be working.

[...]

Well, I flashed the firmware listed above a couple posts, and now the keymap is WAY off, and can't get back into bootloader mode.

I see that you finally got back to bootloader mode, so that's good. Yes, the PROG pad shorting can be finicky.

There are a number of things to address here...

First and foremost, the Vial firmwares that have been posted so far and which are being discussed in this thread are ONLY compatible with the Ellipse recreation keyboards. NOT with the original IBM-manufactured ones that have undergone an xwhatsit brain transplant. The web page explicitly says that these are for the "New Model F" keyboard series from "Model F Labs". The reason for the incompatibility (and for why your keymap looked and worked all screwy after you flashed the wrong firmware to your 'board) is because the recreation 'boards are NOT an exact clone of the originals, and the matrix arrangement is completely different on the Ellipse ones (not to mention that the pin header on the wcass "remix" of the xwhatsit controller is ordered differently than an original xwhatsit, such as what you have, while the Ellipse 'boards all shipped with wcass controllers). In fact, this DT thread is by-and-large dedicated to the recreation/clone boards.

The solenoid stuff is another entirely separate can of worms, and one that I am at a slight disadvantage of at addressing comprehensively since 1) I do not own a solenoid, 2) I do not desire to own a solenoid (at least, not for personal use...if someone wants to send one to me for testing/dev purposes, that's another thing entirely, but since I have no other use for it, I'm not going to sink my own $$ on one), and as a consequence, 3) I have never personally done any firmware testing with solenoids. And back when QMK first got ported to the xwhatsit family of controllers, there was a bunch of discussion in this thread surrounding issues getting it to fire satisfactorily. It seems like eventually most of the problems got worked out, and those updates were incorporated into the QMK firmwares that Ellipse himself was making and shipping pre-flashed to his boards. What I do NOT know for certain is whether these changes ever managed to spread beyond that. They were certainly available for anyone else to take and incorporate into their own builds/projects/forks, but that doesn't mean they did, and I haven't really checked or paid much attention to what others have done. I don't know where you are sourcing your QMK firmwares from that work with your board but which have solenoid performance problems, but if for example you're using pandrew's "beta" QMK Configurator instance to do so, I have no idea what solenoid driver code is being used there behind-the-scenes. (It looks like there is a "full source" download link, but I haven't taken the time to download and comb through it...)

On top of that, there is also the issue of any physical differences between the original IBM solenoids vs. the new solenoids that Ellipse sells (scroll down to the header that says "Custom made solenoid specifications:" for details). Since I have experience with neither, I have no idea if firmware that has been optimized for these new solenoids will perform as expected if you are using an original one. (I also have no idea which solenoid you have.)

All of that having been said, though I have no way to test it, I made sure to integrate the same, "known-good" solenoid code into the firmware builds I have been making for these keyboards, so that at least in theory the solenoid should perform exactly the same with Vial as it did with QMK...it should be no better, nor worse. And I haven't heard any complaints about solenoid performance from people running Vial on their New Model F keyboards in a looong time, which I take as a good sign (no news is good news...).

Anyway, if you wish to try it, I have gone ahead and ported Vial firmware to your original Kish + xwhatsit. The usual disclaimer of course is that I have no original Kish hardware to test it on; however, I'm still pretty confident that it will at least mostly work. You can download it here. Once downloaded, expand the ZIP archive, double-click the "link-flash-scripts" script, then go to the flash-scripts > ibm_f62_xwhatsit folder & double-click the singular "flash-..." script that's in there. Kick the keyboard controller into bootloader mode when instructed, and then wait for it to finish. After it's done, you can download Vial to configure your keyboard. Haptic/solenoid on/off toggle is mapped to Fn + Space + T by default, and "dwell time" can be decreased or increased with Fn + Space + "minus" / "plus" respectively.

[pilcher]

EDIT: Okay, I see what's going on. The generate_layout.py script apparently traverses through all of the header files, I guess to resolve certain constants. So something wrong with avr-gcc installation can in fact break this.

I actually did include a pre-generated version of the kbd_defs.cpp file in diff form which includes all of the definitions for the new keyboard models; it just doesn't get applied automatically since the build script doesn't attempt a build of the utility (and since typically, if you have a properly functioning build environment, the generate_layout.py script works just fine anyway). To utilize it, re-run build.sh to get yourself a fresh build tree, then from your 'qmk_firmware' directory, run:

Code: Select all

patch -p1 < /YOUR/PATH/TO/THE/newfxx-vial-package/src/pandrew-util-new_kbd_defs_r5.diff

Then try your util build again.

That worked!

I wrote up steps I took to build the utility here. Hopefully they will be useful for others.

(Just to note, the avr-gcc and avr-libc packages in Fedora work for the build script in the firmware bundle, so I don't think that they're broken. They are probably just putting things in slightly different paths than generate_layout.py expects.)

Thanks for your help!

[NathanA]

I wrote up steps I took to build the utility here. Hopefully they will be useful for others.

Looks pretty good. There are ways, though, that this could be tightened up even further, if you are interested.

I proposed simply running the build.sh script as that does most of the prep work for you, and telling you to "just run build.sh" is the easiest and most straightforward thing to say in a thread like this where there are already a lot of details to wade through and it's easy to get lost in the nuance. And running that script will certainly work.

But if all you really want to do is build the utility, and not the firmware itself, then going through the motions to install the QMK build enviro through Python, then letting the script check out the whole of the Vial Github tree in addition to the pandrew QMK tree, etc. is definitely overkill. For the utility itself, all you need to do is check out the pandrew sources from his repo, backlevel the files to the versions that the patches were designed to apply to, apply the patches, then do your build.

You can look at the build.sh script itself to figure out what it's doing, and design your more surgical solution around that. For example, from studying what it does after checking out from purdea.ro, we can see that it wants the entire source tree to be at one particular version of the master branch, but selectively wants a different version of kbd_defs.cpp.

Without running build.sh at all or installing the QMK Python stuff, we can reproduce that like this:

Code: Select all

$ git clone http://purdea.ro/qmk_firmware
$ cd qmk_firmware
$ git checkout 6ebae72
$ git checkout 758febb -- keyboards/xwhatsit/util/util/kbd_defs.cpp

After that, just apply BOTH of the diff files included in the newfxx package (the changes to util are spread across both; the second one only contains the differences that would exist to kbd_defs.cpp if you were to run the generate_layout.py script):

Code: Select all

$ patch -p1 < ../newfxx-vial-package/src/newfxx-vial-0p4p1-patches_r5.diff
$ patch -p1 < ../newfxx-vial-package/src/pandrew-util-new_kbd_defs_r5.diff

Note that you WILL get a bunch of patch application failures for the first of the two diffs. That's because some of the diffs expect the versions of the files it is patching are from the Vial sources, and not from pandrew's sources. But those failures don't matter, since you're not actually interested in compiling the keyboard controller firmware itself, just the utility, and all of the utility-related files will be patched successfully. So just ignore the failures, and proceed with your util build.

EDIT: by the way, handy tip: you can see a list of files that will be patched by a diff using:

Code: Select all

grep "^+++\s" file.diff

[Rotti]

Hey guys. I am using a Rev 2 Xwhatsit controller with an original Kishy that I have had working for many years now. I did have the original buzzer board and am trying to get the solenoid working. It does technically function but is very weak. With the default firmware from the "beta" side of QMK, the keys that I found that are supposed to adjust the dwell time for the solenoid do not seem to be working.

[...]

Well, I flashed the firmware listed above a couple posts, and now the keymap is WAY off, and can't get back into bootloader mode.

I see that you finally got back to bootloader mode, so that's good. Yes, the PROG pad shorting can be finicky.

There are a number of things to address here...

First and foremost, the Vial firmwares that have been posted so far and which are being discussed in this thread are ONLY compatible with the Ellipse recreation keyboards. NOT with the original IBM-manufactured ones that have undergone an xwhatsit brain transplant. The web page explicitly says that these are for the "New Model F" keyboard series from "Model F Labs". The reason for the incompatibility (and for why your keymap looked and worked all screwy after you flashed the wrong firmware to your 'board) is because the recreation 'boards are NOT an exact clone of the originals, and the matrix arrangement is completely different on the Ellipse ones (not to mention that the pin header on the wcass "remix" of the xwhatsit controller is ordered differently than an original xwhatsit, such as what you have, while the Ellipse 'boards all shipped with wcass controllers). In fact, this DT thread is by-and-large dedicated to the recreation/clone boards.

The solenoid stuff is another entirely separate can of worms, and one that I am at a slight disadvantage of at addressing comprehensively since 1) I do not own a solenoid, 2) I do not desire to own a solenoid (at least, not for personal use...if someone wants to send one to me for testing/dev purposes, that's another thing entirely, but since I have no other use for it, I'm not going to sink my own $$ on one), and as a consequence, 3) I have never personally done any firmware testing with solenoids. And back when QMK first got ported to the xwhatsit family of controllers, there was a bunch of discussion in this thread surrounding issues getting it to fire satisfactorily. It seems like eventually most of the problems got worked out, and those updates were incorporated into the QMK firmwares that Ellipse himself was making and shipping pre-flashed to his boards. What I do NOT know for certain is whether these changes ever managed to spread beyond that. They were certainly available for anyone else to take and incorporate into their own builds/projects/forks, but that doesn't mean they did, and I haven't really checked or paid much attention to what others have done. I don't know where you are sourcing your QMK firmwares from that work with your board but which have solenoid performance problems, but if for example you're using pandrew's "beta" QMK Configurator instance to do so, I have no idea what solenoid driver code is being used there behind-the-scenes. (It looks like there is a "full source" download link, but I haven't taken the time to download and comb through it...)

On top of that, there is also the issue of any physical differences between the original IBM solenoids vs. the new solenoids that Ellipse sells (scroll down to the header that says "Custom made solenoid specifications:" for details). Since I have experience with neither, I have no idea if firmware that has been optimized for these new solenoids will perform as expected if you are using an original one. (I also have no idea which solenoid you have.)

All of that having been said, though I have no way to test it, I made sure to integrate the same, "known-good" solenoid code into the firmware builds I have been making for these keyboards, so that at least in theory the solenoid should perform exactly the same with Vial as it did with QMK...it should be no better, nor worse. And I haven't heard any complaints about solenoid performance from people running Vial on their New Model F keyboards in a looong time, which I take as a good sign (no news is good news...).

Anyway, if you wish to try it, I have gone ahead and ported Vial firmware to your original Kish + xwhatsit. The usual disclaimer of course is that I have no original Kish hardware to test it on; however, I'm still pretty confident that it will at least mostly work. You can download it here. Once downloaded, expand the ZIP archive, double-click the "link-flash-scripts" script, then go to the flash-scripts > ibm_f62_xwhatsit folder & double-click the singular "flash-..." script that's in there. Kick the keyboard controller into bootloader mode when instructed, and then wait for it to finish. After it's done, you can download Vial to configure your keyboard. Haptic/solenoid on/off toggle is mapped to Fn + Space + T by default, and "dwell time" can be decreased or increased with Fn + Space + "minus" / "plus" respectively.

Good morning NathanA,

Some good news, I managed to get the solenoid somewhat working and keys bound to turn it on off, and I believe increase and decrease dwell time. Didn't have enough time to fully test it due to having to leave for work. But it still doesn't seem to be working like advertised. It still doesn't actuate hard enough to come close to depressing the return spring and is not audible. I am wondering if the driver board was somehow damaged during shipping. The driver and solenoid were both shipped together in the same bag without any separation. There is an LED on the driver that I believe is supposed to flash with the solenoid firing. However, it is not. I am going to try ordering another driver and one of the USB-C controllers and build up my AT and see if that has any better results.

[Rotti]

Quick question. I have the Rev 2 xwhatsit (close to 10 years old light use), and a newly purchased Tom Wong solenoid driver board as well as one of the new designed solenoids. What should I be seeing for voltages across which pins (hopefully looking for both into the driver and out to the solenoid) between keystrokes and during a solenoid trigger event?

It is working, however very light regardless of dwell time setting. Assuming my meter is accurate, I am seeing about 39 ohms across the solenoid coil and I believe 5VDC (ish) across the power pins going into the driver board. However, my meter doesn't react quick enough to see the trigger event. My makerspace does have equipment that should be able to see it.

[Ellipse]

Just wanted to thank you Ellipse for all your effort you put into making these new Model F keyboards a reality. I've been following this project for many years now and had an original F122 that started with the original xwhatsit firmware which never quite worked right for me despite constantly fiddling with it. Several years ago I switched to the beta QMK firmware which has been great, but it was quite fussy to configure at the time.

While I know there are a lot of people that like the crazy small and unusual layouts, since before the project even began I just wanted a Model M layout with the Model F key mechanisms. All the keys, normal size. I was thrilled when the project got to the point where you started producing them. I finally got mine in the mail and spent the afternoon carefully putting the little pieces of floss in it just like my F122, putting it all together and very carefully putting the stickers on. Since this was a "special" model M for me, I decided to make it look like the Industrial M, complete with the requisite square black IBM badge in the corner.

The keys and firmware all worked perfectly right out of the box. No fiddly keys, no fiddly springs, no endless tweaking of sensitivities and thresholds, no bending and reseating the backplates, barrels and foam, no grounding issues, it all just worked as reliably as any other keyboard. Given how sensitive the capacitive sensing on the Model F is to imperfections, I think what you've managed to reliably manufacturer at this level of quality is truly commendable. Couple that with the Vial firmware and its amazing how far things have come over the past few years with all the manual firmware flashing that I used to have to do on my F122. It makes for a very polished experience.

Now I just need to get the icon set to finish it off.

The quality, the look, and the feel of this keyboard is exactly what I was looking for, great job.

photo_2024-10-26_12-42-34.jpg

Thanks for posting the review and photo mbarszcz! Glad everything is up and running.

Regarding the solenoids, many other firmware files do not set the dwell time properly for the new Model F solenoid. As I noted a while back: "If you are using any of my premade hex files for either QMK or Via, the correct dwell time setting is done for you automatically. However if you use the QMK Configurator beta web site to make your firmware, import my JSON template file for your configuration and flash the firmware (see the firmware section of this manual), and while the keyboard is connected to your computer, hold down the keys Fn+Spacebar++= (the + = key next to backspace) which has been preprogrammed to increase the Solenoid dwell time by 1 ms. Press it 20 to 25 more times to get it to the minimum required amount for full power." I am not sure if this changed with later pandrew updates.

I suggest erasing the eeprom and starting over in terms of flashing the firmware again. For testing purposes, you can also flash the original xwhatsit firmware which allows numerical entry of the solenoid dwell time. https://static.wongcornall.com/ibm-capsense-usb/

Also, some laptop and other USB ports may not supply sufficient power for the solenoid, so I recommend testing on a desktop with the cable connected directly to a motherboard USB port.

[NathanA]

I suggest erasing the eeprom and starting over in terms of flashing the firmware again.

It sounded to me like he tried my Vial firmware for the original F62 + xwhatsit, which configures and drives the solenoid identically to all of my other Vial firmwares, and *also* completely wipes EEPROM when you use the flashing scripts that ship with it, and yet he still had the problem. So I think that rules out most of the possible firmware and leftover EEPROM junk issues.

But it still doesn't seem to be working like advertised. It still doesn't actuate hard enough to come close to depressing the return spring and is not audible. I am wondering if the driver board was somehow damaged during shipping. The driver and solenoid were both shipped together in the same bag without any separation. There is an LED on the driver that I believe is supposed to flash with the solenoid firing. However, it is not.

Okay, so you *do* have an Ellipse solenoid and driver board, then. I wasn't sure, but I definitely came away from reading your original post thinking that you likely have an original IBM one, and probably also a solenoid driver board that you sourced around the same time that you got your original xwhatsit.

I also definitely had the impression that you were coming from the original (non-QMK) xwhatsit/ibm-capsense firmware & that you were happy with the solenoid performance when you were using that, and only started having performance issues with it after switching to QMK. Is that assumption on my part also incorrect? Have you even tried it at all with the original xwhatsit firmware? Even if you plan on staying with QMK and/or Vial, it would at least be an interesting & likely educational test for you to roll back to xwhatsit firmware, just to see if the solenoid works any differently with it. Because obviously, if it doesn't, then that clearly tells you it is NOT a software problem. Rules out any possible firmware issues entirely and unambiguously.

[Ellipse]

Here is a firmware One Shot Keys question from someone who recently received their keyboard: "if I keep pressing a key over and over, it stops working for roughly five seconds. I THINK this is “One Shot Keys”. There doesn’t appear to be a setting that I can find (in Vial) to TURN THIS OFF. I can set it to 50 presses and that makes it *less likely* to be a problem, but that STILL will be a problem in video games." I mentioned reflashing the firmware and tightening the ground controller bolts as possible troubleshooting steps.

[NathanA]

"if I keep pressing a key over and over, it stops working for roughly five seconds. I THINK this is “One Shot Keys”."

I had never used the One Shot Keys feature of QMK until I read this post, after which I decided to read up on it and try it myself.

I do not think that this person understands how this feature works. If you read the very clear documentation about OST provided by QMK, it specifically states that the feature ONLY applies to keys that are explicitly set to OSM (or One Shot Modifier, available on the Quantum tab) or OSL (or One Shot Layer, available on the Layer tab).

The default layouts that the keyboards ship preprogrammed with don't have ANY keys set as OSM or OSL. Period. The only way that this feature could possibly be triggered by an owner of a New Model F keyboard running Vial firmware is if they explicitly went into Vial, and programmed keys as OSM or OSL keys themselves. Short of a very bizarre software bug within QMK itself, there is NO WAY to trigger this feature by "accident".

So for example, if you want your Left Shift to act as a "sticky" shift, you have to go into Vial, click your LShift key, go to the Quantum tab, and pick "OSM LSft" from the list. The "LShift" key then changes to be "OSM LSft" (or, in QMK keycode terms, from KC_LSHIFT to OSM(MOD_LSFT)). Once that's done, you can press and release the Left Shift key, then press any one other key on your keyboard, and that one keypress will be shifted.

Where the QMK Settings > One Shot Keys > "Tapping this number of times holds the key until tapped once again" comes into play is, whatever that number is set to, if you tap an OSM or OSL programmed key that many times, then it will hold down that "sticky" modifier key for you indefinitely, rather than just for a single keystroke. So again, for example, let's say this is left at the default of 5. If you have your Left Shift key programmed to OSM LSft, and you press and release it once, then you type the characters "qwerty", then it will come out as "Qwerty", because Shift gets held down for one and only one keystroke (the first character, which is 'q'). But if you press and release Left Shift 5 times, then every character you type from that point on will be shifted ("QWERTY"), until you press Left Shift again, which finally cancels the "sticky" holding down of Shift for you.

"There doesn’t appear to be a setting that I can find (in Vial) to TURN THIS OFF."

There is nothing to "turn off". It only engages if you manually program one or more of your keys to be One Shot keys. If you didn't do this, then none of these behaviors or settings this person is talking about applies.

"I can set it to 50 presses and that makes it *less likely* to be a problem, but that STILL will be a problem in video games."

Frankly, I don't know how to explain this other than as some mix of coincidence and/or placebo. Again, this setting has exactly zero effect on anything outside of ACTUAL One Shot keys.

Furthermore, I have tried repeatedly pressing and releasing any of my standard modifier keys multiple times in a row really fast, and I cannot replicate the problem that this person is talking about. I assume you (Ellipse) also pulled a keyboard out and tried it yourself, just to make sure that we aren't both taking crazy pills here.

Now, to be absolutely clear: I do not doubt that this individual is experiencing the problems they're claiming to be experiencing. But whatever the problem is, I can say with an extremely high degree of confidence that they've found the wrong scapegoat / explanation for the cause. Furthermore, I cannot reproduce it using the exact same firmware running on one of these keyboards (likely a different model, granted, since this is an F77 I'm typing on while I assume that the person in question probably just received a Classic-style F104 or FSSK, since I assume that is what the vast majority of new keyboards going out happen to be right now). So if the problem is software/firmware, then it must be some crazy bug that's somehow unique to the one firmware for whatever particular keyboard model they've got. My guess, though, is that either it's some weird issue with that specific keyboard itself (e.g., your grounding theory, or something along those lines), or some weird issue with the particular PC they're using the keyboard with. My gut instinct says it's the latter...maybe try plugging it into a completely different PC (best if it is a different model entirely, from a different manufacturer) and see if the problem actually still occurs. If it doesn't, then we are at least part-way to figuring out what might be going on.

(Reflashing the firmware is also not a bad thing to try...after all, it's a very easy and cheap test that costs you all of 2 minutes to try, and I suppose some weird EEPROM corruption *could* in theory generate symptoms like this.)