Chrisoft

To answer the question in the title – I don’t know. If you know me, I’m not a big gamer, let alone a hardcore one. I don’t play any game that requires extremely responsive input, or many simultaneous key presses. And I’m very satisfied with the keyboards that I already own (see the background section for some of them). So I have no use for a high-end custom keyboard besides the customization part… which I guess is what I was shooting for?

Disclaimer

I don’t do keyboard reviews on a regular basis. I certainly can type faster than many of your average YouTube keyboard reviewer, but I’m nowhere close as knowledgeable on this topic.

Also typing feel is nothing but subjective anyway.

Some background

As I mentioned already, I’m not a big gamer. My main use case for computer keyboards is the original purpose they are designed for, that is, text entry.

I was semi-professionally trained on speed touch typing back when I was 8. It was the bizarre time when programming contests for youngsters in China had a speed typing component [1]. I spent hours and hours practically every single day on the computer just to type out the same passages again and again. At the time I was able to reach a bit over 500 CPM, or roughly 100 WPM. I wasn’t able to improve further because I made too many dramatic finger movements – minimizing finger movements seemed pretty difficult for me, and I insisted on bottoming out every single key stroke. This remains true to this day. I gave up on the training completely as soon as the typing component is later removed, and of course my typing skills have been in a steady decline ever since. Right now, I’m able to type at a miserable ~85 WPM [2], and that’s only possible when the stars are aligned. But that’s more than enough for me, because it’s still way faster than the speed my brain is capable of conjuring up the things to type.

I’ve used a lot of different keyboards over the years, most of them rubber dome [3]. The keyboard I was trained on was the horrendous OEM keyboard shipped with Lenovo business computers (back when they were still named “LEGEND”). They were mushy [4] and tend to become disgustingly filthy after extensive use, which they absolutely were because that was the computer room of the elementary school I attended.

Another rubber dome keyboard I used that was impressively bad was again, unfortunately shipped with a Lenovo machine, this time my family’s second home computer. The typing feel on that keyboard can be pretty accurately described as “poking at semi-moist mud” – once a key wasn’t pressed for a while, it would “solidify” and would require excessive force to trigger, otherwise it’s just, again, mushy. It also features the awful flat keycaps before modern chiclet keys completely took over the OEM keyboard scene. Separation between keys was extremely poor because the keys were simply too short.

Commendable rubber dome keyboards that I’ve used do exist, and they would have to be those found on ThinkPad laptops. In fact, these are the only keyboards on which I can achieve my ideal WPM nowadays. These provides the crispest tactile response I have ever felt on laptop rubber dome keyboards. I don’t have a clear preference between the classical 7-row keyboard and the newer chiclet 6-row keyboard with 1.8mm of key travel in terms of typing feel. However I do think the 7-row has better inscription markings as well as a layout that makes more sense, and that those travel-reduced 6-row keyboards made after 2020 are a disgrace. And of course, these keyboards feature my favorite implementation of the pointing stick – TrackPoint my beloved.

The first mechanical keyboard that I spent a significant amount of time with was the Cherry G80-3800 (a.k.a. MX-Board 2.0) with Cherry MX black switches. It was cheap – because that was all I can afford when I was in college. For the longest time I was typing on mushy rubber dome keyboards, so I decided to go with their stiffest switches, and they definitely didn’t disappoint. Build quality was nothing special considering it was so cheap. Contrary to many opinions found online, I actually didn’t mind the flat keyboard profile and the height-reduced keycaps, because they a) didn’t affect key travel, and b) had proper separation between keys.

I got my first IBM Model M keyboard in March 2018. It was a later model with part number 1370477, manufactured 1995-07-20. I picked this up for practically nothing (less than the equivalent of US$20 spent), and rescued it from its miserable condition it arrived in. I was looking for a Model M specifically because I was mildly annoyed by people in the lab making the clicky-clacky sounds with their “gaming” keyboards that used blue Cherry MX switches, with the expectation of completely subduing them with the majestic sound of buckling spring on a solid sheet of steel. To my surprise the noise made by it, despite being psychoacoustically louder, wasn’t as obnoxious as the noise emitted from blue Cherry MX switches, perhaps due to its lower pitch. It almost sounded like music to my ears. So that plan completely failed [5]. Yet I instantly fell in love with the tactile feedback of the buckling spring mechanism. Built like a tank, I suspected the keyboard is capable of turning into a murder weapon if prompted [6]. I daily drove this keyboard until we were forcefully parted ways because some dumbass mistook it as e-waste and sent it to the recycling center. I have since acquired a second Model M with P/N 1391401 and mfg date 1989-01-25. It has some imperfections (which I may address at a later date) but I swear we’re never parting ways this time.

Both cubicles belonged to me. The Cherry MX board 2.0 and my first IBM Model M are visible in this photo.
Taken 2018-06-29.

KFA Freebird 75

Why?

I was aware of the existence of the custom keyboard business long before I had any kind of interaction with it. In fact the “gaming keyboards” used by my lab mate mentioned earlier was a custom one. Later it became known to me that hardcore gamers were raving about reviving switch technologies that were long dead in keyboards such as magnetic sensing (hall effect switches) and optoelectronic switches. Features that are once for the elite like NKRO can be found even in peasant-level keyboards nowadays.

I actually came into contact with the custom keyboard business when I was looking into modding my second Model M, specifically I was looking for remapping a few modifier keys and maybe cut an additional opening [7] in the case so that it can house a small desk clock made by me – in my eyes there’s way too much empty space on the back of the Model M to be wasted. I read through a few articles on creating custom QMK-compatible controller boards for the Model M, and decided that it was entirely within my skill set to make one of my own. So I started looking through the source code repo of QMK. But my chaotic evil brain soon decided to wander off and I found myself browsing the list of keyboards that are already supported by QMK.

While doing so, I was absolutely stunned by the aesthetics people could achieve when they build their custom keyboards. After digging myself deeper and deeper in the rabbit hole for a few hours, I impulsively decided to make a purchase.

What?

But here comes the problem – I have no prior experience with custom keyboard DIY whatsoever. I don’t even know what do you need to build a newfangled mechanical keyboard [8]. Nor do I understand many of the terms used by this community: TKL [9], mount, POM… After doing a fair bit of research, I decided to purchase the following components:

• $199   Freebird75 full kit by KeebsForAll (lilac/hotswap ANSI/Aluminum switch plate)
• $ 31.2 KBDFans Green & White Blank Cherry Profile Keycaps
• $ 85.5 kfaPBT Forest Watcher Keycaps by KFA X Captain Sterling
• $ 36   Cherry MX2A Black Linear Switches

I remember going through the component listing of the kit multiple times to make sure that was all I needed (I still failed despite the effort made), and making the conscious decision of not using any additional lubrication on the switches – it would make the build excruciatingly long and the benefit seems diminishingly small to me. I chose black Cherry MX switches because of my familiarity with its characteristics. The reason I got two sets of keycaps is that there was no indication in the description of the Forest Watcher set that it would contain a set of alphanumeric keys without hiragana markings. [10] I personally don’t speak Japanese, or have plans to learn Japanese, nor do I find having markings for a language that I don’t know on my keyboard “cool”. So I decided to supplement it with a blank set that has a similar color scheme. [11]

Now I want to talk about the vendor I bought from – KeebsForAll (or KFA for short). I, as I always do, did my due diligence on this company. Turns out they actually have a pretty bad reputation among people in this community, especially from people purchasing a pre-order item from them. Among the criticism of this company I saw, long shipping times and unresponsive customer service seem to be the two most common ones. “Well,” I said to myself, “I’m not doing a pre-order anyway. And hopefully I won’t need customer support.” I was wrong.

Fortunately for me, the items shipped pretty fast: they sent a tracking number after 2 days and I was getting tracking updates the day after that. The package arrived roughly a week after my order was placed.

As I was unboxing the kit, I was greeted with the dreaded words “made in China” [12] and a few markings in Chinese. Knowing personally a few mechanical keyboard enthusiasts from China, this didn’t surprise me at all: they’ve told me that there’s a huge market for custom mechanical keyboards in China, and it’s already the country pumping out the most plastic crap anyway. What did surprise me though, is that there’s no instructions whatsoever in the package, and better still, that I realized something was missing after unboxing everything – there’s no stabilizers in the kit! [13][14] So I looked around for a stabilizer set that’s good for a beginner build, and I placed an order for the following:

• $10.99 DUROCK Stabilizer V3 Smokey Black 80% Kit

I patiently waited for the package to arrive. Meanwhile I searched online for build instructions. KFA’s official website only provided two heavily edited videos, one of which being a 10-minute review, the other one being an edited down Twitch vod. Neither of these shows how to install the stabilizers. After some more digging, specifically searching for how stabilizers should be installed, I finally found a few videos clearly showing how the type of stabilizers I bought are supposed to be installed. I found this community has a severe lacking of written guides (despite spending hours on the wiki page of r/MechanicalKeyboards) – a lot of stuff is only available as videos, which is something I really, really despise.

The dread

Quality of the kit

There’s not much to nitpick on the quality of the kit – it better be perfect cause it’s so frigging expensive.

According to the specs on KFA’s website, a fully built keyboard in this shell weighs up to 5.5 lbs (2.5 kg). However, the numbers on their website are inconsistent. On another page where all models in the Freebird line-up are compared against each other, the Freebird 75 is listed as 4.6 lbs (2.0 kg). Mine weighs 1.9 kg when it’s fully built. Despite the inconsistencies and inaccuracies, that is still some substantial heft, considering my 1989 Model M is “only” ~2.3 kg, and that one is a full size keyboard. The CNC manufactured case appears to have very high quality, at least visually. The switch panel is shipped secured to the top case with screws [15]. All screws use hex bits. Two different kinds of screws, differing only in length, are used for the entire assembly.

The PCB came in an anti-static bag. The board design makes sense. There doesn’t appear to be any flux contamination or other kind of residual grossness on the board. Switches are held on the PCB with sockets manufactured by Kailh, a Chinese solution provider known by this community for their clone of Cherry switches. The controller is an ATMega32U4.

The switches came in a large, silver resealable bag. Not sure if the bag is capable of dissipating static charge, but I reckon that’s not so important for switches. They were subject to the violent handling in the shipping process. Some switches came with their pins bent, but that’s not a difficult fix.

The keycaps looked mostly good. There’s nothing to say about the blank set. The forest watcher set looked gorgeous on first sight: the color is extremely vibrant, inscription printing is crisp and clear. It even came with a set of alphanumeric keys without hiragana markings [16]. However there are some (literal) rough edges on the bottom of certain keys, mostly near the corners. These are definitely noticeable if looked at closely, but the crappy camera on my cellphone couldn’t quite capture it.

There are some quality (or maybe design) issues that didn’t become apparent until the keyboard was fully assembled. They will be brought up in the next section.

Key switch sockets and PCB details

Controller details

The assembly

Again, there was no instruction supplied with the product whatsoever. However, once I knew where each part goes into, the actual assembly was not difficult – if only a little bit tedious, mainly due to the number of switches and keys I had to install. The entire process took me a solid 90 minutes – including the time wasted when I found out I inserted one of the stems on a stabilizer set backwards.

There are a few issues that only became apparent after the keyboard was fully assembled:

• The top case and bottom case don’t fit perfectly. Sides of this keyboard aren’t perfectly flush for this reason. This is kind of a nitpick but is in my opinion still worth mentioning.
• The PCB is held in place with nothing but the switches on the switch plate. There’s no fasteners between the PCB and the switch plate or the case. As a result, the keys will sink a bit if it’s pressed slightly harder. The effect is especially pronounced for keys near the corner. This seems to be a deliberate design choice, as some people see this flex as desired behavior [17]. To me however, this is more like a design flaw – you would never see a Model M flex like that. Again though, not a huge deal, because you really need to push pretty hard to make the flex visible.

Layout

The keyboard layout I decided to use is strongly inspired by the layout of ThinkPad’s 6 row keyboard. Some keys that are seldom used are replaced with what I see fit. Notably:

• Right Alt -> Fn. The Fn key is set to replicate the functionalities of ThinkPad’s Fn row. It also provides other keys that are not present on this keyboard using a ThinkPad-inspired mapping, e.g. Fn+K -> Scroll Lock.
• CapsLock -> Super. [18]

As a result, some oddities exist in my layout:

• As there’s no key in the keycap set marked Super that fits into CapsLock’s position (which is 1.75u wide), I used a keycap that’s marked Control instead.
• PrintScreen key only comes in one profile in the Forest Watcher set, and it’s supposed to be used in the first row. Using it in the final row makes it stick out like a sore thumb. So I surrounded it with two keys with the same profile, one of which being a novelty key from the Forest Watcher set. [19]

I might try out some small tweaks to the layout in the future.

Absolute chaos

After installing all switches

The fully assembled keyboard. Neat.

Typing feel

Well, it’s the familiar, trusty Cherry MX black after all, not some light linear switch nonsense. I wish I could have bought some linear MX grey switches as well, just to see whether I would like an even stiffer switch. But I can settle with what I have now. It’s certainly not as stiff as the Model M, and it doesn’t have the satisfying tactile feedback midway of the travel [20]. But the typing experience is still something I can fully enjoy.

The sloped design is also something I have to become used to, as I have become so accustomed to typing on laptop keyboards over the last few years. FYI when I was using the Cherry MX Board (which has no slope at all), I wasn’t using the kickstands on it either. IBM keyboards are also sloped, but they are more like “curved” rather than sloped [21] and seems slightly easier to handle for me.

For this reason, it came back as a surprise that I was able to reach the upper limit of my WPM on this keyboard. Sure I know 10fastfingers.com isn’t the best typing test, now shove it.

Slow typing.

Sound profile

If there’s anything that I don’t really like about the keyboard, it would be its sound profile. The sound can be pretty accurately described as a LEGO brick-like sound. A very high-pitched, crisp sound of plastic, it is unmistakably made by the keycaps – after all the switches by themselves are basically silent. To be fair this sound profile seems pretty common on this type of keyboards. This sound will be heard whenever you strike the key with your finger nails, when the key bottoms out, when a key returns to its normal resting position, or even when swiping the palm across the keys causing the keys to slightly wobble (as the switch stem’s fit inside the switch housing isn’t the tightest). Again, the IBM Model M would make a similar kind of sound in all those scenarios, and its is even technically louder (with the distinctive “ringing” of the spring which this keyboard lacks). But the pitch on the Model M is much lower, making it not as annoying to deal with in my opinion.

Here are some sound samples of various keyboards that I currently own. The typing test were recorded as I typed out actual words, rather than simply hitting random keys on the keyboard. Key sounds were made by swiping my finger tips across the keys. All recordings were made with an ATR2100x-USB connected to a Focusrite Scarlett 18i8, placed approximately 5 cm from the tested keyboard. All keyboards were placed on a wooden surface covered by a large deskmat.

I clipped my nails before the test, so you don’t have to listen to the arguably worst part of the noise. Note the distinct metallic sound from the Model M. The sound from my Freebird 75 basically has no metal-sounding component to it, and that is a big plus in my book. However its annoying, high-pitched keycaps is also very noticeable in these recordings. The quietest keyboard amongst the bunch goes unsurprisingly to the rubber dome keyboard.

Some other observations:

• Keys closer to the edge have less high-pitched component to their sound on the Freebird 75. Unfortunately the vast majority of typing doesn’t happen there.
• If I tap on the case of the fully assembled keyboard, it sounds as if I am tapping a hunk of hollow wood rather than anything metallic.

Later it became known to me that this obnoxious plastic contact sound can be mitigated by inserting some padding materials above the switch plate, switching out the switch plate for one made from another material, and / or using custom or modified switches with dampers. But I think I’m good, at least for now.

QMK Shenanigans

Here comes the reason why I made the impulsive purchase in the first place: to test out QMK firmware on a keyboard that officially supports it [22] before creating my own QMK-compatible controller for my Model M. Also flashing a custom firmware is practically required for me, because the factory firmware assumes a layout that’s quite different from mine [23].

QMK has excellent documentation written for people completely new to this custom keyboard firmware business. I decided to configure the layout using their online configuration tool (which also provides a firmware building service), but build the firmware myself. They have a custom utility to aid the firmware compilation process (and firmware development in general). It even provides scripts to install development dependencies on many different distros, including Gentoo [24]. The only intervention I made is that I manually installed the cross compiler for AVR microcontrollers.

My custom layout (only first layer shown)

Compiling the firmware is as simple as importing the JSON layout file generated by the web configuration tool, and then start the build. Both steps are a simple invocation to the qmk command provided by the utility.

Bootloader debacle

Now it’s time to flash the firmware. According to the documentation this should be really straightforward: Simply put the keyboard into USB DFU mode and the qmk command would handle the flashing. However this is where the trouble begins: my keyboard refuses to boot into USB DFU mode no matter what I do.

There are 3 ways to boot into the DFU bootloader listed in the README file for this keyboard in QMK’s firmware directory:

• Bootmagic reset: Hold down the key at (0,0) in the matrix (usually the top left key or Escape) and plug in the keyboard
• Physical reset button: Briefly press the button on the back of the PCB - some may have pads you must short instead
• Keycode in layout: Press the key mapped to QK_BOOT if it is available

However none of them worked for me:

• Bootmagic reset: The keyboard does not show up as a USB device if connected with the Esc key held down. Once the key is released it immediately shows up as a keyboard.
• Physical reset button: The keyboard disconnects when the button is pressed, but comes back as an input device as soon as the button is released.
• Keycode in layout: I assumed there’s no physical key mapped to that key code in the factory firmware.

So I’m very stuck. I decided to reach out to their customer support for help, so I sent a support request with as many details as I could provide at the time. I also joined KFA’s official Discord, with the hope of finding a solution there. After plowing through many different search results and chat logs, I came back with nothing, except two people with the same issue, neither of whom got an answer, or even an acknowledgment of the issue from KFA’s staff. Therefore this is definitely not a one-off issue for Freebird 75 owners. Interestingly I didn’t find any similar reports for other QMK-compatible keyboards sold by them.

Two reports of the same issue in KFA’s official Discord server. Yes they barely made sense, but still warrant a response.

“War Crimes”

⚠️ WARNING: This is not a tutorial. Should anyone ever use this as a guide and brick their keyboard, I shall not be the person to blame.

Of course I can’t just sit there allowing the keyboard to serve as nothing but a paperweight, I started looking for an alternative way to flash the firmware. Having some basic experience playing around with microcontrollers before (but not specifically AVR-based MCUs), I knew that there’s usually more than one way to program a chip. So I started reading the datasheet of the controller chip used in this keyboard.

And unsurprisingly there are more than one way to program the chip. Among those mentioned in the datasheet, serial programming looks awfully simple: the entire chip is basically functioning as an SPI device, although the commands seem proprietary and specific to the AVR series.

So I started looking for more information on flashing the chip through its SPI interface. Soon enough I found there are official programming tools made by Atmel (now Microchip) that uses this interface. There are also a multitude of alternative implementations of this programming tool out there, which make use of very inexpensive hardware ( example 1, example 2, example 3 ). Since I don’t have an AVR-based Arduino, I decided to give USBasp a try. I placed an order for the following:

• $ 7.99 AVR ATMEGA8 Programmer USBasp USB ISP with Cable
• $14.99 SDK08 Test Clip Chip Adapters (NOT RECOMMENDED. Reasons below.)

In the mean time, I started looking for the pins to use. Looks like I just need to connect the RST, SCL, MOSI, and MISO pins on the USBasp to pin 13, 9, 10, 11 respectively and supply power to the chip. That sounds very simple (it’s really not).

As soon as the items arrived, I started working. But I quickly remembered what an absolute abomination these chip lead clippers are to work with [25]. They don’t quite have the grip to hold onto the legs of this QFP package, especially if you have to use it on a few adjacent pins. Even the tiniest disturbance will dislodge the clip from the pin. So I have to find a workaround. This is relatively easy for power pins: ground is available on all four edges of the chip, and Vcc is tied with AVcc on this board.

But this doesn’t solve the issue for the most important pins: those pins for data and clock signal are still clustered together. After looking at the pinout diagram of the chip again it quickly dawned on me that these pins, being on the digital I/O port B, are very likely used in the keyboard matrix. Probing the board to find where they go seems an impossible task as there are way too many switches. So I started looking through the files inside the folder for this keyboard in QMK’s repo, hoping to find some information on how the matrix of this keyboard is designed. And sure enough I found the following lines in keyboard.json for this board:

    "matrix_pins": {
        "cols": ["D0", "D1", "D2", "F7", "F6", "F5", "F4", "F1", "F0", "E6", "B0", "B1", "B2", "B3", "B7"],
        "rows": ["C7", "C6", "B6", "B5", "B4", "D7"]
    },

So B1, B2, B3 (which are SCL, MOSI and MISO when used as SPI pins) are used for the fourth to last to second to last columns of the keyboard. On my keyboard layout these correspond to the columns which F11, F12, and Delete keys are in. Once I confirmed that these keys are indeed connected to the pins that I was looking for by using a simple continuity test, I brutally shoved some breadboard wires into the switch socket. And I’m off to the races.

Surgery in progress…

Barbaric practice

I connected the jig to the USBasp, and then connected the USBasp to my laptop. Nothing exploded or let out the magic smoke. Running avrdude without memory operations indicates that the chip is being recognized by the program. This was a good sign. I then flashed the firmware I built with the following command:

$ avrdude -c usbasp -p m32u4 -v -U flash:w:keebsforall_freebird75_thinkpad_inspired.hex:i

avrdude: Version 7.2
         Copyright the AVRDUDE authors;
         see https://github.com/avrdudes/avrdude/blob/main/AUTHORS

         System wide configuration file is /etc/avrdude.conf
         User configuration file is /home/chrisoft/.avrduderc
         User configuration file does not exist or is not a regular file, skipping

         Using Port                    : usb
         Using Programmer              : usbasp
         AVR Part                      : ATmega32U4
         Chip Erase delay              : 9000 us
         PAGEL                         : PD7
         BS2                           : PA0
         RESET disposition             : possible i/o
         RETRY pulse                   : SCK
         Serial program mode           : yes
         Parallel program mode         : yes
         Timeout                       : 200
         StabDelay                     : 100
         CmdexeDelay                   : 25
         SyncLoops                     : 32
         PollIndex                     : 3
         PollValue                     : 0x53
         Memory Detail                 :

                                           Block Poll               Page                       Polled
           Memory Type Alias    Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
           ----------- -------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
           eeprom                 65    20     4    0 no       1024    4      0  9000  9000 0x00 0x00
           flash                  65     6   128    0 yes     32768  128    256  4500  4500 0x00 0x00
           lfuse                   0     0     0    0 no          1    1      0  9000  9000 0x00 0x00
           hfuse                   0     0     0    0 no          1    1      0  9000  9000 0x00 0x00
           efuse                   0     0     0    0 no          1    1      0  9000  9000 0x00 0x00
           lock                    0     0     0    0 no          1    1      0  9000  9000 0x00 0x00
           signature               0     0     0    0 no          3    1      0     0     0 0x00 0x00
           calibration             0     0     0    0 no          1    1      0     0     0 0x00 0x00

         Programmer Type : usbasp
         Description     : USBasp ISP and TPI programmer
avrdude: auto set sck period (because given equals null)
avrdude: AVR device initialized and ready to accept instructions
avrdude: device signature = 0x1e9587 (probably m32u4)

avrdude: processing -U flash:w:keebsforall_freebird75_thinkpad_inspired.hex:i
avrdude: reading input file keebsforall_freebird75_thinkpad_inspired.hex for flash
         with 16584 bytes in 1 section within [0, 0x40c7]
         using 130 pages and 56 pad bytes
avrdude: writing 16584 bytes flash ...
Writing | ################################################## | 100% 7.92 s 
avrdude: 16584 bytes of flash written
avrdude: verifying flash memory against keebsforall_freebird75_thinkpad_inspired.hex
Reading | ################################################## | 100% 4.29 s 
avrdude: 16584 bytes of flash verified

avrdude done.  Thank you.

And voilà! The keyboard was now using my custom layout. Sadly, the USB DFU bootloader still wouldn’t work. But at that point I had so much confidence that I would never need to flash the keyboard again, that I simply disconnected everything and reassembled the keyboard.

However later that day, I realized that I didn’t assign an Fn combination to the Insert key. Even though I practically never touched that key on other keyboards, this felt like a thing that I simply had to fix. And as I was looking for more information on how to restore the DFU bootloader, I found that it’s possible to flash the bootloader as well using the serial programmer. In fact one of the resources I discovered was QMK’s official documentation on ISP flashing [26]. It also provides a list of prerequisites for the DFU bootloader to work properly. This gave me another reason to do it all over again. So I brought my equipment out and started over.

I first checked the fuses of the chip on my board:

$ avrdude -c usbasp -p m32u4 -v -U hfuse:r:-:h -U lfuse:r:-:h -U efuse:r:-:h

avrdude: Version 7.2
         Copyright the AVRDUDE authors;
         see https://github.com/avrdudes/avrdude/blob/main/AUTHORS

         System wide configuration file is /etc/avrdude.conf
         User configuration file is /home/chrisoft/.avrduderc
         User configuration file does not exist or is not a regular file, skipping

         Using Port                    : usb
         Using Programmer              : usbasp
         AVR Part                      : ATmega32U4
         Chip Erase delay              : 9000 us
         PAGEL                         : PD7
         BS2                           : PA0
         RESET disposition             : possible i/o
         RETRY pulse                   : SCK
         Serial program mode           : yes
         Parallel program mode         : yes
         Timeout                       : 200
         StabDelay                     : 100
         CmdexeDelay                   : 25
         SyncLoops                     : 32
         PollIndex                     : 3
         PollValue                     : 0x53
         Memory Detail                 :

                                           Block Poll               Page                       Polled
           Memory Type Alias    Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
           ----------- -------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
           eeprom                 65    20     4    0 no       1024    4      0  9000  9000 0x00 0x00
           flash                  65     6   128    0 yes     32768  128    256  4500  4500 0x00 0x00
           lfuse                   0     0     0    0 no          1    1      0  9000  9000 0x00 0x00
           hfuse                   0     0     0    0 no          1    1      0  9000  9000 0x00 0x00
           efuse                   0     0     0    0 no          1    1      0  9000  9000 0x00 0x00
           lock                    0     0     0    0 no          1    1      0  9000  9000 0x00 0x00
           signature               0     0     0    0 no          3    1      0     0     0 0x00 0x00
           calibration             0     0     0    0 no          1    1      0     0     0 0x00 0x00

         Programmer Type : usbasp
         Description     : USBasp ISP and TPI programmer
avrdude: auto set sck period (because given equals null)
avrdude: AVR device initialized and ready to accept instructions
avrdude: device signature = 0x1e9587 (probably m32u4)

avrdude: processing -U hfuse:r:-:h
avrdude: reading hfuse memory ...
avrdude: writing output file <stdout>
0x99

avrdude: processing -U lfuse:r:-:h
avrdude: reading lfuse memory ...
avrdude: writing output file <stdout>
0x5e

avrdude: processing -U efuse:r:-:h
avrdude: reading efuse memory ...
avrdude: writing output file <stdout>
0xf3

avrdude done.  Thank you.

They all have the correct values according to QMK’s documentation. So I went ahead and flashed the official DFU bootloader from Microchip.

$ avrdude -c usbasp -p m32u4 -v -U flash:w:ATMega32U4-usbdevice_dfu-1_0_0.hex:i                                                                      

avrdude: Version 7.2
         Copyright the AVRDUDE authors;
         see https://github.com/avrdudes/avrdude/blob/main/AUTHORS

         System wide configuration file is /etc/avrdude.conf
         User configuration file is /home/chrisoft/.avrduderc
         User configuration file does not exist or is not a regular file, skipping

         Using Port                    : usb
         Using Programmer              : usbasp
         AVR Part                      : ATmega32U4
         Chip Erase delay              : 9000 us
         PAGEL                         : PD7
         BS2                           : PA0
         RESET disposition             : possible i/o
         RETRY pulse                   : SCK
         Serial program mode           : yes
         Parallel program mode         : yes
         Timeout                       : 200
         StabDelay                     : 100
         CmdexeDelay                   : 25
         SyncLoops                     : 32
         PollIndex                     : 3
         PollValue                     : 0x53
         Memory Detail                 :

                                           Block Poll               Page                       Polled
           Memory Type Alias    Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
           ----------- -------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
           eeprom                 65    20     4    0 no       1024    4      0  9000  9000 0x00 0x00
           flash                  65     6   128    0 yes     32768  128    256  4500  4500 0x00 0x00
           lfuse                   0     0     0    0 no          1    1      0  9000  9000 0x00 0x00
           hfuse                   0     0     0    0 no          1    1      0  9000  9000 0x00 0x00
           efuse                   0     0     0    0 no          1    1      0  9000  9000 0x00 0x00
           lock                    0     0     0    0 no          1    1      0  9000  9000 0x00 0x00
           signature               0     0     0    0 no          3    1      0     0     0 0x00 0x00
           calibration             0     0     0    0 no          1    1      0     0     0 0x00 0x00

         Programmer Type : usbasp
         Description     : USBasp ISP and TPI programmer
avrdude: auto set sck period (because given equals null)
avrdude: AVR device initialized and ready to accept instructions
avrdude: device signature = 0x1e9587 (probably m32u4)
avrdude: Note: flash memory has been specified, an erase cycle will be performed.
         To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: auto set sck period (because given equals null)

avrdude: processing -U flash:w:ATMega32U4-usbdevice_dfu-1_0_0.hex:i
avrdude: reading input file ATMega32U4-usbdevice_dfu-1_0_0.hex for flash
         with 3948 bytes in 5 sections within [0x7000, 0x7fff]
         using 32 pages and 148 pad bytes
avrdude: writing 3948 bytes flash ...
Writing | ################################################## | 100% 0.13 s 
avrdude: 3948 bytes of flash written
avrdude: verifying flash memory against ATMega32U4-usbdevice_dfu-1_0_0.hex
Reading | ################################################## | 100% 0.00 s 
avrdude: 3948 bytes of flash verified

avrdude done.  Thank you.

Then I flashed my custom QMK firmware again with the same command I used before, only adding a -D option to tell avrdude not to erase the flash before programming it. And you know what? Once that was done all three listed methods of booting into DFU mode now works on my keyboard.

So this firmware flashing ordeal finally came to an end. It appears that my keyboard either shipped without a DFU bootloader, or shipped with a corrupted one. Either way, this is terrible but nevertheless educational experience for someone getting into custom keyboard firmware for the first time.

Interestingly, nearly 6 days after I’m done dealing with this firmware flashing issue, I got a reply from KFA’s customer service saying “I am not exactly sure how you would go about this, but I will reach out to our team to see how we can assist you with this.” This is quoted verbatim from their reply. Thanks but too late, my friend!

Conclusion

• Expensive. Hella expensive. I’m going to be very upfront with this: spending $385.67 on my first custom keyboard is completely insane of me. [27][28]
• Decent quality overall.
• Design choices reverend by the community looks questionable to me.
• Nausea-inducing, high-pitched sound profile.
• Good typing feel. (highly subjective!)
• Shipped with defective firmware. Flashing requires way more effort than one would expect.
• Non-responsive customer service. Didn’t even reply until I resolved the issue myself. [29]
• Worth it for me? Hell no. Not even close.

Am I satisfied with the final outcome? Yes. Will I do this to myself again? Hopefully not. Unfortunately I seem to enjoy inflicting pain on myself, so …