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

[Arkku]

As I am running the keyboard on mostly Mac's, I was hoping to leverage a couple of keys for media functions (Mute, Volume +/-), and so purchased a set of media keys and configured them in VIA -- and they work perfectly when I connect the keyboard to a computer directly or via a USB hub -- yea!. Now for the wrinkle -- these same media keys do not function when I connect the keyboard to the keyboard control port on my KVM (ioGear GCS1794). I am aware of the potential idiosyncrasies associated with "special" keys and KVM's, however, I have 2 other keyboards (Wired Apple and a Unicomp for Mac) for which the media keys do get passed and function properly through the keyboard control port on the KVM.

One possibility might be that the KVM is presenting itself as a keyboard that is constantly connected, rather than the actual keyboard. If the USB HID descriptor of the KVM and/or vendor id doesn't match the way the special keys are implemented on the actual keyboard, they might end up not working. Apple's media keys nowadays are just using the keycodes of F1–F12 + Print Screen / Scroll Lock / Pause/Break, so one thing you could try is just use those, and turn off the setting to use function keys as function keys in System Preferences (it is off by default).

A more advanced way to do this is to compile a custom firmware using Apple's USB vendor id and the product id of the Apple keyboard most closely matching yours. As a bonus, you can have a real Apple Fn key if you do this (it is not possible otherwise, as it uses a vendor-specific extension page in the HID descriptor). This requires patching the firmware, though, and maybe also the VIA tools if you wish to use it (but if you're building custom firmware, you might as well just use the QMK web configurator and skip VIA). (I can elaborate if you wish to go down this road.)

[jamesborr]

Thanks for the feedback -- as it spurred on additional research on my part, specifically this from ioGear:

USB devices, specifically mice and keyboards, are each given a VID number (Vendor Identification) upon release. This VID# is read by your computers' OS's and the device installed; however, since many mouse and keyboard manufacturers hold the rights to the VID# of their product, we cannot "emulate" or "copy" it without their written consent.

At the release of our MiniView KVM II, we anticipated this to be resolved shortly; however, that has not been the case in our dealings with many mouse and keyboard manufacturers. Currently, we are only able to "emulate" a standard, full-size USB keyboard; however, keyboard shortcut keys (E-Mail, Internet, Eject, Volume, etc.) are not guaranteed to function. We do have consent with the GCS1732 and GCS1734 to emulate the functions keys on standard Sun and Mac keyboards.

Therefore, this is a good indication as to why the OEM Apple keyboard media keys work, and also probably why the Unicomp keyboard media keys also work -- as I suspect their "Mac" version might be presenting itself as an Apple keyboard.

Therefore it sounds as though a potential path forward is to have my new F77 present itself self as an Apple keyboard with associated vendor and product ID (as you pointed out). I will research further, and also dig a bit more into the QMK configurator.

Thanks!

[Arkku]

Therefore it sounds as though a potential path forward is to have my new F77 present itself self as an Apple keyboard with associated vendor and product ID (as you pointed out). I will research further, and also dig a bit more into the QMK configurator.

AFAIK there is no QMK configurator available that would allow you to compile the firmware directly with Apple's vendor id. However, you can use the configurator to download the configuration JSON file and then compile the QMK firmware locally, after you have modified the vendor id for the F77.

Short instructions for how to compile QMK on Mac:

Install HomeBrew. From HomeBrew, install at least the packages avr-gcc@9 and avr-binutils. I think these might not be in mainstream HomeBrew, but if you google avr-gcc homebrew, you can probably find the commands to install it.

I think macOS comes with Python 3 installed, if not, install the package python3 from HomeBrew. Then, QMK can be installed with the command:

Code: Select all

pip3 install qmk

Then clone my fork of the QMK firmware repository with the command:

Code: Select all

git clone https://github.com/arkku/qmk_firmware

For this use, check out the branch feature/apple_fn with the command:

Code: Select all

git checkout feature/apple_fn

Inside the qmk_firmware directory, edit the file keyboards/xwhatsit/brand_new_model_f/f77/wcass/config.h and change the VENDOR_ID and PRODUCT_ID (0x05AC is Apple's vendor id, I suggest you take the product id from the Apple keyboard you have, you can see it, e.g., with lsusb – which you can also install from HomeBrew).

In the same directory, edit the file rules.mk and set

Code: Select all

RAW_ENABLE = no

(it is useless since the utility won't recognise the keyboard with Apple's VID).

Then, copy your JSON configuration file from the web configuration to the qmk_firmware root directory. Now, if you have everything installed, you can compile it with:

Code: Select all

qmk compile my_config.json

This should hopefully produce a .hex file in the directory. You can then flash that with, e.g., the QMK toolbox.

(To update the firmware in the future, do

Code: Select all

git pull

and then compile again.)

If you use an ISO layout, Apple also swaps the key in the top left corner of a normal layout with the key next to the left shift, so you may wish to switch them back in the configurator. I generally map some key to toggle to another layer that swaps them around, in case I use the keyboard on other platforms. (You can of course also swap them in software.)

If you wish to map a key to the Apple Fn key, then in rules.mk (see above), add:

Code: Select all

APPLE_FN_ENABLE = yes

In the configurator manually enter the keycode KC_APFN for the key to map to Apple Fn. Or, if you wish to make a key that works as Apple Fn when pressed alone but as a momentary layer toggle when pressed with another key, use APPLE_FN(3) for use with layer number 3, etc.

QMK itself does not support any Apple-specific keys, the KC_APFN is a popular unofficial patch and I have added the APPLE_FN(layer) support to my fork. To map media keys, you can try QMK's media keys but there is a possibility that they might not work since that is not how Apple implements them in their keyboards. It may be that you have to instead map F1-F12 keys (see the symbols on your actual Apple keyboard for the mappings).

[sedevidi]

I got surprised today, when I began to type my password too quickly after waking the computer up. The first 2 keys where probably discarded during the calibration process, and didn't function at all in the subsequent session I openned using the laptop keyboard.
It was a bit wierd that some "random" keys didn't work at all. It took me a few minutes to realise that the keys in question where the first of my password...

[Arkku]

I got surprised today, when I began to type my password too quickly after waking the computer up. The first 2 keys where probably discarded during the calibration process, and didn't function at all in the subsequent session I openned using the laptop keyboard. It was a bit wierd that some "random" keys didn't work at all. It took me a few minutes to realise that the keys in question where the first of my password...

The calibration assumes that all the keys are unpressed when calibrating, so pressing those keys during calibration may cause them to calibrate with an impossibly high threshold. This is why my firmware (and the QMK backport thereof) tries to detect pressed keys during calibration and uses the previously-saved calibration instead, give it a try. =)

[Meowmaritus]

I got surprised today, when I began to type my password too quickly after waking the computer up. The first 2 keys where probably discarded during the calibration process, and didn't function at all in the subsequent session I openned using the laptop keyboard. It was a bit wierd that some "random" keys didn't work at all. It took me a few minutes to realise that the keys in question where the first of my password...

The calibration assumes that all the keys are unpressed when calibrating, so pressing those keys during calibration may cause them to calibrate with an impossibly high threshold. This is why my firmware (and the QMK backport thereof) tries to detect pressed keys during calibration and uses the previously-saved calibration instead, give it a try. =)

Why does it even recalibrate after the first boot if it can just save the values

[Muirium]

Good question. I’d like to know how much they drift over time, from power on to power on.

Xwhatsit’s system—calibrating on boot to one single value for every key, or a user defined override—wasn’t up to scratch for many boards, including my 3278. But losing keys at power up isn’t great, either.

How about defaulting to already stored values, and defining a key combo to hold on power up to manually perform a calibration? If you’re having problems: hold this, then release all keys. Maybe shake the solenoid or chirp the beeper and flash the AT’s LEDs.

[Arkku]

Why does it even recalibrate after the first boot if it can just save the values

The original firmware doesn't have support for saving the calibration.

My version does save it, and doesn't recalibrate if it sees keys as being held on power-up. However, if no keys are held on power-up, there are IMO valid reasons to recalibrate every time:

• The optimized calibration takes under 200 milliseconds, so "why not"
• Calibration can drift over time (it is unclear whether it will ever in practice drift far enough to make a difference, but given the above, at least we are prepared for it)
• Calibration can change due to different operating conditions (humidity, case on/off, grounding)
• Trusting the first calibration to be perfect is questionable (although I do try to detect some suspicious indicators and don't save the calibration in that case): recalibration mitigates the impact of a potential failed first calibration

However, I think if we wanted to have a persistent calibration, it would be better to do it interactively, i.e., ask the user to press each key in turn and calibrate based on that. It could also be done in the tool rather than in the keyboard itself, so we could save more info in RAM and have more resources to calculate the optimal binning. I have actually been considering doing this, but auto-calibration is a more interesting problem. =)

[Arkku]

How about defaulting to already stored values, and defining a key combo to hold on power up to manually perform a calibration? If you’re having problems: hold this, then release all keys. Maybe shake the solenoid or chirp the beeper and flash the AT’s LEDs.

Defining a key combo to perform a calibration is definitely doable (and I have such a key combo in my custom config), but it is risky to only have the calibration behind a key combo, because if the calibration is broken and you need it, there's no guarantee that your key combo will actually work.

Instead, what is being done currently is that if you hold down 5 or more keys while powering up, it will clear the saved calibration, so you should be able to recover from broken calibration by mashing all the keys (i.e., surely out of all keys at least 5 will work) to get rid of a false calibration and then restart again to perform a new first-time calibration. It would be a very easy change to stop the recalibration from happening otherwise, if people want that. But given that the USB setup delays are already longer than the calibration time, I don't really see what advantage there is compared to the current calibration. (Except if the saved calibration is done interactively, in which case you could argue that it is better than what any autocalibration can achieve.)

Edit: Of course if you are getting inconsistent results with calibration and that is why you don't want to do it, then a saved calibration would solve this if it happens to be a good one. But in such cases it would be better to fix the calibration to work consistently (e.g., adjust the threshold offset like we already did once).

Edit 2: The "being done currently" etc. above is referring to my firmware only, not the firmwares almost everyone else is using on thees keyboards. But we are talking about improving the firmware. =)

[Rico]

It has to be noted that Xwhatsit’s PCBs rely on 5V USB rail as a voltage reference.
This is not only used to drive the columns but is also used as a voltage reference for the DAC that is setting the activation threshold.
So any drifting or fluctuations over time of this 5V rail will definitely have an impact on the controller reliability.
As a personal example my own Model F77 works nicely when connected on one of my workstation USB ports but have a few keys that are randomly not recognised when plugged on my powered HUB hub.
And I know that on my USB hub the voltage is more like 5.1V and that it's voltage is not very stable.

As we don't have any control on the USB 5V rail, I am starting to think that most if not all calibrations and use case problems are due to that...

[Muirium]

Well, speaking for my two beamsprings, neither one worked at all well with straight Xwhastit, even in the very same USB port in the same laptop (late 2013 MacBook Pro) throughout their restoration. They could be stable-ish for an afternoon, but come back the next day and all hell broke loose.

Beamsprings are tricky: the design has much lower capsense signal to noise ratio than Model F. And they are all ancient, with dicy foam in my case.

So I think you’ve got a point about that rail, but it’s not the single overriding source of all error.

I loved Xwhatsit’s work at the time, and still applaud him for what he did. But even on a Model F, you were flying by the seat of your pants. The utility could get locked out at the worst possible moments, and landed me with a Kishsaver that instantly spewed a computer inundating tsunami of NKRO chaos for a bit! I can only imagine what Ellipses’s unready customers would have made of that!

But given that the USB setup delays are already longer than the calibration time, I don't really see what advantage there is compared to the current calibration.

Well, Sedevidi discovered one: mysteriously missing keys after power up. The behaviour may be entirely rational from the controller’s point of view, but humans gonna press keys and expect them to show up, whatever the computer or hub or keyboard was just doing. We don’t think of keyboards as systems so much as about a hundred simple buttons! Matrixes? Calibrations? The head gets it, but the fingers crash land first!

[Arkku]

But given that the USB setup delays are already longer than the calibration time, I don't really see what advantage there is compared to the current calibration.

Well, Sedevidi discovered one: mysteriously missing keys after power up. The behaviour may be entirely rational from the controller’s point of view, but humans gonna press keys and expect them to show up, whatever the computer or hub or keyboard was just doing. We don’t think of keyboards as systems so much as about a hundred simple buttons! Matrixes? Calibrations? The head gets it, but the fingers crash land first!

Fair enough, but that case occurred with the original firmware, not the one I'm talking about. =)

So, is there a practical situation where you press a key within 200 ms on power-up but after 10 ms? Because, like said, the saved calibration is loaded first and recalibration is skipped if a key is down at that time. This solves the need to hold down keys on boot, and at least my computers take more than 0.2 seconds to become ready so that I would start typing something normally... And if you plug the keyboard into a computer that's already powered up, I think it will take you more than 0.2 seconds to move your hands from the USB plug to the keyboard. =)

(Also, the outlier elimination I've added to the end of calibration will probably fix it so that the keys don't become non-responsive even if you manage to press a key in the critical window. But yeah, I'm now considering whether it might be better to reload the saved calibration if there is something suspicious in the recalibration, instead of fixing the outliers by assigning them to the nearest other bin.)

Meanwhile the discussion about varying USB voltages is an argument for doing the recalibration, in case the voltage differs because of different connected devices or different USB port or laptop on battery vs powered.

[sedevidi]

So, is there a practical situation where you press a key within 200 ms on power-up but after 10 ms?

That happened once in a few months. I powerup the laptop on its dock, then type my password... The firmware I use is Vial from NathanA.

Meanwhile the discussion about varying USB voltages is an argument for doing the recalibration, in case the voltage differs because of different connected devices or different USB port or laptop on battery vs powered.

My keyboard is since a few months connected to the dock, which implies a new calibration many times a day. It was previously connected to the laptop (sitting on the dock), and I used it to wakeup the computer by hitting a random key. This implies that is was almost never recalibrated... The problems I had were all related to bad spring or key placements.

[Arkku]

So, is there a practical situation where you press a key within 200 ms on power-up but after 10 ms?

That happened once in a few months. I powerup the laptop on its dock, then type my password... The firmware I use is Vial from NathanA.

Yes, that firmware does not have saving of calibration or any of the other changes I'm talking about, so we can't know whether it would have occurred had the firmware detected that you pressed a key at power-up, and the calibration on that firmware takes 2-3 times longer so the window in which you should avoid pressing the keys is easier to hit. (Also, if you are using these new model F62/F77 keyboards, the checks at the end of calibration would almost certainly have fixed the key even if you did press it during calibration. With more finicky old keyboards, the fix is less reliable.)

Just to be clear, I'm speaking only of my firmware versions (AAKBD and my QMK fork, which you have to build from source to use). Almost no-one is using these firmwares at the moment because there is no web configurator that can directly build them.

Meanwhile the discussion about varying USB voltages is an argument for doing the recalibration, in case the voltage differs because of different connected devices or different USB port or laptop on battery vs powered.

My keyboard is since a few months connected to the dock, which implies a new calibration many times a day. It was previously connected to the laptop (sitting on the dock), and I used it to wakeup the computer by hitting a random key. This implies that is was almost never recalibrated... The problems I had were all related to bad spring or key placements.

Waking up from sleep is actually not a "reboot" for the USB keyboard: the keyboard is powered during sleep. That is why it can wake up the computer with a keypress.

Anyway, it is also not my experience that recalibration would be needed in this kind of situation (or indeed, almost any situation, I guess my keyboards are very consistent and/or the USB voltages are stable). The above is thus mostly theoretical, I'm just pointing out that if there are people who have issues due to USB voltages changing (due to whatever scenario) and affecting the keyboard, then periodic recalibration is probably a good idea to at least make these changes recoverable by cycling the keyboard power to get it to calibrate.

(That being said, improving the firmware to be on average the best for everyone is trial and error, and a balancing act, so I'm not locking any final decisions here. Maybe it turns out that the best way is to only use saved calibration unless explicitly requested to recalibrate, who knows. Would need more people actually using this firmware version to have even anecdotal evidence.)

[Ellipse]

Today was the presentation in NYC on the Model F Journey - it was a great honor for the invitation and to see so much turnout and interest. I believe about 100 folks tuned in, some in person and most through a live meeting stream from other company offices.

My host hopes to be able to publicly post a recording of the talk at some point, which some folks have asked about. It was a one hour presentation and Q&A session - lots of smart questions too.

As a fulfillment update, as of now about 98% of the ordered keyboards have shipped so far (3900 out of 3990 or so), and there are also several hundred small orders from the past several months in the backlog.

[Ellipse]

Today we reached a major project milestone - 4,000 keyboards ordered!

Posting with permission a nice F77 Industrial Gray photo sent to me. The UK layout customizations include HHKB style split right shift, UK front printed keys and some blue Esc and cursor keys.

The unique cable is from https://cablelab.co.uk/

F77.jpeg (2.89 MiB) Viewed 10537 times

[depletedvespene]

I think it's been over a year since my last update. I have been working on refactoring of pandrew's QMK firmware for inclusion into the QMK official repo.

I have decided to focus only on the keyboards that I physical possess and can test. I have the Model F Labs F62 and F77.
……

Great news!

When you want to extend the coverage to F107 units, I'll gladly volunteer for that.

(my F107 is currently running pandrew's QMK fork)

[jamesborr]

Quick question: Is it just me, or are others also not able to navigate to the beta QMK configurator site, i.e.: http://35.164.28.200:5000/#/xwhatsit/br ... LAYOUT_all? (am getting an ERR_CONNECTION_TIMED_OUT message). Thanks.

[depletedvespene]

Quick question: Is it just me, or are others also not able to navigate to the beta QMK configurator site, i.e.: http://35.164.28.200:5000/#/xwhatsit/br ... LAYOUT_all? (am getting an ERR_CONNECTION_TIMED_OUT message). Thanks.

Loaded perfectly here. Might have been a slight interruption in service, if at all.

[jamesborr]

Brain fart -- my firewall blocks outgoing ports (including 5000) -- thanks for the confirmation it is still up and running!

[Arkku]

When you want to extend the coverage to F107 units, I'll gladly volunteer for that.

(my F107 is currently running pandrew's QMK fork)

If you are also interested in testing my fork with saving of calibration / improved scanning speed / keys pressed while powering up detection/recovery, send me a copy of your JSON configuration file and I can build a firmware for that. (Caveat: the calibration threshold offset may need tweaking due to more accurate calibration finding a slightly different threshold as the starting point, so the first attempt may not be perfect out of the box.)

[sedevidi]

If you are also interested in testing my fork with saving of calibration / improved scanning speed / keys pressed while powering up detection/recovery, send me a copy of your JSON configuration file and I can build a firmware for that. (Caveat: the calibration threshold offset may need tweaking due to more accurate calibration finding a slightly different tnreshold as the starting point, so the first attempt may not be perfect out of the box.)

Will you also accept a JSON file generated by Vial, not the standard QMK/VIA system? I'm not sure they follow the same format.
Since I don't change my layout anymore, and the keyboard (F77) is stable, I may have time to try or switch to your firmware.

[Arkku]

Will you also accept a JSON file generated by Vial, not the standard QMK/VIA system? I'm not sure they follow the same format.
Since I don't change my layout anymore, and the keyboard (F77) is stable, I may have time to try or switch to your firmware.

To clarify terms, "my firmware" is called AAKBD and it has the USB implementation and keyboard layers/macros/remapping/etc. written from scratch, and only the part that communicates with the physical keyboard is using small parts of QMK. To switch to that one, the layout would need to be created again (by editing a text file and specifying the layers/mappings manually).

I have also backported the Model F capsense calibration and matrix scanning optimisations to the latest version of QMK, but otherwise copying the Model F stuff from pandrew's firmware. I can easily build you versions of this QMK fork from JSON files downloaded from the QMK web configurator for pandrew's firmware.

Vial is not part of the official QMK, it seems, and I have never tried it myself. So, I don't know what difference there is or whether it will work. If you want, we can try, just send me the file. =)

[Muirium]

Have you got a thread for this, Arkku? Think I’ve always seen your work here in Ellipse’s tornado alley.

I’m still running your customised QMK, just as you sent me, and it’s working perfectly as defined. Is that a project you’re interested in maintaining as well as your own AAKBD?

[Arkku]

Have you got a thread for this, Arkku? Think I’ve always seen your work here in Ellipse’s tornado alley.

I’m still running your customised QMK, just as you sent me, and it’s working perfectly as defined. Is that a project you’re interested in maintaining as well as your own AAKBD?

I haven't made a specific thread for either AAKBD or the QMK backport thereof, no… I probably should make one for AAKBD, but TBH I wasn't really planning on maintaining the QMK version since I don't use it myself. I'm kind of hoping that my fork would be adopted by someone who wants to otherwise maintain the QMK version. =)

If I understand correctly, there are now four QMK variants for these keyboards:

• pandrew's, which supports all the xwhatit's-based capsense keyboards, including beamspring, but is based on an old QMK version
• wolfman's, which is based on the latest QMK version, supports Via but I guess only for the F62/F77(?)
• mine, which is based on the latest QMK version, has the improved calibration, saving and faster scanning, and theoretically supports all the xwhatit's-based capsense keyboards but is only tested for the F62, F77 and ones that you tried (and those not with the latest version), and doesn't support Via
• the Vial version – not sure where this is setup or is it just done by patching one of the others

I think the ideal outcome would be to unify the first three into one, i.e., my enhancements + wolfman's Via support, but I guess the difficulty is that both my changes and Via need work for all the different keyboards that are supported. But once that would be done, maybe it could even live in the official QMK repository and be collectively maintained.

Not sure what the best way forward towards that would be, though, or if there is something about my enhancements that prevents acceptance into QMK upstream (e.g., the calibration saving consumes some EEPROM space, leaving less available for Via).

[pelletik]

My enter key binds or sticks. I read the owners manual several times. The stabilizing insert is pushed all the way that it's flush to the barrel. The ears are left and right. I pulled a enter key off of a model m and installed it in my F77. The model m enter key works in my F77 and does not bind. I think I have a bad enter key. Does anyone have any suggestions to get the enter key to not bind? It's the only key that I am having an issue with.

[sedevidi]

• the Vial version – not sure where this is setup or is it just done by patching one of the others

That one was created by NathanA, who described the process a few months ago in this thread. IIRC, this is quite the same as all the other ones: based on mainstream at that time, patched with the capacitive code and some bug fixes, and provided as-is with source, instructions, and binaries for the lazy (like me).
It does have yet another USB ID, for no other reason than the bad original choice. Since then, Ellipse registered the cool ones.

[Arkku]

It does have yet another USB ID, for no other reason than the bad original choice. Since then, Ellipse registered the cool ones.

Yes, I am also using the new USB ids in mine. (And I did patch the utility accordingly as well.)

[pveentjer]

My enter key binds or sticks. I read the owners manual several times. The stabilizing insert is pushed all the way that it's flush to the barrel. The ears are left and right. I pulled a enter key off of a model m and installed it in my F77. The model m enter key works in my F77 and does not bind. I think I have a bad enter key. Does anyone have any suggestions to get the enter key to not bind? It's the only key that I am having an issue with.

I also had a problem with binding keys like enter and shift. What helped to reduce the binding a lot is to pull off the key. Flip the key and you will see 2 parts sticking out; one is the stabilizer pin which you can ignore. The other part that sticks out has 2 legs. Grab these 2 legs 'high' between your thumb and index finger so that the keycap is very close to your skin and give it 30/40 good squeezes and try the key on the keyboard. It could be you need a few rounds of squeezing to get rid of most of the binding.

The binding went from 'totally unacceptable' to 'barely noticeable. Only when you hit the key completely off center (furthest away from where you are normally hitting the key), I can feel binding with the shift; with the enter it is no problem at all.

[Ellipse]

My enter key binds or sticks. I read the owners manual several times. The stabilizing insert is pushed all the way that it's flush to the barrel. The ears are left and right. I pulled a enter key off of a model m and installed it in my F77. The model m enter key works in my F77 and does not bind. I think I have a bad enter key. Does anyone have any suggestions to get the enter key to not bind? It's the only key that I am having an issue with.

I also had a problem with binding keys like enter and shift. What helped to reduce the binding a lot is to pull off the key. Flip the key and you will see 2 parts sticking out; one is the stabilizer pin which you can ignore. The other part that sticks out has 2 legs. Grab these 2 legs 'high' between your thumb and index finger so that the keycap is very close to your skin and give it 30/40 good squeezes and try the key on the keyboard. It could be you need a few rounds of squeezing to get rid of most of the binding.

The binding went from 'totally unacceptable' to 'barely noticeable. Only when you hit the key completely off center (furthest away from where you are normally hitting the key), I can feel binding with the shift; with the enter it is no problem at all.

This is solid advice - I note a similar method as "the wiggle method" in the manual on the project web site.