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

[Muirium]

But I do get the sense that the DT audience here is made up of a larger cross-section of people who are also at least tangentially interested in "vintage tech" when compared other online keyboarding communities

I already mentioned my PowerBook G4. Let's raise the stakes with a 4th architecture:



A cookie if you can get it running on 68k!

Pandrew's 68k.png (7.64 KiB) Viewed 135216 times

[NathanA]

A cookie if you can get it running on 68k!

I have to say, I'm impressed with your pixel art skills.

[Ellipse]

In addition to NathanA's success with updating the various Model F keyboards to support Vial perfectly, Rico has made some exciting progress on the Leyden Jar Rev. 3 RP2040 controller, which is expected to be the default for the current round of the F122 and B122, and eventually for other boards when the ATMEGA-based stock is depleted. Rico's controller also works perfectly in my testing.

The current step is to get the Leyden Jar firmware working with the additional columns added with Rev. 3:

https://www.keebtalk.com/t/the-leyden-j ... s/17489/28

One big advantage of the board is increased memory with the RP2040. NathanA noted that the new Vial firmware for the ATMEGA controllers are getting closer and closer to filling up all of the available space.

[Ellipse]

I have just approved production of the dye sublimated badges. Almost no factories I asked even had the capability of dye sublimation to aluminum. They tried the UV printing option which was fine on its own but a bit fuzzier when compared directly to the dye sublimated option, as shown below. Now available to order here:

https://www.modelfkeyboards.com/product ... ng-extras/

On the production units, there will be no alignment marks and the brush marks will be horizontal like on my original IBM F122 badge. Also the sample edges appear slightly curved as they were not stamped/cut clean like with the production badges but they appear to have been cut by tin snips or a similar tool.

Also the beam spring badge images look slightly blurry because they left the protective film on the sample for the beam spring badge photos. They removed it for the Model F photo.

Another change is that they said they will not crop the bottom of the beam spring image. I initially thought it would be better cropped before the edge, but the gap just looks a bit out of place.

2023 09 10 badge samples (4) - Copy.jpg (79.57 KiB) Viewed 134927 times

2023 09 10 badge samples (1) - Copy.jpg (49.73 KiB) Viewed 134927 times

[Ellipse]

Major firmware update:

Please help test the NathanA beta, prerelease firmware (attached) which is expected to be the main firmware for the wcass controllers going forward.

I hope to submit the F104 and FSSK Round 2 files to the factory for mass firmware loading next week so I hope that folks can do extensive daily driver type testing this week. The inner assemblies all completed production some time ago and are just waiting for the latest firmware. (Also the first batch of F104/FSSK/F122 cases completed production at the case factory and will be on its way to the assembly factory this week).

Instead of flashing the specific layout you want, there is one firmware for each type of keyboard. You flash that firmware and then can configure the board for split backspace, split right shift, etc. There is expected to be future support to flash the exact firmware you want from the start if you want to save a step (also good for the factory workers as they load these en masse).

These are not yet tested on the beam spring boards so it is just Model F to start with. Currently it is good on the F62, F77, and F104/FSSK Rounds 1 and 2.

Permalink to the latest windows utility (the latest mac and linux utilities are not yet ready): https://www.modelfkeyboards.com/wp-cont ... loader.zip

Some features of the NathanA firmware:

Excellent stability in my testing
Vial support (after flashing this new firmware, you can just go to the web site vial.rocks to configure your board any time you want to change something, without needing to generate custom firmware and then reflash the firmware as with the QMK configurator web site. It works natively without needing a custom Vial program or web site or json file because the keyboard details are stored in the firmware and read by Vial). Vial even has a check mark to enable and disable NKRO right from the GUI.
Supports solenoids and LEDs
Supports pandrew's diagnostic utility which has the Signal Level Monitor and Enter Bootloader features (you need to download the latest version which is found in the manual)
And many more features

There are two versions of the latest firmware attached:
The "allpads" version is the way that I prefer, with each pad configurable right away without having to click buttons to reveal pads in Vial. There is also a helpful bat file for each board (allpads version only). Once you enter the bootloader, you can run the bat file to automatically update the firmware and restart the keyboard, no need to unplug and re-plug the cable or use Atmel Flip!
The other file has the source code with a diff file that can be executed on linux to auto build all of the firmware files on your own, if you prefer it. To run NathanA's bash script build.sh in Ubuntu, copy the folder newfxx-vial-package and all its files, then right click build.sh and select run as program.

This is what I do on a fresh Ubuntu install:
open Terminal program and enter one line at a time:

sudo apt update && sudo apt upgrade -y
sudo apt install python3-pip
sudo python3 -m pip install qmk
echo "PATH=$PATH:$HOME/.local/bin" >> ./.bashrc
sudo apt install git
qmk setup

[Ellipse]

hid-remapper current testing results:

hid-remapper is correctly passing through both keyboards' keypresses, but I do not know how to configure it to pass through the MO(1) layer key. Here's what I tried. I also tried with the Hold field checked.

The single pi pico version did not work. The dual RP2040 version worked so that is what I expect to order from JLCPCB: the v1 board here https://github.com/jfedor2/hid-remapper ... tom-boards

I tested with a USB 2.0/3.0 unpowered hub that cost a few dollars on Amazon and it worked fine; I expect to order these on AliExpress for all 50 split ergo boards. https://www.amazon.com/dp/B0C7NPS5Y9

I also tested a Plugable USB 2.0 only hub with and without external power and it worked fine. An Anker USB 3.0 only powered hub did not work.

The only oddity for all of the working hubs I tested was that you have to leave the second keyboard unplugged when you are plugging in everything else (the PCB, hub, and one keyboard). Then wait a bit and plug in the 2nd board and everything works fine. A little annoying though, but again this is only for those who want to share function layers between boards (for example, press Fn on one keyboard and a key on the other board). As noted earlier, if you just want to press Ctrl on one board and S on the other board for example, you don't need to do any of this and you can just connect both boards directly.

Would reducing this number in the QMK config fix the USB hub issues? DMA noted that the Model F without solenoid consumes about 31ma.
#define USB_MAX_POWER_CONSUMPTION 500`
* sets the maximum power (in mA) over USB for the device (default: 500)

[NathanA]

Vial even has a check mark to enable and disable NKRO right from the GUI.

My firmwares actually do not support this particular feature. Support for QMK "Magic" (now called "Command" by QMK themselves) toggles within the Vial GUI only arrived in Vial 0.6.0, and my firmwares are still based on 0.4.1, since I haven't yet managed to get Vial 0.5+ running stably on the Xwhatsit. NKRO on/off is located under this "Magic" feature. You can still control the keyboards running this firmware with the latest version of the Vial utility (0.7.1 at the time of this writing) and even the vial.rocks web site, but it can detect which Vial features the firmware does and doesn't support, and will only show the options applicable to that firmware. Thus the "Magic" tab doesn't even show up under QMK Settings.

So for the time being, to toggle NKRO on and off, similar to HPT_TOG (haptic/solenoid toggle), you still have to assign MAGIC_TOGGLE_NKRO (0x5c14) to some key on some layer of your keymap, and then press that key.

I'm guessing maybe you saw the NKRO toggle in the Vial interface while you were testing a keyboard with a Leyden Jar controller. I'm sure current Leyden Jar firmware is based on a much newer version of Vial than my wcass-xwhatsit Vial firmwares are, so I would expect that option to show up and work on the Leyden Jar.

hid-remapper is correctly passing through both keyboards' keypresses, but I do not know how to configure it to pass through the MO(1) layer key.

I attempted to explain this in a PM but I'm not sure I explained it very well.

This will never work. Period. If somebody told you that this was possible, then they were confused. And if you asked the hid-remapper project lead about this and he answered that it would, then either he didn't understand your question, or you didn't understand his response. Or both. Either way, I think you were talking past each other a bit.

MO(x) keys in QMK do not generate scancodes. Pressing MO(x) + some key stored in that layer *internal* to the keyboard will generate a scancode, of course, but pressing the MO(x) key all by itself will not.

Even if it did, there is no provision for one keyboard half to be able to "talk" to the other keyboard half when they are both plugged into a common hub sitting behind the hid-remapper. The two keyboard halves are completely unaware of each other, and can only talk to a single common host, not to each other. Thus if you have a MO(1) button on the right half, you can't hold it down and then expect to press a key on the left half & have it register whatever is internally programmed using Vial into that key on layer 1 of the left-side board.

I believe the way that this is expected to work is that the hid-remapper has its OWN set of layers that you program into IT. So the "layers 0/1/2/3" that the hid-remapper interface is referring to is talking about layers inside the hid-remapper's memory. It's NOT talking about the layers that Vial/QMK knows about. Those are two separate things.

So when you are using two QMK-based keyboards plugged into a hid-remapper, you actually have TWO completely different & separate sets of layers to think about:

1. The native QMK/Vial layers, one per keyboard, which are internal to just that keyboard and which the other keyboard is not aware of & vice-versa. Also, the hid-remapper is not aware of QMK/Vial layers, either, and has no way to be able to trigger them.
2. The layers that you program within the hid-remapper that would then be common between both keyboards, but are controlled wholly by the hid-remapper (the keyboards are not aware of these layers; the hid-remapper takes care of implementing this itself before passing the scancodes to the host computer).

In the screenshot of your config, you show mapping "Layer 1" to "Layer 1", as if the hid-remapper can pass a layer selection from one keyboard to another, which again isn't possible. This just turns out to be a nonsense configuration that the hid-remapper interface allows you to configure, because it happens to give you the same options for "Input" and "Output" and won't stop you from picking the same thing for both. But that configuration effectively does nothing.

If you want an example of how to configure a shared layer using hid-remapper, you can go to the Examples and look at the one titled "arrows act as mouse when caps lock held". First, you have to pick a key that actually generates a valid scancode when pressed to use as the layer select (so can't be a QMK MO(x) key); in this example, Ctrl. You set that key as the Input, and then for Output, you pick the hid-remapper layer # that you want that key to trigger when held. So now holding Ctrl down acts as the Layer 1 select key for hid-remapper Layer 1 (again, NOT QMK/Vial layer 1! completely separate!!!). Then for the keys that you want to trigger particular actions on that layer, you select that key as Input, make sure to select the appropriate layer checkbox on the right for that key (in this case layer 1), and then for Output you select the action that Ctrl+that key should trigger. So now Ctrl+Left moves the mouse cursor on the X axis by -0.5 units. And so on.

The only way to actually share QMK layers between split keyboards is to wire the two keyboard controllers directly up to each other, and utilize the native provisions within QMK to support split keyboards. In which case the split keyboard would only have one cable going to the host computer & it would appear as a single keyboard to the host without the need for a hid-remapper-like device.
`

hidremapper-layer-example.png (102.61 KiB) Viewed 134768 times

[Ellipse]

Thanks for this explanation NathanA, very helpful. So as to avoid using a key that would potentially have a use within certain programs (for example, Ctrl + Left Cursor moves the cursor by a whole word when editing text - I know it is just the example here - and using this sample setup would possibly eliminate that text editing functionality) I guess the trick would be to set the key in each Vial configuration not to MO(1) but to a rarely-used key recognized by QMK as a key press sent to the computer but that won't do anything on the computer, so that the hid-remapper could recognize it, and program each Layer 1 intended function in hid-remapper. For example, special key + D to send the mute command. Which keys would work best?

The down side would likely be a loss of internal QMK layer built-in functionality unless another key is set to MO(1) in Vial?

Also if it has to send a scan code anyways to the computer, it seems that a software-based remapping solution would be much simpler and have the same functionality compared to this hardware solution for what we are looking to do?

[NathanA]

So as to avoid using a key that would potentially have a use within certain programs [...] I guess the trick would be to set the key in each Vial configuration not to MO(1) but to a rarely-used key recognized by QMK as a key press sent to the computer but that won't do anything on the computer, so that the hid-remapper could recognize it, and program each Layer 1 intended function in hid-remapper. For example, special key + D to send the mute command. Which keys would work best?

Yup, either that or pick a very not-often-used key, or at least one that a particular user doesn't find that useful to them. One example might be code 0x65 "Application" (e.g., "the right-click key"), which I feel like not too many people actually use. Or maybe 0x39 Caps Lock.

It is somewhat unfortunate that it doesn't look like the hid-remapper interface allows one to specify arbitrary, raw keycodes...instead you can only pick from a predefined list. Maybe a feature request to make to the hid-mapper developer? Because then you could pick some keycode ID that is unassigned, and program Vial to send that keycode, and the hid-mapper to listen for that keycode. For example, it looks like according to the USB HID spec that 0xa5 through 0xaf are unassigned/"reserved". ...ugh, scratch that: looks like QMK went ahead and assigned those to Power/Sleep and Volume/Audio controls. Likewise, all of the ones at the end from 0xe8 - 0xff are assigned to Mousekeys. But! It looks like 0xde and 0xdf are unassigned! So those are potentially open for use...

One set of keys that hid-mapper is aware of and that virtually no modern software does anything with is F13 through F24. I know people like to have those keys available on large 122-key models, but on split ergo boards with under 100 keys, it seems very unlikely that anybody is going to assign any F keys above F12 and actually use them for something. So maybe pick some F key above 12 to use as your hid-remapper layer key.

The down side would likely be a loss of internal QMK layer built-in functionality unless another key is set to MO(1) in Vial?

Now you're getting it! Yes, if you want the hid-mapper shared layer, your choices here are either to give up a QMK layer key, OR to sacrifice up to THREE keys as layer-selector keys: two separate Fn keys (one for left, and one for right) for the QMK layer select, and then a third Fn key on either keyboard to act as your hid-remapper layer select.

Also if it has to send a scan code anyways to the computer, it seems that a software-based remapping solution would be much simpler and have the same functionality compared to this hardware solution for what we are looking to do?

That is definitely a conclusion that I'm sure some people will come to. Heck, a few here already have; for example, Mu and his beloved Karabiner.

The one potential advantage to a hardware solution like hid-remapper is that it doesn't require that you install and configure a software solution on every single computer that you might plug your split keyboards into. You can move your hid-remapper between different computers & it will always behave the same, without putting in additional work. Also, depending on which software solution you go with, a software solution can also have the potential downside that you might want your key remappings to ONLY apply to ONE particular keyboard, and not another. For example, if you are on a laptop, you might decide that it is okay to sacrifice Caps Lock on your split keyboard to do something other than Caps Lock, but you might still want Caps Lock to behave *as Caps Lock* if you press it on the laptop's built-in keyboard. Or maybe you sometimes use the split keyboard on a given computer, and at other times you like to switch over to a full-size keyboard, and you want the two boards to behave differently when used on the same computer. I don't think most software keyboard remapping solutions will distinguish between multiple keyboards plugged into a single computer in that way: to them, a Caps Lock press is a Caps Lock press, regardless of which keyboard it happened on.

[Ellipse]

Given the trickiness I went through in my testing of the hid-remapper solution involving the PCB, a USB hub, plugging in the second keyboard only afterwards, etc. I think the solution of the software remapping with an unused key that you specified would probably be the one I recommend as easier to set up and use, but I can link to the hardware-based solution for those who are interested in it. The hardware cost is low (2 picos, some wiring, a micro USB cable, a $4 USB hub, and a micro USB OTG cable that is micro USB male to usb female; alternatively my above-linked USB hub includes adapters for micro USB so the OTG cable is not needed). Having to do the series of unplugging and replugging every time the computer is restarted seems not as tenable.

Which of the main software-based remapper solutions on Win, Mac, and Linux work with assigning F13-F24, 0xde, and/or 0xdf while supporting all of the various keycodes?

[NathanA]

Which of the main software-based remapper solutions on Win, Mac, and Linux work with assigning F13-F24, 0xde, and/or 0xdf while supporting all of the various keycodes?

I don't use one myself (except Karabiner occasionally on my Mac laptops when I've wanted to have that stuuuuuuupid Fn key in the lower-left act as Ctrl instead), so hopefully somebody else with more knowledge and experience with the available options can step in. Aside from Karabiner on Mac, on the Windows side the only one I have a passing familiarity with is AutoHotkey, which is less of a point-and-click solution and more of a scripting language. Whether either app is suitable for the purpose being discussed here, unfortunately can't say.

[RedESC]

I hope to submit the F104 and FSSK Round 2 files to the factory for mass firmware loading next week so I hope that folks can do extensive daily driver type testing this week. The inner assemblies all completed production some time ago and are just waiting for the latest firmware. (Also the first batch of F104/FSSK/F122 cases completed production at the case factory and will be on its way to the assembly factory this week).

Oooh, that's good to hear. Any reviewers to watch out for who are getting these early batch boards? (Especially the F122)

[NathanA]

Packaging up a second Model F firmware release. Any feedback so far on the ones Ellipse posted? No news is good news?

[Ellipse]

RedESC no one has reached out specifically for the F122 but some reviewers are interested in one of the new Model M style case boards without finalizing which one they want.

If anyone can reach out to the various reviewers on their social media it would be much appreciated. This would help get the word out about the new project. It's likely that many of the reviewers became aware of the project through these contacts.

[RedESC]

RedESC no one has reached out specifically for the F122 but some reviewers are interested in one of the new Model M style case boards without finalizing which one they want.

If anyone can reach out to the various reviewers on their social media it would be much appreciated. This would help get the word out about the new project. It's likely that many of the reviewers became aware of the project through these contacts.

Sounds like something Chyrosran22 would be into. Surprised he hasn't got in touch regarding it. Big keyboards is kinda his thing. Especially if they're mechancal and built anything like the previous ones you have made.

[dr_xadium]

Sounds like something Chyrosran22 would be into. Surprised he hasn't got in touch regarding it. Big keyboards is kinda his thing. Especially if they're mechancal and built anything like the previous ones you have made.

I seem to recall him saying he no longer purchases keyboards for review; he only reviews units that are sent to him, so that might be why.

[RedESC]

Sounds like something Chyrosran22 would be into. Surprised he hasn't got in touch regarding it. Big keyboards is kinda his thing. Especially if they're mechancal and built anything like the previous ones you have made.

I seem to recall him saying he no longer purchases keyboards for review; he only reviews units that are sent to him, so that might be why.

Nah, think he has bought one of these. Either that or he already has a deal in place for a review sample based on his latest twitter reply. Looking forward to seeing his opinion of it and VIAL. (think the Leyden Jar is mostly setup for VIAL instead of QMK/VIA if my understanding is right)

[dr_xadium]

Sounds like something Chyrosran22 would be into. Surprised he hasn't got in touch regarding it. Big keyboards is kinda his thing. Especially if they're mechancal and built anything like the previous ones you have made.

I seem to recall him saying he no longer purchases keyboards for review; he only reviews units that are sent to him, so that might be why.

Nah, think he has bought one of these. Either that or he already has a deal in place for a review sample based on his latest twitter reply. Looking forward to seeing his opinion of it and VIAL. (think the Leyden Jar is mostly setup for VIAL instead of QMK/VIA if my understanding is right)

Oh that's great then! I always love his reviews and can't wait for him to get his hands on one of these.

[Ellipse]

Yes, I hope that Chyrosran22 will be able to review one of these M Style boards but which size of board to review I don't think was decided just yet.

[Rico]

I could half test NathanA work.
It is not an extensive test as my XWhatsit controller is currently desoldered (I have a Leyden Jar Rev 3 controller soldered on my F77).

Installed new_model_f-allpads-vial_r4b1.zip
Thanks to the provided .bat files the flashing procedure is pretty straightforward.
Could test that Vial was correctly detecting the board and that Pandrew utility what also detecting it.
Pandrew utility could make the board go to the bootloader and go to the signal level window (not much information for me as the controller is detached).

Good work NathanA !

[NathanA]

Yes, I hope that Chyrosran22 will be able to review one of these M Style boards but which size of board to review I don't think was decided just yet.

I know that you really like the vial.rocks web interface. But I don't have a good read on whether Chyros loves, hates, or is indifferent to web-based configurators. However, I have a feeling that it's probably not indifference as he seems to have strongly-held opinions regardless of what those opinions are (I can relate ). Therefore, regardless of what you send him, I would make sure to be explicitly clear that he has his choice: he can use vial.rocks to configure his keyboard, OR he can download an app that can be used to configure the keyboard OFF-LINE by going to https://get.vial.today/download/

Good work NathanA !

Appreciated!

[NathanA]

Given that I have not been made aware of any glaring issues with the prerelease copy posted by Ellipse earlier, I'm ready to announce a Release 4 of my Vial firmwares for the Model F Labs series of F-model keyboards.

I still consider this something of a prerelease, as it is still missing some things packaged with prior releases; most notably, the complete set of preconfigured layouts for the various different board models. I intend to release a more full-featured package in the future that re-adds those things back in, but as the new keyboard models are going to be shipping out soon, I wanted to get this out the door ASAP for everyone's benefit. I guess you could consider it a "release candidate" in modern software release parlance, as I actually just took my "beta 3" and quickly renamed it, stripping the "b3" part out of most things. Or perhaps I will call this the "Release 4 Limited Availability" edition, following IBM's own footsteps with OS/2 2.0 LA. (It's a good story, which you can read here if you are so inclined.)

For the moment, the package with the source code patches & the one with the binaries and flashing scripts remain separate as well, and I intend to also eventually combine those, as well as throw together similar flashing scripts for MacOS to be included. If what you're interested in is just the hex files, you can just grab the "new_model_f-allpads-vial_r4.zip" file; if you want to set up a build environment, get the patch set, and build your own from source, get "newfxx-vial-package_r4b3.7z" (sorry about the confusing names for now).

This also doesn't yet include any beamspring board firmwares, either. I hope to do something to properly support those in the coming weeks.

Rough changelog (such as it is):

• Changes in r4b1 (from r3):
  • Basing patches off of most recent (at time of release) xwhatsit code and keyboard definitions from pandrew's repository.
  • Adds FSSK, FSSKr2, F104, and F104r2.
  • Additional increased stability, by taking a page out of Arkku's book & moving the KEYBOARD_FILENAME (which the pandrew utility uses to determine the exact keyboard model & thus the layout and matrix mapping) into AVR program space, freeing up tens of bytes of precious SRAM. This seems to have eliminated any remaining (likely stack exhaustion/overload related) known stability issues.
  • Vial EEPROM header "magic" ID computation changed, to allow for writing raw keymap definitions directly into EEPROM during MCU programming.
• Changes in r4b2 (from r4b1):
  • Adds F50, F15 Ergo, and FOrtho(linear) Ergo.
• Changes in r4b3 (from r4b2):
  • Added "Show Extra Nav Pads" Vial layout toggle to FSSK and F104 models.

[mmm]

Congratulations!  You are one of the top bidders and you have won the Dutch/reverse auction that started earlier this year.  My apologies for the delays on my side to get everything together ready to go.

Secret winners' link (please do not share):
https://www.modelfkeyboards.com/product/f15-split-ergonomic-model-f-keyboard/

As a reminder, with a dutch auction everyone is paying the same price, which is the lowest price that all of you bid.  Limit 2 F15 boards per winner (you can also win each of all 3 models though).

The deadline to complete payment is the end of this month, 9/30, but if you need more time please feel free to reply and request it.

Please see the product pages for some important updates, recommendations, and important notes.  The main new feature is built-in Vial compatibility for all 3 models, thanks to great efforts by NathanA over on the Deskthority forum.  Vial is an open source GUI-based layout configuration option that allows you to use the website vial.rocks or the open source Vial program to configure your layout without having to reflash any firmware, a big savings on time.

In terms of the low/custom serial add-on, currently all serial numbers are available and any 7 digit number is acceptable, as well as any production date and year.  The web site allows you to directly order the first 20 or so serials.  If reserving a serial, you have 30 minutes to check out while the serial is reserved to you.  If a serial is greyed out, that means someone else has reserved it in their cart or has successfully placed an order with the serial.  As always, low serial numbers outside of the listed ones are requests and you agree to accept another serial without a change in the cost if yours is unavailable (420 and 1337 tend to go early on for example).

As a note, the final auction price may be a little higher than what a few of you bid.  I am offering a few extra waitlisted folks the ability to order the board at the auction price before everything opens up to the public for the last remaining units (if any are left) that will go for the full price instead of the discounted auction price.

And please do post / send me photos of your setups with these new keyboards after they arrive!

Sincerely,
Joe

Received this mail this morning. My bid was 9% of the "..the final auction price which may be a little higher than what a few of you bid".

I wonder how many people bid at or above quite beefy price I am offered for it. My guess would be far less than the 40 the original page stated. Not stating the price/link out of courtesy, that's up to Ellipse.

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?

[Human]

Received this mail this morning. My bid was 9% of the "..the final auction price which may be a little higher than what a few of you bid".

I wonder how many people bid at or above quite beefy price I am offered for it. My guess would be far less than the 40

Yea, my winning bid was noticably lower too. I suspect the delay was due to lack of bids exceeding a desired threshold. It is very suspect that the winning price has a common suffix used for sales, e.g. "99" or "49", instead of something more likely to be submitted through an auction form, like "00" or "50".

Curious how much above cost they set the price.

[Ellipse]

Yes, the winners just went out today for the 3 custom projects. Apologies for the long delay in wrapping up these auctions. As noted at the start of the auction earlier this year, for the ones with 50 boards, pricing would be set around the (less than 50th) highest bid, with the remaining boards to be open to the public, for those who prefer not to bid or who did not hear about the project in time to place a bid.

For the winners announcement I have also included some bidders who bid below the final price, as noted in the email that was posted, in case they still wanted to bid before the project opens up to the public.

I lowered the final bid prices $1 from what the final amount was; that's why it was set to end in a 9. The Split Ortho finished at $649, the F50 finished at $399, and the F15 Split Ergonomic keyboard finished at $499.

Before the announcement email went out, I posted some updates to the winners' product pages, copied below. If any details are erroneous and need updating please do let me know so I can update the pages.

September 2023 update: Thanks to the great work by Deskthority forum member NathanA, these boards all have the open source Vial firmware as the default, which means you can use the Vial program or go to the web site vial.rocks to configure your keyboard. Both options automatically recognize the keyboard, no need to download any configuration files.

Regarding key combinations: the boards use separate controllers that do not communicate with each other, which means that only keys with scan codes sent to the computer can produce key combinations. You can’t use internal QMK keys like MO(1) for cross-keyboard keypress combinations. This does not affect 99% of what most folks do. For example, you can click Ctrl on the right side keyboard half and click S on the left side to send Ctrl+S to the computer without doing anything extra. You can’t click a key designated as Fn or MO(1) on one half and another key on the other half, since the Fn key press is not sent to the computer but is only used inside the QMK controller.

Recommended option: use the built in tap keys functionality instead of the old function layers, or use that half of the board’s function key for function layers on that board. Tap keys example: you can set the 1 key to send “1” if pressed normally, or “F1” if pressed and held down for a slightly longer amount of time that you can customize. Included by default in the firmware – all you have to do is configure it.

Software remapping: AutoHotKey, Sharpneys, Keytweak on Windows. Karabiner Elements on Mac. xbindkeys, xmodmap, autokey, keyd, kbct, kmonad, interception, xmodmap, setxkbmap, xkeysnail on Linux. In Vial, set one key on each keyboard to an unused scan code (such as F13 through F24, 0xde, or 0xdf). Then in software you can configure a keypress combination of that key plus another key, in order to produce a specific output like volume mute, skip track, etc.

hid-remapper: based around using 2 Raspberry Pi Picos and a USB 2.0 hub. Both keyboards plug into this device and you can program function layers with it. It still has the above limitations (can only work with outputted scancodes) so it is only recommended if you cannot use the above software-based remapping solution. See the Deskthority forum thread for additional details and limitations of each option (no option is perfect).

[Ellipse]

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.
More info: https://www.reddit.com/r/ploopy/comment ... ball_nano/
"

Does it have to be a LED lock or can it be another key like F13-F24 or the two unused scan codes as discussed before? My thinking was that if you press and hold a num lock key that sends caps lock to the computer, it may enable the num lock functionality if you have a second connected keyboard that is full size and rotate keyboards around. Maybe they were suggesting a lock state option so that you could press and release the key, and then have a new layer as is done with the Num Lock and Num pad for example, but I would think that most folks just want to press and hold a key to activate the function layer temporarily on the other keyboard, only while the first key is held down.

Source: https://www.reddit.com/r/olkb/comments/ ... k_devices/


"There are a couple ways layer states can be communicated between QMK devices.

The simplest is for layers that have associated led indicators defined in the HID spec (Num Lock, Caps Lock, Scroll Lock, Compose and Kana). qmk feature_led_indicators 1. Any time the state of one of those keys changes, all usb connected keyboards receives notice. I’ve used this method to trigger layer changes and it happens virtually instantaneous. Scroll lock is convenient for this since the key has become unused. Scroll_Lock Other_uses 1. You can also program a qmk device to change layers only when an led indicator is toggled very quickly, faster than a human can tap.

Qmk also has the Raw HID feature which allows for bidirectional communication between qmk and the computer. I haven’t explored this myself, it would probably require the computer to actively relay messages between qmk input modules."
Source: https://community.frame.work/t/how-can- ... s/28812/11

[genericusername57]

Given that I have not been made aware of any glaring issues with the prerelease copy posted by Ellipse earlier, I'm ready to announce a Release 4 of my Vial firmwares for the Model F Labs series of F-model keyboards.

I haven't had the chance to try them yet as my Model F is at work, safe from being questioned by my significant other both in terms of noise and cost, but I'd be thrilled to have a VIAL-compatible firmware where the solenoid works well. This has been my issue previously, it's just completely impossible to get the solenoid to keep up regardless of dwell time. Flashing the standard QMK firmware makes it keep up with my typing speed (which isn't impressive at all, around 100 WPM normally).

I'll give it a spin next week for sure! Thanks for the work you're putting in!

[mmm]

Yes, the winners just went out today for the 3 custom projects. Apologies for the long delay in wrapping up these auctions. As noted at the start of the auction earlier this year, for the ones with 50 boards, pricing would be set around the (less than 50th) highest bid, with the remaining boards to be open to the public, for those who prefer not to bid or who did not hear about the project in time to place a bid.

For the winners announcement I have also included some bidders who bid below the final price, as noted in the email that was posted, in case they still wanted to bid before the project opens up to the public.

So there are 50 units, the price is set after the lowest bid of the top 50 bids - this leaves one unit per "action winner".

But two units is available per customer, this leaves half a unit per "action winner" (bold assumption here, that everyone would buy two though).

And then additional people has been offered to purchase it, which leaves less than half a unit per auction winner.

It's a bit rude to the 50 hypothetical auction winners to make it essentially FCFS (within a limited pool). But hypothetically speaking, the auction winners might be hypothetical and won't mind anyway.

[Ellipse]

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?

mmm not sure if you read the notes on the product page from the beginning of the auction, but the pricing is set for the top ~40 or so winners, not the 50th best price, the purpose of which was to offer additional keyboards to non-bidders later on.

The F15's might end up having more extras available than the others since it received fewer bids relative to the number of available keyboards, so folks could order two of those but winners can only order one of each of the other two types of keyboards.

Not to worry, everyone who won will get a board if they send in the order by month end. Given what I have seen, very few folks will be ordering two boards - they are already pretty costly to begin with.

[Rico]

Think the Leyden Jar is mostly setup for VIAL instead of QMK/VIA if my understanding is right.

You are totally right!
I feel like VIAL is the best solution for XWhatsit and Leyden Jar controllers.
VIAL automatically detect your keyboard while for VIA you need to go to the hassle to add controller support into official QMK: having done that once on another project the procedure is quite long and tedious even for a very simple firmware, as both XWhatsit and Leyden Jar firmware are quite complex this may take ages.
In QMK defense, looking at every bit of code, formatting and ensuring conventions are well respected is mandatory for such a big project to remain clean and stable... and QMK maintainers are awsome people !

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), another reason why I prefer VIAL.