ThinkPad USB Keyboardが届いた

comp

外観から分かる点について

Travel Keyboardと比較すると、サイズはTravel Keyboardの飛び出し部分を除けば上下左右同寸。全体にとても軽いが、タイピングで触る部分の剛性感はかなりある。キー間隔は今まで通りだが、キーの隙間は固形物が入りにくいように狭く改良されている。この辺は原型となったT400sと同じだろう。


ケーブルは一回り細くなり、50cmほど長くなった。Travel Keyboadにあったハブ機能はなし。折り畳みの足は従来の2段から1段になった。足の先は滑り止め加工としてゴムを被せている。また、Travel Keyboardに附属していたキャリングケースは省略された。


裏面のケーブル収納穴の奥はキーボードアッシーの裏面に黒シートを貼り付けている。（この辺は実はTravel Keyboardも同じ作りだが、収納穴が小さいので気づきにくかった。）裏面に水抜き穴あり。

操作性について

元になっているT400sのキーボードは触ったことがないので比較できないが、このキーボード自体はかなり良好な感触。Travel Keyboardより押し下げが重くなっており、より本物のThinkPadっぽくなっていると感じる。キータッチの印象は、Travel Keyboardが「くにゃくにゃぐんにょり」というタッチだとすると、USB Keyboardは「こりこりしゃっきり」というタッチ。


新デザインのマウスボタンは、タイピング中の操作はしやすくなっているように思えた。中央付近が盛り上がっていないため、手のポジションによってはやや戸惑うこともあるかもしれない。


パームレスト部の面取りが進化しており、掌を手前に持ってきた時のフィット感が向上している。

Linuxマシンに繋いでみた際のデバイス的な話

USBバスから見えるベンダーはLITEONだった。ベンダーIDは0x17ef、デバイスIDは0x6009。


キー入力はmicのmute、ThinkVantageボタンを除けば全てxevから見えた。これら2つのキーはXのカバーしていない範囲のキーコードとのこと。次のXorgで改善するらしい。

結論

前作Travel Keyboardに見られた贅沢な部分はコストカットのために姿を消したが、より本質的なところに改良が施されており、明らかに改善している。これは買いと言える。

g_convert()問題

comp

nosukeさんの日記 http://garakuta.homelinux.org/~nosuke/diary/diary.html?y=2008&m=3&d=23&n=1#23-1 で詳しく説明されている、windows環境でのg_convert()の問題ですが、まだ事態は流動しているようです。


WIN32 APIのWideCharToMultiByte()でUCS-2BEがサポートされていないことに対しては、3月12日のglibへのコミットでaliasが追加されました。 http://testbit.eu/gitdata?p=glib.git;a=commitdiff;h=5114b84c4d4bf1babd803d58187993085ba6fba9


このような後方互換性への配慮が行なわれることから、全角英数字のiso-8859-1へのマップを禁止するWC_NO_BEST_FIT_CHARSの追加もバグ報告すれば取り上げられるのではないかと思います。


win_iconvへの移行はちょっと拙速だったかな？

ページ小分け主義

blog

最近PC関係やIT関係のニュースを見ると、ページを小分けにしている記事が多くなっています。確かに長大な文章は途中でページを改めた方がいいと思いますが、最近ではたいして長くない文章を無闇に改ページしている記事も多く見られます。

こういう記事ではほとんど2ページ目以降のページを読まなくなっていることに気づきました。特に1ページの文章が1画面あるかないかという分量で、後続ページが5ページもあるような記事だとまず読みません。掴みの部分が短いために面白いかどうか判断がつかず、後続ページをクリックして読むほど興味が持てないのでその時点でやめてしまうわけです。

おそらくこのような行動を取っている読者は少なくないはずです。それでいながらページを小分けする風潮は却ってひどくなっているようなので、こういったサイトでは記事がきちんと読まれることとビジネス上の利益の間に何の関係もないのでしょう。

読者が読まないページが利益を生み出すのだとしたら、実に面白い経済が成立していると言わざるを得ません。

vmwaredsp alsa backend

comp

夏頃作ったものですが、安定して使えているので公開してみることにしました。http://www.honeyplanet.jp/vmwaredsp-1.3_alsa_d3.tgz

intel8x0などのサウンドチップの載ったノートでvmwareを使うと、/dev/dspをマルチプルオープンできないためにvmwareからサウンドが使えないということがよくあります。alsaにはdmixというソフトウェアミキサーがあり、擬似的にマルチプルオープンを実現していますが、oss互換レイヤー経由ではdmixに対応しないらしく、vmwareでの問題を解決することはできていませんでした。

vmwaredspはvmware any-any patchで有名なPetr Vandrovecさんの作ったvmware用ソフトウェアサウンドデバイスで、libvmdsp.soというライブラリをプリロードすることで、vmwareから/dev/dspへのアクセスをバックエンドのartsまたはesdにリダイレクトします。これらのサウンドサーバはalsaが標準でdmixを提供している今、メリットがほとんどないのですが、残念ながらvmwaredspはalsaを直接叩くことができなかったため、プロセス起動の不便や音質の問題など、いろいろ我慢して使わざるを得ませんでした。

そこで新たにalsa用のバックエンドを追加したのがこのソフトウェアです。インストール後、vmwarealsaという起動スクリプトを使ってvmwareを起動すると、バックエンドとしてalsaのネイティブインターフェースを使ってサウンド出力を行います。これはdmixが有効なので、ホストOSでサウンドを使用中でもvmwareからサウンド出力ができます。

signal handler

comp

最近メイン開発マシンでSIGSEGVが起きるとcoreから見えるbacktraceが空っぽでデバッグ不能という状態になることが多く、悩まされていました。
ランタイム環境を更新したのと同時期に起こるようになったので、何かの挙動が変わったのがそもそもの原因と思われるのですが、やっと発生条件が分かりました。
それは、SIGSEGVのシグナルハンドラをインストールしていることでした。現在のランタイム環境ではハンドラがある場合、coreファイルに書かれるbacktraceは、プログラムがSIGSEGVを受けるまでのコールスタックではなく、シグナルハンドラのコールスタックになるようです。古い環境のままのマシンではこのような挙動にはならないのですが…
今のところ一番怪しいのはglibc2.5です。しかし特定するためにはもっと実験が必要です。