memo/20250927
created 2025-09-27 modified 2025-09-27
「アナログ軸を持つゲームパッド の入力処理」をいじっています。
遊びと、Linuxの 周辺デバイス プログラミングの勉強、を兼ねて。
でもこれ、思いの外、難しいというか奥が深いです…
物理もI/Fもアナログの軸だと、最初のイベント検出から、若干ディレイを設けて判定するようにしないと奇妙な判定になってしまう。
けど、根本の実装方式で一定tick方式 vs可変フレームレート方式 でできることが違う。それも悩む。
それに、若干のディレイが必須なのはアナログ軸から「ユーザー意図を判定」しようとする場合にだけ必要であって、
単に物理ゲームパッド→仮想ゲームパッドなんていう、プロキシプロセスを作りたいときには要らない。
デジタルボタンにはそれは、本来的に要らない。要らないディレイはつけたくない。
悩ましいです。
でも、プログラムで悩むのは、本当に楽しい。
超楽しい。脳が元気になる。寝るときも考えてる。
あと、
という流れが、やっぱり基本で。
自動車教習所の教官さんなら年間100回は言っているであろうことなんですが、コンピュータプログラムも結局それ。
で、それを、実行フローの制御をどうするか、と絡めて考えて、ソースをどうスッキリ書くかを考えるのが、本当に楽しい。
「物理ゲームパッド→仮想ゲームパッドなんていう、プロキシプロセスを作りたいとき」
元のデバイスを占有したい件。悩む。
【* 日々のメモ】
遊びと、Linuxの 周辺デバイス プログラミングの勉強、を兼ねて。
でもこれ、思いの外、難しいというか奥が深いです…
- 基本
- デバイスオープン ...ok
- 値取得 ...単純にはok
- 仮想デバイスの作成、出力 ...ok
- "コマンド"(所定の連続操作)の自動出力 ...ok
- シーケンスの記述をソース上で独自の形式言語風にするの楽しい
- 元のデバイスを占有する(自プロセスだけ読んで他には隠す)方法で悩む
- 仮想キーボードなどの作成にはセキュリティ上、権限の検討が必要。そうな。改めて勉強になる。
- (でも今回、この件の学習でキーロガーとか本当に作れるようになりました)
- udev の勉強にもなりました
- 値からユーザー意図解釈 ...非常に悩む
- 物理はボタンでI/Fもデジタル、は楽勝
- 物理はボタンでI/Fだけアナログ、なんていう箇所もあるけど、それもまぁ楽勝
- 物理もI/Fもアナログの軸、がやたら難しい
物理もI/Fもアナログの軸だと、最初のイベント検出から、若干ディレイを設けて判定するようにしないと奇妙な判定になってしまう。
けど、根本の実装方式で一定tick方式 vs可変フレームレート方式 でできることが違う。それも悩む。
それに、若干のディレイが必須なのはアナログ軸から「ユーザー意図を判定」しようとする場合にだけ必要であって、
単に物理ゲームパッド→仮想ゲームパッドなんていう、プロキシプロセスを作りたいときには要らない。
デジタルボタンにはそれは、本来的に要らない。要らないディレイはつけたくない。
悩ましいです。
でも、プログラムで悩むのは、本当に楽しい。
超楽しい。脳が元気になる。寝るときも考えてる。
あと、
- 認知
- 解析・判断
- 実行
という流れが、やっぱり基本で。
自動車教習所の教官さんなら年間100回は言っているであろうことなんですが、コンピュータプログラムも結局それ。
で、それを、実行フローの制御をどうするか、と絡めて考えて、ソースをどうスッキリ書くかを考えるのが、本当に楽しい。
「物理ゲームパッド→仮想ゲームパッドなんていう、プロキシプロセスを作りたいとき」
元のデバイスを占有したい件。悩む。
- 同じデバイスが 複数のハンドラ で見えている、ことは理解しました。
- ハンドラによって、サポートする ioctl コマンドが違う。
- /dev/input/event23 では
ioctl(fd, EVIOCGRAB, 1)ができるのだけど - /dev/input/js0 でしか操作情報を取れない
- し、event23 で上記ioctlをやると自プロセスの js0 イベントも見えなくなってしまう
【* 日々のメモ】