Skip to content(if available)orjump to list(if available)

Show HN: Rotary Phone Dial Linux Kernel Driver

Show HN: Rotary Phone Dial Linux Kernel Driver

6 comments

·May 24, 2025

A Linux kernel driver that turns a rotary phone dial into an evdev input device. You might be interested in this driver if you

- prefer the slow pace of dialing over typing numbers with your numpad,

- want to bring your old rotary phone into the digital era,

- are an educator looking for a simple example driver with a VM-based end-to-end development & test environment (no real hardware needed)

- have another creative use case in mind!

This driver was my introduction to embedded Linux years ago—and ultimately led to my career. However, it remained unfinished and unpublished until now. Initially, I intended to reimplement the driver in Rust to explore the state of the Rust for Linux project. Unfortunately, I soon realized that the necessary bindings simply are not available yet, so that part will have to wait.

gchamonlive

About time somebody put that rotary phone to good use and beat Dark Souls with it.

CodeBeater

This article pops up as I have a rotary phone disassembled right on my desk (rewinding the clock spring). Neat coincidence!

jermaustin1

Real question: how long has the phone been disassembled on your desk?

If you are like me: around 2 years ;).

reaperducer

Need a DTMF version.

There's a guy in Australia who makes tiny line-powered boxes that translate rotary pulses into Touch Tones.

They let me keep using my rotary phones until a few years ago when I moved into a building that had no POTS wiring. Sad.

jeroenhd

Very nice! I love these minimal driver implementations. It shows off how little actual code you need for a driver (but also how many flags and kernel methods you need to know exist to make a basic driver work).

>Initially, I intended to reimplement the driver in Rust to explore the state of the Rust for Linux project. Unfortunately, I soon realized that the necessary bindings simply are not available yet, so that part will have to wait.

That's interesting (and quite disappointing, though hardly unexpected). I think documenting your approach and the setbacks you've encountered could make for an interesting blog post, if you care about writing such things.