モードを切替えた時カーソルを白い矩形に再描画してしまう、
ハードウェアカーソルの問題だと分かっています。
この問題を解決するにはカーソルを他の領域に移動させ、コンソールへ
切替えてから元に戻すか、切替えが面倒なら "hw_cursor"
オプションを外してハードウェアカーソルを無効にしてください。
6555x の機器上でフラットパネル全体に拡大したモードの場合、
ハードウェアカーソルがモードに対応して拡大されていません。
この問題は現在のサーバに存在する、
小さいが長いあいだ残されたままのバグです。
"no_stretch" か "sw_cursor"
のどちらかを使うことで、このバグを避けることが出来ます。
訳注：ホットスポット:クリックした時の有効点。
多くの DSTN 画面では ビデオメモリの上位をフレーム高速化のために使用しています。 これはモードのために使用できるメモリの量を 減少させてしまいます。 X サーバは 利用者がこの領域のメモリを使うモードを指定することを 妨げたりせず、コンソールに警告のメッセージを表示します。 この場合、画面の下の方に相当するメモリがフレーム高速化の領域と 同じ位置に割り当てられるため、両者が衝突して画面が乱れます。 モードによって消費されるメモリの量を削減して下さい。
その表示装置で取り扱うことができないモードを使用しています。
非標準なモードを使用している場合は、
少し画面の時間調整を変更する必要があるかもしれません。
その表示装置で取り扱うことができるはずの
標準的なモードと周波数を使用している場合は、
それに近いモードと周波数の組合せを実現できるような
異なる時間調整の設定を試してみて下さい。
LCD のモードについては、
テキストコンソールのパネルの時間調整とグラフィックのそれとで
異なる数値を必要とする場合があります。
このような場合には
"use_modeline" を指定する必要があるかもしれず、
多分 "fix_panel_size" も指定して
LCD パネルの時間調整を微妙に変更する必要があるでしょう。
描画操作によらず絶えまなく水平方向に波うったり画面全体に落ち着かない。 使用しているドットクロックが高過ぎるか低過ぎるような場合に発生します。 近過ぎる MCLK と干渉をおこしている可能性もあります。 より低いドットクロックを試してみましょう。 CRT の場合には、モードの時間調整も変更してみましょう。 2 番めの水平方向の数値を幾らか増加させてみると良いかもしれません。
"noaccel" または "no_bitblt" オプションを
試して下さい。
BIOS の設定が大丈夫かチェックしましょう。
特に 0xa0000-0xaffff のキャッシュは無効にしましょう。
隠し DRAM のリフレッシュも無効にしましょう。
この問題は UnixWare 1.x で報告されています。しかし解析されていません。
UnixWare 2.x ではこの問題は現れません。
また、HiQV シリーズのチップでのみ現れます。
その他の SVR4 オペレーティングシステムでも同様の悪影響が
出るかもしれません。
この現象に遭遇したら "xaa_no_color_exp" オプションを使って
CPU 画面間の高速化機能を使わないようにしましょう。
この現象はアクセラレータ関数のバグに起因したものか、
BitBLT エンジンに関する問題です。
"noaccel" または "no_bitblt" オプションを
試してみて下さい。
また BIOS の設定もチェックしましょう。
それから大きな画面で高いドットクロックや大きな色深度を使うと、
BitBLT エンジンが使うための残りのメモリが
とても小さな帯域幅になってしまいます。
こういう場合にはクロックの削減を試して下さい。
お手持ちのチップセットに似た型のチップセットを 強制的に指定してみましょう。
この問題は "APM_DISPLAY_BLANK" オプションを指定して カーネルをコンパイルしている場合に 起こる可能性があります。 このオプションを指定しても意図したとおりに動作せず、 X 起動時に Xserver の表示画面が真っ黒になる場合があります。 いずれにしろ、 カーネルのコンパイル時にこのオプションを指定してはいけません。 この問題が発生した場合、 CRT/LCD または仮想コンソールとの画面切替えで回復する場合があります。
いくつかの環境で発生すると報告されています。
多くのラップトップでは
コンソールで 6554x のプログラマブルクロックを使っています。
BIOS が VClk の後に MClk を書き込んだ場合には、
このコンソール用クロックの設定を
プログラマブルクロックから必ず発見できるわけではありません。
このため X サーバは 25.175MHz をコンソール用と決めています。
この設定はほとんどのモードで正常に動作しますが、
問題の発生する場合もあり得ます。
通常この問題は LCD と CRT の間で画面切替えを実行することにより
回復します。
あるいは既に説明した "TextClockFreq" オプションを使って
テキストコンソール用に標準とは異なるクロックを選べます。
この問題の原因に関する他の可能性として、
"APM_DISPLAY_BLANK" オプションを指定して
カーネルをコンパイルしている場合があります。
既に説明したように、このオプションは無効にしてください。
この問題は、フラットパネルがその時間調節値として
モードによる画面サイズではなく
パネルの大きさに関係した数値を必要とする
ことによります。
現在の X サーバーにはこの数値を指定する機能はありませんので、
X サーバはパネルの大きさをチップから読み込みます。
"use_modeline" または "fix_panel_size" オプションを
指定した場合には、パネルの時間調整としてパネルの大きさではなく
指定されたモードの画面の大きさから求められた数値を使用します。
これらのオプションを XF86Config から取り除くか、
LCD/CRT 表示画面切替えを試してみましょう。
6554x のハードウェアカーソルでは縦方向に 2 倍になるモードに
関するバグがあります。画面の下半分が利用できません。
この問題の解決方法は縦方向に 2 倍にしない事です。
320x240 モードでの解決結果は 640x360 に拡大する事だけです。
これをしたくないならば、
"sw_cursor" オプションを使ってください。
これによって、 640x480 LCD の全面を占有するモードが使えます。
サスペンド/リジュームの時は BIOS がレジスタを読み書きします。 BIOS が分からないモードを使っている場合、 正しくリジュームする保証はありません。 したがって、 VESA 標準にできるだけ近いモードを選択するべきです。 また VGA パレットもサスペンド/リジュームによって 影響を受ける可能性があります。 8bpp を使用している場合、色が正しく表示出来なくなります。 より大きな bpp ではこの現象は発生しません。 またこの問題は仮想コンソールとの画面切替えによって回復可能です。
この現象は通常 "lcd-center" オプションと関連しています。
このオプションを XF86Config から取り除くと、
問題が解消されるかもしれません。
別の原因として、
製造者がパネルの大きさを間違って EGA コンソールモードとして
仕込んだ場合にも発生します。
"fix_panel_size" オプションを使用して
modeline の数値からパネルサイズレジスタの内容を置き換えることが
可能です。
"HP OmniBook 5000" および "NEC Versa 4080" の
2 つの機器で、この問題の発生が報告されています。
X サーバは TFT のバスを 24 ビットと仮定しています。
ほのかに赤みがかかるのはこの仮定が正しくない場合です。
この問題は "use_18bit_bus" オプションを使用することで
解決します。
この反対もありうるので注意してください。
24bpp の TFT バスに "use_18bit_bus" を使用すると
画面にほのかに赤みがかかります。
このオプションは TFT にしか効果がないので注意してください。
まず、指定したモードで 16/24/32bpp を使える機器であるかどうか 確認してください。 多くの液晶ディスプレイでは 24bpp を扱えません。 また 16/24bpp を使うには 65540 以上、 32bpp を使うには 65550 以上が必要です。 モードに使うビデオメモリは 8bpp のそれぞれ 2/3/4倍必要です。 それぞれのモードで X サーバーを起動する時の正しいオプションを 次に示します。
startx -- -bpp 16 5-6-5 RGB ('64K color', XGA)
startx -- -bpp 16 -weight 555 5-5-5 RGB ('Hicolor')
startx -- -bpp 24 8-8-8 RGB truecolor
HiQV 系列のチップ (6555x, 68554 または 69000) では、
次のような指定も可能です。
startx -- -bpp 32 8-8-8 RGB truecolor
画面描画エラーや波うつ画面などの多くのかたちで現れてくる
X サーバについての一般的な問題は、プログラマブルクロックに
関連したものです。
多くのプログラマブルクロックレジスタの設定は潜在的に不安定です。
とはいえ好運にも同じか非常に良く似たクロックを発生させる
多くの異なるレジスタ設定があります。
単に指定するクロック値を少し変更することで、
より安定した異なるクロックを発生するように
クロックプログラムを手なづけることが可能です。
例えば 65.00MHz が不安定であっても 65.10MHz は安定している、
ということもあり得ます。ですから、今までに説明していない問題に
対処するには、クロックをほんの少しづつ、例えば 0.05MHz 刻みに
変更してみて、問題が解消するかどうか試してみましょう。
別の方法として、 65550 以降のチップでは
"use_vclk1" オプションを使ってみるのも良いでしょう。
その他の画面描画に関する問題に対しては、
"noaccel" または "no_bitblt" オプションを
試してみて下さい。
画面表示に問題が発生した場合、
すべてのラップトップコンピュータで有効な技は
LCD/CRT 表示画面切替えです。
(通常ファンクションキー 5 番によって実行できます)
この文書に記載の無いドライバ関連の問題が発生した場合、 もしくは高速化機能にバグを発見した場合には、 XFree86 チームに連絡をとってみて下さい。 (現在このドライバの保守は dbateman@eng.uts.edu.au および Egbert.Eich@Physik.TH-Darmstadt.DE が行なっています。) もしくは、Usenet のニュースグループ "comp.windows.x.i386unix" に投稿して下さい。