Case study
Giving a vendor-unsupported keypad a native Linux workflow
Built a Linux driver and local React configuration app for the Huion Keydial Mini K20, remapping all 18 keys and its dial over Bluetooth or USB.
-
Situation
What was true before anything changed.
The K20 presented fixed keyboard input and had no useful Linux configuration path. Using it as a programmable creative-workflow controller required both an input-layer driver and a way to configure it without editing files by hand.
-
Constraints
What could not be moved.
The same path had to work over Bluetooth and USB, suppress the original keystrokes, preserve user-level security, update mappings without service restarts, and remain understandable to people who did not want to operate a driver from the terminal.
-
Decision
What was chosen, and over what.
Grab the device through Linux evdev, emit chosen actions through uinput, run the driver as a user service, persist profiles as YAML, and expose the same behavior through a CLI, local HTTP/WebSocket API, and React/Vite interface.
-
Tradeoff
What it cost, knowingly.
The result is Linux-specific and presently alpha software maintained by one person. Installation still requires one-time device-access and service setup, and command execution is constrained rather than delegated to an arbitrary shell.
-
Outcome
What changed, in reach rather than volume.
The public MIT-licensed implementation supports all 18 buttons and the dial, shortcuts, multi-step macros, application launch, profile switching, live input feedback, Bluetooth and USB operation, CLI control, and visual configuration.
-
Retrospective
What would be done differently.
Separating hardware input, action mapping, and configuration behind a local service made the driver usable from more than one interface. Broader hardware support, packaging, and real adoption measurements remain future evidence, not claims.
Detail
Keydial Commander is public source under the MIT license. Its architecture keeps device access, action mapping, and presentation separate: the driver owns the hardware path, the local service owns profiles and live updates, and the CLI and web interface are two clients of the same capability.
That boundary is what turns a one-off input hack into a maintainable tool. It also makes the limitations explicit: Linux is the supported platform, packaging is still evolving, and there is no claim here about adoption beyond what the repository itself proves.