rotary_dial_kmod はロータリー式電話ダイヤルを Linux の evdev 入力デバイスに変換し、ダイヤル入力をテンキーのように扱えるようにする- 動作方式は BUSY/PULSE スイッチを SoC の GPIO ピンに接続する構成で、機械式接点の特性上デバウンス処理が必要
- 国やメーカーによって接点名、パルス長、数字エンコーディングが異なる場合があるため、実際の配線とラベルの確認が重要
- ユーザーは devicetree に
rotary-dial ノードと pulse-gpios、busy-gpios を設定したうえで、ツリー外カーネルモジュールとしてビルド・ロードする
- 実機がなくても 開発 VM で
gpio-sim ベースの BUSY/PULSE GPIO を操作し、エンドツーエンドテストを実行できる
ロータリーダイヤルを evdev 入力デバイスに変換
rotary_dial_kmod はロータリー式電話ダイヤルを evdev 入力デバイスに変換する Linux カーネルドライバ- 次のような状況を想定している
- テンキーより遅いダイヤル操作を好む場合
- 古いロータリー式電話機をデジタル環境で使いたい場合
- 実機なしで VM ベースのエンドツーエンド開発・テスト環境を備えたシンプルなドライバ例が必要な場合
- そのほかの創造的な用途
配線と信号の動作
- このプロジェクトでは、ロータリーダイヤルを BUSY と PULSE の 2 つのスイッチで構成されるデバイスとして扱う
- BUSY は normally open
- PULSE は normally closed
- 2 つのスイッチは pull-up 抵抗を介して組み込み Linux SoC の GPIO ピンに接続される
- ダイヤルを回すと BUSY スイッチが閉じ、busy ピンは low で駆動される
- ダイヤルが元の位置に戻る間、PULSE スイッチが繰り返し開き、pulse ピンは high で駆動される
- 機械式スイッチのため、チャタリングが発生することがある
国・メーカーごとの差異
- スイッチ接点の表記は国やメーカーによって異なる、あるいは存在しない場合がある
- ドイツでは BUSY スイッチを nsa と呼ぶ
- ドイツでは PULSE スイッチを nsi と呼ぶ
- ピン配置が不明な場合は、ダイヤルをゆっくり動かしながらマルチメーターの導通テスターでスイッチの反応を確認する
- パルス信号のデューティサイクルや継続時間も国やメーカーによって異なる
- ドイツの例では、1 パルスあたり PULSE スイッチが 62ms 開き、38ms 閉じる
- 多くの場合、1〜9 パルスは数字 1〜9 に対応し、10 パルスは 0 に対応する
- 一部の国ではエンコーディングが異なり、スウェーデンの例では 1 パルスが 0、10 パルスが 9 に対応する
- 不確かな場合は、ダイヤルのラベルを確認する必要がある
カーネルモジュールの使い方
- ドライバは標準的な ツリー外カーネルモジュール
- 使用手順は、Linux カーネルのビルド環境が整っており、ビルドホストとターゲットホストが同一であることを前提としている
- 実際の環境では、Yocto や Buildroot が提供する クロスツールチェーンでビルドすることが多い
- devicetree には
rotary-dial ノードを追加する
pulse-gpios プロパティは pulse GPIO ピンにバインドするbusy-gpios プロパティは busy GPIO ピンにバインドするlinux,keycodes プロパティでデフォルトのキーコードマップを任意に変更できる- 詳細情報と例は devicetree binding にある
KDIR 環境変数はカーネルソースツリーを指している必要がある- ビルド、インストール、ロードは次のコマンドで実行する
make
make install
modprobe rotary_dial
- カーネルモジュールがロードされるとロータリーダイヤル入力デバイスが現れ、キーコードマッピングに従ってデフォルトではテンキーのように動作する
- デバッグには evemu パッケージを使用できる
evemu-describe で入力デバイスの属性を確認するevemu-record でダイヤルイベントを監視する
開発 VM とシミュレーション
- ドライバ開発とエンドツーエンドテスト用の VM が提供されている
- VM の Linux カーネルには devicetree パッチ が適用されている
- この devicetree は gpio-sim を通じてシミュレートされた busy と pulse GPIO ラインを提供する
- ユーザー空間から GPIO ラインを操作してダイヤル操作をシミュレートできる
- VM の利用手順は次のとおり
- Nix package manager をインストールする
- flakes を有効化する
make vm で VM をビルドする- カーネルをカスタム設定と devicetree パッチ付きで再ビルドする必要があるため、時間がかかる場合がある
make run-vm で VM を起動する- 起動後は開発シェルに自動ログインされる
- VM では
KDIR が VM のカーネルビルド成果物を指すため、make だけでドライバをビルドできる
clang-format と clang-tidy の一部ターゲットではビルド成果物だけでは不十分で、KDIR は別途ダウンロードしたカーネルソースを指している必要がある- ビルド後は
insmod と rmmod ターゲットでドライバをロード・アンロードできる
rotary_dialer とテスト
rotary_dialer は GPIO ラインを操作して数字のダイヤル操作をシミュレートする- ビルドは次のコマンドで実行する
make rotary_dialer
test/rotary_dialer 3
- シェルに戻ると数字
2 が表示されるはずで、これはシミュレーション用 devicetree が スウェーデン式エンコーディングを設定しているため
- テストスイートは開発 VM で実行できる
make test
- テストではカーネルモジュールをロードし、複数のケースを実行する
- 入力デバイス機能を検証する
- 指定したパルス数をダイヤルした後、期待したキーコードが発行されるか確認する
- 不正な入力が適切に処理されるか確認する
メインラインへの取り込み可否
- プロジェクト説明は、ロータリーダイヤルを入力デバイスとして使う未来を前向きに描きつつ、Linus Torvalds は同意しないかもしれないという冗談で締めくくられている
1件のコメント
Hacker News のコメント
70年代末に HP41C 電卓でロータリー式電話のダイヤラーを作ったことがある
NCリードリレーを圧電ブザーにつなぎ、NC接点を電話線に直列に入れた
ダイヤルパルスに必要な短いビープ音を作るため、文書化されていない opcode を使う synthetic programming を使い、名前を英数字で入力すると番号を探して発信できた
10年ほど前、会社で Keith Jarrett という人に会ったのだが、HP-41C Synthetic Programming Manual を書いたあの Keith Jarrett なのか尋ねる前に、「いいえ、ミュージシャンではありません。みんなそれを聞くんです」と言われた
そこで質問を最後までしたところ、35年前に読んだその本の著者だったので、本人もとても喜び驚いていた
https://picclick.com/HP-41-Synthetic-Programming-Made-Easy-b...
https://www.hpmuseum.org/prog/synth41.htm
synthetic programming の紙のガイド本もまだ持っている
その手法を抜きにしても、この電卓は1980年代初頭の基準では非常に強力なプログラム可能ツールだった
同じ友人と、RF伝送のSパラメータ・モデリングの大学院授業の計算を全部処理するプログラムも書いたが、教授に自慢したら「報酬」として全試験で電卓プログラムの使用が禁止された
後になって、電気工学科のRF系とデジタル電子系の間に縄張り争いがあったことを知った
HP-41CX 電卓は電気工学の学位課程で最も重要な教訓の一つを教えてくれた。人間の意思決定では、技術が最優先でないことが多いということだ
hp49g で似たようなことをやったことがあり、制約のある環境でプログラムを書いたのを誇りに思っていたが、41c の1行表示でやったのなら、本当にすごい達成だったと思う
ロータリー式電話が好きな人向けに少し宣伝すると、自分の電話機を完全に動作する Bluetooth ヘッドセットに改造し、ロータリーダイヤルで電話番号をかける機能も入れた
HN の投稿はあまり伸びなかったが、Hackaday では紹介された
https://hackaday.com/2024/10/31/bakelite-to-the-future-a-195...
https://blog.waleson.com/2024/10/bakelite-to-future-1950s-ro...
Bluetooth ロータリー式数字パッドに代替モードを作るのは難しくなさそうだ
あとは時間を見つけるだけ
iPhone がまだ噂にすぎなかった頃、当時の iPod のようにタッチホイールを入れれば、ロータリーダイヤルを復活させるいい機会になると提案した
その場にいた全員にきっぱり却下されたが、おかげで今では Linux ボックスさえ用意すれば、あの古典的なロータリー感を使えるようになった
Steve Jobs もこの特許の発明者の一人として載っていた
私と別の Apple の同僚も、ほぼ同じ時期にほぼ同一の特許を出していて、しばらくの間 Apple はタッチホイールでロータリーダイヤルをシミュレートする特許を二つ保有していた
私の特許は最終的に失効し、Steve の特許は更新された
サンフランシスコでの夕食の席で少し飲み過ぎた状態で同僚にこのアイデアを提案したのだが、物理的な感触が非常によく本物のように感じられた古いピンボールゲームを思い浮かべていた
核心は、ユーザーが適切なジェスチャーでどんな数字でも素早く回せるようにダイヤルの物理感を実装することだと考えていた
このアイデアを出した時点で私は iPhone の情報を共有されていなかったが、同僚が特許委員会に送り、承認された
Steve の特許との類似点を見れば委員会は笑っただろうが、大きな違いもあったので重複ではなかった
ただ、初期マーケティングの一部として iPhone 関連特許の数を増やしたかったのだと思う。Steve も iPhone 発表時にすでに「200件を超える特許」があると言っていた
入力はこれを使えばいい: https://www.youtube.com/watch?v=9BnLbv6QYcA
そろそろ誰かがそのロータリー式電話をきちんと活用して Dark Souls をクリアする頃合いだ
DTMF 版が必要だ
オーストラリアに、回線電源だけで動くとても小さな箱を作っている人がいて、ロータリーパルスを Touch Tone に変換してくれる
数年前、POTS 配線のない建物に引っ越すまでは、そのおかげでロータリー式電話機を使い続けられていた。残念だ
私も1920年代の燭台型電話機を含め、何台もそうやって今も動かして使っている
とても良い。こういう最小限のドライバ実装が好き
ドライバに実際どれほど少ないコードしか必要ないかを示している一方で、基本的なドライバを1つ動かすだけでも、知っておくべきフラグやカーネルメソッドがどれほど多いかも示している
「最初は Rust for Linux プロジェクトの状況を見ようとしてドライバを Rust で再実装しようとしたが、必要なバインディングがまだないことにすぐ気づき、その部分は待つしかなかった」というくだりは興味深く、かなり残念だが予想外ではない
アプローチと遭遇した障害を文書化すれば、面白いブログ記事になりそう
来年あたりにサポートが成熟して Rust での再実装が可能になったら、ぜひ経験を書いてみたい
約30年前の回転式電話に関する出来事を思い出した
自分で回転式電話を使ったわけではないが、まだそうした電話と互換性のある電話網が関係していた
繰り返して書くより、ここにリンクを残しておく:
https://news.ycombinator.com/item?id=40391220
好奇心をそそるために言うと、大きなノック音と「San Jose Police! Open up!」が出てくる話
112 のほうがダイヤルしやすかったからだが、実は1年前にその投稿を初めて見たとき、すでに同じコメントをしていた
Seattle の Connections Museum で、Sarah が Linux マシン上の Asterisk ソフト PBXを古い電話交換機の pre-DTMF トランクと revertive pulse signaling で通信させるドライバを書いた話を思い出した
https://www.youtube.com/watch?v=35N5vKKGDy8
面白い歴史的なひねりとして、ニュージーランドの回転式電話では数字とパルス数の対応が逆だった
そこではパルス数が 10 - 数字だった
その理由を知っている存命のごく少数の一人かもしれないので、知識が失われないよう共有する
比較的初期の機械式電話交換機に rotary exchange があった [0]
電話機から来たパルスが交換機内のクラッチをつなげて回転駆動部を動かし、それがスイッチング装置を動かしていた
rotary exchange の問題の一つは、クラッチパッドが摩耗して接続が不安定になることだった
Aotearoa/NZ では rotary exchange を設置することになった時点で、すでに既存の番号計画があった
ある賢い人物が摩耗の問題を知っており、既存の番号計画を前提に、ダイヤルの1の位置が9パルスを出すようにすれば、全体のパッド摩耗が大幅に減り、保守の手間も少なくなると計算した
そこから始まった方式である
もう一つ面白い事実として、Norway も回転式電話に同じ構成を選んだと聞いている
同じ理由だったかどうかは確かではない
[0] https://en.wikipedia.org/wiki/Rotary_system
ちょうど机の上で回転式電話を分解し、クロックスプリングを巻き直しているところにこの記事が上がってきた
奇妙な偶然だ
自分と同じような状況なら、だいたい2年くらいだと思う