私は基本的に、LinuxカーネルとCでのプログラミングだけでGUIを完全にゼロから作成する方法を理解しようとしています。
GUIデスクトップ環境を最初から作成するつもりはありませんが、いくつかのデスクトップアプリケーションを作成したいと思っています。知識を探す上で、見つけたすべての情報はGUI APIとツールキットに関するものです。少なくともLinux GUIの作成方法の基本を理解するために、APIまたはツールキットを使用せずにGUI環境またはGUIアプリケーションを作成する方法を知りたいと思います。
たとえば、私は疑問に思っています:
既存のAPIとツールキットは、カーネルへのシステムコールを介して機能します(カーネルは、ピクセルまたは何かでGUIイメージを構築するために最低レベルで責任を負います)
これらのツールキットは、情報をスクリーンドライバーに単に渡すシステムコールを実行します(すべてのスクリーンドライバーがこの情報を送信するための標準形式はありますか、またはGUI APIは特定のスクリーン/ドライバーに応じてこの情報を複数の形式で出力できる必要がありますか? )また、これがおおよそ当てはまる場合、raw Linuxカーネルは通常、8ビット文字の形式で情報を画面に送信するだけですか?
Linuxカーネル間で何が起こっているのか、画面に何が表示されているのかを理解したいだけです(知っている場合は、ソフトウェアとハードウェアの両方を流れる制御/情報の流れ、情報の形式など)。詳細な説明をいただければ幸いですが、これは十分に詳細に説明するための参考になるかもしれませんが、このような説明は、好奇心が強く、学習している他の人にとって、すばらしいリソースになると思います。コンテキストとして、私はシステムプログラミングコースのCで最近プログラミングを始めた3年目のコンピュータサイエンスの学生で、Linuxとプログラミングについて中級(またはそれについて説明する)理解を持っています。もう一度私を助けてくれた人にありがとう!!!
それはこのように見えます(縮尺どおりに描かれていません)
┌───────────────────────────────────────────────┐
│ User │
│ ┌─────────────────────────────────────────┤
│ │ Application │
│ │ ┌──────────┬─────┬─────┬─────┤
│ │ │ ... │ SDL │ GTK │ QT │
│ │ ├──────────┴─────┴─────┴─────┤
│ │ │ xLib │
│ │ ├────────────────────────────┤
├─────┴───┬────────┴──┐ X11 │
│ Gnu │ Libraries │ Server │
│ Tools │ │ │
├─────────┘ │ │
├─────────────────────┤ │
│ Linux (kernel) │ │
├─────────────────────┴─────────────────────────┤
│ Hardware │
└───────────────────────────────────────────────┘
図から、X11は主にハードウェアと通信することがわかります。ただし、最初にこのハードウェアにアクセスするには、カーネル経由で通信する必要があります。
私は細部に少しかすんでいます(そして、私が最後にそれを調べてから変更されたと思います)。デバイスがあります/dev/mem
メモリ全体(物理メモリと思います)へのアクセスを提供します。ほとんどのグラフィックハードウェアはメモリマップされているため、このファイル(すべてがファイルであることがわかります)を使用してアクセスできます。 X11はファイルを開き(カーネルがファイルのアクセス許可を使用してこれを実行できるかどうかを確認します)、X_11はmmap
を使用してファイルを仮想メモリにマップし(メモリのように見せます)、メモリはメモリのように見えます。 mmap
の後、カーネルは関与しません。
X11は、メモリを介して直接アクセスするため、さまざまなグラフィックハードウェアについて知る必要があります。
(これには変更、特にセキュリティモデルが含まれる場合があり、メモリの[〜#〜] all [〜#〜]へのアクセスを許可しない可能性があります。 )
下部にはLinux(カーネル)があります。これはシステムのごく一部です。ハードウェアへのアクセスを提供し、セキュリティを実装します。
次にGnu(ライブラリ; bash;ツール:lsなど; Cコンパイラなど)。ほとんどのオペレーティングシステム。
次にX11(またはWayland、...)、基本GUIサブシステム。これは(カーネル外の)ユーザーランドで実行されます。これは、いくつかの特権を持つ単なる別のプロセスです。ハードウェアへのアクセスを許可する以外は、カーネルは関与しません。また、他のプロセスがX11サーバーと通信できるように、プロセス間通信を提供します。
X11のコードを記述できるようにする単純な抽象化。
次は、qt、gtk、sdlなどのライブラリです。これにより、X11が使いやすくなり、ウェイランド、MicrosoftのWindows、MacOSなどの他のシステムで動作します。
アプリケーションはライブラリの上に置かれます。
Xlibを使用することは、X11について学ぶ良い方法です。ただし、最初にX11について少し読んでください。
SDLは低レベルのアクセスを提供し、ビットプレーンに直接アクセスして直接描画します。
低くしたい場合は、現在の選択肢が何であるかはわかりませんが、いくつかのアイデアがあります。
https://en.wikipedia.org/wiki/X_Window_System
これを書くことに興味があったので、それを行うための最新の高速な方法を確認しました。ここにいくつかのリンクがあります:
https://blogs.igalia.com/itoral/2014/07/29/a-brief-introduction-to-the-linux-graphics-stack/
ctrl-alt-delorの答えは、一般的なアーキテクチャの概要を示しています。より実践的なアプローチとして、「LinuxカーネルとCでのプログラミング以外には何もない」という質問にお答えします。
私は時々フレームバッファに直接書き込むのが好きです。フレームバッファーデバイスドライバーは、面倒なハードウェアに近い「これが最終的に画面に表示される方法」などをすべて実行します。あなたはルートシェルを使ってすぐにそうすることができます:
echo -n -e '\x00\x00\xFF' > /dev/fb0
これは、32ビットフレームバッファーの最初(左上)のピクセルを赤に設定します。
/ dev/fb0を開いてバイトを書き込むことで、C内から完全に実行できます。メモリマッピングはあなたの友達になることができます。これは、Xサーバーなしまたは仮想コンソールでのみ機能します。 Ctrl + Alt + F1を押してアクセスします。
PS:マウスの動きのようなランダムデータを視覚化することも楽しいかもしれません。
cat /dev/input/mouse0 > /dev/fb0
PPS:事実上すべての現実のデスクトップアプリケーションは、描画、3D、ビデオレンダリングのハードウェアアクセラレーションなどのいくつかの凝ったもののために、ハードウェアへのより直接的なアクセスを望んでいることにも注意してください。単純なフレームバッファデバイスでは、これはうまく機能しません。
ncurses で始めることを強くお勧めします。
より複雑なグラフィカルシステムとは異なり、これは純粋にテキストに基づいているため、スクリーンドライバーやグラフィックライブラリの詳細に煩わされる必要はありません。ただし、画面上にウィンドウを配置する、ウィンドウ間でフォーカスを移動するなどの基本的な原則は依然として当てはまります。また、単一の文字ブロックとASCIIアートのレベルで、描画を行うこともできます。
もちろん、これはまだライブラリの上に構築していますが、簡単に理解できるライブラリです。それだけでなく、ソースコードが自由に利用できるライブラリであり、かなりよく文書化されており、読みたくても侵入できません。必要に応じて、自分で変更することもできます。または、そこにあるすべてのライブラリ関数を調べて、APIが何である必要があるかを見つけ、その設計に基づいて自分で最初から作成することもできます。
SunOS 5にはDGAライブラリがあり、さまざまなcg [3,6,14]、TCX、またはLEOグラフィックスアダプターへのデバイスに依存しないアクセスを提供しました。これは、SPARCでDoomをサポートするものでもありました。マシン。
cg6は8ビットであり、通常X11で疑似カラービジュアルとして使用されますが、tcxとleoが24ビットアクセラレート3Dディスプレイフレームバッファーであるときに、8ビットトゥルーカラーを提供することもできます(疑似カラー= videoramのバイトは、大容量のインデックスです) 3x8 RGB値を与えるテーブルです。テーブルのコンテンツは簡単に変更できます。)cg3にはほぼ同じ機能がありましたが、高速化されませんでした(cg6デザイナーはその後、別の会社... nVidiaを開始しました)。
ATI Rage Proチップセットに基づいたPGXのような新しいデバイスは、以前のデバイスがサポートしていたトゥルーカラーと疑似カラーを同時にサポートできませんでした。これにより、ユーザーは疑似カラーモデル用に作成された古いアプリケーション(または、可能であればswをアップグレード)とトゥルーカラー指向のアプリケーションのみを実行するアプリケーションのどちらかを選択する必要がありました。
疑似カラーが存在するのは、基本的には、ビデオラムが80年代半ばに1992年頃まで非常に高価だったためです。使用可能なワークステーションタイプの解像度をサポートするカラーディスプレイもかなり高価でした(1984年のSun 2白黒は1152x864の解像度でしたが、1989年ほどのMG1は1600x1280でしたが白黒です)。
X11がサポートしなければならないさまざまな要件を示したいので、これを書いています。