Ubuntu 10.04 lucid のグラフィックドライバ(と Plymouth)

Ubuntu 10.04 lucid でグラフィカルな起動画面を提供する Plymouth ですが、使用しているグラフィック・ドライバによって起動画面の表示の質などが大きく左右されます。

システムの標準の状態にまったく手を加えなければ Plymouth の表示は一瞬にすぎないので、起動画面がどうであろうと気にしない人がほとんどでしょう。

が、自分は本末転倒にもログイン以後よりこっちの方が気になるので、lucid でのグラフィック・ドライバについてちょっと調べることにしました。

まずは公式 Wiki の lucid でのグラフィック・ドライバ(グラフィック以外のドライバも少々含む)部分の説明。

追記:lucid で GMA500 poulsbo ドライバを動かす試みについてはこのスレッドをフォローするとよいかも:Guide to Get the Best Performace from the GMA 500

追記#2:3D支援はまだらしいですが lucid でドライバが使えるようになってきたらしいです。 Ubuntu 10.04 GMA500ドライバ 試してみた – でぶろぐ


https://wiki.ubuntu.com/X/Drivers

Lucid

ビデオドライバ

ドライバの開発元ではクールな機能が数多く実装され続けていて、Ubuntuの方でもそれらをLucidユーザーが利用できるよう努力していますが、残念ながら、機能と安定性の狭間で難しい選択を迫られるケースがあります。
私たちが Lucid に採用した方針は、全てのハードウェアでカーネル・モード設定(KMS)をあまねく有効にしながら、それが原因で問題が生じた場合に、ユーザーが何らかの方法でカーネル・モード設定を切ることができるようにすることです。

-intel

9xx 以降の新しいカードは、開発元でのサポートがとても良い状況です。
これらカードに関して重大な問題のバグ報告は多くあるものの、非常に広範囲に及ぶ問題ではなさそうです。
全般的に Lucid でのドライバはとてもしっかりしているようですが、私たちは報告された散在する問題に対して注視を続けています。
(今まで私たちが調べてみた問題の多くは、カーネルの DRM に関わるバグと判明しているので、パッチによる修正は Ubuntu のカーネルチームに任されます。)

古い8xxカードについては、開発元でのサポートがスポット的で、数多くのバグ報告があります。
私たちの主要目標は、安定して直ちに使える体験をユーザーに提供することですが、これはつまり、諸機能(KMSや3D含む)をオフにして問題の頻発を最小限にすることを意味します。
(Ubuntuとドライバ開発元の両方における)問題部分としては、検証用のハードウェアが欠けていることが挙げられます。
私たちが少々憂慮するのは、相当マイナーなハードウェアで誰も検証していないものがあり、リリース後になって初めて問題が判明することです。

UMS(User Mode-Setting / ユーザー・モード設定)を使用するオプションを残しておきたいため、最新バージョンではなく、2.9.x バージョンのドライバを導入しました。
ドライバの開発元では、2.10で UMS を取り除きました。
2.10系で加えられた修正のほとんどをバックポートしたので、Ubuntu は 2.10 ドライバと同等の機能を提示します。
特定の 8xx カードは依然として KMS と一緒では正常に働かず(これに関する問題は、現在、’Linux’ に対してバグ報告できるでしょう。)、また UMS モードでのみ働く調整オプションのようなものもまだあるかもしれません。
Lucid に UMS を残しておくことで、問題回避のための追加的なオプションをユーザーに提供します。

-nouveau

NouveauのXドライバは正式リリースされていないので、最近のgitスナップショットを導入しました。
カーネル・コンポーネントについては linux 2.6.33のものを取り入れていて、開発元から ctxprog generator をバックポートしています。
このドライバは GeForceシリーズの全部と TNT/TNT2 カードで KMS と2D描画支援をサポートします。
非KMSコードは Nouveau Xドライバから取り除かれているので、KMS を無効にすると Nouveau も無効になり、X は代替として nv ドライバを使用するようになります。

Nouveau の3Dサポートは不完全で、時間経過とともに開発目標が変遷していることで知られています。
現在の Mesa スナップショットには、より新しい libdrm と 0.0.16 nouveau カーネル・インターフェイスが必要です。
したがって、Lucid 上での Nouveau 3Dコンポーネントのビルドはサポートしていません。
冒険的なユーザーは、Nouveau の3Dサポートを有効にしたMesaパッケージを含んでいる Xorg Edgers PPA 提供のパッケージを試してみてください。
開発元の方では、3Dコンポーネントで見つかるバグに関心はないので、そちらにはバグ報告しないでください。

nouveau-kernel-source と nouveau-firmware パッケージは両方共廃止になりました。

-nv

-nouveau ドライバが正しく働かない場合に備えて、その代替を提供するため、古い -nv ドライバが依然として Lucid にも持ち込まれています。
しかし、すでに積極的にサポートしている状態ではありません。

訳者注:nv は Nvidia が Linux などでの自社製品の動作を最低限保証するためにメンテしているオープンソースドライバらしいんですが、Nvidia は Fermi 以降の製品での nv ドライバ対応を取り止めた模様。

NVIDIA Drops Their Open-Source Driver, Refers Users To VESA Driver

-ati

このドライバは、R7xx までの全てのチップセットに対して3Dのハードウェア支援機能を提供するようになりました。
Lucid において、-ati はカーネル・モード設定(KMS) を標準で使用します。
KMS は、起動パフォーマンスを向上させますが、ユーザーのなかには、解像度の検出で悪化が見られる可能性があります。
その場合、それについては linux に対してバグ報告してください。
KMS 有効時は、動画のオーバーレイが利用できないため、動画がチラつく可能性があります。(lp #27192).

32MB未満メモリのカードでは、メモリの制限により、テキストモードの Plymouth テーマが使用されることに留意してください(lp #554143)。

-nvidia

* nvidia-current: 最新の安定版ドライバ
* nvidia-173: レガシー・ドライバ
* nvidia-96: 最も古いレガシー・ドライバ(古いカードで使用されるためのもの)

Jocky(メインメニュー → システム → ハードウェア・ドライバ)が正常に働かない場合に手動で nvidia ドライバをインストールする方法

(これに関する問題に遭遇した場合は、Jockey に対してバグ報告してください。)

1) 使用しているカーネル用のカーネル・ヘッダをインストールしてください。sudo apt-get install linux-headers-$(uname -r)
2) nvidia ドライバをインストールします。: sudo apt-get install nvidia-current (使用しているカードによっては、nvidia-173 または nvidia-96 )
3) 使用したいドライバを選択します。(全てのnvidiaドライバをインストールしておけますが、使用できるのは1つだけです。):
sudo update-alternatives --config gl_conf
sudo ldconfig
sudo update-initramfs -u

4) xorg.conf を設定します。sudo nvidia-xconfig
5) コンピュータを再起動します。(Xサーバの再起動だけでは正常に働かない場合があります。)

備考: どの選択肢が利用されているか(つまり、どのドライバがインストールされて有効になっているか)を見たい場合は、次のコマンドを使用します。:
sudo update-alternatives --display gl_conf

オープンソースドライバへの戻し方

1) xorg.conf を削除します。 sudo rm /etc/X11/xorg.conf
2) オープンソースの選択肢(つまり、/usr/lib/mesa/ld.so.conf)を次のコマンドを使用して選択します。 sudo update-alternatives --config gl_conf
3) ld キャッシュと initramfs を更新:
sudo ldconfig
sudo update-initramfs -u

4) コンピュータを再起動

-fglrx

Lucid のXサーバとカーネルをサポートする fglrx ドライバは、2010年4月に導入されました。

インプット・ドライバ

-evdev

ほとんどの入力デバイスがこのドライバを使用します。-evdev は汎用のXドライバで、ラッパー機能は Linux カーネルにあります。

-wacom

今回のリリースには、Wacom-tools ドライバから新しい xf86-input-wacom ドライバへの移行のため、相当の労力がつぎ込まれました。
この変更の主な理由は、HALへの依存を取り除けるようにすることにあります。
Wacomユーザーが Lucid で自分のデバイスがサポートされていることに確実に出会える助けとなるよう、テストも随分行いました。
デバイスの設定やキャリブレーションについてはまだ初歩段階ですが、大抵のタブレットのパラメータ設定はコマンドライン・ツールの ‘xinput’ が現在サポートしています。


Lucid でのグラフィック・ドライバに関する上記の説明では、カーネル・モード設定(KMS)という言葉が頻繁に出てきます。

以前 Intel ドライバについての開発者さんの説明をブログで取り上げたことがあって、そこにユーザー・モード設定(UMS)や KMS について少し説明がありますが、しかし Ubuntu においては具体的にどうなってるのか気になるところ。

すると Ubuntu Weekly Topics という連載記事に、Ubuntu の一般ユーザーは KMS についてこれに目を通しておけ、というアドバイスがちょうどあったので、自分は記事でいう一般ユーザーには該当しない末端ユーザーではありますが、読んでみました。

http://gihyo.jp/admin/clip/01/ubuntu-topics/201004/02


All about Kernel Mode Setting (or why your $500 nVidia card only displays in 16-colors)

グラフィックカードは、メーカーが異なるとそれぞれ全く別物で、同じメーカーのグラフィックカード同士でも、世代が違えばかなり異なる場合がある。

解像度や色深度、モニタとの通信などについては相当に標準化されているが、ソフトウェア側に標準化の類はほとんどない。

実際、任意の解像度と色深度(モードとも呼ぶ)に設定するような最も基本的な操作の1つをとっても、各カードごとに異なる場合があり、それぞれのメーカーに任せられている。

つまり事実上、モードの設定の仕方を知るのは Video BIOS とグラフィック・ドライバの2つしかないというである。

これまでは、Linux内において、Xウィンドウシステムにグラフィック・ドライバが備わっていた。

モードの設定が必要とされる機会は、別々のあちらこちらに見られる。:

* 起動中、Video BIOS が初期のモードを設定する
* そのモードは、ブートローダが Video BIOS または VBE を使用して変更する可能性がある
* Xサーバがスタートした時点で、カードのネイティブなプロトコルが VESA の代わりに使用され、ハードウェア支援の新しいモードに設定されることだろう
* XサーバからVT(仮想端末)に切り替えた時は、その新モード以前のビデオモードに復帰する必要がある
* VTからXサーバに切り替え戻した時は、正しいビデオモードに設定される必要がある
* サスペンドまたはハイバネートからレジュームする時、レジュームするVTの正しいビデオモードを復帰させる必要がある

このなかで、2つの最も大きな問題は、XサーバとVTの間での切り替えと、サスペンドからのレジュームである。

前者の場合で最も難しいのは、ユーザー切り替えのように、異なるVT上のXサーバ同士で実際に切り替えることだ。

その過程を見てみると次のようになる:

* ユーザー切り替えにより、VT7上のXサーバからVT8上のXサーバへのVT切り替えが開始される
* VT7上のXサーバは、以前のビデオモード(VGA text のような)に戻す
* VT8上のXサーバは、適切にビデオモードを設定する

これによって、VT切り替えの途中、誰もが嫌うようなブラックスクリーンやカーソルの点滅が引き起こされる。

サスペンドからのレジュームの場合に関しては、本当にトリッキーだ。

私たちは必ずしも復帰させる正しいビデオモードを知る必要はない。トリッキーなのは、Video BIOS(またはVBEであっても)に呼びかけることで、これはエラーを起こしがちであり、VESAモードでない場合は働かず、Xサーバのモード設定に関わるコードは、外部から呼び出されるようにデザインされてはいない。

これはつまり、レジュームに関してはXサーバに基本的に任せきりで、Xサーバにモードの復帰を行わせていた、ということである。

こうしたことは、カーネル・モード設定(KMS)で一変する。

Lucid の開発を通じて、KMS という言葉を何度か目にしたことが恐らくあるだろう。

単純に言うと、カーネル・モード設定というのは、グラフィック・ドライバのコードの大半をXサーバから取り上げて、カーネルに配置することに尽きる。

これは要するに、カーネルがネットワークカード・ドライバやワイヤレス・ドライバ、USBドライバなどを持っているのとちょうど同じように、グラフィック・ドライバを持つということを意味する。

最も重要なのは、モードの設定が必要な時はいつでもカーネルがそれを行えて、レジューム時のモード復帰もカーネルで可能ということだ。

これがもたらす、3つの最もユーザーに目に見える形の結果は:

* Xサーバにシームレス(ブラックスクリーンなし)に移行する、ハイカラーで高解像度な起動中のスプラッシュ画面
* ユーザー切り替え時のXサーバ同士での素早いシームレスな移行
* サスペンドからグラフィックへの非常に高速な直接のレジューム(テキストカーソルの点滅なし)

水面下では、さらに素晴らしい機能が将来のリリースで使用されるのを待っている。

もっぱら、こうした新しいドライバが書かれる努力のほとんどは、いわゆるビッグスリーのグラフィックカード・ベンダーのハードウェア向けである。

Intelは、自身で KMS 周りの大部分と、それに向けたドライバに貢献している。

nVidia所有者は、リバースエンジニアリングによる努力の成果として製作された nouveau ドライバでカバーされ、ATIの所有者は、新しい radeon ドライバでカバーされる。

他ベンダーのグラフィックカードの所有者は少々蚊帳の外になってしまうが、少なくとも以前より悪い状態になるわけではない。

一番大きな不満の源は、バイナリ・ドライバも利用可能なカード(大抵は nVidia)の所有者だ。

カーネルに組み込まれたグラフィック・ドライバ(つまり nouveau)から、Xサーバに読み込まれるバイナリとして提供されているドライバ(つまり nvidia-glx)に切り替えると、カーネル・モード設定のサポートは得られなくなり、Ubuntu 9.04 段階の状態に後退してしまう。

すると nVidia ユーザーは、Ubuntu 9.04 のスプラッシュ画面が16色以上だったことを素早く指摘することだろう。

確かにその通りだ。

10.04 での他の変更の1つは、スプラッシュ画面の描画に usplash を使うことをやめて、Plymouth を使うように切り替えたこと。

両方ともフレームバッファ(基本的に、カーネルの2Dグラフィック・キャンバス)に描画することは出来るものの、マルチヘッドやネイティブなパネル解像度のサポート、とりわけ、X へのスムースな移行については Plymouth の方が良い。

オープンソース・ドライバを使用している人たちのために KMS を正当にサポートすることは、そのドライバを利用しない人たちにとって、見た目の面で多少の退行になる。

usplash は、フレームバッファが利用できない際に、バックエンドとして SVGAlib を使用することでハイカラーと高解像度をサポートしていた。

Plymouth 用の新しい SVGAlib レンダラを書くことは、KMS のために現在の統合がきちんと働くようにする作業に上積みとなる単純に負担が大きすぎる仕事だ。
(しかし、個人的なプロジェクトとして誰かやりたい人がいるなら、今すぐやっちゃって!)

SVGAlib使用の代替策となると、せいぜい VESA または VBE を通じてより良いモードに設定するくらいになる。

これを行うには、2つの一般的な方法がある。

1つはVESAフレームバッファ(vesafb)を使用すること、2つ目はEFIフレームバッファ(efifb)の使用を引き金に、ブートローダにグラフィックモードの設定およびカーネル実行中でのそのモードの維持を行わせること。

これら両方に共通した問題が、サスペンドからのレジュームである。

これまで詳細に述べたように、私たちには、レジューム時にこのモードを復帰させる術がない。

したがって、私たちが採用したのは、すべてのハードウェアで正常に働きながら他の問題は引き起こさないという付加的魅力がある第三の代替策、つまり、古き良き信頼性ある16色VGAの使用だ。


というわけで、最後に Ubuntu lucid での設定の説明。

https://wiki.ubuntu.com/X/KernelModeSetting

カーネル・モード設定

カーネル・モード設定(KMS)は、グラフィックモードの選択や設定を行う役割を、X.org からカーネルへ移します。
X.org がスタートすると、そのモードをそのまま検出して使用し、再びモード変更することはありません。
このおかげで、起動がより速く、よりグラフィカルになり、起動中のチラつきも抑えられます。

Lucid における KMS の設定

-intel や -ati、-nouveau ドライバについては、KMS が標準で有効になっています。現時点では、他のドライバでの利用はできません。

モード設定を手動で調節する必要がある場合は、video= という起動パラメータを使用します。具体例は次の通りです。

video=LVDS-1:d -- Disables the LVDS
video=VGA-1:e -- Enables VGA-1

KMS をオフにする必要がある場合は、当該ハードウェアの種類に応じた次の処置を行います。

# ATI Radeon:
echo options radeon modeset=0 > /etc/modprobe.d/radeon-kms.conf

# Intel:
echo options i915 modeset=0 > /etc/modprobe.d/i915-kms.conf

# Nvidia (これにより、-nv または -vesa の使用に戻ることになります。):
echo options nouveau modeset=0 > /etc/modprobe.d/nouveau-kms.conf

一部のユーザー(典型なのは、暗号化ボリュームを使用してるユーザー)にとっては KMS の有効が起動プロセスの非常に初期のため、上記の無効化の変更を反映させるのに、sudo update-initramfs -u の実行が必要となります。

訳者注:原文にはコマンドが上記のように記載されてますが、例えば radeon の場合、echo options radeon modeset=0 | sudo tee /etc/modprobe.d/radeon-kms.conf の方が良いような… i915、nouveau にしても同様。

そもそもそれ以前に、Grub の画面で カーネル起動コマンドに nomodeset を付け足す編集をして、とりあえず一時的に KMS を切る状態でシステムを起動させてみて具合がどうかまず試した方が良い気も…

KMS のオフを常用することに決めたら /etc/default/grubGRUB_CMDLINE_LINUX="" 行を GRUB_CMDLINE_LINUX="nomodeset" に編集して保存後 sudo update-grub 実行、によっても xxx-kms.conf と同じ結果が得られると自分は思ってるんですが、ひょっとしたら .conf を使う方法と何か違いがあるやもしれず。

KMS をすでに無効にしている状態でも、依然として問題に遭遇する場合は、次の内容の xorg.conf を作成することで、別のドライバ(-vesa, -nv 等)を適用できます。:

# /etc/X11/xorg.conf
Section "Device"
Identifier "Configured Video Device"
Driver "vesa" # ここを適用したいドライバの名前に変更してください。
EndSection

Section "Monitor"
Identifier "Configured Monitor"
EndSection

Section "Screen"
Identifier "Default Screen"
Monitor "Configured Monitor"
Device "Configured Video Device"
EndSection

フレームバッファ(framebuffer)の使用

KMS を使用したいが、通常のドライバが何らかの理由で問題を起こしている、という場合、フレームバッファの -fbdev ドライバを試すこともできます。
これは -vesa のような汎用的で機能が限られたドライバですが、KMS 有効下でも働きます(-vesa は KMS と一緒には働きません)。
このドライバを使用するには、次のような内容の xorg.conf を作成します。

# /etc/X11/xorg.conf
Section "Device"
Identifier "Configured Video Device"
Driver "fbdev"
EndSection

Section "Monitor"
Identifier "Configured Monitor"
EndSection

Section "Screen"
Identifier "Default Screen"
Monitor "Configured Monitor"
Device "Configured Video Device"
EndSection

起動プロセスのより早い段階で高解像度のスプラッシュ画面を表示させたい場合、次のコマンドを端末内で実行します。

echo FRAMEBUFFER=y | sudo tee /etc/initramfs-tools/conf.d/splash
sudo update-initramfs -u

KMS が読み込まれているかどうかの検証

dmesg | grep drm

これにより、drm(Direct Rendering Manager)が初期化されてセットアップされていることが示されます。
例えば以下のように、フレームバッファとモードの設定についての記述があったりします。:

[    2.699321] [drm] Initialized drm 1.1.0 20060810
[    2.819877] [drm] set up 7M of stolen space
[    3.334947] [drm] TV-14: set mode NTSC 480i 0
[    3.493351] fb0: inteldrmfb frame buffer device
[    3.513539] [drm] Initialized i915 1.6.0 20080730 for 0000:00:02.0 on minor 0
[    3.627621] [drm] LVDS-8: set mode 1280×800 1d
[    4.227945] [drm] TV-14: set mode NTSC 480i 0

広告

コメントを残す

以下に詳細を記入するか、アイコンをクリックしてログインしてください。

WordPress.com ロゴ

WordPress.com アカウントを使ってコメントしています。 ログアウト / 変更 )

Twitter 画像

Twitter アカウントを使ってコメントしています。 ログアウト / 変更 )

Facebook の写真

Facebook アカウントを使ってコメントしています。 ログアウト / 変更 )

Google+ フォト

Google+ アカウントを使ってコメントしています。 ログアウト / 変更 )

%s と連携中

%d人のブロガーが「いいね」をつけました。