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

[NathanA]

genericusername57 that is an odd issue, though in my NathanA Vial firmware testing of the F104 with both hands and random keypresses (far faster than 100 wpm equivalent) the solenoid kept up. Did you see if the solenoid adjustable bar was maybe misaligned/dragging on the solenoid cylinder? Did you try on a desktop, or a laptop providing sufficient USB power and with power save settings turned off?

I am very interested in this, too. I very much doubt the issue is either a physical or electrical one, because what they appear to be saying is that the problem *goes away* if the *only change* that they make is to go *back* to the old QMK firmware that you made. With all other factors being identical.

I remember others (possibly including this same poster, too...I'd have to go back and check) saying similar things about how the solenoid didn't behave correctly with early versions of the Vial firmwares I was posting, even though in theory there should have been no difference in behavior since I was using the exact same version of haptic.c, with the same default dwell time settings, as you were using in your firmwares at the time. Since I don't have a solenoid, and since so few people were making this claim and engaging me about it, it became near impossible to diagnose. And of course it's been many months since the last time somebody talked about (still) experiencing this problem with the Vial firmwares of mine. So, not a whole lot of data to go on.

But I had this very thing in mind when I specifically asked Ellipse to test the solenoid out while he was running my latest firmwares on his keyboards. He said everything was ship-shape, and I also assumed that if anything was notably off, he would have said something about it.

Right now I'm assuming that possibly & without realizing it, I managed to "fix" the issue well in the past (back when I was initially throwing things at the wall to see what would stick, but without getting any actual helpful feedback from anybody), and that the last time that this person tried Vial was one of my very first releases? As they've likely avoided trying it again since originally running into that issue.

While I could map SOLENOID commands in VIAL application I could not find such a thing in VIA app(if you know a way please let me know)

With both VIA and Vial, you can assign key codes that are unknown to VIA/Vial (either that particular version of the app if it's just too old to know about that key code, or even if the current version still isn't aware of it).

For example, the solenoid toggle is QMK key code HPT_TOG. On VIA and Vial firmwares, this is 0x5CE8 (may be different if running raw QMK build without VIA/Vial). If your version of VIA or Vial doesn't know about HPT_TOG, just configure the raw key code value on the key you want to bind it to.

In VIA: go to the "Special" section, and find the "Any" key. Then it will let you type in raw key code hex values.

In Vial: just double-click the key, and type in the hex value.

[genericusername57]

genericusername57 that is an odd issue, though in my NathanA Vial firmware testing of the F104 with both hands and random keypresses (far faster than 100 wpm equivalent) the solenoid kept up. Did you see if the solenoid adjustable bar was maybe misaligned/dragging on the solenoid cylinder? Did you try on a desktop, or a laptop providing sufficient USB power and with power save settings turned off?

I am very interested in this, too. I very much doubt the issue is either a physical or electrical one, because what they appear to be saying is that the problem *goes away* if the *only change* that they make is to go *back* to the old QMK firmware that you made. With all other factors being identical.

Right now I'm assuming that possibly & without realizing it, I managed to "fix" the issue well in the past (back when I was initially throwing things at the wall to see what would stick, but without getting any actual helpful feedback from anybody), and that the last time that this person tried Vial was one of my very first releases? As they've likely avoided trying it again since originally running into that issue.

Yes, this is probably a likely explanation. And it's very possible that I made the earlier comment you're referring to. It was easy to verify by simply flashing back and forth between the VIAL compatible one and the original QMK to confirm the firmware being the culprit of the solenoid simply not working well under VIAL. I could hit a point where it would keep up to a certain degree but it would never work well enough to not skip half of the inputs when typing fast. And believe me when I say I tried adjusting the dwell time back and forth a lot.

As for how old the firmware was I can't really answer that, I found it by searching this thread but it's possible the search result was one of the very first you made. I can't confidently say which post I got it from anymore.

However I can confirm now that your latest VIAL firmware works just as well as the original QMK one so I think this issue can be considered solved, either by pure magic or perhaps a lucky coincidence Thanks a lot again, it's so much less of a hassle to use VIAL rather than the QMK web configurator.

And to answer Ellipse, this has always been on a stationary PC without any kind of USB power saving activated so I really can't think of any other source of error rather than the firmware.

[AlexB555]

Is there anything new about the BÉPO layout (ordered 6 months ago) and the custom overlay? I know that my order is really customized and it takes longer to do. I would like to know if It can be shipped next month.

Oh yeah, with your permission, I added your F77 on Wikipedia (french) at the bottom of the page :

https://fr.wikipedia.org/wiki/CAN/CSA_Z243.200

[Rico]

In VIA: go to the "Special" section, and find the "Any" key. Then it will let you type in raw key code hex values.
In Vial: just double-click the key, and type in the hex value.

So nothing 'magical' for those special QMK codes, too bad.

[Ellipse]

AlexB555 the factory expects to receive the next order of injection molded keys early next month after they return from a national holiday break, so it may take some more time after that to finish the BEPO and additional CSA sets. The factory has run out of 2U vertical keys in pebble.

Since they had extra 2U vertical keys that were already sublimated with the US ANSI standard, they did not make these sets from my requests a while back and they instead were able to make the JIS sets that I recently submitted, which used these already-sublimated spare 2U vertical keys. Apologies it has taken so long to get the keys manufactured.

The XT quality JIS sets should arrive early next month, all current and future unfilled orders for JIS will use the new XT quality sublimated sets.

[AlexB555]

There is a custom layout for the Quebec CSA keyset called “Canadien (Standard, LaBonté)”. It's free to use, no issues. It's an improvement compared to the version proposed by defaut on Windows. This layout acheive the level of compliance C (⅛ đ ˙ ) are missing in the Windows version. Other minor changes are also made to be close as possible to the original standard (csa z243.200-92). The middle point is not a dead key and the tilde is used as a dead key on the secondary group (Ç key). The layout add also 3 other characters in the ISO 9995-3 standard, the € sign (this one is also in the windows version and in the Quebec CSA keyset by default), and the german guillemets („ ,) on the X key. The Quebec CSA keyset is 100% compatible (the dead keys are not labelled, it's more flexible). I read the official document, it wasn't completely useless.

https://drive.google.com/file/d/1xZdGDm ... sp=sharing

[AlexB555]

Is it too late at this point to submit a new SVG file for the BÉPO? I could buy the official standard Z71-300 (2019) and produce something closer to the original version. You could tell them at the factory to put this project on hold if nothing has been printed yet.

[Ellipse]

Confirmed ok to request an update of the BEPO file, please send the update in the next week or so before they go on break if possible.

If anyone wants to make any additional custom layouts or keys, now is the time as the factory will be doing a small batch of the BEPO and CSA after returning from their holiday break. Please email/PM me if interested.

[AlexB555]

Ok good.

Just a last question, can they print on the spacebar?

I expect No but I never asked directly.
If the answer is no I have an alternative (remap the menu key and use it as a second spacebar with the proper pictograms printed).

Their holiday is probably between September 29 and October 6. So, yeah, before September 28.

The official document is expensive but for the csa layout it was really instructive and helpful. The layout (.exe file) made with kbdedit is really accurate, it should be proposed with the keyset. It's a really nice version. As I said, it's based on the real document.

[Ellipse]

Unfortunately no, not on the spacebar.

[Ellipse]

We have new 1.5U size keys added to the order list today, as someone just custom requested them. Feel free to order on the extra keys page if you are interested. All keys except 1.75U keys are now $3 each, down from $4 each. Available in pebble, blue, and dark gray. They should go out later this year.

custom_keys.png (6.25 KiB) Viewed 172833 times

[NathanA]

I haven't followed the thread closely. Do the split models still function as two separate keyboards, plugged in with USB for each? Is there a proposed solution for having layers across the two halves?

In terms of getting both halves of the split ergo boards to communicate function layers with each other without software remapping or an additional hardware device like hid-remapper, the below idea was mentioned before as another possibility - would this be implementable?

It can be done with scroll lock / num lock / caps lock. You would press one of those on one device, then program the other device to do something if one of those is pressed, such as layer change.

I believe I now have a somewhat workable solution to sharing a layer between the two separate keyboard halves. Naturally, there are some caveats to be aware of, though.

The idea of using the host Num Lock status as a way to signal a layer change is something that I have floated before, in contexts outside of a split keyboard; see for example here and also here (definitely non-exhaustive).

[...] though it would be cool if QMK were modified to allow one to treat NumLock status as a method for selecting a particular layer.

But as far as I was aware, QMK itself had no native "use Num Lock status to select a layer" feature.

The example that Ellipse linked to, though, led me down the right path. You can have Num Lock status change layers if you listen for lock status change events, and then call the appropriate function for changing the layer in response. This involves adding a small bit of code to the keyboard's led_update_kb() or led_update_user() functions, which are called when the LEDs have changed and are usually used to actually update the physical LEDs on the keyboard.

This does mean that there is no way to switch this feature on and off at will. If you build a QMK firmware with this, it's always on. I'm of two minds about this. As this behavior may be undesirable to many of those using non-split keyboards, it might be prudent to only build this mod into the split keyboard firmwares. But I can also envision scenarios where non-split keyboards might also benefit from this feature (see: previous discussions about how to "best" set up the right-side block of the F77). We can always start out by just including it for the split keyboard users, and roll it out more widely if most people think it's a good idea. That, or perhaps it would be enough to add a keycode that *could* toggle this feature on and off; there just wouldn't be any way to see the status of the feature and toggle it using the Vial GUI, for example.

Anyway, here are the biggest differences about its use vs. normal layer-selection keys, as well as disclaimers that one should be aware of about this implementation:

• As it relies on only a single lock LED status, you can share at most one layer between keyboard halves. As such, it seems logical to reserve layer 1 for that purpose, and layer 2 can perhaps just be used for keyboard-specific things (e.g., Debug / Reset / EEPROM Reset, which presumably you would only want to apply to one keyboard half at a time anyway).
• It is possible for some other keyboard attached to the system, or for some software on the system, to either set or clear Num Lock, independently of you pressing the key on your split board that you intend to be your "Fn" key. Which means there are scenarios I can envision where you might unexpectedly find yourself on your 2nd/Fn layer even though you didn't intend to trigger that layer.
• It practically takes using the actual numpad scancodes out of play. For at least the split ergo models, though, I don't anticipate too many people will care, or even notice.
• With QMK's support for locking switches enabled in the firmware, you can use KC_LNUM ("Locking Num") as a means of simulating MO(1) behavior (Num Lock turns on when Fn key is held, and immediately turns off when released).
• The equivalent of TG(1) would just be normal KC_NLCK ("Num Lock").
• Instead of LT(1, [key]), you'd have to implement something similar using a Tap Dance. You'd set "On tap" to be the [key] you want to register when tapped, and "On hold" to be KC_LNUM. Then apply TD(x) to the key in question.
• Instead of TT(1), you would also have to implement as a Tap Dance. You'd set "On hold" to be KC_LNUM, and "On double tap" to be KC_NLCK. Then apply TD(x) to your key.

I'll build some updated firmware files for the two split ergo models and also modify their default keymaps to use these methods, and hopefully this manages to meet most people's needs when it comes to layer sharing on these split ergo boards. Unfortunately, anything more sophisticated than this (such as sharing multiple arbitrary layers) would likely require coming up either with a dedicated piece of software that you have to install on the host that takes care of syncing the layer selection between both halves, or modifying the two controllers in both halves to connect up to each other directly.

The final big disclaimer is that this doesn't work on Macs, at least out of the box, because Macs don't have a native concept of "Num Lock". Fortunately, I did run across a very simple open source utility called SetLedsMac, which allows you to turn on or off any of the lock LEDs on one or more keyboards attached to your system. In and of itself this doesn't solve the problem, but somebody else forked the project and made a version with an added feature that listens for a lock LED change on one keyboard, and rebroadcasts that change to all of the other attached keyboards. So if you have a Mac, all you have to do is install this little utility, et voila! I tested it out, and it worked great for me on Catalina at least.

[NathanA]

'k. Here's my implementation of having the (host) Num Lock status act as a selector (Fn key) for Layer 1.

Since it's probably going to be easiest to simply just build it into all firmwares going forward rather than selectively apply it only to certain models, I went ahead and added a method of enabling and disabling the behavior. This is because as long as it is enabled, it is mutually exclusive to regular layer selection methods for that layer; that is, selecting Layer 1 by other means (e.g., MO(1)) will not work at all if this feature is on, because the firmware will simply immediately re-detect the Num Lock state and either re-select or re-unselect Layer 1 again.

With a zeroed-out EEPROM, by default, it is off. Since neither VIA nor Vial have any clue that this exists at all, there is no UI element in either app that can be used to turn it on or off. Thus, it has to be toggled on and off by a special key code. I have assigned 0x5DFE to that function. You will need to assign that special key code to some key on some layer (advise you NOT put it [only] on Layer 1, or else it will not be reachable in one of the two modes! Layer 2 is a better option.)

It will write the status of this feature to EEPROM, both so that the keyboard still "remembers" whether it's enabled or disabled even if the keyboard is unplugged, and also so that the default state can be embedded in an EEPROM image that can be flashed to a keyboard during initial programming or later re-programming.

I'm attaching the code patch, as well as a version of the F77 firmware that contains this feature for demonstration purposes. It includes keymaps for F77 right-side block Options 3, 4, and 5 that are re-implemented to use this feature, so you can see how this works (and the feature is set to be enabled and operational immediately after flashing as well). As you can see with this demo, this feature is useful outside of simply trying to sync a Layer 1 selection state between two halves of an ergo 'board...after using it for a bit, my opinion is that this method of implementing Num Lock on the F77 with custom functions while Num Lock is "off" is vastly superior to the old method of using TG(1), because now you can actually TELL what the state of Num Lock is! (Of course, if you have no lock LEDs on your F77 -- as virtually nobody does -- then you have to use some kind of app on your PC to see what the status of Num Lock is, but at least that's actually doable!)

I'm also including my "nathana" keymap for the F77, which is what I daily-drive, and which of course is indisputably the BEST F77 keymap.

(Oh, I also now have scripts included for flashing from Mac now. If on a Mac, you run the .sh files, and if on Windows, the .bat files.
The .sh scripts should also work fine on Linux if you first replace the dfu-programmer binary in the bin/ directory with one that's built to run on Linux.)

I'll be sending Ellipse a build of firmware for the ergod*x clone that has this feature enabled & the keymaps similarly re-jiggered to use Num Lock instead, to actually test out the layer sharing between the two halves. Assuming that tests out well, I'll apply the same treatment to the F15.

[Muirium]

selecting Layer 1 by other means (e.g., MO(1)) will not work at all if this feature is on

Eep!

[NathanA]

selecting Layer 1 by other means (e.g., MO(1)) will not work at all if this feature is on

Eep!

This is not as big a deal as you think.

As I explained in the post prior to the quoted one, if you want to use this feature, then you simply replace MO(1) with KC_LNUM. KC_LNUM ("Locking Num") turns Num Lock on when held, and turns it back off when released. Therefore, it works exactly the same way functionally.

Other layer selection methods (such as TG(x), TT(x), LT(x, [key]) and the like) can similarly be reproduced in various ways. Either with KC_NLCK (regular Num Lock), or Tap Dance recipes, which take seconds to configure in Vial.

Users just have to be aware that if they *have* an MO(1) key, *and* they want to use this feature, then they need to replace it with KC_LNUM. Which is the whole point of having the feature to begin with.

But in order to make *my* job easier, so that I don't have to create separate versions of firmware for each keyboard model with and without this feature included -- which would be ridiculous -- I have a *SOFTWARE* toggle built in that allows one to turn the feature on or off in a single, unified firmware.

If the software toggle is off, you continue to use the same keymaps you have already meticulously hand-crafted, with MO(1)/TG(1)/TT(1)/LT(1, [key]) selectors.

When you *ELECT* to toggle it ON, because, y'know, presumably you actually want what the feature offers, then you simply replace those keys with the various Num Lock variants & Tap Dance recipe equivalents.

This feature only affects Layer 1. Layers 2 through n are not affected and should always use MO/TG/TT/LT.

[Muirium]

This feature only affects Layer 1. Layers 2 through n are not affected and should always use MO/TG/TT/LT.

Now I getcha.

[LuX]

How quickly is the numlock LED transmitted? Could you send short codes with it? Consider the following: instead of toggling numlock for the layers, you use it to send a code for fn up/down that leaves numlock in its original state. If it was on it stays on and vice versa, only the pattern matters. If software uses or switches numlock it won't have any effect either, for example many motherboards will turn on numlock at boot by default. You could then also have more function layers. There could even be a confirmation signal sent back to ensure the other side got the message to turn on/off the layer, etc.

[NathanA]

How quickly is the numlock LED transmitted? Could you send short codes with it?

[...potentially clever suggestion re: multiplexing multiple layer switches over the Num Lock status while also continuing to retain original intended use of Num Lock...]

It's an interesting thought to be sure, but I'm honestly not sure how feasible such a thing would or wouldn't be.

1. To be clear, my code doesn't ever change Num Lock status itself. It only ever reads the status of Num Lock, and then takes action based on that status. I attached the code in my previous post so you can take a look for yourself how simplistic it ultimately is.
2. Since I'm not spending any CPU cycles "sending" or "transmitting" anything, I have never benchmarked how fast my nonexistent code for that is able to do so.
3. QMK of course changes Num Lock status in response to keypress events (for KC_NLCK and KC_LNUM codes). How fast that underlying implementation is, dunno. A definitive answer would likely require the expertise of somebody much more knowledgeable about QMK internals and architecture than I. I doubt any of the QMK devs have ever had a reason to optimize it past having it be sufficiently responsive to a singular, manual keypress event, though.
4. Such an implementation would also need to be able to reliably receive at a good rate as well as transmit, of course.
5. In addition to QMK efficiency / optimization, the particular MCU being employed on a given controller is likely also going to be a gating factor in terms of performance.
6. Finally, the host's implementation of keyboard HID is also going to be a factor. For example, I have noticed that, on Windows, when toggling Num Lock on one keyboard, the status seems to change nearly instantaneously on all other attached keyboards. The same, however, can't be said for the Mac, where it is still "fast" (by which I mean "fast enough"), but there is a noticeable fraction-of-a-second delay that isn't observed on Windows. I have to believe that this is because MacOS has no native implementation of this, so I have to use a daemonized userland app that receives and interprets Num Lock status change transmission from one keyboard, and re-broadcast the status change to all of the others, since the native MacOS keyboard HID driver does not do this itself. This is sadly far from "real time".

So my take is that there are multiple variables involved in potential performance, and thus it's not a simple question to answer. Even if it could be made fast enough on certain host platforms, though, ultimately I doubt that it would be a good cross-platform / portable solution to the problem, thanks to the Mac. Sharing a single layer selection across keyboards on a Mac using Num Lock works well enough, but I have a feeling that trying to "overload" Num Lock in the way you're suggesting probably won't perform well on the Mac.

Would love to be proven wrong, though!

[LuX]

Thanks for the insight. I guess with most solutions maintaining cross compatibility and portability will we difficult. Personally I'm leaning to a software solution. Few years back I made an input configuration software that should be adaptable to handle two keyboards as one, with plenty of configuration options, but getting it to a state where it can be shared with others is still far away as most of it is designed around my own needs, and it'll be Windows only too.

Another idea I had relates to what Ellipse tried earlier: using a central MCU. In this case the keyboard halves are programmed to act as a "dumb" keyboard operating over PS/2 protocol (AFAIK most commercial keyboards have the ability to detect if they are plugged into USB or PS/2 and convert to it). Using PS/2 protocol at a moderate clock speed it should be possible for something like a raspberry pico to read the input of two keyboards over gpio and then act as the programmable keyboard interfacing with the computer, and this would also maintain the ability of the halves being connected directly to the computer, just without any programming, but it does require extra hardware.

[engr]

Ellipse,
Are there any plans to offer bright white and grey keysets (similar to the New Model M/Mini M colors)? Pearl/pebble keysets look good on beige and grey cases, but white/grey looks better on a black case. I have a white/grey set from Unicomp, but their print quality isn't quite as good, plus I really want these tri-lingual alphas.

[Ellipse]

engr it is possible but the minimum order value for everyone would be several thousand dollars.

[engr]

engr it is possible but the minimum order value for everyone would be several thousand dollars.

That doesn't sound too bad if there are a few dozen of people interested. Could you set up an interest form like you did for other customizations? I would be happy to order a couple of white/grey keysets. A black F104 case with white alphas and black mod/function keys (if and when pad printed keys become to fruition) would look really nice.

[RedESC]

engr it is possible but the minimum order value for everyone would be several thousand dollars.

That doesn't sound too bad if there are a few dozen of people interested. Could you set up an interest form like you did for other customizations? I would be happy to order a couple of white/grey keysets. A black F104 case with white alphas and black mod/function keys (if and when pad printed keys become to fruition) would look really nice.

NGL, I'd be all for it too. Think I asked about it here too. Would be really nice to have a set of these keys in bright white. (Without going for unicomp keys)

[Ellipse]

For the gray option, is the consensus 40% gray? 30% gray? For reference, the dark gray keys are 60% gray.

[RedESC]

For the gray option, is the consensus 40% gray? 30% gray? For reference, the dark gray keys are 60% gray.

Hard to say, Personally I'd prefer they were a lighter shade of grey so the legends were more visible but I'm not particularly fussy. My only problem is that I'm an ISO UK user so might be a moot point in the end sadly. So long as it offers good contrast to the bright white keys and I can read the legends I'm sold on the look.

[Ellipse]

Custom 3d printed legs for the split ergonomic boards:

Already there is some development, even before these boards start shipping later this month! Copying one such project below:

"I set up a GitHub repo, that includes the following files:
-image of an assembled prototype leg that I think should work with the split ortho keyboard (the screw is an M6 size)
-image render of the 3d printed part
-an .stl file for 3d printing
-an .f3d file that can be modified

https://github.com/vanhornlab/Keebs-ModelF_Split_Ortho

Also on the GitHub is a description of the prototype leg. I intend once I have it to make two or three sizes so that the keyboard tents how I like. I have a few other ideas on legs like to make a bracket with a heat inset.
Anyway I hope it helps and I look forward to the keyboard."

[RedESC]

For the gray option, is the consensus 40% gray? 30% gray? For reference, the dark gray keys are 60% gray.

Hard to say, Personally I'd prefer they were a lighter shade of grey so the legends were more visible but I'm not particularly fussy. My only problem is that I'm an ISO UK user so might be a moot point in the end sadly. So long as it offers good contrast to the bright white keys and I can read the legends I'm sold on the look.

I should also mention a pure brilliant white set of keys would also go quite well with the model M style cases. Not even Unicomp do that as standard. (although you can make special requests from them for that)

[Ellipse]

The latest air shipment arrived from the factory - some nice items in there!

Rico's Rev3 controllers (I hope to assemble and test it with the F122 prototype)

The first 5 sets of XT quality new production JIS, and a few JIS front print sets (these are now available to order)

3 each of the first new keys in pebble, unprinted (PC AT big enter, Code key, and non-stepped ISO Enter) (these are now available to order) - the factory is still working on the jigs for these new keys as well as for the pad printed keys.

The first batch of new production Round 2 beam modules (now I can assemble and take some photos of the B104 keyboard with the approved/finalized Round 2 case)

[engr]

For the gray option, is the consensus 40% gray? 30% gray? For reference, the dark gray keys are 60% gray.

I don't have a strong preference personally; the key (hehe) here is that it has to be cool gray, not warm gray, to go well with black and white.

[NathanA]

[...] the key (hehe) here is that it has to be cool gray, not warm gray

In other words, not the IBM/Unicomp "pebble" color.

If y'all move forward with this, my recommendation would be to match Unicomp's own (light) gray as closely as possible. That will make the keys more useful and versatile, as they could then be mixed-and-matched with (at least some) Unicomp caps, much like Unicomp pearl and pebble colors match pretty closely with Ellipse pearl and pebble colors.

In tangentially-related news, I'd been using Unicomp gray caps on my black classic F77 basically ever since I took delivery of it. I thought they looked great with the black. But I just switched over to Ellipse dark gray caps on the same board, which I wasn't convinced I was going to like as much, and ...frankly it looks awesome, heh.

In fact, the thought has occurred to me that I should keep the main keys as dark gray, and perhaps continue to use the Unicomp gray keys for the modifiers, to establish an inverse two-tone gray look. The main problem with this is that the fonts don't match, as Unicomp 100% re-did all of their dye-sub stencils a few years back & threw out the original IBM ones. Ellipse "light gray" caps would fix that problem...