E-WA'S BLOG CLASSIC

uControl というか、そこら辺のソフトがフックしていた箇所が、フック不可能に書き直されてます > Panther。なもんで、残念ながらフックの仕方そのものを変えないと、uControl の様な処理はできないと言えます。。。

しかし、あの部分をフック不可能に変えるのって、この手のソフトへの嫌がらせ以外の理由が思いつかないのでちょっと嫌な感じです(--;;

スクロールホイール代替ソフトのSideTrack は Panther でも問題なく使えるんですよね。フックの仕方が変更になったのはキーマップのところだけなんですかね。

なるほど、AppleUSBKeyboard.kext がなくなっちゃったわけですね。

参考：http://ella.slis.indiana.edu/~jfieber/osx/

ん〜、ちょっとちゃいます。

そもそもキーボードはADBの場合も、USBの場合もありえます(E-WAさんの出したURLにもあるとおり、PowerBookのキーボードは内部的にはUSBではなくADBで接続されてます)。

なので、そのレベルよりちょっと上のIOHIDSystem というIOKitのクラスをハックして、keyboardEvent() を実行時に上書きし、そこでイベントを書き換えてました。この技術は uControl だけじゃなくて他のその手合いのツールでも使われている技術です。

問題は、このIOHIDSystemクラスにある、keyboardEvent()関数などの、これまでuControlがフックしていた関数がただの飾りとなり、_keyboardEvent()関数などの別の関数に実体の処理が移されてしまい、そしてこの別の関数は private な関数のため、C++の言語上、上書きができなくなってしまいました。

この関数の呼び出し側(IOHIDUserClientなど)は friend という、private な関数を呼び出すことを許される特別なフラグが立てられ、この二者の間はがっちり固められしまい割り込む隙がなく、これまでのように間に処理を咬ますことができなくなった、というのが uControl が動かなくなった真相です。

しかし、この二者をがっちりと固めてしまう���は、まぁ、確かにその方が若干は効率がいいかも知れないですけど、さして大きな理由が思い当たりません。

もし理由があるとするなら。。。uControl のようなソフトを使わせないようにしたかった、という事じゃないかと思えてならないわけです。

Pantherではショートカット割り当てが追加されてるから、
下手にキーマップいじられたりするのを嫌がったのかも。
といっても、いくらでも回避方法はあるだろうから、やっぱし
嫌がらせでしょうか（藁

これって「よくある質問」の答えに最適なんでそのうち
使おうと思ってたソフトだったのでちとショック。

前出の参考 URL に、新たに“In MacOS X 10.3...”という記載が追加されてますね。

USBキーボードなら回避可能でも、そもそもUSBのキーボードなら「お気に入りの配列」を買えるので、あまりソフトウェアで細工がいらなかったり。ってか、会社のデスクトップ用には結局 HHKPro買っちゃいました(涙)

キーボードを交換できない PowerBook こそ、uControl が欲しいのですけど、上記の理由でどうしょうもないのですよ、ねぇ(涙)

...まぁ、AppleADBKeyBoard ドライバはソースがあるので、そいつをハックして置き換えてしまうという奥の手が残ってますが...(--;;

初めまして。
uControl 1.3.2 for Panther（http://www.xwt.org/uControl.html）というのが、ありますが、これは、こちらで紹介している、uControlのPanther対応版ですよね？

1.3.5のPanther対応版も近々でるようなことも書いてあります。

ｷﾀ━━━━━(ﾟ∀ﾟ)━━━━━!!!!

ちょっと試してみた限りでは、スクロールホイール代替は
ちゃんと動作してます。

ただ、console.log に大量のデバッグログを吐く仕様になって
しまってますが。

デバッグログですが、対症療法的には /etc/syslog.conf の2行目にある、「kern.debug」を「kern.none」に修正して、syslogd にHUPシグナルを送る( kill -HUP syslogdのPID)で system.log に残さなくすることはできます。

ただし、これをするとカーネルからのメッセージは一切 system.log に残らなくなります。(色々試してみたけど、noneにして一切出力しないにしないと、何かしらuControlのデバッグログが残ってしまいます)

ただ、system.log をどうせ見ないと言い切れる方、それよりも system.log がぼこぼこ太ってディスクが喰われるのが我慢ならない方には、やってみることをお奨めします。

dmesg には相変わらず残りますが、こっちは固定長のメモリなのでいつかは上書きされるので問題ありません。