お知らせ

  • 利用規約を守って投稿してください。また、よくある質問および投稿の手引きも参照してください。
  • メッセージの投稿にはアカウントが必要です。未登録の方は、ユーザ登録ページからアカウントを作成することができます。

#1 2010-11-05 15:11:37

eemac
メンバ
登録日: 2010-10-30

X.Orgについて

初歩的な質問なんですが、カーネル、OSが画面出力をするまでの仕組みを知りたいのですが、参考になるweb等があれば、お願いします。

Xを使わないCUIにおいてx86パソコンで画面出力するにはどのようにハードを使って
るのでしょうか?XFree86などでGUI環境を作っているというのは聞きますが具体的に
具体的にたとえば、HDD内のあるテキストをモニタに出力するときの一連の流れなど
大雑把ですが、windowsの場合APIの呼び出しになりますが、そのときのAPIの中のハードを含めた詳細になると思いますが。わかりにくくてすみません。

グラフィックボードには専用のグラフィックドライバが必要になりますが、XFree86やX.Org
などではそれがなくてもできるような仕組みを提供している?と思いますが。
具体的にX.Orgとカーネルのやりたとり、また、linuxがCUIモード時の画面出力
までの詳細などをお願いします。

オフライン

 

#2 2010-11-05 16:22:27

funatogawa
メンバ
From: 関東
登録日: 2009-02-01

Re: X.Orgについて

BIOSの出力しているセットアップ画面などはアクセラレータは使っていないので、LinuxのCLI(端末)でもこの画面を使っているだけです。したがって、本来のCLIではXは動きません(必要ありません)。ドライバー(表示プログラム)もBIOSの中に含まれます。ただし、機種によって800×600とか640×200とか400とか固定です。
グラフィックアクセラレータやそのドライバが動いているわけではありません。したがって、XFree86やX.orgも働いていません。
http://www.nas.ne.jp/nas/members/Librar … basic.html

逆に、Xを働かしておいて、CLIウインドウを使うことを仮想端末といいます。

だいぶ昔の勉強なので忘れました。ちがっていたらごめんなさい。
いい教材はないか探しましたが、なにせハード的なもので、PC9801の時代ならともかく、今はチップセットの中に入っていますので、説明した図が見つかりませんでした。
http://ja.wikipedia.org/wiki/PC/AT
http://detail.chiebukuro.yahoo.co.jp/qa … 1215771707

オフライン

 

#3 2010-11-05 18:03:33

eemac
メンバ
登録日: 2010-10-30

Re: X.Orgについて

funatogawa様

解説ありがとうございます。

BIOSがモニタに出力する方法といいますか、そこらへんを詳しく知りたいなと
思います。
BIOS、カーネルがモニタ出力するところのソースといいますか、ハードをどのように
制御して出力しているのかなど。

また、アクセラレーターとは具体的にどのようなことを意味しますか?
よく緊急モード?だったかVGA出力だけで立ち上がるときなど(windows)
グラフィックドライバを使わずに出力することがありますが、そこらへんの
ハードとソフトの詳細がわかるとうれしいです。

ハードを制御するのはOSだと思いますが、OSのハードへのアクセスの仕方?
CPUへのレジスタのアクセスも具体的にどのような感じになってるのか知りたいです。

オフライン

 

#4 2010-11-05 18:40:49

ack
メンバ
登録日: 2007-06-01

Re: X.Orgについて

eemac による投稿:

BIOSがモニタに出力する方法といいますか、そこらへんを詳しく知りたいなと
思います。
BIOS、カーネルがモニタ出力するところのソースといいますか、ハードをどのように
制御して出力しているのかなど。

検索して出てきたものですが、
Linuxカーネル2.6解読室
http://www.amazon.co.jp/Linux%E3%82%AB%E3%83%BC%E3%83%8D%E3%83%AB2-6%E8%A7%A3%E8%AA%AD%E5%AE%A4-%E9%AB%98%E6%A9%8B%E6%B5%A9%E5%92%8C/dp/4797338261
のような書籍と共に、各種フレームバッファのドライバを含むlinuxカーネルのソースコードを見てみる、また
X.orgのソースコードを見てみるのが良いかと思います。

eemac による投稿:

よく緊急モード?だったかVGA出力だけで立ち上がるときなど(windows)
グラフィックドライバを使わずに出力することがありますが、

この状態はUbuntuで言えば「xforcevesa オプションで起動した時」に近いです。
「グラフィックドライバを使わず」ではなく、Windowsが最初から持っている最も汎用なドライバを使って画面を出しています。
実のところ、funatogawaさんの仰るところの

funatogawa による投稿:

グラフィックアクセラレータやそのドライバが動いているわけではありません。したがって、XFree86やX.orgも働いていません。

の画面は、Windowsを使っている場合は「NTLDR is missing ...」のエラー時など、よほどの事が起きない限り目にする事がありません。
(というよりはWindowsにたどり着く前に失敗した場合ぐらい)
※世に出ているWindowsはubuntuで言うところのX.orgに相当する部分をそれだけ止めたりそれなしでOSを動かすことが出来ません。

また、BIOSだけで出せる画面表示はPC/AT互換機であれば基本的に英数字ぐらい(だったはず)で、
「文字だけでウィンドウがないが色があったり漢字ひらがなが出せる状況(WindowsXPなら回復コンソールやセーフモードを選ぶ時のような画面)」
にも、別途画面表示ドライバ(というかソフトウェアというか)が使われています。
ubuntuでは起動時のubuntuロゴの表示がこの方法です。

オフライン

 

#5 2010-11-06 01:57:00

Crush
メンバ
登録日: 2009-02-10

Re: X.Orgについて

これ、Offtopicじゃないのかなぁ。
コードを書かない人間には知る必要がないことで、書ける人ならソースコードで実装例を見てしまった方がグダグダ説明を受けるよりも解ると思うのだけど。
少なくともPC/AT互換機(というか、Windows機)の場合は、表示周りのBIOSには規格があり、BIOSコールをした場合、ハードウェアの違いにかかわらず、一定の動作をするようになっていますので、そこでハードウェアの違いは吸収されます。
ですから、古いPCIのグラフィックカードだろうと、最新のグラフィックカードだろうと、テキストと、ある程度のグラフィック表示については同じように動作するので、本体BIOSが、ビデオカードのBIOSをコールすることで、POST画面の表示などは行われます。
CUIの場合も、BIOSがテキストモードをサポートするので、英数字と記号については、同じように表示されます。
従って互換性を考えた場合は、表示にはハードウェア制御を直接行わず、BIOSをコールすることになります。ただ、正しく実装されていないBIOSも多く、出来るといった解像度が無効であったりすることは意外にザラです。

普通はコンソールや、CUIはテキストモードで、テキストデータとして取り扱います。
但し、アルファベット以外はビデオBIOSがフォントを持っていませんので、日本語表示はソフトウェア的にラップすることによってテキストではなくグラフィックとして表示を行います。内部的には文字ですが、実装としては絵として取り扱っています。
日本語以外でも、表示桁を増やすなど、フレームバッファをCUIに使うこともあります。
ちらっと出てきた98x1等の国産機の一部は、グラフィックスプレーン以外に、日本語フォントと漢字VRAMを持っているため、表示に必要なコードを該当部分に書き込むだけでパターンの転送は必要なく、グラフィックスプレーンとは、ハードウェアによってプライオリティー指定と、合成が行われていました。

制御については、基本的に特定のアドレスに対してウィンドウを開き、データを書き込むことによって、表示装置とのやりとりを行います。
従ってモード変更がうまくいかないなど、書き込むデータやアドレスと、実際の画面モードが異なる場合、
https://forums.ubuntulinux.jp/viewtopic.php?id=9557
の様な現象が発生することがあります。
Windowsの場合は、OS選択のメニュー直前まではテキストモード。漢字表示されるOS選択メニューなどはフレームバッファで表示をしています。

実際の描画の演算をCPUが全てやるのには負担が掛かりますので、グラフィックチップには多くの機能があります。
しかし、それらは、BIOSのサポート外に有りますので、OSや、GUIをサポートするシステムのネイティヴドライバに切り替わったときに、BIOS等ではなく、直接ハードウェアを制御する形で処理は移ります。
それらの恩恵を受け、マウスカーソルの制御や、表示効果などを実現しています。
制御については、接続にもよりますが、基本的には、メモリ空間やI/O空間にマッピングされたハードウェアのレジスタに対して規定の値を書き込むことや、それらによってアドレス空間に開けたウィンドウに対して所定のデータを書き込むことで表示を行います。
それらはハードウェア固有の物であり、そのため、ハードウェアには対応したドライバがOSでは必要になりますし、便宜上表示を行う場合には、VESABIOSをコールすることで、ハードウェアの差異を意識せずに同じコードで表示を行います。
Xの場合は、xforcevesaのそれが近いです。それ故、表示を行うという動作は多くの場合正常に行われる物の、固有の機能は無効であるため、チップが持つ機能を有効にすることは出来ず、パフォーマンスは低下します。

微妙に嘘くさいのですが、厳密な説明に意味があるとも思えませんし、実際にコードを書くなり、読むなりすれば済むことなので、「こんな感じ」と解れば充分です。

vbe3の資料が有った筈なんだけども、見あたらないので、
http://www.monstersoft.com/tutorial1/VESA_intro.html
BIOS経由での制御はこんな風。
MEGADEMOと呼ばれる物にもソースコードが付属している物もあり、それらも古い物はVBEを使っているので、参考になるかもしれません。

どんなに説明されるより実際のコードの方がわかりやすいはずですしその方が解りづらい人には多分知る必要がないことです。
実際の制御は説明しても一行たりともコードは書けないでしょうし理解には至らないと思います。

まとめとしては、
・BIOSは低レベルなグラフィックスと、テキストの表示をサポートする。
・ハードウェア自体は不定であるため、BIOSを介すことで、その差異を吸収し、便宜上の表示は行うことが可能であり、パフォーマンスよりも互換性を重視する場合にはそういった実装を行うし、それ故直接の制御は必ずしも行っていない。
・但し、それらはVBE(VESABIOS)で規定された内容のみであり、場合によっては未実装の物もあるため、或程度の互換性は期待できるが信用は禁物。
・ハードウェアの性能を引き出すにはBIOSの制御によらず、直接ハードウェアを制御することによって、チップが持つ補助機能を利用することが出来るため、パフォーマンスは向上するが特定のハードウェアに依存するため、ハードウェアごとに適切なドライバを書く必要がある。
・動作をするためには制御は必ずあり、ドライバがないのではなく、別の物が制御しているだけである。

オフライン

 

#6 2010-11-06 22:13:40

eemac
メンバ
登録日: 2010-10-30

Re: X.Orgについて

ご回答ありがとうございます。

Linuxカーネル2.6解読室
持っていて観ていなかったので、確認したいと思います。

windowsでの描画も指定のメモリに描画するだけで
そこから先は特に何もしなかった気がしますが。
そこから先は、OSが
指定の場所に書かれた情報を一定のクロックでモニタに
出力し続ける?でよろしいでしょうか?メモリ上変化が
なくても一定の周波数で常に描画し続ける。感じになるんでしょうか?

オフライン

 

#7 2010-11-07 00:12:49

Crush
メンバ
登録日: 2009-02-10

Re: X.Orgについて

>指定の場所に書かれた情報を一定のクロックでモニタに出力し続ける?でよろしいでしょうか?
DRAMのリフレッシュもCPUがソフトウェア的にやるとでも?
そこまで周辺デバイスに気が利かないわけありません。周辺デバイスもまた、自身が規定の動作をするハードウェアであって、普通のPCにおいては、CPUから見た場合すべてのロジックを形成するような動作ではなく、適宜周辺デバイスに必要な要素を共有している信号を使って渡すことになります。
これは表示装置以外でも同じです。

例外的に古いゲーム機とか、ハードウェアがフレームバッファに足るメモリを持っていない場合はトリッキーなコーディングとして走査線レベルでそういうことをしているケースもありますが、普通はそんな必要ありませんし、しません。

よって、電源を供給したまま、制御を切断すると、
http://symzing.way-nifty.com/blog/2005/11/post_8206.html
こんな挙動を示します。
ハングアップしたマシンを前に作りかけの書類を前にして悲しそうな顔をいくらしても、そこからは文章を取り出せないのと一緒です。

ハードウェア制御をするなら、半田ごても握ってデジタル回路もちょっと知ってるとマシかも知れませんね。

オフライン

 

#8 2010-11-07 02:07:56

eemac
メンバ
登録日: 2010-10-30

Re: X.Orgについて

ご返答ありがとうございます。

なるほど、なんとなく想像できました。

オフライン

 

#9 2010-11-07 11:46:08

eemac
メンバ
登録日: 2010-10-30

Re: X.Orgについて

crushさま

解説詳細ありがとうございます。

ハードとソフト周りを含めた学習用キットなどでお勧めがあれば是非お伺いしたいですが、

昔、某大学の情報系で簡単なキットを使ってバス周りやメモリ、CPUなどを制御する学習の
ためにどこかのキットを使っていたのをwebで観たのですが、どこだか忘れてしまいました。
何かお勧めなどwebや秋葉などで簡単で安く入手できるものがあれば是非ご参考までに
教えていただけるとありがたいです。

オフライン

 

#10 2010-11-07 13:14:14

Crush
メンバ
登録日: 2009-02-10

Re: X.Orgについて

http://toshiofukui.com/comp/progs/mz20emu.html
ソースコードが読めるなら、ハードウェアのエミュレートからロジックも見えるはずです。
比較的単純な構造で、規模が小さいので、基本の理解には充分ではないかと。
流石に動く実機は経年劣化でそうそうあるとも思えませんが、ハードウェアを接続するのでなければ問題はないです。
プラグイン形式でハードウェアもソフトウェア的に作成することもできるようになっています。
http://www5d.biglobe.ne.jp/~object/
エミュレータ上での、サンプルはそのベースになったこっちにありますし、このトピックの答えくらいはここにあります。それを見つけられるかどうかは別として。
動くコードは別でも、基本的な構造には大差はありません。

販売は終了していますが、
http://www.msx.d4e.co.jp/1chipmsx.html
こっちでは、MSX相当のハードウェアが実装されていますので、物理的に存在した物が良いのならこちらでも。
VDHLのソースも添付されていますし、VDHLでの実装ですから自分で回路を書き直すことも可能です。
サンプルとしてMSX相当の回路が実装された評価ボードとして見ればPCとして必要な物理的なパーツも付いているので、その気があるのなら回路も作り直せます。
エミュレートされている側のMSXユーザは多かったはずなので、実機側のドキュメントも探せばWeb上に結構あるはずです。
今のハードウェアは歴史的な経緯もあって構造的に複雑になっており、便宜上素直な構造になっていない部分がありますが、化石のようなCPUは命令セットもその回路に直結するような構成になっていますから、「きちんと読めれば」今のそれを見るよりは理解はしやすいはずです。

何度も言われているとおり、ソースがあるならそれを読めばいい。
読めもしないものは書けませんし、話題にする場所も間違っていますので、あとはいじり回すか、余所でどうぞ。少なくともUbuntuとは何の関係もない話題です。
学習用キットや、評価ボードは数が出ない物なので、比較的高価な上、適正がなければがらくたですから、買えばわかるという物でもありませんし。

オフライン

 

#11 2010-11-08 23:11:41

eemac
メンバ
登録日: 2010-10-30

Re: X.Orgについて

Crushさま

ご返信ありがとうございます。

カーネル本とあわせて、確認したいとおもいます。

オフライン

 

Board footer

Powered by FluxBB