This is one user's configuration on one Linux distribution, not a product launch. It is still a useful look at how fan control works, where it falls short, and how to add a manual override without giving up thermal protection.
The problem: temperature curves can't predict intent
A fan curve is a lookup table. Temperature goes in, fan duty comes out. Sherback says that for gaming, browsing and light work his curve is fine, and he has tuned it to stay gentle on his ears.
He names two situations a temperature-only curve handles badly:
- Long renders and encodes. The curve ramps only after heat builds, so the case warms up while the fans catch up. Sherback wants the fans running hard before temperatures climb, and he doesn't mind the noise because he walks away from the desk.
- Recording voiceover or music. He wants near-silence immediately. He says the large intake fans in his Fractal Torrent case can show up on his Shure SM7B microphone.
Neither is a temperature problem, which is why a smarter hysteresis setting won't fix it. He adds that for the render case, making the curve more aggressive is a simpler fix.
The hardware: a keyboard with heft and a knob
Sherback says the Yoga Creative Keyboard AngryMiao Edition is Lenovo's version of Angry Miao's ATM 98. He describes it as a 98-key board on a 2.6 kg aluminum base with a frosted polycarbonate top and two front USB-C ports that act as a hub. His review listing shows a $300 price at Lenovo. By default the knob controls volume, and a three-position switch changes its function.
Sherback's design keeps the knob's normal job and adds a fourth. Holding Ctrl while turning it adjusts fan speed, and turning it without Ctrl behaves as usual.
How the chain works
Sherback's setup has four links:
- keyd is a key-remapping daemon. It watches for the Ctrl-plus-knob combination.
- Instead of changing volume, a small script runs and nudges a number stored in a file.
- CoolerControl reads that file as if it were a temperature sensor.
- A straight-line curve turns the "temperature" into a fan duty. In his example, a dial value of 60 reads as 60 degrees and becomes 60 percent fan speed.
Sherback says the fans respond almost instantly when he holds Ctrl and turns the knob.
A correction on keyd's role
The keyd project describes itself as a system-wide remapping daemon built on kernel-level input primitives, evdev and uinput. keyd's man page documents a command() action that executes a shell command. It also warns that commands are executed by the user running the keyd process (probably root), so the feature should be used judiciously. That matches Sherback's description of a daemon that runs commands as root, and he acknowledges the setup isn't trivial.
The same man page says a bad config can render the machine unusable. The recovery sequence is backspace, escape and enter pressed together, which forces keyd to terminate. Anyone remapping their primary keyboard should know that before experimenting.
What CoolerControl expects from the file
Sherback describes the file value in shorthand. CoolerControl's documentation is stricter. For a temperature sensor, the file must hold a single whole number of zero or above in millidegrees Celsius. Its example is 80000 for 80°C. A value of 60 degrees would therefore be written as 60000, not 60. The docs list an upper bound of 120000.
CoolerControl also describes the failure behavior:
- The file is checked when you save the sensor.
- If it later becomes unreadable or out of range, the sensor keeps its last value for a few readings and then reports a failsafe.
- For a temperature sensor, the failsafe is 100°C, so a curve driven by it speeds the fans up.
So if the script breaks, a fan curve fed by the fake sensor ramps up rather than going silent. I'd still test that on your own machine rather than trust it.
The safety design
Sherback is open about the main risk: a person who forgets. Turn the dial down for a recording, start a heavy job an hour later, and the PC runs hotter than it should. His safeguards:
- Case fans only. The CPU cooler and the GPU's own fans stay on their automatic curves, so the parts that would throttle still respond to heat.
- A Mix profile with a backstop. The dial never drives the case fans alone. A CoolerControl Mix profile combines the dial with a thermal backstop curve and applies whichever asks for more speed. By his account, the backstop sits low until the hotter of the CPU or GPU crosses 75°C, then ramps up hard.
- Reset on reboot. The dial's value doesn't persist, so a bad setting can't linger forever.
CoolerControl's documentation supports the pattern. Mix Profiles combine multiple Graph Profiles using a mix function. The Maximum function is described as the most common choice for case fans. The docs' own example drives case fans from whichever of the CPU or GPU is hotter, using a separate curve for each. The 75°C threshold and the reboot reset are Sherback's choices, not CoolerControl defaults.
One nuance: CoolerControl says that when sensors have different ranges and dynamics, a Mix Profile is better than a Mix custom sensor. A fake dial sensor and a real temperature sensor are an obvious mismatch. That makes the Mix profile the right tool here.
Before you try something similar
This is not a one-click feature, and it isn't a Windows procedure. Sherback's setup is specific to CachyOS with keyd and CoolerControl. Nothing in the reporting shows an equivalent Windows workflow, so I won't suggest one.
A sensible checklist, drawn from CoolerControl's documentation:
- Confirm detection first. CoolerControl warns that undetected hardware cannot be controlled. Its Hardware Support card shows why a fan channel can't be controlled.
- Treat generated profiles as a starting point. The docs say to watch temperatures under a real load and confirm every fan responds as expected.
- Build the backstop before the dial. Only add the manual input once the thermal curve works on its own.
- Test the failure modes. Break the file, reboot, and run a heavy load with the dial turned down.
- Keep the keyd recovery sequence in mind. Also remember that anything keyd's
command()runs executes with the daemon's privileges.
Is it worth it?
Sherback's best argument is that curves can't know your intent. His best counterargument comes from his own article: a well-tuned curve is meant to make you stop thinking about fans. The setup stacks a root-level daemon, a shell script and a fake sensor on top of a problem that a mode switch or a steeper curve could partly solve. A recording-session mode in CoolerControl might also do the job, though that's my observation and not something Sherback tested.
The knob's real appeal is immediacy and tactile feedback. For people who record audio next to a loud PC, an instant physical control has clear value. For everyone else, a steeper curve is probably enough.
The broader idea is a good one. A keyboard knob that only ever changes volume has more potential, as long as you keep automatic thermal protection underneath it.