モードを切替えた時カーソルを白い矩形に再描画してしまう、
ハードウェアカーソルの問題だと分かっています。
この問題を解決するにはカーソルを他の領域に移動させ、コンソールへ
切替えてから元に戻すか、切替えが面倒なら "sw_cursor"
オプションを用いてハードウェアカーソルを無効にしてください。
6555x の機器でフラットパネル全体に拡大したモードで、ハード
ウェアカーソルがそれ相応に対応していません。これを使用すると
現在のサーバには短時間か長時間だんまりになるバグがあります。
"no_stretch" か "sw_cursor" のどちらかを使うと
このバグを避けることが出来ます。
訳注：ホットスポット:クリックした時の有効点。
殆んどの DSTN 画面はビデオメモリの上位をフレーム高速化に使用して います。これはモードに必要なメモリの量を減少させてしまいます。 サーバは利用者が指定したこのメモリを使うモードを指定することを 妨げたりせず、コンソールに警告のメッセージを表示します。 これによって、画面の下の方にあたる同じメモリ部分がフレーム高速化と 衝突して問題が生じます。モードが消費するメモリの量を削減して下さい。
その画面を取り扱うことができないモードを使用しています。非標準
なモードを使用している場合は、少し画面の時間調整を行なう必要がある
かもしれません。標準的なモードと周波数を使用している場合は、その
画面は取り扱うことができるはずですので、異なる時間調整用に似た
ようなモードと周波数の組合せを探して下さい。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 をプログラマブルクロックに書き込んだ
場合の設定がいつも発見出来るわけではありません。故にサーバは
25.175MHz をコンソール用に決めています。この設定が
殆んどのモードで正常に動作しますが、いくつかの問題が起こります。
一般に LCD と CRT の間の切替えの問題は修正されます。
あるいは "TextClockFreq" オプションを使うと
上記と異なるテキストコンソール用のクロックが選べます。
この問題が起こる他の可能性としてカーネルを "APM_DISPLAY_BLANK"
オプションを指定してコンパイルしている場合があります。
思い当たるならば、このオプションを無効にしてください。
この問題はモードによる画面サイズではなくパネルの大きさに関係した
フラットパネルの時間調節が必要になります。現在の Xservers には
この数値を指定する機能はありませんので、サーバはチップから
パネルの大きさを読み込みます。 "use_modeline" か
"fix_panel_size" オプションを指定した場合は、
パネルの時間調整をこのモードの画面の大きさがパネルの大きさと
異なるようなモードから行ないます。これらのオプションを
XF86Config から取り除くか、LCD/CRT 切替えを試してみましょう。
6554x のハードウェアカーソルでは縦方向に 2 倍になるモードの
バグがあります。画面の下半分が利用できません。
この問題の解決方法は縦方向に 2 倍にしない事です。
320x240 モードでの解決結果は 640x360 に拡大する事だけです。
これをしたくないならば、"sw_cursor" オプションを使って
ください。640x480 LCD の全面を占有するモードを使う事が出来ます。
サスペンド/リジュームの時は BIOS がレジスタを読み書きします。 BIOS が分からないモードを使っている場合、 正しくリジュームする保証がありません。したがって、VESA 標準に 出来るだけ近いモードを選択しましょう。BIOS が分からないモードは VGA パレットに影響を与える可能性があります。8bpp を使用している 場合、色が正しく表示出来ません。より多い bpp の場合は、この現象 は発生しませんが、この問題は仮想コンソールと切替えて修正可能です。
この現象は通常 "lcd-center" オプションを使うと発生します。
このオプションを XF86Config から取り除くと、この問題は発生しません。
または、製造者が EGA コンソールモードのパネルの大きさを間違って
仕込んだ場合にも発生します。 "fix_panel_size" を使用して
modeline の数値からパネルサイズレジスタの内容を置き換えれます。
"HP OmniBook 5000" と "NEC Versa 4080" と
いう 2 つの機器でこの問題が発生することが知られています。
サーバは TFT のバスを 24 ビットを仮定しています。ほのかに
赤みがかかるのはこの仮定が正しくない場合です。この問題は
"use_18bit_bus" オプションを使用することで解決します。
この反対もありうるので注意してください。24bpp の TFT バスに
"use_18bit_bus" を使用すると画面がほのかに赤みが
かかります。このオプションは TFT にしか効果がないので注意して
ください。
先ず、16/24 bpp モードが使える機器であるか確認してください。 多くの液晶ディスプレイは 24bpp が使えません。また、16/24bpp を使うには最低減 65540 が必要です。ビデオメモリは 8bpp の それぞれ 2倍/3倍 必要です。それぞれの起動時の正しいオプション は次のように指定します。
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
65550 そのものは 32bpp が可能ですが "-bpp 32" が可能な
Xserver は現在無いことに注意してください。
サーバに関する画面描画や波うつ画面に関する一般的な問題はプログラマブル
クロックに関連したものです。多くのプログラマブルクロックレジスタの設定
は潜在的に不安定です。とはいえ好運にも同じか非常に良く似たクロックを発生
させる多くの異なるレジスタの設定があります。クロックプログラムは異なる
クロックを発生するようにし、単にクロックを少し変更することでより安定した
クロックを得るようにだまします。例えば 65.00MHz は不安定ですが 65.10MHz
は安定しています。上記で説明していない問題には、クロックを少し変更して
例えば 0.05MHz づつ変更して問題が解消するまで切替えてみましょう。
その他の画面描画の問題は、"noaccel" または "no_bitblt"
オプションを試してみて下さい。画面に問題が発生した場合、すべての
ラップトップコンピュータで有効な技は LCD/CRT 切替えです。
(通常ファンクションキー 5 番です)
この文書に記載の無いドライバ関連の問題が発生したら、もしくは 高速化機能にバグを発見したら、XFree86 チームに連絡をとってみて下さい。 (現在このドライバの保守は dbateman@eng.uts.edu.au か Egbert.Eich@Physik.TH-Darmstadt.DE が行なっています。) もしくは、Usenet のニュースグループ "comp.windows.x.i386unix" に投稿して下さい。