自動認識と使えないデバイス、格差のワケ

Linux系OSは、自動認識の機構が進歩することによって、飛躍的に導入しやすくなりました。
ですが、すべてのデバイスが認識できるわけでは無く、また認識できれば稼働できるというわけでもありません。

現在のパソコンでのデバイスの自動認識は、PCIとUSBに関する機器に定められたVendor IDとProducts IDが根幹にあります。これら規格に対応した機器がすべて、これらIDを備え、問いかけに答えるようになっていれば、最低限IDは特定できるわけです。

このID情報を、有効な情報として利用するためには、そのIDが何を指しているのかを特定する必要があります。そして、そのリストを整備することが自動認識の第一歩です。

Linux系OSには、lspci,lsusbというコマンドがあり、リストに無いデバイスについてはVendorIDとProductsIDだけが表示されます。
そして、リストにあればリストに基づいたデバイスの名称が表示されます。
(これはOEM供給において、供給元でのデバイス名が表示されることもあります)

しかし、これだけで動作するわけではありません。
実際にはそのデバイスに適合するデバイスドライバーが存在し、それをIDと関連付けて管理し、自動的にロードする仕組みが必要なわけです。

一部のデバイスについては、デバイス名が表示されながら、デバイスドライバーが自動で読み込まれません。これはカーネルツリーに取り込まれたデバイスドライバーが無いためと考えていいでしょう。

Linux用のデバイスドライバーのほとんどは、オープンソースソフトウェア(OSS)であり、これはLinuxカーネルと共に、カーネルツリーの中に組み込まれた形で配布されています。
UbuntuやFedoraなどのディストリビューションでは、それらドライバーを取捨選択し、SATAドライバーのような、特に一般的なものをカーネルバイナリー(実行ファイルとしてのカーネル)に組み込み、ネットワークアダプターのドライバーのように、有用なものをカーネルモジュールとしてパッケージ化した状態で配布しています。

そのため、非常に多くのデバイスが、自動認識によって稼働しますが、残念ながらそうでないデバイスもあるわけです。

デバイス名が表示されるものの、自動的に稼働しない状態のデバイスについては、面倒臭いことになるか、利用をあきらめることになります。
メーカーサイトなどにデバイスドライバーのソースコードがあり、昔ながらの自分でmakeしてインストールして、modprobeとかやって使うということもあります。
同じコントローラーチップを使った、別の拡張カードが動いているなら、ソースコードを修正して、再構築すれば動くようになることもあります。
ndiswrapperのように、Windows用のネットワークアダプタードライバーをLinuxで稼働させる技術もあります。(これはほとんどの場合、一部のLinux用ドライバーの無い無線LANアダプターのために使われます)

また、SOTECのネットブックC101のように、一部のノートPCではタッチパッドのコントローラーチップの仕様(バグ?)のため、起動時にカーネルオプションを付与しなければ、タッチパッドが正常に認識されず、実質的に操作不能になるような場合もあります。

サウンド機能についても、手動設定が必要になる場合があり、またデバイスドライバーレベルでは正常に機能していながら、より上位の設定が不適切なために、音が出ない,録音ができないといった状況になることがあります。

こういった問題は、コントローラーチップの仕様からデバイスドライバーを作ることはできても、実際にそのコントローラーチップが、基盤上でどう配線されているかは、M/Bや拡張カードのメーカーの任意であるために生じます。
有名なM/Bや拡張カードであれば、事前にそのための設定が為される場合もありますが、日本特有の拡張カードでは、そういった対応が遅れる傾向があるように思えます。
(2000年頃は、Bt8x8系のキャプチャーカードなどでそういう面倒なことが起きていました)



  • 最終更新:2014-04-09 06:16:01

このWIKIを編集するにはパスワード入力が必要です

認証パスワード