[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: btnmgr (Re: cassiopeia patch)
> kiu を扱うデバイスのドライバも自然ですが、
> はたして、kiu = MD キーボードでしょうか？
すくなくとも現状はそうですね。
現在のkiuのドライバ自体はMDキーボードドライバー以外のなのものでも
ないでしょう。
> 本当は、
>
> +-------------------+ +------------------------+
> | MI ボタンドライバ | | MI キーボード ドライバ |
> +-------------------+ +------------------------+
> |
> +------------------------+
> | MD キーボード ドライバ |
> +------------------------+
> \ /
> x
> / \
> / \
> +------------+ +------------+
> | giu ボタン | | kiu |
> | ドライバ | | ドライバ |
> +------------+ +------------+
>
> ていう構造が自然なのではありませんか？
> クロスの部分は、たぶん イベントベースの通信ってことになるんだと思います。
そういう風な構造にするのももちろんできるでしょうね。
で、そうなっている場合にイベントベースでやるのか swベースでやるのか
はまあいろいろなやりかたはできるでしょう。
が、必要以上に複雑な構造のような気がします。
> ここで書いた MD キーボードドライバってのは既に デバイスから遊離して
> いるから MI low レベルドライバかも知れないですね。
そういう構造であれはMDではなくあらたなhpcmips内MIの層でしょう。
でも、いまはそういう構造ではない。
私が反対しているのは きれいなMI/MDの構造に再構成することなく
MDのところでごそごそやるのを反対しているだけです。
だから、上のような構造にきれいに実装しなおしてくれるならば
反対しません。
いまの構成のMDなキーボードドライバーに余計なごそごそをいれるのを
反対しているだけ。
私的には現状の構造で最悪でもuserlandの助けを借りればMI的にできそうなので
再構成をすることはないでしょう。
> | > ここの考え方がなじめないんですが、MD なキーボードドライバと
> | > 通信するってのは なぜだめなんでしょうか？
> | vrなPsPCの場合でvrkiuというMDなキーボードドライバーは無くても
> | 良いはずのドライバーで、実際に別のキーボードに相当するものが
> | あるならばそのドライバーが動くべきだとおもいます。
> |
> | PsPCな場合にkiuに相当するデバイスが全くなくて ボタン群をキーとして
> | 扱いたいのであれば専用のMDなキーボードドライバーをおこすでしょう?
> | そうすれば、本来なくてもいいはずのドライバーと通信する必要も無い
> | じゃないですか。
>
> これに対する反論はたぶん上で説明できているように思います。
構造を再構成すればという仮定をいれればそうでしょうが、
現状の構成でそれをやる場合の反論にはなりません。
> 私は基本的に userland 担当だから、やりたいことがスマートにできれば、
> 本来カーネル内部の構造にこだわるべきではないんですが...
内部の構造に拘るのであればuserland担当といっていないで、
カーネル内に参入するべきでしょう。
とくに構成の変更を伴う場合には。
--
前提
1. HPCではボタンにキーボードとしての役割をあてる必要なない。
2. PsPCではボタンにキーボードの役割をあてたいボタンが存在する。
ボタンを2種類にカテゴライズする。
1.キーボードの役割をあてたいであろうボタン
2.そうでないボタンでアプリケーション起動用。
一見同じボタンであっても HPCとPsPCで1,2のカテゴリが異なるのであれば
別のボタンであると考える。
1.のカテゴリに関してはbuttunドライバーの上にbtnkbdドライバーを作成して
PsPCの場合は HPCのkiuなどのドライバーのかわりにwskbdにつなぐ。
もし必要ならuserlandからkeyscanコードをいれられるようなメカニズムを
いれればいいだろう。(MIなのかMDでなのかは他でもやりたいかどうかによる)
2.のカテゴリに関してはuserlandでbuttunドライバで経由でイベントをひろって
アプリケーションを起動する。
1.のカテゴリに関してはアプリケーションを起動できるようにキーコードを
出すのを禁止したりする機能は必要ならばいれればいいし、いらなければ
いれないでいい。
まえにいったbuttun_launchdだけあればbutton_keymapdはいらない。
こんなとこで現状の枠組の中ですっきりできるとおもいます。
複雑な構成に再構成をする必要を感じない。
sato