rotary_dial_kmod verwandelt eine Wählscheibe eines Telefons in ein evdev-Eingabegerät unter Linux, sodass Wählimpulse wie Eingaben auf einem Nummernblock verarbeitet werden können- Die Funktionsweise basiert darauf, die BUSY/PULSE-Schalter mit GPIO-Pins eines SoC zu verbinden; wegen der mechanischen Kontakte ist eine Entprellung nötig
- Je nach Land und Hersteller können sich Kontaktbezeichnungen, Pulslängen und Zahlencodierung unterscheiden, daher sind die tatsächliche Verdrahtung und Beschriftung wichtig
- Nutzer konfigurieren in der devicetree einen
rotary-dial-Knoten sowie pulse-gpios und busy-gpios und bauen/laden den Treiber anschließend als Out-of-Tree-Kernelmodul
- Auch ohne echte Hardware lassen sich in einer Entwicklungs-VM über
gpio-sim simulierte BUSY/PULSE-GPIOs steuern und End-to-End-Tests ausführen
Wählscheibe in ein evdev-Eingabegerät umwandeln
rotary_dial_kmod ist ein Linux-Kernel-Treiber, der eine Wählscheibe eines Telefons in ein evdev-Eingabegerät verwandelt- Gedacht ist er für Situationen wie diese
- wenn man langsameres Wählen gegenüber einem Nummernblock bevorzugt
- wenn man ein altes Wählscheibentelefon in einer digitalen Umgebung nutzen möchte
- wenn man ein einfaches Treiberbeispiel mit VM-basierter End-to-End-Entwicklungs- und Testumgebung ohne echte Hardware benötigt
- und für andere kreative Anwendungsfälle
Verdrahtung und Signalverhalten
- Dieses Projekt behandelt die Wählscheibe als Gerät aus zwei Schaltern: BUSY und PULSE
- BUSY ist normally open
- PULSE ist normally closed
- Beide Schalter werden über Pull-up-Widerstände mit GPIO-Pins eines Embedded-Linux-SoC verbunden
- Beim Aufziehen der Wählscheibe schließt der BUSY-Schalter, und der busy-Pin wird auf low gezogen
- Während die Wählscheibe in ihre Ausgangsposition zurückläuft, öffnet sich der PULSE-Schalter wiederholt, und der pulse-Pin wird auf high gezogen
- Da es sich um mechanische Schalter handelt, kann Prellen auftreten
Unterschiede nach Land und Hersteller
- Die Bezeichnungen der Schaltkontakte können je nach Land und Hersteller unterschiedlich sein oder fehlen
- In Deutschland heißt der BUSY-Schalter nsa
- In Deutschland heißt der PULSE-Schalter nsi
- Wenn die Pinbelegung unklar ist, sollte man die Wählscheibe langsam bewegen und die Schalterreaktion mit dem Durchgangsprüfer eines Multimeters prüfen
- Auch Tastverhältnis und Dauer des Pulssignals unterscheiden sich je nach Land und Hersteller
- Im deutschen Beispiel ist der PULSE-Schalter pro Puls 62 ms geöffnet und 38 ms geschlossen
- In den meisten Fällen entsprechen 1–9 Pulse den Ziffern 1–9, und 10 Pulse entsprechen 0
- Einige Länder verwenden eine andere Codierung; im schwedischen Beispiel entspricht 1 Puls der 0, und 10 Pulse entsprechen der 9
- Wenn man sich nicht sicher ist, sollte man die Beschriftung der Wählscheibe prüfen
Nutzung des Kernelmoduls
- Der Treiber ist ein standardmäßiges Out-of-Tree-Kernelmodul
- Die Nutzung setzt voraus, dass eine Linux-Kernel-Build-Umgebung vorbereitet ist und Build-Host und Ziel-Host identisch sind
- In realen Umgebungen wird häufig mit einer von Yocto oder Buildroot bereitgestellten Cross-Toolchain gebaut
- In der devicetree wird ein
rotary-dial-Knoten hinzugefügt
- Die Eigenschaft
pulse-gpios wird an den pulse-GPIO-Pin gebunden
- Die Eigenschaft
busy-gpios wird an den busy-GPIO-Pin gebunden
- Über die Eigenschaft
linux,keycodes kann die standardmäßige Keycode-Map optional geändert werden
- Weitere Informationen und Beispiele finden sich im devicetree binding
- Die Umgebungsvariable
KDIR muss auf den Kernel-Quellbaum zeigen
- Build, Installation und Laden erfolgen mit den folgenden Befehlen
make
make install
modprobe rotary_dial
- Sobald das Kernelmodul geladen ist, erscheint ein Eingabegerät für die Wählscheibe, das abhängig vom Keycode-Mapping standardmäßig wie ein Nummernblock funktioniert
- Zum Debugging kann das Paket evemu verwendet werden
- Mit
evemu-describe lassen sich die Eigenschaften des Eingabegeräts prüfen
- Mit
evemu-record lassen sich Wählereignisse überwachen
Entwicklungs-VM und Simulation
- Für Treiberentwicklung und End-to-End-Tests wird eine VM bereitgestellt
- Auf den Linux-Kernel der VM ist ein devicetree-Patch angewendet
- Diese devicetree stellt über gpio-sim simulierte busy- und pulse-GPIO-Leitungen bereit
- Aus dem Userspace lassen sich die GPIO-Leitungen manipulieren, um einen Wählvorgang zu simulieren
- Die Nutzung der VM läuft wie folgt ab
- Nix package manager installieren
- flakes aktivieren
- Mit
make vm die VM bauen
- Das kann dauern, weil der Kernel mit eigener Konfiguration und devicetree-Patch neu gebaut werden muss
- Mit
make run-vm die VM starten
- Nach dem Start erfolgt automatisch der Login in eine Entwicklungs-Shell
- In der VM zeigt
KDIR auf die Kernel-Build-Artefakte der VM, sodass der Treiber allein mit make gebaut werden kann
- Für einige Targets von
clang-format und clang-tidy reichen die Build-Artefakte nicht aus; KDIR muss auf separat heruntergeladene Kernel-Quellen zeigen
- Nach dem Build kann der Treiber über die Targets
insmod und rmmod geladen bzw. entladen werden
rotary_dialer und Tests
rotary_dialer simuliert das Wählen von Ziffern durch Manipulation der GPIO-Leitungen- Der Build erfolgt mit folgendem Befehl
make rotary_dialer
- Ein Beispiel für das Wählen von drei Pulsen sieht so aus
test/rotary_dialer 3
- Wenn man zur Shell zurückkehrt, sollte die Ziffer
2 angezeigt werden, da die simulierte devicetree eine schwedische Codierung konfiguriert hat
- Die Testsuite kann in der Entwicklungs-VM ausgeführt werden
make test
- Die Tests laden das Kernelmodul und führen mehrere Fälle aus
- Sie prüfen die Funktion des Eingabegeräts
- Sie prüfen nach dem Wählen einer gegebenen Pulszahl, ob der erwartete Keycode ausgegeben wird
- Sie prüfen, ob fehlerhafte Eingaben korrekt verarbeitet werden
Aufnahme in den Mainline-Kernel
- Die Projektbeschreibung endet mit dem Witz, dass sie einer Zukunft mit Wählscheiben als Eingabegeräten positiv gegenübersteht, Linus Torvalds dem aber womöglich nicht zustimmt
1 Kommentare
Meinungen auf Hacker News
Ende der 70er habe ich mit einem HP41C-Taschenrechner einen Wählscheiben-Dialer gebaut.
Ich verband ein NC-Reed-Relais mit einem piezoelektrischen Summer und schaltete den NC-Kontakt in Reihe zur Telefonleitung.
Um die kurzen Pieptöne zu erzeugen, die für die Wählimpulse nötig waren, nutzte ich Synthetic Programming mit undokumentierten Opcodes; wenn man Namen alphanumerisch eingab, konnte er die Nummer nachschlagen und wählen.
Vor etwa zehn Jahren traf ich in der Firma jemanden namens Keith Jarrett, und noch bevor ich fragen konnte, ob er der Keith Jarrett sei, der das HP-41C Synthetic Programming Manual geschrieben hatte, sagte er: „Nein, ich bin nicht der Musiker. Das fragen alle.“
Also stellte ich meine Frage zu Ende, und weil er tatsächlich der Autor des Buchs war, das ich 35 Jahre zuvor gelesen hatte, war auch er sehr erfreut und überrascht.
https://picclick.com/HP-41-Synthetic-Programming-Made-Easy-b...
https://www.hpmuseum.org/prog/synth41.htm
Ich habe auch noch die gedruckte Anleitung zu Synthetic Programming.
Selbst ohne diese Technik war dieser Taschenrechner für die frühen 1980er ein äußerst mächtiges programmierbares Werkzeug.
Mit demselben Freund schrieb ich auch ein Programm, das sämtliche Berechnungen für einen Graduiertenkurs zur S-Parameter-Modellierung von HF-Übertragung erledigte; als wir es dem Professor vorführten, wurden als „Belohnung“ Rechnerprogramme in allen Prüfungen verboten.
Erst später verstand ich, dass es zwischen dem HF-Bereich und der digitalen Elektronik im Fachbereich Elektrotechnik einen Revierkampf gab.
Der HP-41CX-Taschenrechner brachte mir eine der wichtigsten Lektionen meines Elektrotechnikstudiums bei: Bei menschlichen Entscheidungen steht Technik oft nicht an erster Stelle.
Ich habe mit einem hp49g etwas Ähnliches gemacht und war stolz darauf, in einer eingeschränkten Umgebung programmiert zu haben; wenn das aber auf dem einzeiligen Display des 41c passiert ist, wäre das wirklich eine beachtliche Leistung.
Als kleine Eigenwerbung für Leute, die Wählscheibentelefone mögen: Ich habe mein Telefon zu einem voll funktionsfähigen Bluetooth-Headset umgebaut, einschließlich Nummernwahl über die Wählscheibe.
Der HN-Beitrag lief nicht besonders, aber Hackaday hat es vorgestellt.
https://hackaday.com/2024/10/31/bakelite-to-the-future-a-195...
https://blog.waleson.com/2024/10/bakelite-to-future-1950s-ro...
Es dürfte nicht schwer sein, alternative Modi für ein Bluetooth-Wählscheiben-Ziffernfeld zu bauen.
Jetzt muss ich nur noch die Zeit finden.
Als das iPhone noch nur ein Gerücht war, schlug ich vor, dass ein Touch Wheel wie beim damaligen iPod eine gute Gelegenheit wäre, die Wählscheibe wiederzubeleben.
Alle Anwesenden lehnten das entschieden ab, aber immerhin braucht man jetzt nur noch eine Linux-Box, um dieses klassische Wählscheiben-Gefühl nutzen zu können.
Steve Jobs war ebenfalls als einer der Erfinder dieses Patents aufgeführt.
Ein anderer Apple-Kollege und ich reichten fast zur gleichen Zeit ein nahezu identisches Patent ein, und eine Weile besaß Apple zwei Patente darauf, eine Wählscheibe auf einem Touch Wheel zu simulieren.
Mein Patent ist schließlich verfallen, Steves Patent wurde verlängert.
Ich hatte diese Idee einem Kollegen bei einem Abendessen in SF vorgeschlagen, nachdem wir ziemlich viel getrunken hatten; ich dachte dabei an ein altes Flipper-Spiel, dessen haptisches Gefühl so gut war, dass es sich echt anfühlte.
Der Kern war meiner Meinung nach, eine Dial-Physik umzusetzen, mit der Nutzer jede beliebige Ziffer durch die passende Geste schnell „drehen“ können.
Als ich die Idee hatte, war ich nicht in die iPhone-Informationen eingeweiht, aber mein Kollege schickte sie an das Patentkomitee, und sie wurde genehmigt.
Angesichts der Ähnlichkeit zu Steves Patent dürfte das Komitee gelacht haben, aber es gab auch deutliche Unterschiede, daher war es keine Doppelung.
Vermutlich wollte man jedoch die Zahl der iPhone-bezogenen Patente als Teil des frühen Marketings erhöhen. Steve sagte bei der iPhone-Präsentation ja bereits, es gebe „über 200 Patente“.
Als Eingabe könnte man das hier verwenden: https://www.youtube.com/watch?v=9BnLbv6QYcA
Jetzt ist es an der Zeit, dass jemand dieses Wählscheibentelefon richtig nutzt und damit Dark Souls durchspielt.
Es braucht eine DTMF-Version.
In Australien gibt es jemanden, der eine sehr kleine Box baut, die allein mit Leitungsspeisung läuft und Wählimpulse in Touch Tone umwandelt.
Dank ihr konnte ich mein Wählscheibentelefon weiter benutzen, bis ich vor ein paar Jahren in ein Gebäude ohne POTS-Verkabelung umzog. Schade.
Ich betreibe so immer noch mehrere Telefone, darunter ein Kerzenständertelefon aus den 1920ern.
Sehr gut. Ich mag solche minimalen Treiber-Implementierungen
Sie zeigen, wie wenig echter Code in einem Treiber nötig ist, aber zugleich auch, wie viele Flags und Kernel-Methoden man kennen muss, um einen einfachen Treiber zum Laufen zu bringen
Interessant und ziemlich enttäuschend, aber nicht unerwartet, ist die Stelle: „Anfangs wollte ich den Treiber in Rust neu implementieren, um mir den Stand des Projekts Rust for Linux anzusehen, merkte aber bald, dass die nötigen Bindings noch fehlen und ich auf diesen Teil warten musste“
Es wäre wohl ein interessanter Blogpost, den Ansatz und die aufgetretenen Hindernisse zu dokumentieren
Wenn die Unterstützung etwa im nächsten Jahr reifer ist und eine Neuimplementierung in Rust möglich wird, schreibe ich meine Erfahrungen gern auf
Das erinnert mich an eine Sache mit Wählscheibentelefonen vor etwa 30 Jahren
Ich habe zwar selbst kein Wählscheibentelefon benutzt, aber es ging um ein Telefonnetz, das noch mit solchen Telefonen kompatibel war
Statt es hier noch einmal zu schreiben, lasse ich den Link da:
https://news.ycombinator.com/item?id=40391220
Um die Neugier zu wecken: In der Geschichte kommen lautes Klopfen und „San Jose Police! Open up!“ vor
Weil 112 leichter zu wählen war; dann stellte sich heraus, dass ich denselben Kommentar schon geschrieben hatte, als ich den Beitrag vor einem Jahr zum ersten Mal gesehen habe
Das erinnert mich daran, wie Sarah im Connections Museum in Seattle einen Treiber geschrieben hat, damit eine Asterisk-Soft-PBX auf einer Linux-Box per revertive pulse signaling mit den pre-DTMF-Trunks einer alten Telefonvermittlung kommunizieren kann
https://www.youtube.com/watch?v=35N5vKKGDy8
Als amüsante historische Wendung war bei neuseeländischen Wählscheibentelefonen die Zuordnung von Ziffern und Impulszahlen umgekehrt
Dort betrug die Impulszahl 10 - Ziffer
Ich glaube, ich bin einer der sehr wenigen noch lebenden Menschen, die diesen Grund kennen, also teile ich ihn, damit das Wissen nicht verschwindet
Unter den relativ frühen mechanischen Telefonvermittlungen gab es die rotary exchange [0]
Die vom Telefon kommenden Impulse kuppelten in der Vermittlung eine Kupplung ein, bewegten einen rotierenden Antrieb, und dieser bewegte die Vermittlungseinrichtung
Eines der Probleme der rotary exchange war, dass die Kupplungsbeläge verschlissen und die Verbindung unzuverlässig wurde
In Aotearoa/NZ gab es bereits einen bestehenden Nummernplan, als man beschloss, rotary exchanges zu installieren
Jemand Kluges kannte das Verschleißproblem und berechnete, dass ausgehend vom bestehenden Nummernplan der Gesamtverschleiß der Beläge deutlich geringer wäre und weniger Wartung nötig wäre, wenn die Position 1 auf der Wählscheibe 9 Impulse erzeugt
So entstand dieses Verfahren
Eine weitere interessante Tatsache ist, dass meines Wissens auch Norwegen für Wählscheibentelefone dieselbe Konfiguration gewählt hat
Ob aus demselben Grund, weiß ich nicht sicher
[0] https://en.wikipedia.org/wiki/Rotary_system
Gerade liegt auf meinem Schreibtisch ein zerlegtes Wählscheibentelefon, und ich bin dabei, die Uhrfeder wieder aufzuziehen, da erscheint dieser Beitrag
Ein merkwürdiger Zufall
Wenn es bei dir ähnlich ist wie bei mir, dürften es ungefähr 2 Jahre sein