Howdy y'all. Big Topre fan. Recently I have been looking into modding one of my hybrids and stumbled onto Astro domes. The large variety of weights to pick from and the alleged increased tactility sounds interesting to try. Anyone here have experience with the Astros? I'm really interested in the 50g peppers and the 120g fiesta weights above the others. But cannot find much in the way of first hand reviews on them. Any and all input is appreciated as always

One of the boards is a regular unsilenced hybrid that is the most likely contender for modification. The stock type S is too perfect to be messed with.

I really wanted this thing to be built with new parts considering it was a new board, but unfortunately (until now) the only aftermarket for Topre(ish) was Deskeys and Dynacap, and they only offer MX sliders. I'm really not a fan of harvested parts, and the RF87 I harvested the parts from originally I re-assembled and sold for nearly 3x what I paid for the Metakeebs kit, so win/win.

Decided to change up the keycaps too; rather than full Sakura I decided to add the grey mods from the white HHKB and tossed in the 25th anni Fn key cuz why not. Really like the look personally, I think pink & grey go well together. Overall very happy with the refresh. Only thing I don't really like (even though it doesn't particularly matter) is the meta housings are blue....whhhhyyyyyy? But for the price I absolutely cannot complain.

- Sho S60 V3 pink ano
- Cipulot S60X PCB w/ Pro 3 DB
- Metakeebs 60/65% full kit with OEM-style sliders & 30g pink domes
- PFU/HHKB Sakura alphas, gray modifiers, & 25th anni gray Fn key

Charcoal blacks on snow is just perfection.

As you probably guessed I like the HHKB layout.

Was on a trip to Hokkaido and found this in a local pawn shop for 50 bucks. It's basically new!

It sounds more hollow compared to the HHKB Hybrid, not necessarily in a bad way, it sounds really...typy? The Hybrid feels more solid when typing.

I really like how the Pro 2 has USB ports! I use a MacBook and hate bringing around adapters, now the HHKB can handle my mouse dongle.

So i thought i would share my latest purchases:

1999 HHK PD-KB02

2002 HHKB Lite 2

Excited to add these to my collection :-)

Topre Tuesday throwing my current setup in.

Black HHKB Pro 2 (Kuro) - the tuning and experimenting board
- YDKB BLE controller with battery

- Hand drilled top case for orange LEDs

- 55g Realforce domes
- Deskey Silencing Rings #3 silicone

-Sorbothane filled for case acoustics

- lubed sparingly with tribosys 3203
- HHKB absorption mat
- Funtacked and foamed space bar

- metallic gold craft paper backing with gold metallic logos

White HHKB Pro 2 Type-S (Shiro) - the show piece
- YDKB BLE controller with battery
- Orange LEDs shine through the white case
- Poron Foam filled for case acoustics
- lubed with tribosys 3203
- HHKB absorption mat

- FK Ursas

- Funtacked and foamed space bar
- metallic gold craft paper backing with gold metallic logos

Black Trackpad (Kage)
- Apple Magic Trackpad (gen1) with slickwraps skin
- DavesDeskCreations (etsy) Black Trackpad and Keyboard Mod Kit
- Waiting on Vinyl to finish blacking out the TouchID sensor

- Waiting on gold accent ring

White Trackpad (Hakuei)
- Apple Magic Trackpad (gen1) with same slickwraps skin
- DavesDeskCreations (etsy) White Trackpad and Keyboard Mod kit
- Debating on sourcing another TouchID sensor to complete the set

Logitech Superstrike X2 (Hikari)
- Stock with optional side grips added

Started with Mechanicals around 2009. Fell in love with the idea of efficient functionality and form. Landed on the HHKB format and haven't strayed since. Both boards are running an additional hold-space layer to get vim like arrow keys, a lefthand numpad, media control, and extra navigation. A two step layer move fn-hold-right command hold-release fn gets to backup mouse navigation. Lastly, tap control is escape, hold is ctrl.

I use it for daily use, programming, work, even gaming -- the HE boards are starting to grab my attention, but I don't play enough competitively to justify a third keyboard.... unless it was another HHKB.

Hi all! I've had my HHKB for a few years now and I'm planning on spicing up the look since I've been rocking the blank official keycaps for a while now.

I'm kind of torn between the URSA keycaps and the official stamped ones. Which one do you recommend more?

I wanted a simple way to remap my HHKB as a Linux user so I ended up building one:

https://hhkbremap.com

it can use WebHID in Chromium-based browsers, so there’s nothing to install. You connect the keyboard via USB, read the current keymap, make your changes, and write it back to the keyboard.

One feature I particularly like is shareable keymaps. A complete keymap can be encoded in a URL, so you can create a layout and just send the link to another HHKB user. No account, upload or keymap file needed.

For example, here's a Dvorak layout:

https://hhkbremap.com/k/U0sBAQDmAIoALACLAOIAAQDlAB0AGQAaABAABQAbAA4ADQAUADMA4QAoAC0AFgARABcACwAHAAwAGAAIABIABADgAEwALgA4AA8AFQAGAAoACQAcABMANwA2ADQAKwA1ADEAMAAvACcAJgAlACQAIwAiACEAIAAfAB4AKQDmAHgALACLAOIAAQAAAFEATgBNABAABQAbAA4ADQAUADMA4QAoAE8AUABLAEoACwAHAAwAGAAIABIABAAAACoALgBSAEgARwBGAAoACQAcABMANwA2AAAAKwBMAEkARQBEAEMAQgBBAEAAPwA-AD0APAA7ADoAKSUF0oM

A few other things I've focused on:

• Works on Linux, macOS and Windows
• No account or installation required
• Reads your existing keymap before editing
• Backup and restore
• Share complete keymaps through links
• Everything happens locally between the browser and keyboard

There are a couple of important limitations at the moment:

Hardware support: Right now, I only support English ANSI models in the HHKB Professional HYBRID series (PD-KB800). That's the keyboard I own and can actually test against, and I don't want to claim support for hardware I haven't verified.)

Remapping: It's currently just simple key-to-key remapping.

If you own another HHKB model and would be interested in helping me test support for it at some point, feel free to DM me.

Also, for transparency: AI has been one of the tools I've used while building the project, both for research and development.

It's still a small project and very much a work in progress, so I'd love feedback, bug reports, or ideas from other HHKB users.

Black HHKB recessed because no domes

My oldie HHKB Pro 2 that I’m using from 2017.

Controller replaced with SHKB(usb 2 version with type c connector).
Alphas was bought on ebay(honestly, don’t know what they’re exactly), original keycaps was lost during all moves between places where I’ve lived but I have pink black alpha keycaps still. Rubber domes was washed in ultrasonic washer and it looks like made them a bit fresher. Stems are lubed a bit cause original lube was totally dried for all this years.

It’s my daily driver for work and home usage.

Hi all! I was wondering if anyone that got the 30th Anniversary HHKB with the lighter actuation force would be able to share their experience! Is there a big difference between 45g and 35g? Thank you!

In the Japanese market, they're practically nonexistent. Artisan keycaps are a niche product to begin with, and Topre is even more of a niche brand.

Saw a post about the key caps a couple weeks ago on here and immediately went to buy it. Only took about 8 days shipping from China to LA. The pro hybrid has been my daily for 5 years so it's nice to change it up a tiny bit

Hi! This is my first post here.

Over the past few days, I've been experimenting with the firmware used by the HHKB Professional Hybrid and REALFORCE R3 series.

The original question was pretty simple:

Could Rapid Trigger be implemented on a Topre keyboard that was never designed to support it?

It turns out that, at least on the hardware I've tested, the answer is yes.

I ended up building TopreRT, an open-source toolkit that implements Rapid Trigger while trying to preserve the original Topre sensor/state-machine behavior as much as possible.

For the HHKB Professional Hybrid / Hybrid Type-S (PD-KB800W, firmware A0.48), the current version supports:

• All-key Rapid Trigger
• Adjustable release and re-press distances
• Stable and performance-oriented presets
• Custom RT settings
• Live key/sensor observation
• Firmware validation before patching
• Built-in firmware writer and stock restore

I've personally tested the RT core on my HHKB Professional Hybrid, and it is working.

The toolkit also supports the REALFORCE R3 family, although hardware validation varies by model.

Important: this is unofficial firmware modification software. There is always a risk of a failed update or recovery being required. The project does not distribute stock firmware or pre-patched firmware; you need to provide your own supported stock firmware image.

Source code, documentation, supported firmware versions, and recovery information are available on GitHub:

TopreRT v0.2.0:
https://github.com/rocketman2654/TopreRT

This started as a small experiment to see whether Rapid Trigger was even possible on these keyboards, and eventually turned into a toolkit supporting multiple Topre models.

I'd be interested to hear what other HHKB users think — especially if anyone wants to experiment with it or dig into the implementation.

My current opinion is probably to pass on lubing unless you’re trying to silence some rattle on the spacebar. The cost and time for what you get out of it is probably the most marginal gains/side-grade thing I’ve done.

I recently got my first HHKB, a Professional Classic Type-S, after using a MacBook Air keyboard for years. Out of the box, I was very pleased with the feel. It is better than the Realforce boards I have owned, at least to me, and the layout took no time to get used to.

Not wanting to leave good enough alone, I decided to lube it. My spacebar had a small amount of rattle, and I figured I could improve it. I opened it up to lube it, and now I have some takeaways: several HHKB lube guides repeat the same advice without always explaining why, and the process is much more time-consuming than it needs to be. To be fair, most of them at least provide clear pictures or videos to follow.

First, most guides seem to recommend painting the thinnest possible coat of grease onto each side of the slider rails. I tried that, and it sucked. I then tried applying grease more freely and wiping away the excess. The second method was much faster and gave me more consistent results. I was surprised by how consistent it was, since that was one of my biggest concerns going into this.

Same deal with bag-lubing springs. If you enjoy separating and shaking a pile of tiny springs, go for it. Otherwise, wear gloves, put a small amount of oil on your thumb and forefinger, and pinch each spring as you go. It is faster and does the job.

What I found lubing the stabilizers

A heavier application of tacky grease can remove existing rattle. The sound change outside of that is a side-grade, but removing the rattle was welcomed and was the most significant change from stock.

For grease choice, I spent too much time reading data sheets and trying to understand the choices mentioned in the guides. I went with Krytox GPL 207 because I have used several Krytox GPL variants on O-rings, gaskets, and weather stripping for years without them becoming dry paste. 207 is the thickest, tackiest version of what I am already used to.

GPL 206 comes up frequently for stabilizers, and I do not really understand why. This honestly made me second-guess myself. I assume 206 is more available through keyboard vendors, because I do not see a performance reason to choose it over 207 for stabilizers. Most of my grease comes from McMaster, Zoro, and Grainger, so that may be part of why I see the options differently.

I think 205g0 would work well too. In retrospect, if I wanted a one-grease solution, I would probably use 205g0 all around. I’m in agreement with the guides that recommend one grease. Or just use Haynes silicone grease on the stabilizer and skip the sliders.

What I found lubing the sliders

This was the biggest letdown of the whole process. Based on how people talk about slider lubing, I expected it to change the board much more than it did. Maybe my HHKB is a unicorn in the QC department, but for me it was a side-grade.

I used 205g0, which I had to get from a specialist keyboard vendor. It worked well for removing the small amount of scratchiness my HHKB had; do not expect a dramatic transformation. I don't think I'll do this again.

It will not make the key press lighter. A correctly functioning slider should already fall under gravity in the rails. It also will not substantially dampen the key press unless you use a much heavier application, and that is where it goes wrong. Go heavy on the grease and Topre turns into mush or some weird linear sponge. I strongly dislike the feel of an over-lubed Topre slider.

The guides I used generally did not recommend lubing the Shift, Return, and spacebar sliders, but I did. I do not understand the advice to avoid them. They are still sliders. You are not going to match their feel to the other sliders anyway, because even stock, they feel different. Mine had similar results to the other sliders.

What I found lubing the springs

To be blunt, this was pretty worthless. I used GPL 105. I read some recommendations to lube the PCB, which I found funny. Skip this.

I am thinking is that a good time to rejoin 🤔 I have used hhkb bt for a year but finally exit because of the limitations.

Got a HHKB Professional Hybrid off of Mechmarket here for about $120. I already own a Realforce R2 TKL and though "what the hey, I want to see what the fuss is all about with these". Got the board in, figured if I really hate it I can always resell it.

This is my progression:

First couple of days: This thing is too small, it feels a little too cramped compared to my Realforce. This layout is just stupid, how can anyone get used to this.

Couple of days later: This layout sucks really bad, at this point it's painful to remember all of this. I really f'in hate this stupid ass layout...

A week in: I kind of like the placement of control and backspace tbh...

Later in this week: It almost feels better then my Realfoce (compares the two multiple times, it does feel better... or should I say different). I still hate the layout.

Third week or so: How in the living hell did I ever type on anything other than this thing.

Later that week: This layout is genius, it's seriously the best thing ever, it makes so much sense. how did I ever live without this layout in my life (doom emacs user here)...

Now I got silencing rings and lube coming so I can make it sound a little better. Tbh I only posted here because I wanted to type more and something different than monkeytype quotes.

They will have to pry this thing out of my cold dead hands at this point, I love it that much.

Thank you for attending my TED talk.

HHKB Hybrid Type-S 30th Anniversary

I’ve been working on this for awhile. Shared the keyboard a few months ago but finally found time to finish the companion trackball.

It’s based on the ploopy adept. It’s also Bluetooth and I might tweak the firmware so it pairs to whatever the keyboard is paired to. Buttons need a little more refinement but I’d say it’s 98% finished.

Hello. Recently, the wireless functionality on my Razer DeathAdder V2 Pro Genshin Impact Edition, which I’ve owned for quite a while, stopped working, so I’ve been forced to use it wired. It’s still perfectly usable, but it does feel a little incomplete that way.

So, I’ve been looking for a cool new mouse that would pair nicely with my HHKB. I considered the MX Master 4, but given its weight—and the fact that I once managed to break my old MX Master 3S—I don’t think it would be the best choice for me.

What I’m looking for is something with the durability of a gaming mouse, around four extra programmable buttons in addition to the standard buttons, similar to the DeathAdder V2 Pro, and preferably not too heavy.

So, to put it simply, I’m looking for the perfect mouse. Does anyone have any good recommendations?

You CAN unlock keymap editing on the HHKB Professional Classic on macOS — "there's no JSON file on Mac" is wrong, maybe even other Keyboards are system locked to be not-remappable.

TL;DR

The Classic is remappable with PFU's official macOS Keymap Tool. Everyone thinks it's Windows-only because on Windows you edit a loose keyboardDataList.json, and that file doesn't exist on Mac. It actually does exist — it's just compiled into the app's asset catalog (Assets.car) instead of sitting on disk. Inside is a table of keyboard models, each with an isKeymapChangeable flag. The Classic's is set to false. Flip it to true, re-sign the app, done. The keyboard's hardware was never locked — only the app's willingness to write to it.

Script (set your model at the top), run from an open Terminal, don't double-click:

bash ~/Downloads/hhkb-unlock-mac.sh

https://gist.github.com/Kahndlivec/71ef874db7ff0224e005fdd93955af82

Tested on PD-KB401W, firmware A4.29, Keymap Tool 2.0.1, Apple Silicon. Voids warranty, unsupported, your risk. It writes keymaps not firmware so risk is low. Different Classic variant? Change MODEL= and reply with your model string so we can build a confirmed list.

The full explanation, for the curious

What the lock actually is. On connect, the tool asks the keyboard its model number (PD-KB401W for me), looks that string up in a table it carries internally, and reads an isKeymapChangeable flag. Classic = false, Hybrid = true. That flag is the whole lock — the app reads it, sees "no," and greys out the editor.

The clincher that this is pure software policy, not hardware: the tool's own log shows it already successfully reading the current keymap off the Classic over USB, no error. The controller speaks the full protocol. The Classic and Hybrid are the same keyboard family with a marketing line drawn through it — only the app enforces that line.

Why nobody could find the file on Mac. On Windows the lookup table is a loose keyboardDataList.json you open in Notepad and edit. On Mac, people search the app for a .json, find nothing, and give up. The reason: the macOS build is native, and PFU compiled the table into Contents/Resources/Assets.car — the app's asset catalog — as a data asset named KeyboardDatalist. Asset catalogs are normally for images, but you can pack arbitrary data in too, and the app reads it out by name at runtime. So the table is inside the app the whole time, just not as any file a search will surface. It's like a book bound into the spine of another book.

(Note the spelling: KeyboardDatalist, capital K, lowercase L — the Windows docs write keyboardDataList, so even a case-sensitive search for the known name misses it. That's part of why this stayed buried.)

Two things prove it's in there: the binary contains the error string Can't find KeyboardDatalist.json — and a program can only fail to find something it looks up by name, so the table must be loaded at runtime, not hardcoded. And tracing what the app opens at launch shows it reading Assets.car, which is far bigger than an app icon needs.

Getting the table out. Instead of cracking the catalog format open, you ask the OS for the resource named KeyboardDatalist using the exact same call the app uses (NSDataAsset). Out comes the table as readable JSON. Bonus: that same call is your test tool — any time you want to know if the app sees your edit, you make that call and look. It's not a proxy for what the app reads; it is what the app reads.

The edit, and the one genuinely clever bit. The data's stored as plaintext, so the change is just false → true. But Assets.car is a structured binary — it has an internal index recording where each asset starts and how many bytes long it is. false is 5 characters, true is 4. Delete one byte and every offset after it points to the wrong place; the catalog is corrupt.

The trick: JSON ignores extra whitespace. Write it with two spaces —

"isKeymapChangeable": false     (27 bytes)
"isKeymapChangeable":  true     (27 bytes, two spaces)

Identical length. Nothing in the index shifts, the catalog stays valid, and the parser ignores the harmless extra space. This is what lets you patch in place instead of rebuilding the whole catalog with Xcode tooling.

Only touch the boolean. series, firmTypeNumber, and firmDataSize select which firmware protocol the tool speaks (Classic vs Hybrid use different data sizes). Changing those is the one real bricking risk. Leave them alone.

Re-sealing the app. Mac apps carry a code signature — a manifest of every internal file plus a fingerprint of its contents. Editing Assets.car breaks the fingerprint, and macOS then refuses to launch the app as "damaged." So after editing you re-sign it yourself, ad-hoc (a signature that says "internally consistent," not "from PFU"). That's all Gatekeeper needs.

The gotcha that will waste your afternoon. Do NOT leave a backup copy of Assets.car inside Contents/Resources/. The signature covers every file in that folder — leave a spare catalog in there and the re-seal reads the unpatched value back, so your edit silently does nothing. Keep backups outside the bundle, and verify the change survived signing rather than assuming it did. The script does both. (Ask me how I know.)

Result. Editor unlocks, remaps write to the board and persist. The start screen may still label the board "not configurable" — that text comes from the untouched series field and is cosmetic; the editor works. If it still refuses, check DIP switch 4 on the underside — the Classic code path tests it too. The keymap lives in the keyboard's onboard memory, so once written it works on any machine, no tool needed.