Daniel sent us this one — he's been deep in the voice-dictation workflow trenches, and he's hit that wall where you're doing the same thing so many times a day that you just want a physical button for it. Opening a terminal, launching Claude, pushing to GitHub — the kind of repetitive stuff where muscle memory kicks in but you're still burning keystrokes. He started building macros and key bindings, and he's discovered what everyone discovers: it gets messy fast. You run out of keys, combinations start conflicting with existing shortcuts, and suddenly you've got three cheap macro pads from AliExpress on your desk wondering whether you should just build your own keyboard. So he's asking us — what are the most reliable key bindings to use, especially on Linux where Unicode recognition gets tricky? And when you're looking at macro pads versus custom keyboards versus something fully hand-built, what's the actual right move for someone going long-term?
Oh, this is a great topic. And Daniel's already stumbled onto the single most useful piece of this puzzle without maybe realizing how important it is. F thirteen through F twenty-four. That range is practically sacred in the macro world.
You said "sacred" with a straight face.
Here's why — F thirteen through F twenty-four are defined in the HID usage tables. The USB standard knows about them. Every operating system understands they exist. But no consumer keyboard ships with them. So they're this pristine, uncontested namespace just sitting there waiting for macro assignment. You map your macro pad to F thirteen, the OS sees it, your voice dictation software sees it, and absolutely nothing else on your system is using it. No "oops, I just triggered screen recording while trying to append a voice note.
This works across Windows, Mac, Linux?
The HID specification is the same everywhere. Where it gets Linux-specific — and this is what Daniel's brushing up against — is how the system interprets those keys when they arrive. On Linux, the input subsystem sees F thirteen as keycode one ninety-one. Most desktop environments pass it through without doing anything weird. But if you're using i3 or Sway or a minimal window manager, you might need to explicitly tell it to ignore those keys so they don't get swallowed. That's usually a one-line config fix.
The F-thirteen-through-twenty-four trick is basically: here's a bank of twelve keys the USB spec reserves but nobody uses. And Daniel's already doing that.
The problem he's identifying — "what happens when I want more than five?" — is the natural next question. A standard macro pad with four or five keys, you assign F thirteen through F seventeen, you're done. But if you want twenty macros? You can't just keep stacking F keys because eventually you run out. And that's where the conversation splits into two paths: layers, or custom firmware.
Let's talk layers first. Because I think most people hear "macro pad" and imagine one key does one thing. But that's not how the serious ones work.
QMK — the open-source keyboard firmware — and VIA, the graphical configurator that sits on top of it, support layers natively. A five-key macro pad running QMK can have, say, four layers. That's twenty macros on five physical keys. You switch layers by holding a specific key, or double-tapping, or whatever you configure. So your five keys for voice dictation — start, stop, pause, append, retake — that's layer one. Tap a layer switch and now those same five keys are your git commands. Tap again, now they're your terminal shortcuts.
That sounds elegant in theory. In practice, how do you remember which layer you're on?
That's the friction. Some macro pads have tiny O. screens per key, or a little display that shows the current layer name. But on a cheap AliExpress pad, you're probably getting nothing — maybe an R. underglow that changes color per layer. Red for voice, blue for git, green for terminal. You memorize it or you get confused and push to production when you meant to pause your dictation.
Daniel's the kind of person who'd have a sticky note on his monitor for the first week and then just know it.
But there's a deeper point about the hardware itself. Those cheap macro pads from AliExpress — they're almost certainly running proprietary firmware that may or may not support layers properly. Some of them just send a single keycode per button, programmed through a janky Windows-only configuration tool. If Daniel's on Linux, he might not even be able to reprogram them without borrowing someone's machine. That's the hidden cost of the five-dollar macro pad.
The AliExpress test run is fine for figuring out if you like the concept, but if you're going to commit, you want something that runs QMK or ZMK.
QMK is the standard for wired. ZMK is the wireless equivalent. Both give you full control over every key, every layer, every behavior. Tap versus hold, double-tap, tap dance — which is where a single key does different things depending on how many times you press it. You can get absurdly granular. And all of this is configured in firmware, so it works identically across operating systems. No driver needed. The computer just sees a standard USB keyboard.
That's the actual term?
It's the actual term in the QMK documentation. Tap once for play-pause, tap twice for next track, tap three times for previous track. All on one key. It's wonderfully ridiculous.
I love that. So Daniel's at this inflection point where he's got the cheap pads, he's proven to himself that physical buttons improve his workflow, and now he's looking at the long game. He mentioned two paths — buying a decent mechanical keyboard with macro keys built in, or going fully custom. Let's compare those honestly.
The "mechanical keyboard with macro keys" market is smaller than people expect. You've got the gaming keyboards — Corsair, Razer, Logitech — which typically give you five or six dedicated macro keys on the left side. They're fine. But they're almost always programmed through the manufacturer's software, which on Linux ranges from "community reverse-engineered and mostly works" to "completely unsupported, good luck." And those extra keys are usually just sending regular key combinations. You don't get the deep firmware control.
You're paying for a keyboard that has macro keys but you're locked into whatever the manufacturer's software allows. And on Linux, that's a gamble.
A gamble that Daniel, specifically, would lose. He's living in the terminal. He's pushing to GitHub. He's using voice dictation that wants to bind to specific key events. He needs reliability, not gaming R. software that phones home.
Which points toward custom.
Custom is where it gets genuinely interesting. And I don't mean "custom" as in "spend eight hundred dollars on a boutique keyboard." I mean building something that's exactly what you need. The mechanical keyboard community has exploded in the last few years. You can get a kit — a hot-swappable P. , a case, a plate — for under a hundred dollars. Slap in some switches, put on keycaps, flash QMK, and you've got a keyboard where every single key is programmable. Not just the macro keys — every key.
This is where Daniel's idea about his own keycaps comes in. He mentioned wanting labeled keys so he's not memorizing what F seventeen does.
Custom keycaps are a rabbit hole, but a fantastic one. There are services now — W. Keyboards does custom-printed sets, there are vendors on Etsy who'll do dye-sublimated individual caps, and if you really want to go deep, you can design your own legends and get them manufactured. Daniel could have a key that literally says "PUSH" in whatever font he wants. Or a little icon of a microphone for his dictation layer. It's absurd and I fully support it.
There's something deeply satisfying about a button that does exactly what it says and says exactly what it does.
It removes the cognitive layer. You're not thinking "F fifteen is append." You're pressing the button that says "APPEND." Your brain doesn't have to do the translation. That matters when you're in flow — when you're dictating and you need to pause, you don't want to think about which key that is. You want your finger to find it.
Let's put some structure around this. Daniel's asking about two use cases — his own, which is voice dictation plus terminal plus git, maybe ten or fifteen macros total. And then the broader question: what about the video editor or the C. user who also wants macro pads? Is the advice different?
The advice converges faster than you'd think. The video editor and the C. user have the same core problem: they're doing repetitive command sequences buried in menus or requiring multi-key chords. Premiere Pro, DaVinci Resolve, AutoCAD, Blender — all have extensive keyboard shortcut systems, but they're scattered across the keyboard and often require three or four keys at once. A macro pad condenses that down to one press.
The difference is that those users are often working inside a single application for hours. Daniel's switching contexts constantly — terminal, browser, dictation, editor.
Which is actually the stronger argument for a dedicated macro pad with layers. If you're in Premiere all day, you might just remap your main keyboard shortcuts and call it done. But if you're hopping between five different tools, having a separate physical surface that changes behavior based on what you're doing — that's powerful. And with QMK, you can even have the layer switch automatically based on which application is in focus, if you set up the host-side integration. There's a tool called "qmk-hid" that lets the keyboard receive signals from the host. So your computer can tell the keyboard "we just switched to the terminal, go to layer two." It's slightly janky to set up on Linux, but it works. Daniel's the kind of person who would enjoy setting it up.
He absolutely would. He'd have a bash script that talks to his keyboard and he'd be unreasonably happy about it.
That's the thing about this whole space — the people who get into custom keyboards and macro pads, they're not just solving a productivity problem. They're having fun. It's a hobby that also happens to make your work faster.
Let's talk about the build-your-own path more concretely. Daniel said "building my own keyboard with my own keycaps." What does that actually look like, step by step, for someone who's never done it?
The entry point for most people is a kit. You buy a printed circuit board that's already designed. You buy a case that fits it. You buy switches — the mechanical bits under each key. And you buy keycaps. Assembly, if you get a hot-swap P. , requires zero soldering. You literally push the switches into the sockets, screw the P. into the case, and put the keycaps on. It's like adult Legos.
Then you flash the firmware.
Flashing QMK is, at this point, almost trivial. You go to the QMK Configurator website — a graphical tool — you drag and drop your layout, assign keycodes, compile, and download a dot-hex file. Then you use QMK Toolbox to flash it to the keyboard. On Linux it's a command-line thing, but it's well-documented. Daniel would be done in an afternoon.
The barrier is: pick a kit, buy parts, assemble, flash. That's it.
That's it. The hardest part is choosing which kit. For someone who wants macro keys specifically, there are keyboards with dedicated macro columns — the "ninety-six percent" or "southpaw" layouts that put a numpad and extra keys on the left side. Or you go with a separate macro pad that sits next to your main keyboard. That's the modular approach Daniel seems to be leaning toward.
Let's talk modular versus all-in-one. Because he raised the concern: what if you want more than five macro keys? Do you end up with four devices on your desk?
That's the aesthetic and ergonomic tension. A single macro pad with five keys is clean. Two starts to look cluttered. Three looks like you're running a launchpad for a spacecraft. Some people love that aesthetic — it's very "mission control." But practically, you're managing multiple U. cables, multiple devices, multiple firmware configurations. It gets administratively annoying.
Whereas an all-in-one keyboard with, say, ten extra programmable keys on the left — that's one cable, one firmware, one thing to configure.
The southpaw layout puts the numpad on the left, which frees up the right side for your mouse while giving you a whole grid of programmable keys under your left hand. For someone doing C. work, that's actually ideal — left hand on the numpad entering commands, right hand on the mouse. It's a layout that exists specifically because of this use case.
I didn't know southpaw keyboards were a C.
They originated in accounting — the idea was you could keep your right hand on the adding machine while entering numbers with your left. users adopted them because the workflow is similar: one hand on input, one hand on a pointing device.
For Daniel specifically — voice dictation plus terminal plus git — what's the actual recommendation? What should he buy or build?
If he wants to go modular, which fits his experimental style, I'd say: get a single quality macro pad that runs QMK. Something like the Koolertron or the Max Falcon twenty — those are programmable without proprietary software. Or if he wants to go deeper, the B. nine from Keebio is a three-by-three grid of keys designed as a macro pad kit. Nine keys, fully programmable, around thirty dollars for the P. plus switches and caps. He can set up three layers of nine macros each. That's twenty-seven macros on a device the size of a credit card.
Twenty-seven macros on nine keys. That's more than he needs, which means he won't outgrow it.
And if he wants to go the custom keyboard route, I'd look at something like the Keychron Q series — those come with QMK and VIA support out of the box, they've got a knob, they're solid aluminum, and they start around a hundred and fifty dollars. The Q five has a southpaw layout if he wants the numpad-as-macro-grid approach.
He mentioned wanting his own legends.
Custom keycaps are a separate order. Keyboards will print a full set with whatever text or icons you want for around sixty or seventy dollars. You upload an S. file with your designs, they dye-sublimate it onto the caps. For a macro pad, you might only need a handful of custom caps, which is even cheaper. Etsy sellers will do individual caps for a few dollars each. Daniel could have a "DICTATE" key, a "PUSH" key, a "PAUSE" key — whatever makes sense in his head.
There's something about having a key that says "PUSH" that just feels right. Like, of course that's the button. Stop memorizing, start knowing.
That's the philosophy behind the whole custom keyboard movement. It's not just about the feel of the switches or the sound of the case — it's about making the tool fit the person instead of the other way around. Daniel's been shaping his software workflow for years. The keyboard is the last piece of hardware between him and the computer that he hasn't fully customized. Once he does, the whole stack is his.
Let's circle back to the key binding question specifically, because he asked about reliability and Unicode. On Linux, if you're binding macros to F thirteen through F twenty-four, what actually breaks? Where's the pitfall?
The main pitfall is that some Linux desktop environments — looking at you, Gnome — have historically intercepted the function keys for their own purposes. F thirteen might get mapped to "launch help browser" or something equally unhelpful. The fix is usually in the keyboard settings or in dconf. You go in and you unbind anything that's grabbing those keys. it's less of an issue. it's basically not an issue. And on a tiling window manager like i3, you explicitly define what every key does, so nothing gets grabbed unexpectedly.
The Unicode concern?
That's actually a separate thing. Unicode input on Linux is typically done through Control-Shift-U followed by a hex code. That's for typing characters like em-dash or special symbols. It's not relevant to key bindings for macros. I think Daniel might be conflating two things — the way voice dictation software sometimes uses Unicode for text output, versus how key events are handled at the input layer. The macro keys don't need to send Unicode. They send HID keycodes, which the OS translates. As long as the voice dictation software is listening for key events — which it is, if it supports keyboard shortcuts — it'll catch F thirteen just fine. The Unicode question is a red herring for this use case. Stick to the function keys or the HID-defined keycodes and you'll never touch Unicode.
Let's talk about the AliExpress pads he bought. He said they were cheap, just to test the concept. What's actually inside those things?
Typically, a microcontroller — often something like a Holtek or a no-name chip — running firmware that's locked down. You program them using a Windows application that writes the configuration to onboard flash memory. Once programmed, they'll work on any OS because they just present as a USB HID keyboard. But the programming process is the weak link. If the software is sketchy — and it often is — you might be limited to basic key assignments, no layers, no tap dance, no advanced features. And if the manufacturer stops updating the software, you're stuck.
They're fine for "do I even like having macro keys?" but not for "this is my permanent setup.
And that's fine. Daniel's using them exactly right — as a proof of concept. Spend fifteen dollars to find out if the workflow clicks before spending two hundred on something permanent. That's smart.
There's also the question of reliability. A five-dollar macro pad from AliExpress — how long until the switch starts chattering or the U. port gets loose?
The switches on those cheap pads are usually Outemu or some clone. They're not terrible, but they're not rated for fifty million keystrokes either. The bigger issue is the soldering quality and the U. ports on cheap devices are notorious for lifting off the board. If Daniel's using this every day, he might get six months before something gets flaky.
Which again points toward: test on the cheap stuff, commit on quality hardware.
The quality hardware doesn't have to be expensive. nine kit is thirty dollars for the P. Switches are maybe twenty cents each if you buy Gaterons or Cherry M. Keycaps are a few dollars. You're at maybe fifty or sixty dollars total for something that'll last a decade. It's actually cheaper in the long run than replacing cheap pads.
Let's zoom out for a second. Daniel's prompt is really about a pattern that a lot of people hit: you optimize your software workflow to the point where the keyboard itself becomes the bottleneck. You're typing the same commands dozens of times a day, your fingers know the sequence, but you're still executing five or six keystrokes to do one thing. The macro pad is the answer to "how do I collapse five keystrokes into one?
The deeper realization — which Daniel seems to be arriving at — is that the macro pad isn't just a convenience. It's a different category of tool. A keyboard is general-purpose. A macro pad is task-specific. It's like the difference between a Swiss Army knife and a dedicated chef's knife. Both cut, but one is optimized for a specific set of motions.
That's a good framing. And it explains why the video editor with their scrub-and-cut macros, and the C. user with their dimension-and-constraint macros, and Daniel with his dictate-and-push macros — they're all converging on the same hardware solution even though their work is completely different.
Because the human problem is the same. Repetitive fine-motor sequences create cognitive load. Every keystroke is a tiny decision. "Control-Shift-P, then type 'push', then Enter" — that's four or five decisions. A single button press is one decision. Over the course of a day, those micro-decisions add up to real fatigue.
There's research on this. Decision fatigue is well-documented in contexts like judicial rulings and medical diagnoses. But it applies to knowledge work too. Every time you have to think "what's the shortcut for this?" you're spending a tiny bit of your cognitive budget. The macro pad externalizes that memory into physical space.
Physical space is something our brains are very good at. Spatial memory is ancient and robust. You remember where the light switch is without thinking about it. A macro pad leverages that — your hand learns where the "pause dictation" key is, and eventually you don't even look. It's proprioception plus habit.
Which is why labeled keycaps matter. The label bridges the gap between "I'm learning this layout" and "I know this layout." And even after you know it, the label is a confirmation — you glance down and see "PUSH" and your brain goes "yes, that one.
There's a reason airplane cockpits and recording studio consoles have labeled buttons everywhere. When the cost of pressing the wrong button is high, you want every affordance you can get. For Daniel, pressing the wrong button might mean pushing broken code or losing a dictated sentence. Not catastrophic, but annoying enough to avoid.
Let's talk about the software side for a minute. Daniel mentioned voice dictation specifically — start, pause, stop, append, retake. Those are five distinct commands. How does the voice dictation software actually receive those key events? Is it just listening globally?
Depends on the software. Most dictation tools on Linux — we're probably talking about Whisper-based tools, or maybe the built-in speech recognition in something like KDE Connect — they register global hotkeys. The application says to the window manager, "I want to listen for F thirteen, even when I'm not in focus." The window manager says okay, and whenever F thirteen arrives, it routes the event to that application. This is standard X11 or Wayland behavior. It's well-supported.
If two applications both want F thirteen?
Then you've got a conflict, and the behavior is undefined — usually the first one to register wins. That's why using F thirteen through F twenty-four is nice: nothing else is competing for them. You're not fighting your email client for Control-Shift-P.
Daniel also mentioned opening Claude in a terminal. What's the macro for that? Just typing "claude" and hitting Enter?
A macro that sends a string — "c-l-a-u-d-e" followed by the Enter keycode — is trivial in QMK. You can define a macro that types out any sequence of characters. So one button opens a terminal, launches Claude, whatever. The limit is that QMK macros are stored in firmware, so they're not dynamic — you can't have a macro that types today's date without rebuilding the firmware. For dynamic stuff, you'd use something like AutoKey on Linux or Keyboard Maestro on Mac. But for static strings like "git push origin main," QMK handles it fine.
There's a split: static macros live in the keyboard firmware, dynamic macros live in software on the host.
That's the clean separation. And Daniel's workflow — launching Claude, pushing to GitHub, starting dictation — those are all static. They don't change day to day. He can hardcode them in firmware and never think about them again.
Which is satisfying in its own way. The keyboard becomes a fixed, reliable thing. It does what it does, and it does it the same way every time. No software updates, no configuration drift.
That permanence is underrated. I've got a macro pad I built four years ago — still running the same firmware. It's outlasted two laptops. The muscle memory is so ingrained that if I sit down at someone else's desk, my fingers reach for keys that aren't there.
I do that with my own keyboard shortcuts. I'll be at a café, using a borrowed machine, and my hands just do the thing — and then nothing happens, and I'm briefly confused about where I am.
And that's the argument for bringing your macro pad with you. If you travel with a laptop, a small macro pad in your bag means your workflow travels too. nine I mentioned is tiny — it fits in a pocket.
Let's talk about the build process for a custom macro pad, because Daniel said he'd consider it. If someone's never soldered, never flashed firmware, never assembled a keyboard — is this actually accessible?
If you go hot-swap, you don't need to solder at all. The switches press into sockets that are pre-soldered on the P. It's literally push-fit. The only tool you might need is a screwdriver for the case. And flashing firmware — if you can use a terminal, you can flash QMK. It's a single command: "qmk flash" and then you press the reset button on the board. That's it.
If something goes wrong?
It's almost impossible to brick a QMK board because there's a physical reset button that puts it into bootloader mode. Even if the firmware is completely corrupted, the bootloader is in a separate part of the chip. You hold the button, you flash, you're back.
That's reassuring. The worst-case scenario is "try again.
The mechanical keyboard community has done an incredible job of making this accessible. Ten years ago, you needed to be an embedded systems programmer to build a custom keyboard. Now, you need to be able to follow a YouTube tutorial. The QMK Configurator is a web app. VIA is a desktop app that lets you remap keys in real time without even reflashing. The tooling has matured enormously.
VIA specifically — that's the one where you change a key mapping and it takes effect immediately?
You open VIA, you click the key you want to change, you pick the new function from a dropdown, and it's live. No recompile, no reflash. It's like the System Preferences of keyboards. For someone like Daniel who wants to experiment with different layouts, VIA is a game-changer. He can try F thirteen for dictation start, decide he prefers F fifteen, change it in three seconds.
That's the kind of rapid iteration that makes a workflow stick. If changing a key binding requires recompiling firmware, you'll put up with a suboptimal setup for weeks. If it's instant, you tweak until it's perfect.
"perfect" is personal. What makes sense to Daniel's fingers and brain might not make sense to mine. The whole point of this hardware path is that the tool conforms to you, not the other way around.
Let's address the elephant in the room: cost. Daniel's looking at cheap AliExpress pads now. If he goes the custom route, what's the realistic budget?
Let me break it down. A Keebio B. nine macro pad kit: the P. is about thirty dollars. A simple plastic case is maybe fifteen. Nine switches — Gateron or similar — about five dollars total. Nine keycaps, maybe ten dollars for a basic set. So we're at sixty dollars. If he wants a full custom keyboard instead, the Keychron Q series starts around a hundred and fifty, switches included. Custom keycaps from W. are another sixty or seventy. So the all-in custom keyboard with custom legends is maybe two hundred twenty dollars. That's not cheap. But it's also not "custom mechanical keyboard" prices from five years ago, which could easily hit five hundred.
Compared to buying three or four cheap macro pads over a couple of years as they break or become limiting?
The custom route probably breaks even within two years and then keeps going for a decade. The switches are rated for fifty to a hundred million keystrokes. has no moving parts except the U. port, and if you get one with a detachable cable, even that's replaceable. These things are tanks.
The economic argument actually favors custom, assuming you stick with the workflow.
Daniel's been doing this workflow long enough that we can assume he'll stick with it. He's not dabbling. He's optimizing.
Let's shift to the broader question Daniel asked — the video editor, the C. They're not necessarily technical in the same way. They might not want to flash firmware. What's their path?
For the less technical user, I'd point them toward pre-built solutions that support VIA. There are keyboards now — from Keychron, from Drop, from Epomaker — that come with QMK and VIA pre-installed. You plug it in, you open VIA, you remap keys. No terminal, no command line, no firmware compilation. It's as easy as configuring a Logitech mouse. And for macro pads specifically, the Elgato Stream Deck is the mainstream option — it's got little L. screens behind each key, so the label changes dynamically. Video editors love those because they can have icons for cut, ripple delete, whatever. The downside is it requires proprietary software and it's not a mechanical keyboard — it's membrane buttons with screens.
The Stream Deck is the "it just works" option for non-technical users, but it locks you into software that might not be great on Linux.
Elgato's Linux support is community-driven and unofficial. It works, but it's not guaranteed. For a Linux user — which Daniel is — the QMK route is more reliable long-term.
What about the C. They've got a different set of constraints — often working with a three-D mouse in one hand and a regular mouse in the other, or a stylus. Where does the macro pad fit?
users often put the macro pad on the left side of the keyboard, or between the keyboard and the three-D mouse. The macros are typically things like "extrude," "fillet," "dimension" — commands used hundreds of times per session. In AutoCAD, these are normally short text commands you type — "E X T" for extrude, "F" for fillet. A macro pad just sends those strings with an Enter at the end. It's the same concept as Daniel's "claude" macro, just different strings.
user might want more keys than the voice dictation user. Ten or fifteen instead of five.
Which is where the southpaw layout or a dedicated numpad-as-macro-grid shines. A standard numpad has seventeen keys. Remap all of them to C. commands, put custom keycaps on with the command names, and you've got a dedicated C. input device for under a hundred dollars.
That's clever. Repurpose a numpad rather than buying a specialized macro pad.
Numpads with QMK support are easy to find. The Keychron Q zero is basically a numpad that runs QMK. It's seventy dollars. It's got a knob. It's aluminum. It's a fantastic macro pad in disguise.
I love the knob. What does the C. user do with a knob?
Zoom in and out. Or rotate the view. Or scrub through the timeline if they're in video editing. A rotary encoder is incredibly satisfying for continuous adjustments. You twist, the view moves. It's tactile in a way that a scroll wheel isn't quite.
The ideal setup for a power user might be: main keyboard, macro pad with a couple of knobs, and custom keycaps labeling everything. That's the endgame.
That's the endgame. And it's achievable for a few hundred dollars and an afternoon of setup. The barrier has dropped so much.
Let's talk about one more thing Daniel mentioned — the "pause-break key" and running out of keys. That's a real frustration. You start mapping macros to Scroll Lock, Pause Break, Insert — keys that modern keyboards barely have anymore — and then you realize you've only got three of those and you need ten.
Those keys are sometimes treated weirdly by operating systems. Pause Break dates back to the original I. where it literally paused the screen output. Modern operating systems don't know what to do with it half the time. Some Linux distros map it to nothing. Some map it to "stop X server," which is catastrophic if you hit it by accident.
I've done that. It's not fun.
Relying on those legacy keys is fragile. F thirteen through F twenty-four is much safer because the operating system knows they're function keys — it just doesn't have anything bound to them by default. They're defined, they're recognized, they're inert. That's exactly what you want for macros.
Daniel's already using F thirteen. He's on the right track. He just needs more of them, and he needs a hardware platform that supports layers so he's not limited to twelve.
That's the summary, really. F thirteen through F twenty-four for key bindings. QMK or ZMK firmware for programmability. Layers for expanding beyond physical key count. Hot-swap kits for easy assembly. Custom keycaps for labels. That's the stack.
It's a stack that didn't exist in a consumer-friendly form five years ago. The mechanical keyboard hobby has productized everything Daniel needs.
It's only getting better. ZMK — the wireless firmware — is adding features rapidly. There are now keyboards with e-ink displays built in. There are macro pads with little round screens under each key that change based on the layer. The hardware is catching up to what people actually want: buttons that tell you what they do, and do it reliably.
The dream, really. A button that says what it does and does what it says.
We contain multitudes, but our keyboards shouldn't have to.
So to land this: Daniel, your F thirteen instinct is correct. Keep using F thirteen through F twenty-four for key bindings — they're the safest, most portable option across operating systems. For hardware, the cheap AliExpress pads are fine for testing, but the long-term play is something that runs QMK with VIA support. nine kit or a Keychron Q series, depending on whether you want a separate macro pad or an all-in-one keyboard. Custom keycaps with your own legends — "DICTATE," "PUSH," "PAUSE" — are worth the money because they reduce cognitive load. And the whole thing, assembled, will cost you somewhere between sixty and two hundred twenty dollars depending on how deep you go, and it'll last a decade.
If you want to go fully custom with your own keyboard design — a from-scratch layout — that's a bigger project but it's doable. There are services that will fabricate a custom P. from your design files. People do this. It's a whole subculture.
