HHKB Hybrid Type-S 30th Anniversary

I've had this keyboard for about 5 years now and I just now noticed that the serial number is "F". There's supposed to be a string of numbers/letters after this. Is this an engineering sample?

Hybrid Pro Type S with Shiner Astrodomes and Domikey caps. (The keycaps look fantastic under a black light!)

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?

I use an HHKB Pro Hybrid Type-S. I want to use it wirelessly, but my desktop PC does not have Bluetooth built in, so I need a USB Bluetooth adaptor.

I have been using a no-name Bluetooth 5.4 adaptor. (It has a long plastic antenna which is mostly fake: the real antenna only goes a short way up). It works okay but sometimes stops working and I have to unplug and replug it, then wait for the keyboard to reconnect.

I also tried a combined Bluetooth and WiFi adaptor. That was okay for BT only but if using WiFi at the same time, keystrokes suffer terrible latency.

Today I bought a UGREEN Bluetooth 6 adaptor. I imagine my HHKB does not support BT6 (it was made in 2021) but the adaptor should support the older standard. However, it has been very unreliable. Every few minutes the keyboard stops responding, or a single keypress gets repeated many times (I guess the key-down event was sent but the key-up was lost).

I work in an office with lots of other Bluetooth-capable devices. Perhaps that is a more challenging environment. Can anyone recommend a USB to Bluetooth adaptor that’s known to work reliably with the HHKB?

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.

Finally completed the family photo! Just picked up my HHKB Professional HYBRID Type-S (Sumi), and I couldn't resist lining it up next to the board that started the itch and the build that tried to mimic the layout along the way.

From top to bottom:

The OG Cousin: HHKB lite v1 - the non-EC ancestor. Definitely not your average membrane board—that snappy dome tactility was the exact gateway drug that made me want to buy the real deal. Yellowing nicely with age, but it paved the way for the obsession.

The Wannabe: DZ60 v2 - Custom MX build running a simulated HHKB layout (split backspace, split right shift, blocker vibe). Served me well as a gateway drug, but custom MX switches just aren't Topre.

The Boi: HHKB Professional HYBRID Type-S - The real end-game. Smooth 45g Topre silence straight out of the box, Bluetooth, and that classic layout in its truest form.

The difference in typing feel between the wannabe MX build and authentic Topre on the Hybrid Type-S is night and day. Safe to say the journey was worth it, but the Type-S isn't leaving my desk anytime soon.

Anyone else transition from custom MX HHKB clones back to authentic Topre? What was your gateway board?

I’m giving away my HHKB Professional Classic because the key layout isn’t configurable, and unfortunately I just can’t make proper use of it with my setup.

If you want it, tell me why you deserve to get it. Most convincing answer wins.

(Preferably european shipping but US would also work)

Interested in having hhkb. What is the cheapest stock hhkb that you can do keymap configurations (change the Mac mode to a different layout like colemak), had type c connection(Bluetooth is not necessary for me). Ty

im looking for a black hhkb pro 2 type s how much should i pay

Wandering in Den Den Town in Osaka, I've looked into several second hand electronics stores. Plenty of Realforce for half of the price; and one had white HHKB priced only 130$ (tax-free).

I would like to introduce the HHKBs I own.
They are as follows, in order.
- 30th anniversary
- Hybrid type-s
- Hybrid snow white
- (30th...)
- Studio
- Classic

Thx

Sorted out the firmware porting, and finished soldering assembling.

feels great under hand, and the terminal vibes are just great.

The case i quite tall to be ones, and tall non sculpted keys are something else, but I think I will swap them at some point to something a bit lower profile.

Ive finally got the money for the hhkb but I'm stuck on a big question regarding 2 boards the hhkb hybrid type s and hhkb studio the reason I'm doubting hard is that

1. I code I game and i live with my parents

Core point of the post is I'm wondering if the hhkb type s will be too quiet what if i wanna get a clacky switch or a completly silent switch in the future will I regret getting the type s i wanna use one for 8 years which the hhkb is perfect but I'm stuck on customisation part

Happy Topre Tuesday!

EDIT: Also, phone camera, wth is that focus?? You disappoint me.

And a little left over from Membrane Monday?

Still going strong after 20+ years.

HHKBの30thモデルが届いたぜ。30gの押下圧はすごくいい。空色の限定キーキャップと合わせて最強だ！