Kernel-Treiber, der ein Legacy-Wählscheibentelefon in ein Linux-Eingabegerät verwandelt

• Der Rotary Phone Dial Linux Kernel Driver ist ein Kernel-Modul, das ein altes Wählscheibentelefon in ein evdev-Eingabegerät unter Linux umwandelt
• Das Projekt stellt einen einfachen Beispieltreiber und eine VM-basierte Entwicklungsumgebung bereit und ist dadurch auch für Lern- und Testzwecke sehr nützlich
• Entwicklung und Tests sind auch ohne echte Hardware möglich; GPIO-Simulation wird unterstützt
• Es unterstützt nahezu jede Keymapping-Konfiguration und kommt auch mit den verschiedenen Puls-Kodierungsverfahren unterschiedlicher Länder zurecht
• Da es sich um ein Standard-Kernel-Modul handelt, lässt es sich leicht in Linux-Systeme erweitern und integrieren

---

Überblick über den Rotary Phone Dial Linux Kernel Driver

• Dieses Projekt ist ein Kernel-Modul, das die Wählscheibe eines alten Telefons in ein Standard-Eingabegerät eines Linux-Systems (z. B. einen Nummernblock) umwandelt
• Es ist unter anderem interessant für folgende Nutzergruppen
  • Wer Zahlen über langsames Wählen eingeben möchte
  • Nutzer, die ein altes analoges Telefon ins digitale Zeitalter holen möchten
  • Lehrende, die einen Beispiel-Kernel-Treiber und eine virtuelle Entwicklungs-/Testumgebung ohne echte Hardware benötigen
  • Sonstige kreative Experimente

Schaltungsanschluss

• Eine Wählscheibe besteht grundsätzlich aus zwei Schaltern: BUSY (offener Zustand) und PULSE (geschlossener Zustand)
  • Diese beiden Schalter werden zusammen mit Pull-up-Widerständen an die GPIO-Pins eines Systems mit Embedded Linux angeschlossen
• Wird die Wählscheibe gedreht, wechselt der BUSY-Schalter in den geschlossenen Zustand, und während die Scheibe in ihre Ausgangsposition zurückkehrt, öffnet und schließt der PULSE-Schalter wiederholt
• Da Anschluss und Pinbelegung je nach Land oder Hersteller unterschiedlich sind, wird empfohlen, das Schaltverhalten mit einem Multimeter zu testen
• Auch Duty Cycle (Öffnungs-/Schließzeit) des Pulssignals und das Dekodierungsverfahren unterscheiden sich je nach Land und Hersteller
  • Beispiel: In Deutschland beträgt die Öffnungszeit pro Puls 62 ms, die Schließzeit 38 ms
  • Üblicherweise stehen ein bis neun Pulse für 1–9 und zehn Pulse für 0 (mit Ausnahmen wie Schweden)
• Im Zweifel sollte das Label der Wählscheibe geprüft oder ein Test durchgeführt werden

Verwendung

• Dieser Treiber ist ein standardmäßiges out-of-tree kernel module
• Die Schritte in Kurzform
  • Im Device Tree einen rotary-dial-Knoten hinzufügen und pulse-gpios sowie busy-gpios auf die realen Pins abbilden
  • Falls nötig, die Keycode-Zuordnung über die Eigenschaft linux,keycodes ändern
  • Den Kernel-Quellpfad (KDIR) als Umgebungsvariable setzen, dann bauen, installieren und das Modul laden
• Nach dem Laden des Kernel-Moduls wird ein Eingabegerät erzeugt, das sich wie ein Nummernblock verhält
• Mit dem Tool evemu lassen sich die Eigenschaften des Eingabegeräts und die Wählscheiben-Ereignisse überwachen

Virtuelle Maschine (VM) für Entwicklung und Tests

• Für die Treiberentwicklung und End-to-End-Tests wird eine VM-Umgebung bereitgestellt
  • Diese VM patcht den Device Tree mit durch gpio-sim simulierten busy/pulse-GPIOs
  • GPIOs können aus dem User Space gesteuert werden, um Testszenarien umzusetzen
• Nach Aktivierung des Nix-Paketmanagers und der Flakes-Funktion lässt sich die VM bauen und starten
• Innerhalb der VM landet man direkt in einer Development Shell
• Nach dem Bauen des Treibers werden auch das Laden und Entladen des Moduls unterstützt
• Mit dem Tool rotary_dialer lässt sich zur Prüfung der Wähleingabe eine bestimmte Pulszahl simulieren
  • (In einer schwedischen Kodierungsumgebung werden 3 Pulse beispielsweise als die Ziffer 2 erkannt)

Tests

• Der Treiber wird zusammen mit einer umfassenden Testsuite bereitgestellt
• In der VM-Umgebung lassen sich mit make test automatisierte Testfälle ausführen
  • Dabei können verschiedene Szenarien geprüft werden, etwa die korrekte Funktion des Eingabegeräts, die Ausgabe des richtigen Keycodes bei gewählten Ziffern oder die Behandlung fehlerhafter Eingaben

Aufnahme in den Mainline-Kernel

• Der Entwickler blickt optimistisch auf die Zukunft der Wählscheibe, merkt aber scherzhaft an, dass Linus Torvalds das womöglich anders sieht

[GN⁺]

Hacker-News-Kommentare

• Jemand erinnert sich daran, Ende der 70er mit einem HP41C-Taschenrechner selbst einen Wählscheiben-Telefondialer gebaut zu haben: Ein kontaktloses Reed-Relais wurde mit einem Piezo-Summer und der Telefonleitung verbunden, und mithilfe von „synthetic programming“ (undokumentierte Befehle) erzeugte man kurze Pieptöne, um die Wählimpulse zu vervollständigen. Verwendet wurde ein Verfahren, bei dem man einen Namen eingab (mit Alphabet-Unterstützung), die Nummer gesucht und sofort gewählt wurde. Außerdem eine Anekdote von vor zehn Jahren aus einer Firma, als die Person Keith Jarrett traf und Leute ihn oft mit dem Musiker verwechselten; sie fragte stattdessen, ob er der Autor des HP-41C Synthetic Programming Manual sei, worauf er überrascht und erfreut reagierte. Dazu gab es Links zu Buchinfos und Informationen zu synthetic programming
  • Jemand fragt, ob dieses Programm direkt auf dem Rechner geschrieben wurde, und erzählt stolz, selbst auf einem hp49g direkt programmiert zu haben; beim 41c mit seinem einzeiligen Display sei das wohl eine noch viel größere Herausforderung gewesen
• Jemand berichtet, ein Wählscheibentelefon zu einem vollständigen Bluetooth-Headset umgebaut und auch das Wählen per Scheibe ermöglicht zu haben. Auf HN sei die Reaktion verhalten gewesen, aber die Vorstellung auf hackaday habe stolz gemacht. Verlinkt wurden das zugehörige Projekt und ein persönlicher Blogpost. Ein Bluetooth-Wählscheiben-Nummernblockmodus ließe sich wohl ebenfalls leicht bauen, aber es fehle an Zeit
  • Heute wäre ein ESP32 die deutlich günstigere Wahl, aber die Person wollte unbedingt einen Linux-Kernel-Treiber schreiben und hat es deshalb selbst umgesetzt
• Aus der Zeit, als das iPhone nur ein Gerücht war, stammt die Erinnerung, vorgeschlagen zu haben, mit dem Touchwheel des iPod eine Wählscheibe nachzubilden, weil das Spaß machen würde — alle lehnten es ab. Dazu die Idee, für das klassische Wählscheiben-Gefühl eine Linux-Box einzurichten
  • Es wird klargestellt, dass man damit nicht allein war: Tatsächlich ließ sich Apple ein Patent für eine Touchwheel-Wählscheibe eintragen, und Steve Jobs steht auf der Erfinderliste. Die Person und Apple-Kollegen hätten ebenfalls ein fast identisches Patent eingereicht, aber letztlich sei das eigene Patent abgelaufen, während nur Steves Patent blieb. In einer Bar in SF sei die Idee entstanden, mit dem Touchwheel zu wählen, wobei die Physik-Engine eines Flippers eine wichtige Inspiration gewesen sei; diese Idee sei vom Patentkomitee anerkannt worden. Es habe Unterschiede zu Steves Patent gegeben, aber vielleicht sei es auch um die Strategie gegangen, die Zahl der iPhone-Patente zu erhöhen
  • Die Vorstellung, ein iPod wäre einfach mit Mobilfunknetz veröffentlicht worden, hätte eine interessante alternative Zeitlinie erzeugt. Außerdem wird ein Video zu effizientem Tippen verlinkt
  • Vermutung, dass es sicher irgendeine App gibt, mit der man auf einem Touchscreen per Wählscheibe telefonieren kann
• Begeisterung darüber, dass endlich jemand offenbar versucht hat, Dark Souls mit einem Wählscheibentelefon durchzuspielen
  • Das weckt Erinnerungen daran, Soul Calibur mit dem Angelruten-Controller der Dreamcast gespielt zu haben
• Es erinnert an Sarah vom Connections Museum in Seattle, die einen Treiber gebaut hat, um pulse signaling an einer alten Telefonvermittlungsanlage in Verbindung mit der Asterisk-Soft-PBX zu ermöglichen. Dazu gibt es auch ein Erklärungsvideo
• Beim Anblick dieser minimalistischen Treiberimplementierung fällt auf, dass der eigentliche Treibercode sehr klein sein kann, man aber trotzdem extrem viel über Kernel-Flags und Methoden wissen muss. Jemand hätte es gern in Rust nachgebaut, war aber enttäuscht, dass die nötigen Bindings noch nicht bereitstanden. Ein Blogpost über den Ansatz und die aufgetretenen Schwierigkeiten wäre ebenfalls interessant
  • Eingeständnis, dass derzeit nur wenige Subsystem-APIs Rust-Bindings unterstützen und man deshalb nicht weit genug gekommen sei; mit reiferer Unterstützung im nächsten Jahr wolle man es noch einmal versuchen und die Erfahrungen teilen
• Erinnerung daran, dass man bei Hayes-kompatiblen Modems statt ATDT den Befehl ATDP für Wählscheiben-Impulswahl verwenden konnte
• Als interessante historische Tatsache wird erwähnt, dass bei neuseeländischen Wählscheibentelefonen die Zuordnung von Ziffern und Pulsanzahl umgekehrt war; tatsächlich wurde ein 10-stelliges Pulsschema verwendet
  • Technische Erklärung dazu: Bei frühen mechanischen Telefonvermittlungen, den rotary exchange, verschlissen Kupplungsbeläge. Um den Gesamtverschleiß zu reduzieren, entstand in Neuseeland die Idee, die Zuordnung umzudrehen, sodass etwa die 1 neun Pulse erzeugte. Soweit bekannt, übernahm auch Norwegen dieses Verfahren. Dazu ein Wikipedia-Link zum rotary system
• Es wird angemerkt, dass eine DTMF-(Touchtone-)Umsetzungsversion nötig wäre. In Australien habe es kleine leitungsversorgte Boxen gegeben, die Wählimpulse in Touchtöne umwandelten. Dadurch konnten normale Telefonleitungen lange weiterverwendet werden, auch wenn neuere Gebäude inzwischen gar keine Telefonleitungen mehr haben, was bedauert wird
  • Mit Anschluss an FXS/ATA lässt sich so weiterhin ein VoIP-Telefon betreiben; sogar ein Kerzenständertelefon aus den 1920ern sei dank dieser Methode noch in Gebrauch
• Jemand findet den Zufall bemerkenswert, genau beim Lesen dieses Beitrags gerade ein Wählscheibentelefon zerlegt auf dem Schreibtisch liegen zu haben und die Feder aufzuziehen
  • Nachfrage, wie lange das Telefon tatsächlich schon zerlegt auf dem Schreibtisch liegt; man selbst kenne das nur zu gut, vermutlich seien es etwa zwei Jahre